統合テストとは何ですか? (例)
統合テストとは何ですか?
統合テスト ソフトウェアモジュールが論理的に統合され、グループとしてテストされるテストの一種として定義されます。 一般的なソフトウェア プロジェクトは、異なるプログラマーによってコーディングされた複数のソフトウェア モジュールで構成されます。 このレベルのテストの目的は、これらのソフトウェア モジュールが統合される際の相互作用における欠陥を明らかにすることです。
統合テストは、これらのモジュール間のデータ通信のチェックに焦点を当てます。 したがって、それは次のようにも呼ばれます 'それ' (統合とテスト)、 「文字列テスト」 時には 「スレッドテスト」.
なぜ統合テストを行うのでしょうか?
各ソフトウェア モジュールは単体テストされていますが、次のようなさまざまな理由で欠陥が依然として存在します。
- モジュールは一般的に、他のプログラマーとは異なる理解とプログラミングロジックを持つ個々のソフトウェア開発者によって設計されます。ソフトウェアモジュールが統一的に機能することを確認するために統合テストが必要になります。
- モジュール開発時には、クライアントの要件が変更される可能性が高くなります。 これらの新しい要件は単体テストされていない可能性があるため、システム統合テストが必要になります。
- ソフトウェアモジュールとデータベースのインターフェースに誤りがある可能性がある
- 外部ハードウェアインターフェース(存在する場合)にエラーがある可能性があります
- 例外処理が不適切だと問題が発生する可能性があります。
クリック こちら ビデオにアクセスできない場合
統合テストケースの例
統合 テストケース という意味で他のテストケースとは異なります。 主にモジュール間のインターフェースとデータ/情報の流れに焦点を当てます。 ここで優先されるのは、 リンクの統合 すでにテストされているユニット関数ではなく。
次のシナリオのサンプル統合テストケース: アプリケーションには「ログインページ」という3つのモジュールがあります。Mail「ボックス」と「メールを削除」があり、それぞれが論理的に統合されています。
ログイン ページのテストはすでに行われているため、ここではあまり集中しません。 単体テスト。ただし、それがどのようにリンクされているかを確認してください Mail Box ページ。
同様に Mail Box: 削除への統合を確認します。 Mail■モジュール。
テストケースID | テストケースの目的 | テストケース Descriptexpression CMS | 期待される結果 |
---|---|---|---|
1 | ログインと間のインターフェイス リンクを確認してください。 Mailボックスモジュール | ログイン資格情報を入力し、「ログイン」ボタンをクリックします | に誘導されるのは、 Mail Box |
2 | 間のインターフェイス リンクを確認します。 Mailボックスと削除 Mailモジュール | Mailボックスでメールを選択し、削除ボタンをクリックします | 選択したメールは削除済み/ゴミ箱フォルダに表示されます |
結合テストの種類
ソフトウェア エンジニアリングでは、統合テストを実行するためのさまざまな戦略を定義します。
- ビッグバンアプローチ:
- インクリメンタルアプローチ:さらに以下のように分類されます
- トップダウンアプローチ
- ボトムアップアプローチ
- サンドイッチアプローチ – トップダウンとボトムアップの組み合わせ
以下に、さまざまな戦略、その実行方法、およびその制限と利点を示します。
ビッグバンテスト
ビッグバンテスト すべてのコンポーネントまたはモジュールを一度に統合し、ユニットとしてテストする統合テストのアプローチです。 このコンポーネントの組み合わせセットは、テスト中は XNUMX つのエンティティとみなされます。 ユニット内のすべてのコンポーネントが完了していない場合、統合プロセスは実行されません。
Advantages:
- 小規模なシステムに便利です。
短所:
- 障害の位置特定は困難です。
- このアプローチではテストする必要があるインターフェイスの数が非常に多いため、テスト対象の一部のインターフェイス リンクが簡単に見落とされる可能性があります。
- 統合テストは「すべての」モジュールが設計された後でのみ開始できるため、テスト チームがテスト段階で実行できる時間が短くなります。
- すべてのモジュールが一度にテストされるため、リスクの高い重要なモジュールが分離されず、優先的にテストされます。 ユーザーインターフェイスを扱う周辺モジュールも分離されず、優先的にテストされます。
増分テスト
増分テスト このアプローチでは、テストは、論理的に相互に関連する XNUMX つ以上のモジュールを統合することによって行われ、アプリケーションが適切に機能するかどうかがテストされます。 次に、他の関連モジュールが段階的に統合され、論理的に関連するすべてのモジュールが統合され、テストが成功するまでプロセスが続行されます。
インクリメンタル アプローチは、次の XNUMX つの異なる方法で実行されます。
- 一気飲み
- トップダウン
スタブとドライバー
スタブとドライバー 統合テストを容易にするために使用されるダミー プログラムです。 ソフトウェアテスト 活動。 これらのプログラムは、テストで不足しているモデルの代替として機能します。 これらはソフトウェア モジュールのプログラミング ロジック全体を実装するわけではありませんが、テスト中に呼び出し側モジュールとのデータ通信をシミュレートします。
スタブ: テスト対象のモジュールによって呼び出されます。
ドライバ: テスト対象のモジュールを呼び出します。
ボトムアップ統合テスト
ボトムアップ統合テスト これは、下位レベルのモジュールが最初にテストされる戦略です。 これらのテストされたモジュールは、より高いレベルのモジュールのテストを容易にするためにさらに使用されます。 このプロセスは、トップレベルのすべてのモジュールがテストされるまで続きます。 下位レベルのモジュールがテストされ統合されると、次のレベルのモジュールが形成されます。
図形表現:
Advantages:
- 障害の位置特定が容易になります。
- ビッグバンアプローチとは異なり、すべてのモジュールが開発されるのを待って時間を無駄にすることはありません
短所:
- アプリケーションのフローを制御する重要なモジュール (ソフトウェア アーキテクチャの最上位レベル) は最後にテストされ、欠陥が発生しやすくなります。
- 初期のプロトタイプは不可能
トップダウン統合テスト
トップダウンの統合テスト ソフトウェア システムの制御フローに従って、上から下に向かって統合テストを実行する方法です。最初に上位レベルのモジュールをテストし、次に下位レベルのモジュールをテストして統合し、ソフトウェアの機能をチェックします。一部のモジュールが準備できていない場合は、スタブを使用してテストします。
ダイアグラム表現:
Advantages:
- 障害の位置特定が容易になります。
- 初期のプロトタイプを入手する可能性。
- 重要なモジュールは優先的にテストされます。 主要な設計上の欠陥が最初に発見され、修正される可能性があります。
短所:
- 多くのスタブが必要です。
- 下位レベルのモジュールは不十分にテストされます。
サンドイッチ試験
サンドイッチ試験 これは、最上位モジュールを下位レベルのモジュールでテストすると同時に、下位モジュールを最上位モジュールと統合してシステムとしてテストする戦略です。 トップダウンアプローチとボトムアップアプローチを組み合わせたものであるため、このように呼ばれます。 ハイブリッド統合テスト。 スタブとドライバーの両方を使用します。
統合テストはどのように行うのですか?
ソフトウェア テスト戦略 (前述) に関係なく、統合テスト手順は次のとおりです。
- 統合の準備 テスト計画
- テスト シナリオ、ケース、スクリプトを設計します。
- テストケースを実行し、続いて欠陥を報告します。
- 欠陥の追跡と再テスト。
- 統合が正常に完了するまで、ステップ 3 と 4 が繰り返されます。
手紙 Descript統合テスト計画の作成
以下の属性が含まれます。
- テストの方法/アプローチ (前述)。
- 結合テストの範囲と範囲外の項目。
- 役割と責任。
- 統合テストの前提条件。
- テスト環境。
- リスクと軽減計画。
結合テストの開始基準と終了基準
あらゆるソフトウェア開発モデルにおける統合テストフェーズへの開始基準と終了基準
エントリー基準:
- 単体テスト済みのコンポーネント/モジュール
- 優先度の高いすべてのバグが修正されクローズされました
- すべてのモジュールのコードが完成し、正常に統合されること。
- 統合テスト 計画、テスト ケース、シナリオを承認して文書化します。
- 必須 テスト環境 統合テスト用にセットアップする
終了基準
- 統合アプリケーションのテストが成功しました。
- 実行されたテストケースは文書化されます
- 優先度の高いすべてのバグが修正されクローズされました
- 技術文書の後にリリースノートを提出する必要があります。
統合テストのベスト プラクティス/ガイドライン
- まず、統合を決定します テスト戦略 採用できるものを選択し、それに応じてテストケースとテストデータを準備します。
- 勉強する Archiアプリケーションの構造設計を検討し、重要なモジュールを特定します。これらは優先的にテストする必要があります。
- インターフェイス デザインを次から入手します。 Archi構造チームと協力してテスト ケースを作成し、すべてのインターフェイスを詳細に検証します。データベース/外部ハードウェア/ソフトウェア アプリケーションへのインターフェイスは詳細にテストする必要があります。
- テスト ケースの次に重要な役割を果たすのはテスト データです。
- 実行する前に、必ずモック データを準備してください。 テスト ケースの実行中にテスト データを選択しないでください。