恒温
#1 ·
2025年09月16日
6 个赞
bug 数量考察测试同学，会导致行为变形的。你可以把一个缺陷拆成 n 个 bug 来报。
橙子
#2 ·
2025年09月16日
BUG 量多不多，得看开发代码质量高不高了，代码质量高自然而然的就少。我希望 BUG 越少越好，覆盖率才是目标，而不是 BUG 量。
只想赚钱啊
#25 ·
2025年09月16日
2 个赞
对
恒温
回复
你让我想起了我现在的一个同事，一个字段一个 bug，开发直接麻了
吹落如雨
#4 ·
2025年09月16日
bug 要有多个维度，纯看数量是没有参考意义的。一个高质量的 bug 跟十个无关紧要的 bug，我是觉得能发现高质量 bug 的人业务理解更深刻。bug 数量短时间内很多 (比如你说的一天内 30-40) 只能证明要么开发质量非常差，要么就是需求没完全对齐。如果开发质量稳定，产品需求明确，一天能发现几个高质量的 bug 就已经很不错了
异彩飞天
#5 ·
2025年09月16日
要输出测试报告吗？如果一次测试完没登记几个 bug，之后产品业务验收、用户反馈一堆 bug，个人觉得很尴尬
test_study
#22 ·
2025年09月16日
得看提测质量的吧，能拆开定位的 bug 就拆开来好一点
天下谁人不识君
#21 ·
2025年09月16日
3 个赞
我还没见过一天之类测试的内容能产出这么多 bug 的开发和发现这么多 bug 的测试，真是开了眼了
天下谁人不识君
#8 ·
2025年09月16日
对
只想赚钱啊
回复
这种应该规范一下 bug 提交规范
究客
#9 ·
2025年09月16日
用 bug 数当做质量指标是个误区
我要下班
#10 ·
2025年09月16日
1 个赞
一个季度提了 76 个 bug,小组倒数第一，活没少干，绩效倒数第一，太操蛋了
天邪泪
#11 ·
2025年09月17日
好的开发，高质量转测 我宁愿少提。
fxy
#12 ·
2025年09月17日
我部门不以 bug 数作为衡量指标，只看工作效率和遗漏 bug 数。
涨死我了
#13 ·
2025年09月17日
一个季度就提了三个，被领导说了一顿
我吃香菜了
#14 ·
2025年09月17日
已最终生产质量，和提交 bug 质量为依据，这应该是测试开发一体去看待。就像有些测试 c1 他只测业务，很少关注技术实现，性能，安全等内容。如果出个事故就会出现高风险事故。c2 测试他的测试内容和用例设计都会考虑到性能和技术实现的优缺点能够提供更大范围的优化建议。你自己就知道哪个是好的，有效的，收敛的。所以单纯看数量没啥意义。
Bingoo
#15 ·
2025年09月17日
管它多少不过，线上不出问题才是最终结果
jokerbay
#16 ·
2025年09月17日
有病吧，已 bug 数量作为产出？
buggg
#11 ·
2025年09月17日
这起码是 10 多年前的测试工程师衡量标准吧，什么 bug 数、用例设计数、用例执行数
水mioo
#18 ·
2025年09月17日
曾经一个版本有 300 多个 bug，原因就是开发质量不行，改 bug 能力也不行，改一个出五个那种。
重来看雨
#19 ·
2025年09月17日
如何要考核，线上 bug 率就很好。
oyoyo
#20 ·
2025年09月18日
1 个赞
没法恒定这个量 每个人测的模块和对应的开发水平、业务逻辑都不一样 如果非要拿你为什么提的比别人少 而不看最终产出结果 那就是闲的了（讲话了，规定时间内，活儿干好了没出毛病就行）
AMEAME
#21 ·
2025年09月22日
一个月只能提 10 多个
BXBG
#22 ·
2025年09月22日
对
水mioo
回复
我试过一个版本开发质量太差；我和另外一个测试把这个项目版本的开发组长给堵了，让他回来给自己的组员改 bug
小叮当
#23 ·
2025年09月22日
Author
对
恒温
回复
身处在这种环境应该怎么办，看他们连 ui 颜色和文案都在提，难倒打不过就加入么 ，我的 bug 数连他们一半都不到，经理看我产出那么少直接 diss，试着解释了一下，感觉她理解成我在让他们 “少提 bug”
小黑子-IKUN
#24 ·
2025年09月22日
对
小叮当
回复
可以加入，ui 颜色和文案这的的确确是 bug，只不过要标记成等级相对比较低的 bug
吐蕃国师
#25 ·
2025年09月26日
笑死，按 bug 数量考核，那我最好公司招的开发越烂越好，产品越做越烂
鑫
#26 ·
2025年09月29日
不是贬义，但是有时候，bug 的质比量更重要。其次，保证的是上线后的功能，用户反馈的线上 bug 少，那就是很好的测试了。
小叮当
关闭了讨论
10月10日 09:03