做者:曾夏,微信客户端测试开发
商业转载请联系腾讯WeTest得到受权,非商业转载请注明出处。 java
2017年4月,企鹅智酷公布了最新的《2017微信用户&生态研究报告》。报告数据显示,截止到2016年12月微信全球共计8.89亿月活用户,新兴的公众号平台拥有1000万个。微信这一年来直接带动了信息消费1742.5亿元,至关于2016年中国信息消费总规模的4.54%。web
坐拥如此量级的用户,也意味着,微信发生一个小问题,即会影响大量的用户体验。基于此,微信很是注重质量。算法
目前国内不少硬件厂商,对于Android版本,深度定制本身的ROM、系统版本,例如小米的MIUI、华为的EMUI、联想的VIBEUI等。这就是N个厂商乘以M个版本,致使的版本数量爆炸,牵引出各类适配问题。数据库
微信应用去适配那么多的设备花费了大量精力时间。在这个环境下,微信团队寄托于自动化测试,但愿把更多的测试环节放在云端自动化地运行。api
兼容性测试覆盖的环节众多,微信优先选取核心的环节进行测试。并把必测的环节尽可能以自动化,云端化的方式实现。那么,哪些问题属于高优先级?微信
安装和启动问题是属于最严重的bug。这种问题通常比较少出现,可是一出现就是大问题。安装和启动失败,极可能形成微信团队的监控数据不充分,有时没法主动发现问题,最后只能经过用户反馈感知到这种错误。此时可能已经给用户形成很大影响了。微信开发
好比曾经发现华为和三星某台机型的getDrawable这个api挂掉了,致使这两款机型部分用户启动不了微信,虽然影响用户量不大,但很是严重。安装失败和启动失败是兼容性测试最基本的要求。app
Crash率是微信团队衡量一个版本是否稳定的重要标准,尤为是新出现的Crash。当测试包灰度出去以后,若是Crash率偏高,或新出现的Crash占比较高,微信团队通常会采起换包,撤包措施。这会带来如下连锁反应框架
一、给用户形成极差的使用体验工具
二、给开发和测试形成额外的工做
三、形成因版本发布延迟引发的一系列损失
所以,新出现的Crash必定是微信最关注的质量标准之一。
上面说起的兼容性问题,出现任何一种状况都是极其严重。微信团队根据同行的积累和历史经验,针对不一样的问题,作不一样的测试。
覆盖安装,顾名思义就是用新版本的应用覆盖旧版本。
覆盖安装的测试流程以下:
针对安装和启动问题是影响最严重的问题,微信团队目前在版本发布前都要作覆盖安装测试。将要发布的包,安装而且启动成功以后保证微信基本功能能正常运行。微信的每一个正式版本基本都会修改配置的版本号,Android也是根据版本号来判断App是否有更新。当覆盖安装完以后,App有专门的代码处理更新,保证数据兼容。通常第三方商店都是以这个值来检测软件是否更新。
覆盖安装测试的流程较简单,尽量模拟真实用户升级安装使用的场景。覆盖安装以后,用户启动微信时,后台发出升级指令,升级主要是确认老版本的数据可否在新版本中使用;最后经过冒烟测试,检测微信核心功能(覆盖到主要的数据库)可否正常经过。微信团队重视覆盖安装测试,除了监测一些数据兼容性问题外,还需检测新打的包是否有问题。此外tinker的patch包也须要通过相似的测试,保证patch成功以及基本的核心功能。
覆盖安装测试只在发布前夕作,由于微信这边是持续集成开发,分布分支上的包一直在更新,因此只拿即将发布的包来作,经过以后才会进行外网发布。
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给对应开发。
兼容性测试根本仍是要覆盖机型,微信团队在作一些自动化方案目的就是为了在多种机器上并行执行。原先,微信团队用来作自动化的机型数量较少。上面提到的覆盖安装测试和定制化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