令和2年秋期試験 午後問9

しおあじさん  
(No.1)
https://www.ap-siken.com/kakomon/02_aki/pm09.html

用語や計算方法に不明点があります。
①テスト検出不具合密度とは
 ぐぐったところバグ密度やテスト密度がヒットしました。同じと考えてよろしいでしょうか?

②設問2(3)の計算問題について
c→再実施する結合テスト工程の全ての障害を解消する場合、開発要員を増員した体制での必要な日数なら結合テストだけの人数ではないのでしょうか

再実施する結合テスト工程の障害の解消に必要な日数計算→目標とするテスト検出不具合密度に収まり120件の「目標「が前述されていないと思いましたがこれはここにきて初めて記述されたのでしょうか(そもそもテスト検出不具合密度がわかっていないので書いてる意味がわからず…--;)

③設問の4を「障害件数とテスト検出不具合密度」としました。後者はあてずっぽうですが前者の障害件数とは模範解答の障害の発生件数と同じと判断できますでしょうか


長文となり恐縮ですがよろしくお願いいたします
2025.08.27 20:57
jjon-comさん 
AP プラチナマイスター
(No.2)
応用情報 令和2年 秋期 午後 問9
https://www.ap-siken.com/kakomon/02_aki/pm09.html

> テスト検出不具合密度とは

分母が ソフトウェアの規模(ソースコードの行数、機能数、モジュール数など)、
分子が テストで検出された不具合の数、である指標値です。
原則として、
テスト検出不具合密度が想定値より顕著に高ければ、前工程でのソフトウェアの作り込み(品質)が悪い。
テスト検出不具合密度が想定値より顕著に低ければ、テスト内容が不十分(テスト自体の品質が悪い)。
という判断をします。

> テスト密度がヒットしました。同じと考えてよろしいでしょうか?

問題文に次の文章が登場します。「AやB」の形で併記されていますから別であることは明らかです。
テスト密度やテスト検出不具合密度などの品質管理の指標値に問題がないことを確認した。

> バグ密度 … 同じと考えてよろしいでしょうか?

けっこう曖昧な表現なのですが、同じと捉えることができると私は考えます。
ソフトウェアのバグは、テストするまでその存在が分からず、テストしてバグ検出して初めてその密度が分かるものなので。

> c→結合テストだけの人数ではないのでしょうか

結合テストによって、大幅に超過した数の障害(不具合)が検出されたわけですが、
表4より、その原因のほとんどは、結合テスト自体ではなく前々工程の基本設計にあることが示されています。

> 前者の障害件数とは模範解答の障害の発生件数と同じと判断できますでしょうか

はい、同じです。〔結合テスト工程の障害の原因分析〕の節に障害件数という表記が2度登場しています。
2025.08.28 09:03
しおあじさん  
(No.3)
jjon-comさん
回答いただきありがとうございます!
助かりました
2025.08.30 20:03

返信投稿用フォーム

※SQL文は全角文字で記載してください。
※宣伝や迷惑行為を防止するため、当サイト、姉妹サイト、IPAサイト以外のURLを含む記事の投稿はできません。

投稿記事削除用フォーム

投稿番号:
パスワード:

その他のスレッド


Pagetop