一周一个版本 200 个缺陷，你们的缺陷好多呀。。

200 个也太多了吧。。。

最主要的还是看 bug 的严重程度和触发条件。 如果容易触发，严重程度也很高。 这样的 bug 漏测一个都是不行的。 相反的如果 bug 的严重程度很低，例如就是个简单样式问题，而且触发条件极其苛刻。这样的 bug 来 10 几个 20 个都可以忍受

十分赞同。再多提一句，简单的 UI 样式问题，大部分都应该在提测前避免的，不应该在测试阶段出现。

我就是举个例子

每周发布，200 个不是很正常么。。。
尽力就好，没主流程异常就 OK 了。
监测异常，第一时间反馈就好。

是的。一周，半天讨论需求，3 天开发，1 天半功能测试 + 回归测试。这种前端做的很重的项目，就是很多 bug。。开发试过一天修复了 100 个 bug

看来大家都差不多啊。

一个版本 200 个 bug，这是开发自测试不充分呀。感觉你们测试是开发的保姆了。

哎，这你就不懂了吧，开发都 996 甚至更夸张开发了，哪来的自测时间。。。

也可以从流程上优化，开发自测 + 测试验证 + 产品 UAT+ 生产验证，大家一起参与，一起把好质量关。对于线上出现的漏侧场景，及时反思总结，看是没有分析到位还是执行层面没有把控好，如果是没分析到位，那就追加到测试用例，几个版本积累下来，肯定会越做越完善。然后将全量的测试用例抽取主流程，整理出发版验证 checklist，每次发版前按照 checklist 一条一条执行，坚持下去，相信质量会越来越好

容忍错误 毕竟工作中不断有坑要踩 但是低级错误扣分、重复错误再犯扣分、事故级别的错误扣分、严重投诉扣分。。。

我们公司专门分 QA 和 QC，QA 就是搞这个事情的，出了线上 bug，评估影响，定级……年底算账 一般都是开发和测试 55 开背锅，有时候还得搭上运维，产品

合理的惩罚制度当然很好。就怕严格这么执行之后，每个版本都有处罚，结果只会是士气越来越低。目前的改进措施，都是着重从总结，复盘，然后改进工作效率的为主。

如果每个版本都有我说的那些个问题，是不是该反思测试人员对工作没有用心或者自身水平有限呢。
我们刚开始推的前几个月确实有一些处罚，但随着时间推移，低级错误和重复错误的的确确是减少了
当然这种规则这也和结果导向的公司文化分不开。

有理。可以尝试

先看复现难度分析线上出现的概率，进而去分析影响范围、产生的经济和体验上的损失，然后析影响了多少日活等其他数据，然后来对这个漏测定性。
不太注重漏测了多少。

我们之前发布一个版本，出现 38 个产品崩溃问题，有一半都是偶现崩溃。你说这开发水平有多差，公司为了节省成本，找来的大部分开发都是培训机构出来的，简直了。我作为测试领头人，干完那个版本直接走人了。

我只想问你们几个前端