リグレッションテストとは?
2020-09-18

リグレッションテストとは?

リグレッションテストとは、プログラムの修正・変更を行った際に、該当箇所以外へ影響を及ぼしていないかを確認するためのテストです。この記事では、リグレッションテストが必要な理由や、行うべきタイミング、また、効果的な実施範囲の決め方や効率化する方法についてもご紹介していきます。

ソフトウェア開発では、開発の規模が大きくなればなるほど、1つ1つのプログラムの修正・変更が及ぼす影響範囲が広くなります。そのため、小さなバグを1つ修正した結果、想定していなかった全く別の箇所に影響を与えてしまい、それまで正常に動いていた機能がエラーを起こしてしまうなんてことも。

そこで、プログラムの修正や変更を行った際に、該当箇所以外へ影響を与えていないかを確認するため、通常のテストとは別に「リグレッションテスト」を行います。

この記事では、リグレッションテストが必要な理由や、行うべきタイミング、また、効果的な実施範囲の決め方や効率化する方法についてもご紹介していきます。

目次

リグレッションテストとは?

どうしてリグレッションテストが必要なのか

リグレッションテストを行うべきタイミング

効果的なリグレッションテストの実施範囲を決めるポイント

単体テスト段階のリグレッションテストは自動化がおすすめ

リグレッションテストとは?

冒頭でお伝えした内容と重複しますが、「リグレッションテスト」とは、バグの修正や仕様変更などでプログラムに手を加えた際に、該当箇所以外の部分に影響を及ぼしていないかを確認するテストです。

リグレッションには、後戻り、前の悪い状態に戻るといった意味があるので、日本語で「回帰テスト」「退行テスト」とも呼ばれています。

どうしてリグレッションテストが必要なのか

プログラムに修正や変更を加えた際に、他に新たな不具合が出るなどして、品質や機能が修正前より悪い状態になることをデグレードと言います。デグレードとリグレッションは、言葉としては、ほぼ同じ意味です。

パソコンのソフトウェアやスマホのアプリ、オンラインゲームなどで、アップデートプログラムに不具合があって、後から追加パッチが配布されたという経験をしたことはありませんか? デグレードは、この、"アップデートプログラムに不具合がある"という状態のこと。

デグレードが起こる原因は、そもそも、プログラムの修正や変更に対するテストが不十分で、手を加えた箇所に不具合が残っている場合のほか、手を加えた箇所が、該当箇所以外の部分に影響を及ぼしているのを見落としていたという場合も。

ソフトウェア開発では、単体のプログラム作り、それを連結させてより高度なプログラムを作り上げていくため、特に開発工程の後半でプログラムの修正や変更を行った場合に、それまで見つかっていなかった新たなバグを発見したり、正常に機能していたプログラムがエラーになるといったことがしばしば起こります。

もうお分かりかと思いますが、この、後者の原因によるデグレードを防ぐために、リグレッションテストが必要なのです。

リグレッションテストを行うべきタイミング

ソフトウェア開発では、単体テスト、連結テスト、統合テスト、運用テストと、開発工程が進むごとに、徐々にプログラムの単位を大きくしながらテストを行います。

リグレッションテストは、本来、これらすべてのテスト工程において行うべきものです。

しかし、開発期間や作業する人員が限られている中で、そこまでリグレッションテストに工数を割くことができないという場合も多いのではないでしょうか。

 

これまでの話の流れから、なんとなくお分かりいただけているかと思いますが、開発工程が進むほど、1つのプログラムの修正や変更によって影響を受ける範囲が、大きくなっていきます。

そのため、開発工程の後半でのリグレッションテストほど、実施範囲が広くなり、また、バグやエラーを発見した場合、不具合の発生箇所の特定に多くのコストを割くことになります。

ですから、リグレッションテストの回数をある程度制限する必要がある場合には、単体テストの段階でリグレッションテストを行うのがベストです。

単体テストの段階であれば、プログラムの修正・変更による影響範囲も限定的で、万が一、バグやエラーが見つかっても、その原因箇所の特定が容易に行えますし、単体のプログラムの精度が高ければ、それだけ、開発工程の後半でのエラーも起きにくくなるからです。

効果的なリグレッションテストの実施範囲を決めるポイント

プログラムを修正・変更する度に、実施範囲を限定せずに全てのテストパターンを試す    「フルリグレッションテスト」を行えば、まず、デグレードは起きないでしょう。

しかし、リグレッションテストには、もちろんコストがかかるので、毎回フルリグレッションテストを行うのは非現実的です。そのため、なるべく効果的なリグレッションテストの実施範囲を決める必要があります。

前提として、効果的なリグレッションテストを行うためには、プログラムの修正や変更を行った箇所そのもののテストをしっかりと行う必要があります。手を加えた箇所にバグが残っていれば、リグレッションテストを行っても、またやり直しになってしまうからです。

効果的なリグレッションテストの実施範囲を決めるには、まず、プログラムの修正・変更による影響範囲を、抜け漏れなく、的確に把握します。これがわからなければ、そもそも、必要なテストパターンを洗い出すことができません。

影響範囲が限定的であれば、テストパターンもそこまで多くありませんので、全て試しても良いでしょう。

影響範囲が大きく、実施範囲をもっと絞る必要がある場合は、影響範囲の中で、デグレードが発生した場合のリスクが高いものをピックアップします。それでも、実施範囲を絞りきれない場合は、過去に発生した不具合のデータや傾向を見ながら、さらに優先度をつけていきましょう。

このように、影響範囲の中から、デグレードによるリスクの高い箇所を抽出することによって、実施範囲を絞っても、効果的なリグレッションテストを行うことが可能です。

単体テスト段階のリグレッションテストは自動化がおすすめ

先ほど、単体テストの段階でリグレッションテストを行うことをおすすめしましたが、この場合、必然的にテストの回数が多くなってしまいます。そこでおすすめなのが、ソフトウェアを使用した単体テストとリグレッションテストの自動化です。
 

組込ソフトウェア用テストプラットフォームであるVectorCAST(ベクターキャスト)は、ソフトウェア開発のライフサイクル全体にわたってテスト作業を自動化する製品ファミリーです。
VectorCASTは世界中の企業に選ばれている単体テスト自動化ツールで、自動車・航空・医療など、極めて高いソフトウェア品質を要求される分野においても数十年に渡ってソフトウェア開発を支えてきた実績が豊富にあります。

VectorCAST詳細

関連トピック

ソフトウェア開発のライフサイクルを通してテスト作業を自動化

VectorCASTはC言語、C++に対応した組込の単体テストを自動化するための単体テストツールです。

詳細はこちら
導入事例|VectorCAST(日本精機株式会社)

フルグラフィッククラスター制御の単体テストにVectorCASTを採用

詳細はこちら
ホワイトペーパー|組込ソフトウェア開発を効率化する変更ベーステスト

VectorCASTのホワイトペーパー「組込ソフトウェア開発を効率化する変更ベーステスト」をダウンロードいただけます。

詳細はこちら
ホワイトペーパー|医療機器のテスト

世界的な医療機器/医療用品メーカーのお客様との間で先日完了したサービス案件について詳しく説明します。

詳細はこちら
ホワイトペーパー|バグの修正および防止コストの定量化

このホワイトペーパーでは、テストの効率向上に使用できる手法を取り上げます。

詳細はこちら