ブラックボックステスト

読み：ぶらっくぼっくすてすと　／　英語表記：black-box testing

内部のプログラム構造を根拠にせず、仕様に示された入力と期待する出力・振る舞いからテストを設計する方法。代表的な技法に同値分割と境界値分析がある。

イマシルちゃんの解説

自動販売機を調べるとき、中の配線を見なくても確かめられることがあるよね。
買える金額を入れたら商品が出るか、足りなければ出ないか、という調べ方だよ。

全部の金額を試すのは大変だから、同じ扱いになるものから代表を選ぶんだ。
扱いが切り替わるところの前後も調べると、うっかりした間違いを見つけやすいよ。

ブラックボックステストは、機能の仕様や業務ルールなど、外から観察できる振る舞いを根拠とする。内部コードを知っている人でも、その構造に依存せずテスト条件を選べば、この方法で設計できる。

入力の一覧だけでは、正しい動作を判定できない。結果を確認するための根拠をテストオラクルと呼ぶ。要求が曖昧な箇所は、テスト実行前に期待する振る舞いを明確にする。

同値分割では、同じように処理されると考えられる入力をまとめ、そのグループを同値クラスとして扱う。全入力を試す代わりに、それぞれから代表値を選ぶ。

独自の例として、「整数の購入個数を2以上8以下で受け付ける」という仕様を考える。

受け付ける側を有効同値クラス、受け付けない側を無効同値クラスとして整理する。空欄や文字列、小数をどう扱うかも別途仕様から洗い出す。一つの代表が通れば、そのグループの全値が絶対に正しいと証明できるわけではない。

境界値分析は、順序のある入力範囲の端や、その近くに注目する。比較演算子の取り違えなどは、範囲の中央だけでは見つけにくい。

先ほどの仕様で端の直前・端・直後を調べるなら、次のようになる。

注目する箇所	入力	期待する結果
下側	1、2、3	拒否、受理、受理
上側	7、8、9	受理、受理、拒否

範囲内の代表だけでなく、範囲外の値も含める。何個の値を採るかは採用する技法やリスクに応じて決め、すべてのテストで一律に六つ必要という意味ではない。

二つの方法は補い合う。コードの全分岐を通っても、仕様にある機能が丸ごと実装されていない欠陥を必ず見つけられるとは限らない。逆に、入力と出力だけからは内部の未実行経路を直接把握できない。

無作為に抽出した実データは現実の組合せを試す助けになるが、まれな異常値や範囲の端が含まれる保証はない。利用頻度に基づく試験も、よく使う操作の評価には有用だが、仕様に基づく系統的な条件選択を置き換えるものではない。

条件が複数ならデシジョンテーブル、操作の順序で結果が変わるなら状態遷移に基づく技法も使う。まず何を検証するかを決め、入力だけでなくエラー時の状態や副作用も確認する。