缺陷分布是把缺陷按模块、严重程度、发现阶段、根因类别等可解释的维度拆开计数，再用占比和密度看清缺陷集中在哪、为什么集中。要让结果可复算，先定评估目标和统计范围，再固定字段口径与分母，最后结合样本量解读并落到预防动作。本文给出维度选择、公式、操作步骤与解读限制。
要点总览（TL;DR）
- 先定主目标再选维度：定位高风险模块看模块维度的缺陷数与密度，判断引入环节看引入环节与根因类别，验证预防效果看措施前后的同口径变化。
- 占比公式为某类缺陷数÷同期缺陷总数×100%，分母必须写明包含哪些状态；密度公式为缺陷数÷规模基数，基数来源与单位要随报表留存。
- 时间窗按发现时间或关闭时间只能选一种，跨周期对比前核对分母、时间字段与状态范围，口径不一致先调整再比较。
- 分布只反映集中程度，结论需抽样查看缺陷详情并结合根因分析；小样本、分母为零、口径变更与录入习惯差异都会影响可比性。
- 单一分布指标不适合评价个人或团队绩效，应结合需求规模、测试投入与业务复杂度综合判断。
评估目标：缺陷分布要回答什么
统计缺陷分布之前，先写清这次分析服务于哪个决策。目标不同，观察对象、维度组合和后续动作都会变化。没有目标的分布图容易变成“数字好看但没人用”的报表。
| 评估目标 | 观察对象 | 典型决策动作 |
|---|---|---|
| 定位高风险模块 | 模块/组件维度的缺陷数与缺陷密度 | 安排专项代码审查、补充测试用例、调整评审资源 |
| 判断缺陷引入环节 | 引入环节、根因类别、发现阶段的交叉分布 | 在需求澄清、设计评审或编码规范上增加拦截动作 |
| 验证预防措施效果 | 同一模块或同一根因类别在措施前后的占比与密度变化 | 保留有效动作、调整无效动作、设定复测时点 |
三类目标可以同时存在，但建议一次统计只设一个主目标，其余作为辅助观察。主目标决定分母怎么取、时间窗怎么划、维度交叉到什么程度。例如以“验证预防措施效果”为主目标时，必须保证措施前后使用同一口径，否则变化无法归因。
本文聚焦缺陷本身的分布统计与解读，跨团队质量指标体系设计、服务事件根因分析不在讨论范围内。若组织需要把缺陷分布并入更大范围的质量度量体系，应另行定义指标层级与汇总规则。
指标与范围：选哪些维度、圈多大范围
维度决定分布能回答什么问题，范围决定结果能和谁比较。两者需要一起确定，并在统计开始前写成文字。
常用维度
- 模块/组件：定位缺陷集中在哪个功能区域，是最常用的分布维度。
- 严重程度：区分阻断、严重、一般、轻微等分级，判断集中点的影响大小。
- 缺陷类型或根因类别：如需求理解偏差、设计缺陷、编码错误、配置问题，用于指向预防动作。
- 发现阶段：单元测试、集成测试、系统测试、验收或线上发现，反映拦截能力。
- 引入环节：需求、设计、编码、构建发布等，用于判断问题在哪个环节进入。
- 发现来源：测试、用户反馈、监控告警、内部评审等，反映发现渠道的覆盖情况。
统计对象范围
需要明确哪些缺陷进入统计。常见做法是只统计有效缺陷，剔除已拒绝和重复单；是否包含已关闭缺陷取决于目标——看历史积累时包含已关闭，看当前存量时只统计未关闭。产品版本或迭代范围也要写清，是按某个发布版本圈定，还是按迭代周期圈定。
时间窗
按发现时间统计反映“这段时间新暴露了多少问题”，按关闭时间统计反映“这段时间处理了多少问题”。两者口径不同，不能混用，也不能把按发现时间算出的占比与按关闭时间算出的占比直接比较。跨周期对比时，前后两个周期必须使用同一种时间字段。
维度数量控制
每增加一个交叉维度，单元格数量成倍增加，单格样本迅速变小。建议主分析使用一到两个维度，需要下钻时再增加维度。若某个交叉组合的缺陷数只有个位数，占比的波动会很大，解读时应标注样本量而非直接下结论。
数据口径：字段、分母与缺失值处理
口径写清楚，不同人才能算出同一结果。以下字段和公式需要在统计前固定，并随报表一起留存。
关键字段定义
| 字段 | 判定规则要点 |
|---|---|
| 模块归属 | 以缺陷提交时选择的模块字段为准；跨模块缺陷指定一个主归属模块，其余记录在关联字段 |
| 严重程度 | 使用团队统一的分级标准，明确各级的判定示例，避免同一问题不同人分级不同 |
| 根因类别 | 在缺陷关闭或根因分析时填写，类别列表保持稳定，新增类别需同步更新历史数据说明 |
| 发现阶段 | 按缺陷被发现时所处的测试或发布阶段记录，与缺陷状态流转区分开 |
| 引入环节 | 通过回溯确定，无法确定时标记为“未知”，不强行归入某一环节 |
占比与密度公式
占比公式：某类缺陷数 ÷ 同期缺陷总数 × 100%。分母必须写明包含哪些状态，例如“分母为统计期内创建且状态不为已拒绝、重复的有效缺陷数”。分母变化会直接改变占比，因此分母口径要与占比结果一起发布。
缺陷密度公式：缺陷数 ÷ 规模基数。规模基数可选千行代码、功能点、需求数、用例数等，需注明基数来源与单位。例如以需求数为基数时，单位为“个/需求”，基数取自同一版本的需求清单，不能混用不同版本的需求数。
缺失值与多标签处理
字段为空时，单独归入“未填写”类别并在报表中显示，不默认归入某一模块或某一根因。一个缺陷对应多个模块时，按主归属模块计数一次，避免同一缺陷在多个模块重复计入导致总数虚高。若业务确实需要多模块视角，另设一张按关联关系展开的报表，并注明与主报表不可直接相加。
去重规则
重复单在统计前合并到主单，只计一次；关联单保留各自记录，但在分析根因时视为同一问题簇。去重规则应写成可执行的判断条件，例如“同一模块、同一复现步骤、同一根因的缺陷合并为一条”。
计算与评估步骤：从取数到结论
按以下顺序执行，每一步都留下产出物，便于复核和下一周期复用。
- 取数与清洗：按确定的范围导出缺陷记录，剔除已拒绝和重复单，补齐模块、严重程度、根因等关键字段。产出：清洗后的缺陷明细表，附剔除记录数与剔除原因。
- 按维度汇总：对每个维度统计缺陷数，计算占比与密度。产出：维度汇总表，含分子、分母、占比、规模基数与密度。
- 同口径对比：与上一周期、同类模块或既定基线比较。对比前核对两边的分母、时间字段和状态范围是否一致，不一致时先调整再比较。产出：对比表与口径核对说明。
- 定位集中点并回溯原因：挑出占比或密度明显偏高的类别，抽样查看缺陷详情，归纳共同触发条件。产出：高占比类别的抽样记录与原因假设。
- 形成预防动作并设定复测时点：针对原因假设制定具体动作，明确责任人和完成时间，并约定下一周期用同一口径复测。产出：预防动作清单与复测计划。
缺陷记录、模块字段和状态流转需要在管理工具中承载，统计才有稳定的数据来源。ONES Project 适配缺陷管理等场景，提供缺陷跟踪管理与缺陷状态分布统计；ONES TestCase 支持未通过的用例快速创建缺陷任务，并提供项目缺陷分布统计与质量统计报表。报表可自定义数据范围和维度，团队可以把模块、严重程度等字段固化为统计口径，减少每次手工整理的工作。具体可统计的维度清单与分母设置，需以团队实际配置为准。
算例：一个模块维度的缺陷分布
以下为演示情景，数字用于说明公式与解读方式，不代表任何真实项目。
某版本共记录120个有效缺陷，其中支付模块45个。支付模块占比 = 45 ÷ 120 × 100% = 37.5%。若该版本支付模块对应30个需求，则支付模块缺陷密度 = 45 ÷ 30 = 1.5个/需求。
| 项目 | 数值 | 说明 |
|---|---|---|
| 有效缺陷总数 | 120个 | 已剔除拒绝单与重复单 |
| 支付模块缺陷数 | 45个 | 按主归属模块计数 |
| 支付模块占比 | 37.5% | 45 ÷ 120 × 100% |
| 支付模块需求数 | 30个 | 同一版本需求清单 |
| 支付模块缺陷密度 | 1.5个/需求 | 45 ÷ 30 |
与上周期对比时，应表述为“本版本支付模块缺陷占比37.5%，上版本为31.2%，两版本均按发现时间统计、分母均为有效缺陷数”。同时给出两版本的缺陷总数，本版本120个、上版本98个，说明占比上升发生在总量也上升的背景下，避免只看比例不看基数。
从占比高到原因假设的推演：支付模块占比37.5%，高于其他模块。抽样查看该模块缺陷详情，若发现多数集中在退款流程且根因多为需求理解偏差，可形成假设“退款规则在需求澄清阶段未被充分确认”。验证动作可以是补充退款场景的需求评审检查项，并在下一版本用同一口径复测该模块占比与根因分布。若复测后占比下降且根因类别中需求理解偏差减少，假设得到支持；若占比未变，则需检查其他原因。
解读与限制：哪些结论能下、哪些不能
缺陷分布反映集中程度，本身不证明原因。占比高只说明该类别缺陷数量相对多，是否由某个环节导致，需要抽样查看缺陷详情并结合根因分析。把分布图直接当作因果结论，容易把资源投到错误的方向。
以下情形需要特别标注，避免误读：
- 分母为零或规模基数缺失：某模块当期无缺陷时占比无意义；规模基数缺失时密度无法计算，应标注“不可比”而非强行填数。
- 小样本：某类别只有三五个缺陷时，占比的波动很大，应同时给出样本量，并说明结论的确定性有限。
- 口径变更：模块划分调整、严重程度分级修改、根因类别增删都会改变历史数据的可比性，跨期对比前需说明变更点。
- 录入习惯差异：不同团队填写模块和根因的细致程度不同，会影响分布形态，解读时应结合录入规范执行情况。
- 绩效评价：单一分布指标不适合评价个人或团队绩效。缺陷数与占比受需求规模、测试投入、业务复杂度影响，需结合多个指标和具体情境判断。
把上述限制写进报表说明，并在每次解读时附上样本量、时间窗和分母口径，缺陷分布才能成为定位高风险模块、判断引入环节和验证预防措施效果的可靠依据。
常见问题
缺陷分布应该按发现时间还是关闭时间统计？
取决于分析目的。按发现时间统计回答“这段时间新暴露了多少问题”，适合观察缺陷产生节奏和定位高风险模块；按关闭时间统计回答“这段时间处理了多少问题”，适合观察修复进度和积压情况。
两种口径不能混用，也不能把按发现时间算出的占比与按关闭时间算出的占比直接比较。跨周期对比时，前后两个周期必须使用同一种时间字段，并在报表中注明。
一个缺陷涉及多个模块时，统计时怎么计数？
建议指定一个主归属模块，按主归属模块计数一次，其余模块记录在关联字段中。这样能保证各模块缺陷数之和等于缺陷总数，占比分母不会虚高。
如果业务确实需要多模块视角，可以另设一张按关联关系展开的报表，并注明它与主报表不可直接相加。字段为空时单独归入“未填写”类别显示，不默认归入某一模块。
模块缺陷占比高，是否说明该模块质量差？
占比高只说明该模块缺陷数量相对多，不能直接推出质量差。模块的需求规模、业务复杂度、测试投入和变更频率都会影响缺陷数量。同样45个缺陷，对应30个需求和对应100个需求，含义完全不同。
建议同时看缺陷密度，即缺陷数÷规模基数，并抽样查看高占比类别的缺陷详情，归纳共同触发条件后再形成原因假设，用下一周期的同口径复测来验证。
统计口径中途调整过，历史数据还能对比吗？
可以对比，但需要先处理口径差异。模块划分调整、严重程度分级修改、根因类别增删都会改变历史数据的含义，直接比较会得出误导性结论。
常见做法是按新口径回溯重算历史数据，或在报表中标注变更点和影响范围，只对比口径一致的部分。若无法回溯，跨期对比时说明变更内容，并把结论限定在可比区间内。
缺陷分布结果怎么落到预防动作上？
先挑出占比或密度明显偏高的类别，抽样查看缺陷详情，归纳共同触发条件，形成可检验的原因假设。再针对假设制定具体动作，例如补充需求评审检查项、增加特定场景的测试用例、调整代码审查重点，并明确责任人和完成时间。
同时约定下一周期用同一口径复测，观察该类别占比与根因分布是否变化。复测结果支持假设就保留动作，不支持则检查其他原因，避免把一次分布结果当成最终结论。
