平成25年度秋期 システムアーキテクト 午前Ⅱ 問8

テストケース設計の根拠を見極める

ブラックボックステストの設計を考えるときは、手法名を暗記するよりも、各考え方がどの情報を手がかりにしてテストケースを導いているかを整理することが大切です。その手がかりと目的の対応を自分の言葉で説明できるか確かめましょう。

この問題で問われていること

この問題で意識したいのは、テストケースを作る際に参照する情報が何であり、それによって何を確かめようとしているのかという一点です。提示された各内容を、この観点に当てはめて一つずつ吟味してみてください。

視点

ソフトウェアのテストには、何を根拠にテストケースを組み立てるかによって複数の立場があります。ブラックボックステストという呼び名が何を『見えない箱』として扱っているのかを言葉の意味から考えてみましょう。設計時に手がかりとして使う情報と、使わない情報を区別して整理すると、個々の考え方の位置付けが見えやすくなります。

確認ポイント

• テストケースを作る際に参照している情報が何かを、各内容ごとに自分の言葉で説明できるか
• その情報からテストケースを導くことで、何を確かめようとしているのかを整理できているか
• 用語の響きや印象ではなく、参照する情報と目的の組合せに基づいて判断しているか

正解

ウ

解説

ブラックボックステストは、プログラムの内部構造を意識せず、仕様で定められた機能や入力に対する出力が適切かを確認するテストです。したがって、仕様書を基にテストケースを設計する記述が適切です。

理由

ブラックボックステストでは、テスト対象を外部から見た機能として扱う。仕様書に記載された要求機能、入力条件、期待される出力などを基に、利用者の観点でテストケースを作成する。

比較

プログラムの全命令を実行することや、実データの抽出方法を重視する考え方は、ブラックボックステストの本質ではありません。内部の命令や分岐を網羅する観点は、主にホワイトボックステストで用いられる。

選択肢ア

これは不正解だよ。実データから無作為に抽出するだけでは、仕様上必要な機能や境界条件、異常時の動作を十分に確認できるとは限らない。ブラックボックステストでは、データの抽出方法ではなく、外部仕様に基づいて期待結果を検証できることが重要である。

選択肢イ

これは不正解だよ。使用頻度が高い実データを重点的に調べることは、実際の利用状況を参考にする方法の一つにすぎない。頻度の低い入力や例外的な条件も仕様上重要な場合があるため、使用頻度だけを基準にテストケースを設計するのは適切ではない。

選択肢ウ（正解）

これは正解だよ。ブラックボックステストでは、プログラム内部の命令や分岐を直接見るのではなく、仕様書から確認すべき機能と期待される結果を把握してテストケースを設計する。この記述は、外部仕様を基準とする設計方法を正しく示している。

選択肢エ

これは不正解だよ。プログラムの全命令が少なくとも1回実行されるようにするのは、内部構造や命令の実行状況を基準にした考え方である。ブラックボックステストは内部の命令網羅を直接の設計基準とせず、仕様上の機能や入出力を確認する。

学習のポイント

ブラックボックステストとホワイトボックステストの設計基準の違いを整理する。