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

テスト設計の根拠を確かめる

テストケースの設計方法を考えるときは、何を手がかりにしてケースを導き出しているのかを意識することが大切です。用語の印象だけで判断せず、設計の出発点となる情報に注目して各項目を一つずつ吟味しましょう。

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

この分野では、テスト対象のどの側面を観察し、どんな情報をもとにテストの入力や期待結果を決めるのかが問われやすい点です。設計の拠り所を正確に捉えられるかどうかが検討の中心になります。

視点

テスト設計の手法は、何を根拠にケースを作るかという観点で整理すると理解しやすくなります。手法の名前を覚えるだけでなく、それぞれがどの情報を出発点にし、どのような狙いでケースを選んでいるのかを自分の言葉で説明できるか確認してください。

確認ポイント

• その設計方法が何の情報を出発点にしてケースを作っているかを言えるか
• 設計の根拠と、そのテストで確かめたい事柄が対応しているか
• 用語の響きではなく、設計の根拠の説明に基づいて判断しているか

正解

ウ

解説

ブラックボックステストは、プログラム内部の命令や分岐を調べるのではなく、仕様書に示された機能と入出力の関係を基にテストケースを設計する。したがって、仕様書で機能を確認する記述が適切です。

理由

ブラックボックステストでは、プログラムの内部構造や命令の実行状況をテスト設計の直接の根拠にしない。仕様書からプログラムが果たす機能を確認し、外部から観測できる入力と出力の関係を検証する。

比較

実データの抽出方法や使用頻度に着目するだけでは、仕様上必要な機能や境界条件を十分に確認できない。一方、全命令を実行させる考え方は、内部構造を基準にするホワイトボックステストに該当する。

選択肢ア

これは不正解だよ。実データからテストデータを無作為に抽出するだけでは、仕様書に定められた機能や入力条件を網羅的に確認できない。ブラックボックステストは、抽出方法の無作為性ではなく、外部仕様に基づく入出力の確認を重視する。

選択肢イ

これは不正解だよ。実データのうち使用頻度が高いものを重点的に抽出しても、使用頻度の低い入力や仕様上重要な条件を確認できるとは限らない。テストケースは頻度だけでなく、仕様に示された機能や期待結果を根拠に設計する必要がある。

選択肢ウ（正解）

これは正解だよ。ブラックボックステストでは、プログラム内部の命令や処理手順を調べるのではなく、仕様書からプログラムが果たす機能を確認してテストケースを設計する。外部から観測できる入力と出力を基準にするため、この記述が適切である。

選択肢エ

これは不正解だよ。プログラムの全命令が少なくとも1回は実行されるようにする考え方は、命令網羅などの内部構造に基づくテスト設計である。これはホワイトボックステストの観点であり、仕様上の機能を基準にするブラックボックステストの説明ではない。

学習のポイント

ブラックボックステストとホワイトボックステストの設計根拠を区別して理解する。