一、冒烟起源篇

冒烟测试的概念在整个测试组其实已经使用很久，在 FT 化之后，冒烟测试下发到各个 FT 里面进行把控，一直是一个不温不火的状态。

在版本节奏越来越快的背景下，如果还是正常的提测 + 测试 + 回归的节奏，基本很难做到版本的快速发布和多版本并行的测试。
     

于是我们想到了 “冒烟测试”，如何利用它减少测试的压力还可以提高测试质量。
   

有一天我说了：“这个版本冒烟提 bug 超过 10 次的童鞋，我请吃饭”， 冲着这顿饭，然后大家就进入了奋命提 bug 的高潮阶段，拉开了我们 FT 冒烟奋战史的帷幕。

说明：目前腾讯手机管家是采用FT模式进行研发，FT就是feature team ,将负责相同模块的各个角色组成一个小组,包括开发、产品、测试、运营、设计等

二、冒烟场景篇

1、不小心多了 23 个 “测试人员”

每天都可以看到一群开发，运营、产品和设计 “变身” 为测试人员，在南通 10 楼的茶水间拿着手机，时不时露出满意的笑容， 在电脑上啪啪啪敲起，又录入了一个 bug。

经常有人大喊：“哇，我又发现一个 crash， 是 A 开发的耶”

然后 A 开发就赶紧： “来，手机拿来，我收集 crash 日志”,然后拿着手机冲到了自己的电脑前…….

还没等我们冒完烟， 他就神色愉悦的跑回来说：“解决了， 是因为 #$%^{&&”,众人投来了崇拜的眼光，内心暗暗想，我要再发现一个 crash 才好…….*}

2、小型适配基地

开发 A 突然说：“咦 ，我的手机这里错位了， 字体也溢出啦”

测试 B 突然说：“咦， 我的手机这个插件打不开耶”

产品 C 一脸茫然的说：“为啥我的都正常呢……”

冒烟组织人：“ 赶紧录进去提 bug，这个是机型适配问题呀！！” 这个时候土豪产品 C 从口袋里掏出了 N 台机器， 来，那这几台机器也都来适配看看结果…….

3、还没开始提测，bug 就已经爆仓了

经历了半小时的 “厮杀” 后，台球桌上笔记本里面已经满满记录了一大页，测试人员随手在电脑上点了一个 “导入”， 各个开发的就收到了一堆待处理的 bug 通知

开发 A 心里暗爽：“刚好在写这块逻辑， 顺手就可以解掉 bug 的啦，小 case， 再也不用担心写完代码想去浪的时候，测试才给我提了个 bug,嘻嘻”

开发 B 小惊喜：“刚才偷偷的发现了自己的几个 bug 耶，趁大家还没发现赶紧灭了它”

测试 C 心里暗爽：“还没开始提测，开发就都把 bug 改了，再也不用担心开发又漏写需求啦”

这时，开发 D 大喊：“好多 bug,好多 bug，然后埋头苦干清 bug”,众人投去了同情的眼光，说：“加油清 bug！”

测试和产品已经愉悦的去吃饭啦， 留下开发在埋头苦干！

4、  人人都是产品经理

吃饱喝足回来，当产品童鞋看着开发还在埋头苦干，忍不住幸灾乐祸了一番，开发抬头看了他一眼，悠悠的说：“bug 都转给你了”

“纳尼。。。”，产品赶紧冲到自己的电脑前,打开 “我负责的未完成的 bug”:10 条．。。。。。。

全部都是体验类问题需要产品跟进，哈哈哈，再也不用担心提测后产品再来修体验问题啦 !

5、 其实一切都是心酸史

心酸 1：打包
 
来，今天我们开始冒烟吧，帮打个冒烟包吧

开发 A:” 好，现在打”

然后过了 15min，“打好了么”

“平台有问题耶， 打不出来了”

然后过了 15min, “打好了么”

“刚才 xx 提交代码了，我重新打个”

 。。。。。。。

然后夜色降临，我们默默的去了饭堂

心酸 2：一定是我不够吸引

冒烟组织人：“来，大家装包开始冒烟”

开发 A:” 好，等我解完这个 bug"

测试 B:” 好，当我测试完这个路径”

产品 C:” 好，你帮我装个包可以么？ 嘻嘻”

然后过了 10min, 大家还是雷动不打的坐在座位上。。。。。。。。

心酸 3：自己给自己挖的坑，哭着也要填完

• 1)  心酸录 bug: 最开始的冒烟我们是拿着一张 A4 纸录 bug ,一个回合下来，20 多条 bug，测试同学吃完饭就苦逼的拿着电脑啪啪啪地录 bug，我们真的不是一个文员。

• 2)  心酸回归 bug: 每天自己测试提了几十条 bug，然后冒烟 bug 还有几十条要测试同学回归， 然后就没有然后了~~~~

6、心酸破解法：

破解法 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. 每天的 showcase： 在冒烟过程中，大家会有很多体验或者需求的问题，产品会在场帮忙大家解答或者收集大家的反馈，有效的反馈都会录入到 tapd

如何录入问题

• 1、标题格式说明：【版本 + 模块名 + 冒烟测试】【BUG/体验】xxxx--提 bug 人 
  

• 2、录入 TAPD:(录入模板参考附件， 录入方式见下
  

六、实践小技巧：

• 今天我当家：开发轮流负责, 提高主动性和加强对测试的理解

• 今日事，今日毕：当天录入 bug, 快速录入让开发快速解决

• 一秒转产品：体验类的问题快速转产品处理，产品再消化为产品问题，确定是否进行需求变更

- 宁可错过，不可放过：无论问题大小，是体验类还是 bug 类， 都让大家进行录入

• 快速回归 bug： 快速回归不遗留，遗留打屁股

• 追求大而全：收集下大家的机型和 android 版本，可以适当的补充遗漏的机型和 android 版本手机

• 吃货诱惑：FT 内可以偶尔准备一些小零食，在冒烟的时候提供，让日复一日的冒烟有一些小惊喜

• 用事实证明自己：氧气冒烟的成果非常可观，为 FT 的质量保证也提供了一个有效且方便的方法，得到了大家认可，大家才会主动持续的参与进来

七、小结

在版本快速迭代的节奏下，冒烟测试作为常规测试的一个有效补充之外，也为其他角色了解测试搭建了一个很好的桥梁，这个过程需要各个角色一同参与和优化，才能达到比较好的实践效果。

本章完~

---

TMQ（腾讯移动品质中心）是腾讯最早专注在移动 APP 测试的团队

网站专注于移动测试技术精华，饱含腾讯多款亿级 APP 的品质秘密，文章皆独家原创，我们不谈虚的，只谈干货！】

扫一扫 关注 TMQ

精彩分享不断