Las pruebas de regresión (rara vez, pruebas que no son de regresión [1] ) consisten en volver a ejecutar pruebas funcionales y no funcionales para garantizar que el software previamente desarrollado y probado siga funcionando como se espera después de un cambio. [2] Si no, eso se llamaría una regresión .
Los cambios que pueden requerir pruebas de regresión incluyen correcciones de errores , mejoras de software, cambios de configuración e incluso sustitución de componentes electrónicos ( hardware ). [3] Dado que los conjuntos de pruebas de regresión tienden a crecer con cada defecto encontrado, la automatización de pruebas suele estar involucrada. La excepción evidente son las pruebas de regresión de las GUI , que normalmente deben ejecutarse manualmente. A veces se realiza un análisis de impacto del cambio para determinar un subconjunto apropiado de pruebas ( análisis de no regresión [4] ).
A medida que el software se actualiza o cambia, o se reutiliza en un objetivo modificado, es bastante común que surjan nuevas fallas y/o que resurgieran fallas antiguas.
A veces, la reaparición se produce porque una solución se pierde debido a prácticas deficientes de control de revisiones (o un simple error humano en el control de revisiones). A menudo, una solución para un problema será " frágil " en el sentido de que soluciona el problema en el caso concreto en el que se observó por primera vez, pero no en casos más generales que pueden surgir durante la vida útil del software. Con frecuencia, la solución de un problema en un área provoca inadvertidamente un error de software en otra área.
Puede suceder que cuando se rediseña una característica, algunos de los mismos errores que se cometieron en la implementación original de la característica también ocurran en el rediseño. En la mayoría de las situaciones de desarrollo de software, se considera una buena práctica de codificación , cuando se localiza y corrige un error, registrar una prueba que exponga el error y volver a ejecutar esa prueba periódicamente después de cambios posteriores en el programa. [5]
Aunque esto se puede hacer mediante procedimientos de prueba manuales utilizando técnicas de programación, a menudo se hace utilizando herramientas de prueba automatizadas . [6] Dicho conjunto de pruebas contiene herramientas de software que permiten que el entorno de pruebas ejecute todos los casos de prueba de regresión automáticamente; algunos proyectos incluso configuran sistemas automatizados para volver a ejecutar todas las pruebas de regresión en intervalos específicos e informar cualquier falla (lo que podría implicar una regresión o una prueba desactualizada). [7]
Las estrategias comunes son ejecutar dicho sistema después de cada compilación exitosa (para proyectos pequeños), todas las noches o una vez a la semana. Esas estrategias pueden automatizarse mediante una herramienta externa.
Las pruebas de regresión son una parte integral del método de desarrollo de software de programación extrema . En este método, los documentos de diseño se reemplazan por pruebas exhaustivas, repetibles y automatizadas de todo el paquete de software en cada etapa del proceso de desarrollo de software . Las pruebas de regresión se realizan una vez concluidas las pruebas funcionales, para verificar que las otras funcionalidades estén funcionando.
En el mundo empresarial, las pruebas de regresión las ha realizado tradicionalmente un equipo de control de calidad del software una vez que el equipo de desarrollo ha completado el trabajo. Sin embargo, los defectos encontrados en esta etapa son los más costosos de solucionar. Este problema se está abordando con el aumento de las pruebas unitarias . Aunque los desarrolladores siempre han escrito casos de prueba como parte del ciclo de desarrollo, estos casos de prueba generalmente han sido pruebas funcionales o pruebas unitarias que verifican solo los resultados previstos. Las pruebas de desarrollador obligan al desarrollador a centrarse en las pruebas unitarias e incluir casos de prueba tanto positivos como negativos. [8]
Las diversas técnicas de prueba de regresión son:
Esta técnica verifica todos los casos de prueba del programa actual para verificar su integridad. Aunque es costoso ya que necesita volver a ejecutar todos los casos, garantiza que no haya errores debido al código modificado. [9]
A diferencia de Volver a probar todo, esta técnica ejecuta una parte del conjunto de pruebas (debido al costo de volver a probar todo) si el costo de seleccionar la parte del conjunto de pruebas es menor que la técnica de Volver a probar todo. [9]
Priorice los casos de prueba para aumentar la tasa de detección de fallas de un conjunto de pruebas. Las técnicas de priorización de casos de prueba programan los casos de prueba de modo que los casos de prueba que tienen mayor prioridad se ejecuten antes que los casos de prueba que tienen menor prioridad. [9]
Esta técnica es un híbrido de selección de pruebas de regresión y priorización de casos de prueba. [9]
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 lograr mediante múltiples enfoques; si se sigue un enfoque de prueba de todos , se proporciona certeza de que los cambios realizados en el software no han afectado las funcionalidades existentes, que permanecen inalteradas. [10]
En el desarrollo ágil de software , donde los ciclos de vida del desarrollo de software son muy cortos, los recursos son escasos y los cambios en el software son muy frecuentes, las pruebas de regresión pueden introducir muchos gastos generales innecesarios . [10]
En un entorno de desarrollo de software que tiende a utilizar componentes de caja negra de un tercero, realizar pruebas de regresión puede ser complicado, ya que cualquier cambio en el componente de terceros puede interferir con el resto del sistema (y realizar pruebas de regresión en un tercero). componente del partido es difícil, porque es una entidad desconocida). [10]
Las pruebas de regresión se pueden utilizar no sólo para comprobar la exactitud de un programa sino también, a menudo, para realizar un seguimiento de la calidad de su resultado. [11] Por ejemplo, en el diseño de un compilador , las pruebas de regresión podrían rastrear el tamaño del código y el tiempo que lleva compilar y ejecutar los casos del conjunto de pruebas.
También como consecuencia de la introducción de nuevos errores, el mantenimiento del programa requiere muchas más pruebas del sistema por declaración escrita que cualquier otra programación. En teoría, después de cada corrección, se debe ejecutar todo el lote de casos de prueba ejecutados previamente en el sistema para asegurarse de que no haya sufrido daños de forma oscura. En la práctica, estas pruebas de regresión deben aproximarse a esta idea teórica, y son muy costosas.
— Fred Brooks , El mes del hombre mítico , pág. 122
Las pruebas de regresión se pueden clasificar en términos generales como pruebas funcionales o pruebas unitarias . Las pruebas funcionales ejercitan el programa completo con varias entradas. Las pruebas unitarias ejercitan funciones individuales, subrutinas o métodos de objetos. Tanto las herramientas de prueba funcional como las de prueba unitaria tienden a estar automatizadas y, a menudo, son productos de terceros que no forman parte del conjunto de compiladores. Una prueba funcional puede ser una serie de entradas de programa programadas, que posiblemente incluso impliquen un mecanismo automatizado para controlar los movimientos y clics del mouse. Una prueba unitaria puede ser un conjunto de funciones separadas dentro del código mismo o una capa de controlador que se vincula al código sin alterar el código que se está probando.
Las actividades de prueba que se centran en problemas de regresión se denominan pruebas (no) de regresión. Generalmente se omite "non"