CN111813686B - 一种游戏测试方法、装置、测试终端及存储介质 - Google Patents

Abstract

本申请实施例提供了一种游戏测试方法、装置、测试终端及存储介质，应用于测试终端，该方法包括：获取待测试游戏的测试用例；通过游戏引擎运行所述测试用例，并获取运行所述测试用例过程中产生的内存数据，所述内存数据用于渲染所述测试用例对应的游戏画面；根据所述内存数据和对应的预期数据确定所述测试用例的测试结果。采用本申请，可以使得游戏测试过程更易于实现，并且可以提升测试准确度。

Description

一种游戏测试方法、装置、测试终端及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种游戏测试方法、装置、测试终端及存储介质。

背景技术

目前针对游戏，如小游戏使用的测试方案多为用户界面(User Interface，UI)自动化测试方案，如使用用于Web应用程序测试的工具来实现的UI自动化测试方案。

其中，UI自动化测试通过解析控件树的方式来检索页面元素，然后加以点击、拖动、滑动等操作方式以达到人工操作的效果。在操作完成后，通过检查页面元素变化来校验结果是否符合预期，或者通过图像识别技术，将操作后的页面表现截图以与预期截图进行图像对比。图像对比一般通过像素点对比，尺度不变特征变换(Scale-invariant featuretransform，SIFT)、加速稳健特征(Speeded-Up Robust Features，SURF)等特征提取算法，结构相似性(Structural Similarity，SSIM)对比等来检测图像相似度。然而，上述方式在实际应用过程中，因页面元素较难获取或页面在不同分辨率设备难以兼容，导致该测试方式在实现上较为困难。并且，在较高帧率，如60帧每秒的游戏渲染过程中，因UI控件检索速度或图像获取速度的不足，难以获得精确的数据以用于测试分析，导致测试不够准确。

另外，测试通常会涉及PC浏览器端、iOS/Android客户端等多端运行，通过UI自动化方式进行测试时，需要同时维护多套自动化测试框架，技术成本大，多端兼容能力差。

发明内容

本申请实施例提供了一种游戏测试方法、装置、测试终端及存储介质，可以使得游戏测试过程更易实现，并有效地提升测试准确度。

第一方面，本申请实施例提供了一种游戏测试方法，应用于测试终端，所述方法包括：

获取待测试游戏的测试用例；

通过游戏引擎运行所述测试用例，并获取运行所述测试用例过程中产生的内存数据，所述内存数据用于渲染所述测试用例对应的游戏画面；

根据所述内存数据和对应的预期数据确定所述测试用例的测试结果。

第二方面，本申请实施例提供了一种游戏测试装置，应用于测试终端，所述装置包括：

获取模块，用于获取待测试游戏的测试用例；

处理模块，还用于通过游戏引擎运行所述测试用例，并通过所述获取模块获取运行所述测试用例过程中产生的内存数据，所述内存数据用于渲染所述测试用例对应的游戏画面；

所述处理模块，还用于根据所述内存数据和对应的预期数据确定所述测试用例的测试结果。

第三方面，本申请实施例提供了一种测试终端，包括输入设备和输出设备，还包括：

处理器，适于实现一条或一条以上指令；以及，

计算机存储介质，所述计算机存储介质存储有一条或一条以上指令，所述一条或一条以上指令适于由所述处理器加载并执行如第一方面所述的游戏测试方法。

第四方面，本申请实施例提供了一种计算机存储介质，所述计算机存储介质存储有一条或一条以上指令，所述一条或一条以上指令适于由处理器加载并执行如第一方面所述的游戏测试方法。

第五方面，本发明实施公开了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述第一方面所述的游戏测试方法。

综上所述，测试终端可以通过游戏引擎运行待测试游戏的测试用例，并获取运行该测试用例过程中产生的内存数据，该内存数据用于渲染该测试用例对应的游戏画面，从而根据该内存数据和对应的预期数据确定该测试用例的测试结果，相较于UI自动化测试，本申请采用上述过程进行游戏测试的过程更易于实现，并且采用内存级别的数据来确定测试结果的方式也提升了测试准确度。

附图说明

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

图1A为本申请实施例提供的一种测试用例执行效果示意图；

图1B为本申请实施例提供的另一种测试用例执行效果示意图；

图1C为本申请提供的一种包含测试结果的可视化界面的示意图；

图1D为本申请提供的另一种包含测试结果的可视化界面的示意图；

图2为本申请提供的一种游戏测试流程的示意图；

图3A为本申请实施例提供的另一种游戏测试流程的示意图；

图3B为本申请实施例提供的一种浏览器端与移动端之间的模块关系图；

图3C为本申请实施例提供的一种测试流程的示意图；

图3D为本申请实施例提供的一种游戏引擎的工作原理示意图；

图4A为本申请实施例提供的另一种测试流程的示意图；

图4B为本申请实施例提供的一种拖动积木模块的示意图；

图4C为本申请实施例提供的一种游戏制作工具的测试用例编写界面的示意图；

图4D为本申请实施例提供的一种测试用例调度及运行层次的结构示意图；

图4E为本申请实施例提供的一种测试用例运行流程示意图；

图4F为本申请实施例提供的一种测试用例精灵移动位置的积木模块执行示例图；

图4G为本申请实施例提供的一种游戏测试系统的系统架构示意图；

图5为本申请实施例提供的一种游戏测试装置的结构示意图；

图6为本申请实施例提供的一种测试终端的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

游戏可以包括基于客户端的小游戏等游戏。用户在客户端内点开某款小游戏，便可以玩这款小游戏，而无需执行下载安装操作。

游戏开发通常可以借由游戏制作工具来完成。例如，小游戏的开发可以借由小游戏制作工具完成。小游戏制作工具是一款可视化游戏编程工具。开发人员可以在小游戏制作工具内以拖拽积木的方式组织游戏逻辑，快速开发出可在客户端运行的小游戏，准入门槛较低。通常来说，游戏开发过程会涉及多端操作，即在PC浏览器端进行开发预览，在移动端，如iOS/Android客户端体验发布。

使用游戏制作工具开发的游戏在测试过程中，往往存在人员操作成本大、测试粒度不够精细、多端运行复杂等问题。目前业内普及的测试方法为UI自动化测试的方法，如对于iOS/Android客户端有基于Appium(一种自动化测试框架)的测试方法、基于UIAutomator(一种自动化测试框架)的测试方法、基于WDA(一种自动化测试框架)的测试方法。这些测试方法都是以检索页面元素加以驱动操作的自动化技术。然而，UI自动化测试在此类游戏项目存在实施难度大，测试准确度较低等技术问题。

为了解决现有技术的问题，本申请实施例提供了一套高效的游戏测试方案，该游戏测试方案可以应用于测试终端。此处的测试终端包括但不限于为移动终端(如智能手机)或个人计算机(Personal Computer，PC)等智能终端。在一个实施例，该测试终端也可以为游戏服务器。该游戏测试方案具体为：获取待测试游戏的测试用例；通过游戏引擎运行测试用例，并获取运行测试用例过程中产生的内存数据；根据内存数据和对应的预期数据确定测试用例的测试结果。其中，所述的内存数据用于渲染测试用例对应的游戏画面。该游戏测试方案具备在此类游戏项目更易于实施，测试准确度高的优点。

此外，该游戏测试方案还具备以下优点：测试过程完全自动化运行，无人工介入，执行稳定耗时短，高效快捷；测试精细度高，通过校验运行测试用例过程中产生的内存数据，能发现帧级别、代码行级别问题，可以发现细致的逻辑问题，问题排查效率高，并且在预期侧做了像素级别的预期，能发现图像对比或者人工测试无法发现的细致问题，如浮点计算精度问题；具备多端运行能力，能充分模拟用户使用场景，涵盖浏览器端和移动端，不需要像UI自动化测试那样因不能兼容多端需同时维护多套自动化测试框架。

在一个测试场景中，假设测试终端为PC，待测试游戏为小游戏A，小游戏A的测试用例1和测试用例2可以在指定测试框架启动的浏览器上执行。待测试游戏的测试用例包括测试用例1和测试用例2。参见图1A所示的浏览器端执行效果图。测试终端在执行前述的测试方案的过程中，可以得到运行测试用例1期间产生的用于渲染如图1A左图所示的游戏画面的内存数据，还可以得到运行测试用例2期间产生的用于渲染如图1A右图所示的游戏画面的内存数据。由图1A可以看出，测试用例切换页面表现为引擎渲染区域内容的变化。

再一个测试场景中，假设测试终端为移动端，待测试游戏为小游戏A，游戏A的测试用例3和测试用例4可以搭载在小游戏中执行。参见图1A所示的移动端端执行效果图。测试终端在执行前述提及的测试方案的过程中，可以得到运行测试用例3期间产生的用于渲染如图1B左图所示的游戏画面的内存数据，还可以得到运行测试用例4期间产生的用于渲染如图1B右图所示的游戏画面的内存数据。由图1B可以看出，测试用例的切换视觉表现为画面场景的不断切换。

在一个实施例中，测试终端在得到测试用例的测试结果后，可以向后台服务器，如测试服务器发送该测试用例的测试结果以及该测试终端的标识信息，以使得测试服务器通过可视化界面展示该测试用例在测试终端上的测试结果。例如参见图1C和如图1D所示的可视化界面，该可视化界面可以包括测试终端的标识信息以及测试结果，测试终端的标识信息可以包括测试终端的名称、型号等信息。该测试结果还可以包括以下至少一项：测试成功的测试用例的信息、测试失败的测试用例的信息、测试成功数、测试失败数、测试类型等等。在一个实施例中，该可视化界面还可以包括游戏引擎的信息，如测试分支的信息。可视化界面可以方便问题的定位。

基于上述描述，本申请实施例提供了一种游戏测试方法，下面将结合图2和图3A对本申请实施例提供的游戏测试方法进行阐述。

请参阅图2，为本申请实施例提供的一种游戏测试方法的流程示意图。该方法可以应用于前述提及的测试终端。该方法具体可以包括如下步骤：

S201、获取待测试游戏的测试用例。

本申请实施例中，测试终端可以从本地获取待测试游戏的测试用例，或可以接收测试服务器发送的待测试游戏的测试用例。所述的待测试游戏可以包括待测试的小游戏等游戏。

在一个实施例中，如果测试终端为PC，那么测试终端可以从本地获取待测试游戏的测试用例。或，如果测试终端为PC，那么测试终端可以在检测到测试任务定时达到时，从本地获取待测试游戏的测试用例。即，测试终端获取的该测试用例可以是测试终端在测试任务定时到达时从测试终端本地获取的。

在一个实施例中，如果测试终端为移动终端，那么测试终端可以接收测试服务器发送的待测试游戏的测试用例。或，如果测试终端为移动终端，测试服务器可以在测试任务定时到达时发送待测试游戏的测试用例至测试终端。测试终端可以接收测试服务器在测试任务定时到达时发送的待测游戏的测试用例。即，测试终端获取的该测试用例可以是由测试服务器在测试任务定时到达后获取的，如测试服务器从测试服务器本地获取的或从其它设备获取的。

在一个实施例中，考虑到在测试终端为移动终端的情况下，该测试终端可能不能有效解析该测试用例，因此测试服务器可以在测试任务定时到达时，对获取的测试用例进行转换，得到待测试游戏的测试用例，并发送待测试游戏的测试用例至测试终端。测试终端可以接收测试服务器在测试任务定时达到后发送的待测试游戏的测试用例。即，测试终端获取的该测试用例是由测试服务器在测试任务定时到达时，对获取的测试用例进行转换得到的。

S202、通过游戏引擎运行所述测试用例，并获取运行所述测试用例过程中产生的内存数据，所述内存数据用于渲染所述测试用例对应的游戏画面。

本申请实施例中，测试终端可以调度游戏引擎运行渲染该测试用例对应的游戏画面的逻辑，获取用于渲染该测试用例对应的游戏画面的内存数据。其中，所述的内存数据可以为所述测试用例对应的游戏画面的内存快照。该内存数据可以称为渲染内存数据或渲染层内存数据，本申请实施例不做限制。

S203、根据所述内存数据和对应的预期数据确定所述测试用例的测试结果。

本申请实施例中，测试终端可以将内存数据与对应的预期数据进行对比，得到对比结果，然后根据对比结果确定该测试用例的测试结果。

在一个实施例中，测试终端根据该内存数据和对应的预期数据确定该测试用例的测试结果的过程可以为测试终端获取该测试用例对应的每帧游戏画面的内存数据；测试终端根据该每帧游戏画面的内存数据和对应的预期数据确定该每帧游戏画面的测试结果，并根据该每帧游戏画面的测试结果确定该测试用例的测试结果。相应地，终端设备可以将每帧游戏画面的测试结果与对应的预期数据进行比对，得到每帧游戏画面对应的比对结果，根据比对结果确定该测试用例的测试结果。

在一个实施例中，假设测试用例对应的游戏画面包括第一游戏画面，第一游戏画面为测试用例对应的游戏画面中的任一游戏画面。测试终端在获取运行测试用例过程中产生的用于渲染第一游戏画面的内存数据后，可以判断该测试用例是否需要调度第二游戏画面，该第二游戏画面为第一游戏画面的下一帧游戏画面，如果需要调度第二游戏画面，则获取运行测试用例过程中产生的用于渲染第二游戏画面的内存数据。在一个实施例中，判断该测试用例是否需要调度第二游戏画面的过程可以为如果确定该第一游戏画面存在第二游戏画面，则确定需要调度第二游戏画面；或，如果确定该第一游戏画面存在第二游戏画面，且第二游戏画面与第一游戏画面的页面发生变换，则确定该测试用例需要调度第二游戏画面。

在一个实施例，如果待测试游戏的测试用例为多个，那么测试终端可以通过游戏引擎依次运行多个测试用例，并针对多个测试用例中的每个测试用例执行以下操作：获取运行该测试用例过程中产生的内存数据，该内存数据用于渲染该测试用例对应的游戏画面，根据内存数据和对应的预期数据确定该测试用例的测试结果。后续，测试终端可以将每个测试用例的测试结果上传至后台服务器，如测试服务器。或，测试终端可以统计用例执行情况数据，得到统计结果，该统计结果可以包括每个测试用例的测试结果；测试终端将统计结果上传至后台服务器。

可见，图2所示实施例中，测试终端可以获取待测试游戏的测试用例，并通过游戏引擎运行该测试用例，从而获取运行该测试用例过程中产生的内存数据，根据该内存数据和对应的预期数据确定该测试用例的测试结果，该游戏测试过程不仅易于实现，还能够提升测试准确度。

请参阅图3A，为本申请实施例提供的另一种游戏测试方法的流程示意图。该方法可以应用于前述提及的测试终端。该方法具体可以包括如下步骤：

S301、运行待测试游戏的测试配置文件，所述测试配置文件包括测试用例配置文件和游戏引擎配置文件，所述游戏引擎配置文件包括游戏引擎的核心引擎逻辑和渲染模块。

本申请实施例，测试终端可以打包核心引擎逻辑和渲染模块，并将其引入测试配置文件，从而屏蔽与测试对象无关的功能，达到简化测试对象的目的。

例如，参见图3B所示的浏览器端与移动端的模块关系，浏览器端包括核心引擎逻辑、渲染模块、积木拖拽模块、上传模块和素材管理模块等模块，移动端包括核心引擎逻辑、渲染模块、预览体验模块、人数限制模块、热更新模块等模块。浏览器端与移动端都包括的有核心引擎逻辑和渲染模块。

在一个实施例中，游戏引擎配置文件包括的游戏引擎的核心引擎逻辑可以是最新的核心引擎逻辑。

S302、根据所述测试配置文件调度所述待测试游戏的测试用例。

本申请实施例中，测试终端根据测试配置文件调度该待测试游戏的测试用例的过程可以为测试终端根据游戏引擎配置文件初始化该游戏引擎的渲染环境；测试终端根据该测试用例配置文件初始化该游戏引擎的游戏实例，并获取运行该待测试游戏的游戏实例所需的特征参数，该特征参数用于该游戏引擎运行该测试用例。其中，渲染环境是指游戏引擎执行渲染操作所需的环境。特征参数可以包括测试对象(如待测试的目标游戏精灵)的句柄以及游戏引擎的渲染器对象。

在一个实施例中，所述的测试用例可以是在获取所述待测试游戏的游戏配置文件后，对所述游戏配置文件进行预处理得到的，所述的游戏配置文件可以包括根据配置的游戏功能模块生成的游戏逻辑。构建测试用例的过程可以是在开发人员对应的设备或测试人员对应的设备上完成的。预处理的过程可以包括将测试对象(如待测试的目标游戏精灵)的标识ID替换指定ID。所述的目标精灵的句柄可以为该目标精灵的指定ID。所指的游戏功能模块可以包括积木模块。

S303、获取待测试游戏的测试用例。

S304、通过游戏引擎运行所述测试用例，并获取运行所述测试用例过程中产生的内存数据，所述内存数据用于渲染所述测试用例对应的游戏画面。

S305、根据所述内存数据和对应的预期数据确定所述测试用例的测试结果。

其中，步骤S303-S305可参见图2实施例中的步骤S201-S203，本申请实施例在此不做赘述。

在一个实施例中，步骤S303可以在步骤S301之前执行，本申请实施例不做限制。

在一个实施例中，服务器在通过游戏引擎运行待测试游戏的测试用例之前，可以检测该测试用例是否包括指定测试对象，如指定游戏精灵，如果包括，则为指定测试对象封装共用的操作方法，以减少后续执行用例逻辑时的一些重复的操作。

可见，图3A所示的实施例中，测试终端可以运行待测试游戏的测试配置文件，然后根据测试配置文件调度该待测试游戏的测试用例；测试终端通过游戏引擎运行测试用例，并获取运行期间产生的内存数据以用于测试分析，该过程通过打包核心引擎逻辑和渲染模块，简化了无关测试对象，能够提升测试效率。

结合图3C以及图3D来看，测试流程一般为根据配置的游戏功能模块(如积木模块)生成对应的游戏逻辑，得到游戏配置文件，根据游戏配置文件构建测试用例。之后，便可以生成中间配置数据文件，即本申请实施例所述的测试配置文件。随后，通过游戏引擎来解析配置执行渲染操作。游戏引擎解析配置并执行渲染操作的过程可以为游戏引擎解析配置并执行初始化相关操作；游戏引擎执行游戏逻辑，游戏引擎渲染游戏画面到测试终端的屏幕上。执行游戏逻辑主要是执行待测试游戏的业务代码，测试主要是测试执行结果是否符合预期，而渲染部分则是逻辑执行的结果表现，因此本申请实施例可以根据渲染的正确性判断逻辑执行的正确性。其中，本申请实施例的渲染过程可以通过标准接口工具，如第三方渲染库pixi.js实现。

参见图4A所示的测试用例的构造及运行过程，该测试用例的构造及运行过程可以分为六个阶段：数据准备、用例编写、用例调度、用例运行、环境清理和数据上报。下面将对这六个阶段进行的工作内容进行阐述。

在数据准备阶段，开发人员/测试人员可以在游戏制作工具中拖拽积木模块生成游戏逻辑，并导出游戏配置游戏配置文件，该游戏配置文件可为json文件，该游戏配置文件包括根据配置的积木模块生成的游戏逻辑。例如，参见图4B开发人员/测试人员可以在游戏制作工具中选择积木模块克隆，并将该积木模块下的克隆自己的积木模块拖动到相应区域以构建游戏逻辑。在导出游戏配置文件后，对游戏配置文件进行预处理。预处理的过程包括将待测试的目标精灵的标识ID替换为固定的ID。通过将目标精灵的ID调整为统一的值，可以方便后续运行测试用例时检索待测目标的一致性。在生成游戏逻辑的过程中，可以生成游戏逻辑副本，该游戏逻辑副本包括配置的积木模块的逻辑以及必要的运行逻辑。优选地，该游戏逻辑副本可以包括待测试的目标积木模块以及必要的运行逻辑，从而降低其它无关积木模块的干扰，以便于在运行测试用例的过程可以较为容易地定位问题。

在用例编写阶段，开发人员/测试人员可以按照积木模块组织测试用例。即，可以将游戏配置文件按照该游戏配置文件包括的积木模块的类型进行存放，以便于后续统一维护。在编写测试用例期间，可以根据该游戏配置文件编写测试用例。在编写测试用例的测试逻辑时，可以获取游戏引擎的实例化对象，以用于根据测试需求，动态控制游戏主循环调度，并在对应的游戏循环里获取内存数据以与预期比较。例如，积木模块为将精灵的位置移动到指定位置(x，y),测试用例可按照以下逻辑编写：

1、调用一次游戏循环；

2、获取精灵对应的内存数据，包括精灵移动后的位置(x’，y’)；

3、判断一次游戏循环后，精灵移动后的位置(x’，y’)是否为指定位置(x，y)。

在一个应用场景中，开发人员/测试人员可以在游戏制作工具上完成对测试用例的编写过程。例如，该游戏制作工具可以包括测试用例编写模块，参见图4C，开发人员/测试人员可以进入游戏制作工具的测试用例编写界面，并基于该界面编写待测试游戏的测试用例的逻辑，该逻辑可以指测试逻辑。

再一个应用场景中，开发人员/测试人员也可以通过其它工具来编写测试用例，本申请实施例对其不做限制。

在编写完成测试用例后，可以得到测试用例配置文件，并在测试配置文件中导入测试用例配置文件。该测试用例配置文件可为json文件，该测试用例配置文件包括测试用例配置数据。或，还可以得到测试用例文件，然后在测试配置文件中导入测试用例配置文件以及测试用例文件。该测试用例文件可为json文件，该测试用例文件可包括测试用例的逻辑。或，还可以将测试用例配置数据导入测试用例文件中，然后将测试用例文件导入测试配置文件。当测试用例为多个时，可以将每个测试用例对应的测试用例配置文件和/或测试用例文件批量引入测试配置文件中，以便于后续批量调度及运行。

其中，用例调度阶段以及用例运行的层次结构可以参见图4D。用例调度阶段可以分为测试配置文件运行前的阶段、待测试游戏所有测试用例运行前的阶段、每条测试用例运行前的阶段。下面将对用例调度阶段中的各阶段进行阐述。

在测试配置文件运行前的阶段，更新待测试游戏的业务代码到被测分支的最新版本，将游戏引擎的核心引擎逻辑和渲染模块打包为游戏引擎配置文件。或，获取最新的核心引擎逻辑，然后利用最新的核心引擎逻辑更新游戏引擎配置文件。该游戏引擎配置文件可为json文件。测试终端可以将游戏引擎配置文件引入测试配置文件中。该过程通过打包多端运行一致的核心引擎逻辑和渲染模块，可以确保一次编写的测试用例能够在多端兼容运行。

在所有测试用例运行前的阶段，可以对测试环境进行初始化。例如，可以通过以下方式初始化游戏引擎的渲染环境：在浏览器端拉起测试页面，然后将画布canvas挂到指定节点上，为渲染提供环境。在环境初始化完毕后，可以测试游戏主循环逻辑，遍历导入的测试用例。

在每条测试用例运行前的阶段，根据测试用例配置文件初始化游戏引擎的游戏实例。在一个实施例中，测试终端可以检测待测试游戏是否存在指定精灵，如果存在，则为指定精灵封装公用的方法，以便在后续执行相关测试用例时可以直接调用该封装的方法。

在测试用例运行时，获取运行测试用例所需的特征参数，该特征参数用于游戏引擎运行测试用例。例如，特征参数可以包括目标精灵的句柄，如指定ID，还可以包括游戏引擎的渲染器对象。

在用例运行阶段，可以控制游戏帧调度，在帧之间获取运行测试用例过程产生的内存数据，判断内存数据是否符合预期。具体可以根据内存数据以及预期数据来判断内存数据是否符合预期。参见图4E测试用例运行阶段可以包括调度游戏引擎运行渲染一帧游戏画面的逻辑，然后获取渲染内存数据，即获取用于渲染这帧游戏画面的内存数据，并将该内存数据与预期数据进行比对以判断内存数据是否符合预期。之后，可以判断是否需要调度下一帧游戏画面，如果需要，则执行调度游戏引擎运行渲染下一帧游戏画面的逻辑。

在测试用例运行阶段，渲染的结果反馈了这一帧游戏画面对应的游戏逻辑的执行结果。例如，存在积木模块为将如图4F所示的精灵从位置(x＝0，y＝0)移动到位置(x＝100，y＝100)，在调度一帧游戏画面后，如果引擎逻辑运行正常，那么如图4F所示的精灵在画布上的表现的位置为位置(x＝100，y＝100)。

其中，游戏精灵，即游戏精灵实例在游戏引擎中的表现一般分为逻辑层和渲染层。逻辑对象是按照积木模块的逻辑运行的表现，而渲染对象是逻辑运行后结果的表现，渲染对象内存与逻辑对象内存可能不一致。从测试正确性的角度出发，本申请实施例在运行测试用例期间获取的内存数据为渲染对象内存数据，是游戏引擎执行结果的最终表现，值得信赖。

在环境清理阶段，由于每条测试用例运行就相当于一个游戏示例demo在运行，因此在每条测试用例执行完毕后，需要销毁当前游戏，如对游戏引擎的游戏实例进行清理，确保完全销毁以便于下一条测试用例运行。

在测试结果上传阶段，在待测试游戏所有测试用例执行完毕后，上报所有数据(如上报根据用例执行情况数据得到的统计结果，该统计结果包括测试用例的测试结果)至后台服务器，即测试服务器，以用于测试数据归档。

在一个实施例中，本申请实施例所述的游戏测试方法可以应用于如图4G所示的系统架构中。图4G所示的系统架构包括测试服务器、云真机平台、被测PC。云真机平台可以包括多个设备。其中，被测PC以及设备均为测试终端。测试服务器可以分别与云真机平台以及被测PC建立通信。

下面将结合如图4G所示的系统架构对移动端的游戏测试过程进行阐述。

测试服务器可以更新待测试游戏的业务代码。测试服务器对获取的测试用例进行转换，得到能够在设备上运行的测试用例。服务器自动上传待测试游戏至云真机平台，触发云真机任务。云真机平台可以通过云真机调度服务将待测试游戏的测试用例分发到多个设备。设备可以运行接收到的测试用例以执行移动端测试流程，并上传测试结果至测试服务器。

例如，该测试任务定时可以为每天的固定时间。测试服务器可以在每日固定时间到达时执行测试任务，如通过移动端测试用例执行定时任务。测试服务器会拉取最新的被测工具(即游戏制作工具)的业务代码，并打包最新的游戏引擎配置文件。由于测试服务器获取的测试用例的编写调试过程都是在浏览器端进行的，测试服务器获取的测试用例不能直接用于移动端运行，因此测试服务器需要对获取的测试用例进行转换，得到设备能够运行的测试用例。并且，考虑到有些积木模块的逻辑的运行过程在移动端与浏览器端不太一致，因此测试服务器可以将获取的测试用例转化为适合移动端运行的数据格式。

对于移动端来说，移动端的测试用例通常以小游戏为载体来运行，因此运行测试用例的过程相当于在小游戏里循环切换游戏demo来进行测试。在转换测试用例后，执行小游戏的自动化打包上传的操作。例如，可使用miniprogram-ci进行小游戏的自动化打包上传。

测试服务器在上传小游戏完毕后，可以调用云真机平台的云真机调度服务。设备会根据小游戏的应用标识APPID在移动端拉起小游戏。小游戏已设定为打开即自动化运行测试用例，运行测试用例完毕会自动上传测试结果到测试服务器。设备在运行测试用例期间会产生内存数据，该内存数据用于渲染小游戏的游戏画面，设备可以获取运行测试用例期间产生的内存数据，并根据该内存数据与预期数据获得测试结果。

下面将结合如图4G所示的系统架构对浏览器端的游戏测试过程进行阐述。

被测PC可以在测试任务定时到达时，使用指定测试框架运行测试用例以执行在浏览器端的测试流程，并上传测试结果至测试服务器。例如，测试任务定时可以是每天的固定时间。被测PC可以在每天的固定时间到达时，获取最新的被侧工具的业务代码，并打包最新的游戏引擎配置文件。例如，该指定测试框架可以为Karma测试框架。Karma测试框架可以模拟真实的浏览器环境提供渲染引擎必须的canvas环境，使得测试用例的执行能更贴切用户的真实使用环境。

本申请实施例主要从测试的最基本3要素：构造数据->测试运行->校验结果，来设计实现。在本申请实施例中：

构造数据阶段：获取游戏的配置文件；

测试运行阶段：打包引擎核心逻辑，模拟游戏demo运行；

校验结果阶段：通过渲染内存数据来校验结果；

如果同函数级别的单元测试相对比，本申请实施例其实还有提升的空间。游戏测试方案其实在每个用例运行时，都模拟了一遍游戏运行的环境运行，重复测试的代码较多，原因是当时的被测业务代码各个积木模块较为耦合，很难根据积木模块单独进行测试，导致必须提供一个完全的引擎环境才能将积木运行起来。

总的来说，在构造数据以及测试运行阶段，业务侧代码如果提供支持，那么测试可以在更低维度的函数级别进行，即积木函数单元测试。如果能将引擎环境运行实例与积木的运行在逻辑上做好分割，那么运行时只需要构造一次引擎运行的环境，便可以动态引入积木运行，在构造数据方面可以更纯粹地关注积木函数运行的必要参数，无需关注整个引擎的运行。如能将被测引擎的逻辑部分以及渲染部分较好地解耦，那么测试时，可以通过mock技术模拟渲染部分执行，将测试重点关注在业务逻辑上面，在测试运行阶段模拟整个引擎的运行会更轻量化。

请参阅图5，为本申请实施例提供的一种游戏测试装置的结构示意图。该游戏处理装置可以应用于测试终端。该装置可以包括：

获取模块501，用于获取待测试游戏的测试用例。

处理模块502，还用于通过游戏引擎运行所述测试用例，并通过获取模块501获取运行所述测试用例过程中产生的内存数据，所述内存数据用于渲染所述测试用例对应的游戏画面。

处理模块502，还用于根据所述内存数据和对应的预期数据确定所述测试用例的测试结果。

在一种可选的实施方式中，处理模块502根据所述内存数据和对应的预期数据确定所述测试用例的测试结果，具体为获取所述测试用例对应的每帧游戏画面的内存数据；根据所述每帧游戏画面的内存数据和对应的预期数据确定所述每帧游戏画面的测试结果；根据所述每帧游戏画面的测试结果确定所述测试用例的测试结果。

在一种可选的实施方式中，处理模块502，还用于在通过游戏引擎运行所述测试用例之前，运行待测试游戏的测试配置文件，所述测试配置文件包括测试用例配置文件和游戏引擎配置文件，所述游戏引擎配置文件包括游戏引擎的核心引擎逻辑和渲染模块；根据所述测试配置文件调度所述待测试游戏的测试用例。

在一种可选的实施方式中，处理模块502根据所述测试配置文件调度所述待测试游戏的测试用例，具体为根据所述游戏引擎配置文件初始化所述游戏引擎的渲染环境；根据所述测试用例配置文件初始化所述游戏引擎的游戏实例；获取运行所述待测试游戏的游戏实例所需的特征参数，所述特征参数用于所述游戏引擎运行所述测试用例。

在一种可选的实施方式中，所述测试用例是在获取所述待测试游戏的游戏配置文件后，对所述游戏配置文件进行预处理得到的，所述游戏配置文件包括根据配置的游戏功能模块生成的游戏逻辑。

在一种可选的实施方式中，所述的游戏测试装置还可以包括通信模块503。

在一种可选的实施方式中，通信模块503，用于向测试服务器发送所述测试用例的测试结果以及所述测试终端的标识信息，以使得所述测试服务器通过可视化界面展示所述测试用例在所述测试终端上的测试结果。

在一种可选的实施方式中，获取模块501获取待测试游戏的测试用例具体为通过通信模块503接收测试服务器发送的待测试游戏的测试用例，所述测试用例是由所述测试服务器在测试任务定时到达时，对获取的测试用例进行格式转换后得到的。

可见，图5所示实施例中，游戏测试装置可以通过游戏引擎运行待测试游戏的测试用例，从而获取运行该测试用例过程中产生的内存数据，根据该内存数据和对应的预期数据确定该测试用例的测试结果，该游戏测试过程不仅易于实现，还能够提升测试准确度。

基于前述描述的游戏测试方法以及游戏测试装置，本申请实施例还提供了一种测试终端。参见图6，该测试终端包括：处理器601、输入设备602、输出设备603以及计算机存储介质604。

所述计算机存储介质604可以存储在测试终端的存储器中，所述计算机存储介质604用于存储有一条或一条以上指令，所述处理器601用于执行所述计算机存储介质604存储的程序指令。处理器601(或称CPU(Central Processing Unit，中央处理器))是测试终端的计算核心以及控制核心，其适于实现一条或一条以上指令，具体适于加载并执行一条或一条以上指令从而实现相应方法流程或相应功能。

所述计算机存储介质604可以包括易失性计算机存储介质(volatile memory)，例如随机存取计算机存储介质(random-access memory，RAM)；计算机存储介质也可以包括非易失性计算机存储介质(non-volatile memory)，例如快闪计算机存储介质(flashmemory)，硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)；计算机存储介质604还可以包括上述种类的计算机存储介质的组合。

所述输入设备602可以包括输入接口，可用于接收测试服务器发送的待测试游戏的测试用例，输入等待进行处理的待处理数据至处理器601。在一个实施例中，输入接口可以包括多个独立的接口，例如以太网接口、LCD(Liquid Crystal Display，液晶显示器)接口等，分别负责不同外围设备向处理器601输入数据的通信。

所述输出设备603可以包括输出接口，可用于输出数据至其他与终端相连的外围设备，可以向外输出处理器601的处理结果，如将测试设备的标识信息和测试用例的测试结果发送至测试服务器。在一个实施例中，输出设备603可以包括多个独立的接口，例如以太网接口、camera接口等，负责处理器601向不同外围设备输出数据的通信。

在一个实施例中，输出设备603以及输入设备602可以是通用输入输出(GeneralPurpose Input Output，GPIO)接口。

在一个实施例中，处理器601还可以进一步包括硬件芯片。上述硬件芯片可以是专用集成电路(application-specific integrated circuit，ASIC)，可编程逻辑器件(programmable logic device，PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(complex programmable logic device，CPLD)，现场可编程逻辑门阵列(field-programmable gate array，FPGA)，通用阵列逻辑(generic array logic,GAL)或其任意组合。

具体地，所述一条或一条以上指令由处理器601加载并执行以下步骤：

获取待测试游戏的测试用例；

通过游戏引擎运行所述测试用例，并获取运行所述测试用例过程中产生的内存数据，所述内存数据用于渲染所述测试用例对应的游戏画面；

根据所述内存数据和对应的预期数据确定所述测试用例的测试结果。

在一个实施例中，在根据所述内存数据和对应的预期数据确定所述测试用例的测试结果时，所述一条或一条以上指令由处理器601加载并执行以下步骤：

获取所述测试用例对应的每帧游戏画面的内存数据；

根据所述每帧游戏画面的内存数据和对应的预期数据确定所述每帧游戏画面的测试结果；

根据所述每帧游戏画面的测试结果确定所述测试用例的测试结果。

在一个实施例中，在通过游戏引擎运行所述测试用例之前，所述一条或一条以上指令由处理器601加载并执行以下步骤：

运行待测试游戏的测试配置文件，所述测试配置文件包括测试用例配置文件和游戏引擎配置文件，所述游戏引擎配置文件包括游戏引擎的核心引擎逻辑和渲染模块；

根据所述测试配置文件调度所述待测试游戏的测试用例。

在一个实施例中，在所述根据所述测试配置文件调度所述待测试游戏的测试用例，所述一条或一条以上指令由处理器601加载并执行以下步骤：

根据所述游戏引擎配置文件初始化所述游戏引擎的渲染环境；

根据所述测试用例配置文件初始化所述游戏引擎的游戏实例；

获取运行所述待测试游戏的游戏实例所需的特征参数，所述特征参数用于所述游戏引擎运行所述测试用例。

在一个实施例中，所述测试用例是在获取所述待测试游戏的游戏配置文件后，对所述游戏配置文件进行预处理得到的，所述游戏配置文件包括根据配置的游戏功能模块生成的游戏逻辑。

在一个实施例中，所述一条或一条以上指令由处理器601加载并执行以下步骤：

通过输出设备603向测试服务器发送所述测试用例的测试结果以及所述测试终端的标识信息，以使得所述测试服务器通过可视化界面展示所述测试用例在所述测试终端上的测试结果。

在一个实施例中，在获取待测试游戏的测试用例时，所述一条或一条以上指令由处理器601加载并执行以下步骤：

通过输入设备602接收测试服务器发送的待测试游戏的测试用例，所述测试用例是由所述测试服务器在测试任务定时到达时，对获取的测试用例进行格式转换后得到的。

本申请的测试终端对应的功能既可以通过硬件设计实现，也可以通过软件设计来实现，还可以通过软硬件结合的方式来实现，在此不作限制。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，上述的程序包括一条或一条以上指令，可存储于一计算机存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，上述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。

本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述游戏测试实施例中所执行的步骤。

以上所揭露的仅为本申请部分实施例而已，当然不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。

Claims (9)

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

根据配置的游戏功能模块生成对应的游戏逻辑得到游戏配置文件，并获取根据所述游戏配置文件构建的待测试游戏的测试用例；所述测试用例与游戏画面所述待测试游戏的任一游戏画面相对应，所述游戏画面包括测试对象；所述测试用例是通过数据准备和用例编写阶段构造的；其中，所述数据准备阶段用于根据对游戏制作工具中积木模块的拖拽生成游戏逻辑并导出游戏配置文件，所述用例编写阶段用于输出测试用例编写界面，并从所述测试用例编写界面获取根据所述游戏配置文件编写的测试用例，并生成测试用例配置文件，以及将所述测试用例配置文件中的测试用例配置数据导入测试配置文件中；

运行所述测试配置文件，并对测试环境进行初始化，以及在对游戏引擎的游戏实例初始化后，获取测试对象句柄；所述测试配置文件包括所述测试用例配置文件和游戏引擎配置文件，所述游戏引擎配置文件包括游戏引擎的核心引擎逻辑和渲染模块；

传入所述测试对象句柄，以通过游戏引擎运行所述测试用例，并控制游戏帧调度，以在帧之间获取运行所述测试用例过程中产生的所述待测试游戏的每帧游戏画面对应的内存数据，所述内存数据用于渲染所述测试用例对应的游戏画面；对所述游戏画面的渲染是所述游戏逻辑执行的结果表现；所述内存数据包括所述测试对象移动后的位置；

根据所述待测试游戏的每帧游戏画面对应的内存数据包括的所述测试对象移动后的位置和对应的预期数据，确定所述测试对象移动后的位置是否为指定位置，以确定所述测试用例的测试结果；其中，若所述测试对象移动后的位置为所述指定位置，则确定所述游戏逻辑运行正常；

在每条测试用例执行完毕后，销毁当前游戏，并在执行完所有测试用例后，统计用例执行情况，并将统计结果上传到测试服务器中，而在任一测试用例执行完毕后，并在执行下一条测试用例时，重新对所述游戏引擎的渲染环境进行初始化。

2.根据权利要求1所述的方法，其特征在于，所述根据所述内存数据和对应的预期数据确定所述测试用例的测试结果，包括：

获取所述测试用例对应的每帧游戏画面的内存数据；

根据所述每帧游戏画面的内存数据和对应的预期数据确定所述每帧游戏画面的测试结果；

根据所述每帧游戏画面的测试结果确定所述测试用例的测试结果。

3.根据权利要求1所述的方法，其特征在于，所述根据所述测试配置文件调度所述待测试游戏的测试用例，包括：

根据所述游戏引擎配置文件初始化所述游戏引擎的渲染环境；

根据所述测试用例配置文件初始化所述游戏引擎的游戏实例；

获取运行所述待测试游戏的游戏实例所需的特征参数，所述特征参数用于所述游戏引擎运行所述测试用例。

4.根据权利要求1所述的方法，其特征在于，所述测试用例是在获取所述待测试游戏的游戏配置文件后，对所述游戏配置文件进行预处理得到的，所述游戏配置文件包括根据配置的游戏功能模块生成的游戏逻辑。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

向测试服务器发送所述测试用例的测试结果以及所述测试终端的标识信息，以使得所述测试服务器通过可视化界面展示所述测试用例在所述测试终端上的测试结果。

6.根据权利要求1所述的方法，其特征在于，获取待测试游戏的测试用例，包括：

接收测试服务器发送的待测试游戏的测试用例，所述测试用例是由所述测试服务器在测试任务定时到达时，对获取的测试用例进行格式转换后得到的。

7.一种游戏测试装置，其特征在于，应用于测试终端，所述装置包括：

获取模块，用于根据配置的游戏功能模块生成对应的游戏逻辑得到游戏配置文件，并获取根据所述游戏配置文件构建的获取待测试游戏的测试用例；所述测试用例与游戏画面所述待测试游戏的任一游戏画面相对应，所述游戏画面包括测试对象；所述测试用例是通过数据准备和用例编写阶段构造的；其中，所述数据准备阶段用于根据对游戏制作工具中积木模块的拖拽生成游戏逻辑并导出游戏配置文件，所述用例编写阶段用于输出测试用例编写界面，并从所述测试用例编写界面获取根据所述游戏配置文件编写的测试用例，并生成测试用例配置文件，以及将所述测试用例配置文件中的测试用例配置数据导入测试配置文件中；

运行所述测试配置文件，并对测试环境进行初始化，以及在对游戏引擎的游戏实例初始化后，获取测试对象句柄；所述测试配置文件包括所述测试用例配置文件和游戏引擎配置文件，所述游戏引擎配置文件包括游戏引擎的核心引擎逻辑和渲染模块；

处理模块，用于传入所述测试对象句柄，以通过游戏引擎运行所述测试用例，并控制游戏帧调度，以在帧之间通过所述获取模块获取运行所述测试用例过程中产生的所述待测试游戏的每帧游戏画面对应的内存数据，所述内存数据用于渲染所述测试用例对应的游戏画面；对所述游戏画面的渲染是所述游戏逻辑执行的结果表现；所述内存数据包括所述测试对象移动后的位置；

所述处理模块，还用于根据所述待测试游戏的每帧游戏画面对应的内存数据包括的所述测试对象移动后的位置和对应的预期数据，确定所述测试对象移动后的位置是否为指定位置，以确定所述测试用例的测试结果；其中，若所述测试对象移动后的位置为所述指定位置，则确定所述游戏逻辑运行正常;

在每条测试用例执行完毕后，销毁当前游戏，并在执行完所有测试用例后，统计用例执行情况，并将统计结果上传到测试服务器中，而在任一测试用例执行完毕后，并在执行下一条测试用例时，重新对所述游戏引擎的渲染环境进行初始化。

8.一种测试终端，包括输入设备和输出设备，其特征在于，还包括：

处理器，适于实现一条或一条以上指令；以及，

计算机存储介质，所述计算机存储介质存储有一条或一条以上指令，所述一条或一条以上指令适于由所述处理器加载并执行如权利要求1-6任一项所述的游戏测试方法。

9.一种计算机存储介质，其特征在于，所述计算机存储介质存储有一条或一条以上指令，所述一条或一条以上指令适于由处理器加载并执行如权利要求1-6任一项所述的游戏测试方法。

Images