応用情報技術者過去問題 平成26年秋期 午後問8
⇄問題文と設問を画面2分割で開く⇱問題PDF問8 情報システム開発
ソフトウェアのテストに関する次の記述を読んで，設問1～3に答えよ。
J社は，自社の販売管理システムを再構築するプロジェクトを実施している。プロジェクトでは，設計者が要件定義，方式設計を行った後，ソフトウェアコンポーネント(以下，コンポーネントという)の詳細設計を行う。その後，構築において，開発者がコンポーネントを構成するソフトウェアユニット(以下，ユニットという)のコード作成と単体テストを行う。そして，結合において，コンポーネント内のユニット間，及びコンポーネント間の結合テストを行う。K君はプロジェクトマネージャを務めている。
販売管理システムは，出荷管理，顧客管理，受注管理，見積り管理の四つのコンポーネントから成る。表1に，これらのコンポーネントのステップ数を示す。
〔単体テストの実施と結果の分析〕
J社では，単体テストとして，ホワイトボックステストとブラックボックステストを行う。テスト項目の件数は，ユニットへの入力の組合せ数でカウントし，その目標を1kステップ当たり100以上と定めている。ただし，回帰テストのために同じテスト項目を複数回実行しても重複してカウントしない。テストにおいて期待どおりの処理結果とならない場合には，その原因となる欠陥を特定し，ユニットごとにその欠陥件数をカウントする。
出荷管理，顧客管理，受注管理は，コンポーネントを構成するユニットの単体テストを予定どおりに完了し，結合テストを実施中である。見積り管理は，他よりも遅れて単体テストを完了し，K君がテスト結果を確認中である。表2は，見積り管理の各ユニットの単体テストで検出された欠陥件数である。
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は，受注管理の結合テストで検出された欠陥の内訳である。
表3のインタフェース誤りは，全て受注管理から出荷管理へのデータ連携テストで検出されたもので，全て双方のコンポーネントのユニットに修正が必要な欠陥であったが，欠陥件数は，データの送出側である受注管理だけに計上していた。
K君は，出荷管理と顧客管理について，図2の破線のように，10月27日と11月3日の週の累積欠陥密度を直線で結び，11月17日以降まで延長させて，11月17日の週の累積欠陥密度を推測した。そして，両コンポーネントの累積欠陥密度は，ともに，結合テストが完了する予定の11月17日の週でも，UCLとLCLの間に収まると予想した。
J社は，自社の販売管理システムを再構築するプロジェクトを実施している。プロジェクトでは，設計者が要件定義，方式設計を行った後，ソフトウェアコンポーネント(以下，コンポーネントという)の詳細設計を行う。その後，構築において，開発者がコンポーネントを構成するソフトウェアユニット(以下，ユニットという)のコード作成と単体テストを行う。そして，結合において，コンポーネント内のユニット間，及びコンポーネント間の結合テストを行う。K君はプロジェクトマネージャを務めている。
販売管理システムは，出荷管理，顧客管理，受注管理，見積り管理の四つのコンポーネントから成る。表1に，これらのコンポーネントのステップ数を示す。
J社では，単体テストとして，ホワイトボックステストとブラックボックステストを行う。テスト項目の件数は，ユニットへの入力の組合せ数でカウントし，その目標を1kステップ当たり100以上と定めている。ただし，回帰テストのために同じテスト項目を複数回実行しても重複してカウントしない。テストにおいて期待どおりの処理結果とならない場合には，その原因となる欠陥を特定し，ユニットごとにその欠陥件数をカウントする。
出荷管理，顧客管理，受注管理は，コンポーネントを構成するユニットの単体テストを予定どおりに完了し，結合テストを実施中である。見積り管理は，他よりも遅れて単体テストを完了し，K君がテスト結果を確認中である。表2は，見積り管理の各ユニットの単体テストで検出された欠陥件数である。
〔結合テストの実施と欠陥発生状況の分析〕
見積り管理を除く三つのコンポーネントについて，結合テストを実施中である。K君は，結合テストにおいて，品質の低いコンポーネントを早い時点で検出して対策を取ることで，工程の遅延を防ぐことを考えた。そこで，テストの実施中から，欠陥の検出状況を，管理図を用いて確認することにした。図2は，結合テストで検出された累積欠陥密度の管理図である。この図の縦軸は，各コンポーネントの結合テストで検出された累積欠陥密度であり，横軸は，結合テストの日程である。結合テストは9月29日の週から開始し，11月17日の週に完了する予定である。J社の結合テストで検出された累積欠陥密度の過去の実績値から，中央値は1.4件／kステップ，UCLは1.7件／kステップ，LCLは1.2件／kステップである。現在，11月9日であり，週初日が11月3日の週を終えたところである。結合テストのテスト項目数はJ社の目標値を満たしており，消化状況も予定どおりである。
K君は，出荷管理と顧客管理について，図2の破線のように，10月27日と11月3日の週の累積欠陥密度を直線で結び，11月17日以降まで延長させて，11月17日の週の累積欠陥密度を推測した。そして，両コンポーネントの累積欠陥密度は，ともに，結合テストが完了する予定の11月17日の週でも，UCLとLCLの間に収まると予想した。
設問1
単体テストの方法について，ホワイトボックステスト，ブラックボックステストのテスト項目の作成方法に該当するものを，解答群の中からそれぞれ全て選び，記号で答えよ。
解答群
- ユニット内の条件判定の組合せ全てを少なくとも1回は実行する。
- ユニットの全ての分岐を少なくとも1回は実行する。
- ユニットの全ての命令を少なくとも1回は実行する。
- ユニットへの入力データの値の範囲を分割し，各代表値で実行する。
- ユニットへの入力と出力の因果関係を網羅するよう実行する。
解答入力欄
- ホワイトボックステスト：
- ブラックボックステスト：
解答例・解答の要点
- ホワイトボックステスト：ア，イ，ウ
- ブラックボックステスト：エ，オ
解説
設問1はテスト設計手法の最も基本的な分類である「ホワイトボックステスト」「ブラックボックステスト」の特徴を問う問題です。
ホワイトボックステストはテスト対象の内部構造の内容がわかっている前提で行うテストです（内部構造とは、ソースコードや詳細設計及びフローチャートなどです）。内部構造を分析した上で網羅性の高い（抜け・漏れのない）テストができるようなテスト項目を作成します。無駄な処理の有無やプログラムの処理効率も判断できる反面、仕様書そのものが間違っていたり仕様の抜け漏れがあっても検出できないというデメリットもあります。
代表的なホワイトボックステストのテスト項目設計手法を以下に示します。
代表的なブラックボックステストのテスト項目設計手法を以下に示します。
一方、「エ」「オ」はいずれもテスト対象の内部構造に関わらずテスト項目を作成できる手法です。したがって、これらは「ブラックボックステスト」に該当します。「エ」は同値分割、「オ」は網羅型に相当します。
∴ホワイトボックステスト：ア，イ，ウ
ブラックボックステスト：エ，オ
ホワイトボックステストはテスト対象の内部構造の内容がわかっている前提で行うテストです（内部構造とは、ソースコードや詳細設計及びフローチャートなどです）。内部構造を分析した上で網羅性の高い（抜け・漏れのない）テストができるようなテスト項目を作成します。無駄な処理の有無やプログラムの処理効率も判断できる反面、仕様書そのものが間違っていたり仕様の抜け漏れがあっても検出できないというデメリットもあります。
代表的なホワイトボックステストのテスト項目設計手法を以下に示します。
- 命令網羅(網羅性:低い↑)
- すべての命令を少なくとも1回は実行するテストケースを設計する。
- 分岐網羅(判定条件網羅)
- 判定条件の真偽を少なくとも1回は実行するテストケースを設計する。
- 条件網羅
- 判定条件が複数ある場合に、それぞれの条件が真・偽の場合を組み合わせたテストケースを設計する。
- 判定条件・条件網羅
- 判定条件網羅と条件網羅を組み合わせてテストケースを設計する。
- 複数条件網羅(網羅性:高↓)
- 判定条件のすべての可能な結果の組合せを網羅し、かつ、すべての命令を少なくとも1回は実行するようにテストケースを作成する。
代表的なブラックボックステストのテスト項目設計手法を以下に示します。
- 網羅型
- テスト対象の仕様から、入力と出力の因果関係を分析し、すべての組み合わせを網羅するようにテストケースを設計する。因果関係の分析にはデシジョンテーブルなどが使用される。
- 同値分割
- 入力データを「有効値」「有効値未満」「有効値超過」のように、正しい入力値と異状な入力値のクラスに分割し、それぞれのクラスから代表値を選んでテストケースとする。
- 境界値分析（限界値分析）
- 入力データを「有効値」「有効値未満」「有効値超過」のように、正しい入力値と異状な入力値のクラスに分割し、それぞれのクラスの境界前後の値を抽出してテストケースとする。
一方、「エ」「オ」はいずれもテスト対象の内部構造に関わらずテスト項目を作成できる手法です。したがって、これらは「ブラックボックステスト」に該当します。「エ」は同値分割、「オ」は網羅型に相当します。
∴ホワイトボックステスト：ア，イ，ウ
ブラックボックステスト：エ，オ
設問2
見積り管理の単体テスト結果について，(1)～(3)に答えよ。
- 図1の管理図に対する分析結果として正しいものはどれか。解答群の中から全て選び，記号で答えよ。
- 表2において，J社の基準に従うと，欠陥密度以外の観点でテストに問題があると考えられるユニットがある。そのユニットのユニットIDを答えよ。また，その理由を20字以内で述べよ。
- 本文中の下線①の，L君が行ったユニットP10の単体テストにおける問題点は何か。30字以内で具体的に述べよ。
解答群
- P1は，UCLを超えており，調査が必要なユニットである。
- P2，P3，P5，P8は，管理限界に収まっているので，品質が保証される。
- P4，P9は，欠陥が少なく，品質が高い。
- P6は，UCLをわずかに超えているだけなので，今は調査に時間を掛けず，結合テストで経過を監視する。
- P7は，テスト項目の精査を行うべきユニットである。
解答入力欄
- ユニットID：
- 理由：
解答例・解答の要点
- ア，オ
- ユニットID：P2
- 理由：テスト項目数が目標値よりも少ない (16文字)
- メイン機能修正後に回帰テストを行っていない (21文字)
解説
- ユニットごとの単体テスト実施結果を、管理図を使用して分析し、適切な判断ができるかどうかを問う問題です。
管理図は「QC7つ道具」の一つで、計測した数値データをグラフ上にプロットし、値がUCL（上部管理限界）とLCL（下部管理限界）の間に収まっているか、通常と異なる変化が出ていないかなどを調べることで異常の有無を判別する手法です。一般的な管理図では横軸を時系列にして、時間経過に伴う計測値の変化を分析することが多いですが、図1の管理図は横軸がユニットIDになっていて、欠陥密度を（時間変化ではなく）ユニット同士で比較する図になっていることに注意が必要です。- 正しい。管理図では基本的に、計測値がUCLからLCLの範囲に収まらないとき、なんらかの異常が生じていると考えるため、UCLを上回るP1はさらなる調査が必要なユニットです。
- 誤り。P2・P3・P5・P8はUCLからLCLの範囲（管理限界）に収まってはいますが、その結果をもって品質を保証することはできません。テストケースの品質が悪く、欠陥が摘出されていない場合もあるためです。
- 誤り。P4・P9の欠陥密度はLCLを著しく下回っているため、「欠陥が少なく品質が高い」ではなく、むしろ「テストが不十分で欠陥が見つけられていない」可能性を疑うべきです。
- 誤り。UCLを超えたということは、その時点で何らかの異常が生じていると見るべきで、この状況を放置して結合テストに進むのは不適切です。前工程での異常は後工程でさらに広がる傾向があるためです。
- 正しい。P7はLCLを下回る欠陥密度であるため、十分なテストが行えるようにテスト項目の精査を行うべきです。
- 〔単体テストの実施と結果の分析〕の中で、J社の基準では「テスト項目の件数は，(中略)その目標を1kステップ当たり100以上と定めている。」と書かれていますが、ユニットP2は「5,500ステップ＝5.5kステップ」に対してテスト項目数が490項目しかなく、テスト項目件数の目標である「5.5kステップ×100件＝550件」を下回っています。したがって問題のあるユニットはP2、理由は「テスト項目数が目標値よりも少ない」となります。
∴ユニットID：P2
理由：テスト項目数が目標値よりも少ない - L君はテスト実施中に欠陥を検出し、ユニット全体に影響するメイン機能の大きな修正を行っています。この場合、メイン機能の大きな修正により検証済みだった部分の動作が変わっている可能性が考えられますが、L君はすでに実施済みのテストはそのまま、未実施のテスト項目だけを実施しています。修正を行った場合は、修正部分が今まで正常に動いていた他の部分に影響を及ぼしていないかを確認する回帰テスト（退行テスト・レグレッションテスト）を行う必要があります。したがって、L君の問題としては「テスト実施済部分に対する回帰テストが未実施」や「メイン機能修正後に修正による影響を確認していない」旨の解答が適切となります。模範解答は「メイン機能修正後に回帰テストを行っていない」です。
∴メイン機能修正後に回帰テストを行っていない
設問3
見積り管理を除く三つのコンポーネントの結合テストにおいて，現状では，検出された欠陥件数が正しく計上されておらず，欠陥件数を修正すると，管理図分析の結果として問題があると考えられるコンポーネントがある。そのコンポーネントを答えよ。また，問題があると考えられる理由を，本文中の字句を用いて20字以内で述べよ。
解答入力欄
- コン\ポ－ネント：
- 理由：
解答例・解答の要点
- コン\ポ－ネント：出荷管理
- 理由：累積欠陥密度がUCLを超えるから (16文字)
解説
〔結合テストの実施と欠陥発生状況の分析〕の中に「表3のインタフェース誤りは，全て受注管理から出荷管理へのデータ連携テストで検出されたもので，全て双方のコンポーネントのユニットに修正が必要な欠陥であったが，欠陥件数は，データの送出側である受注管理だけに計上していた。」という記述があります。つまり、表3に記載されているインタフェース誤り（12件）は、受注管理だけでなく出荷管理にも欠陥件数として計上すべきものであることがわかります。
具体的に出荷管理で増加する欠陥密度を計算してみると、出荷管理のステップ数は表1より「20,000ステップ＝20kステップ」なので、
12件÷20kステップ＝0.6件／kステップ
が上乗せされる欠陥密度とわかります。
次に、図2から出荷管理の累積欠陥密度（11/3時点）を調べると、ちょうどLCL（1.2件／kステップ）の上に位置しています。これに先ほど求めた欠陥密度を上乗せすると1.8件／kステップになり、UCL（1.7件／kステップ）を超えることになります。つまり、出荷管理コンポーネントについても問題があると考えられます。
したがって、管理図分析の結果として問題があると考えられるコンポーネントは「出荷管理」、その理由は「累積欠陥密度がUCLを超えるから」となります。
∴コンポーネント：出荷管理
理由：累積欠陥密度がUCLを超えるから
具体的に出荷管理で増加する欠陥密度を計算してみると、出荷管理のステップ数は表1より「20,000ステップ＝20kステップ」なので、
12件÷20kステップ＝0.6件／kステップ
が上乗せされる欠陥密度とわかります。
次に、図2から出荷管理の累積欠陥密度（11/3時点）を調べると、ちょうどLCL（1.2件／kステップ）の上に位置しています。これに先ほど求めた欠陥密度を上乗せすると1.8件／kステップになり、UCL（1.7件／kステップ）を超えることになります。つまり、出荷管理コンポーネントについても問題があると考えられます。
したがって、管理図分析の結果として問題があると考えられるコンポーネントは「出荷管理」、その理由は「累積欠陥密度がUCLを超えるから」となります。
∴コンポーネント：出荷管理
理由：累積欠陥密度がUCLを超えるから
