Glosario · Fundamentos de testing
Pruebas de caja negra
En inglés: Black-box testing
También llamado: caja negra, prueba de caja negra, black box testing, pruebas funcionales
Definición
Probar un sistema a través de sus entradas y salidas frente a los requisitos, sin mirar ni depender del código ni del diseño interno.
Las pruebas de caja negra tratan el sistema como una caja cerrada: proporcionas entradas, observas las salidas y las comparas con lo que la especificación dice que debería pasar. El tester no necesita conocer el lenguaje de programación, la arquitectura ni cómo está estructurado el código. La mayoría de las pruebas funcionales, de sistema, de API y de aceptación son de caja negra.
Ejemplo
Una API de transferencias acepta importes de 1 a 10.000. Sin ver nada de código, un tester de caja negra deriva las pruebas a partir de la regla:
- Particiones de equivalencia: por debajo del rango (0), válido (500), por encima del rango (10.001), no numérico (
"abc"). - Valores límite: 0, 1, 2, 9.999, 10.000, 10.001.
- Resultados esperados: los importes válidos devuelven
201 Created; los inválidos devuelven400 Bad Requestcon un mensaje de error y no mueven dinero.
Las técnicas usadas aquí, la partición de equivalencia y el análisis de valores límite, junto con las tablas de decisión, las pruebas de transición de estados y el pairwise testing, son las técnicas fundamentales de diseño de caja negra.
Caja negra vs. caja blanca
| Caja negra | Caja blanca | |
|---|---|---|
| Base | Requisitos y especificaciones | Estructura interna del código |
| Conocimiento necesario | Qué debe hacer el sistema | Cómo está escrito el código |
| Niveles típicos | Sistema, API, aceptación | Unitario, parte de integración |
| Se mide con | Cobertura de requisitos | Cobertura de código (sentencias, ramas) |
| Encuentra | Comportamiento ausente o incorrecto, discrepancias con la especificación | Caminos sin probar, código muerto, errores de lógica |
Ninguna reemplaza a la otra. Las pruebas de caja negra pueden encontrar funcionalidades que nunca se implementaron, algo que la caja blanca no puede, porque no hay código que inspeccionar. Las pruebas de caja blanca pueden encontrar caminos que la especificación nunca menciona. Las pruebas de caja gris combinan ambas: se prueba a través de la interfaz usando algo de conocimiento interno, por ejemplo comprobando la base de datos después de una llamada a la API o sabiendo a qué servicio llega una petición.
Fortalezas y límites
Las pruebas de caja negra son independientes de la implementación, así que sobreviven a las refactorizaciones y se pueden escribir a partir de los requisitos antes de que exista el código. Su límite es que no sabes qué caminos internos te saltaste y, sin técnicas sistemáticas, es fácil probar solo los happy paths evidentes.