ソフトウェアの後戻り

ソフトウェアの後戻り英語: software regression)は、システムのアップグレード、システムの更新プログラム適用夏時間への変更などの特定のイベントの後で、機能が意図したとおりに機能しなくなるソフトウェアのバグのこと[1]ソフトウェアのリグレッション・後退・先祖返り、またはデグレード(degrade、デグレ)とも呼ばれる。ソフトウェアパフォーマンスのリグレッションは、ソフトウェアが正常に機能しているにもかかわらず、パフォーマンスが遅くなったり、以前よりも多くのメモリやリソースを使用したりする状況のこと[2]

リグレッションは、多くの場合、ソフトウェア更新プログラムに含まれているバグ修正によって引き起こされる。この種の問題を回避するためには、回帰テストを行うことが一つのアプローチとなる。適切に設計されたテスト計画英語版は、ソフトウェアをリリースする前にリグレッションの可能性を防ぐことを目的としている[3]自動化されたテストと適切に記述されたテストケースにより、リグレッションの可能性を減らすことができる。

ソフトウェアのリグレッションは、次の3つのタイプのいずれかになる。

  • ローカル – 変更により、変更されたモジュールやコンポーネントに新しいバグが発生する。
  • リモート – ソフトウェアの一部を変更することで、別のモジュールやコンポーネントの機能が損なわれる。
  • 露呈 – 変更により、変更前には影響がなかった既存のバグが露呈する。

予防と検出編集

これまでに、さまざまな開発段階でのリグレッションの導入を防止する技術が提案されてきた。以下に概略を説明する。

リリース前編集

リグレッションがエンドユーザーに現れるのを避ける目的で、ソフトウェアに変更が加えられた後、開発者はリグレッションテストを定期的に実行する。こうしたテストには、ローカルのリグレッションを発見するための単体テストと、リモートのリグレッションを発見するための統合テストがある[4]回帰テストの技法では、既存のテストケースを活用して、テストケースの作成に伴う労力を最小限に抑えることがよくある[5]。しかし、こうした既存のテストは量が多いため、多くの場合、テストケースの優先付けなどの技法を使用して代表的なサブセットを選択する必要がある。

性能のリグレッションを検出するために、後続の変更後のレスポンスタイムとリソース使用量のメトリクスを計測するソフトウェアパフォーマンステストが定期的に実行される[6]。機能の回帰テストとは異なり、パフォーマンステストの結果は分散する可能性がある。つまり、パフォーマンス測定値のばらつきにより、結果はテスト間で異なる場合がある。そのため、パフォーマンス数値の変化がリグレッションを構成するかどうかは、経験とエンドユーザーからの要求に基づいて決定する必要がある。この決定を支援するために、統計的有意性検定変化点検出英語版などのアプローチが使用されることもある[7]

コミット前編集

ソフトウェアのリグレッションでは、デバッグや根本的な原因の特定には高いコストがかかるため[8][9]、そもそもリグレッション自体がコードリポジトリにコミットされるのを防止する手法も存在する。たとえば、Git Hooksを利用すると、コードの変更をコミットまたはプッシュするときに自動的にテストスクリプトを実行できる[10]。また、コード変更がプログラムのさまざまなコンポーネントに与える影響を予測し、テストケースの選択と優先順位付けを補助とするために、変更の影響分析英語版も行われている[11][12]。コミットhookにはソフトウェアlinterもよく追加される[13]。linterにより、一貫したコードスタイルを保証することができ、リグレッションが起こりやすくなるスタイルの問題を最小化することができる[13]

脚注編集

  1. ^ Yehudai, Amiram; Tyszberowicz, Shmuel; Nir, Dor (2007). “Locating Regression Bugs”. Haifa Verification Conference. https://www.researchgate.net/publication/225437428 2018年3月10日閲覧。 
  2. ^ Shang, Weiyi; Hassan, Ahmed E.; Nasser, Mohamed; Flora, Parminder (11 December 2014). Automated Detection of Performance Regressions Using Regression Models on Clustered Performance Counters. https://sail.cs.queensu.ca/Downloads/ICPE2015_AutomatedDetectionofPerformanceRegressionsUsingRegressionModelsOnClusteredPerformanceCounters.pdf#page=1. 
  3. ^ Richardson, Jared; Gwaltney, William Jr (2006). Ship It! A Practical Guide to Successful Software Projects. Raleigh, NC: The Pragmatic Bookshelf. pp. 32, 193. ISBN 978-0-9745140-4-8. https://archive.org/details/shipitpracticalg0000rich/page/32 
  4. ^ 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. https://ieeexplore.ieee.org/document/131377 
  5. ^ 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. https://onlinelibrary.wiley.com/doi/abs/10.1002/1099-1689(200006)10:2%3C77::AID-STVR197%3E3.0.CO;2-E. 
  6. ^ 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. https://ieeexplore.ieee.org/document/888628. 
  7. ^ Daly, David; Brown, William; Ingo, Henrik; O'Leary, Jim; Bradford, David (20 April 2020). “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. https://dl.acm.org/doi/abs/10.1145/3358960.3375791 
  8. ^ Nistor, Adrian; Jiang, Tian; Tan, Lin (May 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. https://ieeexplore.ieee.org/document/6624035 
  9. ^ Agarwal, Pragya; Agrawal, Arun Prakash (17 September 2014). “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. https://dl.acm.org/doi/abs/10.1145/2659118.2659125. 
  10. ^ Git - Git Hooks”. git-scm.com. 2021年11月7日閲覧。
  11. ^ Orso, Alessandro; Apiwattanapong, Taweesup; Harrold, Mary Jean (1 September 2003). “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. https://dl.acm.org/doi/abs/10.1145/949952.940089. 
  12. ^ 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. pp. 129–138. doi:10.1109/ICSM.2012.6405263. ISBN 978-1-4673-2312-3. https://ieeexplore.ieee.org/document/6405263 
  13. ^ a b 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. pp. 578–589. doi:10.1109/ASE.2017.8115668. ISBN 978-1-5386-2684-9. https://ieeexplore.ieee.org/document/8115668 

関連項目編集