Tema 4: Pruebas - Conceptos. Departamento de Lenguajes y Sistemas Informáticos II

Transcripción

1 Tema 4: Pruebas - Departamento de Lenguajes y Sistemas Informáticos II

2 Índice

3 Verificaci y Validaci Qué significa verificar el? Determinar si los productos de una fase dada satisfacen las condiciones impuestas al inicio de la fase. Qué significa validar el? Evaluar un sistema o uno de sus componentes, durante o al final de su desarrollo, para determinar si satisface los requisitos.

4 Defecto/fallo/error Qué es un defecto en el? Una definici de datos incorrecta. Un paso de procesamiento incorrecto en el programa. Qué es un fallo en el? Es la incapacidad de un sistema para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados.

5 Defecto/fallo/error Qué es un error en el? Un defecto. Un resultado incorrecto. Acci humana que lleva a un resultado incorrecto. La diferencia entre un valor calculado y el verdadero.

6 Defecto/fallo/error Un error del programador introduce un defecto y este defecto produce un fallo.

7 Software Qué es la prueba del? Una actividad en la que un sistema, o uno de sus componentes, se ejecuta en circunstancias previamente planificadas. Los resultados se observan, se registran y se realiza una evaluaci. Es un elemento crítico para la garantía de calidad del y representa una revisi final de las especificaciones, del diseño y de la codificaci.

8 Software Qué es un caso de prueba? Un conjunto de: Entradas. Condiciones de ejecuci. Resultados esperados. Este conjunto se llama escenario.

9 Software Objetivos Proceso de ejecuci de un programa con el fin de descubrir un error, con poca cantidad de tiempo y esfuerzo. Las pruebas permiten verificar y validar el. Buen caso de prueba Alta probabilidad de encontrar un error. Éxito de una prueba Descubrir error no detectado con anterioridad. Las pruebas no garantizan la ausencia de defectos.

10 Software Principios Planificaci anterior a la realizaci (Plan de prueba). Imposibilidad de hacer unas pruebas exhaustivas. Empezar por lo pequeño y progresar a lo grande. Gran efectividad Realizaci de pruebas por equipos independientes. Se deben incluir tanto entradas correctas como incorrectas. Las pruebas se deben documentar detalladamente.

11 Software Proceso

12 Diseño de pruebas Probar exhaustivamente un es imposible. Necesitamos técnicas que nos ayuden a confeccionar casos de prueba que me aseguren una evaluaci eficiente del. La mejor técnica es aquella que con menos casos de prueba me lo certifique.

13 Diseño de pruebas 4 enfoques para la construcci de casos de prueba: (Estructural). (Funcional)...

14 Principios Ejercitar una vez todos los caminos. Ejercitar todas las decisiones (V/F). Ejercitar todos los bucles (límites). Ejercitar las estructuras de datos. Para cumplir con los principios anteriores disponemos de 2 pruebas: camino básico. la estructura de control.

15 camino básico. Qué es un camino? Es por donde el flujo de ejecuci debe pasar Técnica de prueba de que define un conjunto básico de caminos de ejecuci Se debe generar un caso de prueba para cada camino de ejecuci.

16 camino básico Cómo descubrir los caminos? Mediante el diagrama de flujo.

17 camino básico Cómo construir un diagrama de flujo a partir del código? 1. Señalar todas las decisiones de las sentencias 1. If-then 2. Case-of, 3. While 4. Until. 2. Agrupar resto de sentencias. 3. Señalar los end if y end while.

18 camino básico Principios Condici 1 Condici 3 If or and then Decisi Condici 2

19 camino básico Principios X X X Secuencia Si X entonces Hacer hasta X Mientras X, hacer

20 camino básico Principios Nodo Arista 6 7 R ,3 R2 4,5 R1 Regi R4

21 camino básico Complejidad ciclomática de McCabe: Métrica del sw utilizada para determinar el número máximo de caminos independientes. Fórmula de las regiones: V(G)=A-N+2 Fórmula de las decisiones: V(G)=C+1 (C nodos de decisi). Las Regiones: V(G)=R A-N+2 = C+1 = R

22 camino básico Procedimiento: Dibujar el grafo de flujo. Calcular la complejidad ciclomática. Determinar el conjunto de caminos independientes. Preparar el caso de prueba para cada camino.

23 la estructura de control P. camino básico P. estructura de control. Amplía la cobertura de la prueba. Mejoran su calidad.

24 la estructura de control Grado de cobertura: por qué sentencias se debe pasar para considerar que se ha pasado la prueba. Según la cobertura: sentencia. decisi. condici. decisi/condici. bucles.

25 Se utilizan particiones/clases de equivalencia. Ignora la estructura de control. Se divide el dominio de los valores de entrada en diferentes clases/particiones. Cada clase de equivalencia posee unos ciertos valores ->Estos valores dan resultados iguales ->Para realizar la prueba cogemos un único valor representante de cada clase. 2 métodos de pruebas de Caja negra: Partici en clases de equivalencia. Análisis de valores límite (AVL).

26 Partici en clases de equivalencia Procedimiento Identificar clases de equivalencia. Crear los casos de prueba.

27 Partici en clases de equivalencia Identificar clases de equivalencia De cada clase se deben obtener datos válidos y no válidos.

28 Partici en clases de equivalencia Reglas para la identificaci de clases equivalencia Rango: si se especifica un rango de valores para los datos de entrada se creará una clase válida y dos clases no válidas. Ej: Alquiler para personas entre 18 y 80 años < 18 años > 80 años

29 Partici en clases de equivalencia Valor: si se especifica un valor se creará una clase válida y dos no válidas. Ej: El nombre debe tener 10 caracteres < 10 caracteres > 10 caracteres

30 Partici en clases de equivalencia Lógico: si se especifica una situaci del tipo booleano se identifica una clase válida y una no válida. Si se sospecha que ciertos elementos de una clase no se tratan igual deben dividirse en clases menores. Si se especifica un conjunto de valores y el programa los trata de diferente manera, se identifica una clase válida y otra no válida para cada valor.

31 Partici en clases de equivalencia Principios Para cubrir todas las clases válidas se tratará de preparar casos de prueba que cubran el máximo nº de clases válidas no cubiertas. Para cubrir todas las clases no válidas se preparará un caso de prueba para cada clase no válida sin cubrir.

32 Análisis de valores límite Es una técnica complementaria a la partici en clases de equivalencia. Explora las condiciones límites de un programa. Se eligen valores en los márgenes de la clase. No sólo se fija el dominio de entrada sino también el dominio de salida.

33 Análisis de valores límite Principios 1. Rango: Si una condici de entrada especifica un rango de valores, se deben generar casos válidos con los extremos del rango y casos no válidos para situaciones justo más allá de los extremos. 2. Valor: Si la condici de entrada especifica un valor se deben generar casos para el número máximo, mínimo, máximo+1 y mínimo-1.

34 Análisis de valores límite 3. Usar la regla 1. para la condici de salida. 4. Usar la regla 2. para la condici de salida. Los valores límite de entrada no generan necesariamente los valores límite de salida. No siempre se pueden generar resultados fuera del rango de salida. 5. Si la entrada o la salida de un programa es un conjunto ordenado, los casos se deben concentrar en el primer y último caso.

35 Enumerar una lista de comunes. En funci de ella elaborar los casos de prueba. El valor 0 es una situaci propensa a error, tanto en la salida como en la entrada

36 Se crean datos que sigan las frecuencia y la secuencia que tendrían en la práctica. Se simula la entrada de datos Se usan generadores de prueba.

37 de la fase de pruebas Plan de Pruebas Especificaci de casos de pruebas Especificaci de diseño de pruebas Especificaci de procedimientos de pruebas Ejecuci Informes

38 de la ejecuci Qué se obtiene en la ejecuci? Especificaci de casos de pruebas Especificaci de diseño de pruebas Especificaci de diseño de pruebas

39 Depuraci Es el proceso de localizar, analizar y corregir los defectos que se sospecha que contiene el. La depuraci es síntoma de una prueba con éxito. La localizaci de un defecto conlleva mayor esfuerzo que la correcci.

40 Análisis de Errores Qué se registra? Cuándo se cometió. Quién lo hizo. Qué se hizo mal. Cómo se podría haber prevenido. Cómo se encontró el error.

41 Ciclo de vida de pruebas Código Prueba Unidad Prueba integraci Prueba sistema Prueba validaci

42 las pruebas del sw Proceso de Ingeniería Estrategias de prueba unidad integraci regresi validaci l sistema Depuraci l E D E A A C B B D C 42

43 Estrategias de prueba para arquitecturas convencionales Estrategias de prueba unidad integraci regresi validaci l sistema Depuraci Unidad Integraci validaci Sistema TOTAL: personal, HW, otros sistemas, etc. 43

44 Estrategias de prueba para arquitecturas convencionales Estrategias de prueba unidad integraci regresi validaci l sistema Unidad Verificar el módulo o componente Orientada a Caja Blanca Depuraci 44

45 Estrategias de prueba para arquitecturas convencionales Estrategias de prueba unidad integraci regresi validaci l sistema Depuraci Unidad Interfaz Estructuras de datos locales Condiciones límite Caminos independientes Rutas de manejo de 45

46 Estrategias de prueba para arquitecturas convencionales Estrategias de prueba unidad integraci regresi validaci l sistema Depuraci Unidad - Consideraciones Interfaz: fluidez de informaci desde y hacia la unidad de programa Nº de argumentos = Nº parámetros Orden correcto de los parámetros Valores válidos de los argumentos 46

47 Estrategias de prueba para arquitecturas convencionales Estrategias de prueba unidad integraci regresi validaci l sistema Depuraci Unidad - Consideraciones Estructuras de datos: Integridad de los datos durante la ejecuci Inicializaci o valores erreos Tipos de datos inconsistentes Desbordamiento 47

48 Estrategias de prueba para arquitecturas convencionales Estrategias de prueba unidad integraci regresi validaci l sistema Depuraci Unidad - Consideraciones Condiciones límite: Asegurar el funcionamiento en las restricciones Muy apropiados para descubrir todo tipo de 48

49 Estrategias de prueba para arquitecturas convencionales Estrategias de prueba unidad integraci regresi validaci l sistema Depuraci Unidad - Consideraciones Caminos independientes: Asegurar la ejecuci de todo (al menos una vez) Cálculos incorrectos Comparaciones incorrectas Flujos de control inapropiados 49

50 Estrategias de prueba para arquitecturas convencionales Estrategias de prueba unidad integraci regresi validaci l sistema Depuraci Unidad - Consideraciones Caminos de manejo de : asegura fin limpio al producirse un error No implica no realizar pruebas Descripci insuficiente del error Primar intervenci del manejo de error 50

51 Procedimiento de prueba de unidad Estrategias de prueba unidad integraci regresi validaci l sistema Depuraci Crear conductor (programa principal) Crear resguardo (módulo subordinado) Dependencia del módulo -> sobrecarga de trabajo 51

52 Procedimiento de prueba de integraci Estrategias de prueba unidad integraci regresi validaci l sistema Depuraci Verificar la estructura del programa Aumento de la interacci Integraci, nunca BIG BANG Integraci siempre incremental Errores fáciles de asilar Errores fáciles de corregir 52

53 Procedimiento de prueba de integraci Estrategias de prueba unidad integraci regresi validaci l sistema Depuraci Estrategias de integraci incremental Descendente En profundidad En anchura

54 Procedimiento de prueba de integraci Estrategias de prueba unidad integraci regresi validaci l sistema Depuraci Estrategias de integraci incremental descendente Pasos a seguir Programa principal y resguardos (módulos subordinados inmediatos) Ejecutar pruebas Sustituir resguardo por módulo real y agregar resguardos a ese módulo Ejecutar pruebas Problema Necesidad de un proceso inferior para la prueba de niveles superiores 54

55 Procedimiento de prueba de integraci Estrategias de prueba unidad integraci regresi validaci l sistema Depuraci Estrategias de integraci incremental descendente Soluciones Retrasar la prueba (no determinaci de ) Resguardos que simulen el proceso (exceso de esfuerzo) Integrar desde abajo hacia arriba (integraci ascendente) 55

56 Procedimiento de prueba de integraci Estrategias de prueba unidad integraci regresi validaci l sistema Estrategias de integraci incremental ascendente Hacer grupos con módulos atómicos Crear controlador para la prueba Probar el grupo Eliminar controlador y subir de nivel Depuraci 56

57 Procedimiento de prueba de integraci Estrategias de prueba unidad integraci regresi validaci l sistema Descendente para niveles superiores Ascendente para los inferiores Depuraci 57

58 regresi Estrategias de prueba unidad integraci regresi validaci l sistema Depuraci Asegurar el correcto funcionamiento cuando se produce un cambio en un sistema que ya estaba funcionando Ámbito - Qué se prueba Plan de pruebas Qué estrategia de integraci Fases Planificaci Software adicional (resguardos, controladores) 58

59 regresi Estrategias de prueba unidad integraci regresi validaci l sistema Depuraci Procedimiento de prueba Detalle de las pruebas Orden de integraci Lista de los casos de prueba Resultados esperados Resultados obtenidos Importante para el mantenimiento del SW 59

60 validaci Estrategias de prueba unidad integraci regresi validaci l sistema Depuraci que el funciona como espera el cliente Criterios Plan de pruebas Clases de pruebas Procedimiento de pruebas Definici de los casos de prueba Error -> inversi de más tiempo 60

61 validaci Estrategias de prueba unidad integraci regresi validaci l sistema Depuraci Revisi de la configuraci del Datos Programas Objetivo: mantenimiento del aceptaci Aceptaci del cliente Pruebas Alfa (lugar de desarrollo) Pruebas Beta (lugar del cliente) 61

62 l Sistema Estrategias de prueba unidad integraci regresi validaci l sistema SW + HW + datos + personal + = Sistema Quién es el culpable Buena planificaci de las pruebas Depuraci 62

63 l Sistema Estrategias de prueba unidad integraci regresi validaci l sistema Depuraci recuperaci seguridad resistencia rendimiento 63

64 Depuraci Estrategias de prueba unidad integraci regresi validaci l sistema Depuraci Proceso de eliminaci del error s: Fuerza bruta Vuelta atrás Eliminaci de causas Correcci Se repite en varias partes del programa? Cuál es el siguiente error? Prevenci del error 64