ホワイトボックステストとは？ブラックボックステストとの違いまで解説
COLUMN

システム開発の現場では、ホワイトボックステストを筆頭に数多くのテストが実施されています。当記事では、ホワイトボックステストの概要を中心に、ブラックボックステストとの違いも解説するので、ぜひ参考にしてください。

ホワイトボックステストは、システム開発の中でも一般的な部類のテストですが、これからテストエンジニアを目指す人にとっては未知の業務です。また、開発現場の経験が浅いエンジニアの中には、特徴などを明確に把握していない人も多いのではないでしょうか。
正確かつ効率的なテストの実施を目指すためには、ホワイトボックステストについて正しく理解することが必要です。当記事では、ホワイトボックステストの概要から手法の種類、実施の際の注意点までを解説します。

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

さまざまな製品が複数の部品から構成されていることと同様に、アプリケーションは複数の部品であるプログラムから構成されている製品と考えられます。
ホワイトボックステストは、アプリケーションの内部構造、アプリケーションを構成する部品の品質をチェックする目的で行われるテストです。バグの有無を筆頭に、動作確認が主な目的となっています。

1-1 ホワイトボックステストのメリット

ホワイトボックスとは、内部構造や動作原理が明らかになっている装置のことです。作り手にとってのプログラムは、ソースコードを読むことで内部構造や動作原理を明らかにできるホワイトボックスとなります。ソースコードから内部構造が明らかになることで、プログラム中に記述された条件分岐・繰り返し処理などの制御構文を含む、すべてのロジックに対してテストが可能です。

ホワイトボックステストの特徴は、ロジックが実行される頻度にかかわらず、対象のプログラムで実行され得るすべてのロジックに対してテストが実施されることです。そのため、滅多に実行されないロジックから生じるバグ・エラーの見落としを防止する効果が期待できます。

1-2 ブラックボックステストとの違い

ソースコードを読む立場にないユーザー側の観点で実施されるテストを、ブラックボックステストと言います。ブラックボックスとは、ユーザーが内部構造や動作原理を知らなくても支障がない装置のことです。ホワイトボックステストはソースコードが読める作り手側の観点で行われることに対し、ブラックボックステストはソースコードを読まないユーザー側の観点で行われます。

たとえば、「冷蔵庫が壊れた」「洗濯機が回らない」といった不具合が起きた場合、内部構造を知らないユーザーに不具合の原因は特定できません。アプリケーションの場合も同様で、ユーザーの入力から得られた結果に不具合があっても、一般的なユーザーが原因を特定することは困難です。

そこで、ホワイトボックステストでは、ブラックボックステストではカバーできない内部構造・ロジックに着目してテストを行います。

テスト自動化ツールならATgo
1か月トライアル無料：詳細はこちら

2 ホワイトボックステストの手法

ホワイトボックステストでは、すべてのロジックに対して確実にテストを行う必要があります。そのため、テスト対象のロジック総数・テストが完了したロジック数・テストが完了したロジックの割合を示すカバレッジ（網羅率）の管理が必要です。

ここでは、ホワイトボックステストにおける2つの代表的なテスト手法を紹介します。

2-1　データフローテスト

データフローテストは、プログラムで利用される変数のライフサイクルに焦点を当て、ライフサイクルに則っていない変数を検出するテストです。
変数は通常、プログラム内で定義され、1回以上参照された後、不要になれば消滅するというライフサイクルをたどります。ライフサイクルに則っていないとされるのは、定義されずに参照されている変数や、定義されたまま参照されずに消滅する変数などです。
ライフサイクルに則らない変数はソースコードの解析によって検出できるので、構文解析ツールなどによる自動化が進んでいます。そのため、開発者が能動的にデータフローテストを実施する機会は減りつつあります。

2-2 制御フローテスト

制御フローとは、プログラムの命令や、条件分岐・繰り返し処理などの制御構文によって定められた命令の流れを指す用語です。制御フローテストは、プログラムの制御フローを網羅的に実行し、正しく動作するか検証する技法です。ホワイトボックステストにおける主要なテスト技法と言ってよいでしょう。

テストでは実行可能な制御フローを網羅するのが理想ですが、ごく一般的なプログラムであってもフローの総数は膨大になりがちです。そのため、通常はカバレッジが100％となるカバレッジ基準を定義し、総数を限定した上でテストを実施します。制御フローテストは、カバレッジ算定手法によって4つに分けられます。

1 命令網羅（ステートメントカバレッジ）	ソースコード中の命令文のうち、テストを実施した割合によってカバレッジを算定する手法です。プログラム中に記述されたすべての命令文を最低1回テストすることで、カバレッジが100％と定義されます。

2 分岐網羅（ブランチカバレッジ）	ソースコード中の分岐条件に着目し、テストを実施した割合を算定する手法です。1つの条件分岐に対して、指定の条件を満たす場合と満たさない場合の2通りのテストを行う必要があります。 分岐網羅の場合、個々の条件文にのみ着目し、複合条件は考慮しないことが特徴です。たとえば、条件A・条件Bのどちらかを満たす場合に処理Xが、どちらも満たさない場合は処理Yが実行されるケースは、次のテストを行うとカバレッジが100％となります。  処理Xが実行される場合  処理Yが実行される場合 処理Xが実行された場合、条件A・Bのどちらを満たしたかは考慮されず、処理Xが実行される場合と処理Yが実行される場合の2通りのみがテストされます。

3 条件網羅（コンディションカバレッジ）	ソースコード中の条件式で指定された条件のうち、テストを実施した割合によってカバレッジを算定する手法です。たとえば、条件A・条件Bのどちらかを満たす場合に処理Xが実行されるケースでは、次のテストを実施する必要があります。  条件A・Bを満たす場合  条件Aのみを満たす場合  条件Bのみを満たす場合  条件A・Bのどちらも満たさない場合

4 複合条件網羅（マルチコンディションカバレッジ）	複合条件網羅で着目するのは、ソースコード中の条件式で指定された「条件の組み合わせ」です。条件の組み合わせを網羅することで、命令網羅や条件網羅などのカバレッジ基準も同時に満たせる、精度の高い手法です。 条件の組み合わせが2つ程度であればテストの総数は条件網羅と変わらないものの、条件が増えるにつれて必要なテストの総数は膨大になります。

3 ホワイトボックステストを実施する際の2つの注意点

ホワイトボックステストは、内部構造に直接働きかけるテストです。正しく実施するためには、実施できる前提条件などの注意点を事前に把握する必要があります。また、ホワイトボックステストではカバーできない範囲についても把握することが大切です。
ここでは、ホワイトボックステストを実施する際の注意点を2つ紹介します。

3-1 モジュールの論理構造を把握する

モジュールとは、一定の基準（仕様）に即して作られた規格部品のことです。アプリケーション全体を製品と考えると、モジュールは製品を構成する部品に相当します。

ホワイトボックステストは、モジュールがアプリケーションの仕様に適合しているかを検証するためのテストです。ホワイトボックステストを正しく実施するためには、テスト対象となるモジュールの論理構造を把握し、モジュールが取りうる正しい動作を把握する必要があります。

3-2 検出できないバグ・不具合がある

システムテストの具体的な内容が決まったら、次はテスト環境の構築です。テスト本番で使用するマシンやハードフェアと同じものを用意して、正常に動作するかを確認します。
また、マスターデータやトランザクションデータなども、利用するのは原則として本番と同じデータです。本番と同じデータを使用しなければ、想定外の不具合などを確認することができません。

まとめ

テスト実行後の結果の報告は、信頼度成長曲線などのグラフを用いて行われます。
信頼度成長曲線とは、テストの進捗に応じたバグ発生数の変化を表すグラフです。一般的に、テスト開始時には多くのバグが発生し、修正を重ねるごとに減少する傾向が見られます。
テスト終盤になってもバグ件数に変化が見られない場合、システム内にバグが残っているケースもあります。結果報告の内容によっては、再度システムテストを行うことも考えられるでしょう。