キャリア

初心者向けブラックボックステスト入門｜種類・手法・観点・例を最短で理解する完全ガイド

ENGINEER.CLUB編集部

• 最終更新日:2026/1/30

システム開発の現場でテスト設計を任されると、
まずぶつかる壁が 「ブラックボックステストって結局どう使えばいいの？」 という疑問です。

• 同値分割と境界値分析の違いが曖昧
• 手法が多くて、どれを選べばいいかわからない
• 観点が抜けているとレビューで指摘される
• テストケースを作るのに時間ばかりかかる
• 基本情報で学んだけれど、実務にどう落とし込むか分からない

こうした悩みは、現場のエンジニア・テスターがほぼ必ず通る道です。

しかし実は、ブラックボックステストは「手順」と「考え方」が分かれば、
誰でも 効率よく・漏れなく・再現性のあるテストケースを作れる ようになります。

本記事では、ブラックボックステストの定義から主要手法、
観点の整理方法、そして実務で迷わない使い分けまでを
3章構成で「最短で理解できる形」にまとめました。

読後には、「今の仕様なら、この手法でこうテストするべき」
と自信を持って判断できるレベルになれる内容になっています。
それではまず、ブラックボックステストの基本から見ていきましょう。

１．ブラックボックステストとは何か

１-１．ブラックボックステストの定義と目的

ブラックボックステストとは、プログラムの内部構造を一切気にせず、
外部仕様（要件・画面・入力と出力）だけを根拠にテストする手法です。

つまり、

• コードを読む必要なし
•  開発者でなくても実施可能
•  「ユーザー視点」で期待通りに動くかを検証する

というのが最大の特徴です。

ブラックボックステストの目的は大きく2つ

1. 仕様通りに動作するか（機能検証）
2. 異常入力に対して正しくエラー処理できるか（堅牢性の検証）

コードの中身（if文やループの内部）は見ません。
あくまで「入力 → 出力が期待通りか」で判断します。

１-２．ホワイトボックステストとの違い

ブラックボックスとホワイトボックスは対極の関係です。
わかりやすく比較すると以下の通り。

ポイント：

• ブラックボックステストは「ユーザー視点」
• ホワイトボックステストは「開発者視点」

どちらか一方では不十分で、両輪で品質を支えます。

１-３．どの工程（単体／結合）で使われるテストか

ブラックボックステストはほぼすべての工程で使われます。

特に 結合 → システム → 受け入れ がメインです。

２．ブラックボックステストの主要手法（4大技法）

ブラックボックステストには多くの手法がありますが、
最初からすべて覚える必要はありません。

結論から言うと、現場で本当によく使うのは次の4つだけです。

1. 同値分割
2. 境界値分析
3. 決定表テスト
4. 状態遷移テスト

それぞれ
「どんなときに使うのか」
「なぜそれが必要なのか」
をセットで説明します。

２-１．同値分割と境界値分析（最も使う2大手法）なぜこの2つが必要なのか？

テストで一番つらいのは、「入力値が多すぎて、全部試せない」ことです。

例：

• 年齢：0～120
• 金額：1～1,000,000
• 日付：無限にある

これを全部テストするのは不可能です。そこで考え方をシンプルにします。

◆同値分割とは？

「結果が同じになる入力は、まとめて1つとして扱う」という考え方です。

例：年齢入力（0～120 が正しい仕様）
このとき、年齢は次のグループに分けられます。

•  ① 0～120 → 正常に登録できる
•  ② 0未満 → エラー
•  ③ 120より大きい → エラー

この３つのグループ（＝同値クラス）から、
それぞれ代表となる値を1つずつ選べば十分です。
例：

• 正常代表：25
• 異常代表：-1
• 異常代表：121

「全部やらないで、代表だけやる」ための手法。それが同値分割です。

◆境界値分析とは？

同値分割だけだと、まだ不安が残ります。
なぜなら、バグは「ギリギリのところ」で起きやすいからです。

例：

•  0はOKだけど -1 は？
• 120はOKだけど 121 は？

この「境目」を重点的にテストするのが境界値分析です。

年齢（0〜120）の場合、テストすべき境界は次の通りです。

• -1（下限の外）
• 0（下限ちょうど）
• 1（下限すぐ上）
• 119（上限すぐ下）
• 120（上限ちょうど）
• 121（上限の外）

「範囲がある入力は、境界を必ず叩く」
これが境界値分析です。

◆現場での使い方（迷ったらこれ）

• 数値・日付・文字数 → 必ず境界値分析
• 入力が多すぎる → 同値分割で減らす

この2つはセットで使われることがほとんどです。

２-２．決定表テスト（条件が多い仕様に強い手法）どんなときに必要？

次のような仕様を見たことはありませんか？

• 会員なら割引あり
• 夜の時間帯は料金アップ
• キャンペーン中はさらに割引

こうなると頭の中はこうなります。
「えっと…この条件とこの条件が重なったらどうなるんだっけ？」
人間の頭だけでは、条件の組み合わせ漏れが必ず起きます。

◆決定表テストの考え方
「条件」と「結果」を表にして、全部の組み合わせを見える化する
それが決定表テストです。

例：料金が決まる条件

• 会員区分　　：一般 / 会員
• 時間帯　　　：昼 / 夜
• キャンペーン：あり / なし

これを表にすると、

表にした瞬間、「抜け」や「仕様矛盾」に気づける
これが最大のメリットです。

いつ使うべき？

• 条件が 3つ以上 出てきた
• IF文が多そうな仕様
• 料金・判定ロジック系

このときは、迷わず決定表を作ってください。

２-３．状態遷移テスト（画面遷移・ステータスのある機能向け）状態って何？

状態とは、「今その機能がどの段階にいるか」です。
例：

• ログイン前 / ログイン後
• 下書き / 申請中 / 承認済み
• カート / 注文済み / 完了

このように、
操作によって状態が変わる機能はとても多いです。

◆状態遷移テストで何を見るのか？

ポイントは2つだけです。

1. 正しい操作で、正しい状態に進むか
2. ありえない戻り方をしないか

例：注文処理

そして重要なのが、

• 完了 → カート に戻れない
• 承認済み → 下書き に戻れない

「本来ありえない遷移」を洗い出す
これが状態遷移テストです。

３．テスト観点とテストケース作成の手順

ブラックボックステストでよくある失敗が、いきなりテストケースを書き始めることです。
正しい順番は次の通りです。

1. 観点を整理する
2. 手法を選ぶ
3. テストケースに落とす

３-１．観点整理の方法（仕様からどう抜き出すか）

仕様書を読んだら、次の4つだけをチェックしてください。

1. 入力：何を入れられる？必須？制限は？
2. 出力：何が表示される？何が返る？
3. 遷移：次にどこへ行く？状態は変わる？
4. 例外：失敗したら？禁止操作は？

例：ログイン画面

• 入力：ID / パスワード（文字数、必須）
• 出力：エラーメッセージ / 成功表示
• 遷移：成功→ホーム、失敗→ログイン画面
• 例外：連続失敗でロックされる？

これが「テスト観点」です。

３-２．手法ごとのテストケース作成例

例① 年齢入力（0〜120）

• 観点　　：数値・範囲あり
• 選ぶ手法：同値分割 + 境界値分析

例② 条件で料金が変わる

• 観点　　：条件が多い
• 選ぶ手法：決定表テスト

→ 表にして 全部確認

例③ 注文ステータス

• 観点　　：状態が変わる
• 選ぶ手法：状態遷移テスト

→ 正常遷移 + 異常遷移を確認

３-３．ブラックボックステストを使い分ける判断基準

迷ったら、これだけ覚えてください。

• 範囲がある → 境界値分析
• 入力が多い → 同値分割
• 条件が多い → 決定表
• 状態がある → 状態遷移

４．まとめ

ブラックボックステストは、難しい理論ではありません。

• ユーザーとしてどう使うか考える
• 入力・出力・状態・例外を見る
• 状況に合った手法を選ぶ

これだけです。

「今の仕様なら、まず境界値を見るな」
「条件多いから決定表にしよう」

そう判断できるようになれば、
ブラックボックステストはもう怖くありません。