CN118363830A - 游戏引擎的性能测试系统、方法、装置以及电子设备 - Google Patents

Abstract

本申请提供了一种游戏引擎的性能测试系统、方法、装置、电子设备、以及计算机可读存储介质。所述系统包括：测试部，基于预设的测试用例，对第一游戏引擎进行性能测试；环境控制部，为测试部提供环境控制，以保证第一游戏引擎在测试部上进行性能测试时，每一个测试轮次的测试环境相同，以及在每一个测试轮次的测试进程中，测试环境不发生变化；指标监控部，在第一游戏引擎的测试进程中，实时从测试部获取预设的性能指标对应的第一数据，并实时显示第一数据。该系统解决了现有技术存在的因没有专门用于游戏引擎的性能测试方案，而针对游戏产品的性能测试方案对测试环境的敏感度不高，导致游戏引擎的性能测试结果可靠度低，准确性差的技术问题。

Description

游戏引擎的性能测试系统、方法、装置以及电子设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种游戏引擎的性能测试系统、游戏引擎的性能测试方法、及其装置、电子设备、以及计算机可读存储介质。

背景技术

游戏引擎作为一种基础的软件工具链，在游戏开发阶段和游戏运行阶段都发挥着重要作用，游戏开发者在进行游戏开发之前，会为待开发的游戏产品匹配最合适的游戏引擎，以确保游戏产品的性能稳定。游戏开发者在匹配游戏引擎时，通常会依据游戏引擎的性能指标进行选择。因此，为游戏开发者提供准确可靠的游戏引擎性能指标，是确保游戏产品性能稳定的重要条件。

目前没有专门用于游戏引擎的性能测试方案，测试人员通常会依据针对游戏产品的性能测试方案的设计思路对游戏引擎进行性能评估。由于针对游戏产品的性能测试方案更侧重于游戏资源、游戏玩法等方面，对测试环境的敏感度不高，使得沿用该方案的设计思路对游戏引擎进行性能测试时，往往会因测试环境的变化，导致连续两次的测试数据相差较大，无法向游戏开发者提供可靠、精准的测试数据。

因此，现有技术存在因没有专门用于游戏引擎的性能测试方案，而针对游戏产品的性能测试方案对测试环境的敏感度不高，导致游戏引擎的性能测试结果可靠度低，准确性差的技术问题。

发明内容

本申请提供了一种游戏引擎的性能测试系统、游戏引擎的性能测试方法、及其装置、电子设备、以及计算机可读存储介质。

第一方面，本申请实施例提供了一种游戏引擎的性能测试系统，所述系统包括：测试部，基于预设的测试用例，对第一游戏引擎进行性能测试，所述测试用例为基于所述第一游戏引擎制作的应用程序，所述第一游戏引擎为所述游戏引擎对应的待测试版本，所述性能测试包括至少一个测试轮次；环境控制部，为所述测试部提供环境控制，以保证所述第一游戏引擎在所述测试部上进行所述性能测试时，每一个测试轮次的测试环境相同，以及在每一个测试轮次的测试进程中，测试环境不发生变化；指标监控部，在所述第一游戏引擎的测试进程中，实时从所述测试部获取预设的性能指标对应的第一数据，并实时显示所述第一数据，所述第一数据为所述测试部进行所述第一游戏引擎的所述性能测试时，实时产生的原始数据。

第二方面，本申请实施例提供了一种游戏引擎的性能测试方法，所述方法用于控制游戏引擎的性能测试系统，所述方法包括：控制测试部启动第一游戏引擎，并使用所述第一游戏引擎运行预设的测试用例，所述测试用例为基于所述第一游戏引擎制作的应用程序，所述第一游戏引擎为所述游戏引擎对应的待测试版本；控制环境控制部为所述测试部提供测试环境，以保证所述测试部使用所述第一游戏引擎运行所述测试用例的进程中，所述测试环境不发生变化；控制指标监控部实时从所述测试部获取预设的性能指标对应的第一数据，所述第一数据为所述测试部使用所述第一游戏引擎运行所述测试用例的进程中，实时产生的原始数据。

第三方面，本申请实施例提供了一种游戏引擎的性能测试装置，所述装置用于控制游戏引擎的性能测试系统，所述装置包括：测试部控制单元、环境控制部控制单元、指标监控部控制单元；所述测试部控制单元，用于控制测试部启动第一游戏引擎，并使用所述第一游戏引擎运行预设的测试用例，所述测试用例为基于所述第一游戏引擎制作的应用程序，所述第一游戏引擎为所述游戏引擎对应的待测试版本；所述环境控制部控制单元，用于控制环境控制部为所述测试部提供测试环境，以保证所述测试部使用所述第一游戏引擎运行所述测试用例的进程中，所述测试环境不发生变化；所述指标监控部控制单元，用于控制指标监控部实时从所述测试部获取预设的性能指标对应的第一数据，所述第一数据为所述测试部使用所述第一游戏引擎运行所述测试用例的进程中，实时产生的原始数据。

第四方面，本申请实施例提供了一种电子设备，包括：存储器、处理器；所述存储器，用于存储一条或多条计算机指令；所述处理器，用于执行所述一条或多条计算机指令，以实现上述方法。

第五方面，本申请实施例提供了一种计算机可读存储介质，其上存储有一条或多条计算机指令，该指令被处理器执行时，执行上述方法。

与现有技术相比，本申请提供的游戏引擎的性能测试系统包括测试部、环境控制部、指标监控部，其中，测试部能够基于预设的测试用例，对第一游戏引擎进行性能测试，环境控制部能够为测试部提供环境控制，以保证第一游戏引擎在测试部上进行性能测试时，每一个测试轮次的测试环境相同，以及每一个测试轮次的测试进程中，测试环境不发生变化，指标监控部能够在第一游戏引擎的测试进程中，实时从测试部获取性能指标对应的第一数据。由于环境控制部能够为测试部提供环境控制，使得测试部在一致的测试环境下对第一游戏引擎进行性能测试，环境控制部所提供的一致的测试环境不仅包括不同测试轮次的测试环境，还包括同一测试轮次的测试环境，从而避免了测试过程中的环境变量对测试的影响。采用本申请提供的游戏引擎的性能测试系统，由于对测试环境进行了控制，因此，只要待测试的游戏引擎自身的性能是稳定的，就不会出现连续两次测试数据相差较大的情况。本申请提供的游戏引擎的测试系统提供了针对游戏引擎的测试方案，在游戏引擎的测试过程中能够保证测试环境的稳定性，使得测试结果更可靠、更准确，解决了现有技术存在的因没有专门用于游戏引擎的性能测试方案，而针对游戏产品的性能测试方案对测试环境的敏感度不高，导致游戏引擎的性能测试结果可靠度低，准确性差的技术问题。

附图说明

图1是本申请第一实施例提供的游戏引擎的性能测试系统的示意图；

图2是本申请第一实施例提供的又一游戏引擎的性能测试系统的示意图；

图3是本申请第一实施例提供的环境控制部的示意图；

图4是本申请第一实施例中第一实验例对应的测试结果；

图5是本申请第一实施例中第二实验例对应的测试结果；

图6是本申请第一实施例提供的指标监控部显示性能指标的示意图；

图7是本申请第一实施例提供的另一游戏引擎的性能测试系统的示意图；

图8是本申请第一实施例提供的追踪游戏引擎的性能指标的示意图；

图9是本申请第一实施例提供的又一追踪游戏引擎的性能指标的示意图；

图10是本申请第一实施例提供的另一追踪游戏引擎的性能指标的示意图；

图11是本申请第二实施例提供的游戏引擎的性能测试方法的流程图；

图12是本申请第三实施例提供的游戏引擎的性能测试装置的结构示意图；

图13是本申请第四实施例提供的电子设备的结构示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

为了便于理解，首先对本申请实施例中可能涉及的技术术语进行简单介绍。

1、游戏引擎

游戏引擎是一种预先编写的软件系统，专为开发和制作电子游戏而设计。它提供了一系列工具、框架、接口和库，帮助开发者更快速、更高效地创建游戏内容，而不必从零开始编写所有的基础功能代码。游戏引擎通常包含渲染引擎(负责处理图形图像的生成与显示，包括二维图像渲染和三维场景渲染，支持光照、阴影、纹理映射等技术)、物理引擎(模拟物体在虚拟世界中的物理行为，如重力、碰撞检测、弹性和摩擦力等)、音效引擎(管理和播放游戏中的音频效果以及背景音乐)、脚本引擎(允许开发者使用高级脚本语言编写游戏逻辑，控制游戏流程、角色行为和其他可编程元素)、动画系统(管理游戏角色和其他元素的动画序列)、工具集(编辑器、资源管理器、调试工具等辅助开发工具)等核心组件。

2、性能指标

游戏引擎的性能指标是衡量其在开发和运行游戏时表现的关键参数，这些指标直接影响着游戏的开发效率和玩家的体验质量。帧率、图形渲染性能、物理模拟性能、内存管理、CPU/GPU利用率等是一些重要的游戏引擎性能指标。通过分析和优化游戏引擎的性能指标，可以帮助游戏开发者提升游戏的整体流畅度、响应速度以及视觉效果，从而为玩家提供更好的游戏体验。

3、CPU

CPU(Central Processing Unit，中央处理器)，是电子计算机的核心组件之一，负责执行指令、处理数据并控制整个系统操作的硬件单元，是计算机内部最核心的部件，承担了计算和逻辑判断的主要任务。CPU主要由控制器(负责解释和执行指令集中的各种控制信号，管理程序流程，包括指令获取、解码以及协调各个部件的工作)、算术逻辑单元(进行基本的算术运算和逻辑运算，处理所有的数据操作指令)、寄存器组(用于临时存储中间计算结果、指令地址和数据信息，加速数据在不同计算过程中的传递速度)、高速缓存(位于CPU内部的小容量快速存储区域，用来存储最近常用的数据和指令，减少CPU访问主内存的时间延迟)组成。

4、GPU

GPU(Graphics Processing Unit，图形处理器)，是一种专门设计用于执行并行计算、高效处理大量图像和图形数据的微处理器。GPU架构高度并行化，拥有大量的流处理器核心，可以同时处理多个任务或数据单元，相比CPU更适合进行大规模并发计算。

5、CPU Bound

CPU Bound(CPU计算密集型)，是指计算机程序在运行过程中，其性能瓶颈主要在于中央处理器(CPU)的运算能力。这类程序的特点是大部分时间都在进行复杂的数学计算、逻辑判断或算法处理等高度依赖CPU核心的工作，而不是等待输入输出操作完成。在CPUBound情况下，程序的执行速度受限于CPU的时钟频率和单核/多核CPU的并行计算能力，这时即使系统中的内存等性能再高，只要CPU无法更快地完成必要的计算任务，整个程序的执行效率也会受到极大限制。

6、GPU Bound

GPU Bound(GPU计算密集型)，是指计算机程序在运行过程中，其性能瓶颈主要在于图形处理器(GPU)的处理能力。这类程序的特点是大部分时间都在进行大量的并行计算任务，尤其是在图形渲染、深度学习、科学计算等领域。在GPU Bound情况下，程序的执行速度受到GPU核心数量、频率、显存带宽以及显存容量等因素的限制。在3D游戏或者实时渲染应用中，当场景复杂度极高，包含大量高精度模型和纹理时，需要GPU进行大量的顶点处理、像素着色、纹理采样等操作，此时若GPU处理能力不足，将导致帧率下降，画面流畅度受到影响。

游戏引擎作为一种基础的软件工具链，在游戏开发阶段和游戏运行阶段都发挥着重要作用，基于游戏引擎开发出的游戏产品将在个人计算机、移动终端设备、主机设备等平台上运行。游戏产品在运行过程中产生的卡顿、不流畅、闪退、发热、耗电严重等问题，是游戏开发者和游戏体验者关心的内容。游戏引擎作为游戏产品的底层，游戏引擎的性能会对游戏产品的性能产生较大的影响，因此，游戏开发者在进行游戏开发之前，首先会为待开发的游戏产品匹配最合适的游戏引擎，以确保游戏产品的性能稳定。目前游戏引擎的类型较多，每一种类型的游戏引擎又包括多个版本，每一个版本的游戏引擎在性能上可能存在差异。因此，为游戏开发者提供准确可靠的游戏引擎性能指标，有助于游戏开发者根据待开发的游戏产品的预设需求选择出合适的游戏引擎及版本。

目前没有专门用于游戏引擎的性能测试方案，测试人员通常会依据针对游戏产品的性能测试方案的设计思路对游戏引擎进行性能评估。针对游戏产品的性能测试方案是基于游戏引擎性能稳定的基础，对新增或改变的脚本逻辑、美术资源、网络通信流量等进行监控。由于脚本逻辑的改变或美术资源的变动，一定会引起游戏产品的性能变化，因此，针对游戏产品的性能测试更侧重于游戏资源、游戏玩法等方面，对测试环境的敏感度不高。而针对游戏引擎的性能测试往往追求更加稳定的测试指标，游戏引擎的性能一旦偏移较大，下游的游戏产品的性能就会更加无法控制。为了获得稳定的测试指标，对游戏引擎进行性能测试时需要尽可能的减少变量，比如，减少测试环境的改变等。因为针对游戏产品的性能测试方案对测试环境的敏感度不高，沿用该方案的设计思路对游戏引擎进行性能测试时，往往会因测试环境的变化，导致连续两次的测试数据相差较大，以至于测试者无法向游戏开发者提供可靠、精准的测试数据。

因此，现有技术存在因没有专门用于游戏引擎的性能测试方案，而针对游戏产品的性能测试方案对测试环境的敏感度不高，导致游戏引擎的性能测试结果可靠度低，准确性差的技术问题。

有鉴于此，本申请实施例提供了一种游戏引擎的性能测试系统，该系统通过环境控制部为测试部提供环境控制，使得测试部在一致的测试环境下对待测试的游戏引擎进行性能测试，环境控制部所提供的一致的测试环境不仅包括不同测试轮次的测试环境，还包括同一测试轮次的测试环境，从而避免了测试过程中的环境变量对测试结果的影响。本申请提供的游戏引擎的测试系统提供了针对游戏引擎的测试方案，在游戏引擎的测试过程中能够保证测试环境的稳定性，使得测试结果更可靠、更准确。

除此之外，依据针对游戏产品的性能测试方案的设计思路对游戏引擎进行性能评估，还会存在以下缺陷：

第一，针对游戏产品的性能测试方案的性能指标覆盖度不足，依据针对游戏产品的性能测试方案的设计思路对游戏引擎进行性能评估时，会使测试结果不够全面，影响游戏开发者的细粒度筛选。

第二，针对游戏产品的性能测试方案的硬件覆盖度不足，依据针对游戏产品的性能测试方案的设计思路对游戏引擎进行性能评估时，会使测试结果适用性低，不能覆盖大部分游戏开发者的使用需求。

在本申请的又一些实施例中，还提供了针对上述缺陷的解决方案，比如：根据游戏引擎的性能特点对性能指标进行细粒度拆分与增加，再比如：根据游戏引擎的性能特点预设针对不同硬件的测试用例等。

下面结合具体实施例及附图对本申请所述的游戏引擎的性能测试系统、游戏引擎的性能测试方法、及其装置、电子设备、以及计算机可读存储介质做进一步详细说明。

本申请第一实施例提供了一种游戏引擎的性能测试系统，该系统用于对待测试的游戏引擎进行性能测试与跟踪。

图1是本实施例提供的游戏引擎的性能测试系统的示意图。以下结合图1对本实施例提供的游戏引擎的性能测试系统进行详细描述。以下描述所涉及的实施例用于解释本申请的技术方案，并不作为实际使用的限定。

如图1所示，本实施例提供的游戏引擎的性能测试系统，包括：测试部110、环境控制部120、以及指标监控部130。

所述测试部110，用于基于预设的测试用例，对第一游戏引擎进行性能测试，所述测试用例为基于所述第一游戏引擎制作的应用程序，所述第一游戏引擎为所述游戏引擎对应的待测试版本，所述性能测试包括至少一个测试轮次。

所述环境控制部120，用于为所述测试部110提供环境控制，以保证所述第一游戏引擎在所述测试部110上进行所述性能测试时，每一个测试轮次的测试环境相同，以及在每一个测试轮次的测试进程中，测试环境不发生变化。

所述指标监控部130，用于在所述第一游戏引擎的测试进程中，实时从所述测试部110获取预设的性能指标对应的第一数据，并实时显示所述第一数据，所述第一数据为所述测试部110进行所述第一游戏引擎的所述性能测试时，实时产生的原始数据。

在一具体实现方式中，本实施例提供的游戏引擎的性能测试系统以硬件的形式供测试者使用。其中，测试部可以是与待测试的游戏引擎相匹配的各种终端设备，比如：不同型号和配置的电脑、涵盖不同的操作系统版本(如，Android各版本、iOS各版本)以及各种分辨率和处理器类型的移动设备(如，智能手机和平板电脑)、游戏主机、虚拟现实(VR)和增强现实(AR)头戴式设备等。具体的，需要根据待测试的游戏引擎的类型选择合适的终端设备作为测试部，比如：对于针对手游的游戏引擎的性能测试而言，就不能选择电脑作为测试部，同样，对于针对端游的游戏引擎的性能测试而言，就不能选择智能手机作为测试部。环境控制部可以是能够为测试部提供稳定测试环境的设备或设备组合，比如：温度控制设备、湿度控制设备、充电设备等。指标监控部可以是智能手机、平板电脑、笔记本电脑、台式电脑、个人数字助理(Personal Digital Assistant,PDA)等任一具备交互和显示功能的设备。

以下对本实施例提供的游戏引擎的性能测试系统进行详细说明：

针对测试部：

终端设备运行游戏产品时，是否会生成卡顿、不流畅、闪退、发热、耗电严重等问题，与终端设备的自身性能和运行在终端设备上的游戏引擎的性能密切相关。衡量终端设备的自身性能的指标较多，其中CPU性能和GPU性能是两个最重要的衡量指标，CPU主要侧重于提供逻辑运算能力，GPU主要侧重于提供图像渲染能力。因此，在进行游戏引擎的测试时，选择合适的终端设备作为测试部尤为重要，当测试部的选择不合适时，难免会带来测试结果可用性和适用性方面的问题，比如：虽然测试者提供了对某游戏引擎的性能测试结果，但因使用的测试部为当前市场上拥有最高性能CPU和GPU的终端设备，那么，当游戏开发者获取到测试结果后，并无法判断出该游戏引擎是否能够在拥有中等性能的CPU和GPU的终端设备上稳定运行，无法为最终游戏产品的适用性定位提供参考依据，且对于想要采用该游戏引擎开发大众适用的游戏产品的游戏开发者而言，该测试结果并不适用。这也是当前采用针对游戏产品的性能测试方案的设计思路对游戏引擎进行性能测试时存在的一个问题。

基于此，为了达到对游戏引擎性能测试的覆盖度，本实施例提供的方法还包括对测试部进行采样，通过在多个终端设备上均进行测试，使得最终测试结果的适用度升高，具体的，可以将实用度超过预设阈值作为对测试部进行采用的标准，比如，预设阈值为90％、80％等，当然，使实用度达到100％是最为理想的状态，但考虑到实际应用市场中终端设备的复杂多过高，将预设阈值设置为100％无疑会急剧增加测试成本，因此，在一具体实现方式中，将实用度超过90％作为采样测试部的标准。

测试结果的实用度超过90％，即，意味着超过90％的游戏开发者能够基于最终的测试结果做出该游戏引擎是否适用的判断，也意味着用于测试的测试部在市场的占有率超过90％。市场的多样性，使得要达到测试部在市场的占有率超过90％，测试部所需要包括的终端设备的数量就会非常多，增加采样难度，且测试成本也会增加，因此，在一可选实现方式中，用CPU和GPU的市场占有率作为采样标准，将市场占有率高的多个CPU和多个GPU进行组合，根据CPU和GPU组合采样测试部，具体的，将对应于多个CPU和GPU组合的多个终端设备均作为测试部。这样，在对第一游戏引擎进行测试，即可获得第一游戏引擎在每一种终端设备上的性能测试结果，增加了测试结果的适用度。因此，在本实施例中，所述测试部包括能够承载所述第一游戏引擎的多个设备中的至少一个，所述多个设备对应的中央处理器和图形处理器的市场占有率大于90％。

所述能够承载第一游戏引擎的设备可以理解为与第一游戏引擎适配的终端设备，比如，第一游戏引擎为针对手游的游戏引擎时，那么，该设备即为智能手机，多个设备即为拥有不同CPU和GPU组合的智能手机。

以下以针对手游的M游戏引擎作为待测试的游戏引擎，对测试部的采样过程进行具体描述，测试部的采样过程可以包括如下步骤S11至步骤S14：

步骤S11，根据M游戏引擎确定测试部的设备类型，由于M游戏引擎为针对手游的游戏引擎，因此，将测试部确定的智能手机。

步骤S12，确定市场占有率最高的用于智能手机的多个CPU和多个GPU，多个CPU的市场占有率之和大于90％，多个GPU的市场占有率之和大于90％。

步骤S13，将多个CPU和多个GPU进行组合，形成多个CPU和GPU组合。

步骤S14，根据多个CPU和GPU组合，在市场上采样对应的智能手机。

当然，也可以将内存器、显卡等作为对测试部采样的依据，这主要取决于游戏开发者对游戏引擎性能测试结果的需求，如果游戏开发者想要得到游戏引擎在显卡调用等方面的性能数据，那么，在测试部的采样过程中，也可以将显卡的市场占有率作为一项采用依据，具体在此不做详细说明。

游戏引擎的性能测试与游戏产品的性能测试存在差异，在游戏产品的性能测试中，需要尽可能的模拟玩家的真实使用场景，而在游戏引擎的性能测试中，应该尽可能的减少变量，提高性能指标的可控性，这一方面依赖于对测试环境的控制，一方面依赖于对测试用例的控制。基于此，在本实施例提供的一种可选实现方式中，本实施例提供的游戏引擎的性能测试系统还可以包括：测试用例设置部。所述测试用例设置部用于：响应于基于所述第一游戏引擎对所述测试用例的制作操作，生成所述测试用例；将所述测试用例发送给所述测试部。

所述基于第一游戏引擎对测试用例的制作操作可以理解为测试者在测试用例设置部上基于第一游戏引擎编辑测试用例的操作，测试用例设置部也是能够承载第一游戏引擎的设备，当第一游戏引擎为针对手游的游戏引擎时，测试用例设置部即为智能手机，当第一游戏引擎为针对端游的游戏引擎时，测试用例设置部即为电脑。测试者在测试用例设置部上完成对测试用例的制作后，测试用例设置部即可将测试用例作为独立的应用程序打包发送给测试部，以使测试部启动第一游戏引擎运行测试用例对第一游戏引擎的性能进行测试。

图2是本实施例提供的又一游戏引擎的性能测试系统的示意图。

如图2所示，该游戏引擎的性能测试系统在拥有测试部210、环境控制部220、以及指标监控部230之外，还拥有测试用例设置部240。测试用例设置部240在开始进行游戏引擎的测试前，会将测试用例241发送给测试部210。

本实施例还提供了专门针对游戏引擎性能测试的测试用例，这些测试用例是基于测试用例设置部，根据游戏引擎的功能模块进行分块设计的。在进行第一游戏引擎的性能测试时，可以基于以下测试用例中的一个或多个进行测试：

空场景用例，用于测试所述第一游戏引擎的空转性能；

中央处理器计算密集型用例，用于测试所述第一游戏引擎在处理计算密集型任务时的性能；

图形处理器计算密集型用例，用于测试所述第一游戏引擎在处理图形密集型任务时的性能；

材质用例，用于测试所述第一游戏引擎在图形渲染方面的性能；

动画用例，用于测试所述第一游戏引擎在处理并发动画时的性能；

植被用例，用于测试所述第一游戏引擎在植被渲染方面的性能。

对于空场景用例，主要是针对第一游戏引擎在处理无内容或初始状态时的行为进行验证，比如，使第一游戏引擎加载一个没有放置任何对象、光源、地形或其他资源的空白关卡，以检查第一游戏引擎是否能正常加载并渲染空白场景，而不会出现崩溃或异常行为，并给与游戏开发者第一游戏引擎在空场景下的性能指标(如帧率、内存占用等)数据，让游戏开发者判断第一游戏引擎在空场景下的性能指标是否符合预期。

对于中央处理器计算密集型用例(CPU bound用例)，主要是测试第一游戏引擎在处理大量物理数学计算任务时的性能表现，在CPU bound用例中通常会设置大量简单单一的游戏逻辑实体，比如：碰撞体等，以将测试部的CPU占用率和频率使用到极致。比如，使第一游戏引擎加载一个放置有几千个刚体或柔体进行实时碰撞检查与物理仿真的场景，以获得当CPU执行复杂的物理计算时，游戏引擎是否能够保持稳定的帧率，如何进行资源分配等。

对于图形处理器计算密集型用例(GPU bound用例)，主要是测试第一游戏引擎在处理大量图形渲染、纹理处理、几何体绘制等任务时的性能表现，在GPU bound用例中开启大量体积云、体积雾、反射等后处理任务，放置极少量的游戏逻辑实体，以达到对GPU的频率和占用率使用到极致。比如，使第一游戏引擎加载一个部署了成千上万动态粒子的大规模粒子系统，以获得GPU在处理大量并行渲染任务时的性能数据。

对于材质用例(PBR Shader用例)，主要是测试第一游戏引擎对PBR(基于物理的渲染)材质渲染的性能表现。在PBR Shader用例中通过会将默认材质进行极致外放，比如，使第一游戏引擎加载一个部署有大量包含不同基础材质类型(金属、非金属、透明、半透明等)创建的简单几何体的游戏场景，以获得第一游戏引擎渲染PBR材质时的性能数据。

对于动画用例，主要是测试第一游戏引擎对角色动画、场景动画的性能表现。在动画用例中通过会设置大量的角色动画或场景动画，比如，使第一游戏引擎加载很多角色模型在场景中跑动的动画，以获得游戏动画对游戏引擎的性能压力数据。

对于植被用例，主要是测试第一游戏引擎对植被渲染的性能表现。在植被用例中通过会设置大量植被。比如，使第一游戏引擎加载一个配置有大量植被的游戏场景，获得第一游戏引擎在绘制、批处理、剔除不必要的植被渲染下的性能数据。

当然，根据待测试游戏引擎的差异以及游戏开发者的需求，还可以设置更多的测试用例，以为游戏开发者提供所需的性能参考。需要说明的是，在采用上述测试用例对游戏引擎进行多个轮次的测试时，镜头需要固定，不能有所差异。

针对环境控制部：

环境控制部是本实施例提供的游戏引擎的性能测试系统中的核心组件，主要用于对测试部提供稳定的测试环境，以使测试结果准、可靠。

在一具体实现方式中，测试环境包括温度、湿度、灰尘度、网络信号强度、电量等，这些测试环境都会对测试部本身的性能产生影响。以测试部为智能手机为例，温度提升会导致手机的CPU和GPU过热，为了保护内部组件，手机通常会启动散热机制，如，降低CPU和GPU的频率，从而导致CPU和GPU性能下降，运行速度变慢；湿度升高可能会导致手机电路板受潮，引发短路或其他电气故障，从而影响手机功能，也可能会影响网络信号传输质量，使手机耗电量增加；灰尘进入手机内部后，会附着在电路板、散热片和其他关键部件上，形成隔热层，妨碍散热，进而导致手机内部温度上升，影响手机整体性能的稳定性；网络信号变弱时，手机需要花费更多功率去搜索和维持稳定的信号连接，可能会导致数据传输速率降低，耗电量增加；手机电量较低时，手机系统可能会自动限制部分后台活动或非关键性功能，导致手机整体性能的下降。因此，控制稳定的测试环境，可以减小对游戏引擎进行性能测试时的变量，具体的，减小测试部本身的性能变化对测试结果的干扰。

在一可选实现方式中，所述环境控制部包括第一控制设备和第二控制设备。所述第一控制设备用于控制所述测试部的温度状态、湿度状态、灰尘状态、以及网络状态；所述第二控制设备，用于控制所述测试部的电量状态。基于第一控制设备和第二控制设备确保每一个测试轮次的测试环境相同，且在每一个测试轮次的测试进程中，测试环境不发生变化。

在一具体实现方式中，所述第一控制设备至少包括恒温恒湿箱，所述第二控制设备至少包括电流仪。具体的，将测试部置于所述恒温恒湿箱中，以控制测试部的温度、湿度、灰尘、网络等状态稳定，用所述电流仪为所述测试部供电，以控制测试部的电量状态稳定。

图3是本实施例提供的环境控制部的示意图。

如图3所示，环境控制部包括第一控制设备301和第二控制设备302，具体的，第一控制设备301为一恒温恒湿箱，进行测试时，将测试部303(如，手机)放置于恒温恒湿箱中，第二控制设备302为一电流仪，进行测试时，与测试部303电连接，为测试部303供电。

在另一可选实现方式中，环境控制部可以只包括独立的控制设备，如第三控制设备，第三控制设备为一集成设备，同时控制测试部所处于温度状态、湿度状态、灰尘状态、网络状态、以及电量状态。具体的，第三控制设备为集成有电流仪的恒温恒湿箱，电流仪可以通过与测试部电连接为测试部提供有线供电，也可以通过恒温恒湿箱成测试部提供无线供电。

本实施例提供了具体的实验例，对环境控制部的作用进行了验证。具体的，以历史阶段已通过性能测试或已通过长时间使用确定性能稳定的针对手游的M游戏引擎作为测试引擎，以智能手机P作为测试部，以恒温恒湿箱和电流仪组合作为环境控制部，以GPU帧率作为性能指标。在第一实验例中，将智能手机P放置在实验室的常规环境下，使用智能手机P运行M游戏引擎，具体的，运行采用M游戏引擎制作的测试用例L，进行多个测试轮次。在第二实验例中，将智能手机P放置在恒温恒湿箱中，并采用电流仪对智能手机P进行持续供电，使用智能手机P运行M游戏引擎，具体的，运行采用M游戏引擎制作的测试用例L，进行多个测试轮次。通过指标监控部获得的测试结果如表1、表2、图4、以及图5所示，需要说明的是，在第一实验例和第二实验例中都进行了多个测试轮次，表1、表2、图4和图5中仅展示出其中6个测试轮次。

表1GPU帧率值(第一实验例)

测试轮次	平均值	最大值	最小值	标准差
					1	459447540.0	510000000.0	401800000.0	54206175.448
2	362793495.0	510000000.0	315000000.0	55588994.871
					3	401800000.0	401800000.0	401800000.0	0.0
4	315000000.0	315000000.0	315000000.0	0.0
					5	360193388.0	401800000.0	315000000.0	43543234.713
6	315000000.0	315000000.0	315000000.0	0.0

表2GPU帧率值(第二实验例)

测试轮次	平均值	最大值	最小值	标准差
					1	510000000.0	510000000.0	510000000.0	0.0
2	510000000.0	510000000.0	510000000.0	0.0
					3	510000000.0	510000000.0	510000000.0	0.0
4	510000000.0	510000000.0	510000000.0	0.0
					5	510000000.0	510000000.0	510000000.0	0.0
6	510000000.0	510000000.0	510000000.0	0.0

图4是第一实验例对应的测试结果，是以表1中的测试轮次作为横坐标，以GPU帧率平均值作为纵坐标获得的柱状图，图5是第二实验例对应的测试结果，是以表2中的测试轮次作为横坐标，以GPU帧率平均值作为纵坐标获得的柱状图。

由表1和图4可以看出，将智能手机P放置在实验室的常规环境下进行M游戏引擎的性能测试时，相邻测试轮次的GPU帧率平均值之间差异较大，且任意一个测试轮次中的GPU帧率最大值和GPU帧率最小值之间的差异也较大，根据此结果可以得出M游戏引擎在GPU帧率上性能不稳定的结论，但实际上M游戏引擎是经过测试或使用验证的性能稳定的游戏引擎，因此，测试者基于第一实验例并不能给与游戏开发者准确、可用的测试结果。

由表2和图5可以看出：将智能手机P放置在恒温恒湿箱中，并采用电流仪进行持续供电的实验条件下，进行M游戏引擎的性能测试时，相邻测试轮次的GPU帧率平均值之间没有差异，且任意一个测试轮次中的GPU帧率最大值和GPU帧率最小值之间也没有差异，根据此结果可以得出M游戏引擎在GPU帧率上性能稳定的结论，这与M游戏引擎的实际性能状态相符和，因此，测试者基于第二实验例能够给与游戏开发者准确、可用的测试结果。

从上述实验例可以看出，为测试部提供稳定可控的测试环境，是获得准确、可靠的性能测试结果的必要条件。从上述实验例的全部数据(包括未在表1和表2中展示的数据，也包括其他性能指标对应的数据)可以得出，利用环境控制部对测试环境进行控制，能够极大的缩小误差，比如，将GPU帧率的误差控制在了2帧以内，将CPU占用量的误差控制在了3％以内。

针对指标监控部：

指标监控部可以理解为一个针对测试者的数据收集和数据显示的组件，供测试者观察性能测试是否正常运行。

测试部开启后，即会实时产生各模块当前的状态数据，比如，CPU的当前占用量、内存的当前剩余量等。指标监控部可以在测试进程中，实时从测试部获取这些数据，并对测试者进行实时显示。在本实施例中，将测试部对第一游戏引擎进行性能测试时，实时产生的原始数据定义为第一数据。

在一可选实现方式中，所述性能指标至少包括以下指标中的一种：帧率指标、功耗指标、内存指标、图形处理器占用指标、中央处理器占用指标。这些指标属于基础指标，可以作为游戏开发者感知和筛选游戏引擎的基础依据。

为使游戏开发者能够对游戏引擎的性能进行更为细粒度的感知，从而选择出最为合适的游戏引擎作为游戏产品的开发工具，在本实施例提供的一种可选实现方式中，对基础性能指标进行了拆分，并增加了其他性能指标，具体的，将帧率指标拆分为逻辑帧率指标和渲染帧率指标，将渲染帧率指标增加为绘制调用指标和三角面指标，将内存指标细粒度划分为总内存指标、可用内存指标、使用内存指标、缓存内存指标、缓冲区内存指标、比例集大小指标、独享集大小指标、交换空间指标、堆内存指标、显示和渲染内存指标、追踪内存指标、释放内存指标、压缩内存指标。因此，在采用本实施例提供的测试系统进行游戏引擎的性能测试时，所述帧率指标，包括：逻辑帧率指标和渲染帧率指标，其中，所述渲染帧率指标包括绘制调用指标和三角面指标；所述内存指标，至少包括以下指标中的一种：总内存指标、可用内存指标、使用内存指标、缓存内存指标、缓冲区内存指标、比例集大小指标、独享集大小指标、交换空间指标、堆内存指标、显示和渲染内存指标、追踪内存指标、释放内存指标、压缩内存指标。以下对这些指标做详细解释：

逻辑帧率是指对测试用例中游戏逻辑实体的执行效率，重点在于测试游戏引擎在脚本逻辑执行上的性能表现。

渲染帧率是指对测试用例中待渲染对象的执行效率，重点在于测试游戏引擎在渲染能力上的性能表现。

渲染帧率中的绘制调用(Drawcall)是向GPU发送的一个命令，以告知GPU渲染一组具有特定状态的几何体，该状态可以包括使用的材质(包括纹理)、着色器、光照参数等，每个Drawcall会有一个或多个对象或者几何体被绘制到屏幕上。Drawcall是一个重要的性能指标，因为每个Drawcall都会产生一定程度的CPU和GPU开销，如果有大量的Drawcall，渲染性能就可能受到限制，通过绘制调用指标能够获知游戏引擎在游戏运行过程中均衡Drawcall的性能。

渲染帧率中的三角面是一种重要的性能指标，三角面是几何体的最基本绘制单元，无论多么复杂的几何体，都是由三角面这种简单多边形组成的，三角面的数量通常表示一个模型或整个场景的复杂度，三角面数量越多，模型细节越丰富，但同时对GPU的负荷也越大，通过三角面指标能够获知游戏引擎在实时渲染过程中减少三角面数量的性能。

总内存(Total Memory)是指测试部上可用的全部物理内存总量，给出了测试部具备的内存容量的总体概览。

可用内存(Available Memory)是指当前未被使用的内存量，包括了尚未分配给任何应用程序或系统进程的内存。

使用内存(Used Memory)是指当前正在被应用程序、后台服务和系统进程所占用的内存总量。

缓存内存(Cached Memory)是指被系统用来存储临时数据的内存部分，以便于快速访问，这些数据通常是从较慢的存储媒介(如硬盘)上读取进来的。

缓冲区内存(Buffers)是用来存储原始磁盘块，以便提高I/O操作的性能，主要用于文件系统的操作。

比例集大小(Proportional Set Size，PSS)用于度量了一个应用程序的内存使用量，并且算上了共享库文件的一个公平比例，如果多个应用共享相同的库，那么该库内存占用将被平均分配给这些应用。

独享集大小(Unique Set Size，USS)代表了一个进程独有的内存大小，不与其他任何进程共享，是一个进程独占的内存使用量。

交换空间是硬盘的一部分，当物理内存不足时，系统可能会使用交换空间，作为虚拟内存，数据可以在物理内存和交换空间之间交换，以尝试为运行中的应用程序提供所需内存。

堆内存(Native Heap)是指给非Java语言，通常是C或C++代码分配的堆内存。

显示和渲染内存(Gfx dev)是指图形设备的内存使用，包括用于显示和GPU渲染的内存。

追踪内存(GL mtrack)是指OpenGL(开放图形库)跟踪的内存使用情况，用来衡量与OpenGL相关的资源的占用情况。

释放内存(OOM_adj/OOM_score_adj)是与内存不足(Out of Memory,OOM)处理相关的参数，会影响进程被系统杀死以释放内存的优先级。

压缩内存(ZRAM)是指压缩区内存，用于临时存储交换分区数据，来增加可用的物理内存总量。

通过对上述指标的监控，可以获得第一游戏引擎的细粒度性能测试结果，以使游戏开发者能够更加精细的感知第一游戏引擎的性能，并判断是否选择第一游戏引擎作为游戏开发引擎。

在一具体实现方式中，指标监控部具有显示屏，并安装有性能测试插件，该性能测试插件定义了性能指标对应的第一数据的显示方式，以使各性能指标对应的第一数据通过性能测试插件的展示界面实时显示在指标监控部的显示屏上。

图6是本实施例提供的指标监控部显示性能指标的示意图。

指标监控部的显示屏上显示有性能测试插件的展示界面，该性能测试插件定义了将性能测试的测试数据显示在界面的数据显示区域内，并将不同性能指标的测试数据独立显示，该测试数据包括第一数据以及对第一数据进行初步处理得到的平均值，当然，还可以显示最大值、最小值等，可以根据测试者的设置确定显示内容。此外，性能测试插件还定义了将当前正在进行的性能测试的相关信息(如，待测试游戏引擎的名称、版本号、测试时间、测试部型号等)显示在信息显示区域内、将测试日志显示在日志显示区域内等。如图6所示，区域610为显示当前正在进行的性能测试的相关信息的信息显示区域，如，该区域内显示了当前正在进行性能测试的游戏引擎的名称为M、版本号为5.0，测试时间为2024年1月1日，测试部型号的手机L。区域620为显示测试数据的数据显示区域，其中，子区域621中显示了GPU的当前帧率和帧率平均值、子区域622中显示了GPU的当前占用量和占用量均值、子区域623中显示了可用内存的当前值和平均值、子区域624中显示了使用内存的当前值和平均值，其他区域内的显示内容不再进行说明。区域630为显示测试日志的日志显示区域，其中显示有M游戏引擎正在运行的程序，正在产生的性能数据等。

在本实施例提供的一种可选实现方式中，本实施例提供的游戏引擎的性能测试系统还可以包括：指标存储部。所述指标存储部用于：响应于从所述指标监控部获取到所述性能指标的第一数据，针对每一个测试轮次，对所述性能指标的第一数据进行数据处理，生成每一个测试轮次对应的所述性能指标的第二数据，所述第二数据用于表征所述性能指标在所述性能测试的每一个测试轮次中的数据状态；存储每一个测试轮次对应的所述性能指标的第二数据；响应于客户端发送的针对所述第一游戏引擎的性能指标获取请求，向所述客户端发送每一个测试轮次对应的所述性能指标的第二数据。

指标存储部可以理解为对性能数据进行进一步归纳总结、存储、发送的组件，可以是具有计算和存储能力的设备，也可以是服务器。

图7是本实施例提供的另一游戏引擎的性能测试系统的示意图。

如图7所示，该游戏引擎的性能测试系统在拥有测试部710、环境控制部720、以及指标监控部730之外，还拥有指标存储部740，在该图例中，该游戏引擎的性能测试系统也拥有测试用例设置部750。指标存储部740从指标监控部730获取性能指标的第一数据后，会对性能指标的第一数据进行数据处理，形成以各种方式计算的总结性数据(如，第二数据)，并对计算获得的总结性数据(如，第二数据)进行存储，当指标存储部740接收到客户端760发送的性能指标查看请求时，即会将这些总结性数据(如，第二数据)发送给客户端760，以使客户端760将该性能数据呈现给游戏开发者。

在一可选实现方式中，指标存储部从指标监控部获取性能指标的第一数据也可以理解为指标监控部向指标存储部发送性能指标的第一数据，该数据的获取过程可以是在性能测试完成后进行的一次性获取，也可以在性能测试过程中进行的实时获取，在此不做限制。

在一可选实现方式中，指标存储部对第一数据进行的数据处理至少包括以下处理方式中的一种：平均值计算、最大值筛选、最小值筛选、标准差计算。

在一具体实现方式中，第二数据是指标存储部以第一数据作为待处理数据，以每一个测试轮次作为划分依据，对每一个测试轮次中每一个性能指标的全部第一数据进行平均值计算、最大值筛选、最小值筛选和标准差计算获得的，以此来增加判断游戏引擎稳定性的依据。如上所述的表1和表2中的数据即可理解为GPU帧率指标对应的第二数据，每一行代表一个测试轮次中GPU帧率指标的平均值(对GPU帧率指标对应的全部第一数据作平均值计算获得的)、GPU帧率指标的最大值(从GPU帧率指标对应的全部第一数据中筛选出的最大值)、GPU帧率指标的最小值(从GPU帧率指标对应的全部第一数据中筛选出的最小值)、GPU帧率指标的标准差(对最大值和最小值作标准差计算获得的)。游戏开发者通过第二数据即可感知到游戏引擎的性能是否稳定，如果相邻测试轮次的平均值差异较大，说明该游戏引擎在每次使用时的性能无法保证一致，如果同一测试轮次的最大值和最小值之间差异较大，即，标准差过大，说明该游戏引擎在同一次的使用过程中性能即无法保证一致。

在一可选实现方式中，在针对每一个测试轮次，对性能指标的第一数据进行数据处理，生成每一个测试轮次对应的性能指标的第二数据的步骤之后，指标存储部还用于：针对所述性能测试，对每一个测试轮次对应的所述性能指标的第二数据进行数据处理，生成所述性能测试对应的所述性能指标的第三数据，所述第三数据用于表征所述性能指标在所述性能测试中的数据状态；存储所述性能测试对应的所述性能指标的第三数据；响应于客户端发送的针对所述第一游戏引擎的性能指标获取请求，向所述客户端发送所述性能测试对应的所述性能指标的第三数据。

指标存储部对数据的归纳总结可以是多维度多次数的，在一具体实现方式中，在获得了第二数据之后，还可以第二数据作为待处理数据，以完整的一次性能测试(包括多个测试轮次)作为划分依据，对每一个测试轮次中每一个性能指标的第二数据进行再次数据处理，至少包括以下处理方式中的一种：平均值计算、最大值筛选、最小值筛选、标准差计算，获得该性能测试中每一个性能指标对应的第三数据，以此为游戏开发者提供更加直观的总结性数据。

以表1所示的数据作为第二数据，对如何获得第三数据进行举例说明。对每一个测试轮次对应的平均值进行再次平均值处理，得到第三数据369039070.5(平均值)，从每一个测试轮次对应的最大值中进一步筛选最大值，得到第三数据510000000.0(最大值)，从每一个测试轮次对应的最小值中进一步筛选最小值，得到第三数据315000000.0(最小值)，对筛选出的最大值510000000.0与最小值315000000.0作标准差计算，得到第三数据55588994.871(标准差)。通过上述计算获得的第三数据并不是对应某一个测试轮次的数据，而是对应本次性能测试的总结性数据。将该第三数据呈现给游戏开发者，能够让游戏开发者直观的感知M游戏引擎在GPU帧率性能指标上的测试结果。

在一可选实现方式中，通过本实施例提供的测试系统，还能够对游戏引擎在升级过程中的不同版本进行跟踪监控，以比较的方式向游戏开发者展示该游戏引擎的升级历程中，不同版本之间的性能变化，使游戏开发者深入了解该游戏引擎的可靠度，以及新版本游戏引擎性能的稳定性，以解决游戏开发者对升级游戏引擎的顾虑。基于此，指标存储部中不仅存储有游戏引擎的待测试版本的性能指标数据，还存储有历史版本(即，已通过测试版本)的性能指标数据，在本实施例中将历史版本的游戏引擎定义为第二游戏引擎，具体的，所述指标存储部还存储有针对第二游戏引擎的所述性能测试对应的所述性能指标的第三数据，所述第二游戏引擎为所述游戏引擎对应的至少一个已测试版本。

如上所示，本实施例提供的测试系统包括环境控制部，因此，可以保证在进行第一游戏引擎性能测试时的测试环境与进行第二游戏引擎性能测试时的测试环境相同，进一步采用相同的测试用例进行测试，即可获得具有可比性的数据。

因此，在针对性能测试，对每一个测试轮次对应的性能指标的第二数据进行数据处理，生成性能测试对应的性能指标的第三数据的步骤之后，指标存储部还用于：对所述第一游戏引擎对应的所述性能指标的第三数据、以及所述第二游戏引擎对应的所述性能指标的第三数据进行数据处理，生成针对所述游戏引擎的所述性能指标的第四数据，所述第四数据用于表征所述性能指标在所述第一游戏引擎和所述第二游戏引擎之间的差异状态；存储所述游戏引擎的所述性能指标的第四数据；向所述客户端发送针对所述游戏引擎的所述性能指标的第四数据。

在一具体实现方式中，第四数据是对待测试的游戏引擎的多个版本之间的第三数据进行比较的结果，可以视图的形式表示。该视图可以是柱状图、折线图、饼状图等任意表现方式，具体在此不做限制。

基于此，对第一游戏引擎对应的性能指标的第三数据、以及第二游戏引擎对应的性能指标的第三数据进行数据处理，包括：根据所述第一游戏引擎对应的所述性能指标的第三数据、以及所述第二游戏引擎对应的所述性能指标的第三数据，制作所述性能指标在所述第一游戏引擎和所述第二游戏引擎之间的变化趋势图。

图8是本实施例提供的追踪游戏引擎的性能指标的示意图。

如图8所示，采用本实施例提供的游戏引擎的性能测试系统对M游戏引擎的多个版本进行的性能测试，在性能测试过程中，通过环境控制部为每一次性能测试提供相同的测试环境，每一次性能测试也采用相同的测试用例，因此，针对多个版本的游戏引擎的性能测试结果具有可比性。在图8中显示的数据为针对CPU帧率的性能测试数据，横坐标表示待测试的M游戏引擎的不同版本的版本号，纵坐标表示CPU帧率的数值，以折线图的形式表示不同版本的M游戏引擎在CPU帧率上的性能稳定性。由折线81可以看出，M游戏引擎的不同版本在CPU帧率上的性能是稳定的。

当然，在一张变化趋势图中也可以同时展示多个性能指标的比较结果，或在多个测试部上进行的性能测试的比较结果。

图9是本实施例提供的又一追踪游戏引擎的性能指标的示意图。

如图9所示，采用本实施例提供的游戏引擎的性能测试系统对M游戏引擎的多个版本进行的性能测试，在性能测试过程中，通过环境控制部为每一次性能测试提供相同的测试环境，每一次性能测试也采用相同的测试用例，因此，多个版本的性能测试所获得的数据具有可比性。在图9中显示的数据为针对CPU帧率的性能测试数据和针对GPU帧率的性能测试数据，横坐标表示待测试的M游戏引擎的不同版本的版本号，纵坐标表示帧率的数值，以折线图的形式表示不同版本的M游戏引擎在CPU帧率和GPU帧率上的性能稳定性。折线91为根据不同版本的M游戏引擎的CPU帧率对应的第三数据绘制出的折线，折线92为根据不同版本的M游戏引擎的GPU帧率对应的第三数据绘制出的折线，由折线91可以看出，M游戏引擎的不同版本在CPU帧率上的性能是稳定的，由折线92可以看出，M游戏引擎的不同版本在GPU帧率上的性能也是稳定的。

图10是本实施例提供的另一追踪游戏引擎的性能指标的示意图。

如图10所示，采用本实施例提供的游戏引擎的性能测试系统对M游戏引擎的多个版本进行的性能测试，在性能测试过程中，以多个设备作为测试部，通过环境控制部为每一次性能测试提供相同的测试环境，每一次性能测试也采用相同的测试用例，因此，多个版本的性能测试所获得的数据具有可比性。在图10中显示的数据为针对CPU帧率的性能测试数据，横坐标表示待测试的M游戏引擎的不同版本的版本号，纵坐标表示CPU帧率的数值，以折线图的形式表示不同版本的M游戏引擎在CPU帧率上的性能稳定性。折线101为根据测试设备1生成的不同版本的M游戏引擎的CPU帧率对应的第三数据绘制出的折线，折线102为根据测试设备2生成的不同版本的M游戏引擎的CPU帧率对应的第三数据绘制出的折线，由折线101可以看出，M游戏引擎的不同版本在测试设备1上CPU帧率性能是稳定的，由折线102可以看出，M游戏引擎的不同版本在测试设备2上CPU帧率性能也是稳定的。

当然，也可以第二数据作为待处理数据，获得不同版本的游戏引擎在每一个测试轮次中的比较图，在此不再进行详细说明。

上述第一实施例以多种可选实现方式对游戏引擎的性能测试系统进行了详细说明，具体的，通过增加环境控制部使得测试结果更可靠、更准确，通过增加指标存储部，使得测试结果更加详细，通过对测试部进行采样，增加了测试部的市场占有率，使得测试结果的适用度增高，通过对性能指标的拆分与增加，以及对测试用例的分模块设计，使得测试结果细粒度化，可用度更高。总之，本实施例所述的游戏引擎的性能测试系统提供了专门针对游戏引擎的性能测试方案，为游戏开发者的游戏引擎筛选提供了可靠、精准的依据。

需要说明的是，本实施例中的示例仅是为了对本申请所述的方法做出解释，并不作为实际使用的限定，本申请提供的游戏引擎的性能测试系统包括但不限于本实施例所述的方法。

本申请第二实施例提供了一种游戏引擎的性能测试方法，本实施例提供的方法用于控制本申请第一实施例所述的游戏引擎的性能测试系统。

图11是本实施例提供的游戏引擎的性能测试方法的流程图。以下结合图11对本实施例提供的游戏引擎的性能测试方法进行详细描述。以下描述所涉及的实施例用于解释本申请的技术方案，并不作为实际使用的限定。

如图11所示，本实施例提供的游戏引擎的性能测试方法包括如下步骤S1110至步骤S1130：

步骤S1110，控制测试部启动第一游戏引擎，并使用所述第一游戏引擎运行预设的测试用例，所述测试用例为基于所述第一游戏引擎制作的应用程序，所述第一游戏引擎为所述游戏引擎对应的待测试版本。

步骤S1120，控制环境控制部为所述测试部提供测试环境，以保证所述测试部使用所述第一游戏引擎运行所述测试用例的进程中，所述测试环境不发生变化。

步骤S1130，控制指标监控部实时从所述测试部获取预设的性能指标对应的第一数据，所述第一数据为所述测试部使用所述第一游戏引擎运行所述测试用例的进程中，实时产生的原始数据。

在一可选实现方式中，本实施例所述的方法部署在服务端，本申请第一实施例提供的系统作为用户端为测试者所用。当测试者通过用户端向服务端发出测试启动请求后，服务端即可根据本实施例提供的方法，对游戏引擎的性能测试系统中的各个组件进行控制，以实现各个组件的功能。

在一可选实现方式中，所述性能测试至少包括一个测试轮次，本实施例提供的方法还包括如下步骤S21至步骤S22：

步骤S21，根据测试轮次的预设数量，控制所述测试部使用所述第一游戏引擎重复运行所述测试用例。

步骤S22，控制所述环境控制部为每一个测试轮次提供相同的测试环境。

通过控制环境控制部为每一个测试轮次提供相同的测试环境，才能够使每一个测试轮次产生的测试数据具有可比性。

在一可选实现方式中，由于游戏引擎的性能测试系统还包括指标存储部，因此，本实施例提供的方法还包括如下步骤S31至步骤34：

步骤S31，控制指标存储部从所述指标监控部获取所述性能指标的第一数据。

步骤S32，控制所述指标存储部对所述性能指标的第一数据进行数据处理，生成每一个测试轮次对应的所述性能指标的第二数据，以及所述性能测试对应的所述性能指标的第三数据，其中，所述第二数据用于表征所述性能指标在所述性能测试的每一个测试轮次中的数据状态，所述第三数据用于表征所述性能指标在所述性能测试中的数据状态。

步骤S33，控制所述指标存储部存储每一个测试轮次对应的所述性能指标的第二数据、以及所述性能测试对应的所述性能指标的第三数据。

步骤S34，响应于客户端发送的针对所述第一游戏引擎的性能指标获取请求，控制所述指标存储部向所述客户端发送每一个测试轮次对应的所述性能指标的第二数据、和/或所述性能测试对应的所述性能指标的第三数据。

通过上述步骤对性能测试获得的原始数据(第一数据)进行多维度、多次数的数据处理，获得可以从多个角度判断第一游戏引擎的稳定性的总结性数据，如，第二数据、第三数据，为游戏开发者提供细粒度化的性能测试结果。

在一可选实现方式中，本实施例提供的方法还包括如下步骤S35至步骤36：

步骤S35，控制所述指标存储部生成针对所述游戏引擎的所述性能指标的第四数据，所述第四数据用于表征所述性能指标在所述第一游戏引擎和第二游戏引擎之间的差异状态，所述第二游戏引擎为所述游戏引擎对应的至少一个已测试版本。

步骤S36，控制所述指标存储部以示图的形式将所述第四数据发送给所述客户端，以使所述客户端显示所述性能指标在所述第一游戏引擎和所述第二游戏引擎之间的变化趋势图。

通过上述步骤对游戏引擎的不同版本的性能进行跟踪，并以变化趋势图的形式展示给游戏开发者，能够使游戏开发者从长远的角度了解到该游戏引擎的性能稳定性和可信程度。

在一可选实现方式中，由于游戏引擎的性能测试系统还包括测试用例设置部，因此，本实施例提供的方法还包括如下步骤：

响应于基于所述第一游戏引擎对所述测试用例的制作操作，控制测试用例设置部生成所述测试用例，并将所述测试用例发送给所述测试部。

在本申请第一实施例中已对游戏引擎的性能测试系统中的各个组件(如，测试部、环境控制部、指标监控部、指标存储部、测试用例设置部)、以及测试时的测试用例、性能指标等进行了说明，在本实施例中不再进行赘述，具体内容可参考第一实施例中的详细描述。

上述第二实施例提供了一种游戏引擎的性能测试方法，该方法用于对游戏引擎的性能测试系统进行控制。需要说明的是，本实施例中的示例仅是为了对本申请所述的方法做出示例性解释，并不作为实际使用的限定，本申请提供的游戏引擎的性能测试方法包括但不限于本实施例所述的方法。

本申请第三实施例提供了一种游戏引擎的性能测试装置，该装置用于控制本申请第一实施例提供的游戏引擎的性能测试系统。图12是本实施例提供的游戏引擎的性能测试装置的结构示意图。

如图12所示，本实施例提供的游戏引擎的性能测试装置，包括：测试部控制单元1201、环境控制部控制单元1202、指标监控部控制单元1203。

所述测试部控制单元1201，用于控制测试部启动第一游戏引擎，并使用所述第一游戏引擎运行预设的测试用例，所述测试用例为基于所述第一游戏引擎制作的应用程序，所述第一游戏引擎为所述游戏引擎对应的待测试版本。

所述环境控制部控制单元1202，用于控制环境控制部为所述测试部提供测试环境，以保证所述测试部使用所述第一游戏引擎运行所述测试用例的进程中，所述测试环境不发生变化。

可选的，所述性能测试至少包括一个测试轮次；所述环境控制部控制单元1202还用于：

根据测试轮次的预设数量，控制所述测试部使用所述第一游戏引擎重复运行所述测试用例；

控制所述环境控制部为每一个测试轮次提供相同的测试环境。

所述指标监控部控制单元1203，用于控制指标监控部实时从所述测试部获取预设的性能指标对应的第一数据，所述第一数据为所述测试部使用所述第一游戏引擎运行所述测试用例的进程中，实时产生的原始数据。

可选的，所述装置还包括：指标存储部控制单元；所述指标存储部控制单元用于：

控制指标存储部从所述指标监控部获取所述性能指标的第一数据；

控制所述指标存储部对所述性能指标的第一数据进行数据处理，生成每一个测试轮次对应的所述性能指标的第二数据，以及所述性能测试对应的所述性能指标的第三数据，其中，所述第二数据用于表征所述性能指标在所述性能测试的每一个测试轮次中的数据状态，所述第三数据用于表征所述性能指标在所述性能测试中的数据状态；

控制所述指标存储部存储每一个测试轮次对应的所述性能指标的第二数据、以及所述性能测试对应的所述性能指标的第三数据；

响应于客户端发送的针对所述第一游戏引擎的性能指标获取请求，控制所述指标存储部向所述客户端发送每一个测试轮次对应的所述性能指标的第二数据、和/或所述性能测试对应的所述性能指标的第三数据。

可选的，还用于：

控制所述指标存储部生成针对所述游戏引擎的所述性能指标的第四数据，所述第四数据用于表征所述性能指标在所述第一游戏引擎和第二游戏引擎之间的差异状态，所述第二游戏引擎为所述游戏引擎对应的至少一个已测试版本；

控制所述指标存储部以示图的形式将所述第四数据发送给所述客户端，以使所述客户端显示所述性能指标在所述第一游戏引擎和所述第二游戏引擎之间的变化趋势图。

可选的，所述装置还包括：测试用例设置部控制单元；所述测试用例设置部控制单元用于：

响应于基于所述第一游戏引擎对所述测试用例的制作操作，控制测试用例设置部生成所述测试用例，并将所述测试用例发送给所述测试部。

本申请第四实施例提供了一种电子设备，图13是本实施例提供的电子设备的结构示意图。

如图13所示，本实施例提供的电子设备，包括：存储器1301、处理器1302；

所述存储器1301，用于存储执行游戏引擎的性能测试方法的计算机指令；

所述处理器1302，用于执行存储于所述存储器1301中的计算机指令，以执行如下操作：

控制测试部启动第一游戏引擎，并使用所述第一游戏引擎运行预设的测试用例，所述测试用例为基于所述第一游戏引擎制作的应用程序，所述第一游戏引擎为所述游戏引擎对应的待测试版本；

控制环境控制部为所述测试部提供测试环境，以保证所述测试部使用所述第一游戏引擎运行所述测试用例的进程中，所述测试环境不发生变化；

控制指标监控部实时从所述测试部获取预设的性能指标对应的第一数据，所述第一数据为所述测试部使用所述第一游戏引擎运行所述测试用例的进程中，实时产生的原始数据。

可选的，所述性能测试至少包括一个测试轮次，还执行：

根据测试轮次的预设数量，控制所述测试部使用所述第一游戏引擎重复运行所述测试用例；

控制所述环境控制部为每一个测试轮次提供相同的测试环境。

可选的，还执行：

控制指标存储部从所述指标监控部获取所述性能指标的第一数据；

控制所述指标存储部对所述性能指标的第一数据进行数据处理，生成每一个测试轮次对应的所述性能指标的第二数据，以及所述性能测试对应的所述性能指标的第三数据，其中，所述第二数据用于表征所述性能指标在所述性能测试的每一个测试轮次中的数据状态，所述第三数据用于表征所述性能指标在所述性能测试中的数据状态；

控制所述指标存储部存储每一个测试轮次对应的所述性能指标的第二数据、以及所述性能测试对应的所述性能指标的第三数据；

响应于客户端发送的针对所述第一游戏引擎的性能指标获取请求，控制所述指标存储部向所述客户端发送每一个测试轮次对应的所述性能指标的第二数据、和/或所述性能测试对应的所述性能指标的第三数据。

可选的，还执行：

控制所述指标存储部生成针对所述游戏引擎的所述性能指标的第四数据，所述第四数据用于表征所述性能指标在所述第一游戏引擎和第二游戏引擎之间的差异状态，所述第二游戏引擎为所述游戏引擎对应的至少一个已测试版本；

控制所述指标存储部以示图的形式将所述第四数据发送给所述客户端，以使所述客户端显示所述性能指标在所述第一游戏引擎和所述第二游戏引擎之间的变化趋势图。

可选的，还执行：

响应于基于所述第一游戏引擎对所述测试用例的制作操作，控制测试用例设置部生成所述测试用例，并将所述测试用例发送给所述测试部。

本申请第五实施例提供了一种计算机可读存储介质，计算机可读存储介质包括计算机指令，计算机指令在被处理器执行时用于实现本申请各实施例所述的方法。

需要注意的是，本文中的“第一”、“第二”等关系术语仅用于区分一个实体或操作与另一个实体或操作，并不要求或暗示这些实体或操作之间存在任何实际的关系或顺序。此外,“包括”、“有”,“包含”和“包括”和其他类似形式的词语在含义上是相同的，并且，在上述任何一个词语之后的任何一个或者多个项目的结尾是开放式的，上述任何一个名词均不表示所述一个或多个项目已经列举穷尽，或者仅限于这些已列举的一个或者多个项目。

在本文中使用时，除非另有明确说明，术语“或”包括所有可能的组合，但不可行的除外。例如，如果表达为一个数据库可能包括A或B，则除非另有特别规定或不可行，可能包括数据库A，或B，或者A和B。第二个例子，如果表达为某个数据库可能包括A、B或C，则除非另有特别规定或不可行，所述数据库可以包括数据库A、或B、或C、或者A和B、或者A和C、或者B和C、或者A和B和C。

值得注意的是，上述实施例可以通过硬件或软件(程序代码)，或硬件和软件的组合来实现。如果由软件实现，则可将其存储在上述计算机可读介质中。该软件在由处理器执行时，可以执行上述已披露的方法。本公开中描述的计算单元和其他功能单元可以由硬件或软件，或硬件和软件的组合来实现。本领域普通技术人员，也会理解上述多个模块/单元可以组合成一个模块/单元，而上述每个模块/单元可以进一步划分为多个子模块/子单位。

在上述详细说明中，实施例已参照许多具体细节进行了描述，这些细节可能因实施而异。可以对所述实施例进行某些适配和修改。对于本领域的技术人员，可以从本申请公开的具体实施方式中，显而易见的获得其它一些实施方式。本说明书和示例仅出于示例性的目的，本申请的真实范围和本质由权利要求说明。示图所示的步骤顺序也仅出于解释说明的目的，并不意味着限定于任何特定的步骤、顺序。因此，那些精通本领域的技术人员会意识到，在实施相同的方法时，这些步骤可以以不同的顺序执行。

在本申请的示图和详细说明中，公开了示例性的实施例。但是，可以对这些实施例进行许多变化和修改。相应的，尽管使用了具体的术语，但这些术语只是一般和描述性的，而不是出于限定的目的。

Claims (22)

1.一种游戏引擎的性能测试系统，其特征在于，所述系统包括：

测试部，基于预设的测试用例，对第一游戏引擎进行性能测试，所述测试用例为基于所述第一游戏引擎制作的应用程序，所述第一游戏引擎为所述游戏引擎对应的待测试版本，所述性能测试包括至少一个测试轮次；

环境控制部，为所述测试部提供环境控制，以保证所述第一游戏引擎在所述测试部上进行所述性能测试时，每一个测试轮次的测试环境相同，以及在每一个测试轮次的测试进程中，测试环境不发生变化；

指标监控部，在所述第一游戏引擎的测试进程中，实时从所述测试部获取预设的性能指标对应的第一数据，并实时显示所述第一数据，所述第一数据为所述测试部进行所述第一游戏引擎的所述性能测试时，实时产生的原始数据。

2.根据权利要求1所述的系统，其特征在于，所述系统还包括：

指标存储部；所述指标存储部用于：

响应于从所述指标监控部获取到所述性能指标的第一数据，针对每一个测试轮次，对所述性能指标的第一数据进行数据处理，生成每一个测试轮次对应的所述性能指标的第二数据，所述第二数据用于表征所述性能指标在所述性能测试的每一个测试轮次中的数据状态；

存储每一个测试轮次对应的所述性能指标的第二数据；

响应于客户端发送的针对所述第一游戏引擎的性能指标获取请求，向所述客户端发送每一个测试轮次对应的所述性能指标的第二数据。

3.根据权利要求2所述的系统，其特征在于，所述对所述性能指标的第一数据进行数据处理，至少包括以下处理方式中的一种：

平均值计算、最大值筛选、最小值筛选、标准差计算。

4.根据权利要求2所述的系统，其特征在于，在所述针对每一个测试轮次，对所述性能指标的第一数据进行数据处理，生成每一个测试轮次对应的所述性能指标的第二数据的步骤之后，所述指标存储部还用于：

针对所述性能测试，对每一个测试轮次对应的所述性能指标的第二数据进行数据处理，生成所述性能测试对应的所述性能指标的第三数据，所述第三数据用于表征所述性能指标在所述性能测试中的数据状态；

所述存储每一个测试轮次对应的所述性能指标的第二数据，包括：

存储所述性能测试对应的所述性能指标的第三数据；

所述响应于客户端发送的针对所述第一游戏引擎的性能指标获取请求，向所述客户端发送每一个测试轮次对应的所述性能指标的第二数据，包括：

向所述客户端发送所述性能测试对应的所述性能指标的第三数据。

5.根据权利要求4所述的系统，其特征在于，所述对每一个测试轮次对应的所述性能指标的第二数据进行数据处理，至少包括以下处理方式中的一种：

平均值计算、最大值筛选、最小值筛选、标准差计算。

6.根据权利要求4所述的系统，其特征在于，所述指标存储部还存储有针对第二游戏引擎的所述性能测试对应的所述性能指标的第三数据，所述第二游戏引擎为所述游戏引擎对应的至少一个已测试版本；

在所述针对所述性能测试，对每一个测试轮次对应的所述性能指标的第二数据进行数据处理，生成所述性能测试对应的所述性能指标的第三数据的步骤之后，所述指标存储部还用于：

对所述第一游戏引擎对应的所述性能指标的第三数据、以及所述第二游戏引擎对应的所述性能指标的第三数据进行数据处理，生成针对所述游戏引擎的所述性能指标的第四数据，所述第四数据用于表征所述性能指标在所述第一游戏引擎和所述第二游戏引擎之间的差异状态；

所述存储所述性能测试对应的所述性能指标的第三数据，包括：

存储所述游戏引擎的所述性能指标的第四数据；

所述向所述客户端发送所述性能测试对应的所述性能指标的第三数据，包括：

向所述客户端发送针对所述游戏引擎的所述性能指标的第四数据。

7.根据权利要求6所述的系统，其特征在于，所述第四数据以视图的形式表示；

所述对所述第一游戏引擎对应的所述性能指标的第三数据、以及所述第二游戏引擎对应的所述性能指标的第三数据进行数据处理，包括：

根据所述第一游戏引擎对应的所述性能指标的第三数据、以及所述第二游戏引擎对应的所述性能指标的第三数据，制作所述性能指标在所述第一游戏引擎和所述第二游戏引擎之间的变化趋势图。

8.根据权利要求1所述的系统，其特征在于，所述系统还包括：

测试用例设置部；所述测试用例设置部用于：

响应于基于所述第一游戏引擎对所述测试用例的制作操作，生成所述测试用例；

将所述测试用例发送给所述测试部。

9.根据权利要求1所述的系统，其特征在于，所述测试用例至少包括以下用例中的一种：

空场景用例，用于测试所述第一游戏引擎的空转性能；

中央处理器计算密集型用例，用于测试所述第一游戏引擎在处理计算密集型任务时的性能；

图形处理器计算密集型用例，用于测试所述第一游戏引擎在处理图形密集型任务时的性能；

材质用例，用于测试所述第一游戏引擎在图形渲染方面的性能；

动画用例，用于测试所述第一游戏引擎在处理并发动画时的性能；

植被用例，用于测试所述第一游戏引擎在植被渲染方面的性能。

10.根据权利要求1所述的系统，其特征在于，所述测试部包括能够承载所述第一游戏引擎的多个设备中的至少一个，所述多个设备对应的中央处理器和图形处理器的市场占有率大于90％。

11.根据权利要求1所述的系统，其特征在于，所述环境控制部包括第一控制设备和第二控制设备；

所述第一控制设备，用于控制所述测试部的温度状态、湿度状态、灰尘状态、以及网络状态；

所述第二控制设备，用于控制所述测试部的电量状态。

12.根据权利要求11所述的系统，其特征在于，所述第一控制设备至少包括恒温恒湿箱，所述第二控制设备至少包括电流仪；

所述环境控制部，为所述测试部提供环境控制，包括：

所述测试部置于所述恒温恒湿箱中，所述电流仪为所述测试部供电。

13.根据权利要求1所述的系统，其特征在于，所述性能指标至少包括以下指标中的一种：

帧率指标、功耗指标、内存指标、图形处理器占用指标、中央处理器占用指标。

14.根据权利要求13所述的系统，其特征在于，

所述帧率指标，包括：逻辑帧率指标和渲染帧率指标；其中，所述渲染帧率指标包括绘制调用指标和三角面指标；

所述内存指标，至少包括以下指标中的一种：总内存指标、可用内存指标、使用内存指标、缓存内存指标、缓冲区内存指标、比例集大小指标、独享集大小指标、交换空间指标、堆内存指标、显示和渲染内存指标、追踪内存指标、释放内存指标、压缩内存指标。

15.一种游戏引擎的性能测试方法，其特征在于，所述方法用于控制如权利要求1至14任意一项所述的系统，所述方法包括：

控制测试部启动第一游戏引擎，并使用所述第一游戏引擎运行预设的测试用例，所述测试用例为基于所述第一游戏引擎制作的应用程序，所述第一游戏引擎为所述游戏引擎对应的待测试版本；

控制环境控制部为所述测试部提供测试环境，以保证所述测试部使用所述第一游戏引擎运行所述测试用例的进程中，所述测试环境不发生变化；

控制指标监控部实时从所述测试部获取预设的性能指标对应的第一数据，所述第一数据为所述测试部使用所述第一游戏引擎运行所述测试用例的进程中，实时产生的原始数据。

16.根据权利要求15所述的方法，其特征在于，所述性能测试至少包括一个测试轮次，所述方法还包括：

根据测试轮次的预设数量，控制所述测试部使用所述第一游戏引擎重复运行所述测试用例；

控制所述环境控制部为每一个测试轮次提供相同的测试环境。

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

控制指标存储部从所述指标监控部获取所述性能指标的第一数据；

控制所述指标存储部对所述性能指标的第一数据进行数据处理，生成每一个测试轮次对应的所述性能指标的第二数据，以及所述性能测试对应的所述性能指标的第三数据，其中，所述第二数据用于表征所述性能指标在所述性能测试的每一个测试轮次中的数据状态，所述第三数据用于表征所述性能指标在所述性能测试中的数据状态；

控制所述指标存储部存储每一个测试轮次对应的所述性能指标的第二数据、以及所述性能测试对应的所述性能指标的第三数据；

响应于客户端发送的针对所述第一游戏引擎的性能指标获取请求，控制所述指标存储部向所述客户端发送每一个测试轮次对应的所述性能指标的第二数据、和/或所述性能测试对应的所述性能指标的第三数据。

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

控制所述指标存储部生成针对所述游戏引擎的所述性能指标的第四数据，所述第四数据用于表征所述性能指标在所述第一游戏引擎和第二游戏引擎之间的差异状态，所述第二游戏引擎为所述游戏引擎对应的至少一个已测试版本；

控制所述指标存储部以示图的形式将所述第四数据发送给所述客户端，以使所述客户端显示所述性能指标在所述第一游戏引擎和所述第二游戏引擎之间的变化趋势图。

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

响应于基于所述第一游戏引擎对所述测试用例的制作操作，控制测试用例设置部生成所述测试用例，并将所述测试用例发送给所述测试部。

20.一种游戏引擎的性能测试装置，其特征在于，所述装置用于控制如权利要求1至14任意一项所述的系统，所述装置包括：测试部控制单元、环境控制部控制单元、指标监控部控制单元；

所述测试部控制单元，用于控制测试部启动第一游戏引擎，并使用所述第一游戏引擎运行预设的测试用例，所述测试用例为基于所述第一游戏引擎制作的应用程序，所述第一游戏引擎为所述游戏引擎对应的待测试版本；

所述环境控制部控制单元，用于控制环境控制部为所述测试部提供测试环境，以保证所述测试部使用所述第一游戏引擎运行所述测试用例的进程中，所述测试环境不发生变化；

所述指标监控部控制单元，用于控制指标监控部实时从所述测试部获取预设的性能指标对应的第一数据，所述第一数据为所述测试部使用所述第一游戏引擎运行所述测试用例的进程中，实时产生的原始数据。

21.一种电子设备，其特征在于，包括：存储器、处理器；

所述存储器，用于存储一条或多条计算机指令；

所述处理器，用于执行所述一条或多条计算机指令，以实现如权利要求15-19任意一项所述的方法。

22.一种计算机可读存储介质，其上存储有一条或多条计算机指令，其特征在于，该指令被处理器执行时，执行如权利要求15-19任意一项所述的方法。