CAPÍTULO 18: ESTRATEGIAS DE PRUEBA DEL SOFTWARE

Una Estrategias 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. La estrategia proporciona un mapa que describe los pasos que hay que llevar a cobo como parte de la prueba, cuándo se deben de planificar y realizar esos pasos, y cuánto esfuerzo, tiempo y recursos se van a requerir.

Cualquier estrategia de prueba debe incorporar la planificación de la prueba, el diseño de casos de prueba, la ejecución de las pruebas y la agrupación y evaluación de los datos resultantes.

Se le llama prueba a un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente.

Plantilla para las pruebas del software: Es un conjunto de pasos en los que podamos situar los métodos específicos de diseño de casos de prueba.

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 requerimientos del cliente.

La ingeniería de sistemas define el papel del software, donde se establece el dominio de la información, la función el comportamiento, el rendimiento, las restricciones y los criterios de validación del software.

La estrategia para la prueba del software se puede ver en el contexto de espiral de la siguiente manera:

a) La prueba de unidad: Comienza en el vértice de la espiral y se centra en cada unidad del software, tal como está implementada en código fuente. Esta avanza, al movernos hacia fuera de la espiral, hasta llegar a la prueba de integración.
b) Prueba de integración: Aquí nos centramos en el diseño y la construcción de las arquitecturas del software.
c) Prueba de validación: Aquí se validan los requisitos establecidos como parte del análisis de requisitos del software, comparándolos con el sistema que ha sido construido.
d) Prueba del sistema: Aquí se prueba como un todo el software y otros elementos del sistema. Para probar el software de computadora nos movemos hacia fuera por una espiral que, a cada vuelta, aumenta el alcance de la prueba.

Pasos para definir una estrategia de prueba correcta

1) Especificar los requisitos del producto de manera cuantificable mucho antes de que comiencen las pruebas.
2) Establecer los objetivos de la prueba de manera explícita.
3) Comprender qué usuarios van a manejar el software y desarrollar un perfil para cada categoría de usuario.
4) Desarrollar un plan de prueba que haga hincapié en la prueba de ciclo rápido
5) Construir un software robusto diseñado para probarse así mismo
6) Usar revisiones técnicas formales efectivas como filtro antes de la prueba
7) Usar revisiones técnicas formales par evaluar la estrategia de prueba y los propios casos de prueba
8) Desarrollar un enfoque de mejora continua al proceso de prueba

PRUEBA DE UNIDAD

Esta prueba centra el proceso de verificación en la mejor unidad de diseño del software, que es el componente software o módulo.

Antes de esta prueba, la comprobación selectiva de los caminos de ejecución es una tarea esencial. Se deben diseñar casos de prueba para detectar errores, debido a cálculos incorrectos, comparaciones incorrectas o flujo de control inapropiados.

Las pruebas del camino básico y de bucles son técnicas muy efectivas para descubrir una gran cantidad de errores en los caminos.

Los errores más comunes que ocurren durante la prueba de unidad son:

1) Precedencia aritmética incorrecta o mal interpretada
2) Operaciones de modo mezcladas
3) Inicializaciones incorrectas
4) Falta de precisión
5) Incorrecta representación simbólica de una expresión

Se llama controlador a un programa principal que acepta los datos del caso de prueba, pasa estos datos al módulo e imprime los resultados importantes.

PRUEBA DE INTEGRACIÓN

Está prueba es una técnica sistemática para construir la estructura del programa, mientras que al mismos tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción.

El objetivo de esta prueba es tomar los módulos probados mediante la prueba de unidad y construir una estructura de programa que esté de acuerdo con lo que dicta el diseño.

Prueba de integración descendente.- Es un planteamiento incremental a la construcción de la estructura de programas. Se integran los módulos moviéndose hacia abajo por la jerarquía de control, comenzando por el módulo de control principal; después los módulos subordinados al módulo de control principal se van incorporando en la estructura, bien de forma primero-en-profundidad, o bien de forma primero-en-anchura.
Prueba de integración ascendente.- Empieza la construcción y la prueba con los módulos atómicos. Aquí los módulos se integran de abajo hacia arriba, el proceso requerido de los módulos subordinados siempre está disponible y se elimina la necesidad de resguardos.

Prueba de regresión.- Es volver a ejecutar un subconjunto de pruebas que se han llevado a cabo anteriormente para asegurarse de que los cambios no han propagado efectos colaterales no deseados.

Prueba de humo.- Es un método de prueba de integración que es comúnmente utilizada cuando se han desarrollado un producto software empaquetado.

PRUEBA DE VALIDACIÓN

La validación se consigue cuando el software funciona de acuerdo a las expectativas razonables del cliente. La validación permite descubrir errores, pero su enfoque esta en el nivel de requisitos, sobre cosas que son necesarias para el usuario final.

Criterios de la prueba de validación.

La validación se consigue mediante una serie de pruebas de caja negra que demuestran la conformidad con los requisitos. Un plan de prueba traza la clase de pruebas que se han de llevar a cabo, y un procedimiento de prueba define los casos de prueba específicos en un intento por descubrir errores de acuerdo con los requisitos. Tanto el plan como el procedimiento estarán diseñados para asegurar que se satisfacen todos los requisitos funcionales, que se alcanzan todos los requisitos de rendimiento, que la documentación es correcta e inteligible y que se alcanzaros otros requisitos como la portabilidad, la compatibilidad, recuperación de errores, facilidad de mantenimiento, etc.

Una vez procedido cada caso de prueba pueden darse una de dos condiciones

1. Las características de funcionamiento o rendimiento están de acuerdo a las especificaciones y son aceptables.
2. Se descubre una desviación de las especificaciones y se crea una lista de deficiencias.

Las desviaciones o errores encontrados en esta fase del proyecto raramente se pueden corregir de la terminación planificada.

REVISION DE LA CONFIGURACIÓN

Un elemento importante del proceso de validación es la revisión de la configuración o también conocida como auditoria consiste en asegurarse de que todos los elementos de la configuración de software se han desarrollado apropiadamente, se han catalogado y están suficientemente detallados para soportar la fase de mantenimiento durante el ciclo de vida del software.

PRUEBAS ALFA Y BETA

La prueba Alfa se lleva a cabo por un cliente en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario registrando los errores y los problemas de uso. Las pruebas alfa se llevan en un entorno controlado.

La prueba Beta se lleva a cabo por los usuarios finales en los lugares de trabajo de los clientes. A diferencia de la prueba alfa el desarrollador no esta presente normalmente. La prueba beta es aplicación en vivo del software en un entorno no controlado por el desarrollador. El cliente registra todos los problemas que encuentra durante la prueba beta, el desarrollador del software lleva a cabo modificaciones y así prepara una versión del producto de software para toda la clase de clientes.

PRUEBA DEL SISTEMA

La prueba del sistema esta constituida por una serie de pruebas diferentes cuyo propósito primordial es ejercitar profundamente el sistema basado en computadora. Aunque cada prueba tiene un propósito diferente, todas trabajan para verificar que se han integrado todos los elementos del sistema y que se realizan las funciones apropiadas.

PRUEBA DE RECUPERACION

Es una prueba del sistema que fuerza el fallo del software de muchas formas y verifica que la recuperación se lleva acabo apropiadamente. Si la prueba es automática (llevada a cabo por el propio sistema) hay que evaluar la corrección de la inicialización, de los mecanismos de recuperación de los estados del sistema, de la recuperación de datos y del procesos de rearranque. Si la recuperación requiere la intervención humana, hay que evaluar los tiempos medios de recuperación TMR para determinar si están dentro de los limites aceptables.

PRUEBAS DE SEGURIDAD

Intenta verificar que los mecanismos de protección incorporados al sistema lo protegerán de accesos impropios. Durante esta prueba el responsable de la misma desempeña el papel de un individuo que desea entrar en el sistema. Debe de intentar conseguir las claves por cualquier medio, puede atacar el sistema con software a medida, diseñado para romper con cualquier defensa que se haya construido, debe bloquear el sistema , negando el servicio a otras personas, debe producir a puposito errores del sistema, intentando acceder durante la recuperación o debe de curiosear entre los datos sin protección, tratando de encontrar la clave de acceso al sistema.

PRUEBA DE RESISTENCIA (STREES)


Ejecuta un sistema de forma que demande recursos, frecuencia o volúmenes anormales. Esencialmente el programa.

Una variante de esta prueba es la prueba de Sensibilidad, esta intenta descubrir combinaciones de datos dentro de una clase de entrada valida que pueda producir inestabilidad o un proceso incorrecto.

PRUEBA DE RENDIMIENTO

Esta diseñada para probar el rendimiento del software en tiempo de ejecución dentro del contexto de un sistema integrado

EL ARTE DE LA DEPURACIÓN

La depuración ocurre como consecuencia de una prueba efectiva , o sea que se ha descubierto un error, la depuración es el proceso que elimina el error.

EL PROCESO DE DEPURACIÓN

Este proceso siempre tiene uno de los dos resultados siguientes:

1. Se encuentra la causa, se corrige y elimina.
2. No se encuentra la causa.

Varias características de los errores nos dan una pista para detectarlos:

1. El síntoma y la causa pueden ser remotamente geográficos entre si.
2. El síntoma puede desaparecer temporalmente al corregir otro.
3. El síntoma puede realmente estar por algo que no es un error.
4. El síntoma puede estar causado por un error humano de no fácil detección.
5. El síntoma puede ser el resultado de problemas de temporizacion en vez de proceso.
6. Puede ser difícil reproducir exactamente lasa condiciones de entrada.
7. El síntoma puede aparecer de forma intermitente.
8. El síntoma puede ser debido a causas que distribuyen por una serie de tareas ejecutándose en diferentes procesadores.

CONSIDERACIONES PSICOLOGICAS

La depuración es uno de los procesos mas frustrantes de la programación. Contiene elementos de resolución de problemas o de rompecabezas, junto con el desagradable reconocimiento de que se ha cometido un error. La enorme ansiedad y la no inclinación a aceptar la posibilidad de cometer errores hace que la tarea sea extremadamente difícil. Afortunadamente también se da un gran alivio y disminuye la tensión cuando el error es finalmente corregido.

ENFOQUE DE DEPURACIÓN

El objetivo principal de la depuracion es encontrar y corregir el error en el software. El objetivo se consigue mediante una combinación de una evaluación sistemática, de intuición y de suerte.

Existen tres enfoques que se pueden proponer para la depuración:

1. Fuerza bruta.- Es la depuración mas común y menos eficiente a al hora de aislar la causa del error y se aplica cuando todo lo demás falla. Mediante una filosofía de dejar que la computadora encuentre el error se hacen volcados de memoria, trazas de ejecución y se cargan multitud de sentencias “mostrar” en el programa buscando así alguna pista que nos lleve al origen del error.

2. Vuelta atrás.- Es un enfoque mas normal para la depuración que se puede utilizar con éxito para pequeños programas. Partiendo del lugar donde se descubre el síntoma se recorre hacia atrás manualmente el código fuente hasta llagar a la posición del error.

3. Eliminación de Causas.- Se manifiesta mediante inducción o deducción e introduce el concepto de partición binaria. Los datos relacionados con la causa del error se organizan para aislar las posibles causas. Se llega una hipótesis de causa y se usan los datos anteriores para probar o revocar la hipótesis.

Se debe de hacerse tres preguntas antes de hacerse una corrección que elimine la causa del error.

1. ¿Se repite la causa del error en otra parte del programa?
2. ¿Cual es el siguiente error que se podrá presentar a raíz de la corrección que se va a realizar ?
3. ¿Qué podríamos haber hecho para corregir el error la primera vez?