ソフトウェアプログラムに変更を加えた際、それによって新たな不具合が起きていないかを検証するテストのこと。
バグ(注1)修正や機能追加などの理由で既存のプログラムコードを部分的に変更することはよくある。ところがコンピュータソフトウェアはわずかでも変更を行うと、修正個所とは別の機能が動作しなくなるリグレッション(注2)、デグレード(注3)といった現象が生じることがある。このリグレッションの有無を調べるテストが回帰テストである。
リグレッションがシステムのどこに発生するのか予測できないとすれば、システムの品質を保証するには実施済みのテストをすべて最初からやり直さなければならない。しかも回帰テストでバグや不具合が検出されれば、それを修正することになるので、さらに回帰テストが必要となる。このように回帰テストは非常に工数が掛かるものなので、開発プロジェクトにおける最終工程は別にして、システム運用時の修正保守や機能追加では、完全な回帰テストはあまり実施されない。
対象ソフトウェアが設計時にモジュール間の結合度を十分に小さく作られていれば、不具合の影響度が極小化されると推測できるので、回帰テストを行うときにすべてのテストケースを実施せずに、修正したプログラムコードの影響範囲を考えて行うべきテストケースを絞り込むことができる。そのため、保守テストでは通常、影響度分析を行ってテスト範囲を限定し、回帰テストを実施する。
回帰テストを繰り返し行うシステムでは、テスト自動化ツールの適用が有効とされる。回帰テストが繰り返されるということはソフトウェアが徐々に変化していることを意味するため、それに応じてテストケースも更新して陳腐化させないことが重要となる。
参考文献
▼『自動ソフトウェアテスト――導入から、管理・実践まで効果的な自動テスト環境の構築を目指して』 エルフリード・ダスティン、ジェフ・ラシュカ、・ポール=著/向井清=訳/ピアソン・エデュケーション/2002年10月(『Automated Software Testing: Introduction, Management, and Performance』の邦訳)
▼『ソフトウェアテスト293の鉄則』 セム・ケイナー、ジェームズ・バック、ブレット・ペティコード=著/テスト技術者交流会=訳/日経BP社/2003年4月(『Lesson Learned in Software Testing: A Context-Driven Approach』の邦訳)
関連記事
- 連載:開発プロセス再入門(7) − テスト計画の立案(@IT情報マネジメント)
- 連載:ユカイ、ツーカイ、カイハツ環境!(7) − ブラウザを選ばずWebテストを自動化するSelenium(@IT Java Solutionフォーラム)
関連リンク
Copyright © ITmedia, Inc. All Rights Reserved.