HOME»基本情報技術者平成28年秋期問題»午後問6
基本情報技術者過去問題 平成28年秋期 午後問6
⇄問題文と設問を画面2分割で開く⇱問題PDF問6 プロジェクトマネジメント
単体テストにおける品質管理に関する次の記述を読んで，設問1，2に答えよ。
C社では，販売システムの構築を進めており，現在，単体テストを実施している。販売システムは，C社の情報システム部門によるプロジェクト管理の下で，ベンダL社が構築している。ベンダL社は，C社のシステムを構築するプロジェクトに，今回初めて参画している。
C社の品質管理基準では，テストケースの網羅性を示すテスト密度と，当該プログラムにおけるバグ摘出率という指標を用いてプログラムの品質を評価し，単体テストの完了を判断している。
C社では，販売システムの構築を進めており，現在，単体テストを実施している。販売システムは，C社の情報システム部門によるプロジェクト管理の下で，ベンダL社が構築している。ベンダL社は，C社のシステムを構築するプロジェクトに，今回初めて参画している。
C社の品質管理基準では，テストケースの網羅性を示すテスト密度と，当該プログラムにおけるバグ摘出率という指標を用いてプログラムの品質を評価し，単体テストの完了を判断している。
設問1
C社の品質管理基準に関する次の記述中の に入れる適切な答えを，解答群の中から選べ。ここで，a1～a3に入れる答えは，aに関する解答群の中から組合せとして適切なものを選ぶものとする。
〔単体テスト完了の判断基準〕
単体テストの完了を判断する際に用いる指標の算出方法とその標準値を表1に示す。指標の標準値については，C社のプログラム開発における過去の同一形態の実績値を基に定めている。また，テスト密度は標準値の80%以上，バグ摘出率は標準値の80%以上かつ120%以下を単体テストの完了の基準範囲とする。
単体テストの完了は，表1に基づいて算出した，プログラムごとのテスト密度とバグ摘出率を，図1に示す品質評価のグラフにプロットして判断する。
図1の区分Ⅰ～Ⅳにおける単体テストの品質評価は次のとおりである。
〔単体テスト完了の判断基準〕
単体テストの完了を判断する際に用いる指標の算出方法とその標準値を表1に示す。指標の標準値については，C社のプログラム開発における過去の同一形態の実績値を基に定めている。また，テスト密度は標準値の80%以上，バグ摘出率は標準値の80%以上かつ120%以下を単体テストの完了の基準範囲とする。
- バグ摘出率が基準範囲の上限を超えているので，a1である。
- テスト密度が基準を満たしていないので，テスト不足である。
- テスト密度，バグ摘出率とも基準を満たしているので，a2である。
- テスト密度は基準を満たしているが，バグ摘出率が基準範囲の下限に満たないので，a3
a に関する解答群
解答選択欄
- a:
解答
- a=ウ
解説
品質評価のグラフを領域ごとに分類すると次のようになります。
〔a1について〕
Ⅰはバグ摘出率の上限を超えたプログラムがプロットされる領域なので、品質不良が妥当です。
〔a2について〕
Ⅲは両方の指標が基準範囲に収まっているプログラムがプロットされる領域なので、品質良好が妥当です。
〔a3について〕
Ⅳは十分なテストが行われているにもかかわらずバグの摘出数が少ないプログラムがプロットされる領域です。テスト密度は基準を満たしているため、消去法で「テストの内容と摘出したバグの内容から品質を評価する」が適切とわかります。
このような状況に陥る原因には、以下の2通りがあります。
以上より正しい組合せは「ウ」になります。
Ⅰはバグ摘出率の上限を超えたプログラムがプロットされる領域なので、品質不良が妥当です。
〔a2について〕
Ⅲは両方の指標が基準範囲に収まっているプログラムがプロットされる領域なので、品質良好が妥当です。
〔a3について〕
Ⅳは十分なテストが行われているにもかかわらずバグの摘出数が少ないプログラムがプロットされる領域です。テスト密度は基準を満たしているため、消去法で「テストの内容と摘出したバグの内容から品質を評価する」が適切とわかります。
このような状況に陥る原因には、以下の2通りがあります。
- テストケースの質が悪くバグを摘出できていない
- プログラムの品質が高く元からバグ数が少ない
以上より正しい組合せは「ウ」になります。
設問2
販売システムの単体テストの結果と改善策の実施に関する次の記述中の に入れる適切な答えを，解答群の中から選べ。
〔単体テストの結果〕
販売システムは，複数のサブシステムから構成されており，そのうちの一つであるサブシステムXに含まれるプログラム1～4の単体テストの結果を，表2に示す。
表2の結果から，プログラム1，プログラム3及びプログラム4は，"品質良好"と判断できないので，改善策を実施することにした。
〔改善策の実施〕
プログラム1は，バグ摘出率が基準範囲の上限を超えているので，バグの原因分析を行った。主な原因は，詳細設計書に曖昧な記述があり，プログラムで実現すべき機能に誤りが発生したことであった。そこで，詳細設計書の曖昧な記述を修正後，d。さらに，修正したプログラムについて，必要なテストケースを追加した上で，再度単体テストを実施し，バグ摘出率が基準を満たしていることを確認した。また，同一の観点で，他のプログラムに関しても点検を実施し，同様の問題が含まれていないことを確認した。
プログラム3については，eことを確認し，テストケースの内容自体に問題がないことから，現在のバグ摘出で十分な品質が確保されていると判断したので，改善策は不要とした。
プログラム4については，cことから，テストケースが不足していることが懸念されるので，テストケースの網羅性を点検した上で，fその結果から品質を再評価することにした。
〔単体テストの結果〕
販売システムは，複数のサブシステムから構成されており，そのうちの一つであるサブシステムXに含まれるプログラム1～4の単体テストの結果を，表2に示す。
〔改善策の実施〕
プログラム1は，バグ摘出率が基準範囲の上限を超えているので，バグの原因分析を行った。主な原因は，詳細設計書に曖昧な記述があり，プログラムで実現すべき機能に誤りが発生したことであった。そこで，詳細設計書の曖昧な記述を修正後，d。さらに，修正したプログラムについて，必要なテストケースを追加した上で，再度単体テストを実施し，バグ摘出率が基準を満たしていることを確認した。また，同一の観点で，他のプログラムに関しても点検を実施し，同様の問題が含まれていないことを確認した。
プログラム3については，eことを確認し，テストケースの内容自体に問題がないことから，現在のバグ摘出で十分な品質が確保されていると判断したので，改善策は不要とした。
プログラム4については，cことから，テストケースが不足していることが懸念されるので，テストケースの網羅性を点検した上で，fその結果から品質を再評価することにした。
b に関する解答群
- 7
- 98
- 980
- 9,800
c に関する解答群
- テスト密度は基準を満たしているが，バグ摘出率は基準範囲の下限に満たない
- テスト密度は基準を満たしているが，バグ摘出率は基準範囲の上限を超えている
- バグ摘出率，テスト密度とも基準を満たしていない
- バグ摘出率，テスト密度とも基準を満たしている
d に関する解答群
- プログラムのソースコードが詳細設計書を正確に反映していることを点検した
- プログラムのソースコードに関する記述規定どおりに，プログラムが記述されていることを点検した
- プログラムのソースコードに文法上の誤りがないことを点検した
e に関する解答群
- テストケースが特定の処理の流れを重点的に確認するように作成されている
- テストケースが全ての処理の流れを網羅的に確認できるように作成されている
- テストケースについて，実データを使用した環境で確認している
- テストケースを実行する手順について，正しく定められている
f に関する解答群
- 摘出したバグが修正されていることを確認し
- テストの実施が不足している処理の流れに対してテストケースを追加して再度単体テストを実施し
- テストの実施方法に問題がないことを確認し
- バグを摘出した処理の流れに対して，テストケースを追加して再度単体テストを実施し
解答選択欄
- b:
- c:
- d:
- e:
- f:
解答
- b=イ
- c=ウ
- d=ア
- e=イ
- f=イ
解説
〔bについて〕
本文中の表1よりテスト密度の算出方法は「テストケース数(件)÷開発規模(kステップ)」とわかります。プログラム1は、テストケース数：980kステップ、開発規模10件なので算出式にこの値を代入して答えを導きます。
980÷10＝98
∴a＝イ：98(件／kステップ)
〔cについて〕
まずプログラム4のテスト密度とバグ摘出率を求めます。バグ摘出率の算出方法は「バグ数(件)÷開発規模(kステップ)」です。
∴c＝ウ：バグ摘出率，テスト密度とも基準を満たしていない
〔dについて〕
バグ摘出率が基準範囲を超える原因となったプログラムの誤りは、文法誤りやコーディング規約違反ではなく、詳細設計書の記述ミスに起因するものです。このため詳細設計書の修正後に行うべきは、詳細設計書の修正箇所をプログラムに正しく反映し、バグが多く摘出されてしまうことになった原因を取り除くことです。これによって適切な品質評価を実施できます。
∴d＝ア
〔eについて〕
まずプログラム3が基準範囲を満たすかを確認するためにテスト密度とバグ摘出率を計算します。
〔fについて〕
cのところでも計算したとおり、プログラム4は両指標とも基準を満たしません。テスト密度が基準範囲を下回っていることから、まだ十分にテストが実施されていないと考えられます。
プログラム4のバグ摘出率は基準値の(3.75÷5=)75%で、テスト密度の(75÷100=)75%と比較しても低い水準ではありません。両指標とも80%以上が基準範囲であるため、今後テストケースを追加し、テスト密度が80%以上になるまでテストを続ければ両方とも完了の基準範囲に達することが見込めます。したがってテスト密度を増加させる策を実施するべきと判断できます。
本文中の表1よりテスト密度の算出方法は「テストケース数(件)÷開発規模(kステップ)」とわかります。プログラム1は、テストケース数：980kステップ、開発規模10件なので算出式にこの値を代入して答えを導きます。
980÷10＝98
∴a＝イ：98(件／kステップ)
〔cについて〕
まずプログラム4のテスト密度とバグ摘出率を求めます。バグ摘出率の算出方法は「バグ数(件)÷開発規模(kステップ)」です。
- [テスト密度] 600÷8＝75
- [バグ摘出率] 30÷8＝3.75
∴c＝ウ：バグ摘出率，テスト密度とも基準を満たしていない
〔dについて〕
バグ摘出率が基準範囲を超える原因となったプログラムの誤りは、文法誤りやコーディング規約違反ではなく、詳細設計書の記述ミスに起因するものです。このため詳細設計書の修正後に行うべきは、詳細設計書の修正箇所をプログラムに正しく反映し、バグが多く摘出されてしまうことになった原因を取り除くことです。これによって適切な品質評価を実施できます。
∴d＝ア
〔eについて〕
まずプログラム3が基準範囲を満たすかを確認するためにテスト密度とバグ摘出率を計算します。
- [テスト密度] 750÷6＝125
- [バグ摘出率] 20÷6＝3.333…
- テストケースに偏りがあると、重点的ではない他の処理のバグが十分に摘出されていない可能性があります。このためバグの少なさを肯定する理由としては不適切です。
- 正しい。単体テストはホワイトボックステストで実施され、内部構造を網羅するようにテストケースを作成します。テストケースに十分な網羅度があれば、単体テストが適切に行われたことを確認できます。
- 実データを使用したテストケースではプログラムの内部までテストが行き届いていない可能性があります。このためバグの少なさを肯定する理由としては不適切です。
- 実行順序とバグの摘出率に因果関係はありません。このためバグの少なさを肯定する理由としては不適切です。
〔fについて〕
cのところでも計算したとおり、プログラム4は両指標とも基準を満たしません。テスト密度が基準範囲を下回っていることから、まだ十分にテストが実施されていないと考えられます。
プログラム4のバグ摘出率は基準値の(3.75÷5=)75%で、テスト密度の(75÷100=)75%と比較しても低い水準ではありません。両指標とも80%以上が基準範囲であるため、今後テストケースを追加し、テスト密度が80%以上になるまでテストを続ければ両方とも完了の基準範囲に達することが見込めます。したがってテスト密度を増加させる策を実施するべきと判断できます。
- テスト密度が基準範囲を下回っているので、十分にテストが行われず、プログラム内にバグが残っている可能性があります。このためバグの修正ではなく摘出を優先的に行うべきです。
- 正しい。テストケース不足でバグの摘出が不十分な部分に対して追加のテストを行うことで、テスト密度とバグ摘出率の両指標の増加が見込めます。
- たとえテストの実施方法が正しくても、追加のテストを実施しなければ両指標ともに完了の基準範囲を満たすことはできません。
- 追加テストは網羅度を高めるためにテストが不十分な部分に対して実施すべきです。