CN104978261A - 应用程序的测试方法、装置及系统 - Google Patents

Abstract

本发明公开了一种应用程序的测试方法、装置及系统。其中，该测试方法包括：获取用于测试被测应用程序的多个测试请求；对多个测试请求执行以下步骤，直到完成对多个测试请求中的每一个测试请求所对应的测试指令的执行：从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求；调用与当前测试请求中的测试指令对应的应用程序编程接口API执行测试指令；在调用API执行测试指令的过程中，返回执行从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求的步骤。采用本发明，解决了现有技术中对应用程序进行性能测试时测试终端资源利用率低的问题，实现了高效利用测试终端的CPU资源的效果。

Description

应用程序的测试方法、装置及系统

技术领域

本发明涉及计算机技术领域，具体而言，涉及一种应用程序的测试方法、装置及系统。

背景技术

现有技术中应用程序的性能测试主要是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试均属于性能测试。通过负载测试可以确定在各种工作负载下系统的性能，目标是当负载逐渐增加时，系统各项性能指标的变化请求。压力测试时通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。

当前业界比较成熟的性能测试工具在脚本的使用上都是采用的同步阻塞或者同步非阻塞的技术方案，这些测试工具主要采用的是多线程或者多进程的方式来对应处理机器人的一系列行为，其优势在于用户很容易理解和使用，因为每个用户都对应了一个线程或进程。

现有技术中的性能测试工具提供的脚本录制和回放能很好的模拟用户行为，但是每个机器人需要占用一个线程或者进程处理脚本行为，而每个机器（如压测机）的CPU资源是固定的，例如，只有四个进程，在需要进行多线程多进程测试时，就需要在不同的进程、线程之间进行切换，在这个处理过程中，每个机器人所占用的资源较多，并不能充分利用测试终端（如压测机）的机器资源，尤其是在需要启动的线程或进程数目很多时工具本身会有明显的性能损耗。上述的机器人指的是虚拟的游戏玩家，该虚拟的游戏玩家可以是对系统进行性能测试的虚拟玩家。

其中，异步方式指的是发送方不等接收方响应，便接着发下个数据包的通信方式；而同步指发送方发出数据后，等收到接收方发回的响应，才发下一个数据包的通信方式。阻塞是指执行此套接字的网络调用时，直到成功才返回，否则一直阻塞在此网络调用上，比如调用recv()()函数读取网络缓冲区中的数据，如果没有数据到达，将一直挂在recv()()这个函数调用上，直到读到一些数据，此函数调用才返回；而非阻塞是指执行此套接字的网络调用时，不管是否执行成功，都立即返回。比如调用recv()()函数读取网络缓冲区中数据，不管是否读到数据都立即返回，而不会一直挂在此函数调用上。

在实际网络通信软件开发中，异步非阻塞套接字是用的最多的，平常所说的C/S（客户端/服务器）结构的软件就是异步非阻塞模式的。然而使用对此类系统做性能测试的工具（如互娱游戏自动化性能测试工具）则为采用的同步阻塞或者同步非阻塞的。

例如，使用传统的互娱游戏自动化测试工具对某游戏应用程序进行并发登录的性能测试，其测试目的：验证3000人并发反复登录时，服务器的各项性能资源是否正常。使用传统的工具脚本进行测试：创建机器人、建立机器人与服务器的连接、等待机器人与服务器连接成功、机器人向服务器发送登录请求、机器人等待服务器的登录响应，完成登录，断开连接。每个机器人均要进行上述的一系列操作，如此反复直至完成3000个机器人的测试，大量的机器人通过启动大量的线程或者进程来模拟。使用该种测试方法对单个机器人来讲会同步阻塞在等待连接和等待机器人登录响应，测试时间长、机器资源利用率低。

针对上述对应用程序进行性能测试时测试终端资源利用率低的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种应用程序的测试方法、装置及系统，以至少解决应用程序进行性能测试时测试终端资源利用率低的技术问题。

根据本发明实施例的一个方面，提供了一种应用程序的测试方法，该测试方法包括：获取用于测试被测应用程序的多个测试请求；对多个测试请求执行以下步骤，直到完成对多个测试请求中的每一个测试请求所对应的测试指令的执行：从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求；调用与当前测试请求中的测试指令对应的应用程序编程接口API执行测试指令；在调用API执行测试指令的过程中，返回执行从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求的步骤。

根据本发明实施例的另一方面，还提供了一种应用程序的测试装置，该测试装置包括：请求获取模块，用于获取用于测试被测应用程序的多个测试请求；循环执行模块，用于通过确定模块、处理模块以及返回模块对多个测试请求完成对多个测试请求中的每一个测试请求所对应的测试指令的执行，其中，确定模块，用于从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求；处理模块，用于调用与当前测试请求中的测试指令对应的应用程序编程接口API执行测试指令；返回模块，用于在调用API执行测试指令的过程中，返回执行确定模块。

根据本发明实施例的另一方面，还提供了一种应用程序的测试系统，该测试系统包括：测试终端包括处理器和一个或多个应用程序编程接口API，处理器与一个或多个API连接，处理器用于获取用于测试被测应用程序的多个测试请求，并对多个测试请求执行下述步骤，直至完成对多个测试请求中的每一个测试请求所对应的测试指令的执行：从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求，然后调用与当前测试请求中的测试指令对应的API执行测试指令，并在调用API执行测试指令的过程中，返回执行从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求的步骤。

在本发明实施例中，在调用API执行当前测试请求的测试指令的过程中，从测试请求中选择另一个尚未执行的测试请求作为当前测试请求，而无需等待执行当前的测试指令的执行结果，即开始确定下一个需要执行的测试指令，在测试过程中不会存在采用现有技术方案的响应等待的问题，充分利用了测试指令同步阻塞等待的时间利用终端的资源执行其他操作，从而可以充分利用机器资源，解决了现有技术中对应用程序进行性能测试时测试终端资源利用率低的问题，实现了高效利用测试终端的CPU资源的效果。

附图说明

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

图1是根据本发明实施例的应用程序的测试方法的流程图；

图2是根据本发明实施例的应用程序的测试方法的时序交互图；

图3是根据本发明实施例的一种可选的应用程序的测试方法的流程图；

图4是根据本发明实施例的测试程序主循环的执行流程图；

图5是根据本发明实施例的应用程序的测试装置的示意图；以及

图6是根据本发明实施例的应用程序的测试系统的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例1

根据本发明实施例，提供了一种用于实施应用程序的测试方法的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图1是根据本发明实施例的应用程序的测试方法的流程图。如图1所示，该方法可以包括如下步骤：

步骤S102：获取用于测试被测应用程序的多个测试请求。

步骤S104：从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求。

步骤S106：调用与当前测试请求中的测试指令对应的应用程序编程接口API执行测试指令。

步骤S108：在调用API执行测试指令的过程中，返回执行从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求的步骤，直到完成对多个测试请求中的每一个测试请求所对应的测试指令的执行。

采用本发明，在调用API执行当前测试请求的测试指令的过程中，从测试请求中选择另一个尚未执行的测试请求作为当前测试请求，而无需等待执行当前的测试指令的执行结果，即开始确定下一个需要执行的测试指令，在测试过程中不会存在采用现有技术方案的响应等待的问题，充分利用了测试指令同步阻塞等待的时间利用终端的资源执行其他操作，从而可以充分利用机器资源，解决了现有技术中对应用程序进行性能测试时测试终端资源利用率低的问题，实现了高效利用测试终端的CPU资源的效果。

在本申请中涉及的资源可以指CPU资源。

在本发明的上述实施例中，可以通过测试终端根据用户需求（如对被测应用程序进行性能测试的测试需求）生成多个测试请求（如登录请求、连接请求），在获取多个测试请求之后通过循环执行步骤S102至步骤S108通过测试终端向被测应用程序的服务器发送多个测试请求中的测试指令，采用上述方法开启单线程即可以完成使用多个测试请求对被测应用程序的测试，通过上述的异步非阻塞模式的逻辑控制方法，不仅可以充分利用机器资源，同时还可以降低大量进程线程带来的CPU资源切换开销，也能更好的适应被测应用程序的分布式部署。

其中，上述实施例中的测试终端为对被测应用程序（如某游戏应用程序的服务器）进行测试的终端，该终端可以是计算机或移动终端（如平板电脑）；API（Application Programming Interfac，应用程序编程接口）是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件的以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。API是操作系统留给应用程序的一个调用接口，程序可以通过调用操作系统的API而使操作系统去执行应用程序的命令（动作）。

具体地，每个测试请求可以对应一个或多个测试指令，在当前测试请求对应多个测试指令的情况下，在执行步骤S106的过程中，调用当前测试请求中的一个测试指令对应的API，并记录下一个需要执行的测试指令，如此反复直到执行完成。在调用API执行测试指令的过程中，在触发API执行某个测试指令后立即返回执行标识，而无需等待接收到服务器返回的执行测试指令的结果，从而可以非阻塞的执行测试指令，并且服务器返回的执行测试指令的结果可以通过注册的回调函数处理返回，从而可以异步处理测试指令，充分地利用了测试终端的资源。

在本发明的上述实施例中，在调用API执行测试指令的过程中，返回执行从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求的步骤可以包括：在接收到API返回的第一标识之后和/或在接收到API返回的第二标识之前，按照预设执行序列从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求，其中，第一标识用于表示API开始执行测试指令，第二标识用于表示API完成对测试指令的执行。

具体地，调用API执行测试指令，在API开始执行该测试指令时生成第一标识，并将该标识发送至测试终端的处理器，和/或在API完成对测试指令的执行时生成第二标识，并将该标识发送至测试终端的处理器，处理器在接收到第一标识和/或第二标识之后，按照预设执行序列从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求，然后调用与该当前测试请求中的测试指令对应的API执行该测试指令，循环往复，直至将多个测试请求所对应的测试指令全部执行完成。

下面以使用三个测试请求对被测应用程序进行性能测试为例详细介绍本发明。表1示出了该实施例中测试请求、测试指令以及API的对应关系，如表1所示在该举例说明中，每一个测试请求分别只对应一个测试指令。

表1

测试请求	测试指令	API
			测试请求A	测试指令1	API1
测试请求B	测试指令2	API2
			测试请求C	测试指令3	API3

按照表1示出的测试请求、测试指令以及API的对应关系执行测试指令：在获取到测试被测应用程序的三个测试请求A、B和C之后，从三个测试请求中选择一个尚未执行的测试请求，具体地，可以按照预设好的执行顺序确定当前测试请求，预设好的执行顺序可以为测试请求A→测试请求B→测试请求C。则首先确定当前测试请求为测试请求A，调用与测试请求A的测试指令1对应的API1，同时可以将当前测试请求标记为已执行，在接收到用于标记API1开始执行测试指令1的第一标识之后，从三个测试请求中（按照预设好的执行顺序）选择另一个尚未执行的测试请求B作为当前测试请求，调用与测试请求B中的测试指令2对应的API2，同时将测试请求B标记为已执行，在接收到用于标记API2开始执行测试指令2的第一标识之后，从三个测试请求中（按照预设好的执行顺序）选择另一个尚未执行的测试请求C作为当前测试请求，调用与测试请求C中的测试指令3对应的API3，同时将测试请求C标记为已执行，在接收到用于标记API3开始执行测试指令3的第一标识之后，从三个测试请求中（按照预设好的执行顺序）选择另一个尚未执行的测试请求，而此时三个测试请求均已标记为已执行，则已经将多个测试请求执行完成，完成了此次对被测应用程序的性能测试。

下面仍然以使用三个测试请求对被测应用程序进行性能测试为例详细介绍本发明。表2示出了该实施例中测试请求、测试指令以及API的对应关系，如表2所示，每一个测试请求分别对应多个测试指令。

表2

使用如表2所示的三个测试请求进行性能测试：在获取到测试被测应用程序的三个测试请求A、B和C之后，从三个测试请求中选择一个尚未执行的测试请求，具体地，可以按照预设好的执行顺序确定当前测试请求，预设好的执行顺序可以为测试请求A→测试请求B→测试请求C。则首先确定当前测试请求为测试请求A，调用与测试请求A中需要执行的测试指令A1对应的API a1，同时可以将测试指令A1标记为已执行，在接收到用于标记API a1开始执行测试指令A1的第一标识之后，从三个测试请求中（按照预设好的执行顺序）选择另一个尚未执行完成的测试请求B作为当前测试请求，调用与测试请求B中需要执行的测试指令B1对应的API b1，同时将测试指令B1标记为已执行，在接收到用于标记API b1开始执行测试指令B1的第一标识之后，从三个测试请求中（按照预设好的执行顺序）选择另一个尚未执行完成的测试请求C作为当前测试请求，调用与测试请求C中的测试指令C3对应的API c1，同时可以将测试指令C1标记为已执行，在接收到用于标记API c1开始执行测试指令C1的第一标识之后，从三个测试请求中（按照预设好的执行顺序）选择另一个尚未执行完成的测试请求，按照预设好的执行顺序，此时测试请求A又成为当前测试请求，调用与测试请求A中需要执行的测试指令A2对应的API a2执行该测试指令A2，同时标记该测试指令A2为已执行，然后按照本发明实施例，依序执行测试指令B2→测试指令C2→……→测试指令An→测试指令Bn→测试指令Cn，执行完成对多个测试请求中的每一个测试请求所对应的测试指令的执行，测试结束。

在本发明的上述实施例中，每执行一个测试指令，将执行的测试指令标记为已执行，则下次轮询到该测试请求时，可以通过标记确定下一个需要执行的测试指令。

根据本发明的上述实施例，在获取用于测试被测应用程序的多个测试请求之后、且在对多个测试请求执行步骤之前，测试方法还可以包括：创建脚本虚拟机和与多个测试请求一一对应的虚拟对象，通过脚本虚拟机按照预设加载频率在虚拟对象上加载对应的测试脚本，并将虚拟对象上的测试脚本加载到测试终端的内存中，其中，测试脚本中记载着测试请求所对应的一个或多个测试指令，测试终端为用于对被测应用程序进行测试的终端，虚拟对象为用于发出测试请求的对象。调用与当前测试请求中的测试指令对应的应用程序编程接口API执行测试指令包括：通过脚本虚拟机从内存中的测试脚本中依序读取与当前测试请求对应的测试指令；调用API执行测试指令。

图2是根据本发明实施例的应用程序的测试方法的时序交互图。

具体地，如图2所示，该方法可以包括如下步骤：

步骤S201：创建虚拟对象和脚本虚拟机。

具体地，可以创建与测试请求一一对应的虚拟对象，即每一个测试请求分别对应一个虚拟对象，在获取用户的测试需求时，可以确定用户的此次测试需求中需要对被测应用程序进行何种测试，以及测试需要的虚拟对象。例如，300人同时登录某游戏应用程序的压力测试，则可以根据此测试需求生成300个虚拟对象，在测试过程中，每个虚拟对象分别生成一个登录该游戏应用程序的测试请求，该测试请求中可以包括连接服务器的测试指令和登录服务器的测试指令。

更具体地，在本实施例中可以利用Lex和Yacc工具实现一个语法类似lua的脚本虚拟机tinylua，简称tlua，虚拟机是可以和GAPS工具逻辑处理程序gapsserver一起编译运行的。在本发明的上述实施例中采用的类lua脚本的执行效率比标准lua高出很多，并且本申请中的测试脚本的执行是非阻塞的。

其中，GAPS是互娱游戏自动化性能测试工具的产品代号，可以基于异步非阻塞技术实现；Lex（Lexical Analyzar词法分析生成器），Yacc（YetAnother Compiler Compiler编译器代码生成器）是Unix（一种多用户多任务操作系统）下十分重要的词法分析、语法分析的工具。lua是一个小巧的脚本语言，其设计目的是为了嵌入应用程序中，从而为应用程序提供灵活的扩展和定制功能。

其中，gapsserver是GAPS工具的逻辑处理程序，负责创建及管理虚拟对象（如：性能压测机器人），提供对测试脚本的管理和更新执行、机器人回包数据的管理以及统一的收发包框架、脚本调用C++函数接口框架、动态加载游戏业务扩展so库等逻辑。GAPS工具（该测试工具可以安装在测试终端上）是利用测试脚本驱动的方式，通过gapsserver加载脚本执行序列来控制虚拟对象的执行逻辑（对应到本申请上述实施例中即为测试请求的执行顺序）。测试脚本的执行是异步非阻塞方式，执行立即返回，异步结果则通过回调函数处理保存并且供脚本轮询检查和使用。

步骤S202：通过脚本虚拟机在虚拟对象上挂载测试脚本。

其中，测试脚本中有一些脚本语句组成的脚本函数，每个脚本函数即为上述的一个测试指令，每个测试指令可以用Step（即步骤）命名便于控制脚本运行流程（即上述实施例中的测试指令A1→测试指令A2→测试指令An）。

每执行一个测试指令更新对应的虚拟对象的运行状态时更新的单位为一个Step。

在该实施例中的测试脚本，在获取用户对被测应用程序的测试需求时就已经获取，与测试脚本同时获取的还有一个配置文件，该配置文件也可以是脚本文件，在该配置文件中携带着预设加载频率、测试请求的数量、测试请求的预设执行序列以及测试脚本的运行流程等信息。

步骤S203：脚本虚拟机向处理器返回加载结果。

具体地，通过脚本虚拟机将虚拟对象上的测试脚本加载到测试终端（即安装上述的GAPS工具的终端）的内存中，并返回加载是否成功的结果，如果加载没有成功，则通过脚本虚拟机重新加载测试脚本直至将所有的测试脚本均保存在测试终端的内存中。

步骤S204：用户程序轮询查询调用脚本虚拟机执行所有需要执行的测试脚本。

具体地，即为顺序调用测试脚本中的测试指令以完成对所有的测试脚本的执行。

步骤S205：通过脚本虚拟机执行脚本函数。

在该实施例中脚本函数即为测试指令，在获取到需要执行的脚本函数之后，通过脚本虚拟机确定对应的API。

步骤S206：调用测试工具提供的API。

步骤S207：异步非阻塞的执行API。

其中，脚本虚拟机所调用的API都是采用异步非阻塞的方式，会在执行脚本函数的过程中立即返回执行标识，不会阻塞，也不用同步等待执行结果，异步结果回来会调用注册的回调函数，并记录处理结果供测试脚本检查和使用。

步骤S208：通过API返回执行标识。

具体地，在调用API执行脚本函数的过程中，通过脚本虚拟机获取下一个需要执行的测试指令。

需要进一步说明的是，在测试指令为发包指令的情况下，调用与当前测试请求中的测试指令对应的应用程序编程接口API执行测试指令包括：调用与发包指令对应的发包API向服务器发送第一数据包，发包API返回第一标识和/或第二标识；在测试指令为定时指令的情况下，调用与当前测试请求中的测试指令对应的应用程序编程接口API执行测试指令包括：通过与定时指令对应的定时API为虚拟对象提供定时器，并返回第一标识和/或第二标识；在测试指令为回包指令的情况下，调用与当前测试请求中的测试指令对应的应用程序编程接口API执行测试指令包括：通过与回包指令对应的回包API接收服务器反馈的第二数据包，并返回第一标识和/或第二标识。

具体地，上述实施例中的测试脚本能使用gapsserver提供的一系列API，这些API提供了定时，发包，检查回包等50余个API操作；在执行测试脚本中的测试指令的过程中，调用的所有API都不会阻塞等待，而是立即返回当前的执行标识，对于发包操作，测试脚本调用gapsserver提供的发包API向服务器发送第一数据包，会立即返回发包结果（如是否发包的第一标识），但是第一数据包是否发送到被测的服务器，需要查看错误日志或者回调函数的通知；相应的，服务器回包也是利用注册的回调函数接受处理，并把处理结果保存供脚本调用检查。对于定时器操作，调用定时API，对每个虚拟对象提供8个定时器，用户可以指定使用任意定时器，用户使用的定时器不会阻塞等待，当前定时器时间到了与否都会立即返回执行标识（如是否启动定时器的第一标识）。

通过本发明的上述实施例，测试脚本执行的过程中不会有任何等待，不论发包，收包或者定时等等，所有的测试脚本都是轮询执行的，采用该方法充分有效地利用了脚本同步阻塞等待的时间执行其他操作，充分利用了测试终端的资源，也大大提高了测试被测应用程序的效率。

根据本发明的上述实施例，调用与当前测试请求中的测试指令对应的应用程序编程接口API执行测试指令可以包括：检测与当前测试请求对应的虚拟对象的运行状态是否符合执行测试指令的预设条件；在虚拟对象的运行状态符合执行测试指令的预设条件的情况下，调用与当前测试请求中的测试指令对应的应用程序编程接口API执行测试指令；在虚拟对象的运行状态不符合执行测试指令的预设条件的情况下，返回执行从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求的步骤。

图3是根据本发明实施例的一种可选的应用程序的测试方法的流程图。如图3所示，该方法可以包括如下步骤：

步骤S301：获取用于测试被测应用程序的多个测试请求。

步骤S302：从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求。

步骤S303：检测与当前测试请求对应的虚拟对象的运行状态是否符合执行测试指令的预设条件。

其中，在虚拟对象的运行状态符合执行测试指令的预设条件的情况下，执行步骤S304；在虚拟对象的运行状态不符合执行测试指令的预设条件的情况下，返回执行步骤S302。

步骤S304：调用与当前测试请求中的测试指令对应的应用程序编程接口API执行测试指令。

步骤S305：判断多个测试请求中是否还有尚未执行完成的测试请求。

其中，在多个测试请求中还有尚未执行完成的测试请求的情况下，返回执行步骤S302；在多个测试请求中没有尚未执行完成的测试请求的情况下，也即完成对多个测试请求的执行，则完成测试。

通过本发明的上述实施例，当测试脚本的执行条件（即上述实施例中的虚拟对象的运行状态不符合执行测试指令的预设条件时）不满足时就切换到其他的测试脚本，执行其他测试脚本的测试指令，待下次轮询时，若条件满足再继续执行。采用这种方法充分利用了执行测试脚本的测试指令时的等待时间，有效利用了测试终端的资源，提高了测试效率。

其中，轮询（Polling）是一种CPU决策如何提供周边设备服务的方式，又称“程控输出入”（Programmed I/O）。轮询法的概念是：由CPU定时发出询问，依序询问每一个周边设备是否需要其服务，有即给予服务，服务结束后再问下一个周边，接着不断周而复始。

下面仍然以三个测试请求为例介绍本发明的上述实施例。

具体地，三个测试请求分别为测试请求A、测试请求B以及测试请求C，

三个测试请求分别为对应虚拟对象1的测试请求A、对应虚拟对象2的测试请求B以及对应虚拟对象3的测试请求C，测试请求A中对应请求连接服务器的测试指令A1和请求登录服务器的测试指令A2；测试请求B中对应请求连接服务器的测试指令B1和请求登录服务器的测试指令B2；测试请求C中对应请求连接服务器的测试指令C1和请求登录服务器的测试指令C2。在获取到测试被测应用程序的三个测试请求A、B和C之后，从三个测试请求中选择一个尚未执行的测试请求，具体地，可以按照预设好的执行顺序确定当前测试请求，预设好的执行顺序可以为测试请求A→测试请求B→测试请求C。则首先确定当前测试请求为测试请求A，获取测试请求A中的测试指令A1和虚拟对象1的运行状态，检测虚拟对象1的运行状态是否符合执行测试指令A1的预设条件，若符合则调用与测试请求A中需要执行的测试指令A1对应的API a1，同时可以将测试指令A1标记为已执行，在接收到用于标记API a1开始执行测试指令A1的第一标识之后，从三个测试请求中（按照预设好的执行顺序）选择另一个尚未执行完成的测试请求B作为当前测试请求，获取测试请求B中的测试指令B1和虚拟对象2的运行状态，检测虚拟对象2的运行状态是否符合执行测试指令B1的预设条件，若符合则调用与测试请求B中需要执行的测试指令B1对应的API b1，同时将测试指令B1标记为已执行，在接收到用于标记API b1开始执行测试指令B1的第一标识之后，从三个测试请求中（按照预设好的执行顺序）选择另一个尚未执行完成的测试请求C作为当前测试请求，获取测试请求C中的测试指令C1和虚拟对象3的运行状态，检测虚拟对象3的运行状态是否符合执行测试指令C1的预设条件，若符合则调用与测试请求C中的测试指令C3对应的API c1，同时可以将测试指令C1标记为已执行，在接收到用于标记API c1开始执行测试指令C1的第一标识之后，从三个测试请求中（按照预设好的执行顺序）选择另一个尚未执行完成的测试请求，按照预设好的执行顺序，此时测试请求A又成为当前测试请求，获取测试请求A中的测试指令A2和虚拟对象1的运行状态，检测虚拟对象1的运行状态是否符合执行测试指令A2的预设条件，若符合则调用与测试请求A中需要执行的测试指令A2对应的API a2执行该测试指令A2，同时标记该测试指令A2为已执行；若不符合（如执行测试指令A1未成功，也即虚拟对象1与服务器没有成功建立连接）则跳过测试指令A2，依序执行测试指令B2→测试指令C2→……→测试指令An→测试指令Bn→测试指令Cn，执行完成对多个测试请求中的每一个测试请求所对应的测试指令的执行，测试结束。

需要进一步说明的是，在调用与当前测试请求中的测试指令对应的应用程序编程接口API执行测试指令之后，测试方法还可以包括：接收执行测试指令的测试结果；通过回调函数将测试结果保存在内存中，并使用测试结果更新虚拟对象的运行状态。

图4是根据本发明实施例的测试程序主循环的执行流程图。

具体地，如图4所示，该方法可以包括如下步骤。

步骤S401：进入主循环。

具体地，在gapsserver初始化完成后会进入图4所示的主循环，直到测试执行结束退出。

步骤S402：接收服务器的网络回包。

具体地，在每一次循环的过程中会依次执行bus收包，具体地即为接收服务器的网络回包，并将该网络回包缓存到本地的共享内存中，其中，这些网络回包是服务器返回给虚拟对象（即机器人）的回包。

步骤S403：执行更新管理器。

其中，更新管理器可以依次更新注册的实例（即对应每个虚拟对象的测试脚本，如更新虚拟对象的运行状态、更新执行时间等信息）。

具体地在图4中步骤S402可以包括如下步骤：

步骤S431：更新统计信息。

更新统计信息（即CStaitsticsMgr::Update），如本次循环中收发包的数目，事务个数，成功失败情况，响应时间等信息。

步骤S432：更新场景驱动脚本。

更新场景驱动脚本（VMProjectMgr::Update和VMManger::Update），场景驱动脚本是控制场景行为的脚本，比如该测试场景应该创建多少机器人（即虚拟对象），以怎样的频率（即上述实施例中的预设加载频率）挂载机器人的行为脚本（即上述实施例中的测试脚本）等等信息。

步骤S433：更新机器人管理器。

更新机器人管理器（即CRobotManger::Update），会依次对管理的机器人执行挂载在机器人上的行为脚本（即上述实施例中的测试脚本），也就是这里的机器人行为脚本依赖于场景驱动脚本挂载到机器人上，只有挂载上了脚本的机器人才能在机器人管理器更新时触发具体的行为动作（比如机器人登录、移动、聊天等），而这些脚本的加载执行则需要依赖于脚本虚拟机实例，脚本虚拟机实例在进入主循环前已经被初始化了。

步骤S434：更新当前时间。

更新当前时间（即CGameTime::Update），每次主循环只更新一次时间，每次主循环只更新一次时间，一般主循环会控制在50ms以内，也就是gapsserver里面用到的时间误差在50ms以内。

在执行完成更新管理器之后执行步骤S404：判断测试程序的运行状态是否处于空闲状态。

其中，如果是的话，则执行步骤S405，如果不是的话，则返回执行步骤S401。

步骤S405：控制测试程序在预设时间段内休眠。

其中，预设时间段可以为5ms。

具体地，上述实施例中的测试脚本的执行是通过CRobotManger::Update触发的，每个虚拟对象上分别挂载了自己需要执行的逻辑脚本（即上述实施例中的测试脚本），机器人（即虚拟对象）每次轮询更新的时候会执行测试脚本里的一个Step（即测试指令），并记录下一个需要执行的Step（即测试指令），如此反复直到完成对多个测试请求的执行。更具体地，上述实施例中的gapsserver在触发脚本执行某个Step后会立即返回，体现出非阻塞，而磁盘IO和网络IO的执行结果是通过注册的回调函数处理返回，体现出异步性。

在本发明的上述实施例中，GAPS工具运行在测试终端上，并且gapsserver为GAPS工具的核心运行程序，在本发明实施例中，测试终端上的处理器的功能是通过运行测试程序gapsserver实现的。

下面通过一个性能测试场景详细说明本发明的技术效果。

在该应用场景中，对某游戏并发登录进行性能测试，具体地，验证3000人并发反复登录时，服务器的各项性能资源是否正常。采用本发明，可以在获知用户的上述测试需求时创建大量机器人（即虚拟对象），机器人1（即虚拟对象1）建立连接，机器人2（即虚拟对象2）建立连接……机器人（即虚拟对象）不用阻塞等待连接是否成功，连接成功后会异步通知，下次轮询发现连接建立成功，机器人1发送登录请求，机器人2发送登录请求，机器人也不用阻塞等待登录响应，响应回包会异步通知机器人处理，断开连接，如此反复。

通过对上述的应用场景的分析可知，采用本发明实施例可以单进程但是充分利用了传统工具同步阻塞的时间，尤其是在大量线程或者进程（3000个测试请求）的情况下，更能提升工具承载的机器人数量。在此项目同样产生3000机器人的规模，现有的其他工具的负载程序需要3个（每个部署一台机器），而采用本发明只需要1个就轻松满足（只需一台机器）。采用本发明不仅能够有效利用IO等待的时间服务进行其他业务操作，让机器资源得到充分的利用，通过这种方案实现的性能测试其满负载所能承载的机器人数（即虚拟对象的个数，也即测试请求的格式）是传统做法的1.5倍以上，并且需要的机器少（可以仅使用1台），还可以节省测试成本。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质（如ROM/RAM、磁碟、光盘）中，包括若干指令用以使得一台终端设备（可以是手机，计算机，服务器，或者网络设备等）执行本发明各个实施例的方法。

实施例2

根据本发明实施例，还提供了一种用于实施上述方法实施例的应用程序的测试装置，该装置可以通过在实施例中涉及的测试方法来实现，下面从在测试终端上运行上述装置的角度对本申请的实施过程进行详细描述。

图5是根据本发明实施例的应用程序的测试装置的示意图。

如图5所示，该装置可以包括：请求获取模块10和循环执行模块30，其中，循环执行模块可以包括：确定模块31、处理模块33以及返回模块35。

其中，请求获取模块10用于获取用于测试被测应用程序的多个测试请求。

循环执行模块30用于通过确定模块31、处理模块33以及返回模块35对多个测试请求完成对多个测试请求中的每一个测试请求所对应的测试指令的执行。

确定模块31用于从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求。

处理模块33用于调用与当前测试请求中的测试指令对应的应用程序编程接口API执行测试指令。

返回模块35用于在调用API执行测试指令的过程中，返回执行确定模块。

采用本发明，在调用API执行当前测试请求的测试指令的过程中，从测试请求中选择另一个尚未执行的测试请求作为当前测试请求，而无需等待执行当前的测试指令的执行结果，即开始确定下一个需要执行的测试指令，在整个测试过程中不会有任何等待，充分利用了测试指令同步阻塞等待的时间利用终端的资源执行其他操作，从而可以充分利用机器资源，解决了现有技术中对应用程序进行性能测试时测试终端资源利用率低的问题，实现了高效利用测试终端的CPU资源，提高了测试被测应用程序的效率的效果。

在本发明的上述实施例中，如果通过一个测试终端向被测应用程序的服务器发送多个测试请求，通过上述实施例开启单线程即可以完成多个测试请求，通过异步非阻塞模式的逻辑控制，不经可以充分利用机器资源，同时还可以降低大量进程线程带来的资源切换开销，也能更好的适应被测应用程序的分布式部署。

其中，上述实施例中的测试终端为对被测应用程序进行测试的终端，该终端可以是计算机或移动终端（如平板电脑）。API（ApplicationProgramming Interfac，应用程序编程接口）是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件的以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。API是操作系统留给应用程序的一个调用接口，程序可以通过调用操作系统的API而使操作系统去执行应用程序的命令（动作）。

具体地，每个测试请求可以对应一个或多个测试指令，在当前测试请求对应多个测试指令的情况下，调用当前测试请求中的一个测试指令对应的API时，记录下一个需要执行的测试指令，如此反复直到执行完成。在通过API执行测试指令的过程中，在触发API执行某个测试后立即返回执行标识，而无需等待接收到服务器返回的执行测试指令的结果，从而可以非阻塞的执行测试指令，并且服务器返回的执行测试指令的结果可以通过注册的回调函数处理返回，从而可以异步处理测试指令，充分地利用了测试终端的资源。

根据本发明的上述实施例，返回模块可以包括：执行触发模块，用于在接收到API返回的第一标识之后和/或在接收到API返回的第二标识之前，按照预设执行序列从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求，其中，第一标识用于表示API开始执行测试指令，第二标识用于表示API完成对测试指令的执行。

具体地，调用API执行测试指令，在API开始执行该测试指令时生成第一标识，并将该标识发送至测试终端的处理器，和/或在API完成对测试指令的执行时生成第二标识，并将该标识发送至测试终端的处理器，处理器在接收到第一标识和/或第二标识之后，按照预设执行序列从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求，然后调用与该当前测试请求中的测试指令对应的API执行该测试指令，循环往复，直至将多个测试请求所对应的测试指令全部执行完成。

下面仍然以使用三个测试请求对被测应用程序进行性能测试为例详细介绍本发明。在该举例说明中，每一个测试请求分别对应多个测试指令。

三个测试请求分别为测试请求A、测试请求B以及测试请求C，测试请求A中对应测试指令A1，测试指令A2，……，测试指令An；测试请求B中对应测试指令B1，测试指令B2，……，测试指令Bn；测试请求C中对应测试指令C1，测试指令C2，……，测试指令Cn。在获取到测试被测应用程序的三个测试请求A、B和C之后，从三个测试请求中选择一个尚未执行的测试请求，具体地，可以按照预设好的执行顺序确定当前测试请求，预设好的执行顺序可以为测试请求A→测试请求B→测试请求C。则首先确定当前测试请求为测试请求A，调用与测试请求A中需要执行的测试指令A1对应的API a1，同时可以将测试指令A1标记为已执行，在接收到用于标记API a1开始执行测试指令A1的第一标识之后，从三个测试请求中（按照预设好的执行顺序）选择另一个尚未执行完成的测试请求B作为当前测试请求，调用与测试请求B中需要执行的测试指令B1对应的APIb1，同时将测试指令B1标记为已执行，在接收到用于标记API b1开始执行测试指令B1的第一标识之后，从三个测试请求中（按照预设好的执行顺序）选择另一个尚未执行完成的测试请求C作为当前测试请求，调用与测试请求C中的测试指令C3对应的API c1，同时可以将测试指令C1标记为已执行，在接收到用于标记API c1开始执行测试指令C1的第一标识之后，从三个测试请求中（按照预设好的执行顺序）选择另一个尚未执行完成的测试请求，按照预设好的执行顺序，此时测试请求A又成为当前测试请求，调用与测试请求A中需要执行的测试指令A2对应的API a2执行该测试指令A2，同时标记该测试指令A2为已执行，然后按照本发明实施例，依序执行测试指令B2→测试指令C2→……→测试指令An→测试指令Bn→测试指令Cn，执行完成对多个测试请求中的每一个测试请求所对应的测试指令的执行，测试结束。

在本发明的上述实施例中，每执行一个测试指令，将执行的测试指令标记为已执行，则下次轮询到该测试请求时，可以通过标记确定下一个需要执行的测试指令。

根据本发明的上述实施例，测试装置还包括：创建模块、脚本加载模块以及保存模块，其中，创建模块用于创建脚本虚拟机和与多个测试请求一一对应的虚拟对象，脚本加载模块用于通过脚本虚拟机按照预设加载频率在虚拟对象上加载对应的测试脚本；保存模块用于将虚拟对象上的测试脚本加载到测试终端的内存中，其中，测试脚本中记载着测试请求所对应的一个或多个测试指令，测试终端为用于对被测应用程序进行测试的终端，虚拟对象为用于发出测试请求的对象；处理模块包括：指令读取模块，用于通过脚本虚拟机从内存中的测试脚本中依序读取与当前测试请求对应的测试指令；指令执行模块，用于调用API执行测试指令。

通过上述的创建模块、脚本加载模块以及保存模块，分别对应方法实施例中的步骤S201和步骤S202的实现方法；指令读取模块和指令执行模块分别对应步骤S204至步骤S207的实现方法。上述的各个模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。上述模块可以运行在计算机终端或移动终端，可以通过软件或硬件实现。

需要进一步说明的是，在测试指令为发包指令的情况下，处理模块包括：第一处理子模块，用于调用与发包指令对应的发包API向服务器发送第一数据包，发包API返回第一标识和/或第二标识；在测试指令为定时指令的情况下，处理模块包括：第二处理子模块，用于通过，并返回第一标识和/或第二标识；在测试指令为回包指令的情况下，处理模块包括：第三处理子模块，用于通过与回包指令对应的回包API接收服务器反馈的第二数据包，并返回第一标识和/或第二标识。

具体地，上述实施例中的测试脚本能使用gapsserver提供的一系列API，这些API提供了定时，发包，检查回包等50余个API操作；在执行测试脚本中的测试指令的过程中，调用的所有API都不会阻塞等待，而是立即返回当前的执行标识，对于发包操作，测试脚本调用gapsserver提供的发包API向服务器发送第一数据包，会立即返回发包结果（如是否发包的第一标识），但是第一数据包是否发送到被测的服务器，需要查看错误日志或者回调函数的通知；相应的，服务器回包也是利用注册的回调函数接受处理，并把处理结果保存供脚本调用检查。对于定时器操作，调用定时API，对每个虚拟对象提供8个定时器，用户可以指定使用任意定时器，用户使用的定时器不会阻塞等待，当前定时器时间到了与否都会立即返回执行标识（如是否启动定时器的第一标识）。

通过本发明的上述实施例，测试脚本执行的过程中不会有任何等待，不论发包，收包或者定时等等，所有的测试脚本都是轮询执行的，采用该实施例充分有效地利用了脚本同步阻塞等待的时间执行其他操作，充分利用了测试终端的资源，也大大提高了测试被测应用程序的效率。

其中，gapsserver是GAPS工具的逻辑处理程序，负责创建及管理虚拟对象（如：性能压测机器人），提供对测试脚本的管理和更新执行、机器人回包数据的管理以及统一的收发包框架、脚本调用C++函数接口框架、动态加载游戏业务扩展so库等逻辑。GAPS工具（该测试工具可以安装在测试终端上）是利用测试脚本驱动的方式，通过gapsserver加载脚本执行序列来控制虚拟对象的执行逻辑（对应到本申请上述实施例中即为测试请求的执行顺序）。测试脚本的执行是异步非阻塞方式，执行立即返回，异步结果则通过回调函数处理保存并且供脚本轮询检查和使用。GAPS是互娱游戏自动化性能测试工具的产品代号，可以基于异步非阻塞技术实现。

根据本发明的上述实施例，处理模块可以包括：检测模块，用于检测与当前测试请求对应的虚拟对象的运行状态是否符合执行测试指令的预设条件；调用模块，用于在虚拟对象的运行状态符合执行测试指令的预设条件的情况下，调用与当前测试请求中的测试指令对应的应用程序编程接口API执行测试指令；返回子模块，用于在虚拟对象的运行状态不符合执行测试指令的预设条件的情况下，返回执行确定模块。

具体地，请求获取模块获取用于测试被测应用程序的多个测试请求，通过确定模块从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求，然后使用检测模块检测与当前测试请求对应的虚拟对象的运行状态是否符合执行测试指令的预设条件，调用模块在虚拟对象的运行状态符合执行测试指令的预设条件的情况下，调用与当前测试请求中的测试指令对应的应用程序编程接口API执行测试指令；返回子模块在虚拟对象的运行状态不符合执行测试指令的预设条件的情况下，返回执行确定模块；在执行返回子模块的过程中，通过判断模块判断多个测试请求中是否还有尚未执行完成的测试请求，其中，在多个测试请求中还有尚未执行完成的测试请求的情况下，返回执行确定模块；在多个测试请求中没有尚未执行完成的测试请求的情况下，也即完成对多个测试请求的执行，则完成测试。

通过本发明的上述实施例，当测试脚本的执行条件（即上述实施例中的虚拟对象的运行状态不符合执行测试指令的预设条件时）不满足时就切换到其他的测试脚本，执行其他测试脚本的测试指令，待下次轮询时，若条件满足再继续执行。采用上述实施例充分利用了执行测试脚本的测试指令时的等待时间，有效利用了测试终端的资源，提高了测试效率。

其中，轮询（Polling）是一种CPU决策如何提供周边设备服务的方式，又称“程控输出入”（Programmed I/O）。轮询法的概念是：由CPU定时发出询问，依序询问每一个周边设备是否需要其服务，有即给予服务，服务结束后再问下一个周边，接着不断周而复始。

需要进一步说明的是，测试装置还可以包括：接收模块，用于接收执行测试指令的测试结果；保存更新模块，用于通过回调函数将测试结果保存在内存中，并使用测试结果更新虚拟对象的运行状态。

采用本发明实施例可以单进程但是充分利用了传统工具同步阻塞的时间，尤其是在大量线程或者进程（如3000个测试请求）的情况下，更能提升工具承载的机器人数量。在此项目同样产生3000机器人的规模，现有的其他工具的负载程序需要3个（每个部署一台机器），而采用本发明只需要1个就轻松满足（只需一台机器）。采用本发明不仅能够有效利用IO等待的时间服务进行其他业务操作，让机器资源得到充分的利用，通过这种方案实现的性能测试其满负载所能承载的机器人数（即虚拟对象的个数，也即测试请求的格式）是传统做法的1.5倍以上，并且需要的机器少（1台），还可以节省测试成本。

本实施例中所提供的各个模块与上述实施例一所提供的使用方法相同、应用场景也可以相同。当然，需要注意的是，上述模块涉及的方案可以不限于上述实施例一中的内容和场景。

实施例3

在其最基本的配置中，图6是根据本发明实施例的应用程序的测试系统的结构示意图。出于描述的目的，所绘的体系结构仅为合适环境的一个示例，并非对本申请的使用范围或功能提出任何局限。也不应将该计算系统解释为对图6所示的任一组件或其组合具有任何依赖或需求。

如图6所示，该测试系统可以包括：测试终端50包括处理器51和一个或多个应用程序编程接口API53，处理器与一个或多个API连接。

其中，处理器用于获取用于测试被测应用程序的多个测试请求，并对多个测试请求执行下述步骤，直至完成对多个测试请求中的每一个测试请求所对应的测试指令的执行：从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求，然后调用与当前测试请求中的测试指令对应的API执行测试指令，并在调用API执行测试指令的过程中，返回执行从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求。

采用本发明，在调用API执行当前测试请求的测试指令的过程中，从测试请求中选择另一个尚未执行的测试请求作为当前测试请求，而无需等待执行当前的测试指令的执行结果，即开始确定下一个需要执行的测试指令，在整个测试过程中不会有任何等待，充分利用了测试指令同步阻塞等待的时间利用终端的资源执行其他操作，从而可以充分利用机器资源，解决了现有技术中对应用程序进行性能测试时测试终端资源利用率低的问题，实现了高效利用测试终端的CPU资源的效果。

在本发明的上述实施例中，如果通过一个测试终端向被测应用程序的服务器发送多个测试请求，通过上述实施例开启单线程即可以完成多个测试请求，通过异步非阻塞模式的逻辑控制，不经可以充分利用机器资源，同时还可以降低大量进程线程带来的资源切换开销，也能更好的适应被测应用程序的分布式部署。

其中，上述实施例中的测试终端为对被测应用程序进行测试的终端，该终端可以是计算机或移动终端（如平板电脑）。API（ApplicationProgramming Interfac，应用程序编程接口）是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件的以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。API是操作系统留给应用程序的一个调用接口，程序可以通过调用操作系统的API而使操作系统去执行应用程序的命令（动作）。

具体地，每个测试请求可以对应一个或多个测试指令，在当前测试请求对应多个测试指令的情况下，在执行实施例一的步骤S106的过程中，调用当前测试请求中的一个测试指令对应的API，并记录下一个需要执行的测试指令，如此反复直到执行完成。在通过API执行测试指令的过程中，在触发API执行某个测试后立即返回执行标识，而无需等待接收到服务器返回的执行测试指令的结果，从而可以非阻塞的执行测试指令，并且服务器返回的执行测试指令的结果可以通过注册的回调函数处理返回，从而可以异步处理测试指令，充分地利用了测试终端的资源。

根据本发明的上述实施例，API还用于在开始执行测试指令之后生成并发送第一标识，和/或用于在完成对测试指令的执行时生成并发送第二标识；处理器还包括：执行触发装置，与API连接，用于在接收到API返回的第一标识之后和/或在接收到API返回的第二标识之前，按照预设执行序列从多个测试请求中选择一个尚未执行的测试请求作为当前测试请求。

需要进一步说明的是，处理器还用于创建脚本虚拟机55和与多个测试请求一一对应的虚拟对象，然后通过脚本虚拟机按照预设加载频率在虚拟对象上加载对应的测试脚本，并将虚拟对象上的测试脚本加载到测试终端的内存中，其中，测试脚本中记载着测试请求所对应的一个或多个测试指令，测试终端为用于对被测应用程序进行测试的终端，虚拟对象为用于发出测试请求的对象。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的测试终端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可为个人计算机、服务器或者网络设备等）执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器（ROM，Read-OnlyMemory）、随机存取存储器（RAM，Random Access Memory）、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (14)

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

获取用于测试被测应用程序的多个测试请求；

对所述多个测试请求执行以下步骤，直到完成对所述多个测试请求中的每一个所述测试请求所对应的测试指令的执行：

从所述多个测试请求中选择一个尚未执行的所述测试请求作为当前测试请求；调用与所述当前测试请求中的测试指令对应的应用程序编程接口API执行所述测试指令；在调用所述API执行所述测试指令的过程中，返回执行从所述多个测试请求中选择一个尚未执行的所述测试请求作为当前测试请求的步骤。

2.根据权利要求1所述的测试方法，其特征在于，在调用所述API执行所述测试指令的过程中，返回执行从所述多个测试请求中选择一个尚未执行的所述测试请求作为当前测试请求的步骤包括：

在接收到所述API返回的第一标识之后和/或在接收到所述API返回的第二标识之前，按照预设执行序列从所述多个测试请求中选择一个尚未执行的所述测试请求作为所述当前测试请求，其中，所述第一标识用于表示所述API开始执行所述测试指令，第二标识用于表示所述API完成对所述测试指令的执行。

3.根据权利要求2所述的测试方法，其特征在于，

在获取用于测试被测应用程序的多个测试请求之后、且在对所述多个测试请求执行所述步骤之前，所述测试方法还包括：创建脚本虚拟机和与多个所述测试请求一一对应的虚拟对象，通过所述脚本虚拟机按照预设加载频率在所述虚拟对象上加载对应的测试脚本，并将所述虚拟对象上的所述测试脚本加载到测试终端的内存中，其中，所述测试脚本中记载着所述测试请求所对应的一个或多个所述测试指令，所述测试终端为用于对所述被测应用程序进行测试的终端，所述虚拟对象为用于发出所述测试请求的对象；

所述调用与所述当前测试请求中的测试指令对应的应用程序编程接口API执行所述测试指令包括：通过所述脚本虚拟机从所述内存中的所述测试脚本中依序读取与所述当前测试请求对应的所述测试指令；调用所述API执行所述测试指令。

4.根据权利要求3所述的测试方法，其特征在于，

在所述测试指令为发包指令的情况下，调用与所述当前测试请求中的测试指令对应的应用程序编程接口API执行所述测试指令包括：调用与所述发包指令对应的发包API向服务器发送第一数据包，所述发包API返回所述第一标识和/或所述第二标识；

在所述测试指令为定时指令的情况下，调用与所述当前测试请求中的测试指令对应的应用程序编程接口API执行所述测试指令包括：通过与所述定时指令对应的定时API为所述虚拟对象提供定时器，并返回所述第一标识和/或所述第二标识；

在所述测试指令为回包指令的情况下，调用与所述当前测试请求中的测试指令对应的应用程序编程接口API执行所述测试指令包括：通过与所述回包指令对应的回包API接收所述服务器反馈的第二数据包，并返回所述第一标识和/或所述第二标识。

5.根据权利要求1至4中任意一项所述的测试方法，其特征在于，所述调用与所述当前测试请求中的测试指令对应的应用程序编程接口API执行所述测试指令包括：

检测与所述当前测试请求对应的所述虚拟对象的运行状态是否符合执行所述测试指令的预设条件；

在所述虚拟对象的所述运行状态符合执行所述测试指令的所述预设条件的情况下，调用与所述当前测试请求中的测试指令对应的应用程序编程接口API执行所述测试指令；

在所述虚拟对象的所述运行状态不符合执行所述测试指令的所述预设条件的情况下，返回执行从所述多个测试请求中选择一个尚未执行的所述测试请求作为当前测试请求的步骤。

6.根据权利要求1至4中任意一项所述的测试方法，其特征在于，在调用与所述当前测试请求中的测试指令对应的应用程序编程接口API执行所述测试指令之后，所述测试方法还包括：

接收执行所述测试指令的测试结果；

通过回调函数将所述测试结果保存在内存中，并使用所述测试结果更新所述虚拟对象的运行状态。

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

请求获取模块，用于获取用于测试被测应用程序的多个测试请求；

循环执行模块，用于通过确定模块、处理模块以及返回模块对所述多个测试请求完成对所述多个测试请求中的每一个所述测试请求所对应的测试指令的执行，

其中，确定模块，用于从所述多个测试请求中选择一个尚未执行的所述测试请求作为当前测试请求；处理模块，用于调用与所述当前测试请求中的测试指令对应的应用程序编程接口API执行所述测试指令；返回模块，用于在调用所述API执行所述测试指令的过程中，返回执行所述确定模块。

8.根据权利要求7所述的测试装置，其特征在于，所述返回模块包括：

执行触发模块，用于在接收到所述API返回的第一标识之后和/或在接收到所述API返回的第二标识之前，按照预设执行序列从所述多个测试请求中选择一个尚未执行的所述测试请求作为所述当前测试请求，其中，所述第一标识用于表示所述API开始执行所述测试指令，第二标识用于表示所述API完成对所述测试指令的执行。

9.根据权利要求8所述的测试装置，其特征在于，

所述测试装置还包括：创建模块、脚本加载模块以及保存模块，

其中，所述创建模块用于创建脚本虚拟机和与多个所述测试请求一一对应的虚拟对象，所述脚本加载模块用于通过所述脚本虚拟机按照预设加载频率在所述虚拟对象上加载对应的测试脚本；所述保存模块用于将所述虚拟对象上的所述测试脚本加载到测试终端的内存中，其中，所述测试脚本中记载着所述测试请求所对应的一个或多个所述测试指令，所述测试终端为用于对所述被测应用程序进行测试的终端，所述虚拟对象为用于发出所述测试请求的对象；

所述处理模块包括：指令读取模块，用于通过所述脚本虚拟机从所述内存中的所述测试脚本中依序读取与所述当前测试请求对应的所述测试指令；指令执行模块，用于调用所述API执行所述测试指令。

10.根据权利要求9所述的测试装置，其特征在于，

在所述测试指令为发包指令的情况下，所述处理模块包括：第一处理子模块，用于调用与所述发包指令对应的发包API向服务器发送第一数据包，所述发包API返回所述第一标识和/或所述第二标识；

在所述测试指令为定时指令的情况下，所述处理模块包括：第二处理子模块，用于通过，并返回所述第一标识和/或所述第二标识；

在所述测试指令为回包指令的情况下，所述处理模块包括：第三处理子模块，用于通过与所述回包指令对应的回包API接收所述服务器反馈的第二数据包，并返回所述第一标识和/或所述第二标识。

11.根据权利要求7至10中任意一项所述的测试装置，其特征在于，所述处理模块包括：

检测模块，用于检测与所述当前测试请求对应的所述虚拟对象的运行状态是否符合执行所述测试指令的预设条件；

调用模块，用于在所述虚拟对象的所述运行状态符合执行所述测试指令的所述预设条件的情况下，调用与所述当前测试请求中的测试指令对应的应用程序编程接口API执行所述测试指令；

返回子模块，用于在所述虚拟对象的所述运行状态不符合执行所述测试指令的所述预设条件的情况下，返回执行所述确定模块。

12.根据权利要求7至10中任意一项所述的测试装置，其特征在于，所述测试装置还包括：

接收模块，用于接收执行所述测试指令的测试结果；

保存更新模块，用于通过回调函数将所述测试结果保存在内存中，并使用所述测试结果更新所述虚拟对象的运行状态。

13.一种应用程序的测试系统，其特征在于，包括：

测试终端包括处理器和一个或多个应用程序编程接口API，所述处理器与所述一个或多个API连接，

所述处理器用于获取用于测试被测应用程序的多个测试请求，并对所述多个测试请求执行下述步骤，直至完成对所述多个测试请求中的每一个所述测试请求所对应的测试指令的执行：从所述多个测试请求中选择一个尚未执行的所述测试请求作为当前测试请求，然后调用与所述当前测试请求中的测试指令对应的所述API执行所述测试指令，并在调用所述API执行所述测试指令的过程中，返回执行从所述多个测试请求中选择一个尚未执行的所述测试请求作为当前测试请求的步骤。

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

所述API还用于在开始执行所述测试指令之后生成并发送第一标识，和/或用于在完成对所述测试指令的执行时生成并发送第二标识；

所述处理器还包括：执行触发装置，与所述API连接，用于在接收到所述API返回的第一标识之后和/或在接收到所述API返回的第二标识之前，按照预设执行序列从所述多个测试请求中选择一个尚未执行的所述测试请求作为所述当前测试请求。