[点晴永久免费OA]月活8.89亿背后:微信工程师细数兼容测试经验
当前位置:点晴OA办公管理信息系统
→『 经验分享&问题答疑 』
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倍多,更快速、精准地定位解决问题,累计发现并解决的问题数达数千个,覆盖亿级用户,提供了流畅稳定的体验环境。 后续,我们期待云端化、自动化测试深度覆盖到更多测试环节,使测试过程和测试结果变得更加流畅、可视化。通过技术的力量,持续提升产品的质量! 该文章在 2017/5/4 11:35:27 编辑过 |
关键字查询
相关文章
正在查询... |