激情测试--冒烟军团的远征

一、冒烟起源篇

冒烟测试的概念在整个测试组其实已经使用很久，在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% 命中率

建议： 宁可错过，不可放过

说明： 我们依旧会让大家尽量提bug，在早期暴露了问题，再让开发和产品评估这个问题是否需要解决

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. 推荐： 测试也需要引导测试的路径，可以从测试的一些角度提出

产品童鞋：

每天的showcase：在冒烟过程中，大家会有很多体验或者需求的问题，产品会在场帮忙大家解答或者收集大家的反馈，有效的反馈都会录入到tapd

如何录入问题

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

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

六、实践小技巧

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

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

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

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

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

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

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

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

七、小结

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