BUG 量多不多，得看开发代码质量高不高了，代码质量高自然而然的就少。我希望 BUG 越少越好，覆盖率才是目标，而不是 BUG 量。

你让我想起了我现在的一个同事，一个字段一个 bug，开发直接麻了

bug 要有多个维度，纯看数量是没有参考意义的。一个高质量的 bug 跟十个无关紧要的 bug，我是觉得能发现高质量 bug 的人业务理解更深刻。bug 数量短时间内很多 (比如你说的一天内 30-40) 只能证明要么开发质量非常差，要么就是需求没完全对齐。如果开发质量稳定，产品需求明确，一天能发现几个高质量的 bug 就已经很不错了

要输出测试报告吗？如果一次测试完没登记几个 bug，之后产品业务验收、用户反馈一堆 bug，个人觉得很尴尬

得看提测质量的吧，能拆开定位的 bug 就拆开来好一点

我还没见过一天之类测试的内容能产出这么多 bug 的开发和发现这么多 bug 的测试，真是开了眼了

这种应该规范一下 bug 提交规范

用 bug 数当做质量指标是个误区

一个季度提了 76 个 bug,小组倒数第一，活没少干，绩效倒数第一，太操蛋了

好的开发，高质量转测 我宁愿少提。

我部门不以 bug 数作为衡量指标，只看工作效率和遗漏 bug 数。

一个季度就提了三个，被领导说了一顿

已最终生产质量，和提交 bug 质量为依据，这应该是测试开发一体去看待。就像有些测试 c1 他只测业务，很少关注技术实现，性能，安全等内容。如果出个事故就会出现高风险事故。c2 测试他的测试内容和用例设计都会考虑到性能和技术实现的优缺点能够提供更大范围的优化建议。你自己就知道哪个是好的，有效的，收敛的。所以单纯看数量没啥意义。

管它多少不过，线上不出问题才是最终结果

有病吧，已 bug 数量作为产出？

这起码是 10 多年前的测试工程师衡量标准吧，什么 bug 数、用例设计数、用例执行数

曾经一个版本有 300 多个 bug，原因就是开发质量不行，改 bug 能力也不行，改一个出五个那种。

如何要考核，线上 bug 率就很好。

没法恒定这个量 每个人测的模块和对应的开发水平、业务逻辑都不一样 如果非要拿你为什么提的比别人少 而不看最终产出结果 那就是闲的了（讲话了，规定时间内，活儿干好了没出毛病就行）

一个月只能提 10 多个

我试过一个版本开发质量太差；我和另外一个测试把这个项目版本的开发组长给堵了，让他回来给自己的组员改 bug

身处在这种环境应该怎么办，看他们连 ui 颜色和文案都在提，难倒打不过就加入么 ，我的 bug 数连他们一半都不到，经理看我产出那么少直接 diss，试着解释了一下，感觉她理解成我在让他们 “少提 bug”

可以加入，ui 颜色和文案这的的确确是 bug，只不过要标记成等级相对比较低的 bug

笑死，按 bug 数量考核，那我最好公司招的开发越烂越好，产品越做越烂

不是贬义，但是有时候，bug 的质比量更重要。其次，保证的是上线后的功能，用户反馈的线上 bug 少，那就是很好的测试了。