- ベストアンサー
プログラムの消化テストについて
- テストによって発見される累積バグ数と消化テスト項目数の関係をグラフに示すと、右肩上がりの曲線となる。
- もし消化テスト項目数の増加に対して累積バグ数の上昇が通常より低い場合、テストケースに不備があるか見直しを検討する必要がある。
- プログラムの品質が高いため、テストを打ち切ることも考えられる。
- みんなの回答 （3）
- 専門家の回答
質問者が選んだベストアンサー
物を作ったことがあると分かりやすいのですが、 あるアプリケーションなどを作成する場合、最低でも 以下の手順を辿ります。 １．プログラミング ２．単体テスト この時、デバッグしながらプログラミングしてるから バグなんて1つも出ないんだけど・・・と思わないで下さい。 それはデバッグの域を超えた確認を行ってるせいです。 プログラミングはあくまで設計をプログラミングした のみであって、試験はしてないと受け止めて下さい。 というか、情報処理試験ではそれが『普通』です。 よほどのことがなければ、単体テストでバグが相当数 現れます。 この時、バグの発生数は、試験数に対して多く存在する でしょう。 １個バグを直しちゃ１個バグが出て・・・。 それはしばらく続くでしょう。 しかし試験を進めていくにつれてバグは消化されていく わけですから、試験を進めれば進めるほど緩やかになります。 つまりバグが見つかりにくくなるわけです。 この時、設問の以下の部分が問題になります。 > 図３の実線のように消化テスト項目数の増加に対し，累積バグ数の上昇が通常より極めて低い場合 最初っから試験をしてもしてもバグがでない、なぜだ、と。 つまり、あんたがた、効果薄い勘違い試験してんじゃねーの？と なるわけです。 まあ現実だとプログラムも試験も高品質だったり小規模だったりで バグがでない時もありますが、『バグの発見数が少ないので，プログラムの品質が高い』 とは判断しませんので。 図３から考えるとその理由は品質を担保する理由には当たらず、 バグは試験項目の品質担保によって消化されていった結果であって、 品質を保ち続けなければならないのは試験項目です。 つまり、試験項目が高品質ならば、バグを消化していった結果、 プログラムも高品質になります。
その他の回答 (2)
- itou2618
- ベストアンサー率26% (319/1208)
目標とするバグ数を摘出できない場合、テストケースに偏りがあるのでは？と疑うのが常識です。 そしてＣ０、Ｃ１などテストカバレッジをチェックして、妥当ならば高品質のプログラムと判断します。 ウとエは質問のグラフからは読み取れない内容です。
お礼
ありがとうございます
- snowsan062
- ベストアンサー率42% (21/50)
ウとエはグラフに無い人数や装置を挙げてるのでまず無いでしょう。 なんの為にテストしてるかを考えたら イの方が適切だと思う。 今回の問題の場合、信頼度成長曲線がまず前提としてあるんで これに該当しないケースは異常と捕らえるのが模範的な回答なんじゃない。
お礼
ありがとうございます。
お礼
詳しく書いていただき、ありがとうございます。