Caja Blanca, Gris y Negra

Apuntes:

Caja Blanca, Gris y Negra

Cuándo estamos refiriéndonos a “una caja” es la manera de observar el contenido del Software, ya sea que no tenemos noción más que la interfaz con la que estamos trabajando, caja negra. Cuándo podemos ver todo el contenido como una caja de cristal, caja blanca. Las integraciones, los datos cómo fluyen de un lugar a otro, dónde no conozco el código ni veo interfaz pero puedo ver cómo fluye la información a través de las redes, caja gris.

Caja Negra

• Participación de Equivalencia. Esos grupos de datos que pueden entrar para casos exitosos o para casos no exitosos.

• Valores Límite. Se puede tener usado un rango de valores.
• Tabla de Decisiones. Va enfocada si tuviéramos valores seleccionables.
• Transición de Estados. Cómo el componente se comporta.
• Casos de Uso. Realizar escenarios que pueda realizar el usuario.

Caja Blanca

• Cobertura de declaraciones. Las declaraciones son todo aquello que tienes dentro del código y estás asumiendo que es lo que se pide que haga, al decir cobertura es, dependiendo el tipo de software, los requerimientos, el objetivo, se establece un porcentaje de cobertura, esto significa que, cada línea de código debería ser ejecutada al menos una vez, cada sentencia debería de ejecutarse alguna vez.
• Cobertura de código. Que se evite tener código obsoleto.

Caja Gris

• Casos de Negocio. Es necesario conocer cómo el usuario interactúa, qué datos ingresa y qué datos van a ser retornados.
• Pruebas End to End. Cómo se están agregando datos y aún no queremos ver datos de salida.
• Pruebas de integración. Ver cómo viajan esos datos, la respuesta y la comunicación de cómo fluyen los datos entre diferentes servicios.

Los ejercicios vienen en el pdf de la sección archivos del vídeo 1 de la introducción, página 81.
EJERCICIOS:
Diseñar y ejecutar pruebas correspondiente a :
a. un sitio web
b. una aplicación móvil
c. una API
d. un caso de uso

Podrian darme su opinion? Gracias

Pruebas de caja
Negra: No vemos como fue construido, no vemos el código, no sabemos su arquitectura

• Partición de equivalencia: Grupos de datos para casos exitosos y fallos
• Valores límite: Que valores se pueden introducir
• Tabla de decisiones: valores de decisión lógicos
• Transición de estados: dependencias de otras acciones
• Casos de uso: probar que funcione correctamente
  Blanca: podemos ver todo lo que esta dentro, evitar la ceguera de no ver los defectos a los que uno ya esta acostumbrado.
• Cobertura de declaración: eliminar código inútil o problemático
• Cobertura de decisiones
  Gris: las integraciones vemos como se transmiten los datos a través de las redes
• Casos de negocio: que se procesen los datos y regresen un valor
• Pruebas End to End: se ingresan datos pero no se obtiene una respuesta visual
• Pruebas de integración: como viajan los datos

Este canal me ayudó mucho con los ejemplos, espero también les sirva

https://www.youtube.com/channel/UCVD0XAaYNHSb_YhaT9D-P3Q

Que literatura se recomienda para estos temas?

Las pruebas sólo pueden demostrar la presencia de errores, no su ausencia.
-Dijkstra

EJERCICIOS:
Diseñar y ejecutar pruebas correspondiente a :
a. un sitio web
b. una aplicación móvil
c. una API
d. un caso de uso

Quizas no sea el espacio para poder decir esto pero les dejo una sugerencia que puede observarse de analizar la caja negra en la pantalla de la clase.
Cuando uno realiza la escritura de comentario en el campo para poder hacerlo y luego por X cuestion desea alterar el tamano del navegador que esta utilizando pierde lo que tenia escrito. Y uno debe volver a escribir.
Debería permanecer escrito ya que muchas veces uno busca materiales para compartir y tiene que moverse en distintas partes.

Para mayor información, recomiendo encarecidamente este artículo de la Wikipedia

Caja negra hace alusión de que no se puede ver adentro de la caja, solo tenemos unos datos de entrada y otros de salida.
Mientras que la caja blanca, se puede ver como se están haciendo las coas, es decir se puede ver el código.
Por otro lado entre estos dos tipo, esta la caja gris, en la que aun no se ve una interfaz ni código pero si vemos como los datos fluyen de un lugar a otro (las integraciones), como se trasmiten los datos a través de las redes.

CAJA NEGRA (técnicas)

1. Partición de equivalencia
   Grupo de datos para casos exitosos y no exitosos (Condiciones ejemplo: Cuando en un input donde solo puedo ingresar valores solo con 5 dígitos, que sean mayores a 10 y menores a 100)
2. Valores límite
   Evaluar y verificar que pasa cuando se pasa de un limite condicional
3. Tabla de decisiones
   Para check box o una lista (solo pueden ser seleccionables)
4. Transición de estados
   Como un componente se comporta en relaciona con otros (Cuando por ejemplo para enviar un mensaje de whatsapp, tienes que escribir algo para que el botón cambie del símbolo de audio al de enviar )
5. Casos de uso
   Probar que el usuarios termine un proceso, como por ejemplo llenar un formulación.

CAJA BLANCA (técnicas)
Porcentaje de cobertura se refiere a que cada función o linea de código debe ejecutarse al menos una vez. (Evitar código inútil)

1. Cobertura de declaraciones
2. Cobertura de código

CAJA GRIS (técnicas)

1. Casos de negocio
   Conocer como el usuario interactuar
2. Pruebas END TO END
   consiste en probar flujos de ejecución en una aplicación de comienzo a fin
3. Pruebas de integración
   Como viajan los datos entre diferentes servicios y sus respuestas.

Caja negra
Son las pruebas en donde no sabemos como funciona el software por dentro
Caja blanca/transparente
Es cuando sabemos como funciona el software por dentro
Caja gris
Es cuando vemos partes de la interfaz del usuario y de la parte de adentro del software

Cuando pienso en pruebas lo que siempre recuerdo son las pruebas de caja negra y caja blanca. Las pruebas de caja gris siguen siendo un concepto ambiguo para mi, aun después de ver el vídeo.

Un Sitio WEB: Envió de correo electrónico al registrar una transacción
Pruebas de Caja Negra: Funcional
Caso 1: Datos de entrada: Registrar pedido de venta. Resultado esperado (Salida): El sistema envía un correo electrónico al cliente como constancia que su pedido se ha recibido.

Caso 2: Datos de entrada: Registrar despacho de mercancía al cliente. Resultado esperado (Salida): El sistema envía un correo electrónico al cliente como constancia que se ha realizado el despacho.

Caso 3: Datos de entrada: Registrar factura de cliente. Resultado esperado (Salida): El sistema envía un correo electrónico al departamento de facturación y al cliente.

Caso 4: Datos de entrada: Registrar cobro. Resultado esperado (Salida): El sistema envía un correo electrónico al departamento de cuentas por cobrar y al agente comercial (vendedor) que lleva la cuenta del cliente.

Negra
No podemos observar cómo fue construida, no vemos el código, no sabemos su arquitectura, no tenemos nociones más que la interfaz que estamos interactuando.
Partición de equivalencia
Valores límite
Tabla de decisiones
Transición de estados
Casos de usos
Blanca
Es como una caja de cristal, puedo ver todo lo que hay adentro e incluso puedo ser parte del equipo que desarrolla el software.
Cobertura de declaración
Cobertura de decisiones
Gris
Pueden ser la integraciones, cómo fluye el código y puedo ver como se transmiten los datos a través de las redes.
Casos de negocios
Pruebas End-to-End
Pruebas de integración

Al principio pensé que sería muy fácil diseñarlos, después me di cuenta que la gran mayoría de los casos de pruebas, deben de partir de un requisito, por ejemplo la autenticación previa de usuario.
El nivel de detalle es algo importante a considerar, los pasos pueden ser enormes con mucho detalle, o muy cortos con poco detalle.
También me parece que sería mejor (para los caso de uso funcionales), agregar una columa que especifique los caso de uso relacionados, y otra para los requisitos del caso.

pregunta: No veo los ejercicios en esta clase.¿donde los encuentro ?

Que mala onda que tengamos que ir hasta la primera clase a buscar los ejercicios que menciona la maestra…

Recomiendo la lectura de este post si quieren comprender un poco mejor, con ventajas y desventajas:

https://www.solvd.com/blog/black-white-grey-box-testing

Caja Negra: (Front-End)

• partición de equivalencia
• Valores Limite
• tabla de decisiones
• transacción de estados
• Casos de Uso

Caja Blanca: (Back-End)

• Cobertura de declaraciones

• Cobertura de código

  1. sentencias
  2. decisiones
  3. condiciones

Caja Gris:

• Casos de Negocio
• Pruebas End to End
• pruebas de Integración

Encontre otra prueba de Caja Negra.
Pruebas de historias de usuario:
Prueba muy utilizada en metodologías Ágiles como puede ser el Scrum. Los requerimientos de usuario son preparados como historias de usuario.
Estas historias de usuario describen una funcionalidad que puede ser desarrollada o probada en una misma secuencia.
En estas descripciones en las historias de usuarios suelen aparecer funcionalidades a implementar, requerimientos no funcionales y los criterios de aceptación.
Los criterios de aceptación abarcan la cobertura mínima requerida para la historia de usuario.
Los casos de pruebas se basan en estos criterios de aceptación.

Que opinan?
Comparto el Link https://howtotesting.com/testing-funcional/pruebas-de-caja-negra/

Caja Negra:

• Partición de Equivalencia
• Valores límite
• Tabla de decisiones.
• Transición de Estados
• Casos de uso.

Caja Blanca:

• Cobertura de Declaraciones
• Cobertura de Código.

Caja Gris:

• Casos de Negocio
• Pruebas End to End
• Pruebas de integracion

Por favor, suban los ejercicios. Hace 13 días que se publicó esta inquietud y no la han respondido. Estos ejercicios sirven para practicar y profundizar en el tema. O es que los ejercicios aparecen en vídeos posteriores?

Done puedo ver los ejercicios?

Comparto los ejercicios:

Pruebas de caja negra

1. particion de equivalencia: grupos de datos que ingresan exitosos y no exitosos
2. valores limite: definir datos , hasta cuantos digitos
3. tabla de decisiones: true o false
4. transicion de estados: como se comporta el componente, si necesita de otro para estar activo
5. casos de uso: el usuario puede llenar el formualrio pasa al siguiente si esta completo

Pruebas de caja Gris

Pruebas de caja Blanca

Pruebas de caja Negra

En la Academia de Ingles de Platzi se encuentra un curso genial. Ingles para Developers en el que hablan más acerca de esto.

Cuando no estamos refiriendo a una caja es la manera de observar el contenido de software.

Negra:No podemos observar cómo fue construida, no vemos el código, no sabemos su arquitectura, no tenemos nociones más que la interfaz que estamos interactuando.

Partición de equivalencia
Valores límite
Tabla de decisiones
Transición de estados
Casos de usos
Blanca: Es como una caja de cristal, puedo ver todo lo que hay adentro e incluso puedo ser parte del equipo que desarrolla el software.

Cobertura de declaración
Cobertura de decisiones
Gris: Pueden ser la integraciones, cómo fluye el código y puedo ver como se transmiten los datos a través de las redes.

Casos de negocios
Pruebas End-to-End
Pruebas de integración

Muy interesante

Caja negra > Transiciones de Estados en Formularios

Un caso muy común son los campos obligatorios. Por ejemplo: si un usuario no ingresa un contacto, no debe de poder completar el formulario hasta llenarlo. Por lo cuál el estado del botón “Enviar formulario” debería verse en modo inactivo hasta que el campo mencionado se complete.

Caja Blanca, Gris y Negra
Se llaman pruebas de caja porque es la manera de observar el contenido del software.

Los modelos de caja negra es cuando por ejemplo en un computador no vemos como fue construido, se puede referenciar dentro del desarrollo como la parte del Backend, el codigo, no sabemos de arquitectura, si no la unica noción que tenemos es la interfaz con la que interactua el usuario

Pruebas de caja negra
Partición de equivalencia: Que tipo de informacion dentro de los tipos de datos deberia contener por ejemplo un formulario, enteros, flotantes

Valores límite: Establecer limites por ejemplo un maximo de digitos en una fraccion en pesos. Que pasa si coloco una fraccion de 90.001 o 90.000.001 o 90.000.00001

Tabla de decisiones: Aplica para casos donde existen check box o listas y son valores fijos, no le corresponde la opcion de establecer un criterio a los usuarios

Transición de estados: Como el componente se comporta

Casos de usos: Por ejemplo donde un usario puede llenar un formulario y enviarlo o los campos son obligatorios y no puede pasar al siguiente campo hasta no completar los que son obligatorios

Los modelos de caja blanca es llamada en ocasiones caja de cristal, se puede referenciar dentro del desarrollo como la parte del Frontend, donde se puede ver todo lo que hay adentro e incluso es posible ser parte del equipo que esta desarrollando software

Pruebas de caja blanca
Cobertura de declaración: Es todo aquello que esta dentro del codigo y se pide hacer, es decir que cada linea de codigo realizada se ejecute por lo menos una vez, debe tener una cobertura medible por porcentaje

Cobertura de codigo: Es eliminar todo tipo de codigo que sea innecesario en el producto o proyecto teniendo en cuenta:

Sentencias

Desiciones

Condiciones

Los modelos de caja gris es donde se realizan integraciones, viene siendo un punto intermedio entre la caja blanca y la caja negra y podemos ver los datos como fluyen o se transmiten de un lugar a otro

Pruebas de caja gris
Casos de negocios: Como el usuario esta interactuando en el Frontend o la interfaz y como esta respondiendo el producto es decir todo lo que va al Backend, se transforma y de que forma regresa la informacion al Frontend de nuevo. Es decir datos de entrada y salida

Pruebas End-to-End: Se refiere por ejemplo a la creacion de un usuario para una aplicacion pero no necesariamente se tiene que ver como quedo en la salida y posiblemente no se vea el resultado pero se visualiza en otro entorno

Pruebas de integración: Es ver como se estan transmitiendo los datos del Frontend al Backend

Tipos de pruebas de CAJA NEGRA

• Partición de equivalencia: Se divide entre los datos validos y los que no son.
• Valores limite: Determina un valor limite para un cierto tipo de dato
• Tabla de decisiones: Esta aplica al momento en el que tenemos elementos que puedan ser true/false o si/no
• Transición de estados: Aplica en cosas como los videos de platzi (están en pausa, en play, silenciados, etc)
• En los casos de uso es como una prueba para saber si se puede realizar ciertas acciones

Yo Hice Mis Purebas en Python Con Una libreria llamada unittest su
modulo interno de unittet llamado TestCase o tambien caso de prueba
consiste en ir verificando cada modulo si pasa la prueba el mismo te indica que las pruebas salieron Ok y sino te muestra las fallas se ejecuta directamente en el modulo principal yo recomiendo hacerlo en un archivo Aparte importarlo y dejarlo hay y hacer las pruebas con el respectivo codigo que te pasan para corregir …
Te invido a Probarla y ver como te va aki un breve ejemplo correro y me dices como te fue

import unittest

def suma(num_1,num_2):
return num_1 + num_2

class CajaNegraTest(unittest.TestCase):

def test_suma_dos_positivos(self):
    num_1 = 10
    num_2 =  5

    resultado = suma(num_1,num_2)

    self.assertEqual(resultado, 15)

def test_suma_dos_negativos(self):
    num_1 = -10
    num_2 = -7

    resultado = suma(num_1,num_2)

    self.assertEqual(resultado, -17)

if name == “main”:
unittest.main()

entonces por ejemplo, en la caja gris irían las pruebas al servicio web?

no hay los ejercicios 😦

Dónde están los ejercicios de Caja Negra, Gris, Blanca?

Cuando no estamos refiriendo a una caja es la manera de observar el contenido de software.

Negra: No podemos observar cómo fue construida, no vemos el código, no sabemos su arquitectura, no tenemos nociones más que la interfaz que estamos interactuando.

Partición de equivalencia
Valores límite
Tabla de decisiones
Transición de estados
Casos de usos

Blanca: Es como una caja de cristal, puedo ver todo lo que hay adentro e incluso puedo ser parte del equipo que desarrolla el software.

Cobertura de declaración
Cobertura de decisiones

Gris: Pueden ser la integraciones, cómo fluye el código y puedo ver como se transmiten los datos a través de las redes.

Casos de negocios
Pruebas End-to-End
Pruebas de integración

Cuál es la diferencia entre la técnica de casos de usos vs casos de negocio?

Caja Negra: Interfaz.

• Participación de Equivalencias
• Valores límites
• Tabla de decisiones
• Transición de estados
• Casos de usos.
  Caja Blanca: Ingresó a la fuente, su interior.
• Cobertura de declaraciones
• Cobertura de decisiones.
  Caja Gris:Comunicación del código
• Casos de negocios
• Pruebas End to end
• Pruebas de integración.

Entendido

La caja se refiere al contenido del software.

• Negra -> No conocemos su código ni arquitectura ni cómo fue construido. Solamente la noción de la interfaz.
• Blanca -> Puedo ver todo lo que hay dentro, incluso puedo ser parte del equipo que desarrolló el software.
• Gris -> No conozco el código, pero veo cómo se transmiten los datos.

Técnicas de pruebas:

• Caja negra
  • Partición de equivalencia
  • Valores límite
  • Tabla de decisiones
  • Transición de estados
  • Casos de uso
• Caja gris
  • Casos de negocio
  • Pruebas End to End
  • Pruebas de integración
• Caja blanca
  • Cobertura de declaración
  • Cobertura de decisiones

Las prubeas “End to End” consisten en: Yo como usuario hago cosas y la información se verá reflejada no en mí, sino en otra parte de front end.

Las pruebas de integración son las respuestas y la comunicación de cómo fluyen los datos entre diferentes servicios.

¡También hay que tomar en cuenta los datos vacíos! Se debería mostrar un mensaje diciendo “No puedes dejar X campo vacío”.

En un textboxt creo que también entra la tabla de la verdad, el el momento de validar el tipo de datos, por ejemplo con expresiones regulares, si cumple o no el patrón!

Caja blanca
En los tipos de pruebas que se aplican a la caja blanca son las de cobertura, ósea que se checan que estén funcionando correctamente una cierta cantidad de modelos del código o de las declaraciones en este caso

Para complementar estas lecciones. les aconsejo que tomen el curso de English for Developers, ahí también explican esto de las cajas.