缺陷指标

研发团队每周关闭 120 个缺陷，不代表质量一定变好：如果其中 30 个在下一轮测试中重开，另有 8 个高严重度问题在发布后才被发现，“关闭数”就更像流程活动量，而不是用户风险下降…

研发团队的缺陷数量下降了，质量就一定变好了吗？我在做缺陷流程诊断时，最常看到的反常识现象是：团队把关闭速度提高了，线上问题却没有减少；Bug 看板越来越干净，重复缺陷、回归缺陷和“…

缺陷流程最容易出现的误判，不是“Bug 数量太多”，而是团队把“关闭率高”当成“质量变好”。一个版本可以在发布前关闭九成缺陷，却仍然把高风险问题带到线上：因为缺陷可能被重复建单、被…

同一个版本里，缺陷从 86 个降到 41 个，项目看起来进步明显；但如果这 41 个里有 12 个是上线后才发现的严重问题，团队可能只是把问题从测试阶段推到了生产环境。做 Bug …

一个版本里 Bug 从 180 个降到 96 个，团队看起来像是效率提升了；但如果其中 30 个缺陷只是被合并、搁置或延迟到上线后才暴露，这个数字就不能说明质量变好。做 Bug 分…

一个团队一周关闭了 180 个 Bug，项目经理却仍然不知道版本是否更稳定：其中 60 个是重复单，20 个在验证后重新打开，另有 35 个被标成“已修复”却没有关联代码提交。缺陷…

项目经理最容易误判的缺陷风险，不是“今天新增了多少个 Bug”，而是一个高优先级缺陷在多少个环节里失去了负责人、时限或验证证据。缺陷总数下降，可能只是团队少报了；关闭率上升，也可能…

项目经理最容易被“缺陷总数下降”误导：某版本缺陷从 120 个降到 80 个，看起来质量变好；如果同期测试投入翻倍、需求范围缩小一半，或者严重缺陷被改成普通缺陷，这个数字就没有证明…