bug 数量考察测试同学，会导致行为变形的。你可以把一个缺陷拆成 n 个 bug 来报。

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

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

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

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

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