Las pruebas de mutación (o análisis de la mutación o mutaciones programa ) se utiliza para diseñar nuevas pruebas de software y evaluar la calidad de las pruebas de software existentes. Las pruebas de mutación implican modificar un programa en pequeñas formas. [1] Cada versión mutada se llama mutante y las pruebas detectan y rechazan mutantes haciendo que el comportamiento de la versión original difiera del mutante. A esto se le llama matar al mutante. Los conjuntos de pruebas se miden por el porcentaje de mutantes que matan. Se pueden diseñar nuevas pruebas para matar mutantes adicionales. Los mutantes se basan en operadores de mutación bien definidos .que imitan errores de programación típicos (como usar el operador incorrecto o el nombre de variable) o fuerzan la creación de pruebas valiosas (como dividir cada expresión por cero). El propósito es ayudar al evaluador a desarrollar pruebas efectivas o localizar debilidades en los datos de prueba utilizados para el programa o en secciones del código a las que rara vez o nunca se accede durante la ejecución . La prueba de mutación es una forma de prueba de caja blanca . [2] [3]
La mayor parte de este artículo trata sobre la "mutación del programa", en la que se modifica el programa. Una definición más general de análisis de mutaciones es el uso de reglas bien definidas definidas en estructuras sintácticas para realizar cambios sistemáticos en los artefactos de software. [4] El análisis de mutaciones 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 de análisis de mutaciones para diseñar nuevas pruebas de software o para evaluar pruebas de software existentes. [4] Por lo tanto, el análisis y las pruebas de mutaciones se pueden aplicar para diseñar modelos, especificaciones, bases de datos, pruebas, XML y otros tipos de artefactos de software, aunque la mutación del programa 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 dado, pero la creación de pruebas aún plantea la pregunta de si las pruebas son correctas y cubren suficientemente los requisitos que han originado la implementación. [6] (Este problema tecnológico es en sí mismo una instancia de un problema filosófico más profundo llamado " Quis custodiet ipsos custodes? " ["¿Quién vigilará a los guardias?"].) La idea es que si se introduce un mutante sin ser detectado por el suite de pruebas, esto indica que el código que había sido mutado nunca se ejecutó (código muerto) o que la suite de pruebas no pudo localizar las fallas representadas por el mutante.
Para que esto funcione a cualquier escala, se suele introducir una gran cantidad de mutantes, lo que lleva a la compilación y ejecución de una cantidad extremadamente grande de copias del programa. Este problema del costo de las pruebas de mutaciones había reducido su uso práctico como método de prueba de software. Sin embargo, el mayor uso de lenguajes de programación orientados a objetos y marcos de pruebas unitarias ha llevado a la creación de herramientas de prueba de mutaciones que prueban partes individuales de una aplicación.
La prueba de mutación fue propuesta originalmente por Richard Lipton como estudiante en 1971, [9] y desarrollada y publicada por primera vez por DeMillo, Lipton y Sayward. [1] La primera implementación de una herramienta de prueba de mutaciones fue realizada por Timothy Budd como parte de su trabajo de doctorado (titulado Análisis de mutaciones ) en 1980 de la Universidad de Yale . [10]
Recientemente, con la disponibilidad de una potencia informática masiva, ha habido un resurgimiento del análisis de mutaciones dentro de la comunidad 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 .