ホワイトボックステストとは？手法やメリット、ブラックボックステストとの違いを解説

システム開発における機能の系統的なテスト手法として、主にホワイトボックステストとブラックボックステストの2つが使われます。組み上げられたシステムの外部から見た仕様を確認するブラックボックステストに対し、ホワイトボックステストは開発者目線で作成したものそのものをチェックするテストです。両者は異なる視点で行われるテストですが、いずれもソフトウェアテストにおいて重要なものといえます。

本記事では、ホワイトボックステストの概要とメリット・デメリット、採用される主な手法と実施手順を解説します。

株式会社SHIFTでは、ソフトウェアテストに関して豊富な実績とテストナレッジを保有しており、あらゆるお客様のニーズを満たしたテスト・品質保証を上流～下流（テスト計画・テスト設計・テスト実行・テスト品質管理）まで一気通貫でご依頼いただけます。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

ホワイトボックステストとは、システムの内部構造に重点を置いたテスト手法です。イメージとしてはシステムの内部構造がクリア（ホワイト）な状態を前提としたテストとイメージしてください。

単体テストの工程で記述したプログラムを網羅的に確認するために用いられ、プログラムからの命令文、分岐条件を把握し、プログラム全体を網羅的に確認します。テスト手法や網羅の基準によって、テストケースの数は変わってきます。

網羅率、テスト手法を意識したテストケースの作成をしないと、本来ホワイトボックステストで見つける必要がある不具合を見逃してしまい、後工程で不具合が多発することにつながるケースもあります。その結果、システムの品質担保やプロジェクトの進捗に影響が出ることがあるため、非常に大切なテストといえるでしょう。

なお、画面やインフラ構成などについても、内部構造を意識してホワイトボックステストを行いますが、本記事では以下、プログラムのホワイトボックステストについて説明します。

▼あわせて読みたい▼
＞＞コンポーネント（単体、ユニット）テストとは？手法などを例で紹介のページへ

ホワイトボックステストは、実際に作成されたプログラムの構造を見て、プログラムが正常に動作しているかを確認するテストです。単体テスト工程で記述されているプログラムの論理や動作が作成者の意図通りになっているかどうかの確認を行います。

また、条件分岐や例外処理など、網羅的なテストを実施するのもホワイトボックステストの特徴です。単純なミスの検出だけではなく、分岐条件やエラー判断など、プログラム上の記載ミスや処理ミスによる不具合がないかを検証することもできます。

 何よりも、プログラムのすべての部分を網羅的にテストすることで、プログラムの書き方に誤りがないということを主張できます。開発者が自分の意図の通りのプログラムを、詳細設計通りに開発できているかを確認できるため、不測のトラブルの防止にもつながるのです。

ブラックボックステストはシステムの外部仕様に重点を置いたテスト手法となり、イメージとしてはシステムの内部構造が不明瞭（ブラック）な状態を前提としたテスト手法です。そのため、システムの内部構造は意識せずにシステムに入力する情報、システムから出力される情報に着目しているため、ユーザーと同じようにシステムの外部からシステムに触れてテストを実施します。

ブラックボックステストについてはこちらもご覧ください。
＞＞ブラックボックステストとは？特徴や技法、ホワイトボックステストとの違いを解説のページへ

一方のホワイトボックステストは、開発者目線で書いたプログラムが論理的に問題ないか、思った通りに動作しているかを確認するテストです。プログラムコードに関する知識が求められるので、開発者がテストを作成することが多いですが、意図したとおりにプログラムが動作するか否かは、ソフトウェア開発において非常に重要です。プログラムの内部構造まで細かくチェックし、意図通りに動作するかを確認します。

両者は別々に実施されるテストですが、どちらか片方だけを実施すればいいわけではありません。ユーザー視点も開発者視点もどちらも重要であるため、両方のテストを行うのが必須となります。

ホワイトボックステストが必要な理由としてあげられるものは、以下の2つが代表的です。

・書いたプログラムを網羅的にテストするため、コーディング時に気づけなかったレベルの潜在的な不具合が抽出できる
・プログラムに修正が入ったときにホワイトボックステストを再実行することで、意図せぬ動作の変化を見つけることができる

開発者がコーディング中に何か誤解をしたときに、自己レビューでは同じように考えてしまって、この不具合を検出することは困難です。複数人で見ると気が付くこともありますが、それでも見落とす可能性があります。ホワイトボックステストでプログラムを網羅的にテスト実行することで、開発者が気付かなかったプログラム上の間違いを発見できる可能性があります。

また、ホワイトボックステストでは、条件を網羅するためにさまざまなデータを使ってテストを行います。そのため、単体テストフレームワークを用いて自動的にテストができるようにするのが一般的です。自動化することでリグレッションテストとしての実行も可能で、プログラム修正時の動作の変化を容易に検出することができます。

リグレッションテストに関してはこちらもご覧ください。
＞＞リグレッションテスト（回帰テスト）とは？目的や自動化のメリットを解説のページへ

ホワイトボックステストの実施は必須ですが、留意事項があることも理解しておかなければなりません。代表的なものは次の2つです。

・プログラムに書かれていることを基にテストをするため、プログラムに書き落としたことを検出することがむずかしい
・プログラムの設計が稚拙で、条件文が大量に書かれていたり適切なインターフェース設計ができていない場合、テストケースが膨大になったり、実行するのに複雑な仕組みが必要になったりする

基本的に、ホワイトボックステストを実施する際には書かれたプログラムを網羅するように設計します。しかし、根本的に誤っていてプログラムに書かれていないと、そもそも間違いを発見できない可能性があるのです。期待された機能をすべて満足しているかどうかは、ホワイトボックステストだけではなく、インターフェースレベルのブラックボックステストを行って確認する必要があります。

もうひとつの留意点としてあげられるのが、プログラミングスキルの稚拙さがそのままホワイトボックステストの難度に直結する点です。優れた開発者は、スッキリしたプログラムを書きますが、経験の浅い開発者の書いたプログラムは条件が複雑になりがちです。条件文が増えるとその分テストケースは増えるので、プログラムをテストするにはより多くのテストケースが必要で、テスト工数もかかることになります。また、プログラムのインターフェースの設計に考慮が行き届いていれば、そのプログラムを切り離して容易にテスト実行ができます。しかし、成り行きでインターフェース設計をしているような場合は関連するプログラムが複雑になり、場合によっては工数が増えるだけではなく、単体でのテスト自体ができなくなることもあります。付け加えておくと、テストプログラムの書き方が稚拙だと、テスト自体が成立していないということもあります。ホワイトボックステストの経験を積むことはプログラム設計の良し悪しを知ることにつながりますので、設計力向上を意識したホワイトボックステストを行うことをおすすめします。

ホワイトボックステストでよく使われている手法は、次の4つです。

・制御フローテスト
・データフローテスト
・同値分割法
・境界値分析

「同値分割法」「境界値分析」は、テストの密度を調整するテスト手法で、ホワイトボックステストでも使用します。併せて解説します。

プログラム内にあるソースコードには分岐条件が含まれているケースが多くあります。この分岐条件に対して特定のデータを設定することでプログラムが設計書の意図通りの挙動をしていることを確認する手法を「制御フローテスト」と呼びます。

分岐条件で設定できるデータは、例えば文字列や数値だとデータのパターンが膨大になるため、すべてのパターンを実施することは現実的ではありません。

テスト対象となるシステムの重要度、複雑度にもよりますが、ホワイトボックステストでは適切なテストデータのパターンを選択し、プログラム内のすべての処理経路を少なくとも1度は実行できるようなパターンを組む必要があります。

ホワイトボックステストとしては、すべての処理経路に対して少なくとも1度テストパターンを実行すれば完了となります。しかし、前述のとおりホワイトボックステストでは書いたプログラムしか確認しないため、すべての機能を確認しているかという点ではテストとしては不十分です。単体テストの工程ではホワイトボックステストだけでなく、インターフェースレベルで機能を網羅するようなブラックボックステストを行うことで、機能の実装漏れを確認できます。ここまでテストすることでプログラムレベルの確認は完了し、後工程のテストで多くの不具合が見つかることもなくスムーズに進むでしょう。

上記の「制御フローテスト」はプログラムの処理フローに着目したテスト手法ですが、対して「データフローテスト」はプログラム内のデータの流れに着目したテスト手法となります。

データはプログラム内で変数として「定義」→「使用」→「消滅」といったライフサイクルで使用されており、開発者のコーディングミスによって変数に不正な値が入力されていることを見つけるのが、このテストの主な目的となります。

「同値分割法」は、機能テストの技法のひとつで、同値領域から代表値を実行するテストケ－スを設計するものです。

有効または無効のような同様の結果をもたらす値を、それぞれ「同値クラス」として分類し、最低1回各同値クラスのグループから実行するように設計するのが原則になります。これによりテストケースを限りなく少なくし、効率よく不具合を発見するための技法です。

（例）以下の①～③のような仕様が存在した場合、基本情報処理の未取得者について「同値分割法」を用いると以下のように表現ができます。

1．基本情報処理の資格取得者は1万円割引
2．基本情報処理の未取得者でも、40歳以上であれば5,000円割引
3．上記①、②の条件に合致していない場合、30歳以上であれば3,000円割引
4．上記①～③の条件に複数合致しても重複して割引を受けることはできない

「境界値分析」も機能の技法のひとつで、仕様に定められている条件の境界値を基にして行うテスト技法です。

境界値とは、ある範囲の最小値または最大値などの同値分割した領域の端にあたる値です。具体的には「未満」や「以下」などが該当します。境界部分はソフトウェア開発において間違いを引き起こしやすく、不具合につながりやすいため、境界値分析で検証する必要があります。特に、プログラム上は「age >= 40」と「age > 40」のように「=」の有無だけで表現されるため間違いやすく、ホワイトボックステストでの確認が有効です。

（例）以下の①～③のような仕様が存在した場合、基本情報処理の未取得者について「境界値分析」を用いると以下のように表現ができます。

1．基本情報処理の資格取得者は1万円割引
2．基本情報処理の未取得者でも、40歳以上であれば5,000円割引
3．上記①、②の条件に合致していない場合、30歳以上であれば3,000円割引
4．上記①～③の条件に複数合致しても重複して割引を受けることはできない

＞＞テストケースを作成する手法「境界値分析（限界値分析）」について解説のページへ

ホワイトボックスを実施する前に、以下を確認しておく必要があります。

・制御フローを網羅する指針
・同値分割、境界値分析の基準
・テスト実施の環境、網羅率測定の方法
・網羅が不可能であるときの対応方針

ホワイトボックステストでは、プログラムをすべて網羅することが基本となりますが、その「網羅した」ことを判断する指針を決めなければなりません。後述しますが、網羅の考え方にはさまざまあって、ある指針では網羅したことになっても、別の指針では網羅が足りないということになります。これを明確に指針として決めます。

次に、テスト手法として、同値分割か境界値分割かどちらを採用するかの基準を決めます。整数で不等号があるときは境界値分割も容易で採用されることが多いですが、実数だと丸め誤差があったり境界の反対側の値をどう表現したらいいのか難しかったりします。制御フローだけでなく、データの型まで分析するのがホワイトボックステストらしいですね。

つづいて、テスト実施の環境や網羅率測定の方法ですが、多くの場合は単体テストフレームワークと関連するツールで実行も測定もできるので、これを選ぶことが多いでしょう。プログラミング言語の都合でツールがないなどの場合には、ドライバのプログラムを書くのかシステム操作で実施するのかを選ぶ必要があったり、網羅の評価もテストケースレベルの机上評価になったりします。

最後に網羅が不可能な場合の対応を決めます。前にインターフェース設計が悪いプログラムだと単体でのテスト実行ができないケースがあるということをお伝えしました。この場合、本筋はテストできるように修正することですが、今回の開発対象ではない場合など諸事情に関わるので、事前に方針を考えておくべきでしょう。一方で、優秀な開発者が作ったプログラムには、万が一の場合に誤動作を回避する処理が書かれていて、万が一の状況を作り出せなくて確認ができないということがあります。これも網羅から除外してよい条件として明示しておくとよいでしょう。

準備ができたら、残りの手順は明確です。

・プログラムの制御構造から、それを網羅するテストケースを設計して実行確認する
・網羅できなかったルートがあれば、それを通るようにテストケースを追加する

事前に検討した例外を除いてすべてを網羅したら、ホワイトボックステストは完了です。

ホワイトボックステストではシステムの内部構造を網羅的にテストするために、どの程度の網羅率でテストが実行できるかを知らなければなりません。網羅率のことを「カバレッジ（※）」と呼び、代表的なものとして以下の3パターンがあります。

・C0（命令網羅）
・C1（分岐網羅）
・C2（条件網羅）

網羅率の基準が高いほどテストの綿密さは高くなるため、不具合の抽出はしやすくなりますが、その分、多くのテストケースを必要とします。ホワイトボックステストは内部の論理構造に不備がないかを確認するテストであるため、テストの綿密さは非常に重要です。現在は綿密さが高いC2レベルでテストを行うのが一般的になっています。

C2の定義にも若干幅があります。原則的には、「基本情報処理未取得かつ40歳以上」の場合、「基本情報処理を取得しているか」「40歳以上か」の双方について真偽を組み合わせてテストを行うという方法を表します。単純にこれを組み合わせると4つのパターンになりますが、多くの言語では複合条件の左辺で結果が決まる場合に右辺の真偽は評価しないため、3つのパターンで満足するという考え方も広まっており、網羅率のツールもこれに従うものが多くあります。一方で、一つの関数（メソッド）内で別の条件文があったら、その個々の条件も含めてすべての真偽パターンをつくる、すなわち条件文が10個あったら1024パターンのテストをするという定義もあります。

通常はツールが対応する定義を使うのが無難ですが、条件によってはソフトウェアの特性を見てどの定義を採用するか決めましょう。

※カバレッジについての考え方は以下を参照ください。
https://service.shiftinc.jp/column/4547/

ホワイトボックステストは、開発したソフトウェアそのものを開発者目線で確認するテストです。正常に機能するのか、分岐条件に問題はないかなどを確認することで、品質の高いソフトウェアを提供することができます。プログラムに書かなかったことについては担保できないため、ブラックボックステストと一緒に行うのがおすすめです。開発物の品質の担保には、正しいホワイトボックステストが必須といえます。

SHIFTでは、ソフトウェアテストのサポートも実施しています。年間4,000件以上のソフトウェアテストを実施しているノウハウを生かし、特定のソフトウェアに対してどのようなテストが有効なのかのアドバイスが可能です。また、第三者としてのテストも可能であるため、どのような形でもテストに関与できるメリットがあります。ソフトウェアテストに悩みを抱えている方、サポートが必要な方は、ぜひSHIFTまでご相談ください。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座