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倍多，更快速、精准地定位解决问题，累计发现并解决的问题数达数千个，覆盖亿级用户，提供了流畅稳定的体验环境。
后续，我们期待云端化、自动化测试深度覆盖到更多测试环节，使测试过程和测试结果变得更加流畅、可视化。通过技术的力量，持续提升产品的质量！
