1 Módulo 8: Testing EstructuralDiseño y Desarrollo de Software Dra. Marcela Capobianco Licenciatura en Ciencias de la Computación - UNS

2 Licencia Copyright © 2010 Marcela CapobiancoSe asegura la libertad para copiar, distribuir y modificar este documento de acuerdo a los términos de la GNU Free Documentation License, Version 1.2 o cualquiera posterior publicada por la Free Software Foundation, sin secciones invariantes ni textos de cubierta delantera o trasera. Una copia de esta licencia está siempre disponible en la página

3 Resumen Las técnicas de prueba intentan establecer una guía sistemática para desarrollar pruebas que: comprueben la lógica de los componentes verifiquen los dominios de entrada y salida del programa El SW se prueba desde 2 perspectivas: pruebas de caja blanca (lógica interna) pruebas de caja negra (requisitos del software)

4 Comportamiento Especificado vs ImplementadoUniverso de comportamientos S P Funcional (black box) Confianza Estructural (white box) Busca defectos

5 Pruebas de caja blanca Las pruebas de caja blanca realizan un examen minucioso de los detalles procedurales Se testean los caminos lógicos del software Problema: es imposible realizar un testeo exhaustivo Importancia: permite testear los caminos lógicos más importantes y las E de D

6 Pruebas de caja blanca Se usa la estructura de control del diseño procedural para derivar los casos de prueba. Objetivos: Garantizar que todos los caminos independientes dentro de un módulo se han seguido Probar todas las deciones lógicas en sus caminos verdadero y falso Ejecutar todos los loops en sus límites Probar las E de D internas

7 ¿Por qué? Los errores lógicos y suposiciones incorrectas son inversamente proporcionales a la probabilidad de que ese camino sea ejecutado Los errores tipográficos son random El testeo de caja negra puede no encontrar estos errores

8 Grafo de programa Dado un programa escrito en un lenguaje imperativo su grafo de programa es un grafo dirigido en el cual los nodos son fragmentos de sentencias y los arcos representan flujo de control Si i y j son notos del grafo, un arco existe de i a j sssi el fragmento que corresponde al nodo j puede ser ejecutado después del corresp al nodo i

9 Grafo de programa

10

11 D-D Paths Decision to Decision Paths [Miller, 1977] Resume las secuencias sin ramificaciones Son una forma de grafo condensado single node con indeg=0 single node con outdeg=0 single node con indeg>1 o outdeg>1 single node con indeg=1 y putdeg=1 cadena maximal con longitud mayor o igual a 1

12 Ejemplo del triángulo

13 Métricas de cubrimientoLa razón de los DD-paths es que permiten especificar en forma precisa el cubrimiento de los casos de test Existen varias métricas universalmente aceptadas Tener una visión del cubrimiento de las pruebas en un programa permite manejar mejor el proceso

14 Observación Para un dado programa pueden existir varios grafos de programa, pero todos convergen a un único D-D path Los D-D permiten una definición precisa de métricas de cubrimiento

15 Algunas métricas Gnode= cada nodo del grafo del programaGedge= cada arco del grafo del programa Gpath= cada camino del ppio al sink

16 Métricas de Miller C0= cada stament del programa C1= cada DD-pathC1P = cada predicado con cada salida posible C2= C1 + loops Cd= C1 + caminos dependientes (data flow testing)

17 Prueba de la condición Ejercita las condiciones lógicas requeridas en el módulo de un programa Detectan los errores en las condiciones del programa (en variables, operadores, etc) Puede además detectar otros errores Existen distintas estrategias: de ramificaciones (V o F) del dominio (cuidado, con n variables 2n)

18 Prueba de bucles Se centra exclusivamente en la validez de las construcciones de bucles Bucles simples Bucles anidados Bucles concatenados Bucles no estructurados

19 Prueba de bucles simplesPasar por alto una pasada dos pasadas m pasos, con m < n n-1, n, n+1 pasos por el bucle valores excluidos >N? N: número máximo de pasos permitidos

20 Prueba de bucles anidadosResulta demasiado si se usa la misma estrategia 5 simple, 25 dos niveles, 125 tres niveles comenzar por el bucle de mas adentro bucle de testeo simple con el bucle de afuera en un valor minimo trabajar hacia afuera todos los bucles de afuera en valores mínimos los otros con valores típicos

21 Prueba de bucles concatenadosSi son independientes se usa el enfoque de los bucles simples Si se usa el controlador del 1 como inicial del 2 se recomienda usar el enfoque de bucles anidados

22 Testeo del camino base Los casos de testing derivados ejecutarán cada instrucción al menos una vez Usa la notación de DD-Graphs Permite derivar una medida de la complejidad lógica del diseño procedural y usarla para definir un conjunto base de caminos

23 Testeo del camino base

24 Notación En un grafo de flujo estilo DD-graph:Los arcos representan el flujo de control Los nodos (círculos) representan una o más acciones Las áreas acotadas por los arcos y nodos se llaman regiones Un nodo predicado contiene una condición Cualquier diseño procedural puede ser transformado en un grafo de flujo

25 Notación nodo 1 1 arco 2 2,3 3 11 4,5 6 R2 6 4 R1 R3 5 7 8 7 8 9 10 9 10 R4 11

26 Ejemplo (costo transporte)public double calculate(int amount) { -1- double rushCharge = 0; -1- if (nextday.equals("yes") ) {-2- rushCharge = 14.50; } -3- double tax = amount * .0725; -3- if (amount >= 1000) { shipcharge = amount * rushCharge; } -5- else if (amount >= 200) { shipcharge = amount * rushCharge; } -7- else if (amount >= 100) { shipcharge = rushCharge; } -9- else if (amount >= 50) { shipcharge = rushCharge; } -11- else if (amount >= 25) { shipcharge = rushCharge; } else { shipcharge = rushCharge; } -14- total = amount + tax + shipcharge; -14- return total; } //end calculate

27 Ejemplo (cont) Observar como se agrupan las acciones consecutivas

28 Complejidad ciclomáticaEs una métrica del software que cuantifica la complejidad lógica Define el nro de caminos independientes del conjunto básico de un programa Nos da un límite superior del nro de pruebas Camino independiente: cualquier camino del programa que introduce un nuevo conjunto de sentencias (nuevo nodo) o una nueva condición (nuevo arco)

29 Ejemplo nodo 1 arco 2,3 4,5 6 R2 R1 R3 7 8 9 10 R4 11

30 Complejidad ciclomáticaEjemplo: Camino 1: 1-11 Camino 2: Camino 3: Camino 4: El camino no es independiente porque no viaja por ningún arco nuevo (es una combinación de caminos ya especificados) Por lo tanto no nos interesa testearlo

31 Complejidad ciclomáticaComo sabemos cuantos caminos debemos buscar? Con la ayuda de la teoría de grafos, el número está dado por la formula: V(G)=A-N+2 La complejidad ciclomática del gráfico anterior es: = 4 ¿Cómo hacemos para obtener los casos de prueba?

32 Ejemplo Ejemplo desarrollado en el pizarrón continuación del ejemplo de costo transporte. Calculamos complejidad ciclomática, caminos independientes y casos de prueba para cubrirlos

33 Obtención de casos de pruebaUsando el código como base calculamos el grafo de flujo Determinamos la complejidad ciclomática del gráfico resultante Determinamos el conjunto básico de caminos independientes Preparamos los casos de prueba que forzarán la ejecución de cada camino del conjunto básico

34 Condiciones complejas

35 Data Flow testing La prueba del camino básico es solo una de las muchas técnicas para la prueba de la estructura de control A continuación analizaremos la técnica conocida como Data Flow Testing

36 Data flow testing Se refiere a formas de testeo estructural que se focalizan en como las variables reciben valores y como estos valores son posteriormente usados Se puede ver como una forma de path testing Veremos dos variantes: Define/use testing Slice-based testing

37 Data flow testing Históricamente los acercamientos a esta técnica se basaron en el siguiente conjunto de fallas: Una variable se define pero no se usa Una variable se usa sin definirse Una variable se define dos veces antes de ser usada ¿Qué tipo de análisis es suficiente para encontrar estas fallas?

38 Define/use testing Supongamos que contamos con un programa P, G(P) su grafo y un conjunto de variables V de P n es un defining node para v, DEF(v,n) si el fragmento corresp a n cambia el valor de v Ejemplos?

39 Define/use testing n es un usage node para v, USE(v,n) si el fragmento corresp a n usa el valor de v Las memory locations asociadas con v deben permanecer como estaban antes de la ejecución (sin cambios) Ejemplos?

40 Cadena de definición-usoUna (sub)cadena de definición-uso con respecto a una variable v (notado du-path) es un (sub)camino en PATHS(P) tal que para algún v en V existen nodos DEF(v,n) y USE(v,m) tal que m y n son los nodos iniciales y finales del (sub) camino

41 Cadena de definición limpiaUna (sub)cadena de definición limpia con respecto a una variable v (notado dc-path) es una cadena de definició-uso en PATHS(P) con nodos iniciales y finales DEF(v,n) y USE(v,m) tal que ningún otro nodo en la (sub)cadena es un nodo de definición de v.

42 Ejemplo Desarrollado en el pizarrón, commision problem, pág 124 del libro de Jorgensen

43 Métricas (Rapps-Weyuker)Algunas son equivalentes a las anteriores (all edges – all nodes – all paths) T es un cojunto de (sub)cadenas en el grafo G(P) con el conjunto de variables V: T satisface All-Defs iff para cada variable v de V T contiene cadenas limpias de cada nodos de definición de v a un uso de v T satisface All-Uses iff para cada variable v de V T contiene cadenas limpias de cada nodos de definición de v a cada nodo de uso de v y a su sucesor

44 Métricas (Rapps-Weyuker)T satisface All P-uses/some C-uses iff para cada variable v de V T contiene cadenas limpias de cada nodos de definición de v a cada nodo de uso predicativo de v, y si una definición no tiene P- uses existe un camino limpia hasta al menos un nodo de C-use

45 Métricas (Rapps-Weyuker): relacionesAll paths All-uses All-P-uses/some C-uses All-Defs All-P-uses All-Edges All-Nodes

46 Slice-based testing Slice: Dado un programa P y G(P) su grafo correspondiente tal que los staments están numerados y un conjunto V de variables de P el slice del conjunto de variables V en en fragmento n, S(V,n), es el conjunto de números de nodos de todos los fragmentos de P previos a n que contribuyen a los valores de las variables de V en n

47 Slices (idea) Separar el programa en componentes que tienen un significado útil para un fin Para saber que significa contribuir definimos tipos de USO y DEFS: P-use: usado en un precidado C-use: usado en computos O-use: usado para salida L-use: usado para locaciones (punteros, etc) I-use: iteraciones, loop indices I-def: definido por entrada A-def: definido por asignaciones

48 Salesman read/written correcltyEjemplo Para el comission problem: S1: S(salesman,17) = {17} S2: S(salesman,18) = {17} S4: S(locks,22) = {22} S5: S(locks,23) = {22,23,24,29,30} S6: S(locks,29) = {29} Salesman read/written correclty Locks read correctly Sentinel correct

49 Slices Cuando nos concentramos en slices interesantes podemos descartar partes que no nos interesan No podemos hacer esto con los du-paths Existe un conjunto de recomendaciones que conviene seguir

50 Slices: recomendacionesNo hacer un slice S(V,n) para el cual las variables v en V no figuran en el fragmento n Hacerlos sólo sobre una variable Hacer slices para todos los nodos A-def Hacer slices para P-use nodes Cuidado: los slices no se mapean directamente en test-cases