◀ 6.

結合テストとは｜単体テスト後のモジュール間I/F整合を確認する工程

▶
編集

本稿は 結合テスト (IT: Integration Test) に関する記事です。結合テストは、単体テスト (UT) の後段に位置し、複数のモジュール・コンポーネントを組み合わせた状態でシステムが正しく動作するかを確かめる工程です。単体では発見できないI/F の食い違い・データの受け渡し・状態遷移の不整合などを検出するのが目的です。

結合テストの位置づけ

工程視点
単体テスト (UT)関数・クラス単位の正しさ
結合テスト (IT)モジュール間の連携・I/F の整合
システムテスト (ST) / 総合テストシステム全体の機能・非機能
受入テスト (UAT) / 運用テスト業務視点・運用視点での合格判定

結合テストで確認する観点

観点例
I/F の整合API のリクエスト/レスポンス形式、CSV ヘッダ・桁・型
データ受け渡し画面 ↔ コントローラ ↔ サービス ↔ DAO ↔ DB の連携
状態遷移セッション・トランザクション・ワークフロー
例外伝播下位の例外が想定どおり上位に渡る／変換される
外部システム連携API 呼び出し・メール送信・ファイル転送
権限と認可ロールに応じた API/画面アクセス制御
性能ピーク時の応答時間 (性能テストへの橋渡し)

結合テストのアプローチ

アプローチ説明
ボトムアップ下位モジュールから順に結合。下位の動作確認が早く取れる
トップダウン上位 (画面・コントローラ) から結合。スタブで下位を仮置き
ビッグバンすべて結合してから一気にテスト。問題切り分けが難しい
サンドイッチ / ハイブリッド上下を並行に結合。多くの実プロジェクトで採用
機能 (Feature) ベース1 つの業務シナリオごとに結合する

スタブ / ドライバ / モック

呼び方役割
スタブ (Stub)下位モジュールが未実装の場合に用意する仮実装 (返り値だけ用意)
ドライバ (Driver)上位モジュールが未実装の場合に下位を呼び出すテスト用ハーネス
モック (Mock)呼ばれ方を検証できる仮実装
サービス仮想化外部 API・メインフレーム等の応答をシミュレート

主な成果物

  • 結合テスト計画書 — スコープ・体制・期間・テスト環境
  • テスト観点・シナリオ・テストケース — 機能ID / 画面ID と紐付け
  • テストデータ — マスタ・トランザクション・境界値
  • 環境構成資料 — 結合テスト用 DB / API のスタブ・モック
  • テスト結果報告書 — 実施件数・OK/NG・欠陥一覧
  • 欠陥トラッキング — 起票 → 修正 → 再テストのフロー

典型的なシナリオ例 (Web アプリ)

  • ログイン → 画面遷移 → CRUD 操作 → 結果確認 (Happy path)
  • 権限が無いユーザでの操作 (403 になるか)
  • 入力チェックの境界値 (桁・型・必須・相関)
  • セッションタイムアウト中の再操作
  • 外部 API 呼び出し失敗時のリトライ・代替動作
  • 同時アクセスでの楽観/悲観ロック挙動
  • ファイルアップロード・大容量データ・タイムアウト

使われるツール

用途ツール
API テストPostman、Insomnia、curl、HTTPie、Karate
E2E (画面操作)Selenium、Cypress、Playwright、Puppeteer
DB セットアップDbUnit、Testcontainers、Flyway / Liquibase
モック / スタブWireMock、MockServer、Hoverfly
Java の結合テストJUnit 5 + Spring Boot Test (@SpringBootTest)、Testcontainers
負荷JMeter、k6、Gatling
CI/CDGitHub Actions、Jenkins、GitLab CI

結合テストの合格基準 (例)

  • 計画したテストケースを100% 実施済み
  • 重大度 High の欠陥がすべてクローズ
  • 主要な業務シナリオがエラーなく通る
  • 同時アクセス・データ量の想定シナリオで応答が SLA 内
  • 外部 I/F のフォーマット・タイミングが仕様どおり
  • 関係者によるレビューと承認

うまくいかないサイン

  • テストデータが本番想定とかけ離れている — 件数 1 件、固定値だけ
  • 異常系が抜けている — Happy path しかテストしない
  • 環境差を吸収するモックが過剰 — 本物の I/F の不整合を見逃す
  • 欠陥の収束が見えない — 毎日新規欠陥が増える状態でリリース判定
  • UT を結合テストで肩代わり — 単体で潰すべき欠陥がここに集まる

注意点

  • UT で潰す欠陥は UT で潰す。結合テストは I/F・連携の検証に集中する
  • テスト環境のデータ管理を仕組み化する (Flyway / Liquibase / fixture)
  • 本番相当の負荷で 1 度通す経験を作る (性能課題の先送り防止)
  • 個人情報・本番データを検証環境にコピーする場合はマスキング必須
  • 欠陥の再現条件・重大度・回避策を必ず記録する
  • CI で自動回帰実行できる結合テストを段階的に増やす

関連

編集
Post Share
子ページ

子ページはありません

同階層のページ
  1. 要件定義
  2. 基本設計
  3. 詳細設計
  4. 製造
  5. 単体テスト
  6. 結合テスト
  7. 総合テスト
  8. 受入テスト/運用テスト
2026-05-13 09:20:42 atom 235

人気ページ

最近更新/作成されたページ