Pruebas de regresión ( eng. pruebas de regresión ← lat. regressio “retroceder, regresar, retirarse”) es un nombre colectivo para todos los tipos de pruebas de software destinadas a detectar errores en secciones ya probadas del código fuente . Dichos errores, cuando, después de realizar cambios en el programa, algo que debería haber seguido funcionando deja de funcionar, se denominan errores de regresión .
Pruebas de regresión (para algunos[ ¿Qué? ] fuentes) incluye una nueva corrección de errores : comprobar la corrección de un defecto recién encontrado, una corrección de errores anterior: comprobar que un defecto corregido y verificado previamente no se reproduzca en el sistema de nuevo, y también un efecto secundario : comprobar que el funcionamiento anterior la funcionalidad no se ha roto, si su código podría verse afectado al corregir algunos defectos en otra funcionalidad. Los métodos de prueba de regresión comúnmente utilizados incluyen repeticiones de pruebas anteriores, así como la verificación de errores de regresión en la próxima versión como resultado de la fusión del código.
Por la experiencia del desarrollo de software, se sabe que la aparición repetida de los mismos errores es un caso bastante frecuente. A veces esto se debe a técnicas de control de versiones débiles oa un error humano en el control de versiones . Pero con la misma frecuencia, la solución a un problema es “de corta duración”: después del próximo cambio en el programa, la solución deja de funcionar. Y finalmente, al reescribir cualquier parte del código, a menudo aparecen los mismos errores que estaban en la implementación anterior.
Por lo tanto, se considera una buena práctica al corregir un error para crear una prueba y ejecutarlo periódicamente con los cambios posteriores en el programa. Si bien las pruebas de regresión se pueden realizar manualmente, generalmente se realizan con la ayuda de programas especializados que le permiten realizar todas las pruebas de regresión automáticamente . Algunos proyectos incluso usan herramientas para ejecutar automáticamente pruebas de regresión en un intervalo de tiempo determinado. Esto generalmente se hace después de cada compilación exitosa (en pequeños proyectos) ya sea cada noche o cada semana.
Las pruebas de regresión son una parte integral de la programación extrema . Esta metodología reemplaza la documentación de diseño con pruebas extensibles, repetibles y automatizadas de todo el paquete de software en cada etapa del proceso de desarrollo de software .
Las pruebas de regresión se pueden usar no solo para verificar la corrección de un programa, sino que a menudo también se usan para evaluar la calidad del resultado. Entonces, al desarrollar un compilador , al ejecutar pruebas de regresión, se considera el tamaño del código resultante, la velocidad de su ejecución y el tiempo de compilación de cada uno de los casos de prueba.
En su artículo, S. Yoo y M. Harman [1] brindan la siguiente clasificación de las pruebas de regresión:
La prueba de minimización de conjuntos busca reducir el tamaño del conjunto de prueba eliminando los casos de prueba del conjunto de prueba en función de un criterio dado. Hay tres enfoques, el primero de los cuales utiliza pruebas de seguridad automatizadas para detectar vulnerabilidades mediante el examen de fallas de aplicaciones que pueden detectar malware conocido como virus o gusanos. Este enfoque considera que solo las pruebas fallidas de la versión anterior se volverán a ejecutar en la nueva versión del sistema después de que se solucione el problema.
Otro enfoque está diseñado para detectar y corregir vulnerabilidades en versiones menores de aplicaciones web. Establece un enlace duro con las páginas de la versión anterior utilizando iteradores que se seleccionan para examinar las páginas web que contienen vulnerabilidades.
Y, finalmente, el tercer enfoque ofrece pruebas con autoadaptación del sistema para fallas ya conocidas. Los autores evitan reproducir errores ya conocidos al considerar que solo se ejecutarán aquellas pruebas que revelaron fallas conocidas en versiones anteriores.
El problema de la prueba de priorización consiste en ordenar las pruebas correctamente, lo que maximiza las propiedades deseadas, como la detección temprana de fallas. Además, los enfoques de priorización actuales solo consideran las vulnerabilidades.
Un método ofrece pruebas de prioridad basadas en errores que explotan directamente el conocimiento de su capacidad para detectar fallas.
El otro ofrece un sistema modificable de grabación y reproducción que le permite reescribir la versión grabada y ejecutada de la aplicación en una nueva y modificada. Su ejecución se prioriza debido a la determinación de la reescritura modificada óptima en función de la función de costo y la medición de la diferencia entre la ejecución original y la modificada en el reintento.
El método de selección le permite seleccionar un subconjunto o todos los casos de prueba para probar las partes modificadas del software. Los siguientes enfoques prueban tanto los mecanismos de seguridad como las vulnerabilidades.
Las pruebas de regresión se realizan cuando se realizan cambios en la funcionalidad existente del software o si hay una corrección de errores en el software. Las pruebas de regresión se pueden implementar a través de varios enfoques. Pasar todas las pruebas con éxito por parte del programa modificado brinda confianza de que los cambios realizados en el software no afectan la funcionalidad existente, que debe permanecer sin cambios en cualquier caso.
En un proceso ágil de gestión de proyectos donde el ciclo de vida de desarrollo de software es muy corto, los recursos son escasos y los cambios de software se realizan con mucha frecuencia. Las pruebas de regresión pueden generar muchos gastos generales innecesarios.
Por lo general, las pruebas de regresión se realizan mediante herramientas de automatización, pero la generación actual de herramientas de prueba de regresión no está diseñada para manejar aplicaciones de bases de datos. Por esta razón, cuando se ejecuta una prueba de regresión en aplicaciones que usan bases de datos, puede haber un costo no planificado porque requiere mucho trabajo manual.
Un problema fundamental en el mantenimiento de software es que la corrección de un error tiene una alta probabilidad (20-50%) de provocar la aparición de uno nuevo. Por lo tanto, todo el proceso sigue el principio de "dos pasos adelante, un paso atrás".
¿Por qué no podemos corregir los errores con mayor precisión? Primero, incluso un defecto oculto se manifiesta como una falla en un lugar. En realidad, a menudo tiene ramificaciones en todo el sistema, generalmente no obvias. Cualquier intento de arreglarlo con el mínimo esfuerzo arreglará lo que es local y obvio, pero a menos que la estructura sea muy clara o la documentación sea muy buena, los efectos a largo plazo de esta solución pasarán desapercibidos. En segundo lugar, los errores generalmente no los corrige el autor del programa, sino a menudo un programador junior o un aprendiz.
Debido a la introducción de nuevos errores, el mantenimiento del programa requiere mucha más depuración del sistema por declaración que cualquier otra forma de programación. Teóricamente, después de cada reparación, debe ejecutar el conjunto completo de casos de prueba con los que se verificó el sistema antes, para asegurarse de que no se haya dañado de alguna manera incomprensible. En la práctica, tales pruebas de retroceso (regresión) deberían aproximarse a este ideal teórico, y son muy costosas.
- F. Brooks El mítico hombre-mes o cómo se crean los sistemas de software [2]