Tema I Testing Estructurado 1ra Parte Verificación y Validación de Software ‐‐ UNS 1 Contenidos y Conceptos de V&V y Fundamentos de Testing y Testing de Unidad y Testing de Unidad: Caja Blanca Verificación y Validación de Software ‐‐ UNS 2 Verificación y Validación y Lectura y Ghezzi, C., et.al. Fundamentals of Software Engineering. Prentice‐Hall, 1991. [Cap. 6] Verificación y Validación de Software ‐‐ UNS 3 Conceptos de V&V (1) y Durante el diseño y construcción de un Producto Software, se requiere verificar el producto en todas las etapas intermedias de desarrollo y Aún con técnicas de diseño y programación sofisticadas, la intervención humana implica equivocaciones que se traducen en errores y Los productos terminados que pasaron las verificaciones intermedias, también deben ser verificados y Los Clientes deben dar su conformidad con el Producto Software desarrollado Verificación y Validación de Software ‐‐ UNS 4 Conceptos de V&V (2) y Verificación: Proceso de evaluación de un sistema ¿Estamos construyendo correctamente el producto? (o de uno de sus componentes) para determinar si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase ¿Estamos construyendo el producto correcto? y Validación: Proceso de evaluación de un sistema (o de uno de sus componentes) durante o al final del proceso de desarrollo para determinar si satisface los requisitos marcados por el usuario Verificación y Validación de Software ‐‐ UNS 5 Conceptos de V&V (3) Ciclo de Vida de Software – Modelo V Verificación y Validación de Software ‐‐ UNS 6 Conceptos de V&V (4) y Debido a la urgencia de entregas de un Producto Software, es una práctica común realizar una pobre verificación y En general consiste de algunos casos de ejemplo, para observar si los resultados de ejecución cumplen nuestras expectativas y Esto implica una pobre confianza en ese Producto Software y La verificación no se puede sólo basar en la intuición humana, experiencia o suerte. y Se require que la actividad de verificación siga principios y técnicas rigurosas y adecuadas Verificación y Validación de Software ‐‐ UNS 7 Conceptos de V&V (5) y Tanto el proceso de desarrollo de software como los productos generados deben ser verificados y “Aún el proceso de verificación debe ser verificado” y Una vez realizada una verificación para comprobar un comportamiento apropiado, es necesario verificar si los experimentos se desarrollaron en forma apropiada y Se aplican métodos y técnicas para la verificación, donde en general se requiere alguna intervención humana, que es falible a equivocaciones. Verificación y Validación de Software ‐‐ UNS 8 Conceptos de V&V (6) y A través de la verificación no solo debe controlarse si el software implementado se comporta de acuerdo a la especificación, sino certificar características de calidad. y Atributos de calidad como Performance, Portabilidad, Tolerancia a Fallas, etc. son requerimientos arquitectónicos, priorizados por los Stakeholders (participantes) en un Desarrollo centrado en Arquitectura Software y Cuando el Producto Software ha pasado las verificaciones iniciales y ha sido construido “como un todo”, debe ser verificado en sus cualidades arquitectónicas. Verificación y Validación de Software ‐‐ UNS 9 Conceptos de V&V (7) • La actividad de verificación debe realizarse en momentos diferentes con objetivos, técnicas y personal diferente • “Quien desarrolla su producto no debería verificar su producto” • El ego humano no permite ser objetivo. No queremos aceptar nuestras equivocaciones, y queremos “terminar pronto”. • La verificación no puede reducirse a una respuesta binaria (“si/no”) ya que: • la presencia de defectos en software complejo no puede evitarse completamente • a veces, algunos defectos pueden ser tolerados • en la práctica, la correctitud es relativa • la eficiencia es un ejemplo típico de calidad que puede aparecer en distintos niveles Verificación y Validación de Software ‐‐ UNS 10 Conceptos de V&V (8) Enfoques de Verificación • Experimentar con el comportamiento de un producto para observar si realiza lo esperado, i.e. testear el producto • Es una técnica dinámica, dado que requiere ejecutar el sistema para ser verificado. • Analizar el producto (o especificación de diseño) para deducir su operación correcta como consecuencia lógica de las decisiones de diseño. • Es una técnica estática, dado que no requiere ejecutar el producto, y se puede realizar temprano en el Ciclo de Vida. Verificación y Validación de Software ‐‐ UNS 11 Conceptos de V&V (9) • El mito dice que si somos realmente buenos programando, no habrá errores que encontrar. • Si nos concentramos bien, si usamos programación estructurada, OO, silver bullets ... • Hay bugs, dice el mito, porque somos malos programando, y si somos malos debemos sentirnos culpables! La producción de software, como cualquier actividad humana, es un proceso sujeto a errores. Cualquiera sean los métodos usados, no es posible garantizar que el producto final se comporte siempre como es requerido. Verificación y Validación de Software ‐‐ UNS 12 Fundamentos de Testing (1) Testing de Software: verificación dinámica del comportamiento de un programa contra el comportamiento esperado, usando un conjunto finito de casos de test, seleccionados de manera adecuada desde el dominio infinito de ejecución. (SWEBOK04) • El test de un programa puede revelar la PRESENCIA de fallas pero NUNCA demostrar su AUSENCIA [Dijkstra’72] Verificación y Validación de Software ‐‐ UNS 13 Fundamentos de Testing (2) • El test debe: • ayudar a localizar errores (no solo detectarlos), • ser repetible (riguroso, objetivo e independiente), • ser preciso (confiable y formal) Modelos de Testing Destrucción: detección de errores de implementación (fines ‘70, inicio ‘80) Evaluación: detección de errores en el análisis, la especificación, el diseño, la implementación (década de los ‘80) Verificación y Validación de Software ‐‐ UNS 14 Fundamentos de Testing (3) • La mayor parte del costo del software es el costo de los bugs: detectarlos, corregirlos, diseñar los test, ejecutar los test • El diseño de tests es uno de los mejores métodos para prevenir bugs ... • Un diseño de test debe documentar: expectativas, el procedimiento del test en detalle, los resultados del test Un bug se manifiesta como una conducta no esperada Saber que el programa es incorrecto no implica conocer el bug - diferentes bugs se pueden manifestar de la misma manera - un bug puede tener diferentes síntomas Verificación y Validación de Software ‐‐ UNS 15 Fundamentos de Testing (4) Los síntomas y las causas pueden ser descubiertas con muchos pequeños tests Tipos de bugs: estructurales, en los datos, en el código, en las interfaces, en los tests . . . 1+1=3 Terminología IEEE • falla (failure): manifiesta el sintoma de la presencia de un error. • defecto (fault): estado intermedio incorrecto al que se puede ingresar durante la ejecución. • error: aspecto incorrecto program doble (input, output) var x,y: integer; begin read(x); y := x * x; write(y); end. Verificación y Validación de Software ‐‐ UNS 16 Fundamentos de Testing (5) Un programa P es considerado una función del conjunto de datos D, dominio de la función, en el conjunto de datos R, el codominio (P: D -> R) • P(d) = r (d en D, r en R) ejecución de P con d • ok(P,d) si P(d) es correcto, satisface la especificación • ok(P) P es correcto para cada elemento d del dominio de ingreso D ok(P) ssi For all d en D ok(P,d) Un test T para un programa P con dominio D es un subconjunto del dominio D Un elemento t de un test T es un dato de test La ejecución de un test T consiste en la ejecución de P para todos los datos de test t contenidos en T Verificación y Validación de Software ‐‐ UNS 17 Fundamentos de Testing (6) • ok(P,T): un programa P es correcto respecto a un test T si el programa es correcto para todos los elementos de T ok(P,T) ssi For all t en T ok(P,t) • éxito(T,P) ssi not ok(P,T) es decir, si encontró una falla De un test que no revela ninguna falla no se deduce que el programa es correcto, sino que el test es inadecuado • Un test es ideal si de su NO éxito se puede deducir que el programa es correcto ok(P,T) -> ok(P) Buscamos aproximarnos a test ideales Verificación y Validación de Software ‐‐ UNS 18 Testing de Unidad (1) • No existe algoritmo que dado un programa arbitrario P genere un test ideal finito • No es posible establecer si dos programas genéricos calculan la misma función qué hacer? white-box vs. black-box Verificación y Validación de Software ‐‐ UNS 19 Testing de Unidad (2) Ciclo de Vida de Software – Modelo V Verificación y Validación de Software ‐‐ UNS 20 Testing de Unidad (3) Caja Blanca Caja Negra • Test Estructural: • Test de Función: basado en la estructura del programa (ej.: código) • Ventajas • formal • con una teoría completa • eficiente • metódico basado en la conducta requerida del programa (ej.: especificaciones) • Ventajas • con significado asociado • encuentra los errores que ve el usuario • no necesita análisis • independiente de la implementación Verificación y Validación de Software ‐‐ UNS 21 Testing de Unidad (4) Caja Blanca: • Desventajas • puede no ser útil o no tener significado • no encuentra muchos errores importantes • dependiente de la impl. • Efectividad • encuentra 50-75% de los errores en test de unidad • . . . pero son los errores más fáciles de encontrar Caja Negra: • Desventajas • ineficiente • teoría incompleta • no puede ser automatizado • intuitivo más que formal • Efectividad: encuentra errores... • 10-30% en test de unidad • 50-75% en test de sistema • los errores más embarazosos Verificación y Validación de Software ‐‐ UNS 22 Testing de Unidad (5) Estrategias de Testing de Unidad Caja Blanca Caja Negra • Ejecución Simbólica • Partición en Clases de Equivalencia • Análisis de Flujo de Datos • Test basado en Defectos (fault) • Análisis de Valores Límites • Análisis Mutacional • Grafos Causa-Efecto • Debugging • Test basado en Estado Verificación y Validación de Software ‐‐ UNS 23 Testing de Unidad: Caja Blanca (1) Cada estrategia tiene el concepto de cubrimiento asociado Un cubrimiento del 100% no es equivalente a que el testing sea completo, significa que es completo respecto a cierta estrategia Existe gran cantidad de estrategias, ninguna es la mejor, pero hay algunas mejores que otras. Criterios de Flujo de Control: • • • • • • Criterio de Comandos (o Sentencias, o Nodos) Criterio de Decisiones (o Arcos) Criterio de Condiciones y Decisiones Criterio de Condiciones Múltiples Criterio de Bucles (Loops, Iteraciones) Criterio de Caminos Verificación y Validación de Software ‐‐ UNS 24 Testing de Unidad: Caja Blanca (2) Criterios de Flujo de Control Criterio de Comandos: Un test T satisface este criterio ssi cada comando ejecutable del programa es ejecutado al menos una vez en correspondencia a al menos un dato de test de T Criterio de las decisiones (arcos): Seleccionar un conjunto de test T tal que al ejecutar P para cada d en T, cada arco del grafo de flujo de control de P sea atravesado al menos una vez Verificación y Validación de Software ‐‐ UNS 25 Testing de Unidad: Caja Blanca (3) Grafos de Flujo de Control B1 B2 nodos de I/O, asignación, o llamada a función While B1 Dos bloques secuenciales B1 If-Then B1 B2 If-Then-Else Verificación y Validación de Software ‐‐ UNS 26 Testing de Unidad: Caja Blanca (4) 1 program statement; read(x) read(y) 2 var 3 x, y: real; 4 begin not (x <> 0) 5 read(x); 6 read(y); 7 if x <> 0 then x := x + 10; 8 y := y / x; 9 write(x); x <> 0 x := x + 10 y := y/x TC = { (x=20, y=30) } 10 write(y); 11 end. write(x) write(y) TD = { (x=20, y=30), (x=0, y=30) } Verificación y Validación de Software ‐‐ UNS 27 Testing de Unidad: Caja Blanca (5) Cubrimiento de las condiciones: Un test T satisface este criterio ssi cada condición simple que aparece en cada decisión del programa es evaluada al menos una vez a TRUE y al menos una vez a FALSE para diferentes datos de test. True False Cubrimiento de las condiciones múltiples: Un test T satisface este criterio ssi cada condición simple que aparece en cada decisión del programa es evaluada a TRUE y a FALSE en todas las combinaciones de la tabla de verdad, para diferentes datos de test. Verificación y Validación de Software ‐‐ UNS 28 Testing de Unidad: Caja Blanca (6) read(x) read(y) 1 program branch; 2 var 3 x, y: real; 4 begin 5 read(x); 6 read(y); 7 if x = 0 or y > 0 then y:= y/x 8 else x := y + 2 / x; 9 write(x); 10 write(y); 11 end. 1 2 x := y + 2 / x x = 0 or y > 0 3 write(x) 4 y := y / x 5 write(y) T1 = { (x=5, y=5), (x=5, y=-5) } T2 = { (x=0, y=-5), (x=0, y=5) } Verificación y Validación de Software ‐‐ UNS 29 Testing de Unidad: Caja Blanca (7) Cubrimiento de los caminos: Seleccionar un conjunto de test T tal que al ejecutar P para cada d en T, todos los caminos desde el nodo inicial al final del grafo de flujo de control sean atravesados. Condiciones para ejecutar loops Después de elegir un criterio, deberíamos buscar valores que garanticen su aplicación. • Podemos no necesitar read (x); gran esfuerzo . . . z := 2 * x; if z = 4 then statement . . . • . . . o nunca encontrar datos de test . . . if x > 0 then if x < 0 then statement . . . Verificación y Validación de Software ‐‐ UNS 30