15/06/2010 Contenido 1. 2. INGENIERIA DE SOFTWARE Tema 5. Métodos de Prueba 3. 4. 5. Presenta: David Martínez Torres 6. Universidad Tecnológica de la Mixteca 7. Introducción Métodos de prueba Pruebas de caja blanca Pruebas de caja negra Diseño de casos de prueba Conclusiones Referencias dtorres@mixteco.utm.mx Cubo 37 1 2 1. Introducción ... 1. Introducción La prueba es uno de los pasos de la I.S. destructivos(psicológ.) La prueba del software: Elemento crítico para la garantía de la calidad del software, representa la revisión final de las especificaciones, diseño y codificación (normalmente muy cara esta etapa) Mito, si fuéramos realmente buenos programando no habría errores que buscar Objetivos de la prueba Proceso de ejecución de un programa para descubrir un error Buen caso de prueba, tiene una probabilidad alta de descubrir un error hasta entonces Tiene éxito si descubre un error hasta entonces. No puede asegurar la ausencia de defectos, solo puede demostrar que existen defectos 3 Principios de la prueba 1. 2. 3. 4. 5. 6. Facilidad de prueba A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente Debería planificarse mucho antes de que empezasen El p principio p de Pareto es aplicable p a la prueba p del software Deberían empezar por lo “pequeño” y progresar a lo “grande” No son posibles las pruebas exhaustivas Para ser más efectivas, deberían ser conducidas por un equipo independiente 5 Características que llevan a un software fácil de probar Operatividad –Cuanto mejor funcione, más eficientemente se puede probar Observabilidad -lo que ves es lo que pruebas Controlabilidad –Cuanto mejor se pueda controlar el Sw, más se puede automatizar y optimizar Capacidad p de descomposición p –p permite aislar los problemas más á rápidamente á y llevar a cabo mejores pruebas de regresión Simplicidad – Cuanto menos haya que probar, más rápido se puede probar Estabilidad – Cuanto menos cambios, menos interrupciones en la prueba Facilidad de comprensión –Cuanto más info. se tenga, más inteligentes serán las pruebas 6 1 15/06/2010 2. Métodos de prueba del software Prueba de caja blanca Heztel[HET84] “A pequeña escala” Estructura del control del programa Prueba del camino básico P b d Prueba de condiciones di i y del d l flujo fl j de d datos d t 4. Técnica de pruebas de caja blanca Prueba de caja negra (s/la interfaz del Sw) “A gran escala” Validan los requisitos funcionales sin fijarse en el funcionamiento interno de un programa Se centran en el ámbito de info. de un programa Prueba del camino básico La técnica de Tom McCabe[MCC76], permite al diseñador de casos de prueba obtener una medida de la complejidad lógica de un diseño procedimental y usar esa medida como guía para la definición ó de un conjunto básico á de caminos de ejecución (complejidad ciclomática) El camino básico, define el número de caminos independientes del conjunto básico de un programa 7 Complejidad Ciclomática Complejidad Ciclomática La complejidad de un programa puede ser medido por el número ciclomático del grafo de flujo (diagrama de flujo). El número ciclomático puede ser calculado de 3 maneras: Basado-grafo de flujo 8 Basado-código V(G) = 1 + d d: número de nodos predicados V(G) = e - n + 2 e: número de aristas (ramas y ciclos) n: número de nodos (bloques de (nodos con grado grado-salida salida mas de 1) d: representa el número de loops en el grafo, o el número de puntos de decisión en el programa código secuencial) V(G) = Número de regiones 9 Complejidad ciclomática Ejemplo: Basado-código Por grafo v(G) = e – n + 2 v(G) = 7 – 6 + 2 v(G) = 3 1 2 R1 3 4 1 #include <stdio.h> main() 2 R3 { 3 R2 int a; 4 R1 5 scanf(“%d”, &a); 6 if (a>= 10) 8 if (a < 20) printf(“10 < a < 20 %d\n”, a); else printf(“a >= 20 %d\n”, a); else printf(“ a <= 10 %d\n”, a); } R2 5 R3 6 e: # aristas n: # de nodos Por código g v(G) = 1 + d v(G) = 1 + 2 v(G) = 3 Por regiones v(G) = # de regiones v(G) = 3 11 7 Por código v(G) = 1 + d v(G) = 1 + 2 v(G) = 3 grafo Por g v(G) = e – n + 2 v(G) = 9 – 8 + 2 v(G) = 3 Por regiones v(G) = # de regiones v(G) = 3 12 2 15/06/2010 Ejemplo: Basado-Grafo 5. Diseño de casos de prueba Por grafo v(G) = e – n + 2 v(G) = 15 – 12 + 2 v(G) = 5 9 El diseño de casos de prueba es obtener un conjunto de pruebas que tengan la mayor probabilidad de descubrir los defectos del software Por código v(G) = 1 + d v(G) = 1 + 4 v(G) = 5 Por regiones v(G) = # de regiones v(G) = 5 13 14 Obtención de casos de prueba 1. 2. 3. 4. Ej: Grafo del flujo del procedimiento media El método del camino básico se puede aplicar a un diseño procedimental detallado o a un código fuente Pasos: A partir de un diseño o código se dibuja el grafo de fl j flujo Se determina la complejidad ciclomática Se determinar un conjunto básico de caminos linealmente independientes 1. Importante identificar nodos predicados Preparar los casos de prueba que forzarán la ejecución de cada camino del conjunto básico 1 2 3 10 4 12 11 6 13 8 16 Cálculo de la complejidad ciclomática … Ej. Diseño de casos de prueba V(G)=No. Regiones = 6 V(G)=1+d=1+5=6 V(G)=e-n+2 = 17-13+2=6 1 7 9 15 Grafo del flujo del procedimiento media 5 Diseño de casos de prueba 2 R1 10 R6 12 R2 11 3 5 R3 6 13 8 Ej. Conjunto básico 4 R4 9 R5 7 Camino Camino Camino Camino Camino ... Camino 2-... 1: 2: 3: 4: 5: 1-2-10-11-13 1-2-10-12-13 1-2-3-10-… 1-2-3-4-5-8-9-2-... 1-2-3-4-5-6-8-9-2- 6: 1-2-3-4-5-6-7-8-917 18 3 15/06/2010 6. Conclusiones 7. Referencias Es una fase de gran utilidad sobre todo para los desarrolladores Permite corroborar con los casos de prueba, que los resultados dados por el sw son los esperados Fase de g gran importancia p debido a que q valida que el producto realmente cumpla con sus especificaciones y por tanto asegura la calidad de sw. Se usa también para mejorar el rendimiento del sw También cabe recordar que la fase de pruebas nunca terminan. 19 1. 2. 3. Pressman, S Roger (1998) “Ingeniería del Software: Un enfoque práctico,” 4a edición McGraw-Hill. Somerville, Ian (2002) “Ingeniería de software,” 6a edición edición. Addison Wesley. Wesley Braude Eric J. (2003) “Ingeniería de Software Una perspectiva orientada a objetos,” Alfaomega 20 ¿Preguntas? Gracias! 21 4