欠陥密度とは何ですか? 例で計算する式

欠陥密度とは何ですか?

欠陥密度 これは、特定の運用期間または開発期間中にソフトウェアまたはモジュールで確認された欠陥の数を、そのソフトウェアまたはモジュールのサイズで割ったものです。これにより、チームはソフトウェアのリリース準備が整っているかどうかを判断できます。

欠陥密度は、コード1,000行あたりでカウントされ、KLOC（コード行数）とも呼ばれます。この数値はサイズで正規化されているため、欠陥が多い大規模モジュールと欠陥が少ない小規模モジュールを同じ尺度で比較できます。これは、生のバグ数では決して不可能なことです。

この指標は通常、テストサイクルの終わりに報告され、 tracリリースごとにリリースが繰り返されるため、他のリリースと並んで表示されます。 欠陥管理プロセス に選出しました。 ソフトウェアテストのライフサイクル.

欠陥密度を計算する方法

欠陥密度を測定する式:

Defect Density = Defect count/size of the release

リリースの規模は、コード行数（LOC）で測定できます。

結果として得られる数値が意味を持つかどうかは、次の3つの要素によって決まります。

• サイズ単位。 LOCとKLOCは最も一般的な単位です。プログラミング言語に左右されないサイズ測定単位が必要な場合はファンクションポイントが使用され、モジュール単位またはコンポーネント単位で正規化するチームもあります。
• 欠陥とみなされるものは何ですか。 分子には、確認済みの欠陥のみを含める必要があります。重複、却下された報告、および機能強化要求は除外しなければならず、そうしないとコードの品質に変化がないにもかかわらず数値が膨らんでしまいます。
• 測定範囲。 システムテスト中に発見された欠陥、 回帰試験、そしてリリース後には異なることが説明されるため、期間は数字で示す必要があります。

欠陥密度の例

あなたのソフトウェア製品に3つのモジュールが組み込まれているとします。各モジュールには、以下の数のバグが発見されています。

• モジュール 1 = 10 個のバグ
• モジュール 2 = 20 個のバグ
• モジュール 3 = 10 個のバグ

合計バグ数 = 10+20+10 = 40

各モジュールのコード行数の合計は以下のとおりです。

• モジュール 1 = 1000 LOC
• モジュール 2 = 1500 LOC
• モジュール 3 = 500 LOC

合計ライン Code = 1000+1500+500 = 3000

欠陥密度は次のように計算されます。

Defect Density = 40/3000 = 0.013333 defects/loc = 13.333 defects/Kloc

以下のグラフが示すように、モジュールごとに同じ計算を適用する方が、合計値よりも有用です。モジュール2は1500行のコードで20個の欠陥があり、モジュール3はわずか500行のコードで10個の欠陥があります。そのため、バグの報告数は少ないものの、モジュール3の方が密度が高く、リスクが高いと言えます。

欠陥密度の標準規格

欠陥密度には決まった基準はありません。研究によると、 欠陥 1000行あたりのコード量は、一般的にプロジェクトの品質が良いことを示す指標とみなされており、この数値は業界で最も広く引用されている経験則である。

期待値は、対象分野によって異なります。航空電子機器や医療機器など、安全性が重視され規制対象となるソフトウェアは、1,000行あたり1件以下の欠陥を目標としていますが、一般的なビジネスアプリケーションは、通常この目標値を上回っています。カウントルール、サイズ単位、テスト深度は組織によって異なるため、公開されている研究から得られたベンチマークは、同じ方法で測定されたプロジェクトとのみ比較可能です。したがって、この指標の実用的な用途は社内での使用に限られます。つまり、同じ製品の以前のリリースと、同じ方法で測定されたリリースを比較するということです。

欠陥密度に影響を与える要因

同じコードベースでも、以下の要因によって欠陥密度は大きく異なる場合があります。

• Code 複雑。 深く入れ子になったロジックと高い 循環的複雑度 単純なコードよりも、1行あたりの欠陥が多く発生する。
• 考慮される欠陥の種類。 機能的な欠陥のみを数えるか、ユーザビリティ、ドキュメント、 機能しない 調査結果によると、分子は大幅に変化する。
• 考慮される時間範囲。 2週間のテストサイクルで測定された数値は、6か月間の実運用で測定された数値とは比較できない。
• 開発者およびテスターとしてのスキル。 経験豊富な開発者は欠陥を混入させる頻度が少なく、経験豊富なテスターは存在する欠陥をより多く発見するため、この2つの効果によって指標は正反対の方向に引っ張られる。
• テスト範囲。 探さなかった欠陥はカウントされないので、 テストカバレッジ 測定可能な密度の上限を暗黙のうちに制限する。

欠陥密度とその他の欠陥指標の比較

欠陥密度は、「既知の欠陥がどの程度集中しているか」という一つの疑問に答える指標です。それに加えて、3つの指標が、欠陥密度では答えられない疑問に答えます。そして、ほとんどのチームはこれらの指標をまとめて報告しています。

これら4つの指標をまとめて読むと、より全体像が把握できます。欠陥密度が低く欠陥漏洩が多いということは、コードがクリーンではなく、テストが不十分であることを示唆しており、これはまさに次のセクションで警告している誤読です。

欠陥密度の利点

欠陥密度の利点は以下のとおりです。

• これは、テストの効果を測定するのに役立ちます。
• これは、コンポーネント間およびソフトウェアモジュール間の欠陥集中度を区別するのに役立ちます。
• これは、修正や改善が必要な領域を特定するのに役立ちます。
• これは高リスクのコンポーネントを指摘するのに役立ち、直接 リスクベースのテスト.
• これは、さまざまな人材の研修ニーズを特定するのに役立ちます。
• これは、欠陥によって発生するテストや再作業の労力を見積もる際に役立つ可能性がある。
• ソフトウェアに残っている欠陥を推定できる。
• リリース前に、これまでに実施されたテストが十分かどうかを判断するのに役立ちます。
• これは、後のリリースを評価するための歴史的な基準となる。

欠陥密度の限界

この指標は計算は簡単ですが、誤解しやすいという側面もあります。リリース判断において、この指標にどれだけの重みを与えるべきかは、以下の制約事項によって決まります。

• 検出されない欠陥は目に見えない。 分子には実際にテストで発見された欠陥のみが含まれるため、テストが不十分なモジュールは実際よりも良い数値を報告することになる。
• 重症度は無視される。 支払いを不正に処理する欠陥と、見た目上の位置ずれは同じものとして扱われるため、深刻度を考慮した加重表示が必要となる。
• 欠陥の定義は様々である。 異なる方法で集計を行う2つのチームは、たとえ同じ組織内であっても、比較できない数値を生み出す。
• コード行数は、サイズを示す指標としては不十分である。 冗長なコードは何も改善することなく密度を低下させるだけであり、また、プログラミング言語間で単位を比較することはできない。
• この指標は操作される可能性がある。 境界線上の報告書を却下したり、行数を水増ししたりすることは、いずれも製品の品質を向上させることなく数値を良くするだけだ。

これらのことは、欠陥密度が無意味になることを意味するものではありません。むしろ、チーム同士を比較するためのスコアではなく、一貫して測定される単一製品の傾向指標となるということです。

欠陥密度を低減する方法

欠陥密度を紙面上の数値ではなく、真に低減するには、欠陥を早期に防止し、リリース前に残りの欠陥を発見する必要があります。以下に示す実践方法は、公開されているガイドライン全体を通して繰り返し見られるものです。

• テストをもっと早い段階で行うべきだ。 要件定義と設計の段階でテスターを関与させることで、曖昧さがコードになる前に発見でき、欠陥の除去コストが最も安くなる。
• Revマージする前にコードを確認してください。 ピアレビューは、論理エラー、要件の誤解、設計上の欠陥などを検出します。 単体テスト 探すために書かれた。
• 回帰テストスイートを自動化する。 すべてのコミットに対してチェックを実行します 継続的インテグレーション 新しいコードが記述されている間に、以前の不具合が再発するのを防ぎます。
• まずテストを書こう。 テスト駆動開発 各動作は実装前に指定されることを強制し、 突然変異試験 そうすれば、結果として得られたテストが本当に何かを主張していることを確認できる。
• 静的解析を使用してください。 自動コードスキャンにより、テスト実行前にヌル参照解除、リソースリーク、および複雑性のホットスポットが検出されます。
• 密度の高いモジュールをリファクタリングする。 欠陥密度分析によって最も問題のあるコンポーネントが特定されたら、それらを分割して簡素化することで、通常は複雑さと欠陥数の両方を削減できます。
• 欠陥をプロセスにフィードバックする。 振り返りにおける根本原因分析は、個々の欠陥を一時的な応急処置ではなく、プロセス改善へと転換させる。

Tracked リリースとリリースが並行して ソフトウェアテスト手法 欠陥密度は、カバレッジデータと組み合わせることで、成績表ではなく早期警告システムとなる。

よくあるご質問