CAPITULO 17: “ESTRATEGIAS DE PRUEBA DE SOFTWARE”

...

Una estrategia de integración ascendente puede implementarse con los siguientes pasos:

- Los componentes en el nivel inferior se combinan en grupos, que realizan una subfunción de software específica.

- Se escribe un controlador (un programa de control para pruebas) a fin de coordinar la entrada y salida de casos de prueba.

- Se prueba el grupo.

- Los controladores se remueven y los grupos se combinan moviéndolos hacia arriba en la estructura del programa.

Prueba de regresión

Cada vez que se agrega un nuevo módulo como parte de las pruebas de integración, el software cambia.

Es la nueva ejecución de algún subconjunto de pruebas que ya se realizaron a fin de asegurar que los cambios no propagaron efectos colaterales no deseados. Las pruebas de regresión se pueden realizar manualmente, al volver a ejecutar un subconjunto de todos los casos de prueba o usando herramientas de captura/reproducción automatizadas.

Prueba de humo

Se usa cuando se desarrolla software de producto. Se diseña como un mecanismo de ritmo para proyectos críticos en el tiempo.

Actividades que abarca:

- Los componentes de software traducidos en código se integran en una construcción.

- Se diseña una serie de pruebas para exponer los errores que evitarán a la construcción

realizar adecuadamente su función.

- La construcción se integra con otras construcciones, y todo el producto, se somete a prueba de humo diariamente.

La prueba de humo proporciona algunos beneficios cuando se aplica sobre proyectos de

software complejos y cruciales en el tiempo:

- Se minimiza el riesgo de integración.

- La calidad del producto final mejora.

- El diagnóstico y la corrección de errores se simplifican.

- El progreso es más fácil de valorar.

Opciones estratégicas

La selección de una estrategia de integración depende de las características del software y, en ocasiones, del calendario del proyecto.

Un enfoque combinado (a veces llamado prueba sándwich), que usa pruebas descendentes para niveles superiores de la estructura del programa acopladas con pruebas ascendentes para niveles subordinados, puede ser el mejor arreglo. Conforme se realiza la integración, quien efectúa la prueba debe identificar los módulos críticos.

Un módulo crítico tiene una o más de las siguientes características:

1) aborda muchos requerimientos de software,

2) tiene un alto nivel de control (reside relativamente alto en la estructura del programa),

3) es complejo o proclive al error o

4) tiene requerimientos de rendimiento definidos.

Producto de trabajo de las pruebas de integración

Un plan global para interagracion del sw y una descripción de las pruebas específicas se documentan en una especificación de pruebas.

Los siguientes criterios y pruebas correspondientes se aplican a todas las fases de prueba:

- Integridad de interfaz. Las interfaces internas y externas se prueban conforme cada módulo (o grupo) se incorpora en la estructura.

- Validez funcional. Se realizan pruebas diseñadas para descubrir errores funcionales ocultos.

- Contenido de la información. Se realizan pruebas diseñadas para descubrir errores ocultos asociados con las estructuras de datos locales o globales.

- Rendimiento. Se realizan pruebas diseñadas para verificar los límites del rendimiento establecidos durante el diseño del software.

Estrategias de prueba para software orientado a objetos

El objetivo de probar es encontrar el mayor número posible de errores con una cantidad manejable de esfuerzo aplicado durante un lapso realista.

Prueba de prueba para software orientado a objetos

Existen dos estrategias diferentes para la prueba de integración de los sistemas OO.

- La prueba basada en hebra: integra el conjunto de clases requeridas para responder a una entrada o evento para el sistema. Cada hebra se integra y prueba de manera individual. La prueba de regresión se aplica para asegurar que no ocurran efectos colaterales.

- La prueba basada en uso: comienza la construcción del sistema al probar dichas clases (llamadas clases independientes) que usan muy pocas clases servidor

Después de probar las clases independientes, se prueba la siguiente capa de clases, llamadas dependientes, que usan las clases independientes.

Estrategia de prueba para webapps

La estrategia para probar webapps adopta los principios básicos para todas las pruebas de software y aplica una estrategia y tácticas que se usan para sistemas orientados a objetos.

Los siguientes pasos resumen el enfoque:

1. El modelo de contenido para la webapp se revisa para descubrir errores.

2. El modelo de interfaz se revisa para garantizar que todos los casos de uso pueden adecuarse.

3. El modelo de diseño para la webapp se revisa para descubrir errores de navegación.

4. La interfaz de usuario se prueba para descubrir errores en los mecanismos de presentación y/o navegación.

5. A cada componente funcional se le aplica una prueba de unidad.

6. Se prueba la navegación