1 統合試験の概要
1.1 目的と位置づけ
統合試験は、複数のソフトウェア部品やサブシステムを結合した状態で、機能要件と非機能要件が所定の条件下で成立することを確認する試験である。単体の正しさだけでは保証されない、結合後に顕在化する不整合を対象とし、インタフェース、データ受け渡し、連携の順序、障害時の挙動などを重点的に検証する点に特徴がある。
位置づけとしては、単体試験で確認された各要素の品質を前提に、結合によって発生しうる連携面の欠陥を洗い出し、システム試験へ接続する段階に置かれることが多い。結果は、後続工程におけるリスク低減や品質見積りの根拠として活用される。
1.2 対象範囲と粒度
1.2.1 コンポーネント間の結合
コンポーネント間の結合では、API、イベント、メッセージ、ファイル入出力などの境界をまたぐ動作を中心に検証する。具体的には、呼び出し規約の整合、戻り値や例外の扱い、タイムアウトやリトライの方針、並行実行時の整合性など、結合によって表れる相互作用を確認する。
粒度は、個別の機能単位よりも「境界を含む最小の結合体」を基準に設定されることが多い。境界が十分に実装・観測できない場合は、後述するスタブや検証用アダプタを用いて確認可能な形に整える。
1.2.2 サブシステム間の連携
サブシステム間の連携では、複数のモジュールを越えて、業務フローや制御の連鎖が正しく成立するかを検証する。入力から処理、出力までの一連の流れが、想定した順序で進行し、途中の分岐や条件に応じて適切な分岐先へ遷移することが焦点となる。
ここでは、責務の分割によって起きやすい「どこで検証し、どこでエラーを扱うか」の線引きにも注目する。例えば、上流が前提条件を満たすと想定しているのに下流が同じ前提を置いていない、といった齟齬は統合段階で表面化する。
1.2.3 システム全体への拡張
システム全体への拡張では、統合範囲を広げることで、従来見えなかった経路や連鎖が動作するかを確認する。複数のサブシステムが同時に稼働する状況、運用設定が絡む状況、データ量や負荷条件が増える状況を取り込み、全体最適の観点で整合性を評価する。
ただし、統合範囲を無制限に広げると原因特定が難しくなるため、段階的統合と、段階ごとの合格基準を明確にして進めるのが一般的である。目的は「一括の動作確認」ではなく「段階ごとの品質リスクを潰すこと」に置かれる。
1.3 単体試験・システム試験との違い
単体試験は、個々の部品が設計仕様どおりに動くことを、主に内部観点で確認する。対照的に統合試験は、部品同士の境界に起因する問題—仕様解釈の差、入出力形式の不整合、データの整形や変換漏れ、連携順序のずれ—を中心に評価する。
システム試験は、より広い要件環境のもとで、ユーザ視点に近い形で総合的な成立を検証する傾向がある。統合試験はその前段に位置し、総合試験で見つかった不具合を「どの結合点に起因するか」に分解しやすい状態で不具合を減らす役割を担う。
2 計画と準備
2.1 テスト方針と基準
2.1.1 合格基準と判定方法
統合試験の合格基準は、機能面と非機能面を分けて設定するのが一般的である。機能面では、ユースケースごとの期待結果、許容される例外の種類、エラー時の復帰やロールバック可否などを基準化する。非機能面では、応答時間、処理能力、障害発生時の復旧時間、アクセス制御の成立などを数値または判定条件として定める。
判定方法としては、テストケースの合否に加え、重大度の高い不具合の混入有無、既知の欠陥の残存条件、再現性の有無、回帰試験の結果を合わせて総合判断する運用が多い。重要なのは、合格・不合格の判断が主観に依存しないよう、観測可能な指標と責任分界を用意することである。
2.2 統合戦略の設計
2.2.1 結合順序（段階的統合）
段階的統合では、依存関係の少ない要素から結合を始め、徐々に結合範囲を広げる。順序設計の要点は、原因切り分けの容易さと、早期に重要リスクを露出させることである。例えば、データ変換や共通基盤を先に結合しておくと、後続の多数ケースで繰り返し発生する不整合を先に潰せる。
また、結合の単位（どこからどこまでを一つの統合ステップとするか）を過度に大きくしないことが重要である。ステップが大きいほど一回の検証範囲は広がるが、不具合が出た際の特定コストが増える。
2.2.2 スタブ・ドライバの活用
スタブは、未完成または外部依存があるコンポーネントの代替として用いられ、期待する入出力を再現する。ドライバは、呼び出し側が未整備である場合に、テスト対象が想定するインタフェース経由で入力を生成する役割を持つ。
統合試験におけるスタブ・ドライバの価値は、環境依存を減らし、段階統合を成立させる点にある。ただし、スタブが仕様から逸脱すると偽陰性や偽陽性を生むため、入出力の契約（データ形式、エラー条件、タイムアウト挙動）を厳格に定義し、同じ契約に基づいて実装する必要がある。
2.3 テスト環境とデータ準備
2.3.1 環境構成と依存関係の整理
テスト環境では、対象が依存する外部要素—データベース、メッセージング基盤、外部API、認証基盤、ファイルストレージ、時刻・設定パラメータ—を整理し、再現可能な形で用意する。結合の成否は、ネットワーク条件や権限設定、設定値の差に敏感な場合があり、環境差を吸収できるよう構成を文書化することが重要である。
依存関係の整理には、疎結合に近い形での差し替え可否も含める。例えば、外部サービスはテスト用のゲートウェイや模擬サーバを介してアクセスし、実データに触れないよう配慮する運用が取りやすい。
2.3.2 データセットと再現性
データ準備では、代表ケースに加え、境界値や異常系を含むデータセットを用意する。再現性の確保のため、初期状態の復元手順（投入順序、マイグレーション有無、キャッシュ状態、乱数の固定）を明確にする。
また、データがもつ整合性制約（参照関係、状態遷移の前提、必須項目の有無）を満たすだけでなく、失敗が期待されるケースでは「失敗に至る条件」が確実に再現されるように設計する。これにより、統合段階での例外処理や復帰挙動を検証しやすくなる。
3 実施内容
3.1 インタフェース整合性の検証
3.1.1 入出力仕様の一致
入出力仕様の一致では、項目定義、型、桁数、単位、符号の扱い、必須・任意、デフォルト値、文字コード、丸め規則などを確認する。単体では成立していた処理が、統合すると別の変換層を経由して意味が変わることがあるため、境界での解釈差を重点的に点検する。
さらに、エラー時の契約にも注意を払う。例外コード、エラーメッセージの粒度、リトライ可能性、後続処理への影響（中断か継続か）を揃えることが、運用品質の安定に直結する。
3.1.2 形式・プロトコル・通信方式
形式・プロトコル・通信方式の検証では、同期・非同期の扱い、メッセージ配信の順序保証、重複配信への対応、タイムアウトとキャンセルの伝播などを確認する。通信方式により、同じ論理処理でも観測される挙動が変わるため、期待する契約を明文化して測定する。
加えて、互換性に関する観点—バージョン番号、後方互換の扱い、フィールド追加時の既存クライアント挙動—も必要に応じて確認対象にする。統合試験でここを押さえると、配布後の断片的な不具合を減らしやすい。
3.2 連携シナリオの試験
3.2.1 業務フロー／ユースケース連携
業務フロー／ユースケース連携では、複数のサブシステムが協調して成立する一連の流れを、期待結果と照合する。入力受付から検証、計算、永続化、通知、監査記録など、複数工程にまたがる成果物（状態や出力物）が矛盾なく整うことが要点である。
また、分岐条件や例外ルート—たとえば中間での検証失敗、外部参照不可、部分的なデータ欠落—が、他の工程に波及していないかを点検する。特に、成功時の処理だけでなく失敗時の整合もテストの一部として扱う。
3.2.2 状態遷移と例外処理
状態遷移と例外処理では、各コンポーネントの状態モデルが整合しているかを確認する。入力により状態が変化し、次の処理へ進むという前提が、結合によって崩れていないか—例えば承認待ちから実行中への遷移条件のずれ—を検証する。
例外処理では、エラー検知からユーザや上流へ返すまでの一連の応答を評価する。復帰可能か、再試行が許されるか、部分更新をロールバックするか、監査ログに何を残すかといった運用上の観点も含め、期待される振る舞いを判定基準に反映させる。
3.3 データ受け渡しの検証
3.3.1 境界値と整合性制約
境界値と整合性制約の検証では、データの最小・最大、欠け、過剰、形式違反などを用いて受け渡しの脆弱性を評価する。桁あふれ、日付の解釈差、空配列と欠損の区別、重複キーの扱いなど、境界で顕在化しやすい欠陥を優先して試験する。
整合性制約では、参照整合、排他条件、状態整合、冪等性の成立を確認する。例えば同一要求が再送された場合に、二重計上や二重発行が起きないかを、観測可能な指標で判断する。
3.3.2 同期・非同期処理の確認
同期処理では、応答が返るまでの計算結果や副作用（保存、通知、状態更新）が一貫しているかを確認する。非同期処理では、イベントの遅延、順序逆転、重複配信、最終的整合（eventual consistency）の成立などを評価対象にする。
さらに、後続処理が前提とする「いつ完了したとみなすか」を合わせる必要がある。完了通知の時刻、永続化の完了タイミング、監査記録の出力順など、観測点の差が問題を生むため、ログやメトリクスで追跡できる形にして検証する。
3.4 非機能要件の確認
3.4.1 性能（スループット・応答時間）
性能の確認では、スループットと応答時間を中心に、設定した負荷条件のもとで目標を満たすかを測定する。統合段階では、単体では分解できないボトルネック—通信待ち、データ変換のコスト、ロック競合、外部依存の遅延—が表に出る。
測定では、ウォームアップ、同時実行数、データ量、想定時間帯などの条件を明確にし、同じ条件で比較できるようにする。ばらつきが大きい場合は、分位点や平均以外の指標も併用する。
3.4.2 信頼性（障害耐性・回復）
信頼性では、障害が発生した際に機能が破綻しないこと、回復時に整合性が維持されることを確認する。例として、コンポーネントの一時停止、通信断、タイムアウト、ストレージ不足に近い条件などを用い、再試行やフォールバックが設計どおりに働くかを見る。
回復の評価には、状態の扱いが重要である。部分更新が残留しないか、重複処理が起きないか、ログが追跡可能な形で残っているかを、観測可能な結果として確認する。
3.4.3 セキュリティ（権限・入力検証）
セキュリティの確認では、権限の境界と入力検証を中心に検証する。統合段階では、認証情報の受け渡しが正しく行われるか、認可判定が期待した場所で実行されるか、内部連携でも同一の制約が適用されるかが論点となる。
入力検証では、形式チェック、長さ制限、文字種、構造の妥当性、危険な値の扱いを確認する。さらに、統合によって生じる「片側だけ検証している」状態を避けるため、上流・下流の責務分担を照合し、抜けがないことを確かめる。
4 成果物と品質保証
4.1 テスト仕様書・ケース設計
テスト仕様書とケース設計では、対象範囲、試験条件、合格基準、観測方法を整理し、再現可能な手順として記す。ケース設計は、ユースケース網羅と結合点の重点化を両立させることが望ましい。特にインタフェース境界と例外ルートは、仕様のズレが出やすいため優先される。
また、入力データと期待結果を対応付け、再実行時に判定がブレないようにする。ケースの粒度が粗すぎると原因特定に時間がかかり、細かすぎると運用コストが増えるため、バランスを調整する。
4.2 記録・ログ・証跡管理
記録では、実行条件、環境情報、入出力、例外発生点、性能測定結果などを体系的に保存する。ログは単なる出力ではなく、後から追跡可能な形で相関情報（要求ID、トランザクションID、タイムスタンプ、関連コンポーネント名）を含めることが重要である。
証跡管理は、監査対応や品質レビューに耐える形で、テスト実行と結果を紐づける。変更があった場合の比較もできるようにし、同じ不具合が再度起きた際の迅速な分析に役立てる。
4.3 不具合管理とトレーサビリティ
不具合管理では、検出から修正、再発確認までの流れを明確化する。統合試験では、複数コンポーネントが関与する場合が多いため、影響範囲、再現手順、期待と実際の差、観測ログの参照をセットで残すことが望ましい。
トレーサビリティは、要件、設計、テストケース、検出不具合が結び付く状態を指す。どの要件に対し、どの境界で、どの不具合が見つかったのかが追えると、品質の説明責任が果たしやすくなる。
4.4 改善サイクル（振り返りと次回計画）
改善サイクルでは、統合試験の結果をもとに、設計・実装・テストの観点で学習を蓄積する。振り返りでは、失敗したケースだけでなく、時間を要した切り分け、曖昧だった期待値、環境差が原因となった問題などを洗い出す。
次回計画では、優先的に見直す境界や、スタブ・ドライバの契約の改善、合格基準の再調整、ログ粒度の向上などを反映する。反復によって検出効率と品質の説明可能性を高めることが目的である。
5 よくある課題と対策
5.1 結合仕様の曖昧さ
結合仕様が曖昧だと、実装者間で解釈がずれ、統合後に同種の不具合が繰り返し出る。対策としては、入出力の契約—データ形式、エラーコード、タイムアウト、再試行規則—を具体化し、例示を含めて合意をとることが有効である。曖昧さが残る場合は、早期にプロトタイプ結合を行い、差分を可視化する。
また、仕様書だけでなく、テストケースにも契約を反映させることで、運用時の認識差を減らせる。
5.2 依存関係の不整合
依存関係の不整合は、バージョン差、設定値の差、外部連携の要件不足によって起きやすい。対策として、依存コンポーネントのバージョン管理と、環境構成の差分を自動的に検出できる仕組みを導入することが望ましい。
加えて、スタブの契約を依存仕様に整合させることで、統合前に失敗が早期検出される。依存関係の境界で「誰が責任を持って前提条件を満たすか」を定めることも、再発防止に寄与する。
5.3 環境差・データ差による不具合
環境差・データ差による不具合は、同じケースでも結果が変わるため、原因特定が難しくなる。対策として、初期状態を固定し、再実行手順を標準化する。性能試験での揮発要因（キャッシュ、同時負荷、計測方法）の制御も同様に重要である。
データ差については、投入順序や状態遷移の前提を含めて扱い、境界値の意図が崩れないようにする。可能であれば、データ生成はコード化し、同じ条件で再生できる形にする。
5.4 障害時の切り分け困難さ
障害時の切り分けが難しい要因は、ログ不足、相関情報の欠如、失敗の伝播経路が追えないことにある。対策として、要求単位で追跡できる識別子を導入し、重要な処理段階で記録を残す。統合試験では、通常系だけでなく障害系のログ設計も対象にする。
また、どのコンポーネントが、どのタイミングで、どの例外を扱うべきかを整理し、期待する伝播パターンと実際を照合する。観測点が増えるほど収集負荷は上がるため、測定コストと分析価値のバランスを取りながら設計する。