线上 bug 本来就是线下 bug 成正比啊，一个 2 周的迭代线下 bug 就几百，你能指望全部发现完。你确定发布的时候缺陷呈收敛态势了？
这种情况就是要去控制提测质量，提测质量控制不好，你再要求测试也没用

有时候明明知道问题在哪，但是就是左右不了

这种公司感觉没必要待了，这情况感觉整体都出了问题

没事，开发都不怕，你怕个锤子，混就完事

过多 为啥要上线？

当 bug 过多，就不仅仅是测试的问题了

这种提测后的测试工作就是屎上雕花，发现的 bug 一般大多是零零碎碎的功能，而且捡了芝麻丢了西瓜，互相折磨。
这么多 bug 需要的是从需求立项，需求评审，任务拆解，技术评审，用例评审全方位的精细化，合理化。
测试本来就是话语权比较小的岗位，这种情况就只能在测试阶段多提 bug，线上出问题扯 bug 泄漏率什么的，核心论点就是测试已经很努力了，但是提测质量实在是不行。
妄图破局除非是一个比研发 leader 更懂项目，有人事任免决定的人来做，否则大部分还是流于 PPT，一顿折腾该啥还是啥。

这种情况下，测试已经没什么好的破局之道了，一定是整个研发过程出了问题。需要对这些 BUG 做个分类，按不同的维度统计出对应数据，然后重新审视整个研发环节：

1. 需求是足够清晰，数量是否过多？
2. 研发的产能是否过于超负荷？还是人员配置有问题，能力有问题？
3. 测试左移是否实施到位，比如尽早提供冒烟测试用例，研发是否执行到位；
4. 过程中是否存在许多无关的干扰项？比如环境问题，上下游依赖问题，数据问题等等；

至于线上 BUG，风险评估好，做好监控，控制好风暴半径，也问题不大（按这研发质量，估计也做不好）

• 很明显，这是牺牲质量换速度，问一下你们 PM、总监甚至 CTO，如果是为了生存而不得不这么做，那你就别想着破局了，尽好本分把测试做好点，质量的坑，如果活下来了，以后会有时间让你们去填的，活不下来也就不需要操心质量问题了
• 如果大佬没说这是节奏是来自市场或者投资人的压力，那就是你们需求排期问题严重，开发严重高估自己的迭代吞吐率了，可以把 PM 拉过来，拿数据给他看，告诉他挖了坑以后终归是要填的，他不听你就找大佬投诉……然后，保不齐你就变成了 PM……成为下一个被投诉的

做好复盘吧，要么是测试策略有问题，要么就是测试人不行

项目很大吗？开发和测试人员有多少？开发有自测吗？有自测的话还是这么多问题需要好好复盘一下原因是因为什么？问题是比较容易就发现的吗？还是隐藏比较深

是什么样的需求，可以产出 300 个 bug，这不应该从需求大小层面下刀吗

做好测试左移
提测前需求评审、UX 评审、技术评审、测试用例评审都认真评了么？ 没提前发现问题？
要求开发做基础的自测，比如提测前要通过冒烟测试，不通过直接打回。
自动化、CICD 做了么？还是全靠手工？
测试用例完善么？线上问题还很多，这个能忍？
BUG 归下类，哪些是需求不明确导致的，哪些是纯代码的 BUG，假如是代码屎山堆不上去了就要重构，找到原因再想办法。
提测后进入测试环节发现的 BUG，都属于是自找活干，自己给自己擦屁股。

一句话就是：想办法用最短的时间、最少的成本发现问题，最少的代价解决问题。

开发和测试，都有问题吧，如果问题这么多，为什么还能上线哦？

灵魂拷问来了：线上的 bug，是因为漏测，还是因为改了其他 bug，产生新的 bug？

bug 改的完吗；是否符合上线标准；迭代内的需求个数，开发测试排期是否合理；测试是否到位；反正整个流程都拉出来看看

每天都快 30 了，改 bug 都改不完吧

你们测试关心开发细节干啥，跟你们说又听不懂

我本地没问题

没那么快发放吧，不是应该次月才发吗

N+3 很良心了

N+3 很良心了

怎么找回 testerhome 密码

这个都很简单，你随便看看就好，我都看过了

不是我的问题，别找我

n+3 赔偿，虽然不是最好的待遇，但是也勉强还算良心了，总比 N+1 最低法律规定好得多，公司不搞芯片，员工也没办法选择。