Pruebas de caja negra, blanca y gris

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.

Elmer Padilla Espinoza

Buen resumen Antonio, Gracias.

Juan Pablo Perez

Gracias por los apuntes Antonio.

María Guadalupe Aranda González

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

Juan Pablo Perez

Gracias Lupita.

Emanuel Vega Rozo

Hace 5 años

Gracias! por poco volteo todo elescritorio buscando jajaja

VICTOR CASTILLO

Podrian darme su opinion? Gracias

Sonia Silva Contreras

cómo le hiciste para subir la imagen ? soy nueva en platzi y no logré subir las fotos de mi cuadro de apuntes, aproposito muy ilustrativo y útil el tuyo, saludos

Oscar Bustos Peña

Hace 3 años

me parecen buenas las propuestas

Diego Adrián Sánchez Gutiérrez

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

Miguel Angel Reina Walteros

Hace 4 años

Caso 1 Sitio Web: Pruebas de caja negra, verificar si hay formulario de contáctenos, si si verificar su diligenciamiento y validaciones correspondientes a los campos, si no se realizan pruebas de rendimiento, adicional pruebas de carga o tiempo de respuesta, pruebas de responsive o adaptabilidad a múltiples dispositivos o resoluciones. Caso 2 Aplicación Móvil: prueba de caja negra, verificar si carga con o sin datos o internet, verificar el flujo o navegación por los módulos, prueba de rendimiento, carga o tiempo de respuesta, probar que pasa si me paso a otra aplicación en el celular, se cierra la sesión? pierdo lo que he realizado?, probar si se pierde la señal de datos o internet o perdida de conexion Caso 3 una API: prueba de caja gris, probar conexión al servidor, tiempo de respuesta de las solicitudes, almacenamiento de la información completa en el servidor Caso 4 caso de uso: prueba de caja blanca, verificación del caso de uso de un frontal, probar que esta validando los campos obligatorios que se necesitan en la base de datos para no enviar campos nulos o vacíos en el formulario, validar el correcto flujo del proceso o diagrama, que pasa si se salta un paso del caso de uso.

estas serian algunas de las pruebas a realizar en los ejercicios.

Luz Mery Patiño

No es muy clara la diferencia entre partición de equivalencia y valores limites

María Inés Santander Arrazola

Los valores límite son una extensión de la partición de equivalencia, pero solo se puede utilizar cuando la partición es ordenada, y consiste en datos numéricos y secuenciales. Los valores mínimo y máximo (o valores inicial y final) de una partición son sus valores frontera/límite (Beizer 1990). Tomado del Programa de estudio ISTQB CTFL

Irving Juárez

Usando la lógica podemos decir que la partición de equivalencias se enfoca en los datos que sirven y los que no, mientras que los valores limites solo tiene un valor limite, como el hecho de que no podemos comprar mas de $8000 en una sola compra (ejemplo)

Gustavo Hernan Tiseira

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.

Joel Eduardo Gaspar

Que literatura se recomienda para estos temas?

Adrian Peralta

para tests de caja negra y blanca podría ser algún libro sobre TDD como: Test-Driven Development with Python.
En el libro utilizan selenium para los test de caja negra y tests unitarios para los tests de caja blanca.

para los tests de caja gris, tal vez algún libro de integration testing.

Espero que compartan más sugerencias.
Saludos.

Joel Eduardo Gaspar

Muchas gracias por tu respuesta!

Daniela Muñoz Jiménez

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.

Andres Velasquez

Hace 4 años

Este es un aporte clave. La especificidad de la información juega un papel que evita el retrabajo y la duplicación de pruebas.

Ricardo Blanco

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

Carlos Nassif Trejo Garcia

Reinaldo Mendoza

Que genial como se ven esas notas, es algun sw en especifico?

Jose Sanchez

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

Juan Pablo

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)

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)
Valores límite Evaluar y verificar que pasa cuando se pasa de un limite condicional
Tabla de decisiones Para check box o una lista (solo pueden ser seleccionables)
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 )
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)

Cobertura de declaraciones
Cobertura de código

CAJA GRIS (técnicas)

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

Natali Rodríguez

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.

Eleazar Ponce Guardiola

Hace 2 años

gracias

JUAN FELIPE CONTRERAS DELGADO

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.

Daniel Andres Rojas Paredes

Hace 2 años

pues no se si te sirva pero yo lo entiendo como probar que el fujo de datos entre frontend y back end sea correcto. en back end lo que pruebo no es el flujo de datos sino las operaciones que se hacen con esos datos.

Daniela Lombo Rodriguez

Hace 8 meses

Ejercicios resueltos:

a) Un sitio web

Pruebas de Caja Negra

(No se conoce el código, solo se prueba la funcionalidad)
Verificar que el usuario pueda registrarse e iniciar sesión con datos válidos.
Probar formularios (campos obligatorios, validaciones, mensajes de error).
Navegación entre páginas (menú, enlaces, botones).
Pruebas de compatibilidad en distintos navegadores (Chrome, Firefox, Edge).
Pruebas de usabilidad y experiencia de usuario.

Pruebas de Caja Blanca

(Se conoce el código fuente)
Pruebas unitarias de funciones JavaScript (validaciones, cálculos).
Revisión de rutas y controladores del backend.
Cobertura de código (if/else, bucles).
Verificación de consultas a la base de datos.
Pruebas de seguridad a nivel de código (inyección SQL, XSS).

Pruebas de Caja Gris

(Conocimiento parcial del sistema)
Probar flujos completos sabiendo cómo interactúan frontend y backend.
Verificar cookies, sesiones y tokens.
Pruebas de carga simulando usuarios concurrentes.
Validar respuestas del servidor según distintos roles de usuario.

b) Una aplicación móvil

Pruebas de Caja Negra

Instalación y desinstalación de la app.
Pruebas de interfaz (botones, gestos, navegación).
Validar notificaciones push.
Comportamiento con y sin conexión a internet.
Pruebas en distintos dispositivos y tamaños de pantalla.

Pruebas de Caja Blanca

Pruebas unitarias del código (Kotlin, Swift, Flutter, etc.).
Validación de métodos, clases y controladores.
Manejo de excepciones y errores.
Uso correcto de memoria y recursos del dispositivo.

Pruebas de Caja Gris

Interacción de la app con APIs externas.
Manejo de datos locales (cache, base de datos interna).
Pruebas de seguridad (almacenamiento de credenciales).
Flujos de usuario con conocimiento parcial de la arquitectura.

c) Una API

Pruebas de Caja Negra

Verificar endpoints (GET, POST, PUT, DELETE).
Validar códigos de respuesta (200, 400, 401, 500).
Pruebas con datos válidos e inválidos.
Pruebas de autenticación y autorización.
Uso de herramientas como Postman o Insomnia.

Pruebas de Caja Blanca

Pruebas unitarias de controladores y servicios.
Validar lógica de negocio interna.
Pruebas de manejo de errores.
Revisión de consultas a base de datos.
Análisis de cobertura del código.

Pruebas de Caja Gris

Pruebas de integración con otros sistemas.
Validar reglas de negocio con conocimiento parcial.
Pruebas de seguridad (tokens, roles).
Pruebas de rendimiento con conocimiento del flujo interno.

d) Un caso de uso

Ejemplo: “Usuario realiza una compra”

Pruebas de Caja Negra

Usuario selecciona producto y lo agrega al carrito.
Realiza el pago con datos válidos.
Recibe confirmación de compra.
Validar mensajes de error en pagos fallidos.

Pruebas de Caja Blanca

Verificar la lógica de cálculo del total.
Validar flujo del código de pago.
Pruebas unitarias de reglas de negocio (descuentos, impuestos).
Verificación de transacciones en base de datos.

Pruebas de Caja Gris

Flujo completo sabiendo qué servicios intervienen.
Verificar comunicación entre módulos.
Pruebas de seguridad en el proceso de pago.
Simulación de fallos parciales (timeout, error de servicio).

Irving Juárez

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

Lizeth Churaira

Hace 4 años

muchas gracias

Edinson Padrón

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

Sonia Silva Contreras

Diferencias entre cobertura de declaraciones y cobertura de código ?

Daniel Adolfo Ordoñez Rubio