ブラックボックステスト

ブラックボックステストでは、システムを中身の見えない箱として扱います。入力を与え、出力を観察し、仕様が定める期待結果と比較します。テスターはプログラミング言語やアーキテクチャ、コードの構造を知る必要がありません。機能テスト、システムテスト、API テスト、受け入れテストの大半はブラックボックステストです。

具体例

送金 API が 1 から 10,000 までの金額を受け付けるとします。コードを一切見なくても、ブラックボックステストの担当者はこのルールからテストを導き出せます。

• 同値分割：範囲より下（0）、有効（500）、範囲より上（10,001）、数値以外（"abc"）。
• 境界値：0、1、2、9,999、10,000、10,001。
• 期待結果：有効な金額は 201 Created を返し、無効な金額はエラーメッセージ付きの 400 Bad Request を返して送金は行われない。

ここで使った同値分割と境界値分析に、デシジョンテーブル、状態遷移テスト、ペアワイズテストを加えたものが、ブラックボックステストの中核となる設計技法です。

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

	ブラックボックス	ホワイトボックス
根拠	要件と仕様	内部のコード構造
必要な知識	システムが何をすべきか	コードがどう書かれているか
主なテストレベル	システム、API、受け入れ	ユニット、一部の結合
測定指標	要件カバレッジ	コードカバレッジ（ステートメント、ブランチ）
見つかるもの	欠けている・誤った振る舞い、仕様との不一致	未テストのパス、デッドコード、ロジックの誤り

どちらも他方の代わりにはなりません。ブラックボックステストは実装されなかった機能を見つけられますが、ホワイトボックステストでは調べるコードが存在しないため見つけられません。ホワイトボックステストは、仕様が触れていないパスを見つけられます。グレーボックステストは両者を組み合わせたもので、インターフェース経由でテストしながら、API 呼び出し後にデータベースを確認する、リクエストがどのサービスに届くかを把握する、といった内部知識を一部活用します。

強みと限界

ブラックボックステストは実装から独立しているため、リファクタリング後もそのまま使え、コードが存在する前に要件から書くこともできます。限界は、どの内部パスを見逃したかが分からないことです。また、体系的な技法を使わないと、分かりやすいハッピーパスだけをテストしがちになります。