1.什么是冒烟？
冒烟测试,严格来说就是一个基本功能点的验证测试，版本测试必须要有这样一个过程，其中可提高自身的质量意识，从而可以更有效的提高产品的质量，和版本发布速度。简单的说，就是先保证系统能跑的起来，不至于让测试工作做到一半突然出现错误导致业务中断。
2.测试准入条件
冒烟测试必须在每次提交新的测试版本前执行，且执行规范需根据需求设计文档来要求，工程师在每次发布新版本前，严格执行冒烟测试点，也就是基本功能点，避免后期版本发布时出现功能遗漏，或者功能实现有缺陷等等问题。
3.针对执行人的考虑
冒烟测试的执行到底谁来做，其实这也是经常会出现的矛盾，开发人员不愿意做测试是事实，但是提高产品的质量最后还是由开发人员自己来完成的。
其实严格来说，测试人员肯定也是要做冒烟测试的，因为这是测试流程中的首要阶段，也是必要条件之一，但是测试人员执行冒烟测试不通过，就说明版本不具备测试条件，重新发回给开发人员。与此往复必然会耽误大家的时间。
所以开发人员也应该参与到冒烟测试的流程中。只有开发在提版本之前做一个版本自身体检，才能让这个版本健康的发布出去，这样才能更有效的提高大家的工作效率。
4.执行流程：
a.测试人员按照当前迭代内容设定冒烟测试范围，并交由产品审核；
b.产品审核通过后，由测试人员在项目提测前一天交由开发人员；
c.开发人员在提测前执行对应的冒烟测试用例，通过后发布开发结束通报；
d.开发人员，需要在通报中具体说明自测结果；(如实填写)
e.测试人员针对冒烟用例进行复测，通过后进入正式测试阶段，不通过返回给开发人员；
f.测试完成，测试人员发送迭代通告，说明测试结果与开发自测成功率。
5.关于冒烟用例未通过是否应该测试的考虑
基本上测试人员是属于各个子项目的专属配置。假设冒烟测试不通过测试人员直接拒绝测试，很可能会影响项目上线的进度。不利于团队发展。总的来说吧，我觉得关于质量的把控还是应该大家一起参与的，对于质量意识我觉得并不仅仅是意识。有对应的标准规范，对应的控制节点，才能更好的定位问题发现问题并解决问题。
这并不仅仅是测试部门的事情，所以对于一些流通性比较强的规范，还是应该去付诸行动，因为在没有公认的规范前提下，所有的工作准备都会大打折扣，进而也不利于个人与团队的发展。
当然我想说，当前的项目分配，在时间允许的情况下提测质量不达标的测试任务也会进入测试阶段，但是这并不是长久之计。长此以往也会出现一些问题。所以还需要大家都能理解并认同。另外提测后开发自测结果反馈也会在测试结束的报告中进行体现。
6.跟现在开发流程是否冲突
基本上功能提测后开发人员都会进行自测，只是自测的点和自测的质量，没有具体说明，其实我主要的想法是把开发自测这块儿，单独拿出来放到流程中，我们测试人员提供冒烟用例。自测结果数据化，希望通过数据的统计可以发现并解决一些问题。具体跟现在的流程冲突不大。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
