単体テストと結合テストの違い｜目的やテスト方法の種類・注意点を解説！

ソフトウェア開発における「単体テストと結合テストの違い」に焦点を当てます。まずは、両テストの違いについて理解した上で、概要（目的・方法）について詳しく解説。
最後に「テストを実施する上での注意点」について紹介します。

「ソフトウェアテストについてイメージができていない」「単体テストと結合テストの違いを知りたい」という方ぜひご一読ください。

単体テストと結合テストの違いは、「対象範囲」です。
内容は、以下のとおりです。

単体テスト
単体機能（例：画面ひとつ）

結合テスト
別々の機能間、他システム間のデータ・バッチ連携　など

また、結合テストには「内部結合テスト/外部結合テスト」の2段階が存在します。

内部結合テスト
サブシステム内部の機能間の連携を検証するテスト。
結合テストの前半部分。

外部結合テスト
サブシステム内部の機能間の連携と、他システムとの機能連携を検証するテスト。
結合テストの後半部分。

留意点
小規模なプロジェクトでは、外部結合テストが省略されるケースもある。

ソフトウェアテストの質は、品質レベルに直結します。今回の内容を把握し、正確で効率的な単体テスト・結合テスト実現にお役立ていただければ幸いです。

単体テスト【Unit Testing/UT/CT/ユニットテスト】とは主に、開発工程におけるプログラム作成後に実施され、比較的ロジックが小さな単位（最小単位ユニット）をテスト対象とし、個々の機能（モジュール）が正常に動作しているのかを検証します。

では、単体テストは、なぜ実施されるのでしょうか？
次は「単体テストの目的」について、重要性とともに解説します。

単体テストを行う目的は、「対象プログラムを個別に実行し、不具合を除去すること」です。

実施環境を一度整備することで、不具合の修正・確認作業を効率的に進めることができます。

一方で、単体テストは比較的時間や労力、スキルを要します。そのため、万が一簡易的になった場合は「その後の不具合見落とし」や「的確な修正対応ができない」などの不都合が生じる可能性があるため注意が必要です。

次に、「単体テストの方法」について解説します。

代表的な単体テストの方法

• ホワイトボックステスト
• ブラックボックステスト

ここからは単体テストの各方法について説明します。
まずは「ホワイトボックステスト」から解説します。

単体テストのやり方のBlogはこちら

ホワイトボックステストではプログラムの内部構造を理解・意識し、それらが正しく動作しているかを確認します。具体的には、ソースコードの文・分岐・条件などを網羅的にテストします。そのため、実行にはプログラミングに関する知識を要します。

ホワイトボックステストの例

• 命令網羅
• 分岐網羅
• 条件網羅
• 複数条件網羅

ホワイトボックステストのメリット	ホワイトボックステストのデメリット
耐久性やバグなど、網羅的に検証できる 内部処理上の不具合・バグが発見できる テスト項目がまとめやすい	作業工数、コスが多くなりがち ユーザー要求を満たしているかはわからない 仕様の漏れまでは検出不可能

　

ホワイトボックステストは、システムの内部構造を網羅するテストケースに適しています。具体的には、テストケースによるプログラム実行結果をテスト品質の指標とし、その網羅率（カバレッジ）を計測・分析します。

ホワイトボックステストの詳細はこちら

ブラックボックステストではプログラムの内部構造を考慮せず、ユーザー要求を仕様通り満たしているかを確認します。また、テスト項目は仕様書などから洗い出します。

ブラックボックステストの例

• 同値分割法
• 境界値分析
• デジションテーブル

ブラックボックステストのメリット	ブラックボックステストのデメリット
対応可能なテストレベルが幅広い ユーザー要求を満たしているか確認できる 差往査面の良い点・悪い点を洗い出せる	網羅性は高くない 評価ポイントが多くなりがち 内部処理上の不具合を発見しにくい

　

ブラックボックステストは、複数プログラムを組み合わせたシステムの入出力や、ユーザー視点に着目したテストケースに適しています。

ブラックボックステストの詳細はこちら

結合テスト【integration testing/統合テスト】とは、複数のモジュールを組み合わせた上で不具合がないかを検証するテストで、モジュール間の接続部分（インターフェース）を対象範囲とします。

インターフェースが正常に機能しているかを確認するケースと、結合した状態で外部から観察し、一体として正常に機能するかを確認するケースがあります。

また、結合テストには「内部結合テスト/外部結合テスト」が存在します。

まずは、「内部結合テストがなぜ実施されるのか？」についてご紹介します。

結合テストの詳細・Blogはこちら

内部結合テストを行う目的は、「複数の機能・部品が正常に動作するかを調査すること」です。

万が一、内部結合テストが正しく実施されなかった場合、機能やその周辺に問題が残存し、テスト結果の信頼性や品質低下に繋がります。

これらの問題防止や安全性・品質保証の観点から、「内部結合テストによる細部まで内部構造の検証」が非常に重要であると言えるでしょう。

外部結合テストを行う目的は、主に結合テストの後半部分にて「複数の機能・部品（モジュール）が不具合なく正常に動作するかを調査すること」です。
一般的にはサブシステム間の結合テストを、外部結合テストとするケースが多々あります。

外部結合テスト正しく実施されなかった場合、内部結合テストと同じく信頼性や品質低下に繋がります。

次は「結合テストの方法」について紹介します。

結合テストの代表的な種類

• インターフェーステスト
• 業務シナリオテスト
• 負荷テスト

ここからは、各種類のテスト内容について解説します。
以下を参考に、検証すべきモジュールに沿ったテスト実行に繋げましょう。

結合テストのBlogはこちら

インターフェーステストは「連結テスト」とも呼ばれ、インターフェースとは「異なるモジュール（備品・機能）同士の接続部分」です。

異なるモジュール間でのデータの引渡し・連携などが、仕様書通りに正常に動作しているかを検証します。具体的には内部・外部にて以下のテストを行います。

内部結合テスト

• 画面移行
• 画面からバッチの起動
• バッチからバッチへの起動・連携

外部結合テスト

• システム間のデータ送信
• サブシステム間のデータ送信
• 外部から俯瞰した、モジュール間の結合

インターフェーステスト実施上のポイント・注意点

両テストの共通点は、「サブシステムの機能と、連携結果（結合した結果）を確認すること」と言えます。また、テストの実施に際してはインターフェース部分に着目した「テストシナリオ」を要します。

業務シナリオテストは、システムの動作を予め想定し仕様書を基に行います。検証内容は、対象となるシステムや業務内容により異なります。

実施上のポイント・注意点

業務シナリオテストでは「イレギュラーな操作を想定し、網羅すること」が大切です。なぜなら、基本動作は開発工程において何度も確認がなされているため、正常に動作していることがほとんどであるためです。

負荷テストとは、別称「ロードテスト」とも呼ばれ、
開発工程における結合テストの最終工程です。対象システムに対し、通常時や稼働のピーク時に意図的な負荷をかけて性能・耐久性を検証します。

具体的な検証内容は、設計時に想定した動作環境・仕様の範囲内の負荷を用いて検証するケースや、負荷の強度を高めていった場合にシステムの劣化や異状が発生するなどがないか限界値を検証するケースがあります。

実施上のポイントや注意点

負荷テストの効果的な実施に役立つ方法は、以下の通りです。

• 性能テスト （スループット＝単位時間あたりの処理量）
• 性能テスト （応答時間）
• 限界テスト
• 耐久テスト

上記アプローチは完全に別々に実施する必要はなく、システムの状況に応じた組み合わせで実施することが可能です。

最後に「テストを実施するうえでの注意点」をご紹介します。

テストを実施するうえでの注意点

• テストが必要な機能や条件の網羅
• 本番環境と同じ環境でテストを行う
• DBデータは必ずシステム上の機能を利用して変更

ソフトウェアテストに際しては以下内容をおさえ、実行しましょう。

これらが大切な理由としては、「テスト観点の漏れ防止・網羅性向上」が挙げられます。

また、単体テストでは特に、「テスト観点の洗い出し」も重要です。

テスト観点の漏れを防止するためには、プログラムの処理条件をわかりやすく表現できる「デシジョンテーブルの活用」が有用です。さらに要件定義書の作成者（クライアント）やテスト関係者ともレビューを行うと、多角的な視点から洗い出しが可能です。

テクバンでは上記を網羅した専門家による、「ソフトウェアサービス」をご提供しております。
「最終テスト実施に不安がある…」「テスト実行までのノウハウや人的リソースが不足している」といった企業様は、ぜひ一度ご相談ください。

テクバンの「ソフトウェアテスト」とは？

• 専門チームがテスト業務を内部監査
• プロジェクト立ち上げ～品質改善コンサルまで対応
• 徹底したヒアリングで品質業務の最適化

当社在籍のテストエンジニアがお客様のご要望・特性などをヒアリングした上で、効果的なテスト設計～実行までを全面サポートさせていただきます。

この点が大切な理由としては、開発システムを利用するユーザー端末において利用上の問題発生リスクといった利用上の問題が発生する場合があるためです。
（例えばchromeもしくはInternet Explorerによって操作ができた、できないなど）

ここでの「環境」とは具体的に以下を指します。

ミドルウェア
主に、オペレーティングシステム（OS）とアプリケーションソフトの中間に位置。様々なソフトウェアから共通して利用される機能を提供。

サーバ
製品・サービスのユーザー要求に応じた機能やデータなどを提供するコンピュータ及びソフトウェア。

バージョン
ソフトウェアなどについて同名の製品・サービスにおける新旧を区別する番号・符号。

結合テストの前工程である単体テストでは、テストデータを用意する工数削減のため、DBを直接編集しデータを作る場合が多々あります。しかし、複数モジュール間のやり取り・連携を検証する結合テストにおいて、データを直接書き換えることは好ましくありません。

これらの対策としてはシステム上の機能利用の他に、
「データ編集の権限をあらかじめ限定する」なども有効です。

最後までお読みいただき、ありがとうございました。
今回はソフトウェアテストにおける「単体テストと結合テストの違い」に注目しました。

今回ご紹介した各テストのポイントをおさえ、正しい手順でテストを行うことで、インターフェースやシステムの操作・連携といった部分の品質担保に役立ていただければ幸いです。