regresión de software

Para evitar que el usuario final vea regresiones después del lanzamiento, los desarrolladores ejecutan regularmente pruebas de regresión después de introducir cambios en el software. Estas pruebas pueden incluir pruebas unitarias para detectar regresiones locales, así como pruebas de integración para detectar regresiones remotas. ^{[ 6 ]} Las técnicas de pruebas de regresión a menudo aprovechan los casos de prueba existentes para minimizar el esfuerzo que implica crearlos. ^{[ 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, se realizan pruebas de rendimiento de software periódicamente para monitorizar el tiempo de respuesta y las métricas de uso de recursos del software tras los cambios posteriores. ^{[ 8 ]} A diferencia de las pruebas de regresión funcional, los resultados de las pruebas de rendimiento están sujetos a varianza ; es decir, los resultados pueden diferir entre pruebas debido a la varianza en las mediciones de rendimiento. Por consiguiente, es necesario decidir si un cambio en los valores de rendimiento constituye una regresión, basándose en 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 facilitar 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 incorporen al repositorio de código . Por ejemplo, los Git Hooks permiten a los desarrolladores ejecutar scripts de prueba antes de que los cambios de código se confirmen o se envíen al repositorio. ^{[ 12 ]} Además, el análisis de impacto de cambios 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 ]} Los linters de software también se suelen añadir a los ganchos de confirmación para garantizar un estilo de codificación coherente, minimizando así los problemas de estilo que pueden hacer que el software sea propenso a regresiones. ^{[ 15 ]}

Una técnica común para localizar regresiones funcionales es la bisección , que toma como entrada una confirmación con errores y una confirmación que funcionaba previamente, e intenta encontrar la causa raíz mediante una búsqueda binaria en las confirmaciones intermedias. ^{[ 16 ]} Los sistemas de control de versiones como Git y Mercurial ofrecen métodos integrados para realizar la bisección en un par de confirmaciones. ^{[ 17 ] [ 18 ]}

Otras opciones incluyen asociar directamente el resultado de una prueba de regresión con cambios en el código; ^{[ 19 ]} establecer puntos de ruptura de divergencia; ^{[ 20 ]} o utilizar análisis incremental de flujo de datos , que identifica casos de prueba, incluidos los que fallan, que son relevantes para un conjunto de cambios en el código, ^{[ 21 ]} entre otros.

El análisis de rendimiento mide el desempeño y el uso de recursos de varios componentes de un programa, y ​​se utiliza para generar datos útiles para depurar problemas de rendimiento. En el contexto de las regresiones de rendimiento del software, los desarrolladores suelen comparar los árboles de llamadas (también conocidos como "líneas de tiempo") generados por los analizadores de rendimiento tanto para la versión con errores como para la versión que funcionaba anteriormente, y existen mecanismos para simplificar esta comparación. ^{[ 22 ]} Las herramientas de desarrollo web suelen proporcionar a los desarrolladores la capacidad de registrar estos perfiles de rendimiento. ^{[ 23 ] [ 24 ]}

El registro de eventos también ayuda a localizar la regresión del rendimiento y, de forma similar a los árboles de llamadas, los desarrolladores pueden comparar registros de rendimiento sistemáticamente ubicados de múltiples versiones del mismo software. ^{[ 25 ]} Existe una disyuntiva al agregar estos registros de rendimiento, ya que agregar muchos registros puede ayudar a los desarrolladores a identificar qué partes del software están experimentando regresión a niveles más pequeños, mientras que agregar solo unos pocos registros también reducirá la sobrecarga al ejecutar el programa. ^{[ 26 ]}

Otros enfoques incluyen escribir pruebas unitarias que tengan en cuenta el rendimiento para ayudar con la localización, ^{[ 27 ]} y clasificar los subsistemas en función de las desviaciones del contador de rendimiento. ^{[ 28 ]} La bisección también se puede reutilizar para regresiones de rendimiento considerando como errores las confirmaciones que rinden por debajo (o por encima) de un cierto valor de referencia, y tomando el lado izquierdo o el derecho de las confirmaciones en función de los resultados de esta comparación.