本文章转载于搜狗测试
不知道大家在日常工作中，有没有遇到以下情形：
情景1：“新版本提测了，测试拿过版本就开始进行测试，测试半天后，突然发现：某个功能实现逻辑与需求不符，开发需要重新修改，已测试的功能白测了~~”
情景2：“新版本提测后，执行半天用例后，发现部分功能不可用，后面的用例直接阻塞了~~”
遇到以上情况，即影响测试进度，又影响测试心情，怎么办？今天小编就给大家介绍一下“冒烟测试”（或叫“预测试”）
冒烟测试的目的：
确认提测模块的基本功能、实现逻辑符合需求，可以进行后续的正式测试工作，将正式测试未知的风险降至最低，防止bug阻塞导致测试进度阻塞
冒烟测试时机：
1. 新增功能提测时
2. Bug修改或需求变更对原有功能模块逻辑修改范围较大
冒烟测试时间安排：
由各模块负责人安排具体的预测试时间。参考规则：
1. 冒烟测试的时间可根据模块的复杂程度来定，复杂度越高的模块，预测试的时间可以安排的长些
2. 冒烟测试时间一般不超过该模块一轮测试时间的10%
冒烟测试标准：
有以下1条执行结果，预测试不通过
1. 提测模块中，不可测试的功能点占总功能点的40%以上
2. 崩溃或bug导致70%以上的功能无法测试（即有70%的测试用例阻塞测试。另：若阻塞部分有独立模块，与其他模块无影响时，该模块可以测试）。
3. 崩溃频繁导致无法进行测试。
4. 半个小时随机测试，发现bug数量超过20个
5. 兼容机型、浏览器等有一半以上不可用，需要与开发负责人确认修改范围是否与兼容有关，再评估是否可测试
6. 个别bug影响60%以上的功能逻辑
冒烟测试结果模板：
邮件主题：【xx版本-冒烟测试结果】——xx模块验证通过/验证不通过
邮件发送：发给开发；抄送给产品、开发经理、测试项目负责人
模板字段说明：
预测试验证次数：验证该模块预测试的次数
模块名称：测试验证的功能模块
提交bug个数：填写该模块一共提交了几个bug
阻塞Bug或严重bug说明：bug相关说明
模块状态说明：
分别说明当前模块可测试内容、不可测试内容、未提测内容，内容填写样式如上表；如果全部可测试，直接填写全部可测试；如果部分可测试，需要填写测试时间
测试负责人和开发负责人：对应相关人员
预计测试时间 ：说明预计开始测试时间点
项目进度影响：填写对当前项目进度的影响；如果无，则填写“无”
