結合テストとは？目的・種類・実施方法をわかりやすく解説
システム開発において、個々の機能が正しく動いていても、組み合わせたときに問題が発生することがあります。そうした「つなぎ目」の問題を検出するのが結合テストです。本記事では、結合テストの目的・種類・テスト観点の洗い出し方・実施方法まで初心者にもわかりやすく解説します。
目次
結合テストとは？
結合テスト(IT: Integration Testing)とは、個別に開発・テストされた複数のモジュール（機能・部品）を組み合わせ、それらが正しく連携して動作するかを確認するテストです。英語では Integration Testing（インテグレーションテスト） と呼ばれ、略称として IT や CT（Combined Test） が使われることもあります。
JSTQBなどの標準では「統合テスト」と表記されますが、国内の開発現場では「結合テスト」という呼称も広く使われています。本記事では「結合テスト」に統一します。
V字モデルで整理すると、結合テストは単体テストの後、システムテストの前に位置します。
なお、システムテストは開発チームがシステム全体の動作を確認するテストであるのに対し、受け入れテストはシステムを実際に使う立場の関係者（社内のビジネス部門やプロダクトオーナー、顧客など）が業務要件を満たしているかを確認するフェーズです。誰が実施するかはプロジェクトの体制によって異なりますが、「作る側」と「使う側」で役割が分かれる点が特徴です。
具体例で考えてみましょう。
ECサイトに「商品検索 → 商品一覧表示 → 商品詳細表示 → ショッピングカートへの追加」という処理があるとします。単体テストでは各処理を個別に確認しますが、結合テストでは「商品を検索したら、正しい商品一覧が表示されるか」「商品一覧から詳細ページへ遷移したとき、正しい商品情報が引き渡されるか」といった各処理間のつながりと連携を確認します。
誰が実施するのかについては、開発チームが担当するケースと、QAチームが担当するケースがあり、プロジェクトの体制によって異なります。
結合テストと単体テストの違い
結合テストの定義を踏まえると、単体テストとの違いがより明確になります。
| 単体テスト | 結合テスト | |
|---|---|---|
| テスト対象 | 関数・メソッドなど最小単位 | 複数のモジュール間の連携 |
| 目的 | 個々の機能が仕様通りに動くかの確認 | モジュール間のインターフェース・データの受け渡しの確認 |
| 主な担当 | 開発者 | 開発チーム・QAチーム |
単体テストは「商品検索機能単体が正しく動くか」を確認するのに対し、結合テストは「商品検索の結果が商品一覧ページに正しく渡されているか」を確認するイメージです。
両者の違いについては、「単体テストと結合テストの違いとは？比較表と具体例で分かりやすく解説」でより詳しく解説しています。
結合テストとシステムテスト(総合テスト)の違い
結合テストとよく比較されるシステムテストに関しても、両者の違いを見ていきましょう。
| 結合テスト | システムテスト | |
|---|---|---|
| テスト対象 | 特定のモジュール間・機能間の連携 | システム全体 |
| 目的 | モジュール間の連携に問題がないかの確認 | システム全体が要件定義・仕様通りに動くかの確認 |
| 主な担当 | 開発チーム・QAチーム | QAチーム・第三者検証チーム |
結合テストは「部分的なつながりの確認」、システムテストは「全体としての動作確認」と整理できます。
結合テストの目的
結合テストの概要を踏まえ、次はなぜ結合テストを実施するのか、その主な目的を3つ紹介します。
単体テストでは検出できない不具合を発見する
個々のモジュールが単体では正常に動いていても、組み合わせたときに初めて問題が発生することがあります。例えば、あるモジュールが返すデータの型と、受け取り側のモジュールが期待するデータの型が一致しない、といったケースがあります。こうした「連携部分の不具合」は単体テストだけでは検出できないため、結合テストで早期に発見することが重要です。
後工程の手戻りを防ぐ
結合テストの段階で不具合を検出・修正しておくことで、その後のシステムテストや受け入れテストでの大きな手戻りを防ぐことができます。テストの後工程になるほど不具合の修正コストは上昇する傾向があるため、早期発見は開発全体の効率化にもつながります。
システム全体の品質と信頼性を高める
各モジュール間の連携が保証されることで、システム全体としての品質が高まります。結合テストをしっかり実施することで、システムテストへスムーズに移行でき、最終的なシステムの信頼性向上につながります。
結合テストの種類
では、結合テストには具体的にどのような種類があるのでしょうか。ここでは代表的な3つを紹介します。
インターフェーステスト（連結テスト）
インターフェーステスト(連結テスト)は、モジュール間でデータを受け渡す際に、データの型・桁数・順序・必須項目などが仕様通りになっているかを確認するテストです。結合テストの中で最も基本的なテストとして位置づけられています。
確認する主な項目の例：
- APIのリクエスト・レスポンスのデータ形式が仕様通りか
- 画面Aから画面Bへ遷移する際、必要なパラメータが正しく引き渡されているか
- 関数の呼び出し結果が、呼び出し元に正しく返却されているか
業務シナリオテスト
業務シナリオテストは、実際の業務フローや利用シーンを想定して、一連の操作が正しく完了するかを確認するテストです。
例えば、ECサイトでの「ログイン → 商品検索 → カートに追加 → 注文確定 → 確認メール送信」という一連の流れが、複数のモジュールをまたいでスムーズに動作するかを検証します。基本的な正常系だけでなく、イレギュラーな操作（在庫切れの商品を購入しようとするなど）も含めてテストすることが重要です。
結合テストの段階で実施される非機能テスト
負荷テストやパフォーマンステストなどの非機能テストは、結合テストの段階で実施されることがあります。JSTQBの定義では、これらは「何をテストするか」を表すテストタイプの分類であり、「どの段階でテストするか」を表すテストレベルとは別の軸で考えるものです。
そのため、結合テストのフェーズで、アクセスが集中した際の応答速度や連続稼働時の安定性を確認するといった形で実施されることがあります。
現場によって異なる「結合テスト」の呼び方と進め方
「結合テスト」という言葉は、開発現場の規模・体制・開発手法によって、指す内容や呼び方が変わる場合があります。自分の現場でどのような文脈で使われているかを把握しておくと、認識のすり合わせがスムーズになります。
ここでは、「大規模業務システム・受託開発」と「Web系自社開発」の場合に分けて、どのように呼び方が変わるのかを紹介します。
大規模業務システム・受託開発の場合
複数のサブシステムが複雑に絡み合う大規模なシステム開発では、結合テストを段階的に分けて実施する場合があります。
- ITa（内部結合テスト）：同一サブシステム内のモジュール間の連携を確認する段階
- ITb（外部結合テスト）：異なるサブシステム間や外部システム（決済システム、メール配信サービスなど）との連携を確認する段階
このように段階を分けることで、問題の発生箇所を切り分けやすくなるという利点があります。ウォーターフォール型の開発では、テスト仕様書をベースに手順を明文化し、開発チームとQAチームが役割分担して進める傾向にあります。
略称については現場によって異なり、IT・JT（Joint Test）・CT（Combined Test）などが使われることもあります。
Web系自社開発の場合
アジャイル開発やCI/CDパイプラインを採用するWeb系の自社開発では、「結合テスト」よりも 「APIテスト」 と呼ばれることがある傾向にあります。
この場合、ITa/ITbのような厳密な段階分けよりも、APIの入出力確認やサービス間の連携確認を自動化し、コードのプッシュごとにCI/CDで継続的に実行する形が多く見られます。開発者自身がテストコードを書き、スプリントの中で繰り返し実施していくスタイルです。
どちらのアプローチも、開発の規模・体制・文脈に応じたものであり、優劣があるわけではありません。大切なのは「モジュール間の連携を確認する」という結合テストの本質を理解した上で、自分の現場に合った形で実施することです。
結合テストに必要な観点
次に、結合テストで「何をテストすればよいか」を決める際の基本的な観点を洗い出していきます。
モジュール間のインターフェースの確認
インターフェーステストで特に見落としやすいのが、仕様書上は正しく見えても実装間でずれが生じるケースです。具体的には次のような問題が起きやすい傾向にあります。
- 片方のモジュールがnullや空文字を返すケースを、受け取り側が想定していない
- データの単位や桁数の解釈が送り手と受け手で異なる（例：金額を円で渡すつもりが銭で受け取られる）
- 必須パラメータが特定の条件下でのみ欠落する
正常系・異常系の動作確認
正しいデータでの正常動作だけでなく、不正なデータや境界値での動作も確認します。
- 正常系：期待通りの入力で、期待通りの結果が得られるか
- 異常系：存在しないIDでのログイン試行、在庫数0の商品のカート追加など、イレギュラーなケースで適切なエラー処理が行われるか
データの整合性・引き渡しの確認
モジュールをまたいでデータが欠損・変換されていないかを確認します。「画面遷移が正しく行われるか」という観点はシステムテストの範疇ですが、遷移の際に必要なデータが正しく引き渡されているかは結合テストで確認します。
- 商品一覧で選択した商品のIDが、詳細ページに正しく渡されているか
- ある処理でデータベースに書き込まれた内容が、次の処理で正しく参照されているか
洗い出しのコツとしては、基本設計書・画面遷移図・シーケンス図を参照しながら、「どこでデータが受け渡されるか」「どのモジュールがどのモジュールを呼び出すか」を整理することで、テスト観点を漏れなく洗い出しやすくなります。
結合テストの実施方法
ここでは、最も基本的なインターフェーステストを例に、シンプルな手順を説明します。
1. テスト計画の作成
テストの対象範囲・スケジュール・担当者を決めます。どのモジュール間の連携を確認するのかを明確にしておくことが重要です。
2. テスト設計（観点の洗い出し → テストケース作成）
テストの観点を洗い出し、「どのデータを入力したときに、何が返ってくるか」という具体的なテストケースを作成します。観点の洗い出し方については「結合テストに必要な観点」のセクションを参照してください。
テストケースは以下のような形式で記述するのが一般的です。
| テスト対象 | 入力値 | 期待される結果 | 合否 |
|---|---|---|---|
| ログイン機能（入力フォーム → 認証モジュール） | 正しいID・パスワード | 認証成功・ホーム画面のデータが返る | - |
| ログイン機能（入力フォーム → 認証モジュール） | 誤ったパスワード | 認証失敗・エラーコードが返る | - |
| 商品検索 → 商品一覧 | 存在する商品名 | 該当商品のID・名称・価格が正しく渡る | - |
| 商品検索 → 商品一覧 | 存在しない商品名 | 空のリストが返る | - |
テストケースを作る際は、正常系（期待通りの入力）と異常系（不正な入力・境界値）の両方を含めることが重要です。
3. テスト環境の準備
テスト対象のモジュールが未完成の場合は、スタブやドライバーを準備します。
スタブとドライバーを使う目的は、「未完成のモジュールがあっても、他のモジュールのテストを先に進める」ためです。開発は並行して進むことが多く、すべてのモジュールが揃うまで待っていてはテストが遅れてしまいます。
ここで、スタブとドライバーについて簡単に説明します。
- スタブ：呼び出し先の下位モジュールがまだ完成していない場合に、決まった値を返すダミープログラムとして使う
- ドライバー：テスト対象モジュールを呼び出す上位モジュールが未完成の場合に、代わりに呼び出しを行うプログラムとして使う
なお、本物のモジュールと差し替えた際には、スタブやドライバーを使ったテストとは別に改めて確認が必要です。
4. テスト実行・不具合管理
テストケースに沿ってテストを実行し、期待と異なる動作があれば不具合として記録・管理します。
5. テスト完了の判断
あらかじめ定めた完了基準（テストケースの消化率、不具合の解消状況など）を満たしたら完了とします。
結合テストを実施する際のポイント
実施方法を踏まえた上で、結合テストをより効果的に進めるためのポイントを4つ紹介します。
テスト設計前に基本設計書・画面遷移図を整備する
テスト観点の洗い出しは、設計ドキュメントが土台になります。基本設計書や画面遷移図に不足がある場合は、テスト設計の前に確認・補完しておきましょう。設計ドキュメントが充実しているほど、テストの網羅性が高まります。
単体テストの完了を前提とする
結合テストは、各モジュールの単体テストが完了していることを前提に実施します。単体テストが不十分なまま結合テストに進むと、単体の不具合と連携の不具合が混在してしまい、原因特定が困難になります。
段階的に結合範囲を広げる
一度に多くのモジュールを結合してテストするよりも、少数のモジュールから始めて段階的に範囲を広げていく方が、不具合の原因を特定しやすくなります。問題が発生したときに「どの結合ステップで問題が起きたか」を絞り込みやすくなるためです。
テストの粒度をチームで先に合わせる
「単体テストとシステムテストはイメージしやすいが、結合テストはどこからどこまでか」という疑問は、現場でよく聞かれます。結合テストは定義の幅が広く、何と何を組み合わせて1つのテストとして扱うか（粒度）が、チームによって異なりやすいためです。
粒度が細かすぎると単体テストと内容が重複して工数だけかかり、逆に粗すぎると一度に多くのモジュールを結合するいわゆるビッグバン結合になり、不具合の原因特定が困難になります。
粒度を決める際は、以下のような切り口が参考になります。
- 基本設計書でひとまとまりとして定義されている単位を基準にする
- データの受け渡しが発生する境界（インターフェース）を洗い出し、その境界をひとつのテスト単位にする
- チームや担当の境界線（チームAとチームBの接点など）を現実的な基準として使う
大切なのは、テスト設計を始める前にチーム内で「自分たちの結合テストでは何と何をひとまとめにテストするか」を言語化して合意しておくことです。粒度の認識が揃っていないと、テストケースが人によってバラバラになり、レビューもしにくくなります。
結合テストにおける手動テストと自動化の使い分け
では、結合テストにおいて、手動テストと自動化はどのように使い分ければよいのでしょうか。
自動化が効果的な場面
繰り返し実施するリグレッションテスト（既存機能への影響確認）は、自動化との相性が良い傾向にあります。たとえば、コンポーネント間のAPIインターフェーステストを自動化しておくことで、機能追加や変更のたびに既存の連携が壊れていないかを素早く検知できるようになります。CI/CDパイプラインに組み込むことで、コードの変更のたびに自動で実行される仕組みを作ることも可能です。
手動テストが適している場面
業務シナリオテストなど、実際の利用シーンを想定した複雑な判断が必要なテストは、手動での実施が適している場合があります。また、初回のテスト設計の段階では、どのケースを自動化すべきかを人が判断する必要があります。
MagicPodのようなテスト自動化ツールを活用することで、GUI操作を含む結合テストの自動化も検討できます。手動と自動を組み合わせ、効率的なテスト体制を構築することがポイントです。
まとめ
結合テストは、単体テストとシステムテストの間に位置する、モジュール間の連携を確認するテスト工程です。単体テストでは見つからない「つなぎ目」の不具合を早期に検出し、後工程をスムーズに進めるための重要なステップです。実施する際は、テストの粒度をチームで合わせ、手動テストと自動化を適切に使い分けることが、システム全体の品質向上につながります。
