Testing basado en sintaxis: Gramáticas en espacios de inputs 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)

Gramáticas para espacios de inputs Recordemos que un espacio de inputs es el conjunto de inputs permitidos para un cierto software. El espacio de inputs se puede describir de múltiples formas: Manuales de usuario. Páginas man (Unix). Precondiciones de los métodos. Un cierto lenguaje. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Gramáticas para espacios de inputs La mayoría de los espacios de inputs se pueden expresar como una gramática. Usualmente no hay gramáticas disponibles, pero crearlas suele ser muy útil para el testeador. De hecho, se pueden encontrar algunos errores simplemente creando una gramática. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Usando gramáticas para inputs El software debe rechazar o manejar los datos inválidos. Los programas suelen hacer esto de forma incorrecta. Algunos programas asumen (¡mal hecho!) que todos los inputs son correctos. Esto ocurre incluso a día de hoy: ¿Qué ocurre después de que el programa tenga cambios debidos a mantenimiento? ¿Qué ocurre si una componente se reúsa en otro programa? Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Usando gramáticas para inputs Las consecuencias de asumir la corrección de los inputs recibidos pueden ser severas: La base de datos se puede corromper. Los usuarios no están satisfechos. Muchas vulnerabilidades de seguridad se deben a no controlar excepciones provocadas por inputs inválidos. 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) Validación de inputs Básicamente, validación de inputs es decidir si el software puede procesar los inputs recibidos. Los buenos programas deben comprobar que los inputs son válidos antes de empezar a procesarlos. Se nos plantean, al menos, dos preguntas lícitas: ¿Cómo debería reconocer un programa a los inputs inválidos? ¿Qué debe hacer el programa con los inputs inválidos? 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) Validación de inputs Si tenemos una descripción del espacio de inputs como una gramática, entonces un parser puede comprobar automáticamente la validez de los inputs. Desgraciadamente, Esto no ocurre frecuentemente. Es fácil escribir comprobadores de inputs… pero también es fácil tener errores. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Gramáticas para espacios de inputs Como ya hemos dicho, los espacios de inputs se pueden representar de varias formas. Una forma muy común consiste en usar algún tipo de gramática. Vamos a considerar tres tipos distintos de gramáticas: Expresiones regulares. Gramáticas BNF. Esquemas XML. Todas son similares y se pueden usar en contextos diferentes. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Expresiones regulares Consideremos un programa que procesa una secuencia de depósitos y retiradas en un banco. Inputs depósito 5306 $4.30 retiro 0343 $4.14 depósito 5306 $7.29 Expresión Regular Inicial (depósito cuenta cantidad | retiro cuenta cantidad) * Preparada depósito retiro FSM que representa a una gramática Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Gramática BNF para el banco Las gramáticas son más expresivas que las expresiones regulares: pueden capturar más detalles. banco ::= acción* acción ::= dep | ret dep ::= “depósito” cuenta cantidad deb ::= “retiro” cuenta cantidad cuenta ::= dígito4 cantidad ::= “$” dígito+ “.” dígito2 dígito ::= “0” | “1” | “2” | “3” | “4” | “5” | “6” | “7” | “8” | “9” Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

FSM para la gramática del banco depósito retiro dígito “.” $ Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

FSMs y generación de tests Se pueden derivar tests sustituyendo sistemáticamente cada símbolo no terminal con una producción. Si el testeador diseña una gramática a partir de una descripción informal del espacio de inputs, entonces debería hacerlo pronto: Lo antes posible para mejorar el diseño. Casi todas las veces se encontrarán errores y omisiones. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

XML para describir espacios de inputs Las componentes software que se pasan datos entre si deben ponerse de acuerdo en formatos, tipos y organización. Las aplicaciones web tiene requisitos especiales: Loose coupling (poco conocimiento de las otras componentes) e integración dinámica. En el caso de sistemas con loose coupling, los datos se pasan directamente entre las componentes. XML permite que los datos acarreen documentación sobre su formato. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

XML para describir espacios de inputs Los mensajes XML se definen mediante gramáticas: esquemas y DTDs (Definición de Tipo de Documento). Los esquemas pueden definir muchos tipos de tipos. Los esquemas incluyen facets (restricciones sobre los valores para definir los aceptables) que refinan la gramática. En resumen, los esquemas se pueden usar para definir espacios de inputs para componentes software. 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) XML: Ejemplo <books> <book> <ISBN>0471043281</ISBN> <title>The Art of Software Testing</title> <author>Glen Myers</author> <publisher>Wiley</publisher> <price>50.00</price> <year>1979</year> </book> </books> Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Dominios de inputs Inputs deseados (dominio objetivo) Inputs descritos (dominio especificado) Inputs aceptados (dominio implementado) Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Ejemplo de dominio de inputs Los dominios objetivo de inputs suelen ser irregulares. Dominio objetivo para tarjetas de crédito Primer dígito es un identificador del proveedor (4 para visa, 34 o 37 para American Express, 5 para Mastercard….). Los primeros seis dígitos y la longitud indican el emisor. El último dígito es de control. Otros dígitos identifican una cuenta específica. Dominio especificado habitualmente para tarjetas de crédito Primer dígito es 3, 4, 5 o 6. La longitud está entre 13 y 16. Dominio implementado habitualmente para tarjetas de crédito Todos los elementos son numéricos. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Dominios de inputs Esta región da lugar a muchos errores…. Inputs deseados (dominio objetivo) Inputs descritos (dominio especificado) Esta región da lugar a muchos errores…. Inputs aceptados (dominio implementado) Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Uso de gramáticas para diseñar tests Esta forma de testing nos permite centrarnos en las interacciones entre componentes (se aplicó originalmente a servicios web que dependían de XML). Se usa un modelo formal de la gramática XML. La gramática se usa tanto para crear test válidos como inválidos. Se muta la gramática. La gramática mutada se usa para generar mensajes XML nuevos. Los mensajes XML se usan como 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) Esquema: Gramática para libro Book Grammar – Schema <xs:element name = “books”> <xs:complexType> <xs:sequence> <xs:element name = “book” maxOccurs = “unbounded”> <xs:element name = “ISBN” type = “isbnType” minOccurs = “0”/> <xs:element name = “author” type = “xs:string”/> <xs:element name = “title” type = “xs:string”/> <xs:element name = “publisher” type = “xs:string”/> <xs:element name = “price” type = “priceType”/> <xs:element name = “year” type = “yearType”/> </xs:sequence> </xs:complexType> </xs:element> Tipos Built-in <xs:simpleType name = “priceType”> <xs:restriction base = “xs:decimal”> <xs:fractionDigits value = “2” /> <xs:maxInclusive value = “1000.00” /> </xs:restriction> </xs:simpleType> Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Restricciones en XML: Facets Restricciones frontera Otras restricciones maxOccurs enumeration minOccurs use length fractionDigits maxExclusive pattern maxInclusive nillable maxLength whiteSpace minExclusive unique minInclusive minLength totalDigits 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) Generación de tests Test válidos Generar tests como mensajes XML derivando cadenas a partir de la gramática. Usar cada producción al menos una vez. Usar todas las opciones…. Teniendo en cuenta que cláusulas maxOccurs =“unbounded” significa 0,1 y más de 1 veces. Test inválidos Mutar la gramática de forma estructurada. Crear mensajes XML que son casi válidos. Esto sirve para explorar el espacio gris en el dominio 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) Generación de tests Los criterios que vimos al principio del tema (cobertura de producciones y de símbolos terminales) se pueden usar en este contexto. En el caso de la gramática para libros, la única elección se basa en “minOccurs” que aparece en ISBN. 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) Esquema: Gramática para libro Book Grammar – Schema <xs:element name = “books”> <xs:complexType> <xs:sequence> <xs:element name = “book” maxOccurs = “unbounded”> <xs:element name = “ISBN” type = “isbnType” minOccurs = “0”/> <xs:element name = “author” type = “xs:string”/> <xs:element name = “title” type = “xs:string”/> <xs:element name = “publisher” type = “xs:string”/> <xs:element name = “price” type = “priceType”/> <xs:element name = “year” type = “yearType”/> </xs:sequence> </xs:complexType> </xs:element> 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) Generación de tests Los criterios que vimos al principio del tema (cobertura de producciones y de símbolos terminales) se pueden usar en este contexto. En el caso de la gramática para libros, la única elección se basa en “minOccurs” que aparece en ISBN. Cobertura de producciones (PC) requiere dos tests: aparece ISBN y no aparece ISBN. Se usan facets para generar valores que son válidos… pero también queremos valores que no sean válidos. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Mutación de gramáticas Los mutantes son tests. Se crean cadenas válidas e inválidas. No hay cadenas básicas: no mataremos mutantes. Vamos a ver una serie de operadores de mutación muy genéricos pero que se deberían refinar para gramáticas específicas. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Mutación de gramáticas: operadores Sustitución de un no terminal. Cada símbolo no terminal de cada producción se sustituye por otros símbolos no terminales. Sustitución de un terminal. Cada símbolo terminal de cada producción se sustituye por otros símbolos terminales. Eliminación de terminales y no terminales. Cada símbolo terminal y no terminal de cada producción se elimina. Duplicación de terminales y no terminales. Cada símbolo terminal y no terminal de cada producción se duplica. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Operadores de mutación Muchas cadenas puede ser inútiles. Hay que usar información adicional sobre tipos, si es posible. Hay que tener cuidado a la hora de descartar tests. Solamente se debería usar una sustitución si tiene sentido. Veamos unos ejemplos: 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) Ejemplos Realizaremos mutaciones sobre la gramática vista anteriormente banco ::= acción* acción ::= dep | ret dep ::= “depósito” cuenta cantidad deb ::= “retiro” cuenta cantidad cuenta ::= dígito4 cantidad ::= “$” dígito+ “.” dígito2 dígito ::= “0” | “1” | “2” | “3” | “4” | “5” | “6” | “7” | “8” | “9” Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Sustitución de no terminal Sustitución de no terminal Ejemplos Sustitución de no terminal dep ::= “depósito” cuenta cantidad dep ::= “depósito” cantidad cantidad dep ::= “depósito” cuenta cuenta depósito $1500.00 $3789.88 depósito 4400 5 Sustitución de no terminal cantidad ::= “$” dígito+ “.” dígito2 cantidad ::= “.” dígito+ “.” dígito2 cantidad ::= “$” dígito+ “$” dígito2 cantidad ::= “$” dígito+ “1” dígito2 depósito 4400 .1500.00 depósito 4400 $1500$00 depósito 4400 $1500100 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Ejemplos Eliminación de terminal y no terminal dep ::= “depósito” cuenta cantidad dep ::= cuenta cantidad dep ::= “depósito” cantidad dep ::= “depósito” cuenta 4400 $1500.00 depósito $1500.00 depósito 4400 Duplicado de terminal y no terminal dep ::= “depósito” cuenta cantidad dep ::= “depósito” “depósito” cuenta cantidad dep ::= “depósito” cuenta cuenta cantidad dep ::= “depósito” cuenta cantidad cantidad depósito depósito 4400 $1500.00 depósito 4400 4400 $1500.00 depósito 4400 $1500.00 $1500.00 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) Notas y aplicaciones Hay mucha más experiencia en mutación de programas que en mutación de gramáticas. Por tanto, los operadores son menos precisos. Aplicación de operadores de mutación: Mutar la gramática para, a continuación, derivar cadenas. Derivar cadenas y mutar una derivación. Algunos mutantes dan cadenas que están en la gramática original (equivalente). En este caso, es más sencillo reconocer la equivalencia. 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) Mutación de XML Los esquemas de XML se pueden mutar. Si no existe un esquema, los testeadores deberían derivar uno. Como siempre, esto les ayudará a encontrar problemas inmediatamente. Muchos programas validan mensajes contra una gramática. Es menos frecuente que los programas comprueben todos los facets del esquema. De hecho, la mutación de facets puede dar lugar a tests muy efectivos. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

Generación de tests: Ejemplo Esquema original (parcial) <xs:simpleType name = “priceType”> <xs:restriction base = “xs:decimal”> <xs:fractionDigits value = “2” /> <xs:maxInclusive value = “1000.00” /> </xs:restriction> </xs:simpleType> Mutantes: value = “3” value = “1” Mutantes: value = “100” value = “2000” XML del esquema original <books> <book> <ISBN>0-201-74095-8</ISBN> <price>37.95</price> <year>2002</year> </book> Mutant XML 1 <books> <book> <ISBN>0-201-74095-8</ISBN> <price>37.95 </price> <year>2002</year> </book> Mutant XML 2 <books> <book> <ISBN>0-201-74095-8</ISBN> <price>37.95</price> <year>2002</year> </book> Mutant XML 3 <books> <book> <ISBN>0-201-74095-8</ISBN> <price>37.95 </price> <year>2002</year> </book> Mutant XML 4 <books> <book> <ISBN>0-201-74095-8</ISBN> <price>37.95 </price> <year>2002</year> </book> 505 5 99.00 1500.00 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) Conclusiones Esta aplicación de la mutación (a las gramáticas que definen espacios de inputs) es bastante nueva. No existen herramientas para automatizar el proceso. Las técnicas se pueden usar a mano para conseguir ad-hoc tests efectivos. Existen aplicaciones para gramáticas de propósito específico (en contra de las de propósito general) muy prometedoras: XML, SQL y HTML. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)