「ホワイトボックステスト」は、テスト対象の内部構造に着目して実施する基本的なテスト手法です。
本稿では、ホワイトボックステストとは何かと「ブラックボックステスト」との違いについて解説していきます。さらに、ホワイトボックステストのメリット・デメリットや、ポイントについてもご紹介。
ぜひ最後までご覧ください。
ホワイトボックステストとは
ホワイトボックステストとは、テスト対象の内部構造に着目して実施するテスト手法です。
処理の順序や分岐、データの流れなど、プログラムレベルの詳細を把握したうえで、それらが設計どおりに動作するかを検証します。
ホワイトボックステストのテスト対象となるのは、主に個々のプログラム要素（関数やメソッドなど）です。そのため、ソフトウェアをプログラムレベルで理解する開発者が主に担当します。
主な実施タイミングは、プログラム実装後の「単体テスト」です。
ブラックボックステストとの違い
ホワイトボックステストと対比される「ブラックボックステスト」との違いを押さえておきましょう。
ブラックボックステストとは、テスト対象を外から見たときの振る舞いに着目して実施するテスト手法です。つまり、プログラムの内部構造には着目しません。
ブラックボックステストでは、仕様書や要件定義書といったドキュメントで定義された入力・出力を踏まえて実施します。
ある入力（データや条件）をテスト対象に与えた際に、仕様で定義されたとおりの出力（データや挙動）となるかを検証するのが基本です。
一方、ホワイトボックステストではテスト対象の内部構造を踏まえ、プログラム内部の処理やデータの流れが設計レベルで想定どおりかを検証します。
ホワイトボックステストは主に開発者視点ですが、ブラックボックステストはユーザー視点で実施することもできます。
しかし、どちらもソフトウェアの品質保証には欠かせず、両方を組み合わせて実施することが重要です。
ホワイトボックステストを実施するメリット
ホワイトボックステストを実施するメリットは、主に次の2つです。
2-1 プログラムレベルの問題を検出できる
ホワイトボックステストを実施することで、プログラムレベルの問題を検出できます。
ブラックボックステストだと内部構造に問題があっても、入力に対する出力結果が設計仕様どおりであれば問題は発見できません。
その点、プログラムレベルで検証するホワイトボックステストであれば、そのような問題もしっかり検出できます。処理の順序やデータの扱い方などを含め詳細に検証するため、発生条件が限定的なバグや、潜在的な問題なども検出できます。
2-2 早期段階で問題を検出できる
ホワイトボックステストは通常、単体テストや結合テストといった実装に近い段階で行われます。
そのため、開発の早期段階でプログラムレベルの問題を検出し、対処することができます。
仮に問題がシステムテストや運用段階で発覚すると、修正の影響範囲が広がり、手戻りが大きくなります。
しかし、ホワイトボックステストによって早期段階でバグに対処できれば、修正コストを最小限に抑えられます。
ホワイトボックステストを実施する注意点
ホワイトボックステストには、メリットだけでなく注意点もあります。ホワイトボックステストを実施する注意点は、主に次の2つです。
3-1 プログラミングの専門知識が必要
ホワイトボックステストを実施するためには、プログラムの内部構造を理解できるだけの専門知識が必要です。
開発言語の文法やアルゴリズム、データ構造などへの理解がないと、正確な実施は難しいでしょう。専用の開発ツールを使う場合も多く、その使い方も知っておく必要があります。現実的には、開発者以外が実施するにはハードルが高いといえます。
3-2 仕様や設計レベルの問題は検出が難しい
ホワイトボックステストではプログラムの内部構造を検証するため、仕様や設計レベルの問題を検出することは難しいです。
たとえば、関数の内部が設計どおりだと示せても、その設計が仕様にマッチしているか、といった観点までは検証できません。
そのため、ホワイトボックステストだけでソフトウェア全体の品質は担保できず、ブラックボックステストとの併用が不可欠です。コストの割に検出できる問題が限定的という課題もあります。
ホワイトボックステストに用いられるテスト技法
ホワイトボックステストの実施においては、テスト技法の活用が欠かせません。ここでは、ホワイトボックステストにおいて役立つテスト技法2つを紹介します。
4-1 制御フローテスト
「制御フローテスト」は、テスト対象における制御の仕方に焦点を当てる技法です。
「フローチャート」によりデータの制御方法を可視化し、全制御を網羅するように実施します。
詳細設計書などにフローチャートが記載されている場合は、それを利用することもできます。
制御フローテストでは、特に条件分岐を適切に網羅することが重要です。
主なカバレッジ基準として、次の3種類があります。
下に記載されたものほど粒度が細かくなり、より多くのテストケースが必要になりますが、その分より厳密な検証ができます。
| 種類 | 概要 |
| 命令網羅 | すべての命令を最低1回は通るようにテストする。 |
| 分岐網羅 | すべての条件分岐の真偽を最低1回は通るようにテストする。 |
| 条件網羅 | すべての条件分岐の組み合わせを最低1回は通るようにテストする。 |
例として、Javaで記述されたテスト対象に、次のような条件分岐があったとします。
「条件Aが真(true)」だと処理1、「条件Aが偽(false)かつ条件Bが真(true)」だと処理2、「条件Aが偽(false)かつ条件Bが偽(false)」だと処理3が実行されます。
| if (条件A) { 処理1; } else { if (条件B) { 処理2; } else { 処理3; } } |
この場合、各カバレッジ基準には次のような違いが生じます。
| 種類 | 概要 |
| 命令網羅 | すべての命令（処理1、処理2、処理3）を最低1回は実行する。 各条件分岐の真偽（true/false）は問わず、3つの処理を通せばよい。 |
| 分岐網羅 | すべての条件分岐（条件Aと条件B）で「真」と「偽」の両方を通す。 この場合、「条件Aが真」「条件Aが偽」「条件Bが真」「条件Bが偽」のすべてを網羅する必要がある。 |
| 条件網羅 | すべての条件分岐（条件Aと条件B）の「真」と「偽」の組み合わせを網羅する。この場合、「条件Aが真かつ条件Bが真」「条件Aが真かつ条件Bが偽」「条件Aが偽かつ条件Bが真」「条件Aが偽かつ条件Bが偽」のすべてを網羅する必要がある。 |
今回の例だと、分岐網羅と条件網羅のいずれも4パターンの実施が必要になるため、結果としてテストケース数に差はありません。
しかし、複雑な条件分岐が発生するプログラムでは、網羅の種類によって最終的なテストケース数も大きく変わってきます。
制御フローテストではカバレッジ基準を決め、それに沿ってすべての制御が設計どおりとなることを検証します。
4-2 データフローテスト
「データフローテスト」は、テスト対象が使用しているデータの流れに焦点を当てる技法です。
具体的には、データを格納する変数の定義→使用→消滅という流れに着目し、適切な変数処理が行われているかどうか検証します。
制御フローと同じように、変数処理の流れをフローチャートなどで可視化することが一般的です。
たとえば定義された変数Aが使用せずに消滅している、といった不適切な変数処理を発見でき、コードの最適化につながります。
データフローテストには、目視や静的解析ツールなどで変数処理の流れを可視化する方法、実際にプログラムを実行しながら変数の使用状況を監視する方法があります。
後者の場合は、プログラムのデバッグに用いられる開発ツールを使用することも多いです。
ホワイトボックステストを成功させるには
ホワイトボックステストを成功させるために、2つのポイントを押さえておきましょう。
5-1 ブラックボックステストとバランスを取る
ホワイトボックステストとブラックボックステストは役割が異なるため、両者のバランスが大切です。
ホワイトボックステストはプログラムレベルの問題を検出できますが、ブラックボックステストは外から見た振る舞いの問題を検出できます。
すべての問題をホワイトボックステストだけで検出することはできません。両者の性質を理解し、適切に使い分けましょう。
5-2 テスト技法への理解を深める
ホワイトボックステストの成功には、制御フローテストやデータフローテストといったテスト技法への理解が欠かせません。
テスト技法への理解が不足していると、テストケースの漏れや工数の増大を招く恐れがあります。
テスト技法に関する解説本や、講座を受講するなど理解を深めていきましょう。
バルテスでは、ブラックボックステストの5つのテスト技法を解説したお役立ち資料を公開しています。
また、バルテスでは、テストに関する幅広い講座をオンラインで提供しています。
ホワイトボックステストの技法を体系的に学びたい方は、こちらもご活用ください。
まとめ
ホワイトボックステストとは、テスト対象の内部構造に着目して実施するテスト手法です。
処理の順序や分岐、データの流れなど、プログラムレベルの詳細を把握したうえで、それらが設計どおりに動作するかを検証します。
ホワイトボックステストを成功させるためには、テスト技法への正しい理解が欠かせません。
ホワイトボックステストを実施する際には、今回の内容をぜひ参考にしてください。