最終更新日：2026年8月9日
fe fe-technology programming testing
まず結論
ブラックボックステストとホワイトボックステストの違いは、何を基準にテストケースを設計するかです。
仕様・入力・出力を見る
→ ブラックボックステスト
内部構造・処理手順・分岐を見る
→ ホワイトボックステスト
FE試験では、誰がテストするか、いつテストするかよりも、テストケース設計の根拠を見ると選択肢を切りやすくなります。
迷ったら、次の1問を自分に聞きます。
このテストケースを作るために、プログラムの中身を見る必要があるか？
- 見なくても仕様から作れる → ブラックボックステスト
- 中のロジックや経路を見る → ホワイトボックステスト
個別の仕組みを先に確認したい場合は、ブラックボックステストとは？ と ホワイトボックステストとは？ を先に読むと整理しやすくなります。
直感的な説明
自動販売機をテストする場面で考えてみます。
ブラックボックステスト
自動販売機の中は見ません。
100円を入れる
↓
100円の商品を選ぶ
↓
商品が出るか確認する
見るのは、入力と結果です。
ホワイトボックステスト
自動販売機の中の制御まで見ます。
金額判定を通ったか
↓
商品選択の分岐を通ったか
↓
商品排出の処理が実行されたか
見るのは、内部でどの処理を通ったかです。
つまり、同じ製品をテストしていても、注目する場所が違います。
外から見る → ブラック
中まで見る → ホワイト
定義・仕組み
両者を比較すると、違いがはっきりします。
| 比較ポイント | ブラックボックステスト | ホワイトボックステスト |
|---|---|---|
| 主に見るもの | 外部仕様 | 内部構造 |
| テスト設計の基準 | 機能、入力、出力、インタフェース | ソースコード、処理手順、分岐、経路 |
| 中身を見る必要 | 基本的にない | ある |
| 代表的な考え方 | 同値分割、限界値分析 | 命令網羅、判定条件網羅、条件網羅 |
| 試験での合図 | 仕様、入力、出力、境界 | ロジック、分岐、条件、経路 |
ブラックボックステストの考え方
例えば、仕様が次のようになっているとします。
入力できる値は1～100
この仕様から、次のような入力を考えます。
0, 1, 2, 99, 100, 101
ここでは、ソースコードを読まなくてもテストケースを作れます。
この考え方を詳しく確認したい場合は、ブラックボックステストとは？仕様からテストケースを設計する考え方 を参照してください。
ホワイトボックステストの考え方
一方、プログラム内部に次のような分岐があるとします。
if score >= 60
合格の処理
else
不合格の処理
このとき、真側と偽側の両方を通るか確認するには、内部の条件式を見る必要があります。
この考え方を詳しく確認したい場合は、ホワイトボックステストとは？内部構造を見て処理経路を確認する方法 を参照してください。
さらに、命令網羅・判定条件網羅・条件網羅などを整理したい場合は、ホワイトボックステストの網羅基準とは？ へ進むと学習がつながります。
科目Aでどう出る？
科目Aでは、テストケースの設計方法を説明した選択肢を見て、ブラックボックステストかホワイトボックステストか判断する問題があります。
まず「何を見ているか」を探す
問題文や選択肢の中で、次の言葉を探します。
| 出てきた言葉 | 判断しやすいテスト |
|---|---|
| 機能仕様 | ブラックボックス |
| インタフェース仕様 | ブラックボックス |
| 入力と出力 | ブラックボックス |
| 同値分割 | ブラックボックス |
| 限界値分析 | ブラックボックス |
| ソースコード | ホワイトボックス |
| 処理手順 | ホワイトボックス |
| 分岐・条件判定 | ホワイトボックス |
| 命令網羅・分岐網羅 | ホワイトボックス |
「いつ実施するか」では切らない
例えば、次のような表現には注意します。
コーディングが終了した段階でテストする
これだけでは、ブラックボックステストかホワイトボックステストかは決まりません。
重要なのは、その後です。
仕様を参照してテストケースを作る
→ ブラックボックス
ソースコードや内部構造を参照してテストケースを作る
→ ホワイトボックス
FE試験では、時期ではなく設計根拠を見るのが判断のコツです。
科目Bでどう使う？
科目Bでは、仕様とプログラムの両方を読む場面があります。
このとき、ブラックボックスとホワイトボックスの考え方を分けると、何を確認しているのか整理しやすくなります。
例えば、仕様が次のようになっているとします。
1～100なら正常処理
それ以外はエラー
仕様だけから、0, 1, 100, 101 などを選ぶならブラックボックス的な考え方です。
一方、プログラム内部の条件式を見て、真側と偽側の両方を通る入力を探すならホワイトボックス的な考え方です。
仕様から入力を決める
→ ブラックボックス
分岐から入力を決める
→ ホワイトボックス
ホワイトボックス側の分岐の追い方を詳しく練習する場合は、判定条件網羅（分岐網羅）とは？ を続けて読むと理解しやすくなります。
よくある誤解・混同
誤解1：ブラックボックスは完成後、ホワイトボックスは開発中
実施時期だけでは区別できません。
何を基準にテストケースを作るか
で判断します。
誤解2：開発者が行えばホワイトボックス
誰が実施するかも、本質的な判断基準ではありません。
内部構造やソースコードを基準にするならホワイトボックス、仕様を基準にするならブラックボックスです。
誤解3：「条件」という言葉があればホワイトボックス
条件の意味を確認します。
入力条件の範囲を仕様から確認
→ ブラックボックス
プログラム内部の条件式の真偽を確認
→ ホワイトボックス
誤解4：両方はどちらか一方だけ使う
ブラックボックステストとホワイトボックステストは、目的が異なります。
外から見える仕様だけでは内部の経路を十分に確認できず、内部の経路だけでは利用者から見た仕様どおりの振る舞いを十分に確認できない場合があります。
試験では、どちらが優れているかではなく、何を確認する方法かを切り分けます。
まとめ（試験直前用）
- 仕様・入力・出力を見る → ブラックボックステスト
- 内部構造・処理手順・分岐を見る → ホワイトボックステスト
- 「いつ」「誰が」ではなく、何を基準にテストケースを設計するかで判断する
- 同値分割・限界値分析 → ブラックボックス側
- 命令網羅・判定条件網羅・条件網羅 → ホワイトボックス側
理解を深める順番は、ブラックボックステスト → ホワイトボックステスト → ホワイトボックステストの網羅基準 → 判定条件網羅（分岐網羅） と進むと自然です。