システム開発の結合テストとは？実施方法やテストのポイントを紹介

本ブログでは、単体テスト後に実施する「結合試験」についてご紹介します。まずはテストの種類・実施方法について説明し、実施上のポイントを解説します。今回はテスト未経験者の方にもわかりやすく、図解を用いて説明します。

テスト仕様書・計画書作成の方法やガイドをまとめた資料はこちら。 巻末に項目のサンプルも用意しています。

結合テスト【integration testing/統合テスト】とは、システムやソフトウェアの検証手法のひとつであり、個々のモジュール（部品・機能）での単体テスト後に実施されます。

その名の通り、複数のモジュールを組み合わせた上でシステムに不具合がないかを検証します。

結合テストは主に、モジュール間の接続部分（インターフェース）を対象範囲とします。
検証方式は、インターフェースが正常に機能しているかを確認するケースと、結合した状態で外部から観察し、一体として正常に機能するかを確認するケースがあります。

結合テストは、テスト対象を単体ではなく独立したひとつのシステムとして包括的に捉えた、ユーザビリティ重視の検証方法です。

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

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

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

ここからは、各種類のテスト内容について解説します。

インターフェーステストとは、別称「連結テスト」とも呼ばれます。
インターフェースとは主に、「異なるモジュール（備品・機能）の接続時に、データや信号のやり取りを仲介する回路・手順・規約などを定義したもの」を指します。

インターフェースは「ハードウェアインターフェース/ソフトウェアインターフェース/ユーザーインターフェース」の３つに大別されます。

インターフェーステストでは、異なる個々のモジュール間でのデータの引渡し・連携などが、仕様書通りに不具合な正常に動作しているかを検証します。

業務シナリオテストとは、システムの動作を想定し仕様書を基に行うテストです。検証内容は、システム・業務内容によって異なります。

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

以上をふまえ、業務シナリオテストでは、操作上でのイレギュラーケースを想定した検証が必須です。

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

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

以上をふまえ、次は「結合テストの実施方法」について解説します。

結合テストの進め方には、以下の方式が存在します。

●代表的な結合テストの検証方式

• トップダウンテスト
• ボトムアップテスト

ここからは、「結合テストの実施方法」についてそれぞれご紹介します。

トップダウンテストは、外部から初めに呼び出される最上位モジュールから結合テストを開始し、下位に向かって順次検証を進めるテスト方法を指します。具体的には、上記モジュールに応じたテストドライバ・スタブを用いた上で実行し、動作検証を実施します。

テストドライバ： テスト対象のソフトウェアを呼び出し、テストを実施するプログラム。

スタブ： 呼び出し先における下位モジュールの代用となるモジュールのこと。

トップダウンテストのメリット・デメリット

●メリット

• 最上位モジュールからテストを行うため、プログラム機能の抜け漏れを検出しやすい
• 使用頻度の高い上位モジュールの信頼性向上に寄与する

●デメリット

• 上位モジュールの検証完了後に下位モジュールの開発工程に入るため、プログラミングとテスト作業の同期が困難
• テストごとに、スタブを作成し続けることが必要

ボトムアップテストは、プログラム階層構造における最下位モジュールから結合テストを開始し、上位に向かって順次検証を進める方法です。
上記モジュールに応じたドライバを用いて、その動作が正常かを検証します。

ボトムアップテストのメリット・デメリット

●メリット

• プログラムが親課題となり、枝分かれした別のテスト作業との同時進行が可能
• プログラミングに際しても下位モジュールから作成後、ボトムアップテストを実施することで、プログラミング後に素早くテストを実施できるため、効率的なプロジェクト進行が可能

●デメリット

• 全体が完成するまで、プログラムが正常に動作しているか分かりにくい
• 終盤に不具合・ミスが検出されて、手戻りが発生するリスクが高い
• テストを実施するために、テストドライバを作成し直す必要がある

つぎは、「結合テスト実施のポイント」をご紹介します。

結合テストは、開発プロジェクト・システムの規模により、用いる種類や実施方法が異なる検証方法です。実施に際しては、以下のポイントが重要です。

結合テスト実施時の大切なポイント

• 余裕をもってテストのスケジュールを組む
• システムを利用する環境と同じ環境でテストをする
• DBのデータを直接書き換えない

ここからは上記をそれぞれ解説します。

１つ目のポイントは、結合テスト実施時に「予め余裕のあるテストスケジュールを組むこと」です。

結合テストは、単体テストにて検証をクリアしたモジュールを対象範囲とします。
そのため、テスト設計ミスや単体テストにおけるテストケースの抜け漏れなど、結合テストを開始してから不具合・ミスが発覚することも少なくありません。

また、結合テスト工程では、クライアント側の仕様変更・機能追加などの依頼により、とっぱつてきな手戻りの工数が発生する場合もあります。尚、このようなイレギュラー対応の発生によるテストの遅延は、プロジェクト全体のスケジュール変更・遅延にもつながるため、注意が必要です。

突発的な仕様変更などに対応できるよう、余裕のあるテストスケジュールを組みましょう。

２つ目のポイントは、結合テスト実施時に
「システムを利用する環境と、同じ環境でテストすること」です。

結合テストでは、できる限り本番環境と同様の利用環境することが重要になります。

理由としては、開発システムを利用するユーザー端末・ブラウザなどにおいて、種類（chromeもしくはInternet Explorer）によって操作ができたり、できなかったりといった利用上の問題が発生する場合があるためです。

これらを留意し、テストを行うことで同じサーバ・ミドルウェアを活用し、バージョンも同じであることで、より質の高いテスト実行が可能となります。

また、テスト環境だけでなく、用いるデータやスケジュールも本番環境と揃えましょう。

３つ目のポイントは、結合テストにおいては「データベース（以下、DB）上のデータを直接書き換えない」という点です。

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

理由としては、テスト環境のDBを直接編集してしまうことで、必要なデータの削除や、書き換えミスによる不正データ作成などのヒューマンエラー発生リスクが高まるためです。
これらの問題が発生した場合、テスト結果の信頼性・妥当性が低下するだけでなく、テスト全体のやり直しなどの大きな時間的ロスが発生してしまうため、注意しましょう。

これらの対策としては、データ編集の権限を予め限定するなどの方法が有効です。
高品質なテスト及び製品・サービスを担保するためにも、テスト環境におけるDBを直接編集することは避けましょう。

今回は「結合テストとは何か？」について、種類・実施方法・実施時の注意点を整理し、ご紹介しました。

ご紹介したポイントをおさえ、正しい手順でテストを行うことで、インターフェースやシステムの操作といった部分の品質担保を可能にします。

本記事を参考に、プロジェクトに応じた結合テストの種類・実施方法の選定にお役立ていただければ幸いです。