SITとは？システム統合テスト（例付き）

システム結合テストとは何ですか?

システム 統合テスト システム全体の動作を検証するために、ハードウェアとソフトウェアの統合環境で実行されるソフトウェア テストの一種として定義されます。 これは、システムが指定された要件に準拠しているかを評価するために、完全な統合システムに対して実施されるテストです。

システム統合テスト（SIT）は、ソフトウェアシステムのモジュール間の相互作用を検証するために実施されます。これは、ソフトウェア要件仕様書／データおよびソフトウェア設計書に規定された高レベルおよび低レベルのソフトウェア要件の検証を扱います。

SIT（システム統合テスト）は、ソフトウェアシステム同士の共存性を検証し、ソフトウェアアプリケーションのモジュール間のインターフェースをテストします。このタイプのテストでは、まずモジュールを個別にテストし、その後組み合わせてシステムを構築します。例えば、ソフトウェアやハードウェアのコンポーネントを組み合わせて段階的にテストし、最終的にシステム全体が統合されます。

上の図は、SITを定義する進行過程を示しています。個別に検証されたモジュールが段階的に統合され、最終的に単一の統合システムがテスト対象となります。

システム統合テストはなぜ行うのでしょうか?

ソフトウェアエンジニアリングでは、システム統合テストが行​​われます。その理由は次のとおりです。

• 検出に役立ちます 欠陥 早く
• 個々のモジュールの受け入れ可能性に関する事前のフィードバックが利用可能になります
• 欠陥修正のスケジュールは柔軟で、開発と重複させることも可能
• 正しいデータフロー
• 正しい制御フロー
• 正しいタイミング
• 正しいメモリ使用量
• ソフトウェア要件に合わせて修正します

システム統合テスト、システムテスト、ユーザー受け入れテストの比較

これら3つのレベルは連続しているため、しばしば混同される。 システムテスト SITは完成したビルドを要件と照らし合わせて検査し、ビルド間の継ぎ目を検査し、 ユーザー受け入れテスト 顧客の視点から企業の健全性を検証します。以下の表は、それらを分類したものです。

	システム統合テスト	システムテスト	ユーザー受け入れテスト
主な焦点	統合モジュール間のインターフェースとデータフロー	組み立てられた構造全体の挙動	実際の使用に適したビジネス環境
テストレベル	レベル2	レベル3	稼働開始前の最終段階
技術	ブラックボックス	黒箱、白箱、または灰色箱	ブラックボックス
によって演奏された	統合テスト担当者と開発者	独立テストチーム	顧客またはエンドユーザー
典型的な欠陥	インターフェース、タイミング、メモリ、データマップping エラー	機能的および非機能的なシステムエラー	使いやすさと要件の不一致
実行時	後 単体テスト	SIT後	システムテスト後

順序が重要です。モジュールは単体テストに合格し、SITはインターフェースを検証し、システムテストは組み立てられた製品を検証し、UATは製品がビジネスの期待に合致していることを確認します。ping SITはインターフェースの欠陥をUATに押し付けるため、UATでは修正にかかるコストがはるかに高くなる。

システム結合テストのやり方

これは、インターフェースに関連するエラーを明らかにするためのテストを実施しながら、プログラム構造を構築するための体系的な手法である。

すべてのモジュールは事前に統合されており、プログラム全体が全体としてテストされます。 ただし、このプロセス中に一連のエラーが発生する可能性があります。

プログラム全体の膨大な拡張により分離原因が複雑になるため、このようなエラーを修正することは困難です。 これらのエラーが修正および修正されると、新しいエラーが表示され、プロセスは無限ループでシームレスに続行されます。. この状況を回避するために、別の手法である増分統合が用いられます。増分統合の手法については、次のセクションで詳しく説明します。

ターゲットプロセッサに基づいてシステム上で統合テストを実行するなど、いくつかの段階的な方法があります。 使用される方法論は、 ブラック Box テスト。 ボトムアップまたはトップダウンの統合を使用できます。

テスト ケースは、高レベルのソフトウェア要件のみを使用して定義されます。

ソフトウェア統合は主にホスト環境で実現され、ターゲット環境に固有のユニットはホスト内で引き続きシミュレートされます。 ターゲット環境でテストを繰り返して確認する必要があります。

このレベルの確認テストでは、メモリの割り当てや解放におけるエラーなど、環境固有の問題を特定します。ホスト環境でのソフトウェア統合の実現可能性は、ターゲット固有の機能がどの程度存在するかによって異なります。一部の組み込みシステムでは、ターゲット環境との結合が非常に強いため、ホスト環境でのソフトウェア統合は現実的ではありません。

大規模なソフトウェア開発では、ソフトウェア統合をいくつかのレベルに分割します。ソフトウェア統合の下位レベルは主にホスト環境に基づいて行われ、ソフトウェア統合の上位レベルはターゲット環境に大きく依存するようになります。

注意： ソフトウェアのみがテストされている場合は、ソフトウェア ソフトウェア統合テスト [SSIT] と呼ばれ、ハードウェアとソフトウェアの両方がテストされている場合は、ハードウェア ソフトウェア統合テスト [HSIT] と呼ばれます。

段階的なアプローチ

すべてを一度に統合すると欠陥の特定が難しくなるため、ほとんどのチームはここで説明する段階的な方法を採用しています。

増分テストは統合テストの方法の XNUMX つです。 このタイプのテスト方法では、最初にソフトウェアの各モジュールを個別にテストし、次に他のモジュールを追加してテストを続けます。

インクリメンタル統合は、ビッグバン アプローチとは対照的です。 プログラムは小さなセグメントに分けて構築およびテストされるため、エラーの切り分けと修正が容易になります。 インターフェースは完全にテストされる可能性が高く、体系的なテストアプローチが適用される場合があります。

増分テストには XNUMX 種類あります

• トップダウンアプローチ
• ボトムアップアプローチ

トップダウンアプローチ

このタイプのアプローチでは、スタブによってシミュレートされた基礎的な機能を使用してユーザー インターフェイスのみをテストすることから始め、次に、下の図に示すように、下位層と下位層を統合して下方に移動します。

• メイン制御モジュールから始めて、制御階層を下位に移動することでモジュールが統合されます。
• メイン制御モジュールのサブモジュールは、幅優先方式または深さ優先方式のいずれかで構造に組み込まれます。
• 深さ優先統合では、次の図に示すように、構造の主要な制御パス上のすべてのモジュールが統合されます。

モジュール統合プロセスは次のように実行されます。

1. メイン制御モジュールはテストドライバとして使用され、スタブはメイン制御モジュールの直下にあるすべてのモジュールを置き換えます。
2. 下位スタブは、選択したアプローチ (幅優先または深さ優先) に応じて、一度に XNUMX つずつ実際のモジュールに置き換えられます。
3. テストは各モジュールが統合されながら実行されます。
4. テストの各セットが完了すると、別のスタブが実際のモジュールに置き換えられます。
5. 新しいエラーが導入されていないことを確認するには 回帰テスト 実行される場合があります。

プロセスはステップ 2 からプログラム構造全体が構築されるまで継続されます。 トップダウン戦略は比較的複雑ではないように思えますが、実際にはロジスティック上の問題が発生します。

これらの問題のうち最も一般的なのは、上位レベルを適切にテストするために階層の下位レベルでの処理が必要な場合に発生します。

スタブはトップダウン テストの開始時に低レベル モジュールを置き換えるため、重要なデータがプログラム構造内を上に流れることはできません。

テスターが直面する可能性のある課題:

• スタブが実際のモジュールに置き換えられるまで、多くのテストを遅らせます。
• 実際のモジュールをシミュレートする限定された機能を実行するスタブを開発します。
• ソフトウェアを階層の下から上に統合します。

注意： 最初のアプローチでは、特定のテストと特定のモジュールの組み込みとの間の対応をある程度制御できなくなります。 これにより、エラーの原因を特定することが困難になる可能性があり、トップダウン アプローチの高度に制約された性質に違反する傾向があります。

2 番目のアプローチは実行可能ですが、スタブが複雑になるにつれて、大きなオーバーヘッドが発生する可能性があります。

ボトムアップアプローチ

ボトムアップ統合では、プログラム構造の最下位レベルのモジュールで構築とテストが開始されます。 このプロセスでは、モジュールが下から上まで統合されます。

このアプローチでは、特定のレベルに従属するモジュールに必要な処理が常に利用可能であり、スタブの必要性が排除されます。

この統合テストのプロセスは、一連の XNUMX つのステップで実行されます。

1. 低レベル モジュールは、特定のソフトウェア サブ機能を実行するクラスターに結合されます。
2. ドライバーは、テスト ケースの入力と出力を調整するために作成されます。
3. クラスターまたはビルドがテストされます。
4. ドライバーは削除され、クラスターはプログラム構造の上方に移動しながら結合されます。

統合が上位レベルに進むにつれて、個別のテストドライバの必要性は減少します。実際、プログラム構造の最上位2レベルをトップダウンで統合すれば、ドライバの数を大幅に削減でき、クラスタの統合も非常に簡素化されます。統合は、以下の図に示すパターンに従います。

注意： プログラム構造の上位 XNUMX つのレベルがトップダウンで統合されると、ドライバーの数を大幅に減らすことができ、ビルドの統合が大幅に簡素化されます。

ビッグバンアプローチ

このアプローチでは、すべてのモジュールの準備が整うまで、すべてのモジュールは統合されません。 準備ができたら、すべてのモジュールが統合され、実行されて、統合されたすべてのモジュールが機能しているかどうかがわかります。

このアプローチでは、すべてを一度に統合するため、失敗の根本原因を知ることが困難です。

また、本番環境では重大なバグが発生する可能性が高くなります。

このアプローチは、統合テストを一度に実行する必要がある場合にのみ採用されます。

ハードウェア ソフトウェア統合テスト

ハードウェア ソフトウェア統合テスト は、ターゲット ハードウェア環境上でコンピュータ ソフトウェア コンポーネント (CSC) の高レベルの機能をテストするプロセスです。 ハードウェア/ソフトウェア統合テストの目的は、ハードウェア コンポーネントに統合された開発されたソフトウェアの動作をテストすることです。

要件に基づいたハードウェアとソフトウェアの統合テスト

要件ベースのハードウェア/ソフトウェア統合テストの目的は、ターゲット コンピューターのソフトウェアが高レベルの要件を満たしていることを確認することです。 このテスト方法で判明する一般的なエラーは次のとおりです。

• ハードウェア/ソフトウェア インターフェースのエラー
• ソフトウェアのパーティショニングの違反。
• 組み込みテストで障害を検出できない
• ハードウェア障害に対する誤った対応
• シーケンス、過渡入力負荷、および入力電力過渡によるエラー
• フィードバック ループの誤った動作
• メモリ管理ハードウェアの不正または不適切な制御
• データバス競合の問題
• フィールドロード可能なソフトウェアの互換性と正確性を検証するメカニズムの誤った操作

ハードウェア ソフトウェア統合では、高レベルの要件の検証が行われます。 このレベルのテストはすべて、ターゲット ハードウェアで実行されます。

• ブラック ボックス テストは、このレベルのテストで使用される主要なテスト方法です。
• 定義する テストケース 高レベルの要件のみ
• テストは実稼働標準ハードウェア (ターゲット上) で実行する必要があります

HW/SW統合のテストケースを設計する際の考慮事項

• ソフトウェアによるすべてのデータの正確な取得
• ハードウェアからソフトウェアまで予想どおりのデータのスケーリングと範囲
• ソフトウェアからハードウェアへのデータの正しい出力
• 仕様内のデータ（正常範囲）
• 仕様外データ（異常範囲）
• 境界データ
• 割り込み処理
• タイミング
• 正しいメモリ使用法 (アドレス指定、オーバーラップなど)
• 状態遷移

注意： 割り込みテストの場合、すべての割り込みは、最初のリクエストから完全なサービス、および完了まで独立して検証されます。 テスト ケースは、割り込みを適切にテストするために特別に設計されます。

ソフトウェア間の統合テスト

これは、ホスト/ターゲットコンピュータ環境内で動作するコンピュータソフトウェアコンポーネントのテストであり、システム全体（他のCSC）をシミュレートしながら、高レベルの機能についてテストを行うものです。

これは、シミュレートされたホスト/ターゲット環境におけるCSCの動作に焦点を当てています。ソフトウェア統合に使用されるアプローチは、インクリメンタルアプローチ（トップダウン、ボトムアップ、またはその両方を組み合わせたもの、サンドイッチアプローチまたはハイブリッドアプローチとも呼ばれる）のいずれかです。

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

アプローチと2つの統合方式が決定したら、残る問題はチームがいつ開始し、いつ終了するかということです。通常、統合テストの実施においては、ETVX（エントリー基準、タスク、検証、および終了基準）戦略が用いられます。

エントリー基準：

• 完了 単体テスト

入力：

• ソフトウェア要件データ
• ソフトウェア設計書
• ソフトウェア検証計画
• ソフトウェア統合ドキュメント

活動：

• 高レベルおよび低レベルの要件に基づいてテスト ケースと手順を作成する
• 共通の機能を実装する低レベルのモジュール ビルドを結合する
• テストハーネスを開発する
• ビルドをテストする
• テストに合格すると、そのビルドは他のビルドと結合され、システムが全体として統合されるまでテストされます。
• ターゲットのプロセッサベースのプラットフォームですべてのテストを再実行し、結果を取得します。

終了基準

• ターゲット ハードウェアへのソフトウェア モジュールの統合が正常に完了しました
• 指定された要件に従ってソフトウェアが正しく動作すること

出力

• 統合テストレポート
• ソフトウェアのテストケースと手順 [SVCP]。

システム統合テストにおける一般的な課題

適切なアプローチと明確な終了基準を設けたとしても、統合環境では単体テストでは決して表面化しない問題が発生する。それらを早期に認識することで、スケジュールを現実的なものに維持できる。

• 環境の不一致: 統合された テスト環境 本番環境と完全に一致することは稀であるため、タイミングや構成の欠陥は非常に遅い段階まで見過ごされてしまう。
• 依存関係の準備状況： サードパーティ製インターフェースやレガシーインターフェースは未完成であることが多く、テスターは予定よりもはるかに長い期間、スタブやシミュレーターに頼らざるを得ない。
• データの不整合： 2つのモジュールが同じレコードを異なる方法で表現する可能性があり、目に見えるエラーではなく、潜在的な不一致が生じる可能性がある。
• 欠陥の所有権: 2 つのチームにまたがる失敗の場合、根本原因分析と 欠陥管理 明らかに速度を落としてください。
• 回帰コスト： 新しいインターフェースは、 回帰試験 スイートであるため、手動での再実行はすぐに持続不可能になります。

これらのほとんどは、技術的な行き詰まりというよりは、スケジュール上のリスクです。最初のビルドを統合する前に、インターフェースの準備完了日、シミュレーターの範囲、および欠陥トリアージの担当者を合意しておくことで、これらのリスクの大部分を回避できます。ベンダー所有のインターフェースについては、合意したメッセージ形式とエスカレーション連絡先も記録しておきましょう。担当者が不在だと、欠陥の修正が本来の期間よりも長く遅れてしまうからです。

システム統合テストのベストプラクティス

再現性の高いSITサイクルは、ツールよりもインターフェース、データ、エビデンスに関する規律に大きく依存します。以下の5つのプラクティスは、小規模な組み込みシステム構築にも、大規模なマルチベンダー環境にも等しく適しており、いずれも後のテスト段階で発生する手戻りを削減します。

1. まず、すべてのインターフェースをマッピングしてください。 テストケースを作成する前に、各データ交換、その方向、プロトコル、および所有者を一覧にしてください。
2. リスクに基づいて優先順位をつける。 お金、身分証明書、または規制対象データを扱うインターフェースは、外観に関わるインターフェースよりも先に検証してください。
3. 現実的なテストデータを設計する。 通常範囲、境界範囲、異常範囲を網羅することで、スケーリング誤差や丸め誤差を早期に発見できます。
4. 安定した経路を自動化する。 ワイヤインターフェースは 継続的インテグレーション パイプラインによって、ビルドのたびにそれらが再検証されます。
5. 証拠を保管する trac食べられる。 各結果を要件にリンクする trac能力マトリックス つまり、出口基準は主張するのではなく、証明できるものなのだ。

⚠ヒント： 統合を開始する前に、インターフェース仕様を確定してください。メッセージフォーマットを後から変更すると、インターフェースの両側のテストケースが無効になり、SIT（システム統合テスト）のやり直し作業の最も一般的な原因となります。

よくあるご質問