応用情報技術者 2009年 秋期 午後 問08

解答の導き方

1. テスト工程名は「診断サブシステム プログラム作成、テスト」です。プログラム作成・テストの段階で検証すべきは、プログラムがどの設計どおりに作られているか、すなわち詳細設計どおりかどうかです。
2. 図2で「診断サブシステム ソフトウェア詳細設計」は工程 (7) に対応しており、(7) が (8) の直前工程になっています。したがって (8) が確認すべき要求事項を定義する工程は (7) です。
   → a：(7)

1. 「ソフトウェア適格性確認テスト」は、ソフトウェアが要求どおりに実現されているかを確認するテストです。受け入れ／適格性の観点では、設計そのものではなく要求（要件）を基準にします。
2. 図2で「ソフトウェア要件定義」は工程 (3) に対応しています。よってソフトウェア適格性確認テストが参照すべき要求定義は (3) の「ソフトウェア要件定義」です。
   → b：(3)

1. 「システム適格性確認テスト」は、システム全体が要件どおりに実現されているかを確認する工程です。システムレベルの適格性は「システム要件定義」を基準に評価します。
2. 図2で「システム要件定義」は工程 (1) です。よって (12) の参照先は (1) になります。
   → c：(1)

1. 本文には「測定装置サブシステムのセンサデータにアクセスし、データを収集するには、B社が提供するセンサデータ読出し関数を診断サブシステムのプログラムから呼び出す必要がある。」とあります。診断サブシステム（A社側）のプログラムは、B社提供の関数を呼び出す設計です。
2. A社とB社がサブシステムを並行開発しているため、A社が自らのプログラムをテストする段階でB社の実装が未完成・未提供である可能性があります。この場合、呼び出される側の実装を代替する「スタブ」を使って、呼び出しインタフェースや戻り値の取り扱いを検証すると、ソフトウェア結合テスト（(9)）での結合不具合発生リスクを下げられます。
3. したがってスタブを有効に使うのは診断サブシステムのプログラム作成・テストの工程、すなわち (8) が適切です。
   → d：(8)

誤りやすいポイント

• 表の空欄を見落とす／誤認する
  • 表をよく見ずに「(8)〜(12) が全部空欄」と誤認する人がいます。実際は空欄は (8),(10),(12) のみで、(9) と (11) は既に設定されています。
• テストレベルと参照すべき設計書の対応を取り違える
  • プログラム作成・テストは「ソフトウェア詳細設計」を基準、結合テストは「方式設計」を基準、適格性確認（受入）は「要件定義」を基準、という対応を押さえてください。
• スタブとドライバの混同
  • モジュールAがモジュールBを呼ぶ構造でBが未実装ならA側は「スタブ」を使ってBを代替します。逆にBを単体でテストする際に呼び出し元が未実装なら「ドライバ」を用います。今回の文脈では診断側が呼び出すのでスタブです。
• 工程番号の読み違い（(6)と(8)など）
  • 測定装置側の作業は (6) で、診断サブシステム側の作業は (8) です。スタブを使うのは診断側の (8) ですから、(6) を選ばないよう注意してください。
• 同値分割の誤り（D君の例）
  • 問題文に「正常値でも異常値でもないデータが保存されている場合は、測定データ収集プロセスが、これを不正データとして処理する。」とあります。単に「正常」「異常」だけを同値クラスにするのは不十分で、「不正データ」や境界値、形式不正などのクラスを追加する必要があります。

FAQ

解答の論理構成

1. サブシステム間の並行開発
   問題文では、A社とB社の開発を「並行に実施」すると述べています。B社のモジュールが未完成の間にA社がテストを進めるには、呼び出し先の代替物（スタブ）が不可欠です。
2. 呼び出しインタフェースの特定
   A社が外部に依存する唯一のインタフェースは、問題文にある
   「B社が提供するセンサデータ読出し関数を診断サブシステムのプログラムから呼び出す」
   という部分です。ここがスタブ化の対象になります。
3. スタブを使用する工程の確認
   スタブ活用が必要とされる工程は、d＝「診断サブシステム プログラム作成、テスト」です。つまり、この工程でB社の機能を仮実装しなければ、単体テストすら実行できません。
4. 以上より、診断サブシステム側で用意すべきスタブは「センサデータ読出し関数」と結論づけられます。

誤りやすいポイント

• 測定装置サブシステム全体をスタブ化すると勘違いする
  実際に診断サブシステムが直接呼び出すのは「センサデータ読出し関数」だけです。
• スタブの使用場所をソフトウェア結合テストだと思い込む
  結合テストは両サブシステムを合わせる工程なので、むしろスタブは不要です。必要なのは単体・詳細テストの段階。
• 「センサデータ」そのものをスタブ化すると回答する
  データではなく、データを提供する関数（インタフェース）をスタブ化する点に注意が必要です。

FAQ

解答の論理構成

1. 該当箇所の確認
   【問題文】には、

   "システム結合テストでは、eを基本とする。具体的には、同値分割やfを行って、テストケースを作成する必要がある"
   と明記されています。この一文から、e と f は「システム結合テストで採用するテスト手法・テスト設計技法」に関係する語句であることが分かります。

2. e の決定
   • システム結合テストは、サブシステム間インタフェースや機能を外部仕様ベースで検証する工程です。
   • コード内部の経路に着目する「ホワイトボックステスト」ではなく、外部から入出力だけを観察する「ブラックボックステスト」が基本になります。
   • 解答群には
     • ウ：ブラックボックステスト
       が該当するため、e＝「ウ」と判断できます。
3. f の決定
   • 具体的なテスト設計技法として “同値分割” と並列で挙げられる代表は “限界値分析” です。
   • 同値分割は入力値を同じ振る舞いのグループに分け、限界値分析はその境界値でテストケースを作る手法で、両者はセットで紹介されることが多いブラックボックス系技法です。
   • 解答群には
     • ア：限界値分析
       があるため、f＝「ア」と確定します。
4. よって模範解答
   • e：ウ
   • f：ア

誤りやすいポイント

• 「ホワイトボックステスト」と誤答するパターン
  システム結合テストでは詳細コードよりもサブシステム間のやり取りを重視するため、内部構造を解析するホワイトボックスは適しません。
• “条件網羅テスト” “命令網羅テスト”といった構造網羅系技法を f に選ぶミス
  同値分割と並べて記述されるのは入力データ中心の技法が多く、構造網羅は文脈に合いません。
• 「運用テスト」や「モジュールテスト」を e に選ぶ混同
  テストレベルとテスト手法を取り違えないよう注意が必要です。

FAQ

解答の論理構成

1. C君がレビューした時点の状況
   D君は「設備情報で設備ごとに指定されている測定データの正常値の範囲と異常値の範囲を同値クラスとしていた」とあります。つまり、同値クラスは
   ・正常値の範囲
   ・異常値の範囲
   の2つだけで作成されていました。
2. しかし要求仕様にはもう1種類のデータが存在
   問題文には次の記述があります。
   ――「正常値でも異常値でもないデータが保存されている場合は、測定データ収集プロセスが、これを不正データとして処理する。」
   ここで “正常値でも異常値でもないデータ” ＝ “不正データ” が明示されています。
3. テスト設計技法（同値分割）の観点
   同値分割では、入力領域を互いに重複しない同値クラスに分け、それぞれから代表値を選びます。正常値クラスと異常値クラスだけでは、“正常でも異常でもない領域” がテスト対象から漏れてしまい、網羅性が不足します。
4. したがって追加すべき同値クラス
   「正常値でも異常値でもない」入力を代表するクラス、すなわち “不正データ” を追加する必要があります。
5. 結論
   追加すべき同値クラスは「不正データ」となります。

誤りやすいポイント

• 正常／異常を2分割した時点で安心してしまい、問題文に登場する第3の区分「不正データ」を見落とす。
• “異常値” と “不正データ” を同一視してしまう。異常値は仕様で想定された範囲外の値だが、それでも有効入力として処理フローが定義されている。一方、不正データは仕様が想定していない値であり、別の例外処理が必要。
• 同値分割では境界値分析も組み合わせることが多いが、本問ではまず同値クラスの網羅性が問われていると気付かず、境界値の有無だけを確認してしまう。

FAQ