対象試験と出題頻度
ブラックボックステストは、基本情報技術者・応用情報技術者で出題されるテーマです。
ホワイトボックステストとの対比問題が定番化しており、「同値分割」「限界値分析」「原因結果グラフ」などのテストケース設計手法を正確に区別できるかが問われます。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★★☆
ランクA（重要）必ず覚えておくべき
用語の定義
情報処理試験を勉強していると、「ブラックボックステストとホワイトボックステスト、結局何が違うの？」と混乱しがちです。
ブラックボックステスト（Black-box Testing）とは、一言で言うと
「プログラムの内部構造を一切見ず、仕様書どおりに入力と出力が対応するかを検証するテスト技法」
のことです。
イメージとしては、「自動販売機の動作確認」です。
自販機を点検するとき、内部の配線やコイン判別の仕組みは見ません。120円を入れてボタンを押せば狙ったジュースが出てくるか、50円しか入れていないのにボタンを押しても出てこないか、を外側から確かめるだけです。
ブラックボックステストも同じで、ソースコードを開かずに「この入力ならこの出力が返るはず」という仕様だけを頼りにテストケースを作ります。
📊 ブラックボックステストの基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Black-box Testing（機能テスト） |
| 着目点 | 仕様（入力と出力の関係） |
| 主な実施工程 | 結合テスト・システムテスト・受入テスト |
| 代表的な手法 | 同値分割、限界値分析、原因結果グラフ、デシジョンテーブル |
解説
ソフトウェアの検証アプローチは「内側から見るか、外側から見るか」で2つに分かれます。内側からコードのロジックを追うのがホワイトボックス側、外側から仕様の通りに動くかを確かめるのがブラックボックス側です。
コードが完璧に書けていても、そもそも仕様の解釈を間違えていれば利用者にとっては不具合です。仕様書を真正面から検証するために生まれたのが、外側からのアプローチです。
代表的なテストケース設計手法
外側からテストする場合、考えうる入力をすべて試すのは現実的ではありません。
そこで「効率よくバグを見つけるためのケース選びの作法」が手法として整理されています。FE・APで頻出の4つを押さえます。
| 手法 | 考え方 |
|---|---|
| 同値分割 | 入力値を「同じ結果になるグループ（同値クラス）」に分け、各グループから代表値を1つだけ選ぶ。有効同値と無効同値の両方を選ぶのが定石。 |
| 限界値分析 （境界値分析） |
同値クラスの「境目」を狙い撃ちする。バグは<と<=の取り違えなど境界で起きやすいため、最少コストで最大の検出効果が得られる。 |
| 原因結果グラフ | 入力条件（原因）と出力（結果）の論理関係をグラフ化し、組合せから漏れのないテストケースを導く。 |
| デシジョン テーブル |
複数の条件と動作を表形式で整理し、すべての組合せを網羅する。条件の組合せが複雑な業務ロジックに有効。 |
図解：同値分割と限界値分析（年齢入力欄の例）
「年齢欄に 0〜120 を入力できる」という仕様を例に、同値分割と限界値分析でどんなテストデータが選ばれるかを図にしてみます。
▼ 仕様：年齢入力欄（0〜120を有効値とする）
（負の数）
（121以上）
| 手法 | 選ぶテストデータ |
|---|---|
| 同値分割 | 各グループの代表値：-5（無効）／50（有効）／200（無効） |
| 限界値分析 | 境界の前後：-1, 0, 1 ／ 119, 120, 121 |
▲ 同値分割は「どこか1つ」、限界値分析は「ギリギリの境目」を狙う
ホワイトボックステストとの比較
FE・APの試験では、両者の対比がそのまま選択肢として並ぶパターンが多いため、観点ごとに整理しておきます。
| 観点 | ブラックボックス | ホワイトボックス |
|---|---|---|
| 着目点 | 入力と出力（仕様） | 内部のロジック・制御フロー |
| 主な工程 | 結合・システム・受入テスト | 単体テスト |
| 代表手法 | 同値分割／限界値分析 | 命令網羅／分岐網羅／条件網羅 |
| 仕様抜けの検出 | 得意 | 不得意 |
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 ブラックボックステストの核心を3行で
・内部構造を見ず、仕様の入出力関係に基づいてテストケースを設計する技法
・代表手法は「同値分割（代表値）」「限界値分析（境界値）」の2つを最優先で押さえる
・主に結合テスト以降で使い、単体テスト中心のホワイトボックス側と対をなす
試験ではこう出る！
FE・APの午前問題で繰り返し出題されている定番テーマです。出題パターンは大きく3つに分かれます。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| FE H31春 午前 問47 |
技法に関する記述として最も適切なものを選ぶ問題。 | ・「命令や分岐の網羅率」はホワイトボックス側のひっかけ ・正解は「仕様に基づきテストデータを作成」 |
| FE H30春 問48 / AP H25春 問48 |
テストデータの作成方法を選ぶ問題（FE・APで類題が流用）。 | ・正解は「同値分割や限界値分析で作成」 ・「実データを無作為抽出」「内部分岐を網羅」がひっかけ |
| FE H22秋 午前 問48 |
テストケースの設計方法として適切なものを選ぶ問題。 | ・「同値クラスから代表値」が同値分割 ・「制御パスを網羅」はホワイトボックス側 |
| AP H23秋 午前 問47 |
テストケース設計に関する記述として適切なものを選ぶ問題。 | ・「実データから無作為抽出」は誤り ・仕様ベースのケース設計が正解の方向性 |
📝 IPA試験での出題パターン
パターン1：「技法の説明を選べ」
4択でホワイトボックス・ブラックボックス・回帰テストなどの説明文が並び、正しい組合せを選ぶ形式。キーワードは「仕様に基づく」「入力と出力」「内部構造を見ない」。「命令網羅」「分岐網羅」「制御フロー」が出てきたらホワイトボックス側です。
パターン2：「テストケースを選べ」
「0〜100の入力欄に対して、限界値分析で選ぶデータはどれか」のように、具体的な仕様に対するテストデータを選ぶ形式。境界（最小値・最大値とその±1）を選ぶのが鉄則です。
パターン3：「代表手法を選べ」
同値分割・限界値分析・原因結果グラフ・デシジョンテーブルのうち、どれがブラックボックステストの手法かを問う形式。「実データの無作為抽出」は技法ではないため、ひっかけとしてよく登場します。
深追いすると「ペアワイズ法」「直交表」など発展的な技法も出てきますが、FE・APでは同値分割と限界値分析の2つを確実に押さえればOKです。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. ブラックボックステストの説明として、最も適切なものはどれでしょうか？
- A. プログラムの内部構造（制御フロー）に着目し、命令や分岐に対する網羅率を基準にテストデータを作成する。
- B. プログラムの内部構造を考慮せず、仕様書に基づいて入力と出力の対応を確認するために、同値分割や限界値分析でテストデータを作成する。
- C. 修正によって既存機能に影響が出ていないかを確認するため、過去に成功したテストケースを再実行する。
正解と解説を見る
正解：B
解説：
ブラックボックステストは内部構造を一切参照せず、仕様書に書かれた「この入力にはこの出力が返るはず」という対応関係を検証する技法です。テストケース設計には同値分割や限界値分析を用います。FE H31春 問47の正解と同じ方向性の説明です。
選択肢Aはホワイトボックステストの説明です。命令や分岐の網羅率（C0/C1など）を基準にするのは内部構造に着目するアプローチであり、仕様ベースのブラックボックステストとは対をなします。選択肢Cは回帰テスト（リグレッションテスト）の説明です。修正後に既存機能の動作が壊れていないかを確認する目的別の分類であり、テストデータの設計技法とは別の概念です。
よくある質問（FAQ）
Q. 同値分割と限界値分析は、どちらか片方だけ使えばよいですか？
通常は併用します。同値分割で「どのグループからテストするか」を決め、限界値分析で「グループの端」を狙うという二段構えが定石です。バグは境界条件で起きやすいため、限界値分析だけで多くの欠陥を拾えますが、有効値の中央付近で発生する論理的なバグは限界値分析では捉えにくいため、同値分割で代表値を試す意義があります。
Q. 「ブラックボックス」「機能テスト」「仕様ベーステスト」は同じ意味ですか？
ほぼ同じ意味で使われます。IPAの教材では「ブラックボックステスト」、ISTQB（国際的なテスト技術者認定団体）では「仕様ベーステスト（Specification-based Testing）」と表現します。実務の会話では「機能テスト」と呼ばれることもあります。試験ではブラックボックステストの呼称で統一されているので、それを基準に覚えておけば問題ありません。
Q. 実務ではどのツールでブラックボックステストを行いますか？
UI操作を自動化するSelenium、Playwright、Cypressなどが代表的です。APIレベルではPostmanやREST Assuredが使われます。テストケース管理ツール（TestRail、Qaseなど）に同値分割・限界値分析で導いたケースを登録し、自動化スクリプトと紐付ける運用が一般的です。CI/CDパイプラインで回帰テストとして繰り返し実行されます。
Q. 仕様書がない場合はブラックボックステストはできませんか？
純粋な仕様ベースの設計は難しくなりますが、画面の振る舞いや既存マニュアルから「あるべき動作」を推定して進める「探索的テスト」というアプローチがあります。テスト実施者の経験と直感に依存するため属人化しやすい一方、仕様書が未整備のスタートアップ環境では現実的な選択肢になります。試験範囲としては仕様ベースの技法（同値分割・限界値分析）を押さえれば十分です。
