1 Validación y Verificación de Software Testing

2 2 La Crisis del Software Fenómeno mundial “decretado” hace muchos años –Muchos dicen que es crónica –Algunos casos traumáticos… Therac-25 (6 vidas) Arianne 5 (500 mill.) AT&T Switching System, etc, etc… Denver Airport (9 meses penalidad de 1.1 x día) –Miles de fracasos en Information Systems Cada vez + software crítico y + complejo

3 3 ¿Por qué es tan difícil? No existen soluciones mágicas, o “Balas de Plata” –Dificultades esenciales y accidentales Inmadurez de la Disciplina Abismo entre el “Estado del Arte” y el “Estado de la Práctica” (Ing. en Verificación) Problemas de Gerenciamiento Confusión Calidad Proceso  Calidad Producto

4 4 Ciclo de Vida y la introducción, detección y eliminación de defectos

5 5 Algunos números sobre los defectos 50 % de los defectos se introducen durante la programación Hoy, no más del 15% de los defectos iniciales son detectados antes del testing Al comienzo del test de unidad la densidad es de 20 defectos x cada 1000 líneas de código (no comentadas) 80% de los defectos de prog. se encuentran en el 20% de los módulos de programación. Muchos se evidencian durante la integración Costo de reparación (1000 en test de unidad a 12500 durante operación)

6 6 Calidad en software Confiabilidad Corrección Robustez Seguridad (en datos, en acceso, Safety) Funcionalidad Usabilidad Facilidad de Mantenimiento Reusabilidad Verificabilidad + Claridad Interoperabilidad

7 7 Asegurar la calidad vs. controlar la calidad Una vez definidos los requerimientos de calidad, tengo que tener en cuenta que: –Las calidad no puede “inyectarse” al final. –La calidad del producto depende de tareas realizadas durante todo el proceso. –Detectar errores en forma temprana ahorra esfuerzos, tiempo, recursos.

8 8 Testear antes de codificar “ El acto de diseñar tests es uno de los mecanismos conocidos más efectivos para prevenir errores… El proceso mental que debe desarrollarse para crear tests útiles puede descubrir y eliminar problemas en todas las etapas del desarrollo” B. Beizer “Test-Driven Development”: Kent Beck. XP

9 9 Definiciones Validación –¿Estamos haciendo el producto correcto? –Basada en el uso de modelos Verificación –¿Estamos haciendo el producto correctamente? –Necesariamente es en relación a un componente anterior, que describe nuestro producto

10 10 Aspectos de los “errores” de software Falla (failure) Diferencia entre los resultados esperados y reales Defecto (defect o fault) Está en el texto del programa, una especificación, un diseño, y desde allí se hace visible una falla Error = equivocación humana Un error lleva a uno o más defectos, que están presentes en un producto de software Un defecto lleva a cero, una o más fallas: la manifestación del defecto

11 11 Verificación estática y dinámica Dinámica: trata con ejecutar y observar el comportamiento de un producto Estática: trata con el análisis de una representación estática del sistema para descubrir problemas

12 12 Técnicas de Verificación Estática Inspecciones, Revisiones, Walkthrough (31 a 93 % media de 60%) Análisis de Reglas Sintácticas sobre código Análisis Data Flow sobre código Model Checking Theorem Proving (prueba de teoremas), etc.

13 13 Técnicas de Verificación Dinámica Testing Run-Time Monitoring. (pérdida de memoria, performance) Run-Time Verification

14 14 Testing Verificación Dinámica de la adecuación del sistema a los requerimientos (de distinto tipo) Objetivo: encontrar los errores importantes Mundialmente: 30 a 50% del costo de un software confiable

15 15 Testing Es el proceso de ejecutar un producto para –verificar que satisface los requerimientos –identificar diferencias entre el comportamiento real y el comportamiento esperado (IEEE Standard for Software Test Documentation, 1983) No prueba la corrección del software!

16 16 Cómo se hace testing? Input Comportamiento esperado del programa - ORÁCULO ? = okFalla ¹¹ Comportamiento obtenido del programa

17 17 Estamos asumiendo... que se puede ejecutar el programa que se conoce el resultado esperado y que el resultado esperado puede compararse con el resultado obtenido (problema del oráculos: visibilidad y comparación)

18 18 Limitación del testing El testing puede demostrar la presencia de errores, nunca su ausencia [Dijkstra] –entonces, el testing NO puede probar que el software funciona ok Una de las mayores dificultades es encontrar un conjunto de tests adecuado: –suficientemente grande para abarcar el dominio y maximizar la probabilidad de encontrar errores –suficientemente pequeño para poder ejecutar el proceso de testing con cada elemento del conjunto y minimizar el costo del testing

19 19 Unidad de Tiempo % Errores Detectados La visión moderna Se puede invertir mucho esfuerzo en testear Testear es el proceso de establecer confianza en que un programa hace lo que se supone que tiene que hacer Testear es una decisión económica Mejor prevenir

20 20 El pesticida mata el 98% de los bichos, dejando un residuo (los más fuertes) Al siguiente año, necesito un pesticida mejor Bicho en inglés es bug El buen uso del testing implica que los errores que no se encuentran son los más sutiles ¡Si todo anda bien, el tipo de errores encontrados tiene que cambiar! La paradoja del pesticida (Beizer)

21 21 Cuándo Parar? Problema: imposible en la práctica de estimar la intensidad del testing para alcanzar determinada densidad de defectos Estrategias (confiando en la convergencia): –Pasa exitosamente el conjunto de pruebas diseñado (“No Failure”) + cobertura estructural –“Good Enough”: cierta cantidad de fallas no críticas es aceptable (umbral de fallas no críticas por unidad de testing). –Defectos detectados es similar a la cantidad de defectos estimados, etc.

22 22 Test de requerimientos no funcionales - Ejemplos Test de seguridad, validando disponiblidad, integridad y confidencialidad de datos y servicios Test de performance, validando los tiempos de acceso y respuesta del sistema Test de stress, validando el uso del sistema en sus límites de capacidad y verificando sus reacciones más allá de los mismos Test de Usabilidad

23 23 Niveles de test Test de sistema (o subsistema) Test de integración Test de unidad

24 24 Testing de Integración Test orientado a verificar que las partes de un sistema que funcionan bien aisladamente, también lo hacen en conjunto –Testeamos la interacción, la comunicación entre partes –No debe confundirse con testear un sistema-integrado (test de sistema)

25 25 El test de Integración Unimos y testeamos partes ya testeadas (que se asumen correctas) La “estrategia” de unión depende del tipo de sistema –Sistema organizado jerárquicamente Top-down, bottom up, combinación de ambos –Sistema batch de procesamiento secuencial Por partes del flow de corrida –Sistema sin jerarquía (p.e., objetos) libre, salvo por el orden del desarrollo

26 26 Programa auxiliares: Stubs y drivers Driver simula las llamada Stub simula subprograma En total, exigen un esfuerzo considerable de programación

27 27 Hints Los puntos clave del test de integración: –Conectar de a poco las partes más complejas Esto permite identificar más fácil las causas de errores –Minimizar la necesidad de programas auxiliares Para ahorrar esfuerzo de programación

28 28 Error de Interpretación La funcionalidad provista por un módulo difiere del comportamiento esperado por quien usa un módulo Ejemplos: supongamos que A llama a B, ÔLa funcionalidad provista por B no es la requerida por la especificación de A ÔB provee más funcionalidades de las que usa A ÔA puede llamar a B con parámetros fuera del dominio de B

29 29 Error de ubicación de llamada La (instrucción de) llamada a un módulo no está en un lugar correcto del código Ejemplos: Ôla instrucción está en un camino que no debiera contener la llamada Ôla instrucción está mal ubicada dentro de un camino que debe contener a la llamada Ôla instrucción no está presente en un camino que debiera contener a la llamada

30 30 Error de Interfaz El estándar establecido entre llamador y llamado se viola Ejemplos: Ôlos parámetros no están en el orden correcto Ôlos parámetros no son del tipo correcto Ôlas reglas de llamadas no se respetan (por valor, por referencia) Ôel dominio del parámetro formal difiere del dominio del parámetro real ÔProblemas de sincronismo que hace que se acceda a información desactualizada

31 31 Tipos de interfaces más comunes Interfaces de parámetros tipo “call - return” –datos pasados de un procedimiento a otro Interfaces de memoria compartida Interfaces de intercambio de mensajes –Un subsistema requiere servicios de otro –En general son asincrónicas

32 32 Algunos hints para el testing de interfaces Aplicar el criterio de condiciones de borde Probar todos los parámetros de punteros con nulos Diseñar tests que hagan fallar al componente En el caso de memoria compartida, cambiar la secuencia de acceso a los datos Usar testing de estrés en interfaces de mensajes En interfaces de mensajes, cambiar el orden

33 33 Testing de Unidad Se realiza sobre una unidad de código pequeña, claramente definida –qué es una unidad En general es llevado a cabo por los desarrolladores

34 34 Test de unidades ¿Qué es una unidad? –Un programa… –Una función o procedimiento… –Un form… –Un script de un form… –Un subsistema… –Una clase…

35 35 Qué es y qué no es una unidad Una unidad es –El trabajo de un único programador –La cosa más pequeña que puede ser probada –Pequeña... 50 a 300 líneas de código Una unidad no es –La entidad más pequeña que provee una determinada funcionalidad –Lo primero que se puede probar sin programas auxiliares –50,000 - 100,000 líneas de código

36 36 El Testing y el ciclo de vida de un sistema Requerimientos Diseño preliminar Diseño detallado Preparar Test de unidades Programación Preparar test de integración Test de integración Preparar test de sistema Test de sistema Test de unidades Test de aceptación Modelo del Ciclo de Vida en “V”

37 37 Proceso de testing El testing no es sólo una etapa del proceso de desarrollo –Tradicionalmente, empezaba al término de la implementación, y terminaba con la puesta en producción es un proceso, paralelo al desarrollo

38 38 Actividades del proceso de testing Asociadas a requerimientos –Planificación de test de sistema Derivación de casos de test funcionales –Corrección de requerimientos a partir de lo detectado al confeccionar el plan

39 39 Actividades del proceso de testing Asociadas a arquitectura y diseño detallado –Planificación de test de integración y unidad –Generación de casos de test funcionales

40 40 Actividades del proceso de testing Asociadas a la implementación –creación de ambiente de ejecución de tests –generación de casos de test estructurales –ejecución de test de unidad –ejecución de test de integración –documentación de resultados –seguimiento de errores –test de regresión

41 Testing Funcional

42 42 Test funcional - Corrección funcional El programa p implementa correctamente a f si  i  dom(f): p(i) = f(i) espec. f f(i)f(i) i Outputs Inputs

43 43 Qué debe testear el testing funcional? p implementa correctamente a f Además, lo hace en forma razonable –por ejemplo, si i  dom(f) y f(i) = error, p da un error razonable (por ejemplo, no se cuelga!) Además,  i  dom(f), p avisa que i  dom(f)

44 44 Cómo seleccionar datos de test?...Intuiciones Agrupando los inputs Hipótesis: hay inputs “parecidos” (tratamiento), entonces testear el programa con uno de estos, equivaldría a testearlo con cualquier otro de estos –Esto no es verdad pero sirve y es la base de la mayor parte de las técnicas!!!

45 45 Terminología (I) Requerimientos de Test: Qué quiero testear. En el marco del testing de sistemas reactivos se llama el Test Purpuse. Especificaciones de Test :Supuestos y definiciones que sirven para generar los casos de test para el requerimiento de test

46 46 Terminología (II) Casos de test: descripciones de condiciones o situaciones a testear. Suele surgir de una especificación de test. Dato de test: asignación de valores concretos de parámetros para ejecutar un caso de test Test Suite T: conjunto de datos de test con los que se testea el programa Si P es correcto para todo elemento de T, se dice que T es exitoso para P Crear especificaciones y casos es un proceso creativo Crear datos de test es un proceso laborioso, y hay creatividad en cumplir económicamente con los casos

47 47 De manera Simple Caso1: cond 1, cond 2, cond 3,..., cond n 1 y ResEsp(1)... Casok: cond 1,...,..., cond n k ResEsp(k) DatosParam 1 Param 2 Param 3 Res. Esp. D1D1 X1X1 Y1Y1 Z1Z1 R1R1... DkDk XkXk YkYk ZnZn RnRn

48 Criterios de Selección: La base Teórica de las Técnicas de Generación de Casos

49 49 Criterios de selección de datos de test Un criterio es un subconjunto de conjuntos finitos del dominio de Inputs del programa P (puede estar expresado en términos de un conjunto de predicados también llamados casos) Se dice que un conjunto de datos T satisface un criterio C sii T  C

50 50 Criterios “ideales” Un Criterio C es Consistente para P sii para todo par T1 y T2 de test sets que satisfacen C, T1 es exitoso para P sii T2 lo es Un Criterio C es Completo para P sii si P es incorrecto entonces hay un test set T que no es exitoso para P

51 51 Son estas nociones efectivas? es decir, hay un algoritmo que proponga casos (i.e., un criterio) tales que encuentren todos los errores en cualquier programa? NO! Ni siquiera un algoritmo que diga si un criterio es completo y/o consistente. Ninguna técnica puede ser efectiva para detectar todos los errores en un programa arbitrario Uso de heurísticas en forma de criterios de testing

52 52 function fastexp(x,y: int): int; {devuelve x a la y} “¿Que casos probarían?” x,y xyxy Criterios“caja negra” También llamado testing producido por los datos, o testing producido por la entrada/salida –nos desentendemos completamente de la estructura interna del programa, pero no de su especificación

53 53 function fastexp (x,y: int):int; % pre: y >= 0 % post: devuelve x a la y z :int :=1; while y  0 do if odd(y) then z :=z*x; y :=y-1 endif; x := x*x; y :=y/2 endwhile return(z) “¿Qué pasa si y es potencia de 2?” “¿Qué pasa si y = 2 n -1?” x,y xyxy Criterios estructurales o de “caja blanca o de cristal” Los casos de test se definen a partir de la estructura interna del programa

54 54 Cómo evaluar en la práctica la calidad de los casos o datos generados Cobertura estructural del código (ej.: branching coverage) Cobertura contra especificación (ej.: caso de uso, workflow, etc.) Cobertura de GUI Fault Seeding (ej.: mutation testing), etc.

55 55 Importante No sólo testear casos válidos!!!! Condiciones válidas y esperadas –hace lo que se supone que hace Condiciones inválidas o inesperadas –no hace lo que se supone que no hace

56 Técnicas de Selección de Casos: “Partir y Combinar”

57 57 Qué se busca con las Técnicas? alta probabilidad de encontrar errores a bajo costo (o al menos controlable) usando ideas generales, sistematizables y semiautomatizables y un modelo de fallas subyacente como “rationale”

58 58 Técnicas de partición de Dominio Técnica II: Category-Partition de T. Ostrand & M. Balcer -1988 (generalización de Técnica I)

59 59 Método de Partición en Categorías - Ejemplo FIND Dado un nombre de archivo A y una expresión E, FIND devuelve la lista L de las palabras en A que comienzan con E, sin repeticiones. E no puede ser vacía ni contener blancos

60 60 Ejemplo PASO 1 1. Elegir una funcionalidad que pueda testearse en forma independiente Ya lo tenemos!

61 61 Ejemplo PASO 2 2. Determinar sus parámetros u otros objetos del ambiente que pueden afectar su funcionamiento -Archivo (nombre) -Expresión

62 62 PASO 3 3. Determinar las características relevantes de cada objeto determinado en el punto 2 (Archivo, Expresión) y de la relación entre estos objetos en el output (relación Archivo/Expresión) “Category” en el artículo original de Ostrand & Balcer 1988

63 63 Ejemplo - PASO 3 Características de E longitud de expresión blancos en la misma

64 64 Ejemplo - PASO 3 Características de A Tamaño de A

65 65 Ejemplo - PASO 3 Características de A/E número de ocurrencias de E en A número máximo de ocurrencias de E en una línea de A longitud de A vs. longitud de E repeticiones de palabras que contienen a E en A ubicación relativa de E en palabras de A...

66 66 PASO 4 4. Determinar elecciones (“choices”) para cada característica de cada objeto

67 67 Ejemplo en Categorías de E longitud de expresión –vacía –no vacía contiene blancos –sí –no

68 68 Ejemplo en Categorías de A existe –sí –no tamaño –vacío –no vacío

69 69 Ejemplo en Categorías de A/E (I) número de ocurrencias de E en A –0 –al menos 1 número máximo de ocurrencias de E en una línea de A –0 a 1 –más de 1

70 70 Ejemplo en Categorías de A/E (II) longitud de A vs. longitud de E –long A >= long E –long A < long E repeticiones de palabras que contienen a E en A –Sin repeticiones –A contiene repetida a p, palabra que comienza con E Ubicación relativa de E –p en A, E es prefijo de p –p en A, p contiene a E pero p no comienza con E...

71 71 PASO 5 - Clasificación : errores, únicos, restricciones E longitud –vacía - ERROR –no vacía blancos –sí - ERROR –no A existe –sí –no - ERROR tamaño –vacío - ÚNICO –no vacío

72 72 PASO 5 - Clasificación : errores, únicos, restricciones A/E número de ocurrencias de E en A –0 - ÚNICO –al menos 1 (A no vacío) número máximo de ocurrencias de E en una línea de A –0 o 1 –más de 1 (A no vacío) ÚNICO ETC.

73 73 PASO 6 Armado de casos Ver una posible soluci ó n en archivo Word

74 74 Resumen del Método 1. Elegir una funcionalidad que pueda testearse en forma independiente 2. Determinar sus parámetros u otros objetos del ambiente que pueden afectar su funcionamiento 3. Determinar las características relevantes de cada objeto determinado en el punto 2 y de la relación entre estos objetos en el output 4. Determinar elecciones para cada característica de cada objeto 5. Clasificación: errores, únicos, relaciones, restricciones 6. Armado de casos

75 75 Información para identificar categorías Texto informal o formal de la especificación Características propias de los param. de I/O de la funcionalidad a probar Cardinalidad del modelo de datos, que define reglas del negocio Ciclo de Vida de las entidades del modelo de datos

76 76 Algunas Conclusiones El método se aplica a cualquier descripción de funcionalidad (formal, semiformal o informal) Es necesario usar los requerimientos para planificar el testing Esto genera preguntas de incompletitud, ambigüedad, inconsistencia, e incorrección en un momento en que es “fácil” corregir requerimientos

77 77 Algunas Conclusiones (cont.) No hay una ú nica soluci ó n: dependiendo de c ó mo se realice el proceso se obtendr á un conjunto de casos de test particular Los casos de test pueden darse a conocer a los programadores antes de que implementen

78 78 Técnicas de partición de Dominio Técnica para la identificación de Categorías

79 79 Especificaciones de Servicios o Requerimientos Aparecen de manera + o – clara los (parámetros implícitos y explícitos), su casuística, la relación entre ellos Ejemplo:en los casos de uso: hay escenarios distintos dependiendo de valores de parámetros o de acciones decididas por el actor. Son parámetros candidatos con sus categorías y elecciones

80 80 Análisis de condiciones de borde Los casos de test que exploran los bordes de las clases de equivalencia producen mejor resultado –Cada margen de la clase de equivalencia debe quedar sujeto a un test –input y output

81 81 1. Heurística Si una condición de input especifica un rango de valores (intervalo), identificar una clase válida y dos inválidas Ejemplo: el item puede variar entre 1 y 999 VÁLIDA: 1 < valor < 999 INVÁLIDAS: 1  valor y valor  999 DE BORDE: valor = 1 y valor = 999

82 82 2. Heurística Si una condición de input especifica un número de valores, identificar una clase válida y dos inválidas Ejemplo: un automóvil puede tener entre uno y seis dueños VÁLIDA: entre uno y seis dueños INVÁLIDAS: ningún dueño y más de seis dueños DE BORDE: 1 dueño y 6 dueños

83 83 3. Heurística Si una condición de input especifica un conjunto de valores, y hay razones para pensar que cada uno es manejado por el programa en forma distinta, identificar una clase válida por cada elemento y una clase inválida Ejemplo: tipo de vehículo: camión, taxi, auto, moto VÁLIDAS: camión, taxi, auto, moto INVÁLIDA: algún tipo que no es camión, taxi, auto ni moto

84 84 4. Heurística Si una condición de input especifica una situación que debe ocurrir, identificar una clase válida y una clase inválida Ejemplo: el primer caracter debe ser una letra VÁLIDAS: es una letra INVÁLIDA: no es una letra

85 85 5. Sobre clases inválidas ¿Qué me falta? Probar el ingreso de valores de otro tipo que la clase –numéricos en vez de alfabéticos –alfabéticos en vez de numéricos –combinaciones de alfabéticos y numéricos –fechas erróneas, etc. El entorno de desarrollo puede ahorrar este trabajo

86 86 6. Tipos de Datos de input y output Caracter í sticas propias de los tipos de datos de entrada y salida de la funcionalidad testeada. Ejemplo: Fechas, listas, archivos de texto con determinado formato, etc.

87 87 8. Cardinalidad del modelo de datos La cardinalidad de las relaciones define reglas del negocio que deben ser probadas Cardinalidad mínima: cuántas instancias hay como mínimo de una entidad por cada instancia de una entidad relacionada con ella Cardinalidad máxima: cuántas instancias hay como máximo de una entidad por cada instancia de una entidad relacionada con ella

88 88 Ejemplo Cuenta sin firmante (inválido) Cuenta con un firmante (válido) Cuenta con más de un firmante (válido) Cuenta con más firmantes del máximo permitido (inválido)

89 89 9. Ciclo de vida de las entidades Visión temporal del modelo de datos: –a partir de un diagrama del ciclo de vida de una entidad

90 90 Ejemplo Debo probar: –Transiciones válidas –Transiciones inválidas

91 91 Técnicas Combinatorias Técnica III: Notación Arbórea

92 92 Datos Válidos Datos inválidos Caja de ahorroCuenta corriente ComúnDólares Alta de Cuenta Definición Arbórea Un ejemplo:

93 93 Definición Arbórea Puede verse como category-partition especial donde el mismo diseñador de casos decide explicítimanete cómo combinar Por ejemplo, cuando hay idea de orden de ingreso de parámetros se puede minimizar casos sin sentido Se arma un árbol donde cada nodo indica “category” sobre un parámetro o combinación entre un parámetro y uno anterior descripto en el árbol Los ejes que salen son las choices compatibles con las condiciones acumuladas desde la raíz Los casos de tests especificados y ejecutados son los caminos del árbol

94 94 Definición Arbórea: Consejos –Hay categorías que pueden ser irrelevantes en una rama, entonces no se abren –Varios choices pueden agruparse –Un error corta la rama –Condiciones normales de un lado, errores del otro... –Tener en cuenta que el orden en que aparecen los parámetros y sus categorías puede ser importante (ej: del año y día) –Mantener el mismo orden parámetro-categoría en todas las ramas para facilitar la documentación posterior

95 95 Combinando Category-Partition Fases 1- 5 con Definición Arbórea Si primero hago un category partition (salvo combinatoria): –conviene anotar la relevancia de cada categoría respecto a choices de otras categorías –Criterio de cobertura: hay que revisar que todos los choices sean ejercitados en el árbol

96 96 Técnicas Combinatorias Técnica I: Grafo Causa-Efecto

97 97 Grafo de Causa-Efecto Especificaciones de I/O complejas (mucha dependencia entre Inputs, entre Outputs y entre I/O) Nos permite definir combinaciones relevantes de categorías binarias sobre inputs para definir casos. Allí difiere del la parte combinatoria de Category-Partition Provee un display visual de las relaciones entre una causa y la otra Ayuda a detectar ambigüedades o incompletitud en la especificación

98 98 Grafo de Causa-Efecto Idea: Generar todos los outputs admisibles con la siguiente heurística: –Si hay un “or” (todas las opciones con sólo una señal en True) –Si hay un “and” (todas con sólo una en falso) O(n*k*o) en lugar de O(2 n ) dónde n es la cantidad de categorías binarias sobre el input, k la profundidad del DAG y o la cantidad de combinaciones del output válidas

99 99 Ejemplo Grafo de Causa-Efecto Para mostrar una de las 10 posibles secciones del índice se debe entrar un comando que consiste en una letra y un dígito –El primer carácter debe ser una D para display o una L para List, y debe estar en la columna 1 –El segundo carácter debe ser un número (0..9) en la columna 2 –Si se ingresa un comando como éste, el índice de la sección identificada por el dígito es mostrada en la terminal. Si el primer caracter es incorrecto “comando inválido”, y si el 2do caracter es incorrecto “número de índice inválido”

100 100 1=causa presente pasa, nulo no importa 1 220 51 50 352 E not andand Grafo booleano oror Grafo de Causa-Efecto: Ejemplo Causas 1. Carácter en la 1er columna es D 2. Carácter en la 1er columna es L 3. Carácter en la 2da columna es un dígito Efectos 50. El índice de la sección es mostrado 51. Msg “comando inválido” 52 Msg “número de indice inválido”

101 101 Grafo de Causa-Efecto: Ejemplo Ejemplo de datos de test derivados Tabla de decisión y casos de test

102 102 Grafo de Causa-Efecto: Otro Ejemplo B I P E E=B SE E=I SE=B SE=I SE=I+B andand andand oror oror b i p m m m m

103 103 Técnicas Combinatorias Técnica II: 2-wise Partition & Arreglos Ortogonales

104 104 2-Wise Testing y OATS Aplicando 2-wise Testing, se seleccionan casos de test de manera tal de testear las interacciones entre pares de parámetros (factores) independientes de una manera económica Ej.: 75 parámetros de 2 estados c/u se pueden testear con 28 tests! Inputs independientes enumerados Supuesto: errores son de tipo single o double mode. OATS (Orthogonal Array Testing Strategy) Herramientas de Telecordia y Freeware.

105 105 Arreglo Ortogonal: Ejemplo La sintaxis de un comando consiste en 3 posibles parámetros: –Command PARM1, PARM2, PARM3 (enter) PARMx=1, 2, 3 –En teoría un tester debería crear 3 3 =27 combinaciones –En este caso hay 3 factores con 3 niveles cada uno. Entonces, con la técnica de arreglo ortogonal, sólo quedan 9 casos definidos

106 106 Arreglo Ortogonal: Ejemplo Las combinaciones entre 2 parámetros son 9: Una posible solución es la dada en el siguiente arreglo ortogonal –En el arreglo ortogonal las columnas se corresponden con los factores y las filas los casos de test. Las filas representan todas las posibles combinaciones de a pares entre los posibles niveles de los factores

107 107 Arreglo Ortogonal: Ejemplo

108 108 Arreglo Ortogonal (OATS) Factors: Columnas=Parámetros Levels: cantidad de valores posibles para cada columna (e.g.,choices) Strength: Cantidad de columnas tales que las Levels Strenght posibilidades aparecen la misma cantidad de veces Tabulados como: L runs (Levels Factors ) Ej: L 4 (2 3 ): cuatro corridas para cubrir 3 factores con dos elecciones posibles c/u L 18 (3 6 6 1 ): 18 corridas para 7 factores, 6 de 3 niveles y 1 de 6 niveles. Mejor que 216 tests!

109 109 Conclusiones sobre la Generación de Casos Ninguna técnica es completa Las técnicas atacan distintos problemas Lo mejor es combinar varias de estas técnicas para complementar las ventajas de cada una Depende del programa a testear Sin especificaciones de req. todo es mucho más difícil Tener en cuenta la conjetura de defectos Ser sistemático y documentar las suposiciones sobre el comportamiento o el modelo de fallas

110 110 Cobertura: evaluación de la calidad de los Casos de test (I) La especificación de tests cubre la especificación o los requerimientos del sistema? –Tengo requerimientos de Test para cada funcionalidad pedida (ej. Caso de uso)? El conjunto de casos de test cubre la estructura de mi workflow o mi caso de uso? –Para los escenarios normales y las acciones alternativas: Hay datos que ejerciten cada uno de estos flujos? –Todas las actividades y todas las elecciones que hacen cambiar el flujo de trabajo han sido ejercitadas? –Determinemos flujos punta a punta interesantes del workflow y verifiquemos que los estamos cubriendo (testing de sistema)

111 111 Cobertura: evaluación de la calidad de los Casos de test (II) Los casos de tests cubren la combinatoria esperada sobre mi especificación? –Tengo identificadas como categorías o “choices” las condiciones que aparecen en la especificación? –Se dan los cruces que espera un experto en el dominio?. Inspección de Casos de Test Los datos cubren a los casos de test? –La pregunta básica usada para definir cuando un conjunto de datos cubre un conjunto de casos

112 112 Cobertura: evaluación de la calidad de los Casos de test (III) Las ejecuciones cubren el grafo de control o el de flujo de datos siguiendo algún criterio estructural? –Ejecuté todas las instrucciones? –Ejecuté todas las ramas -de los grafos de control de las componentes involucradas- después de mi set de prueba? Los datos cubren estructuralmente la GUI? –Se realizaron eventos relevantes sobre todos los objetos de la GUI? (ej: botones clickeados, combos abiertos e items seleccionados, etc.)

113 113 Cómo Documentar los Casos: Algunas Sugerencias Ordenar las categorías por parámetro, y ordenar los parámetros Poner la categorías de las relaciones P 1 /P 2 después de P 1 y de P 2 Esto sale naturalmente de recorrer el árbol (si usé esa técnica) Describir genéricamente el resultado esperado Al TestDirector o a una planilla Excel. Vincular a los requerimientos de testing (test requirement)

114 Testing Estructural de Unidades

115 115 Representación del flujo de control Secuencia if then elseif then zRepresentamos el flujo de control de un programa a través de un grafo de flujo o flowgraph zProgramas secuenciales, con un único punto de ingreso y un único punto de terminación

116 116 Esta es una representación posible. Existen varias. do while repeat until case, o selección múltiple Representación del flujo de control

117 117 Flowgraph - Ejemplo begin 1:read(x,y) 2:while x  y do 3:if x > y 4:then x := x-y 5:end-if 6:end-while 7: return x 8: end 1 2 3 4 5 6 7 8

118 118 Caminos del flowgraph Un camino en un flowgraph desde el nodo asociado al inicio del programa hasta el nodo asociado a la terminación del programa se llama camino completo Una ejecución del programa que termina satisfactoriamente, está asociada a un camino completo en el flowgraph del programa Cada camino del flowgraph corresponde a una ejecución? Y los caminos completos?

119 119 De caminos a casos de test Dado un camino completo en un flowgraph, ¿cómo obtengo un caso de test que lo fuerce? –A partir de un camino completo, se puede obtener condiciones sobre los inputs para forzar dicho camino ejecución simbólica caso de test

120 120 Caminos no factibles Un camino en un flowgraph para el cual no existe input del programa que fuerce su ejecución, se dice camino no factible –Cada camino factible puede tener muchos inputs asociados que fuercen su ejecución Cuál es el problema de los caminos no factibles?

121 121 Criterios de Testing Estructural Un criterio de testing estructural permite identificar entidades que deben cubrirse con los datos de test para satisfacer el criterio

122 122 Cubrimiento de sentencias o instrucciones Todas las sentencias del programa deben ejercitarse equivale a cubrir todos los nodos del flowgraph

123 123 Flowgraph - Ejemplo 2 begin 1:read(a,b,x) 2:if (a>-1) and (b=0)then 3:x := x/a 4:end if 5:if (a=2) or (x >1) then 6:x := x+1 7: end if 8:end 1 2 3 4 5 6 7 8

124 124 Ejemplo sentencias en el ejemplo, debemos cubrir los nodos 1, 2, 3, 4, 5, 6, 7 y 8 el siguiente camino cubre todos los nodos 1, 2, 3, 4, 5, 6, 7, 8 por ejemplo, con el input siguiente forzamos el camino –Test 0: a=2, b=0, x=1

125 125 Testing estructural - proceso 1- Con el código como base, dibujamos el grafo de flujo de control 2- Determinamos un conjunto de caminos que cumple el criterio 3- Preparamos los datos de test que forzarán la ejecución de cada camino –p.e., usando ejecución simbólica 4- Evaluamos si satisfacemos el criterio 5- Eventualmente, iteramos

126 126 Observaciones El testing basado en código encuentra muchos errores Se ha realizado mucha investigación para determinar qué técnica estructural es la mejor Pero…

127 127 Problemas Cualquier técnica de selección de casos que no está basada en el comportamiento funcional, está mal guiada desde el comienzo –La gente no usa el software para ejecutar sus instrucciones, sino para invocar sus funcionalidades –Es fácil ejecutar todas las instrucciones y sin embargo no invocar ciertas funciones

128 128 Técnicas estructurales como criterio de adecuación Derivar casos de test funcionales Ejecutar tests Fallas? Cubrimiento estructural? Reparar Terminación del testing NO SI NO No usar información estructural

129 129 Cubrimiento de decisiones o Branch Problema: el “else” del “if” no está testeado Todas las decisiones en el control del programa deben ejercitarse al menos una vez por true, y al menos una vez por false branch equivale a cubrir todos los arcos del flowgraph branch implica sentencias

130 130 Ejemplo cubrimiento de decisiones en el ejemplo, debemos cubrir todos los arcos (y en particular, los arcos 2-3, 2-4, 5-6 y 5-7) por ej., con los inputs siguientes –Test1: a=0, b=0, x=0 –Test2: a=-2, b=0, x=2 ejecutamos los siguientes caminos, que cubren todos los arcos –Camino1: 1, 2, 3, 4, 5, 5-7, 7, 8 –Camino2: 1, 2, 2-4, 4, 5, 6, 7, 8

131 131 Problema... Una decisión puede estar compuesta de varias condiciones En el ejemplo, (a>-1) and (b=0) Test1: a=0, b=0, x=0 –condiciones: a>-1, b=0, a  2, x  1 Test2: a=-2, b=0, x=2 –condiciones: a  -1, b=0, a  2, x>1

132 132 Cubrimiento de condiciones Todas las condiciones de todas las decisiones en el control del programa deben ejercitarse al menos una vez por true, y al menos una vez por false

133 133 Condiciones Para satisfacer condiciones hay que ejecutar: (a>-1) (a  -1) (b=0) (b  0) (a=2) (a  2) (x>1) (x  1) Por ejemplo, Test1, Test2 y Test3, donde: Test3: a=2, b=1, x=0 –camino: 1, 2, 4, 5, 6, 7, 8 –condiciones: a>-1, b  0, x  1, a=2 se satisface el criterio condiciones

134 134 Relación entre branch y condiciones Consideramos la guarda If A&B branch: (A & B), (  (A & B)) –puede faltar  A o  B  branch no implica condiciones condiciones: A,  A, B,  B –(A &  B) (  A & B)  condiciones no implica branch ves decir, ninguno garantiza al otro! vLo mismo sucede entre sentencias y condiciones

135 135 Cubrimiento de caminos Todo camino del flujo de control del programa debe ejercitarse al menos una vez equivale a cubrir todos los caminos del flowgraph Es factible? Garantiza algo?

136 136 Criterios estructurales basados en flujo de control Control flow testing sentencias branch decisiones caminos

137 137 Data Flow Testing Motivación Programas = control + data

138 138 Definiciones y Usos una sentencia que guarda un valor en la posición de memoria de una variable, crea una definición una sentencia que trae el valor de la posición de memoria de una variable es un uso de la definición activa de esa variable –un uso de x es un un uso predicado o p-uso si aparece en el predicado de una sentencia que representa una bifurcación de control –en otro caso, se llama uso computacional o c-uso (aparece del lado derecho de una asignación)

139 139 Def-Use flowgraph Dado un programa P y una variable x en P, el def- use flowgraph es el flowgraph de P anotado de la siguiente manera: por cada definición de x, el nodo asociado está etiquetado con una definición de x por cada c-uso, el nodo asociado está etiquetado con un uso de x Por cada p-uso todos los arcos salientes del nodo asociado están etiquetados con un uso de x

140 140 Def-use flowgraph para a Ejemplo begin 1:read(a,b,x) 2:if (a>-1) and (b=0)then 3:x := x/a 4:end if 5:if (a=2) or (x >1) then 6:x := x+1 7: end if 8:end 1 2 3 45 6 7 8 dada uaua uaua uaua uaua uaua

141 141 Def-use flowgraph para b Ejemplo begin 1:read(a,b,x) 2:if (a>-1) and (b=0)then 3:x := x/a 4:end if 5:if (a=2) or (x >1) then 6:x := x+1 7: end if 8:end 1 2 3 45 6 7 8 dbdb ubub ubub

142 142 Def-use flowgraph para x Ejemplo begin 1:read(a,b,x) 2:if (a>-1) and (b=0)then 3:x := x/a 4:end if 5:if (a=2) or (x >1) then 6:x := x+1 7: end if 8:end 1 2 3 45 6 7 8 dxdx u x d x uxux uxux

143 143 DUA ( definition-use association) Una DUA es una terna [d, u, x] tal que la variable x está definida en el nodo d la variable x se usa en el nodo u o en el arco u hay al menos un camino desde d hasta u que no contiene otra definición de x además de la de d (def-clear para x o libre de definiciones para x)

144 144 Ejemplo – DUAS ejemplo 2 [1, 2-3, a] [1, 2-4, a] [1, 3, a] [1, 5-6, a] [1, 5-7, a] [1, 2-3, b] [1, 2-4, b] [1, 3, x] [1, 5-6, x] [1, 5-7, x] [1, 6, x] [3, 5-6, x] [3, 5-7, x] [3, 6, x]

145 145 Criterios estructurales basados en flujo de datos Data flow testing all defs all c-use all p-use all uses all c-use some p-uses all p-uses some c-uses all du-paths

146 146 Cubrimiento All-uses Para cada variable en el programa, deben ejercitarse toda las asociaciones entre cada definición y toda uso de la misma (tal que esa definición esté activa) All-uses equivale a cubrir todas las DUAS del programa

147 147 Ejemplo All-Uses Test 0: a=2, b=0, x=1 –Cubre las DUAS [3, 5-6, x], [3, 6, x] Test1: a=0, b=0, x=0 –Cubre las DUAS [1, 2-3, a], [1, 3, a], [1, 5-7, a], [1, 2- 3, b], [1, 3, x], [3, 5-7, x] Test2: a=-2, b=0, x=2 –Cubre las DUAS [1, 2-4, a], [1, 5-6, a], [1, 2-4, b], [1, 5-6, x], [1, 6, x] Test3: a=2, b=1, x=0 –Cubre las DUAS [1, 2-4, a], [1, 5-6, a], [1, 2-4, b], [1, 5-6, x], [1, 6, x]

148 148 Ejemplo (cont.) Falta cubrir la DUA [1, 5-7, x] Por ejemplo, el test Test 4: a=1, b=1, x=0 cubre esta DUA

149 149 Subsumption en Criterios estructurales Un criterio A subsume a otro criterio B si un conjunto de datos de test T satisface un criterio A, entonces T satisface B Qué relación existe a la hora de encontrar más fallas?

150 Ejecución del testing

151 151 Ejecución del testing  selección de datos dónde testear: ambiente de test terminación del testing documentación reporte y seguimiento de errores test de regresión

152 152 Ejecución del testing selección de datos  dónde testear: ambiente de test terminación del testing documentación reporte y seguimiento de errores test de regresión

153 153 Movimiento de componentes DesarrolloTestingProducción integración, testing del sistema testing de aceptación programación testing de unidades

154 154 Ejecución del testing selección de datos dónde testear: ambiente de test terminación del testing documentación reporte y seguimiento de errores test de regresión

155 155 Terminación del testing  Se terminó el tiempo o recursos  Se corrieron todos los tests derivados sin detectarse ningún error  % de cubrimiento de ciertas técnicas elegidas  Fault-rate más bajo que un cierto valor especificado (# de errores por unidad de tiempo de testing)  Se encontró un número predeterminado de errores (% del número total de errores estimado)

156 156 Ejecución del testing selección de datos dónde testear: ambiente de test terminación del testing  documentación  reporte y seguimiento de errores test de regresión

157 157 Documentos de Casos de test Criterios de derivación de casos empleados Casos de test organizados por –Módulo, sistema, unidad, etc. –Incluyendo el resultado esperado –con referencia al requerimiento que prueban Criterios de terminación del testing Datos de prueba

158 158 Documentos de reporte de ejecución ambiente de test selección de datos –referencia a casos de test que prueban ejecución y resultado obtenido –reporte de errores re-ejecución luego de las modificaciones pertinentes

159 159 Gerenciamiento de errores  Determinación del origen del error  una vez detectado un error, se busca el problema que lo originó haciendo debugging  Clasificación de errores  prioridad  severidad  Seguimiento de errores

160 160 Gerenciamiento de errores  Reparación del software  Testing y testing de regresión  Iterar hasta terminar

161 161 Ejecución del testing selección de datos dónde testear: ambiente de test terminación del testing documentación reporte y seguimiento de errores  test de regresión

162 162 Test de Regresión Tareas de testing luego de que un sistema ha sido modificado –Algunos estudios dicen que la probabilidad de introducir un error al hacer un cambio es entre 50-80% [Hetzel: The complete guide to software testing, QED Info. Sciences, Wellesley, 1984]

163 163 ¿Cuándo hacer test de regresión? Durante el desarrollo de software En tareas de mantenimiento, por –corrección –adaptación a nuevo ambiente –mejora de las prestaciones

164 164 Selección de casos de regresión Casos reusables: corresponden a partes del software no modificadas (ni especificación, ni implementación) Retesteables: la especificación no cambia, pero sí la implementación Obsoletos: no pueden seguir usándose –p.e., test case que especifica una relación I/O incorrecta, por modificación de la especificación

165 165 Bibliografía Beizer: Software Testing Techniques, Van Nostrand Reinhold, 1990. Myers: The art of Software Testing, John Wiley & Sons, 1979. Ghezzi et al.: Fundamentals of Software Engineering, Prentice Hall, 1992. Rapps, Weyuker: Selecting software test data using data flow information, IEEE Trans. on Software Engineering, SE- 11(4):367-375, April 1985. Michal Young, Mauro Pezze: Software Testing and Analysis. 2006.