Criterios cobertura de grafos: especificaciones

Presentación del tema: "Criterios cobertura de grafos: especificaciones"— Transcripción de la presentación:

1 Criterios cobertura de grafos: especificaciones
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)

2 Especificaciones de diseño
Describen aspectos sobre qué debería hacer el software. También se llaman modelos. Una especificación puede (o no) reflejar la implementación. De hecho, debemos verlo al revés: una implementación puede no reflejar exactamente lo que indica la especificación. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

3 Especificaciones de diseño
Veremos dos tipos de especificaciones: Restricciones sobre secuencias entre clases. Descripciones, basadas en estados, del software. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

4 Restricciones sobre secuencias
Son reglas que imponen restricciones sobre el orden en el que se puede llamar a los distintos métodos. Se pueden usar como precondiciones de otras especificaciones. Recordemos que existen clases con métodos que no se llaman entre ellos (pilas con operaciones push, pop, y isEmpty). Para estas clases, un test puede ser una secuencia de llamadas a métodos. Finalmente, comentar que estas restricciones dan una forma fácil y efectiva para elegir las secuencia que se deben usar. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

5 Restricciones sobre secuencias
Estas restricciones pueden estar expresadas explícitamente, implícitamente, o que no lo estén de ninguna forma. Si no existen, los testeadores las deberían derivar a partir de los documentos de diseño, de los documentos de los requisitos, preguntando a los desarrolladores o, última opción, mirando a la implementación. De hecho, si no existen es muy probable que haya más defectos (faults). Es deseable que las restricciones se compartan con los diseñadores antes de diseñar los test. Esta técnica tiene limitaciones: las restricciones no capturan, habitualmente, todo el comportamiento. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

6 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Ejemplo: colas public int deQueue() { // Pre: la cola tiene al menos un elemento … … public enQueue (int e) { // Post: e está al final de la cola. Restricciones aparecen ímplicitamente en pre/postcondiciones. Por ejemplo, hay que llamar a enQueue () antes que a deQueue (). No incluyen el requisito “debe haber al menos tantas llamadas a enQueue () como a deQueue (). Este requisito lo podemos tener en cuenta usan técnicas basadas en estados. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

7 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Ejemplo: TAD Fichero La clase FicheroTAD tiene tres métodos: open (String fName) // Abre un fichero con nombre fName close () // Cierra el fichero y lo deja inaccesible write (String textLine) // Escribe una línea de texto en el fichero. Secuencias de restricciones válidas en FicheroTAD open (f) se debe ejecutar antes de cada write (t). open (f) se debe ejecutar antes de cada close (). write (t) no se puede ejecutar tras close () a menos que haya un open (f) entre medias. Un write (t) se debería ejecutar antes de cada close (). 1 2 3 4 5 6 open (f) write(t) write (t) close () Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

8 TAD Fichero: check estático
¿Existen caminos que violan las restricciones de secuencia? ¿Hay un camino que llega a write (t) pero que no pasa por open (f)? ¿Hay un camino que llega a close () pero que no pasa por open (f)? ¿Hay un camino de un close () a un write (t)? ¿Hay un camino de un open (f) a close () que no pase por un write (t)? 1 2 3 4 5 6 open (f) write(t) write (t) close () [1, 3, 4, 6] representa un uso incorrecto. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

9 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
TAD Fichero: RT [1, 3, 4, 6] representa un uso incorrecto pero es posible que la lógica del programa no permita los pares de aristas [1, 3, 4]. En otras palabras, el bucle se tiene que ejecutar al menos una vez. Determinar si esto se cumple es indecidible. Por tanto, los métodos estáticos no son suficientes. Debemos usar las restricciones sobre secuencias para generar requisitos de testing. El objetivo es violar cada restricción sobre secuencias. 1 2 3 4 5 6 open (f) write(t) write (t) close () Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

10 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
TAD Fichero: RT Se deberán aplicar a todos los programas que usen el TAD Fichero. Cubrir todos los caminos desde el nodo inicial a todos los nodos write() de forma que el camino no pase por open(). Cubrir todos los caminos desde el nodo inicial a todos los nodos close() de forma que el camino no pase por open(). Cubrir todos los caminos desde cualquier nodo close() hasta cualquier nodo write(). Cubrir todos los caminos desde cualquier nodo open() hasta cualquier nodo close() tal que el camino no pase por un nodo write(). Si el programa es correcto, todos los requisitos serán irrealizables. Cualquier test que se cree encontrará faults casi con toda seguridad. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

11 Testing del comportamiento de estados
Una máquina de estados finitos (FSM) es un grafo que describe como las variables del software se modifican durante su ejecución. Nodos: Estados, representan conjuntos de valores de variables relevantes. Aristas: Transiciones, posibles cambios en el estado. Off On switch up switch down Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

12 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
FSMs: introducción Las FSMs pueden modelar con precisión muchos tipos de software. Software empotrado y de control. Tipos Abstractos de Datos. Compiladores y Sistemas Operativos. Aplicaciones web. Crear FSMs puede ayudar a encontrar problemas en el software. Hay numerosos lenguajes y formalismos para expresar FSMs: UML Statecharts, autómatas, Redes de Petri, etc. Limitaciones: FSMs no son muy útiles para programas que tienen muchos estados (por ejemplo, GUIs). Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

13 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
FSMs: anotaciones Las FSMs se pueden anotar con distintos tipos de acciones: acciones sobre transiciones, acciones de entrada a los nodos, acciones de salida en los nodos. Las acciones pueden expresar cambios en las variables o condiciones sobre estas variables. En este curso solo usaremos: Precondiciones (guardas): condiciones que deben cumplirse para ejecutar las transiciones. Triggers: Cambios a las variables que hacen que se ejecuten las transiciones. Esta visión es cercana a UML Statecharts (pero no exactamente igual). Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

14 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Ejemplo: anotaciones Abrir puerta ascensor Cerrada Abierta pre: ascVeloc = 0 trigger: abrirBotón = pulsado Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

15 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Cobertura de FSMs Cobertura de nodos: Ejecutar cada estado (cobertura de estados). Cobertura de aristas: Ejecutar cada transición (cobertura de transiciones). Cobertura de pares de aristas: Ejecutar todo par de transiciones (cobertura de pares de transiciones). Generar FSMs es, usualmente, más difícil que realizar su cobertura. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

16 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Derivando FSMs En algunos proyectos se crean FSMs durante el diseño. En estos casos, el testeador debe comprobar que la FSM todavía representa un modelo de la implementación. En caso contrario, el testeador debería derivar la FSM. Estrategias para derivar FSMs a partir de un programa: Combinar grafos de control de flujo (mala idea). Usar la estructura del software (mala idea). Modelar variables de estado. No vamos a entrar en más detalles (simplemente nos quedamos con la idea de que debemos centrarnos en las variables, no en la estructura). Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

17 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
FSMs de orden superior S2 S1 S3 a b c Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

18 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
FSMs: pros y contras Dos ventajas: Los tests se pueden diseñar antes de la implementación. Analizar FSMs es mucho más sencillo que analizar el código. Tres desventajas: Algunas decisiones de implementación no se modelan en las FSMs. Hay variaciones en los resultados debido a la naturaleza subjetiva de derivar FSMs. Los tests se tienen que convertir en inputs del programa. Los nombres que aparecen en la FSM pueden ser distintos de los que aparecen en el programa. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)