Pruebas de Software. Agenda. Pruebas de Programas Los Niveles de Prueba Diseño de Casos de Prueba

Transcripción

1 Pruebas de Software R. Casallas Dpto. de Ingeniería de Sistemas y Computación Universidad de los Andes 1 Agenda Pruebas de Programas Los Niveles de Prueba Diseño de Casos de Prueba 2 1

2 Pruebas de Programas Pruebas de programas es el proceso de ejecutar programas con el propósito de encontrar errores Se puede mostrar la presencia de un error pero no la ausencia [Dijkstra] Debería ser visto como el último recurso para encontrar errores 3 Proceso de Pruebas de Programas Preparar Casos de Prueba Congelar versión del Sw para Pruebas Ejecutar Casos de Prueba Errors Detectados? NO Version Acceptada SI Hacer Pruebas Totales o parciales de Regresión Seleccionar y Priorizar los errores para corrección Verificar Correcciones Congelar versión corregida del Sw Corregir 4 2

3 Proceso de Pruebas de Programas: Depuración Diagnosticar Error Planificar Cambios Actualizar Requerimientos? Seleccionar casos de prueba para probar los cambios Selecionar casos de Prueba para Pruebas de Regresión Actualizar Diseño Arquitec. Actualizar Diseño Detallado Actualizar código Probar los Cambios Pruebas de Regresión 5 Ciclo en V Definición de Requerimientos Análisis Requirementos Preparación Pruebas Aceptación Diseño Arquitectura Preparación Pruebas Sistema Diseño Detallado Preparación Integración Programación Preparacion Pruebas Unit. Pruebas Unitarias Pruebas Integración Pruebas SIstema Pruebas Aceptación 6 3

4 Técnicas de Prueba Caja blanca o pruebas estructurales El conocimiento del diseño interno del software se usa para desarrollar los casos de pruebas Caja negra o pruebas funcionales Los casos de prueba son diseñados basados sólo en la especificación externa del software Pruebas basadas en escenarios o casos de uso Actuar como un usuario final y crear escenarios reales para detectar errores 7 Técnicas de Prueba (2) Pruebas Selectivas Generar más casos de prueba para las funciones o componentes que son más usados Probar más rigurosamente las funciones o componentes más críticos Generar mas casos de prueba para las funciones o componentes más complejos 8 4

5 Agenda Introducción Inpecciones Pruebas de Programas Metodología de Pruebas Los Niveles de Prueba Diseño de Casos de Prueba 9 Pruebas Unitarias (1) Descripción Su propósito es encontrar errores en la lógica, datos o algoritmos en componentes o subsistemas individuales Realizado por los desarrolladores del componente Técnica de prueba: Caja blanca 10 5

6 Pruebas Unitarias (2) Guías para generar casos de prueba Tratar de detectar errores en los algoritmos y la lógica Tratar de detectar errores en la manipulación de las estructuras de datos Tratar de detectar errores en el llamado a otros módulos Identificar todos los caminos posibles del módulo y tratar de hacer casos de prueba que los cubran Tratar de detectar errores usando datos límites 11 Pruebas de Integración Descripción Su propósito es encontrar errores en las interfaces entre los módulos Realizado por los desarrolladores de los módulos que serán integrados Técnica de Prueba: Caja negra basado en las especificaciones de las interfaces 12 6

7 Pruebas de Integración (2) Guías para generar casos de prueba Tratar de detectar errores en los formatos de intercambio de datos Tratar de detectar errores en en el orden en que interactúan los módulos, la sincronización y los tiempos de respuesta 13 Pruebas de Sistema Descripción Su propósito es encontrar errores en el comportamiento del sistema de acuerdo con la especificación de requerimientos Realizado por un grupo diferente al de desarrollo Técnica de Prueba: Caja negra basado en los requerimientos y en escenarios reales 14 7

8 Pruebas de Sistema (2) Guías para generar casos de prueba Verificar que la funcionalidad del sistema es correcta y completa Verificar que el sistema tiene la capacidad volumétrica, de robustez y que se comporta bien ante fallas 15 Pruebas de Aceptación Descripción Su propósito es verificar que el sistema satisface los requerimientos del cliente (en el sitio del cliente) Realizado por un grupo de usuarios finales Técnicas de Prueba: Caja negra basado en los requerimientos y en escenarios reales Guías para generar casos de prueba Similar a pruebas del sistema 16 8

9 Pruebas de Regresión Descripción Su propósito es verificar que, después de un cambio, las partes no cambiadas del sistema se siguen comportanto igual (no hay efectos de borde) Están asociadas al mantenimiento de Software 17 Agenda Introducción Pruebas de Programas Metodología de Pruebas Los Niveles de Prueba Diseño de Casos de Prueba Conceptos Estructura del Espacio de Pruebas Diseño de Casos de Prueba 18 9

10 Conceptos Espacio de Prueba Conjunto de todos los posibles casos de Prueba Pruebas de subdominios Subconjuntos del espacio de Prueba Línea de Prueba (Test Suite) Conjunto de casos de prueba que serán ejecutados en una fase 19 Conceptos (2) Testbed/Test Harness Software adicional desarrollado para soportar la ejecución de los casos de prueba Prueba de Cubrimiento Grado en el cual los casos de prueba pasan por el código siendo probado 20 10

11 Estructura del Espacio de Pruebas Taxonomia de los Casos de Prueba Pruebas Funcionales: considerar solamente entradas válidas al sistema y condiciones normales de operación. Pruebas de Robustez: considerar datos de entrada inválidos, secuencias invalidas de comandos/acciones, etc. Pruebas de Frontera: considerar valores/tamaños mínimos y máximos para datos de entrada, carga del sistema mínima y máxima, etc. 21 Estructura del Espacio de Pruebas (2) Taxonomia de los Casos de Prueba Pruebas de tolerancia a fallas: considerar condiciones anormales de operación, fallas hardware y software de la plataforma computacional sobre la que funciona el software en prueba

12 Diseño de los Casos de Prueba Hacer una lista de los propósitos de Prueba Usar la taxonomía de los casos de prueba como guía 23 Diseño de los Casos de Prueba (2) Por cada propósito de Prueba, hacer una lista de casos de prueba Construir una versión preliminar de la lista de casos de prueba a partir de los escenarios típicos relacionados con el propósito de prueba Enriquecer la lista de casos de prueba, analizando las posibles variaciones o casos especiales de los escenarios considerados Complementar la lista de casos de prueba, analizando posibles casos que puedan revelar errores, usando como guía la siguiente lista de 24 chequeo: 12

13 Diseño de los Casos de Prueba (3) Cuales son los errores típicos encontrados en productos similares probados en el pasado, y que casos de prueba se usaron para revelarlos? En pruebas del sistema y pruebas de aceptación, qué casos es probable que los desarrolladores hubieran pasado por alto (desde el punto de vista del experto del negocio o dominio de aplicación)? En pruebas de unidad y pruebas de integración, qué características complejas del diseño pudieron haber sido implementadas de forma incorrecta? 25 Diseño de los Casos de Prueba (4) En pruebas del sistema y pruebas de aceptación, qué aspectos complejos acerca de los requerimientos pudieron haber sido mal interpretados por los desarrolladores? Qué casos triviales pudieran haber sido no tenidos en cuenta en la implementación? 26 13

14 Diseño de los Casos de Prueba (5) Para cada caso de prueba, especificar los pasos para realizar la prueba y los criterios de aceptación de la prueba, tal como se indica en el formato: 27 Diseño de los Casos de Prueba (6) Caso de uso Procedimiento Criterios de aceptación Procedimiento Criterios de aceptación... Caso de uso

15 Diseño de los Casos de Prueba (7) Para cada caso de prueba se debe especificar Instrucciones de prueba: lista de pasos a seguir por los usuarios encargados de ejecutar la prueba. Criterios de aceptación: lista de condiciones (predicados) que deben satisfacerse para determinar el éxito de la prueba, incluyendo restricciones sobre los datos de salida esperados, y condiciones que deben cumplirse en el estado interno del sistema (ej. valores de algunas tablas) después de ejecutar el caso de prueba