ホワイトボックステスト（内部構造に着目する）

📌

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

ホワイトボックステストとは、プログラムの内部構造（命令や分岐の流れ）に着目し、処理の経路が正しく通るかを検証するテストです。「ホワイトボックス＝中身が透けて見える箱」という意味で、ソースコードの中身を見ながらテストします。

対になるのがブラックボックステストです。
・ホワイトボックス：中身（内部構造）を見て、処理の経路を確かめる
・ブラックボックス：中身は見ず、入力と出力の対応だけを確かめる

身近な例で考えると、機械の点検に似ています。カバーを開けて配線や歯車を1つずつたどり「すべての部品がちゃんとつながって動くか」を確認するのがホワイトボックス。一方、ボタンを押して正しい動きが出るかだけを見るのがブラックボックスです。上の図解で、左の中身の見える箱がホワイトボックスにあたります。

📌

網羅基準

ホワイトボックステストでは、「内部の経路をどこまで通したか」を測る物差しとして網羅基準（カバレッジ基準）を使います。代表的なものは次の3つです。
・命令網羅：すべての命令を最低1回は実行する
・分岐網羅（判定条件網羅）：各分岐の真・偽の両方を最低1回ずつ通る
・条件網羅：分岐の中の各条件式について、真・偽の両方を試す

これらは下に行くほど基準が厳しくなり、必要なテスト数が増えます。たとえばif (x > 0) という分岐があるとき、命令網羅は処理が一通り動けばよいのに対し、分岐網羅はx > 0 が成立する場合と成立しない場合の両方を必ず通す必要があります。

身近な例では、分かれ道のある散歩コースをすべて歩くのに似ています。とりあえず端まで歩けば命令網羅、すべての分かれ道で右にも左にも進めば分岐網羅です。基準を上げるほど見落としは減りますが、その分だけ歩く回数（テスト件数）が増えていきます。

📌

適用工程(単体テスト等)

ホワイトボックステストは、主に単体テスト（モジュール1つを単独で確認するテスト）で行われます。理由は、テスト対象が小さく、作り手が内部構造を細かく把握しているため、経路を1つずつ確認しやすいからです。

テスト工程ごとの使われ方を整理すると、次のようになります。
・単体テスト：内部構造に踏み込むホワイトボックステストが中心
・結合テスト：モジュール間の連携を見るため、ブラックボックスの観点も増える
・システムテスト：全体を仕様どおりか確認するブラックボックスが中心

大きな単位になるほど中身は複雑になり、経路をすべて通すのは現実的でなくなります。そのため「小さい単位は内部まで見るホワイトボックス、大きい単位は外から見るブラックボックス」と役割分担し、両方を組み合わせて品質を確保します。

📌

網羅基準を選ぶ理由（どの厳しさにするか）

なぜ網羅基準を選ぶ必要があるのか。すべての経路を完全に網羅しようとすると、テストの件数が膨大になります。たとえば if 文が10個あるだけで分岐の組み合わせは1024通り以上になります。すべてを試すと時間とコストが膨大になるため、「どこまで確認するか」をあらかじめ決めるのが網羅基準の役割です。

上の具体例のように、if (x > 0) が1つあるとき、基準によってテスト件数が変わります。
・命令網羅：x = 1（真のみ）でもOK。処理Bを通らなくてもよい。テスト1件で済む
・分岐網羅：x = 1（真）と x = -1（偽）の2件必要。処理A・Bを両方通す
・条件網羅：分岐の中に複数の条件式（例: x > 0 && y > 0）があれば、それぞれの真偽も組み合わせて試す

基準を厳しくすれば見落としは減りますが、テスト件数が増えて時間もかかります。何をどこまで確かめるかをバランスよく決めるのがテスト設計の大切な仕事です。一般的に、単体テストでは最低でも分岐網羅を目標にすることが多いです。

📌

ホワイトボックスとブラックボックスの比較

なぜ2種類に分かれているのか。プログラムの品質を確認するには、「内側から見て、全パターンが動くか」と「外側から見て、要求どおりか」の2方向が必要だからです。どちらか一方だけでは見落としが生まれます。

たとえば、外から見て正しい出力が返っていても、内部の特定の分岐が一度も通らずに隠れたバグが残っていることがあります。逆に、すべての経路を通しても、仕様として必要な動作が抜けていることもあります。上の表のように、両方のアプローチを組み合わせてテストすることで、幅広い種類のバグをより確実に見つけられます。