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

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

回帰テスト 最近のプログラムまたはコードの変更が既存の機能に悪影響を与えていないことを確認するためのソフトウェア テストの一種として定義されます。 これは、既存の機能が正常に動作することを確認するために再実行される、すでに実行されたテスト ケースの完全または部分的な選択に他ならないとも言えます。

このタイプのテストは、新しいコードの変更が既存の機能に副作用を及ぼさないことを確認するために行われます。 最新のコード変更が行われた後も、古いコードが引き続き動作することが保証されます。

なぜ回帰テストを行うのか?

回帰テストのプロセスはテスト範囲において不可欠です。 コードの変更や機能強化によって新たな欠陥が生じているか、既存の機能テストが中断されているかを特定できるためです。

回帰テストプロセスがなければ、コードの小さな変更でも、コストのかかるエラーが発生する可能性があります。 したがって、これはソフトウェアの品質を維持するための体系的な実践です。 この方法は、既知の問題の再発を防止し、ソフトウェアに対する信頼性を高めるのに役立ちます。

回帰テストはいつ実行できますか?

回帰テスト プロセスを適用できるシナリオは次のとおりです。

新しい機能がアプリケーションに追加されます。 これは、アプリまたは Web サイトで新しい機能やモジュールが作成されたときに発生します。 回帰は、新しい機能の導入によって既存の機能が通常どおり動作するかどうかを確認するために実行されます。

変更要件の場合: システムに重大な変更が発生した場合、回帰テストが使用されます。このテストは、これらの変更が既存の機能に影響を与えているかどうかを確認するために行われます。

欠陥が修正された後: 開発者は、機能のバグを修正した後、回帰テストを実行します。 これは、バグの修正中に行われた変更が他の関連する既存の機能に影響を与えたかどうかを判断するために行われます。

パフォーマンスの問題が解決されたら、次のようにします。 パフォーマンスの問題を修正した後、回帰テスト プロセスがトリガーされ、他の既存の機能テストに影響がないかどうかが確認されます。

新しい外部システムとの統合中: 製品が新しい外部システムと統合される場合は常に、エンドツーエンドの回帰テスト プロセスが必要です。

ソフトウェアテストで回帰テストを行う方法

前に説明したように、回帰テストはソフトウェアに加えられた変更に基づいてトリガーされます。変更には、バグ修正、新機能の統合などがあります。このような作業が発生するたびに、QA チームは以下のアクティビティを実行します。これらのタスクは、回帰テスト実行サイクルを開始する前に実行されます。

• 変更中に触れられた特定のモジュールとライブラリについて開発チームと話し合う
• 新機能への変更について製品所有者と話し合い、それが他の機能にどのように影響するか、他の機能にどのような影響を与えるかを学びます。
• 既存のテスト スイートから、既存の機能を回帰するためにテスターが実行する必要があるテストを特定します。

効果的なソフトウェア品質保証のために、さまざまな回帰テスト手法を実行できます。

すべて再テスト

これは回帰テストの方法の XNUMX つであり、特に回帰テスト スイートを使用します。 この場合、既存のテスト バケットまたはスイート内のすべてのテストを再実行する必要があります。 これは多くの時間とリソースを必要とするため、高価な方法です。

回帰テストの選択

回帰テストの選択は、テスト スイートからいくつかの選択されたテスト ケースを実行する手法です。 変更されたコードがソフトウェア アプリケーションに影響を与えるかどうかをテストするのに役立ちます。 ここでは、テスト ケースは XNUMX つの部分に分類されます。 再利用可能なテスト ケースはその後の回帰サイクルで使用できますが、古いテスト ケースは後続のサイクルでは使用できません。

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

テスト ケースの優先順位は、ビジネスへの影響、重要度、および頻繁に使用される機能テストによって異なります。 また、優先順位に基づいてテスト ケースに優先順位を付けることで、回帰テストの実行の労力が大幅に軽減されます。

回帰テスト用のテストケースの選択

業界データから、顧客から報告されたかなりの数の欠陥が直前のバグ修正によるものであることが判明しました。 これにより副作用が発生したため、 テストケース 回帰テストは簡単な作業ではありません。

効果的な回帰テストスイートは、次の種類のテストケースを選択することで構築できます。

• 頻繁に欠陥がある機能/モジュールのテスト ケース。
• ユーザーにとってよりわかりやすい機能
• 製品のコア機能を検証するテスト ケース
• 最近変更された機能のテスト ケース。
• すべての統合の再構築
• すべての複雑なテストケース
• 境界値テストケース
• 選択されたハッピー パスとネガティブ テスト ケース

回帰テストツール

ソフトウェアが頻繁に変更される場合、回帰テストのコストは増大します。 テスト ケースを手動で実行すると、テストの実行時間とコストが増加します。 このような場合には、回帰テスト ケースの自動化が賢明な選択です。 自動化の程度は、後続の回帰サイクルで再利用可能なテスト ケースの数によって異なります。

ソフトウェア エンジニアリングにおける機能テストと回帰テストの両方の自動化に使用される最も重要なツールは次のとおりです。

1) テスト厳格

テスト厳格 は、テストを平易な英語で実行可能な仕様として直接表現するのに役立ちます。あらゆる技術能力のユーザーが、モバイル、Web、API の各ステップを網羅する、あらゆる複雑さのエンドツーエンド テストを構築できます。テスト ステップは、XPath や CSS セレクターなどの実装の詳細に依存するのではなく、エンド ユーザー レベルで表現されます。

機能と特徴：

• 永久に無料の公開バージョン
• テストケースは英語です
• 無制限のユーザーと無制限のテスト
• 自動化を学ぶ最も簡単な方法
• Webステップのレコーダー
• CI/CD およびテスト ケース管理との統合
• メールとSMSのテスト
• XNUMX つのテストで Web + モバイル + API のステップを実行

testRigor にアクセス >>

Selenium: Selenium Web アプリケーションを自動化するために最もよく使用されているオープンソース ツールです。 Selenium ブラウザベースの回帰テストに使用できます。などのプログラミング言語をサポートしています。 Javaルビー、 Python, etc.

クイック テスト プロフェッショナル (QTP): HP Quick Test Professional は、機能テスト ケースと回帰テスト ケースを自動化するように設計された自動ソフトウェアです。 自動化には VB スクリプト言語を使用します。 これはデータ駆動型のキーワードベースのツールです。

合理的機能テスター (RFT): IBMの合理的な機能テスターは Java ソフトウェア アプリケーションのテスト ケースを自動化するために使用されるツール。これは主に回帰テスト ケースを自動化するために使用され、Rational Test Manager とも統合されます。

回帰テストの種類

さまざまな種類の回帰テストを次に示します。

1) ユニット回帰テスト (URT)

これは、影響領域ではなく、変更されたセクションのみが回帰テストの対象となる、非常に焦点を絞ったアプローチです。 このようにして、モジュールの他の部分は影響を受けません。

例:

として たとえば、ビルド 1 では問題が発見され、開発者に報告されました。

それがログイン機能のバグだったとしましょう。 そこで開発者はそれを修正し、バグ修正をビルド 2 に追加して送信します。 テスト チームは、他の機能をチェックするのではなく、ログイン機能が期待どおりに動作するかどうかのみをチェックします。

2) 地域回帰テスト (RRT)

地域回帰テストでは、変更領域と影響領域がテストされます。 この領域は、信頼できるモジュールが変更によって影響を受ける可能性があるかどうかを調べるために検査されます。

例： この例では、最初のビルドでモジュール A、B、C、D が開発者によるテスト用に送信されます。 テスターはモジュール B にバグを発見したため、アプリケーションはバグを修正するために開発者に返されます。

開発者がモジュール B の XNUMX 番目のビルドのバグを修正すると、それが再びテスト エンジニアに送信されます。 テスト エンジニアは、モジュール B を修正したことが A と C に影響を与えたことを知りました。

したがって、テスターは XNUMX 番目のリリースでモジュール B の変更をチェックします。 次に、A と C の影響領域もテストして、どのような影響を受けたかを特定します。

注意： 回帰テスト中に、以下の問題が発生する可能性があります。

問題点：

• ビルド 1 では、通常、クライアントは変更、修正、追加機能を要求します。
• このリクエストは、開発チームとテスト チームの両方に送信されます。
• その後、開発チームが変更を加えます。次に、テスト エンジニアがクライアントに電子メールを送信し、変更が影響を与える領域を通知します。
• 次に、テスト リーダーは、クライアント、開発者、テスト部門から影響を受ける領域のリストを収集します。
• 影響リストはテスト エンジニアに送信され、回帰テストが開始されます。

このタイプのテスト方法では、コミュニケーションのギャップが生じます。開発者と顧客は常に電子メールに戻ることができるとは限らないため、影響領域の概要が適切に把握されません。

解決策： この種の問題を解決するために、テスト チームは、バグ修正、新機能、および変更が行われた新しいビルドが到着したときに会議を手配できます。 この会議は、モジュールが修正によって影響を受けるかどうかを議論するために開催されます。

影響を見つけるためのテストラウンドが行われ、影響リストを作成できるようになります。 テスト リードは、このリストの衝撃領域に最大数のエリアを追加します。

ここで、プロセスは次のようになります。

• アプリケーションの主な機能を確認する「ビルド検証テスト」。
• すべての新機能のテスト。
• 変更または修正された機能を検査します。
• バグの再テスト。
• 次に、最後に、地域回帰テストを使用した影響エリア分析です。

3) 完全な回帰テスト (FRT):

このテストは、アプリケーションのすべての機能をカバーします。完全な回帰テストは通常​​、後のリリースで実行されます。したがって、最初の数回のリリースの後、およびリリース前の最終テストとして FRT を使用できます。

XNUMX 回目または XNUMX 回目の構築では、顧客または事業主が変更を要求する場合があります。 また、新しい機能を要求したり、欠陥を報告したりする場合もあります。 次に、テスト チームは影響分析を実施し、すべての変更を加えて、最終的な完全な製品テストを実行します。

たとえば、4 番目のビルドは発売前の最後のリリースです。 そのため、このビルドでは、テスト チームは、影響を受ける領域や機能だけではなく、製品の完全なテストまたは再テストを実行します。 これは、ビルド 1、2、および 3 の変更とテストの後に行われます。

完全な回帰テストを実行するには、次の状況を考慮する必要があります。

• 変更はアプリケーションのコアコンポーネントで実行されます。 たとえば、アプリまたはコア モジュールのルート ファイルに変更があった場合、アプリケーション全体をリグレッションする必要があります。 多数の変更が加えられた場合。

4) 修正回帰テスト:

このテストは、機能に変更が加えられていない場合に実行されます。 このようなテストは、既存のケースで実行できます。

5) すべての回帰テストを再テストします。

この形式のテストでは、オリジナルまたはビルド 1 からアプリケーションに加えられたすべてのマイナー変更からメジャー変更が再テストされます。

このテストは、他のすべての回帰テストで問題の根本原因を特定できなかった場合に実行されます。

6) 選択的回帰テスト:

これは、プログラムに新しいコードが追加されたときにコードがどのように反応するかを確認するために行われます。 このテストを実行するには、既存のケースのサブセットが使用され、効率的かつコスト効率が高くなります。 サブセットを選択する基準は、変更されたコード モジュール、依存関係、影響を受ける機能の重要度、および過去の欠陥データに基づいています。

7) 漸進的回帰テスト:

このタイプの回帰テストは、プログラムに特定の変更が加えられ、新しいテスト ケースが作成されたときに重要な出力を生成します。

これは、古いバージョンのコンポーネントが最新バージョンで影響を受けていないことを確認するのに役立ちます。

8) 部分回帰テスト:

部分回帰テストは、新しいコードの変更や機能強化が既存の機能に悪影響を与えていないことを検証するために使用されます。 ただし、アプリケーション全体を再テストする完全回帰テストとは異なり、部分回帰テストでは、最近の変更の影響を受けるソフトウェアの特定の部分のみに焦点を当てます。

したがって、部分回帰テストの主な目的は、アプリケーションの変更されていない部分の再テストを回避して時間とリソースを節約することです。 部分回帰テストのテスト ケースは、コード変更の影響分析に基づいて慎重に選択されます。 部分回帰テスト スイートに含める正しいテスト ケースを特定することが重要です。 重要なテスト ケースが欠けていると、問題が見落とされる可能性があります。

自動回帰テスト

前述したように、複数のリリースがある場合には回帰テストの自動化が必要です。 また、複数の回帰サイクルや多数の反復的なアクティビティにも必要です。 複数のリリースにわたって複数のテスト サイクルを実行すると、非常に時間がかかります。

ただし、自動化を使用すると、複数回テストできます。 これには、実行用の自動テスト スクリプトを作成する必要があり、それには関連する計画と設計が必要です。 このようなテストでは、チームは自動化を直接開始することはできません。 したがって、この範囲をカバーするには、手動テスト チームと自動テスト チームの両方を関与させる必要があります。 自動回帰テストがどのように行われるかは次のとおりです。

ステップ1） 手動テスト チームはすべての要件をチェックし、影響を受ける領域を特定します。 このプロセスの後、要件テスト バンドルを自動化チームまたは自動化エンジニアに転送します。

ステップ2） 手動テスト チームは新しいモジュールのテストを開始し、自動テスト チームはスクリプトを作成してテスト ケースを自動化します。

ステップ3） この回帰テスト方法を使用する前に、自動化チームはどのケースが自動化をサポートするかを特定します。

ステップ4） どのケースを自動化できるかに応じて、回帰テストをスクリプトに変換します。

ステップ5） スクリプト作成プロセス中に、自動化チームは回帰テスト ケースを参照します。 彼らは製品、ツール、アプリの知識を持っていない可能性があるため、そうします。

ステップ6） テスト スクリプトが完了すると、自動化チームは新しいアプリでそれらを実行します。

ステップ7） 実行後、結果によってテストが合格か不合格かがわかります。

ステップ8） テストが失敗した場合は、手動テスト方法を使用して再チェックされ、問題が存在する場合は、それぞれの開発者に報告されます。

注意： バグが修正されると、問題と影響範囲が再テストのために手動テスターに​​送信され、自動化チームがスクリプトを再実行します。

ステップ9） このプロセスは、新しく追加されたすべての回帰機能が合格ステータスを取得するまで続きます。

自動回帰テストの利点は次のとおりです。

• 再利用可能： そのテスト スクリプトは、複数のリリースにわたって再利用できます。
• 位置精度： 自動化ツールはタスクを冗長的に実行し、エラーの可能性を減らします。
• 時間を節約する： 手動の機能テスト プロセスよりも高速であり、時間効率が優れています。
• バッチ実行: 自動テストでは、すべてのスクリプトを同時に並列に実行できます。
• リソースを増やす必要はありません: 回帰テストは、新しいリリースがリリースされるたびに増加するはずです。 ただし、自動化のために新しいリソースを追加する必要はありません。

回帰テストのテストケースはどのように選択すればよいですか?

回帰テストに適切なケースを選択する方法は次のとおりです。

• 変更の範囲を理解し、アプリケーションの変更、追加、または修正された部分を特定します。 その後、これらの領域に焦点を当てて回帰テストを行うことができます。
• 重要な機能をカバーし、これを回帰テストのベースラインとして維持するスイートを用意します。 前述したように、これらのテストを自動化することを強くお勧めします。
• 機能の重要性、エンドユーザーへの影響、および過去の欠陥データに基づいてテストに優先順位を付けます。

回帰テストのベストプラクティス

以下に、回帰テストを維持する際に従うべき重要な実践方法をいくつか示します。

可能な限り自動化する

自動回帰テストにより、テストの労力が軽減され、多数のテスト ケースを迅速に実行できるようになります。

継続的インテグレーション

回帰テストを CI/CD パイプラインに組み込むと、コードベースに変更がコミットされるたびにテストが自動的に実行されます。

テストケースの選択

コア機能と高リスク領域を表すテスト ケースのサブセットを特定し、維持します。 以前のテスト ケースをすべて実行するのは現実的ではないため、行われる変更に直接関連するものを選択することもできます。

定期実行

回帰テストを定期的に、特にコードを変更するたびに実行してください。 これは、開発プロセスの初期段階で問題を特定するのに役立ちます。

テストデータ管理

データ関連の問題はテスト結果に影響を与える可能性があるため、回帰テストに使用されるテスト データが一貫性があり、管理可能であることを確認してください。

環境管理

一貫性があり再現可能なテスト環境を維持します。これには、本番環境で使用されているものと同じオペレーティング システム、ブラウザー、デバイス構成の使用が含まれます。

欠陥の記録と追跡

回帰テスト中に発見された欠陥はすべて記録され、追跡され、管理される必要があります。 重大度に基づいて解決に優先順位を付けます。

再利用性

再利用可能なテスト スクリプトとテスト データを作成して、重複を減らし、保守性を向上させます。

回帰テストと構成管理

コードが継続的に変更されるアジャイル環境では、回帰テスト中の構成管理が必須になります。効果的な回帰テストを確実に行うには、次の点に注意してください。

• 回帰テストの対象となるコードは、構成管理ツールの下にある必要があります。
• 回帰テスト段階ではコードに変更を加えてはなりません。 回帰テスト コードは開発者の変更の影響を受けないようにする必要があります。
• 回帰テストに使用されるデータベースは分離する必要があります。 データベースの変更を許可してはなりません

再テストと回帰テストの違い

再テストとは、コードが修正されていることを確認するために、欠陥やバグの機能を再度テストすることを意味します。 修正されていない場合は、 欠陥 再度開く必要があります。 修正されれば、欠陥は閉じられます。

回帰テストとは、ソフトウェア アプリケーションのコードが変更されたときにテストすることを意味します。 これは、新しいコードがソフトウェアの他の部分に影響を与えていないことを確認するために行われます。

これら XNUMX つのテストの主な違いは次のとおりです。

再テスト	回帰試験
欠陥修正専用に構築されています。	回帰テストは主に、コードの変更が他の機能に影響を与えているかどうかを検証するために行われます。
再テストでは他のバージョンはチェックされず、壊れた機能が復元されるかどうかのみが検証されます。	以前のバージョンに焦点を当て、以前の機能が引き続き期待どおりに動作するかどうかをテストします。
それぞれのテストは特殊です	回帰は一般的なテストです。
このテストは、失敗したテスト ケースに対するものです。	合格したテストケース用です。
特定の欠陥をチェックするため、自動化することはできません。	自動化できる。 また、前述のように自動化することを強くお勧めします。
再テストはバグが見つかった場合にのみ必要となるため、常にテスト サイクルの一部であるわけではありません。	コードが変更されるたびに、製品の機能が安定しているかどうかを理解するためにこのテストを実行する必要があるため、回帰は常にテストの一部です。
既知の問題に焦点を当てているため、優先度の高いテストです。	これは、潜在的な欠陥の全体的なテストであるため、優先度の低いテストです。
このテストは特定の欠陥に対して行われるため、時間はかかりません。	ソフトウェアの広い領域が関与するため、時間がかかります。
異なる入力と新しいバージョンを使用して、同じデータと環境で欠陥を特定します。	このテストでは、ユーザーマニュアル、不具合レポート、機能仕様から事例を取得できます。
最初の検査がなければ再検査はできません。	これは、既存のプロジェクトで変更や修正が必要な場合に行われます。

また、相違点の完全なリストも確認してください。 こちら.

回帰テストの長所と短所

優位性

• 回帰テストにより製品の品質が向上します。
• このテストにより、変更とバグ修正によって既存の機能が変更されていないことを確認できます。
• 回帰ベッドは既存の機能で実行されるため、古い欠陥も確実にカバーされます。
• 効率的な製品開発が促進されます。
• このテストを実施すると、高いユーザー満足度を達成できます。
• 全体として、ソフトウェアの安定性が維持されます。

デメリット

• わずかな変更が既存のモジュールに問題を引き起こす可能性があるため、小さな変更が行われるたびに実行する必要があります。
• このテストは手動で行うと時間がかかり、テストを繰り返す必要があります。

回帰テストの課題

回帰テストを実行する際の主なテスト上の問題は次のとおりです。

• 回帰を連続して実行すると、テスト スイートはかなり大きくなります。 時間と予算の制約により、回帰テスト スイート全体を実行することはできません
• テストスイートを最小限に抑えながら最大限のパフォーマンスを達成することは依然として課題です
• 回帰テストの頻度、つまり、すべての変更後、ビルド更新後、または多数のバグ修正後、を決定するのは困難です。

動画による回帰テストの実践例

クリック こちら ビデオにアクセスできない場合

回帰テストの例 – Amazon

電子商取引の巨人について考えてみましょう Amazonは、収益創出をウェブサイトに依存している数十億ドル規模の企業です。機能性、信頼性、パフォーマンスを維持するために、回帰テストが重要な役割を果たします。

新しい製品カテゴリを追加するシナリオを考えてみましょう。

想像してみてください Amazon 同社は、「電子機器」や「衣料品」などの既存のカテゴリーに加えて、「スマートホームデバイス」という新しいカテゴリーを導入し、製品ラインナップを拡大することを決定しました。

考えられる回帰ケースは次のとおりです。

ホームページの機能: ホームページに新しい「スマート ホーム デバイス」カテゴリが既存のカテゴリと並んで表示上の問題なく表示されていることを確認します。

カテゴリ ナビゲーション: ユーザーが問題なく「スマート ホーム デバイス」カテゴリ ページにスムーズに移動し、ホームページに戻れるようにします。

検索機能: ユーザーがスマート ホーム デバイスを検索したときに検索バーがその結果を正確に返し、他の製品と混在しないようにします。

ユーザー アカウント: ユーザー アカウントが作成、更新され、スマート ホーム デバイスやその他の製品の購入に利用できることを確認します。

支払い処理: 購入に特化した支払いゲートウェイをテストし、安全でエラーのない取引を保証します。

モバイル対応: ウェブサイトがモバイル対応であり、ユーザーがさまざまなデバイスでスマートホーム デバイスにアクセスして購入できることを確認します。

これらの回帰テスト ケースのいずれかが失敗した場合は、新しい製品カテゴリの追加による Web サイトの既存の機能に問題があることを示します。この問題は文書化して直ちに解決する必要があります。さらに、 Amazon サービスの拡充と Web サイトの変更を継続している場合、信頼性の高いオンライン ショッピング エクスペリエンスを維持するには、これらの回帰テストを実行する必要があります。自動テスト ツールを使用すると、このプロセスを合理化できます。

まとめ：

• 回帰テストの意味 – 回帰テストは、アプリケーションが改善、コード変更、またはバグ修正後も期待どおりに機能することを確認するソフトウェア テストの一種です。
• 効果的な回帰戦略により、組織は時間と費用の両方を節約できます。
• ケーススタディによると、回帰により、その後のバグ修正の最大 60% が節約されました。