「ソフトウェアリグレッション」の版間の差分

2021年6月20日 (日) 15:35時点における版

2022年1月8日 (土) 12:48時点における版

1行目:

'''ソフトウェアの後戻り''' ([[英語（{{Lang-en|英]]: software regression) }}）は、システムのアップグレード、システムの[[パッチ|更新プログラム適用]]、[[夏時間]]への変更などの特定のイベントの後で、機能が意図したとおりに機能しなくなる[[バグ|ソフトウェアのバグ]]のこと<ref name="ibm-locating-bugs">{{Cite conference|last=Yehudai|first1=Amiram|last2=Tyszberowicz|first2=Shmuel|last3=Nir|first3=Dor|title=Locating Regression Bugs|url=https://www.researchgate.net/publication/225437428|conference=Haifa Verification Conference|conferenceurl=https://www.research.ibm.com/haifa/conferences/hvc2017/previous.shtml|year=2007|access-date=10 March 2018}}</ref>。 '''ソフトウェアのリグレッション・後退・先祖返り'''、または'''デグレード'''（degrade、デグレ）とも呼ばれる。'''ソフトウェアパフォーマンスのリグレッション'''は、ソフトウェアが正常に機能しているにもかかわらず、パフォーマンスが遅くなったり、以前よりも多くのメモリやリソースを使用したりする状況のこと<ref>{{Cite journal|last=Shang|first=Weiyi|last2=Hassan|first2=Ahmed E.|last3=Nasser|first3=Mohamed|last4=Flora|first4=Parminder|date=11 December 2014|title=Automated Detection of Performance Regressions Using Regression Models on Clustered Performance Counters|url=https://sail.cs.queensu.ca/Downloads/ICPE2015_AutomatedDetectionofPerformanceRegressionsUsingRegressionModelsOnClusteredPerformanceCounters.pdf#page=1}}</ref>。

リグレッションは、多くの場合、[[パッチ|ソフトウェア更新プログラム]]に含まれている[[ホットフィックス|バグ修正]]によって引き起こされる。この種の問題を回避するためには、[[回帰テスト]]を行うことが一つのアプローチとなる。適切に設計された[[テスト計画]]は、ソフトウェアをリリースする前にリグレッションの可能性を防ぐことを目的としている<ref>{{Cite book|last=Richardson|first=Jared|last2=Gwaltney, William Jr|title=Ship It! A Practical Guide to Successful Software Projects|url=https://archive.org/details/shipitpracticalg0000rich/page/32|year=2006|publisher=The Pragmatic Bookshelf|___location=Raleigh, NC|pages=[https://archive.org/details/shipitpracticalg0000rich/page/32 32, 193]|isbn=978-0-9745140-4-8}}</ref>。 [[テスト自動化|自動化されたテスト]]と適切に記述された[[テストケース]]により、リグレッションの可能性を減らすことができる。

8行目:

* '''リモート''' – ソフトウェアの一部を変更することで、別のモジュールやコンポーネントの機能が損なわれる。

* '''露呈''' – 変更により、変更前には影響がなかった既存のバグが露呈する。

== 予防と検出 ==

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

=== リリース前 ===

リグレッションが[[エンドユーザー]]に現れるのを避ける目的で、ソフトウェアに変更が加えられた後、開発者はリグレッションテストを定期的に実行する。こうしたテストには、ローカルのリグレッションを発見するための[[単体テスト]]と、リモートのリグレッションを発見するための[[統合テスト]]がある<ref>{{Cite book|last=Leung|first=Hareton K.N.|last2=White|first2=Lee|title=Proceedings of the International Conference on Software Maintenance|date=November 1990|publisher=IEEE|___location=San Diego, CA, USA|isbn=0-8186-2091-9|url=https://ieeexplore.ieee.org/document/131377|chapter=A study of integration testing and software regression at the integration level|doi=10.1109/ICSM.1990.131377}}</ref>。[[回帰テスト]]の技法では、既存のテストケースを活用して、テストケースの作成に伴う労力を最小限に抑えることがよくある<ref>{{Cite journal|last=Rothermel|first=Gregg|last2=Harrold|first2=Mary Jean|last3=Dedhia|first3=Jeinay|date=2000|title=Regression test selection for C++ software|url=https://onlinelibrary.wiley.com/doi/abs/10.1002/1099-1689(200006)10:2%3C77::AID-STVR197%3E3.0.CO;2-E|journal=Software Testing, Verification and Reliability|volume=10|issue=2|pages=77–109|language=en|DOI=10.1002/1099-1689(200006)10:2<77::AID-STVR197>3.0.CO;2-E|ISSN=1099-1689}}</ref>。しかし、こうした既存のテストは量が多いため、多くの場合、[[回帰テスト#%E3%83%86%E3%82%B9%E3%83%88%E3%82%B1%E3%83%BC%E3%82%B9%E3%81%AE%E5%84%AA%E5%85%88%E9%A0%86%E4%BD%8D%E4%BB%98%E3%81%91|テストケースの優先付け]]などの技法を使用して代表的なサブセットを選択する必要がある。

性能のリグレッションを検出するために、後続の変更後のレスポンスタイムとリソース使用量のメトリクスを計測する[[ソフトウェアパフォーマンステスト]]が定期的に実行される<ref>{{Cite journal|last=Weyuker|first=E.J.|last2=Vokolos|first2=F.I.|date=December 2000|title=Experience with performance testing of software systems: issues, an approach, and case study|url=https://ieeexplore.ieee.org/document/888628|journal=IEEE Transactions on Software Engineering|volume=26|issue=12|pages=1147–1156|DOI=10.1109/32.888628|ISSN=1939-3520}}</ref>。機能の回帰テストとは異なり、パフォーマンステストの結果は[[分散 (統計学)|分散]]する可能性がある。つまり、パフォーマンス測定値のばらつきにより、結果はテスト間で異なる場合がある。そのため、パフォーマンス数値の変化がリグレッションを構成するかどうかは、経験とエンドユーザーからの要求に基づいて決定する必要がある。この決定を支援するために、[[仮説検定|統計的有意性検定]]や{{Ill|変化点検出|en|change point detection}}などのアプローチが使用されることもある<ref>{{Cite book|last=Daly|title=Proceedings of the International Conference on Performance Engineering|chapter=The Use of Change Point Detection to Identify Software Performance Regressions in a Continuous Integration System|url=https://dl.acm.org/doi/abs/10.1145/3358960.3375791|pages=67–75|isbn=978-1-4503-6991-6|publisher=Association for Computing Machinery|date=20 April 2020|first5=David|first=David|last5=Bradford|first4=Jim|last4=O'Leary|first3=Henrik|last3=Ingo|first2=William|last2=Brown|doi=10.1145/3358960.3375791}}</ref>。

=== コミット前 ===

ソフトウェアのリグレッションでは、[[デバッグ]]や根本的な原因の特定には高いコストがかかるため<ref>{{Cite book|last=Nistor|first=Adrian|last2=Jiang|first2=Tian|last3=Tan|first3=Lin|title=Proceedings of the Working Conference on Mining Software Repositories (MSR)|date=May 2013|pages=237–246|url=https://ieeexplore.ieee.org/document/6624035|chapter=Discovering, reporting, and fixing performance bugs|doi=10.1109/MSR.2013.6624035|isbn=978-1-4673-2936-1}}</ref><ref>{{Cite journal|last=Agarwal|first=Pragya|last2=Agrawal|first2=Arun Prakash|date=17 September 2014|title=Fault-localization techniques for software systems: a literature review|url=https://dl.acm.org/doi/abs/10.1145/2659118.2659125|journal=ACM SIGSOFT Software Engineering Notes|volume=39|issue=5|pages=1–8|DOI=10.1145/2659118.2659125|ISSN=0163-5948}}</ref>、そもそもリグレッション自体が[[リポジトリ|コードリポジトリ]]にコミットされるのを防止する手法も存在する。たとえば、[[Git]] Hooksを利用すると、コードの変更をコミットまたはプッシュするときに自動的にテストスクリプトを実行できる<ref>{{Cite web|title=Git - Git Hooks|url=https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks|website=git-scm.com|accessdate=7 November 2021}}</ref>。また、コード変更がプログラムのさまざまなコンポーネントに与える影響を予測し、テストケースの選択と優先順位付けを補助とするために、{{Ill|変更の影響分析|en|Change impact analysis}}も行われている<ref>{{Cite journal|last=Orso|first=Alessandro|last2=Apiwattanapong|first2=Taweesup|last3=Harrold|first3=Mary Jean|date=1 September 2003|title=Leveraging field data for impact analysis and regression testing|url=https://dl.acm.org/doi/abs/10.1145/949952.940089|journal=ACM SIGSOFT Software Engineering Notes|volume=28|issue=5|pages=128–137|DOI=10.1145/949952.940089|ISSN=0163-5948}}</ref><ref>{{Cite book|last=Qu|first=Xiao|last2=Acharya|first2=Mithun|last3=Robinson|first3=Brian|title=Proceedings of the International Conference on Software Maintenance|date=September 2012|pages=129–138|url=https://ieeexplore.ieee.org/document/6405263|chapter=Configuration selection using code change impact analysis for regression testing|doi=10.1109/ICSM.2012.6405263|isbn=978-1-4673-2312-3}}</ref>。コミットhookには[[Lint|ソフトウェアlinter]]もよく追加される<ref name=":0">{{Cite book|last=Tómasdóttir|first=Kristín Fjóla|last2=Aniche|first2=Mauricio|last3=van Deursen|first3=Arie|title=Proceedings of the International Conference on Automated Software Engineering|date=October 2017|pages=578–589|url=https://ieeexplore.ieee.org/document/8115668|chapter=Why and how JavaScript developers use linters|doi=10.1109/ASE.2017.8115668|isbn=978-1-5386-2684-9}}</ref>。linterにより、一貫したコードスタイルを保証することができ、リグレッションが起こりやすくなるスタイルの問題を最小化することができる<ref name=":0" />。

== 脚注 ==