跳到主要内容

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 的函数,须进行单元测试覆盖。

改进成果也应当是可量化的,便于持续度量,追踪改进效果。