統合テストとは何ですか? (例)

統合テストとは何ですか?

統合テスト ソフトウェアモジュールが論理的に統合され、グループとしてテストされるテストの一種として定義されます。 一般的なソフトウェア プロジェクトは、異なるプログラマーによってコーディングされた複数のソフトウェア モジュールで構成されます。 このレベルのテストの目的は、これらのソフトウェア モジュールが統合される際の相互作用における欠陥を明らかにすることです。

統合テストは、これらのモジュール間のデータ通信のチェックに焦点を当てます。 したがって、それは次のようにも呼ばれます 'それ' (統合とテスト)、 「文字列テスト」 時には 「スレッドテスト」.

なぜ統合テストを行うのでしょうか?

統合テスト

各ソフトウェア モジュールは単体テストされていますが、次のようなさまざまな理由で欠陥が依然として存在します。

  • 一般に、モジュールは個々のソフトウェア開発者によって設計され、その理解やプログラミング ロジックは他のプログラマとは異なる場合があります。ソフトウェアモジュールが動作することを検証するには、統合テストが必要になります。 unity
  • モジュール開発時には、クライアントの要件が変更される可能性が高くなります。 これらの新しい要件は単体テストされていない可能性があるため、システム統合テストが必要になります。
  • ソフトウェアモジュールとデータベースのインターフェースにエラーがある可能性がありますneous
  • 外部ハードウェア インターフェイスがある場合、エラーが発生する可能性がありますneous
  • 例外処理が不適切だと問題が発生する可能性があります。

クリック (茶事の話はこちらをチェック) ビデオにアクセスできない場合

統合テストケースの例

統合 テストケース という意味で他のテストケースとは異なります。 主にモジュール間のインターフェースとデータ/情報の流れに焦点を当てます。 ここで優先されるのは、 リンクの統合 すでにテストされているユニット関数ではなく。

以下の統合テスト ケースのサンプルwing シナリオ: アプリケーションには「ログイン ページ」、「」という 3 つのモジュールがあります。Mailbox' および 'e を削除mail」とそれぞれが論理的に統合されています。

ログイン ページのテストはすでに行われているため、ここではあまり集中しません。 単体テスト。ただし、それがどのようにリンクされているかを確認してください Mail Box ページ。

同様に Mail Box: 削除への統合を確認します。 Mail■モジュール。

テストケースID テストケースの目的 テストケースの説明 期待される結果
1 ログインと間のインターフェイス リンクを確認してください。 Mailbox モジュール ログイン資格情報を入力し、「ログイン」ボタンをクリックします に誘導されるのは、 Mail Box
2 間のインターフェイス リンクを確認します。 Mailbox および削除 Mailモジュール Mailbox eを選択してくださいmail そして削除ボタンをクリックしてください 選択されたemail 削除済み/ゴミ箱フォルダーに表示されるはずです

結合テストの種類

ソフトウェアエンジニアリングは、統合テストを実行するためのさまざまな戦略を定義します。 viz.

  • ビッグバンアプローチ:
  • インクリメンタルアプローチ: さらに次のように分かれています。wing
    • トップダウンアプローチ
    • ボトムアップアプローチ
    • サンドイッチアプローチ – トップダウンとボトムアップの組み合わせ

以下に、さまざまな戦略、その実行方法、およびその制限と利点を示します。

ビッグバンテスト

ビッグバンテスト すべてのコンポーネントまたはモジュールを一度に統合し、ユニットとしてテストする統合テストのアプローチです。 このコンポーネントの組み合わせセットは、テスト中は XNUMX つのエンティティとみなされます。 ユニット内のすべてのコンポーネントが完了していない場合、統合プロセスは実行されません。

Advantages:

  • 小規模なシステムに便利です。

短所:

  • 障害の位置特定は困難です。
  • このアプローチではテストする必要があるインターフェイスの数が非常に多いため、テスト対象の一部のインターフェイス リンクが簡単に見落とされる可能性があります。
  • 統合テストは「すべての」モジュールが設計された後でのみ開始できるため、テスト チームがテスト段階で実行できる時間が短くなります。
  • すべてのモジュールが一度にテストされるため、リスクの高い重要なモジュールが分離されず、優先的にテストされます。 ユーザーインターフェイスを扱う周辺モジュールも分離されず、優先的にテストされます。

増分テスト

増分テスト このアプローチでは、テストは、論理的に相互に関連する XNUMX つ以上のモジュールを統合することによって行われ、アプリケーションが適切に機能するかどうかがテストされます。 次に、他の関連モジュールが段階的に統合され、論理的に関連するすべてのモジュールが統合され、テストが成功するまでプロセスが続行されます。

インクリメンタル アプローチは、次の XNUMX つの異なる方法で実行されます。

  • 一気飲み
  • トップダウン

スタブとドライバー

スタブとドライバー 統合テストを容易にするために使用されるダミー プログラムです。 ソフトウェアテスト 活動。 これらのプログラムは、テストで不足しているモデルの代替として機能します。 これらはソフトウェア モジュールのプログラミング ロジック全体を実装するわけではありませんが、テスト中に呼び出し側モジュールとのデータ通信をシミュレートします。

スタブ: テスト対象のモジュールによって呼び出されます。

ドライバ: テスト対象のモジュールを呼び出します。

ボトムアップ統合テスト

ボトムアップ統合テスト これは、下位レベルのモジュールが最初にテストされる戦略です。 これらのテストされたモジュールは、より高いレベルのモジュールのテストを容易にするためにさらに使用されます。 このプロセスは、トップレベルのすべてのモジュールがテストされるまで続きます。 下位レベルのモジュールがテストされ統合されると、次のレベルのモジュールが形成されます。

図形表現:

ボトムアップ統合テスト

Advantages:

  • 障害の位置特定が容易になります。
  • ビッグバンアプローチとは異なり、すべてのモジュールが開発されるのを待って時間を無駄にすることはありません

短所:

  • 重要なモジュール (ソフトウェアのトップレベル) archiアプリケーションのフローを制御するテクチャ)は最後にテストされるため、欠陥が発生しやすい可能性があります。
  • 初期のプロトタイプは不可能

トップダウン統合テスト

トップダウンの統合テスト 統合テストは上から下へ行われる方法です。wing ソフトウェアシステムの制御フロー。 ソフトウェアの機能をチェックするために、最初に上位レベルのモジュールがテストされ、次に下位レベルのモジュールがテストおよび統合されます。 スタブは、一部のモジュールの準備ができていない場合のテストに使用されます。

ダイアグラム表現:

トップダウン統合テスト

Advantages:

  • 障害の位置特定が容易になります。
  • 初期のプロトタイプを入手する可能性。
  • 重要なモジュールは優先的にテストされます。 主要な設計上の欠陥が最初に発見され、修正される可能性があります。

短所:

  • 多くのスタブが必要です。
  • 下位レベルのモジュールは不十分にテストされます。

サンドイッチ試験

サンドイッチ試験 これは、最上位モジュールを下位レベルのモジュールでテストすると同時に、下位モジュールを最上位モジュールと統合してシステムとしてテストする戦略です。 トップダウンアプローチとボトムアップアプローチを組み合わせたものであるため、このように呼ばれます。 ハイブリッド統合テスト。 スタブとドライバーの両方を使用します。

サンドイッチ試験

統合テストはどのように行うのですか?

ソフトウェア テスト戦略 (前述) に関係なく、統合テスト手順は次のとおりです。

  1. 統合の準備 テスト計画
  2. テスト シナリオ、ケース、スクリプトを設計します。
  3. テストケースを実行し、続いて欠陥を報告します。
  4. 欠陥の追跡と再テスト。
  5. 統合が正常に完了するまで、ステップ 3 と 4 が繰り返されます。

統合テスト計画の簡単な説明

以下が含まれますwing 属性:

  • テストの方法/アプローチ (前述)。
  • 結合テストの範囲と範囲外の項目。
  • 役割と責任。
  • 統合テストの前提条件。
  • テスト環境。
  • リスクと軽減計画。

結合テストの開始基準と終了基準

あらゆるソフトウェア開発モデルにおける統合テストフェーズへの開始基準と終了基準

エントリー基準:

  • 単体テスト済みのコンポーネント/モジュール
  • 優先度の高いすべてのバグが修正されクローズされました
  • すべてのモジュールのコードが完成し、正常に統合されること。
  • 統合テスト 計画、テスト ケース、シナリオを承認して文書化します。
  • 必須 テスト環境 統合テスト用にセットアップする

終了基準

  • 統合アプリケーションのテストが成功しました。
  • 実行されたテストケースは文書化されます
  • 優先度の高いすべてのバグが修正されクローズされました
  • 技術文書の後にリリースノートを提出する必要があります。

統合テストのベスト プラクティス/ガイドライン

  • まず、統合を決定します テスト戦略 それは採用されるかもしれないし、 later それに応じてテスト ケースとテスト データを準備します。
  • 勉強する Archiアプリケーションの構造設計を検討し、重要なモジュールを特定します。これらは優先的にテストする必要があります。
  • インターフェイス デザインを次から入手します。 Archi構造チームと協力してテスト ケースを作成し、すべてのインターフェイスを詳細に検証します。データベース/外部ハードウェア/ソフトウェア アプリケーションへのインターフェイスは詳細にテストする必要があります。
  • テスト ケースの次に重要な役割を果たすのはテスト データです。
  • 実行する前に、必ずモック データを準備してください。 テスト ケースの実行中にテスト データを選択しないでください。