総合テストと結合テストの違い 目的・検証範囲・実施環境・テスト観点の比較と実務での使い分け

「総合テストと結合テストの違いを説明できない」「テスト計画で両者の境界を決めにくい」「プロジェクトごとに名称や範囲が異なり、認識がずれる」。こうした曖昧さは、テスト漏れや重複、品質低下の原因になります。

結合テストは、複数のモジュールを組み合わせた際に、データの受け渡しや機能間の連携が正しく動くかを確認するテストです。一方、総合テストは、完成したシステム全体が要件通りに動作するかを、本番に近い環境で検証します。

本記事では、結合テストと総合テストの目的や検証範囲、実施環境、テスト観点の違いを整理し、テスト計画を立てる際の判断基準までわかりやすく解説します。

この記事でわかること

・結合テストと総合テストそれぞれの正確な定義と目的

・両者の違いを6つの観点で比較した明確な整理

・テスト工程全体における結合テストと総合テストの位置づけ

・結合テストと総合テストで検証すべき具体的な観点

・テスト計画を立てる際に意識すべき実務上のポイント

無料サービス資料

AIコンサル・AX伴走支援サービス
ご紹介資料

• 
• 
• 

少数精鋭で高利益率な「筋肉質企業」への変革を実現するための考え方や支援内容をまとめた資料です。

こんな方におすすめ

• AI導入を検討している
• 業務改善の進め方を知りたい
• 導入事例を確認したい

サービス資料をダウンロードする

結合テストとは ─ モジュール間の「つなぎ目」を検証する

結合テスト（IT：Integration Testing）は、単体テストを通過した複数のモジュール（プログラムの部品）を組み合わせた際に、モジュール間でのデータの受け渡し、処理の呼び出し、画面間の遷移が正しく機能するかを検証するテストです。「連結テスト」「統合テスト」と呼ばれることもあります。

たとえば、「商品の検索画面で選択した商品の情報が、注文入力画面に正しく引き継がれるか」「注文の登録処理が完了した後に、在庫テーブルの数量が正しく減算されるか」といった、モジュール同士が連携して動作する部分に問題がないかを確認するのが結合テストの主な目的です。

結合テストには大きく分けて、「内部結合テスト」と「外部結合テスト」の2種類があります。内部結合テストは同一サブシステム内の密接に連携するモジュール同士の動作を検証し、外部結合テストは異なるサブシステム間や外部システムとのデータ連携が仕様通りに行われるかを検証します。

総合テストとは ─ 「完成したシステム全体」を検証する

総合テスト（ST：System Testing）は、結合テストを経てすべてのモジュールが組み合わさった状態のシステム全体を対象に、本番環境に近い条件のもとで、要件定義で定められた機能要件と非機能要件がすべて満たされているかを総合的に検証するテストです。「システムテスト」とも呼ばれ、開発チームが実施する最後のテスト工程として、「このシステムはリリースに耐えうる品質を備えている」と保証するための最後の関門として明確に位置づけられています。

総合テストでは、機能が正しく動作するかだけでなく、性能（応答速度、同時接続時の安定性）、セキュリティ（不正アクセスへの耐性）、障害回復（障害発生時の復旧能力）、運用性（日常の運用業務が問題なく実施できるか）といった非機能面の検証も含まれます。結合テストでは検証の対象に含まれないこれらの非機能面の品質が、総合テストで初めて本格的に検証されるという点が、両テスト工程を区別する最も大きな特徴です。

関連記事：業務効率化アイデア55選｜部門別30＋AI15＋明日から3つで成果を出す方法

無料サービス資料

AIコンサル・AX伴走支援サービスご紹介資料

• 
• 
• 

AI導入・業務改善の進め方や支援内容、導入実績がわかる資料です。

この資料でわかること

• 社外AI役員とは
• 支援内容
• 導入の進め方
• 導入実績・効果

サービス資料をダウンロードする

総合テストと結合テストの違いを6つの観点で比較する

観点1：目的 ─ 「つなぎ目の検証」と「全体の検証」

結合テストの目的は、モジュール間でデータが正しく受け渡されるか、処理の呼び出しが期待通りに機能するかという「部品同士のつなぎ目」の正確性を検証することです。総合テストの目的は、すべてのモジュールが統合された「完成形としてのシステム全体」が、要件定義で定めた内容通りに動作するかを総合的に検証することです。

観点2：検証範囲 ─ モジュール間の連携かシステム全体か

結合テストの検証範囲は、2つ以上のモジュールを組み合わせた際のインターフェース（接続点）とデータの流れです。総合テストの検証範囲は、システムを構成するすべての機能、データベース、外部連携、ハードウェア、ネットワークを含むシステム全体です。結合テストが「モジュール間の接続が正常か」という部分的な視点で検証するのに対し、総合テストは「システム全体が要件通りに動作するか」というトップレベルの視点で検証する点が、検証範囲における最も根本的な違いです。

観点3：実施環境 ─ 開発環境か本番に近い環境か

結合テストは、開発環境やテスト用の環境で実施されることが一般的です。総合テストは、本番環境とできる限り同等の条件（ハードウェア、ネットワーク構成、データの量と種類）を揃えた環境で実施されるのが原則です。環境の違いに起因する問題は、開発環境だけでは検出できないため、本番に可能な限り近い条件での検証が不可欠なのです。

観点4：テスト観点 ─ 機能面中心か非機能面も含むか

結合テストでは、機能間のデータ連携、画面遷移、処理の順序が正しいかという機能面に焦点を当てた検証が中心です。総合テストでは、機能面の検証に加えて、性能テスト、セキュリティテスト、障害回復テスト、運用テストといった非機能面まで含めた多角的な観点での検証を通じて、システム全体の品質をリリース前に総合的に確認します。

観点5：テストの基準 ─ 詳細設計書か要件定義書か

結合テストは、詳細設計書に記載されたモジュール間のインターフェース仕様に基づいてテストケースを作成し、実行します。総合テストは、要件定義書に記載されたシステム全体の機能要件と非機能要件に基づいてテストケースを設計し、実行します。それぞれのテストの根拠となる設計文書が異なることで、検証の視点と粒度にも明確な差が生まれるのです。

観点6：工程の順序 ─ 結合テストが先、総合テストが後

標準的な開発プロセスでは、「単体テスト→結合テスト→総合テスト（システムテスト）→受入テスト」の順にテスト工程が進みます。結合テストでモジュール間の連携が正常であることが確認された後に、初めて総合テストとしてシステム全体の検証に進みます。結合テストが完了していない状態で総合テストを開始すると、結合テストの段階で解消されるべき連携不備が総合テストで大量に検出される事態となり、テスト工程全体の効率が著しく低下してしまいます。

結合テストで検証すべき具体的な観点

結合テストでは、以下のような観点に重点を置いて検証を行います。

データの受け渡しの正確性として、画面から画面へ、あるいは機能から機能へデータが引き渡される際に、値の型、桁数、内容が正しく維持されているかを検証します。処理の呼び出し順序として、ある機能が別の機能を呼び出す際に、呼び出しの順序と条件が設計通りであるかを確認します。画面遷移の正確性として、各画面からの遷移先が正しいか、戻りボタンやエラー時の遷移先が設計通りかを検証します。外部システムとの連携として、外部結合テストでは、他のシステムやサービスとのデータのやり取りが仕様通りに行われるかを確認します。

総合テストで検証すべき具体的な観点

総合テストでは、結合テストの対象とならない以下の観点を中心に検証を行います。

機能の網羅性として、要件定義書に記載されたすべての機能が正しく実装されているかを一つひとつ確認します。性能として、画面の応答速度、データの処理速度、同時アクセス時の安定性が要件で定められた基準を満たしているかを計測します。セキュリティとして、権限のないユーザーによるデータへの不正アクセスが防止されているか、入力値の不正な操作に対してシステムが適切に対応するかを検証します。障害回復として、サーバーの停止やネットワークの切断が発生した場合に、システムが正しく復旧し、データの整合性が保たれるかを確認します。運用性として、バックアップの取得と復元、ログの出力、バッチ処理の実行が手順通りに問題なく実施できるかを検証します。

テスト計画で意識すべき実務上のポイント

結合テストと総合テストの境界を明文化する

プロジェクトによっては結合テストと総合テストの境界が曖昧になりがちです。「結合テストではここまでを検証し、総合テストではここからを検証する」という境界線をテスト計画書に明文化し、プロジェクトの関係者全員で合意しておくことが、テスト漏れを防ぐ最も基本的な対策です。

結合テストを完了させてから総合テストに進む

スケジュールが逼迫している場合、結合テストの完了を待たずに総合テストを並行で開始しようとする誘惑がありますが、モジュール間の連携不備が残ったまま総合テストに入ると、本来結合テストで発見すべき不具合が総合テストで大量に検出され、かえって工程全体の遅延を招きます。目先のスケジュール圧縮のために工程を飛ばすよりも、結合テストの完了判定を厳密に行い、品質を確保したうえで次の工程に進むことが、結果として最も短い工期でプロジェクトを完了させる効率的な進め方です。

総合テストでは本番に近い環境を必ず用意する

総合テストを開発環境で代替してしまうと、本番環境固有の問題（ネットワークの遅延、データ量の違いに起因する性能劣化、外部連携先の仕様差異など）が検出できません。テスト環境の構築に手間とコストがかかったとしても、本番環境に可能な限り近い条件を整えて総合テストを実施することは、リリース後の障害発生リスクを最小化するための投資として必ず回収されます。

関連記事：AI研修とは｜目的・種類・費用・助成金から失敗しない選び方まで

まとめ

結合テストは、モジュール間のデータの受け渡しや連携が正しく機能するかを確認するテストです。一方、総合テストは、すべてのモジュールを統合したシステム全体が要件通りに動作するかを、本番に近い環境で検証します。つまり、結合テストは「部品同士のつなぎ目」、総合テストは「完成したシステム全体」を確認する点が大きな違いです。

テスト計画では、両者の目的や検証範囲、実施環境、テスト観点などを明確にし、結合テストの完了後に総合テストへ進むことが重要です。工程ごとの役割を明確にすることで、検証漏れや重複を防ぎ、リリース後の障害リスクを抑えられます。

テスト工程の品質を改善したい方は、要件定義からテスト戦略・設計、社員研修まで支援するネクストスケールへご相談ください。

AIコンサル・AX伴走支援サービスご紹介資料

• 
• 

この資料でこんなことがわかります！

• 社外AI役員とは
• 支援内容
• 導入の進め方
• 導入実績・効果

＼3ステップで簡単入力／