腾讯移动品质中心TMQ [腾讯 TMQ] 激情测试-冒烟军团的远征

匿名 · 2016年08月09日 · 最后由 AWSL 回复于 2016年08月10日 · 114 次阅读

一、冒烟起源篇

冒烟测试的概念在整个测试组其实已经使用很久,在 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
精彩分享不断
共收到 9 条回复 时间 点赞

这两篇都很赞呐,冒烟测试也是提高测试效率的一种手段,提前暴露问题,可以有效避免正式提测时仍存在主流程上的问题,从而打乱测试节奏,陷入无限重复测试的死循环中

—— 来自 TesterHome 官方 安卓客户端

真的羡慕全民参与测试的团队。

= =冒烟是产品交付的最后一关了,如果那个时候都产生 B+ 问题是失职吧。测试也同行军打仗,新老兵交杂,这个战斗力没法看的。质量是大家一起把控的,但具体测试还是交给测试吧,人多反而拖冒烟测试时间,不是自己职能的自己在做,还会产生对测试不信任,人人可以做测试的思想。矛盾点:没时间修和需求不明确各种问题。

#1 楼 @rtttte 冒烟测试- -是提高测试效率的一种手段...好吧

#4 楼 @jiazurongyu 是开发提测前需要先自己进行一次冒烟测试,当然是在开发提测质量较低的前提下,这样还是很有帮助的。

#5 楼 @rtttte 冒烟测试来源工业,汽车产业最早来源。最终交付前的验收,在这个阶段理论是做过缺陷收敛和控制的,会根据交付版本更新的粒度(客户端,服务端,壳,数据结构)等来规划时间,属于较短的交付行为。
用例和方法也是抽取本次更新的 70% 内容加之前版本 30% 左右的进行测试,控制在 1 人/1 小时内(客户端和服务端的),如果 3 个人就是控制在 30 分钟,冒烟测试做开发迭代的话,那就不是冒烟测试了。
开发提测,客户端应该是测试提测吧,服务端也应该由测试交付给 SA 运维

感觉更像探索新测试

#6 楼 @jiazurongyu 好吧,冒烟原来是交付前的验收,一直认为是正式测试前的可测性验证

—— 来自 TesterHome 官方 安卓客户端

我觉得冒烟测试非常好啊 不一定非得专业测试人员做,有些时候跳出思维定势发现 bug 的恰恰是非测试人员呢。一些遍历 UI 的工作可以用自动化来完成。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册