概述
做过开发的，肯定会遇到下面的场景：
开发人员提测某个功能后，被测试人员打回了，原因是，功能主流程没过。
这属于冒烟没过的情况，为了不影响测试进度，开发在提测前，自己要做一下功能冒烟。
冒烟用例的执行
测试人员可以提供覆盖主流程的冒烟用例，供开发人员执行，如果开发没执行完，测试人员是有理由不进入功能测试流程的。因为一旦进入测试流程，又发现主流程不通，各种bug的，会极大的影响测试效率，进而影响功能的准时上线。
开发冒烟可以看成是一个技术活动，且涉及到多个端，因此是需要组织起来的，一堆人一起配合，最好指定一个冒烟负责人，去推进整个冒烟过程，从而提高冒烟效率和质量。
如果你所在的技术团队，人员的自驱性和专业程度还不够，就更加需要一个负责人去跟进冒烟进度了，不然都是自扫门前雪，都只是考虑点的问题，而没人去考虑线的问题。
千万要狠抓开发冒烟，重视这个关键节点，这样才能保证后续测试流程的顺畅性，也就为项目准时上线打了个好的基础。像之前在大厂的时候，冒烟没过，是要通报批评的，多次没过，测试人员直接上报到开发总监那里，明确表示：
不测试该功能了，主流程都没通，测试和上线风险都极大。
这样的话，整个研发团队都无法交代了。
端到端的冒烟
冒烟一定是端到端的，且冒烟通过的功能，从研发侧的角度看，就是可以上线的了。要有这样的意识，且单个端做到完美也是没鬼用的，一端到端联调，就可能会有问题。
如果在冒烟的过程中，出现了严重的阻塞性问题，一定要及时上报，且留好相关人士。及时的调用和协调相关资源，提前解决问题。
如果功能模块需要依赖第三方公司的接口，则切记，这个是不可控因素，一定要提前跟对方协调商量好，约定好联调时间，且时时询问对方进度，把可能的风险先暴露出来。
如果项目是比较大的，冒烟负责人一定要梳理出，哪些模块先冒烟，哪些可以晚些冒烟，让各个组中参与冒烟的人，目标明确。再强调一遍，这个很重要。
必要时候狠一点
有时候会出现一些倒排期项目，给到的开发时间短，留给开发的冒烟时间会很短，这个时候，一定有整体思维的思考模式，进行必要的加班，促进冒烟活动能完成，不然就会进入病态的恶性循环。
随意提测，测试打回，继续提测，又打回。
这样效率会非常低，宁愿加班，把冒烟活动做好，保证后续流程的顺畅性。执行的过程中会出现矛盾或者得罪人，这个时候，要沟通好，把目标说清楚，以求大家理解一致，往同一个目标努力。如果实在推动不了，一定要把问题上升。
时刻关注测试人员执行冒烟的进度
当开发辛辛苦苦执行完冒烟用例后，就可以提测了。测试人员会开始介入，这个时候，要时刻关注测试人员上报的问题，及时解决。毕竟测试人员也希望冒烟顺利一些，中间万一有主流程case没有通过，只要处理及时，测试人员也不会直接打回的。
小结
冒烟负责人其实是个苦差事，得到处跑，在各个研发团队中游走，而且还得帮忙出主意，解决遇到的问题，你光在那push进度，很容易被排斥的。因此我是比较建议让有经验技术好的人，来做冒烟负责人的。
