默认
打赏 发表评论 1
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
月活8.89亿的超级IM微信是如何进行Android端兼容测试的
微信扫一扫关注!

原作者:曾夏,微信客户端测试开发工程师。


1、前言


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

1.jpg

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

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

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

2.png

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


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

1安装和启动失败


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

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

2Crash问题


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

这会带来以下连锁反应:

  • 1、给用户造成极差的使用体验;
  • 2、给开发和测试造成额外的工作;
  • 3、造成因版本发布延迟引起的一系列损失。

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

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


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

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


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

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

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

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

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

2Crash问题——稳定性测试


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的时候检查是否有弹框(地理位置),跑的时候是否有退出登录等。

目前来看改造的效果比原生的效果有一定的提升,下面是单机的测试结果:
4.jpg

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

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

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


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

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

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

6.png

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

4、其他关键质量问题:新功能适配


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

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

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

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

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

功能自动化测试迁入云测试平台:
针对功能适配兼容性测试,微信团队也把H5适配兼容性测试和部分高优先级自动化用例迁移到WeTest平台上。
  • 建立微信私有云:在私有云上,微信团队不间断提交自动化脚本进行24小时测试。当私有云缺少某台特定机型时,公有云上的机型作为补充测试。
  • 微信质量系统与私有云对接:公有云测试平台将一些接口开放给微信,微信利用这些接口,搭建了自己的云端质量管理平台,直观、便捷地进行测试管理工作,大大提升了效率。

7.png

5、最终效果


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

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

(原文链接:点此进入

附录:有关QQ、微信的文章汇总


[1] 有关QQ、微信的技术文章:
月活8.89亿的超级IM微信是如何进行Android端兼容测试的
以手机QQ为例探讨移动端IM中的“轻应用”
一篇文章get微信开源移动端数据库组件WCDB的一切!
微信客户端团队负责人技术访谈:如何着手客户端性能监控和优化
微信后台基于时间序的海量数据冷热分级架构设计实践
微信团队原创分享:Android版微信的臃肿之困与模块化实践之路
微信后台团队:微信后台异步消息队列的优化升级实践分享
微信团队原创分享:微信客户端SQLite数据库损坏修复实践
腾讯原创分享(一):如何大幅提升移动网络下手机QQ的图片传输速度和成功率
腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(下篇)
腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(上篇)
微信Mars:微信内部正在使用的网络层封装库,即将开源
如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源
开源libco库:单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]
微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解
微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)
微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)
Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]
微信团队原创分享:Android版微信从300KB到30MB的技术演进
微信技术总监谈架构:微信之道——大道至简(演讲全文)
微信技术总监谈架构:微信之道——大道至简(PPT讲稿) [附件下载]
如何解读《微信技术总监谈架构:微信之道——大道至简》
微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]
微信异步化改造实践:8亿月活、单机千万连接背后的后台解决方案
微信朋友圈海量技术之道PPT [附件下载]
微信对网络影响的技术试验及分析(论文全文)
一份微信后台技术架构的总结性笔记
架构之道:3个程序员成就微信朋友圈日均10亿发布量[有视频]
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
快速裂变:见证微信强大后台架构从0到1的演进历程(二)
微信团队原创分享:Android内存泄漏监控和优化技巧总结
全面总结iOS版微信升级iOS9遇到的各种“坑”
微信团队原创资源混淆工具:让你的APK立减1M
微信团队原创Android资源混淆工具:AndResGuard [有源码]
Android版微信安装包“减肥”实战记录
iOS版微信安装包“减肥”实战记录
移动端IM实践:iOS版微信界面卡顿监测方案
微信“红包照片”背后的技术难题
移动端IM实践:iOS版微信小视频功能技术方案实录
移动端IM实践:Android版微信如何大幅提升交互性能(一)
移动端IM实践:Android版微信如何大幅提升交互性能(二)
移动端IM实践:实现Android版微信的智能心跳机制
移动端IM实践:WhatsApp、Line、微信的心跳策略分析
移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)
移动端IM实践:iOS版微信的多设备字体适配方案探讨
信鸽团队原创:一起走过 iOS10 上消息推送(APNS)的坑
腾讯信鸽技术分享:百亿级实时消息推送的实战经验
>> 更多同类文章 ……

[2] 有关QQ、微信的技术故事:
技术往事:创业初期的腾讯——16年前的冬天,谁动了马化腾的代码
技术往事:史上最全QQ图标变迁过程,追寻IM巨人的演进历史
技术往事:“QQ群”和“微信红包”是怎么来的?
开发往事:深度讲述2010到2015,微信一路风雨的背后
开发往事:微信千年不变的那张闪屏图片的由来
开发往事:记录微信3.0版背后的故事(距微信1.0发布9个月时)
一个微信实习生自述:我眼中的微信开发团队
首次揭秘:QQ实时视频聊天背后的神秘组织
>> 更多同类文章 ……

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:以手机QQ为例探讨移动端IM中的“轻应用”下一篇:腾讯手机管家iOS版的iPhoneX适配实践分享

本帖已收录至以下技术专辑

推荐方案
评论 1
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部