【原创】如何通过冒烟测试前置来把控提测质量？

一

你是否碰到过开发提测速度很快，导致项目排队，结果介入测试时，第一条用例都跑不通的情况？

你是否碰到过因为开发提测质量差，导致反复修改，反复提测，反复重复验证的情况？

你是否碰到过因为开发提测质量差，导致一个修改影响了一大票老功能，从而让项目质量岌岌可危的情况？

你是否碰到过因为开发提测质量差，导致项目后期通过压缩测试时间来保证项目进度的情况？

你是否碰到过开发拍胸脯承诺这次肯定没问题，结果测试数据稍一变通就跑不通过的情况？

不管你有没有碰到过，我反正是全都碰到过。

有人说，这开发太水了，咋不自测呢？

有些确实是没有自测导致的，但是有一些开发确实自测了，但是自测的结果是没问题的。

一方面开发自测时都是针对自己修改的内容进行自测，这种情况往往发现不了啥问题，毕竟自己对自己的代码太熟悉了。

另一方面开发自测时，大部分都是通过调试来看效果，并不是真正的用户环境，甚至连测试环境都算不上，那么这种自测的效果就很差。

那有没有什么好的解决办法呢？有。

二

下面提供几个操作建议供参考：

1.提供给开发人员自测需要的环境

比如我们是 Windows 客户端的软件，经常需要覆盖不同的 Windows 系统版本，很多开发都没有很全的系统版本的环境，所以提测的时候只会在一个他自己常用的环境进行自测。

有时候出现问题，他们的借口也可以是自己没有现成的环境，搭建环境需要时间太多等等，那好吧，我们给提供需要的各种拿来即用的环境就好了