Partición del espacio de inputs (PEI) 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)

Cuatro estructuras para modelar software Grafos Lógica Espacio de Inputs Syntaxis 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)

Especificación, Validación y Testing (M. G. Merayo y M. Núñez) Dominios de entrada El dominio de inputs de un programa contiene todos los posibles inputs del programa. Incluso para programas pequeños, el dominio de inputs es tan grande que podría considerarse infinito. Testing consiste, fundamentalmente, en elegir un conjunto finito de valores de este dominio. 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) Dominios de entrada Los parámetros de entrada definen el ámbito del dominio de inputs: Parámetros de un método. Datos que se leen de un fichero. Variables globales. Etc. Los dominios asociados con los parámetros de entrada se particionan en regiones. Se escoge al menos un valor de cada una de estas regiones. 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) Beneficios de PEI Se puede aplicar a varios niveles de testing Unitario. Integración. Sistema. Es relativamente sencillo de aplicar sin realizar automatización. Es fácil adaptar el proceso para considerar más/menos tests. No se necesita conocer la implementación: simplemente el espacio de inputs. 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) Partición de dominios Dominio D. Esquema de partición q de D. La partición q define un conjunto de bloques: Bq = b1 , b2 , …, bQ La partición debe cumplir dos propiedades: Los bloques deben ser disjuntos dos a dos (no solapan). Los bloques cubren todo el dominio D (completitud). b1 b2 b3 bi  bj = Ø,  i  j, bi, bj  Bq  b = D b  Bq Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Uso de Particiones: Hipótesis Se elije un valor de cada bloque Se asume que cada valor es igual de útil para testear el sistema. Aplicación de testing: Encontramos características en los inputs: parámetros, descripciones semánticas, … Particionamos cada característica. Elegimos tests al combinar valores de las características. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Uso de Particiones: Hipótesis Ejemplos de características: Input X es null. Orden del fichero de entrada F (ordenado, ordenado a la inversa, arbitrario…). Mínima separación entre dos aviones. Dispositivo de entrada de señal (DVD, CD, VCR, ordenador, …). Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Elección de particiones La elección (definición) de particiones parece sencilla pero es fácil equivocarse. Consideremos “ordenación del fichero F”. Solución: Cada característica debería considerar solo una propiedad b1 = ordenado ascendentemente b2 = ordenado descendentemente b3 = orden arbitrario C1: F ordenado ascendente - c1.b1 = true - c1.b2 = false C2: F ordenado descendente - c2.b1 = true - c2.b2 = false pero … algo huele mal … ¿Qué ocurre si la longitude es 1? El fichero está en los tres bloques… No se cumple “no solapamiento”. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Propiedades de las particiones Si las particiones no son completes o disjuntas entonces no hemos sido suficiente cuidadosos al elegirlas. Deberían revisarse detenidamente (como cualquier diseño). Se deberían considerar alternativas diferentes. Modelaremos el dominio de inputs en cinco pasos. Los pasos 1 y 2 nos mueven del nivel de la implementación al nivel de diseño. Los pasos 3 y 4 se llevan a cabo al nivel de diseño. El paso 5 nos devuelve al nivel de implementación. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Modelado del dominio de inputs Paso 1: Identificar las funciones testeables. Los métodos individuales tienen una función testeable. Los métodos de una clase suelen tener las mismas características. Los programas tienen características más complicadas: documentos de modelado, como UML, se pueden usar para diseñar características. Los sistemas que integran componentes hardware y software usan dispositivos, sistemas operativos, plataformas hardware, browsers, etc. 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) Modelado del dominio de inputs Paso 2: Encontrar todos los parámetros. Usualmente es muy sencillo, incluso mecánico. Es muy importante que sea completo (no nos dejamos ninguno). Métodos: Parámetros y variables no locales. Componentes: Parámetros para métodos y variables no locales. Sistema: Todos los inputs, incluyendo ficheros y bases de datos. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Modelado del dominio de inputs Paso 3: Modelar el dominio de inputs. El dominio viene acotado por los parámetros. La estructura se define en términos de las características. Cada característica se particiona en conjuntos de bloques. Cada bloque representa un conjunto de valores. Este es el paso más creativo al llevar a cabo PEI. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Modelado del dominio de inputs Paso 4: Aplicar un criterio para elegir las combinaciones de valores. Cada test contiene un valor para cada parámetro. Un bloque para cada característica. Usualmente es imposible considerar todas las combinaciones. Los criterios de cobertura permiten elegir subconjuntos. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Modelado del dominio de inputs Paso 5: Transformar las combinaciones de bloques en tests. Elegir valores apropiados para cada bloque. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Dos metodologías para modelar el dominio de inputs Basada en el interface Se desarrollan características a partir de los parámetros de entrada. Es la forma más simple. En algunas situaciones se puede automatizar (parcialmente). Basada en funcionalidades Se desarrollan características a partir del comportamiento observado en el programa que estamos testeando. Más difícil de desarrollar: necesita más esfuerzo de diseño. Puede dar lugar a mejores tests o menos tests que son igual de efectivos. Modelo del Dominio de Inputs (MDI) 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) Basada en el interface De forma mecánica, consideramos cada parámetro por separado. Esta es una técnica sencilla de modelado y se basa, esencialmente, en la sintaxis. De hecho, no se tendrá en cuenta alguna información semántica o sobre el dominio, lo que dará lugar a MDI incompletos. Ignora completamente las relaciones entre parámetros. 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) Basada en el interface Consideremos un método Triangulo() que implementa el problema con el que empezamos el curso y que forma parte de una clase TipoTriangulo. public enum Triangulo { Escaleno, Isosceles, Equilatero, Invalido } public static Triangulo triang (int Lado1, int Lado2, int Ladoe3) // Lado1, Lado2, and Lado3 representan las longitudes de los lados del triángulo // Devuelve el valor apropiado de enum El MDI es igual para cada parámetro. Característica razonable: Relación de lado con cero. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Basada en las funcionalidades Se identifican características que corresponden con las supuestas funcionalidades. Como ya hemos dicho, requiere un mayor esfuerzo de diseño por parte del testeador. Pueden incorporar conocimiento sobre semántica y dominio. Puede tener en cuenta relaciones entre parámetros. El modelado se puede basar en los requisitos en lugar de en la implementación. Un parámetro puede aparecer en varias características. Por tanto, es más difícil traducir valores en tests. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Basada en las funcionalidades Consideremos de nuevo el método Triangulo() de la clase TipoTriangulo. Los tres parámetros representan un triángulo. El MDI puede combinar todos los parámetros. Característica razonable: Tipo de triángulo. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Pasos 1 & 2: Funcionalidades, parámetros y características La creatividad juega un papel relevante. Un mayor número de características da lugar a más tests. Basada en el interface: Traducir de parámetros a características. Candidatos para características: Precondiciones y postcondiciones. Relaciones entre variables. Relación entre variables con valores especiales (cero, null, blanco, …). Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Pasos 1 & 2: Funcionalidades, parámetros y características No se debería usar el código fuente: características deberían basarse en el dominio de los inputs. El código se debería usar con criterios basados en grafos o lógica. Es mejor tener más características con menos bloques. Menos errores y menos tests. 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) Pasos 1 & 2: Interface public boolean encontrarElemento (List lista, Object elemento) // Si lista o elemento es null lanzar NullPointerException // sino devuelve true si elemento está en lista, false e.o.c. Basada en interface Dos parámetros: lista, elemento Características: lista es null (block1 = true, block2 = false) lista es vacía (block1 = true, block2 = false) Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Pasos 1 & 2: Funcionalidades public boolean encontrarElemento (List lista, Object elemento) // Si lista o elemento es null lanzar NullPointerException // sino devuelve true si elemento está en lista, false e.o.c. Basada en funcionalidades Dos parámetros: lista, elemento Características: número de apariciones de elemento en lista (0,1, >1) elemento sale el primero en la lista (true, false) elemento sale el último en la lista (true, false) Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Paso 3: Modelando el dominio de inputs Partiticionar las características en bloques y valores es un paso muy creativo. Más bloques implican más tests. A menudo se pueden realizar las particiones directamente a partir de las características (y ambos pasos se hacen juntos). En general, se deberían evaluar por separado: algunas veces se pueden usar menos características con más bloques y viceversa. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Paso 3: Modelando el dominio de inputs Estrategias para identificar valores: Incluir valores válidos, inválidos y especiales. Sub-particionar algunos bloques. Explorar las fronteras entre dominios. Incluir valores que representan el “uso normal”. Intentar equilibrar el número de bloques por característica. Comprobar completitud y disjuntos. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Paso 3: MDI-Interface triang() Triang() tiene una función testeable y tres inputs enteros. Da lugar a un máximo de 3*3*3 = 27 tests. Algunos triángulos serán válidos y otros serán inválidos. Refinar la caracterización puede dar lugar a más tests …. Primera caracterización de los inputs Característica b1 b2 b3 q1 = Relación de Lado1 con 0 mayor que 0 igual a 0 menor que 0 q2 = Relación de Lado2 con 0 q3 = Relación de Lado3 con 0 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Paso 3: MDI-Interface triang() Segunda caracterización de los inputs Característica b1 b2 b3 b4 q1 = Refina q1 mayor que 1 igual a 1 igual a 0 menor que 0 q2 = Refina q2 q3 = Refina q3 Da lugar a un máximo de 4*4*4 = 64 tests. Completa porque los inputs son enteros. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Paso 3: MDI-Interface triang() Segunda caracterización de los inputs Característica b1 b2 b3 b4 q1 = Refina q1 mayor que 1 igual a 1 igual a 0 menor que 0 q2 = Refina q2 q3 = Refina q3 Valores posibles para q1 Característica b1 b2 b3 b4 Lado1 5 1 -5 2 -1 Si queremos tener en cuenta las fronteras Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Paso 3: MDI-funcionalidades triang() Las primeras dos caracterizaciones están basadas en sintaxis: los parámetros y su tipo. Una caracterización a nivel semántico puede usar el hecho de que los tres enteros representen un triángulo. Oh, oh, algo huele mal…. los equiláteros también son isósceles… refinar Caracterización geométrica de los inputs Característica b1 b2 b3 b4 q1 = Clasificación Geométrica escaleno isósceles equilátero inválido Caracterización correcta geométrica de los inputs Característica b1 b2 b3 b4 q1 = Clasificación Geométrica escaleno Isósceles, no equilátero equilátero inválido Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Paso 3: MDI-funcionalidades triang() Los valores de esta partición se puede elegir de la siguiente forma: Posibles valores para partición geométrica q1 Característica b1 b2 b3 b4 Triángulo (4,5,6) (3,3,4) (3,3,3) (3,4,8) Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Paso 3: MDI-funcionalidades triang() Una alternativa sería partir la caracterización anterior en cuatro. Además, hay que añadir restricciones para asegurar que: equilátero = True implica isósceles = True. válido = False implica escaleno = isósceles = equilátero = False. Cuatro características para triang() Característica b1 b2 q1 = escaleno True False q2 = isósceles q3 = equilátero q4 = válido Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Paso 3: Uso de más de un MDI Algunos programas pueden tener cientos de parámetros. Una buena alternativa puede ser crear varios MDIs pequeños, dando lugar a una estrategia divide y vencerás. Diferentes partes del software se pueden testear con diferente rigurosidad. Por ejemplo, algunos MDIs pueden incluir muchos valores inválidos. El hecho de que los diferentes MDIs solapen no acarrea problemas: la misma variable puede aparecer en varios MDIs. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Paso 4: Eligiendo combinaciones de valores Cuando se han definido las características y las particiones, el siguiente paso es elegir valores para los tests. Utilizamos criterios para elegir subconjuntos efectivos. El criterio más obvio consiste en elegir todas las combinaciones. El número de tests es igual al producto del número de bloques en cada característica. La segunda caracterización de triang() da lugar a 64 tests. ¿Creéis que son demasiados? All Combinations (ACoC): Se usan todas las combinaciones de bloques de todas las características.  Q i=1 (Bi) Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Criterio PEI: Todas combinaciones Consideremos la segunda caracterización geométrica: Por conveniencia, reetiquetamos los bloques: Característica b1 b2 b3 b4 q1 = Refina q1 mayor que 1 igual a 1 igual a 0 menor que 0 q2 = Refina q2 q3 = Refina q3 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Criterio PEI: Todas combinaciones Característica b1 b2 b3 b4 A A1 A2 A3 A4 B B1 B2 B3 B4 C C1 C2 C3 C4 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Criterio PEI: Tests ACoC A1 B1 C1 A1 B1 C2 A1 B1 C3 A1 B1 C4 A1 B2 C1 A1 B2 C2 A1 B2 C3 A1 B2 C4 A1 B3 C1 A1 B3 C2 A1 B3 C3 A1 B3 C4 A1 B4 C1 A1 B4 C2 A1 B4 C3 A1 B4 C4 A2 B1 C1 A2 B1 C2 A2 B1 C3 A2 B1 C4 A2 B2 C1 A2 B2 C2 A2 B2 C3 A2 B2 C4 A2 B3 C1 A2 B3 C2 A2 B3 C3 A2 B3 C4 A2 B4 C1 A2 B4 C2 A2 B4 C3 A2 B4 C4 A3 B1 C1 A3 B1 C2 A3 B1 C3 A3 B1 C4 A3 B2 C1 A3 B2 C2 A3 B2 C3 A3 B2 C4 A3 B3 C1 A3 B3 C2 A3 B3 C3 A3 B3 C4 A3 B4 C1 A3 B4 C2 A3 B4 C3 A3 B4 C4 A4 B1 C1 A4 B1 C2 A4 B1 C3 A4 B1 C4 A4 B2 C1 A4 B2 C2 A4 B2 C3 A4 B2 C4 A4 B3 C1 A4 B3 C2 A4 B3 C3 A4 B3 C4 A4 B4 C1 A4 B4 C2 A4 B4 C3 A4 B4 C4 ACoC da lugar a 4*4*4=64 tests. Ciertamente, esta cantidad parece muy alta. En particular, teniendo en cuenta que solo 8 de ellos son válidos (todos los lados mayores que cero). Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Criterio PEI: Cada elección Un nuevo criterio se conforma a partir de la idea de que debemos probar al menos un valor de cada bloque. El número de tests es igual al número de bloques de la característica con más bloques. Each Choice Coverage (ECC): Un valor de cada bloque de cada característica se debe usar en al menos un test. Max Q i=1 (Bi) triang() : A1, B1, C1 A2, B2, C2 A3, B3, C3 A4, B4, C4 Usando valores: 2, 2, 2 1, 1, 1 0, 0, 0 -1, -1, -1 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) Criterio PEI: Dos a dos En el criterio anterior, cada elección da menos tests pero puede ser inefectiva. Una alternativa es combinar valores con otros valores. El número de tests es al menos el producto de los bloques de la dos características con más bloques. Pair-Wise Coverage (PWC): Un valor de cada bloque de cada característica se debe combinar con un valor de todos los bloques de las otras características. (Max Q i=1 (Bi) ) * j=1, j!=i (Bj) ) triang() : A1, B1, C1 A1, B2, C2 A1, B3, C3 A1, B4, C4 A2, B1, C2 A2, B2, C3 A2, B3, C4 A2, B4, C1 A3, B1, C3 A3, B2, C4 A3, B3, C1 A3, B4, C2 A4, B1, C4 A4, B2, C1 A4, B3, C2 A4, B4, C3 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) Criterio PEI: Dos a dos En el criterio anterior, cada elección da menos tests pero puede ser inefectiva. Una alternativa es combinar valores con otros valores. Pair-Wise Coverage (PWC): Un valor de cada bloque de cada característica se debe combinar con un valor de todos los bloques de las otras características. Otro ejemplo: Tenemos tres particiones con bloques [A,B], [1,2,3] y [x,y] los tests necesitan cubrir las siguientes 16 combinaciones. Como cada test puede cubrir más de una combinación es suficiente con los siguientes 8 tests: A,1 B,1 1,x A,2 B,2 1,y A,3 B,3 2,x A,x B,x 2,y A,y B,y 3,x 3,y A,1,x A,2,x A,3,x B,1,y B,2,y B,3,y Nota: - se puede sustituir por cualquier valor. 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) Criterio PEI: de t en t Una extensión obvia consiste en requerir la combinación de t valores en lugar de 2. El número de tests es al menos el producto de los bloques de la t características con más bloques. Si todas las características tienen el mismo tamaño: Si t es igual al número de características Q entonces Q-Wise = ACoC. T-wise es costoso y sus beneficios no están claros. t-Wise Coverage (TWC): Un valor de cada bloque de cada grupo de t características se debe combinar. (Max Q i=1 (Bi) ) t Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Criterio PEI: Elección base Los testeadores identifican que algunos valores son más importantes. Esto usa conocimiento del dominio del programa. El número de tests es igual a un test base más un test por cada uno de los restantes bloques: Base Choice Coverage (BCC): Para cada característica se designa un bloque como elección base. Un test base se conforma usando la elección base de cada característica. Los siguientes tests se forman manteniendo todos los valores constantes menos uno y usando cada elección no base en las demás características. 1 +  Q i=1 (Bi -1 ) Base A1, B1, C1 A1, B1, C2 A1, B2, C1 A2, B1, C1 A1, B1, C3 A1, B3, C1 A3, B1, C1 A1, B1, C4 A1, B4, C1 A4, B1, C1 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Criterio PEI: Elección base El test base debe ser factible, es decir, las elecciones deben ser compatibles. Las elecciones base pueden ser: Más habituales desde el punto de vista del uso final. Más simples. Más pequeñas. Primeras en algún orden. Tests que siguen un camino feliz suelen ser buenas elecciones. La elección base es una decisión de diseño crucial. Los diseñadores de tests deberían documentar sus decisiones en este sentido. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Criterio PEI: Múltiple elección base Algunas veces existe más de un elección base lógica. Si tenemos M tests base y mi elecciones base para cada característica entonces tenemos (a lo sumo) tests: Multiple Base Choice Coverage (MBCC): Se elige al menos un bloque de elección base para cada característica. Los tests base se conforman usando la elección base de cada característica al menos una vez. Los siguientes tests se forman manteniendo todos los valores constantes menos uno y usando cada elección no base en las demás características. M +  Q i=1 (M * (Bi - mi )) Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

All Combinations Coverage Multiple Base Choice Coverage Criterios PEI: Subsunción Each Choice Coverage ECC All Combinations Coverage ACoC T-Wise Coverage TWC Multiple Base Choice Coverage MBCC Pair-Wise Coverage PWC Base Choice Coverage BCC Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Restricciones entre características Algunas combinaciones de bloques no son factibles. “menor que cero” y “escaleno” no son posibles al mismo tiempo. Estas combinaciones se pueden representar mediante restricciones entre bloques. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Restricciones entre características Hay dos tipos de restricciones: Un bloque de una característica no se puede combinar con un bloque específico de otra. Un bloque de una característica puede combinarse SOLO con un bloque específico de otra. La manipulación de restricciones depende del criterio considerado: ACC, PWC, TWC: Eliminar los pares no factibles. BCC, MBCC: Cambiar un valor por otro que no sea base para encontrar una combinación factible. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Ejemplo manipulación restricciones public boolean encontrarElemento (List lista, Object elemento) // Si lista o elemento es null lanzar NullPointerException // sino devuelve true si elemento está en lista, false e.o.c. Característica Bloque 1 Bloque 2 Bloque 3 Bloque 4 A: longitud y contenidos un elemento más de uno, no ordenados más de uno, ordenados más de uno, todos iguales B : match elemento no encontrado elemento una vez elemento más de una vez Combinaciones inválidas: (A1, B3), (A4, B2) Un elemento no puede estar más de una vez en una lista con un elemento Si la lista tiene un único elemento pero aparece varias veces, no podemos encontrarlo una sola vez Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Simple, sencillo, efectivo, y ampliamente usado Resumen de PEI Relativamente fácil de usar, incluso sin automatización. Son convenientes para considerar más/menos testing. Aplicable a todos los niveles (unidad, clase, integración, etc). Basado solo en el espacio de inputs del programa, no en la implementación Simple, sencillo, efectivo, y ampliamente usado Especificación, Validación y Testing (M. G. Merayo y M. Núñez)