defect-density
测试缺陷密度
| 属性 | |
|---|---|
| 指标定义 | 软件产品或程序正式发布上线前，在内部测试阶段发现的缺陷数与对应代码量或代码变更量的比值，用以表征测试缺陷的密度。 |
| 指标价值 | 测试缺陷密度是衡量软件质量的主要指标。 |
| 指标来源 | 项目管理系统、版本控制系统 |
| 实践域 | 测试 |
| 认知域 | 交付质量 |
| 度量范围 | 项目、团队 |
度量（Measure）
测试缺陷密度是很有价值的指标，能够用于度量代码质量、分析测试充分性、预测交付软件质量。但在实际使用中，应尽量避免将其作为考核指标，尤其是常见的千行代码缺陷密度指标。其潜在的负向牵引作用，容易引导团队成员做出一些对无益于长远、整体效能的行为，例如：
增大基数，增加无意义代码
把定长循环分开写，写成顺序方法
把可配置信息写死到代码中
大量的复制、粘贴代码
重新发明各种轮子
因此，建议将千行代码缺陷密度与代码复用度、合并请求通过率、圈复杂度等指标交叉分析，并使用千代码当量缺陷密度*替代千行代码缺陷密度，提高指标粉饰的成本，对冲单指标的负向牵引作用。
: 代码当量是基于深度代码分析的代码工作量指标，可有效避免换行、空行、死代码等噪音对代码规模的影响。推荐采用千代码当量缺陷密度，更合理地度量代码质量。
分析（Analyze）
环比分析
分析与历史数据相比，各版本、迭代、功能模块的千行代码缺陷密度是否处于合理区间（参照历史基线），过高或过低需分析原因。
通常测试缺陷密度过高（超过合理区间），表明版本质量偏低，测试发现与潜在缺陷密度均高于历史。反之，则需结合测试用例分析测试是否充分。连续观察多个数据点的缺陷密度变化，分析数据变化是否存在异常或规律性。
趋势分析
与横向对比指标绝对值相比，该指标的变化趋势更具比较意义。因为不同模块业务不同，复杂度也不同，趋势变化更能体现缺陷密度平缓收敛情况及软件质量的稳定性。
观察多个版本或连续周期内缺陷密度的变化趋势，对连续 3-6 个点上扬的数据进行提示分析。
下探分析
对千行代码缺陷密度异常偏高或偏低的项目/团队进行下探，分析缺陷密度相关模块和责任人，识别异常点分别是否存在聚集。
CMMI（Capability Maturity Model Integration 能力成熟度模型集成）
CMMI 等级 千行代码缺陷密度参考值 CMM1 级 11.95‰ CMM2 级 5.52‰ CMM3 级 2.39‰ CMM4 级 0.92‰ CMM5 级 0.32‰ 对于千行代码缺陷密度过高、过低的情况，应辩证分析。缺陷密度低不一定代表软件质量好，需结合测试覆盖度、缺陷严重级别等，分析测试方案合理性，同时，缺陷密度过高也需要结合缺陷定义、定级进行合理性分析。
对二次或多次打开的缺陷进行统计，并进行根因分析。
回顾（Review）
根据分析结果，进行异常值的调研，分析根本原因：
- 参照测试缺陷密度环比，及历史数据（基线）偏低或偏高的根本原因是什么。是版本质量问题还是测试不充分？数据的合理性是否解释得通？
- 缺陷密度的连续上扬的原因是什么？
- 缺陷密度是否集中于某些模块？原因是什么？
- 缺陷密度是否集中于某些成员？原因是什么？
- 缺陷 reopen 的原因是什么，对于超过 2 次以上打开的缺陷进行根本原因的分析。
- 对于严重级别高，影响范围广的缺陷，须针对缺陷进行水平展开排查、修复。同时，对影响重大的缺陷进行复盘。
- 重大缺陷的复盘需要对根本原因进挖掘，识别避免或解决该缺陷的关键措施，复盘可基于时间顺序或事件脉络进行，要点应包括：缺陷现象/描述、时间线、根因分析、关键措施及后续行动。
改进（Improve）
针对调研结果，给出对应改进方案。一方面，调整测试策略、测试方案。另一方面，强化开发侧质量内建，通过加强需求、设计、代码评审等环节，提高软件质量。
以下为可参考的改进思路：
- 测试前移、测试人员尽早参与需求/设计评审。
- 开发自测、代码评审。
- 及时解决技术债：提高代码复用度、降低圈复杂度、及时解决代码问题、增加单元测试、增加注释、优化模块性。
改进成果也应当是可量化的，便于持续度量，追踪改进效果。
线上缺陷密度
| 属性 | |
|---|---|
| 指标定义 | 软件发布后，线上发现的缺陷数与对应代码量或代码变更量的比值，用以表征线上缺陷的密度。如：线上千行代码缺陷密度、千代码当量缺陷密度。 |
| 指标价值 | 线上缺陷密度作为上线发布后的质量指标，代表了从研发阶段逃逸到交付后的缺陷密度，是用以评估软件产品质量、测试质量的指标之一。在软件开发生命周期的后期，修复检测到的缺陷的成本较高。 |
| 指标来源 | 项目管理系统、版本控制系统 |
| 实践域 | 运营 |
| 认知域 | 交付质量 |
| 度量范围 | 项目 |
度量（Measure）
- 按项目统计千行代码或千代码当量 缺陷密度。
- 按时间统计千行代码或千代码当量缺陷密度的变化趋势。
- 基于历史数据，建立千行代码或千代码当量缺陷密度的参考基线。
分析（Analyze）
- 同比分析：使用同类项目同时期线上缺陷密度进行比较分析，通过数据的上升、下降观察上线后产品质量的改进效果。
- 环比分析：分析最近一年项目的线上缺陷密度，按时间轴分析线上缺陷密度的变化情况，同时与历史基线进行比较，给出指标的上升、下降的判断分析。
- 趋势分析：以单项目发布后的等比时间（天、周、月）为单位，分析线上缺陷密度变化趋势，判断趋势上升幅度。\ 通过观察趋势放缓、平滑等变化，评估发布后产品质量的稳定周期是否合理。
- 横向分析：对比多项目线上缺陷密度，作为软件产品上线质量的评估参考。
- 分类分析：对线上缺陷类型、严重级别、所属模块进行分类分析，识别呈现聚集性分布的关键问题。
- 分析质量缺陷的来源包括但不限于：用户反馈、监控系统（log 信息）、第三方平台（电子商务）。
回顾（Review）
对于严重级别高的线上缺陷，应进行完整复盘。按照时间线，角色维度、事件顺序对缺陷进行根因挖掘、定位关键问题。
根据分析环节得出的量化结论，从是否漏测、所属模块、产生原因、发生周期、解决情况几个维度，组织进一步的数据下探及根因挖掘：
缺陷逃逸率
计算公式：
缺陷逃逸率 = 线上缺陷数/（线上缺陷数+测试缺陷数）这个指标可以与历史数据进行比较。如果数据超过历史及测试部门的可接受区间，则需进行分析漏测原因，强化用例设计执行和管理。
缺陷所属模块
通过分析缺陷分本，定位问题集中的关键模块。
针对缺陷集中模块的典型问题，需求、设计、开发、测试等各相关环节均需要制定针对性改进措施。
缺陷产生原因
按照产生原因将缺陷聚类，识别高风险的关键原因，讨论下一步的改进措施，精准降低同类缺陷数量。
缺陷发生周期
结合用户使用频率，系统更新优化、重构等具体情况，分析缺陷发生周期，为系统稳定性提供数据参考。
缺陷解决情况
统计上线缺陷的解决情况，可分为已解决、临时处理仍需继续改进、未解决等类型。
在此基础上，可继续探讨：临时方案是否可能造成其他缺陷；用户是否接受临时方案；计划如何继续改进；开发及测试环节应怎样避免同类缺陷发生等。
改进（Improve）
落实改进措施，明确提升目标、改进措施、验证周期及责任人。
按照缺陷发现越晚，复杂度越高，解决成本越高的原则，除了从测试设计及执行入手改进外，更应从前置环境开始质量的建设，实现缺陷发现阶段的前移。
以下为可参考的改进思路：
- 根据静态扫描问题的类型、数量、严重级别等，对静态扫描规则进行优化，减少误报漏报，尽量多暴露严重问题，提高工具可信度。
- 定义不同严重级别问题的解决比例要求，控制严重问题的积压，避免技术债堆积。
- 建立代码评审制度、策略，鼓励代码评审的推广实施。
- 结合实际情况，建立单元测试覆盖率要求。例如：圈复杂度大于 10 的函数，须进行单元测试覆盖。
改进成果也应当是可量化的，便于持续度量，追踪改进效果。