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

解答の論理構成

• 問題文では「J社では、単体テストとして、ホワイトボックステストとブラックボックステストを行う。」と明記されています。したがって、両者の典型的なテスト項目作成技法を識別することが要求されています。
• ホワイトボックステストはソースコードの内部構造を基に網羅性を測る手法です。典型例として
  • ア：「ユニット内の条件判定の組合せ全てを少なくとも1回は実行する。」（条件組合せ網羅）
  • イ：「ユニットの全ての分岐を少なくとも1回は実行する。」（分岐網羅）
  • ウ：「ユニットの全ての命令を少なくとも1回は実行する。」（命令網羅）
    が挙げられ、いずれも内部ロジックの“網羅率”を量的に保証する観点です。
• 一方、ブラックボックステストは仕様記述や入出力の観点から設計する手法です。代表的なのは
  • エ：「ユニットへの入力データの値の範囲を分割し、各代表値で実行する。」（同値分割・境界値分析）
  • オ：「ユニットへの入力と出力の因果関係を網羅するよう実行する。」（原因結果グラフ）
    であり、プログラム内部を意識せず、外部仕様の正当性を確認します。
• 上記より、模範解答どおり
  • ホワイトボックステスト：ア、イ、ウ
  • ブラックボックステスト：エ、オ
    が論理的に導かれます。

誤りやすいポイント

• 「条件判定の組合せ」と「入力と出力の因果関係」を混同しやすい。前者は内部条件式、後者は仕様レベルの入力–結果マッピングである点を区別する必要があります。
• 「入力データの値の範囲を分割する」技法を“境界値網羅＝内部ロジック確認”と誤認し、ホワイトボックスに分類してしまうケースがあります。
• “命令網羅＝全命令実行”をブラックボックスだと思い込むミス。内部実装の網羅率を測っている時点でホワイトボックスです。

FAQ

解答の論理構成

1. 管理図の基準値を確認
   問題文には「中央値は11件／kステップ、UCLは14件／kステップ、LCLは8件／kステップである。」と示されています。
   したがって各ユニットの欠陥密度が
   • 14より大きい → 上方管理限界を超過（異常値の疑い）
   • 8未満 → 下方管理限界を下回る（テスト不足の疑い）
   • 8以上14以下 → 管理範囲内（正常値）
   と判断できます。
2. 選択肢ごとの検証
   ア：「P1は、UCLを超えており、調査が必要なユニットである。」
   　　 表2より “P1” の欠陥密度は “16.1” 件／kステップで、UCL “14” を超えています。異常値のため調査が必要—正しい。
   イ：「P2, P3, P5, P8は、管理限界に収まっているので、品質が保証される。」
   　　 これらは確かに 8～14 の範囲ですが、管理図は“工程が安定しているか”を見る道具であり、「品質を保証」するものではありません。したがって誤り。
   ウ：「P4, P9は、欠陥が少なく、品質が高い。」
   　　 “P4” は “5.0”、“P9” は “4.4” とLCL “8” を下回ります。欠陥が少ないのではなくテスト網羅が不十分な恐れがあるため、品質が高いと断定できません。誤り。
   エ：「P6は、UCLをわずかに超えているだけなので、今は調査に時間を掛けず、結合テストで経過を監視する。」
   　　 “P6” は “14.1” とUCL “14” を超えています。限界超過は僅差でも直ちに原因究明すべきですから誤り。
   オ：「P7は、テスト項目の精査を行うべきユニットである。」
   　　 “P7” は “6.8” とLCL “8” を下回ります。下方逸脱はテスト不足が疑われ、テスト項目の見直しが必要—正しい。
3. 結論
   よって正しい組合せは「ア、オ」です。

誤りやすいポイント

• 管理図の目的を「品質保証」と誤認しがちですが、本来は“工程の異常検知”です。正常範囲に入っていても欠陥ゼロとは限りません。
• LCL 未満を「優秀」と早合点するケース。むしろテスト不足・データ収集漏れの疑いが濃いことを忘れがちです。
• UCL 超過を「少しだけなら大丈夫」と軽視するミス。限界値は経験統計から決めているため、僅差でも異常シグナルとなります。

FAQ

解答の論理構成

1. 目標値の確認
   【問題文】には「テスト項目の件数は…その目標を1kステップ当たり 100 以上と定めている」とあります。
   つまり必要なテスト項目数＝ステップ数 ÷ 10 です。
2. 各ユニットの実績と比較
   表2から「P2」のステップ数は「5,500」、テスト項目数は「490」です。
   必要項目数は $5,500÷10=550$ なので、実績「490」は目標「550」に未達です。
3. ほかのユニットはどうか
   例として「P1」はステップ数「3,600」で必要項目数「360」、実績「456」で達成。
   同様に P3 〜 P10 も計算すると全て達成しており、未達なのは P2 だけです。
4. 結論
   したがって、問題のあるユニットIDは「P2」、理由は「テスト項目数が目標値よりも少ない」です。

誤りやすいポイント

• 欠陥密度に気を取られてテスト項目数の目標を見落とす。
• 目標値の計算を「100行につき1件」などと誤解し、÷10 を忘れる。
• 「P10」は欠陥密度が高いため目立つが、テスト項目数の観点では目標を満たしている。

FAQ

解答の論理構成

1. 問題文では、L君の作業状況が次のように記述されています。
   ――「重大な欠陥を検出し、ユニット全体に影響するメイン機能の大きな修正を行っていた。そして、その修正を完了した後、直ちに、未消化のテスト項目を実施していた。」
2. 単体テストでは、コードを大きく修正した場合、修正によって既に実行済みのテスト項目の結果が無効になる可能性があります。そのため、修正前に実施済みだったテスト項目を再実行し、修正が副作用を起こしていないか確認する「回帰テスト」が必須です。
3. しかし引用文にあるとおり、L君は修正後「直ちに、未消化のテスト項目」を続行し、再実行（回帰テスト）を行った記載がありません。
4. この欠落により、修正によって再混入した欠陥を見逃し、欠陥密度が「UCL を大きく超過しているユニットP10」という結果につながったと推定できます。
5. 以上から、L君の問題点は「メイン機能修正後に回帰テストを実施していないこと」です。

誤りやすいポイント

• 「テスト項目を 50%消化した時点で修正」とあるため、残り50%の実施だけで十分と誤解しやすい。
• 表2の「同じテスト項目を複数回実行しても重複してカウントしない」というルールを、再実行自体が不要と解釈してしまう。
• 欠陥密度の上昇＝コード品質だけの問題と短絡し、手順不備（回帰テスト漏れ）を見落としやすい。

FAQ

解答の論理構成

1. 欠陥件数の計上誤り
   ― 【問題文】「表3のインタフェース誤りは、全て受注管理から出荷管理へのデータ連携テストで検出されたもので、…欠陥件数は、データの送出側である受注管理だけに計上していた。」
   → 本来は受信側の「出荷管理」にも同数（12件）計上すべきです。
2. 出荷管理の欠陥件数を修正
   ・現状（11月3日の週）の累積欠陥密度：図2より「出荷管理」＝1.2件／kステップ
   ・ステップ数は表1より「出荷管理」＝20,000ステップ＝20kステップ
   ・現状の累積欠陥件数
   $1.2\times 20=24$ 件
   ・インタフェース誤り 12 件を加算
   $24+12=36$ 件
   ・修正後の累積欠陥密度
   $36÷20=1.8$ 件／kステップ
3. 管理図との照合
   ― 【問題文】「UCL は 1.7 件／k ステップ」
   → 1.8件／kステップは UCL を超過。
   よって、修正後に管理図で「問題がある」と判定されるのは出荷管理です。

誤りやすいポイント

• 「インタフェース誤り」を両コンポーネントに計上するルールを見落とし、受注管理だけを調整してしまう。
• 累積欠陥密度の換算で、ステップ数を “20,000” ではなく “20” と読み違え、件数計算を誤る。
• 管理図の UCL（1.7）・LCL（1.2）を取り違え、判定を反転させる。

FAQ