ESTRATEGIAS DE PRUEBA DE SOFTWARE

Transcripción

1 Características generales: La prueba comienza en el nivel de módulo y progresa hacia la integración del sistema. En diferentes puntos son adecuadas diferentes técnicas de prueba. La prueba la lleva a cabo el equipo de desarrollo y un equipo independiente de prueba. La prueba y la depuración son actividades diferentes, pero la depuración puede entrar en cualquier estrategia de prueba. Elicitación de Requisitos de Usuario Pruebas de Aceptación Usuarios comprueban que el sistema hace lo especificado en el contrato Análisis y Especificación de Requisitos Pruebas de Sistema Sistema: Cumplimiento de objetivos. Validación: desajustes entre el software y los requisitos Diseño Pruebas de Integración Agrupación de módulos. Interfaces. Especificación y lógica del módulo Pruebas de Unidad Lógica de módulos (Blanca). Funciones (Negra). Código 1

2 1. Prueba de unidad. Se concentran en la lógica del procesamiento interno y en las estructuras de datos dentro de los límites del módulo a probar. Este tipo de prueba se puede aplicar en paralelo a varios componentes. Qué se examina? 1) La interfaz: para asegurar que los datos fluyen correctamente hacia adentro y hacia afuera del módulo. 2) Estructuras de datos locales: para asegurar que los datos temporales mantienen la integridad durante la ejecución de un algoritmo. 3) Caminos independientes: para asegurar que se han probado al menos 1 vez. 4) Condiciones límite: para asegurar que opera apropiadamente en los límites establecidos para restringir el procesamiento. 5) Caminos de manejo de errores: para asegurar que en efecto hay control y diagnóstico de ciertos errores preestablecidos (p. ej: manejo de excepciones). Prueba de unidad. Errores comunes a descubrir: Precedencia aritmética incorrecta o mal interpretada. Operaciones de tipos mixtos. Inicializaciones incorrectas. Falta de precisión. Variables incorrectas. Terminación de bucles inapropiada o inexistente. Variables de bucle alteradas de forma incorrecta. 2

3 Prueba de unidad. Procedimientos: Para cada prueba de unidad debe desarrollarse software controlador, o bien software de resguardo o incluso de ambas categorías. Programa de prueba El controlador actúa a modo de programa principal que acepta los datos del caso de prueba, pasa estos datos al módulo e imprime los resultados importantes. Otros módulos Módulo en pruebas Otros módulos Reales o simulados (stubs) Un stub o resguardo, usa la interfaz del módulo que está suplantando para realizar: -Verificación de datos de entrada -Una mínima manipulación de datos. (p.e.: inicializaciones, mostrar los datos recibidos). Y, devuelve el control al módulo de prueba. 3

4 2. Prueba de integración. ESTRATEGIAS DE PRUEBA DE SOFTWARE El gran problema está al unir, es decir, cuando se crean las interfaces. En una interface es posible perder datos, es posible que un módulo tenga efectos indeseados sobre otro, es posible que estructuras de datos globales presentes problemas, es posible que etc. etc. etc. La prueba de integración es una técnica sistemática para construir la arquitectura del software mientras, al mismo tiempo, se aplican las pruebas para descubrir errores asociados con la interface. El objetivo: tomar componentes a los que se aplicó prueba de unidad y construir una estructura de programa de acuerdo con los diseños. El enfoque a tener en cuenta: integración incremental Es la antítesis al enfoque big-bang integrar todos los módulos cuando estén terminados y probarlos todos a la vez ( X- ) En el enfoque incremental se prueba de la misma forma en que se va construyendo, es decir, en pequeños incrementos, en los cuales resulta más fácil aislar y corregir los errores, y es más probable que se prueben por completo las interfaces y darle mayor orden a este proceso. Hay varias estrategias de integración incremental. 4

5 Prueba de integración Integración descendente. * Se usa el módulo de control principal como conductor de la prueba, disponiendo resguardos para todos los módulos subordinados al módulo de control principal. * Dependiendo de la aproximación de integración elegida (en profundidad o en anchura) se van sustituyendo los resguardos subordinados uno a uno por los módulos reales. * Se llevan a cabo pruebas cada vez que se integra un nuevo módulo. * Tras terminar cada conjunto de pruebas, se reemplaza otro resguardo con el módulo real. * Se hace la prueba de regresión (todas o alguna de las pruebas anteriores) para comprobar que no se han pasado por alto errores. 5

6 Prueba de integración Integración descendente. Otros módulos Reales, ya probados Otros módulos Módulo en pruebas Otros módulos simulados (stubs) 6

7 Prueba de integración Integración ascendente. * Se combinan los módulos de bajo nivel (atómicos) en grupos (construcciones) que realicen una subfunción específica del Software. * Se escribe un conductor para coordinar la entrada y la salida de los casos de prueba. * Se prueba el grupo. *Se eliminan los conductores y se combinan los grupos moviéndose hacia arriba por la estructura del programa. 7

8 Prueba de integración Integración ascendente. Programa de prueba Otros módulos Módulo en pruebas Otros módulos Otros módulos Reales, ya probados 8

9 EJERCICIO DE ESTRATEGIAS DE INTEGRACION Se ha realizado un software con la siguiente estructura jerárquica de módulos: Donde A es un módulo de control muy complejo, I y K son módulos de Entrada/Salida J contiene un algoritmo novedoso. Qué estrategia seguirías para realizar las pruebas de integración? Desarrolla los pasos que se darían en detalle (módulo a módulo). 9

10 EJERCICIO DE ESTRATEGIAS DE INTEGRACION 10

11 EJERCICIO DE ESTRATEGIAS DE INTEGRACION 11

12 EJERCICIO DE ESTRATEGIAS DE INTEGRACION 12

13 EJERCICIO DE ESTRATEGIAS DE INTEGRACION 13

14 EJERCICIO DE ESTRATEGIAS DE INTEGRACION 14

15 2-A. Prueba de regresión En el contexto de una estrategia de prueba de integración, la 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. El conjunto de pruebas de regresión (el subconjunto de pruebas a realizar) contiene tres clases diferentes de casos de prueba: Una muestra representativa de pruebas que ejercite las funciones del software en los escenarios más probables; Pruebas adicionales que se centran en las funciones del software que se van a ver probablemente afectadas por el cambio; Pruebas que se centran en los componentes del software que han cambiado. 15

16 3. Prueba de Validación (o de Aceptación) Se hace sobre el producto (vista de usuario) * Criterios de prueba de validación: Se satisfacen todos los requerimientos funcionales. Se alcanzan todos los requerimientos de rendimiento. La documentación es correcta y completa. ESTRATEGIAS DE PRUEBA DE SOFTWARE Se alcanzan requerimientos de compatibilidad, facilidad de mantenimiento, recuperación de errores, portabilidad, etc... La experiencia muestra que aún después del más cuidadoso proceso de pruebas por parte del desarrollador, quedan una serie de errores que sólo aparecen cuando el cliente usa el software. 16

17 Por estas razones, muchos desarrolladores ejercitan unas estrategias denominadas "pruebas alfa" y "pruebas beta". Las pruebas alfa consisten en invitar al cliente a que venga al entorno de desarrollo a probar el sistema. Se trabaja en un entorno controlado y el cliente siempre tiene un experto a mano para ayudarle a usar el sistema y para analizar los resultados. Las pruebas beta se desarrollan en el entorno del cliente, un entorno que está fuera de control. Aquí el cliente se queda a solas con el producto y trata de encontrarle fallos de los que informa al desarrollador. Las pruebas alfa y beta son habituales en productos que se van a vender a muchos clientes. Algunos de los potenciales compradores se prestan a estas pruebas bien por ir entrenando a su personal con tiempo, bien a cambio de alguna ventaja económica (mejor precio sobre el producto final, derecho a mantenimiento gratuito, a nuevas versiones, etc.). La experiencia muestra que estas prácticas son muy eficaces. 17

18 4. Prueba del Sistema Solidez (robustness testing) Se prueba la capacidad del sistema para salir de situaciones embarazosas provocadas por errores en el suministro de datos. Estas pruebas son importantes en sistemas con una interfaz al exterior, en particular cuando la interfaz es humana. TIPOS: Prueba negativa: Entradas inválidas. Prueba de valores límite: Límites de rangos; condiciones de frontera. 18

19 Aguante (stress testing) En ciertos sistemas es conveniente saber hasta dónde aguantan, bien por razones: internas ( hasta cuantos datos podrá procesar?), externas ( es capaz de trabajar con un disco al 90%?, aguanta una carga de la CPU del 90%?, etc) Prestaciones (performance testing) A veces es importante el tiempo de respuesta, u otros parámetros de gasto. Típicamente nos puede preocupar cuánto tiempo le lleva al sistema procesar cierto volumen de datos, o cuánta memoria consume, o cuánto espacio en disco utiliza, o cuántos datos transfiere por un canal de comunicaciones, etc. Para todos estos parámetros suele ser importante conocer cómo evolucionan al variar la dimensión del problema (por ejemplo, al duplicarse el volumen de datos de entrada). 19

20 D E P U R A C I Ó N No es una prueba pero suele ser consecuencia de esta. Características de los errores: El síntoma y la causa pueden estar muy alejados dentro del código. El síntoma puede desaparecer (temporalmente) al corregir otro error. Puede estar causado por algo que no es realmente un error. El síntoma puede se problema de tiempo en lugar de procesamiento. Puede ser difícil reproducir las condiciones de entrada de un error. El síntoma puede aparecer de forma intermitente FIN DEL DOCUMENTO 20