編集元: https://blog.csdn.net/vikeyyyy/article/details/80900540
序章
統合テスト（統合テスト）、アセンブリテストまたはジョイントテストとも呼ばれます。単体テストに基づいて、設計要件に従って（構造図に従ってなど）、すべてのモジュールをサブシステムまたはシステムに組み立て、結合テストを実施します。
統合テスト (アセンブリ テスト、ジョイント テストとも呼ばれます) は、単体テストの論理的な拡張です。最も単純な形式では、テストされる 2 つのユニットを 1 つのコンポーネントに結合し、それらの間のインターフェイスをテストします。この意味で、コンポーネントとは、複数のユニットが統合された集合体を指します。実際のシナリオでは、多くのユニットがコンポーネントに結合され、コンポーネントが集合してプログラムのより大きな部分になります。このアプローチは、フラグメントの組み合わせをテストし、最終的にはプロセスに拡張して、モジュールを他のモジュール グループと一緒にテストすることです。最後に、プロセスを構成するすべてのモジュールが一緒にテストされます。また、プログラムが複数のプロセスで構成されている場合は、すべてのプロセスを同時にテストするのではなく、ペアでテストする必要があります。
統合テストは単体テストに基づいており、すべてのソフトウェアユニットが概略設計仕様の要件に従ってモジュール、サブシステム、またはシステムに組み立てられているかどうか、各部分の作業が対応する技術指標と要件を満たしているか実現しているかどうかをテストします。 。つまり、結合テストの前に単体テストが完了している必要があり、結合テストで使用されるオブジェクトは単体テストが完了したソフトウェア ユニットである必要があります。これは非常に重要です。単体テストが不合格になると、結合テストの効果に大きな影響が生じ、ソフトウェア単体コードのエラー訂正コストが大幅に増加するからです。
すべてのソフトウェアプロジェクトはシステム統合の段階から逃れることはできません。どのような開発モードを採用する場合でも、具体的な開発作業は 1 つのソフトウェア ユニットから 1 つずつ開始する必要があり、ソフトウェア ユニットは統合によってのみ有機的な全体を形成できます。特定の統合プロセスは、明示的または暗黙的である場合があります。統合が行われる限り、共通の問題は必ず発生しますが、エンジニアリングの現場では、ソフトウェア単位が問題なく組み立てられるケースはほとんどありません。結合テストは単体テストよりもはるかに時間がかかり、単体テストからシステムテストに直接移行するのは極めて不適切です。
テストの焦点
一部のモジュールは単独で動作しますが、接続したときに正常に動作するという保証はありません。プログラムの一部で反映されない問題がグローバルに顕在化し、機能の実現に影響を与える可能性があります。そのため、統合テストを行う必要があります。2 つの主要な質問: 1. モジュール間のインターフェイス (インターフェイス カバレッジ) (1) モジュールを接続すると、モジュール インターフェイスを通過するデータは失われますか。(2) グローバルデータ構造に問題はないか、異常な改ざんはないか。2. 統合機能（パラメータ転送）(1) 各サブ機能の組み合わせが期待する親機能を実現できるかどうか。(2) あるモジュールの機能が他のモジュールの機能に悪影響を与えるかどうか。(3) 単一モジュールのエラーが許容できないレベルまで蓄積された場合に拡大するかどうか。
3 つのレベルの統合テスト
統合の強度が異なるため、統合テストは通常 3 つのレベルに分けることができます。
1. モジュール内統合テスト。
2. サブシステム内の統合テスト。
3. サブシステム間の統合テスト。
統合テストのパターン
非増分テスト: 最初に各モジュールを個別にテストし、次に設計要件に従ってすべてのモジュールを一度に組み立ててから、全体のテストを実行します。非増分テスト中に多数のエラーが見つかる可能性があります。各エラーを見つけて修正することは非常に困難であり、1 つのエラーを修正する間に新しいエラーが発生する可能性があります。古いエラーと新しいエラーが混在しているため、特定がさらに困難になります。エラーの原因と場所。Big Bang Ensemble などの非インクリメンタルなメソッド。
増分テスト: 統合テスト用にテスト済みモジュールに未テストのモジュールを 1 つずつアセンブルします。新しいモジュールがテスト用に追加されるたびに、プログラムのアセンブリが完了するまでこのプロセスを繰り返します。増分テストには、トップダウンとボトムアップの組み立て方法があります。
2 つの違いは次のとおりです:
1. ノンインクリメンタル方式は、単体テストと結合テストを 2 つの異なる段階に分割し、モジュールの単体テストは前の段階で完了し、結合テストは前の段階で完了します。後期。増分テストは、単体テストと統合テストを組み合わせて、同時に完了します。
2. ノンインクリメンタル型は各モジュールにドライバモジュールとスタブモジュールが必要となるため工数がかかりますが、インクリメンタル型はテスト済みのモジュールをドライバモジュールまたはスタブモジュールとして使用するため工数が少なくなります。
3. インクリメンタル型はインターフェース間のエラーを早期に検出でき、ノンインクリメンタル型は最終組み立てまで発見されません。
4. インクリメンタルモードではミスが発生しやすく、新たに追加したモジュールに関連したエラーが発生することが多いのですが、非インクリメンタルモードではインターフェイスのエラーが最後まで遅れて発生するため、インターフェイスのどの部分が間違っているかを判断するのが困難です。
5. インクリメンタル方式は比較的徹底的であり、テスト済みのモジュールと新しいモジュールがテストされています。
6. ノンインクリメンタルスタートにより、すべてのモジュールを並行してテストできるため、人的資源を最大限に活用でき、大規模なソフトウェアをテストする場合に非常に有意義です。
統合テスト戦略
統合テストには主に 3 つの戦略があります。
1. ビッグバン統合。
2. トップダウンの統合。
3. ボトムアップの統合。
上記の 3 つのテスト戦略に基づいて、次の 5 つの統合テスト戦略が提案されています。これらはすべて、上記の 3 つの主要なテスト戦略に基づいて統合および改善されています。
1. サンドイッチの統合。
2. バックボーンの統合。
3. レイヤーの統合。
4. 機能ベースの統合。
5. スケジュールベースの統合
ビッグバン統合
(1) 概念: ビッグバン インテグレーションは、非増分インテグレーションの手法であり、ワンタイム アセンブリまたは全体アセンブリとも呼ばれます。この統合により、コンポーネント間の相互依存性や潜在的なリスクに関係なく、すべてのコンポーネントが一度にテスト対象のシステムに統合されます。
(2) 目的：システムを最短時間で組み立て、最小限のテストでシステム全体を検証する。
(3) 戦略: ビッグバン統合手法では、まず各モジュールの単体テストを実施し、次にすべてのユニットを組み立ててテストし、最終的に必要なソフトウェア システムを取得する必要があります。
(4) 利点:
* 有利な状況下では、ビッグバン統合は統合テストを迅速に完了でき、非常に少数のドライブ ユニットとスタブ ユニット (必要な場合) のみを必要とします。
* 必要なテストケースは最小限です。
※方法は比較的簡単です。
※並行して実施でき、人的・物的資源の資源利用率が高い。
(5) デメリット:
* 単体テストをベースに、コンポーネント間の依存関係を考慮せずにすべてのコンポーネントを一度に組み立てます。単純ではありますが、プログラム内にモジュール間インターフェイスやグローバル データ構造が必然的に存在するため、他の問題があるため、試行が成功する可能性は高くありません。
※エラーが見つかった場合、問題を特定して修正することが困難です。
*テスト対象のシステムを一度に統合できたとしても、依然として多くのインターフェイスの問題が発生し、統合テストを回避してシステム テストに入る可能性があります。
(6) 適用範囲:
*保守プロジェクト (または機能拡張プロジェクト)。以前の製品は非常に安定しており、新しいプロジェクトのコンポーネントはわずかに追加または変更されています。
* テスト対象のシステムは比較的小規模で、その各コンポーネントは完全に単体テストされています。
トップダウンの統合
(1) 概念: トップダウン統合 (トップダウン統合) は、テストの設計と同じ順序を採用し、初めてシステムの制御インターフェイスを検証し、トップレベルのコンポーネントが制御責任を負います。この統合方法では、深さ優先戦略と幅優先戦略を採用できます。
(2) 目的: 最上位層から制御し、設計と同じ考え方を使用してシステムをテストし、システムのインターフェイスの安定性を検証します。
(3) 戦略:
*メインモジュールをテスト対象モジュールおよびドライブモジュールとし、メインモジュール直下のすべての従属モジュールをスタブユニットに置き換えてメインモジュールをテストします。
*深さ優先 (Depth-First) または幅優先 (Breath-First) 戦略を採用し、対応するスタブ モジュールを実際のモジュールで置き換え、次にその直接の従属モジュールをスタブ モジュールで置き換え、テスト済みのモジュールで新しいサブシステムまたはモジュールを形成します。システム。
(4) メリット：
・トップダウン統合方式により、テスト工程の早い段階で主制御点と判定点を検証するため、主制御に問題があった場合でも早期に発見でき、今後の手戻りを軽減できるため、とても重要です、必要です。
*深さ優先戦略を採用すると、最初に完全なソフトウェア機能を実現して検証でき、最初にロジック入力の分岐を組み立ててテストでき、隠れたエラーや欠陥をチェックしてサービスでき、機能の正確性を確認できます。検証することができ、さらなる分析に使用できます。主要な処理ブランチの組み立てとテストにより、保証が提供されます。
※機能の実現可能性は事前に確認しております。
* 必要なドライバーモジュールは最大 1 つだけなので、ドライバーモジュールのコストが削減され、後段のドライバーモジュールのメンテナンスも軽減されます。
※この手法は設計と考え方が同じであるため、設計と並行して行うことができ、対象環境や設計を変更する必要がある場合にも柔軟に対応できます。
* 障害分離をサポートします。例: モジュール A のテストは正常ですが、モジュール B の後に問題がある場合は、モジュール B に問題があるか、モジュール A とモジュール B の間のインターフェイスに問題があると判断できます。 。
(5) 欠点:
* すべてのテストでスタブを提供する必要があるため、スタブの開発と保守がこの戦略の最大のコストとなります。
* 最下位レベルのコンポーネントで予期せぬニーズが発生すると、多くの最上位コンポーネントが変更され、以前に構築されたテスト スイートの一部が破損する可能性があります。
* 基礎となるコンポーネントの動作の検証は延期されます。
*基礎となるモジュールの数が増加し続けるにつれて、システムはますます複雑になり、基礎となるモジュール、特に再利用されるモジュールのテストが不十分になります。
(6) 適用範囲:
*製品管理構造は比較的明確で安定しています。
※製品の上位層は比較的安定しており、下位層は頻繁に変化します。
※製品の制御モジュールには技術的なリスクがある可能性があるため、早期に検証する必要があります。
*製品のシステム機能の動作をできるだけ早く確認できることを願っています。
ボトムアップの統合
(1) 概念: ボトムアップ統合は、プログラム モジュール構造の一番下のモジュールからアセンブルとテストを開始します。モジュールは下から上にテストされるため、特定のレベルのモジュールについては、そのサブモジュールはすでにアセンブルおよびテストされています。そのため、スタブ モジュールは必要なくなりました。サブモジュールから取得する必要がある情報は、サブモジュールを実行することで直接取得できます。
(2) 目的: 依存関係が最小限の最下位コンポーネントから開始して、依存関係ツリーの構造に従い、層ごとに上位のコンポーネントを統合して、システム全体の安定性を検証します。
(3) 戦略:
*システムの最下位モジュールから始めて、複数のサブモジュールをテストのためにマージすることもできます。
*ドライバー モジュールを使用して、選択したモジュールをテストします。
* ドライバー モジュールを実際のモジュールに置き換え、テスト済みのサブモジュールとともにテスト用に大きなモジュール グループに組み立てます。
*システムの最上位モジュールがテスト対象システムに追加されるまで、上記の手順を繰り返します。
(4) 利点:
* 基礎となるモジュールの動作を早期に検証できます。
* 作業の開始時には、トップダウン テストよりも効率的な並列統合を使用できます。
*実際のモジュールの代わりにドライバー モジュールが追加で記述されるため、実際のテスト対象モジュールに対するテスト容易性の要件は、トップダウン テスト戦略よりも小さくなります。
* スタブ モジュールの作業負荷が軽減されました。
* 誤った隔離。
(5) デメリット：
・ドライバモジュールの開発負荷が比較的大きい。
※特にシステム全体の制御機構がより重要な製品の場合、高度な検証は後回しになり、設計ミスを早期に発見することができません。
※最上位層に統合されるとシステム全体がますます複雑になり、最下位層で一部の例外をカバーすることが困難になります。
(6) 適用範囲：
※受託設計製品。
*比較的安定した基盤インターフェイスを備えた製品。
*上位インターフェイスが頻繁に変更される製品。
※基盤モジュールが先に完成した製品。
サンドイッチの統合
トップダウン統合戦略とボトムアップ統合戦略にはそれぞれ欠点があるため、これら 2 つのテスト戦略を組み合わせた統合方法、つまりサンドイッチ統合があります。
(1) 概念：サンドイッチインテグレーション（サンドイッチインテグレーション）は、ハイブリッドインテグレーションとも呼ばれます. サンドイッチインテグレーションとは、システムを3つの層に分割することです. 中間の層がターゲット層です. テストの際には、ターゲット層の上の層が使用されます. -down 統合戦略は、ターゲット レイヤーの下のレイヤーに対してボトムアップ統合戦略を使用し、最終テストはターゲット レイヤーで行われます。
(2) 目的: トップダウンの統合テスト戦略とボトムアップの統合テスト戦略の利点を統合すること。
(3) 戦略:
*まず、対象層の上の層に対してトップダウンのテスト戦略を採用し、メインモジュール A をテストし、A が呼び出すサブモジュール (対象層) をスタブユニットに置き換えます。
*2番目に、ターゲット層の下の層に対してボトムアップのテスト戦略を採用します。
※最後に3つのレイヤーを統合します。
(4) 利点: トップダウンとボトムアップの統合戦略の利点を組み合わせています。
(5) 欠点: 中間層は統合前に十分にテストされていません。
(6) 適用範囲: この統合戦略は、ほとんどのソフトウェア開発プロジェクトで使用できます。
バックボーンの統合
(1) コンセプト: 多くのシステム、特に組み込みシステムでは、一般的にカーネル部分 (コア部分) と周辺アプリケーション部分の 2 つの部分に分けられ、これら 2 つの部分は異なるプロジェクト チームによって同時に開発されることがよくあります。
(2) 目的: トップダウン、ボトムアップ、ビッグバン統合の要素を組み合わせて、密結合されたサブシステム間の相互運用性を検証する。
(3) 戦略:
* 必要に応じてドライバーとスタブを使用して、バックボーン内の各モジュールに対して個別の十分なテストを実行します。
*バックボーン内のすべてのモジュールをビッグバン統合してバックボーン サブシステムを形成し、ドライバー モジュールを使用してビッグバン バックボーンをチェックします。
* アプリケーションの制御サブシステムのトップダウン統合。
※バックボーンと制御サブシステムを統合し、制御サブシステムを再構築します。
*ボトムアップの統合戦略が各アプリケーション サブシステムに採用されています。
※基幹サブシステム、制御サブシステム、各アプリケーションサブシステムを統合してシステム全体を構成します。
(4) 利点: サンドイッチ統合の利点があり、大規模で複雑なプロジェクトの統合により適しています。
(5) 欠点:
* システムの構造と相互依存性を注意深く分析する必要があります。
※スタブモジュールやドライブモジュールの開発が必要であり、テスト対象システムの複雑さによりこれらモジュールの開発工数が増加しますが、多重化技術によりある程度のコスト削減が可能です。
*ビッグバン戦略を部分的に採用しているため、一部のインターフェイスのテストが不完全である可能性があります。
(6) 適用範囲: 大規模で複雑なプロジェクト
* マルチレイヤ プロトコルを備えた組み込みシステムに適しています。
*オペレーティング システム製品
レイヤーの統合
(1) 概念: 階層化モデルは通信システムでは非常に一般的であり、階層化統合はこの機能に使用される統合です。
(2) 目的: インクリメンタル統合による階層アーキテクチャを持つアプリケーション システムの安定性と相互運用性を検証すること。
(3) 戦略:
* システムの階層を分割します。
※各レベルの内部統合戦略を決定する この戦略は、ビッグバン統合、トップダウン統合、ボトムアップ統合、サンドイッチ統合のいずれかの戦略を使用することができ、一般的には最上層と第 2 層で使用できます。トップダウンの統合戦略、中間層のボトムアップ統合戦略、および最下層の個別のテストです。
* ビッグバン統合、トップダウン統合、ボトムアップ統合、サンドイッチ統合のいずれかを使用できるレイヤー間の統合戦略を決定します。
(4) 長所と短所: 各層間および層内で採用される戦略が異なるため、長所と短所は、その層で採用されるテスト戦略に対応します。
(5) 適用範囲: 明らかな線形の階層関係を持つ製品システム。
機能ベースの統合
(1) コンセプト：開発プロセスでは、システムの主要な機能の実現をできるだけ早く見る必要があり、機能ベースの統合では、機能の観点から開始し、システムの重要度に応じてモジュールを統合します。機能を順番に整理します。
(2) 目的: 付加価値のある方法を使用して、システムの主要な機能をできるだけ早期に検証します。
(3) 戦略:
* 機能の優先順位を決定します。
※最優先の機能パスを解析し、そのパス上の全モジュールを統合し、必要に応じてスタブモジュールやユニットモジュールを使用します。
*キー関数を追加し、すべてのモジュールがテスト対象のシステムに統合されるまで上記の手順を続けます。
(4) 利点：
* この方法により、主要な機能の実現ができるだけ早く確認でき、主要な機能の正当性を検証できます。
※この方法は、特定の機能を検証する際に複数のモジュールを追加する場合があるため、トップダウン、ボトムアップ、サンドイッチ統合戦略よりも進捗が若干早くなります。
*インターフェイス カバレッジでは、比較的少数のテスト ケースを使用します。
* ドライバーモジュールの開発を削減できる
(5) 短所:
* 複雑なシステムの場合、機能間の相互関係が複雑になり、分析が困難になる可能性があります。
* 一部のインターフェイスは十分にテストされていないため、多くのインターフェイス エラーが見逃されます。
*一部の初期統合ではスタブ モジュールの使用が必要です。
* 比較的大規模な冗長テストが存在する可能性があります。
(6) 適用範囲：
※主要な機能においてリスクの高い製品。
*技術的な探索プロジェクトの場合、その機能の実現は品質よりもはるかに重要です。
※機能の実現が不明な商品。
スケジュールベースの統合
(1) コンセプト：実際の業務では、あらゆるソフトウェア開発プロジェクトで進捗のプレッシャーに直面します。
進捗を完了するためには、品質を犠牲にすることも可能であり、進捗ベースの統合では、品質と進捗のバランスを見つけることが求められます。
(2) 目的: 統合テストをできるだけ早く実施し、開発と統合の並列性を向上させ、進捗を効果的に短縮します。
(3) 戦略: この統合の戦略は、統合のインセンティブとして利用可能な最も早いコードを使用し、必要に応じてスタブ モジュールとドライバー モジュールを開発し、開発との並行性を最大限に維持することで、プロジェクトの統合時間を短縮することです。
(4) 利点:
* 比較的高い並列度を持ちます。
*プロジェクト開発の進行を効果的に短縮します。
(5) 短所:
* 初期のモジュールは完全性を欠き、独立してしか統合できないため、後で多くのインターフェースを検証する必要がある可能性がありますが、システムはこの時点ですでに非常に複雑である可能性があり、効果的なインターフェースの問題が見つからないことがよくあります。 。
※スタブモジュールやドライバーモジュールの負荷が非常に大きくなる場合があります。
*進歩により、モジュールが不安定で常に変更される可能性があり、テストの重複と無駄が発生します。
(6) 適用範囲：品質よりもスケジュールを優先するプロジェクト。
統合テスト戦略
統合テストは正式なテスト プロセスであり、慎重に計画し、単体テストの完了時間と調整する必要があります。テスト計画を策定するときは、次の要素を考慮する必要があります:
1. アセンブリとテストに使用されるシステムのアセンブリ方法; 2.
アセンブリとテストのプロセス中にモジュールが接続される順序;4. テストプロセス中に特別なハードウェア機器が必要かどうか;
上記の問題を解決した後、各モジュールの単体テストが完了した日付と、各モジュールのコンパイルとテストのスケジュールをリストすることができます。最初の統合 テストの日付、すべての統合テストが完了する日付、必要なテスト ケースと予想されるテスト結果。ソフトウェアテストに必要なハードウェア機器が不足している場合は、ハードウェアの納期が結合テスト計画と一致しているかどうかを確認します。たとえば、テストにデジタイザとプロッタが必要な場合は、ハードウェアの設置と納品のために余裕を持って、これらのデバイスが利用可能になったときにテストをスケジュールする必要があります。さらに、テスト計画では、テストに必要なソフトウェア (ドライバー モジュール、スタブ モジュール、テスト ケース ジェネレーターなど) の準備状況を考慮する必要があります。単体テストの後は、結合テストを実施して、モジュールの接続で発生する可能性のある上記の問題を発見して解消し、最終的に必要なソフトウェアサブシステムまたはシステムを構成する必要があります。サブシステムの場合、統合テストはコンポーネント テストとも呼ばれます。統合テストの合理的な構成、つまり実行可能なシステムを形成するためにモジュールを組み立てる方法の選択は、モジュール テスト ケースの形式、使用するテスト ツールの種類、モジュール番号とテストの順序、生成に直接影響します。テストケースの数とデバッグコスト。一般に、ワンタイム組立方式と付加価値組立方式の 2 つの異なる組立方式があります。
結合テストの完了基準
統合テスト プロセスの完了を判断する方法は、次の側面で確認できます:
1. テスト計画で指定されたすべての統合テストが正常に実行された;
2. 見つかったエラーが修正された;
3. テスト結果がパネルによるレビューに合格した専門家。
統合テストは、経験豊富なシステム設計者とプログラマーで構成される専任のテスト チームによって実施される必要があります。試験活動全体は評価者の立ち会いの下で実施されます。
スケジュールされた組み立てテスト作業が完了したら、テストチームはテスト結果を整理および分析し、テストレポートを作成する責任があります。テストレポートには、実際のテスト結果、テストで見つかった問題、それらの問題を解決する方法、解決後の再度のテスト結果を記録する必要があります。さらに、解決できず、管理者や開発者の注意が必要ないくつかの問題を提起し、治療に関する意見を提供するためにテストのレビューと最終決定を提供する必要があります。
ソフトウェアテストにおける統合テストとは一体何なのでしょうか? 統合にはどのような方法がありますか?
編集元: https://blog.csdn.net/weixin_67553250/article/details/126650989
編集者は資料の収集と整理に熱心で、ピットを踏んでからピットに登るまでのプロセスを記録します。学んだこと、実際の仕事で使ったテクニック、学習方法、経験、踏んだ落とし穴などを記録できればと思います。また、ソフトウェア テストを行いたいと考えている皆さんが、私の共有を通じて回り道を避け、独自の方法を確立して実際に適用できることを願っています。
目次
序文
統合テスト 統合テストは複雑で、ある程度の開発スキルと論理スキルが必要です。確かにそうです！では、このテストをテスト戦略に組み込む目的は何でしょうか? この質問に答えるのは急ぐ必要はありません。段階的に見ていきましょう。そうすれば分かるでしょう。
なぜ統合テストを行うのでしょうか?
その理由は次のとおりです。
① 実際、アプリケーションを開発するとき、アプリケーションは小さなモジュールに分割され、各開発者にモジュールが割り当てられます。ある開発者が実装するロジックは他の開発者とはまったく異なるため、開発者が実装したロジックが期待どおりであり、指定された規格に従って正しい値を提供するかどうかを確認する必要があります。
② ほとんどの場合、データをあるモジュールから別のモジュールに移動すると、データの表面や構造が変わります。特定の値を追加または削除すると、後続のモジュールで問題が発生する可能性があります。
③ このモジュールは、特定のサードパーティ ツールまたは API とも対話します。これらも、API/ツールによって受信されたデータが正しく、生成された応答が期待どおりであることを確認するためにテストする必要があります。
④テストでよくある問題 - 頻繁に変更される要件! :) 多くの場合、開発者は単体テストを行わずに展開および変更を行います。このとき、統合テストが重要になります。
基本コンセプト: ソフトウェアを統合した後にテストします。結合テストは、サブシステム テスト、アセンブリ テスト、コンポーネント テストなどとも呼ばれます。結合テストは主にソフトウェアの上位設計をテストするためのもので、一般的にはモジュールやサブシステム単位でテストが行われます。
統合テストのレベルには次のものがあります。
\1. モジュール内の統合は主に、モジュール内のさまざまなインターフェイス間のインタラクティブな統合関係をテストすることです。
\2. サブシステム内の統合。サブシステム内のモジュール間の相互作用をテストします。
\3. システム統合。システム内のさまざまなサブシステムとモジュール間の統合関係をテストします。
**統合テストの本質: **それはテスト インターフェイス間の関係です。
**補足：**統合テストにはホワイトボックステストとブラックボックステストの両方の要素があり、ホワイトボックステストとブラックボックステストの特徴を併せ持つもので、一般的にはグレーボックステストに分類されます。
統合テストとソフトウェア概要 (概要) 設計の関係
ソフトウェアの概要 (ハイレベル) 設計は、アーキテクチャ設計とも呼ばれます。アーキテクチャ設計の非常に重要な部分は、インターフェイス関係図です。統合テストは、一般に、インターフェイス関係図とモジュール インターフェイスに依存してテストされます。適切に設計されたシステムでは、ソフトウェアのインターフェイス グラフは非巡回有向グラフ (階層グラフ) である必要があります。
統合テストは必要ですか?
一般的に結合テストは必要ですが、実際にはタイムスケジュールの問題で結合テストを行う時間が取れなかったり、結合テストをやりたがらない理由が多々あります。ただし、次の状況では統合テストを実行する必要があります。
\1. 航空宇宙ソフトウェア、通信ソフトウェア、システム基盤ソフトウェアなど、ソフトウェア品質に対する高度な要件が求められるソフトウェア システム。
\2. 幅広い用途と多数のユーザー層を持つソフトウェア。
\3. 使用クラスは、C/C++などのポインタを持った言語で開発されたソフトウェアです。
\4. クラス ライブラリ、ミドルウェア、その他の製品。
注: 結合テストはテスト範囲が広いテストであり、統合テストをさらに絞り込むと単体テストになります。
統合テストと単体テストの違いは次のとおりです。
1. テストしたユニットが異なります
単体テストはソフトウェアの基本単位（機能など）のテストですが、結合テストはモジュールやサブシステムのテストで、主にインターフェイス間の関係をテストします。
2. テストの根拠が異なる
単体テストはソフトウェアの詳細設計のためのテストであり、テストケースの主な基礎も詳細設計です。結合テストはソフトウェアの一般的な設計のためのテストであり、テスト ケースの主な基礎は一般的な設計です。
3. テストスペースが異なります
結合テストは主にインターフェース層のテスト空間をテストし、単体テストは主に内部実装層のテスト空間をテストします。
4. 統合テストでは単体テストとは異なる方法が使用されます
結合テストはインターフェースの統合に重点を置き、単体テストは単体に重点を置くため、具体的なテスト方法も異なります。
統合テストの統合方法:
統合手法には主にビッグバン統合、ボトムアップ統合、トップダウン統合、サンドイッチ統合などがあります。これらはすべて、インターフェイス コール グラフに基づいた統合方法です。
結合テストとは、単体テストに基づいて、設計要件に従ってすべてのモジュールを完全なシステムに組み立てるテストを指すため、アセンブリテストまたは結合テストとも呼ばれます。
単一のモジュールは正常に動作することが実際に証明されていますが、次の理由により、組み立て後も正常に動作しない可能性があります。
(1) 単体テストで使用されるドライバー モジュールとスタブ モジュールは、置き換えられるモジュールと完全に同等ではないため、単体テストは完全かつ厳密ではありません。
(2) 各モジュールを組み立てると、モジュールインターフェースを通過するデータが失われる可能性があります。
(3) あるモジュールの機能が他のモジュールの機能に悪影響を与える可能性があります。
(4) 各モジュールの機能の組み合わせによっては、期待される主な機能を満たさない場合があります。
(5) 単一モジュールでは許容できる誤差が蓄積され、組み立てられると許容できないレベルまで拡大する可能性があります。
(6) グローバルデータに問題がある可能性があります。
したがって、モジュールの組み立てで起こり得る問題を発見するために統合テストを実行し、最終的に要件を満たすソフトウェア システムを構成する必要があります。
結合テストには主に 2 つの方法があります
(1) ノンインクリメンタルテスト
まず、各モジュールが個別にテストされ、次にテストの設計要件に従ってすべてのモジュールが組み立てられます。
(2) インクリメンタルテスト
統合テストのために、未テストのモジュールをテスト済みのモジュールに 1 つずつアセンブルします。新しいモジュールが追加されるたびに結合テストが実行され、プログラムがアセンブルされるまでこのプロセスが繰り返されます。