难道不应该算线上缺陷数？都线上缺陷了，还看概率？

哎，我司现在某些度量指标有些真的是一言难尽。。。

是啊，应该看个数

按影响程度排序，统计个数

按影响程度定级，每个月统计各个级别的数量。看影响比较严重的级别个数是否在下降。

同时做好每次影响严重故障的复盘，落实改进措施。相比大的统计数据，找到根因、避免再犯更重要。

线上应该按照缺陷定级来统计，严重的有多少，是否影响功能等等作为依据

产品或者团队如果有一个比较长的成长期，比如内部业务核心系统这种，在成长期看缺陷消除率
稳定成熟期，就看个数，发现一个分析一次，管你写了十行还是十万行代码……

这里面有几个问题

第一 线上缺陷分为本版本引入和历史遗留爆发两种
我见到过一个项目，线上发现的缺陷 90%+ 是历史是当前测试人员接收以前的版本引入的历史遗留 bug，就是那么多历史遗留 bug 不容易被发现，也不一定就是当前测试人员牛逼，也不一定之前测试人员不行，可能是当前测试人员漏的 bug 可能在两三年后在线上被发现呢。 这种情况下 该怎么统计才合理，如果严格按照这个线上故障率统计，结果只能是负责这个项目的人永远绩效很差，没多久就跑路。

第二 线上缺陷的界定往往由运维团队界定，比如一个服务有三百多个监控项，运维看不过来，只挑二十几个主要的看，然后某一次在这二十几个之外，三百多个之内的一个监控项有异常之后不久服务挂了，经过讨论大家认可这种情况属于使用方使用不当给与短时间负载过高，挂了是合理的，但没告警不合理，运维坚持二十几个主要告警里看不出来，所以这是缺陷，开发说我三百多个告警呢谁让你只看那二十几个的，这不是缺陷？ 这种扯皮怎么算，究竟算线上缺陷数 +1 还是不算？

第三 测试阶段发现的 bug 也分为测试中发现历史遗留 bug 和发现当前版本 bug 啊，要区分开吗？

这里面有几个问题

第一 线上缺陷分为本版本引入和历史遗留爆发两种
我见到过一个项目，线上发现的缺陷 90%+ 是历史是当前测试人员接收以前的版本引入的历史遗留 bug，就是那么多历史遗留 bug 不容易被发现，也不一定就是当前测试人员牛逼，也不一定之前测试人员不行，可能是当前测试人员漏的 bug 可能在两三年后在线上被发现呢。 这种情况下 该怎么统计才合理，如果严格按照这个线上故障率统计，结果只能是负责这个项目的人永远绩效很差，没多久就跑路。

第二 线上缺陷的界定往往由运维团队界定，比如一个服务有三百多个监控项，运维看不过来，只挑二十几个主要的看，然后某一次在这二十几个之外，三百多个之内的一个监控项有异常之后不久服务挂了，经过讨论大家认可这种情况属于使用方使用不当给与短时间负载过高，挂了是合理的，但没告警不合理，运维坚持二十几个主要告警里看不出来，所以这是缺陷，开发说我三百多个告警呢谁让你只看那二十几个的，这不是缺陷？ 这种扯皮怎么算，究竟算线上缺陷数 +1 还是不算？

第三 测试阶段发现的 bug 也分为测试中发现历史遗留 bug 和发现当前版本 bug 啊，要区分开吗？

还要区分历史遗留和当前版本……你这个指标是为了产品质量负责还是为了测试工程师的绩效负责？
另外，线上缺陷上报是有标准的，而且这个数量指标运维也要背，如果一个团队的目标都不一致那还不如团伙呢……