回帰テスト

回帰テスト（稀に非回帰テスト^{[1] ）は、}機能テストと非機能テストを再実行して、以前に開発およびテストされたソフトウェアが変更後も期待どおりに動作することを確認することです。^{[2]そうでない場合は、}回帰と呼ばれます。

回帰テストが必要となる変更には、バグ修正、ソフトウェアの機能強化、構成変更、さらには電子部品（ハードウェア）の交換などが含まれます。 ^[3]回帰テストスイートは欠陥が見つかるたびに大きくなる傾向があるため、テストの自動化が頻繁に行われます。明らかな例外はGUIの回帰テストで、通常は手動で実行する必要があります。変更影響分析を実行して、適切なテストのサブセットを決定することもあります（非回帰分析^[4]）。

ソフトウェアが更新または変更されたり、修正されたターゲットで再利用されたりすると、新しい障害が発生したり、古い障害が再び発生したりすることがよく起こります。

不適切なリビジョン管理方法 (またはリビジョン管理における単純な人為的エラー)により修正が失われ、問題が再発することがあります。多くの場合、問題の修正は、最初に確認された狭い範囲の問題は修正しますが、ソフトウェアの存続期間中に発生する可能性のあるより一般的なケースは修正しないという点で「脆弱」です。ある領域の問題の修正が、別の領域で 意図せずソフトウェア バグを引き起こすことがよくあります。

機能を再設計すると、その機能の元の実装で発生したのと同じ間違いが、再設計でも発生することがあります。ほとんどのソフトウェア開発では、バグが見つかり修正されたら、そのバグを明らかにするテストを記録し、その後プログラムに変更を加えた後にそのテストを定期的に再実行することが、優れたコーディング方法であると考えられています。^[5]

これはプログラミング技術を使用した手動テスト手順を通じて行われる場合もありますが、多くの場合、自動テストツールを使用して行われます。^[6]このようなテストスイートには、テスト環境ですべての回帰テストケースを自動的に実行できるようにするソフトウェアツールが含まれています。多くのプロジェクトでは、継続的インテグレーションシステムを自動化して、指定された間隔ですべての回帰テストを再実行し、失敗（回帰または古いテストを意味する可能性があります）を報告します。^[7]

一般的な戦略としては、コンパイルが成功するたびに (小規模プロジェクトの場合)、毎晩、または週に 1 回、このようなシステムを実行することが挙げられます。これらの戦略は、外部ツールによって自動化できます。

回帰テストは、エクストリーム プログラミングソフトウェア開発方法の不可欠な部分です。この方法では、設計ドキュメントの代わりに、ソフトウェア開発プロセスの各段階を通じてソフトウェア パッケージ全体を対象に、広範囲で繰り返し可能な自動テストが行​​われます。回帰テストは、機能テストが完了した後に実行され、他の機能が動作していることを確認します。

企業の世界では、回帰テストは開発チームが作業を完了した後にソフトウェア品質保証チームによって伝統的に行われてきました。しかし、この段階で見つかった欠陥の修正には最もコストがかかります。この問題は、ユニットテストの台頭によって解決されつつあります。開発者は常に開発サイクルの一環としてテストケースを書いてきましたが、これらのテストケースは一般的に機能テストか、意図した結果のみを検証するユニットテストのいずれかでした。開発者テストでは、開発者はユニットテストに集中し、肯定的なテストケースと否定的なテストケースの両方を含めるように求められます。^[8]

さまざまな回帰テスト手法は次のとおりです。

この手法は、現在のプログラムのすべてのテストケースをチェックして整合性をチェックします。すべてのケースを再実行する必要があるためコストがかかりますが、変更されたコードによるエラーがないことが保証されます。^[9]

「すべて再テスト」とは異なり、この手法では、テストスイートの一部を選択するコストが「すべて再テスト」手法よりも低い場合、テストスイートの一部が実行されます（「すべて再テスト」のコストによる）。^[9]

テストケースに優先順位を付けることで、テストスイートの障害検出率が向上します。テストケースの優先順位付け技術では、優先度の高いテストケースが優先度の低いテストケースよりも先に実行されるようにテストケースをスケジュールします。^[9]

• 一般的な優先順位付け – 後続のバージョンに役立つテストケースを優先する
• バージョン固有の優先順位付け - ソフトウェアの特定のバージョンに関してテスト ケースに優先順位を付けます。

この手法は回帰テストの選択とテストケースの優先順位付けを組み合わせたものである。^[9]

回帰テストは、ソフトウェアの既存の機能に変更が加えられた場合、またはソフトウェアにバグ修正があった場合に実行されます。回帰テストは複数のアプローチで実行できます。すべてをテストするアプローチを採用すると、ソフトウェアに加えられた変更が、変更されていない既存の機能に影響を与えていないことが確実になります。^[10]

アジャイルソフトウェア開発では、ソフトウェア開発ライフサイクルが非常に短く、リソースが不足しており、ソフトウェアの変更が非常に頻繁に行われるため、回帰テストによって多くの不要なオーバーヘッドが発生する可能性があります。^[10]

サードパーティのブラックボックスコンポーネントを使用する傾向があるソフトウェア開発環境では、サードパーティコンポーネントの変更がシステムの他の部分に干渉する可能性があるため、回帰テストを実行するのは難しい場合があります（サードパーティコンポーネントは未知のエンティティであるため、回帰テストを実行することは困難です）。^[10]

回帰テストは、プログラムの正確性をテストするだけでなく、その出力の品質を追跡するためにも使用できます。 ^[11]たとえば、コンパイラの設計では、回帰テストによってコードサイズと、テストスイートケースのコンパイルと実行にかかる時間を追跡できます。

また、新しいバグが導入された結果として、プログラムのメンテナンスでは、他のプログラミング言語よりも、記述されたステートメントごとにはるかに多くのシステム テストが必要になります。理論的には、修正のたびに、以前にシステムに対して実行されたテスト ケースのバッチ全体を実行して、システムが不明瞭な方法で損傷を受けていないことを確認する必要があります。実際には、このような回帰テストは、この理論的なアイデアに近似する必要があり、非常にコストがかかります。

— フレッド・ブルックス『神話の人月』122ページ

回帰テストは、機能テストと単体テストに大別できます。機能テストでは、さまざまな入力を使用してプログラム全体をテストします。単体テストでは、個々の関数、サブルーチン、またはオブジェクト メソッドをテストします。機能テスト ツールと単体テスト ツールはどちらも自動化される傾向があり、コンパイラ スイートの一部ではないサードパーティ製品であることがよくあります。機能テストは、スクリプト化された一連のプログラム入力であり、マウスの動きやクリックを制御するための自動化メカニズムが含まれる場合もあります。単体テストは、コード自体に含まれる個別の関数のセット、またはテスト対象のコードに変更を加えずにコードにリンクするドライバー レイヤーです。

• 品質管理
• テスト駆動開発