위키백과

소프트웨어 회귀

(회귀 버그에서 넘어옴)

소프트웨어 회귀(software regression)는 이전에는 작동했던 기능이 작동을 멈추는 소프트웨어 버그의 일종이다. 이는 새로운 기능의 추가 및 버그 수정을 포함하여 소프트웨어의 소스 코드에 변경 사항이 적용된 후에 발생할 수 있다.[1] 또한 시스템 업그레이드, 시스템 패치 또는 일광 절약 시간제 변경과 같은 소프트웨어가 실행 중인 환경의 변경으로 인해 발생할 수도 있다.[2] 소프트웨어 성능 회귀(software performance regression)는 소프트웨어가 여전히 올바르게 작동하지만 이전보다 더 느리게 수행되거나 더 많은 메모리나 자원을 사용하는 상황을 말한다.[3] 실제로 다음과 같은 다양한 유형의 소프트웨어 회귀가 확인되었다:[4]

  • 로컬 – 변경된 모듈 또는 구성 요소에 새로운 버그가 발생한다.
  • 원격 – 소프트웨어의 한 부분이 변경되면 다른 모듈이나 구성 요소의 기능이 손상된다.

회귀는 종종 소프트웨어 패치에 포함된 포괄적인 버그 수정으로 인해 발생한다. 이러한 종류의 문제를 방지하는 방법 중 하나는 회귀 테스트이다. 적절히 설계된 테스트 계획은 소프트웨어를 출시하기 전에 이러한 가능성을 방지하는 것을 목표로 한다.[5] 자동화된 테스트와 잘 작성된 테스트 케이스를 통해 회귀의 가능성을 줄일 수 있다.

예방과 감지

편집

다음과 같이 다양한 개발 단계에서 회귀가 소프트웨어에 발생하는 것을 방지하기 위한 기술이 제안되었다.

출시 이전

편집
  이 부분의 본문은 회귀 테스트입니다.

최종 사용자에게 릴리스 후 회귀가 나타나는 것을 방지하기 위해 개발자는 소프트웨어에 변경 사항이 적용된 후 회귀 테스트를 정기적으로 실행한다. 이러한 테스트에는 로컬 회귀를 포착하기 위한 단위 테스트와 원격 회귀를 포착하기 위한 통합 테스트가 포함된다.[6] 회귀 테스트 기술은 종종 기존 테스트 케이스를 활용하여 만드는 데 수반되는 노력을 최소화한다.[7] 그러나 이러한 기존 테스트의 양으로 인해 테스트 케이스 우선 순위 지정과 같은 기술을 사용하여 대표적인 하위 집합을 선택해야 하는 경우가 많다.

성능 회귀를 감지하기 위해 소프트웨어 성능 테스트를 정기적으로 실행하여 후속 변경 후 소프트웨어의 응답 시간 및 자원 사용량 메트릭을 모니터링한다.[8] 기능 회귀 테스트와 달리 성능 테스트의 결과는 분산의 영향을 받는다. 즉, 성능 측정의 분산으로 인해 테스트 간에 결과가 다를 수 있다. 성능 수치의 변화와 최종 사용자의 요구에 따라 회귀에 해당하는지 여부를 결정해야 한다. 이 결정을 돕기 위해 통계적 가설 검정과 변경점 감지와 같은 접근 방식이 사용되기도 한다.[9]

커밋 이전

편집

소프트웨어 회귀의 근본 원인을 디버깅하고 국소화하는 것은 비용이 많이 들 수 있기 때문에,[10][11] 애초에 회귀가 코드 저장소에 커밋되지 않도록 하는 몇 가지 방법들도 존재한다. 예를 들어 깃 훅을 사용하면 개발자가 코드 변경 사항을 커밋하거나 코드 리포지토리에 푸시하기 전에 테스트 스크립트를 실행할 수 있다.[12] 또한, 코드 변경이 프로그램의 다양한 구성 요소에 미치는 영향을 예측하고, 테스트 케이스 선택 및 우선 순위 지정을 보완하기 위해 변경 영향 분석이 소프트웨어에 적용되었다.[13][14] 또한 소프트웨어 린터는 일관된 코딩 스타일을 보장하기 위해 커밋 훅에 추가되는 경우가 많아 소프트웨어가 회귀하기 쉬운 스타일 문제를 최소화한다.[15]

국소화

편집

비회귀 소프트웨어 버그의 근본 원인을 찾는 데 사용되는 많은 기술들인 브레이크포인트 디버깅, 프린트 디버깅, 프로그램 슬라이싱 등은 소프트웨어 회귀 디버깅에도 사용할 수 있다. 아래에 설명된 기술은 종종 소프트웨어 회귀를 디버그하는 데에도 사용된다.

기능적 회귀

편집

기능 회귀를 국소화하는 데 사용되는 일반적인 기술은 버그가 있는 커밋과 이전에 작업한 커밋을 모두 입력으로 사용하고 그 사이의 커밋에 대해 이진 검색을 수행하여 근본 원인을 찾으려 하는 이분법이다.[16] 깃과 머큐리얼과 같은 버전 관리 시스템은 주어진 커밋 쌍에 대해 이분법을 수행할 수 있는 기본 제공 방법을 제공한다.[17][18]

다른 옵션으로는 회귀 테스트 결과를 코드 변경과 직접 연관시키는 것,[19] 분기 중단점을 설정하는 것,[20] 코드 변경과 관련된 테스트 케이스(실패한 것을 포함)를 식별하는 증분 데이터 흐름 분석을 사용하는 것[21] 등이 있다.

성능 회귀

편집

프로파일링은 프로그램의 다양한 구성 요소의 성능과 자원 사용량을 측정하며 성능 문제를 디버깅하는 데 유용한 데이터를 생성하는 데 사용된다. 소프트웨어 성능 회귀의 맥락에서 개발자는 버그가 있는 버전과 이전에 작동하던 버전 모두에 대해 프로파일러에서 생성된 호출 트리("타임라인"이라고도 함)를 종종 비교하며 이러한 비교를 단순화하는 메커니즘이 있다.[22] 웹 개발 도구는 일반적으로 개발자에게 이러한 성능 프로필을 기록할 수 있는 기능을 제공한다.[23][24]

로깅은 또한 성능 회귀 국소화에 도움이 되며 호출 트리와 유사하게 개발자는 동일한 소프트웨어의 여러 버전에 대해 체계적으로 배치된 성능 로그를 비교할 수 있다.[25]

이러한 성능 로그를 추가할 때 절충점이 존재하는데, 많은 로그를 추가하면 개발자가 소프트웨어의 어느 부분이 더 작은 단위에서 회귀하는지 정확히 찾아내는 데 도움이 될 수 있지만 몇 개의 로그만 추가하면 프로그램 실행 시 오버헤드가 감소할 수 있기 때문이다.[26] 추가적인 접근 방식에는 국소화에 도움이 되는 성능 인식 단위 테스트 작성[27] 및 성능 카운터 편차를 기준으로 하위 시스템 순위 지정 등이 있다.[28] 또한 이분법은 성능 회귀를 위해 특정 기준 값 이하(또는 그 이상)를 수행하는 커밋을 버그가 많은 것으로 간주하고 이 비교 결과에 기초하여 커밋의 왼쪽 또는 오른쪽을 취하는 것으로 사용할 수도 있다.

같이 보기

편집

각주

편집
  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. 2018년 3월 10일에 확인함. 
  3. ↑ Shang, Weiyi; Hassan, Ahmed E.; Nasser, Mohamed; Flora, Parminder (2014년 12월 11일). “Automated Detection of Performance Regressions Using Regression Models on Clustered Performance Counters” (PDF). 2021년 1월 13일에 원본 문서 (PDF)에서 보존된 문서. 2022년 4월 10일에 확인함. 
  4. ↑ Henry, Jean-Jacques Pierre (2008). 《The Testing Network: An Integral Approach to Test Activities in Large Software Projects》. Springer Science & Business Media. 74쪽. ISBN 978-3540785040. 
  5. ↑ Richardson, Jared; Gwaltney, William Jr (2006). 《Ship It! A Practical Guide to Successful Software Projects》. Raleigh, NC: The Pragmatic Bookshelf. 32, 193쪽. ISBN 978-0-9745140-4-8. 
  6. ↑ Leung, Hareton K.N.; White, Lee (November 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. S2CID 62583582. 
  7. ↑ Rothermel, Gregg; Harrold, Mary Jean; Dedhia, Jeinay (2000). “Regression test selection for C++ software”. 《Software Testing, Verification and Reliability》 (영어) 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. (December 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 (2020년 4월 20일). 〈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. 67–75쪽. doi:10.1145/3358960.3375791. ISBN 978-1-4503-6991-6. S2CID 211677818. 
  10. ↑ Nistor, Adrian; Jiang, Tian; Tan, Lin (May 2013). 〈Discovering, reporting, and fixing performance bugs〉. 《Proceedings of the Working Conference on Mining Software Repositories (MSR)》. 237–246쪽. doi:10.1109/MSR.2013.6624035. ISBN 978-1-4673-2936-1. S2CID 12773088. 
  11. ↑ Agarwal, Pragya; Agrawal, Arun Prakash (2014년 9월 17일). “Fault-localization techniques for software systems: a literature review”. 《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》. 2021년 11월 7일에 확인함. 
  13. ↑ Orso, Alessandro; Apiwattanapong, Taweesup; Harrold, Mary Jean (2003년 9월 1일). “Leveraging field data for impact analysis and regression testing”. 《ACM SIGSOFT Software Engineering Notes》 28 (5): 128–137. doi:10.1145/949952.940089. ISSN 0163-5948. 
  14. ↑ Qu, Xiao; Acharya, Mithun; Robinson, Brian (September 2012). 〈Configuration selection using code change impact analysis for regression testing〉. 《Proceedings of the International Conference on Software Maintenance》. 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 (October 2017). 〈Why and how JavaScript developers use linters〉. 《Proceedings of the International Conference on Automated Software Engineering》. 578–589쪽. doi:10.1109/ASE.2017.8115668. ISBN 978-1-5386-2684-9. 
  16. ↑ Gross, Thomas (1997년 9월 10일). 〈Bisection Debugging〉. 《Proceedings of the International Workshop on Automatic Debugging》 (영어). Linkøping University Electronic Press. 185–191쪽. 
  17. ↑ “Git - git-bisect Documentation”. 《git-scm.com》. 2021년 11월 7일에 확인함. 
  18. ↑ “hg - bisect”. 《www.selenic.com》. Mercurial. 2021년 11월 7일에 확인함. 
  19. ↑ “Reading 11: Debugging”. 《web.mit.edu》. MIT. 
  20. ↑ Buhse, Ben; Wei, Thomas; Zang, Zhiqiang; Milicevic, Aleksandar; Gligoric, Milos (May 2019). 〈VeDebug: Regression Debugging Tool for Java〉. 《Proceedings of the International Conference on Software Engineering: Companion Proceedings (ICSE-Companion)》. 15–18쪽. doi:10.1109/ICSE-Companion.2019.00027. ISBN 978-1-7281-1764-5. S2CID 174799830. 
  21. ↑ Taha, A.-B.; Thebaut, S.M.; Liu, S.-S. (September 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. 527–534쪽. doi:10.1109/CMPSAC.1989.65142. ISBN 0-8186-1964-3. S2CID 41978046. 
  22. ↑ Ocariza, Frolin S.; Zhao, Boyang (2021). “Localizing software performance regressions in web applications by comparing execution timelines”. 《Software Testing, Verification and Reliability》 (영어) 31 (5): e1750. doi:10.1002/stvr.1750. ISSN 1099-1689. S2CID 225416138. 
  23. ↑ “Analyze runtime performance”. 《Chrome Developers》 (영어). Google. 2021년 11월 7일에 확인함. 
  24. ↑ “Performance analysis reference - Microsoft Edge Development”. 《docs.microsoft.com》 (미국 영어). Microsoft. 2021년 11월 7일에 확인함. 
  25. ↑ Yao, Kundi; B. de Pádua, Guilherme; Shang, Weiyi; Sporea, Steve; Toma, Andrei; Sajedi, Sarah (2018년 3월 30일). 〈Log4Perf: Suggesting Logging Locations for Web-based Systems' Performance Monitoring〉. 《Proceedings of the International Conference on Performance Engineering》. Association for Computing Machinery. 127–138쪽. doi:10.1145/3184407.3184416. ISBN 978-1-4503-5095-2. S2CID 4557038. 
  26. ↑ Li, Heng; Shang, Weiyi; Adams, Bram; Sayagh, Mohammed; Hassan, Ahmed E. (2020년 1월 30일). “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. S2CID 213679706. 
  27. ↑ Heger, Christoph; Happe, Jens; Farahbod, Roozbeh (2013년 4월 21일). 〈Automated root cause isolation of performance regressions during software development〉. 《Proceedings of the International Conference on Performance Engineering》. Association for Computing Machinery. 27–38쪽. doi:10.1145/2479871.2479879. ISBN 978-1-4503-1636-1. S2CID 2593603. 
  28. ↑ Malik, Haroon; Adams, Bram; Hassan, Ahmed E. (November 2010). 〈Pinpointing the Subsystems Responsible for the Performance Deviations in a Load Test〉. 《Proceedings of the International Symposium on Software Reliability Engineering》. 201–210쪽. doi:10.1109/ISSRE.2010.43. ISBN 978-1-4244-9056-1. S2CID 17306870. 
원본 주소 "https://ko.wiki.x.io/w/index.php?title=소프트웨어_회귀&oldid=36786315"