用語比較
ホワイトボックステストとブラックボックステストの違い
ホワイトボックステストは、プログラム内部の処理の流れや分岐を踏まえて動作を確かめる方法です。ブラックボックステストは内部構造へ立ち入らず、入力に対して期待する出力が得られるかに着目します。
DS検定では、テスト担当者の所属やツール名ではなく、テストケースを何から作るかを読みます。コードの分岐や処理経路を基準にするならホワイトボックス、入力条件と期待出力を基準にするならブラックボックスです。
このページは、白は中が見える、黒は中が見えないという比喩だけで覚え、具体的な設問で判断軸を失う人を対象にしています。分岐テストをホワイトボックス技法として位置付ける一方、仕様に対する入出力確認はブラックボックスとして切り分け、両方を組み合わせる場面でも目的を混ぜない読み方を固めます。
この記事の根拠と出典
本文の主要なセクションでは、公式一次資料と照合した内容と編集部の整理を、見出しの下のラベルで区別しています。 試験日、料金、申込条件、試験方式など変動する情報は、公式情報を最終確認してください。 当サイトの一次情報確認日: 2026-07-12。
- 公式一次資料と照合した内容
- ホワイトボックステストとブラックボックステストの区別、分岐テストの位置付けはDS検定の登録factsと公式一次資料へ照合しています。
- 編集部が学習用に整理した内容
- テストケースの根拠から選ぶ手順は編集部の学習上の整理です。
DS検定の一次資料
結論
公式一次資料と照合用語の定義は公式一次資料と照合しています。
ホワイトボックステスト
内部構造、処理経路、分岐を踏まえてテストケースを作り、想定した経路が動くかを確かめる。
ブラックボックステスト
内部構造を前提にせず、入力条件に対して期待する出力や振る舞いが得られるかを確かめる。
違いを表で確認
| 比較軸 | ホワイトボックステスト | ブラックボックステスト |
|---|---|---|
| 参照するもの | コードの内部構造や処理の流れ | 外部から見える入力・出力と期待する振る舞い |
| テストケースの起点 | 分岐、条件、実行経路 | 仕様、入力条件、期待結果 |
| 代表的な手掛かり | 分岐テスト、真と偽の経路 | 内部実装を問わない入出力確認 |
| 見つけたい不具合 | 通っていない処理経路や分岐の実装不備 | 仕様どおりの結果を返さない外部振る舞い |
| 設問で先に読む語 | 内部、コード、分岐、経路 | 仕様、入力、出力、期待結果 |
公式一次資料と照合DS検定の一次資料で確認（一次情報確認日: 2026-07-12）一次資料の一覧を見る →
どこで迷っているかを切り分ける
テスト担当者の立場で決めてしまう初学者
開発者が行うからホワイトボックス、利用者が行うからブラックボックス、と担当者だけで決めると設問の中心を外します。誰が行うかではなく、テストケースの根拠が内部コードなのか、外部仕様と入出力なのかを確認してください。
分岐テストを独立した第三の方式だと思う人
分岐テストは、if文などの分岐が取る結果を実行できるか確かめるホワイトボックス技法です。名称を三つ横並びで覚えず、分岐テストが内部構造を基準にする具体例だと位置付けます。
一つの方式だけで十分だと考える再受験者
内部経路が実行されたことと、外部仕様どおりの結果が得られることは同じ確認ではありません。設問が両方の観点を求める場合は、二者択一にせず、内部構造を見る確認と入出力を見る確認を別目的として組み合わせます。
具体例で使い分ける
編集部の整理
例 1
条件分岐の真と偽の経路を確かめる
コード中の条件分岐について、条件が真になる経路と偽になる経路を通るテストケースを作る場面です。
- テストケースの起点が、外部仕様だけでなくコード内部の分岐になっています。
- どの処理経路を実行したかを確認するため、内部構造を知らずには設計できません。
- 分岐テストはホワイトボックス技法として整理されるため、入力と期待出力だけを見る説明とは分けます。
結論: 内部の分岐と実行経路を基準にするので、ホワイトボックステストです。
例 2
入力に対する期待出力を仕様から確かめる
プログラムの内部実装を前提にせず、与えた入力に対して仕様どおりの出力が返るかを確認する場面です。
- テストケースの根拠は、コードの行や分岐ではなく外部から確認できる仕様です。
- 内部でどの経路を通ったかではなく、観測した出力が期待結果と一致するかを見ます。
- 内部構造を知らなくても同じ入力条件と期待結果を定義できるため、ホワイトボックスの説明ではありません。
結論: 入力と期待出力を基準にするので、ブラックボックステストです。
例 3
内部経路と外部仕様を別々に確認する
内部の主要な分岐を通したうえで、利用者から見える出力も仕様どおりか確認する場面です。
- 分岐を通ったかという確認は、内部構造に基づくホワイトボックスの観点です。
- 期待出力と一致するかという確認は、外部振る舞いに基づくブラックボックスの観点です。
- 二つの目的を一つの名称へ押し込まず、どちらの観点で何を確認したかを分けて記録します。
結論: 両方式を、内部経路と外部仕様という別の目的で組み合わせる場面です。
問題文から答えを選ぶ手順
編集部の整理テストケースの根拠から選ぶ手順は編集部の学習上の整理です。
- 1
テストケースの根拠を探す
コード、分岐、処理経路からケースを作るのか、仕様、入力条件、期待結果から作るのかを確認します。担当者名や工程名より先に根拠を読みます。
- 2
内部構造を知る必要があるかを見る
どの分岐を通るか確認するには内部構造が必要です。内部実装を知らなくても入力と期待出力を定義できるなら、ブラックボックスの観点です。
- 3
分岐テストを位置付ける
if文の真・偽などコード中の分岐をテストケースで実行する分岐テストは、ホワイトボックス技法として整理します。独立した第三分類にはしません。
- 4
二つの目的を混ぜずに答える
内部経路を通したことと、仕様どおりの出力が得られたことを別々に確認します。両方が書かれているなら、設問がどちらの観点を尋ねているかを一文で言い直します。
試験での見分け方
編集部の整理
- 1内部構造や処理経路を基準にするならホワイトボックステスト。
- 2入力と期待出力を仕様から決めるならブラックボックステスト。
- 3分岐テストはホワイトボックス技法として整理する。
- 4担当者や開発工程だけで方式を決めず、テストケースの根拠を見る。
- 5内部経路の確認と外部仕様の確認は目的が異なるため、必要なら両方を使う。
誤答しやすい選択肢
開発者が行えば必ずホワイトボックスと考える
修正: 誰が行うかではなく、内部構造を使ってテストケースを作るかで判断します。
画面から操作すれば必ずブラックボックスと考える
修正: 操作場所だけで決めません。内部の分岐を狙ってケースを作るならホワイトボックスの観点を含みます。
分岐テストをブラックボックス技法に分類する
修正: 分岐テストはコード中の分岐を基準にするため、ホワイトボックス技法です。
内部経路を通れば仕様も満たしたとみなす
修正: 経路の実行と期待出力の一致は別の確認です。外部振る舞いも分けて確かめます。
確認問題
Q1コード中のif文が取る各分岐を実行するようテストケースを作る方式は？
答え: ホワイトボックステスト
コード内部の分岐と実行経路を基準にケースを作るためです。分岐テストはホワイトボックス技法として整理します。
Q2内部実装を前提にせず、入力に対して仕様どおりの出力が得られるかを確かめる方式は？
答え: ブラックボックステスト
外部から見える入力条件と期待結果を基準にするためです。内部で通ったコード行や分岐を判断根拠にしません。
Q3主要な分岐を実行できたことと、期待出力が得られたことは同じ確認？
答え: 同じではない
前者は内部構造に基づく確認、後者は外部仕様に基づく確認です。必要ならホワイトボックスとブラックボックスの両観点を使います。
到達チェック
- ホワイトボックステストを内部構造と処理経路から説明できる
- ブラックボックステストを入力・出力と期待結果から説明できる
- 分岐テストをホワイトボックス技法として位置付けられる
- 担当者ではなくテストケースの根拠で二つを区別できる
- 内部経路と外部仕様の確認を別目的として説明できる
関連ページで確認する
よくある質問
Qホワイトボックスとブラックボックスは、どちらか一方だけ使う？
一方だけとは限りません。内部経路を確認する目的と、外部仕様どおりの出力を確認する目的は異なるため、必要に応じて両方の観点を使います。
Q分岐テストはどちら？
ホワイトボックステストです。コード中の分岐をテストケースで実行するため、内部構造を判断根拠にします。
Q画面から入力して結果を見るテストは必ずブラックボックス？
操作場所だけでは決まりません。入力と期待出力を仕様から作るならブラックボックスですが、内部の特定分岐を狙っているならホワイトボックスの観点も含みます。
Q試験では何を最初に読む？
テストケースの根拠です。内部のコード・分岐・経路ならホワイトボックス、仕様・入力・期待出力ならブラックボックスと分けます。
執筆: ミナト編集部（運営者情報を見る）