2025.03.27
ソフトウェアテストの技法の一つである、「ホワイトボックステスト」。
ホワイトボックステストは、プログラムの内部構造を分析するテストのことを指します。プログラムの最小単位であるモジュール一つ一つを対象とした「単体テスト」にて用いられることが多いです。※場合によっては結合テストでも活用されます。
今回は、モジュール単位の機能を解析することができる「ホワイトボックステスト」について、基本から詳しくご説明します。
ブラックボックステストとの違い、具体的な技法やおさえておくべきポイントについても解説しますので、ぜひ最後までご覧ください。
- もくじ
1．ホワイトボックステストとは？
ソフトウェアテストで用いる「ホワイトボックステスト」について基礎的な知識と、ブラックボックステストとの違いを解説していきます。
1-1 ホワイトボックステストとは「内部構造を分析する」テスト
ホワイトボックステストは、ソフトウェアのプログラムを理解した上でプログラムの論理構造が正しいかどうかを解析するテストのことを指します。
主にソフトウェアの最小単位であるモジュール（部品）の1つを対象とした単体テストで用いられることが多いです。
ホワイトボックステストでは、モジュールが設計した論理構造に従って動作するかどうかを検証します。そのため、モジュールの論理構造を正しく把握していることが必須不可欠です。
モジュールの論理構造を正しく把握するには、モジュールの論理構造をフローチャートなどの図表にして表すと良いでしょう。
表に表すことで、テストすべき点が明らかになるだけなく、開発者にとっても、既存の論理構造の修正箇所や修正負担や他モジュールへの影響などが容易に把握でき、適切な修正作業を行えるようになります。
主な種類としては「制御フローテスト」と「データフローテスト」があります。詳しくは2章で解説します。
1-2 ホワイトボックステストとブラックボックステストの違い
ホワイトボックステストと並んで覚えられる「ブラックボックステスト」とは、内部構造を意識せずに行うテストのことです。
要件や仕様書からテストすべき項目を洗い出し、入力情報・出力情報に着目してテストを実施を行います。
また、画面表示のデザインやレイアウトが崩れていないか、使いやすさなど、よりシステムのユーザーの目線に立ったテストを行うことができます。
主なテスト技法の種類としては、「同値分割法」「境界値分析」「ディシジョンテーブルテスト」「状態遷移テスト」「組合せテスト」などがあります。
ブラックボックステストの詳細はこちらの記事をご覧ください。
2．ホワイトボックステストの2つの技法と実施方法
ホワイトボックステストでは主に２つのテスト技法「制御フローテスト」と「データフローテスト」が使われます。それぞれの技法について詳しく解説していきます
2-1 制御フローテスト
制御フローテストとは、1つの処理に対してソフトウェアがどのように動くかをフローチャート図に表し、期待通りの動作をするかを検証する手法です。
この図の中では、if文の条件式や繰り返しのロジックによって指定された処理の流れを図示します。
入力値や条件を組み合わせたときの処理の流れが、設計意図通りに動作するか確認することが、本テストの目的です。
実施方法
1．ソースコードをもとに、フローチャートを書く
ソースコードをもとに、モジュールの論理構造をフローチャートにして可視化します。この時点でテスト対象のモジュールは動かしません。
2．カバレッジ基準を決める
続いてカバレッジ基準を定めます。
カバレッジとは対象のプログラムがどこまでテスト実施されたのかの割合のことです。制御フローテストで着目する要素を選択します。これらを「カバレッジ基準」と呼びます。
| カバレッジ基準の例 | 概要 |
|---|---|
| 命令網羅(ステートメントカバレッジ/C0) | プログラム中のすべての命令が少なくとも1回は実行されること |
| 分岐網羅(ブランチカバレッジ/C1) | プログラム中のすべての分岐条件がtrue、falseの両方に少なくとも1回ずつ実行されること |
| 複合条件網羅(マルチコンディションカバレッジ/C2) | 条件に含まれるすべての分岐の組み合わせが正常に実行されること |
これらのカバレッジ基準を使ってテストケースを作成します。
3．カバレッジ基準を網羅する経路を抽出する
フローチャートを見ながら、定めたカバレッジ基準をすべて通るフローチャート上の経路を決定します。
4．抽出した経路を通るようにテストを行う
抽出した経路を通る入力値を指定してモジュールを動作させ、テストを行います。
5．結果を見る
指定したすべての経路を通ったかを確認します。
▼カバレッジ(網羅率)について、詳しくはこちらの記事をご覧ください。
2-2 データフローテスト
データフローテストとは、ソフトウェアの中で使用されるデータや変数が「定義」→「使用」→「消滅」の順に正しく処理されているかを確認するテストです。
このテストを行うことで、未定義のまま使われているデータ・使用されていないデータの定義を見つけ出すことができます。
実施方法
1．データの流れを図に表す
ソースコードをもとに、データの流れをフロー図にして可視化します。
2．カバレッジ基準を決める
| カバレッジ基準の例 | 概要 |
|---|---|
| 全定義網羅 (All-Defs) | すべての定義が少なくとも1回以上使用されること |
| 全使用網羅 (All-Uses) | すべてのDUペア（定義-使用ペア）が網羅されること |
これらのカバレッジ基準を使ってテストケースを作成します。
3．未定義・未使用のデータを確認する
作成したテストケースをプログラムで実行し、未定義・未使用になっている部分があるか確認します。
結果を分析し、バグや欠陥を特定していきます。
3．ホワイトボックステストで検出できない欠陥
ホワイトボックステストで焦点となるのは「プログラムの論理構造」です。そのため、見つけられない不具合も存在します。
3-1 要求仕様自体の誤りや不備
ホワイトボックステストでは、開発者が詳細設計書や仕様書に従って完成させたモジュールが設計・仕様通りであることを確認します。
そのため、設計書・仕様書自体がユーザーの求める仕様にそぐわない、といった開発の上流工程で起こる不具合は検出できません。
3-2 設計自体の漏れ抜け
ホワイトボックステストでは、設計したとおりにモジュールが動作するかを確認します。
そのため、例えば、開発段階では想定しなかった入力値に対する考慮漏れがあっても、それをテストすることもないため、この種のバグは検出が困難です。
3-3 テスト対象外のモジュールと結合時の動作不整合
モジュール単体では独立して機能していたとしても、システム全体で見たときに予想しない動きをすることがあります。この原因として、他モジュールとの不整合などが挙げられますが、この種のバグもホワイトボックステストでは検出が困難です。
他モジュールとの連携はモジュール間結合テストで検証されるべきもので、単体モジュールのホワイトボックステストでは検証の対象に含まれないためです。
以上のことから、ホワイトボックステストだけで、テストを終えることはできません。
ホワイトボックステストで検出できない欠陥はほかのテストを用いて、ソフトウェアの品質向上を目指していきましょう。
まとめ
今回は、単体テストで多く用いる「ホワイトボックステスト」の基礎知識をご紹介しました。
ホワイトボックステストは、ソフトウェアの「プログラムの論理構造」を理解した上で行うため、モジュール単位の機能を確認することができます。検出されるバグや不具合、修正箇所を特定しやすく、モジュールを調査・変更するだけで効率的に修正することが可能です。
一方で、要求仕様自体の誤りや不備など、ソフトウェアの論理構造からは分かりにくいバグや不具合は検出しにくいという注意点もあります。目的に応じて他のテスト手法と組み合わせて使い分けていきましょう。
テスト技法については以下の記事をご覧ください。
