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 en el 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 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] A menudo también se agregan linters de software 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]

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]

Otras opciones incluyen asociar directamente el resultado de una prueba de regresión con cambios de código; [19] establecimiento de puntos de interrupción de divergencia; [20] o el uso de análisis incremental de flujo de datos , 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 del software, los desarrolladores suelen comparar los árboles de llamadas (también conocidos como "líneas de tiempo") generados por los perfiladores 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 ofrecer a los desarrolladores la posibilidad 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 forma similar a los árboles de llamadas, los desarrolladores pueden comparar registros de rendimiento colocados sistemáticamente de varias 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á los gastos generales al ejecutar el programa. [26]

Los enfoques adicionales incluyen escribir pruebas unitarias conscientes del 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 las confirmaciones que funcionan por debajo (o por encima) de un determinado valor de referencia como con errores y tomando el lado izquierdo o derecho de las confirmaciones en función de los resultados de esta comparación.

Ver también

Referencias

  1. ^ Wong, W. Eric; Horgan, JR; Londres, Saúl; 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 de Software (ISSRE 97). IEEE. doi :10.1109/ISSRE.1997.630875. ISBN 0-8186-8120-9. S2CID  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 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 fallas 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, Mithun; 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 el monitoreo 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.