Una regresión de software es un tipo de error de software en el que una característica que ha funcionado antes deja de funcionar. Esto puede suceder después de que se apliquen cambios al código fuente del software , incluida la adición de nuevas funciones y correcciones de errores. [1] También pueden ser introducidos por cambios en el entorno en el que se ejecuta el software, como actualizaciones del sistema , parches del sistema o un cambio al horario de verano . [2] Una regresión del rendimiento del software es una situación en la que el software aún funciona correctamente, pero funciona más lentamente o utiliza más memoria o recursos que antes. [3]En la práctica, se han identificado varios tipos de regresiones de software, incluidos los siguientes: [4]
Las regresiones a menudo son causadas por correcciones de errores englobadas incluidas en los parches de software . Un enfoque para evitar este tipo de problema es la prueba de regresión . Un plan de prueba diseñado correctamente tiene como objetivo prevenir esta posibilidad antes de lanzar cualquier software. [5] Las pruebas automatizadas y los casos de prueba bien redactados pueden reducir la probabilidad de una regresión.
Se han propuesto técnicas que intentan evitar que se introduzcan regresiones en el software en varias etapas de desarrollo, que se describen a continuación.
Para evitar que el usuario final vea regresiones después del lanzamiento, los desarrolladores ejecutan pruebas de regresión con regularidad después de que se introducen cambios en el software. Estas pruebas pueden incluir pruebas unitarias para capturar regresiones locales, así como pruebas de integración para capturar regresiones remotas. [6] Las técnicas de prueba de regresión a menudo aprovechan los casos de prueba existentes para minimizar el esfuerzo involucrado en su creación. [7] Sin embargo, debido al volumen de estas pruebas existentes, a menudo es necesario seleccionar un subconjunto representativo, utilizando técnicas como la priorización de casos de prueba .
Para detectar regresiones de rendimiento, las pruebas de rendimiento del software se ejecutan de forma regular, para monitorear el tiempo de respuesta y las métricas de uso de recursos del software después de cambios posteriores. [8] A diferencia de las pruebas de regresión funcional, los resultados de las pruebas de rendimiento están sujetos a variaciones , es decir, los resultados pueden diferir entre las pruebas debido a la variación en las mediciones de rendimiento; como resultado, se debe tomar una decisión sobre si un cambio en las cifras de rendimiento constituye una regresión, en función de la experiencia y las demandas del usuario final. En ocasiones, se utilizan enfoques como las pruebas de significación estadística y la detección de puntos de cambio para ayudar en esta decisión. [9]
Dado que depurar y localizar la causa raíz de una regresión de software puede ser costoso, [10] [11] también existen algunos métodos que intentan evitar que las regresiones se envíen al repositorio de código en primer lugar. Por ejemplo, Git Hooks permite a los desarrolladores ejecutar scripts de prueba antes de que los cambios de código se confirmen o se envíen al repositorio de código. [12] Además, el análisis del impacto del cambio se ha aplicado al software para predecir el impacto de un cambio de código en varios componentes del programa y para complementar la selección y priorización de casos de prueba. [13] [14] Linters de softwaretambién se agregan a menudo para confirmar ganchos para garantizar un estilo de codificación consistente, minimizando así los problemas de estilo que pueden hacer que el software sea propenso a regresiones. [15]