Please enable JavaScript.
Coggle requires JavaScript to display documents.
2.4. Pruebas de unidad: enfoque de caja blanca - Coggle Diagram
2.4. Pruebas de unidad: enfoque de caja blanca
Que és?
Tipo de prueba donde se accede al código fuente para diseñar los casos.
Evaluamos rutas de ejecución, estructuras condicionales y bifuracaciones
¿Cuales son sus objetivos?
Verificar flujos lógicos
Asegurar que se ejecutan todas las partes del codigo
¿Qué NO cubre
Funcionalidad o comportamiento
Criterios de cobertura
Statement coverage
Ejecutar todas las instrucciones del código al menos una vez. (Habitualmente poco usado por ser MUY pobre)
Branch coverage
Ejecutar cada rama de decisión (true/false) al menos una vez.
Condition coverage
Probar cada condición booleana en ambas salidas, todas True y todas False. No satisface necesariamente la cobertura de decisiones.
Multiple condition coverage
Escribir mínimo número de casos de prueba que permitan evaluar todas las combinaciones de salidas de condiciones en cada decisión
Path coverage
Ejecutar todos los caminos posibles del flujo de control.
Complejidad ciclomática
CC = E - N + 2
E = aristas
N = nodos
Function coverage
Invocar cada función al menos una vez.
Diseño de casos de prueba
Extraer las decisiones del código fuente
if
while
for
Elegir el criterio de cobertura
Decisiones
Condiciones
Condición múltiple
Diseñar el mínimo conjunto de casos
Tabla D: para análisis de decisiones.
Tabla C: para análisis de condiciones/condición múltiple.
Tabla Casos: entrada, salida esperada, y escenarios cubiertos por cada prueba.
Ámbito de uso
Especialmente útiles en pruebas de unidad.
No tan prácticas para pruebas de integración o de sistema debido a su complejidad
ideales para métodos o funciones con mucha lógica interna, donde los errores pueden estar en la estructura de control
Ventajas
Detección profunda de errores.
Optimización de la lógica del código.
Análisis de calidad estructural (complejidad, legibilidad).
Pruebas exhaustivas y meticulosas.
Desventajas
Costosas en tiempo y esfuerzo.
Requieren conocimiento técnico del código.
Son frágiles: cambian si cambia el código o su especificación.
Doble dependencia: del código fuente y del comportamiento esperado.
Relación coste-beneficio
Es un proceso riguroso, intensivo y cososo
Core banking systems.
Defensa y seguridad.
Aviación.
Recomendaciones finales
El criterio de condición múltiple es el más exhaustivo.
Si es viable, debe ser la primera opción.
Ningún criterio es suficiente por sí solo.
Se recomienda complementar con técnicas de caja negra
Añadir nuevos casos de caja negra sin modificar los ya definidos por caja blanca