Técnicas de diseño de casos de prueba: caja blanca, caja negra e integración

Técnicas de diseño de casos de prueba

Un caso de prueba es un conjunto de entradas, condiciones de ejecución y resultados esperados, desarrollado para conseguir un objetivo particular o condición de prueba. Para llevarlo a cabo, es necesario definir las precondiciones y post condiciones, identificar unos valores de entrada y conocer el comportamiento que debería tener el sistema ante dichos valores. Tras realizar ese análisis, se observa si su comportamiento es el previsto o no y por qué;Para llevar a cabo el diseño de casos de prueba se utilizan dos técnicas.

Prueba de caja blanca:

Se centran en validar la estructura interna del programa.

Prueba de caja negra

Se centran en validar los requisitos funcionales sin fijarse en el funcionamiento interno del programa. 

Caja blanca

.Se basan en el minucioso examen de los detalles procedimentales del código de la aplicación. Se pueden obtener casos de pruebas que:Garanticen que se ejecutan al menos una vez todos los caminos independientes de cada módulo;Ejecuten todas las sentencias al menos una vez;Ejecuten todas las decisiones lógicas en su parte verdadera y en su parte física;Ejecuten todos los bucles en sus límites;Utilicen todas las estructuras de datos internas para asegurar su validez.;Una de las técnicas utilizadas para desarrollar los casos de prueba de caja blanca es la prueba de camino.

Caja negra

Se llevan a cabo sobre la interfaz del software, no hace falta conocer la estructura interna del programa ni su funcionamiento. El sistema se considera como una caja negra cuyo comportamiento solo se puede determinar estudiando las entradas y las salidas que devuelve en función de las entradas suministradas;Funcionalidades incorrectas o ausentes;Errores de interfaz;Errores en estructuras de datos o en accesos a base de datos externas;Errores de rendimiento;Errores de inicialización y finalización.

Estrategias de pruebas del software

En el vértice de la espiral comienza la prueba de unidad. Se centra en la unidad más pequeña de software, el módulo tal como está implementando en código fuente;La prueba avanza para llegar a la prueba de integración. Se toman los módulos probados mediante la prueba de unidad;La espiral avanza llegando a la prueba de validación.
Prueba del software en el entorno real de trabajo con intervención del usuario final;Finalmente se llega a la prueba del sistema.
Verifica que cada elemento encaja de forma adecuada y se alcanza la funcionabilidad y rendimiento total.

Prueba de unidad

Se prueba cada unidad o módulo con el objetivo de eliminar errores en la interfaz y en la lógica interna. Utiliza técnicas de caja negra y caja blanca, según convenga para lo que desea probar;La interfaz del módulo;Las estructuras de datos locales;Las condiciones límite;Todos los caminos independientes de la estructura de control;Todos los caminos de manejo de errores.

Prueba de integración

Existen dos enfoques fundamentales para llevar a cabo las pruebas

:Integración no incremental o big bang

Se prueba cada módulo por separado y luego se combinan todos de una vez y se prueba todo el programa completo.

Integración incremental:

El programa se va construyendo y probando en pequeños segmentos, en este caso los errores son más fáciles de localizar. En la integración Ascendente la construcción y prueba del programa empieza desde los módulos de los niveles más bajos de la estructura del programa. En la Descendente la integración comienza en el módulo principal.

Prueba del sistema

La prueba del sistema está formada por un conjunto de pruebas cuya misión es ejecutar profundamente el software.

Prueba de recuperación

Se fuerza el fallo del software y se verifica que la recuperación se lleva a cabo apropiadamente.

Prueba de seguridad

Esta prueba intenta verificar que el sistema está protegido contra accesos ilegales.

Prueba de resistencia

Trata de enfrentar el sistema con situaciones que demandan gran cantidad de recursos

.Documentación para las pruebas

Plan de pruebas

Describe el alcance, el enfoque, los recursos y el calendario de las actividades de prueba

.Especificaciones de prueba

Están cubiertas por tres tipos de documentos;La especificación del diseño de la prueba;La especificación de los casos de prueba;La especificación de los procedimientos de prueba;Informes de pruebas. Se definen cuatro tipos de documentos:Un informe que identifica los elementos que están siendo probados;Un registro de las pruebas;Un informe de incidentes de prueba;Un informe resumen de las actividades de prueba.

Pruebas de Código

Las pruebas del código consisten en la ejecución del programa, con el objetivo de encontrar errores. Para las pruebas de código se van a mostrar diferentes técnicas que dependerán el tipo de enfoque utilizado: de caja blanca, se centran en la estructura interna del programa; o de caja negra, más centrado en las funciones, entradas y salidas del programa.

Prueba del camino básico

La prueba del camino básico en una técnica de prueba de caja blanca que permite al diseñador de casos de prueba obtener una medida de complejidad lógica de un diseño procedimental y usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución.Para la obtención de la medida de la complejidad lógica, emplearemos una representación del flujo de control denominada grado de flujo o grado del programa.