最近团队内部在进行质量度量体系的优化，我们在讨论关于缺陷逃逸率的设定标准，想当作年度指标。
通过网络，豆包查询了一些得到的都是一些参考：
优秀水平：<7% 代表质量控制严格，测试覆盖充分（如腾讯部分系统、金融机构案例）。
一般水平：7%~10% 行业常见范围，需持续优化测试流程。
需改进水平：>10% 质量控制存在显著风险，需优先排查需求评审、用例设计等环节。
想了解下大家公司目前是否有明确的缺陷逃逸率标准？ 希望能够听到的朋友们的真实数据
缺陷逃逸率的分母是哪个呢？
想起我上一家公司，也算是一线大厂吧，当时负责的是信贷系统，领导给定的缺陷逃逸率<2%，年底总结每次拉缺陷数据我都感觉很好笑，还好也都差不多达标了。
缺陷逃逸率的分母是哪个呢？+1
7%，还能优秀，这得多小的用户量或者多垃圾的质量啊
我们做编辑器的，还挺高的
22/563+22=0.037
好奇一点, 为了数据好看, 会不会导致一些很小的问题也提一个 bug, 或者一个 bug 拆分成多个
这个要看业务的，不同的业务不可能拉在一个线上对比。就比如 toB 业务，7% 的逃逸率估计算一般或略差；但是对于 toC 尤其是带开发者开放属性的业务，逃逸率 10%+ 是正常的，因为长尾场景多得数不来。
而且问题逃逸也不一定代表什么，毕竟逃逸风险有高有低，同时，当下的测试资源和业务阶段也是影响逃逸率的重要因素。
故，你要找到同领域同类型（最好还是阶段类似）的业务去对比。
我们也有缺陷逃逸率的要求，但是我们不是说定一个标准就行了；我们领导要求我们对比上一年同期的缺陷逃逸率，要求下降多少
0.6% 我们的指标
这个得看业务吧 区别挺大的
说起这个，我就很惆怅
很多新的业务场景，没有需求方，列不清楚，遇到了才知道
奇迹的迹奇
回复
不是说重复缺陷, 或者无效缺陷, 比如样式问题, 如果没有考核,那么写个文档所有样式问题放一起, 要考核那就一个样式一个缺陷
千行代码缺陷量也是, 本来少量的代码能解决的, 为了数据把代码量堆上去, 而且不同模块的代码本身要求差异就大, 比如业务代码和核心算法
总之个人觉得这些指标都比较形式化, 属于面对复杂质量问题无奈的表现, 不去深究问题根因试图靠简单的指标解决问题
本身这是一个循序渐进的过程，先有指标，再把不同数据纳入指标。这也是一个团队不团提升的过程。例如先 2%，但是指标数据是测试介入需求引起，下一个阶段就是需求缺陷，再下一个阶段就是所有需求。有这个过程的团队一般也是正规的公司才会有。
吼猴
回复
是的，只有一个指标，没有其他方向的支持很难推进下去，要用好指标，还是得研发测试一体来做。
比如样式问题，如果很多，要么说明 UI 走查得不细，要么就是前端做得太随意。多提缺陷是合理的，这样压力自然就给到了研发那边（需要给他们设定明确的千行代码 BUG 率），这等于反向促进他们，让他们以后提测的质量更高。
至于研发为了凑分母堆代码量，这就得看研发部门自己的内控方案了，是走 Code Review 还是 AI 代码审查，总有方案规范的。
奇迹的迹奇
回复
认同使用这些指标作为质量管理的引入点, 但不认同长期使用. 上有政策下有对策, 好的指标使团队聚焦提高战斗力, 但有的指标使团队陷入内耗