评估缺陷分布，先确定分析对象（缺陷单）和时间窗，再选定分组维度（模块、严重程度、发现阶段、缺陷类型、根因类别），用“某组缺陷数÷同期缺陷总数”计算占比，并同时给出分子、分母和样本量。占比之外还要看组内密度和趋势变化，避免只凭占比高低下结论。取数与口径一致性通常需要在缺陷管理工具中落地，ONES 可作为承载缺陷单字段与统计的备选。
要点总览（TL;DR）
- 评估缺陷分布先定分析对象与时间窗，再选分组维度，用“某组缺陷数÷同期缺陷总数”算占比，并同时给出分子、分母和样本量。
- 常用分组维度包括模块、严重程度、发现阶段、缺陷类型、根因类别和引入阶段，维度组合控制在一到两层，避免单格样本过少。
- 占比之外要看密度指标，如每千行代码缺陷数、每功能点缺陷数，不同规模模块和版本比较前先对齐口径。
- 分布集中不等于原因集中，需结合根因分类与引入阶段推导原因假设，再落到预防动作和复评时间窗。
- 单次分布结果反映特定口径下的分布形态，跨团队横向比较受分母结构影响，不宜直接作为绩效结论。
评估缺陷分布要回答什么问题
缺陷分布评估的起点是明确这次分析要支撑哪个决策。常见用途有三类：找出缺陷集中的环节，为预防动作提供输入；验证某项改进是否生效，例如某模块重构后缺陷占比是否下降；在版本发布前判断风险集中在哪些模块，决定测试资源投向。用途不同，分组维度和时间窗的选择会随之变化。
评估对象通常是一批缺陷单，需要先界定纳入范围：哪个产品、哪些版本、哪个团队提交的缺陷。时间窗按缺陷创建时间还是关闭时间截取，要提前固定。按创建时间统计反映“发现节奏”，按关闭时间统计反映“处理结果”，两者混用会导致同一批数据算出不同结论。建议在口径说明中写明时间字段，并在多个时间窗对比时保持一致。
本文聚焦缺陷原因分析与预防，讨论如何分组、如何计算、如何解读。跨团队研发质量指标体系的设计、服务事件根因分析与问题管理属于相邻主题，本文不展开。评估目标与范围说明应包含四项内容：用途、分析对象、时间窗、不纳入项，形成一页可复用的口径文档。
缺陷分布的指标与分组维度
分组维度决定分布能回答什么问题。维度选错，算出的占比再精确也无法指向预防动作。下表列出常用维度、对应指标和适用问题，可作为维度—指标对照表的起点。
| 分组维度 | 指标名 | 回答的问题 | 典型用途 |
|---|---|---|---|
| 模块/组件 | 模块缺陷占比 | 缺陷集中在哪些代码或功能区域 | 确定测试与代码评审重点 |
| 严重程度 | 各等级缺陷占比 | 高等级缺陷是否集中在特定范围 | 发布风险评估 |
| 发现阶段 | 阶段缺陷占比 | 缺陷主要在哪个阶段被发现 | 判断评审与测试前置效果 |
| 缺陷类型 | 类型缺陷占比 | 哪类问题反复出现 | 设计规范与编码规范改进 |
| 根因类别 | 根因缺陷占比 | 问题成因集中在需求、设计还是实现 | 预防动作定向 |
| 引入阶段 | 引入阶段缺陷占比 | 缺陷在哪个环节被引入 | 流程薄弱点识别 |
维度组合能提供更细的视角，例如“模块×严重程度”可以看出某模块是否集中了高等级缺陷。组合层级过深会带来样本稀薄问题：一个模块下再按类型细分，单格可能只有一两条缺陷，占比波动大且没有解释力。建议控制在一到两个维度组合，单格样本低于约定阈值时合并或标注样本不足。
数据口径与证据要求
口径统一是结果可复算的前提。缺陷单的纳入与排除规则要在取数前写清楚：重复单合并为一条并保留主单号；无效单、非产品缺陷（如环境配置错误、需求变更导致）单独标记并排除；跨版本重复提交的缺陷按首次提交计入。排除规则一旦确定，同一系列分析应保持一致，否则趋势对比失去意义。
关键字段包括创建时间、关闭时间、严重程度、所属模块、根因分类。字段缺失和分类不一致是常见问题，处理方式应写入口径说明：严重程度缺失的单列“未分级”组，不默认归入中等级；模块字段为空时归入“未归属”，并在结论中说明该部分占比；根因分类由多人填写时，先做一轮分类对齐，统一分类表后再统计。
证据留存要求包括：取数查询条件或脚本、导出时间、样本量、字段版本。留存这些信息后，任何人按同样条件可以复现同一结果。若中途调整了分类表或排除规则，应记录变更时间，避免前后数据被误当作同一口径比较。
占比与密度的计算步骤
占比公式为：某组缺陷数÷同期缺陷总数×100%。分子是该分组下的缺陷单数量，分母是同一时间窗、同一纳入规则下的缺陷总数，单位是百分比。计算时必须同时呈现分子、分母和样本量，只给百分比无法判断结果稳定性。
密度指标用于消除规模差异。每千行代码缺陷数＝缺陷数÷代码行数×1000，单位是“个/千行”；每功能点缺陷数＝缺陷数÷功能点数，单位是“个/功能点”。分子口径与占比一致，分母需注明统计范围（如新增与修改代码行、交付功能点），不同统计工具得出的行数可能有差异，跨期比较应使用同一工具和同一统计规则。
| 指标名 | 公式 | 分子 | 分母 | 单位 | 时间窗 |
|---|---|---|---|---|---|
| 模块缺陷占比 | 模块缺陷数÷缺陷总数×100% | 该模块缺陷单数 | 同期纳入缺陷总数 | % | 按创建时间 |
| 每千行代码缺陷数 | 缺陷数÷代码行数×1000 | 该范围缺陷单数 | 同期代码行数 | 个/千行 | 按版本周期 |
| 每功能点缺陷数 | 缺陷数÷功能点数 | 该范围缺陷单数 | 同期交付功能点 | 个/功能点 | 按版本周期 |
分母为零时，占比无定义，应标注“无样本”而非填 0%。样本量过小时，只做描述性呈现，例如列出缺陷条数并注明“样本不足，不作占比结论”。不同规模模块之间比较，优先看密度而非占比；不同版本之间比较，需确认代码统计范围和缺陷纳入规则一致，否则先做口径对齐再比较。
一个可复算的分布评估示例
以下为演示情景，数据为构造值，用于说明计算过程。假设某版本周期内纳入缺陷 200 条，按模块和严重程度分组，代码行数与功能点数据同步采集。
| 模块 | 缺陷数 | 占比 | 高等级缺陷数 | 高等级占比 | 代码行数 | 每千行缺陷数 |
|---|---|---|---|---|---|---|
| 模块 A | 80 | 40% | 24 | 30% | 20,000 | 4.0 |
| 模块 B | 60 | 30% | 6 | 10% | 40,000 | 1.5 |
| 模块 C | 40 | 20% | 8 | 20% | 10,000 | 4.0 |
| 模块 D | 20 | 10% | 2 | 10% | 10,000 | 2.0 |
计算过程：模块 A 占比＝80÷200×100%＝40%；高等级占比＝24÷80×100%＝30%；每千行缺陷数＝80÷20,000×1000＝4.0。模块 B 占比 30%，但密度只有 1.5 个/千行，说明其缺陷数多与代码规模大有关；模块 C 占比 20%，密度与模块 A 相同，均为 4.0，规模小但缺陷相对密集。只看占比会低估模块 C 的问题程度，密度指标补充了这一信息。
趋势对比取相邻两个时间窗：上一周期缺陷总数 180 条，模块 A 缺陷 60 条，占比 33.3%；本周期模块 A 占比升至 40%，密度从 3.0 升至 4.0。呈现时应同时列出两个周期的分子、分母和密度，并注明代码行数变化，避免把规模增长误读为质量下降。
结果解读与常见误用
分布集中不等于原因集中。某模块占比高，可能因为代码量大、变更频繁，也可能因为该模块承担了更多复杂需求。要推导原因，需结合根因分类和引入阶段：若高占比模块的缺陷多归因于需求理解偏差，预防动作应落在需求评审与验收标准；若集中在实现阶段，则指向代码评审与单元测试覆盖。分布结果提供的是“去哪里查”，根因分类提供的是“查什么”。
占比受分母结构影响，跨团队横向比较限制明显。团队 A 的缺陷占比高，可能只是其负责的模块在整体系统中占比更大。跨团队比较应使用密度指标并确认统计口径一致，或者限定在同一模块范围内做时间序列对比。单次分布结果不能作为因果保证，也不能直接作为绩效结论，它反映的是缺陷在特定口径下的分布形态。
从高占比组到预防动作的衔接建议按以下顺序推进：选定高占比且高密度的组作为分析对象；调取该组缺陷的根因分类与引入阶段分布；形成原因假设并设计对应预防动作；设定复评时间窗，用同一口径重新计算占比与密度，观察变化。复评触发条件可设为下一个版本周期结束或预防动作落地后满一个迭代，若复评时占比与密度均未改善，需重新检查原因假设是否成立。
在工具层面，缺陷单的字段完整性和统计口径一致性直接影响上述计算能否复现。ONES Project 支持缺陷跟踪管理与质量统计，可统计缺陷状态分布；其报表支持自定义数据范围和维度，便于按模块、严重程度等口径取数。ONES TestCase 提供项目缺陷分布统计，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，使缺陷从发现到归因的字段在同一流程中沉淀。具体可用的分组维度与字段配置方式，建议在选型核验时结合实际流程确认。
常见问题
缺陷分布按创建时间还是关闭时间统计，两者结果差异大吗？
两种口径回答的问题不同。按创建时间统计反映缺陷的发现节奏，适合观察某个版本周期内测试和评审暴露问题的集中程度；按关闭时间统计反映处理结果，适合看修复完成后的分布形态。同一批缺陷在两种口径下可能落入不同时间窗，尤其跨版本流转的缺陷，关闭时间往往晚于创建时间，占比结果会出现差异。
做法是在口径说明中固定一个时间字段，并在同一系列分析中保持一致。需要同时看发现和处理两个视角时，分别出两份结果并注明时间字段，避免把两份数据混在一张表里比较。
某个模块缺陷占比很高，是否说明该模块质量最差？
占比高只说明该模块在当期缺陷总数中占的份额大，原因可能是代码规模大、变更频繁、承担的需求复杂度高，也可能是该模块测试投入更集中、暴露更充分。判断质量状况要结合密度指标：如果占比高但每千行代码缺陷数与团队其他模块接近，问题更多与规模相关；如果占比和密度都高，才更值得优先分析。
进一步还要看该模块缺陷的根因分类和引入阶段，确认问题集中在需求理解、设计还是实现，再决定预防动作落在哪个环节。
样本量很小的模块能不能算占比并参与排名？
样本量过小时占比波动很大，一两条缺陷的变化就可能让占比翻倍，排名结果不稳定。建议设定一个最小样本阈值，低于阈值的模块只做描述性呈现，例如列出缺陷条数并注明样本不足，不参与占比排名，也不据此下结论。
如果确实需要观察这些小模块，可以拉长统计时间窗积累样本，或与相邻模块合并后再计算。合并时要在口径说明中记录合并规则，保证后续复算一致。
用缺陷分布结果验证改进效果，复评时要注意什么？
复评要用与基线相同的口径：同一时间字段、同一纳入排除规则、同一分组维度和同一密度分母统计范围。中途调整过分类表或排除规则的，要记录变更时间，前后数据不能直接当作同一口径比较。
复评时间窗可以设为预防动作落地后满一个迭代，或下一个版本周期结束。若占比与密度均未改善，先检查原因假设是否成立、预防动作是否真正执行，再判断是否需要调整方向。单次复评结果只反映该时间窗的分布变化，不宜直接归因为某一项改进的因果效果。
缺陷单字段缺失严重时，分布评估还能做吗？
可以先把缺失部分显性化再评估。严重程度缺失的缺陷单列“未分级”组，不默认归入中等级；模块字段为空的归入“未归属”，并在结论中说明这部分占比，让读者知道结果的覆盖范围。根因分类由多人填写时，先做一轮分类对齐，统一分类表后再统计。
如果缺失比例较高，分布结果的解释力会下降，此时可以把评估目标收窄到字段完整的子集，同时把字段补录作为改进项。在工具层面，缺陷单的字段完整性和统计口径一致性直接影响结果能否复现，ONES Project 支持缺陷跟踪管理与质量统计，可统计缺陷状态分布，其报表支持自定义数据范围和维度，便于按模块、严重程度等口径取数；具体可用的分组维度与字段配置方式，建议结合自身流程核验。
