哈哈，的确现在就这样的，测试测完了还有 BUG 就算是测试的问题了，和开发没有关系，感觉整套思路下来大家都面向锅，而不是面向解决问题和发现问题去看了，每个 BUG 都上纲上线。

大哥我悟了

跟出这个指标的领导讲，你这个模型它还可以完善，千万不要讲是错的不合理的，要秉着打补丁的逻辑，建议应该从以前的 bug 指标里得出我们团队的数据模型，然后拍个脑袋乘个系数。而且 bug 是分严重层度的，还要按等级乘以系数，这样才和实际情况匹配。反正嘛，看到不合理的就配合着绕弯子，绕到大家知难而退，实在玩不起，就准备准备面试吧，玩不起跑总是可以的。

1，开控制台；2，大拆小；3，把开发打一顿每天必须写几个 bug。

我们之前公司要求每个测试一天要找出 5 个 BUG 不然不准下班

测试就是点工了，还要求 bug 数，有没有 bug 在测之前谁知道有多少

定这个规则的人不懂测试 不懂研发 凡是拿数量去做度量的 一律按照流氓处置

这个逼着开发写 bug 呀

真就面向 KPI 呗就

666

跟开发商量下,边界值文案这些故意整错几个

快被这破指标整吐了，还以为都这样，现在就一个问题前后端各一个，大问题拆小问题
想要 bug 数带来的安全感我就给你安全感

我悟了，** 项目经理就是想甩锅

我不生产 bug 我只是 bug 的搬运工！！！

bug 随着测试的深入肯定是越来越少的啊，这操作给我整懵了，感情你进的不是互联网公司，是 bug 生产基地啊

太可笑了，奇葩骚操作，头一次见

如果这样就达到 kpi 了，而且分分能超额完成！如果测试那边 A 了，还出 bug，这锅开发背，我觉得毋问题！

这是准备制定 KPI 考核么

那测试要 20 个才行

这是什么奇葩统计维度。。。

太无厘头了，我觉得不合理。
你觉得合理也不会来问了……