回帰テスト 回帰テストの概要

ウィキペディア

回帰テスト

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/12/04 20:52 UTC 版)

背景

ソフトウェアが更新または変更されたり、変更されたターゲットで再利用されたりすると、新しい障害の発生や古い障害の再発生が非常に一般的である。不十分なリビジョン管理手法（またはリビジョン管理における単純な人為的エラー）によって修正が失われるために、再出現が発生することがある。多くの場合、問題の修正は「脆弱」であり、最初に観察された狭いケースでは問題が修正されるが、ソフトウェアの存続期間中に発生する可能性のあるより一般的なケースでは修正されない。多くの場合、ある領域の問題を修正すると、別の領域でソフトウェアのバグが発生する。最後に、一部の機能が再設計されると、その機能の元の実装で行われたのと同じ間違いのいくつかが再設計で行われる場合がある。

そのため、ほとんどのソフトウェア開発の状況では、コーディングのベストプラクティスとして、バグの修正を行ったら、バグを再現させたテストを実行して、さらにプログラムに以降の変更を行ったときに定期的にプログラムへの同じテストを再実行することが挙げられている。 これは、プログラミング手法を使用した手動テスト手順で実行できるが、多くの場合、自動テストツールを使用して実行される。 このようなテストスイートには、テスト環境ですべての回帰テストケースを自動的に実行できるようにするソフトウェアツールが含まれる。一部のプロジェクトでは、自動システムをセットアップして、指定された間隔ですべての回帰テストを再実行し、障害を報告する（これは回帰または古いテストを意味する可能性がある）。 一般的な戦略では、コンパイルが成功するたびに（小さなプロジェクトの場合）、毎晩、または週に1回、このようなシステムを実行する。これらの戦略は、外部ツールによって自動化できる。

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

企業の世界では、従来、回帰テストは、開発チームが作業を完了した後にソフトウェア品質保証チームによって実行されてきた。ただし、この段階で見つかった欠陥は、修正するのに最も費用がかかる。この問題は、単体テストによって対処されている。開発者は常に、開発サイクルの一環として、テストケースを書いているが、これらのテストケースは、一般的にどちらかだった機能テストや単体テストのみ意図成果を検証する。開発者テストでは、開発者は単体テストに集中し、ポジティブテストケースとネガティブテストケースの両方を含める必要がある。

テクニック

回帰テスト手法は次のとおり。

すべてを再テスト

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

回帰テストの選択

すべてを再テストするのとは異なり、この手法は、テストスイートの一部を選択するコストがすべてを再テストする手法よりも少ない場合、テストスイートの一部を実行する（すべてを再テストするコストがかかるため）。

テストケースの優先順位付け

テストスイートの障害検出率を高めるために、テストケースに優先順位を付ける。テストケースの優先順位付け手法では、優先度の高いテストケースが、優先度の低いテストケースの前に実行されるようにテストケースをスケジュールする。

テストケースの優先順位付けの種類

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

ハイブリッド

回帰テストの選択とテストケースの優先順位付けを組み合わせたもの。