CN107025165B

CN107025165B - 游戏自动化测试方法及相关装置

Info

Publication number: CN107025165B
Application number: CN201710132376.1A
Authority: CN
Inventors: 方亮; 许敏华; 孙大伟; 阚传奇; 贺国睿
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd; Tencent Cloud Computing Beijing Co Ltd
Priority date: 2017-03-07
Filing date: 2017-03-07
Publication date: 2020-02-07
Anticipated expiration: 2037-03-07
Also published as: CN107025165A

Abstract

本发明实施例提供游戏自动化测试方法及相关装置。该方法包括获取录制文件；录制文件包括多条录制记录，每一条录制记录包括：第一操作事件、相关联的UI控件标识、场景信息和操作序列号；根据录制文件，执行至少一次回放操作；其中：每次回放操作包括：获取测试终端的当前游戏场景信息和当前UI控件列表；当前UI控件列表包括与测试终端的当前游戏界面相关联的所有UI控件标识；根据当前游戏场景信息、当前UI控件列表以及上一次回放操作对应的操作序列号，在录制文件中查找匹配的录制记录作为目标录制记录；在测试终端上回放目标录制记录。

Description

游戏自动化测试方法及相关装置

技术领域

本发明涉及计算机应用技术领域，具体涉及游戏自动化测试方法及相关装置。

背景技术

目前市场上终端(例如PC机、智能终端)的种类非常之多，以安装有安卓操作系统的智能手机为例，其机型多达上千款，由于不同机型使用的硬件和软件都不一样，所以游戏在开发过程中以及上市之前都需要在主流机型上进行游戏兼容性测试，以验证其能否正常运行。

传统的游戏自动化测试是基于录制回放工具通过录制坐标序列然后回放来操作游戏，以达到自动化测试的目的。其做法是：

录制过程：记录测试人员在智能终端上操作游戏的测试过程。具体的，由于人对游戏中UI控件的操作，实际是对显示屏上的坐标的操作，例如，点击某个UI控件，其实是点击了与该UI控件对应的坐标点。因此，录制回放工具会记录测试人员因触摸智能终端屏幕而产生的各种begin、move和up输入事件对应的坐标信息，生成录制记录。

回放过程：测试装置遵循时间顺序(也即输入事件的发生顺序)来依次按录制记录中的坐标信息模拟人对被测智能终端的屏幕的操作。

传统的游戏自动化测试的缺点是明显的：

在现有自动化测试过程中，若出现异常情况，例如录制过程中出现的界面在回放过程中并未出现，则后续的操作将可能完全错乱：

假定在录制过程中，弹出一个广告界面，测试人员点击关闭了该广告界面，关闭广告界面的相关输入事件会被录制下来(假定关闭广告界面共对应3个输入事件，其操作序列号是10-12)。而在回放过程时，在执行完操作序列号为9的输入事件后，广告界面并未弹出。尽管广告界面未弹出，现有自动化测试方式还是会回放关闭广告界面的相关输入事件，从而导致操作错乱，进而可能影响后续的回放。

因此，传统的游戏自动化测试存在优化空间。

发明内容

有鉴于此，本发明实施例提供一种游戏自动化测试方法及相关装置，以优化游戏自动化测试。

为实现上述目的，本发明实施例提供如下技术方案：

一种游戏自动化测试方法，包括：

获取录制文件；所述录制文件包括多条录制记录，每一条录制记录包括：第一操作事件、与所述第一操作事件相关联的操作对象、场景信息和操作序列号；所述操作对象包括UI控件标识；

根据所述录制文件，执行至少一次回放操作；其中：

所述回放操作包括：

获取测试终端的当前游戏场景信息和当前UI控件列表；所述当前UI控件列表包括与所述测试终端的当前游戏界面相关联的所有UI控件标识；

根据所述当前游戏场景信息、当前UI控件列表以及上一次所采用的录制记录中的操作序列号，在所述录制文件中查找匹配的录制记录作为目标录制记录；

在所述测试终端上回放所述目标录制记录。

一种游戏自动化测试装置，包括：

获取模块，用于获取录制文件；所述录制文件包括多条录制记录，每一条录制记录包括：第一操作事件、与所述第一操作事件相关联的操作对象、场景信息和操作序列号；所述操作对象包括UI控件标识；

回放模块，用于根据所述录制文件，执行至少一次回放操作；其中：

所述回放操作包括：

在所述测试终端上回放所述目标录制记录。

可见，在本实施例中，是根据当前游戏场景信息、当前UI控件列表以及操作序列号来查找匹配的录制记录。

举例来讲，假定在录制过程中，弹出一个广告P，测试人员点击关闭了广告P，则录制文件中将存在关闭广告P对应的录制记录。假设关闭广告P对应的录制记录包括第一操作事件A，与之关联的UI控件B、场景信息C和操作序列号12。

而在回放过程中，在测试终端上回放操作序列号为11的录制记录后，广告P并未弹出，当前游戏场景信息为场景信息C1、当前UI控件列表包括UI控件B1，B2，B3。则根据本申请提供的方案，操作序列号12对应的录制记录(包括UI控件B、场景信息C)与当前游戏场景信息和当前UI控件列表不匹配，不会被作为目标录制记录进行回放。

也即，在“录制过程中出现的界面在回放过程中并未出现”的情况下，本申请提供的方案可以跳过相应的录制记录不进行回放，从而不会导致操作错乱。可见，本实施例所提供的技术方案强壮了回放过程，优化了游戏自动化测试。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1a和图1b为本发明实施例提供的应用场景示意图；

图2为本发明实施例提供的服务器或终端的计算机架构示例图；

图3为本发明实施例提供的游戏当前界面及UI控件树示意图；

图4-8，10为本发明实施例提供的游戏自动化测试方法示例性流程图；

图9为本发明实施例提供的回放报告示例图；

图11为本发明实施例提供的游戏自动化测试装置或服务器的示例性结构图；

图12为本发明实施例提供的测试终端的示例性结构图。

具体实施方式

本发明可能使用的技术名词、简写或缩写如下：

手游：手机游戏，相对于运行在PC机上的游戏而言，主要是指运行在终端及平台上的游戏；

游戏兼容性测试：由于市场上终端的种类非常之多，以安装有安卓操作系统的智能手机为例，其机型多达上千款，由于不同机型使用的硬件和软件都不一样，所以游戏在开发过程中以及上市之前都需要在主流机型上进行兼容性测试，以验证其能否正常运行，这便是游戏兼容性测试；

Unity引擎：Unity引擎是用于创建三维游戏、建筑可视化等类型互动内容的多平台的综合型游戏开发工具，是一个全面整合的专业游戏引擎。目前市面上100％的游戏使用unity引擎制作；

UI：用户界面；

UI控件：用户界面控件，例如，请参见图3，图3左侧为一游戏界面，在该界面上有两个UI控件，即“与微信好友玩”按钮和“与QQ好友玩”按钮。实际上，UI控件是与图右所示的UI控件树上的某一GameObject(节点)相对应。每一UI控件对应UI控件树上的一个节点。UI控件对应的GameObject的名称即为UI控件的控件名称。

例如，“与QQ好友玩”按钮对应的节点的路径为：

"/BootObj/CUIManager/Form_Login/LoginContainer/pnlMobileLogin/btnGroup/btnQQ"。

其中，“与QQ好友玩”的控件名称是tnQQ，其父亲节点名称为btnGroup，而btnGroup的父亲节点是pnlMobileLogin，以此类推。

NGUI：Next-Gen UI kit，NGUI是Unity引擎上一套功能强大的UI和事件传递框架；

UGUI：与NGUI类似，UGUI是Unity官方出品的一套UI和事件传递框架。可用于创建按钮、滑动栏等UI控件，处理按钮对应的点击事件等；

WeTest平台：云端手机管理系统，管理实验室几百台手机。通过WeTest平台能够获取某一部手机的屏幕转向、长宽、截图等服务；WeTest平台可包括多个云端服务器。

SDK：软件开发包；

ADB：Android Debug Bridge，Google提供，android开发工具之一。主要的作用是，提供电脑和智能终端之间交互服务。通过USB线，电脑上的软件能够直接访问智能终端，连接智能终端。

本发明提供游戏自动化测试方法、应用于服务器的游戏自动化测试装置、测试终端及游戏自动化测试系统。

上述服务器具体可为本地服务器(例如普通的个人计算机)或云端服务器。本地服务器可连接一台被测试的终端(简单为测试终端)，而云端服务器可连接多台测试终端。

测试终端可为PC端，也可为智能终端，例如手机、ipad等。在测试终端中安装有待测试的游戏(简称为测试游戏)。

图1a和图1b示出了上述游戏自动化测试系统的一种示例性结构，该系统至少包括服务器和智能终端(测试终端)。

需要说明的是，虽然图1a和图1b示出的游戏自动化测试系统仅包含了一台终端和一台本地服务器，但不应理解为游戏自动化测试系统仅限于包含一台测试终端和一台服务器。

游戏自动化测试系统可包含多个云端服务器，每一云端服务器可连接多台测试终端。

服务器中包含自动化测试装置(或自动化测试模块)，自动化测试装置可进一步划分为录制工具和回放工具。录制工具可安装在服务器上，也可直接安装在测试终端上，而回放工具则可安装在服务器上。

在一个示例中，服务器中存储有python脚本(游戏自动化测试脚本)，通过运行python脚本，可实现自动化测试装置/模块的功能，执行上述游戏自动化测试方法。

对于云端服务器，前述介绍了可连接多台终端。一台终端对应一个WeTest服务进程，对应运行一次脚本。举例来讲，云端服务器连接10台终端，则有10个WeTest服务进程，脚本会运行10次。

在另一个示例中，自动化测试装置可以硬件的形式安装于服务器中。

测试终端中安装有测试游戏，为了配合服务器完成游戏自动化测试，上述测试游戏嵌入了WeTest SDK。

其中：

WeTest SDK可视为游戏的组件，可提供游戏控件(特别是UI控件)ID查询、控件位置查询、交互操作等(例如点击、长按、滑动等)。在游戏启动时，WeTest SDK随之启动，并会开启一个socket服务，监听来自Python脚本的请求。

当然，WeTest SDK是在自动化测试过程中安装在游戏中的。真正发行的游戏版本中不包含WeTest SDK。手游的UI控件可由Unity引擎的NGUI或UGUI开发。因此，WeTest SDK可有两个版本，一个针对NGUI，一个针对UGUI。

Python脚本：可通过ADB与WeTest SDK通信。其功能可包含检查游戏当前界面，决定操作行为，判定执行结果等。

UI Automator：可用于查看安卓系统标准UI控件。

录制工具：可通过与WeTest SDK通讯完成录制过程；

回放工具：可通过与WeTest SDK通讯完成回放过程。

图2示出了上述游戏自动化测试装置的一种通用计算机系统结构。

上述计算机系统可包括总线、处理器1、存储器2、通信接口3。在一个示例中，上述计算机系统还可包括输入设备4和输出设备5。

上述处理器1、存储器2、通信接口3、输入设备4和输出设备5通过总线相互连接。其中：

总线可包括一通路，在计算机系统各个部件之间传送信息。

处理器1可以是通用处理器，例如通用中央处理器(CPU)、网络处理器(NetworkProcessor，简称NP)、微处理器等，也可以是特定应用集成电路(application-specificintegrated circuit，ASIC)，或一个或多个用于控制本发明方案程序执行的集成电路。还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

处理器1可包括主处理器，在一个示例中，还可包括显卡、基带芯片、调制解调器等。

存储器2中保存有执行本发明技术方案的程序或脚本，还可以保存有操作系统和其他关键业务。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。脚本则通常以文本(如ASCII)保存，只在被调用时进行解释或编译。

更具体的，存储器2可以包括只读存储器(read-only memory，ROM)、可存储静态信息和指令的其他类型的静态存储设备、随机存取存储器(random access memory，RAM)、可存储信息和指令的其他类型的动态存储设备、磁盘存储器、flash等等。

输入设备4可包括接收用户输入的数据和信息的装置，例如键盘、鼠标、摄像头、扫描仪、光笔、语音输入装置、触摸屏、计步器或重力感应器等。

输出设备5可包括允许输出信息给用户的装置，例如显示屏、打印机、扬声器等。

通信接口3可包括使用任何收发器一类的装置，以便与其他设备或通信网络通信，如以太网，无线接入网(RAN)，无线局域网(WLAN)等。

处理器1执行存储器2中所存放的程序，以及调用其他设备，可用于实现下述图4-8，10所示实施例提供的游戏自动化测试方法。

此外，上述服务器或测试终端也可采用图1所示的通用计算机系统结构。

下面将基于上面所述的本发明涉及的共性方面，对本发明实施例进一步详细说明。

本发明的技术方案的实施基于录制过程中生成的不同于现有录制记录的录制记录。为便于理解，先介绍录制过程。

图4示出了上述录制过程的一种示例性流程。图4所示的方法应用于上述图1a或图1b提及的应用场景中，在硬件上，由图4所示的服务器与测试终端交互完成。

请参见图4，录制过程示例性得可包括：

在401部分：参考终端确定发生的每一第一操作事件，以及与之关联的操作对象、场景信息及操作序列号；

参考终端为录制过程中测试者使用的终端，一般为某种型号的手机。参考终端中也安装了测试游戏。在一个示例中，可由该测试游戏中的WeTestSDK来确定第一操作事件及与之关联的操作对象、场景信息及操作序列号。

需说明的是，在后续的回放过程中，也会出现操作事件，为了区分，将录制过程中出现的操作事件称为第一操作事件。

与第一操作事件相关联的操作对象是指，第一操作事件所操作的响应类UI控件的标识(简称为UI控件标识)。UI控件标识具体可为上述响应类UI控件对应的GameObject的路径。

举例来讲，假定测试者点击了图3中的“与QQ好友玩”按钮，而“与QQ好友玩”按钮对应的路径是：

"/BootObj/CUIManager/Form_Login/LoginContainer/pnlMobileLogin/btnGroup/btnQQ"。则可使用上述路径作为UI控件标识。

需要指出的是，第一操作事件可能有相应的操作对象。举例来讲，测试者点击一块石头的UI控件，该UI控件并不会响应点击操作，则石头对应的UI控件标识不能作为操作对象。在诸如此类的情况下，第一操作事件并不对应操作对象。

场景信息用于表征游戏当前场景，场景信息是unity里特有的。更具体的，场景信息可包括unity当前游戏界面归属的scene名称。举例来讲，当前游戏界面为登录界面，则其归属的scene名称为login。

操作序列号则用于表征某一第一操作事件在录制过程中的执行顺序。例如，第一个第一操作事件的操作序列号为1，第二个第一操作事件的操作序列号为2，第三个第一操作事件的操作序列号为3等等，以此类推，不作赘述。

需要说明的是，在PC机上，人可通过鼠标、键盘等输入设备进行点击、长按或滑动等操作，当然若PC机上的屏幕为触摸屏，也可通过触摸屏进行点击、长按或滑动等操作。

而在移动设备(智能终端)上，人一般通过触摸屏进行点击、长按或滑动等操作。

上述点击、长按或滑动等操作方式或操作类型，会对应有操作位置(显示屏坐标系下的坐标)。

例如，测试者点击了某一UI控件，点击位置为(x＝300y＝400)。则相应的第一操作事件可表示为Click：x＝300y＝400。

实际中，测试者的一个操作与下一操作之间是有停顿的。为了在回放过程中可以模拟测试者的真实操作，则需要记录某一操作事件与下一操作事件之间的时间间隔(以sleep表示)。

因此，第一操作事件具体可包括第一操作方式、在参考终端的显示屏坐标系下的第一操作位置，以及与下一第一操作事件的时间间隔；其中，第一操作方式可包括点击(click)、长按(press)、滑动(swipe)；第一操作位置指在参考终端的显示屏坐标系下的操作位置。本文后续还会对第一操作事件进行具体的介绍。

在402部分：参考终端根据上述第一操作事件以及与之关联的操作对象、场景信息及操作序列号生成一条录制记录，并保存至录制文件。

在一个示例中，可由测试游戏中的WeTest SDK生成录制记录，发送给录制工具，录制工具将其保存至录制文件。

在另一个示例中，也可由测试游戏中的WeTest SDK在生成录制记录后，保存至本地的录制文件。最后录制结束时，将本地保存的录制文件输出给录制工具。

其中，每一条录制记录可包括：第一操作事件、与之相关联的操作对象、场景信息和操作序列号。

在一个示例中，录制记录的格式可如下表1所示：

Scene

Index

Element

Action

表1

其中，Scene表示场景信息(场景名称)；Index表示操作序列号；Element表示操作对象(UI控件标识)，Element可能为空；Actions表示第一操作事件。

或者，在另一个示例中，录制记录的格式可如下所示：

(第一条录制记录)Login,1,/Root/Login/QQButton,(Click x＝300y＝400sleep＝3秒)；

(第二条录制记录)GameStart,2,/Root/Game/Attack,(Press x＝300y＝400press＝2秒，sleep＝1秒)；

(第三条录制记录)GameStart,3,/Root/Game/Attack,/Root/Game/Attack，(Swipe start_x＝300start_y＝400move＝[(250,220)]end_x＝150end_y＝50duration＝2秒，sleep＝1秒)；

在第一条录制记录中，login是场景名称(即场景信息)，后面的1是操作序列号，“/Root/Login/QQButton”是UI控件的标识(以路径作为标识)，而(Click x＝300y＝400sleep＝3秒)表示第一操作事件。

其中，click表示第一操作方式，“x＝300y＝400”表示第一操作位置，而sleep＝3秒表示本操作事件与下一操作事件之间的时间间隔为3秒。

在第二条录制记录的第一操作事件中，第一操作方式则包括了Press以及press＝2秒，其中的“press”表示操作类型为长按，press＝2秒表示长按的持续时长为2秒；

而在第三条录制记录的第一操作事件中，第一操作方式包括了Swipe以及duration＝2秒，其中，“Swipe”表示操作类型为滑动，duration＝2秒表示滑动的持续时长为2秒；而第一操作位置则包括“start_x＝300start_y＝400move＝[(250,220)]end_x＝150end_y＝50”。

需要说明的是，在滑动过程中，测试者会将手指放在屏幕上，然后手指在屏幕上滑动一段时间(距离)后抬起手指。在此过程中，会产生begin输入事件(对应手指放在屏幕上)，up输入事件(对应手指抬起)，在begin输入事件与up输入事件之间，还会产生move输入事件。在本申请中，是将begin、up和move三类输入事件合并为一个(第一)操作事件。

在第三条录制记录中的“start_x＝300start_y＝400”对应的是手指放在屏幕上时在参考终端的显示屏坐标系下的位置，“end_x＝150end_y＝50”对应的是手指抬起时在参考终端的显示屏坐标系下的位置，move＝[(250,220)]表示move输入事件在参考终端的显示屏坐标系下的位置。

还需要说明的是，第三条录制记录中包括两个UI控件的标识，上述两个UI控件的标识可能相同，也可能不同。其中，第一个UI控件的标识与“start_x＝300start_y＝400”相关联，表征的是手指放在屏幕上时所操作的响应类UI控件，第二个UI控件的标识与“end_x＝150end_y＝50”相关联，表征的是手指抬起时所操作的响应类UI控件。

此外，录制记录中还可包括回放次数。用于表征该条录制记录在回放过程中被回放的次数。

需要指出的是，在现有的录制记录中，仅包括了操作序列号和操作位置。这就决定了，现有的回放方式仅可严格按时间顺序依次执行录制记录。

而在本实施例中，录制记录中还包括了操作对象、场景信息，操作对象和场景信息在后续的回放过程中，起到了重要的作用。本文后续将进行介绍。

下面，将更详细得介绍如何生成录制文件。

图5示出了上述录制过程的另一种示例性流程，可包括：

在500部分：测试者启动测试游戏开启录制工具。

例如，测试者点开游戏的APP，然后开启录制工具。

理论上讲，可在任意时间点开启录制工具进行录制，但为了完整得测试游戏，一般会选择在开启测试游戏之后就开启录制工具。

在501部分：录制工具或WeTest SDK判断录制是否结束，若是，进入509部分，否则进入502部分。

当游戏结束，或测试者手动结束录制(例如点击了录制工具的结束按钮)时，都可导致录制结束。

无论哪种情况，都会造成WeTest SDK与录制工具之间断开通讯，因此，录制工具或WeTest SDK可通过判断是否与对方断开通讯，来判断录制是否结束。

在502部分：WeTest SDK等待用户操作游戏(监听)。

在503部分：WeTest SDK获取测试者触摸上述参考终端的显示屏而产生的输入事件，判断输入事件的类型(阶段)。若上述输入事件为begin输入事件，进入504部分，若输入事件的类型为up或move输入事件，进入505部分；

输入事件类型可为begin、move、up。也即，某一输入事件具体可为begin输入事件、move输入事件或up输入事件。

以点击操作为例，测试者会将手指放在屏幕上进行短暂的按压，然后抬起手指。在此过程中，会产生begin输入事件(对应手指放在屏幕上)，up输入事件(对应手指抬起)。在begin输入事件与up输入事件之间，还可能产生move输入事件。

尤其在滑动操作过程中，测试者在将手指放在屏幕上后，还会在屏幕上滑动一段距离再抬起手指。因此，在滑动操作对应的begin输入事件与up输入事件之间，会有多个move输入事件。

在504部分：WeTest SDK查找begin输入事件对应的当前操作UI控件(响应类UI控件)的标识；

那么，如何确认begin输入事件对应的UI控件是否为响应类控件呢？

请参见图6，对于NGUI开发的控件，WeTest SDK可通过反射调用UICamera.Raycast方法，获取当前坐标下对应的GameObject。如果查找到的GameObject中包含有UIButton、UIToggle、UIInput、UIEventListenser等组件，则表示该GameObject对应的UI控件为响应类控件或当前操作控件，该GameObject的路径将作为该begin输入事件对应的当前操作UI控件的标识；而如果不包括上述组件，则表示该GameObject对应的UI控件为非响应类控件，后续也不会将该GameObject的路径作为该begin输入事件对应的当前操作UI控件的标识。

对于UGUI开发的控件，WeTest SDK可通过EventSystem.current.RaycastAll()方法，获取当前坐标下的所有GameObject。如果RaycastAll返回多个GameObject，则查找第一个GameObject及其父节点中是否包含有IEventSystemHandler组件，如果是，表示该GameObject对应的UI控件为响应类控件或当前操作控件。否则，表示该GameObject对应的UI控件为非响应类控件，后续也不会将该GameObject的路径作为录制记录的UI控件标识。

此外，也可采用类似的方式来查找up输入事件对应的当前操作UI控件(响应类UI控件)的标识，在此不作赘述。

在505部分：WeTest SDK记录该输入事件。

输入事件可包括发生时刻、显示屏坐标和类型。

在506部分：若输入事件为up输入事件，WeTest SDK将该up输入事件、该up输入事件之前的begin输入事件，以及二者之间的move输入事件，合并为一个第一操作事件。

需要说明的是，在现有方式中，是直接记录了输入事件对应的录制记录，并未对输入事件进行合并。而在本实施例中，则对输入事件进行合并，这样可减少WeTest SDK与录制工具之间的传输流量。

更具体的，可将begin输入事件、up输入事件，以及二者之间的move输入事件，合并为click、press或swipe操作事件。如何合并将在后续说明。

在507部分：WeTest SDK获取与第一操作事件相关联的场景信息及操作序列号。

场景信息及操作序列号相关内容请参见前述的401部分的介绍，在此不作赘述。

在508部分：WeTest SDK根据上述第一操作事件以及与之关联的操作对象、场景信息及操作序列号生成一条录制记录，并发送至录制工具。

相关内容请参见前述的402部分，在此不作赘述。

录制工具会将接收到的录制记录保存至录制文件。

此外，录制工具或WeTest SDK还会根据与第i个第一操作事件相关联的begin输入事件的发生时刻，以及与第i-1个第一操作事件相关联的up输入事件的发生时刻，计算得到第i-1个第一操作事件的时间间隔(sleep)。

举例来讲，假定与第0个第一操作事件关联的up输入事件的发生时刻为12:00，而与第1个第一操作事件相关联的begin输入事件的发生时刻12:05，则第0个操作事件的sleep＝5秒。

在509部分：录制结束。

下面将介绍将输入事件合并为第一操作事件的具体方式。请考虑以下三种情况：

情况一(第一条件)：up输入事件与之前(请注意指的是发生时刻位于up输入事件之前)的begin输入事件间的时间差小于预设时长，同时，二者距离小于预设距离。

在此情况下，将begin输入事件、up输入事件，以及二者间的move输入事件，合并成操作方式为点击(click)的第一操作事件。

在一个示例中，预设时长可取200ms，预设距离可取50pix(像素)。

举例来讲，若begin输入事件与up输入事件的时间差在200ms以内，且begin输入事件的坐标与up输入事件的坐标的距离在50pix以内，则将该begin输入事件、up输入事件，以及二者间的move输入事件，合并为一个click事件。

或者，也可在begin输入事件与up输入事件的时间差在200ms以内，并且up输入事件、begin输入事件以及中间的move输入事件，两两间距均小于预设距离时，将begin输入事件、up输入事件，以及中间的move输入事件，合并成操作方式为点击(click)的第一操作事件。

情况二(第二条件)：up输入事件与之前的begin输入事件间的时间差大于上述预设时长，同时，二者距离小于上述预设距离。

或者，也可在up输入事件与之前的begin输入事件间的时间差大于预设时长，并且，up输入事件、begin输入事件以及中间的move输入事件，两两间距均小于预设距离时，将begin输入事件、up输入事件，以及中间的move输入事件，合并成操作方式为一个press事件。

其他情况下，将begin输入事件、up输入事件，以及二者间的move输入事件，合并成操作方式为滑动的第一操作事件。

举例来讲，若begin输入事件与up输入事件的时间差大于200ms，begin输入事件与up输入事件的坐标间的距离也大于50pix则将该begin输入事件、up输入事件，以及二者间的move输入事件，合并为一个swipe事件。

此外，在一个示例中，还可对begin输入事件与up输入事件之间的move输入事件进行采样，即抽取部分move输入事件，以减少move输入事件的数量；然后，将begin输入事件、up输入事件，以及抽取的部分move输入事件，合并为一个swipe事件。

举例来讲，假定在begin输入事件与up输入事件之间有100个move输入事件，可抽取其中的20个move输入事件，将这20个move输入事件与begin输入事件和up输入事件合并为一个swipe事件。

对move输入事件采样，可进一步减少WeTest SDK与录制工具之间的传输流量。

在介绍完录制过程后，本文后续将介绍回放过程。

图7示出了上述录制过程的另一种示例性流程。图7所示的方法应用于上述图1a或图1b提及的应用场景中，在硬件上，由图7所示的服务器与测试终端交互完成。

在700部分：服务器在测试终端上安装、启动测试游戏；

在一个示例中，可由服务器的回放工具(python脚本实现)自动在测试终端上安装、启动测试游戏。

在701部分：服务器获取录制文件。

在一个示例中，可由服务器的回放工具获取录制文件。

上述录制文件包括多条录制记录。录制记录的相应描述可参见前述402部分的介绍，在此不作赘述。

在702部分：服务器判断是否满足回放结束条件，若否，进入703部分以执行一次回放操作，若是，进入回放结束步骤。

在一个示例中，可由服务器上的回放工具执行702部分。

回放结束条件可包括游戏退出，或者，回放到最后一条录制记录，或者，回放率达到阀值(例如80％)。后续将介绍如何计算回放率。

其中，游戏退出与否，可通过判断与WeTest SDK之间的通讯是否中断来实现。

在703部分：服务器获取测试终端的当前游戏场景信息和当前UI控件列表。

当前场景信息可为unity当前游戏界面归属的scene名称。举例来讲，当前游戏界面为登录界面，则其归属的scene名称为login。

当前UI控件列表包括与当前游戏界面相关联的所有UI控件标识。更具体的，当前UI控件列表包括的是与当前游戏界面相关联的所有响应类UI控件的标识。

举例来讲，当前游戏界面关联了石头的控件，但该控件并不响应点击、长按、滑动等操作，则石头的控件标识不会出现在当前UI控件列表中。

在一个示例中，服务器中的回放工具可向游戏中的WeTest SDK发送当前UI控件列表请求消息，WeTest SDK则将查找出的、与当前游戏界面关联的所有响应类UI控件的标识反馈给回放工具。

在704部分：服务器根据上述当前游戏场景信息、当前UI控件列表，以及上一次所采用的录制记录中的操作序列号，在录制文件中查找匹配的录制记录，如查找出匹配的录制记录，进入705部分，否则，进入706部分。

在一个示例中，可在录制文件中查找与上述当前游戏场景信息、当前UI控件列表以及上一次回放操作所采用的录制记录中的操作序列号均匹配的录制记录作为匹配的录制记录；

当前游戏场景信息、当前UI控件列表和操作序列号相关描述请参见前述记载，在此不作赘述。

举例来讲，假定当前场景名称为01，UI控件列表包括UI控件A-E，上一次采用的录制记录的操作序列号为005；

而在录制文件中，在场景名称01下有五条录制记录，示例性得为：

场景名称01，UI标识A，第一操作事件(click)，操作序列号006；

场景名称01，UI标识A，第一操作事件(press)，操作序列号010；

场景名称01，UI标识B，第一操作事件(press)，操作序列号100；

场景名称01，UI标识B，第一操作事件(swipe)，操作序列号101；

场景名称01，UI标识F，第一操作事件(swipe)，操作序列号120。

则操作序列号006的录制记录与当前游戏场景信息、当前UI控件列表以及上一次回放操作所采用的录制记录中的操作序列号(006紧邻005，在执行时序上是衔接的)均匹配，则006对应的录制记录(最优匹配录制记录)即为匹配的录制记录。

若未查找出与上述当前游戏场景信息、当前UI控件列表以及上一次回放操作所采用的录制记录中的操作序列号均匹配的录制记录时，可将与当前游戏场景信息和当前UI控件列表相匹配的录制记录(次优匹配录制记录)作为匹配的录制记录。

可见，在本申请中，在没有最优匹配录制记录情况下，可使用相对接近的次优匹配录制记录继续进行回放，回放过程更加健壮。

而若既未查找到与上述当前游戏场景信息、当前UI控件列表以及上一次回放操作所采用的录制记录中的操作序列号均匹配的录制记录，也未查找到与当前游戏场景信息和当前UI控件列表相匹配的录制记录，则确定未查找到出匹配的录制记录。

在705部分：服务器在上述测试终端上回放上述目标录制记录(即查找出的匹配的录制记录)。

除回放目标录制记录外，服务器中的游戏自动化测试装置/模块还可执行性能数据采集、终端日志采集、crash检测等。在本发明其他实施例中，还可记录目标录制记录的回放次数。

需要说明的是，705部分需要服务器中的回放工具与WeTest SDK之间交互才能实现。

可将目标录制记录中的第一操作事件称为目标第一操作事件，将目标录制记录中的UI控件标识所表征的控件称为目标UI控件。

在一个示例中时，服务器中的回放工具可根据上述目标第一操作事件，确定针对目标UI控件的第二操作事件，并通知测试终端(中的WeTest SDK)执行确定出的第二操作事件(可将指示测试终端执行第二操作事件的通知称为第一通知)。

第二操作事件包括第二操作方式，在测试终端的显示屏坐标系下的第二操作位置，以及，预设等待时长。本文后续将进行详细介绍如何根据目标第一操作事件，确定针对目标UI控件的第二操作事件。

需要强调的是，在本实施例中，是根据当前游戏场景信息、当前UI控件列表以及操作序列号来查找匹配的录制记录。

举例来讲，假定在录制过程中，弹出一个广告P，测试人员点击关闭了广告P，则录制文件中将存在关闭广告P对应的录制记录。可假设关闭广告P对应的录制记录包括第一操作事件A，与之关联的UI控件B、场景信息C和操作序列号12。

而在回放过程中，在测试终端上回放操作序列号为11的录制记录后，广告P并未弹出，假设当前游戏场景信息为场景信息C1、当前UI控件列表包括UI控件B1，B2，B3。则根据本申请提供的方案，操作序列号12对应的录制记录(包括UI控件B、场景信息C)与当前游戏场景信息和当前UI控件列表不匹配，不会被作为目标录制记录进行回放。

在706部分：根据上述当前UI控件列表确定出随机操作事件，并通知测试终端执行上述随机操作事件。

可将指示测试终端执行随机操作事件的通知称为第二通知。

在一个示例中，随机操作事件可实现：在当前UI控件列表不为空时，从当前UI控件列表中随机选择一个UI控件进行点击。在当前UI列表为空时，在测试终端的屏幕上随机点击。

更具体的，与第一操作事件相类似，上述随机操作事件可包括第三操作方式，在测试终端的显示屏坐标系下的第三操作位置，以及，默认等待时长(可为零，或者1秒等)。

其中，第三操作方式可为点击、长按和滑动。

默认等待时长可为零秒、1秒等，本领域技术人员可根据实际需要进行灵活设计，在此不作赘述。

至于第三操作位置，具体可通过如下方式确定：

在上述当前UI控件列表不为空时，从上述当前UI控件列表中随机选择一个UI控件标识；可将随机选择出的UI控件标识所表征的UI控件称为随机UI控件；

确定该随机UI控件在所述测试终端的显示屏坐标系下的当前顶点位置以及覆盖区域；

根据该随机UI控件的覆盖区域和当前顶点位置，确定第三操作位置；

或者，

在上述当前UI控件列表为空时，在所述测试终端的显示屏坐标系下随机选择一个坐标作为第三操作位置。

706部分可解决现有回放方式存在的另一问题：在录制过程中未出现的界面在回放过程中出现了。这同样可导致现有自动化测试过程的操作错乱。

例如在录制过程中并未弹出广告界面，但在回放过程中弹出了广告界面，如严格按照时间顺序执行录制记录，那么后续操作将可能完全错乱。

而在本申请实施例中，可在当前UI控件列表不为空时，从当前UI控件列表中随机选择一个UI控件进行点击。或者，在当前UI列表为空时，在测试终端的屏幕上随机点击。在一次或多次随机点击操作后，广告界面可能会被关闭。被关闭后，可根据广告界面关闭后的当前游戏场景信息、当前UI控件列表，以及上一次所采用的录制记录中的操作序列号，在录制文件中查找匹配的录制记录作为目标录制记录进行回放，而不会发生错乱。

在本发明其他实施例中，仍请参见图7，在705部分或706部分之后，还可包括：

707部分：服务器生成本次回放操作对应的回放记录保存至回放报告。

在其他实施例中，也可由WeTest SDK生成回放记录，并返回服务器，由服务器将回放记录保存至回放报告。

回放记录与前述录制记录的格式相类似。

在一个示例中，若查找到匹配的录制记录，那么回放该匹配的录制记录后对应的回放记录可包括第二操作事件，与第二操作事件关联的操作对象、场景信息、回放序列号等。回放序列号用于表征第二操作事件(或本次回放操作)在回放过程中的执行顺序。

在若未查找到匹配的录制记录，而是执行的随机操作事件，则相应的回放记录可包括随机操作事件，与随机操作事件相关联的操作对象、场景信息、截图，以及，表征该随机操作事件在回放过程中的执行顺序的回放序列号。

本文后续还将对回放记录进行介绍。

在708部分：服务器根据所有回放记录统计得到的回放率。

需要说明的是，回放率是每进行一次回放操作就计算一次。因为在下一次回放操作之前，还需要根据回放率来判断是否满足回放结束条件。

回放率可通过下述方式计算：匹配的录制记录的条数/最大的回放序列号(回放操作执行次数)。

举例来讲，假定回放报告中最大回放序列号为4，也即进行了四次回放操作，其中，执行了一次随机操作事件，匹配的录制记录的条数为3，则回放率为75％。

此外，还可统计随机操作事件的数量。

回放率和随机操作事件的数量可属于回放报告的一部分，因此，707部分和708部分的操作，都可视为对回放报告的更新。

下面，将介绍如何在上述测试终端上回放目标录制记录的具体方式。

图8示出了回放目标录制记录的一种示例性流程。图8所示的方法应用于上述图1a或图1b提及的应用场景中，在硬件上，由图8所示的服务器与测试终端交互完成。

上述回放目标录制记录的示例性流程包括：

在800部分：服务器向测试终端发送位置查询请求，位置查询请求中携带了目标UI控件标识(也即目标UI控件对应的GameObeject节点的路径)。

在801部分：测试终端(WeTest SDK)获取并返回目标UI控件标识的实时位置信息。

上述实时位置信息可包括目标UI控件在测试终端的显示屏坐标系下的当前顶点位置，以及，目标UI控件在测试终端的显示屏上的覆盖区域。

在一个示例中，上述当前顶点位置具体可为目标UI控件的左上角坐标或右下角坐标，而覆盖区域具体为目标UI控件的长和宽。

需要说明的是，虽然UI控件在前台可被渲染成各种形状，例如圆形、椭圆等。但在后台，UI控件的形状均为矩形。所以每一UI控件均有左上角。而对于一个矩形的目标UI控件来说，在知道其左上角坐标及覆盖区域的情况下，可唯一的确定目标UI控件实时、真正的位置所在。

当前顶点位置和UI控件在终端显示屏上的覆盖区域可由WeTest SDK计算得到。

此外，前述提及的随机UI控件，其在所述测试终端的显示屏坐标系下的当前顶点位置以及覆盖区域，也可通过类似801部分的操作而确定。

在802部分：服务器根据上述覆盖区域、当前顶点位置确定第二操作事件的第二操作位置。

以人进行点击或长按为例，人一般是会点击或长按UI控件的中心部位。对于滑动UI控件也是如此。而在801部分获取到的是UI控件左上角的坐标，因此，需要计算第二操作位置。

此外，前述提及的根据随机UI控件的覆盖区域和当前顶点位置确定第三操作位置，也可采用类似802部分的操作而实现。

需要说明的是，在目标录制记录中的操作对象不为空时，可采用800-802来确定第二操作事件的第二操作位置。在此过程中，不需要使用目标录制记录中的第一操作位置。

而若目标录制记录中的操作对象为空时(想象一下用户点击了石头控件)，则可根据参考终端和测试终端的屏幕分辨率，将目标第一操作事件对应的第一操作位置转换为第二操作位置。

在803部分：服务器将目标第一操作事件的第一操作方式作为上述第二操作方式，将上述目标第一操作事件的时间间隔作为上述预设等待时长T。

举例来讲，假定目标录制记录包括：Login,1,/Root/Login/QQButton,(Click x＝300y＝400sleep＝3秒)。

其中，目标录制记录中的目标UI控件为“/Root/Login/QQButton”，不为空。假定根据目标UI控件的覆盖区域和当前顶点位置，确定出第二操作位置为x＝500y＝400，则第二操作事件为：Click x＝500y＝400T＝3秒。

后续WeTest SDK将在测试终端显示屏的x＝500y＝400位置上进行点击。

在804部分：对测试终端的当前游戏界面进行截图，并在截图上标记第二操作位置(例如在截图上标记红点)。

后续生成的回放记录中将包含上述截图。这样，通过重播截图序列，可对应查看录制记录的执行过程。

在805部分：服务器通知测试终端采用803部分得到的第二操作方式对第二操作位置进行操作(通知第二操作事件)，以实现对目标UI控件采用上述第二操作方式进行操作。

请同时参见图1a和图1b，在一个示例中，可由服务器通过ADB向游戏中的WeTestSDK发送通知。则终端根据通知，执行上述第二操作事件，以实现对与第二操作位置对应的UI控件、采用第二操作方式进行操作。

仍沿用前例，假定第二操作事件为：Click x＝500y＝400T＝3秒。则WeTest SDK将在测试终端显示屏的x＝500y＝400位置上进行点击。

在806部分：服务器等待上述预设等待时长T。

在807部分：服务器生成本次回放操作对应的回放记录，并更新回放报告。

回放报告的示例性格式请参见图9。在图9中，非匹配回放记录是对应随机操作事件的，图9中的片段是由操作序列号连续的录制记录所对应的回放记录构成的。

更新回放报告的其他相关描述请参见前述实施例707部分和708部分的记载，在此不作赘述。

下面将重点介绍如何从录制文件中查找匹配的录制记录。

图10示出了查找匹配的录制记录的一种示例性流程。图10所示的方法应用于上述图1a或图1b提及的应用场景中，在硬件上，由图10所示的服务器与测试终端交互完成。

上述示例性流程可包括：

在1000部分：服务器获取测试终端的当前界面对应的应用程序唯一标识，并判断上述应用程序唯一标识是否是测试游戏的唯一标识或与测试游戏相关联的应用程序的唯一标识；若是，进入1001部分，否则，启动上述测试游戏。

换种说法，可判断应用程序唯一标识是否表征了测试游戏或与测试游戏相关联的应用程序。

应用程序唯一标识为包名。在一个示例中，服务器中的回放工具可通过uiautomator或者其他工具确定手机当前界面的包名(应用程序唯一标识)，以确定进程。

在回放过程中，可能因各种原因，其他应用程序(即非测试游戏)的界面会成为当前界面，考虑下述两种情况：

情况一：与测试游戏相关联的应用程序的操作界面成为当前界面。举例来讲，如测试游戏可通过微信账号或QQ账号登录，微信应用程序或QQ应用程序就是与测试游戏相关联的应用程序。在尝试登录的过程，微信应用程序或QQ应用程序的操作界面可能成为当前界面；

情况二，与测试游戏无关联的应用程序(未知程序)的操作界面成为当前界面。在这种情况下，就要尝试启动测试游戏，否则可能无法完成回放。

在1001部分：服务器获取测试终端的当前游戏场景信息和当前UI控件列表。

1001部分与前述实施例的703部分相同，在此不作赘述。

1001部分未在图10中示出。

在1002部分：从上述录制文件中查找满足第一匹配条件的录制记录。若未查找到，进入1003部分，若查找到，进入1004部分。

其中，第一匹配条件包括场景信息与当前游戏场景信息相匹配。

例如，当前游戏场景的名称为login，则查找所有游戏场景信息为login的录制记录。

可将满足第一匹配条件的录制记录称为第一候选录制记录。

在1003部分：根据上述当前UI控件列表确定出随机操作事件，并通知测试终端执行上述随机操作事件。

1003部分与前述的706部分相同，在此不作赘述。

在1004部分：在上述第一候选录制记录中查找满足第二匹配条件的录制记录。若查找到，进入1005部分，否则，进入1006部分。

其中第二匹配条件可包括：操作序列号与上一次所采用的录制记录中的操作序列号相接续。

举例来讲，上一次所采用的录制记录中的操作序列号是3，而第一候选录制记录中有操作序列号为4的录制记录，则认为相接续。

可将满足第二匹配条件的录制记录称为第二候选录制记录，第二候选录制记录同时满足第一匹配条件和第二匹配条件。

在1005部分：在上述第二候选录制记录中查找满足第三匹配条件的录制记录；若查找到进入1006部分，否则进入1007部分。

上述第三匹配条件包括：UI控件标识与上述当前UI控件列表相匹配。

满足第三匹配条件的录制记录，亦同时满足第一匹配条件和第二匹配条件，是最优选录制记录。最优选录制记录将作为匹配的录制记录(即目标录制记录)，后续将在测试终端上回放该最优选录制记录。

举例来讲，假定当前场景名称为01，UI控件列表包括UI控件标识A-E，上一次回放操作对应的操作序列号为005；

而在录制文件中，与场景名称01匹配的录制记录有五条，分别：

场景名称01，UI标识A，第一操作事件click，操作序列号006；

场景名称01，UI标识A，第一操作事件press，操作序列号010；

场景名称01，UI标识B，第一操作事件press，操作序列号100；

场景名称01，UI标识B，第一操作事件swipe，操作序列号101；

场景名称01，UI标识F，第一操作事件swipe，操作序列号120。

则选择操作序列号006的录制记录。因为006紧邻005，在执行时序上是衔接的，并且UI标识A在当前UI控件列表中。

在1006部分：在上述第一候选录制记录中查找出满足第四匹配条件的录制记录，若查找到进入1007部分，否则进入1008部分。

上述第四匹配条件可包括：UI控件标识与所述当前UI控件列表相匹配。

场景名称01，UI标识A，第一操作事件click，操作序列号007，回放次数1；

场景名称01，UI标识A，第一操作事件press，操作序列号010，回放次数0；

场景名称01，UI标识B，第一操作事件press，操作序列号100，回放次数5；

场景名称01，UI标识B，第一操作事件swipe，操作序列号101，回放次数2；

场景名称01，UI标识F，第一操作事件swipe，操作序列号120，回放次数8。

则标下划线的录制记录均为满足第四匹配条件的第三录制记录。

在1007部分：从第三候选录制记录中选择回放次数最少或操作序列号最小的录制记录作为上述匹配的录制记录进入回放。

仍沿用前例，可选择“场景名称01，UI标识A，第一操作事件click，操作序列号007，回放次数1”的录制记录作为匹配的录制记录，也可选择“场景名称01，UI标识A，第一操作事件press，操作序列号010，回放次数0”的录制记录作为匹配的录制记录。

在1007部分选择出的录制记录可视为次优选录制记录。

在1008部分：根据上述当前UI控件列表确定出随机操作事件，并通知测试终端执行上述随机操作事件。

1008部分与前述的706部分相同，在此不作赘述。

图11示出了上述实施例中所涉及的游戏自动化测试装置或服务器的一种可能的结构示意图，包括：

获取模块1101，用于获取录制文件；

其中，上述录制文件包括多条录制记录，每一条录制记录包括：第一操作事件、与上述第一操作事件相关联的操作对象(UI控件标识)、场景信息和操作序列号；

回放模块1102，用于根据上述录制文件，执行至少一次回放操作；

其中，回放操作包括：

根据所述当前游戏场景信息、当前UI控件列表以及上一次回放操作所采用的录制记录中的操作序列号，在所述录制文件中查找匹配的录制记录；

如查找出匹配的录制记录，将所述匹配的录制记录作为目标录制记录；

在所述测试终端上回放所述目标录制记录。

在本发明其他实施例中，上述回放操作还可包括：如未查找出匹配的录制记录，根据上述当前UI控件列表确定出随机操作事件，并通知测试终端执行上述随机操作事件。随机操作事件可参见前述记载，在此不作赘述。

在本发明其他实施例中，仍请参见图11，上述游戏自动化测试装置或服务器还可包括：

录制模块1103，用于在录制过程中，确定每一第一操作事件，以及与之关联的操作对象、场景信息及操作序列号；

使用所述第一操作事件以及与之关联的操作对象、场景信息及操作序列号更新录制文件。

图12示出了上述实施例中所涉及的测试终端的一种可能的结构示意图，包括：

接收单元1201，用于接收来自服务器或游戏自动化测试装置的第一通知或第二通知；所述第一通知用于指示执行第二操作事件，所述第二通知用于指示执行随机操作事件；

执行单元1202，用于根据所述第一通知，执行所述第二操作事件，以实现在所述测试终端上回放目标录制记录；或者，

根据所述第二通知，执行所述随机操作事件。

具体细节请参见本文前述记载，在此不作赘述。

在本发明其他实施例中，仍请参见图12，上述测试终端还可包括：

录制单元1203，用于根据第一操作事件以及与之关联的操作对象、场景信息及操作序列号生成一条录制记录并发送给所述服务器或游戏自动化测试装置。

录制单元1203和执行单元1202的功能可由SDK实现。

其中，获取模块1101可用于执行图7所示的701部分。

回放模块1102可用于执行图7所示实施例的702-708部分、图8所示实施例的800，802-807部分、图10所示实施例的1000-1008部分。

录制模块1103(录制工具)可通过与测试终端中的录制单元1202(SDK)通讯，执行图4所示实施例的401-402部分，图5所示的实施例的500-509部分，以及，图6所示的实施例。

执行单元1202可用于执行图8所示实施例的801部分，及其他SDK执行的步骤。

接收单元1201可用于执行图8所示实施例的800部分和805部分。

本发明实施例还要求保护游戏自动化测试系统，其可包括上述所有实施例中的测试终端以及上述服务器，或包括上述所有实施例中的测试终端及游戏自动化测试装置。

结合本发明公开内容所描述的方法或者算法的步骤可以硬件的方式来实现，也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、移动硬盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。另外，该ASIC可以位于用户设备中。当然，处理器和存储介质也可以作为分立组件存在于用户设备中。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。

Claims

1.一种游戏自动化测试方法，其特征在于，包括：

根据所述录制文件，执行至少一次回放操作；其中：

所述回放操作包括：

获取测试终端的当前游戏场景信息和当前UI控件列表；所述当前UI控件列表包括与所述测试终端的当前游戏界面相关联的UI控件标识；

在所述测试终端上回放所述目标录制记录。

2.如权利要求1所述的方法，其特征在于，所述回放操作还包括：

在未查找出匹配的录制记录时，根据所述当前UI控件列表确定出随机操作事件；

通知所述测试终端执行所述随机操作事件。

3.如权利要求2所述的方法，其特征在于，所述根据所述当前游戏场景信息、当前UI控件列表以及上一次回放操作所采用的录制记录中的操作序列号，在所述录制文件中查找匹配的录制记录包括：

在所述录制文件中查找与所述当前游戏场景信息、当前UI控件列表以及上一次回放操作所采用的录制记录中的操作序列号均匹配的录制记录作为匹配的录制记录；

在未查找出与所述当前游戏场景信息、当前UI控件列表以及上一次回放操作所采用的录制记录中的操作序列号均匹配的录制记录时，将与所述当前游戏场景信息和当前UI控件列表相匹配的录制记录作为匹配的录制记录。

4.如权利要求3所述的方法，其特征在于，当存在多条与所述当前游戏场景信息和当前UI控件列表相匹配的录制记录时，所述将与所述当前游戏场景信息和当前UI控件列表相匹配的录制记录作为匹配的录制记录包括：

从与所述当前游戏场景信息和当前UI控件列表相匹配的录制记录中，选择回放次数最少或操作序列号最小的录制记录作为匹配的录制记录。

5.如权利要求2所述的方法，其特征在于，所述在所述测试终端上回放目标录制记录包括：

根据目标第一操作事件，确定针对目标UI控件的第二操作事件；其中，所述目标第一操作事件为所述目标录制记录中的第一操作事件；所述目标UI控件为所述目标录制记录中的UI控件标识所表征的控件；

通知所述测试终端执行所述第二操作事件。

6.如权利要求5所述的方法，其特征在于，

任一所述第一操作事件包括第一操作方式、在参考终端的显示屏坐标系下的第一操作位置，以及与下一第一操作事件的时间间隔；所述参考终端为在录制过程中使用的终端；

所述第二操作事件至少包括第二操作方式，在所述测试终端的显示屏坐标系下的第二操作位置，以及，预设等待时长。

7.如权利要求6所述的方法，其特征在于，所述根据所述目标录制记录中的第一操作事件，确定针对目标UI控件的第二操作事件包括：

确定所述目标UI控件在所述测试终端的显示屏坐标系下的当前顶点位置，以及，覆盖区域；

根据所述目标UI控件的覆盖区域、当前顶点位置，或者根据所述目标第一操作事件的第一操作位置，确定所述第二操作位置；

将所述目标第一操作事件的第一操作方式作为所述第二操作方式，将所述目标第一操作事件的时间间隔作为所述预设等待时长。

8.如权利要求7所述的方法，其特征在于，所述通知所述测试终端执行所述第二操作事件包括：

通知所述测试终端采用所述第二操作方式对所述第二操作位置进行操作，以实现对所述目标UI控件采用所述第二操作方式进行操作；

等待所述预设等待时长。

9.如权利要求7所述的方法，其特征在于，在通知所述测试终端执行所述第二操作事件之前，或者在通知所述测试终端执行所述随机操作事件之前，还包括：

对所述测试终端的当前游戏界面进行截图。

10.如权利要求9所述的方法，其特征在于，在所述测试终端上回放所述目标录制记录之后，还包括：

生成本次回放操作对应的回放记录；

所述回放记录包括所述目标第一操作事件的操作序列号，所述第二操作事件，与所述第二操作事件相关联的操作对象、场景信息、截图，以及，表征所述第二操作事件在回放过程中的执行顺序的回放序列号，或者，

所述回放记录包括所述随机操作事件，与所述随机操作事件相关联的操作对象、场景信息、截图，以及，表征所述随机操作事件在回放过程中的执行顺序的回放序列号。

11.如权利要求1所述的方法，其特征在于，还包括：记录所述目标录制记录的回放次数。

12.如权利要求1所述的方法，其特征在于，在获取所述录制文件之前，还包括：

在录制过程中，确定每一第一操作事件，以及与之相关联的操作对象、场景信息及操作序列号；

根据所述第一操作事件以及与之相关联的操作对象、场景信息及操作序列号生成一条录制记录，并保存至所述录制文件。

13.如权利要求12所述的方法，其特征在于，所述确定每一第一操作事件，以及与之相关联的操作对象、场景信息及操作序列号包括：

获取参考终端的显示屏产生的输入事件，所述输入事件为begin输入事件、move输入事件或up输入事件；

若所述输入事件为begin输入事件，查找所述begin输入事件对应的当前操作UI控件的标识作为所述操作对象；

若所述输入事件为up输入事件，将所述up输入事件、所述up输入事件之前的begin输入事件，以及二者之间的move输入事件，合并为一个第一操作事件；

获取与所述第一操作事件相关联的场景信息及操作序列号。

14.如权利要求13所述的方法，其特征在于，所述将所述up输入事件、所述up输入事件之前的begin输入事件，以及二者之间的move输入事件，合并为一个第一操作事件包括：

在满足第一条件时，将所述up输入事件、所述up输入事件之前的begin输入事件，以及二者之间的move输入事件合并为操作方式为点击的第一操作事件；

在满足第二条件时，将所述up输入事件、所述up输入事件之前的begin输入事件，以及二者之间的move输入事件合并为操作方式为长按的第一操作事件；

在同时不满足所述第一条件和所述第二条件时，将所述up输入事件、所述up输入事件之前的begin输入事件，以及二者之间的move输入事件合并为操作方式为滑动的第一操作事件；

其中：所述第一条件至少包括所述up输入事件与之前的begin输入事件间的时间差小于预设时长，同时，二者距离小于预设距离；所述第二条件至少包括所述up输入事件与之前的begin输入事件间的时间差大于所述预设时长，同时，二者距离小于所述预设距离。

15.如权利要求14所述的方法，其特征在于，所述将所述up输入事件、所述up输入事件之前的begin输入事件，以及二者之间的move输入事件合并为操作方式为滑动的第一操作事件包括：

从所述二者之间的move输入事件中抽取部分move输入事件，以减少move输入事件的数量；

将所述up输入事件、所述up输入事件之前的begin输入事件，以及抽取的部分move输入事件，合并为操作方式为滑动的第一操作事件。

16.一种游戏自动化测试装置，其特征在于，包括：

所述回放操作包括：

在所述测试终端上回放所述目标录制记录。

17.如权利要求16所述的游戏自动化测试装置，其特征在于，所述回放模块还用于:

在未查找出匹配的录制记录时，根据所述当前UI控件列表确定出随机操作事件，并通知所述测试终端执行所述随机操作事件。

18.如权利要求16所述的游戏自动化测试装置，其特征在于，在所述测试终端上回放目标录制记录方面，所述回放模块具体用于：

通知所述测试终端执行所述第二操作事件。

19.如权利要求18所述的游戏自动化测试装置，其特征在于，还包括：

录制模块，用于在录制过程中，确定每一第一操作事件，以及与之相关联的操作对象、场景信息及操作序列号；

20.一种游戏自动化测试方法，其特征在于，应用于测试终端，所述游戏自动化测试方法包括：

接收来自服务器或游戏自动化测试装置的第一通知或第二通知；所述第一通知用于指示执行第二操作事件，所述第二通知用于指示执行随机操作事件；

根据所述第一通知，执行所述第二操作事件，以实现在所述测试终端上回放目标录制记录；或者，

根据所述第二通知，执行所述随机操作事件；

其中，所述目标录制记录为，所述服务器或游戏自动化测试装置根据当前游戏场景信息、当前UI控件列表以及上一次所采用的录制记录中的操作序列号在录制文件中查找出的匹配的录制记录；

所述录制文件包括多条录制记录，每一条录制记录包括：第一操作事件、与所述第一操作事件相关联的操作对象、场景信息和操作序列号；

所述第二操作事件是根据所述目标录制记录中的第一操作事件确定的；

所述随机操作事件是在未查找出匹配的录制记录时确定出的。

21.如权利要求20所述的方法，其特征在于，在接收所述第一通知之前，还包括：

接收来自服务器或游戏自动化测试装置针对目标UI控件的位置查询请求；所述目标UI控件为所述目标录制记录中的UI控件标识所表征的控件；

确定并返回所述目标UI控件在所述测试终端的显示屏坐标系下的当前顶点位置及覆盖区域。

22.如权利要求21所述的方法，其特征在于，在接收来自服务器或游戏自动化测试装置针对目标UI控件的位置查询请求之前，还包括：

在录制过程中，确定每一第一操作事件，以及与之关联的操作对象、场景信息及操作序列号；

根据所述第一操作事件以及与之关联的操作对象、场景信息及操作序列号生成一条录制记录并发送给所述服务器或游戏自动化测试装置。

23.一种终端，其特征在于，包括：

接收单元，用于接收来自服务器或游戏自动化测试装置的第一通知或第二通知；所述第一通知用于指示执行第二操作事件，所述第二通知用于指示执行随机操作事件；

执行单元，用于根据所述第一通知，执行所述第二操作事件，以实现在所述测试终端上回放目标录制记录；或者，根据所述第二通知，执行所述随机操作事件；

其中，所述目标录制记录是：所述服务器或游戏自动化测试装置根据当前游戏场景信息、当前UI控件列表以及上一次所采用的录制记录中的操作序列号在录制文件中查找出的匹配的录制记录；所述录制文件包括多条录制记录，每一条录制记录包括：第一操作事件、与所述第一操作事件相关联的操作对象、场景信息和操作序列号；所述第二操作事件是根据所述目标录制记录中的第一操作事件确定的；所述随机操作事件是在未查找出匹配的录制记录时确定出的。

24.如权利要求23所述的终端，其特征在于，还包括录制单元，用于：

25.一种游戏测试系统，其特征在于，包括如权利要求16-19所述的游戏自动化测试装置以及，如权利要求23-24所述的测试终端。