首先，肯定是非常影响心情 。
这种版本，BUG随便一提，就是几十个（甚至上百个）。纯粹是浪费时间 。 这种时候，不太建议疯狂提BUG 。
一些可行性做法：
1. 先测主流程，及明显的BUG，然后让开发修复后，再测第二轮 。
2.直接冒烟测试不通过，版本打回，拒绝测试，等待新版本提测后，再介入测试 。
3.可以更向前推进一步：向项目经理，或者Leader反馈，这个版本提测质量非常烂，明显开发没有做自测，得好好批评一顿 。
4.当然，如果质量部门，没有准入标准，此时，应该思考，该建立准入标准了，什么样的版本，才合格，才能提测 。
补充观点：
1. BUG提的多，并不能代表你的能力，多数是提测版本质量太烂 。 2.如果想体现自己的能力：线上无漏测，才是能力的体现 。
3.之前还收到一些测试从业者反馈，他们团队，考核用例的数量。这种其实，很难操作，用例写的多又咋样？一个Bug都发现不了，一顿逻辑遗漏，也许只是一些非核心的业务，重复写用例而已 。
最后，
很多同学反馈，工作非常忙碌，从早9点，加班到晚12点，功能都测不完，也没时间学习，没有重复业务测试，而且Bug越测越多 。
其实啊，还是自己不会合理利用碎片化时间，没有思考如何提高自己的工作效率，怎样把重复的事，标准化、脚本化 。
End，
有啥补充，或者此文，引发了你的某些思考。
直接底部留言交流，互相学习 。
IDO老徐 2019/06/24
原创文章，禁止任何形式的COPY转载 。转发到朋友圈 & 群，非常欢迎 。
