CN110059004A

CN110059004A - 一种应用测试的方法、装置、设备和介质

Info

Publication number: CN110059004A
Application number: CN201910216326.0A
Authority: CN
Inventors: 党万春
Original assignee: Shenzhen Tencent Information Technology Co Ltd
Current assignee: Shenzhen Tencent Information Technology Co Ltd
Priority date: 2019-03-21
Filing date: 2019-03-21
Publication date: 2019-07-26
Anticipated expiration: 2039-03-21
Also published as: CN110059004B

Abstract

本申请属于测试技术领域，公开了一种应用测试的方法、装置、设备和介质，本申请公开的一种应用测试的方法包括，第一应用响应启动操作显示业务界面；响应于针对业务界面中用于开启测试的功能控件的触发操作，将测试开启指令，通过状态共享内存传输至第二应用，使得第二应用执行测试操作，并将测试数据存入数据共享内存；若检测到数据共享内存中存在更新数据，则通过数据共享内存，获得第二应用的测试数据；根据获得的测试数据，生成测试结果，并在业务界面显示测试结果。这样，可以应用于各种应用场景，适用范围广，提高性能数据获取的覆盖面以及精确性。

Description

一种应用测试的方法、装置、设备和介质

技术领域

本申请涉及测试技术领域，尤其涉及一种应用测试的方法、装置、设备和介质。

背景技术

玩家在体验游戏的过程中，若游戏客户端卡顿会严重降低玩家的体验。因此，为进一步提高游戏客户端的性能，测试人员需要获取游戏客户端运行时的性能数据进而确定卡顿定位原因。

现有技术下，通常采用多种不同的测试应用同时对游戏客户端的性能数据进行收集，并且针对不同的操作系统，以及不同的游戏版本，也需要采用不同类型的测试应用。

但是，采用不同的测试应用分别收集不同的性能数据，收集的性能数据可能不全面，并且各性能数据以及时间可能无法对应，测试应用的适用范围较小。

综上所述，如何扩大测试应用的适用范围是目前需要考虑的技术问题。

发明内容

本申请实施例提供一种应用测试的方法、装置、设备和介质，用以在获取游戏客户端的性能数据时，扩大测试应用的适用范围。

一方面，提供一种应用测试的方法，包括：

第一应用响应启动操作显示业务界面；

响应于针对业务界面中用于开启测试的功能控件的触发操作，将测试开启指令，通过状态共享内存传输至第二应用，使得第二应用执行测试操作，并将测试数据存入数据共享内存；

若检测到数据共享内存中存在更新数据，则通过数据共享内存，获得第二应用的测试数据；

根据获得的测试数据，生成测试结果，并在业务界面显示测试结果。

较佳的，测试数据至少包括各测试参数的参数值；

每个测试参数的参数值是通过第二应用通过DLL对该测试参数相应的函数进行hook获得的；

DLL是第一应用响应于用于注入DLL的功能控件的触发操作，向第二应用的目标进程中注入的。

较佳的，将测试开启指令，通过状态共享内存传输至第二应用，包括：

将测试开启指令按照预先定义的数据格式序列化；

将序列化后的测试开启指令，以及序列化后的测试开启指令的指令长度，写入状态共享内存，使得第二应用执行以下步骤：若检测到状态共享内存中存在更新数据，则根据指令长度，对状态共享内存中存储的序列化后的测试开启指令进行读取以及反序列化，获得测试开启指令。

较佳的，若检测到数据共享内存中存在更新数据，则通过数据共享内存，获得第二应用的测试数据，包括：

按照预设的第一读取时长读取数据共享内存中的索引指示信息；

若索引指示信息与本地存储的上一索引指示信息不同，则判定数据共享内存中存在更新数据；

从数据共享内存中获取序列化后的测试数据的数据长度，序列化后的测试数据是第二应用按照预先定义的数据格式对测试数据进行序列化后获得的；

根据数据长度，获取共享内存中的序列化后的测试数据；

将序列化后的测试数据进行反序列化，获得第二应用的测试数据。

较佳的，进一步包括：

若索引指示信息与本地存储的上一索引指示信息相同，则判定数据共享内存中不存在更新数据；

按照预设的第二读取时长读取数据共享内存中的索引指示信息，直到索引指示信息与本地存储的上一索引指示信息不同，执行从数据共享内存中获取序列化后的测试数据的数据长度的步骤。

较佳的，进一步包括：

响应于针对业务界面中用于卡顿分析的功能控件的触发操作，根据测试数据，生成卡顿分析结果；

在业务界面显示卡顿分析结果；

卡顿分析结果至少包含测试结果、卡顿定位信息以及卡顿详情。

一方面，提供一种应用测试的装置，包括：

启动单元，用于响应启动操作显示业务界面；

写入单元，用于响应于针对业务界面中用于开启测试的功能控件的触发操作，将测试开启指令，通过状态共享内存传输至第二应用，使得第二应用执行测试操作，并将测试数据存入数据共享内存；

读取单元，用于若检测到数据共享内存中存在更新数据，则通过数据共享内存，获得第二应用的测试数据；

显示单元，用于根据获得的测试数据，生成测试结果，并在业务界面显示测试结果。

较佳的，测试数据至少包括各测试参数的参数值；

较佳的，写入单元用于：

将测试开启指令按照预先定义的数据格式序列化；

较佳的，读取单元用于：

根据数据长度，获取共享内存中的序列化后的测试数据；

较佳的，读取单元还用于：

较佳的，显示单元还用于：

在业务界面显示卡顿分析结果；

一方面，提供一种控制设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时执行上述任一种应用测试的方法的步骤。

一方面，提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述任一种应用测试的方法的步骤。

本申请实施例提供的一种应用测试的方法、装置、设备和介质中，第一应用响应启动操作显示业务界面；响应于针对业务界面中用于开启测试的功能控件的触发操作，将测试开启指令，通过状态共享内存传输至第二应用，使得第二应用执行测试操作，并将测试数据存入数据共享内存；若检测到数据共享内存中存在更新数据，则通过数据共享内存，获得第二应用的测试数据；根据获得的测试数据，生成测试结果，并在业务界面显示测试结果。这样，可以应用于各种应用场景，适用范围广，提高性能数据获取的覆盖面以及精确性。

本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施方式中一种应用测试系统的架构示意图；

图2为本申请实施方式中一种应用测试的方法的实施流程图；

图3a为本申请实施方式中一种测试应用配置的界面示例图；

图3b为本申请实施方式中一种注入DLL的界面示例图；

图3c为本申请实施方式中一种数据共享内存的数据格式示意图；

图3d为本申请实施方式中一种测试结果显示界面示意图；

图3e为本申请实施方式中一种卡顿分析结果示例图；

图3f为本申请实施方式中一种卡顿分析详情示例图；

图3g为本申请实施方式中一组基础性能数据的示例图；

图3h为本申请实施方式中一种hook函数的示意图；

图3i为本申请实施方式中一种卡顿时的渲染指标数据示例图；

图3j为本申请实施方式中单帧部分渲染指标的示例图；

图3k为本申请实施方式中一种Dump文件的解析示例图；

图3l为本申请实施方式中一种磁盘文件的读写信息示例图；

图3m为本申请实施方式中一种大内存分配示例图；

图3n为本申请实施方式中一种卡顿截图的示例图；

图4为本申请实施方式中一种应用测试的方法的交互流程图；

图5为本申请实施方式中一种应用测试的装置的结构示意图；

图6为本申请实施方式中一种控制设备的结构示意图。

具体实施方式

为了使本申请的目的、技术方案及有益效果更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

首先，对本申请实施例中涉及的部分用语进行说明，以便于本领域技术人员理解。

1、源码：就是按照一定的程序设计语言规范书写的文本文件，是一系列人类可读的计算机语言指令。编写最原始程序的代码编译后会生成可执的计算机程序。

2、DirectX：是由微软公司创建的多媒体接口，由C++编程语言实现。旨在使基于Windows的计算机成为运行具有丰富多媒体元素的应用程序的平台。应用程序可以通过使用DirectX API来访问这些新功能。例如，应用程序为游戏客户端。目前主流的Windows游戏使用的是DirectX9或DirectX11。丰富多媒体元素如全色图形、视频、3D动画以及音频等。

游戏客户端\端游：是将游戏中多种资源储存起来，为用户提供游戏服务的应用程序。玩家通过游戏客户端输入指令，游戏客户端将输入指令翻译成数据发送给服务器。服务器处理并返回结果。然后，客户端将该结果图形化表现出来展示给玩家。端游通常是指运行在Windows系统接受用户输入的指令，处理后使用DriectX来渲染图像并在显示器上输出显示的电脑游戏。

3、端游客户端性能：指游戏运行时所消耗的计算机资源，如，cpu消耗、内存消耗、图形处理器(Graphics Processing Unit，GPU)使用率、gpu显存消耗、网络流量等，分析客户端性能时需要收集客户端长期运行时这些指标的数值。不同游戏对客户端性能的要求不同，通常会关注性能数据的最大值、最小值以及平均值等指标，用来判断端游客户端性能的状况。

4、刷新率(Frame Per Second，FPS)：指每秒出现在显示器上的帧数或帧率，帧率是称为帧的位图连续出现在显示器上的速率(频率)。每秒的帧数或者帧率表示图形处理器处理图像时每秒钟能更新的次数。高的帧率可以得到更流畅的动画。FPS较低时游戏会显的不连贯有卡顿感。FPS是游戏性能的重要指标。

5、函数hook技术：一种对目标函数进行hook，用于改变函数执行结果或获取想要信息的技术。使用这种技术可以改变或增加一个函数的原有功能。基本方法是找到需要修改的函数入口点，改变它的地址指向新的自定义函数。在进行hook时要注意保存函数的上下文，防止因为hook导致程序异常或崩溃。

6、动态链接库文件(Dynamic Link Library，DLL)：是软件文件类型。在Windows系统中，许多应用程序并不是一个完整的可执行文件，它们被分割成一些相对独立的动态链接库，即DLL文件，放置于系统中。当我们执行某一个程序时，相应的DLL文件会被加载，不同DLL实现不同的软件功能。测试人员可以编写自己的DLL并让目标程序加载执行。

7、DLL远程注入技术：是指通过技术手段让其他运行中的进程执行自己编写的DLL中的代码。自己的DLL中通常会使用函数hook技术来对目标进程中执行的函数进行hook，从而改变函数执行效果或获取自己想要的信息。

其中，标准的DLL注入技术分为4步：1.在目标进程中申请一个空间。2.把准备注入的DLL路径写入到对方的进程空间中。3.创建一个远程线程，让目标进程调用LoadLibrary()函数来加载执行自己的DLL。4.释放申请的虚拟内存空间。

8、共享内存：共享内存是多进程之间的通信方法，多个进程可以共享访问同一块内存区域来读写数据，这样多个程序间可以通过共享内存来传递信息。

9、端游客户端卡顿：端游客户端卡顿的直观表现是玩家在体验游戏时感觉游戏画面卡住或者各种操作反馈有延迟。游戏卡顿表现在数据上是FPS降低。通过统计FPS值可以确定卡顿发生的时间。客户端卡顿会严重影响游戏的体验。

10、Dump文件：进程的内存镜像。可以把程序的执行状态通过调试器保存到Dump文件中。该文件内保存当前进程的寄存器和线程栈空间。通过Dump文件能够方便的保存发生问题时进程的状态，便于后续的分析。在Windows系统上可以通过MiniDumpWriteDump()函数生成Dump文件。

11、程序数据库文件(Program Database File，PDB)文件：是软件编译链接时生成的文件。PDB文件主要存储了调试程序时所需要的基本信息，主要包括源文件名、变量名、函数名、帧指针、对应的行号等信息。可以通过加载分析PDB文件把函数在内存中的地址映射成对应的函数名称。

下面介绍本申请实施例的设计思想。

玩家在体验游戏的过程中，若游戏客户端卡顿会严重降低玩家的体验。例如，用户在进行多人在线战术竞技游戏(Multiplayer Online Battle Arena，MOBA)实时对战时，游戏卡顿会导致游戏角色未释放出逃生技能或击杀技能而导致角色死亡，显然，这会极大的影响玩家的体验，使得玩家逐渐从游戏中流失。

因此，如何获取游戏客户端的性能数据以进行卡顿分析，是游戏开发测试过程中最重要的工作之一。

传统技术中，获取游戏客户端的性能数据时，通常采用不同的测试应用同时收集对游戏客户端的性能数据。

例如，采用一个测试应用收集游戏客户端的FPS数据。另一个测试应用收集内存、CPU以及IO等性能数据。但是，通过两个测试应用收集的数据，很难对应到相应的时间点，并且不能实时展示游戏的性能数据的变化。

再者，游戏客户端通常分为x86和x64位。且不同游戏可能采用DirectX9或DirectX11，因此，这样多种组合的情况要求开发人员提供对不同位数、不同DirectX版本的支持，对测试人员的要求比较高，且开发成本比较高。进一步地，卡顿通常只记录FPS值，然后根据FPS值来确定发生了卡顿，但是卡顿发生的原因无法确定。

申请人对传统技术进行分析后发现，传统技术中并没有提供一种适用范围广，并且可以实时显示游戏客户端的性能数据以及进行卡顿定位的技术方案。因此，亟待需要一种可以应用于各种应用场景的应用测试的技术方案，以获取高精度，覆盖面广的测试数据，以及定位卡顿点。

鉴于此，申请人考虑到可以采用动态注入技术将DLL注入到游戏客户端的源码中，从而在不影响游戏的正常运行的情况下，通过hook技术获取游戏客户端运行时的测试数据；将游戏客户端与测试应用通过共享内存进行测试数据以及测试指令的传输，使得测试应用可以通过测试指令控制游戏客户端的测试操作，并将游戏客户端共享的测试数据实时显示。进一步地，在获取测试数据时，若检测到存在卡顿，则将卡顿时的各种信息记录在卡顿文件中，从而可以根据指定文件对卡顿原因进行具体分析。

鉴于以上分析和考虑，本申请实施例中提供了一种应用测试的方案，该方案中，响应于针对第一应用的业务界面的用于开启测试的功能控件的触发操作，将测试开启指令通过状态共享内存传输至第二应用，以控制第二应用通过注入的DLL执行测试操作；通过数据共享内存获取第二应用采集并处理后的测试数据，并根据测试数据生成并显示测试结果。这样，就可以在各种应用场景中，仅通过第一应用，就可以获取第二应用中的所有测试数据，并可以将测试数据进行实时显示。

进一步地，第一应用根据第二应用检测到卡顿时记录的卡顿文件，生成卡顿分析结果。

为进一步说明本申请实施例提供的技术方案，下面结合附图以及具体实施方式对此进行详细的说明。虽然本申请实施例提供了如下述实施例或附图所示的方法操作步骤，但基于常规或者无需创造性的劳动在所述方法中可以包括更多或者更少的操作步骤。在逻辑上不存在必要因果关系的步骤中，这些步骤的执行顺序不限于本申请实施例提供的执行顺序。所述方法在实际的处理过程中或者装置执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行。

参阅图1所示，为一种应用测试系统的架构示意图。应用测试系统包括第一应用101、第二应用102、状态共享内存103、以及数据共享内存104。

第一应用101，用于向第二应用102注入DLL后，通过状态共享内存103将测试指令传输至第二应用102，使得第二应用102根据测试指令执行相应的测试操作；以及根据第二应用102返回的测试数据生成测试结果，并实时显示测试结果；进一步地，根据测试数据生成卡顿分析结果。

其中，DLL是第一应用101响应于用于注入DLL的功能控件的触发操作，向第二应用102的目标进程中注入的。测试数据至少包括各测试参数的参数值。每个测试参数的参数值是通过第二应用102通过DLL对该测试参数相应的函数进行hook获得的。

第二应用102，用于根据第一应用101发送的测试开启指令执行测试，并根据测试停止指令停止测试，以及将测试数据和卡顿时的卡顿文件通过数据共享内存104传输至第一应用101。

状态共享内存103，用于将第一应用101写入的测试指令传输至第二应用102。

数据共享内存104，用于将第二应用102写入的测试数据存储传输至第一应用101。

本申请实施例中，第一应用101预先将DLL注入到第二应用102中。在第一应用响应启动操作显示业务界面后，响应于针对业务界面中用于开启测试的功能控件的触发操作，将测试开启指令通过状态共享内存103传输至第二应用102。第二应用102根据测试开启指令，执行测试，并将测试数据通过数据共享内存104传输至第一应用101。第一应用101根据获得的测试数据生成测试结果，并在业务界面显示测试结果。进一步地，第一应用101响应于针对业务界面中用于卡顿分析的功能控件的触发操作，根据测试数据生成卡顿分析结果，以及在业务界面显示卡顿分析结果。其中，卡顿分析结果至少包含测试结果、卡顿定位信息以及卡顿详情。

本申请实施例中，以第一应用101为测试应用，第二应用为游戏客户端为例进行具体说明，实际应用中，第一应用101和第二应用102可以为任意应用，在此不再赘述。第一应用101和第二应用102为同一个控制设备中的两个应用。

参阅图2所示，为本申请提供的一种应用测试的方法的实施流程图。该方法的具体流程如下：

步骤200：第一应用响应启动操作显示业务界面。

具体的，以第一应用为一个可独立运行的测试应用为例进行说明，为避免收集的数据量过大降低设备性能，第一应用将收集的测试数据划分为基础数据和高级数据。

其中，基础数据为默认收集的必要数据，高级数据为根据用户的设置进行选择性收集的数据。

例如，基础数据可以为性能指标数据以及FPS，高级数据可以为渲染指标数据，即顶点总数(Total Vertices)、VBO顶点(VBO Vertices)、图元总数(TotalPrimitives)、绘图调用(glDraw*Calls)、平均透支额(Average Overdraw)、总纹理(Total Texture)。

步骤201：第一应用响应于针对业务界面中用于应用配置的功能控件的触发操作，执行相应的配置操作。

具体的，用户通过业务界面的功能控件，选择第二应用待收集的测试参数，第一应用则响应于针对业务界面中用于应用配置的功能控件的触发操作，执行相应的配置操作。

例如，参阅图3a所示，为一种测试应用配置的界面示例图。用户点击第一应用的业务界面中的“选项”功能控件，弹出设置窗口。则用户设定StandardFPS的值，即游戏平稳运行时的FPS值，并开启高级设置。其中，高级设置包括以下渲染指标：Total Vertices、VBOVertices、Total Primitives、glDraw*Calls、Average Overdraw、Total Texture。最后，点击“保存”功能控件。这样，第一应用根据用户对各功能控件的触发操作，进行相应的信息配置。第二应用会按照高级设置中的选择的渲染指标进行数据收集。

这样，用户在开启测试之前，通过用于测试配置的功能控件进行测试应用配置，第一应用根据接收的用于应用配置的功能控件的触发操作，进行相应的应用配置，以设置第二应用待收集的测试参数。

可选的，由于第一应用通常有默认的应用配置，因此，步骤201也可以不执行。

步骤202：第一应用响应于用于注入DLL的功能控件的触发操作，通过动态注入技术向第二应用注入DLL。

具体的，在启动游戏客户端进入游戏后，用户点击第一应用的注入功能控件，并在弹出的进程列表中选择目标进程，双击或右键选择注入。第一应用响应于该功能控件的触发操作，通过动态注入技术向第二应用注入DLL，若注入成功，则会弹出注入成功的提示。

例如，参阅图3b所示，为一种注入DLL的界面示例图。用户启动第一应用后，在业务界面点击“注入”功能控件，在弹出的进程列表中选择第二应用的目标进程，双击或单击右键选择注入，则第一应用向第二应用注入DLL。在注入成功后，弹出图3b所示的注入成功的提示。

步骤203：第一应用响应于针对业务界面中用于开启测试的功能控件的触发操作，将序列化后的测试开启指令写入状态共享内存。

具体的，用户点击业务界面中用于开启测试的功能控件(如，图3b所示的开始功能控件)，第一应用响应于该功能控件的触发操作，将测试指令按照预先定义的数据格式进行序列化，并将序列化后的测试开启指令以及序列化后的测试开启指令的指令长度写入状态共享内存。

其中，状态共享内存用于存储测试指令。状态共享内存的数据包括测试指令以及指令长度两部分。状态共享内存通常采用前面的指定个数(如，4个)的字节存储序列化后的测试指令的指令长度，其余部分用于存储序列化后的测试指令。序列化后的测试指令通常为字符串的形式。

可选的，测试指令可以为测试开启指令以及测试停止指令等。测试指令可以采用一个或多个状态标志位的形式进行信息传递。数据格式可以采用一种轻便高效的结构化数据存储格式(Google Protocol Buffe，protobuf)。使用protobuf序列化，可用跨语言传输数据，且不会有变量格式的差别，避免了数据格式转换导致的数据错乱问题。

例如，一种状态共享内存的名称为GameHackerStatus_SM_id，大小为1024*10。状态位共享内存的前4个字节为序列化后的测试指令的指令长度，后面是按照protobuf序列化后的测试指令。一种protobuf文件GameHStatus.proto核心定义如下：

其中，整个状态共享内存的作用是由required SMCategory Status(enum类型)变量控制的。RESET、SET、START、STOP四个状态标志位标示了当前状态共享内存的作用：这样，就可以按照上述核心定义对状态标志位(即测试指令)进行protobuf序列化。

RESET：当第一应用开启或者重新启动时一般需要设置这个状态标志位，重置各种状态标志位。

SET：针对第一应用advance setting里的各类设置进行传递。

START：开始保存测试数据文件，同时收集测试数据，以及截图操作。

STOP：结束数据采集，不再进行其他操作。

这样，第一应用和第二应用通过状态共享内存进行测试指令的传递。第一应用将测试指令写入状态共享内存，第二应用从状态共享内存中读取测试指令。

步骤204：第二应用若检测到状态共享内存中存在更新数据，则获取共享内存中的指令长度，并根据指令长度对状态共享内存中存储的序列化后的测试开启指令进行读取以及反序列化。

具体的，第二应用周期性读取状态共享内存中在前面的指定个数的字节的数据，获得指令长度，若该指令长度符合预设读取条件，则判定状态共享内存已经更新，则根据获取的指令长度，对状态共享内存中存储的序列化后的测试开启指令进行读取并反序列化，获得反序列化后的测试开启指令。

进一步地，第二应用在读取状态共享内存中的数据后，将状态共享内存中的指令长度设置为指定长度，如0，以表示状态共享内存已经读取。若第二应用读取的指令长度为上述指定长度，则判定状态共享内存未更新，否则，判定状态共享内存已经更新。

步骤205：第二应用根据读取的测试开启指令，周期性采集测试数据。

具体的，测试开启指令还包含应用配置的配置信息，即设置的第二应用待收集的测试参数。第二应用按照预设的采集时长，通过第一应用注入的DLL，采用hook技术对每一测试参数相应的函数进行hook获得相应的采集值，并根据每一测试参数的采集值进行数据处理，获得相应参数值。

其中，hook技术：一种对目标函数进行hook，以改变函数执行结果或获取想要信息的技术。这种技术可以改变或增加一个函数的原有功能。基本方法是找到需要修改的函数入口点，改变它的地址指向新的自定义函数。在进行hook时要注意保存函数的上下文，防止因为hook导致程序异常或崩溃。

可选的，第二应用可以采用C++实现。测试参数可以为FPS、CPU使用率、内存占用大小、GPU的使用率、GPU显存的占用、以及磁盘文件的读写速率(IO read/write)等。针对不同位数的第二应用，分别注入提供相应的hook功能的DLL。

这样，针对不同的应用场景，只要选择不同的DLL就可以进行应用测试，应用范围广。

本申请实施例中，以下面的多个测试参数的获取方式进行示例说明，实际应用中，可以根据实际的应用场景采用相应的获取方式，在此不再赘述。

一种实施方式中，由于present函数每执行一次，就会在屏幕上更新一帧图像，因此，可以启动一个dx线程，在dx线程里通过hook DirectX的present()函数，统计每秒内present函数的执行次数，并将执行次数确定为FPS。一种针对DirectX9present()函数的hook的核心代码示例如下：

具体的，针对DirectX9，通过hook Direct3DCreate9获得类型为LPDIRECT3D9的Direct3D对象的接口指针，并根据Direct3D对象接口指针找到Direct3D对象的虚函数表，以及根据虚函数表确定IDirect3D9::CreateDevice的内存地址。其中，IDirect3D9::CreateDevice为Direct3D对象的一个成员函数。接着，通过hook IDirect3D9::CreateDevice，获得类型为LPDIRECT3DDEVICE9的设备对象指针,并根据设备对象指针找到设备对象的虚函数表，以及根据虚函数表找到IDirect3DDevice9::Present在内存中的地址，对其进行hook，获得FPS。

类似的，针对DirectX11precent()函数的hook核心代码示例如下：

HRESULT__stdcall New_D3D11_Present(IDXGISwapChain*pSwapChain，UINTSyncInterval，UINT Flags)

{++currentTotalFps；//总fps+1

return D3D11_pPresent(pSwapChain，SyncInterval，Flags)；}

DirectX11的FPS获取方式与DirectX9的FPS获取方式类似。由于DirectX11有很多变化，因此，在实际的技术实现中需要做相应的处理。

上述precent()函数的hook核心代码的核心功能是在原始的precent()函数中增加了FPS计数累加，并每秒存储当前precent()函数执行的总次数fps+1，通过这种方式，就可以统计每秒的precent()函数的执行次数，从而计算出当前的FPS值。

一种实施方式中，第二应用通过当前程序运行时对CPU时间片的占用比获得的CPU使用率。

一种实施方式中，以win7为例，第二应用获取目标进程对PrivateWorkingSet中占用的内存页的数量，并将该数量乘以每个内存页的大小，获得内存占大小。其中，针对不同操作系统，计算内存占大小的方式不同，在此不做限制。

一种实施方式中，第二应用调用Windows内核的DLL，获取GPU的使用率和GPU和显存的占用。

一种实施方式中，第二应用通过hook文件读写函数，获取对磁盘文件的读写速率，并根据获取的读写速率，确定每秒内磁盘的读取和写入速率。

一种实施方式中，对各种网络发送接收函数进行hook，获得网络数据包的个数，并根据网络数据包的个数与每一个网络数据包的长度，确定网络流量。例如，网络发送接收函数可以为send/recv、WSASend/WSARecv等。

一种实施方式中，为便于后续扩展，获取测试数据时，第二应用采用plugin插件线程的形式，一种线程示例如下：

//添加perf的hook线程

Worker*perf_worker＝new PerfWorker()；

Plugin*perf_plugin＝new PerfPlugin()；

perf_plugin->Init()；

perf_plugin->Add(perf_worker)；

PluginFramework::Instance()->Register(perf_plugin)；

另一种线程示例如下：

Worker*dx_worker＝new DxWorker()；

Plugin*dx_plugin＝new DxPlugin()；

dx_plugin->Init()；

dx_plugin->Add(dx_worker)；

PluginFramework::Instance()->Register(dx_plugin)；

可选的，可以在perf线程里进行cpu、mem、gpu、IO read/write以及send/recv等相关数据的收集，并在dx线程中采集FPS信息等。

进一步地，若第二应用根据第一应用的测试开启指令，确定开启测试时同时开启卡顿记录功能，则周期性根据测试数据检测是否存在卡顿，若确定存在卡顿，则将卡顿时的各种信息记录在卡顿文件中，从而可以在后续步骤中根据指定文件对卡顿原因进行具体分析。

可选的，由于卡顿分析相关的测试参数的数据量较大，因此，第二应用仅在确定开启卡顿记录功能时，开始采集卡顿分析相关的信息。

下面以获取卡顿分析相关的渲染指标数据为例进行说明：

由于若在卡顿发生之后，再获取后续的渲染指标对卡顿定位帮助不大，因此渲染指标数据不能在卡顿发生之后再去统计，需要提前监控一段时间内每帧的渲染指标。又由于各渲染指标相关的数据量较大，不能全部保存到本地，因此，本申请实施例中，采用队列的方式存储渲染指标数据。

具体的，定义一个包含各渲染指标成员的单例对象，然后，将每一帧的渲染指标数据更新到该单例对象，并将更新后的单例对象写入渲染队列。在发生卡顿时，将该渲染队列中的所有单例对象写到本地的卡顿文件，并清空该渲染队列，使得渲染队列重新开始更新数据。

其中，渲染队列是一种先进先出的数据结构，渲染队列的队列长度是根据配置信息中包含的平均PFS设置的。

这样，当渲染队列的值达到平均PFS之后，每次渲染队列更新时，先将渲染队列中最早进入的单例对象出队，再将更新后的单例对象入队。采用这种类似滑动窗口的机制，实时记录当前的关键的渲染指标。

一种实施方式中，基于与渲染指标数据存储相似的原理，将磁盘文件读写信息写入磁盘队列，并在发生卡顿时，将磁盘队列中的信息写入本地的卡顿文件。

一种实施方式中，第二应用还获取卡顿发生时的dump文件。Dump文件用于存储第二应用的目标进程的寄存器信息、内存信息以及函数调用堆栈信息。在卡顿发生时，第二应用调用windows系统的API：MiniDumpWriteDump()可以生成一个MiniDump文件(FullDump文件虽然能包含更多的信息，但是一个文件的大小会超过1G，文件过大生成太慢)。其中，通过dump文件，可以确定那些函数发生时会发生卡顿，进而可以修改优化相关函数以解决卡顿问题。

一种实施方式中，由于大内存块的分配的系统开销比较大，可能会引起卡顿，因此，本申请实施例中，将所有大于指定大小(如，1024字节)的内存块记录到文件。

一种实施方式中，确定发生卡顿时，第二应用调用系统的截图函数进行界面截图，以可以直观的了解到哪一个画面发生了卡顿，以便实现卡顿复现和定位。

进一步地，第二应用确定发生卡顿时，将表示卡顿发生的时间点记录下来。可选的，可以采用设置卡顿标志位的方式记录。

步骤206：第二应用周期性将序列化后的测试数据写入数据共享内存。

具体的，基于与状态共享内存相似的读写原理，第二应用采用一个信息类对象周期性存储获得的测试数据，并将以信息类对象形式存储的测试数据按照指定的数据格式序列化，并将序列化后的测试数据写入数据共享内存中。

其中，测试数据还包括索引指示信息。由于共享内存(包括数据共享内存和状态共享内存)实际存储的数据长度不固定，因此，为便于读取解析，需要存储数据的长度。数据共享内存用于保存测试数据，第一应用只能读，第二应用只能写。为区分多个目标进程不同的数据共享内存，使得第一应用可以同时开启多个，同时针对多个目标进程进行测试，可以基于目标进程的进程ID对数据共享内存进行命名，如：GameHackerPerf_SM_pid，其中，pid是目标进程的进程ID。可选的，数据共享内存大小可以为1024*20字节。一种protobuf里的文件GameHproto.proto核心定义示例如下：

这样，就可以按照上述核心定义对测试数据进行protobuf序列化。本申请实施例中，采用状态共享内存和数据共享内存并存，这样，使得共享内存不会冲突，不需要加锁，提高了准确度和效率。

例如，参阅图3c所示，为一种数据共享内存的数据格式示意图。图3c中，数据共享内存的前指定个数的字节用于存储序列化后的测试数据的数据长度，其余部分用于存储序列化后的测试数据。

步骤207：第一应用若检测到数据共享内存中存在更新数据，则通过数据共享内存，获得测试数据。

具体的，第一应用按照预设的第一读取时长(如，1s)读取数据共享内存中的索引指示信息，若索引指示信息与本地存储的上一索引指示信息(即上一次获取的索引指示信息)不同，则判定数据共享内存中存在更新数据；从数据共享内存中获取序列化后的测试数据的数据长度，根据数据长度，获取共享内存中的序列化后的测试数据；将序列化后的测试数据进行反序列化，获得第二应用的测试数据。

其中，序列化后的测试数据是第二应用按照预先定义的数据格式对测试数据进行序列化后获得的。

进一步地，若索引指示信息与本地存储的上一索引指示信息相同，则判定数据共享内存中不存在更新数据；按照预设的第二读取时长(如，200ms)读取数据共享内存中的索引指示信息，直到索引指示信息与本地存储的上一索引指示信息不同，执行从数据共享内存中获取序列化后的测试数据的数据长度的步骤。

步骤208：第一应用根据测试数据生成测试结果，并在业务界面实时显示测试结果。

具体的，第一应用分别针对每一测试参数，按照预先设定的生成规则，生成测试结果，并在业务界面显示该测试结果。

可选的，生成规则可以根据实际应用场景进行设定。显示测试结果时，可以采用以下方式中的任意一种或任意组合：曲线、表格、图像以及文字。实际应用中，还可以采用其它任意形式呈现测试结果，在此不作限制。

例如，第一应用分别可以将每一测试参数的参数值以表格或曲线的形式呈现。

例如，参阅图3d所示，为一种测试结果显示界面示意图。需要指出的是，图3d仅为一种数据以曲线形式呈现的示例，图3d中的线条和文字是否清晰，不影响图示说明，即不会存在不清楚问题。图3d中所示，第一应用分别将每一测试参数的各参数值以曲线呈现，当用户在业务界面的曲线上移动鼠标时，会有浮动窗口显示鼠标指定位置的各项详细指标。当用户点击曲线时，在应用界面的下方的状态栏中也有详细的相关数据展示，以便用户查看。

步骤209：第一应用响应于停止测试的功能控件的触发操作，将测试停止指令通过状态共享内存传输至第二应用。

具体的，用户点击停止功能控件，第一应用将测试停止指令传输至第二应用，并弹出弹窗提示生成的测试文件的保存位置。

步骤210：第二应用根据获取的测试停止指令，停止测试操作。

步骤211：第一应用响应于用于卡顿分析的功能控件的触发操作，根据测试数据，生成卡顿分析结果。

具体的，卡顿分析结果至少包括测试结果、卡顿定位信息以及卡顿详情。卡顿定位详情可以根据卡顿时各测试参数的参数值、Dump文件、磁盘文件读写信息、大内存块的分配信息以及卡顿截图等获得的。

可选的，卡顿分析结果可以采用曲线、表格以及图像等任意方式或组合进行展现，并可以分别计算并呈现每一测试参数的最大值、最小值以及均值，以及根据卡顿信息，在曲线上用特殊标识(如，带颜色的圆点标识)标出。为便于用户查看，卡顿分析结果可以采用一个窗口或多个窗口进行呈现。

例如，参阅图3e所示，为一种卡顿分析结果示例图，需要指出的是，图3e仅为一种数据以曲线形式呈现的示例，图3e中的线条和文字是否清晰，不影响图示说明，即不会存在不清楚问题。图3e中，不仅包含了测试结果，还包含了发生卡顿的卡点，曲线中的每一个黑色圆点，均表示一次卡顿。其中，卡顿点是通过测试数据中包含的卡顿信息获得的。

例如，参阅图3f所示，为一种卡顿分析详情示例图。需要指出的是，图3f仅为一种卡顿分析详情以表格以及图片的组合的形式呈现的示例，图3f中的线条、文字以及截图是否清晰，不影响图示说明，即不会存在不清楚问题。当用户点击图3e中的曲线上的卡顿点时，进入图3f所示的卡顿分析详情界面，用户通过图3f，可以直观的了解卡顿发生的具体场景以及详情。

其中，卡顿分析具体包含以下几个方面：

第一、卡顿点定位：通过FPS确定每帧耗时，若每帧耗时大于指定耗时阈值，则判定出现卡顿，并将记录当前的各种测试数据以定位卡顿，以及设置一个全局标志位，以通知各线程保存游戏运行时的现场数据。

第二、根据卡顿时的基础性能数据进行卡顿分析。

例如，若CPU值过高，则说明计算过多，导致帧耗时过长，需要开发人员对游戏内各种计算进行优化。若磁盘读写速率过高，则也会导致游戏卡顿。以端游流放之路为例，每次在副本中会同时加载大量本地资源文件，导致磁盘读写速率过高，进而副本中角色卡顿严重。这样，后续研发人员需要并更同时资源加载为加载模式，这是由于读写磁盘资源文件可以减少卡游戏副本卡顿。若GPU使用率过高，则会导致游戏界面图像渲染国漫，从而出现卡顿。若游戏使用的内存过大，即由于资源加载会导致内存频繁换页，导致游戏卡顿。

例如，参阅图3g所示，为一组基础性能数据的示例图。需要指出的是，图3g仅为一种基础性能数据以表格形式呈现的示例，图3g中的文字是否清晰，不影响图示说明，即不会存在不清楚问题。图3g中显示了一组基础性能数据：CpuRate、MemUsage……。通过图3g中各基础性能数据，分析出现卡顿的原因。

第三、根据卡顿时的各渲染指标数据进行卡顿分析。若发生卡顿时各种基础性能数据表现相对正常，则可能是由于渲染时某项指标偏高引起的。例如，DrawCall数过高，即绘制图形的函数执行次数过多，或者，绘制的三角形数过多等。项渲染指标如，顶点数((Vertices)，带索引的顶点数(IndexedVertices)，Primitives等，以及函数执行数(APICalls)等。

参阅图3h所示，为一种hook函数的示意图。图3h示出了多个需要hook的函数。图3i所示，为一种卡顿时的渲染指标数据示例图。通过图3i可知，上方为一组渲染指标在分别在每一秒中的数据。选择任意指标，会在界面下方呈现该指标的变化曲线。图3i中界面下方为Vertices的值的变化曲线，显然，Vertices的值在索引为15时突然增大，因此，判定卡顿原因是由于Vertices的值较大。参阅图3j所示，为单帧部分渲染指标的示例图。图3j中为索引为11的一组渲染指标。需要指出的是，图3h和图3i仅为一种hook函数时的终端界面以及卡顿分析界面的示例图，图3h和图3i中的文字是否清晰，不影响图示说明，即不会存在不清楚问题。

第四、根据卡顿时的Dump信息进行卡顿分析。参阅图3k所示，为一种Dump文件的解析示例图。左侧展示了第二应用的所有进程标识。右侧展示了对应线程标识的函数调用信息。由于在内存中函数的标识只是一串地址，因此，pathofexile_x64:140dd979e，因此，可以通过第一应用的PDB功能控件，将地址映射为相应的函数名，以便测试人员定位卡顿原因。

第五、根据磁盘文件读写信息进行卡顿分析。参阅图3l所示，为一种磁盘文件的读写信息示例图。图3l中，展示了卡顿时部分磁盘文件的读写信息，偏移量，读写大小以及读写文件的句柄等。

第六、根据大内存块的分配信息进行卡顿分析。参阅图3m所示，为一种大内存分配示例图。图3m中，展示了大内存块的线程标识以及相应的内存块的大小。

第七、根据卡顿时的截图进行卡顿分析。当发生卡顿时，测试人员可以通过截图进行卡顿复现和定位。参阅图3n所示，为一种卡顿截图的示例图。需要指出的是，图3n仅为一种截图的示例，图3n中的线条和文字是否清晰，不影响图示说明，即不会存在不清楚问题。

这样，通过上述七方面的数据进行卡顿分析，获得如图3f所示的卡顿详情示例图。即图3f为上述图g-图3n的组合。

本申请实施例中提供的应用测试的技术方案，支持x86和x64游戏客户端，并支持DirectX9与DirectX11，以及支持Win7、Win8、Win10等系统，适用范围广，可以低门槛、低成本、实时获取游戏运行时的各种性能指标和卡顿信息，便于开发、测试人员了解游戏的性能情况。定位性能瓶颈及引发卡顿的原因，并对表现差的性能项及卡顿进行针对性优化工作，提升游戏的客户端性能，为用户提供更好的用户体验。

参阅图4所示，为本申请提供的一种应用测试的方法的交互流程图。该方法的具体流程如下：

步骤400：第一应用响应启动操作显示业务界面。

步骤401：第一应用接收用于注入DLL的功能控件的触发操作。

其中，用于注入DLL的功能控件可以为一个功能控件或一组控件。

步骤402：第一应用响应于用于注入DLL的功能控件的触发操作，向第二应用注入DLL。

步骤403：第一应用接收第二应用返回的DLL注入成功的响应消息。

步骤404：第一应用接收用于开启测试的功能控件的触发操作。

其中，用于开启测试的功能控件可以为一个或一组控件。

步骤405：第一应用响应于用于开启测试的功能控件的触发操作，将测试开启指令写入状态共享内存。

步骤406：第二应用检测状态共享内存是否更新，若确定状态共享内存更新，则读取测试开启指令。

步骤407：第二应用根据测试开启指令确定开启测试，周期性采集测试数据。

步骤408：第二应用周期性将获取的测试数据存入数据共享内存中。

步骤409：第一应用周期性读取数据共享内存中的测试数据。

步骤410：第一应用根据测试数据生成测试结果。

步骤411：第一应用在业务界面显示测试结果。

步骤412：第一应用确定接收到用于停止测试的功能控件的触发操作。

步骤413：第一应用响应于用于停止测试的功能控件的触发操作，将测试停止指令写入状态共享内存。

步骤414：第二应用检测到状态共享内存已经更新，则读取测试停止指令。

步骤415：第二应用确定接收到测试停止指令，停止数据采集。

步骤416：第一应用确定接收到用于卡顿分析的功能控件的触发操作。

步骤417：第一应用根据测试数据，生成卡顿分析结果。

步骤418：第一应用在业务界面显示卡顿分析结果。

基于同一发明构思，本申请实施例中还提供了一种应用测试的装置，由于上述装置及设备解决问题的原理与一种应用测试的方法相似，因此，上述装置的实施可以参见方法的实施，重复之处不再赘述。

如图5示，其为本申请实施例提供的一种应用测试的装置的结构示意图。一种应用测试的装置包括：

启动单元501，用于响应启动操作显示业务界面；

写入单元502，用于响应于针对业务界面中用于开启测试的功能控件的触发操作，将测试开启指令，通过状态共享内存传输至第二应用，使得第二应用执行测试操作，并将测试数据存入数据共享内存；

读取单元503，用于若检测到数据共享内存中存在更新数据，则通过数据共享内存，获得第二应用的测试数据；

显示单元504，用于根据获得的测试数据，生成测试结果，并在业务界面显示测试结果。

较佳的，测试数据至少包括各测试参数的参数值；

较佳的，写入单元502用于：

将测试开启指令按照预先定义的数据格式序列化；

较佳的，读取单元503用于：

根据数据长度，获取共享内存中的序列化后的测试数据；

较佳的，读取单元503还用于：

较佳的，显示单元504还用于：

在业务界面显示卡顿分析结果；

参阅图6所示，为一种控制设备的结构示意图。基于同一技术构思，本申请实施例还提供了一种控制设备，可以包括存储器601和处理器602。

所述存储器601，用于存储处理器602执行的计算机程序。存储器601可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据区块链节点的使用所创建的数据等。处理器602，可以是一个中央处理单元(central processing unit，CPU)，或者为数字处理单元等。本申请实施例中不限定上述存储器601和处理器602之间的具体连接介质。本申请实施例在图6中以存储器601和处理器602之间通过总线603连接，总线603在图6中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线603可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器601可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)；存储器601也可以是非易失性存储器(non-volatilememory)，例如只读存储器，快闪存储器(flash memory)，硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)、或者存储器601是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器601可以是上述存储器的组合。

处理器602，用于调用所述存储器601中存储的计算机程序时执行如图2中所示的实施例提供的应用测试的方法。

本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述任意方法实施例中的应用测试的方法。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对相关技术做出贡献的部分可以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台控制设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims

1.一种应用测试的方法，其特征在于，包括：

第一应用响应启动操作显示业务界面；

响应于针对所述业务界面中用于开启测试的功能控件的触发操作，将测试开启指令，通过状态共享内存传输至第二应用，使得所述第二应用执行测试操作，并将测试数据存入数据共享内存；

若检测到所述数据共享内存中存在更新数据，则通过所述数据共享内存，获得所述第二应用的测试数据；

根据获得的测试数据，生成测试结果，并在所述业务界面显示所述测试结果。

2.如权利要求1所述的方法，其特征在于，所述测试数据至少包括各测试参数的参数值；

每个测试参数的参数值是通过所述第二应用通过动态链接库DLL对该测试参数相应的函数进行hook获得的；

所述DLL是所述第一应用响应于用于注入DLL的功能控件的触发操作，向第二应用的目标进程中注入的。

3.如权利要求1所述的方法，其特征在于，将测试开启指令，通过状态共享内存传输至第二应用，包括：

将所述测试开启指令按照预先定义的数据格式序列化；

将序列化后的测试开启指令，以及所述序列化后的测试开启指令的指令长度，写入所述状态共享内存，使得所述第二应用执行以下步骤：若检测到所述状态共享内存中存在更新数据，则根据所述指令长度，对所述状态共享内存中存储的序列化后的测试开启指令进行读取以及反序列化，获得所述测试开启指令。

4.如权利要求1所述的方法，其特征在于，若检测到所述数据共享内存中存在更新数据，则通过所述数据共享内存，获得所述第二应用的测试数据，包括：

按照预设的第一读取时长读取所述数据共享内存中的索引指示信息；

若所述索引指示信息与本地存储的上一索引指示信息不同，则判定所述数据共享内存中存在更新数据；

从所述数据共享内存中获取序列化后的测试数据的数据长度，所述序列化后的测试数据是所述第二应用按照预先定义的数据格式对测试数据进行序列化后获得的；

根据所述数据长度，获取所述共享内存中的序列化后的测试数据；

将所述序列化后的测试数据进行反序列化，获得所述第二应用的测试数据。

5.如权利要求4所述的方法，其特征在于，进一步包括：

若所述索引指示信息与本地存储的上一索引指示信息相同，则判定所述数据共享内存中不存在更新数据；

按照预设的第二读取时长读取所述数据共享内存中的索引指示信息，直到所述索引指示信息与本地存储的上一索引指示信息不同，执行从所述数据共享内存中获取序列化后的测试数据的数据长度的步骤。

6.如权利要求1-5任一项所述的方法，其特征在于，进一步包括：

响应于针对所述业务界面中用于卡顿分析的功能控件的触发操作，根据所述测试数据，生成卡顿分析结果；

在所述业务界面显示所述卡顿分析结果；

所述卡顿分析结果至少包含所述测试结果、卡顿定位信息以及卡顿详情。

7.一种应用测试的装置，其特征在于，包括：

启动单元，用于响应启动操作显示业务界面；

写入单元，用于响应于针对所述业务界面中用于开启测试的功能控件的触发操作，将测试开启指令，通过状态共享内存传输至第二应用，使得所述第二应用执行测试操作，并将测试数据存入数据共享内存；

读取单元，用于若检测到所述数据共享内存中存在更新数据，则通过所述数据共享内存，获得所述第二应用的测试数据；

显示单元，用于根据获得的测试数据，生成测试结果，并在所述业务界面显示所述测试结果。

8.如权利要求7所述的装置，其特征在于，所述测试数据至少包括各测试参数的参数值；

9.一种控制设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权力要求1-6任一项所述的方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1～6任一所述方法的步骤。