La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

10.- Flujo de Pruebas Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA.

Presentaciones similares


Presentación del tema: "10.- Flujo de Pruebas Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA."— Transcripción de la presentación:

1 10.- Flujo de Pruebas Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA

2 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Contenidos Introducción Error Pasos Verificación & Validación Métodos de pruebas Tipos de pruebas Actividades de pruebas

3 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Introducción Se verifica el resultado de la implementación probando cada build -internos e intermedios- y la release. Objetivos: Planear las pruebas requeridas en cada iteración, incluyendo pruebas de integración y de sistema. Integración: para cada build, estilo caja blanca. Sistema: al final de cada iteración. Comportamiento observable externamente. Diseñar e implementar las pruebas, creando casos de prueba, procedimientos de prueba (cómo hacerlos) y creando componentes de prueba ejecutables para automatizar las pruebas. Realizar las pruebas y manejar sistemáticamente los resultados de las mismas.

4 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Error Un error software existe cuando el software no hace lo que el usuario espera que haga, acordado previamente en la especificación de requisitos.

5 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Pasos Los ing. de pruebas realizan el plan de pruebas para cada iteración (esfuerzo de pruebas a realizar). Describen los casos de prueba y los procedimientos de prueba a realizar. Si procede, los ing. de componentes crean los componentes de prueba para automatizar las pruebas. Los probadores de sistema e integración prueban cada build y anotan los defectos encontrados. Los resultados se pasan a los ing.de pruebas para que evalúen los resultados de las pruebas y a otros flujos como diseño e implementación para subsanar los defectos.

6 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Verificación & Validación Verificación: ¿Se ha construido el sistema correctamente? Validación: ¿se ha construido el sistema correcto?

7 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Métodos de pruebas (I): caja blanca Comportamiento interno y estructura del programa. Se ejecutan todas las sentencias al menos una vez Se navega por todos los caminos independientes Realista: es imposible. Técnicas: Prueba de interfaz Análisis del flujo de datos a través de las interfaces. Prueba de estructuras de datos locales Prueba del camino básico Definición de un conjunto básico de caminos de ejecución usando una medida calculada previamente de la complejidad lógica del módulo (complejidad ciclomática). Prueba de condiciones límite Validar la construcción de los bucles.

8 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Métodos de pruebas (y II): caja negra Considera el SW como una caja negra sin tener en cuenta los detalles. Los datos de entrada han de generar una salida en concordancia con las especificaciones. Técnicas: Partición de equivalencia División de la entrada de un programa en clases de datos de las que se pueden derivar casos de prueba para reducirlos. Análisis de valores límite Probar los límites de cada clase de equivalencia.

9 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Tipos de pruebas (I): unitarias Prueba de cada módulo o clase del programa de manera que cumpla unitariamente el caso de uso que implementa. Realizada por el ingeniero de desarrollo del caso de uso. Ventajas: Error más localizado. Se pueden probar varios módulos simultaneamente. Método empleado: caja blanca. En algunos casos se pueden crear módulos sencillos de prueba para probar módulos con alta cohesión.

10 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Tipos de pruebas (II): de integración Integración de módulos en subsistemas. Método: caja negra -blanca a veces-. Tipos: No incremental (BIG BANG): todo a la vez :( Incremental.

11 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Tipos de pruebas (III): de validación Comprobación de que se cumplen todos los requisitos. Dos partes: Validación por parte del usuario. Utilidad, facilidad de uso y ergonomía de la GUI. Tipos: Pruebas Alfa: realizadas por los desarrolladores en el entorno de usuario. Pruebas Beta: realizadas por el usuario.

12 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Tipos de pruebas (IV): de sistemas Se prueba el sistema integrado en su entorno (HW & SW). Consta de pruebas de: interfaces externas volumen funcionamiento recuperación seguridad resistencia rendimiento/comportamiento fiabilidad documentación

13 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Tipos de pruebas (y V): de aceptación Último paso antes de la entrega formal del SW al cliente. Se realiza normalmente en el entorno del usuario.

14 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Actividades de Pruebas Planear las pruebas. Diseñar pruebas. Implementar pruebas. Realizar pruebas de integración. Evaluar pruebas.

15 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Actividad: Planear las pruebas Objetivos: Describir una estrategia de pruebas (p.e. cuantos casos de prueba serán automatizados, con qué técnicas, etc.) Estimar los recursos precisos. Planificar el esfuerzo. Las entradas son los casos de uso, el modelo de diseño, etc.

16 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Actividad: Diseñar pruebas (I) Objetivos: Identificar y describir los casos de prueba para cada build. Identificar y estructurar los procedimientos de prueba especificando como realizar los casos de prueba. Pruebas de integración: Chequear que las interacciones reales entre objetos son las especificadas en las realizaciones de los casos de uso. Pruebas de sistemas: Probar casos de uso bajo diferentes condiciones (de hardware, de carga, de número de actores, con diferentes tamaños de base de datos) y combinaciones.

17 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Actividad: Diseñar pruebas (y II) Pruebas de regresión: Algunos casos de prueba de previas builds podrán usarse en la actual para asegurar que las cosas que funcionaban en la build anterior lo siguen haciendo. A veces los casos de prueba no podrán ser reutilizados directamente. A la hora de diseñar procedimientos de prueba, deben tratar de reutilizarse lo más posible (por ejemplo especificando un único procedimiento para partes comunes de varios casos de uso).

18 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Actividad: Implementar pruebas Crear componentes de prueba que puedan automatizar los procesos de prueba (p.e generadores de carga).

19 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Actividad: Realizar pruebas de integración Si existe algún fallo en la batería de pruebas realizada, es necesario notificarlo a los ingenieros de componentes cuyos componentes no están funcionando, y a los ingenieros de pruebas para que puedan evaluar el resultado global de las pruebas.

20 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Actividad: Evaluar pruebas El objetivo es evaluar el esfuerzo de pruebas durante la iteración. Básicamente se usan dos métricas: Completitud de las pruebas: % de los casos de prueba que se han ejecutado y % del código que se ha probado. Fiabilidad: se basa en analizar los defectos descubiertos y las tendencias que puedan extraerse de ellos (p.e una parte que falla demasiadas veces, o una tendencia general a que se produzcan situaciones anómalas bajo ciertas situaciones de carga).

21 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Ejemplo

22 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Bibliografía Software Development on Internet Time. M. A. Cusumano, D. B. Yoffie. IEEE Computer, Oct Evaluating the Effectiveness of Independent Verification and Validation. J. D. Arthur, M. K. Gröner, K. J. Hayhurst, C. M. Holloway. IEEE Computer, Oct When to test less. T. Menzies, B. Cukic., IEEE Software, Sept-Oct Improvisation in small software organizations. T. Dyba. IEEE Software, Sept- Oct Knowledge-based software architectures: acquisition, specification and verification. J.J.P.Tsai, A.Liu, E.Juan, A. Sahay. IEEE Transactions on Knowledge and Data Engineering. Jan-Feb The Role of Independent Verification and Validation in Maintaining a Safety Critical Evolutionary Software in a Complex Environment: The NASA Space Shuttle Program. M. V. Zelkowitz, I. Rus. IEEE International Conference on Software Maintenance (ICSM 01). Software Verification and Validation. An overview. D. R. Wallace, R. U. Fujii. IEEE Software, May 1989.


Descargar ppt "10.- Flujo de Pruebas Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA."

Presentaciones similares


Anuncios Google