测试缺陷数
| 属性 | |
|---|---|
| 指标定义 | 软件产品或程序正式发布上线前，在内部测试阶段发现的缺陷数；或软件发布后，线上发生的缺陷数。缺陷是软件中存在的破坏正常运行能力的问题、错误，或者功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。 |
| 指标价值 | 1. 通过测试发现的缺陷数可为判断测试是否充分提供参考。 |
| 指标来源 | 项目管理系统 |
| 实践域 | 测试、运营 |
| 认知域 | 交付质量 |
| 度量范围 | 项目、团队 |
MARI 方法
度量
- 测试缺陷数是交付前，内部测试阶段发现的缺陷总数。
- 按项目统计上线后缺陷数量、缺陷累计新增数量。
测试缺陷数可以从项目或团队维度统计，统计维度包括：缺陷总数、缺陷严重等级、缺陷类型（业务、功能分类）、缺陷修复周期、缺陷归属（模块、责任人）、缺陷累计趋势。
分析
缺陷异常点
根据测试计划、定期或按需分析测试缺陷数，观察新增缺陷数，分析与历史相比，各版本缺陷新增是否处于合理区间（参照历史基线）。过高或过低需分析原因。
一般情况下，指标过高表明版本质量偏低，潜在缺陷高于历史；指标过低则需结合测试用例，分析测试是否充分。
连续观察多个数据点的新增缺陷数，分析数据变化是否存在异常或规律性。
缺陷严重等级
不同等级缺陷可使用加权方式给出得分，可参考使用DI值（Defect Index，DI值是衡量软件质量的高低的指标之一。
计算公式：
DI = 致命级别的问题个数*10+严重级别的问题个数*3+一般级别的问题个数*1+提示级别的问题个数*0.1）DI值可用于评估软件质量。根据业务特征、逻辑复杂度、技术新颖度等，不同项目或团队可以设置不同的DI值评分标准。
缺陷分类
可根据缺陷分布及严重等级，采用柱状图或帕累托，分析缺陷占比较高的功能模块、业务类别或相关分类，为测试策略的调整提供参考。
缺陷修复周期
统计分析缺陷从提交到修复各状态时长，识别阻塞状态，分析合理缩短缺陷修复周期的措施，进而缩短MTTR（Mean Time To Recovery）。
缺陷累计增长趋势
缺陷累计增长趋势，可用于判断缺陷的增速是否放缓，缺陷累计呈现平缓收敛趋势，是判断软件版本质量稳定的重要参考，也为产品是否符合交付条件提供判断依据。
通常连续3-6个点呈现缺陷0增长可作为软件版本质量判稳的参考原则。而对缺陷仍活跃且未呈现收敛趋势的情况，需进行根因回顾分析。
缺陷责任归属
缺陷责任归属分析，可为制定设计及代码评审策略提供参考，加强开发阶段质量内建。
相比缺陷数绝对值，缺陷密度（
缺陷密度 = 所属owner缺陷数/对应owner代码贡献规模）将代码贡献规模纳入考量，分析更加合理。通过强化设计及代码评审，实现缺陷检出前移，降低总体质量成本。
通过折线图，动态观察发布后缺陷数及累加趋势，分析缺陷的增幅、峰值及趋势是否趋向收敛，判断发布后版本的稳定性。
采用饼图，按缺陷的严重等级、缺陷类型进行分布分析，为评估缺陷的严重性及发版质量提供参考，可以历史数据为参照，进行对比分析，并对与历史水平的差异进行调查。
分析缺陷的来源包括，但不限于：用户反馈、监控系统（log信息）、第三方平台（电子商务）等，判断缺陷的主要来源渠道与缺陷数量及类型的关系。
回顾
根据量化分析结果，进行异常数据的调研，分析根本原因：
- 测试缺陷数相比历史基线，偏低或偏高的根本原因是什么？是版本质量问题还是测试不充分？数据合理性是否解释得通？
- 如测试缺陷数合理，缺陷DI值评分是否偏高？
- 缺陷是否在某个分类（比如某类项目、某类模块或某些成员）中存在群集现象？原因可能是什么？
- 观察多个版本或连续周期内缺陷的增长趋势，对缺陷未收敛的原因进行分析。
- 分析缺陷责任归属分布，对缺陷密度偏高的原因进行分析，对典型缺陷进行复盘，并落实改进措施。
造成缺陷逃逸的直接原因主要有两种：一种是测试人员设计测试用例不全面导致的遗漏，一种是有测试用例的覆盖，但是测试执行过程存在疏漏，导致一些显而易见的软件缺陷或本来应该发现的软件缺陷没有被测试出来。
以上是从测试环节本身分析得出的原因。从更全面的角度等来看，测试用例设计不全面或测试执行有遗漏的有多种潜在的根本原因：
- 需求不明确，导致测试人员对需求理解不到位，测试设计不够全面。
- 需求变更频繁，如在测试过程中发生需求变更，则容易导致测试人员获取到的需求不够及时、准确，测试案例不足以覆盖变更后的需求。
- 测试计划安排不够合理，测试时间过于紧张，导致测试人员没有充足的时间设计用例和执行测试。
- 测试设计人员对系统需求不够熟悉，或设计能力有限，案例覆盖度不够高。
- 测试执行人员与设计人员不同，不能全面理解测试用例的测试要点。
- 测试环境或版本与生产环境有差异，某些缺陷难以在测试环境被发现。
- 某些特殊数据才会出现的缺陷，因测试数据不足而难以发现。
- 设计人员和执行人员重视程度不足等主观因素
改进
针对回顾结果，对阻塞环节，从规范、流程、工具、行为等方面给出针对性改进措施，明确提升目标、改进措施、验证周期及责任人。针对缺陷逃逸可能的客观原因，制定针对性措施。
以下为可参考的改进思路：
- 建立基线，以评估测试缺陷数、新增缺陷数、缺陷严重级别评分、缺陷收敛趋势的合理性。
- 基于测试缺陷分析结果，评估版本质量，适当调整测试策略及措施。
- 测试尽早介入，在需求阶段就参与进来，加强需求的分析、确认和评审等工作，使测试人员可以充分理解需求以便设计准确而全面的测试用例。
- 控制需求变更的频次和时间，尤其是进入测试阶段后，尽量减少或避免需求变更，并在必要变更出现时加强信息的传达。
- 合理安排测试计划，和开发计划，避免开发时间延后从而挤占测试时间，为测试保留相对合理的设计和执行时间。
- 安排熟悉系统需求并掌握测试用例设计方法的人员设计测试用例，并加强对测试用例的评审。
- 如测试执行人员与设计人员不同，可安排案例评审和讲解会，确保测试执行人员全面掌握测试要点。
- 加强环境和版本管理，使测试环境尽量与生产环境一致。
改进成果也应当是可量化的，便于持续度量，追踪改进效果。