回帰テスト
ソフトウェアが更新または変更されたり、変更されたターゲットで再利用されたりすると、新しい障害の発生や古い障害の再発生が非常に一般的である。不十分なリビジョン管理手法(またはリビジョン管理における単純な人為的エラー)によって修正が失われるために、再出現が発生することがある。多くの場合、問題の修正は「脆弱」であり、最初に観察された狭いケースでは問題が修正されるが、ソフトウェアの存続期間中に発生する可能性のあるより一般的なケースでは修正されない。多くの場合、ある領域の問題を修正すると、別の領域でソフトウェアのバグが発生する。最後に、一部の機能が再設計されると、その機能の元の実装で行われたのと同じ間違いのいくつかが再設計で行われる場合がある。
そのため、ほとんどのソフトウェア開発の状況では、コーディングのベストプラクティスとして、バグの修正を行ったら、バグを再現させたテストを実行して、さらにプログラムに以降の変更を行ったときに定期的にプログラムへの同じテストを再実行することが挙げられている。 これは、プログラミング手法を使用した手動テスト手順で実行できるが、多くの場合、自動テストツールを使用して実行される。 このようなテストスイートには、テスト環境ですべての回帰テストケースを自動的に実行できるようにするソフトウェアツールが含まれる。
回帰テスト手法は次のとおり。
回帰テストは、プログラムの正当性をテストするためだけでなく、多くの場合、その出力の品質を追跡するためにも使用できる。 たとえば、コンパイラの設計では、回帰テストでコードサイズと、テストスイートのケースをコンパイルして実行するのにかかる時間を追跡できる。
回帰テストは、機能テストまたは単体テストに分類できる。機能テストは、さまざまな入力を使用してプログラム全体を実行する。単体テストは、個々の関数、サブルーチン、またはオブジェクトメソッドを実行する。機能テストツールと単体テストツールはどちらも自動化される傾向があり、多くの場合、コンパイラスイートの一部ではないサードパーティ製品である。機能テストは、スクリプト化された一連のプログラム入力である場合があり、マウスの動きとクリックを制御するための自動化されたメカニズムが含まれる場合もある。単体テストは、コード自体内の個別の関数のセット、またはテスト対象のコードを変更せずにコードにリンクするドライバーレイヤーの場合がある。