Tema I Testing Estructurado 4ta Parte Verificación y Validación de Software UNS Contenido Testing de Unidad: Caja Negra Grafos Causa Efecto Clases de Equivalencia Valores Límite Verificación y Validación de Software UNS 2
Testing de Unidad: Caja Negra Lectura Ghezzi, C., et.al. Fundamentals of Software Engineering. Prentice Hall, 99. [Cap. 6] White Lee, General Overview of Software Testing. Artículos Scuola estiva Software Testing Metodi e Tecniche, Italia, 993. Verificación y Validación de Software UNS 3 Testing de Módulos: Caja Negra () No tiene en cuenta la estructura El sistema se ve como una caja negra con entradas y con salidas Sólo nos importa que la salida sea correcta para unas entradas predefinidas Se comprueba la respuesta conforme a la especificación Verificación y Validación de Software UNS 4
Testing de Módulos: Caja Negra (2) Es impracticable probar el software para todas las posibilidades De nuevo hay que tener criterios para elegir buenos casos de prueba Permite descubrir la omisión de implementación de un camino de control Especificación Formal vs. Informal Verificación y Validación de Software UNS 5 Testing de Módulos: Caja Negra (3) Problema del Oráculo Para muchos problemas no es posible determinar a priori el resultado de la ejecución de un programa => no existen datos de test para comparar Es necesario contar con un Oráculo de Testing, para chequear correctitud de las salidas de los tests. El Oráculo puede asumir la forma de una tabla de valores, algoritmos para ejecutar manualmente, fórmulas en el cálculo de predicados. Verificación y Validación de Software UNS 6
Testing de Módulos: Caja Negra (4) Un caso de prueba funcional es bien elegido si se cumple que: Reduce el número de otros casos necesarios para que la prueba sea razonable Esto implica que el caso ejecute el máximo número de posibilidades de entrada diferentes para así reducir el total de casos Verificación y Validación de Software UNS 7 Testing de Módulos: Caja Negra (5) Proceso de Testing de Caja Negra: Descomponer una especificación en un conjunto de casos relevantes Producir para cada caso uno o más datos de test La descomposición es por pasos, basada en la identificación de condiciones y la derivación de casos Verificación y Validación de Software UNS 8
Testing de Módulos: Caja Negra (6) Existen diversas técnicas: Grafos Causa-Efecto/Tablas de Decisión Clases de Equivalencia Valores Límites Verificación y Validación de Software UNS 9 Caja Negra: Grafos Causa Efecto () Solo debemos conocer los operadores booleanos OR AND IF A = OR B = THEN C = IF A = AND B = THEN C = Explora las circunstancias donde se dan combinaciones de las entradas Verificación y Validación de Software UNS
Caja Negra: Grafos Causa Efecto (2) Solo debemos conocer los operadores booleanos IDENTITY NOT IF A = THEN B = IF A = THEN B = ELSE B = Verificación y Validación de Software UNS Caja Negra: Grafos Causa Efecto (3) Desarrollando los Grafos, Tablas y Casos de Test. Dividir la especificación en piezas que sean trabajables. No intentar crear un simple grafo para toda la especificación 2. Identificar Causas y Efectos: Una causa es una única condición de entrada Un efecto es una condición de salida o transformación del sistema 3. Traducir las relaciones semánticas en cada segmento en relaciones booleanas enlazando causas con efectos. Es decir, construir los grafos Verificación y Validación de Software UNS 2
Caja Negra: Grafos Causa Efecto (4) 4. Colocar las restricciones que se aplican a las causas y efectos Restricciones sobre las Causas Exclusiva Inclusiva A lo sumo uno es TRUE. A= THEN B=; B= THEN A=. Pueden ser ambos Al menos uno es TRUE. No pueden ser todos FALSE Verificación y Validación de Software UNS 3 Caja Negra: Grafos Causa Efecto (7) Restricciones sobre las Causas Requiere Una y solo una A es TRUE entonces B debe ser TRUE. Si A= THEN B= Solo una puede ser TRUE. No pueden ser ambas FALSE ni ambas TRUE. Restricciones sobre los Efectos Mascaras Si el efecto A es TRUE (A=) entonces el efecto B debe ser FALSE (B=) Verificación y Validación de Software UNS 4
Caja Negra: Grafos Causa Efecto (8) Desarrollando los Grafos, Tablas y Casos de Test 5. Crear una Tabla de Decisión resumiendo todas las posibles combinaciones de estados Las Causas son las entradas Los Efectos son las salidas Las Columnas son los casos de prueba 6. Dividir las entradas de la tabla en reglas, una por cada combinación única de estados en el grafo. Verificación y Validación de Software UNS 5 Caja Negra: Grafos Causa Efecto (9) Desarrollando los Grafos, Tablas y Casos de Test Indicar cuales combinación de estados están asociados con los efectos colocando una X (o un ) en la columna que representa esa combinación estadocondición. Convertir cada columna (regla) de la tabla de decisión en un caso de test Verificación y Validación de Software UNS 6
Caja Negra: Grafos Causa Efecto () Ejemplo: Requerimientos para calcular primas en seguros de autos : Para mujeres de menos de 65 años, la prima es de $5 Para hombres de menos de 25 años, la prima es de $3 Para hombres entre 25 y 64 años, la prima es de $ Para cualquiera de mas de 65 años, la prima es de $5 Verificación y Validación de Software UNS 7 Caja Negra: Grafos Causa Efecto () Ejemplo: Pasos -2 Causas (condiciones de entrada). Sexo masculino 2. Sexo femenino 3. Edad < 25 4. Edad >=25 y < 65 5. Edad >= 65 Efectos (condiciones de salida). Prima = $. Prima = $3 2. Prima = $5 3. Prima = $5 Verificación y Validación de Software UNS 8
Caja Negra: Grafos Causa Efecto (2) Ejemplo: Paso 3 Causas: (Sexo masculino) AND 4 (Edad >=25 y < 65) Efecto: (Prima = $) 2 Causas:. (Sexo masculino) AND 3 (Edad <25) Efecto: (Prima = $3) Verificación y Validación de Software UNS 9 Caja Negra: Grafos Causa Efecto (2) Ejemplo: Paso 3 3 Causas: ( AND 5 (Edad >= 65)) OR (2 (Sexo femenino) AND 5) Efecto: 2 (Prima = $5 4 Causas: (2 AND 3 (Edad <25) OR (2 AND 4 (Edad >=25 y < 65) Efecto: 3 (Prima = $5) Verificación y Validación de Software UNS 2
Caja Negra: Grafos Causa Efecto (3) Ejemplo: Paso 4 Colocamos una restricción de una y solo una porque el sexo puede ser femenino o masculino pero no ambas 3 Verificación y Validación de Software UNS 2 Caja Negra: Grafos Causa Efecto (4) Ejemplo: Pasos 5-75 grafo 3 grafo 4 Casos de Test 2 3 4 5 6 Causas (masculino) 2 (femenino) 3 (<25) 4 (>=25 y <65) 5 (>=65) Efectos ($) ($3) 2 ($5) 3 ($5) Verificación y Validación de Software UNS 22
Caja Negra: Grafos Causa Efecto (5) Casos de Test Ejemplo: Paso 8 Entradas (Causas) Salidas Esperadas (Efectos) Sexo Edad Masculino <25 $3 2 Masculino >=25 y <65 $ 3 Masculino >=65 $5 4 Femenino >=65 $5 5 Femenino <25 $5 6 Femenino >=25 y <65 $5 Verificación y Validación de Software UNS 23 Caja Negra: Clases de Equivalencia () Se utilizan para reducir el número de tests sin reducir su cobertura La metodología a a seguir es: Identificar todas las entradas posibles a la unidad que se está testeando. Particionar el universo de las entradas en Clases Definir Cláses Válidas: aquellas que son las entradas esperadas Definir Clases Inválidas: aquellas que no cumplen los requisitos Escoger unos datos representativos de cada clase y probar sólo con esos datos Comprobar que la salida se corresponde con la entrada. Verificación y Validación de Software UNS 24
Caja Negra: Clases de Equivalencia (2) Ejemplo: Entrada: Código de entre uno y tres caracteres ASCII como máximo Particiones: Cadenas de uno a tres carácteres. Ej. CR Entradas inválidas: Cadenas de cuatro o más caracteres. Ej. FGTRY Cadena nula: null Test representativos a pasar a la unidad: CR, FGTRY, null. Verificación y Validación de Software UNS 25 Caja Negra: Clases de Equivalencia (3) Identificación de las Clases de Equivalencia: Rango de valores una clase equivalente válida dos clases inválidas Número de valores una clase equivalente válida dos clases inválidas Conjunto de valores de entradas, manejados en forma diferente por el programa uno válido y otro inválido Debe ser uno válido y otro inválido Verificación y Validación de Software UNS 26
Caja Negra: Valores Límites () Se testean las unidades considerando los valores límites l de sus entradas y salidas. Puede considerarse como un caso especial de las Clases de Equivalencia eligiendo como valores los límites de las distintas clases. Verificación y Validación de Software UNS 27 Caja Negra: Valores Límites (2) Los límites son más propensos a los errores tanto en la especificación como en el propio código. A menudo no se especifica la manera de interactuar con esos valores. Codificando no los tenemos en cuenta: if a>... if a<... Si a= que hacemos? Verificación y Validación de Software UNS 28
Caja Negra: Valores Límites (3) Ejemplos de valores que hay que testear: Máximos valores tanto negativos como positivos de los valores numéricos de entrada y salida así como el valor cero. Cadenas nulas, de un caracter, del límite máximo de las cadenas tanto de salida como de entrada. Archivos vacíos o con un solo caracter Para un rango de valores entre x e y (x-), x, (x+) (y-), y, (y+) Para n elementos, probar con n-, n y n+ elementos x Verificación y Validación de Software UNS 29 y Caja Negra: Valores Límites (4) Ejemplo: Entrada: Código de entre uno y tres caracteres ASCII como máximo Particiones: Cadenas de un caracter. Ej. A Cadenas de tres caracteres. Ej. DNI Entradas inválidas: Cadenas de cuatro caracteres. Ej. TOMA Cadena nula: null Test representativos a pasar a la unidad: A, DNI, TOMA, null Verificación y Validación de Software UNS 3