基本情報技術者 2010年 秋期 午前（科目A） 問48

ブラックボックステストにおけるテストケースの設計方法として、適切なものはどれか。【午前2 解説】

要点まとめ

• 結論：ブラックボックステストは内部構造を無視して、機能やインタフェース仕様に基づきテストケースを設計する手法です。
• 根拠：仕様ベースの観点から同値クラステストや境界値分析、状態遷移テストなどを用い、外部から見える振る舞いを検証します。
• 差がつくポイント：仕様の曖昧さを発見し等価クラスや境界を正確に切り分ける力と、インタフェース考慮で例外系を網羅することが合格差になります。

正解の理由

よくある誤解

• 「ブラックボックス＝テストは後で行う」は誤り：ブラックボックスは仕様があればコーディング前でも設計可能で、早期テスト設計に有効です。
• 「インタフェースだけ見れば十分」と考える誤り：インタフェースに加え仕様の同値分割や境界条件、異常系の期待結果も設計する必要があります。
• 「真偽判定を1回ずつ通せば十分」との錯覚：それは条件網羅（白箱の指標）に関する基準であり、ブラックボックスの評価基準とは異なります。

解法ステップ

1. 問題文からキーワードを抽出：「ブラックボックステスト」。
2. 定義を即座に想起：内部実装を見ない、仕様ベースで設計。
3. 選択肢を見て「内部参照」「ロジック経路」「真偽判定網羅」といった語があれば白箱系として除外。
4. 仕様（機能／インタフェース）に基づく設計を述べているものを選択する。

選択肢別の誤答解説

• ア: プログラム仕様書の作成又はコーディングが終了した段階で、仕様書やソースリストを参照して、テストケースを設計する。
  → 誤り。後工程でソースリストを参照するのは白箱的アプローチや実装確認のニュアンスがあり、ブラックボックスの定義（仕様に基づく、実装を見ない）からズレます。
• イ: プログラムの機能仕様やインタフェースの仕様に基づき、テストケースを設計する。
  → 正解。仕様ベースで外部からの振る舞いを検証するブラックボックスの本質を正しく示しています。
• ウ: プログラムの処理手順、すなわちロジック経路に基づき、テストケースを設計する。
  → 誤り。ロジック経路（制御フロー）に着目するのはホワイトボックス（構造化）テストの領域です。
• エ: プログラムのすべての条件判定で、真と偽をそれぞれ1回以上実行させることを基準に、テストケースを設計する。
  → 誤り。これは条件網羅（condition coverage）や判定網羅と呼ばれる白箱的カバレッジ基準であり、ブラックボックスの設計基準ではありません。

補足コラム

• 同値クラステスト（等価クラス）: 入力範囲を有効／無効などのクラスに分け、代表値でテストする。例：年齢入力 0–150 のうち負数・0・正常・上限超えを分類。
• 境界値分析: 境界付近の入力（±0、±1）を重点的に検査する。例：受注数上限が100なら99・100・101をテスト。
• 状態遷移テスト: 状態とイベントの組合せで期待遷移を検証。例：ログイン状態／ログアウト状態での操作許可を確認。
• ユースケース／シナリオテスト: システム利用フロー全体を想定して実務的なケースを作る。
  これらは内部実装に依存せず、要件や外部仕様から直接設計できるため要件定義や仕様レビュー段階でも有効です。

FAQ