Pruebas de mutación

Las pruebas de mutación (o análisis de mutación o mutación de programas ) se utilizan para diseñar nuevas pruebas de software y evaluar la calidad de las pruebas de software existentes. Las pruebas de mutación implican realizar pequeños cambios en el programa que se está probando. ^{[ 1 ]} Cada versión modificada se denomina mutante . Una prueba detecta, y por lo tanto rechaza, un mutante cuando falla; el fallo indica que la prueba discernió correctamente que el comportamiento del mutante difiere del comportamiento del código original. El rechazo se denomina eliminación del mutante. El valor de un conjunto de pruebas se mide por el porcentaje de mutantes que elimina. El conjunto de pruebas se puede mejorar añadiendo nuevas pruebas diseñadas para eliminar mutantes adicionales.

La creación de mutantes se realiza mediante operadores de mutación bien definidos que imitan errores de programación típicos (como usar un operador o nombre de variable incorrecto) o fuerzan la creación de pruebas valiosas (como dividir cada expresión por cero).

Las pruebas de mutación son una forma de pruebas de caja blanca . ^{[ 2 ] [ 3 ]} Su propósito es ayudar al probador a desarrollar pruebas de regresión efectivas al localizar debilidades en los datos de prueba utilizados para probar el programa y descubrir secciones del código del programa probado que rara vez o nunca se acceden durante la ejecución .

La mayor parte de este artículo trata sobre la "mutación de programas", en la que se modifica el programa. Una definición más general de análisis de mutación es el uso de reglas bien definidas sobre estructuras sintácticas para realizar cambios sistemáticos en los artefactos de software. ^{[ 4 ]} El análisis de mutación se ha aplicado a otros problemas, pero generalmente se aplica a las pruebas. Por lo tanto, las pruebas de mutación se definen como el uso del análisis de mutación para diseñar nuevas pruebas de software o para evaluar las pruebas de software existentes. ^{[ 4 ]} Así, el análisis de mutación y las pruebas se pueden aplicar al diseño de modelos, especificaciones, bases de datos, pruebas, XML y otros tipos de artefactos de software, aunque la mutación de programas es la más común. ^{[ 5 ]}

Se pueden crear pruebas para verificar la corrección de la implementación de un sistema de software determinado, pero la creación de pruebas aún plantea la cuestión de si estas son correctas y cubren suficientemente los requisitos asociados con la implementación. ^{[ 6 ]} (Este problema tecnológico es en sí mismo un ejemplo de un problema filosófico más profundo llamado " Quis custodiet ipsos custodes? " ["¿Quién vigilará a los vigilantes?"]).

La idea detrás de las pruebas de mutación es que el programa que se está probando funcione según lo previsto, por lo que si se introduce una mutación y la funcionalidad cambia, esto significa que se introduce un error, que las pruebas deberían detectar. De esta manera, se prueban las funciones. Si la suite de pruebas no detecta una mutación, esto generalmente indica que la suite de pruebas no puede localizar los fallos representados por la mutación, pero también puede indicar que la mutación no introduce ningún fallo. Es decir, la mutación es un cambio válido, que produce el resultado deseado o que no afecta la funcionalidad. Una forma (común) en que una mutación puede ser válida es que el código modificado sea "código muerto" que nunca se ejecuta.

Para que las pruebas de mutación funcionen a gran escala, se suele introducir un gran número de mutantes, lo que conlleva la compilación y ejecución de muchísimas copias del programa. Este problema del elevado coste de las pruebas de mutación había reducido su uso práctico como método de prueba de software. Sin embargo, el creciente uso de lenguajes de programación orientados a objetos y marcos de pruebas unitarias ha propiciado la creación de herramientas de pruebas de mutación que permiten probar partes específicas de una aplicación.

Los objetivos de las pruebas de mutación son múltiples:

• identificar fragmentos de código poco probados (aquellos para los que no se eliminan los mutantes) ^{[ 1 ]}
• identificar pruebas débiles (aquellas que nunca matan mutantes) ^{[ 7 ]}
• calcular la puntuación de mutación, ^{[ 4 ]} la puntuación de mutación es el número de mutantes eliminados / número total de mutantes.
• Aprende sobre la propagación de errores y la infección de estados en el programa.

Las pruebas de mutación fueron propuestas originalmente por Richard Lipton cuando era estudiante en 1971, ^{[ 8 ]} y desarrolladas y publicadas por primera vez por DeMillo, Lipton y Sayward. ^{[ 1 ]} La primera implementación de una herramienta de pruebas de mutación fue realizada por Timothy Budd como parte de su trabajo de doctorado (titulado Análisis de mutación ) en 1980 en la Universidad de Yale . ^{[ 9 ]}

Recientemente, gracias a la disponibilidad de una enorme capacidad de procesamiento informático, se ha producido un resurgimiento del análisis de mutaciones dentro de la comunidad de la informática, y se ha trabajado para definir métodos de aplicación de pruebas de mutación a lenguajes de programación orientados a objetos y lenguajes no procedimentales como XML , SMV y máquinas de estados finitos .

En 2004, la empresa Certess Inc. (ahora parte de Synopsys ) extendió muchos de estos principios al ámbito de la verificación de hardware. Mientras que el análisis de mutaciones solo busca detectar diferencias en el resultado, Certess va más allá al verificar que un comprobador en el banco de pruebas detecte realmente dicha diferencia. Esta extensión implica que se evalúan las tres etapas de la verificación: activación, propagación y detección. A esto lo denominaron cualificación funcional.

El fuzzing puede considerarse un caso especial de prueba de mutación. En el fuzzing, los mensajes o datos intercambiados dentro de las interfaces de comunicación (tanto dentro como entre instancias de software) se modifican para detectar fallos o diferencias en el procesamiento de los datos. Codenomicon ^{[ 10 ]} (2001) y Mu Dynamics (2005) desarrollaron los conceptos de fuzzing hasta convertirlos en una plataforma de prueba de mutación con estado completo, que incluye monitores para evaluar exhaustivamente las implementaciones de protocolos.

Las pruebas de mutación se basan en dos hipótesis. La primera es la hipótesis del programador competente . Esta hipótesis afirma que los programadores competentes escriben programas que están cerca de ser correctos. ^{[ 1 ]} El término "cerca" se refiere al comportamiento, no a la sintaxis. La segunda hipótesis se denomina efecto de acoplamiento . El efecto de acoplamiento afirma que las fallas simples pueden encadenarse o acoplarse para formar otras fallas emergentes. ^{[ 11 ] [ 12 ]}

Los mutantes de orden superior también revelan fallas sutiles e importantes, lo que respalda aún más el efecto de acoplamiento. ^{[ 13 ] [ 14 ] [ 7 ] [ 15 ] [ 16 ]} Los mutantes de orden superior se posibilitan mediante la creación de mutantes con más de una mutación.

Las pruebas de mutación se realizan seleccionando un conjunto de operadores de mutación y aplicándolos al programa fuente uno por uno para cada fragmento de código aplicable. El resultado de aplicar un operador de mutación al programa se denomina mutante . Si el conjunto de pruebas detecta el cambio (es decir, si una de las pruebas falla), se dice que el mutante ha sido eliminado .

Por ejemplo, considere el siguiente fragmento de código C++:

if ( a && b ) { c = 1 ; } else { c = 0 ; }

El operador de mutación de condición reemplazaría &&con ||y produciría el siguiente mutante:

if ( a || b ) { c = 1 ; } else { c = 0 ; }

Ahora bien, para que la prueba elimine a este mutante, deben cumplirse las siguientes tres condiciones:

1. Una prueba debe llegar a la instrucción modificada.
2. Los datos de entrada de prueba deberían infectar el estado del programa provocando diferentes estados del programa para el mutante y el programa original. Por ejemplo, una prueba con a = 1y b = 0haría esto.
3. El estado incorrecto del programa (el valor de 'c') debe propagarse a la salida del programa y ser verificado por la prueba.

Estas condiciones se denominan colectivamente modelo RIP . ^{[ 8 ]}

Las pruebas de mutación débil (o cobertura de mutación débil ) requieren que solo se cumplan la primera y la segunda condición. Las pruebas de mutación fuerte requieren que se cumplan las tres condiciones. La mutación fuerte es más potente, ya que garantiza que el conjunto de pruebas pueda detectar los problemas de forma efectiva. La mutación débil está estrechamente relacionada con los métodos de cobertura de código . Requiere mucha menos potencia de cálculo para garantizar que el conjunto de pruebas cumpla con las pruebas de mutación débil que con las de mutación fuerte.

Sin embargo, existen casos en los que no es posible encontrar un caso de prueba que pueda eliminar este mutante. El programa resultante es conductualmente equivalente al original. Dichos mutantes se denominan mutantes equivalentes .

La detección de mutantes equivalentes es uno de los mayores obstáculos para el uso práctico de las pruebas de mutación. El esfuerzo necesario para comprobar si los mutantes son equivalentes o no puede ser muy elevado, incluso para programas pequeños. ^{[ 17 ]} Una revisión sistemática de la literatura de 2014 sobre una amplia gama de enfoques para superar el problema de los mutantes equivalentes ^{[ 18 ]} identificó 17 técnicas relevantes (en 22 artículos) y tres categorías de técnicas: detección (DEM); sugerencia (SEM); y evitación de la generación de mutantes equivalentes (AEMG). El experimento indicó que la mutación de orden superior en general y la estrategia JudyDiffOp en particular proporcionan un enfoque prometedor para el problema de los mutantes equivalentes.

Además de los mutantes equivalentes, existen mutantes subsumidos , que son mutantes que se encuentran en la misma ubicación del código fuente que otro mutante y se dice que están "subsumidos" por este último. Los mutantes subsumidos no son visibles para una herramienta de prueba de mutaciones y no contribuyen a las métricas de cobertura. Por ejemplo, supongamos que tenemos dos mutantes, A y B, que modifican una línea de código de la misma manera. Primero se prueba el mutante A, y el resultado es que el código no funciona correctamente. Luego se prueba el mutante B, y el resultado es el mismo que con el mutante A. En este caso, el mutante B se considera subsumido por el mutante A, ya que el resultado de la prueba del mutante B es el mismo que el de la prueba del mutante A. Por lo tanto, no es necesario probar el mutante B, ya que el resultado será el mismo que el del mutante A.

Para realizar cambios sintácticos en un programa, un operador de mutación sirve como guía para sustituir partes del código fuente. Dado que las mutaciones dependen de estos operadores, los investigadores han creado una colección de operadores de mutación para adaptarse a diferentes lenguajes de programación, como Java. La eficacia de estos operadores de mutación desempeña un papel fundamental en las pruebas de mutación. ^{[ 19 ]}

Los investigadores han explorado numerosos operadores de mutación. A continuación, se presentan algunos ejemplos de operadores de mutación para lenguajes imperativos:

• Eliminación de declaraciones
• Duplicación o inserción de sentencias, por ejemplo goto fail;^{[ 20 ].}
• Sustitución de subexpresiones booleanas por verdadero y falso.
• Sustitución de algunas operaciones aritméticas por otras, por ejemplo , +con *, -con/
• Sustitución de algunas relaciones booleanas por otras, por ejemplo , >con y>===<=
• Sustitución de variables por otras del mismo ámbito (los tipos de variables deben ser compatibles).
• Eliminar el cuerpo del método. ^{[ 21 ]}

Estos operadores de mutación también se denominan operadores de mutación tradicionales. También existen operadores de mutación para lenguajes orientados a objetos, ^{[ 22 ]} para construcciones concurrentes, ^{[ 23 ]} objetos complejos como contenedores, ^{[ 24 ]} etc.

Existen tres tipos de pruebas de mutación;

función checkCredentials ( nombre de usuario , contraseña ) { si ( nombre de usuario === "admin" && contraseña === "password" ) { devolver verdadero ; } }

// Código original función multiplyByTwo ( valor ) { return valor * 2 ; }// Mutación de valor: Valor pequeño a valor mayor function multiplyByTwoMutation1 ( value ) { return value * 10 ; }// Mutación de valor: Función de valor mayor a valor menor multiplyByTwoMutation2 ( valor ) { return valor / 10 ; }

// Función de código original isPositive ( número ) { return número > 0 ; }// Mutación de decisión: Cambiando la función del operador de comparación isPositiveMutation1 ( number ) { return number >= 0 ; }// Mutación de decisión: Negación del resultado function isPositiveMutation2 ( number ) { return ! ( number > 0 ); }

• Detección de errores (o siembra de fallos)
• Pruebas de cordura
• Inyección de fallos