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

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

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

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

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

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

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

如果项目规模非常大，相关较大的子项目都有几十个，涉及到开发人员几百上千，线上非核心业务 BUG 几十，还算可以接受吧
但是如果项目规模一般，比如就十来个开发，核心业务相关 BUG 几十个，那这项目估计是自身自灭的项目，趁早跑路。。。

应对的话

1. 先看资源配置是否合理，10 个经验开发的活要求让 1 个初学者干了，这没得玩
2. 进度是否合理。。。两周一个迭代是不是要做两三个月做的。。。
3. 如果以上都满足，那就看整个研发流程是不是有问题，每个环节挨个梳理一下，针对性解决

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

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

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

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

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

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

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

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

过多 为啥要上线？

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

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

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

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

同意

bug 这么多 还上线阿