¿Qué Son las Pruebas de Caja Gris?
Las pruebas de caja gris (grey-box testing) se ubican entre el black-box y el white-box testing. El tester tiene conocimiento parcial del funcionamiento interno del sistema — suficiente para diseñar pruebas más inteligentes que el puro black-box, pero sin la visibilidad completa del código fuente del white-box.
Un tester de caja gris podría conocer:
- La arquitectura del sistema (qué servicios se comunican entre sí)
- El esquema de base de datos (estructura de tablas, relaciones)
- Los contratos de API (endpoints, formatos de request/response)
- El flujo de datos entre componentes
- El stack tecnológico (framework, motor de base de datos, cola de mensajes)
Pero típicamente no tiene:
- Acceso al código fuente completo
- Conocimiento de implementaciones específicas de algoritmos
- Comprensión línea por línea de la lógica de negocio
Piensa en un mecánico que conoce el diseño general de un motor (cilindros, inyección, escape) pero no ha leído los planos detallados de ingeniería. Puede diagnosticar problemas más efectivamente que alguien sin conocimiento mecánico, incluso sin la documentación completa.
Cuándo Aplica el Grey-Box Testing
El grey-box testing ocurre naturalmente en varios escenarios comunes:
Pruebas de Integración
Al probar cómo se comunican dos servicios, el tester frecuentemente conoce el contrato de API entre ellos, el formato de mensajes y quizás las tablas donde aterrizan los datos. Este conocimiento parcial ayuda a diseñar pruebas que verifican no solo “¿tuvo éxito la solicitud?” sino “¿llegaron los datos correctamente a la base de datos?”
Pruebas de API
Los testers de API típicamente conocen la estructura de endpoints, los payloads esperados, mecanismos de autenticación y posiblemente el esquema de base de datos. Prueban la API como caja negra (enviar request, verificar response) pero usan su conocimiento de la base de datos para verificar persistencia.
Pruebas de Seguridad
Los testers de seguridad frecuentemente conocen el stack tecnológico, el flujo de autenticación y patrones comunes de vulnerabilidad. Prueban desde afuera (como un atacante) pero usan conocimiento interno para enfocarse en los vectores de ataque más probables.
Pruebas de Migración
Al migrar de un sistema a otro, los testers conocen las estructuras de datos origen y destino. Usan este conocimiento para verificar reglas de transformación y completitud de datos.
Técnicas de Caja Gris
Testing de Matriz
Examina la documentación de arquitectura para identificar todas las interacciones entre componentes. Crea una matriz de conexiones y prueba cada una:
| Componente A | Componente B | Interfaz | Prioridad |
|---|---|---|---|
| Web App | Auth Service | REST API | Alta |
| Auth Service | User DB | SQL | Alta |
| Web App | Payment Gateway | REST API | Crítica |
| Order Service | Email Service | Cola de Mensajes | Media |
Testing de Patrones
Usa el conocimiento del stack tecnológico para probar patrones comunes de vulnerabilidad:
- Bases de datos SQL → Prueba SQL injection
- REST APIs → Prueba IDOR (Insecure Direct Object References)
- Colas de mensajes → Prueba orden y duplicación de mensajes
- Capas de cache → Prueba datos obsoletos
Testing Basado en Estado con Verificación de Base de Datos
Ejecuta una acción de caja negra (ej. enviar un formulario) y luego verifica el estado resultante en la base de datos:
- Verificar estado inicial de la base de datos
- Realizar la acción del usuario a través de UI o API
- Consultar la base de datos para verificar almacenamiento correcto
- Verificar que tablas relacionadas se actualizaron (foreign keys, logs de auditoría)
- Verificar que los caches se invalidaron
Ejemplos del Mundo Real
Ejemplo 1: Checkout de e-commerce. Un tester de caja gris sabe que el checkout involucra Order Service, Payment Service e Inventory Service. Prueba el flujo feliz a través de la UI (black-box) pero también verifica que el inventario disminuyó en la base de datos (grey-box).
Ejemplo 2: Registro con verificación de email. El tester sabe que el sistema envía emails vía SMTP y almacena un token de verificación en la base de datos. Registra un usuario (black-box), luego consulta la base de datos por el token (grey-box).
Ejemplo 3: Funcionalidad de búsqueda. El tester sabe que el sistema usa Elasticsearch. Usa este conocimiento para probar casos borde específicos: caracteres especiales, stemming, umbrales de fuzzy matching.
Grey-Box vs. Black-Box vs. White-Box
| Aspecto | Caja Negra | Caja Gris | Caja Blanca |
|---|---|---|---|
| Acceso al código | Ninguno | Ninguno o limitado | Completo |
| Conocimiento de arquitectura | Ninguno | Sí | Completo |
| Acceso a base de datos | Ninguno | Frecuentemente sí | Completo |
| Conocimiento de API | Solo endpoints | Contratos + flujo datos | Implementación completa |
| Quién lo realiza | QA, usuarios | QA, SDETs | Desarrolladores |
| Base del test | Requisitos | Requisitos + arquitectura | Código fuente |
| Mejor para | Funcional, UAT | Integración, API, seguridad | Pruebas unitarias |
Ventajas sobre Enfoques Puros
Sobre black-box:
- Puede verificar integridad de datos a nivel de base de datos
- Puede enfocar pruebas en puntos débiles arquitectónicos conocidos
- Puede verificar operaciones asíncronas revisando colas o bases de datos
- Reduce pruebas redundantes al entender los caminos internos de datos
Sobre white-box:
- No requiere habilidades profundas de programación
- Las pruebas mantienen cierta independencia de los detalles de implementación
- Simula más cercanamente la perspectiva de un atacante o usuario avanzado
- Menos mantenimiento de pruebas cuando el código interno cambia
Ejercicio: Identifica Oportunidades de Grey-Box Testing
Estás probando una aplicación web de delivery de comida. Te proporcionaron la siguiente documentación:
Arquitectura del Sistema:
- Frontend React comunicándose con un API Gateway REST
- Microservicios: Restaurant Service, Order Service, Delivery Service, Payment Service
- Bases de datos PostgreSQL:
restaurants_db,orders_db,users_db - Redis cache para menús y ubicaciones de repartidores
- RabbitMQ para actualizaciones de estado de pedidos
- Stripe API para pagos, Google Maps API para rutas
Esquema de Base de Datos (parcial):
-- orders_db
orders (id, user_id, restaurant_id, status, total_amount, created_at)
order_items (id, order_id, menu_item_id, quantity, price)
delivery_assignments (id, order_id, driver_id, status, pickup_time, delivery_time)
Parte 1: Clasifica cada escenario como black-box, grey-box o white-box testing:
- Un usuario hace un pedido y verifica la pantalla de confirmación
- Después de un pedido, consultar
orders_dbpara verificar los registros - Revisar el código fuente del Order Service para verificar el algoritmo de descuentos
- Hacer un pedido y verificar que RabbitMQ publicó el mensaje correcto
- Probar la búsqueda de restaurantes ingresando palabras clave
- Verificar que cuando un repartidor acepta, el cache Redis se actualiza
Parte 2: Diseña 5 escenarios grey-box para el flujo de pedidos.
Parte 3: El equipo notó discrepancias entre totales en pantalla y en base de datos. Describe tu enfoque de investigación.
Pista
Para la Parte 1, el diferenciador clave es qué conocimiento usa el tester. Si solo usa la UI, es black-box. Si usa conocimiento arquitectónico (base de datos, cola de mensajes, cache), es grey-box. Si lee código fuente, es white-box.Solución
Parte 1: Clasificación
- Black-box — Solo interactúa con la UI y verifica la salida visible.
- Grey-box — Acción de usuario + verificación en base de datos.
- White-box — Revisión directa del código fuente.
- Grey-box — Acción de usuario + verificación en cola de mensajes.
- Black-box — Solo usa la UI de búsqueda y evalúa resultados visibles.
- Grey-box — Acción del repartidor + verificación del estado del cache.
Parte 2: Escenarios Grey-Box
Escenario 1: Consistencia de precios
- Acción: Agregar 3 items al carrito y hacer pedido
- Verificación: Consultar
order_itemsy comparar precios conrestaurants_db - Detecta: Discrepancia por cache de menú obsoleto
Escenario 2: Pedidos concurrentes
- Acción: Dos usuarios piden simultáneamente el último item disponible
- Verificación: Revisar
orders_dbpara ambos pedidos - Detecta: Condición de carrera con inventario limitado
Escenario 3: Propagación de estado
- Acción: Hacer pedido, restaurante confirma
- Verificación: Revisar RabbitMQ y
delivery_assignments - Detecta: Falla en cola donde la UI confirma pero el delivery no fue notificado
Escenario 4: Atomicidad pago-pedido
- Acción: Hacer pedido (Stripe procesa el pago)
- Verificación: Si el cargo Stripe tuvo éxito, verificar que existe el registro en
orders_db - Detecta: Falla parcial donde se cobra pero no se crea el pedido
Escenario 5: Asignación de repartidor
- Acción: Hacer pedido en hora pico
- Verificación: Revisar
delivery_assignmentsy datos de ubicación en Redis - Detecta: Asignación con datos de ubicación obsoletos del cache
Parte 3: Enfoque de Investigación
- Reproducir y capturar el total en pantalla vs
orders.total_amount - Sumar
quantity × pricedeorder_itemsy comparar contotal_amount - Comparar precios en
order_itemscon precios actuales enrestaurants_db - Verificar cache Redis vs precios en base de datos
- Revisar la aplicación de descuentos/promociones
- Capturar el payload del API request y comparar con lo almacenado
Causas más probables: cache Redis obsoleto, condición de carrera entre actualización de precios y pedido, o cálculo inconsistente de descuentos entre frontend y backend.
Puntos Clave
- El grey-box testing usa conocimiento parcial del sistema para diseñar mejores pruebas que el puro black-box
- Es el enfoque natural para pruebas de integración, API y seguridad
- Los testers de caja gris verifican no solo comportamiento externo sino también integridad de datos interna
- Combina testing desde la perspectiva del usuario con verificación interna del sistema
- Técnicas comunes incluyen testing de matriz, de patrones y verificación de estado en base de datos
- Detecta bugs que el black-box no encuentra sin requerir acceso completo al código fuente