応用情報技術者 2009年 秋期 午後 問08
開発プロセスでのテストに関する次の記述を読んで、設問1~4に答えよ。
A社は、顧客の製造プラントの設備診断システムを開発することになった。設備診断システムは、プラント内の各設備の温度・湿度・振動の情報を収集し、設備の正常・異常などの診断レポートを作成するシステムであり、測定装置サブシステムと診断サブシステムから構成される。図1は設備診断システムのDFDである。測定装置サブシステムの開発は、設備に装着可能な専用コンピュータを使用するので、専用コンピュータの開発元であるB社に委託し、A社は診断サブシステムの開発を行うことになった。

測定装置サブシステムは、温度測定、湿度測定、振動測定の各プロセスから成り、それぞれがセンサを用いて設備の温度・湿度・振動を測定し、センサデータとして保存する。診断サブシステムの測定データ収集プロセスは、これらセンサデータを定期的に収集し、測定データとして蓄積する。
正しいセンサデータは、設備やセンサの種類に応じてそれぞれ定められた範囲の数値データであり、各設備が問題なく運転できる正常値の範囲と、問題となる異常値の範囲に分けられる。正常値でも異常値でもないデータが保存されている場合は、測定データ収集プロセスが、これを不正データとして処理する。不正データの原因には、センサの故障がある。測定装置サブシステムのセンサデータにアクセスし、データを収集するには、B社が提供するセンサデータ読出し関数を診断サブシステムのプログラムから呼び出す必要がある。
設備情報登録プロセスは、各設備の正常値の範囲と異常値の範囲を設備情報として登録する。診断データ作成プロセスは、測定データと設備情報から、診断データを作成する。診断レポート作成プロセスは、診断データを基に、診断レポートを作成する。
図2は、設備診断システム開発プロジェクトの日程である。

図2の中で、運用テストは顧客の分担であり、実運用環境での動作検証、初期データの確認、システムを利用する保守担当者の訓練が主目的である。
C君はA社の開発チームに所属し、設備診断システムのテスト計画を立案することになった。担当する範囲は、図2の工程(8)~(12)のテスト工程である。最初にC君は、テスト工程ごとに、そこで確認すべき要求事項がどの工程で定義されているかと、テストの目的とをテスト工程定義として表のように設定した。

テスト実施方法の検討に当たって、C君は、A社とB社が開発するサブシステム間でのデータ連携の検証が重要であると考えた。A社による診断サブシステムのプログラム作成、テストの工程と、B社による測定装置サブシステムのプログラム作成、テストの工程を並行に実施した後、両サブシステムを初めて組み合わせるソフトウェア結合テストにおいて、設計上の不整合やプログラムミスなどから不良が発生し、工程遅延を引き起こすリスクがあると予想した。そのため、dにおいて、スタブを有効に活用する必要があると考えた。
また、システム結合テストでは、eを基本とする。具体的には、同値分割やfを行って、テストケースを作成する必要があると考えた。
その後、プロジェクトは予定どおり開始され、現在はシステム結合テストの準備中である。C君は、システム結合テストの準備を担当しているD君が作成したテストケースのレビューを行った。D君は、同値分割において、設備情報で設備ごとに指定されている測定データの正常値の範囲と異常値の範囲を同値クラスとしていた。C君は、これではテストケースとして不十分であり、同値クラスの追加を指示する必要があると考えた。
設問1:
表及び本文中のa〜dに入れる適切な工程を図2の中から選び(1)〜(14)の番号で答えよ。
模範解答
a:(7)
b:(3)
c:(1)
d:(8)
解説
解答の論理構成
-
表の該当箇所を確認
- 問題文には「表 テスト工程定義」があり、(8)〜(12) の各工程で “[ ]” が空欄になっています。
- 例えば (8) 行には
「(8) 診断サブシステムプログラム作成、テスト」「診断サブシステムのプログラムが、aどおり実現されていることの確認」
と明記されています。
-
“どの工程で定義された要求事項を検証するか” という視点
- ソフトウェア開発では V モデルに従い、
詳細設計 → プログラム作成・単体テスト
要件定義 → 適格性確認テスト
となるのが基本です。 - 問題文の記述と V モデルを突き合わせると次の対応が自然に導けます。
- ソフトウェア開発では V モデルに従い、
詳細設計 → プログラム作成・単体テスト
-
各空欄の導出
a. a- 単体テストでは詳細設計との差分を確認するのがセオリー。
- 図2 で詳細設計に相当する工程番号は「(7) 診断サブシステム ソフトウェア詳細設計」。
- よって a = (7)。
b. b- 「ソフトウェア適格性確認テスト」はソフトウェア要件に対する適合性を評価する工程。
- 図2 で該当するのは「(3) ソフトウェア要件定義」。
- よって b = (3)。
c. c- 「システム適格性確認テスト」はシステム要件を満たしているかを確認する最終段階。
- 図2 の「(1) システム要件定義」が対応。
- よって c = (1)。
d. d- 問題文には
「両サブシステムを初めて組み合わせるソフトウェア結合テストにおいて…工程遅延を引き起こすリスク…そのため、dにおいて、スタブを有効に活用する必要がある」
とあります。 - リスクを低減するには、結合前に各社単独のプログラム作成・テスト段階でスタブを入れて相手機能を仮想化するのが一般的。
- A社が担当する該当工程は図2 の「(8) 診断サブシステム プログラム作成、テスト」。
- よって d = (8)。
-
結論
- a:(7)
- b:(3)
- c:(1)
- d:(8)
誤りやすいポイント
- 単体テストの参照元を「ソフトウェア方式設計」と勘違いしやすい
(方式設計ではなく詳細設計が対象)。 - 「適格性確認テスト」は“要件定義”にトレーサビリティを取ることを忘れがち。
- スタブ/ドライバの利用場面を結合テストと混同し、「(9) ソフトウェア結合テスト」を選んでしまうケースが多い。
FAQ
Q: “ソフトウェア結合テスト” でスタブを使ってはいけないのですか?
A: 使ってはいけないわけではありませんが、本問の狙いは“結合時に遅延が起こらないよう、前工程でスタブを活用しておく”というリスク低減策を見抜くことにあります。
A: 使ってはいけないわけではありませんが、本問の狙いは“結合時に遅延が起こらないよう、前工程でスタブを活用しておく”というリスク低減策を見抜くことにあります。
Q: “システム適格性確認テスト” と “運用テスト” の違いは?
A: 前者は開発側がシステム要件を満たすかどうかを最終確認する工程、後者は顧客側が実運用環境で運用手順やデータを検証する工程です。
A: 前者は開発側がシステム要件を満たすかどうかを最終確認する工程、後者は顧客側が実運用環境で運用手順やデータを検証する工程です。
Q: “適格性確認テスト” という言葉がピンと来ません。一般的な呼称は?
A: ISO/IEC 25051 等での正式名称ですが、一般には“受入テスト(ソフトウェア受入テスト/システム受入テスト)”と呼ばれることが多いです。
A: ISO/IEC 25051 等での正式名称ですが、一般には“受入テスト(ソフトウェア受入テスト/システム受入テスト)”と呼ばれることが多いです。
関連キーワード: Vモデル、単体テスト、結合テスト、スタブ、トレーサビリティ
設問2:
A社とB社の並行開発期間中に、診断サブシステムのテストのために用意すべきスタブは何か。本文中の字句を用いて答えよ。
模範解答
センサデータ読出し関数
解説
解答の論理構成
- サブシステム間の並行開発
問題文では、A社とB社の開発を「並行に実施」すると述べています。B社のモジュールが未完成の間にA社がテストを進めるには、呼び出し先の代替物(スタブ)が不可欠です。 - 呼び出しインタフェースの特定
A社が外部に依存する唯一のインタフェースは、問題文にある
「B社が提供するセンサデータ読出し関数を診断サブシステムのプログラムから呼び出す」
という部分です。ここがスタブ化の対象になります。 - スタブを使用する工程の確認
スタブ活用が必要とされる工程は、d=「診断サブシステム プログラム作成、テスト」です。つまり、この工程で B社の機能を仮実装しなければ、単体テストすら実行できません。 - 以上より、診断サブシステム側で用意すべきスタブは「センサデータ読出し関数」と結論づけられます。
誤りやすいポイント
- 測定装置サブシステム全体をスタブ化すると勘違いする
実際に診断サブシステムが直接呼び出すのは「センサデータ読出し関数」だけです。 - スタブの使用場所をソフトウェア結合テストだと思い込む
結合テストは両サブシステムを合わせる工程なので、むしろスタブは不要です。必要なのは単体・詳細テストの段階。 - 「センサデータ」そのものをスタブ化すると回答する
データではなく、データを提供する関数(インタフェース)をスタブ化する点に注意が必要です。
FAQ
Q: スタブとドライバの違いは何ですか?
A: スタブは下位呼び出し先を仮実装するもの、ドライバは上位モジュールを仮実装してテスト対象を呼び出すものです。本設問は下位側(B社機能)の代替なのでスタブです。
A: スタブは下位呼び出し先を仮実装するもの、ドライバは上位モジュールを仮実装してテスト対象を呼び出すものです。本設問は下位側(B社機能)の代替なのでスタブです。
Q: スタブは実際に何を返せばよいですか?
A: 典型的には正常系・異常系・境界値など、診断サブシステムが期待する形式で固定値や擬似データを返します。測定値の同値クラスを設計し、テスト目的に応じて切り替えられるようにします。
A: 典型的には正常系・異常系・境界値など、診断サブシステムが期待する形式で固定値や擬似データを返します。測定値の同値クラスを設計し、テスト目的に応じて切り替えられるようにします。
Q: スタブは結合テストでも使えますか?
A: 基本は単体・詳細テスト用ですが、上位システムが揃わない一部機能試験などで限定的に用いることはあります。ただし本プロジェクト計画では結合テスト時点で両サブシステムがそろう想定です。
A: 基本は単体・詳細テスト用ですが、上位システムが揃わない一部機能試験などで限定的に用いることはあります。ただし本プロジェクト計画では結合テスト時点で両サブシステムがそろう想定です。
関連キーワード: スタブ、インタフェース、単体テスト、モジュール結合、代替実装
設問3:
本文中のe、fに入れる適切な字句を解答群の中から選び、記号で答えよ。
eに関する解答群
ア:運用テスト
イ:パリティチェック
ウ:ブラックボックステスト
エ:ホワイトボックステスト
オ:モジュールテスト
fに関する解答群
ア:限界値分析
イ:条件網羅テスト
ウ:静的テスト
エ:ビッグバンテスト
オ:命令網羅テスト
模範解答
e:ウ
f:ア
解説
解答の論理構成
-
該当箇所の確認
【問題文】には、"システム結合テストでは、eを基本とする。具体的には、同値分割やfを行って、テストケースを作成する必要がある"
と明記されています。この一文から、e と f は「システム結合テストで採用するテスト手法・テスト設計技法」に関係する語句であることが分かります。 -
e の決定
- システム結合テストは、サブシステム間インタフェースや機能を外部仕様ベースで検証する工程です。
- コード内部の経路に着目する「ホワイトボックステスト」ではなく、外部から入出力だけを観察する「ブラックボックステスト」が基本になります。
- 解答群には
- ウ:ブラックボックステスト
が該当するため、e=「ウ」と判断できます。
- ウ:ブラックボックステスト
-
f の決定
- 具体的なテスト設計技法として “同値分割” と並列で挙げられる代表は “限界値分析” です。
- 同値分割は入力値を同じ振る舞いのグループに分け、限界値分析はその境界値でテストケースを作る手法で、両者はセットで紹介されることが多いブラックボックス系技法です。
- 解答群には
- ア:限界値分析
があるため、f=「ア」と確定します。
- ア:限界値分析
-
よって模範解答
- e:ウ
- f:ア
誤りやすいポイント
- 「ホワイトボックステスト」と誤答するパターン
システム結合テストでは詳細コードよりもサブシステム間のやり取りを重視するため、内部構造を解析するホワイトボックスは適しません。 - “条件網羅テスト” “命令網羅テスト”といった構造網羅系技法を f に選ぶミス
同値分割と並べて記述されるのは入力データ中心の技法が多く、構造網羅は文脈に合いません。 - 「運用テスト」や「モジュールテスト」を e に選ぶ混同
テストレベルとテスト手法を取り違えないよう注意が必要です。
FAQ
Q: システム結合テストでブラックボックスを採用するのはなぜですか?
A: サブシステム間インタフェースや外部仕様が要件どおりかを確認する工程だからです。内部ロジックを意識せず、入出力の観点で網羅的に検証する方が効果的です。
A: サブシステム間インタフェースや外部仕様が要件どおりかを確認する工程だからです。内部ロジックを意識せず、入出力の観点で網羅的に検証する方が効果的です。
Q: 同値分割と限界値分析はいつ使い分けますか?
A: 基本はセットで用います。同値分割で代表値を選び、さらに境界付近の値を限界値分析で抽出するとテスト効率が高まります。
A: 基本はセットで用います。同値分割で代表値を選び、さらに境界付近の値を限界値分析で抽出するとテスト効率が高まります。
Q: システム結合テストでホワイトボックス技法を全く使わないのですか?
A: メインはブラックボックスですが、障害解析や追加リスクが判明した場合に限定的にホワイトボックスを補助的に利用することはあります。
A: メインはブラックボックスですが、障害解析や追加リスクが判明した場合に限定的にホワイトボックスを補助的に利用することはあります。
関連キーワード: ブラックボックステスト、同値分割、限界値分析、システム結合テスト
設問4:
D君が追加すべき同値クラスは何か。本文中の字句を用いて答えよ。
模範解答
不正データ
解説
解答の論理構成
-
C君がレビューした時点の状況
D君は「設備情報で設備ごとに指定されている測定データの正常値の範囲と異常値の範囲を同値クラスとしていた」とあります。つまり、同値クラスは
・正常値の範囲
・異常値の範囲
の2つだけで作成されていました。 -
しかし要求仕様にはもう1種類のデータが存在
問題文には次の記述があります。
――「正常値でも異常値でもないデータが保存されている場合は、測定データ収集プロセスが、これを不正データとして処理する。」
ここで “正常値でも異常値でもないデータ” = “不正データ” が明示されています。 -
テスト設計技法(同値分割)の観点
同値分割では、入力領域を互いに重複しない同値クラスに分け、それぞれから代表値を選びます。正常値クラスと異常値クラスだけでは、“正常でも異常でもない領域” がテスト対象から漏れてしまい、網羅性が不足します。 -
したがって追加すべき同値クラス
「正常値でも異常値でもない」入力を代表するクラス、すなわち “不正データ” を追加する必要があります。 -
結論
追加すべき同値クラスは「不正データ」となります。
誤りやすいポイント
- 正常/異常を2分割した時点で安心してしまい、問題文に登場する第3の区分「不正データ」を見落とす。
- “異常値” と “不正データ” を同一視してしまう。異常値は仕様で想定された範囲外の値だが、それでも有効入力として処理フローが定義されている。一方、不正データは仕様が想定していない値であり、別の例外処理が必要。
- 同値分割では境界値分析も組み合わせることが多いが、本問ではまず同値クラスの網羅性が問われていると気付かず、境界値の有無だけを確認してしまう。
FAQ
Q: 不正データは具体的にどのような値を指すのですか?
A: 問題文に例示はありませんが、センサの故障や通信異常で発生した “規定範囲外かつ数値として成立しない” データなどが想定されます。正常値・異常値のどちらにも該当しないため、専用のエラーハンドリングを確認することが重要です。
A: 問題文に例示はありませんが、センサの故障や通信異常で発生した “規定範囲外かつ数値として成立しない” データなどが想定されます。正常値・異常値のどちらにも該当しないため、専用のエラーハンドリングを確認することが重要です。
Q: 異常値クラスと不正データクラスは同じテストケースにまとめても良いですか?
A: 同値分割の原則では、振る舞いが異なる場合は別クラスに分けます。問題文には異常値は診断対象として扱い、不正データは「測定データ収集プロセスが…処理する」と別動作が示されているので、別クラスとするのが正解です。
A: 同値分割の原則では、振る舞いが異なる場合は別クラスに分けます。問題文には異常値は診断対象として扱い、不正データは「測定データ収集プロセスが…処理する」と別動作が示されているので、別クラスとするのが正解です。
Q: 境界値分析はどの工程で行うのが適切ですか?
A: 本問の流れでは「システム結合テスト」で「同値分割やfを行って、テストケースを作成」とあり、ここで境界値分析も併用して詳細なテストケースを設計します。
A: 本問の流れでは「システム結合テスト」で「同値分割やfを行って、テストケースを作成」とあり、ここで境界値分析も併用して詳細なテストケースを設計します。
関連キーワード: 同値分割、境界値分析、不正データ処理、サブシステム連携、テストケース設計


