トレンド情報 / 記事を探すCOLUMN

おさらいしよう!「ホワイトボックステスト」の基本

更新日|2018.06.25

Qbook編集部

おさらいしよう!「ホワイトボックステスト」の基本

ソフトウェアの品質を向上させるためには、ソフトウェアテストが重要な役割を果たしますが、テスト技法にはさまざまな種類があります。

今回はソフトウェアの内部構造を理解した上でモジュール単位の機能を解析することができる「ホワイトボックステスト」について、基本から詳しくご説明します。

ホワイトボックステストとは

8607-00010-02

本稿では、「実体のある機械装置が透明の箱に収められていて、外側から箱の中の内部構造が見えているような状態(機械の原理や機構を認識できる状態)」を「ホワイトボックス」と定義します。

「ホワイトボックステスト」は、ソフトウェアのプログラムを理解した上でプログラムの論理構造が正しいかどうかを解析するテストのことを指します。

ホワイトボックステストは、主にソフトウェアの最小単位であるモジュール(部品)の1つを対象とした単体テストで用いられるため、本稿でも単体テストで用いられるホワイトボックステストに重点をおいて解説します。

ホワイトボックステストではモジュールの論理構造を正しく把握する

モジュールとはシステムを構成する最小単位です。各モジュールは設計書や仕様書に基づいて論理的に組み立てて実装されますが、もしその論理構造に考慮漏れや誤りがあったり、実装ミスで設計どおりに動作しないような欠陥があれば、当然ながら、そのモジュールは正しく動作せず、他のモジュールと組み合わせた際にはさまざまな問題を引き起こしてしまうことになります。つまり、システムが適切に動くことを担保するには、モジュール単体が設計した論理構造に従って動作することを担保するのが前提となります。

モジュールが設計した論理構造に従って動作するかどうかを検証するには、当然ながら、そのモジュールの論理構造を正しく把握していることが必須不可欠です。

モジュールの論理構造を正しく把握するには、モジュールの論理構造をフローチャートなどの図表にして表すと良いでしょう。

8607-00010-03

図表に表すことで、テストすべき点が明らかになるだけなく、開発者にとっても、
・既存の論理構造の修正箇所
・修正負担や他モジュールへの影響
などが容易に把握でき、適切な修正作業を行えるようになります。

ホワイトボックステストで使用される技法

ここからは、ホワイトボックステストに用いられる「制御フローテスト」と「データフローテスト」についてご紹介します。

処理動作の確認は「制御フローテスト」

制御フローは、1つの処理に対してソフトウェアがどのように動くかをフローチャートと呼ばれる図にしたものです。この図の中では、if文の条件式や繰り返しのロジックによって指定された処理の流れを図示します。

入力値や条件を組み合わせたときの処理の流れが、設計意図通りに動作するか確認することが、本テストの目的です。

データ流れの確認は「データフローテスト」

データフローとは、モジュール内で使用されるデータや変数処理の流れのことです。

特に、変数データが「定義」「使用(参照)」「消滅」するような処理を指します。データに着目して意図した順序で正しく処理されるか、無駄なデータ処理をしていないかなどを確認することができます。

ホワイトボックステストと「カバレッジ」

ホワイトボックステストでは、内部構造を網羅するようにテストケースを作成することが求められますが、テストがテスト対象をどれくらい網羅いるかを測る尺度として、カバレッジ(網羅率)という考え方があります。

一般的にはカバレッジの高いテストを実施すれば、テスト対象のモジュールの品質は高くなる方向に傾きますが、より多くのテストケースも必要となり、かけられる時間・コストとのバランスを見て戦略的にリソースを配分する必要があります。そのためホワイトボックステストでは、適切なカバレッジを設定し、そのカバレッジを満たすように効率よくテストケースを設計することが大切です。

カバレッジについての詳細はこちらをご参照ください。

ホワイトボックステストでは検出できないバグ・不具合とは?

ホワイトボックステストで焦点となるのは「プログラムの論理構造」です。

そのため、以下のような不具合は見つけられません。

要求仕様自体の誤りや不備

開発者は詳細設計書や仕様書に従って実装し、テスト担当者は完成したモジュールが設計・仕様通りであることを確認します。そのため、設計書・仕様書自体がユーザーの求める仕様にそぐわない、といった開発の上流工程で起こる不具合は検出できません。

設計自体の漏れ抜け

ホワイトボックステストでは、設計したとおりにモジュールが動作するかを確認します。

そのため、例えば、開発段階では想定しなかった入力値に対する考慮漏れがあっても、それをテストすることもないため、この種のバグは検出が困難です。

テスト対象外のモジュールと結合時の動作不整合

モジュール単体では独立して機能していたとしても、システム全体で見たときに予想しない動きをすることがあります。この原因として、他モジュールとの不整合などが挙げられますが、この種のバグもホワイトボックステストでは検出が困難です。

他モジュールとの連携はモジュール間結合テストで検証されるべきもので、単体モジュールのホワイトボックステストでは検証の対象に含まれないためです。

「ブラックボックステスト」との違いは?

ソフトウェアのプログラムを理解・意識した上で行う「ホワイトボックステスト」とは対称に、プログラムの内部構造を見ずにインプットとアウトプットを確認する「ブラックボックステスト」があります。このテストは、よりシステムのユーザーの目線に立ったテストを行うことができる手法で、ホワイトボックステストのデメリットをうまくカバーする性質があります。

おわりに

今回は、単体テストで多く用いる「ホワイトボックステスト」の基本についてご紹介しました。このテストは、ソフトウェアの「プログラムの論理構造」を理解した上で行うため、モジュール単位の機能を確認することができます。検出されるバグや不具合、修正箇所を特定しやすく、モジュールを調査・変更するだけで効率的に修正をできることが可能です。

一方で、要求仕様自体の誤りや不備など、ソフトウェアの論理構造からは分かりにくいバグや不具合は検出しにくいため、目的に応じて他のテスト手法と組み合わせて使い分けることが大切です。

資料ダウンロード

ライター:Qbook編集部

ライター

バルテス株式会社 Qbook編集部。 ソフトウェアテストや品質向上に関する記事を執筆しています。