【腾讯TMQ】激情测试

【腾讯TMQ】激情测试-冒烟军团的远征

一、冒烟起源篇

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

精彩分享不断