結合テストとは何か？ソフトウェアのテストの目的と進め方を解説
結合テストの概要
結合テストとは、単体テストが完了したプログラムを組み合わせ、動作を確認するテストのことです。
システム開発のVモデルに照らし合わせると、結合テストは外部設計で考えた機能が、すべて実現できているかをチェックする段階です。
今回はこの結合テストについて解説していきます。
結合テストの目的
結合テストでは、単体テストが終了したすべてのモジュールを接続して、アプリケーションとしてのテストを行います。テストの観点としては、モジュール間のデータの受け渡しに問題がないか、また、アプリケーションのすべての機能が正常に動作しているかの確認になります。
この段階で確認すべき機能をすべて洗い出し、外部設計書に基づいたチェックシートを作成します。
チェックシートに基づいて１つ１つ動作確認を行い、正常動作することが確認出来れば、チェックシートの消込を行います。
チェックシートの消込がすべて完了することにより、結合テストによる「要求された機能はすべて正常に動作しています」と言うことができるでしょう。
結合テストの進め方
１．結合テスト開始条件
すべてのモジュールの単体テストが完了していることを確認します。
単体テストが不十分な状態で結合テストを開始した場合、結合テストで不具合が多く発生したり、不具合の原因調査に時間がかかったりするなど、単体テストで省略した時間の何倍もの遅れが出てしまいます。
２．モジュール同士の結合開始
結合テストはモジュールを結合した状態でテストを行います。このとき、最上位モジュールから下位モジュールへと順番に結合を増やしていく方法を「トップダウンテスト」といい、逆に最下位モジュールから上位モジュールへと順番に結合を増やしていく方法を「ボトムアップテスト」といいます。
ただし、通常の開発プロジェクトでは、限られた時間内で結合テストを実施しなければならないため、担当者のスケジュールを調整し、可能なところからモジュールを結合していくこともよくあります。
３．アプリケーションの機能テスト
すべてのモジュールが結合されるとアプリケーションとしての動作が始まりますので、作成したテストケースを使って機能テストを行います。この機能テストからは、プログラマーではなく、テスターによって実施するほうが望ましいです。それは作成した設計書のとおりに動作するか客観的なテストを行うためです。また、各テストフェーズの中で、この機能テストが最も不具合が出やすく、プログラマーは不具合修正に専念できる、というメリットもあります。
なぜ「インターフェース」が大事なのか
ソフトウェア開発では、モジュールのインターフェース部分に不具合が集中することがよくあります。
インターフェースとは、モジュール毎に別のプログラマーが担当することがあり、担当者間のインターフェースとも言えます。外部設計によってモジュール間のインターフェースが設計されますが、設計書に曖昧な部分が残っていると、それぞれの担当者の解釈に齟齬が生じ、結合できないモジュールが作成されることがあります。
事前の対策としては、まず外部設計書の作成、レビューで、モジュール間のインターフェース部分の精度を上げることが大事です。
たとえば、設計書の書式を決めておき、開発メンバー全員が理解しやすい状態にしておくと効果的です。また、単体テストのときに、モジュール間で受け渡すサンプルデータをやりとりすることで、インターフェースの仕様の確認もできます。
テスト設計がカギとなる
結合テストの成果物は機能テストが完了したアプリケーションとなります。その品質を決めるものは何でしょうか？
それは機能的な安定性です。つまり、残っている不具合の少なさが評価基準となりますので、どれだけ十分なテストができるかがポイントになります。
この十分なテストとは、単に時間をかけるだけでできるものではありません。そもそも開発プロジェクトは、通常そのような有り余った時間を持っていません。
そのため、限られた時間の中で精度の高いテストを行うためには、最適なテストケースが必要です。したがって、結合テストの成果物の品質を決めるものは、テスト設計となります。しかし実際には、テスト設計の担当者が頭の中で設計をしながら、テストケースを作成していく、という方法が多いようです。テストケースの作成は設計作業ではなく、実装作業（プログラムで言えばコーディング）になりますので、テストケースを書き始める前に、しっかりテスト設計を行っていきましょう。そして、そのテスト設計書でレビューを行うと、テストケースのレビューよりも格段に効果があります。
バグ管理を始めよう
ソフトウェア開発のプロジェクトでは、バグ管理は避けて通れません。
バグを発見して、すぐさま修正できれば不要かもしれませんが、実際には、バグの症状をプロジェクトメンバーと共有して、担当者をアサインし、原因調査、対策、修正レビュー、などを経てひとつのバグ対策が完了します。
また、開発規模が大きい場合には、数百ものバグが発生することも珍しくありませんので、プロジェクトとしてしっかりバグ管理を行わないと、発見したバグをひとつ残らず確実に対策することができません。
では、バグ管理はいつから始めればよいのでしょうか。それはすべてのモジュールの結合ができた後、アプリケーションとしての機能テストの開始から始めるのが一般的です。
バグ修正では何を修正するのか
バグ修正で最も大事なことは、バグの原因を究明し、修正することです。
バグはひとつの症状から発見されます。そして、ひとつのバグには、いくつもの症状があることもあります。
仮に、バグの対策として、原因ではなく、ひとつの症状の対策を行った場合には、他の症状は対策されずに残ることもありますし、そのときには症状は残っていなくても、その後のプログラムの変更によって、あらたなバグが発生することもあります。
そのため、バグが発見されたときには、その原因調査が重要になります。
例えば、モジュール間のインターフェース部分でのバグの場合、どちらのモジュールのバグなのか、正しく判断しなければなりません。ときには、外部設計まで戻って、修正箇所を決めなければなりません。
開発プロジェクトの大きな山
開発プロジェクトをスケジュール進捗の観点から見ると、結合テストが大きな山であると言えます。機能テストの結果は、この前工程である外部設計、詳細設計、開発、単体テストの品質がそのまま現れるからです。ここまでの工程で、必要な作業を省略することでスケジュールに間に合わせていたときには、バグの大量発生という状況に陥るかもしれません。失敗するプロジェクトの多くは、この結合テストフェーズを乗り切ることができず、スケジュール変更を要求することになります。
結合テストをスケジュールどおり完了させるためには、当然、前工程の品質を上げることが重要です。時間切れになったから、次の工程を進める、ということは行わず、各工程の成果物が品質の基準を満たしていることを確認して、次の工程に進めます。
もうひとつ、結合テストでのバグ対策の進捗管理も大事です。機能テストが開始されてからは、日々のバグ発生状況、バグ対策状況をグラフ化することで、スケジュールどおりにバグ発生が収束し、バグ対策が完了できるか、の状況を可視化することができます。