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