プログラムの消化テストについて

一般的にテストによって発見される累積バグ数を縦軸に，消化テスト項目数を横軸にとってグラフ
に示すと，信頼度成長曲線(図３の破線)と呼ばれる急激に上昇し，後に緩やかに上昇する
右肩上がりの曲線になる。
テストを実施している際に，もし図３の実線のように消化テスト項目数の増加に対し，累積バグ数の上昇が通常より極めて低い場合は，(11）と考えられる。

（11）の解答群
ア．バグの発見数が少ないので，プログラムの品質が高いと判断し，テストを打ち切ってもよい
イ．バグの発見数が少ないので，テストケースに不備がないか見直しを検討する必要がある
ウ．テストを実施する人数が少ないか見直しを検討する必要がある
エ．テストを実施する装置が少ないか見直しを検討する必要がある

答えはイなのですが、その理由がわかりません。
解説をお願いします。

No.1 回答者： snowsan062 回答日時： 2012/07/18 22:44

ウとエはグラフに無い人数や装置を挙げてるのでまず無いでしょう。

なんの為にテストしてるかを考えたら
イの方が適切だと思う。
今回の問題の場合、信頼度成長曲線がまず前提としてあるんで
これに該当しないケースは異常と捕らえるのが模範的な回答なんじゃない。

この回答へのお礼

ありがとうございます。

お礼日時：2012/07/18 22:55

No.2 ベストアンサー 回答者： naktak 回答日時： 2012/07/18 23:34

物を作ったことがあると分かりやすいのですが、

あるアプリケーションなどを作成する場合、最低でも
以下の手順を辿ります。

　１．プログラミング
　２．単体テスト

この時、デバッグしながらプログラミングしてるから
バグなんて1つも出ないんだけど・・・と思わないで下さい。
それはデバッグの域を超えた確認を行ってるせいです。
プログラミングはあくまで設計をプログラミングした
のみであって、試験はしてないと受け止めて下さい。
というか、情報処理試験ではそれが『普通』です。


よほどのことがなければ、単体テストでバグが相当数
現れます。

この時、バグの発生数は、試験数に対して多く存在する
でしょう。
１個バグを直しちゃ１個バグが出て・・・。
それはしばらく続くでしょう。
しかし試験を進めていくにつれてバグは消化されていく
わけですから、試験を進めれば進めるほど緩やかになります。
つまりバグが見つかりにくくなるわけです。


この時、設問の以下の部分が問題になります。
> 図３の実線のように消化テスト項目数の増加に対し，累積バグ数の上昇が通常より極めて低い場合

最初っから試験をしてもしてもバグがでない、なぜだ、と。
つまり、あんたがた、効果薄い勘違い試験してんじゃねーの？と
なるわけです。


まあ現実だとプログラムも試験も高品質だったり小規模だったりで
バグがでない時もありますが、『バグの発見数が少ないので，プログラムの品質が高い』
とは判断しませんので。

図３から考えるとその理由は品質を担保する理由には当たらず、
バグは試験項目の品質担保によって消化されていった結果であって、
品質を保ち続けなければならないのは試験項目です。
つまり、試験項目が高品質ならば、バグを消化していった結果、
プログラムも高品質になります。

この回答へのお礼

詳しく書いていただき、ありがとうございます。

お礼日時：2012/07/19 08:14

No.3 回答者： itou2618 回答日時： 2012/07/19 07:14

目標とするバグ数を摘出できない場合、テストケースに偏りがあるのでは？と疑うのが常識です。

そしてＣ０、Ｃ１などテストカバレッジをチェックして、妥当ならば高品質のプログラムと判断します。
ウとエは質問のグラフからは読み取れない内容です。

この回答へのお礼

ありがとうございます

お礼日時：2012/07/19 08:13