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

一

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

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

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

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

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

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

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

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

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

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

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

二

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

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

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

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

其实和几个开发的沟通发现，他们还是挺高兴有这些环境的，所以可能真不是人家不想自测。

那既然可以两全其美，何乐而不为呢。

2.提供开发人员自测的测试用例

我们在收到开发的提测通知后，经常的对话就是「自测没？」，「这次真的自测了。」，结果一冒烟，依然有问题，开发带着震惊的表情过来一看，不好意思，这个场景我们考虑到，但是我确实自测了呀，你看测试数据换成这样肯定没问题。

是滴，不是没有自测的错