最新消息: 电脑我帮您提供丰富的电脑知识,编程学习,软件下载,win7系统下载。

【腾讯TMQ】激情测试

IT培训 admin 7浏览 0评论

【腾讯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
精彩分享不断

【腾讯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
精彩分享不断

与本文相关的文章

发布评论

评论列表 (0)

  1. 暂无评论