Pruebas de caja negra, blanca y gris
Clase 16 de 29 • Curso de Fundamentos de Pruebas de Software
Contenido del curso
Principios de las pruebas
- 2

Por qué el testing moderno previene errores
09:26 min - 3

Pruebas de software en cada etapa del desarrollo
06:51 min - 4
Pruebas en el Ciclo de Vida del Software: Mejora y Optimización
01:35 min - 5

Anomalía vs defecto vs fallo vs error
10:04 min - 6

Los siete principios del testing moderno
11:43 min - 7

Roles de testing especializados y tu path de crecimiento
12:18 min
Testing
- 8

Testing en cada fase del desarrollo
13:19 min - 9

Mapas mentales para estrategias de testing
09:10 min - 10

Testing vs checking en automatización de pruebas
10:53 min - 11

Testing ágil: todo el equipo prueba
08:03 min - 12

Niveles de pruebas: componentes a sistema
05:11 min - 13

Tipos de pruebas de software explicados
04:42 min - 14

Pruebas estáticas vs dinámicas en testing
10:01 min - 15

Cómo diseñar casos de prueba efectivos
13:10 min
Gestión, monitoreo y control
Gestión de bugs
Depuración
Bases de la automatización de pruebas
Comprende con claridad cuándo aplicar pruebas de caja negra, caja blanca y caja gris para asegurar calidad, cobertura y seguridad en software. Aquí se explican técnicas clave como partición de equivalencia, valores límite y tablas de decisiones, además de cobertura de declaraciones y cobertura de código, y validaciones de casos de negocio, pruebas end-to-end e integración.
¿Qué son pruebas de caja negra, caja blanca y caja gris?
Las pruebas de caja se nombran según el acceso al contenido del software. En caja negra no se ve el código ni la arquitectura: solo la interfaz de usuario. En caja blanca se observa todo el interior, como una caja de cristal, y se ejecutan pruebas desde el código. Entre ambas, la caja gris valida datos, servicios y cómo fluyen por redes y microservicios, sin ver necesariamente el código ni solo la interfaz.
- Caja negra: útil cuando un tercero prueba sin sesgos y evita la “ceguera de taller”.
- Caja blanca: se apoya en el equipo de desarrollo para revisar el código en detalle.
- Caja gris: se centra en datos, integraciones y servicios entre frontend y backend.
¿Qué técnicas de caja negra aplican a formularios y flujos?
Ejemplo práctico: un formulario web con un campo “cantidad” que debe aceptar números. Con este contexto se aplican técnicas para validar entradas válidas e inválidas, así como el comportamiento de la interfaz.
¿Cómo aplicar partición de equivalencia?
Agrupa los datos en clases válidas e inválidas para reducir casos y maximizar cobertura.
- Aceptar solo números que representen una cantidad numérica.
- Definir rangos válidos (por ejemplo: cinco dígitos, menores de noventa mil, mayores de diez mil).
- Separar claramente las clases inválidas (cadenas, símbolos, valores fuera de rango).
¿Qué validar con valores límite?
Verifica extremos y bordes del rango permitido.
- Ingresos justo por encima del tope: 90,001.
- Decimales en el límite: 90,000.0001, si el campo permite decimales.
- Cantidad de dígitos permitidos: ¿hasta cuántos admite el campo?
- Valores especiales: 0 o negativos, si la especificación los contempla o los prohíbe.
¿Cuándo usar tablas de decisiones?
Cuando hay opciones fijas y seleccionables.
- Valores como verdadero/falso o sí/no.
- Listas cerradas donde cualquier valor fuera de la lista debe marcar error.
-
Implementación sugerida con radio buttons o checkboxes para evitar entradas libres.
-
Transición de estados: valida cómo cambia un componente según acciones del usuario. Ejemplo con video: pausa, play, detenido, adelantar y regresar.
- Casos de uso: comprobar que el usuario llena el formulario y lo envía. Validar campos obligatorios y la imposibilidad de avanzar si falta alguno.
¿Cómo se mide la caja blanca y qué riesgos aborda?
La caja blanca se enfoca en dos ejes: cobertura de declaraciones y cobertura de código. Se define un porcentaje de cobertura según el tipo de software y su riesgo. Cada línea y cada sentencia deberían ejecutarse al menos una vez para decidir si pasa de pruebas a producción.
- Establecer un porcentaje objetivo de cobertura acorde al riesgo.
- En software crítico (por ejemplo, análisis de salud), exigir coberturas cercanas a 99.99%.
- En otros contextos, puede bastar con 70% si cubre sentencias, decisiones y condiciones.
- Objetivo clave: eliminar código inútil y reducir superficies de ataque y fallos de seguridad.
¿Qué validan las pruebas de caja gris en datos e integraciones?
La caja gris conecta frontend y backend validando datos, servicios y microservicios. Importa cómo entran, se procesan y salen los datos.
- Casos de negocio: el usuario compra un artículo y consulta el status del pedido; hay datos de entrada, procesamiento y salida visibles para el usuario final.
- Pruebas end-to-end: crear un usuario, agregar datos y visualizar la información en otro frontend. No siempre es un caso de negocio; puede ser propio del administrador del sitio.
- Integración: comprobar el flujo y la confirmación entre servicios. Ejemplo: “el dato A llegó” con estatus aceptado o activo.
¿Qué pruebas adicionales sumarías dentro de la caja negra, la blanca o la gris? Comparte tus ideas y experiencias en los comentarios.