Estratégias De Prueba Del Software

CAPITULO 18 – ESTRATEGIAS DE PRUEBA DEL SOFTWARE

Una estrategia de prueba del software integra las técnicas de diseño de casos de prueba en una serie de pasos bien planificados que dan como resultado una correcta construcción del software.

18.1 Un enfoque estratégico para las pruebas del software

Las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente. Se debe definir en el proceso de ingeniería del software una plantilla para las pruebas del software: un conjunto de pasos en los que podamos situar los métodos específicos de diseño de casos de prueba:

Plantilla para la prueba:

Las pruebas comienzan a nivel de módulo y trabajan “hacia fuera”, hacia la integración de todo el sistema basado en computadora.

Según el momento, son apropiadas diferentes técnicas de prueba.

La prueba la lleva a cabo el responsable del desarrollo del software y un grupo independiente de pruebas.

La prueba y la depuración son actividades diferentes, pero la depuración se debe incluir en cualquier estrategia de prueba.

18.1.1 Verificación y validación (V&V)

Verificación: se refiere al conjunto de actividades que aseguran que el software implementa correctamente una función específica.

Validación: se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos del cliente. La verificación y la validación abarcan una amplia lista de actividades de SQA(garantía de calidad del software) que incluyen:

1.-Revisiones técnicas formales.

2.-Auditorias de calidad y de configuración.

3.-Monitorización de rendimientos.

4.-Simulación.

5.-Estudios de factibilidad.

6.-Revisión de la documentación.

7.-Revisión de la base de datos.

8.-Análisis de algoritmos.

9.-Pruebas de desarrollo.

10.-Pruebas de validación.

11.-Pruebas de instalación.

La calidad se incorpora en el software durante el proceso de ingeniería del software. La calidad se confirma durante las pruebas.

18.1.2 Organización para las pruebas del software

Desde un punto de vista psicológico, el análisis y el diseño del software son tareas constructivas.

Cuando comienza la prueba, aparece una sutil, aunque firma intención de “romper” lo que el ingeniero a construido.

El responsable del desarrollo del software siempre es responsable de probar las unidades individuales (módulos) del programa, asegurándose de que cada una lleve a cabo la función para la que fue diseñada. Solo una vez que la arquitectura del software esté completa entra en juego un grupo independiente de prueba.

Grupo independiente de prueba (GIP): Un grupo de prueba independiente elimina el conflicto de intereses.

18.1.3 Una estrategia de prueba del software

El proceso de ingeniería del software se puede ver como una espiral. Inicialmente,la ingeniería de sistemas define el papel del software y conduce al análisis de los requisitos del software, donde se establece el dominio de información, la función, el comportamiento, el rendimiento, las restricciones y los criterios de validación del software.

También se puede ver la estrategia para la prueba del software en el contexto de la espiral:

La prueba de unidad, comienza en el vértice de la espiral y se centra encada unidad del software, tal como está implementada en código fuente.

La prueba de integración, donde el foco de atención es el diseño y la construcción de la arquitectura del software.

La prueba de validación, donde se validan los requisitos del software,comparándolos con el sistema que ha sido construido. El software satisface todos los requisitos funcionales, de comportamiento y de rendimiento.

La prueba del sistema, en la que se prueban como un todo el software y otros elementos. Cada elemento encaja de forma adecuada y que se alcanza la funcionalidad y el rendimiento del sistema total.

18.1.4 Criterios para completar la prueba

“La prueba nunca termina, ya que el responsable del desarrollo del software carga o pasa el problema al cliente”

“Se termina la prueba cuando se agota el tiempo o el dinero disponible a tal efecto”.

Mediante el modelado estadístico y la teoría de fiabilidad del software, se pueden desarrollar modelos de fallos del software. Modelo logarítmico de Poisson de tiempo de ejecución:F(t) = (1/p) * ln[(l0pt+1)].

F(t)es número acumulado de fallos que se espera.

l0es la intensidad de fallos inicial del software al principio de la prueba.

p es la reducción exponencial de intensidad de fallo a medida que se encuentran los errores y se van haciendo las correcciones.

18.2 Aspectos estratégicos

Implementar con éxito una estrategia de prueba del software:

Establecer los requisitos del producto de manera cuantificable mucho antes de que comienzen las pruebas.

Establecer los objetivos de la prueba de manera explicita.

Comprender que usuarios van a manejar el software y desarrollar un perfil para cada categoría de usuario.

Desarrollar un plan de prueba que haga hincapié en la “prueba de ciclo rápido”.

Construir un software “robusto” diseñado para probarse a si mismo.

Usar revisiones técnicas formales efectivas como filtro antes de la prueba.

Llevar a cabo revisiones técnicas formales para evaluar la estrategia de prueba y los propios casos de prueba.

Desarrollar un enfoque de mejora continua al proceso de prueba. Debería medirse la estrategia de prueba.

18.3 Prueba de unidad

La prueba de unidad centra el proceso de verificación en la menor unidad del diseño del software: el componente software o módulo.

18.3.1 Consideraciones sobre la prueba de unidad.

1. Se prueba la interfaz del módulo.

2. Se examinan las estructuras de datos locales.

3. Se prueban las condiciones límite.

4. Se ejercitan todos los caminos independientes.

5. Se prueban todos los caminos de manejo de errores.

Antes de iniciar cualquier otra prueba es preciso probar el flujo de datos de la interfaz del módulo.

Se deben diseñar casos de prueba para detectar errores debidos a cálculos incorrectos comparaciones incorrectas o flujos de control inapropiados.

La prueba de límites es la última tarea del paso de la prueba de unidad.

18.3.2 Procedimientos de Prueba de unidad

Un controlador no es más que un “programa principal” que acepta los datos del caso de prueba, pasa estos datos al

...