当接到一个「质量非常烂、UI效果非常LOW」的提测版本时

首先，肯定是非常影响心情 。

这种版本，BUG随便一提，就是几十个（甚至上百个）。纯粹是浪费时间 。 这种时候，不太建议疯狂提BUG 。

一些可行性做法：

1. 先测主流程，及明显的BUG，然后让开发修复后，再测第二轮 。

2.直接冒烟测试不通过，版本打回，拒绝测试，等待新版本提测后，再介入测试 。

3.可以更向前推进一步：向项目经理，或者Leader反馈，这个版本提测质量非常烂，明显开发没有做自测，得好好批评一顿 。

4.当然，如果质量部门，没有准入标准，此时，应该思考，该建立准入标准了，什么样的版本，才合格，才能提测 。

补充观点：

1. BUG提的多，并不能代表你的能力，多数是提测版本质量太烂 。 2.如果想体现自己的能力：线上无漏测，才是能力的体现 。

3.之前还收到一些测试从业者反馈，他们团队，考核用例的数量。这种其实，很难操作，用例写的多又咋样？一个Bug都发现不了，一顿逻辑遗漏，也许只是一些非核心的业务，重复写用例而已 。

最后，

很多同学反馈，工作非常忙碌，从早9点，加班到晚12点，功能都测不完，也没时间学习，没有重复业务测试，而且Bug越测越多 。

其实啊，还是自己不会合理利用碎片化时间，没有思考如何提高自己的工作效率，怎样把重复的事，标准化、脚本化 。

End，

有啥补充，或者此文，引发了你的某些思考。

直接底部留言交流，互相学习 。

IDO老徐 2019/06/24

原创文章，禁止任何形式的COPY转载 。转发到朋友圈 & 群，非常欢迎 。

往期文章推荐：

职业选择 之 外包（利 & 弊）

找了三个月，没找到工作 。

行业内，有个测试方法叫「错误推测法」

“测试时间估算”的现状 及 4点建议

关于测试用例的所有问题 。