冒烟测试的概念在整个测试组其实已经使用很久，在 FT 化之后，冒烟测试下发到各个 FT 里面进行把控，一直是一个不温不火的状态。
在版本节奏越来越快的背景下，如果还是正常的提测 + 测试 + 回归的节奏，基本很难做到版本的快速发布和多版本并行的测试。
于是我们想到了 “冒烟测试”，如何利用它减少测试的压力还可以提高测试质量。
有一天我说了：“这个版本冒烟提 bug 超过 10 次的童鞋，我请吃饭”， 冲着这顿饭，然后大家就进入了奋命提 bug 的高潮阶段，拉开了我们 FT 冒烟奋战史的帷幕。
说明：目前腾讯手机管家是采用FT模式进行研发，FT就是feature team ,将负责相同模块的各个角色组成一个小组,包括开发、产品、测试、运营、设计等
每天都可以看到一群开发，运营、产品和设计 “变身” 为测试人员，在南通 10 楼的茶水间拿着手机，时不时露出满意的笑容， 在电脑上啪啪啪敲起，又录入了一个 bug。
经常有人大喊：“哇，我又发现一个 crash， 是 A 开发的耶”
然后 A 开发就赶紧： “来，手机拿来，我收集 crash 日志”,然后拿着手机冲到了自己的电脑前…….
还没等我们冒完烟， 他就神色愉悦的跑回来说：“解决了， 是因为 #$%&&”,众人投来了崇拜的眼光，内心暗暗想，我要再发现一个 crash 才好…….*
开发 A 突然说：“咦 ，我的手机这里错位了， 字体也溢出啦”
测试 B 突然说：“咦， 我的手机这个插件打不开耶”
产品 C 一脸茫然的说：“为啥我的都正常呢……”
冒烟组织人：“ 赶紧录进去提 bug，这个是机型适配问题呀！！” 这个时候土豪产品 C 从口袋里掏出了 N 台机器， 来，那这几台机器也都来适配看看结果…….
经历了半小时的 “厮杀” 后，台球桌上笔记本里面已经满满记录了一大页，测试人员随手在电脑上点了一个 “导入”， 各个开发的就收到了一堆待处理的 bug 通知
开发 A 心里暗爽：“刚好在写这块逻辑， 顺手就可以解掉 bug 的啦，小 case， 再也不用担心写完代码想去浪的时候，测试才给我提了个 bug,嘻嘻”
开发 B 小惊喜：“刚才偷偷的发现了自己的几个 bug 耶，趁大家还没发现赶紧灭了它”
测试 C 心里暗爽：“还没开始提测，开发就都把 bug 改了，再也不用担心开发又漏写需求啦”
这时，开发 D 大喊：“好多 bug,好多 bug，然后埋头苦干清 bug”,众人投去了同情的眼光，说：“加油清 bug！”
测试和产品已经愉悦的去吃饭啦， 留下开发在埋头苦干！
吃饱喝足回来，当产品童鞋看着开发还在埋头苦干，忍不住幸灾乐祸了一番，开发抬头看了他一眼，悠悠的说：“bug 都转给你了”
“纳尼。。。”，产品赶紧冲到自己的电脑前,打开 “我负责的未完成的 bug”:10 条．。。。。。。
全部都是体验类问题需要产品跟进，哈哈哈，再也不用担心提测后产品再来修体验问题啦 !
心酸 1：打包
来，今天我们开始冒烟吧，帮打个冒烟包吧
开发 A:” 好，现在打”
然后过了 15min，“打好了么”
“平台有问题耶， 打不出来了”
然后过了 15min, “打好了么”
“刚才 xx 提交代码了，我重新打个”
。。。。。。。
然后夜色降临，我们默默的去了饭堂
心酸 2：一定是我不够吸引
冒烟组织人：“来，大家装包开始冒烟”
开发 A:” 好，等我解完这个 bug"
测试 B:” 好，当我测试完这个路径”
产品 C:” 好，你帮我装个包可以么？ 嘻嘻”
然后过了 10min, 大家还是雷动不打的坐在座位上。。。。。。。。
心酸 3：自己给自己挖的坑，哭着也要填完
1) 心酸录 bug: 最开始的冒烟我们是拿着一张 A4 纸录 bug ,一个回合下来，20 多条 bug，测试同学吃完饭就苦逼的拿着电脑啪啪啪地录 bug，我们真的不是一个文员。
2) 心酸回归 bug: 每天自己测试提了几十条 bug，然后冒烟 bug 还有几十条要测试同学回归， 然后就没有然后了~~~~
破解法 1： 每个版本指定一名开发打包，在冒烟开始半小时前就开始进入打包流程
破解法 2：每个版本轮流换人组织冒烟，打包的人也是轮流的， 大家就会互相体谅不同角色的难处
破解法 3： 使用模板在电脑上录 bug，一键导入 tapd, 并且谁提的 bug 谁负责回归
然后测试同学就爽歪歪了！
经过了 N 多个版本的奋斗后， 现在的冒烟过程已经是一个非常愉悦有效的过程， 当中有很多的冒烟心得和 tips， 会在下面一一列出。
a) 体验问题：版本 dogfood 和 showcase 时间太晚，冒烟可以早期暴露大量体验类问题
b) 机型问题 : 冒烟参与的人多，可以快速覆盖更多的机型和 android 版本
c) 问题暴露： 在还未正式提测前就开始冒烟，可以快速暴露问题和解决
d) 人多力量大： 各个角色一同参与冒烟，可以从不同的维度发现问题，经常都能给出一些很有效的优化建议
冒烟就跟精准测试一样，无法解决所有问题，也存在一些不可避免的缺点，例如：提 bug 的有效性，重复 bug 录入，开发解决大量 bug 带来的耗时等。
我们 FT 的冒烟之路一开始也遇到了同样的问题，但是经过多个版本的磨合，FT 内都是比较认同冒烟测试带来的效果，整体效果利大于弊的，积极性也越来越高，偶尔想让大家休息一天， 开发甚至会主动提出要冒烟测试。
下面贴下我们 FT 在手管 6.2 版本的一些冒烟数据和改进过程，大家可以参考下：
1、BUG 有效性：
有效性： 64% 命中率
建议： 宁可错过，不可放过
2、重复 BUG：
说明： 下图是被拒绝的冒烟 bug 的分布，重复的 bug 占比比较高
参考： 越多人提的 bug，越重要？在思考 bug 有效性的时候，重复 bug 可以作为一个参考，越多人提的 bug 是否需要更加关注。
3、冒烟 BUG 分布
影响因素：
1. 功能改动
2. 冒烟指导力度（大家可以依据自己的重点功能加强对应的冒烟路径指导力度）
4、我们的优化之路
在 FT 的实践过程中，各个角色提出自己的意见，对冒烟测试的组织优化起到了关键性的作用。
测试准备：
设备： 一台录入 bug 的笔记本（附件有 bug 录入模板）
冒烟时间： 每天下午 5:30 到 6:00，规定半小时以内
开发童鞋：
1. 轮流： 每个版本指定一名开发童鞋
2. 打包： 5:30 之前打好冒烟的包，发到冒烟的 RTX 群让大家安装
3.收集： 收集当天的冒烟路径（由各个功能的开发和测试提供）
4. 拉人： 5:30 准时拉人去冒烟
5. 推荐： 跟大家推荐今天重点体验的功能和路径（一般对应的开发会主动引导）
测试童鞋：
1. 问题收集 : 负责收集各个同学提供的 bug，并使用模板批量导入到 tapd（必须当天导入）
2. 问题回归：每天会打印需要回归的 bug，在冒烟的时候让对应的同学回归
3. bug 优先级控制： 根据提的冒烟 bug，可以协助开发标明优先级或者类型
4. Bug 回归推动： 需要关注 bug 的解决情况，在需要的时候推动 bug 的解决和回归
5. 推荐： 测试也需要引导测试的路径，可以从测试的一些角度提出
产品童鞋：
如何录入问题
1、标题格式说明：【版本 + 模块名 + 冒烟测试】【BUG/体验】xxxx--提 bug 人
2、录入 TAPD:(录入模板参考附件， 录入方式见下
今天我当家：开发轮流负责, 提高主动性和加强对测试的理解
今日事，今日毕：当天录入 bug, 快速录入让开发快速解决
一秒转产品：体验类的问题快速转产品处理，产品再消化为产品问题，确定是否进行需求变更
- 宁可错过，不可放过：无论问题大小，是体验类还是 bug 类， 都让大家进行录入
快速回归 bug： 快速回归不遗留，遗留打屁股
追求大而全：收集下大家的机型和 android 版本，可以适当的补充遗漏的机型和 android 版本手机
吃货诱惑：FT 内可以偶尔准备一些小零食，在冒烟的时候提供，让日复一日的冒烟有一些小惊喜
用事实证明自己：氧气冒烟的成果非常可观，为 FT 的质量保证也提供了一个有效且方便的方法，得到了大家认可，大家才会主动持续的参与进来
在版本快速迭代的节奏下，冒烟测试作为常规测试的一个有效补充之外，也为其他角色了解测试搭建了一个很好的桥梁，这个过程需要各个角色一同参与和优化，才能达到比较好的实践效果。
本章完~
