CN105281978A - 一种性能测试的方法、装置和系统 - Google Patents

Abstract

本公开是关于一种性能测试的方法、装置和系统，属于互联网技术领域。所述方法包括：获取测试配置信息；根据所述测试配置信息，生成测试模型；分解所述测试模型，得到至少两个子模型；将所述至少两个子模型分配给至少两个测试节点，并控制各个测试节点采用各自分配到的子模型进行性能测试；接收并合并所述至少个测试节点发送的测试数据。本公开通过获取测试配置信息，根据测试配置信息生成测试模型，并将测试模型分解为至少两个子模型，不需要测试人员编写测试脚本，实现成本低。将至少两个子模型分配给测试节点，并控制各个测试节点按照各自分配到的子模型进行性能测试，适用于大型系统的性能测试。

Description

一种性能测试的方法、装置和系统

技术领域

本公开涉及互联网技术领域，尤其涉及一种性能测试的方法、装置和系统。

背景技术

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件对测试对象的各项性能指标进行测试。相关技术中，测试器运行测试脚本对被测试系统进行自动化测试，同时监测器对测试系统处理测试数据的过程进行监测，得到测试结果。由于测试脚本是测试人员根据被测试系统的不同情况编写的，因此需要测试人员具有编程开发能力，实现成本高。

发明内容

为克服相关技术中存在的问题，本公开提供一种性能测试的方法、装置和系统。

根据本公开实施例的第一方面，提供一种性能测试方法，所述方法包括：

获取测试配置信息；

根据所述测试配置信息，生成测试模型；

分解所述测试模型，得到至少两个子模型；

将所述至少两个子模型分配给至少两个测试节点，并控制各个测试节点采用各自分配到的子模型进行性能测试；

接收并合并所述至少两个测试节点发送的测试数据。

在本公开实施例的一种实现方式中，所述测试配置信息包括模型数据和策略规则，所述模型数据包括业务流程、业务流程中各个步骤的请求信息、业务流程中各个步骤的比例以及用户并发数量，所述策略规则包括业务流量类型、策略参数。

其中，所述测试模型包括协议请求序列、每种协议请求序列的比例以及协议请求序列的流转规则。

进一步地，所述根据测试配置信息，生成测试模型，包括：

根据所述请求信息，生成所述协议请求序列；

根据所述业务流程中各个步骤的比例，确定每种协议请求序列的比例；

根据所述业务流程，确定协议请求序列的流转规则。

在本公开实施例的又一种实现方式中，所述分解所述测试模型，得到至少两个子模型，包括：

分解测试模型中的协议请求序列以及协议请求序列的比例，得到各个子模型的协议请求序列以及子模型的协议请求序列在所属的子模型中的比例。

进一步地，所述分解测试模型中的协议请求序列，包括：

分解测试模型中协议请求序列的参数生成规则。

在本公开实施例的又一种实现方式中，所述方法还包括：

根据合并后的测试数据，确定测试指标的数值；

当测试指标的数值大于指标设定值时，向各个测试节点发送测试指标对应的调节指令。

可选地，所述调节指令用于指示调节请求生成速率、用户并发数量、每秒发起的请求数量中的至少一种。

可选地，所述测试指标包括响应时间、每秒查询率QPS、系统负载、中央处理器CPU利用率、数据生成速率、错误率、吞吐量中的至少一种。

在本公开实施例的又一种实现方式中，所述方法还包括：

获取测试节点的状态信息；

实时输出获取到的所述状态信息。

根据本公开实施例的第二方面，提供一种性能测试装置，所述装置包括：

获取模块，用于获取测试配置信息；

生成模块，用于根据所述获取模块获取到的测试配置信息，生成测试模型；

分解模块，用于分解所述生成模块生成的测试模型，得到至少两个子模型；

控制模块，用于将所述分解模块得到的所述至少两个子模型分配给至少两个测试节点，并控制各个测试节点采用各自分配到的子模型进行性能测试；

数据处理模块，用于接收并合并所述至少两个测试节点发送的测试数据。

在本公开实施例的一种实现方式中，所述测试配置信息包括模型数据和策略规则，所述模型数据包括业务流程、业务流程中各个步骤的请求信息、业务流程中各个步骤的比例以及用户并发数量，所述策略规则包括业务流量类型、策略参数。

其中，所述测试模型包括协议请求序列、每种协议请求序列的比例以及协议请求序列的流转规则。

进一步地，所述生成模块，包括：

生成子模块，用于根据所述请求信息，生成所述协议请求序列；

比例确定子模块，用于根据所述业务流程中各个步骤的比例，确定每种协议请求序列的比例；

流转规则确定子模块，用于根据所述业务流程，确定协议请求序列的流转规则。

在本公开实施例的又一种实现方式中，所述分解模块用于分解测试模型中的协议请求序列以及协议请求序列的比例，得到各个子模型的协议请求序列以及子模型的协议请求序列在所属的子模型中的比例。

进一步地，所述分解模块，用于分解测试模型中协议请求序列的参数生成规则。

在本公开实施例的又一种实现方式中，所述装置还包括：

指标数值确定模块，用于根据所述数据处理模块得到的合并后的测试数据，确定测试指标的数值；

调节指令发送模块，用于当测试指标的数值大于指标设定值时，向各个测试节点发送测试指标对应的调节指令。

可选地，所述调节指令用于指示调节请求生成速率、用户并发数量、每秒发起的请求数量中的至少一种。

可选地，所述测试指标包括响应时间、每秒查询率QPS、系统负载、中央处理器CPU利用率、数据生成速率、错误率、吞吐量中的至少一种。

在本公开实施例的又一种实现方式中，所述装置还包括：

状态信息获取模块，用于获取测试节点的状态信息；

输出模块，用于实时输出所述状态信息获取模块获取到的所述状态信息。

根据本公开实施例的第三方面，提供一种性能测试装置，所述装置包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

获取测试配置信息；

根据所述测试配置信息，生成测试模型；

分解所述测试模型，得到至少两个子模型；

将所述至少两个子模型分配给至少两个测试节点，并控制各个测试节点采用各自分配到的子模型进行性能测试；

接收并合并所述至少两个测试节点发送的测试数据。

根据本公开实施例的第四方面，提供一种性能测试系统，所述系统包括：控制节点和至少两个测试节点，

所述控制节点，用于获取测试配置信息；根据所述测试配置信息，生成测试模型；分解所述测试模型，得到至少两个子模型；将所述至少两个子模型分配给至少两个测试节点，并控制各个测试节点采用各自分配到的子模型进行性能测试；

所述至少两个测试节点用于在所述控制节点的控制下，采用各自分配到的子模型进行性能测试，得到测试数据；并将得到的所述测试数据发送给所述控制节点；

所述控制节点还用于接收并合并所述至少两个测试节点发送的测试数据。

本公开的实施例提供的技术方案可以包括以下有益效果：通过获取测试配置信息，根据测试配置信息生成测试模型，并将测试模型分解为至少两个子模型，不需要测试人员编写测试脚本，实现成本低。将至少两个子模型分配给测试节点，并控制各个测试节点按照各自分配到的子模型进行性能测试，适用于大型系统的性能测试。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

图1是根据一示例性实施例示出的性能测试方法的应用场景的结构示意图；

图2是根据一示例性实施例示出的一种性能测试方法的流程图；

图3是根据另一示例性实施例示出的一种性能测试方法的流程图；

图4是根据一示例性实施例示出的一种性能测试装置的框图；

图5是根据另一示例性实施例示出的一种性能测试装置的框图；

图6是根据一示例性实施例示出的一种性能测试装置的框图；

图7是根据一示例性实施例示出的一种性能测试系统的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

下面先结合图1简单介绍一下本公开提供的性能测试的方法的应用场景。如图1所示，控制节点1分别与多个测试节点2通过互联网连接，控制节点1用于根据测试配置信息生成测试模型，并根据测试模型控制测试节点2对网站进行性能测试。图1中测试节点2的数量仅为举例，本公开实施例并不以此为限。

图2是根据一示例性实施例示出的一种性能测试的方法的流程图，如图2所示，该性能测试的方法用于服务器(例如图1中的控制节点)中，包括以下步骤。

在步骤S101中，获取测试配置信息。

其中，测试配置信息用于描述测试需求。

测试配置信息可以包括模型数据和策略规则，模型数据可以包括业务流程、业务流程中各个步骤的请求信息、以及业务流程中各个步骤的比例，请求信息可以包括协议请求类型、协议请求参数、业务参数，策略规则可以包括业务流量类型、用户并发数量、策略参数。

在步骤S102中，根据测试配置信息，生成测试模型。

该测试模型用于描述业务场景，包括协议请求序列、每种协议请求序列的占比以及协议请求序列的流转规则。

在步骤S103中，分解测试模型，得到至少两个子模型。

在步骤S104中，将至少两个子模型分配给至少两个测试节点，并控制各个测试节点采用各自分配到的子模型进行性能测试。

在步骤S105中，接收并合并至少两个测试节点发送的测试数据。

通过监控合并后的测试数据，即可监控网站的性能。

本公开实施例通过获取测试配置信息，根据测试配置信息生成测试模型，并将测试模型分解为至少两个子模型，不需要测试人员编写测试脚本，实现成本低。将至少两个子模型分配给测试节点，并控制各个测试节点按照各自分配到的子模型进行性能测试，适用于大型系统的性能测试。

图3是根据一示例性实施例示出的一种性能测试的方法的流程图，如图3所示，该方法包括以下步骤。

在步骤201中，控制节点获取测试配置信息。

测试配置信息可以包括模型数据和策略规则，模型数据可以包括业务流程、业务流程中各个步骤的请求信息、业务流程中各个步骤的比例、以及用户并发数量，请求信息可以包括协议请求类型、协议请求参数、业务参数，策略规则可以包括业务流量类型、策略参数。

其中，协议请求类型包括但不限于超文本传输协议(HyperTextTransferProtocol，简称HTTP)、简单邮件传输协议(SimpleMailTransferProtocol，简称SMTP)等，协议请求参数为协议所依赖的参数，例如HTTP需要请求的统一资源定位器(UniformResourceLocator，简称URL)、POST方法的具体参数等，业务参数指业务过程所需要的参数，例如登陆需要的用户名(即用户标识)、商品标识、页面编号等，业务参数可以包括数据源以及参数生成规则。其中，数据源可以为取值区间、数据集合等，参数生成规则包括但不限于随机生成、递增、递减。业务参数还可以包括上下文依赖信息，用于指示各请求之间的关系。

业务流量类型包括但不限于阶梯递增、阶梯递减、突发。策略参数包括变化时间、初始数量、单位时间变化数量。例如对于阶梯递增，策略参数包括递增时间n秒、初始数量为m、单位时间变化数量为每秒增加x个，x大于0、m等于或大于0；对于阶梯递减，策略参数包括变化时间为n秒，初始数量为m，单位时间变化数量为每秒减少x个，m和x均大于0。对于突发，策略参数包括初始数量m，变化时间为0，单位时间变化数量为每秒0个，m大于0；对于突发而言，策略参数的初始数量可以为用户并发数量。这里的数量均指同时发起的请求的数量。

实现时，测试配置信息可以由测试人员输入。

以某电商网站的突发性流量测试为例，对该步骤进行举例说明。

假定某电商网站的业务流程依次包括A、B、C三步，比例分别为7:2:1，预计该站点能承受并发用户在10000，业务流量类型为突发。

则测试人员输入的模型数据，包括业务流程的每个步骤中的请求信息，请求信息包括请求协议类型、协议请求参数、业务参数和上下文依赖信息，其中，业务参数包括数据源和参数生成规则，例如用户ID的参数生成规则可以为以递增方式分配，初始值是123445。上下文依赖信息是指各请求之间的关系，例如步骤B的请求的输出作为步骤C的请求一个输入参数。

其中，步骤A的请求和步骤B的请求采用的数据源可以相同，也可以不同，不同步骤的请求采用的数据源可以根据实际业务流程设置。

模型数据还包括各个步骤的请求的占比(例如，步骤A的请求的数量占所有请求数量的70％，步骤B的请求的数量占所有请求数量的20％，步骤C的请求的数量占所有请求数量的10％)、各个步骤的请求的流转规则，用户并发数量(10000)。

在步骤202中，控制节点根据测试配置信息，生成测试模型。

该测试模型用于描述业务场景，包括协议请求序列、每种协议请求序列的占比以及协议请求序列的流转规则。

该步骤202可以包括：

根据请求信息，生成协议请求序列；

根据业务流程中各个步骤的比例，确定每种协议请求序列的比例；

根据业务流程，确定协议请求序列的流转规则。

其中，协议请求序列即各个步骤中的协议请求类型以及请求所依赖的参数。而协议请求序列的流转规则是指各种协议请求序列之间的执行顺序。

在步骤203中，控制节点分解测试模型，得到至少两个子模型。

根据策略规则对测试模型进行分解，得到多个子模型以及测试模型与多个子模型的映射关系。

子模型至少包括协议请求序列和协议请求序列的比例。一个子模型可以包括一种协议请求序列，也可以包括两种以上协议请求序列。当一个子模型包括两种以上协议请求序列时，子模型还可以包括协议请求序列的流转规则。

其中，根据策略规则对测试模型进行分解，还包括将策略规则分解为与子模型一一对应的子策略规则，实现时，可以根据测试节点的处理能力进行划分，例如，以突发流量为例，其策略参数包括初始数量m，变化时间为0，单位时间变化数量为每秒0个，m大于0；若测试节点为两个且处理能力相当，则可以分解为两个子策略规则，每个子策略规则中的业务流量类型均为突发，且策略参数为初始数量m/2，变化时间为0，单位时间变化数量为每秒0个，m大于0。

该步骤203可以包括：

分解测试模型中协议请求序列以及各种协议请求序列的比例，得到各个子模型的协议请求序列以及子模型的协议请求序列在所属的子模型中的比例。

进一步地，分解测试模型中协议请求序列，包括：

获取各协议请求序列之间的上下文依赖关系；

将具有上下文依赖关系的协议请求序列划分到同一子模型；

将不具有上下文依赖关系的协议请求序列划分到同一个子模型或划分到不同的子模型。

例如，以前述步骤A中的请求(下文简称请求A)和步骤B中的请求(下文简称请求B)和步骤C中的请求(下文简称请求C)为例，根据上下文依赖关系可知，请求B的输出为请求C的一个输入参数，则请求B和请求C需要划分至同一个子模型；请求A与请求B和请求C均没有上下文依赖关系，因此，请求A可以和请求B、C划分到同一个子模型，也可以划分到一个单独的子模型中。

其中，不具有上下文依赖关系的协议请求序列可以根据各种协议请求序列的比例、测试节点的硬件处理能力中的至少一种确定是单独划分到一个子模型中，还是和其他请求划分到同一个子模型中。例如，请求A的比例为70％，大于请求B和请求C所占的比例，则可以将请求A单独划分到一个子模型中。又例如，若测试节点的硬件处理能力很强，只需要两台测试节点即可以完成测试任务，则此时可以将50％(占所有请求的比例)的请求A划分到一个子模型中，而20％(占所有请求的比例)的请求A和请求B以及请求C划分到一个子模型中。

进一步地，分解测试模型中协议请求序列的比例，可以包括以下方式中的至少一种：

将单个协议请求序列的比例拆分至至少两个子模型中；

将至少两个协议请求序列的比例一起拆分至至少两个子模型中，该至少两个协议请求序列中的全部或部分可以具有上下文依赖关系。

通过协议请求序列的比例的拆分，可以降低对单个测试节点的硬件处理能力的要求，适用于大流量测试。

其中，将至少两个协议请求序列的比例一起拆分至至少两个子模型中，可以采用相等的拆分方式，也可以采用不相等的拆分方式，只要最终测试模型中协议请求序列的比例不会发生变化即可。例如，假设测试模型中R1和R2请求比例为4:3，可用的测试节点为两个，则该测试模型可以分解为两个测试节点的子模型中R1和R2请求比例均为4:3(采用相等的拆分方式)；或者该测试模型可以分解为测试节点1的子模型中R1和R2请求比例为2:2，测试节点2的子模型中R1和R2请求比例为2:1(采用不相等的拆分方式)，这两种拆分方式均可以保证所有子模型组合之后，R1和R2请求的比例为4:3，即测试模型中的R1和R2请求的比例为4:3。

可选地，分解测试模型中的协议请求序列，还可以包括：

分解测试模型中的协议请求序列的参数生成规则，得到子模型中的协议请求序列的参数生成规则。

其中，分解测试模型中的协议请求序列的参数生成规则，包括：分解参数生成规则所采用的数据源，即取值区间或数据集合。

例如，设定参数a的生成规则是顺序在[x,y]区间内取值，如果有2台测试节点，则可以把[x,y]区间拆分为[x,m],[m,y]两个区间，一台测试节点顺序在[x,m]区间内取值，另一台测试节点顺序在[m,y]区间内取值。

在步骤204中，控制节点将至少两个子模型分配给至少两个测试节点。

一个子模型对应一个测试节点，将至少两个子模型分配给至少两个测试节点，即将至少两个子模型的模型数据和子模型对应的子策略规则分别发送给各自对应的测试节点，子模型的模型数据包括请求信息以及请求的比例，请求信息包括协议请求类型、协议请求参数、业务参数。关于请求信息的详细描述参见步骤201，在此不再赘述。

该步骤204包括：

检测可用的测试节点；

将多个子模型分配给可用的测试节点。

进一步地，控制节点可以接收测试节点发送的心跳信息，根据心跳信息获取测试节点的状态，即该测试节点是否空闲可用。

实现时，多个测试节点可以位于不同的地理位置，例如位于不同的国家，从而可以实现对同一网站的跨地域测试。

在步骤205中，测试节点获取分配到的子模型。

每个测试节点会分配到一个子模型，测试节点接收到分配到的子模型的模型数据后，根据该子模型的模型数据生成测试请求。

在步骤206中，控制节点接收用户输入的控制指令。

在该步骤中，控制指令为开始指令。

在步骤207中，控制节点将控制指令发送给各个测试节点。

测试节点接收到该开始指令后，初始化引擎和静态数据，其中，初始化引擎用于检测测试节点的运行环境。初始化静态数据，包括采用数据源和对应的参数生成规则生成业务参数数据。初始化完成后，向控制节点返回初始化结果。

由于本实施例中的流量模型为突发，所有的测试节点的虚拟用户阻塞，等待开始信号。控制节点接收到各个测试节点返回的初始化结果后，若各个测试节点均完成初始化，则向所有的测试节点发出开始信号，测试节点接收到开始信号后，执行步骤208。

在步骤208中，测试节点发起测试请求，接收测试请求的应答。

如果该测试请求需要关联随后测试请求的上下文，即该测试请求的输出是下一测试请求的一个输入参数，则根据对应的参数生成规则对该应答做规则处理，提取数据，供下次测试请求使用。

通过步骤204～208，即可实现将至少两个子模型分配给测试节点，并控制测试节点按照各自分配的子模型进行性能测试。

在步骤209中，测试节点将测试数据发送给控制节点。

测试数据包括每个虚拟用户的每个请求的时间戳、连接时间和请求耗时、消耗带宽、结果状态码。其中，时间戳为发送测试请求的系统时间。

实现时，测试节点中配置有监控进程，用于获取测试请求的测试数据，并根据模型与子模型的映射关系将测试请求的测试数据提交给控制节点。

在步骤210中，控制节点接收各个测试节点发送的测试数据。

实现时，各个测试节点发送的测试数据可以包括每个虚拟用户的每个请求的测试数据，也可以为测试节点上所有虚拟用户的所有请求的测试统计数据，其中测试统计数据可以包括每秒查询率(QueryPerSecond，简称QPS)、响应时间、错误占比、吞吐量等。

在步骤211中，控制节点合并接收到的各个测试节点发送的测试统计数据，得到整体测试数据。

该步骤211可以包括：

根据模型和子模型的映射关系合并接收到的各个测试节点发送的测试统计数据，得到整体测试数据。

可选地，该步骤211还可以包括：

实时输出整体测试数据；通过实时输出整体测试数据，可以便于测试人员及时全面地了解测试情况。

可选地，除了实时输出整体测试数据，还可以输出各个测试节点上的测试统计数据，以便于测试人员可以了解各个测试节点的测试情况。

可选地，该方法还可以包括：

在步骤212中，控制节点根据接收到的测试数据，确定测试指标的数值；

在步骤213中，当测试指标的数值大于指标设定值时，控制节点向各个测试节点发送测试指标对应的调节指令。

其中，测试指标可以包括响应时间、QPS、系统负载、中央处理器(CentralProcessingUnit，简称CPU)利用率、请求生成速率、错误率、吞吐量中的至少一种。

可选地，调节指令可以用于指示调节请求生成速率、用户并发数量、每秒发起的请求数量中的至少一种，以防止系统由于负载过重而崩溃。

例如，测试指标为请求生成速率，测试指标的数值为5.1K，指标设定值为5K，测试指标的数值大于指标设定值，则发送限速指令。

可以理解地，通过向各个测试节点发送调节指令，以根据测试情况进行适应性调整。

可选地，该方法还可以包括：

当测试指标的数值大于指标设定值时，发出告警。以便于测试人员实时监控，可用于线上的压力测试。

可选地，该方法还可以包括：

在步骤214中，控制节点获取各个测试节点的状态信息，状态信息包括正在执行的任务、当前的总请求速率、请求的错误率、网络吞吐量、主机的负载、内存占用等信息；

在步骤215中，控制节点实时输出各个测试节点的状态信息。

通过实时输出各个测试节点的状态信息，测试人员可以实时监控测试节点的状态，帮助测试人员把控测试过程。

进一步地，该方法还可以包括：

控制节点接收输入的修改指令，该修改指令包括测试节点增加指令、服务器地址变更指令中的至少一种；

响应于测试节点增加指令，控制节点将子模型发送给新节点，并控制新节点按照分配到的子模型进行性能测试；

响应于服务器地址变更指令，控制节点将服务器地址同步到各个测试节点。

当测试人员发现测试节点单机硬件已达到极限，而指标数据不能达到预期，则可以输入测试节点增加指令，该测试节点增加指令包括新节点的信息，例如新节点的IP地址、新节点的硬件处理能力(例如最大承载流量信息)等。将新节点增加为测试节点。

当在测试过程中需要变更服务器的地址，则控制节点接收服务器地址变更指令，该服务器地址变更指令包括新的服务器地址，将该新的服务器的地址同步到各个测试节点后，测试节点将更新子模型，并根据新的子模型进行性能测试。

可选地，该方法还可以包括：

控制节点接收用户输入的控制指令，该控制指令包括暂停指令、结束指令、继续执行指令；

控制节点将控制指令发送给各个测试节点。

本公开实施例通过获取测试配置信息，根据测试配置信息生成测试模型，并将测试模型分解为至少两个子模型，不需要测试人员编写测试脚本，实现成本低。将至少两个子模型分配给测试节点，并控制各个测试节点按照各自分配到的子模型进行性能测试，适用于大型系统的性能测试。

图4是根据一示例性实施例示出的一种性能测试装置的框图，参照图4，该装置包括获取模块301、生成模块302、分解模块303、控制模块304和数据处理模块305。

该获取模块301被配置为用于获取测试配置信息。该生成模块302被配置为用于根据获取模块301获取到的测试配置信息，生成测试模型。该分解模块303被配置为用于分解生成模块302生成的测试模型，得到至少两个子模型。该控制模块304被配置为用于将分解模块303得到的至少两个子模型分配给至少两个测试节点，并控制各个测试节点采用各自分配到的子模型进行性能测试。该数据处理模块305被配置为用于接收并合并至少两个测试节点发送的测试数据。

其中，测试配置信息用于描述测试需求。测试配置信息可以包括模型数据和策略规则，模型数据可以包括业务流程、业务流程中各个步骤的请求信息、以及业务流程中各个步骤的比例，请求信息可以包括协议请求类型、协议请求参数、业务参数，策略规则可以包括业务流量类型、用户并发数量、策略参数。

该测试模型用于描述业务场景，包括协议请求序列、每种协议请求序列的占比以及协议请求序列的流转规则。

本公开通过获取测试配置信息，根据测试配置信息生成测试模型，并将测试模型分解为至少两个子模型，不需要测试人员编写测试脚本，实现成本低。将至少两个子模型分配给测试节点，并控制各个测试节点按照各自分配到的子模型进行性能测试，适用于大型系统的性能测试。

图5是根据一示例性实施例示出的一种性能测试装置的框图，参照图5，该装置包括获取模块401、生成模块402、分解模块403、控制模块404和数据处理模块405。

该获取模块401被配置为用于获取测试配置信息。该生成模块402被配置为用于根据获取模块401获取到的测试配置信息，生成测试模型。该分解模块403被配置为用于分解生成模块402生成的测试模型，得到至少两个子模型。该控制模块404被配置为用于将分解模块403得到的至少两个子模型分配给至少两个测试节点，并控制各个测试节点采用各自分配到的子模型进行性能测试。该数据处理模块405被配置为用于接收并合并至少两个测试节点发送的测试数据。

其中，测试配置信息可以包括模型数据和策略规则，模型数据可以包括业务流程、业务流程中各个步骤的请求信息、业务流程中各个步骤的比例、以及用户并发数量，请求信息可以包括协议请求类型、协议请求参数、业务参数，策略规则可以包括业务流量类型、策略参数。

其中，协议请求类型包括但不限于HTTP、SMTP等，协议请求参数为协议所依赖的参数，例如HTTP需要请求的URL、POST方法的具体参数等，业务参数指业务过程所需要的参数，例如登陆需要的用户名(即用户标识)、商品标识、页面编号等，业务参数可以包括数据源以及参数生成规则。其中，数据源可以为取值区间、数据集合等，参数生成规则包括但不限于随机生成、递增、递减。业务参数还可以包括上下文依赖信息，用于指示各请求之间的关系。

业务流量类型包括但不限于阶梯递增、阶梯递减、突发。策略参数包括变化时间、初始数量、单位时间变化数量。例如对于阶梯递增，策略参数包括递增时间n秒、初始数量为m、单位时间变化数量为每秒增加x个，x大于0、m等于或大于0；对于阶梯递减，策略参数包括变化时间为n秒，初始数量为m，单位时间变化数量为每秒减少x个，m和x均大于0。对于突发，策略参数包括初始数量m，变化时间为0，单位时间变化数量为每秒0个，m大于0；对于突发而言，策略参数的初始数量可以为用户并发数量。这里的数量均指同时发起的请求的数量。

进一步地，所述生成模块402可以包括：

生成子模块4021，用于根据所述请求信息，生成所述协议请求序列；

比例确定子模块4022，用于根据所述业务流程中各个步骤的比例，确定每种协议请求序列的比例；

流转规则确定子模块4023，用于根据所述业务流程，确定协议请求序列的流转规则。

其中，所述分解模块403用于分解测试模型中的协议请求序列以及协议请求序列的比例，得到各个子模型的协议请求序列以及子模型的协议请求序列在所属的子模型中的比例。

所述分解模块403，用于分解测试模型中协议请求序列的参数生成规则。

分解模块403分解测试模型的方式可以参见步骤203，在此省略详细描述。

可选地，所述装置还可以包括：

指标数值确定模块406和调节指令发送模块407，指标数值确定模块406被配置为用于根据所述数据处理模块得到的合并后的测试数据，确定测试指标的数值；调节指令发送模块407被配置为用于当测试指标的数值大于指标设定值时，向各个测试节点发送测试指标对应的调节指令。

其中，该调节指令可以用于指示调节请求生成速率、用户并发数量、每秒发起的请求数量中的至少一种。

其中，该测试指标可以包括响应时间、QPS、系统负载、CPU利用率、数据生成速率、错误率、吞吐量中的至少一种。

可选地，所述装置还可以包括：状态信息获取模块408和输出模块409。状态信息获取模块408被配置为用于获取测试节点的状态信息；输出模块409被配置为用于实时输出所述状态信息获取模块408获取到的所述状态信息。

可选地，该装置还可以包括接收模块410和处理模块411，该接收模块410被配置为用于接收输入的修改指令，该修改指令包括测试节点增加指令、服务器地址变更指令中的至少一种；该处理模块411被配置为用于响应于测试节点增加指令，将子模型发送给新节点，并控制新节点按照分配到的子模型进行性能测试；响应于服务器地址变更指令，将服务器地址同步到各个测试节点。

可选地，该装置还可以包括：控制指令接收模块412和发送模块413，该控制指令接收模块412被配置为接收用户输入的控制指令，发送模块413被配置为控制指令接收模块412接收到的控制指令发送给各个测试节点。控制指令包括但不限于开始指令、暂停指令、结束指令、继续执行指令。

本公开通过获取测试配置信息，根据测试配置信息生成测试模型，并将测试模型分解为至少两个子模型，不需要测试人员编写测试脚本，实现成本低。将至少两个子模型分配给测试节点，并控制各个测试节点按照各自分配到的子模型进行性能测试，适用于大型系统的性能测试。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图6是根据一示例性实施例示出的一种性能测试装置500的框图。例如，装置500可以被提供为一服务器。参照图6，装置500包括处理组件522，其进一步包括一个或多个处理器，以及由存储器532所代表的存储器资源，用于存储可由处理组件522的执行的指令，例如应用程序。存储器532中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件522被配置为执行指令，以执行上述方法。

装置500还可以包括一个电源组件526被配置为执行装置500的电源管理，一个有线或无线网络接口550被配置为将装置500连接到网络，和一个输入输出(I/O)接口558。装置500可以操作基于存储在存储器532的操作系统，例如WindowsServerTM，MacOSXTM，UnixTM,LinuxTM，FreeBSDTM或类似。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器532，上述指令可由装置500的处理组件522执行以完成上述方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

一种非临时性计算机可读存储介质，当所述存储介质中的指令由服务器的处理器执行时，使得服务器能够执行一种性能测试方法，所述方法包括：

获取测试配置信息；

根据所述测试配置信息，生成测试模型；

分解所述测试模型，得到至少两个子模型；

将所述至少两个子模型分配给至少两个测试节点，并控制各个测试节点采用各自分配到的子模型进行性能测试；

接收并合并所述至少两个测试节点发送的测试数据。

在本公开实施例的一种实现方式中，所述测试配置信息包括模型数据和策略规则，所述模型数据包括业务流程、业务流程中各个步骤的请求信息、业务流程中各个步骤的比例以及用户并发数量，所述策略规则包括业务流量类型、策略参数。

其中，所述测试模型包括协议请求序列、每种协议请求序列的比例以及协议请求序列的流转规则。

进一步地，所述根据测试配置信息，生成测试模型，包括：

根据所述请求信息，生成所述协议请求序列；

根据所述业务流程中各个步骤的比例，确定每种协议请求序列的比例；

根据所述业务流程，确定协议请求序列的流转规则。

在本公开实施例的又一种实现方式中，所述分解所述测试模型，得到至少两个子模型，包括：

分解测试模型中的协议请求序列以及协议请求序列的比例，得到各个子模型的协议请求序列以及子模型的协议请求序列在所属的子模型中的比例。

进一步地，所述分解测试模型中的协议请求序列，包括：

分解测试模型中协议请求序列的参数生成规则。

在本公开实施例的又一种实现方式中，所述方法还包括：

根据合并后的测试数据，确定测试指标的数值；

当测试指标的数值大于指标设定值时，向各个测试节点发送测试指标对应的调节指令。

可选地，所述调节指令用于指示调节请求生成速率、用户并发数量、每秒发起的请求数量中的至少一种。

可选地，所述测试指标包括响应时间、QPS、系统负载、中央处理器CPU利用率、数据生成速率、错误率、吞吐量中的至少一种。

在本公开实施例的又一种实现方式中，所述方法还包括：

获取测试节点的状态信息；

实时输出获取到的所述状态信息。

图7为本发明实施例提供的一种性能测试系统，该系统包括控制节点701和至少两个测试节点702。

其中，控制节点701，用于获取测试配置信息；根据所述测试配置信息，生成测试模型；分解所述测试模型，得到至少两个子模型；将所述至少两个子模型分配给至少两个测试节点，并控制各个测试节点采用各自分配到的子模型进行性能测试；

至少两个测试节点702用于在控制节点701的控制下，采用各自分配到的子模型进行性能测试，得到测试数据；并将得到的测试数据发送给控制节点701；

控制节点701还用于接收并合并至少两个测试节点702发送的测试数据。

控制节点701和测试节点702的具体工作过程参见图3所示实施例的具体描述，在此省略详细描述。

本公开通过获取测试配置信息，根据测试配置信息生成测试模型，并将测试模型分解为至少两个子模型，不需要测试人员编写测试脚本，实现成本低。将至少两个子模型分配给测试节点，并控制各个测试节点按照各自分配到的子模型进行性能测试，适用于大型系统的性能测试。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求指出。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。

Claims (22)

1.一种性能测试的方法，其特征在于，所述方法包括：

获取测试配置信息；

根据所述测试配置信息，生成测试模型；

分解所述测试模型，得到至少两个子模型；

将所述至少两个子模型分配给至少两个测试节点，并控制各个测试节点采用各自分配到的子模型进行性能测试；

接收并合并所述至少两个测试节点发送的测试数据。

2.根据权利要求1所述的方法，其特征在于，所述测试配置信息包括模型数据和策略规则，所述模型数据包括业务流程、业务流程中各个步骤的请求信息、业务流程中各个步骤的比例以及用户并发数量，所述策略规则包括业务流量类型、策略参数。

3.根据权利要求2所述的方法，其特征在于，所述测试模型包括协议请求序列、每种协议请求序列的比例以及协议请求序列的流转规则。

4.根据权利要求3所述的方法，其特征在于，所述根据测试配置信息，生成测试模型，包括：

根据所述请求信息，生成所述协议请求序列；

根据所述业务流程中各个步骤的比例，确定每种协议请求序列的比例；

根据所述业务流程，确定协议请求序列的流转规则。

5.根据权利要求3所述的方法，其特征在于，所述分解所述测试模型，得到至少两个子模型，包括：

分解测试模型中的协议请求序列以及协议请求序列的比例，得到各个子模型的协议请求序列以及子模型的协议请求序列在所属的子模型中的比例。

6.根据权利要求5所述的方法，其特征在于，所述分解测试模型中的协议请求序列，包括：

分解测试模型中协议请求序列的参数生成规则。

7.根据权利要求1-6任一项所述的方法，其特征在于，所述方法还包括：

根据合并后的测试数据，确定测试指标的数值；

当所述测试指标的数值大于指标设定值时，向各个所述测试节点发送所述测试指标对应的调节指令。

8.根据权利要求7所述的方法，其特征在于，所述调节指令用于指示调节请求生成速率、用户并发数量、每秒发起的请求数量中的至少一种。

9.根据权利要求7所述的方法，其特征在于，所述测试指标包括响应时间、每秒查询率QPS、系统负载、中央处理器CPU利用率、数据生成速率、错误率、吞吐量中的至少一种。

10.根据权利要求1-6任一项所述的方法，其特征在于，所述方法还包括：

获取测试节点的状态信息；

实时输出获取到的所述状态信息。

11.一种性能测试装置，其特征在于，所述装置包括：

获取模块，用于获取测试配置信息；

生成模块，用于根据所述获取模块获取到的测试配置信息，生成测试模型；

分解模块，用于分解所述生成模块生成的测试模型，得到至少两个子模型；

控制模块，用于将所述分解模块得到的所述至少两个子模型分配给至少两个测试节点，并控制各个测试节点采用各自分配到的子模型进行性能测试；

数据处理模块，用于接收并合并所述至少两个测试节点发送的测试数据。

12.根据权利要求11所述的装置，其特征在于，所述测试配置信息包括模型数据和策略规则，所述模型数据包括业务流程、业务流程中各个步骤的请求信息以及业务流程中各个步骤的比例，所述策略规则包括业务流量类型、用户并发数量、策略参数。

13.根据权利求12所述的装置，其特征在于，所述测试模型包括协议请求序列、每种协议请求序列的比例以及协议请求序列的流转规则。

14.根据权利求13所述的装置，其特征在于，所述生成模块，包括：

生成子模块，用于根据所述请求信息，生成所述协议请求序列；

比例确定子模块，用于根据所述业务流程中各个步骤的比例，确定每种协议请求序列的比例；

流转规则确定子模块，用于根据所述业务流程，确定协议请求序列的流转规则。

15.根据权利求13所述的装置，其特征在于，所述分解模块用于分解测试模型中的协议请求序列以及协议请求序列的比例，得到各个子模型的协议请求序列以及子模型的协议请求序列在所属的子模型中的比例。

16.根据权利要求15所述的装置，其特征在于，所述分解模块，用于分解测试模型中协议请求序列的参数生成规则。

17.根据权利要求11-16任一项所述的装置，其特征在于，所述装置还包括：

指标数值确定模块，用于根据所述数据处理模块得到的合并后的测试数据，确定测试指标的数值；

调节指令发送模块，用于当所述测试指标的数值大于指标设定值时，向各个所述测试节点发送所述测试指标对应的调节指令。

18.根据权利要求17所述的装置，其特征在于，所述调节指令用于指示调节请求生成速率、用户并发数量、每秒发起的请求数量中的至少一种。

19.根据权利要求17所述的装置，其特征在于，所述测试指标包括响应时间、每秒查询率QPS、系统负载、中央处理器CPU利用率、数据生成速率、错误率、吞吐量中的至少一种。

20.根据权利要求11-16任一项所述的装置，其特征在于，所述装置还包括：

状态信息获取模块，用于获取测试节点的状态信息；

输出模块，用于实时输出所述状态信息获取模块获取到的所述状态信息。

21.一种性能测试装置，其特征在于，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

获取测试配置信息；

根据所述测试配置信息，生成测试模型；

分解所述测试模型，得到至少两个子模型；

将所述至少两个子模型分配给至少两个测试节点，并控制各个测试节点采用各自分配到的子模型进行性能测试；

接收并合并所述至少两个测试节点发送的测试数据。

22.一种性能测试系统，其特征在于，所述系统包括：控制节点和至少两个测试节点，

所述控制节点，用于获取测试配置信息；根据所述测试配置信息，生成测试模型；分解所述测试模型，得到至少两个子模型；将所述至少两个子模型分配给至少两个测试节点，并控制各个测试节点采用各自分配到的子模型进行性能测试；

所述至少两个测试节点用于在所述控制节点的控制下，采用各自分配到的子模型进行性能测试，得到测试数据；并将得到的所述测试数据发送给所述控制节点；

所述控制节点还用于接收并合并所述至少两个测试节点发送的测试数据。