stringtranslate.com

Regresión de software

Una regresión de software es un tipo de error de software en el que una característica que funcionaba 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 características y correcciones de errores. [1] También pueden introducirse por cambios en el entorno en el que se ejecuta el software, como actualizaciones del sistema, parches del sistema o un cambio en el 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 lo hace más lentamente o usa más memoria o recursos que antes. [3] Se han identificado varios tipos de regresiones de software en la práctica, incluidos los siguientes: [4]

Las regresiones suelen ser causadas por correcciones de errores incluidas en parches de software . Un enfoque para evitar este tipo de problemas son las pruebas de regresión . Un plan de pruebas correctamente diseñado tiene como objetivo evitar esta posibilidad antes de lanzar cualquier software. [5] Las pruebas automatizadas y los casos de prueba bien escritos pueden reducir la probabilidad de una regresión.

Prevención y detección

Se han propuesto técnicas que intentan evitar que se introduzcan regresiones en el software en diversas etapas de desarrollo, como se describe a continuación.

Antes del lanzamiento

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 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, se realizan pruebas de rendimiento de software 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 variación , es decir, los resultados pueden diferir entre pruebas debido a la variación en las mediciones de rendimiento; como resultado, se debe tomar una decisión sobre si un cambio en los números de rendimiento constituye una regresión, en función de la experiencia y las demandas del usuario final. A veces se utilizan enfoques como pruebas de significación estadística y detección de puntos de cambio para ayudar en esta decisión. [9]

Antes de comprometerse

Dado que la depuración y la localización de la causa raíz de una regresión de software pueden resultar costosas, [10] [11] también existen algunos métodos que intentan evitar que las regresiones se confirmen en el 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 de los 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 las regresiones. [15]

Localización

Muchas de las técnicas que se utilizan para encontrar la causa raíz de los errores de software que no son de regresión también se pueden utilizar para depurar regresiones de software, incluidas la depuración de puntos de interrupción , la depuración de impresión y la segmentación de programas . Las técnicas que se describen a continuación se utilizan a menudo específicamente para depurar regresiones de software.

Regresiones funcionales

Una técnica común utilizada para localizar regresiones funcionales es la bisección , que toma como entrada tanto una confirmación con errores como una confirmación que funcionaba previamente, e intenta encontrar la causa raíz haciendo una búsqueda binaria en las confirmaciones intermedias. [16] Los sistemas de control de versiones como Git y Mercurial proporcionan formas integradas de realizar la bisección en un par determinado de confirmaciones. [17] [18]

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

Regresiones de rendimiento

La creación de perfiles mide el rendimiento 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 de software, los desarrolladores suelen comparar los árboles de llamadas (también conocidos como "líneas de tiempo") generados por los generadores de perfiles 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 también ayuda con la localización de la regresión del rendimiento y, de manera similar a los árboles de llamadas, los desarrolladores pueden comparar registros de rendimiento colocados sistemáticamente de múltiples versiones del mismo software. [25] Existe una compensación al agregar estos registros de rendimiento, ya que agregar muchos registros puede ayudar a los desarrolladores a identificar qué partes del software están retrocediendo en granularidades más pequeñas, 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 al considerar las confirmaciones que funcionan por debajo (o por encima) de un cierto valor de referencia como defectuosas y tomar el lado izquierdo o derecho de las confirmaciones en función de los resultados de esta comparación.

Véase también

Referencias

  1. ^ Wong, W. Eric; Horgan, JR; London, Saul; Agrawal, Hira (1997). "Un estudio de pruebas de regresión efectivas en la práctica". Actas del octavo simposio internacional sobre ingeniería de confiabilidad del software (ISSRE 97). IEEE. doi :10.1109/ISSRE.1997.630875. ISBN . 0-8186-8120-9. Número de identificación del sujeto  2911517.
  2. ^ Yehudai, Amiram; Tyszberowicz, Shmuel; Nir, Dor (2007). Localización de errores de regresión. Conferencia de verificación de Haifa. doi :10.1007/978-3-540-77966-7_18 . Consultado el 10 de marzo de 2018 .
  3. ^ Shang, Weiyi; Hassan, Ahmed E.; Nasser, Mohamed; Flora, Parminder (11 de diciembre de 2014). "Detección automática de regresiones de rendimiento mediante modelos de regresión en contadores de rendimiento agrupados" (PDF) . Archivado desde el original (PDF) el 13 de enero de 2021 . Consultado el 22 de diciembre de 2019 . {{cite journal}}: Requiere citar revista |journal=( ayuda )
  4. ^ Henry, Jean-Jacques Pierre (2008). La red de pruebas: un enfoque integral para las actividades de prueba en proyectos de software de gran envergadura . Springer Science & Business Media. pág. 74. ISBN 978-3540785040.
  5. ^ Richardson, Jared; Gwaltney, William Jr (2006). Ship It! Una guía práctica para proyectos de software exitosos. Raleigh, NC: The Pragmatic Bookshelf. pp. 32, 193. ISBN 978-0-9745140-4-8.
  6. ^ Leung, Hareton KN; White, Lee (noviembre de 1990). "Un estudio de pruebas de integración y regresión de software a nivel de integración". Actas de la Conferencia Internacional sobre Mantenimiento de Software. San Diego, CA, EE. UU.: IEEE. doi :10.1109/ICSM.1990.131377. ISBN 0-8186-2091-9.S2CID62583582  .​
  7. ^ Rothermel, Gregg; Harrold, Mary Jean; Dedhia, Jeinay (2000). "Selección de pruebas de regresión para software C++". Pruebas de software, verificación y confiabilidad . 10 (2): 77–109. doi :10.1002/1099-1689(200006)10:2<77::AID-STVR197>3.0.CO;2-E. ISSN  1099-1689.
  8. ^ Weyuker, EJ; Vokolos, FI (diciembre de 2000). "Experiencia con pruebas de rendimiento de sistemas de software: problemas, un enfoque y un estudio de caso". IEEE Transactions on Software Engineering . 26 (12): 1147–1156. doi :10.1109/32.888628. ISSN  1939-3520.
  9. ^ Daly, David; Brown, William; Ingo, Henrik; O'Leary, Jim; Bradford, David (20 de abril de 2020). "El uso de la detección de puntos de cambio para identificar regresiones del rendimiento del software en un sistema de integración continua". Actas de la Conferencia internacional sobre ingeniería del rendimiento. Association for Computing Machinery. págs. 67–75. doi :10.1145/3358960.3375791. ISBN 978-1-4503-6991-6. Número de identificación del sujeto  211677818.
  10. ^ Nistor, Adrian; Jiang, Tian; Tan, Lin (mayo de 2013). "Descubrimiento, notificación y corrección de errores de rendimiento". Actas de la Conferencia de trabajo sobre minería de repositorios de software (MSR). págs. 237–246. doi :10.1109/MSR.2013.6624035. ISBN 978-1-4673-2936-1. Número de identificación del sujeto  12773088.
  11. ^ Agarwal, Pragya; Agrawal, Arun Prakash (17 de septiembre de 2014). "Técnicas de localización de fallos para sistemas de software: una revisión de la literatura". ACM SIGSOFT Software Engineering Notes . 39 (5): 1–8. doi :10.1145/2659118.2659125. ISSN  0163-5948. S2CID  12101263.
  12. ^ "Git - Git Hooks". git-scm.com . Consultado el 7 de noviembre de 2021 .
  13. ^ Orso, Alessandro; Apiwattanapong, Taweesup; Harrold, Mary Jean (1 de septiembre de 2003). "Aprovechamiento de los datos de campo para el análisis de impacto y las pruebas de regresión". Notas de ingeniería de software de ACM SIGSOFT . 28 (5): 128–137. doi :10.1145/949952.940089. ISSN  0163-5948.
  14. ^ Qu, Xiao; Acharya, Mithun; Robinson, Brian (septiembre de 2012). "Selección de configuración mediante análisis del impacto de los cambios de código para pruebas de regresión". Actas de la Conferencia Internacional sobre Mantenimiento de Software. págs. 129–138. doi :10.1109/ICSM.2012.6405263. ISBN 978-1-4673-2312-3.S2CID 14928793  .
  15. ^ Tómasdóttir, Kristín Fjóla; Aniche, Mauricio; van Deursen, Arie (octubre de 2017). "Por qué y cómo los desarrolladores de JavaScript usan linters". Actas de la Conferencia Internacional sobre Ingeniería de Software Automatizada. págs. 578–589. doi :10.1109/ASE.2017.8115668. ISBN 978-1-5386-2684-9. Número de identificación del sujeto  215750004.
  16. ^ Gross, Thomas (10 de septiembre de 1997). "Depuración de bisecciones". Actas del Taller internacional sobre depuración automática. Prensa electrónica de la Universidad de Linkøping. págs. 185-191.
  17. ^ "Git - Documentación de git-bisect". git-scm.com . Consultado el 7 de noviembre de 2021 .
  18. ^ "hg - bisect". www.selenic.com . Mercurial . Consultado el 7 de noviembre de 2021 .
  19. ^ "Lectura 11: Depuración". web.mit.edu . MIT.
  20. ^ Buhse, Ben; Wei, Thomas; Zang, Zhiqiang; Milicevic, Aleksandar; Gligoric, Milos (mayo de 2019). "VeDebug: herramienta de depuración de regresión para Java". Actas de la Conferencia internacional sobre ingeniería de software: actas complementarias (ICSE-Companion). págs. 15-18. doi :10.1109/ICSE-Companion.2019.00027. ISBN 978-1-7281-1764-5.S2CID174799830  .​
  21. ^ Taha, A.-B.; Thebaut, SM; Liu, S.-S. (septiembre de 1989). "Un enfoque para la localización y revalidación de fallas de software basado en el análisis incremental del flujo de datos". Actas de la Conferencia Anual Internacional de Software y Aplicaciones Informáticas. IEEE. págs. 527–534. doi :10.1109/CMPSAC.1989.65142. ISBN . 0-8186-1964-3. Número de identificación del sujeto  41978046.
  22. ^ Ocariza, Frolin S.; Zhao, Boyang (2021). "Localización de regresiones de rendimiento de software en aplicaciones web mediante la comparación de líneas de tiempo de ejecución". Pruebas de software, verificación y confiabilidad . 31 (5): e1750. doi :10.1002/stvr.1750. ISSN  1099-1689. S2CID  225416138.
  23. ^ "Analizar el rendimiento en tiempo de ejecución". Desarrolladores de Chrome . Google . Consultado el 7 de noviembre de 2021 .
  24. ^ "Referencia de análisis de rendimiento - Desarrollo de Microsoft Edge". docs.microsoft.com . Microsoft . Consultado el 7 de noviembre de 2021 .
  25. ^ Yao, Kundi; B. de Pádua, Guilherme; Shang, Weiyi; Sporea, Steve; Toma, Andrei; Sajedi, Sarah (30 de marzo de 2018). "Log4Perf: Sugerencia de ubicaciones de registro para la supervisión del rendimiento de sistemas basados ​​en la Web". Actas de la Conferencia internacional sobre ingeniería del rendimiento. Association for Computing Machinery. págs. 127–138. doi :10.1145/3184407.3184416. ISBN 978-1-4503-5095-2. Número de identificación del sujeto  4557038.
  26. ^ Li, Heng; Shang, Weiyi; Adams, Bram; Sayagh, Mohammed; Hassan, Ahmed E. (30 de enero de 2020). "Un estudio cualitativo de los beneficios y costos del registro desde la perspectiva de los desarrolladores". IEEE Transactions on Software Engineering . 47 (12): 2858–2873. doi :10.1109/TSE.2020.2970422. S2CID  213679706.
  27. ^ Heger, Christoph; Happe, Jens; Farahbod, Roozbeh (21 de abril de 2013). "Aislamiento automatizado de la causa raíz de las regresiones de rendimiento durante el desarrollo de software". Actas de la Conferencia Internacional sobre Ingeniería de Rendimiento. Association for Computing Machinery. págs. 27–38. doi :10.1145/2479871.2479879. ISBN 978-1-4503-1636-1. Número de identificación del sujeto  2593603.
  28. ^ Malik, Haroon; Adams, Bram; Hassan, Ahmed E. (noviembre de 2010). "Identificación de los subsistemas responsables de las desviaciones de rendimiento en una prueba de carga". Actas del Simposio internacional sobre ingeniería de confiabilidad del software. págs. 201–210. doi :10.1109/ISSRE.2010.43. ISBN 978-1-4244-9056-1. Número de identificación del sujeto  17306870.