Webアプリの開発において「結合テスト」は、システム全体の品質を左右する重要な工程です。
単体テストで個々の機能が正しく動いても、機能同士をつなげたときに思わぬ不具合が発生することはよくあります。
本記事では、Webアプリの結合テストとは何か、どんな観点でテストケースを作るのか、そして実際のテストケースの具体例をわかりやすく紹介します。
これから結合テストの設計や実施を行うエンジニア・テスターの方に役立つ内容です。
結合テストとは？基本の考え方をわかりやすく解説
結合テスト（Integration Test）とは、複数のモジュールや機能を組み合わせて動作させ、それらが正しく連携しているかを確認するテストのことです。
目的
- 各機能間のデータの受け渡しが正しく行われるか
- 外部APIやDBとの接続が想定通りに動作するか
- 画面遷移やフローに不整合がないか
単体テストでは「1つの関数・機能」単位で確認しますが、結合テストでは「機能のつながり」全体に注目します。
たとえば、**「ログイン → 商品一覧 → カート追加 → 購入確認」**という一連の流れをテストするのが結合テストです。
結合テストと他のテスト工程との違い
| テスト工程 | 対象範囲 | 主な目的 | 実施者 |
|---|---|---|---|
| 単体テスト | 各関数・モジュール | 機能が正しく動くか | 開発者 |
| 結合テスト | 複数の機能の組み合わせ | データ連携・動作の整合性 | 開発者・テスター |
| システムテスト | システム全体 | 要件通りに動くか | テストチーム |
| 受け入れテスト | 実運用環境での利用 | ユーザー視点の確認 | クライアント |
結合テストは、「単体テストの後、システムテストの前」に実施される中間的な工程です。
ここで連携の不具合を見逃すと、後工程で修正コストが大きくなります。
結合テストで確認すべき主な観点
結合テストの設計では、次の観点を意識してテストケースを作成します。
- データの受け渡し
→ フロントエンドから送信されたデータがバックエンドに正しく届いているか。 - 画面遷移の整合性
→ 「ログイン後しかアクセスできない画面」に未ログインでアクセスした場合の動作。 - 入力値の妥当性
→ フォーム入力値のバリデーションが正しく働くか。 - 外部システム連携
→ 決済API、メール送信サービス、クラウドストレージなどの動作確認。 - 例外処理・エラーハンドリング
→ DBエラーやAPIタイムアウト時の動作。 - セッション管理・認証連携
→ ログインセッションが切れた状態で操作した場合の挙動。
これらの観点ごとにテストケースを作成することで、漏れのない検証が可能になります。
Webアプリでの結合テストケースの具体例（ユーザー登録機能）
ここでは、Webアプリにおける代表的な「ユーザー登録」機能を例に、結合テストケースを紹介します。
シナリオ：新規ユーザー登録の流れ
| No | テスト項目 | 前提条件 | 操作内容 | 期待結果 |
|---|---|---|---|---|
| 1 | 正常登録 | 登録フォームが開ける状態 | 全項目を正しく入力して「登録」クリック | 登録完了画面に遷移、確認メール送信 |
| 2 | メールアドレス重複 | すでに同じアドレスで登録済み | 既存のメールアドレスを入力 | 「このメールアドレスは登録済みです」とエラーメッセージ表示 |
| 3 | パスワード不一致 | パスワード確認欄が異なる | 「パスワード」と「確認パスワード」が不一致 | 「パスワードが一致しません」エラー表示 |
| 4 | バリデーション | 必須項目を未入力 | 名前・メールアドレスを空欄にして送信 | エラーメッセージがそれぞれ表示される |
| 5 | 外部API連携 | メール送信APIが正常稼働 | 正常登録完了後にAPIへ送信 | メール送信がAPIレスポンス200で完了 |
| 6 | 異常系APIエラー | APIレスポンスが500 | 正常登録を行う | 登録は完了せず、エラーメッセージ表示 |
| 7 | DB制約 | データベース接続不可 | DBサーバ停止 | 画面に「システムエラー」表示、登録失敗 |
このように、正常系と異常系の両方をカバーすることが重要です。
特にAPIやDBなど外部要素を含むケースは、結合テストで重点的に確認します。
結合テストケースの作り方ステップ
① 機能一覧を洗い出す
まず、対象システムの画面・機能を一覧化します。
例：「ログイン」「ユーザー登録」「商品一覧」「カート」「注文」「決済」「メール送信」など。
② 機能間のつながりを整理する
次に、機能同士のつながりをフローチャートやシーケンス図で明確化します。
（例）
ログイン → トークン発行 → セッション作成 → ユーザー情報取得
③ 入出力データを定義する
機能間でやり取りするデータ（例：ユーザーID、商品ID、セッションキーなど）を明確にします。
④ 正常系・異常系のテストパターンを作る
各機能連携について、想定される入力・出力・エラー条件を表形式で整理します。
⑤ テストデータを準備する
テスト環境に投入するデータ（例：登録済みユーザー・在庫あり商品）をCSVなどで用意します。
⑥ 実施と結果記録
テスト結果を「成功／失敗」「不具合内容」として記録し、開発側と共有します。
よくある結合テストの不具合例とその原因
- API連携のデータ型不一致
→ 文字列と数値の不整合によりエラー発生。 - セッション切れの考慮不足
→ ログインセッションが切れた状態でAPIを呼ぶとエラー画面に遷移。 - リダイレクトループ
→ 認証処理とアクセス制御の設定ミス。 - 在庫・数量の同期ズレ
→ フロントで更新済みだがバックエンドの反映が遅延。 - 非同期通信（Ajax）での例外未処理
→ フロントエンド側でエラーハンドリングが未実装。
これらは単体テストでは発見しにくく、結合テストの段階で明らかになる典型的な不具合です。
結合テストを効率化するポイント
- テストケースをExcelやTestRailなどで一元管理する
- テストデータを自動生成スクリプトで再利用する
- Jest・Cypressなど自動化ツールを活用する
- テスト環境を本番とできるだけ近い構成にする
- 不具合再現の手順をログとスクリーンショットで明確化
手動テストと自動テストを組み合わせることで、効率的に品質を担保できます。
まとめ：結合テストは“つながり”を検証する重要フェーズ
結合テストは、Webアプリの品質を左右する「つながりのテスト」です。
個々の機能が正しく動いても、連携が崩れればユーザー体験は損なわれます。
本記事で紹介したように、
- データ連携や画面遷移を意識した設計
- 正常系・異常系のバランスの取れたケース作成
- テスト結果の記録と共有
これらを徹底することで、安定したWebアプリをリリースできます。