WeTest腾讯质量开发平台 月活 8.89 亿背后:微信工程师细数兼容测试经验

腾讯WeTest · 2017年04月27日 · 最后由 赵宁 回复于 2018年06月09日 · 3515 次阅读

作者:曾夏,微信客户端测试开发
商业转载请联系腾讯 WeTest 获得授权,非商业转载请注明出处。
原文链接:http://wetest.qq.com/lab/view/306.html


2017 年 4 月,企鹅智酷公布了最新的《2017 微信用户&生态研究报告》。报告数据显示,截止到 2016 年 12 月微信全球共计 8.89 亿月活用户,新兴的公众号平台拥有 1000 万个。微信这一年来直接带动了信息消费 1742.5 亿元,相当于 2016 年中国信息消费总规模的 4.54%。

坐拥如此量级的用户,也意味着,微信发生一个小问题,即会影响大量的用户体验。基于此,微信非常注重质量。

目前国内很多硬件厂商,对于 Android 版本,深度定制自己的 ROM、系统版本,例如小米的 MIUI、华为的 EMUI、联想的 VIBEUI 等。这就是 N 个厂商乘以 M 个版本,导致的版本数量爆炸,牵引出各种适配问题。

微信应用去适配那么多的设备花费了大量精力时间。在这个环境下,微信团队寄托于自动化测试,希望把更多的测试环节放在云端自动化地运行。

一、微信最关注的质量问题

兼容性测试覆盖的环节众多,微信优先选取核心的环节进行测试。并把必测的环节尽量以自动化,云端化的方式实现。那么,哪些问题属于高优先级?

1、安装和启动失败

安装和启动问题是属于最严重的 bug。这种问题一般比较少出现,但是一出现就是大问题。安装和启动失败,很可能造成微信团队的监控数据不充分,有时无法主动发现问题,最后只能通过用户反馈感知到这种错误。此时可能已经给用户造成很大影响了。

比如曾经发现华为和三星某台机型的 getDrawable 这个 api 挂掉了,导致这两款机型部分用户启动不了微信,虽然影响用户量不大,但非常严重。安装失败和启动失败是兼容性测试最基本的要求。

2、Crash 问题

Crash 率是微信团队衡量一个版本是否稳定的重要标准,尤其是新出现的 Crash。当测试包灰度出去之后,如果 Crash 率偏高,或新出现的 Crash 占比较高,微信团队一般会采取换包,撤包措施。这会带来以下连锁反应

1、给用户造成极差的使用体验

2、给开发和测试造成额外的工作

3、造成因版本发布延迟引起的一系列损失

因此,新出现的 Crash 一定是微信最关注的质量标准之一。

二、对症下药,提前发现问题

上面提及的兼容性问题,出现任何一种情况都是极其严重。微信团队根据同行的积累和历史经验,针对不同的问题,做不同的测试。

1、针对安装和启动问题——覆盖安装测试

覆盖安装,顾名思义就是用新版本的应用覆盖旧版本。

覆盖安装的测试流程如下:

针对安装和启动问题是影响最严重的问题,微信团队目前在版本发布前都要做覆盖安装测试。将要发布的包,安装并且启动成功之后保证微信基本功能能正常运行。微信的每个正式版本基本都会修改配置的版本号,Android 也是根据版本号来判断 App 是否有更新。当覆盖安装完之后,App 有专门的代码处理更新,保证数据兼容。一般第三方商店都是以这个值来检测软件是否更新。

覆盖安装测试的流程较简单,尽可能模拟真实用户升级安装使用的场景。覆盖安装之后,用户启动微信时,后台发出升级指令,升级主要是确认老版本的数据能否在新版本中使用;最后通过冒烟测试,检测微信核心功能(覆盖到主要的数据库)能否正常通过。微信团队重视覆盖安装测试,除了监测一些数据兼容性问题外,还需检测新打的包是否有问题。此外 tinker 的 patch 包也需要经过类似的测试,保证 patch 成功以及基本的核心功能。

覆盖安装测试只在发布前夕做,因为微信这边是持续集成开发,分布分支上的包一直在更新,所以只拿即将发布的包来做,通过之后才会进行外网发布。

2、Crash 问题——稳定性测试

Crash 问题对应的测试是稳定性测试。对于 app 的稳定性测试,官方的测试工具是 monkey。monkey 会产生一些列随机性事件(具体比例可以配置)测试目标 APP 是否出现 Crash。

Monkey 测试的局限性

微信团队发现 monkey 不会去检测界面上的控件,因此产生的事件过于随机,不太符合微信的测试需求。因此,微信开发了一个基于控件的定制化 monkey 来做稳定性测试。

要基于控件开发一个定制化 monkey,首先就需要获取界面(Activity)的所有控件(View)。

选择框架修改 Monkey 脚本

一开始采用 robotium 框架,但微信本身是一个多进程的 App,比如打开相册,或者 webview 的时候,都是在一个 tools 进程中的,而 robotium 只针对单个进程,需要去改框架源码才可以支持多进程的微信 App,实现起来比较繁琐。因此后面微信团队开始使用官方框架 UIAutomator。

利用框架获取控件(View)

google 并没有给出公开接口获取所有控件,如果使用 selector 来获取,速度很慢,因为 google 为了保证 ui 自动化的执行,很多地方加了等待,而 monkey 测试需要快速的点击。通过参考 UIAutomator 的源码实现,微信团队决定利用 java 的反射原理拿到 AccessibilityNodeInfo,中间去掉无谓的等待或者减少等待事件增加重试次数。AccessibilityNodeInfo 跟 view(控件)有一对一的关系,在 uiautomator 里面就跟一个 UiObject 对应。目前外面很多的抢红包插件也是利用 AccessibilityService 拿到 AccessibilityNodeInfo 来做识别和点击。

定制化 Monkey 的诞生

通过反射的方案,获取当前 activity 的速度可以保证在十几毫秒以内完成。获取所有控件之后,就可以针对控件做随机探索了!

为了更好的遍历尽可能多的 activity,微信团队采用改造之后深度遍历算法。我们称之为 “定制化 Monkey”。定制化 monkey 的运行逻辑比较简单,其中,还有一些特殊处理,比如返回的时候要检查是否有弹框,打开 webview 的时候检查是否有弹框(地理位置),跑的时候是否有退出登录等。目前来看改造的效果比原生的效果有一定的提升,下面是单机的测试结果:

从上图可以看出,相对于原生的 monkey,行覆盖率大约有 80% 的提升,activity 覆盖率大约有将近 200% 的提升。而且从曲线上可以看到,这两个 monkey 在登录之后的 1 个小时以内,行覆盖率和 activity 覆盖率都有明显的提升,在 1 到 2 个小时以内也会缓慢提升,而两个小时之后提升就非常缓慢了。

微信团队每天都会取最新代码编的 apk 包进行稳定性测试,收集出现的 Crash,并且把新出现的 Crash,提交 bug 给对应开发。

3、机型覆盖——云端化测试

兼容性测试根本还是要覆盖机型,微信团队在做一些自动化方案目的就是为了在多种机器上并行执行。原先,微信团队用来做自动化的机型数量较少。上面提到的覆盖安装测试和定制化 monkey 测试,可能只跑典型的 6 到 10 台机型。

现在兼容性测试迁移到 WeTest 平台上,测试基于 WeTest 给微信搭建的私有云平台进行,同时公有云的机型作为补充。

至此,微信团队实现了机型管理云端化,设备覆盖也有了实质性提升。

微信团队每天都会在测试平台上申请上百台手机跑多轮定制化 Monkey 测试,日均测出十几个 Crash,一些新特性上线的高峰期有时可达 40/50 个。

三、其他关键质量问题——新功能适配

除以上问题之外,新功能上线时,微信团队会非常关注其是否会产生新的适配问题。譬如,字体截断问题,键盘问题等。一年多前,微信发布小视频功能,发现多个厂商定制 ROM 导致的视频方向错误,黑屏,播放失败等问题,严重影响用户体验。

每个版本都有功能兼容性问题,并且每个版本的测试内容都不一样。目前采用的方式还比较低级,主要依靠人力在主流机型上进行兼容性测试以及众测。

版本间差异大,自动化陷入困境

功能测试一般针对某个特定版本,因此自动化脚本基本只适用特定版本,复用性弱,自动化不能带来好的收益。同时,功能测试路径有时比较特殊,自动化脚本难写,验证麻烦。比如小视频功能测试,自动化脚本判断不出来是否出现黑屏、花屏,必须要人眼判断。

部分特性可以自动化实现:半自动化测试

一些特性可以做自动化或者半自动化测试。比如 H5 测试,主要是检测在不同手机上打开页面,看看页面是否有 UI 问题。半自动化测试方案:通过脚本驱动 UI 操作和 webview 操作,同时在关键的页面截图,生成带一系列截图的测试报告。事后肉眼查看截图,比对判断测试是否通过。

功能兼容性问题目前我们还没有一个通用的解决方案,都是根据不同的需求利用目前手头资源做尽可能完善的测试。

功能自动化测试迁入 WeTest 平台

针对功能适配兼容性测试,微信团队也把 H5 适配兼容性测试和部分高优先级自动化用例迁移到 WeTest 平台上。

● 建立微信私有云:在私有云上,微信团队不间断提交自动化脚本进行 24 小时测试。当私有云缺少某台特定机型时,WeTest 公有云上的机型作为补充测试。

● 微信质量系统与私有云对接:WeTest 将一些接口开放给微信,微信利用这些接口,搭建了自己的云端质量管理平台,直观、便捷地进行测试管理工作,大大提升了效率。

四、效果

微信团队通过自动化、云端化测试,在兼容性和功能测试方面效率提升了 1 倍多,更快速、精准地定位解决问题,累计发现并解决的问题数达数千个,覆盖亿级用户,提供了流畅稳定的体验环境。

后续,我们期待云端化、自动化测试深度覆盖到更多测试环节,使测试过程和测试结果变得更加流畅、可视化。通过技术的力量,持续提升产品的质量!


马上进入 “专家兼容测试” 界面,找腾讯测试专家团队帮您把关移动应用质量吧!点击链接即可使用专家兼容测试服务:http://wetest.qq.com/product/expert-compatibility-testing

恰逢 WeTest 钜惠焕新季,还有手游专家兼容豪华大礼包哦!特大优惠不容错过:
http://wetest.qq.com/activities/20170419

可以联系 wetest 小助手抢先了解优惠详情,咨询预约(QQ:800024531)


亲爱的读者,为了能够提供更好的网站内容,希望您填写我们的问卷,我们会随机抽取读者回馈 20Q 币以示感谢!问卷入口:https://wj.qq.com/s/1221194/26ad

共收到 8 条回复 时间 点赞

微信团队居然不用腾讯的 new monkey 吗?

simple 回复

WeTest 平台也是腾讯的哦

腾讯WeTest 回复

用 new monkey 了吗?我看提到的是定制 monkey

匿名 #5 · 2017年04月28日

跪求 monkey 的具体实现方案,目前想做这一方面,但是 monkey 太随机了,感觉不是很有效率,即便设置了参数,也很难达到想要的效果。

simple 回复

微信使用的是定制化 monkey,和你说的 new monkey 不是一回事

能问一下反射的方案具体吗

定制 monkey 的行覆盖率是指代码覆盖率吗??
另外看图上显示定制 monkey 的 Activity 覆盖率才 30%,基于控件之类的深度遍历覆盖度提升有限,建议换种思路,我也对 monkey 做了优化,跑一次 monkey 目前 Activity 覆盖率可以到 65%,理论上可以 100%,等不忙了有时间我可以分享下😀

请问一下你们实现了视频通话的自动化测试了么

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