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