回帰テストとは何ですか？定義、ツール、方法、および例

what is regression testing

回帰テストとは何ですか？

回帰テストは、ソフトウェアのコード変更が製品の既存の機能に影響を与えないことを確認するために行われるテストの一種です。これは、製品が新しい機能、バグ修正、または既存の機能の変更で正常に動作することを確認するためです。以前に実行されたテストケースは、変更の影響を検証するために再実行されます。

=> 完全なテスト計画チュートリアルシリーズについては、ここをクリックしてください

回帰テストは、アプリケーションの以前の機能が正常に機能していて、新しい変更によって新しいバグが発生していないかどうかを確認するために、テストケースが再実行されるソフトウェアテストタイプです。

このテストは、単一のバグ修正でも元の機能に大幅な変更があった場合に、新しいビルドで実行できます。

回帰とは、アプリケーションの変更されていない部分を再テストすることを意味します。

学習内容：

• このシリーズで取り上げるチュートリアル
• 回帰テストの概要
• このテストをいつ実行するか？
• 回帰テストは手動で実行できますか？
• 自動回帰テストツール
• なぜ回帰テストなのか？
• 回帰テストの種類
  • ＃1）ユニットの回帰
  • ＃2）部分的な回帰
  • ＃3）完全な回帰
• どのくらいの回帰が必要ですか？
• 回帰チェックで何をしますか？
• 回帰テスト手法
  • ＃1）すべてを再テストする
  • ＃2）回帰テストの選択
  • ＃3）テストケースの優先順位付け
  • ＃4）ハイブリッド
• 回帰テストスイートを選択する方法は？
• 回帰テストを実行する方法は？
• アジャイルでの回帰
  • ＃1）スプリントレベルの回帰
  • ＃2）エンドツーエンドの回帰
• 利点
• 短所
• GUIアプリケーションの回帰
• 回帰と再テストの違い
• 回帰テスト計画テンプレート（TOC）
  • ＃1）ドキュメント履歴
  • ＃2）参考文献
  • ＃3）回帰テスト計画
  • ＃4）承認/承認
• 結論
• 推奨読書

このシリーズで取り上げるチュートリアル

チュートリアル＃1： 回帰テストとは （このチュートリアル）
チュートリアル＃2： 回帰テストツール
チュートリアル＃3： 再テストと回帰テスト
チュートリアル＃4： アジャイルでの自動回帰テスト

回帰テストの概要

回帰テストは検証方法のようなものです。テストケースは何度も何度も実行する必要があり、同じテストケースを何度も手動で実行する必要があるため、テストケースは一般に自動化されており、時間と手間もかかります。

例えば、 製品Xについて考えてみます。この機能の1つは、(確認)、(承認)、および(ディスパッチ)ボタンがクリックされたときに、確認、承認、およびディスパッチされた電子メールをトリガーすることです。

確認メールでいくつかの問題が発生し、それを修正するために、いくつかのコード変更が行われます。この場合、確認メールだけでなく、承認メールと発送メールもテストして、コードの変更が影響を受けていないことを確認する必要があります。

回帰テストは、Java、C ++、C＃などのプログラミング言語に依存しません。これは、製品の変更や更新が行われているかどうかをテストするために使用されるテスト方法です。製品の変更が製品の既存のモジュールに影響を与えないことを確認します。

バグが修正され、新しく追加された機能によって、ソフトウェアの以前の動作バージョンで問題が発生していないことを確認します。

テスターは、新しいビルドが検証に利用できるときに機能テストを実行します。このテストの目的は、既存の機能に加えられた変更と、新しく追加された機能も検証することです。

このテストが完了すると、テスターは既存の機能が期待どおりに機能しているかどうか、および新しい変更によってこの変更前に機能していた機能に欠陥が生じていないかどうかを確認する必要があります。

回帰テストはリリースサイクルの一部である必要があり、テストの見積もりで考慮する必要があります。

このテストをいつ実行するか？

回帰テストは通常​​、変更または新機能の検証後に実行されます。しかし、これは常にそうであるとは限りません。完了するまでに数か月かかるリリースの場合、回帰テストを毎日のテストサイクルに組み込む必要があります。毎週のリリースでは、変更の機能テストが終了したときに回帰テストを実行できます。

回帰チェックは、再テストのバリエーションです（これは単にテストを繰り返すことです）。再テストする場合、理由は何でもかまいません。たとえば、特定の機能をテストしていて、それが1日の終わりでした。テストを終了できず、テストが成功したか失敗したかを判断せずにプロセスを停止する必要がありました。

翌日戻ってきたら、もう一度テストを実行します。つまり、以前に実行したテストを繰り返します。テストを繰り返すという単純な行為は再テストです。

その核となる回帰テストは、ある種の再テストです。アプリケーション/コードの何かが変更されたのは特別な場合のみです。システムの全体的なフレームワークを決定するのは、コード、設計、またはその他のものである可能性があります。

この状況で、前述の変更が以前に機能していたものに影響を与えていないことを確認するために実行される再テストは、回帰テストと呼ばれます。これが実行される可能性がある最も一般的な理由は、コードの新しいバージョンが作成された（スコープ/要件の増加）か、バグが修正されたためです。

回帰テストは手動で実行できますか？

私はクラスで最近教えていたところですが、「回帰は手動で実行できますか？」という質問がありました。

私は質問に答えて、クラスに進みました。すべてが大丈夫だったように見えましたが、どういうわけか、この質問はかなり後に私を悩ませました。

多くのバッチにわたって、この質問はさまざまな方法で何度も出てきます。それらのいくつかは次のとおりです。

• テストの実行を実行するには、ツールが必要ですか？
• 回帰テストはどのように実行されますか？
• テスト全体を行った後でも、初心者は回帰テストが正確に何であるかを識別するのが難しいと感じていますか？

そしてもちろん、元の質問：

• このテストは手動で実行できますか？

そもそも、 テストの実行 これは、テストケースを使用し、AUTでこれらの手順を実行し、テストデータを提供し、AUTで取得した結果をテストケースに記載されている期待される結果と比較するという単純な行為です。

比較結果に応じて、テストケースの合格/不合格のステータスを設定します。テストの実行はそれと同じくらい簡単で、このプロセスに必要な特別なツールはありません。

自動回帰テストツール

自動回帰テストは、ほとんどのテスト作業を自動化できるテスト領域です。以前に実行したすべてのテストケースを新しいビルドで実行します。

これは、テストケースセットが利用可能であり、これらのテストケースを手動で実行するのに時間がかかることを意味します。期待される結果がわかっているため、これらのテストケースを自動化することで時間を節約でき、効率的な回帰テスト方法になります。自動化の範囲は、長期にわたって適用可能なままになるテストケースの数によって異なります。

テストケースが時々変化する場合、アプリケーションの範囲は拡大し続け、回帰手順の自動化は時間の無駄になります。

ほとんどの回帰テストツールは、記録および再生タイプです。 AUT（テスト中のアプリケーション）をナビゲートしてテストケースを記録し、期待される結果が得られるかどうかを確認します。

ツール

• セレン
• カタログスタジオ
• AdventNet QEngine
• リグレッションテスター
• vTest
• 水
• 活性化
• Rational Functional Tester
• SilkTest
• TimeShiftX

これらのほとんどは、機能テストツールと回帰テストツールです。

推奨読書=> トップリグレッションツールのリストについては、こちらを確認してください

自動化テストスイートでの回帰テストケースの追加と更新は、面倒な作業です。回帰テスト用の自動化ツールを選択するときは、ツールでテストケースを簡単に追加または更新できるかどうかを確認する必要があります。

ソフトウェアテスト用のサンプルテストスクリプト

ほとんどの場合、システムが頻繁に変更されるため、自動回帰テストケースを頻繁に更新する必要があります。

ビデオを見る

例を含む定義の詳細な説明については、以下を確認してください。回帰テストビデオ：

なぜ回帰テストなのか？

リグレッションは、プログラマーがバグを修正するか、システムに新しい機能の新しいコードを追加すると開始されます。

新しく追加された機能と既存の機能には、多くの依存関係が存在する可能性があります。

変更されていないコードが影響を受けないように、新しいコードが古いコードに準拠しているかどうかを確認するのは品質基準です。ほとんどの場合、テストチームには、システムの直前の変更をチェックするタスクがあります。

このような状況では、影響を受けるアプリケーション領域のみをテストして、システムの主要なすべての側面をカバーすることにより、テストプロセスを時間どおりに完了する必要があります。

このテストは、アプリケーションに継続的な変更/改善が追加されている場合に非常に重要です。新しい機能は、既存のテスト済みコードに悪影響を与えるべきではありません。

コードの変更が原因で発生したバグを見つけるには、リグレッションが必要です。このテストが行​​われない場合、製品は実際の環境で重大な問題を引き起こす可能性があり、それは実際に顧客をトラブルに導く可能性があります。

オンラインWebサイトのテスト中に、テスターが製品の価格が正しく表示されない、つまり製品の実際の価格よりも低い価格を示しているという問題を報告しました。すぐに修正する必要があります。

開発者が問題を修正したら、再テストする必要があります。報告されたページの価格が修正されていることを確認するために回帰テストも必要ですが、合計が表示される概要ページに誤った価格が表示されている可能性があります。他の料金または顧客に送信されたメールの価格が正しくありません。

さて、この場合、サイトが誤った価格で総コストを計算し、同じ価格が電子メールで顧客に送られるため、このテストが実行されない場合、顧客は損失を負担する必要があります。顧客が同意すると、製品はオンラインで低価格で販売され、顧客にとって損失になります。

したがって、このテストは大きな役割を果たし、非常に必要であり、重要でもあります。

回帰テストの種類

以下に、さまざまなタイプの回帰を示します。

• ユニット回帰
• 部分的な回帰
• 完全な回帰

＃1）ユニットの回帰

ユニット回帰は、 ユニットテスト フェーズとコードは個別にテストされます。つまり、テスト対象のユニットへの依存関係がブロックされるため、ユニットを個別にテストできます。

＃2）部分的な回帰

部分回帰は、コードに変更が加えられ、そのユニットが変更されていないコードまたは既存のコードと統合されている場合でも、コードが正常に機能することを確認するために行われます。

＃3）完全な回帰

完全なリグレッションは、コードの変更が多数のモジュールで行われた場合、および他のモジュールの変更による変更の影響が不確実な場合に行われます。コードが変更されたために変更があったかどうかを確認するために、製品全体がリグレッションされます。

どのくらいの回帰が必要ですか？

これは、新しく追加された機能の範囲によって異なります。

修正または機能の範囲が大きすぎる場合、影響を受けるアプリケーション領域も非常に大きいため、すべてのアプリケーションテストケースを含めてテストを徹底的に実行する必要があります。しかし、これは、テスターがスコープ、性質、および変更の量について開発者から入力を受け取ったときに効果的に決定できます。

これらは反復テストであるため、テストケースを自動化して、一連のテストケースだけを新しいビルドで簡単に実行できます。

回帰テストケースは、最大の機能が最小のテストケースセットでカバーされるように、非常に慎重に選択する必要があります。これらの一連のテストケースでは、新しく追加された機能を継続的に改善する必要があります。

アプリケーションスコープが非常に大きく、システムに継続的な増分またはパッチがある場合、非常に困難になります。このような場合、テストのコストと時間を節約するために、選択的なテストを実行する必要があります。これらの選択的なテストケースは、システムに加えられた機能強化と、システムが最も影響を与える可能性のある部分に基づいて選択されます。

回帰チェックで何をしますか？

• 以前に実施したテストを再実行します
• 現在の結果を以前に実行したテスト結果と比較します

これは、ソフトウェアテストのライフサイクル全体のさまざまな段階で実行される継続的なプロセスです。

ベストプラクティスは、次の後に回帰テストを実施することです。 正気または煙のテスト ショートリリースの機能テストの最後に。

効果的なテストを実施するために、回帰 テスト計画 作成する必要があります。この計画では、回帰テストの戦略と終了基準の概要を説明する必要があります。パフォーマンステストもこのテストの一部であり、システムコンポーネントに加えられた変更によってシステムパフォーマンスが影響を受けないことを確認します。

ベストプラクティス ：自動テストケースを毎日夕方に実行して、回帰の副作用を翌日のビルドで修正できるようにします。このように、リリースサイクルの最後に欠陥を見つけて修正するのではなく、ほとんどすべての回帰欠陥を早い段階でカバーすることにより、リリースリスクを軽減します。

回帰テスト手法

以下に、さまざまな手法を示します。

• すべて再テスト
• 回帰テストの選択
• テストケースの優先順位付け
• ハイブリッド

＃1）すべてを再テストする

名前自体が示すように、テストスイートのテストケース全体が再実行され、コードの変更によって発生したバグがないことを確認します。これは、他の手法と比較してより多くの時間とリソースを必要とするため、費用のかかる方法です。

＃2）回帰テストの選択

この方法では、テストスイートからテストケースを選択して再実行します。スイート全体が再実行されるわけではありません。テストケースの選択は、モジュール内のコード変更に基づいて行われます。

テストケースは2つのカテゴリに分類されます。1つは再利用可能なテストケースで、もう1つは廃止されたテストケースです。再利用可能なテストケースは将来の回帰サイクルで使用できますが、廃止されたテストケースは次の回帰サイクルでは使用されません。

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

優先度の高いテストケースは、優先度が中程度および低いテストケースよりも最初に実行されます。テストケースの優先度は、その重要度と製品への影響、およびより頻繁に使用される製品の機能によって異なります。

＃4）ハイブリッド

ハイブリッド手法は、回帰テストの選択とテストケースの優先順位付けを組み合わせたものです。テストスイート全体を選択するのではなく、優先度に応じて再実行されるテストケースのみを選択します。

回帰テストスイートを選択する方法は？

実稼働環境で見つかったバグのほとんどは、11時間目に行われた変更または修正されたバグ、つまり後の段階で行われた変更が原因で発生します。最終段階でのバグ修正により、製品に他の問題/バグが発生する可能性があります。そのため、製品をリリースする前に回帰チェックが非常に重要です。

以下は、このテストの実行中に使用できるテストケースのリストです。

• 頻繁に使用される機能。
• 変更が行われたモジュールをカバーするテストケース。
• 複雑なテストケース。
• すべての主要コンポーネントを含む統合テストケース。
• 製品のコア機能または機能のテストケース。
• 優先度1と優先度2のテストケースを含める必要があります。
• 頻繁に失敗するテストケースまたは最近のテストの欠陥が同じ場所で見つかりました。

回帰テストを実行する方法は？

回帰の意味を確立したので、それがテストも行っていることは明らかです。特定の理由で特定の状況で繰り返すだけです。したがって、そもそも同じ方法がテストに適用されることは、これにも適用できることを安全に導き出すことができます。

したがって、テストを手動で実行できる場合は、回帰テストも実行できます。ツールの使用は必要ありません。ただし、時間が経つにつれて、アプリケーションにはますます多くの機能が積み重なっていき、リグレッションの範囲が拡大し続けます。時間を最大限に活用するために、このテストは ほとんどの場合自動化 。

以下に、このテストの実行に関連するさまざまな手順を示します。

• に記載されている点を考慮して、回帰用のテストスイートを準備します 「回帰テストスイートの選択方法」？
• テストスイートのすべてのテストケースを自動化します。
• テストケースでカバーされていない新しい欠陥が見つかった場合など、必要に応じて回帰スイートを更新します。また、同じテストケースをテストスイートで更新して、次回のテストを見逃さないようにする必要があります。 。回帰テストスイートは、テストケースを継続的に更新することによって適切に管理する必要があります。
• コードに変更があったり、バグが修正されたり、新しい機能が追加されたり、既存の機能が拡張されたりするたびに、回帰テストケースを実行します。
• 実行されたテストケースの合格/不合格ステータスを含むテスト実行レポートを作成します。

例えば：

これを例を挙げて説明しましょう。以下の状況を調べてください。

以下は、上記の状況から私たちが行うことができる観察です。

• リリースが大きくなるにつれて、機能も大きくなります。
• 開発時間は必ずしもリリースとともに増加するわけではありませんが、テスト時間は増加します
• テストに多くの時間を費やし、開発に費やす時間を減らす準備ができている企業/その経営陣はありません
• テストチームの規模を増やしても、テストにかかる時間を短縮することはできません。新しい人はより多くのお金を意味し、新しい人は多くのトレーニングを意味し、新しい人は必要な知識と同等ではない可能性があるため、品質の妥協も意味します。すぐにレベル。
• 他の選択肢は明らかに、回帰の量を減らすことです。しかし、それはソフトウェア製品にとって危険である可能性があります。

これらすべての理由から、回帰テストは自動化テストの有力な候補ですが、その方法でのみ実行する必要はありません。

回帰テストを実行するための基本的な手順

ソフトウェアが変更され、新しいバージョン/リリースがリリースされるたびに、このタイプのテストを実行するために実行できる手順は次のとおりです。

• ソフトウェアにどのような変更が加えられたかを理解する
• ソフトウェアのどのモジュール/パーツが影響を受ける可能性があるかを分析および決定します–開発チームとBAチームはこの情報を提供するのに役立ちます
• テストケースを見て、完全回帰、部分回帰、または単位回帰を実行する必要があるかどうかを判断します。あなたの状況に合うものを特定してください
• 時間をスケジュールしてテストしてください！

アジャイルでの回帰

アジャイル は、反復型および増分型の方法に従う適応型アプローチです。この製品は、スプリントと呼ばれる短い反復で開発され、2〜4週間続きます。アジャイルでは、多くの反復があります。したがって、新しい機能またはコードの変更が反復で行われるため、このテストは重要な役割を果たします。

回帰テストスイートは、初期段階から準備し、スプリントごとに更新する必要があります。

アジャイルでは、回帰チェックは2つのカテゴリに分類されます。

• スプリントレベルの回帰
• エンドツーエンドの回帰

＃1）スプリントレベルの回帰

スプリントレベルの回帰は、主に最新のスプリントで行われる新機能または拡張のために行われます。テストスイートのテストケースは、新しく追加された機能または実行された拡張機能に従って選択されます。

＃2）エンドツーエンドの回帰

エンドツーエンド回帰には、製品のすべてのコア機能をカバーすることにより、製品全体をエンドツーエンドでテストするために再実行されるすべてのテストケースが含まれます。

アジャイルはスプリントが短く、それが続くため、テストスイートを自動化する必要があり、テストケースが再度実行され、それも短期間で完了する必要があります。テストケースを自動化すると、実行時間と欠陥のずれが減少します。

利点

回帰テストのさまざまな利点を以下に示します。

• それは製品の品​​質を向上させます。
• これにより、行われたバグ修正または拡張が製品の既存の機能に影響を与えないことが保証されます。
• このテストには自動化ツールを使用できます。
• すでに修正された問題が再発しないようにします。

短所

いくつかの利点がありますが、いくつかの欠点もあります。彼らです：

• コードを少し変更しただけでも既存の機能に問題が発生する可能性があるため、コードを少し変更した場合にも実行する必要があります。
• このテストのプロジェクトで自動化が使用されていない場合、テストケースを何度も実行するのは時間と手間がかかります。

GUIアプリケーションの回帰

GUI（グラフィカルユーザーインターフェイス）の回帰テストを実行するのが難しい場合 GUI構造 変更されます。古いGUIで記述されたテストケースは、廃止されるか、変更する必要があります。

回帰テストケースを再利用するということは、GUIテストケースが新しいGUIに従って変更されることを意味します。ただし、GUIテストケースのセットが多い場合、このタスクは面倒な作業になります。

回帰と再テストの違い

実行中に失敗したテストケースに対して再テストが行​​われ、そのために発生したバグが修正されましたが、リグレッションチェックは他のテストケースも対象としているため、バグ修正に限定されず、バグ修正が行われていないことを確認します。製品の他の機能に影響を与えました。

回帰テスト計画テンプレート（TOC）

1.ドキュメント履歴

2.参考文献

3.回帰テスト計画

3.1。前書き

3.2。目的

3.3。テスト戦略

3.4。テストする機能

3.5。リソース要件

3.5.1。ハードウェア要件

3.5.2。ソフトウェア要件

3.6。テストスケジュール

3.7。変更要求

3.8。入場/退場基準

3.8.1。このテストのエントリー基準

3.8.2。このテストの終了基準

3.9。仮定/制約

3.10。テストケース

3.11。リスク/仮定

3.12。ツール

4.承認/承認

それぞれについて詳しく見ていきましょう。

＃1）ドキュメント履歴

ドキュメント履歴は、最初のドラフトの記録と、以下の形式で更新されたすべてのドラフトで構成されます。

＃2）参考文献

参照列は、テスト計画の作成中に、プロジェクトで使用または必要なすべての参照ドキュメントを追跡します。

＃3）回帰テスト計画

3.1。前書き

このドキュメントでは、テスト対象の製品の変更/更新/拡張と、このテストに使用されるアプローチについて説明します。すべてのコードの変更、拡張、更新、追加された機能は、テストするために概説されています。単体テストと統合テストに使用されるテストケースを使用して、回帰のテストスイートを作成できます。

3.2。目的

回帰テスト計画の目的は、結果を達成するためにテストを正確にどのように実行するかを説明することです。回帰チェックは、コードの変更によって製品の他の機能が妨げられていないことを確認するために行われます。

3.3。テスト戦略

テスト戦略では、このテストを実行するために使用されるアプローチについて説明します。これには、使用される手法、完了基準、実行するアクティビティ、テストスクリプトを作成するユーザー、使用する回帰ツールが含まれます。 、リソースの不足、生産の遅延などのリスクをカバーするための手順。

3.4。テストする機能

テストする製品の機能/コンポーネントはここにリストされています。リグレッションでは、実行された修正/更新または拡張に応じて、すべてのテストケースが再実行されるか、既存の機能に影響を与えるものが選択されます。

3.5。リソース要件

3.5.1。ハードウェア要件：

ここでは、コンピューター、ラップトップ、モデム、Macブック、スマートフォンなどのハードウェア要件が特定されています。

3.5.2。ソフトウェア要件：

ソフトウェア要件は、どのオペレーティングシステムとブラウザが必要になるかなどで識別されます。

3.6。テストスケジュール

テストスケジュールは、テストアクティビティを実行するための推定時間を定義します。

例えば テストアクティビティを実行するリソースはいくつありますか？それもどのくらいの時間で実行されますか？

3.7。変更要求

回帰が実行されるCRの詳細が記載されています。

3.8。入退場基準

3.8.1。このテストのエントリー基準：

製品が回帰チェックを開始するための入力基準が定義されています。

例えば：

• コーディングの変更/拡張/新機能の追加を完了する必要があります。
• 回帰テスト計画は承認される必要があります。

3.8.2。このテストの終了基準：

ここでは、回帰の終了基準が定義されています。

例えば：

• 回帰テストを完了する必要があります。
• このテスト中に見つかった新しい重大なバグはすべて閉じる必要があります。
• テストレポートの準備ができているはずです。

3.9。テストケース

回帰テストケースはここで定義されます。

3.10。リスク/仮定

リスクと仮定が特定され、そのための緊急時対応計画が作成されます。

3.11。ツール

プロジェクトで使用するツールが特定されます。といった：

• 自動化ツール
• バグ報告ツール

＃4）承認/承認

人々の名前と指定はここにリストされています：

結論

回帰テストは、コードの変更が小さいか大きいかにかかわらず、既存または古い機能に影響を与えないことを確認することにより、高品質の製品を提供するのに役立つため、重要な側面の1つです。

回帰テストケースを自動化するために多くの自動化ツールを利用できますが、プロジェクトの要件に従ってツールを選択する必要があります。回帰テストスイートは頻繁に更新する必要があるため、ツールにはテストスイートを更新する機能が必要です。

以上で、このトピックを締めくくり、今後、このテーマがより明確になることを願っています。

回帰関連の質問とコメントをお知らせください。回帰テストのタスクにどのように取り組みましたか？

=> 完全なテスト計画チュートリアルシリーズについては、こちらをご覧ください

推奨読書

• 最高のソフトウェアテストツール2021 (QAテスト自動化ツール)
• 2021年に最も人気のある回帰テストツールトップ10
• 信頼性テストとは：定義、方法、ツール
• Androidアプリケーションをテストするための11の最高の自動化ツール（Androidアプリテストツール）
• 自動回帰テスト：課題、プロセス、およびステップ
• PrimereBookダウンロードのテスト
• 例を使用した再テストと回帰テストの違い
• トップ10以上のベストSAPテストツール（SAP自動化ツール）