Manuel Núñez Especificación, Validación y Testing

Presentación del tema: "Manuel Núñez Especificación, Validación y Testing"— Transcripción de la presentación:

1 Manuel Núñez Especificación, Validación y Testing
Cobertura lógica 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 Cuatro estructuras para modelar software
Grafos Lógica Espacio de Inputs Sintaxis Casos de uso Especs Diseño Código Aplicado a FND Especs FSMs Código Aplicado a Input Modelos Integra Código Aplicado a Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

3 Cobertura lógica (semántica)
US Federal Aviation Administration requiere cobertura de expresiones lógicas para safety critical software. Las expresiones lógicas puede surgir de muchos lugares Decisiones en los programas. FSMs y statecharts. Requisitos. Los tests deben elegir un subconjunto del total de combinaciones de valores de verdad que pueden tomar las expresiones. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

4 Predicados y cláusulas
Un predicado es una expresión que se evalúa a un valor booleano. Los predicados pueden incluir: Variables booleanas. Variables no-booleanas combinadas con operadores (< , ==, !=, …). Llamadas a funciones que devuelven un booleano. La estructura interna se crea mediante operadores lógicos (¬ , , , , ,  ). Una cláusula es un predicado sin operadores lógicos. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

5 Datos sobre predicados
La mayoría de los predicados tiene un número pequeño de cláusulas. 88,5% tiene una cláusula. 9,5% tiene dos cláusulas. 1.35% tiene tres cláusulas. 0.65% tiene cuatro o más. Procedencia de los predicados. Decisiones en programas. Guardas de FSMs. Decisiones en los diagramas de actividad de UML. Requisitos (tanto formales como informales). Queries de SQL. Datos obtenidos a partir del estudio de 63 programas de código abierto con más de 400,000 predicados. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

6 Traducción de lenguaje natural
¡¡Cuidado!! Me gusta el Amarone della Valpolicella y el Châteauneuf-du-Pape. Por tanto, bebida = Amarone O bebida = CdP. Menú del día: De primero tenemos A, B o C. Manolo dice: “si, deme los 3”. Si sales antes de las 8:30 toma la línea 1 pero si sales después de las 9 toma la línea 2. (hora < 8:30  línea =1)  (hora > 9:00  línea =2) Hmmm, ¡pero esto es incompleto! (hora < 8:30  línea =1)  (hora > = 8:30  línea =2) Algunas veces “y de lenguaje natural” es “o lógico”. Algunas veces “o de lenguaje natural” es “xor lógico”. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

7 Criterios de cobertura lógica
Utilizamos predicados en testing para: Desarrollar un modelo del software mediante uno o más predicados. Requerir que los tests satisfagan alguna combinación de cláusulas. Abreviaturas: P es un conjunto de predicados. p es un predicado. C es el conjunto de cláusulas de P. Cp es el conjunto de cláusulas del predicado p. c es una cláusula de C. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

8 Cobertura de predicados y cláusulas
Los dos primeros criterios requieren que cada predicado/cláusula se evalúe a true y false. Cuando los predicados provienen de las condiciones en las ramas del software entonces este criterio coincide con cobertura de aristas. Teniendo en cuenta que PC no evalúa todas las cláusulas…. Predicate Coverage (PC) : Para cada p de P, RT contiene dos requisitos: p evalúa a true y p evalúa a false. Clause Coverage (CC) : Para cada c de C, RT contiene dos requisitos: c evalúa a true y c evalúa a false. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

9 Ejemplo de cobertura de predicados
((a < b)  D)  (m >= n*o) Predicado = true a = 5, b = 10, D = true, m = 1, n = 1, o = 1 = ((5 < 10)  true)  (1 >= 1*1) = (true  true)  true = true Predicado = false a = 10, b = 5, D = false, m = 1, n = 1, o = 1 = ((10 < 5)  false)  (1 >= 1*1) = (false  false)  true = false Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

10 Ejemplo de cobertura de cláusulas
((a < b)  D)  (m >= n*o) (a < b) = true a = 5, b = 10 (a < b) = false a = 10, b = 5 D = true D = false Casos true 1) a = 5, b = 10, D = true, m = 1, n = 1, o =1 Casos false 2) a = 10, b = 5, D = false, m = 1, n = 2, o = 2 m >= n*o = true m = 1, n = 1, o = 1 m >= n*o = false m = 1, n = 2, o = 2 Dos tests Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

11 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Deficiencias de PC y CC PC no considera completamente todas las cláusulas, especialmente si tenemos evaluación cortocircuitada. CC no siempre implica PC: Se puede satisfacer CC sin que el predicado tome los dos valores (true y false). La solución más simple para resolver estos problemas consiste en considerar todas las combinaciones. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

12 Cobertura combinatoria
Combinatorial Coverage (CoC) : Para cada p de P, RT contiene requisitos para las cláusulas de Cp que los evalúan a todas las posibles combinaciones de valores de verdad. a < b D m >= n*o ((a < b)  D)  (m >= n*o) 1 T 2 F 3 4 5 6 7 8 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

13 Cobertura combinatoria
CoC es simple, elegante, limpio, completo…. Pero muy costoso: 2N tests, siendo N el número de cláusulas. Es impráctico para situaciones con más de 3 o 4 cláusulas. Para solventar este problema, muchas propuestas sugieren, de una u otra forma, testear cada cláusula independientemente de las demás. Sin embargo, existen problemas adicionales: ¿Qué quiere decir independientemente? El libro de bibliografía básica propone la idea de utilizar cláusulas activas. 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)
Cláusulas activas Cobertura de cláusulas presenta una debilidad: Los valores no siempre dan lugar a una diferencia. Consideremos el primer test del ejemplo de CC que daba true a cada cláusula: ((5 < 10)  true)  (1 >= 1*1). Solo la primera cláusula es útil. Para testear de forma efectiva el resultado de una cláusula, ésta debería ser un factor determinante en el valor del predicado. Esto es lo que se considera hacer una cláusula activa. Determinación : Una cláusula ci del predicado p, llamada cláusula principal, determina p sii los valores de las demás cláusulas cj, llamadas secundarias, son tales que cambiar el valor de ci cambia el valor de p. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

15 Predicados determinantes
P = A  B Si B = true, entonces p es true. Por tanto, si B = false, entonces A determina p. Si A = false entonces B determina p. P = A  B Si B = false, entonces p es false. Por tanto, si B = true, entonces A determina p. Si A = true, entonces B determina p. Objetivo: Encontrar tests para cada cláusula que determine el valor del predicado. Esta idea se formaliza mediante una familia de criterios que tiene diferencias sutiles pero muy importantes. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

16 Cobertura de cláusulas activas
Active Clause Coverage (ACC) : Para cada p de P y cada cláusula principal ci de Cp, elíjanse cláusulas secundarias cj, , para j != i, tales que ci determina p. RT contiene dos requisitos para cada ci : ci evalúa a true y ci evalúa a false. p = a  b a = true, b = false a = false, b = false a = false, b = true a is principal b is principal Duplicado Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

17 Cobertura de cláusulas activas
Este criterio de cobertura subyace a modified condition/decision coverage (MC/DC), criterio que se usa en aviación y que consiste en: Se pasa por cada punto de entrada y de salida. Cada predicado toma todos los posibles valores. Cada cláusula de cada predicado toma todos los posibles valores. Se muestra que cada cláusula de cada predicado afecta al resultado de la evaluación de dicho predicado. CoC presenta una ambigüedad: ¿Las cláusulas secundarias tienen que tener los mismos valores al considerar que la principal vale true y que vale false? Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

18 Resolviendo la ambigüedad
p = a  (b  c) Cláusula principal : a a = true, b = false, c = true a = false, b = false, c = false c = false ¿Está permitido este cambio? Esta pregunta ha causado mucha confusión entre los testeadores. Podemos considerar tres criterios distintos basados en esta pregunta: Cláusulas secundarias no necesitan ser la misma. Cláusulas secundarias deben ser la misma. Cláusulas secundarias fuerzan a que el predicado evalúe a true para un valor de la cláusula principal y a false para el otro. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

19 Resolviendo la ambigüedad
Cláusulas secundarias no necesitan ser la misma: Es posible tener GACC sin tener cobertura de predicados…. Mal criterio. General Active Clause Coverage (GACC) : Definición formal (Ammann & Offutt: Introduction to Software Testing (2nd Edition) Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

20 Resolviendo la ambigüedad
Cláusulas secundarias deben ser la misma. Esta ha sido una interpretación habitual para los desarrolladores de sistemas para aviación. El problema es que, frecuentemente, da lugar a requisitos de test imposibles. Además, no hay una razón lógica para pedir esta restricción (que no cambien las cláusulas secundarias al valer la principal true o false). Restricted Active Clause Coverage (RACC) : Definición formal (Ammann & Offutt: Introduction to Software Testing (2nd Edition) Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

21 Resolviendo la ambigüedad
Cláusulas secundarias fuerzan a que el predicado evalúe a true para un valor de la cláusula principal y a false para el otro. Esta es una interpretación más reciente. Implícitamente permite que las cláusulas secundarias tomen valores distintos. Explícitamente subsume cobertura de predicados. Correlated Active Clause Coverage (RACC) : Definición formal (Ammann & Offutt: Introduction to Software Testing (2nd Edition) Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

22 Cobertura de cláusulas inactivas
Los criterios basados en la cobertura de cláusulas activas aseguran que las cláusulas primarias afectan a los predicados. La cobertura de cláusulas inactivas toma la dirección contraria: las cláusulas principales no afectan a los predicados. Existen criterios duales a los que se ven en activas: General Inactive Clause Coverage (GICC) Restricted Inactive Clause Coverage (RICC) A diferencia de lo que ocurre en las coberturas activas, en este caso siempre se garantiza la cobertura de predicados. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

23 Subsunción de criterios lógicos
Clause Coverage CC Predicate Coverage PC Combinatorial Clause Coverage COC Restricted Active Clause Coverage RACC Restricted Inactive Clause Coverage RICC General Active Clause Coverage GACC Correlated Active Clause Coverage CACC General Inactive Clause Coverage GICC Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

24 Inviabilidad de los requisitos
Consideremos el predicado: (a > b  b > c)  c > a Tenemos que (a > b) = true, (b > c) = true, (c > a) = true es imposible. Al igual que ocurría en los criterios basados en grafos, los requisitos de testing imposibles tienen que reconocerse e ignorarse. Pero, como ya hemos dicho, detectar que un requisito de testing es inviable es difícil y, en general, indecidible. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

25 Haciendo que las cláusulas determinen a los predicados
Encontrar valores para cláusulas secundarias es fácil para predicados sencillos. Para predicados más complicados, podemos usar la siguiente estrategia: Sea pc=true el predicado p donde cada c se sustituye por true. Sea pc=false el predicado p donde cada c se sustituye por false. Construimos el predicado pc = pc=true  pc=false . Este predicado nos da los valores que debe tomar c para determinar p. Si las cláusulas hacen que pc evalúe a true/false entonces el valor de c determina/es independiente el/del valor de p. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

26 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Ejemplos Para que la cláusula principal a determine p la cláusula secundaria b tiene que ser false. p = a  b pa = pa=true  pa=false = (true  b) XOR (false  b) = true XOR b = ¬ b Para que la cláusula principal a determine p la cláusula secundaria b tiene que ser true. p = a  (b  c) pa = pa=true  pa=false = (true  (b  c))  (false  (b  c)) = true  (b  c) = ¬ (b  c) = ¬ b  ¬ c p = a  b pa = pa=true  pa=false = (true  b)  (false  b) = b  false = b Nota: RACC requiere la misma elección para ambos valores de a mientras que CACC no lo hace. Para que la cláusula principal a determine p las secundarias tienen que cumplir que b o c es false. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

27 Ejemplo (más interesante)
p = ( a  b )  ( a  ¬ b) pa = pa=true  pa=false = ((true  b)  (true  ¬ b))  ((false  b)  (false  ¬ b)) = (b  ¬ b)  false = true  false = true a siempre determina el valor de p. p = ( a  b )  ( a  ¬ b) pb = pb=true  pb=false = ((a  true)  (a  ¬ true))  ((a  false)  (a  ¬ false)) = (a  false)  (false  a) = a  a = false b nunca determina el valor de p: es irrelevante. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

28 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Método tabular Algunas veces las cuentas se complican. Una tabla de verdad puede simplificar las cosas. b y c son iguales, a es diferente y p es diferente: TTT y FTT hacen que a determine el valor de p. Para b, solo el par TTF y TFF hace que b determine el valor de p. De Nuevo, b y c son iguales, así que TTF y FTF hacen que a determine el valor de p. Finalmente, TFT y FFT también hacen que a determine el valor de p. Similarmente, para c, solo un par, TFT y TFF hace que c determine el valor de p. a b c a  (b  c) 1 T 2 F 3 4 5 6 7 8 pa pb pc En resumen, hay 3 pares distintos de filas que hacen que a determine p y solo un para para b y c. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

29 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Resumen A menudo los predicados son muy simples (en la práctica, muchos tienen menos de 3 cláusulas.) De hecho, muchos predicados solo tienen una cláusula (en este caso Cobertura de Predicados es suficiente). Con 2 o 3 cláusulas se puede aplicar CoC (Combinatorial Coverage). Las ventajas de ACC e ICC se muestran para predicados grandes (donde CoC es impracticable). Por ejemplo, los programas de control suelen tener predicados complicados con muchas cláusulas. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)