CN104077212B - 压力测试系统及方法 - Google Patents

Abstract

本申请公开了压力测试系统及方法，该系统为由控制节点及代理节点组成的集群，用于进行消息转换的控制节点包括：外部消息接收单元，用于接收业务控制消息；节点确定单元，用于确定目标控制节点和/或目标代理节点；内部消息生成单元；消息发送单元，用于将内部消息发送到目标控制节点和/或目标代理节点；所述代理节点用于对测试任务执行相应的操作，对性能数据进行记录，将性能数据发送到目标控制单元；用于进行数据收集的控制单元包括：监听单元，用于监听代理节点的性能数据；回传单元，用于根据收集到的性能数据向外部业务系统进行回传。通过本申请，能够提供一种可以共享、支持多测试任务的压力测试方案。

Description

压力测试系统及方法

技术领域

本申请涉及软件测试技术领域，特别是涉及压力测试系统及方法。

背景技术

系统压力测试就是指对被测系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。例如，测试一个Web站点在大量的负荷下，何时系统的响应会退化或失败。

压力测试工具的原理是：客户端通过多线程或多进程模拟虚拟用户访问，对服务器端施加压力，然后在过程中监控和收集性能数据。压力测试工具中的压力产生模块可以根据脚本内容产生实际的负载，也就根用户的设置，进行自我复制来生成多个客户端向服务器发送请求。对于压力测试工具来说，每复制出来的一份，就是一个进程或线程，进程和线程的运行是要占用系统资源的。所以，对于一台压力测试机来说，能运行的虚拟用户数也是有限的。如果一台压力测试机不能模拟足够多的虚拟用户，此时就要通过多台压力测试机合作，以模拟更多的虚拟用户向服务器发请求。

传统的压力测试工具能够通过控制台-代理(Console-Agent)的连通从一定程度上解决了单机施压压力不够的问题。但是，这些压力测试工具作为一种桌面应用，只能被一个性能测试工程师独立使用，独占式的编写脚本、独占式的规划测试，独占式的运行测试和分析结果，独占式的使用多台压力测试机。对于一个中小型公司而言，这可能不是问题，但是在大型互联网公司中，这意味着低下的工作效率。如果想要扩大测试团队规模，这意味着巨额的软硬件成本开销。因为每个测试人员都需要有自己的测试工具，并且有一套自己的用作压力测试机以及代理的硬件设备，这势必造成非常严重的资源浪费。

发明内容

本申请提供了压力测试系统及方法，能够提供一种可以共享、支持多测试任务的压力测试方案。

本申请提供了如下方案：

一种压力测试系统，所述系统包括由至少一个控制节点以及至少一个代理节点组成的集群，其中：

所述控制节点包括用于进行消息转换的控制节点以及用于进行数据收集的目标控制节点；

所述用于进行消息转换的控制节点包括：

外部消息接收单元，用于接收外部业务系统的业务控制消息；

节点确定单元，用于确定用于进行数据收集的目标控制节点和/或用于进行任务执行的目标代理节点；

内部消息生成单元，用于根据所述业务控制消息以及目标控制节点和/或目标代理节点的信息，生成第一内部消息和/或第二内部消息；

消息发送单元，用于将所述第一内部消息发送到所述目标控制节点，和/或，将所述第二内部消息发送到所述目标代理节点；

所述代理节点包括：

任务执行单元，用于根据接收到的第二内部消息对测试任务执行相应的操作；

数据收集单元，用于对任务执行过程中产生的性能数据进行记录；

数据发送单元，用于将记录的性能数据发送到所述用于进行数据收集的目标控制单元；

所述用于进行数据收集的控制单元包括：

监听单元，用于监听所述代理节点发送的性能数据；

回传单元，用于根据收集到的性能数据向外部业务系统进行数据回传。

一种压力测试方法，其特征在于，包括：

接收外部业务系统的业务控制消息；

确定用于进行数据收集的目标控制节点和/或用于进行任务执行的目标代理节点；

根据所述业务控制消息以及目标控制节点和/或目标代理节点的信息，生成第一内部消息和/或第二内部消息；

将所述第一内部消息发送到所述目标控制节点，和/或，将所述第二内部消息发送到所述目标代理节点；以便所述目标代理节点根据接收到的第二内部消息对测试任务执行相应的操作，对任务执行过程中产生的性能数据进行记录，并将记录的性能数据发送到所述用于进行数据收集的目标控制单元；所述用于进行数据收集的目标控制单元监听所述目标代理节点发送的性能数据，根据收集到的性能数据向外部业务系统进行数据回传。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请，能够提供一个压力测试集群，集群中可以包括控制节点以及代理节点，外部业务系统可以通过集群提供的服务接口向集群发送业务控制消息，集群中的控制节点在接收到业务控制消息之后，可以确定出用于进行数据收集的控制节点(数据收集节点)和/或进行任务执行的代理节点(任务执行节点)，并将业务控制消息转换为内部消息，并将内部消息发送到数据收集节点和/或任务执行节点；这样，任务执行节点就可以根据接收到的内部消息执行相应的任务操作，并对任务执行过程中产生的性能数据进行记录，并发送到数据收集节点；数据收集节点可以在监听到代理节点发送的性能数据之后，根据收集到的数据向外部业务系统提供相应的数据，使得外部业务系统获得压力测试结果。可见，通过这种方式，使得多个外部业务系统能够共享该压力测试集群，这样，可以避免在压力测试过程中对软硬件资源造成的浪费。

另外，集群中的各个节点可以通过节点注册表来维护集群中的节点信息，并且可以在节点加入或退出集群时，向集群中的其他节点进行通知，使得集群中的其他节点可以更新节点注册表，即使某节点发生宕机，集群也可在检测到后将其剔除，使得压力测试集群中的节点的维护成本几乎可以忽略不计。

再者，在代理节点具体进行任务执行时，如果一个测试任务包括多个场景，则可以以场景为单位创建测试进程，然后在进程中，根据对应场景中需要模拟的虚拟用户数创建相应数目的测试线程，这样可以避免过多的占用代理节点的资源，提高集群的性能。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的第一系统的示意图；

图2是本申请实施例提供的第二系统的示意图；

图3是本申请实施例提供的第三系统的示意图；

图4是本申请实施例提供的第四系统的示意图；

图5是本申请实施例提供的方法的流程图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，提供了一种用于进行压力测试的集群，并将启动测试任务(脚本执行)、停止测试任务、暂停测试任务、继续测试任务、测试进程/线程管理(虚拟用户数的修改，包括增加或者减少)和数据统计等抽象出来作为服务对外提供，外部业务系统可以通过这些服务向压力测试集群提交测试任务，并进行后续的控制、管理等操作。因此，外部业务系统可以不用再单独部署压力测试所需的硬件系统，并且，压力测试集群可以同时接收并执行多个测试任务，相当于提供了一种可以共享、实时在线、支持多测试任务的压力测试系统。

在集群内部，由控制节点和代理节点构成，每个节点都是一个独立的运行单元。控制节点又可以分为用于进行消息转换的控制节点，以及用于进行数据收集的控制节点。当然，这属于逻辑上的划分，在实际应用中，对于同一个测试任务而言，用于进行消息转换的控制节点与用于进行数据收集的控制节点可能是同一个控制节点。其中，用于进行消息转换的控制节点可以通过消息机制接收外部业务系统的业务控制信息，然后产生多条集群内部消息发送给用于进行数据收集的控制节点和/或代理节点进行处理。代理节点可以根据接收到的内部消息，产生和管理实际的任务执行进程，同时负责在节点粒度上汇总一个任务的多个执行进程所产生的性能数据，并发送到用于进行数据收集的控制节点。用于进行数据收集的控制节点可以接收代理节点执行任务时产生的结果数据。如果同一个测试任务由多个代理节点执行，那么数据会在用于进行数据收集的控制节点处进行汇总，然后用于进行数据收集的控制节点会将数据通过外部接口回传给外部业务系统；或者，可以对收集到的数据按照一定的采样频率进行采样，然后将采样结果回传到外部业务系统。

参见图1，本申请实施例提供了一种压力测试系统，该系统包括至少一个控制节点以及至少一个代理节点103，其中，控制节点包括用于进行消息转换的控制节点101以及用于进行数据收集的控制节点102，用于进行消息转换的控制节点101具体可以包括：

外部消息接收单元1011，用于接收外部业务系统的业务控制消息；

节点确定单元1012，用于确定用于进行数据收集的目标控制节点和/或用于进行脚本执行的目标代理节点；

内部消息生成单元1013，用于根据所述业务控制消息以及目标控制节点和/或目标代理节点的信息，生成待发送到目标控制节点的第一内部消息和/或待发送到目标代理节点的第二内部消息；

消息发送单元1014，用于将所述第一内部消息发送到所述目标控制节点，和/或，将所述第二内部消息发送到所述目标代理节点；

所述代理节点103包括：

任务执行单元1031，用于根据接收到的第二内部消息对测试任务执行相应的操作；

数据收集单元1032，用于对任务执行过程中产生的性能数据进行记录；

数据发送单元1033，用于将记录的性能数据发送到所述用于进行数据收集的目标控制单元；

所述用于进行数据收集的控制单元102包括：

监听单元1021，用于监听所述代理节点发送的性能数据；

回传单元1022，用于根据收集到的性能数据向外部业务系统进行数据回传。

本申请实施例提供的压力测试集群的重点是消息机制，集群通过消息与外部系统通信，降低系统间的耦合，使得平台接入变得简单；集群内部通过消息互通各个节点的状态并进行业务传递。但这两种消息有着很大的区别，为便于描述，可以将前者称为外部消息，后者称为内部消息。集群的外部消息可以采用AMQP(Advanced Message QueuingProtocol，高级消息队列协议)消息协议，可以使用如RabbitMQ(是一种开源消息队列系统，用erlang语言开发)这样的消息中间件来实施。内部消息可以使用JGroups实现，JGroups是一个开源的纯JAVA编写的可靠的群组通讯工具包，利用JGroups，压力测试集群中的节点可以方便的实现消息单播和组播。

例如，具体实现时，压力测试集群中的控制节点可以通过AMQP消息协议与外部业务系统进行被动连接，通过监听特定的消息队列来处理外部消息。外部消息被转换成为集群内部消息，如果是脚本执行或者压力(压力测试进程/线程)控制相关的消息会发送给特定的代理节点，如果是数据收集、采样相关的消息则发送给相应的控制节点。压力测试集群中的代理节点负责控制具体的压测进程/线程的生命周期，进程/线程产生原始数据通过消息传送到负责数据收集的控制节点，最终由控制节点通过消息或者RPC接口返回给外部业务系统，使得外部业务系统获取到压力测试相关的性能数据。

其中，如果用于进行消息转换的控制节点101接收到的业务控制消息是启动测试任务的启动消息，则该启动消息中可以携带多方面的信息，例如，包括测试任务的信息(例如，外部业务系统的服务器地址等)、测试时使用的测试脚本、需要模拟的虚拟用户数等等。在实际应用中，对于同一个测试任务而言，可能需要在多种场景下进行测试，例如，在对某Web服务进行测试时，可以在用户浏览网页的场景下模拟多个虚拟用户，同时还需要在购买网页中的商品的场景下模拟多个虚拟用户。此时，可针对各个不同的场景分别提供测试脚本，在向压力测试集群发送启动消息时，可携带测试任务包括的场景、各个场景对应的测试脚本、各个场景下需要模拟的虚拟用户数等信息。

控制节点101在接收到启动消息时，参见图2，其节点确定单元1012可以包括：节点选择子单元10121，用于从各个控制节点中选择出用于针对此次测试任务进行数据收集的目标控制节点，从各个代理节点中选择出用于执行此次测试任务的目标代理节点。然后就可以根据选择出的控制节点及代理节点生成内部消息，然后将部分内部消息发送到用于进行数据收集的控制节点102，将测试任务的标识和执行该测试任务的代理节点103的信息发送给控制节点102，以便通知对应的控制节点102需要对哪个测试任务的数据进行收集，并对执行该测试任务的代理节点103进行监听，以便收集代理节点103在执行测试任务的过程中产生的性能数据。

另外一部分内部消息发送到用于执行此次测试任务的代理节点103，将需要执行的测试脚本、需要模拟的虚拟用户的数目等信息发送到代理节点103。相应的，代理节点103中的任务执行单元1031可以包括：脚本执行子单元10311，用于根据接收到的第二内部消息执行测试任务的测试脚本。如果一个测试任务包括多个场景，则还可将场景信息以及各个场景与测试脚本之间的对应关系、各个场景中需要模拟的虚拟用户数等信息发送到代理节点103。这样，代理节点103就可以以创建测试进程，并执行对应的测试脚本。

在实际应用中，如果一个测试任务需要模拟的场景、用户数目的规模非常大，或者各个代理节点的资源利用率都已经比较高的情况下，则可能会将一个测试任务分配到多个不同的代理节点上执行。但是，对于同一个测试任务而言，用于进行数据收集的控制节点可以只有一个，这样，可以使得同一个测试任务在不同的代理节点上执行时获取到的性能数据被汇总到控制节点中，然后再回传到外部业务系统。也就是说，用于进行数据收集的控制节点102还可以包括：数据汇总单元，用于将各个代理节点发送的关于同一测试任务的性能数据进行汇总。

而控制节点101在接收到启动测试任务的启动消息之后，一个主要的逻辑就是如何选择出用于进行数据收集的控制节点102(称为数据收集节点)和用于执行测试任务的代理节点103(任务执行节点)。具体实现时，可以维护一个设计对象，例如节点注册表，这样，控制节点101在进行消息转换处理的过程中，就可以通过调用节点注册表的接口方法来获取可用的数据收集节点和任务执行节点。

其中，节点注册表中包含当前集群中所有节点的相关信息，各个节点可以按照节点类别存放在AGENT_FORM和CONTROLLER_FORM两个列表中，AGENT_FORM列表用于存放各个代理节点的相关信息，CONTROLLER_FORM列表用于存放各个控制节点的相关信息。当有节点加入或者离开集群时，都会向集群中的各个现有节点发送通知消息，相应的，集群中的现有节点都会收到消息通知，对节点注册表进行更新。

另外，集群中的每个节点都可以按照一定频率(例如5S、10S等)将自身的资源使用信息通过消息组播发送到其他节点。在处理启动消息的过程中，节点注册表的nextAgent和nextController方法可以被调用，用来分配节点给当前测试任务和场景。在这些方法中，可以首先对节点表进行权重排序，然后选择权重最低的节点来分配。其中，一个节点的权重可以通过计算该节点的资源利用率来实现。在实现过程中，具体可以采用磁盘利用率和内存利用率作为阈值，例如，当磁盘利用率超过90％，可用物理内存小于500M，则将该节点权重设置为极高；否则，通过计算当前节点的负载和CPU利用率得出权重值：负载越低、CPU利用率越低则计算出的权重越低。在为当前测试任务选择控制节点及代理节点时，就可以根据计算出的各个节点的权重，进行选择。

也就是说，前文所述节点选择子单元可以包括：

资源利用率信息接收子单元，用于接收集群中的各个节点通过消息组播的方式按照指定频率向集群中的其他节点发送的消息，所述消息中携带有各个节点自身的资源利用率信息；

选择子单元，用于根据当前接收到的各个节点的资源利用率，选择出资源利用率符合预置条件的节点作为所述目标控制节点以及目标代理节点。

在实际应用中，在为一个测试任务选择了收据收集节点以及任务执行节点之后，还可以将该测试任务的标识信息(例如，任务ID，用来唯一标识一个任务，集群中不允许同时运行多个相同ID的测试任务)以及对应的节点分配情况添加到任务注册表中。在任务注册表中维护从任务ID到数据收集信息以及任务执行信息的映射。如果一个测试任务中包括多个场景，则每个场景也可以有对应的场景标识信息(例如场景ID)。例如，某测试任务T包括三个场景，其中，场景1和场景2被分配到代理节点A上执行，场景3被分配到代理节点B上执行，并分配控制节点C作为收集数据的节点，则在任务注册表中可以添加以下信息：

任务ID：T

场景ID：1，任务执行节点：代理节点A；

场景ID：2，任务执行节点：代理节点A；

场景ID：3，任务执行节点：代理节点B；

数据收集节点：控制节点C。

也即，用于进行消息转换的控制节点还可包括：任务注册单元，用于保存待测任务的标识信息与分配给待测任务的节点信息之间的对应关系，生成任务注册表；所述分配给待测任务的节点包括用于对待测任务进行数据收集的控制节点及用于执行测任务各个场景的测试脚本的代理节点。

需要说明的是，任务注册表和节点注册表可以通过集群消息同步机制在集群中每个节点上被实时同步，所以任何一个节点都可以有集群中当前所有的任务运行信息和节点信息。

由于对各个测试任务的标识以及节点分配信息保存在任务注册表中，因此，外部业务系统可以向集群发送消息对指定的测试任务进行管理或控制，相应的，集群在接收到外部业务系统的管理或者控制消息时，就可以根据指定测试任务的标识信息在任务注册表中找到对应的节点分配信息，然后将对应的节点发送相应的内部消息，以完成相应的管理或控制。

例如，外部业务系统在获取到测试过程中的性能数据之前，无法获知多少用户访问时会达到系统的临界点，因此，预先设定的需要模拟的虚拟用户数一般只是一个估计值，而在测试过程中，得到一些性能数据之后，可能需要多次反复修改虚拟用户数，以便最终得到相对准确的临界点。也就是说，在启动一个测试任务之后，可能需要对虚拟用户数进行增加或者减少。此时，外部业务系统就可以根据压力测试集群提供的修改虚拟用户数服务，向集群发出相应的消息，并携带测试任务的标识信息，以及修改后的虚拟用户数，如果存在多个场景，还可以携带各个场景下分别对应的修改后的虚拟用户数，当然，也可以针对一个测试任务中的部分场景，进行虚拟用户数的修改。控制节点101在收到该消息之后，就可以根据消息中携带的测试任务的标识信息，在任务注册表中查询到分配给该测试任务的代理节点的信息，然后根据需要修改的虚拟用户数，向对应的代理节点发送相应的内部消息，以便代理节点通过改变测试线程的数量，来将虚拟用户数修改为对应的数量。如果用于修改虚拟用户数的消息中还携带有场景标识信息，则可以分别向任务注册表中各个场景标识对应的代理节点发送内部消息。

参见图3，节点确定单元1012可以包括：第一节点查询子单元10122，用于根据所述指定测试任务查询任务注册表，获知为所述指定测试任务的所述指定场景分配的代理节点。相应的，任务执行单元1031可以包括：修改执行子单元10312，用于根据接收到的第二内部消息中携带的修改后的虚拟用户数，执行测试脚本。

又如，外部业务系统还可以向集群发送停止、暂停或继续某指定测试任务的消息，消息中可以携带指定测试任务的标识信息，这样，在接收到这样的消息之后，就可以通过查询任务注册表，获知该指定的测试任务对应的代理节点，然后向这个或者这些代理节点发送消息，以便代理节点控制该指定测试任务的操作，例如停止、暂停或者继续执行等。也就是说，参见图4，节点确定单元1012也可以包括：第二节点查询子单元10123，用于根据所述指定测试任务查询任务注册表，获知为所述指定测试任务分配的代理节点。相应的，任务执行单元1031可以包括：控制子单元10313，用于根据接收到的第二内部消息，控制该对应测试任务的操作。例如，控制该对应测试任务的停止、暂停或继续等。

另外，外部业务系统还可以向集群发送获取指定测试任务的任务处理日志的消息，此时，可以根据任务注册表查找到该指定测试任务对应的数据收集节点，然后向该数据收集节点发送内部消息，通知数据收集节点向外部业务系统发送任务处理日志，等等。

需要说明的是，在本申请实施例中，控制节点101的外部消息接收单元1011可以同时接收多个外部业务系统的业务控制消息，也就是说，可以做到多个外部业务系统之间的共享。

在本申请实施例提供的测试集群进行各个外部业务系统的测试任务的过程中，对操作有时序性要求的场景不多，并且只限于对同一个测试任务的操作。也就是说，在多数情况下，测试集群可以对接收到的消息采用异步处理的方式，但是针对同一测试任务而言，测试集群可以采用集群锁等机制保证同一时刻同一个任务只允许有一个消息在处理，这样就基本消除了发生反序处理同一任务消息的可能性。

其中，可能采用异步方式处理的消息一般是指相互之间没有依赖关系的消息，如果消息之间存在依赖性，则需要采用同步的方式进行处理。例如，对于集群中的状态消息(例如，代理节点的状态汇报信息需要通知集群中的所有控制节点)和数据消息(例如，代理节点产生的数据消息需要发送到创建任务的控制节点)，这些消息的处理之间没有依赖关系，所以可以异步发送。异步消息层面的可靠性保证可以由消息系统底层的协议实现，协议保证发送者发送的消息最终会被发送到在线的目的节点。这些一些控制消息之间存在一定的依赖关系，比如在启动测试任务过程中，控制节点至少需要发送以下消息：

1、任务注册消息-集群组播

2、运行环境初始化消息-单播至代理节点

a)本地目录创建

b)下载依赖包

c)下载脚本

d)系统变量设置

3、启动测试消息-单播至代理节点

这三个操作中，后一个依赖于前一个操作的执行结果，所以这三条消息需要顺序执行，因此，就需要使用同步消息，保证每一步执行是正确返回再继续发送下一条消息。其他同步消息还有压力调整消息等，因为外部业务系统需要知道确切的操作执行是否成功。

压力测试集群中的控制节点可以进行前述消息转换、节点选择、消息发送等操作，而压力测试引擎是具体执行测试脚本和收集原始性能数据的核心模块。每个代理节点在收到启动测试场景的消息时都会创建一个测试进程来执行对应的测试脚本，并且负责收集汇总这个进程所产生的测试数据。因为测试是在独立的进程中执行，所以脚本带来的问题比如死锁、内存溢出都不会对代理节点本身造成影响。

其中，如果一个测试任务包括多个场景，则代理节点可以以场景为单位创建测试进程，然后根据各个场景中需要模拟的虚拟用户数，在对应的进程内创建相应数目的线程，在各个线程中分别执行该场景对应的测试脚本。由于线程在运行时对资源的占用情况小于进程，因此，这种方式可以减少对代理节点资源的消耗，提高测试集群的性能。也就是说，如果代理节点需要针对测试任务的多个场景进行测试，则所述脚本执行单元1031包括：

进程创建子单元，用于以测试任务的场景为单位创建测试进程；

线程创建子单元，用于在各个进程中，根据对应场景下需要模拟的虚拟用户数，创建对应数目的线程；

执行子单元，用于分别在各个线程中执行对应场景的测试脚本。

另外需要说明的是，在本申请实施例的压力测试集群中可以不必设置一个固定的主节点(Master)来掌控集群的节点信息和行为，每个节点在集群中都是对等的。集群中不需要配置中心单元，所以当节点加入集群时不需要事先知道某个中心配置单元进行信息注册，而是会向集群组播PING消息来获得当前集群节点信息和协调者(Coordinator)信息。集群协调者起着类似Master的角色，但这不是强制性要求，当集群的协调者因为某种原因失效时，集群会可以通过一定的机制让其他的节点自动承担集群协调者的角色。这样压力测试集群的节点没有任何维护成本，启动即可用，如果宕机，集群会自动感知将其剔除，这些功能都可以通过JGroups的可配置协议栈来实现。

与本申请实施例提供的压力测试系统相对应，本申请实施例还提供了一种压力测试方法，该方法介绍的是用于进行消息转换的控制节点在压力测试过程中的处理流程，也即，各个步骤的执行主体为用于进行消息转换的控制节点。参见图5，该方法可以包括以下步骤：

S501：接收外部业务系统的业务控制消息；

S502：确定用于进行数据收集的目标控制节点和/或用于进行任务执行的目标代理节点；

S503：根据所述业务控制消息以及目标控制节点和/或目标代理节点的信息，生成第一内部消息和/或第二内部消息；

S504：将所述第一内部消息发送到所述目标控制节点，和/或，将所述第二内部消息发送到所述目标代理节点；以便所述目标代理节点根据接收到的第二内部消息对测试任务执行相应的操作，对任务执行过程中产生的性能数据进行记录，并将记录的性能数据发送到所述用于进行数据收集的目标控制单元；所述用于进行数据收集的目标控制单元监听所述目标代理节点发送的性能数据，根据收集到的性能数据向外部业务系统进行数据回传。

其中，如果业务控制消息是用于启动某测试任务的启动消息，则启动消息中携带有测试任务的信息、测试脚本、需要模拟的虚拟用户数，此时，具体在确定用于进行数据收集的目标控制节点以及用于进行任务执行的目标代理节点时，可以从各个控制节点中选择出用于针对此次测试任务进行数据收集的目标控制节点，从各个代理节点中选择出用于执行此次测试任务的目标代理节点。相应的，代理节点可以根据接收到的第二内部消息执行测试任务的测试脚本。

针对启动消息，具体在从各个控制节点中选择出用于针对此次测试任务进行数据收集的目标控制节点，从各个代理节点中选择出用于执行此次测试任务的目标代理节点时，可以接收集群中的各个节点通过消息组播的方式按照指定频率向集群中的其他节点发送的消息，然后根据当前接收到的各个节点的资源利用率，选择出资源利用率符合预置条件的节点作为所述目标控制节点以及目标代理节点，其中，所述消息中携带有各个节点自身的资源利用率信息。

为了便于后续测试过程中，执行参数的修改等操作，用于进行消息转换的控制节点还可以保存测试任务的标识信息与分配给该测试任务的节点信息之间的对应关系，生成任务注册表；所述分配给该测试任务的节点包括用于对该测试任务进行数据收集的控制节点及用于执行该测试任务的测试脚本的代理节点。

如果业务控制消息是用于修改指定测试任务的虚拟用户数的修改消息，所述修改消息中携带有所述指定测试任务的标识信息以及修改后的虚拟用户数，则具体在确定目标节点时，只需要确定用于进行任务执行的目标代理节点，具体的，可以根据指定测试任务的标识信息查询任务注册表，获知为指定测试任务分配的代理节点，相应的，代理节点可以根据接收到的第二内部消息中携带的修改后的虚拟用户数，执行测试脚本。

如果业务控制信息是用于对指定测试任务进行停止、暂停、继续的消息，所述消息中携带有所述指定测试任务的标识信息，则在确定目标节点时，也只需要确定用于进行任务执行的目标代理节点，具体的，可以根据指定测试任务的标识信息查询任务注册表，获知为指定测试任务分配的代理节点，相应的，代理节点可以根据接收到的第二内部消息，停止、暂停或继续对应测试脚本的执行。

另外，为了每个节点能够掌握集群中的节点加入或退出的情况，还可以维护一节点注册表，并当接收到节点加入或退出集群的组播消息时，对节点注册表进行更新。在实际应用中，可以同时接收多个外部业务系统的业务控制消息，然后分别针对各个业务控制消息，进行消息的转换以及节点的选择。

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

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的压力测试系统及方法，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (18)

1.一种压力测试系统，其特征在于，所述系统包括由至少一个控制节点以及至少一个代理节点组成的集群，其中：

所述控制节点包括用于进行消息转换的控制节点以及用于进行数据收集的控制节点；

所述用于进行消息转换的控制节点包括：

外部消息接收单元，用于接收外部业务系统的业务控制消息；

节点确定单元，用于确定用于进行数据收集的目标控制节点和/或用于进行任务执行的目标代理节点；

内部消息生成单元，用于根据所述业务控制消息以及目标控制节点和/或目标代理节点的信息，生成第一内部消息和/或第二内部消息；

消息发送单元，用于将所述第一内部消息发送到所述目标控制节点，和/或，将所述第二内部消息发送到所述目标代理节点；

所述代理节点包括：

任务执行单元，用于根据接收到的第二内部消息对测试任务执行相应的操作；

数据收集单元，用于对任务执行过程中产生的性能数据进行记录；

数据发送单元，用于将记录的性能数据发送到所述用于进行数据收集的目标控制节点；

所述用于进行数据收集的控制节点包括：

监听单元，用于监听所述代理节点发送的性能数据；

回传单元，用于根据收集到的性能数据向外部业务系统进行数据回传。

2.根据权利要求1所述的系统，其特征在于，所述业务控制消息包括启动测试任务的启动消息，所述启动消息中携带有测试任务的信息、测试脚本、需要模拟的虚拟用户数；

所述节点确定单元包括：

节点选择子单元，用于从各个控制节点中选择出用于针对此次测试任务进行数据收集的目标控制节点，从各个代理节点中选择出用于执行此次测试任务的目标代理节点；

所述任务执行单元包括：

脚本执行子单元，用于根据接收到的第二内部消息执行测试任务的测试脚本。

3.根据权利要求2所述的系统，其特征在于，如果所述代理节点需要针对测试任务的多个场景进行测试，则所述脚本执行子单元包括：

进程创建子单元，用于以测试任务的场景为单位创建测试进程；

线程创建子单元，用于在各个进程中，根据对应场景下需要模拟的虚拟用户数，创建对应数目的线程；

执行子单元，用于分别在各个线程中执行对应场景的测试脚本。

4.根据权利要求2所述的系统，其特征在于，所述节点选择子单元包括：

资源利用率信息接收子单元，用于接收集群中的各个节点通过消息组播的方式按照指定频率向集群中的其他节点发送的消息，所述消息中携带有各个节点自身的资源利用率信息；

选择子单元，用于根据当前接收到的各个节点的资源利用率，选择出资源利用率符合预置条件的节点作为所述目标控制节点以及目标代理节点。

5.根据权利要求2所述的系统，其特征在于，对于同一压力测试任务，用于进行数据收集的控制节点为一个，用于执行测试脚本的代理节点为一个或多个；如果执行测试脚本的代理节点为多个，则所述用于进行数据收集的目标控制节点还包括：

数据汇总单元，用于将各个代理节点发送的关于同一测试任务的性能数据进行汇总。

6.根据权利要求2所述的系统，其特征在于，所述用于进行消息转换的控制节点还包括：

任务注册单元，用于保存测试任务的标识信息与分配给该测试任务的节点信息之间的对应关系，生成任务注册表；所述分配给该测试任务的节点包括用于对该测试任务进行数据收集的控制节点及用于执行该测试任务的测试脚本的代理节点。

7.根据权利要求1所述的系统，其特征在于，所述业务控制消息还包括用于修改指定测试任务的虚拟用户数的修改消息，所述修改消息中携带有所述指定测试任务的标识信息以及修改后的虚拟用户数；

所述节点确定单元包括：

第一节点查询子单元，用于根据所述指定测试任务查询任务注册表，获知为所述指定测试任务分配的代理节点；所述任务注册表中保存有测试任务的标识信息与分配给该测试任务的节点信息之间的对应关系，所述分配给该测试任务的节点包括用于对该测试任务进行数据收集的控制节点及用于执行该测试任务的测试脚本的代理节点；

所述任务执行单元包括：

修改执行子单元，用于根据接收到的第二内部消息中携带的修改后的虚拟用户数，执行测试脚本。

8.根据权利要求1所述的系统，其特征在于，所述业务控制消息包括用于对指定测试任务进行停止、暂停、继续的消息，所述消息中携带有所述指定测试任务的标识信息；

所述节点确定单元包括：

第二节点查询子单元，用于根据所述指定测试任务查询任务注册表，获知为所述指定测试任务分配的代理节点；所述任务注册表中保存有测试任务的标识信息与分配给该测试任务的节点信息之间的对应关系，所述分配给该测试任务的节点包括用于对该测试任务进行数据收集的控制节点及用于执行该测试任务的测试脚本的代理节点；

所述任务执行单元包括：

控制子单元，用于根据接收到的第二内部消息，停止、暂停或继续对应测试脚本的执行。

9.根据权利要求1至8任一项所述的系统，其特征在于，所述集群中的各个节点还包括：

节点注册表维护单元，用于维护一节点注册表，并当接收到节点加入或退出集群的组播消息时，对节点注册表进行更新。

10.根据权利要求1至8任一项所述的系统，其特征在于，所述外部消息接收单元，用于接收多个外部业务系统的业务控制消息。

11.一种压力测试方法，其特征在于，包括：

接收外部业务系统的业务控制消息；

确定用于进行数据收集的目标控制节点和/或用于进行任务执行的目标代理节点；

根据所述业务控制消息以及目标控制节点和/或目标代理节点的信息，生成第一内部消息和/或第二内部消息；

将所述第一内部消息发送到所述目标控制节点，和/或，将所述第二内部消息发送到所述目标代理节点；以便所述目标代理节点根据接收到的第二内部消息对测试任务执行相应的操作，对任务执行过程中产生的性能数据进行记录，并将记录的性能数据发送到所述用于进行数据收集的目标控制节点；所述用于进行数据收集的目标控制节点监听所述目标代理节点发送的性能数据，根据收集到的性能数据向外部业务系统进行数据回传。

12.根据权利要求11所述的方法，其特征在于，所述业务控制消息包括启动测试任务的启动消息，所述启动消息中携带有测试任务的信息、测试脚本、需要模拟的虚拟用户数；

所述确定用于进行数据收集的目标控制节点和/或用于进行任务执行的目标代理节点包括：

从各个控制节点中选择出用于针对此次测试任务进行数据收集的目标控制节点，从各个代理节点中选择出用于执行此次测试任务的目标代理节点，以便所述目标代理节点根据接收到的第二内部消息执行测试任务的测试脚本。

13.根据权利要求12所述的方法，其特征在于，所述从各个控制节点中选择出用于针对此次测试任务进行数据收集的目标控制节点，从各个代理节点中选择出用于执行此次测试任务的目标代理节点，包括：

接收集群中的各个节点通过消息组播的方式按照指定频率向集群中的其他节点发送的消息，所述消息中携带有各个节点自身的资源利用率信息；

根据当前接收到的各个节点的资源利用率，选择出资源利用率符合预置条件的节点作为所述目标控制节点以及目标代理节点。

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

保存测试任务的标识信息与分配给该测试任务的节点信息之间的对应关系，生成任务注册表；所述分配给该测试任务的节点包括用于对该测试任务进行数据收集的控制节点及用于执行该测试任务的测试脚本的代理节点。

15.根据权利要求11所述的方法，其特征在于，所述业务控制消息还包括用于修改指定测试任务的虚拟用户数的修改消息，所述修改消息中携带有所述指定测试任务的标识信息以及修改后的虚拟用户数；

所述确定用于进行数据收集的目标控制节点和/或用于进行任务执行的目标代理节点包括：

根据所述指定测试任务查询任务注册表，获知为所述指定测试任务分配的代理节点；所述任务注册表中保存有测试任务的标识信息与分配给该测试任务的节点信息之间的对应关系，所述分配给该测试任务的节点包括用于对该测试任务进行数据收集的控制节点及用于执行该测试任务的测试脚本的代理节点；以便所述目标代理节点根据接收到的第二内部消息中携带的修改后的虚拟用户数，执行测试脚本。

16.根据权利要求11所述的方法，其特征在于，所述业务控制消息包括用于对指定测试任务进行停止、暂停、继续的消息，所述消息中携带有所述指定测试任务的标识信息；

所述确定用于进行数据收集的目标控制节点和/或用于进行任务执行的目标代理节点包括：

根据所述指定测试任务查询任务注册表，获知为所述指定测试任务分配的代理节点；所述任务注册表中保存有测试任务的标识信息与分配给该测试任务的节点信息之间的对应关系，所述分配给该测试任务的节点包括用于对该测试任务进行数据收集的控制节点及用于执行该测试任务的测试脚本的代理节点；以便所述代理节点根据接收到的第二内部消息，停止、暂停或继续对应测试脚本的执行。

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

维护一节点注册表，并当接收到节点加入或退出集群的组播消息时，对节点注册表进行更新。

18.根据权利要求11至16任一项所述的方法，其特征在于，所述接收外部业务系统的业务控制消息包括：

接收多个外部业务系统的业务控制消息。