4
回答
【开源访谈】全面解读 Airtest,Google 青睐的开源自动化测试方案

游戏应用更新频繁,如何在发布更新之前快速将 bug 找出来并修复,以免延误版本发布,这对游戏的测试来说是一大挑战。游戏自动化测试方案的出现减轻了测试人员的负担,同时提高了上游开发与设计等人员的效率,使他们可以创造更多价值。

然而,游戏自动化测试领域在理论和实践上并不很让人满意,目前游戏自动化测试面临着一些复杂的问题,一般来说,包括但不限于以下几个方面:

  • 游戏引擎众多。这个问题是最被诟病的,游戏开发中使用不同的引擎,开发的方式、开发出来的产品也就不同,而在这样的情况下去做统一的测试是比较困难的,需要根据不同的引擎去做不同的测试方案。如果不跳出这个以引擎来划分游戏的思维局限,那自动化测试始终将带上引擎的束缚,难以大步向前。
  • 游戏迭代速度快。是不是发现登录游戏的时候,几乎每次都会提示游戏更新信息?游戏的迭代速度是明显高于其它应用程序的,如果自动化测试脚本的编写和更新速度跟不上,那么也就没法进行顺利的测试。
  • 需要同时兼顾不同平台。越来越多的产品会在移动端平台与 PC 端平台上同时发布,那如何让测试方案能够同时支持多平台的验证,以提高工作效率呢?这也是游戏自动化测试面临的问题。

今年3月份,在 GDC(游戏开发者大会)的 Google 开发者专场上,网易联手 Google 发布了一款由网易研发的自动化测试方案:Airtest Project。

该项目不仅解决了上边描述的一些游戏自动化测试中的问题,同时还带有模块化、扩展性等优点。开源中国采访了 Airtest 项目负责人刘欣,针对为什么 Airtest 会被 Google 青睐一探究竟。

目前项目已经开源。项目地址:

嘉宾介绍

刘欣,2013年毕业于华中科技大学,网易游戏质量保障部门技术总监,负责端游和手游的自动化测试和工具平台构建。



(贴错林更新的照片了?)

 

OSC:先分别给大家介绍一下 Airtest 项目的组成吧?



整个项目叫做 Airtest Project,在这个项目下边有两个底层的测试框架,分别是:

  • Airtest:基于设备层模拟输入和图像识别的测试框架
  • Poco:基于游戏引擎 UI 控件检索的测试框架

然后是可视化的自动化测试编辑器 Airtest IDE 和公司内部暂未开源的大规模真机测试平台 Testlab。

总体上看,就是测试框架—可视化工具——云测试平台这样的一套系统。

 

OSC:我们为什么需要做游戏自动化测试?

我觉得主要可以从以下两个方面来看这个问题:

  • 安卓手机的碎片化问题非常严重,通常网易游戏出品的游戏上线前要测试200款型号的手机。人工来做兼容性测试非常痛苦,容易出错,耗时长,自动化在这里的作用非常明显。
  • 前面说到游戏的迭代更新快,如何保证每周更新不会影响已有的内容,就需要用自动化的方式进行回归测试。通常我们的一个大型游戏每周更新前会运行数十个小时的自动化测试,如果不用自动化,那根本跟不上。

说到底也都是解放人力提高准确率效率的问题。

 

OSC:来讲讲技术上的东西,Poco 的实现原理是怎样的?

Poco 的原理是参考了安卓测试框架 UIAutomator 和 Web 测试框架 Selenium,获取到整个 UI 系统的树状结构,然后递归查找到需要操作的 UI 控件,再调用引擎或者设备接口进行模拟操作。

但是这些都不是针对游戏的测试框架,具体到游戏自动化测试上,问题就复杂很多。因为游戏引擎各异,除了流行的商业引擎 Unity、Cocos 等,还有各家公司自研的引擎,网易内部就有2款成熟的引擎。所以我们设计了一套通用的 SDK,每个引擎只需按接口实现 SDK 即可。

我们的 SDK 在游戏内启动了一个 RpcServer,外部的 Python 测试框架通过 JSONRPC 调用 SDK 的方法抓取游戏的控件树。再通过 Airtest IDE 显示整个 UI 层次结构,通过模拟输入进行自动化操作。



我们逐步支持了网易内部的各个引擎,也包括了 Unity 和 Cocos,同时我们提供了多语言的 SDK 给其他公司开发者,他们可以自行扩展到他们的自研引擎,这样我们就解决了游戏跨引擎的 UI 自动化问题。

 

OSC:Airtest 框架运用了图像识别技术,具体实现是怎么样的呢?

在14年开始做自动化的时候,看到了 MIT 研究人员公布的论文,讲的是一种新的图形脚本语言 Sikuli ,在 Sikuli 中,开发人员想要使用其它界面的元素,或者调用其它程序是不需要输入代码的,而是只要在代码处插入相应的按钮或图标截图。



这是一种理论革新,它直接以可视化的图形,而不再是以内存中的对象来作为调用单位,完全颠覆了以往的开发方式。

接触了这样一种思想之后,我们觉得非常惊艳,但是同时又认为 Sikuli 更像是一个研究成果,暂时还不能够成熟地应用在生产环境中。这时候就在想,我们自己的 Airtest 项目就可以来做一次落地啊,于是借鉴了它的思想,并做了更多的事情。

首先我们做了一层硬件抽象层的封装,将 Android/Windows/iOS 等操作系统封装成了一套统一的 API,这样我们可以轻松地获取截图,对目标进行图像识别,然后进行模拟操作。

图像识别技术主要采用了 OpenCV 中的模板匹配和 SIFT 特征值匹配。其中模板匹配对于分辨率相同的输入效果非常完美,但是由于手机分辨率各不相同,我们需要采用 SIFT 特征值匹配来解决这个问题。

SIFT 特征值具有的尺度不变性和旋转不变性满足了这个要求,但是运行效率和识别率都不够。于是我们进一步研究了常用游戏引擎的 UI 适配规则,内置了 Cocos 引擎的适配规则,同时暴露了 API 让游戏开发者明确指定自己游戏的分辨率适配算法。

这样就完美解决了图像识别的问题。实际上我们内部编写的脚本,可以运行在200种不同型号的手机上,甚至可以在电脑版客户端上运行。

 

OSC:目前游戏测试行业面临的具体问题有哪些?业内都有哪些相应的解决方案?

游戏测试行业面临的最大问题,前边有提到,由于游戏引擎不统一,整套工具链都不统一,而且引擎方支持较少,需要开发者自行解决,这样就使得不同引擎开发出来的游戏不能以通用的方案去做测试,带来了很多资源和技术上的问题。

另一个方面,对比 Android/iOS/Web 开发,整个游戏行业的工具链和开发理念都落后很多,更别提生态环境了。Unity/Cocos 的出现和流行解决了部分这类问题,但是愿意投入人力和技术资源来解决这类问题的公司不多。网易游戏在这块已经算做得不错了,我们整个团队15人,技术能力很强,就是专门在做游戏自动化和游戏开发中的持续集成。

 

OSC:Airtest 整个解决方案其实就是为了达到“自动化”,这也是软件测试行业一直以来的追求,那么关于如何去做自动化测试,行业内其它解决方案是怎么样的?人工智能在这里边势头好吗?

软件测试的自动化一般分为3层:

  • 代码层的单元测试
  • 接口层的集成测试
  • UI 层的测试

前两层在软件行业已经有一些比较好的实践,特别是那些大型稳定项目。但是对于游戏项目来说,通常开发进度超快,短时间大量迭代,所以代码和接口不够稳定,很难做自动化。于是我们只能从最上层 UI 层来做自动化。这里当然也存在 UI 迭代的问题,所以我们尽量想降低自动化的成本,这也是 Airtest IDE 产生的初衷。

业内常规的 UI 自动化方案,比较典型的有两种:

  • Android 的测试框架 UIAutomator /Espresso,利用 Android 系统的控件结构来做自动化,通常是测试代码直接在安卓手机上运行。但是仅限于 Android,而且需要有 Android 开发经验,对技术水平要求较高。
  • Selenium 和 Appium,被测应用通过 webdriver 协议与外部工具通信,再进行自动化测试。目前这套方案协议层做得不错,覆盖大部分的端,但是外部工具门槛较高,也不适合测试人员使用。

关于人工智能我们在 GDC 同一场有过分享,我们和 Google 合作的部分结合了人工智能进行尝试。目前做到的程度是用 Object Detection 来取代单纯的图像匹配,这样对于3D对象效果更好,即使3D对象转向或被遮挡也能有较好的识别率。

另外我们还在积极地做一些尝试,比如用人工智能技术做一个智能爬虫抓取游戏内的所有界面进行比对。再下一步就是真正带智能地来玩游戏,这个可能要等 DeepMind 团队先把星际争霸玩好了:)

人工智能在游戏行业和测试行业的应用,我是非常看好的。

 

OSC:请简单总结一下,对比同类项目,在技术上,Airtest 项目的特点是什么?优势是什么?

对比的话,其实前边也大致讲到了,这里简单说一下 Airtest 的特点与优势:

  • 跨平台、跨引擎:支持 Windows/Android/(iOS即将到来),支持 Unity3d/Cocos2dx,同时可以扩展其它引擎
  • 上手门槛低、上限足够高:可视化编程,0上手门槛,同时可以结合整个 Python 的工具链进行持续集成
  • 经过验证、有大量的最佳实践:在网易游戏内部,自动化技术已经应用在梦幻西游、大话西游、阴阳师等数十个产品,上千个自动化脚本累计运行上万小时

 

OSC:Google 在该项目中的参与情况具体是怎么样的?

Airtest 之前是我们的内部工具,在内部开发和使用了3年,梦幻西游、大话西游、阴阳师、荒野行动等大型游戏都在使用。

开源这个事的契机最初是我在2017年5月去硅谷参加 Google IO 大会,去到他们的 Firebase Test Lab 的展台,与 Google 的开发者进行交流。当时我也介绍了我们有这一套内部自动化解决方案,邀请他们过来广州参观。

后来几个月我们一直保持交流,他们也过来了几波人参观,评价我们这是最好的游戏自动化方案,然后我们决定合作把这个技术开源出去。

之后我们也一直保持着联系,每周有视频会议,在 Airtest 项目的产品设计和技术上进行沟通。谷歌也在 Google Firebase Test Lab 上支持 Airtest 和 Poco 框架。除此之外,Google 还给了我们很多开源方面的建议。

 

OSC:请介绍一下该项目接下来的计划。

游戏领域是我们最擅长的,所以我们会争取做到最好。目前我们在国内的社区非常活跃,有大量的用户反馈,我们会持续优化和完善。

我们发布时也支持了 Android 源生 App 的测试,而且反馈也不错,这块准备深挖一下。

接下来我们的主要开发计划是扩展支持更多的平台,支持所有端的自动化测试。最重要的是 iOS,后面还有 Web/Hybrid/VR 等等。

从3月 GDC 发布以来,我们开发团队一直在持续开发,可以预告一下 iOS 和 Web 端支持即将在未来几周到来。5月的 GoogleIO Android Game Summit 上,我也被邀请做一个 Airtest Project 技术演讲。

更重要的一点是,我们希望能把整个自动化测试的开源社区建立起来,有兴趣的同学可以通过以下邮箱联系我们,一起交流技术,把开源事业做好:

  • gzliuxin@corp.netease.com
举报
h4cd
发帖于5个月前 4回/2K+阅
顶部