結合テストとは？手法と観点のポイントを解説

以前の記事でシステム開発におけるテスト工程の重要性と単体テストについて解説しましたが、今回は次のテスト工程である「結合テスト」について、詳しく掘り下げていきます。
ひとつ前の工程である単体テストで正常に動作するようになったコンポーネントやシステムを組み合わせることで、実際の動作に近い状態でソフトウェアの挙動を確認します。

結合テストとは

結合テストとは、複数のモジュール（機能）を組み合わせて動作させたときに、システム全体として期待通りに動作するかを確認する工程です。
たとえば、ログイン機能とダッシュボード表示機能、データ登録機能と通知機能など、単体では正常に動作する機能同士が「つながったとき」にどうなるかを検証します。
V字モデルにおいては「基本設計」に対応したテスト工程です。
基本設計では開発システムの全体像（機能ごとに、機能がどのようなものなのか、何をするためのものなのか、他の機能とのつながりなど）を決めていきます。
要件や画面設計の“意図”が、システムとして正しく結合されているかが重要になります。裏を返せば、要件と仕様のギャップや画面の遷移ミス、データ整合性の破綻といったバグは、この段階で多く発見されます。
つまり、基本設計に書かれた「機能間の連携仕様」がきちんと実装されているかを確認するのが結合テストです。
このことからも、基本設計の質が結合テストの成否に直結すると言えます。

基本設計がテストの指針になる

結合テストの設計は、一般的には基本設計書をベースに行います。
特に以下のような情報が重要です。
・画面間の遷移フロー
・機能間の依存関係（例：登録後に一覧へ戻るなど）
・入力と出力の整合性（例：DB登録 → 表示内容）
・外部システムとの連携仕様（API連携など）
「要件を満たす＝結合テストで期待通りの結果が出る」という関係が成立するには、設計段階での粒度と整合性が重要です。

単体テストとの違いと結合テストの役割

前回解説した単体テストは、関数やクラスなど最小単位の検証でした。
対して結合テストでは、「この機能が正しく動いたうえで、次の機能につながるか」という流れ・つながりの品質に焦点を当てます。

どのテスト工程も重要ではありますが、結合テストはユーザーの体験や業務フローに最も近いため、品質と評価に直結します。

• 想定と異なる画面遷移
• 入力した値が反映されていない
• 前画面と整合しない内容が表示される

こういった不具合は、結合テストでしか見つけられないことも多くあります。
また、開発者にとっても、画面や機能の目的、つながりを理解する良い機会になります。
結合テストの有無にかかわらず、設計や実装段階からも「この機能はどのような意図で使われるのか？」「この処理の後に何が起きるのか？」を意識することが、エンジニアとしての視野を広げます。

結合テストで行われる一般的なテストの種類と観点

結合テストでは、単に「動くか」だけではなく、機能同士のつながりが現実的な業務フローとして成立しているかを、多角的に確認します。複数のモジュールを組み合わせて検証するため、単体テストでは見つからない不具合や仕様の齟齬が明らかになります。以下に代表的なものを紹介します。

疎通テスト（接続確認）

疎通テストは、結合テストの前段階として行われる簡易的な動作確認です。モジュール間をつないだ後、システムが致命的なエラーなく動作するか、最低限の通信や遷移が成立するかを確認します。つまり、「とりあえず、動くかどうか」結合テストを実施するにあたって問題が無いかをテストします。

• 目的
  ・ 結合テストを開始するにあたっての前提確認
  ・ 致命的な設定ミスや接続エラーを早期に発見
• 特徴
  ・ 詳細な仕様検証は行わない
  ・ テスト環境や構成ミスによる「テスト不能状態」を早期に防ぐ
  ・ 通常は失敗した場合、結合テストに進まず修正対応が優先される
• 例
  ・ 画面から別の画面に遷移できるか
  ・ APIにアクセスして正常なレスポンスが返るか
  ・ バッチ処理が起動可能か

機能テスト（結合テストにおける）

結合テストにおける機能テストは、「ログイン機能」や「検索機能」など、1つの機能単位として表現される処理が、複数の内部モジュールや画面・APIを連携して正しく動作するかを確認するテストです。
「1機能」といっても、ログイン機能を例にすると「画面表示 → 入力処理 → 認証API呼び出し → セッション設定 → リダイレクト」など、実際には複数の処理が連携して成り立っています。結合テストでは、単体テストを終えたモジュールを組み合わせ、これらが機能としてまとまっている状態で正しく動くかを確認します。

• 目的
  ・ 要求仕様の検証：各機能が想定された入力に対して、正しい出力や処理を行うかを確認する
  ・ 入力・処理・画面遷移・データ共有など、機能間の「つながり」を検証する
  ・ 単体テストで確認できないUIや画面遷移の動作もあわせて検証する
• 特徴
  ・ 仕様に基づく：テストケースは画面仕様書や機能仕様書に基づいて設計される
  ・ 入力内容の受け渡しや処理状態の引き継ぎも重要な観点
  ・ 単体では検出できない「連携上の不整合」が浮き彫りになる
• 例
  ・ 「申込 → 承認 → 完了」の一連フローのテスト
  ・ 商品登録後に一覧画面に正しく表示されるか
  ※ 複数の機能（登録処理・表示処理・状態変更処理など）が正しく連携しているかを確認する観点に基づいたテスト

回帰テスト（リグレッションテスト）

回帰テストは、結合テストの中で修正や機能追加があった際に、既存の連携や動作に悪影響が出ていないかを確認するテストです。
特に連携部分は副作用が出やすく、継続的な再検証が必要です。

• 目的
  ・ 修正や追加によって壊れてしまった機能間連携を検出する
  ・ 品質を継続的に維持し、改修後もシステム全体が安定して動作することを確認する
  
• 特徴
  ・ 検証範囲は修正箇所だけでなく、その周辺機能との連携も対象
  ・ 結合テスト中に発見されたバグの修正後に、重点的に実施される
  ・ テスト自動化との親和性が高い
  
• 例
  ・ 通知機能を修正したあと、関連する一覧表示・詳細画面で異常が出ていないかを確認
  ・ 検索ロジックを改修後、検索結果が正しく表示されるか、並び順が崩れていないか確認
  ・ 入力処理に変更を加えた際、バリデーションや遷移動作に影響がないかを再確認

ユーザビリティテスト（使いやすさの検証）

ユーザビリティテストは、画面や機能をつないだ操作の中で、ユーザーが直感的に使えるかどうかを確認するテストです。本来UATやシステムテストで重点的に行われますが、結合テストの過程でも、機能連携の流れの中で操作のしづらさや誘導ミスなどに気づくことがあります。
結合テストの過程でも、機能連携の中にある「わかりにくさ」「誤解されやすさ」などに気づく機会にもなります。

• 目的
  ・ 操作のしやすさや、ユーザー誘導の明快さを確認する
  ・ 画面・機能間の連携が“使いにくさ”につながっていないかを評価する
  
• 特徴
  ・ 結合テスト中に見つかるUIの違和感や使い勝手の課題を整理できる
  ・ 専門的なUX評価とは別に、現場レベルでの気づきとして活用される
  ・ システムテストやUATで本格実施されることも多いが、結合段階でも重要な視点
  
• 例
  ・ 画面遷移後、操作対象のボタンが画面外にあって見つけにくい
  ・ 入力エラー時のメッセージが不明瞭で、何を修正すべきか伝わらない
  ・ 戻るボタンを押すと、予期しない画面に遷移してしまう

状態遷移テスト（ステータス変化の検証）

状態遷移テストは、機能間の連携によってデータやシステムの状態が変化した際に、その変化が期待通りであるかを確認するテストです。
ワークフローやステータス管理など、複数機能の連携で状態が推移するようなケースに有効です。

• 目的
  ・ 業務フロー上の状態変化が正しく反映されているかを確認する
  ・ 状態に応じた画面表示・操作制御が仕様通りに行われているか検証する
  
• 特徴
  ・ 複数の画面や操作を経て状態が変わるため、結合テストの中でも重点観点
  ・ 状態が誤って変わる、または変わらないといった「実害」が出やすい領域
  ・ 条件付きでの遷移（承認済のみ遷移可能など）もテスト対象
  
• 例
  ・ 応募が「未対応 → 対応中 → 完了」と進むフローの各段階で画面表示が正しいか
  ・ 申請が却下されたあとに「再申請ボタン」が表示されるか
  ・ 公開済みの投稿を編集後、「公開中」ステータスが維持されているか

エラーパステスト（異常系動作の検証）

エラーパステストは、結合された機能同士の連携中に発生し得る異常に対して、システムが適切に対処できるかを確認するテストです。
正常系だけでなく、失敗パターンにも対応できるかを確認します。

• 目的
  ・ 入力ミス・通信エラー・データ不整合などに対する耐性を確認する
  ・ 利用者に誤動作や混乱を与えない適切な制御・エラー表示があるかを確認する
  
• 特徴
  ・ 単体では正常でも、連携したときに異常が顕在化するケースが多い
  ・ 例外処理、リトライ、タイムアウトなど、現実の動作環境を模擬する観点が重要
  ・ 「落ちない」「壊れない」「間違えない」ための堅牢性テストの一環
  
• 例
  ・ API通信に失敗したときにエラーメッセージが表示され、リトライできるか
  ・ 間違ったユーザーIDでログインを試みた際に、想定外の画面遷移が発生しないか
  ・ 関連データが削除された状態でも、画面が正しく動作するか

データ整合性テスト（情報の一貫性確認）

データ整合性テストは、複数の画面・機能をまたいで扱われるデータが、どの段階でも正しく保たれているかを確認するテストです。
保存・表示・出力など、複数経路を通ったデータの一貫性を確認します。

• 目的
  ・ データが機能間で正しく受け渡され、変質や欠損が発生していないことを確認する
  ・ 一つの入力がシステム全体に正しく反映されていることを保証する
  
• 特徴
  ・ 画面 → DB → 表示 → 通知メール など、データの通り道を意識する
  ・ 表示レベルだけでなく、DBやログといった裏側も含めて確認する
  ・ 結合テストならではの“横断的な観点”として非常に重要
  
• 例
  ・ 入力した会社名が、確認画面・一覧・詳細・メール通知すべてで一致しているか
  ・ 表示上は削除済みになっているが、DB上では削除されていないなどの不整合がないか
  ・ 商品の金額を変更した際、請求画面・CSV出力・APIレスポンスがすべて更新されているか