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 funcionó 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 todavía 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 incluidas en los parches de software . Una forma de evitar este tipo de problemas son las pruebas de regresión . Un plan de pruebas diseñado adecuadamente tiene como objetivo evitar 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.

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 las regresiones después del lanzamiento, los desarrolladores ejecutan periódicamente 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 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, se ejecutan pruebas de rendimiento del 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 desempeño están sujetos a variación , es decir, los resultados pueden diferir entre las pruebas debido a la variación en las mediciones de desempeño; como resultado, se debe tomar una decisión sobre si un cambio en las cifras de rendimiento constituye una regresión, basándose en la experiencia y las demandas del usuario final. A veces 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]

antes de comprometerse

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] Los linters de software también se agregan a menudo para confirmar los 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]

Localización

Muchas de las técnicas utilizadas 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, incluida la depuración de puntos de interrupción , la depuración de impresión y la divisió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 funcionó 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]

Other options include directly associating the result of a regression test with code changes;[19] setting divergence breakpoints;[20] or using incremental data-flow analysis, which identifies test cases - including failing ones - that are relevant to a set of code changes,[21] among others.

Performance regressions

Profiling measures the performance and resource usage of various components of a program, and is used to generate data useful in debugging performance issues. In the context of software performance regressions, developers often compare the call trees (also known as "timelines") generated by profilers for both the buggy version and the previously working version, and mechanisms exist to simplify this comparison.[22] Web development tools typically provide developers the ability to record these performance profiles.[23][24]

Logging also helps with performance regression localization, and similar to call trees, developers can compare systematically-placed performance logs of multiple versions of the same software.[25] A tradeoff exists when adding these performance logs, as adding many logs can help developers pinpoint which portions of the software are regressing at smaller granularities, while adding only a few logs will also reduce overhead when executing the program.[26]

Additional approaches include writing performance-aware unit tests to help with localization,[27] and ranking subsystems based on performance counter deviations.[28] Bisection can also be repurposed for performance regressions by considering commits that perform below (or above) a certain baseline value as buggy, and taking either the left or the right side of the commits based on the results of this comparison.

See also

References

  1. ^ Wong, W. Eric; Horgan, J.R.; London, Saul; Agrawal, Hira (1997). "A Study of Effective Regression Testing in Practice". Proceedings of the Eighth International Symposium on Software Reliability Engineering (ISSRE 97). IEEE. doi:10.1109/ISSRE.1997.630875. ISBN 0-8186-8120-9. S2CID 2911517.
  2. ^ Yehudai, Amiram; Tyszberowicz, Shmuel; Nir, Dor (2007). Locating Regression Bugs. Haifa Verification Conference. doi:10.1007/978-3-540-77966-7_18. Retrieved 10 March 2018.
  3. ^ Shang, Weiyi; Hassan, Ahmed E.; Nasser, Mohamed; Flora, Parminder (11 de diciembre de 2014). "Detección automatizada 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}}: Citar diario requiere |journal=( ayuda )
  4. ^ Henry, Jean-Jacques Pierre (2008). La red de pruebas: un enfoque integral para las actividades de prueba en grandes proyectos de software . Medios de ciencia y negocios de Springer. pag. 74.ISBN _ 978-3540785040.
  5. ^ Richardson, Jared; Gwaltney, William Jr (2006). ¡Envíalo! Una guía práctica para proyectos de software exitosos. Raleigh, Carolina del Norte: La estantería pragmática. págs.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, California, Estados Unidos: IEEE. doi :10.1109/ICSM.1990.131377. ISBN 0-8186-2091-9. S2CID  62583582.
  7. ^ Rothermel, Gregg; Harrold, María Jean; Dedhia, Jeinay (2000). "Selección de prueba de regresión para software C++". Pruebas, verificación y confiabilidad de software . 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 en pruebas de rendimiento de sistemas de software: problemas, enfoque y estudio de caso". Transacciones IEEE sobre ingeniería de software . 26 (12): 1147-1156. doi : 10.1109/32.888628. ISSN  1939-3520.
  9. ^ Daly, David; Marrón, Guillermo; 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 de rendimiento del software en un sistema de integración continua". Actas de la Conferencia Internacional sobre Ingeniería del Rendimiento. Asociación para Maquinaria de Computación. págs. 67–75. doi :10.1145/3358960.3375791. ISBN 978-1-4503-6991-6. S2CID  211677818.
  10. ^ Nistor, Adrián; Jiang, Tian; Tan, Lin (mayo de 2013). "Descubrir, informar y corregir errores de rendimiento". Actas de la Conferencia de Trabajo sobre Repositorios de Software Minero (MSR). págs. 237–246. doi :10.1109/MSR.2013.6624035. ISBN 978-1-4673-2936-1. S2CID  12773088.
  11. ^ Agarwal, Praga; 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". Notas de ingeniería de software de ACM SIGSOFT . 39 (5): 1–8. doi :10.1145/2659118.2659125. ISSN  0163-5948. S2CID  12101263.
  12. ^ "Git - Ganchos de Git". git-scm.com . Consultado el 7 de noviembre de 2021 .
  13. ^ Orso, Alejandro; Apiwattanapong, Taweesup; Harrold, Mary Jean (1 de septiembre de 2003). "Aprovechamiento de datos de campo para análisis de impacto y 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, Mithún; Robinson, Brian (septiembre de 2012). "Selección de configuración mediante análisis de impacto de 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 utilizan 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. S2CID  215750004.
  16. ^ Gross, Thomas (10 de septiembre de 1997). "Depuración de bisección". 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 - bisectar". 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. S2CID  174799830.
  21. ^ Taha, AB; 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 de flujo de datos incremental". Actas de la Conferencia Anual Internacional de Aplicaciones y Software Informáticos. IEEE. págs. 527–534. doi :10.1109/CMPSAC.1989.65142. ISBN 0-8186-1964-3. S2CID  41978046.
  22. ^ Ocariza, Frolín S.; Zhao, Boyang (2021). "Localización de regresiones de rendimiento de software en aplicaciones web mediante la comparación de cronogramas de ejecución". Pruebas, verificación y confiabilidad de software . 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 Padua, Guilherme; Shang, Weiyi; Espora, 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 web". Actas de la Conferencia Internacional sobre Ingeniería del Rendimiento. Asociación para Maquinaria de Computación. págs. 127-138. doi :10.1145/3184407.3184416. ISBN 978-1-4503-5095-2. S2CID  4557038.
  26. ^ Li, Heng; Shang, Weiyi; Adams, Bram; Sayagh, Mahoma; Hassan, Ahmed E. (30 de enero de 2020). "Un estudio cualitativo de los beneficios y costos de la tala desde la perspectiva de los desarrolladores". Transacciones IEEE sobre ingeniería de software . 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 del Rendimiento. Asociación para Maquinaria de Computación. págs. 27–38. doi :10.1145/2479871.2479879. ISBN 978-1-4503-1636-1. S2CID  2593603.
  28. ^ Malik, Harún; 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 de software. págs. 201–210. doi :10.1109/ISSRE.2010.43. ISBN 978-1-4244-9056-1. S2CID  17306870.