基本情報技術者 2016年 秋期 午後 問06
単体テストにおける品質管理に関する次の記述を読んで、設問1，2に答えよ。
C社では、販売システムの構築を進めており、現在、単体テストを実施している。販売システムは、C社の情報システム部門によるプロジェクト管理の下で、ベンダL社が構築している。ベンダL社は、C社のシステムを構築するプロジェクトに、今回初めて参画している。
C社の品質管理基準では、テストケースの網羅性を示すテスト密度と、当該プログラムにおけるバグ摘出率という指標を用いてプログラムの品質を評価し、単体テストの完了を判断している。
設問1：
問題文を見る C社の品質管理基準に関する次の記述中のに入れる適切な答えを、解答群の中から選べ。ここで、a1〜a3に入れる答えは、aに関する解答群の中から組合せとして適切なものを選ぶものとする。
〔単体テスト完了の判断基準〕
単体テストの完了を判断する際に用いる指標の算出方法とその標準値を表1に示す。指標の標準値については、C社のプログラム開発における過去の同一形態の実績値を基に定めている。また、テスト密度は標準値の80%以上、バグ摘出率は標準値の80%以上かつ120%以下を単体テストの完了の基準範囲とする。
単体テストの完了は、表1に基づいて算出した、プログラムごとのテスト密度とバグ摘出率を、図1に示す品質評価のグラフにプロットして判断する。
図1の区分I〜IVにおける単体テストの品質評価は次のとおりである。
I：バグ摘出率が基準範囲の上限を超えているので、a1である。
II：テスト密度が基準を満たしていないので、テスト不足である。
III：テスト密度、バグ摘出率とも基準を満たしているので、a2である。
IV：テスト密度は基準を満たしているが、バグ摘出率が基準範囲の下限に満たないので、a3。
aに関する解答群
模範解答
a：ウ
解説
解答の導き方
この問題では、プログラムごとに「テストを十分な量だけ行ったか」と「プログラムの品質が基準を満たしているか」を、二つの指標で判断します。
単体テスト（プログラムを部品単位で動かして確認するテスト）で使う指標は、テスト密度とバグ摘出率です。テスト密度は、プログラムの規模に対するテストケース（確認する条件や手順）の数です。バグ摘出率は、プログラムの規模に対する、テストで見つかったバグの数です。ここで、kステップはプログラムの規模を表す単位で、1,000ステップを意味します。
まず、表1の標準値と、問題文にある「標準値の80%以上」「標準値の80%以上かつ120%以下」から、それぞれの基準範囲を求めます。
- テスト密度の標準値は100です。したがって、基準を満たすのは、以上です。
- バグ摘出率の標準値は5です。したがって、基準範囲は、以上、以下です。
つまり、テスト密度は80以上、バグ摘出率は4以上6以下なら基準を満たします。「以上」「以下」なので、境界の値も範囲に含まれます。
次に、図1の区分ごとに二つの指標を確認します。
- Iは、バグ摘出率が基準範囲の上限である6を超えています。プログラムの規模に対して多くのバグが見つかっているため、品質不良と判断します。したがって、は「品質不良」です。
- IIは、テスト密度が基準の下限である80に達していません。テストケースの数が基準に足りないため、テスト不足です。
- IIIは、テスト密度が80以上で、バグ摘出率も4以上6以下です。二つの基準を満たしているため、品質良好です。したがって、は「品質良好」です。
- IVは、テスト密度が80以上なので、テストの量は基準を満たしています。一方、バグ摘出率は4未満です。バグが少ない理由は、プログラムの品質が高いためかもしれませんが、テストでバグを見つけられていないためかもしれません。そのため、数値だけで品質良好ともテスト不足とも決めず、「テストの内容と摘出したバグの内容から品質を評価する」とします。これがに入ります。
以上から、三つの空欄の組合せは、解答群の「ウ」と判断できます。
誤りやすいポイント
- バグ摘出率が高いほど品質が良い、と考えてしまうことがあります。この問題では、バグ摘出率が基準の上限を超えると、プログラムに多くのバグがあると見て品質不良と判断します。
- バグ摘出率が低い場合に、すぐ品質良好と決めてしまうのも誤りです。テストでバグを見つけられていない可能性もあるため、テスト内容などを確認する必要があります。
- テスト密度とバグ摘出率の役割を混同しないようにしましょう。テスト密度はテストの量、バグ摘出率は規模に対して見つかったバグの数を表します。
- 基準範囲の境界値を外してしまうことがあります。80以上、4以上6以下なので、80、4、6はいずれも基準を満たします。
FAQ
Q: テスト密度が基準を満たしていれば、単体テストは十分ですか？
A: テストの量については基準を満たしていますが、それだけで品質が良いとは判断できません。バグ摘出率も確認します。
A: テストの量については基準を満たしていますが、それだけで品質が良いとは判断できません。バグ摘出率も確認します。
Q: バグ摘出率が4未満なら、テスト不足ではないのですか？
A: テスト密度が基準を満たしているなら、テストの量が不足しているとは判断できません。ただし、バグが少ない理由を確認するため、テスト内容と見つかったバグの内容から品質を評価します。
A: テスト密度が基準を満たしているなら、テストの量が不足しているとは判断できません。ただし、バグが少ない理由を確認するため、テスト内容と見つかったバグの内容から品質を評価します。
Q: バグ摘出率がちょうど4、または6の場合は基準内ですか？
A: はい。バグ摘出率の基準は4以上6以下なので、4と6も基準内です。
A: はい。バグ摘出率の基準は4以上6以下なので、4と6も基準内です。
関連キーワード: 単体テスト、テスト密度、バグ摘出率、テストケース、品質評価
設問2：
問題文を見る 販売システムの単体テストの結果と改善策の実施に関する次の記述中のに入れる適切な答えを、解答群の中から選べ。
〔単体テストの結果〕
販売システムは、複数のサブシステムから構成されており、そのうちの一つであるサブシステムXに含まれるプログラム1〜4の単体テストの結果を、表2に示す。
表2の結果から、プログラム1、プログラム3及びプログラム4は、“品質良好”と判断できないので、改善策を実施することにした。
〔改善策の実施〕
プログラム1は、バグ摘出率が基準範囲の上限を超えているので、バグの原因分析を行った。主な原因は、詳細設計書に曖昧な記述があり、プログラムで実現すべき機能に誤りが発生したことであった。そこで、詳細設計書の曖昧な記述を修正後、d。さらに、修正したプログラムについて、必要なテストケースを追加した上で、再度単体テストを実施し、バグ摘出率が基準を満たしていることを確認した。また、同一の観点で、他のプログラムに関しても点検を実施し、同様の問題が含まれていないことを確認した。
プログラム3については、eことを確認し、テストケースの内容自体に問題がないことから、現在のバグ摘出で十分な品質が確保されていると判断したので、改善策は不要とした。
プログラム4については、cことから、テストケースが不足していることが懸念されるので、テストケースの網羅性を点検した上で、f、その結果から品質を再評価することにした。
bに関する解答群
ア：7
イ：98
ウ：980
エ：9,800
cに関する解答群
ア：テスト密度は基準を満たしているが、バグ摘出率は基準範囲の下限に満たない
イ：テスト密度は基準を満たしているが、バグ摘出率は基準範囲の上限を超えている
ウ：バグ摘出率、テスト密度とも基準を満たしていない
エ：バグ摘出率、テスト密度とも基準を満たしている
dに関する解答群
ア：プログラムのソースコードが詳細設計書を正確に反映していることを点検した
イ：プログラムのソースコードに関する記述規定どおりに、プログラムが記述されていることを点検した
ウ：プログラムのソースコードに文法上の誤りがないことを点検した
eに関する解答群
ア：テストケースが特定の処理の流れを重点的に確認するように作成されている
イ：テストケースが全ての処理の流れを網羅的に確認できるように作成されている
ウ：テストケースについて、実データを使用した環境で確認している
エ：テストケースを実行する手順について、正しく定められている
fに関する解答群
ア：摘出したバグが修正されていることを確認し
イ：テストの実施が不足している処理の流れに対してテストケースを追加して再度単体テストを実施し
ウ：テストの実施方法に問題がないことを確認し
エ：バグを摘出した処理の流れに対して、テストケースを追加して再度単体テストを実施し
模範解答
b：イ、c：ウ、d：ア、e：イ、f：イ
解説
解答の導き方
まず、図１から品質評価の基準を読み取ります。テスト密度の下限は80件／kステップです。バグ摘出率の基準範囲は4件／kステップ以上、6件／kステップ以下です。
単体テスト（プログラムを個別に動かして確認するテスト）では、テストケース（確認する条件や入力、期待する結果を組み合わせたテスト項目）の数と、見つかったバグ（プログラムの誤り）の数を、開発規模で割って比較します。ここで、kステップは1,000ステップを表します。
各プログラムのテスト密度とバグ摘出率を計算すると、次のとおりです。
bはプログラム1のテスト密度です。テストケース数980件を開発規模10kステップで割るので、です。したがって、bには「98」が入ります。なお、プログラム1のバグ摘出率はで、基準範囲の上限である6を超えています。
cはプログラム4の評価です。テスト密度は75件／kステップで、下限の80を満たしていません。バグ摘出率も3.75件／kステップで、下限の4に達していません。つまり、テスト密度とバグ摘出率の両方が基準を満たしていないので、cには「ウ」が入ります。
次に、改善策を考えます。
プログラム1は、バグの主な原因が詳細設計書の曖昧な記述にあり、プログラムの機能に誤りが生じていました。詳細設計書を直した後は、プログラムが修正後の設計どおりに作られているかを確かめる必要があります。その確認に当たるのは「プログラムのソースコードが詳細設計書を正確に反映していることを点検した」です。ソースコード（プログラムを記述した内容）に文法上の誤りがないか、記述規定に従っているかだけでは、機能の誤りが直ったとは確認できません。したがって、dには「ア」が入ります。
プログラム3は、テスト密度が125件／kステップなので基準を満たしていますが、バグ摘出率は約3.33件／kステップで下限の4を下回っています。この値だけを見ると、テスト不足の可能性があります。しかし、設問ではテストケースの内容自体に問題がないことを確認するとしています。テストケースが全ての処理の流れを網羅的に確認できるように作られているなら、テスト漏れではなく、プログラムに実際に含まれるバグが少なかった可能性があります。網羅性とは、確認すべき範囲をどれだけ漏れなく調べたかということです。したがって、eには「イ」が入ります。
プログラム4は、テスト密度が基準の下限を下回っているため、テストケースが不足し、まだ確認していない処理の流れがあることが懸念されます。まずテストケースの網羅性を点検し、テストが不足している処理の流れに対してケースを追加して、単体テストを再度実施します。その結果を見て品質を評価し直すため、fには「イ」が入ります。すでにバグを摘出した処理の流れだけにケースを追加しても、確認できていない処理の流れを補えるとは限りません。
誤りやすいポイント
- テスト密度は、テストケース数を開発規模で割って求めます。バグ数を使う計算ではありません。
- バグ摘出率は、バグ数を開発規模で割って求めます。テストケース数を使う計算ではありません。
- バグ摘出率が低いからといって、必ず品質が良いとは限りません。テストケースが不足していて、バグを見つけられていない可能性もあります。
- プログラム3のようにバグ摘出率が基準を下回っていても、テストケースが全ての処理の流れを確認できているなら、直ちに追加テストが必要とは限りません。
- プログラム4では、基準を下回った値を見て終わるのではなく、網羅性を点検し、未確認の処理の流れを補うことが大切です。
FAQ
Q: バグ摘出率が基準範囲の上限を超えると、なぜ問題なのですか？
A: プログラムの規模に対して見つかったバグが多く、プログラムの品質に問題がある可能性が高いためです。プログラム1では原因分析の結果、設計書の曖昧さによる機能の誤りが見つかっています。
A: プログラムの規模に対して見つかったバグが多く、プログラムの品質に問題がある可能性が高いためです。プログラム1では原因分析の結果、設計書の曖昧さによる機能の誤りが見つかっています。
Q: テスト密度が基準を満たせば、テスト漏れはないといえますか？
A: いいえ。テスト密度は、開発規模に対するテストケース数を示す指標です。数が基準を満たしていても、テストケースが同じ処理ばかりを確認していれば、別の処理の流れが漏れている可能性があります。テストケースの内容や網羅性も確認する必要があります。
A: いいえ。テスト密度は、開発規模に対するテストケース数を示す指標です。数が基準を満たしていても、テストケースが同じ処理ばかりを確認していれば、別の処理の流れが漏れている可能性があります。テストケースの内容や網羅性も確認する必要があります。
関連キーワード: 単体テスト、テスト密度、バグ摘出率、テストケース、テスト網羅性
