回帰テスト
(回帰試験 から転送)
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2025/07/04 21:07 UTC 版)
|
この記事は別の言語から大ざっぱに翻訳されたものであり、場合によっては不慣れな翻訳者や機械翻訳によって翻訳されたものかもしれません。
|
回帰テスト (かいきテスト、英: regression testing) とは、以前にテストしたソフトウェアが変更後もまだ正しく動作することを、機能テストと非機能テストを再度実行して確認する作業のこと[1]。退行テスト、リグレッションテストとも呼ばれる。正しく動作しない場合、そのことを先祖返りと呼ぶ。回帰テストが必要になる可能性のある変更には、バグ修正、ソフトウェアの機能強化、構成変更、さらにはハード的な電子部品の置き換えなどある[2]。欠陥が見つかるたびに回帰テストの集合が大きくなる傾向があるため、しばしばテストの自動化を一緒に行う。テストするためのテストケースを決定するために、変更影響分析を実行することもある（非回帰分析[3] ）。
背景
ソフトウェアが更新または変更されたり、変更されたターゲットで再利用されたりすると、新しい障害の発生や古い障害の再発生が非常に一般的である。不十分なリビジョン管理手法（またはリビジョン管理における単純な人為的エラー）によって修正が失われるために、再出現が発生することがある。多くの場合、問題の修正は「脆弱」であり、最初に観察された狭いケースでは問題が修正されるが、ソフトウェアの存続期間中に発生する可能性のあるより一般的なケースでは修正されない。多くの場合、ある領域の問題を修正すると、別の領域でソフトウェアのバグが発生する。最後に、一部の機能が再設計されると、その機能の元の実装で行われたのと同じ間違いのいくつかが再設計で行われる場合がある。
そのため、ほとんどのソフトウェア開発の状況では、コーディングのベストプラクティスとして、バグの修正を行ったら、バグを再現させたテストを実行して、さらにプログラムに以降の変更を行ったときに定期的にプログラムへの同じテストを再実行することが挙げられている[4]。 これは、プログラミング手法を使用した手動テスト手順で実行できるが、多くの場合、自動テストツールを使用して実行される[5]。 このようなテストスイートには、テスト環境ですべての回帰テストケースを自動的に実行できるようにするソフトウェアツールが含まれる。一部のプロジェクトでは、自動システムをセットアップして、指定された間隔ですべての回帰テストを再実行し、障害を報告する（これは回帰または古いテストを意味する可能性がある）[6]。 一般的な戦略では、コンパイルが成功するたびに（小さなプロジェクトの場合）、毎晩、または週に1回、このようなシステムを実行する。これらの戦略は、外部ツールによって自動化できる。
回帰テストは、エクストリームプログラミングソフトウェア開発手法の不可欠な部分である。この方法では、設計ドキュメントは、ソフトウェア開発プロセスの各段階を通じて、ソフトウェアパッケージ全体の広範囲にわたる反復可能な自動テストに置き換えられる。回帰テストは、機能テストが終了した後に実行され、他の機能が機能していることを確認する。
企業の世界では、従来、回帰テストは、開発チームが作業を完了した後にソフトウェア品質保証チームによって実行されてきた。ただし、この段階で見つかった欠陥は、修正するのに最も費用がかかる。この問題は、単体テストによって対処されている。開発者は常に、開発サイクルの一環として、テストケースを書いているが、これらのテストケースは、一般的にどちらかだった機能テストや単体テストのみ意図成果を検証する。開発者テストでは、開発者は単体テストに集中し、ポジティブテストケースとネガティブテストケースの両方を含める必要がある[7]。
テクニック
回帰テスト手法は次のとおり。
すべてを再テスト
現在のプログラムのすべてのテストケースをチェックして、その整合性をチェックする。すべてのケースを再実行する必要があるためコストがかかるが、コードが変更されたためにエラーが発生しないことが保証される[8]。
回帰テストの選択
すべてを再テストするのとは異なり、この手法は、テストスイートの一部を選択するコストがすべてを再テストする手法よりも少ない場合、テストスイートの一部を実行する（すべてを再テストするコストがかかるため）[8]。
テストケースの優先順位付け
テストスイートの障害検出率を高めるために、テストケースに優先順位を付ける。テストケースの優先順位付け手法では、優先度の高いテストケースが、優先度の低いテストケースの前に実行されるようにテストケースをスケジュールする[8]。
テストケースの優先順位付けの種類
- 一般的な優先順位付け–後続のバージョンで有益となるテストケースに優先順位を付ける。
- バージョン固有の優先順位付け–ソフトウェアの特定のバージョンに関してテストケースに優先順位を付ける。
ハイブリッド
回帰テストの選択とテストケースの優先順位付けを組み合わせたもの[8]。
長所と短所
回帰テストは、ソフトウェアの既存の機能に変更が加えられた場合、またはソフトウェアにバグ修正がある場合に実行される。回帰テストは複数のアプローチで実現できる。すべてのアプローチをテストする場合、ソフトウェアに加えられた変更が、変更されていない既存の機能に影響を与えていないことを確認できる[9]。
ソフトウェア開発ライフサイクルが非常に短く、リソースが不足しており、ソフトウェアへの変更が非常に頻繁であるアジャイルソフトウェア開発では、回帰テストによって多くの不要なオーバーヘッドが発生する可能性がある[9]。
サードパーティのブラックボックスコンポーネントを使用する傾向があるソフトウェア開発環境では、サードパーティコンポーネントの変更がシステムの他の部分に干渉する可能性があるため、回帰テストの実行は難しい場合がある（そしてサードパーティで回帰テストを実行するパーティコンポーネントは不明なエンティティであるため、困難な場合がある）[9]。
用途
回帰テストは、プログラムの正当性をテストするためだけでなく、多くの場合、その出力の品質を追跡するためにも使用できる。 [10]たとえば、コンパイラの設計では、回帰テストでコードサイズと、テストスイートのケースをコンパイルして実行するのにかかる時間を追跡できる。
回帰テストは、機能テストまたは単体テストに分類できる。機能テストは、さまざまな入力を使用してプログラム全体を実行する。単体テストは、個々の関数、サブルーチン、またはオブジェクトメソッドを実行する。機能テストツールと単体テストツールはどちらも自動化される傾向があり、多くの場合、コンパイラスイートの一部ではないサードパーティ製品である。機能テストは、スクリプト化された一連のプログラム入力である場合があり、マウスの動きとクリックを制御するための自動化されたメカニズムが含まれる場合もある。単体テストは、コード自体内の個別の関数のセット、またはテスト対象のコードを変更せずにコードにリンクするドライバーレイヤーの場合がある。
関連項目
脚注
- ^ Basu, Anirban (2015). Software Quality Assurance, Testing and Metrics. PHI Learning. ISBN 978-81-203-5068-7
- ^ National Research Council Committee on Aging Avionics in Military Aircraft: Aging Avionics in Military Aircraft. The National Academies Press, 2001, page 2: ″Each technology-refresh cycle requires regression testing.″
- ^ Boulanger, Jean-Louis (2015). CENELEC 50128 and IEC 62279 Standards. Wiley. ISBN 978-1119122487
- ^ Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 73. ISBN 978-0-470-04212-0
- ^ Automate Regression Tests When Feasible, Automated Testing: Selected Best Practices, Elfriede Dustin, Safari Books Online
- ^ daVeiga (2008年2月6日). “Change Code Without Fear: Utilize a Regression Safety Net”. Dr. Dobb's Journal. 2020年12月21日閲覧。
- ^ Dudney (2004年12月8日). “Developer Testing Is 'In': An interview with Alberto Savoia and Kent Beck”. 2007年11月29日閲覧。
- ^ a b c d Duggal, Gaurav; Suri, Bharti (29 March 2008). Understanding Regression Testing Techniques. National Conference on Challenges and Opportunities. Mandi Gobindgarh, Punjab, India.
- ^ a b c Yoo, S.; Harman, M. (2010). “Regression testing minimization, selection and prioritization: a survey”. Software Testing, Verification and Reliability 22 (2): 67–120. doi:10.1002/stvr.430.
- ^ Kolawa. “Regression Testing, Programmer to Programmer”. Wrox. 2020年12月21日閲覧。
外部リンク
回帰試験 (Regression Test)
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/07/14 01:34 UTC 版)
「ソフトウェアテスト」の記事における「回帰試験 (Regression Test)」の解説
詳細は「回帰テスト」を参照 プログラムを修正・変更した場合に、過去に実施したテストを再度実施することを回帰試験 (英: regression test) 又は退行テストという。修正前の試験に再度合格するかどうか、他の機能に影響与えていないかどうか、他の機能が動作するかどうかを確認する。過去のテスト資産を使い、実施する回数も多いことから、実施を省略することがないようにテスト自動化することにより効率化を図る。 回帰試験にて、テストする範囲を全テストケースとするか、(全テストケースを実施した場合に要する時間や工数と修正が及ぼす範囲を考慮して)部分テストケースとするか判断し、また、欠陥を検出する頻度を考慮して高い優先度で実施するテストケースを選択する方法がある。一方で、アジャイル開発手法を選択した場合、ソフトウェアの更新頻度も仕様変更頻度も共に高くなることが見込まれるため、特に開発期間が短いアジャイル開発手法においては、回帰試験が多くの不必要なオーバーヘッドになる可能性がある。回帰試験をサードパーティーに委託する場合、あるいは、ソフトウェアの一部がサードパーティーによって開発される場合、必ずしも修正が及ぼす範囲が判断できるわけではないので、テストする範囲は全テストケースと成らざるを得ない。[要出典]
※この「回帰試験 (Regression Test)」の解説は、「ソフトウェアテスト」の解説の一部です。
「回帰試験 (Regression Test)」を含む「ソフトウェアテスト」の記事については、「ソフトウェアテスト」の概要を参照ください。
- 回帰試験のページへのリンク
