システム統合テスト (SIT) の例とは

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

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

システム統合テスト (SIT) は、ソフトウェアシステムのモジュール間の相互作用を検証するために実行されます。これは、ソフトウェア要件仕様/データおよびソフトウェア設計文書で指定された高レベルおよび低レベルのソフトウェア要件の検証を扱います。また、ソフトウェアシステムと他のソフトウェアシステムの共存を検証し、ソフトウェアアプリケーションのモジュール間のインターフェイスをテストします。このタイプのテストでは、まずモジュールを個別にテストし、次に組み合わせてシステムを作成します。たとえば、ソフトウェアおよび/またはハードウェアコンポーネントが結合され、システム全体が統合されるまで段階的にテストされます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

通常、統合テストの実行中には、ETVX (開始基準、タスク、検証、および終了基準) 戦略が使用されます。

エントリー基準：

完了単体テスト

入力：

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

活動：

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

終了基準

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

出力

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

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

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

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

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

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

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

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

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

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

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

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

ホスト/ターゲットコンピュータ内で動作するコンピュータソフトウェアコンポーネントのテストです。

環境では、システム全体（他の CSC）と高レベルの機能をシミュレートします。

シミュレートされたホスト/ターゲット環境における CSC の動作に焦点を当てています。ソフトウェア統合に使用されるアプローチは、段階的なアプローチ (トップダウン、ボトムアップのアプローチ、または両方の組み合わせ) です。

段階的なアプローチ

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

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

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

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

トップダウンアプローチ

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

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

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

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

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

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

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

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

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

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

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

ボトムアップアプローチ

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

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

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

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

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

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

ビッグバンアプローチ

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

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

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

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

まとめ

統合は、ソフトウェアシステムのモジュール間の相互作用を検証するために実行されます。不具合の早期発見に役立ちます
統合テストは、ハードウェアとソフトウェア、またはハードウェアとハードウェアの統合に対して実行できます。
結合テストは XNUMX つの方法で行われます
- 段階的なアプローチ
- ビッグバンアプローチ
統合テストの実行中は、通常、ETVX (開始基準、タスク、検証、および終了基準) 戦略が使用されます。

よろしければ：