一

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

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

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

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

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

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

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

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

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

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

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

二

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

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

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

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

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

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

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

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

是滴，不是没有自测的错，只是测试的内容和我们预期的不一样，也就是每个人对「自测」的理解不一样，那我们明确下自测的详细要求就好了呗。

目前我们组几个同学的方法就是直接丢给开发冒烟测试的用例，必须把这些用例跑通过了才能提测。

开发其实也挺乐意这样做的，毕竟目标明确，还能避免反复低质量提测，何乐而不为呢。

3.提供提测时的前置自动化校验

上面说的两种方法都是人工干预，既然是人工干预，就会涉及到人的不可控性，为了避免人的因素造成的问题，我们又在提测系统中增加了一些必要检查点的自动化检测逻辑。

比如文件签名属性的检查，一方面这是对所有文件的通用检查要求，另一方面检查的规范要求的十分明确，那么这种就特别适合做成自动化实现，如果检查有问题，直接阻止提测，减少交互造成的时间浪费。

这地方提醒下，所有的阻止项一定要给明确的说明，避免开发不知道什么原因被阻止，也不知道怎么修改，那就尴尬了。

4.提供冒烟测试的自动化用例

在一些自动化落实程度比较高的项目中，如果已经有主要用例完成了自动化用例覆盖，完全可以把自动化执行接入到提测流程中，提测前必须过自动化用例检查。

这样一方面可以节省开发准备环境的时间，另一方面开发对用例的关注程度也可以减弱了，所有的结果和问题都可以在自动化用例实现上进行完善。

三

其实对于一些要求开发进行充分单元测试的项目，上面这些担心都不是必要的，因为我们提供的解决方法都包含到单元测试的要求里面了。

但是基于国内的现状，能完整开展单元测试的项目并不多，那么质量保证的任务就全部落到测试人员的身上了。

有同学可能对上面的方式有一些疑问，比如测试是不是做的太多了，提测质量的要求本来就是需要开发做到的，现在他们做不到，却还让测试帮忙额外做这么多事情，太没有道理了。

其实之前我也是这么想的，后来发现测试工程师的主要工作职责其实就是质量保证，那么所有和质量保证相关的事情，测试都可以去推进，这也是很多公司衍生出 SQA 的原因。

那如果从质量保证的角度想想，是不是上面做的这些事情就很有必要了，只是把一些测试人员需要做的事情前置了，但是带来的好处却是比投入要大的多，毕竟谁都知道早期发现问题的修改成本要比后期发现再修改的成本低的多。

以上，关于冒烟测试你有什么看法和想法，欢迎给我留言讨论。