結合テストとは？目的・単体テストとの違いと種類・実施時の3つの注意点

結合テストとはソフトウェアテストの工程の1つで、一般的に単体テストの後に実施されるテストです。

単体テストはモジュールごとにテストするのに対し、結合テストは複数のモジュールを組み合わせて動作確認を行います。

本記事では、結合テストとは何か、目的や重要、単体テストとの違いを解説していきます。

記事の後半では結合テストの主な種類や実施するときに心掛けておくべきポイントについても解説しますので、ぜひ最後までご覧ください。

もくじ

1. 結合テストとは？
   1. 結合テストとは
   2. 結合テストの目的
   3. 単体テスト（ユニットテスト）との違い
2. 結合テストの主な4つの種類
   1. インターフェーステスト
   2. ブラックボックステスト
   3. シナリオテスト
   4. 負荷テスト
3. 結合テストの実施方式
   1. トップダウンテスト
   2. ボトムアップテスト
   3. ビッグバンテスト
4. 結合テストの実施で注意すべき３つのポイント
   1. テストスケジュールに余裕を持たせる
   2. データベースのデータを直接書き換えない
   3. 本番に近い環境でテストをする
5. まとめ

1．結合テストとは？

結合テストとは、ソフトウェア開発において重要となるテスト工程の一つです。統合テストやコンポーネント統合テスト、ユニット統合テストとも呼ばれます。

具体的な概要や目的、他テストとの違いについて解説します。

1-1　結合テストとは

結合テストとは、複数のモジュールを組み合わせて動作確認をするテストです。

具体的には、モジュール間のインターフェースの構造自体に問題がないか、モジュールを結合した状態でデータのやり取りや動作が適切に行われるかなどについて確認します。

JSTQB「テスト技術者資格制度Foundation Level シラバスVersion 2023V4.0.J02」では以下のように説明されています。

結合テストは、基本設計に対して設計を検証するテストで、「IT（Integration Test）」や「JT（Joint Test）」とも呼ばれることもあります。

ソフトウェア開発の手法の一つであるウォーターフォール型V字モデル（下図）では、単体テストの後に実施されます。

1-2　結合テストの目的

結合テストを実施する目的は主に以下の5つです。

単体テストで問題がなかったモジュール同士でも、組み合わせてみると動作不良などの不具合が見つかることがあるため、結合テストは極めて重要なテストです。

実際にモジュール同士が結合した際の挙動が、仕様書通りに機能しているか等を確認するためにも、様々なパターンの結合テストを繰り返す必要があります。

また、結合テストは比較的小規模から行われるため柔軟に組み合わせることが可能です。

そのため、広範囲に渡って実施されるシステムテスト・受入テストよりもバグや不具合の発生個所・原因が特定しやすくなります。

結合テストの段階で可能な限りバグ・不具合を対処しておくことで、後の「システムテスト」「受入れテスト」へと円滑に繋げることができます。

1-3　単体テスト（ユニットテスト）との違い

結合テストと単体テストの大きな違いは「テストを実行する範囲」です。具体的には以下の通りです。

単体テスト(ユニットテスト、コンポーネントテスト)

システムの最小単位に近いひとつの機能・画面に対してテストを実行して、個別に動作の確認を行う。

結合テスト(ユニット統合テスト、コンポーネント統合テスト)

単体テストを経た構成要素を結合し、複数の機能・画面に対して、機能間・画面間・データ連携等の動作確認を行う。

「単体テスト」は個別のモジュールに対して動作確認を行います。

一方で「結合テスト」では、単体テストで正常に動作したモジュールを、複数組み合わせて動作確認を行います。

2．結合テストの主な4つの種類

主な結合テストとしては、インターフェーステスト、モジュールを結合した状態でのブラックボックステスト、シナリオテスト、負荷テストの4種類が挙げられます。

以下でそれぞれの特徴について見ていきましょう。

2-1　インターフェーステスト

2-2　ブラックボックステスト

ブラックボックステストとは、テスト対象の内部構造を把握せずに、入力に対して正しい出力が得られるかを確かめるテストです。

結合テストでは、単体テストを終えたモジュール同士を結合してブラックボックステストを実施し、モジュールの動作順序やタイミングを含めて動作確認を行います。

2-3　シナリオテスト

シナリオテストとは、実際の利用シーンやシナリオを想定して動作の確認を行うテストです。

実利用上の妨げになるような不具合の発見や、機能やシステムの連携を妨げる不具合を発見する目的で実施されます。

実際の運用時に出てくるであろう問題の洗い出しを行うために、正常系のテスト以外に異常系（イレギュラーな動作など）のテストも実施することがあります。

シナリオテストの基本の「き」[入門編]

ソフトウェアテスト技法の一つ「シナリオテスト」について解説しているミニ冊子です。「そもそもシナリオテストとは何なのか」から解説している入門編となります。

資料ダウンロード

2-4　負荷テスト

負荷テストとは、システムが実際の業務に耐えられる処理能力を持っているか確認するために行うテストです。

別名で「ストレステスト」や「ラッシュテスト」とも呼びます。システムに対して想定を超える負荷がかかると異常停止やパフォーマンスの低下などが起こる場合があります。

そこで、あえて大量のアクセスを行ったり、想定外の環境（高温状態など）で運用を行うなどして反応を検証します。

3．結合テストの実施方式

結合テストは、「増加テスト」と「非増加テスト」の2つのアプローチに大別することができます。

増加テストとは、テストが完了したモジュールに未テスト状態のモジュールを追加しながら、徐々にテストを進めていくアプローチです。

増加テストにはトップダウンテストとボトムアップテストがあります。両者の違いは、上位モジュールからテストを行うのか、それとも下位モジュールから行うのかという点です。これに加え、両者を同時並行で実施する「サンドイッチテスト」が挙げられます。

一方、非増加テストとは、モジュールを結合して一気に実施するテストです。これを「ビッグバンテスト」と呼びます。

それぞれ詳しく解説していきます。

3-1　トップダウンテスト

トップダウンテストとは、上位モジュールを呼び出した後に下位モジュールヘと移行してテストを進めていく方式です。

上位モジュールから順番にテストをしていくことで、致命的な不具合を早期発見しやすいというメリットがあります。

結合テストはシステムテストを行う前段階に実施されることが多く、テスト対象以外のモジュールが開発途中である場合もあります。

テストに関わる全ての下位モジュールの開発を待たずに結合テストを実施しなければならない事態も避けられません。

このような場合には、「スタブ」と呼ばれる下位モジュールの機能を代替するモジュールを作成し、テスト対象を動作させるために必須なモジュールのみを呼び出してテストを行います。

3-2　ボトムアップテスト

ボトムアップテストとは、プログラムの下位階層にあるモジュールから優先的にテストを進めていく方式です。

下位モジュールが検索や計算処理などシステムの根幹に関わる機能を担う場合、優先度の高い機能から順番にテストを進められるメリットがあります。

トップダウンテスト同様、上位モジュールのインターフェースやメイン機能が完成しないうちにテストを行わなければならない場合があります。

このように上位モジュールが開発しきれていない場合には、「ドライバ」と呼ばれる上位モジュールの機能を代替するモジュールを作成し、下位モジュールの動作に必要な値を出力させてテストを進めます。

3-3　ビッグバンテスト

ビッグバンテストは、別名で「一斉テスト」、「一斉結合テスト」とも呼ばれる結合テストの実行方法の一つです。

単体テストが終了した複数のモジュールをすべて結合してテストを行います。

不具合が発生した箇所の特定が難しいデメリットがあることから、小規模だったり単純なシステムに適している手法であるといえます。

4．結合テストの実施で注意すべき３つのポイント

開発規模や対象システムなどによって、結合テストの種類や実施方式は変わってきます。

しかし、結合テストの内容にかかわらず、共通して気を付けたいポイントもあります。

この章では、結合テストを実施する際に注意すべき3つのポイントをご紹介します。

4-1　テストスケジュールに余裕を持たせる

結合テストを実施する際は、テストスケジュールに余裕を持たせましょう。

結合テストは単体テストをクリアしたモジュールに対して実施されますが、設計上のミスや単体テストのケース漏れなどの理由から、統合テストを実施して初めて問題が発覚することも少なくありません。

また、顧客の要求の変更や機能追加の依頼に応じて、仕様変更を行うことも考えられます。この場合、手戻りによって大きな時間的ロスが発生します。

このように、結合テストの工程では、突発的なトラブルが起こりやすいという特徴があります。

結合テストの遅延はプロジェクト全体の遅延につながるため、余裕をもってテストスケジュールに余裕を持たせることが重要です。

4-2　データベースのデータを直接書き換えない

結合テストでは、データベースのデータを直接書き換えないようにしましょう。

単体テストでは、データ準備コストを削減するため、データベースを直接編集してテストデータを作成するケースがよく見られます。これは、モジュールやメソッド単位での動作確認を行う際には有効かもしれません。

しかし、複数機能やモジュール間のデータのやり取りについて確認する結合テストでは推奨できません。

テスト環境のデータベースを直接編集してしまうと、人的ミスで必要なデータを削除してしまう、システムでは作成しえない不正データを作ってしまうリスクがあります。

リスクが現実化した場合、テスト環境下で行ったテスト結果の信頼度が下がり、テストのやり直しが発生することも。

ソフトウェアの品質を確実に担保するため、テスト環境のデータベースの書き換えは避けるようにしましょう。安易にデータを編集できないように権限を設定することも1つの方法です。

4-3　本番に近い環境でテストをする

結合テストは、できるだけ本番環境に近いところでテストを実施しましょう。

なぜなら、実際に起きる不具合は環境に影響されることも多いからです。

例えば、以下のような細かい部分も再現するとより効果的なテストを行うことができます。

• システムに利用するOSや端末などを揃える
• 必要な装置やソフトウェアを用意する
• 実際に利用する時間帯でテストする

同じ環境でしか発見できない問題を事前にチェックするためにも、本番環境に近づけてテストを行いましょう。

まとめ

ソフトウェアテスト工程の一つである「結合テスト」とは、モジュール間のインターフェースの構造自体に問題がないか、モジュールを結合した状態でデータのやり取りや動作が適切に行われるかなどについて確認するテストです。

単体テストで問題がなかったモジュール同士の動作不良や細かなバグ・不具合を見つけ、システムテストなど後工程にスムーズに進めるためにとても重要な工程になります。

結合テストには、複数のテスト手法がありますが、いずれもユーザーの利用状況を考慮した上で実施することが大切です。

今回ご紹介した内容を踏まえて、今一度チーム内での結合テストのあり方を再考してみてはいかがでしょうか。