[发明专利]软件性能测试方法、系统和可读存储介质

说明书

本发明实施例提出软件性能测试方法、系统和可读存储介质。方法包括：第二设备接收第一设备发来的一个或多个携带软件性能测试脚本的软件性能测试任务创建请求；第二设备针对每个软件性能测试脚本分别创建一个软件性能测试任务，针对每个软件性能测试任务，分别启动一个JMeter容器，将每个软件性能测试任务对应的软件性能测试脚本分别发送给一个JMeter容器；JMeter容器接收并执行软件性能测试脚本，并根据脚本中的Kafka后端监听器模块将任务执行过程中产生的结果数据实时发送给Kafka集群的预定义的消息主题队列中，其中，结果数据中包含对应的软件性能测试任务ID。本发明实施例提高了软件性能测试效率。

技术领域

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

背景技术

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后端监听器模块；