做软件测试工作半年多了，由于工作的公司是一家小型的IT企业，故而对于岗位的职责没有做太清晰的划分，也就导致我对于冒烟测试的重要性有了较为深刻的感受，所以想在这里记录下来以供参考，也算是给想入门这行的新人一点帮助。
首先说说冒烟测试。冒烟测试起源于硬件测试，这个“冒烟”其实就是指硬件是否能够正常工作。比如说一根烟囱，将黑烟导出屋外其实就是他的主要工作，他的内部结构、外部结构都是为了这个主要工作来设计的，当它的主要功能存在问题，那么无论它内部结构多么精细，外部设计多么美观，都是毫无意义的，冒烟测试其实就是验证这根烟囱是否能够导出黑烟。从硬件延伸到我们的软件系统中，其实是一个道理，例如一个登录页，那么登录功能就是它的主要工作，我们只要验证到他确实能够使用账号密码登录到系统中，它就是能“冒烟”的，而对于他的字段规范要求、输入框等我们可以放到后面的详细测试中。这就是“冒烟测试”。
再说说冒烟测试的时机。我认为冒烟测试的时机有三个。一是在有新功能点提测前；二是当有BUG回归时；三是当需求变更导致功能点逻辑变动较大时。这三个时机都有一个共同点，就是在我们详细测试功能之前。我的经历告诉我，冒烟测试的存在与冒烟测试的时机是非常重要的，我曾经测试一个项目时，在开发提测后我以为他们已经进行过冒烟测试，于是就临急临忙的去做测试，从登录页开始，一点一点的严格细致地跟着测试用例慢慢走，用了两个小时测试到某个重要功能时才发现，这个功能存在重大的BUG，甚至于已经影响了整个系统的运行，主要流程根本无法跑通，我只能将其打回给开发让他修改完后再提测，那么我这两个小时就是在浪费时间，也相当于拖延了项目的进度。其实我们完全可以用测试一轮的5%-10%的时间进行冒烟测试来避免这种情况，例如整个系统我们测试一轮需要一天的时间，那么我们可以用半个小时到一个小时的时间来进行一轮冒烟测试，确定的主要流程没问题后再详细测试，如果发现有问题，就可以马上打回给开发让其修复后再提测。回到冒烟测试的三个时机，第一个很好理解，第二，第三个可能会有人不理解为什么这种情况需要冒烟测试，其实原因很简单：在测试人员发现BUG并反馈给开发人员后，开发人员及时修复，再次更新系统代码，这个时候，冒烟测试的重点就要放在更新的这一部分，需要验证该部分内容是否能够融入整个系统之中，不对系统的其他业务造成影响（需求变更时同理）。
还有一点就是冒烟测试的执行者。冒烟测试究竟要谁来做？这一点在网上有两种看法，有人认为应该测试来干，这本就是测试的工作。另一批人则认为应该开发来干（当然大公司貌似有专业的冒烟测试人员，如果你们公司是这样，这一段请跳过）。正如我上一段所说的经历中，造成那个错误的原因，除了我的错误外，还有就是因为我们公司对于岗位的职责没有做太清晰的划分，我以为开发会做，开发以为我会做。对于上述两种观点，试想一下两种流程：开发提测给测试后，测试进行冒烟测试发现流程不通，打回给开发修改；开发在联调完毕后马上进行冒烟测试，发现流程不通，马上进行修改。这两种流程哪一种更快？很明显是后者。另外我在工作过程中发现，部分开发对于他们开发的项目一点都不了解，他们只会根据原型来设计代码，这就导致了如果原型里的说明不够详细，或是存在歧义，他们就会做出奇奇怪怪的功能来。正确的开展冒烟测试有益于执行人对于系统认知的加深，做出更符合需求的产品。其实开发人员不愿意做测试是事实，但是提高产品的质量最后还是由开发人员自己来完成，这一点测试人员也无能为力；而严格来说，测试人员肯定是要做冒烟测试的，因为这是测试流程中的首要阶段，也是必要条件，测试人员执行冒烟测试不通过，就说明版本不具备测试条件，重新发回给开发人员，但是如果每次都出现这种问题，因为冒烟测试不通过而打回原形必然会耽误大家的时间，而为了节省这个时间，提高版本发布的效率，那就需要开发人员自己做冒烟测试，但是如果每次冒烟都需要开发来执行的话，又会影响开发的代码效率，有点得不偿失。综上所述，我认为冒烟测试应该分情况来决定执行者，在冒烟测试的三个时机中，第一个时机应该由开发来执行；第二、第三个时机应该由测试来执行。
最后说说冒烟测试标准。冒烟测试在网上有许多的标准，但是我认为总的来说有这么几种情况：1.存在导致系统崩溃的严重BUG。2.频繁出现卡顿等异常情况，严重影响测试过程。3.主要流程无法跑通，阻塞了大部分测试用例的进行。出现这三种情况可以无脑打回不接受提测，其余的需要按实际情况与公司行情而视。
附上我自己写的冒烟测试报告模板。
