what is system integration testing
システム統合テストとは何ですか？
システム統合テスト（SIT）は、多くのサブシステムで構成されるシステム全体の全体的なテストです。 SITの主な目的は、すべてのソフトウェアモジュールの依存関係が適切に機能し、システム全体の個別のモジュール間でデータの整合性が維持されるようにすることです。
SUT（System Under Test）は、ハードウェア、データベース、ソフトウェア、ハードウェアとソフトウェアの組み合わせ、または人的介入を必要とするシステム（HITL – Human in the Loop Testing）で構成できます。
ソフトウェアエンジニアリングとソフトウェアテストのコンテキストから、SITは、ソフトウェアシステムと他のシステムとの共起をチェックするテストプロセスと見なすことができます。
配列javaから要素を削除する方法
SITには、基礎となる複数の統合システムがすでにシステムテストを受けて合格しているという前提条件があります。次に、SITは、これらのシステム全体で必要な相互作用をテストします。 SITの成果物は、UAT（ユーザー受け入れテスト）に渡されます。
学習内容：
- システム統合テストの必要性
- SITの粒度
- システム統合テストを実行する方法は？
- システムテストとシステム統合テスト
- システム統合テストとユーザー受け入れテスト
- SITの例
- SITテクニック
- 結論
- 推奨読書
システム統合テストの必要性
SITの主な機能は、異なるシステムコンポーネント間の依存関係をテストすることであるため、回帰テストはSITの重要な部分です。
共同プロジェクトの場合、SITはSTLC（ソフトウェアテストライフサイクル）の一部です。通常、SIT前のラウンドは、顧客が独自のSITテストケースを実行する前に、ソフトウェアプロバイダーによって実行されます。
アジャイルスプリントモデルに従ってITプロジェクトに取り組んでいるほとんどの組織では、リリースの前にQAチームによってSITのラウンドが実施されます。 SITで見つかった欠陥は開発チームに送り返され、修正に取り組みます。
スプリントからのMVP（Minimum Viable Product）リリースは、SITを通過したときにのみ実行されます。
SITは、統合されたサブシステム間で相互作用が発生したときに発生する障害を明らかにするために必要です。
システムで使用されるコンポーネントはいくつかあり、個別に単体テストすることはできません。ユニットを個別にテストした場合でも、サブシステムが相互に作用するときに発生する問題が多いため、システムで組み合わせると失敗する可能性があります。
したがって、SITは、ユーザー側でシステムを展開する前に、障害を明らかにして修正する必要があります。 SITは欠陥を早期に検出するため、後で修正する時間とコストを節約できます。また、モジュールの受け入れ可能性に関するフィードバックを早期に得るのにも役立ちます。
SITの粒度
SITは、次の3つの異なるレベルの粒度で実行できます。
（i）システム内テスト： これは、モジュールを融合して統合システムを構築することを目的とした低レベルの統合テストです。
（ii）システム間テスト： これは、独立してテストされたシステムとのインターフェースを必要とする高レベルのテストです。
（iii）ペアワイズテスト： ここでは、システム全体で相互接続された2つのサブシステムのみが一度にテストされます。これは、他のサブシステムがすでに正常に機能していることを前提として、2つのサブシステムを組み合わせたときに正常に機能できるようにすることを目的としています。
システム統合テストを実行する方法は？
SITを実行する最も簡単な方法は、データ駆動型の方法です。ソフトウェアテストツールの使用を最小限に抑える必要があります。
まず、システムコンポーネント間でデータ交換（データインポートとデータエクスポート）が行われ、次に個々のレイヤー内の各データフィールドの動作が調べられます。
ソフトウェアが統合されると、以下に説明するように、データフローの3つの主要な状態があります。
＃1）統合レイヤー内のデータ状態
統合レイヤーは、データのインポートとエクスポートの間のインターフェースとして機能します。このレイヤーでSITを実行するには、スキーマ（XSD）、XML、WSDL、DTD、EDIなどの特定のテクノロジーに関する基本的な知識が必要です。
データ交換のパフォーマンスは、次の手順でこのレイヤーで調べることができます。
- このレイヤー内のデータプロパティをBRD / FRD / TRD（ビジネス要件ドキュメント/機能要件ドキュメント/技術要件ドキュメント）に対して検証します。
- XSDとWSDLを使用してWebサービスリクエストをクロスチェックします。
- いくつかの単体テストを実行し、データのマッピングとリクエストを検証します。
- ミドルウェアログを確認します。
＃2）データベースレイヤー内のデータ状態
この層でSITを実行するには、SQLとストアドプロシージャの基本的な知識が必要です。
この層でのデータ交換のパフォーマンスは、以下の手順で調べることができます。
- 統合レイヤーからのすべてのデータがデータベースレイヤーで正常に到達し、コミットされているかどうかを確認します。
- テーブルと列のプロパティをBRD / FRD / TRDに対して検証します。
- ビジネス仕様に従って、データベースに適用されている制約とデータ検証ルールを検証します。
- ストアドプロシージャで処理データを確認してください。
- サーバーログを確認します。
＃3）アプリケーション層内のデータ状態
SITは、次の手順でこのレイヤーで実行できます。
- すべての必須フィールドがUIに表示されているかどうかを確認します。
- いくつかのポジティブおよびネガティブテストケースを実行し、データプロパティを検証します。
注意： データのインポートとエクスポートに対応する組み合わせはたくさんあります。利用可能な時間を考慮して、最適な組み合わせでSITを実行する必要があります。
システムテストとシステム統合テスト
システムテストとSITの違い：
| SIT（システム統合テスト） | システムテスト |
|---|---|
| SITは主に、システム全体に統合されたときに個々のモジュールが互いにどのように相互作用するかを確認するために行われます。 | システムテストは主に、指定された要件を参照してシステム全体が期待どおりに機能しているかどうかを確認するために行われます。 |
| これはユニットテストの後に実行され、新しいモジュールがシステムに追加されるたびに実行されます。 | これは、最終レベルで、つまり統合テストの完了後、UAT用のシステムを提供する直前に実施されます。 |
| これは低レベルのテストです。 | これは高レベルのテストです。 |
| SITテストケースは、システムコンポーネント間のインターフェイスに焦点を当てています。 | この場合のテストケースは、実際のシナリオのシミュレーションに焦点を合わせています。 |
システム統合テストとユーザー受け入れテスト
SITとUATの違いは次のとおりです。
| SIT（システム統合テスト） | UAT（ユーザー受け入れテスト） |
|---|---|
| このテストは、モジュール間のインターフェースの観点から行われます。 | このテストは、ユーザー要件の観点から行われます。 |
| SITは開発者とテスターによって行われます。 | UATは顧客とエンドユーザーによって行われます。 |
| 単体テストの後、システムテストの前に実行されます。 | これはテストの最後のレベルであり、システムテストの後に行われます。 |
| 一般に、SITで見つかった問題は、データフロー、制御フローなどに関連しています。 | UATで見つかった問題は、通常、ユーザーの要件に従って機能していない機能のようなものです。 |
テストのレベルに関する以下の画像は、ユニットテストからUATへのフローを明確にします。
CPU温度を監視するための最良のプログラム
SITの例
会社がクライアントの詳細を保存するためにソフトウェアを使用していると仮定しましょう。
このソフトウェアのUIには、画面1と画面2の2つの画面があり、データベースがあります。画面1と画面2に入力された詳細がデータベースに入力されます。今のところ、同社はこのソフトウェアに満足しています。
しかし、数年後、同社はソフトウェアが要件を満たしていないことを発見し、拡張の必要性があります。したがって、彼らは画面3とデータベースを開発しました。現在、画面3とデータベースを備えたこのシステムは、古い/既存のソフトウェアと統合されています。
現在、統合後にシステム全体で行われるテストは、システム統合テストと呼ばれています。ここでは、新しいシステムと既存のシステムの共存をテストして、統合システム全体が正常に機能することを確認します。
SITテクニック
主に、SITを実行するための4つのアプローチがあります。
- トップダウンアプローチ
- ボトムアップアプローチ
- サンドイッチアプローチ
- ビッグバンアプローチ
トップダウンアプローチとボトムアップアプローチは一種のインクリメンタルアプローチです。まず、トップダウンアプローチから議論を始めましょう。
＃1）トップダウンアプローチ：
この場合、テストはアプリケーションの最上位モジュール、つまりテストドライバーと呼ばれるUIから始まります。
基盤となるモジュールの機能は、スタブを使用してシミュレートされます。最上位モジュールは下位レベルのモジュールスタブと1つずつ統合され、後で機能がテストされます。
各テストが完了すると、スタブは実際のモジュールに置き換えられます。モジュールは、幅優先または深さ優先のいずれかの方法で統合できます。テストは、アプリケーション全体が構築されるまで続きます。
このアプローチの利点は、ドライバーが不要であり、システムの機能の観点からテストケースを指定できることです。
このタイプのアプローチの主な課題は、低レベルのモジュール機能の可用性への依存です。実際のモジュールがスタブに置き換えられるまで、テストが遅れる可能性があります。スタブを書くことも難しいです。
Javaで配列を渡す方法
＃2）ボトムアップアプローチ：
これにより、トップダウンアプローチの制限がなくなります。
この方法では、最初に、最下位レベルのモジュールを組み立ててクラスターを形成します。これらのクラスターは、アプリケーションのサブ機能として機能します。次に、テストケースの入力と出力を管理するためのドライバーが作成されます。この後、クラスターがテストされます。
クラスターがテストされると、ドライバーが削除され、クラスターが次の上位レベルと結合されます。このプロセスは、アプリケーション構造全体が完成するまで続きます。
このアプローチではスタブは必要ありません。処理が上に移動し、ドライバーの必要性が減少するにつれて、それは単純化されます。このアプローチは、オブジェクト指向システム、リアルタイムシステム、および厳密なパフォーマンスニーズのあるシステムに対してSITを実行する場合に推奨されます。
ただし、このアプローチの制限は最も重要なサブシステムです。つまり、UIは最後にテストされます。
＃3）サンドイッチアプローチ：
ここでは、上記のトップダウンとボトムアップのアプローチが組み合わされています。
システムは、ターゲット層である中間層、ターゲットの上の層、およびターゲットの下の層の3つの層を持っていると認識されます。テストは両方向で行われ、中央にあるターゲットレイヤーに集まります。これを下の画像に示します。
サンドイッチテスト戦略
このアプローチの利点は、システムの最上層と最下層を並行してテストできることです。ただし、このアプローチの制限は、統合前に個々のサブシステムを徹底的にテストしないことです。
この制限を排除するために、スタブとドライバーを使用して、最上層、中間層、および最下層の統合を並行してテストするサンドイッチテストを変更しました。
＃4）ビッグバンアプローチ：
このアプローチでは、アプリケーションのすべてのモジュールの準備が整った時点で統合が行われます。すべてのモジュールを統合した後にテストを実行して、統合システムが機能しているかどうかを確認します。
インクリメンタルテストではなく、すべてが一度に統合されるため、このアプローチで問題の根本原因を見つけることは困難です。このアプローチは通常、1ラウンドのSITのみが必要な場合に採用されます。
結論
この記事では、システム統合テスト（SIT）とは何か、そしてそれを実行することがなぜ重要なのかを学びました。
SITの実行に関連するコアの概念、手法、アプローチ、および方法について理解しました。また、SITがUATやシステムテストとどのように異なるかについても説明しました。
この素晴らしい記事を楽しんでいただけたでしょうか！