最終更新日: 2024年2月19日
ホワイトボックステストとは、プログラムの構造を理解した開発者によって行われるテストです。テスターが行う種類のテストとは大きく異なりますが、ソフトウェアテストにおいては必要な種類のテストと言えます。この記事では、ホワイトボックステストの概要を紹介した上で、その技法やよく比較されるブラックボックステストとの違いを解説しています。
ホワイトボックステストとは
ホワイトボックステストとは、ソフトウェアを構成するプログラムが、仕様書の意図する通り正確に動作するかをチェックするテストです。ホワイトボックステストは、そのプログラムの構造を理解していないとできないテストなので、基本的には開発者によって行われます。それ以外の第三者によって行われることは、あまりありません。
ホワイトボックステストは、ソフトウェアの最小単位であるモジュールの動作をチェックする「単体テスト」の工程でよく行われます。単体テストのあとに続く結合テスト・システムテストといった工程でも行えないわけではありませんが、その機会は少ないです。
ブラックボックステストとの違い
ブラックボックステストとはプログラム内部の構造を考慮せず、ソフトウェアがユーザーの要望通りに動作するかチェックするテストです。プログラム構造に着目するホワイトボックステストは、コンセプトが正反対といえるでしょう。
両者の違いは、テストの対象にもあります。紹介した通り、ホワイトボックステストではプログラムの内部構造に着目します。一方でブラックボックステストではインターフェイスのレイアウトが正しいかといった、外部的な仕様もテストの対象です。
ホワイトボックステストは、開発者自身が意図した通りプログラムが動作するかのチェックが目的であるため作り手側のテストと言われます。一方ブラックボックステストが注目するのは、ソフトウェアがユーザーの要望通りに設計されているかです。そのためブラックボックステストは、ユーザー側のテストとも言われます。
このように両者は、コンセプトやテストの対象、役割が異なります。そのため、ソフトウェアテストではホワイトボックステスト・ブラックボックステスト両方を行うことが必要です。
ホワイトボックステストの技法
ホワイトボックステストには、「制御フローテスト」「データフローテスト」という2種類の技法があります。以下、それぞれの技法の概要を紹介します。
制御フローテスト
制御フローとは、簡単に言うと行われた処理に対しプログラムがどのように動作するかをまとめた図のことです。たとえばデータの入力という処理が行われた場合は、データベースへの接続・データベースへのデータ登録といった動作が続きます。
制御フローでは、このような処理の流れをまとめるわけです。制御フローテストとは、想定した通り制御フローが正しく動作するかをチェックするテストを指します。
理想的には全ての制御フローをチェックできればよいですが、その数は膨大となるため現実的ではありません。そのため制御フローテストでは以下に挙げる網羅基準を設け、その基準に従い行われます。
命令網羅（ステートメントカバレッジ）
全ての命令（処理）を、少なくとも1回は通すという基準です。制御フローテストの中では一番粒度が粗く、最も基本的な基準と言えます。さきほどの図の場合、すべての命令を1回は通すには、以下の通りとなります。
分岐網羅（ブランチカバレッジ）
制御フローにおける全ての条件分岐を、少なくとも1回は実行するという基準です。命令網羅と比べると、粒度が細かくなります。上図でいうと、たとえば以下の2つのテストケースで実施できます。
条件分岐（デシジョンカバレッジ）
制御フローにおける全ての条件分岐の組み合わせを、少なくとも1回は実行するという基準です。3つの基準の中では最も粒度が細かいため、この基準を採用すればテストの品質も向上します。上図でいうと、以下4つのテストケースをすべて実施するということになります。
これらのうちどの基準を採用するか、どれだけの可能性を網羅するか（カバレッジ率）は、組織やプロジェクトごとに異なります。それぞれ目標値を定めて、実行するわけです。
データフローテスト
データフローテストとは、データが順番通り正しく処理されるかをチェックするためのテストです。モジュールで使われるデータは、定義された後に使用（参照）され、いらなくなったら消滅するという流れで処理されます。
データフローテストでは、この流れ通りに処理されているかをチェックするわけです。たとえば定義される前にデータが使用・消滅されていたら、不具合と判断します。
ホワイトボックステストの必要性と注意点
ソフトウェア開発の際に、ホワイトボックステストは必ず行われるべきテストです。ソフトウェアテストでホワイトボックステストが十分に行えていないと、その後のテストでバグが多く検出される可能性があります。
またホワイトボックステストを行わないと要件の考慮漏れが発生する可能性があり、手戻りの工数が増大化してしまいます。その結果、開発コストが膨らんでしまったり、十分な品質を確保できなくなったりする可能性が高くなるのです。
一方、ホワイトボックステストでできるのは、仕様書通りにプログラムが動作するかのチェックまでとなる点は注意が必要です。仮に仕様書がユーザーの要求を満たしていなかったとしても、ホワイトボックスで検出することはできません。この検出は、ユーザー視点のテストである、ブラックボックステストの役割となります
グレーボックステストとは
グレーボックステストとは、プログラムの内部構造を理解した人がテストの実行者となり、外部から機能や仕様をチェックするテストです。ホワイトボックステスト・ブラックボックステストの中間的なテストということで、グレーボックステストと呼ばれます。
テスト対象はブラックボックステストと同じですが、内部構造を把握した担当者が行うため、より詳細に検証できるのがメリットです。グレーボックステストは、プログラム構造を理解しているプログラム作成者等が担当します。
まとめ
ホワイトボックステストとは仕様書通りにプログラムが動作するか確認するテストで、プログラムの内部構造を理解した開発者が行います。ホワイトボックステストの役割は意図通りにプログラムが動作するかまでで、仕様書がユーザーの要求を満たしているかは確認できません。その役割を果たすのは「ブラックボックステスト」です。
ホワイトボックステストでは、「制御フローテスト」と「データフローテスト」という技法が用いられます。制御フローテストでは、想定通りに制御フロー（プログラムの処理をまとめた図）が動作するかを確認します。一方、データフローテストで確認するのは、モジュール上でデータが正しく処理されているかです。
仮にホワイトボックステストをしないと、このあとのテストで多くのバグが検出される可能性があります。ホワイトボックステストでは、プログラムの構造のなかで要件漏れがないかチェックできるためです。
ソフトウェアテストに従事して約20年。 テストマネージャーとして、Webシステムやスマホアプリ、ゲーム等の様々なソフトウェアのテスト計画策定、テストチーム構築、テスト管理、品質分析および品質向上施策提案などに携わる。保有資格として、IVECハイレベル5やJSTQB AL TMなど。現在は、AIQVE ONE株式会社にて、ソフトウェアテストについての社員教育や、テストプロセス・テスト手法の仕組み化・標準化に取り組んでいる。
【著作】『ゲームをテストする バグのないゲームを支える知識と手法』（翔泳社）