PROFILPELAJAR.COM

Regresie software

O regresie software este un tip de bug software în care un feature care anterior funcționa încetează să funcționeze corect. Aceasta se poate întâmpla după ce se aplică modificări codului sursă al software-ului, inclusiv prin adăugarea de noi feature-uri⁠(d) sau prin remedieri de buguri.[1] Acestea pot fi introduse însă și prin modificări ale mediului în care rulează software-ul, cum ar fi actualizări de sistem, patch-uri de sistem⁠(d) sau trecerea la sau încetarea orei de vară.[2] O regresie de performanță este o situație în care software-ul funcționează în continuare corect, dar funcționează mai lent sau utilizează mai multă memorie sau altfel de resurse decât înainte.[3] În practică au fost identificate diverse tipuri de regresii software, între care:[4]

  • Locală – o modificare introduce un bug nou în modulul sau componenta modificată.
  • Remote – o modificare a unei părți a software-ului întrerupe funcționalitatea unui alt modul sau componentă.
  • Unmasked – o modificare expune o eroare deja existentă care până atunci nu avea niciun efect.

Regresiile sunt adesea cauzate de hotfixuri incluse în patch-uri. O abordare pentru a evita acest tip de problemă este testarea de regresie⁠(d). Un plan de test⁠(d) conceput corespunzător își propune să prevină această posibilitate înainte de lansarea oricărui software.[5] Testarea automată și cazurile de test⁠(d) bine scrise pot reduce probabilitatea unei regresii.

Prevenire și detectare

Au fost propuse tehnici concepute să prevină introducerea regresiilor în software în diferite etape de dezvoltare, așa cum este prezentat mai jos.

Înainte de lansare

Pentru a evita ca regresiile să fie văzute de utilizatorul final⁠(d) după lansare, dezvoltatorii rulează în mod regulat teste de regresie⁠(d) după ce sunt introduse modificări în software. Aceste teste pot include teste unitare⁠(d) pentru a detecta regresiile locale, precum și teste de integrare⁠(d) pentru a detecta regresiile la distanță.[6] Tehnicile de testare de regresie utilizează adesea cazurile de testare existente pentru a minimiza efortul implicat în crearea lor.[7] Cu toate acestea, din cauza volumului acestor teste existente, este adesea necesar să se selecteze o submulțime reprezentativă a lor, folosind tehnici precum prioritizarea cazurilor de test.

Pentru detectarea regresiilor de performanță, se execută regulat teste de performanță ale software-ului⁠(d), pentru a monitoriza timpul de răspuns și indicatorii de utilizare a resurselor software-ului după modificările ulterioare.[8] Spre deosebire de testele de regresie funcțională, rezultatele testelor de performanță sunt supuse varianței – adică rezultatele pot fi diferite de la un test la altul din cauza variației măsurătorilor de performanță; prin urmare, trebuie luată o decizie cu privire la faptul dacă o modificare a cifrelor de performanță constituie o regresie, pe baza experienței și a cerințelor utilizatorului final. Abordări precum testarea ipotezelor statistice și detectarea punctelor de schimbare⁠(d) sunt uneori utilizate pentru a ajuta la luarea acestei decizii.[9]

Înainte de commit

Întrucât debuggingul⁠(d) și localizarea cauzei principale a unei regresii software pot fi costisitoare,[10][11] există și unele metode care încearcă să prevină în primul rând commiterea regresiilor în depozitul de cod. De exemplu, Git Hooks permit dezvoltatorilor să ruleze scripturi de testare înainte ca modificările de cod să fie commise sau trimise în depozitul de cod.[12] În plus, se rulează o analiză de impact a modificărilor⁠(d) pentru a prezice impactul unei modificări de cod asupra diferitelor componente ale programului și pentru a suplimenta selecția și prioritizarea cazurilor de testare.[13][14] De asemenea, linterele software⁠(d) sunt adesea adăugate la hook-urile de commit pentru a asigura un stil de codare consistent, reducând astfel la minimum problemele stilistice care pot face software-ul să fie predispus la regresii.[15]

Localizare

Multe dintre tehnicile utilizate pentru a găsi cauza principală a erorilor software care nu sunt de tip regresie pot fi folosite și pentru debugul regresiilor software, inclusiv debugging cu breakpoints⁠(d), debugging cu afișare de mesaje și slicing⁠(d).

Regresii funcționale

O tehnică obișnuită utilizată pentru localizarea regresiilor funcționale este bisecția⁠(d), care începe cu un commit care a introdus eroarea și cu un commit la care se știa ca problema nu se manifestă. Tehnica presupune efectuarea unei căutări binare prin commituri.[16] Sistemele de control al versiunilor, cum ar fi Git și Mercurial, oferă modalități integrate de a efectua bisecția pe o anumită pereche de commit-uri.[17][18]

Alte opțiuni includ asocierea directă a rezultatului unui test de regresie cu modificările de cod;[19] setarea punctelor de întrerupere a divergenței;[20] sau utilizarea analizei incrementale a fluxului de date⁠(d), care identifică cazurile de test – inclusiv cele eșuate – care sunt relevante pentru un set de modificări de cod,[21] printre altele.

Regresii de performanță

Profilarea⁠(d) măsoară performanța și utilizarea resurselor diferitelor componente ale unui program și este utilizată pentru a genera date utile în depanarea problemelor de performanță. În contextul regresiilor de performanță software, dezvoltatorii compară adesea arborii de apeluri⁠(d) (cunoscuți și sub denumirea de timeline-uri) generați de profilere atât pentru versiunea cu erori, cât și pentru versiunea funcțională anterioară, și există mecanisme pentru a simplifica această comparație.[22] Instrumentele de dezvoltare web⁠(d) oferă de obicei dezvoltatorilor posibilitatea de a înregistra aceste profiluri de performanță.[23][24]

Logurile ajută și la localizarea regresiei de performanță și, similar arborilor de apeluri, dezvoltatorii pot compara logurile de performanță plasate sistematic pe mai multe versiuni ale aceluiași software.[25] Există un compromis atunci când se adaugă aceste loguri de performanță, deoarece adăugarea de loguri multe poate ajuta dezvoltatorii să identifice cu granularitate mai fină care porțiuni ale software-ului regresează, în timp ce adăugarea de loguri puține va reduce costurile generale de execuție a programului.[26]

Abordările suplimentare includ scrierea de teste unitare conștiente de performanță pentru a ajuta la localizare[27] și clasificarea subsistemelor pe baza abaterilor contorului de performanță.[28] Bisecția poate fi reutilizată și pentru regresii de performanță, considerând commit-urile care au performanțe sub (sau peste) o anumită valoare de referință ca fiind cele cu eroare și luând fie partea stângă, fie cea dreaptă a listei de commituri în baza rezultatelor acestei comparații.

Note

  1. ^ Wong, W. Eric; Horgan, J.R.; London, Saul; Agrawal, Hira (). Proceedings of the Eighth International Symposium on Software Reliability Engineering (ISSRE 97). IEEE. doi:10.1109/ISSRE.1997.630875. ISBN 0-8186-8120-9. 
  2. ^ Yehudai, Amiram; Tyszberowicz, Shmuel; Nir, Dor (). Locating Regression Bugs. Haifa Verification Conference. pp. 218–234. doi:10.1007/978-3-540-77966-7_18. 
  3. ^ Shang, Weiyi; Hassan, Ahmed E.; Nasser, Mohamed; Flora, Parminder (). Automated Detection of Performance Regressions Using Regression Models on Clustered Performance Counters. ICPE '15: Proceedings of the 6th ACM/SPEC International Conference on Performance Engineering. ACM. pp. 15–26. doi:10.1145/2668930.2688052. ISBN 978-1-4503-3248-4. 
  4. ^ Henry, Jean-Jacques Pierre (). The Testing Network: An Integral Approach to Test Activities in Large Software Projects. Springer Science & Business Media. p. 74. ISBN 978-3-540-78504-0. 
  5. ^ Richardson, Jared; Gwaltney, William Jr (). Ship It! A Practical Guide to Successful Software Projects. Raleigh, NC: The Pragmatic Bookshelf. pp. 32, 193. ISBN 978-0-9745140-4-8. 
  6. ^ Leung, Hareton K.N.; White, Lee (noiembrie 1990). „A study of integration testing and software regression at the integration level”. Proceedings of the International Conference on Software Maintenance. San Diego, CA, USA: IEEE. doi:10.1109/ICSM.1990.131377. ISBN 0-8186-2091-9. 
  7. ^ Rothermel, Gregg; Harrold, Mary Jean; Dedhia, Jeinay (). „Regression test selection for C++ software”Necesită abonament cu plată. Software Testing, Verification and Reliability (în engleză). 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, E.J.; Vokolos, F.I. (decembrie 2000). „Experience with performance testing of software systems: issues, an approach, and case study”. 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 (). „The Use of Change Point Detection to Identify Software Performance Regressions in a Continuous Integration System”. Proceedings of the International Conference on Performance Engineering. Association for Computing Machinery. pp. 67–75. doi:10.1145/3358960.3375791. ISBN 978-1-4503-6991-6. 
  10. ^ Nistor, Adrian; Jiang, Tian; Tan, Lin (mai 2013). „Discovering, reporting, and fixing performance bugs”. Proceedings of the Working Conference on Mining Software Repositories (MSR). pp. 237–246. doi:10.1109/MSR.2013.6624035. ISBN 978-1-4673-2936-1. 
  11. ^ Agarwal, Pragya; Agrawal, Arun Prakash (). „Fault-localization techniques for software systems: a literature review”Necesită abonament cu plată. ACM SIGSOFT Software Engineering Notes. 39 (5): 1–8. doi:10.1145/2659118.2659125. ISSN 0163-5948. 
  12. ^ „Git - Git Hooks”. git-scm.com. Accesat în . 
  13. ^ Orso, Alessandro; Apiwattanapong, Taweesup; Harrold, Mary Jean (). „Leveraging field data for impact analysis and regression testing”Necesită abonament cu plată. ACM SIGSOFT Software Engineering Notes. 28 (5): 128–137. doi:10.1145/949952.940089. ISSN 0163-5948. 
  14. ^ Qu, Xiao; Acharya, Mithun; Robinson, Brian (septembrie 2012). „Configuration selection using code change impact analysis for regression testing”. Proceedings of the International Conference on Software Maintenance. pp. 129–138. doi:10.1109/ICSM.2012.6405263. ISBN 978-1-4673-2312-3. 
  15. ^ Tómasdóttir, Kristín Fjóla; Aniche, Mauricio; van Deursen, Arie (octombrie 2017). „Why and how JavaScript developers use linters”. Proceedings of the International Conference on Automated Software Engineering. pp. 578–589. doi:10.1109/ASE.2017.8115668. ISBN 978-1-5386-2684-9. 
  16. ^ Gross, Thomas (). „Bisection Debugging”. Proceedings of the International Workshop on Automatic Debugging (în engleză). Linkøping University Electronic Press. pp. 185–191. 
  17. ^ „Git - git-bisect Documentation”. git-scm.com. Accesat în . 
  18. ^ „hg - bisect”. www.selenic.com. Mercurial. Accesat în . 
  19. ^ „Reading 11: Debugging”. web.mit.edu. MIT. 
  20. ^ Buhse, Ben; Wei, Thomas; Zang, Zhiqiang; Milicevic, Aleksandar; Gligoric, Milos (mai 2019). „VeDebug: Regression Debugging Tool for Java”. Proceedings of the International Conference on Software Engineering: Companion Proceedings (ICSE-Companion). pp. 15–18. doi:10.1109/ICSE-Companion.2019.00027. ISBN 978-1-7281-1764-5. 
  21. ^ Taha, A.-B.; Thebaut, S.M.; Liu, S.-S. (septembrie 1989). „An approach to software fault localization and revalidation based on incremental data flow analysis”. Proceedings of the Annual International Computer Software & Applications Conference. IEEE. pp. 527–534. doi:10.1109/CMPSAC.1989.65142. ISBN 0-8186-1964-3. 
  22. ^ Ocariza, Frolin S.; Zhao, Boyang (). „Localizing software performance regressions in web applications by comparing execution timelines”Necesită abonament cu plată. Software Testing, Verification and Reliability (în engleză). 31 (5). doi:10.1002/stvr.1750. ISSN 1099-1689. 
  23. ^ „Analyze runtime performance”. Chrome Developers (în engleză). Google. Accesat în . 
  24. ^ „Performance analysis reference - Microsoft Edge Development”. docs.microsoft.com (în engleză). Microsoft. Accesat în . 
  25. ^ Yao, Kundi; B. de Pádua, Guilherme; Shang, Weiyi; Sporea, Steve; Toma, Andrei; Sajedi, Sarah (). „Log4Perf: Suggesting Logging Locations for Web-based Systems' Performance Monitoring”. Proceedings of the International Conference on Performance Engineering. Association for Computing Machinery. pp. 127–138. doi:10.1145/3184407.3184416. ISBN 978-1-4503-5095-2. 
  26. ^ Li, Heng; Shang, Weiyi; Adams, Bram; Sayagh, Mohammed; Hassan, Ahmed E. (). „A Qualitative Study of the Benefits and Costs of Logging from Developers' Perspectives”. IEEE Transactions on Software Engineering. 47 (12): 2858–2873. doi:10.1109/TSE.2020.2970422. 
  27. ^ Heger, Christoph; Happe, Jens; Farahbod, Roozbeh (). „Automated root cause isolation of performance regressions during software development”. Proceedings of the International Conference on Performance Engineering. Association for Computing Machinery. pp. 27–38. doi:10.1145/2479871.2479879. ISBN 978-1-4503-1636-1. 
  28. ^ Malik, Haroon; Adams, Bram; Hassan, Ahmed E. (noiembrie 2010). „Pinpointing the Subsystems Responsible for the Performance Deviations in a Load Test”. Proceedings of the International Symposium on Software Reliability Engineering. pp. 201–210. doi:10.1109/ISSRE.2010.43. ISBN 978-1-4244-9056-1. 

Content Disclaimer

Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.

  1. The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
  2. There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
  3. It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
  4. Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
  5. Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.