// Ingeniería de Software

Pruebas de
Software

Planificación · Caja Negra · Caja Blanca · Datos de Prueba

01
Planificación y Documentación

La planificación de pruebas es el proceso de definir el alcance, los objetivos, los recursos y el calendario de las actividades de prueba. Un buen plan evita improvisaciones y garantiza cobertura suficiente del sistema.

La documentación recoge los casos de prueba, los resultados esperados, los entornos de prueba y los criterios de aceptación. Sirve como contrato entre desarrolladores, testers y clientes.

Los documentos clave incluyen el Plan de Pruebas, las Especificaciones de Caso y los Informes de Resultados.

1
Definir
alcance
2
Estimar
recursos
3
Diseñar
casos
4
Ejecutar
pruebas
5
Documentar
resultados
6
Revisión
y cierre
Plan de pruebas
Casos de prueba
Criterios de aceptación
Trazabilidad de requisitos
Entornos de prueba
Métricas de calidad
02
Pruebas de Caja Negra

En las pruebas de caja negra el tester no conoce la implementación interna del sistema. Solo interactúa con la interfaz pública: entradas y salidas. El objetivo es verificar que el sistema se comporta según las especificaciones funcionales.

Son ejecutadas normalmente por testers o usuarios finales. Permiten detectar funcionalidades incorrectas, errores de interfaz, comportamiento inesperado ante entradas inválidas y problemas de rendimiento.

▼ Ventajas

No requiere conocimiento del código. Simula el uso real del usuario. Aplicable a cualquier nivel (unitario, integración, sistema). Detecta discrepancias respecto a los requisitos.

▲ Limitaciones

Cobertura interna limitada. Difícil diseñar casos sin ambigüedad. No detecta código inactivo ni lógica oculta. Dependiente de la calidad de las especificaciones.

Partición de equivalencia
Valores límite
Tablas de decisión
Pruebas de transición de estado
Casos de uso
03
Pruebas de Caja Blanca

Las pruebas de caja blanca, también llamadas pruebas estructurales o de caja transparente, tienen acceso total al código fuente. El tester diseña casos de prueba basándose en la lógica interna, las rutas de ejecución y las estructuras de datos.

El objetivo es garantizar que todas las instrucciones, ramas y caminos posibles del código se ejercitan al menos una vez, maximizando la cobertura del código.

▼ Técnicas principales

Cobertura de sentencias. Cobertura de ramas (branch coverage). Cobertura de caminos (path coverage). Pruebas de bucles. Análisis de flujo de datos.

▲ Limitaciones

Requiere conocimiento profundo del código. No detecta funcionalidades no implementadas. Costoso en sistemas grandes. Cobertura del 100% de caminos es en general inviable.

Cobertura de código
Pruebas de ramas
Grafos de flujo
Complejidad ciclomática
Mutación de código
Pruebas unitarias
04
Utilización de Datos de Prueba

Los datos de prueba son las entradas que se suministran al sistema durante la ejecución de los casos de prueba. Una buena selección de datos es fundamental para obtener una cobertura representativa y detectar defectos.

Pueden generarse manualmente, extraerse de sistemas reales (con anonimización) o crearse mediante herramientas de generación automática. Deben cubrir datos válidos, inválidos, límite y casos extremos.

Tipo de dato Descripción Ejemplo Resultado esperado
Válido Entrada dentro del rango correcto edad = 25 PASS
Límite inferior Valor mínimo permitido edad = 18 PASS
Límite superior Valor máximo permitido edad = 99 PASS
Fuera de rango Valor que supera el máximo edad = 150 ERROR
Tipo inválido Tipo de dato incorrecto edad = "abc" ERROR
Nulo / vacío Campo obligatorio sin valor edad = null WARN
Datos válidos
Datos inválidos
Valores límite
Datos nulos
Generación automática
Anonimización
Datos de producción