把机器变成人· 揭秘WeTest自动云探索技术

      谨以此文祭奠这些年我在适配上栽过的坑——毛毛

 

安卓平台的诞生为手机智能化的普及立下汗马功劳，但安卓平台最大的缺点也越来越凸显，那就是碎片化严重：设备繁多，品牌众多，版本各异，分辨率不统一等等，这些都逐渐成为安卓系统发展的障碍，碎片化严重不仅造成安卓系统混乱，也导致安卓应用的隐形开发成本的增多。Crash问题不解决玩家的吐槽之声就无法熄灭。

 

 

 

Android碎片化让适配测试必不可少

 

开始话题前，先看看适配中心提供的数据，了解下Android到底有多碎片化？

（Android 碎片化细分维度——数据来自适配中心）

 

数据上可以明显看出，android 碎片化主要体现在机型上，细分下去还关乎系统版本、手机品牌（定制rom）、分辨率等好几个维度。

 

为了解决机型碎片化，平时发布一个手游或迭代一个大版本前，都需要做一个比较全面的适配测试。不同工作室要求不一样，有的要求TOP50，有的要求TOP100，但即使是做到了TOP100也只是覆盖了市面上30%的机型，更何况TOP50和TOP10 。

（Android TOP机型的覆盖率——数据来自适配中心）

 

看到这里你肯定会问“到底测试多少款设备够呢？”，这个没有统一的定论，但就目前人工测试的情况，能做到TOP100就已经不错了；另外由于人力限制，适配测试也不可能做到每日构建，一般上线之前根据情况做个2-4次，还包括回归测试，且适配问题的修改通常也是突击式的，那有没有更好的办法来做适配测试呢？

 

探索中诞生的新思路——把机器变成人，让手机自动探索帮助适配测试

 

 

要实现适配测试自动化需要借助UI自动化工具来模拟人的操作，说到UI自动化，如果你做过Web测试 ，你可能会接触过Selenium，Watir，IBM RFT等，做过Windows平台的，你可能知道AutoIT，PyWinAuto等，做过Android平台的，你可能知道Robotium，Appium等，还有基于图像识别的工具Sikuli，做过的同学都知道UI自动化有一个天敌——UI变化！想想都是泪！

 

而变化对手游来说更是天天在发生，那怎么办呢？——不用写脚本就可以自动化！

 

 

你可能会想这应该是写一个比较复杂的AI脚本完成的！但是我想告诉你，这个视频中的效果不需要写一句脚本，对比需要写脚本的传统坐标录制法（普遍应用在一些测试工具上），也有着有非常大的优势，可以见下图：

 

技术揭秘，如何把机器变成人？

 

目前，我们的自动化云探索技术，可以针对适配测试的特点，在大量真机上运行，尽量可能的深入到游戏中的各个场景中，关注是否有Crash/ANR以及画面方面的问题；但不验证功能本身是不是正确，功能测试很多地方需要主观判断且与机型没什么关系，只需在少数手机上测试，目前来看手工还比较适合。

第一步：识别当前游戏界面上的UI控件，如下图

原理即是在游戏中集成一个自动化测试所需要的SDK，与外部的云探索测试执行器通信。

执行器通过SDK获取到游戏中的UI信息，进而操作。而对于机器来说，默认情况下只能做简单的Touch操作，无法预知游戏中的哪个地方应该去滑动等复杂情形。

这一部分可以通过学习的方式或是策略配置的方式，使得当探索到某个固定的场景（按场景特征匹配）时，可以有策略的按配置的策略执行，比如刚刚飞机大战的那个界面，当到那个游戏中，可以配置一个左右滑动的策略，这样飞机到了这个场景就可以左右滑动了。

那么如何去探索呢？

关键是如何选择UI对象，这里面可以根据UI的一些信息，设备对应的优先级，比如按钮等可以提高优先级，也可以探索的过程中随着场景的深入来调整优先级，总之目标是保证一些重要的UI可以优先被操作。

还有一个问题，探索过程出现的一些异常情况怎么办？

方法是记录异常点，然后重启游戏，继续后续的操作步骤。这样方法，成本比较低，有的游戏只需要接入一个SDK，复杂些的游戏配置一下对应场景的策略即可。可以把测试的过程接入到RDM上，每日构建出来后在真机实验室跑一遍，可以早期快速发现一些适配问题。

 

把机器变成人，最终会代替人吗？

 

目前看来，永远不会。

我们只是辅助优化测试团队，减轻测试团队的工作负担，然后让测试人员更专注在专业领域上，变成更专业的测试专家。也让团队能够优化得更有效率。

 

如何接入？

但目前由于手游游戏类型过于丰富，自动化云探索技术对不同类游戏还需要积累学习行为，暂时这项技术并没有在WeTest平台（http://wetest.qq.com）提供，仍处于内部测试阶段。但我们非常欢迎有兴趣的项目可以联系我们做合作试点，帮助我们加强技术，也可以在前期优先体验产品，尽快提升人工测试效率。

 

感兴趣的同事请rtx联系ayuzzhang 或者发送邮件做申请。

 

 

最后分享一些会上比较集中的Q&A给大家，希望能帮助大家更了解这项技术。

1、 能支持哪些游戏引擎？

目前支持Unity和cocos2dx，具体引擎的版本也会根据需求扩充。

 

2、 这种方法，XX玩法的手游能否支持？

这方法对不同玩法的游戏适应能力不同，具体需要大家一起去探讨，如何利用这样的机制来更好的服务手游的适配测试，比如棋牌类，机器是不会打牌的，但是可以利用托管来打牌。有些比较复杂的游戏，可以通过使用GM命令或是开发同学做一些可测试性的配合来提高测试的有效性。比如天天飞车或是雷霆战机这样的游戏，可以通过GM命令把车或飞机变的很牛逼，然后过很多关；如果开发同学可以提供更多的信息，通过扩展方式可以躲藏前面的障碍（我YY的）。

 

3、 可以获取哪些适配问题？

安装失败、拉起失败、Crash、ANR、画面类的问题，如黑屏和白屏这样的可以考虑通过图像识别来自动化检测，但是对于一些主观性很强的画面问题目前看只能通过人来看测试过程中的截图来识别。

 

4、 手游项目接入成本高吗？

针对不同的游戏引擎有不同的SDK包，方法都很简单，修改几行代码即可以接入，发布时去掉，可以通过编译开关控制，RDM编译时自动生成一个用于自动化的包。

 

5、 市面上的一些云测试工具是怎么做的呢？

对于手游基本都是用录制屏幕的方式，这种方法成本比较低，但是坐标的方法限制也很多，首先脚本需要人工录制，屏幕分辨率会影响，而且只能测试一些很固定的流程，流程变化了需要重录，如果流程中有些随机因素，那后面全部乱掉。

也有少数基于引擎编写脚本，但由于编写脚本工作量很大，尤其是面对游戏复杂多变的逻辑还有很强的随机性，游戏变化后维护的工作量也很大，因此通常也只是用于相对比较稳定的新手引导部分或某些固定逻辑的场景。

 

最后的最后，感谢每一位在现场给我们点赞的小伙伴！