archivo

Archivo de la etiqueta: mutation testing

Mutation testing es una técnica de pruebas de caja blanca que surgió en la década de los setenta que se utiliza para realizar una verificación de la calidad de los métodos y procedimientos de testing utilizados.

El motivo principal de la utilización de este tipo de estrategias es la de comprobar si las pruebas definidas son correctas y cubren los requerimientos del sistema que se está verificando. A veces se definen pruebas que efectivamente dan por válidas las salidas correctas de un determinado programa, pero que también dan por válidas otras salidas que deberían ser erróneas, es decir, nos centramos en comprobar que el resultados que esperamos se produce sin pensar en que lo mismo hay otras formas anómalas de producir resultados que además son incorrectos.

¿En qué consiste la técnica? En realizar ligeras modificaciones al código fuente original que deberían provocar unos resultados diferentes al normal y comprobar si la técnica de testing utilizada puede detectar estos cambios. Ejemplos de estos pequeños cambios lo podemos tener modificando el operador en las guardas de sentencias selectivas o iterativas, eliminando sentencias, etc…

Si la técnica de testing no ha detectado el cambio puede ser por dos motivos, por un lado que los cambios en el código fuente no han sido ejecutados (ya sea porque ese fragmento de código no se ejecuta nunca) o porque la estrategia de testing ha fallado. Para intentar que este tipo de situaciones no provoque falsos positivos lo que se hace es incluir mutaciones en zonas cubiertas por pruebas unitarias (y que se ha verificado que el código puede llegar a ejecutarse) o bien realizar mutaciones en diversas zonas del código.

Las técnicas de testing de caja blanca se realiza cuando el tester accede al código fuente de la aplicación y en consecuencia a los diferentes algoritmos y estructuras de datos utilizadas. La implementación de este tipo de pruebas requiere habilidades de programación, un conocimiento del framework de desarrollo y un cierto conocimiento funcional que permita conocer qué misión tienen determinadas clases y métodos.

Entre las técnicas de testing de caja blanca más conocidas tenemos la cobertura que consiste básicamente en la verificación de que todos los caminos lógicos de la aplicación son alcanzables teóricamente en función de los diferentes valores de entradas de los parámetros. Este tipo de pruebas, se automatizan con la ejecución de pruebas unitarias.

Otra técnica bastante conocida es la Mutation Testing que se suele utilizar para verificar la bondad de los métodos de testing utilizados. Se basa principalmente en realizar ligeras modificaciones en el programa que darían lugar a un comportamiento anómalo del mismo (resultados distintos) y verificar si la estrategia de testing utilizada es capaz de detectar estos cambios. Ejemplos de estos pequeños cambios lo podemos tener modificando el operador en las guardas de sentencias selectivas o iterativas, eliminando sentencias, etc…

Entre las críticas a esta estrategia de testing se encuentra el hecho de que hay que saber elegir muy bien cómo realizar las mutaciones, ya que hay que verificar que realmente lo que se cambia provoca un comportamiento diferente en el algoritmo porque lo mismo haces un cambio y no cambia de comportamiento.

Otra técnica de caja blanca la tenemos con la Fault Injection que persigue objetivos similares a la Mutation Testing (de hecho se considera a esta técnica como parte de la Fault Injection). Entre este tipo de técnicas tenemos la Code Insertion Testing, en la cual se introducen sentencias nuevas que provocan un error o un comportamiento anómalo en el sistema. Además de estas tećnicas, que se aplican en tiempo de compilación, la Fault Injection también aplica estrategias en tiempo de ejecución, como el hecho de provocar determinados fallos o excepciones del sistema que permitan estudiar el comportamiento del sistema en esos casos.

Una de las técnicas de testing de caja blanca más conocida es el análisis estático de código que tiene como objetivo principal evaluar (directa o indirectamente) la deuda técnica del software o lo que es lo mismo, evaluar el grado de mantenibilidad del sistema.

La mantenibilidad del sistema es una característica a la que no se suele dedicar suficiente atención, al fin y al cabo lo importante es que el sistema funcione (algo de lo que estoy totalmente de acuerdo), pero que una vez que se consigue debe ser compatible con el hecho de que el sistema sea escalable y pueda ser modificado a un coste razonable.

Además, por regla general, un sistema con una deuda técnica elevada será más propenso a tener errores.

Ver también:

Testing de caja negra.
Testing de caja gris.