結合テストとは？テストする観点と単体／システムテストとの違いを解説

2025.10.02

システム開発における開発工程の一部である結合テストについて具体的にどのようなことをしているのか、よく比較されがちな単体テストやシステム（総合）テストと何が違うのか、その辺りも含めて解説していきます。

本記事を読んでいただき、システム開発における結合テストについて、少しでも理解に繋がる材料となれると幸いです。

1.結合テストの目的とは？

単体テストを一通りクリアしたら、結合テストに移ることになります。そんな結合テストについて、1章ではどんなテストをするのか概要を説明します。

1-1.結合テストは、機能と機能の連携をテストすること

結合テストは、機能と機能を組み合わせて動作させた時に意図した通りの動きをするかテストすることです。挙動だけではなく、その挙動が仕様書に沿っているか、機能と操作の組み合わせが適切か、様々な観点で確認します。そのため、1回のテストで終わることはなく複数回繰り返してテストします。

1-2.結合テストは、単体テストの次に位置する

結合テストは、テスト工程の中でも単体テストを終えてからやってくるテスト工程となります。単体テストがクリアできていない状態で結合テストをやることは有りません。

各工程を以下のように略して呼ぶこともあるので、ここで覚えておくと良いでしょう。

工程	略称	英語
要件定義	RD	Requirement Definition
基本設計	BD	Basic Design
詳細設計	DD	Detail Design
単体テスト	UT	Unit Test
結合テスト	IT	Integration Test
システムテスト	ST	System Test
受入テスト	OT	Operation Test

1-3.結合テストと総合テストとの違い

それでは、単体テスト／総合テストと何が違うのか紹介します。簡単に表にまとめると以下の通りです。

名称	工程	対象	内容
単体テスト	最初のテスト	機能単体	機能単体で不具合なく動作するかテスト
結合テスト	単体テストの次	機能単体＋機能単体	機能と機能を組み合わせた時に不具合なく連動して動作するかテスト
総合テスト	結合テストの次	システム全体	要件定義で設定した要件に沿った動作をするかテスト

上記の通り、テストは3段階に分けて実施していきます。単体テストをクリアしても結合テストでエラーになることもあり、その場合は単体テストに戻ってエラーの原因を探りにいくことになります。そのエラーを放置して先に進めると欠陥があるシステムとなってしまうので、エラーは必ず解消しなければなりません。

2.結合テストの進め方

2章では実際に結合テストをどのように進めたら良いのか、どのような手法があるのか紹介します。

2-1.結合テストするための仕様書を作成する

結合テストを行うための仕様書をまずは作成しましょう。この仕様書は要件定義書等とは別で、結合テスト専用の仕様書になります。この仕様書をもとにエンジニアが結合テストを実施していくことになります。

要件定義書をもとに結合テストが必要な機能を洗い出す
結合テストの手法を記載
結合テストの観点を記載
どのような条件（環境）で実施するか

2-2.結合テストを実施する

結合テストには2種類の方法があります。考え方としては単体テストと同じです。単体なのか、複数なのかの違いです。

＜トップダウンテスト＞

最上位モジュールから下位モジュールの代用（スタブ）に上から順番に検証していく方法です。上から順番に確認していくので抜け漏れがしづらく管理がしやすいです。一方で上位モジュールが完成しないとテストができないので、すべて完成してからでないとテストができない非効率な部分があります。

＜ボトムアップテスト＞

トップダウンの逆で最下位モジュールから上に向かって順番に検証していく方法です。上位モジュールの代用でドライバと呼ばれるテスト用のプログラムを置きます。最上位ができていなくても下からテストしていくので、テストを同時並行的に進めることができます。一方で、上位に近づいてからエラーが発生したときは手戻りが多くなる可能性があります。

2-3.結合テストの結果を記録する

ログや入力／出力したデータを残しておくようにしましょう。後工程で、何か不具合が起きた時にどのようなテストをして、どのような結果が出たのか結果を見返すこともあるでしょう。テストしたエンジニアと別の人が見返すこともあるので、他人が見ても分かるように整理しておく必要があります。結果の残し方も仕様書で決めてあることが多いです。

3.結合テストで見るべき観点

3章では結合テストで注意してみるべきポイントを紹介します。

3-1.インターフェースのテスト

異なるモジュールとモジュールの連携がしっかりされるかテストをします。モジュール間でのデータの引き渡し等が仕様書に記載されている通り、正常に動作しているか確認します。

3-2.イレギュラーを想定したテスト

実業務で多くの人がシステムを触ることになると、開発者が想定していない操作をする人もいます。そんなイレギュラーな操作をしても不具合なく動作するか確認します。場合によっては仕様書には書かれていないイレギュラー操作もあるかもしれません。たくさんの人が触ることを想定して、テストをしましょう。

3-3.負荷を掛けてテスト

多くの人がシステムを扱った際にシステムがダウンしないか、何か不具合が起きないか確認します。閑散している時に起きなくても、アクセスが集中した時に起きる不具合も有ります。それを防ぐために仕様で決められている最大値の負荷（できれば＋α）を掛けてテストしましょう。

4.結合テストで失敗を避けるためのポイント

4章では結合テストの実施に当たって押さえておきたいポイントを紹介します。

4-1.システムを利用する環境と同じ環境でテストする

開発したシステムを利用する環境と同じ環境でテストすることが重要です。そうすることで、より精度の高い結合テストを実施することができるでしょう。環境としては以下のことを指します。

端末（PC、モバイル、iPadなど）
OSの種類/バージョン
ブラウザの種類/バージョン
システムを活用する時間　など

4-2.データベースを直接修正しない

単体テストでは何かエラーが発生した際に、データベースを直接修正するケースが多いですが、複数モジュールの影響が生じる結合テストではデータベースを直接修正するのは避けましょう。直接修正したことで、その修正によりこれまで問題なかった箇所も含めて多くのエラーが発生する可能性があります。最悪な場合、テスト全体を一からやり直すことがあります。テストテロにならないように、データベースのテストデータをいじって動作を確認してから反映させるようにしましょう。