一种分布式压力测试方法和系统技术领域
本发明涉及压力测试领域，尤其涉及一种分布式压力测试方法和系统。
背景技术
随着互联网的兴起与发展，WEB(网页)类系统或者接口需提供给越来越多的用户
访问，不断增长的用户访问需求对系统的并发量和承载能力提出了越来越高的要求，因此
对系统进行压力测试的必要性也越来越高。
压力测试通过模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或
超大负荷地运行测试软件，来测试被测系统的性能、可靠性、稳定性等。目前，有很多的方法
可以对系统进行压力测试，主要有利用压测工具(如loadrunner、JMeter、Grinder等等)和
通过编程实现两种方法。但是，现有的绝大部分压测工具仅能在本地的单台压测机器上运
行，测试工具的选择比较复杂和多样化，每个测试人员可能都需要搭建一个压力测试工具
的使用环境，造成了资源的浪费，缺乏统一的集中管理。同时，单台机器可能不能满足大量
的压测任务，只能手动地将不同的压测任务分配到不同的机器上执行，效率较低。而通过编
程实现则需要采用多线程或多进程的方式生成大量的并发请求来模拟用户行为，对被测系
统进行访问，对测试人员的编程能力及技术功底有较高要求，并且需要耗费大量的时间去
设计实现，同时实现的测试方法往往仅适用于单个系统，可复用度较低，测试结果的可信度
需要验证，工具的学习成本往往较高。
发明内容
本发明实施例的目的在于提供一种分布式压力测试方法和系统，对压力测试任务
进行集群化的统一管理，实现分布式的压力测试，减少资源浪费、降低压力测试成本、提高
压力测试效率。
为实现上述目的，本发明实施例提供了一种分布式压力测试系统，包括控制服务
器和由至少两个测试机组成的测试集群；
所述测试机包括负载均衡模块；
所述负载均衡模块，用于采集所述测试机的资源使用情况，根据所述资源使用情
况得到所述测试机的加权优先级，并将所述测试机的IP地址和对应的加权优先级反馈给所
述控制服务器；
所述控制服务器包括第一消息处理模块；
所述第一消息处理模块，用于根据各个测试机的加权优先级和对应的IP地址，将
任务类消息分发给加权优先级最高的测试机；
所述测试机还包括第二消息处理模块和压测引擎模块；
所述第二消息处理模块，用于接收所述控制服务器发送来的任务类消息，从所述
任务类消息中解析出对应的压力测试任务，并将所述压力测试任务发送给所述压测引擎模
块；
所述压测引擎模块，用于执行所述压力测试任务。
优选地，所述第一消息处理模块，还用于将配置类消息广播给所有测试机；
所述第二消息处理模块，还用于接收所述控制服务器发送来的配置类消息，从所
述配置类消息中解析出对应的配置操作任务，并将所述配置操作任务发送给所述压测引擎
模块；
所述压测引擎模块，还用于执行所述配置操作任务。
进一步地，所述控制服务还包括UI模块；
所述UI模块，用于根据用户的UI操作生成所述任务类消息或所述配置类消息。
优选地，所述分布式压力测试系统还包括数据库；
所述数据库，用于存储所述负载均衡模块反馈的IP和对应的加权优先级；
所述负载均衡模块包括采集单元，用于采集测试集群中各个测试机的资源使用情
况，根据所述资源使用情况得到所述测试机的加权优先级，并将所述测试机的IP地址和对
应的加权优先级以心跳的方式上传到数据库；
所述第一消息处理模块包括获取单元，用于当所述控制服务器生成所述任务类消
息后，从所述数据库中读取所有测试机的加权优先级和对应的IP地址。
优选地，所述资源使用情况包括CPU使用率、内存使用率、磁盘使用率、网络使用率
以及接收到的请求量中的一种或多种组合。
相应地，本发明实施例还提供了一种分布式压力测试方法，包括：
采集测试集群中各个测试机的资源使用情况，根据所述资源使用情况得到所述测
试机的加权优先级，并将所述测试机的IP地址和对应的加权优先级反馈给控制服务器；
所述控制服务器根据各个测试机的加权优先级和对应的IP地址，将任务类消息分
发给加权优先级最高的测试机；
所述测试机接收所述控制服务器发送来的任务类消息，从所述任务类消息中解析
出对应的压力测试任务，并执行所述压力测试任务。
优选地，在所述采集测试集群中各个测试机的资源使用情况，根据所述资源使用
情况得到所述测试机的加权优先级，并将所述测试机的IP地址和对应的加权优先级反馈给
控制服务器之前，还包括：
所述控制服务器将配置类消息广播给所有测试机；
所述测试机接收所述控制服务器发送来的配置类消息，从所述配置类消息中解析
出对应的配置操作任务，并执行所述配置操作任务。
进一步地，在所述控制服务器将配置类消息广播给所有测试机之前，还包括：
所述控制服务器根据用户的UI操作生成所述任务类消息或所述配置类消息。
优选地，所述采集测试集群中各个测试机的资源使用情况，根据所述资源使用情
况得到所述测试机的加权优先级，并将所述测试机的IP地址和对应的加权优先级反馈给控
制服务器，包括：
采集测试集群中各个测试机的资源使用情况，根据所述资源使用情况得到所述测
试机的加权优先级，并将所述测试机的IP地址和对应的加权优先级以心跳的方式上传到数
据库；
当所述控制服务器生成所述任务类消息后，从所述数据库中读取所有测试机的加
权优先级和对应的IP地址。
优选地，所述资源使用情况包括CPU使用率、内存使用率、磁盘使用率、网络使用率
以及接收到的请求量中的一种或多种组合。
本发明通过分布式化的压力测试系统使得测试人员可以同时运行大量压测任务，
有利于提高压测效率。通过采集测试集群中各个测试机的资源使用情况，得到测试机的加
权优先级，将压力测试任务分发给加权优先级最高的测试机去执行，实现负载均衡，有利于
提高资源利用率。
进一步地，本发明通过压测引擎模块可以将压测工具统一部署到测试机，并对配
置、测例、测试结果、测试报告等进行统一管理，减少环境成本和维护成本，提高测试效率。
附图说明
图1是本发明提供的分布式压力测试系统的一个实施例的结构图；
图2是如图1所示实施例提供的消息处理架构的一个实施例的架构图；
图3是本发明提供的分布式压力测试方法的一个实施例的流程图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完
整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于
本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他
实施例，都属于本发明保护的范围。
参见图1，是本发明提供的分布式压力测试系统的一个实施例的结构图。
如图1所示，所述分布式压力测试系统包括控制服务器(Master)10和由至少两个
测试机(Slave-1～n)200组成的测试集群20；所述控制服务器10为系统的控制端，负责将压
测任务及配置信息发送至测试机并接收处理结果。所述测试机200为系统的被控端，设置有
压测引擎模块，负责接收压测任务和配置并对被测服务器进行压力测试。
所述测试机200包括负载均衡模块201；
所述负载均衡模块201，用于采集所述测试机200的资源使用情况，根据所述资源
使用情况得到所述测试机200的加权优先级，并将所述测试机200的IP地址和对应的加权优
先级反馈给所述控制服务器10；
在一种优选的实施方式当中，所述资源使用情况包括CPU、内存、磁盘和网络中的
一种或多种资源的使用情况，加权优先级(Weight)的计算方法如下：
![]()
其中，CPUp、MEMp、DISKp、NETp为各指标的资源使用率，各指标的加权系数K1～K4的
大小可根据压测引擎对资源的消耗程度设置，在一种优选的实施方式当中，K1＝0.4,K2＝
0.3,K3＝0.2,K4＝0.1。当CPU、内存、磁盘、网络中任何一个资源使用率大于90％(本领域技
术人员可根据实际需要对该值进行调整)时，将该Slave节点从可用节点中移除(将其加权
优先值设为-1)，直至该节点资源恢复可用状态(资源使用率小于90％)。
在另一种优选的实施方式当中，所述资源使用情况包括测试机接收到的请求量，
通过LVS-NAT等负载均衡方案计算所述测试机的加权优先级，以达到类似的目的。与前述实
施方式相比，本实施方式通过请求量来进行负载均衡，前述实施方式则通过收集Slave节点
的真实资源使用情况并计算加权优先级进行负载均衡，前者更能反映测试机的空闲状态。
所述控制服务器10包括第一消息处理模块101；
所述第一消息处理模块101，用于根据各个测试机200的加权优先级和对应的IP地
址，将任务类消息分发给加权优先级最高的测试机200；
所述测试机200还包括第二消息处理模块202和压测引擎模块203；
所述第二消息处理模块202，用于接收所述控制服务器10发送来的任务类消息，从
所述任务类消息中解析出对应的压力测试任务，并将所述压力测试任务发送给所述压测引
擎模块203；
所述压测引擎模块203，用于执行所述压力测试任务。所述压测引擎模块203是一
个专门负责压测任务执行的模块，负责接收压测任务、构造并发送请求对被测服务器进行
压力测试。
在具体实施当中，所述第一消息处理模块101，还用于将配置类消息广播给所有测
试机200；
所述第二消息处理模块202，还用于接收所述控制服务器10发送来的配置类消息，
从所述配置类消息中解析出对应的配置操作任务，并将所述配置操作任务发送给所述压测
引擎模块203；
所述压测引擎模块203，还用于执行所述配置操作任务。
本发明通过配置类消息的广播和执行，可对slave节点进行统一的部署和配置，保
证所有分布式slave节点数据的完整性和一致性。
具体地，所述第二消息处理模块202用于接收控制服务10发送来的消息(包括任务
类消息和配置类消息)，解析消息内容，根据消息内容产生对应的处理任务(包括压力测试
任务和配置操作任务)，并将处理任务交给压测引擎模块203执行，并根据任务的执行结果
生成响应消息返回给控制服务器10。所述压测引擎模块203负责执行slave节点中第二消息
处理模块202接收到的任务(包括压力测试任务和配置操作任务)，主要包括压测任务的配
置文件生成、测例代码生成、任务执行和测试报告生成等。
在一种优选的实施方式当中，所述分布式压力测试系统还包括数据库(Mysql)30；
所述数据库30，用于存储所述负载均衡模块201反馈的IP和对应的加权优先级；
所述负载均衡模块201包括采集单元，用于采集测试集群中各个测试机的资源使
用情况，根据所述资源使用情况得到所述测试机的加权优先级，并将所述测试机的IP地址
和对应的加权优先级以心跳的方式上传到数据库。
所述第一消息处理模块包括获取单元，用于当所述控制服务器10生成所述任务类
消息后，从所述数据库30中读取所有测试机的加权优先级和对应的IP地址，以获取加权优
先级最高的测试机的IP地址。
此外，压测引擎模块200还可进一步将测试结果和被测系统所在服务器资源使用
数据写入数据库中以供控制服务器10中UI模块查询和展示。
本实施方式当中，负载均衡模块201会以心跳的方式将其所在测试机的IP地址和
加权优先级存入数据库30中。当控制服务器10产生一个任务类消息时，会从数据库30中读
取测试集群20的所有可用测试机节点的IP地址和加权优先级，并将该任务类消息发送给较
为空闲(加权优先级最高)的机器。通过数据库30作为数据传输的存储和中转，可根据压测
需求动态的调整Slave节点的数量(只需在数据库的Slave信息表中注册添加测试机IP，并
在该节点以其IP作为routing_key运行第二消息处理模块和压测引擎模块即可，无需重启
服务)。
进一步地，如图1所示，所述控制服务还包括UI模块102；
所述UI(User Interface，用户界面)模块102，用于根据用户的UI操作生成所述任
务类消息或所述配置类消息。
UI模块102为用户提供简便操作，这些操作可分为两种类型：任务类操作和配置类
操作。任务类操作是指只需在单台slave节点执行的操作，此类操作不会破坏Slave节点数
据的完整性和一致性，一般包括信息读取和压测任务执行，如申请测例录制代理、启动测例
录制、停止测例录制、预览测例代码、启动测试任务、获取任务log(日志)信息等。配置类操
作是指需在所有slave节点执行的操作，这些操作必须保证所有分布式slave节点数据的完
整性和一致性，一般包括任务创建编辑和配置下发，如创建任务、编辑任务、删除任务、任务
配置、测例代码保存等。
在一种优选的实施方式当中，所述控制服务器10中的第一消息处理模块101和所
述测试机200中的第二消息处理模块202之间使用RabbitMQ作为消息系统媒介。RabbitMQ是
一个消息代理，它可以为你的应用提供一个通用的消息发送和接收平台，并且保证消息在
传输过程中的安全。
在具体实施当中，第一消息处理模块101和第二消息处理模块202集成RabbitMQ负
责生成、发送、接收任务消息。Master节点的第一消息处理模块101主要负责解析用户在UI
上的操作并将这些操作生成对应的消息，然后通过RabbitMQ将消息发送给指定Slave节点，
并接收Slave节点通过RabbitMQ返回的响应消息。Slave节点的第二消息处理模块202则负
责接收Master节点通过RabbitMQ发出的消息，并解析消息内容生成对应任务交给压测引擎
模块执行，并根据任务的执行结果生成响应消息通过RabbitMQ返回给Master。
消息处理架构如图2所示，整个架构中有faout和direct两种类型的交换机
(exchange)，名称分别为config(配置)和task(任务)，Slave节点的消息模块启动时会声明
一个消息队列(queue)。所有Slave节点的消息队列会绑定(binding)到config交换机，同时
会将该消息队列以Slave节点的IP作为绑定键(routing_key)绑定到task交换机。
Master发送消息时会声明回调队列(reply_to)和关联标识(correlation_id)，关
联标识为请求的uuid，当Slave节点收到Master发送的消息并处理后会产生响应消息，该响
应消息会通过回调队列发送给Master。
当Master产生配置类消息时，会将该消息发送给config交换机，config交换机会
将收到的消息广播至所有与之绑定的Slave节点的消息队列，从而达到配置分发和数据一
致性的目的。当Master产生任务类消息时，首先会从数据库中读取所有Slave节点的加权优
先级并获取最为空闲(加权优先级最高)的Slave节点的IP地址，然后将该IP地址作为
routing_key并将该任务类消息发送给task交换机，task交换机会根据消息的routing_key
将该消息路由到对应Slave节点的消息队列中，从而达到负载均衡的目的。
如图2所示，假如测试集群中有IP为192.168.44.16和192.168.44.17两台Slave
(测试机)A和B，并且其负载均衡加权优先级分别为50.0和60.0。当用户在UI上进行配置类
操作(如配置保存)产生配置类消息时，Master便会将该消息发送给config交换机，并通过
config交换机将该消息广播至A、B两台测试机。当用户在UI上进行任务类操作(如执行测试
任务)产生任务类消息时，Master会从数据库中读取A、B两台Slave节点的加权优先级并获
取最为空闲的B节点的IP地址192.168.44.17，然后将192.168.44.17作为routing_key并将
该任务类消息发送给task交换机，task交换机便会将该消息只转发给B节点。
本实施方式中消息处理采用异步通讯方式的RabbitMQ，可以减少用户等待时间，
进一步提高压测的效率。应当说明的是，上述实施方式仅为本发明的一种优选实施方式，本
领域技术人员也可根据实际需要，采用其他方式以实现消息模块之间的通讯，如作为一种
次选的实施方式，也可通过API(Application Programming Interface，应用程序编程接
口)的方式进行同步通讯，实现消息模块之间的信息交互。
本发明为压力测试提供一种分布式化及负载均衡的解决方案，主要解决以下问
题：压测工具选取多样、复杂问题：本发明的压测引擎模块集成一种通用的压力测试工具，
所有的压测引擎统一部署到测试集群的各个节点上，无需测试人员单独搭建压测工具的使
用环境，所有测例的编写方式统一；任务、测例、结果分散问题：测试人员生成的测试任务、
配置、测例、测试结果、报告等由系统统一进行管理；单台机器不能满足多任务、多系统压测
需求问题：本发明提供负载均衡解决方案，可以根据测试集群中每个节点的资源使用情况
将测试任务分配给测试集群中较为空闲的机器。
参见图3，是本发明提供的分布式压力测试方法的一个实施例的流程图。本实施例
的基本原理与图1所示实施例一致，本实施例中未详述之处可参见图1所示实施例中的相关
描述。
如图2所示，所述分布式压力测试方法，包括：
S1，采集测试集群中各个测试机的资源使用情况，根据所述资源使用情况得到所
述测试机的加权优先级，并将所述测试机的IP地址和对应的加权优先级反馈给控制服务
器；
S2，所述控制服务器根据各个测试机的加权优先级和对应的IP地址，将任务类消
息分发给加权优先级最高的测试机；
S3，所述测试机接收所述控制服务器发送来的任务类消息，从所述任务类消息中
解析出对应的压力测试任务，并执行所述压力测试任务。
其中，所述资源使用情况包括CPU使用率、内存使用率、磁盘使用率、网络使用率以
及接收到的请求量中的一种或多种组合。
在具体实施当中，在所述步骤S1之前，还包括：
S21，所述控制服务器将配置类消息广播给所有测试机；
S22，所述测试机接收所述控制服务器发送来的配置类消息，从所述配置类消息中
解析出对应的配置操作任务，并执行所述配置操作任务。
进一步地，在所述步骤S21之前，还包括：
S20，所述控制服务器根据用户的UI操作生成所述任务类消息或所述配置类消息。
在一种优选的实施方式当中，所述步骤S1具体包括：
S11，采集测试集群中各个测试机的资源使用情况，根据所述资源使用情况得到所
述测试机的加权优先级，并将所述测试机的IP地址和对应的加权优先级以心跳的方式上传
到数据库；
S12，当所述控制服务器生成所述任务类消息后，从所述数据库中读取所有测试机
的加权优先级和对应的IP地址。
综上所述，本发明通过分布式化的压力测试系统使得测试人员可以同时运行大量
压测任务，有利于提高压测效率。通过采集测试集群中各个测试机的资源使用情况，得到测
试机的加权优先级，将压力测试任务分发给加权优先级最高的测试机去执行，实现负载均
衡，有利于提高资源利用率。本发明通过压测引擎模块可以将压测工具统一部署到测试机，
并对配置、测例、测试结果、测试报告等进行统一管理，减少环境成本和维护成本，提高测试
效率。
需说明的是，以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件
说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以
不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的
需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本发明提供的装置
实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或
多条通信总线或信号线。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解
并实施。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本发明可借
助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专
用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以
很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多
样的，例如模拟电路、数字电路或专用电路等。但是，对本发明而言更多情况下软件程序实
现是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出
贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质
中，如计算机的软盘，U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储
器(RAM，Random Access Memory)、磁碟或者光盘等，包括若干指令用以使得一台计算机设
备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何
熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵
盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。