评估缺陷分布，先要准备三类材料：缺陷台账的原始字段、分类与统计口径说明，以及支撑归因的补充记录。把缺陷按模块、严重度、发现阶段、根因类型和时间窗统一归类后，才能算出占比、集中度和趋势，并判断分布是否真实反映风险。本文围绕缺陷原因与预防展开，给出可复算的指标定义、数据清单和操作步骤。
要点总览（TL;DR）
- 评估缺陷分布需要三类材料：缺陷台账原始字段、分类与统计口径说明、支撑归因的补充记录（版本环境、复现步骤、根因分析结论）。
- 核心指标包括模块缺陷占比、模块缺陷密度、严重度构成、发现阶段分布和重开率，每个指标都要写明分子、分母、时间窗和单位。
- 统计范围要提前约定纳入的缺陷状态、版本归属规则、重复缺陷处理方式和时间窗起止，否则不同人导出的数据无法比较。
- 操作按五步推进：定范围、导数据并清洗、分类校验、计算占比与密度、结合根因证据解释并形成预防建议。
- 占比高不等于风险高，需结合模块规模和严重度一起看；分布是线索，根因判断要有证据支撑，不设通用达标线。
评估缺陷分布要回答什么问题
评估缺陷分布的直接目的，是找出缺陷在哪些模块、阶段或类型上集中出现，为预防动作提供落点。它服务于改进决策，例如决定下一轮迭代把评审资源投向哪个模块、在哪个阶段增加检查，或者验证上一轮预防措施是否生效。
一份可用的评估结论需要回答三个问题：
- 集中在哪：缺陷在模块、严重度、发现阶段、根因类型上的分布形态是什么，哪些位置占比或密度明显偏高。
- 为什么集中：结合版本变更、环境、复现步骤和根因分析记录，解释集中现象背后的技术或流程原因。
- 是否在改善：与自身历史基线对比，观察同类缺陷的占比或密度是否随时间下降。
本文的范围限定在缺陷原因分析与预防视角，即围绕缺陷记录本身做分布统计和归因。跨团队研发质量指标体系（如多团队横向排名、组织级质量评分）和线上服务事件的根因分析，属于另外的评估任务，本文不展开。明确这条边界，可以避免把缺陷分布数据强行套用到它无法支撑的结论上。
缺陷分布评估的指标与统计范围
指标定义要写到可以复算的程度：每个指标都明确分子、分母、时间窗和单位，换一个人拿同样的数据能算出同样的结果。下表列出常用指标的口径。
| 指标 | 公式 | 分子 | 分母 | 时间窗 | 单位 |
|---|---|---|---|---|---|
| 模块缺陷占比 | 模块缺陷数 ÷ 缺陷总数 | 统计范围内归属该模块的缺陷数 | 统计范围内全部缺陷数 | 按版本或迭代，或固定自然月 | 百分比 |
| 模块缺陷密度 | 模块缺陷数 ÷ 模块变更规模 | 该模块缺陷数 | 该模块同期代码变更量（如变更行数）或需求点数 | 与缺陷统计同一时间窗 | 个/千行 或 个/需求点 |
| 严重度构成 | 某严重度缺陷数 ÷ 缺陷总数 | 致命、严重、一般、轻微各档缺陷数 | 缺陷总数 | 同上 | 百分比 |
| 发现阶段分布 | 某阶段发现缺陷数 ÷ 缺陷总数 | 单元测试、集成测试、系统测试、验收、上线后各阶段发现数 | 缺陷总数 | 同上 | 百分比 |
| 重开率 | 重开缺陷数 ÷ 已关闭缺陷数 | 关闭后被重新打开的缺陷数 | 统计范围内已关闭的缺陷数 | 按关闭时间落入窗口 | 百分比 |
统计范围需要在取数前写清楚，否则不同人导出的数据无法比较。至少要约定四项：
- 纳入的缺陷状态：是只统计已关闭缺陷，还是包含处理中、待验证的缺陷。做趋势分析时通常按发现时间纳入全部状态，做修复质量分析时按关闭时间纳入已关闭缺陷。
- 版本或迭代范围：按发现版本归属，还是按修复版本归属，两者会产生不同的分布结果，需在口径说明中固定一种。
- 重复缺陷的处理：重复缺陷是否计入总数。若计入，需单独标注重复标记，避免同一问题被放大计数。
- 时间窗的起止：明确起止日期和时区，跨版本对比时保证每个窗口长度一致。
需要准备哪些数据与证据
所需材料可以分为必需字段、口径说明、补充证据和数据质量证据四类。必需字段支撑占比和密度计算，补充证据支撑归因解释，质量证据决定结论可信度。
| 类别 | 内容 | 支撑的指标或用途 | 必需性 |
|---|---|---|---|
| 缺陷台账字段 | 缺陷编号、所属模块/组件、严重度、优先级、发现阶段、发现时间、关闭时间、状态、根因分类 | 全部占比、密度、重开率指标 | 必需 |
| 规模数据 | 各模块同期代码变更量或需求点数 | 缺陷密度 | 计算密度时必需 |
| 口径说明 | 维度字典、严重度定义、根因分类标准、状态流转定义 | 分类一致性与结果可复算 | 必需 |
| 补充证据 | 版本与环境信息、复现步骤、根因分析记录、评审或复盘结论 | 解释集中原因、形成预防建议 | 补充 |
| 质量证据 | 字段完整率、分类一致率 | 判断结论可信度与适用范围 | 补充但建议保留 |
口径说明是容易被忽略的一项。维度字典要写明模块划分规则，例如按代码仓库目录还是按业务功能划分；严重度定义要给出每一档的判断标准；根因分类标准要列出可选类别，如需求理解偏差、设计缺陷、编码错误、配置问题、环境问题。没有统一字典，不同人填写的分类会互相冲突，分布结果随之失真。
补充证据的作用是把“哪里多”推进到“为什么多”。版本与环境信息帮助判断缺陷是否集中在特定发布批次；复现步骤和根因分析记录提供技术层面的解释；评审或复盘结论则可能已经指出流程环节的问题。这些材料不必对每条缺陷都齐全，但覆盖集中区域的主要缺陷，归因才有依据。
数据质量证据用两个比率衡量：字段完整率是必填字段非空的缺陷数占缺陷总数的比例；分类一致率是抽样复核后分类正确的缺陷数占抽样数的比例。两者偏低时，应先补数据再下结论。缺陷台账、分类字典和统计视图通常由缺陷管理工具承载。以 ONES 为例，ONES Project 支持缺陷跟踪管理并统计缺陷状态分布，ONES TestCase 提供项目缺陷分布统计，可作为台账与统计视图的承载位置；具体可选维度和字段配置以实际产品界面为准。
计算与评估步骤
从取数到形成结论可以按五步推进，每步都有明确的输入和产出，便于复核和复用。
步骤一：确定时间窗与统计范围
输入是评估目的和口径说明，动作是写下时间窗起止、纳入的缺陷状态、版本归属规则和重复缺陷处理方式，产出是一页统计范围说明。这份说明要与后续所有数字一起存档，保证结论可追溯。
步骤二：导出并清洗缺陷台账
按统计范围导出缺陷记录，然后处理三类问题：缺失字段，标记为空值并记录缺失比例；重复缺陷，按重复标记去重或单独归类；跨模块归属，对涉及多个模块的缺陷约定主责模块规则，例如按缺陷首次发现位置或修复提交所在模块归属。产出是清洗后的分析数据集和一份清洗记录。
步骤三：按维度分类并校验一致性
依据维度字典给每条缺陷打上模块、严重度、发现阶段和根因分类标签。随后抽样复核，计算分类一致率。一致率明显偏低时，回到字典检查定义是否清晰，或对争议类别补充判定示例。产出是带完整分类标签的数据集和一致率数值。
步骤四：计算占比、密度与集中度
按第二节的公式逐项计算。集中度可以用排名前几位模块的缺陷占比之和表示，也可以用各模块占比与均匀分布的偏离程度描述。计算时同步记录分母，分母为零的指标单独标注，不参与横向比较。产出是指标结果表。
步骤五：结合根因证据解释并形成预防建议
对占比或密度偏高的模块和类型，调取对应的版本信息、复现步骤和根因分析记录，判断集中原因是技术复杂度、需求变更频繁、评审覆盖不足还是测试环境差异。解释成立后，再对应提出预防动作，例如在需求评审阶段增加某类检查、对高频出错模块补充自动化用例。产出是评估结论与预防建议清单。
一个可复算的示例
以下为演示情景，数字用于说明计算方法，不代表任何真实项目。
假设某版本统计窗口内共有缺陷 120 个，涉及三个模块，同期代码变更量如下：
| 模块 | 缺陷数（个） | 缺陷占比 | 代码变更量（千行） | 缺陷密度（个/千行） |
|---|---|---|---|---|
| 模块 A | 60 | 60 ÷ 120 = 50% | 10 | 60 ÷ 10 = 6.0 |
| 模块 B | 36 | 36 ÷ 120 = 30% | 30 | 36 ÷ 30 = 1.2 |
| 模块 C | 24 | 24 ÷ 120 = 20% | 2 | 24 ÷ 2 = 12.0 |
从占比看，模块 A 最高，占一半缺陷；从密度看，模块 C 最高，每千行变更对应 12 个缺陷，是模块 A 的两倍。两个指标给出不同信号：模块 A 缺陷绝对数量多，与其变更规模较大有关；模块 C 变更量小但缺陷密集，更值得优先排查。这说明占比和密度需要一起看，单看占比容易把规模因素误读为质量因素。
边界情况的处理方式如下：若模块 C 当期变更量为零，密度分母为零，此时密度记为“不适用”，只报告缺陷数和占比，不参与密度排序；若某条缺陷的模块字段为空，计入“未分类”单独一行，并在结论中说明未分类占比，避免它稀释各模块占比；若某模块严重度字段缺失，严重度构成计算时将其排除在分母之外，同时报告缺失数量。
对应到预防动作：模块 C 密度高且变更量小，适合先做代码走查和补充单元测试，确认是否存在集中的编码错误类型；模块 A 缺陷数多，可结合根因分类查看是否集中在某类需求变更，若是，则在需求评审环节增加对应检查项。下一版本用同样口径复算，观察两个模块的密度是否下降，作为预防措施是否有效的判断依据。
如何解读结果与规避误判
分布结果是线索，不是结论。解读时需要守住几条边界，避免把统计现象直接当作风险判断或绩效评价。
- 占比高不等于风险高。缺陷多的模块可能只是变更规模大、业务逻辑复杂。要结合模块规模和严重度构成一起看，严重缺陷集中的小模块，风险可能高于一般缺陷多的大模块。
- 样本量小、时间窗短时结论不稳定。缺陷总数只有十几个时，单个缺陷的增减就会让占比大幅波动。此类结果适合作为观察记录，不宜据此做资源调整。
- 分类口径不一致会让分布失真。不同人按各自理解填写根因分类，统计出的类型分布反映的是填写习惯差异。分类一致率偏低时，先统一字典再解读。
- 分布指向线索，根因需要证据支撑。某类缺陷占比上升，只能说明该类问题出现得多，具体原因要结合版本变更、环境差异和根因分析记录判断。统计相关性不构成因果保证。
- 不设通用达标线。缺陷密度、重开率没有放之四海皆准的合格值，不同产品、不同模块的技术特征差异很大。应建立自身历史基线，用趋势变化判断改进效果。
把这些限制写进评估报告，结论的适用范围就清楚了：读者知道哪些判断有数据支撑，哪些还需要进一步验证。缺陷分布评估的价值，正在于用可复算的数据把改进注意力引向真正集中的环节，再由根因证据决定具体动作。
常见问题
缺陷总数很少时，缺陷分布评估还能做吗？
可以做，但结论要限定用途。缺陷总数只有十几个时，单个缺陷的增减就会让占比大幅波动，此时的分布结果更适合作为观察记录，用来发现苗头，不宜据此调整资源或评价团队。若确实需要判断，可以拉长统计窗口、合并相邻版本，或改用缺陷绝对数量和严重度构成来描述，同时注明样本量。
同一缺陷涉及多个模块，归属怎么定？
需要在口径说明中固定一条主责模块规则，常见做法是按缺陷首次发现位置归属，或按修复提交所在模块归属。选定后对所有跨模块缺陷统一执行，并在数据集中保留涉及的次要模块信息，便于后续按需重算。规则不统一会让同一批数据算出不同的模块分布，横向比较就失去意义。
根因分类各人填得不一样，分布结果还能用吗？
先看分类一致率。抽样复核后若一致率明显偏低，说明字典定义不够清晰，应先补充每一类的判定标准和示例，再重新分类。在一致率达标之前，根因类型的分布反映的更多是填写习惯差异，可以用于发现争议点，不宜直接作为预防动作的依据。模块、严重度、发现阶段等结构化字段通常比根因分类更稳定，可优先使用。
缺陷分布统计在工具里怎么落地？
缺陷台账、分类字典和统计视图通常由缺陷管理工具承载。ONES Project 支持缺陷跟踪管理并统计缺陷状态分布，ONES TestCase 提供项目缺陷分布统计，可作为台账与统计视图的承载位置；具体可选维度、字段配置和统计口径以实际产品界面为准。工具承载的是数据，指标定义和统计范围仍需团队自己写清楚。
评估结果要不要设一个缺陷密度的合格线？
不建议设通用合格线。不同产品、不同模块的技术特征差异很大，同一密度数值在复杂核心模块和简单配置模块上的含义完全不同。更稳妥的做法是建立自身历史基线，用同一口径逐版本复算，观察密度和占比的趋势变化，以此判断预防措施是否生效。
