ソフトウェア開発では、開発フェーズによって単体テスト、結合テスト、システムテストなどタイプの異なるテストが実施されます。今回は、その中から結合テストについて、その目的やアプローチ、具体的な手法などをご紹介します。
結合テスト（IT）とは？
「結合テスト」は、「統合テスト」、「IT（Integration Testing）」とも呼ばれ、単体テストを行ったモジュールやコンポーネントを結合した際に、意図したとおりに動作するかを確認するテストです。ウォーターフォール型ソフトウェア開発のV字モデルでは、「基本設計/機能設計」に対して実施するもので、設計を検証するテストとも言えます。
結合テストの種類
結合テストは、結合する対象により以下のようなテストに分けられます。
| テストの種類 | 内容 |
|---|---|
| モジュール間結合テスト | モジュールを結合させた際に意図したとおりに動作するかを検証 |
| サブシステム内結合テスト | サブシステム内の機能を結合させた際に意図したとおりに動作するかを検証 |
| サブシステム間結合テスト | サブシステム同士を結合させた際に意図したとおりに動作するかを検証 |
| 外部システム結合テスト | 外部システムと結合した際に意図したとおりに動作するかを検証 |
結合する対象によって、「内部結合テスト（内結）」、「外部結合テスト（外結）」と呼ばれることもあります。ただし、どこまでを内部、どこから外部とするかはプロダクトによって異なり、モジュール間結合を内部結合テスト、サブシステム間結合を外部結合テストと呼ぶ場合や、誰が主体となって実施するかによって内部結合テスト、外部結合テストを切り分けるケースなどがあります。
このように、「何を結合してテストするか」はプロダクトごとに異なり、その呼び方も様々です。結合テストはテスト対象の決定が難しく、プロダクトごとに開発チーム内で確認をとりながら、テストの対象範囲を決定する必要があります。
結合テストのアプローチ
では、結合テストの進め方を具体的にみていきましょう。
結合テストは、大別すると「増加テスト」と「非増加テスト」の2つのアプローチで行われます。増加テストには「トップダウンテスト」や「ボトムアップテスト」、トップダウンとボトムアップを同時並行的に行う「サンドイッチテスト」などがあります。一方、非増加テストはビッグバンテストとも呼ばれ、増加テストとは全く異なるアプローチでテストを行います。
なお、結合テストは、開発途中のモジュールに対してテストを行う場合があり、単体テストと同様に「スタブ」や「ドライバ」が必要になる場合があります。スタブは下位モジュールの代わりとなるもの。ドライバは上位モジュールの代わりとなります。
トップダウンテスト
上位のモジュールから下位のモジュールへとテストを行う方式です。といっても、ピンと来ない人も多いのではないでしょうか。
上位モジュールはシステムの階層構造の上位に位置するモジュールで、システムに常駐してシステムの状態を把握しながら下位モジュールを呼び出す、重要な役目を担います。下位モジュールは上位モジュールに呼び出されたときにその機能を実行する単機能を持つモジュールで、上位モジュールに下位モジュールが複数つながってシステムを構成している状態を想像してみてください。
トップダウンテストは、この重要な上位モジュールをまず呼出し、そこから下位のモジュールを呼び出すテストを行うため、重要なモジュールの不具合を早期に発見できます。また、たくさんの下位モジュールを呼び出すテストを行うことで上位モジュールのテストを繰り返し行うことになり、重大な不具合を見つけやすいというメリットがあります。
ただし、結合テスト実施の段階で下位モジュールが完成していない場合は、スタブを作る必要があり、未完成の下位モジュールが多いとその作成に時間がとられてしまうというデメリットもあります。
ボトムアップテスト
ボトムアップテストは、トップダウンテストとは逆に下位モジュールのテストを行い、問題がないことを確認してから上位モジュールと結合してテストを実施していきます。
下位モジュールからテストをしていくことから、開発の初期段階で開発とテストを同時に進めることが可能で、テストケースやテスト仕様書の作成、結果のチェックが簡単に行えます。また、モジュール単体の機能を十分にテストできるというメリットもあります。
しかし、重要な役割を担う上位モジュールとの結合テストを最後に行うため、結合テストの最終段階で大きな不具合が発覚する可能性が高い方法です。下位モジュールのテスト段階で上位モジュールがまだ開発途中の場合は、ドライバを準備する必要もあります。
ビッグバンテスト
モジュールの単体テスト終了後に、すべてのモジュールを結合してテストを行うアプローチです。すべてのモジュールが開発された後に行うため、スタブやドライバを準備する必要がないというメリットがあります。ただし、不具合が発覚した場合、原因の特定が難しいというデメリットがあるため、主に小規模な案件でのみ使用される手法です。
結合テストの実施方法
結合テストの主な方法として、「インターフェーステスト」と、「ブラックボックステスト」の2種類があります。
インターフェーステストは、結合したモジュール間のインターフェースに着目したテストで、機能やモジュール間でデータを適切に受け渡しできるかを確認します。
ブラックボックステストは、データの入力と出力に着目したテストで、結合テストでは結合したモジュールに対して、その内部構造を考えずに入力に対して正しい出力が得られるかを確認します。以下で、代表的なブラックボックステストの技法を紹介します。
ブラックボックステスト技法1：同値分割（同値クラス）
同値分割（同値クラス）テストは、入力・選択対象を同じ動作をする条件の集まりとしてクラス化（パーティション化）し、それぞれのクラスに対してテストを行う技法です。
例えば、以下のように同じ処理結果となる年齢の集まりを「未成年」「現役」「高齢者」という3つにクラス化し、それぞれの有功値内から任意の値を1つ選択してテストを行います。
- 0～19歳：未成年
- 20～64歳：現役
- 65歳～：高齢者（前期後期高齢者）
各クラスの代表値でテストして欠陥が見つかれば同値クラス内の他の値でも同じ欠陥が見つかり、欠陥が見つからない場合は同値クラス内ではその欠陥は見つからないだろうという考え方で行われるテストで、テストを効率的に実施する代表的な技法のひとつです。
ブラックボックステスト技法2：境界値分析
境界値分析は、判定の境界値に注目して行うテスト技法です。プログラムでは、「＞」と「＝＞」を間違えるというケアレスミスは起こりやすく、このミスが発生した場合の影響は大です。
コードの記述にケアレスミスがなかったとしても、仕様の記述にある「以上」「以下」「未満」「より小さい」「より大きい」などの表現が間違って解釈されると、仕様にはない動作をするソフトウェアが作られてしまうことになります。このように境界値には間違いが混入しやすく、境界値をテストすれば、このような間違いがないことが確認できます。
同値分割で示した例の場合は、「未成年」「現役」「高齢者」の境目となる
0、19、20、64、65
の5種類を境界値としてテストします。
ブラックボックステスト技法3：デシジョンテーブル
例えば、以下のように複数の条件の組合せでソフトウェアの動作が決まるシステムがあるとします。
- 会員であるか未会員であるか
- 割引クーポンを所持しているか
- 利用日が割引デーか
これらの条件の組合せで割引率が変わる場合、その条件をデシジョンテーブルという表を使ってもれなく洗い出し、テスト条件を整理するテスト技法が「デシジョンテーブルテスト」です。デシジョンテーブルを使うことで、組合せが整理できるだけではなく、仕様上ありえない組合せを見つけることもできます。
<参考>
