软件性能测试方法、系统和可读存储介质

技术领域

本发明涉及软件测试技术领域，尤其涉及软件性能测试方法、系统和可读存储介质。

背景技术

Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试。它可以用于测试静态和动态资源，例如静态文件、Java小服务程序、CGI(CommonGateway Interface)脚本、Java对象、数据库、FTP(File Transfer Protocol，文件传输协议)服务器，等等。JMeter可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度或分析整体性能。另外，JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证程序返回了期望的结果。为了最大限度的灵活性，JMeter允许使用正则表达式创建断言。

目前通过JMeter来进行分布式性能测试，主要使用到了JMeter的Master(主)-Slave(从)机制。图1为现有的通过JMeter进行分布式性能测试的系统架构示意图，如图1所示，在该方案中需要启动一个MasterJMeter服务及若干个Slave JMeter，通过Master节点下发测试任务及控制命令，Slave节点执行实际的测试脚本，并将结果返回到Master节点进行统一处理。该方案有如下不足：

一、单点压力大

由于所有Slave节点的执行结果都会发回到Master节点进行处理，且Master节点无法进行横向扩展，导致在并发量较大的情况下Master节点的配置会成为整个测试模型的瓶颈，影响测试效果。

二、节点复用性差

由于JMeter自身机制的限制，在同一台Slave节点上同时只能接受一台Master节点的测试任务，当单个测试任务负载并不高时，Slave节点上没法同时执行多个测试任务，导致该节点无法被多个测试复用，资源利用率较低。

三、环境管理复杂

Master及Slave节点需要手动依次进行配置及单独管理，例如：需要在Master节点上配置所有Slave节点的信息，各Slave节点上配置Master节点的信息，配置工作比较繁琐，效率较低。

四、网络要求高

JMeter的Master-Slave机制使用了RMI(Remote Method Invoke，远程方法调用)协议来进行节点间的相互通信，该机制要求Master及Slave节点必须要处于同一个二层网络中，对网络环境的要求较高，无法实现跨网络的分布式测试。

发明内容

本发明实施例提出软件性能方法、系统和可读存储介质，以提高软件性能测试效率。

本发明实施例的技术方案是这样实现的：

一种软件性能测试方法，该方法包括：

第二设备接收第一设备发来的一个或多个携带软件性能测试脚本的软件性能测试任务创建请求，其中，每个软件性能测试脚本中包含Kafka后端监听器模块；

第二设备针对每个软件性能测试脚本分别创建一个软件性能测试任务，针对每个软件性能测试任务，分别启动一个JMeter容器，将每个软件性能测试任务对应的软件性能测试脚本分别发送给一个JMeter容器；且，JMeter容器接收并执行软件性能测试脚本，并根据脚本中的Kafka后端监听器模块将任务执行过程中产生的结果数据实时发送给Kafka集群的预定义的消息主题队列中，其中，结果数据中包含对应的软件性能测试任务ID。

所述将任务执行过程中产生的结果数据实时发送给Kafka集群的预定义的消息主题队列中之后，进一步包括：

第三设备根据预定义的消息主题，从Kafka集群的该消息主题的队列中消费结果数据，将结果数据存入预设数据库中；第一设备从数据库读取结果数据，并将结果数据显示在Web页面上。

所述第二设备接收第一设备发来的一个或多个携带软件性能测试脚本的软件性能测试任务创建请求之前，进一步包括：

第一设备接收用户输入的一个或多个软件性能测试脚本，针对每个软件性能测试脚本，根据实时维护的各个第二设备的实时负载，在其中选择负载最小的第二设备，将当前软件性能测试脚本携带在软件性能测试任务创建请求中发送给所选择的第二设备。

所述第一设备接收用户输入的一个或多个软件性能测试脚本包括：

第一设备接收用户输入的一个或多个软件性能测试脚本以及可选第二设备列表；

所述在其中选择负载最小的第二设备包括：

在用户输入的可选第二设备列表中选择负载最小的第二设备。

所述第一设备接收用户输入的一个或多个软件性能测试脚本之前，进一步包括：

第一设备保存各第二设备的IP地址；

所述将当前软件性能测试脚本携带在软件性能测试任务创建请求中发送给所选择的第二设备包括：

根据所选择的第二设备的IP地址，将当前软件性能测试脚本携带在软件性能测试任务创建请求中发送给所选择的第二设备。

所述第二设备与第一设备之间通过HTTP进行通信。

所述第二设备接收第一设备发来的一个或多个携带软件性能测试脚本的软件性能测试任务创建请求包括：

第二设备接收一个或多个第一设备发来的一个或多个携带软件性能测试脚本的软件性能测试任务创建请求，其中，每个第一设备发来一个或多个携带软件性能测试脚本的软件性能测试任务创建请求。

一种软件性能测试系统，包括：

第一设备，接收用户输入的一个或多个携带软件性能测试脚本，针对每个软件性能测试脚本，选择一个第二设备，将该软件性能测试脚本携带在软件性能测试任务创建请求中发送给所选择的第二设备；

第二设备，接收第一设备发来的一个或多个携带软件性能测试脚本的软件性能测试任务创建请求，其中，每个软件性能测试脚本中包含Kafka后端监听器模块；针对每个软件性能测试脚本分别创建一个软件性能测试任务，针对每个软件性能测试任务，分别启动一个JMeter容器，将每个软件性能测试任务对应的软件性能测试脚本分别发送给一个JMeter容器；且，JMeter容器接收并执行软件性能测试脚本，并根据脚本中的Kafka后端监听器模块将任务执行过程中产生的结果数据实时发送给Kafka集群的预定义的消息主题队列中，其中，结果数据中包含对应的软件性能测试任务ID；

Kafka集群设备，维护Kafka集群。

所述系统进一步包括：

第三设备，根据预定义的消息主题，从Kafka集群的该消息主题的队列中消费结果数据，将结果数据存入预设数据库中；

且，所述第一设备从预设数据库读取软件性能测试脚本执行过程中产生的结果数据，并将结果数据显示在Web页面上。

一种非瞬时计算机可读存储介质，所述非瞬时计算机可读存储介质存储指令，所述指令在由处理器执行时使得所述处理器执行如上任一项所述的方法的步骤。

本发明实施例中，第二设备接收到多个软件性能测试脚本后，可以针对每个软件性能测试脚本分别创建一个软件性能测试任务，并针对每个软件性能测试任务分别启动一个JMeter容器，从而使得第二设备能够同时执行多个软件性能测试脚本，提高了软件性能测试效率；同时，软件测试脚本执行过程中的结果数据并不需要发送给第一设备，而是存储到Kafka队列中，将控制平面和数据平面分离，从而降低了第一设备的处理负担，进一步提高了软件性能测试的效率。

附图说明

图1为现有的通过JMeter进行分布式性能测试的系统架构示意图；

图2为本发明一实施例提供的软件性能测试方法流程图；

图3为本发明另一实施例提供的软件性能测试方法流程图；

图4为本发明实施例提供的软件性能测试系统的结构示意图；

图5为本发明实施例提供的电子设备的结构示意图。

具体实施方式

下面结合附图及具体实施例对本发明再作进一步详细的说明。

图2为本发明一实施例提供的软件性能测试方法流程图，其具体步骤如下：

步骤201：第二设备接收第一设备发来的一个或多个携带软件性能测试脚本的软件性能测试任务创建请求，其中，每个软件性能测试脚本中包含Kafka后端监听器模块。

步骤202：第二设备针对每个软件性能测试脚本分别创建一个软件性能测试任务，针对每个软件性能测试任务，分别启动一个JMeter容器，将每个软件性能测试任务对应的软件性能测试脚本分别发送给一个JMeter容器。

步骤203：JMeter容器接收并执行软件性能测试脚本，并根据脚本中的Kafka后端监听器模块将任务执行过程中产生的结果数据实时发送给Kafka集群的预定义的消息主题队列中，其中，结果数据中包含对应的软件性能测试任务ID。

上述实施例中，第二设备接收到多个软件性能测试脚本后，可以针对每个软件性能测试脚本分别创建一个软件性能测试任务，并针对每个软件性能测试任务分别启动一个JMeter容器，从而使得第二设备能够同时执行多个软件性能测试脚本，提高了软件性能测试效率；同时，软件测试脚本执行过程中的结果数据并不需要发送给第一设备，而是存储到Kafka队列中，将控制平面和数据平面分离，从而降低了第一设备的处理负担，进一步提高了软件性能测试的效率。

一可选实施例中，步骤203中，JMeter容器将任务执行过程中产生的结果数据实时发送给Kafka集群的预定义的消息主题队列中之后，进一步包括：

第三设备根据预定义的消息主题，从Kafka集群的该消息主题的队列中消费结果数据，将结果数据存入预设数据库中；第一设备从数据库读取结果数据，并将结果数据显示在Web页面上。

上述实施例中，通过将结果数据从Kafka队列读取到预设数据库，实现了对结果数据的持久化保存，且第一设备可从数据库中读取结果数据并显示在Web页面上，实现了结果数据对用户的展示。

一可选实施例中，步骤201中，第二设备接收第一设备发来的一个或多个携带软件性能测试脚本的软件性能测试任务创建请求之前，进一步包括：

第一设备接收用户输入的一个或多个软件性能测试脚本，针对每个软件性能测试脚本，根据实时维护的各个第二设备的实时负载，在其中选择负载最小的第二设备，将当前软件性能测试脚本携带在软件性能测试任务创建请求中发送给所选择的第二设备。

上述实施例中，可根据各第二设备的负载，分配软件性能测试脚本，从而避免了软件性能测试脚本被延迟执行，提高了软件性能测试效率。

一可选实施例中，第一设备接收用户输入的一个或多个软件性能测试脚本包括：第一设备接收用户输入的一个或多个软件性能测试脚本以及可选第二设备列表；

且，在其中选择负载最小的第二设备包括：在用户输入的可选第二设备列表中选择负载最小的第二设备。

考虑到：同一时刻会有多个用户同时进行软件性能测试，为了使得所有第二设备能够被均匀使用，因此，可将所有第二设备预先分配给各个用户，即为每个用户分配一部分第二设备，这样，每个用户拥有一个可选第二设备列表，从而提高了所有第二设备的负载均衡性，提高了软件性能测试效率。

一可选实施例中，第一设备接收用户输入的一个或多个软件性能测试脚本之前，进一步包括：第一设备保存各第二设备的IP地址；

将当前软件性能测试脚本携带在软件性能测试任务创建请求中发送给所选择的第二设备包括：根据所选择的第二设备的IP地址，将当前软件性能测试脚本携带在软件性能测试任务创建请求中发送给所选择的第二设备。

通过上述实施例可以看出，本发明实施例中，只需要在第一设备上配置第二设备的IP地址即可，配置简单。

一可选实施例中，第二设备与第一设备之间通过HTTP(HyperText TransferProtocol，超文本传输协议)进行通信。

由于第二设备和第一设备之间通过HTTP进行通信，因此第二设备和第一设备无需必须处于同一二层网络中，可以实现跨网络的分布式测试。

一可选实施例中，步骤201中，第二设备接收第一设备发来的一个或多个携带软件性能测试脚本的软件性能测试任务创建请求包括：

第二设备接收一个或多个第一设备发来的一个或多个携带软件性能测试脚本的软件性能测试任务创建请求，其中，每个第一设备发来一个或多个携带软件性能测试脚本的软件性能测试任务创建请求。

通过上述实施例可以看出：第二设备可以同时接受并执行多个第一设备发来的软件性能测试脚本，提高了对第二设备的资源利用率，同时第一设备可以横向扩展，避免了第一设备达到处理瓶颈，进一步提高了软件性能测试效率。

图3为本发明另一实施例提供的软件性能测试方法流程图，其具体步骤如下：

步骤301：预先设置一个或多个第一设备作为控制设备，预设多个配置有Node-Controller组件的第二设备作为执行设备，设置一个或多个配置有Data-Streaming组件的第三设备作为结果处理设备，在各第一设备上分别配置所有第二设备的IP地址。

步骤302：任一第一设备接收一用户输入的一个或多个JMX格式的软件性能测试脚本和可选第二设备列表。

在实际应用中，用户为了方便起见，在当前软件性能测试脚本的内容与之前已经编译完成的软件性能测试脚本的内容基本相同，只存在部分压力参数的差异时，用户可直接将之前的软件性能测试脚本和一个压力参数更新表发送给第一设备，其中，压力参数更新表中包括发生变化的压力参数的名称和新的取值。

步骤303：第一设备接收该一个或多个软件性能测试脚本，将预先定义的KafkaBackendListener(Kafka后端监听器)模块添加到各脚本的预设位置处。

KafkaBackendListener模块的作用是，将脚本执行过程中产生的结果数据实时写入Kafka集群的预设消息主题中。

若某个软件性能测试脚本有对应的压力参数更新表，则第一设备还需根据该压力参数更新表对脚本中的对应压力参数的取值进行更改。

步骤304：第一设备针对每个脚本分别创建一个软件性能测试任务，针对每个任务，在可选第二设备列表中选择一个第二设备，将该任务发送给所选择的第二设备。

在实际应用中，在存在前端处理步骤时，通常会专门设置前端设备来处理前端步骤，即第一设备可以拆分成两个设备：前端设备和后端设备，前端设备执行步骤302，然后将接收到的各个软件性能测试脚本发送给后端设备，后端设备执行步骤303和304。

前端设备和后端设备之间通过HTTP进行通信。

步骤305：第二设备通过Node-Controller组件的接口接收到该任务，Node-Controller组件通过Docker接口启动一个JMeter容器，将该任务对应的软件性能测试脚本发送给该JMeter容器。

步骤306：JMeter容器执行该脚本，并根据脚本中的KafkaBackendListener模块将执行过程中的结果数据实时发送到Kafka集群的预设消息主题中，其中，结果数据中包含对应的软件性能测试任务ID。

JMeter容器执行完软件性能测试脚本后自动销毁。

步骤307：第三设备的Data-Streaming组件根据预先订阅的消费消息主题，从Kafka集群的预设消息主题的队列中消费结果数据，将消费的结果数据存入预设数据库中。

步骤308：第一设备从数据库中读取结果数据，将结果数据展示在Web页面上。

若第一设备拆分成前端设备和后端设备，则后端设备从数据库中读取结果数据，将结果数据发送给前端设备，前端设备将结果数据展示在Web页面上。

其中，第一设备和第二设备之间通过HTTP进行通信。

图4为本发明实施例提供的软件性能测试系统的架构图，如图4所示，该系统中包括：至少一个第一设备、多个第二设备、Kafka集群设备和至少一个第三设备，其中：

第一设备，接收用户输入的一个或多个携带软件性能测试脚本，针对每个软件性能测试脚本，选择一个第二设备，将该软件性能测试脚本携带在软件性能测试任务创建请求中发送给所选择的第二设备；从数据库读取软件性能测试脚本执行过程中产生的结果数据，并将结果数据显示在Web页面上。

第二设备，接收第一设备发来的一个或多个携带软件性能测试脚本的软件性能测试任务创建请求，其中，每个软件性能测试脚本中包含Kafka后端监听器模块；针对每个软件性能测试脚本分别创建一个软件性能测试任务，针对每个软件性能测试任务，分别启动一个JMeter容器，将每个软件性能测试任务对应的软件性能测试脚本分别发送给一个JMeter容器；且，JMeter容器接收并执行软件性能测试脚本，并根据脚本中的Kafka后端监听器模块将任务执行过程中产生的结果数据实时发送给Kafka集群的预定义的消息主题队列中，其中，结果数据中包含对应的软件性能测试任务ID。

Kafka集群设备，维护Kafka集群。

第三设备，根据预定义的消息主题，从Kafka集群的该消息主题的队列中消费结果数据，将结果数据存入预设数据库中。

本发明实施例还提供一种非瞬时计算机可读存储介质，该非瞬时计算机可读存储介质存储指令，该指令在由处理器执行时使得所述处理器执行步骤201-203。

图5为本发明实施例提供的电子设备的结构示意图，该电子设备包括如上所述的非瞬时计算机可读存储介质51、以及可访问非瞬时计算机可读存储介质51的处理器52。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。