Pruebas de caja negra, blanca y gris

Clase 16 de 29Curso de Fundamentos de Pruebas de Software

Resumen

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.