是的，只有一个指标，没有其他方向的支持很难推进下去，要用好指标，还是得研发测试一体来做。
比如样式问题，如果很多，要么说明 UI 走查得不细，要么就是前端做得太随意。多提缺陷是合理的，这样压力自然就给到了研发那边（需要给他们设定明确的千行代码 BUG 率），这等于反向促进他们，让他们以后提测的质量更高。
至于研发为了凑分母堆代码量，这就得看研发部门自己的内控方案了，是走 Code Review 还是 AI 代码审查，总有方案规范的。

哇。。对质量要求相当高。。 能否告知下你们属于 IT 里哪个行业的要求？

我们也是这么计划，但还是希望能再有个横向对比，看其他公司的指标对比我们的处于什么水平。

认同，这次还是想先调研看看不同 IT 业务的缺陷逃逸率都怎么定的。

有可能，但缺陷的重复率，无效率也是测试指标中的一环么，研发的千行代码缺陷量也应该是他们的指标一环。

同感，7% 有点高了。。所以豆包给的不太好参考，来这问问大家内部的逃逸率标准是什么

用项目整个周期内提交的所有缺陷 + 用户线上反馈缺陷

1. 有个完整的时间对齐三方对项目功能及细节的理解。不一致的会上就解决了。
2. 能够补充一些没考虑到的场景 ，经验丰富的研发会给出一些模块的测试重点（也可能开发时候没咋细琢磨，准备靠测试了）。
3. 出问题甩锅做准备。都没想到的测试点三方一起负责。

metersphere?

有，目标提供接口文档给 AI，自动生成接口用例 + 脚本，并能自动执行用例