2014年 秋期 応用情報技術者試験 問8
ソフトウェアのテストに関する次の記述を読んで、設問1〜3に答えよ。
J社は、自社の販売管理システムを再構築するプロジェクトを実施している。プロジェクトでは、設計者が要件定義、方式設計を行った後、ソフトウェアコンポーネント(以下、コンポーネントという)の詳細設計を行う。その後、構築において、開発者がコンポーネントを構成するソフトウェアユニット(以下、ユニットという)のコード作成と単体テストを行う。そして、結合において、コンポーネント内のユニット間、及びコンポーネント間の結合テストを行う。K君はプロジェクトマネージャを務めている。
販売管理システムは、出荷管理、顧客管理、受注管理、見積り管理の四つのコンポーネントから成る。表1に、これらのコンポーネントのステップ数を示す。
コンポーネント | ステップ数 |
---|---|
出荷管理 | 20,000 |
顧客管理 | 10,000 |
受注管理 | 21,000 |
見積り管理 | 51,700 |
[単体テストの実施と結果の分析]
J社では、単体テストとして、ホワイトボックステストとブラックボックステストを行う。テスト項目の件数は、ユニットへの入力の組合せ数でカウントし、その目標を1kステップ当たり100以上と定めている。ただし、回帰テストのために同じテスト項目を複数回実行しても重複してカウントしない。テストにおいて期待どおりの処理結果とならない場合には、その原因となる欠陥を特定し、ユニットごとにその欠陥件数をカウントする。
出荷管理、顧客管理、受注管理は、コンポーネントを構成するユニットの単体テストを予定どおりに完了し、結合テストを実施中である。見積り管理は、他よりも遅れて単体テストを完了し、K君がテスト結果を確認中である。表2は、見積り管理の各ユニットの単体テストで検出された欠陥件数である。
ユニットID | ステップ数 | テスト項目数 | 欠陥件数 | 欠陥密度(件/kステップ) |
---|---|---|---|---|
P1 | 3,600 | 456 | 58 | 16.1 |
P2 | 5,500 | 490 | 55 | 10.0 |
P3 | 4,800 | 558 | 42 | 8.8 |
P4 | 5,400 | 730 | 27 | 5.0 |
P5 | 7,200 | 828 | 81 | 11.3 |
P6 | 6,300 | 660 | 89 | 14.1 |
P7 | 5,700 | 600 | 39 | 6.8 |
P8 | 4,200 | 450 | 42 | 10.0 |
P9 | 5,400 | 600 | 24 | 4.4 |
P10 | 3,600 | 390 | 63 | 17.5 |
K君は表2を基に図1の欠陥密度の管理図を作成した。この図の縦軸は欠陥密度、横軸はユニットIDである。管理図分析では、しきい値モデルを使用し、データの分布がUCL(Upper Control Limit:上部管理限界)とLCL(Lower Control Limit:下部管理限界)に対してどの位置にプロットされるかを見て、データが正常値であるか異常値であるかを判断する。K君は、J社の単体テストで検出された欠陥密度の過去の実績値の四分位点を利用し、LCLに第1四分位点の値を、中央値に第2四分位点の値を、UCLに第3四分位点の値を置いた。J社の過去の実績値から中央値は11件/kステップ、UCLは14件/kステップ、LCLは8件/kステップである。
管理図から、K君は、欠陥密度がUCLを大きく超過しているユニットP10は、品質に問題がある可能性が高いと考えた。P10の構築を担当したのは、入社2年目のL君である。L君にヒアリングしたところ、テスト開始当初から多くの欠陥を検出し、
テスト項目を50%消化した時点で、重大な欠陥を検出し、ユニット全体に影響するメイン機能の大きな修正を行っていた。そして、その修正を完了した後、直ちに、未消化のテスト項目を実施していた。K君は、①L君の単体テストの実施方法に問題があると考え、やり直しを指示した。
[結合テストの実施と欠陥発生状況の分析]
見積り管理を除く三つのコンポーネントについて、結合テストを実施中である。K君は、結合テストにおいて、品質の低いコンポーネントを早い時点で検出して対策を取ることで、工程の遅延を防ぐことを考えた。そこで、テストの実施中から、欠陥の検出状況を、管理図を用いて確認することにした。図2は、結合テストで検出された累積欠陥密度の管理図である。この図の縦軸は、各コンポーネントの結合テストで検出された累積欠陥密度であり、横軸は、結合テストの日程である。結合テストは9月29日の週から開始し、11月17日の週に完了する予定である。J社の結合テストで検出された累積欠陥密度の過去の実績値から、中央値は1.4件/kステップ、UCLは1.7件/kステップ、LCLは1.2件/kステップである。現在、11月9日であり、週初日が11月3日の週を終えたところである。結合テストのテスト項目数はJ社の目標値を満たしており、消化状況も予定どおりである。
K君は、受注管理が既にUCLを超えているので、原因を調査することにした。表3は、受注管理の結合テストで検出された欠陥の内訳である。
欠陥分類 | 欠陥内容 | 欠陥件数 |
---|---|---|
仕様不良 | 要件定義漏れ | 1 |
詳細設計漏れ(詳細設計での機能定義漏れ) | 3 | |
詳細設計誤り(詳細設計での機能の設計誤り) | 4 | |
ユニットのコード不良 | インタフェース誤り | 12 |
コード漏れ(必要なコードの記述漏れ) | 14 | |
その他 | コード誤り(コードの記述誤り) | 0 |
その他 | その他 | 4 |
表3のインタフェース誤りは、全て受注管理から出荷管理へのデータ連携テストで検出されたもので、全て双方のコンポーネントのユニットに修正が必要な欠陥であったが、欠陥件数は、データの送出側である受注管理だけに計上していた。
K君は、出荷管理と顧客管理について、図2の破線のように、10月27日と11月3日の週の累積欠陥密度を直線で結び、11月17日以降まで延長させて、11月17日の週の累積欠陥密度を推測した。そして、両コンポーネントの累積欠陥密度は、ともに、結合テストが完了する予定の11月17日の週でも、UCLとLCLの間に収まると予想した。