Criterios cobertura de grafos: casos de uso Manuel Núñez Especificación, Validación y Testing Estas transparencias están basadas en las desarrolladas por Ammann & Offutt como acompañamiento de su libro Introduction to Software Testing (2nd Edition)

Especificación, Validación y Testing (M. G. Merayo y M. Núñez) Casos de uso en UML Los casos de uso de UML suelen representar requisitos software. Ayudan a expresar el flujo de trabajo de la aplicación. No vamos a ver casos de uso en detalle. Solo veremos algún ejemplo. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Ejemplo sencillo: caso de uso Actores: Humanos o componentes software que usan el software que se está modelando. Casos de uso: Círculos u óvalos. Cobertura de nodos: usar cada caso de uso una vez. Sacar fondos Ver saldo Transferir fondos Usuario Cajero Sin embargo, los casos de uso, por si mismos, no son útiles para testing. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Elaboración del caso de uso Nombre del caso de uso: Sacar fondos. Resumen: Cliente usa una tarjeta válida para sacar fondos de una cuenta válida. Actor: Cliente de cajero. Precondición: El cajero muestra un mensaje de “bienvenida”. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Elaboración del caso de uso Descripción: El cliente inserta una tarjeta en el lector del cajero. Si el sistema reconoce la tarjeta, entonces lee su número. El sistema le dice al cliente que ponga el PIN. El cliente pone el PIN. El sistema comprueba fecha de caducidad y si tarjeta robada/perdida. Si la tarjeta es válida entonces el sistema comprueba si PIN es correcto. Si el PIN es correcto, el sistema busca la cuenta que se puede acceder. El sistema muestra las cuentas disponibles y solicita tipo de operación. Hay tres tipos: retirada, saldo, transferencia. …… Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Elaboración del caso de uso Descripción(continuación, retirada de fondos): Los 8 pasos anteriores son comunes a las 3 operaciones. El cliente selecciona retirada de fondos, una de sus cuentas y una cantidad. El sistema comprueba que la cuenta es válida, comprueba que el cliente tiene fondos suficientes, que no se ha pasado del límite diario y que el cajero dispone de fondos. Si todas las comprobaciones son correctas, el cajero da el dinero. El sistema imprime un recibo con un número de transacción, el tipo de transacción, la cantidad retirada, y el nuevo saldo de la cuenta. El sistema devuelve la tarjeta. El sistema muestra un mensaje de “bienvenida”. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Elaboración del caso de uso Alternativas: Si el sistema no reconoce la tarjeta, la devuelve y muestra “bienvenido”. Si fecha es superior a caducidad, se confisca y muestra “bienvenido”. Si tarjeta robada/perdida, se confisca y muestra “bienvenido”. Si PIN incorrecto, sistema pide PIN de nuevo. Si PIN incorrecto tres veces, tarjeta se confisca y muestra “bienvenido”. …. Postcondición: Los fondos han sido retirados de la cuenta del cliente. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Especificación, Validación y Testing (M. G. Merayo y M. Núñez) Hmmm, espera un minuto…. ¿Qué tiene todo esto que ver con testing? Específicamente, ¿qué tiene que ver con grafos? Se supone que tenemos que buscar un grafo y cubrirlo. En la literatura existen los “Grafos de flujos de transacciones”. UML tiene algo similar: diagramas de actividad. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Casos de uso a diagramas de actividad Diagramas de actividad indican flujo entre actividades. Las actividades deberían modelar pasos a nivel de usuario. Dos tipos de nodos: acción y ramas secuenciales. Las descripciones del caso de uso se convierten en nodos de acción en el diagrama de actividad. Las alternativas son nodos de ramas secuenciales. Flujo entre pasos son aristas. Los diagramas de actividad tienen, habitualmente, características muy útiles: pocos bucles y predicados simples. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Especificación, Validación y Testing (M. G. Merayo y M. Núñez) Diagrama de actividad Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Cobertura de diagramas de actividad Cobertura de nodos: Los inputs se derivan de las etiquetas de los nodos y predicados. Se usan para generar valores para los tests. Cobertura de aristas Escenarios de testing: camino completo que atraviesa el diagrama. Deberían tener un significado claro y preciso para los usuarios. Usualmente, hay un número finito de caminos; en caso contrario, los escenarios se definen a partir del conocimiento del dominio. Se puede usar Specified Path Coverage, donde caminos = escenarios. Recordemos que SPC no subsume a cobertura de aristas, pero los escenarios deberían definirse de forma que, en este caso, lo hace. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Resumen testing casos de uso Los casos de uso se definen al nivel de requisitos. Pueden ser de muy alto nivel. Los diagramas de actividad de UML codifican casos de uso como grafos. Estos grafos suelen tener una estructura simple. Testing basado en requisitos puede usar cobertura de grafos. Fácil de hacer a mano. Specified path coverage tiene sentido en estos grafos. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)