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

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

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

システム開発における結合テストは、単体テストを完了した複数のモジュールを組み合わせ、それらが連携して期待通りに動作するかを検証する工程です。このテストは、システム全体の品質を確保する上で非常に重要な役割を果たします。

結合テストは、単体テストで確認された個々のモジュールの機能が、統合された環境で互いに正しく連携するかを検証するものです。モジュール間のインターフェース、データ連携、機能連携といった要素を重点的にチェックし、システム全体の整合性を確認します。

結合テストの主な目的は、モジュール間の連携に起因する不具合を早期に検出し、システム全体の品質を向上させることです。これにより、後工程での手戻りを大幅に削減し、開発効率を高めることができます。また、システム全体の信頼性を高め、ユーザーに安心して利用いただけるシステムを提供することが可能となります。

結合テストでは、以下の観点を重視し、多角的な検証を行うことが重要です。

モジュール間のデータの受け渡しが正確に行われているか、データの形式や内容に不整合がないかを確認します。

データが連携先で正しく処理されるか、データの欠損や不正な変換がないかを確認します。

複数のモジュールが連携することで、期待される機能が正常に動作するか、機能間の連携に不具合がないかを確認します。

連携による性能劣化がないか、システム全体の性能要件を満たしているか、負荷テストやストレステストを実施し、性能面での問題がないかを確認します。

連携によるセキュリティ上の脆弱性がないか、不正アクセスやデータ漏洩のリスクがないかを確認します。

モジュール間の連携でエラーが発生した場合に、適切なエラー処理が行われるか、エラーメッセージが適切に表示されるかを確認します。

通常の処理フローから外れた例外的なケースにおいても、システムが正常に動作するかを確認します。

これらの観点を網羅的に検証することで、システムの信頼性を高め、スムーズなシステムテストへの移行を実現します。結合テストは、システム開発における品質保証の要となる工程であり、入念な計画と実施が求められます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

●メリット

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

●デメリット

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

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

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

●メリット

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

●デメリット

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

システム開発におけるテスト工程は、単体テスト、結合テスト、システムテスト、受け入れテストなど、複数の段階に分かれています。それぞれのテストは、目的、対象範囲、実施主体が異なり、システム全体の品質を確保するために重要な役割を果たします。

単体テストは、個々のモジュールやコンポーネントが単独で正しく動作するかを検証するテストです。一方、結合テストは、単体テストを終えた複数のモジュールを組み合わせ、それらが連携して期待通りに動作するかを検証します。

両テストの違いをまとめた記事はこちらにもあります。
単体テストと結合テストの違い｜目的やテスト方法の種類・注意点を解説！

単体テストの観点をまとめた記事はこちら。
単体テストの観点とは

単体テストのやり方をまとめた記事はこちら。
単体テストのやり方と手順

単体テスト：個々のモジュールの機能検証
結合テスト：モジュール間の連携検証

単体テスト：個々のモジュール
結合テスト：モジュール間のインターフェース、データ連携

単体テスト：開発者
結合テスト：開発者、テストエンジニア

システムテストは、完成したシステム全体が要件定義書通りに動作するかを検証するテストです。一方、結合テストは、モジュール間の連携に焦点を当てたテストであり、システム全体の機能検証は行いません。

システムテストについてまとめた記事はこちらにもあります。
システムテストとは？テストの意義や観点、仕様書の書き方について解説！

結合テスト：モジュール間の連携検証
システムテスト：システム全体の機能検証

結合テスト：モジュール間のインターフェース、データ連携
システムテスト：システム全体

結合テスト：統合テスト環境
システムテスト：本番環境に近いテスト環境

受け入れテストは、顧客やエンドユーザーがシステムを実際に使用し、要件を満たしているかを検証するテストです。一方、結合テストは、開発者側がモジュール間の連携を検証するテストであり、顧客視点は含まれません。

受け入れテストについてまとめた記事はこちらにもあります。
システムの受入テストで考慮すべきポイントとは？

結合テスト：モジュール間の連携検証
受け入れテスト：顧客の要件確認

結合テスト：開発者、テストエンジニア
受け入れテスト：顧客、エンドユーザー

結合テスト：技術的な観点
受け入れテスト：業務的な観点

これらの違いを理解することで、各テストの役割を明確にし、効率的なテスト計画を立てることができます。

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

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

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