CN116795673A - 一种系统测试方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请提供一种系统测试方法，包括：创建并编辑被测服务的测试用例；基于测试用例中消息队列的配置信息修改被测服务的配置文件；如果被测服务是生产者服务，基于测试用例中配置的业务触发方式触发生产者服务向消息队列中发送消息体；通过模拟的消费者服务从消息队列中获取消息体，以对消息体进行校验；如果被测服务是消费者服务，通过模拟的生产者服务向消息队列发送消息体，通过消费者服务从消息队列中获取消息体，以基于测试用例中配置的校验方式对消息体的处理结果进行校验。本申请还同时提供了一种系统测试装置、电子设备及存储介质。可以保证在消息队列的场景下被测服务的业务被正常触发和正常校验，以降低业务触发的失败率和校验失败率。

Description

一种系统测试方法、装置、电子设备及存储介质

技术领域

本发明涉及软件或互联网的测试技术，具体涉及一种系统测试方法、装置、电子设备及存储介质。

背景技术

随着IT行业的发展，传统的网络应用系统在面对高并发时逐渐力不从心，后端技术逐步演进后，企业级的消息队列(消息中间件)被应用得愈发广泛。在针对后端系统的软件测试过程中，基于消息队列的技术实现和特性(异步，并且不再区分调用方和被调用方，而是出现了新的角色即生产者和消费者)，已有的测试方法已不再适用(例如接口测试，包括功能和性能测试)，需要寻求一种新的测试方法来测试使用消息队列来通信的后端系统。

发明内容

为解决现有存在的技术问题，本申请的技术方案是这样实现的：

根据本申请的一方面，提供一种系统测试方法，所述方法包括：

创建并编辑被测服务的测试用例；

基于所述测试用例中消息队列的配置信息修改所述被测服务的配置文件；

如果所述被测服务是生产者服务，基于所述测试用例中配置的业务触发方式触发所述生产者服务向消息队列中发送消息体；通过模拟的消费者服务从所述消息队列中获取所述消息体，以对所述消息体进行校验；

如果所述被测服务是消费者服务，通过模拟的生产者服务向所述消息队列发送消息体，通过所述消费者服务从所述消息队列中获取所述消息体，以基于所述测试用例中配置的校验方式对所述消息体的处理结果进行校验。

上述方案中，所述基于所述测试用例中配置的业务触发方式触发所述生产者服务向消息队列中发送消息体，至少包括以下方法之一：

获取所述测试用例中携带的对象标识；

如果所述对象标识表征所述业务触发方式为网络接口，触发所述生产者服务将所述测试用例中的测试数据封装成超文本传输协议HTTP请求的消息体向消息队列发送；

如果所述对象标识表征所述业务触发方式为定时任务，触发所述生产者服务根据定时任务的函数将所述测试用例中的测试数据封装成HTTP请求的消息体向消息队列发送；

如果所述对象标识表征所述业务触发方式为消息队列，触发所述生产者服务将所述测试用例中的测试数据封装成队列消息向消息队列发送。

上述方案中，所述通过模拟的消费者服务从所述消息队列中获取所述消息体，以对所述消息体进行校验，包括：

通过模拟的消费者服务基于所述测试用例中消息队列的配置信息对所述消息队列中的消息体进行过滤，得到目标消息体；

解析所述目标消息体，得到所述目标消息体对应的各属性信息；

基于所述测试用例中配置的校验方式和校验内容对所述各属性信息进行校验。

上述方案中，所述通过消费者服务从所述消息队列中获取所述消息体，以基于所述测试用例中配置的校验方式对所述消息体的处理结果进行校验，至少包括以下方法之一：

通过所述消费者服务基于所述测试用例中消息队列的配置信息对所述消息队列中的消息体进行过滤，得到目标消息体；

如果所述测试用例中配置的校验方式是回调接口的报文，在通过所述模拟的生产者服务监听到所述消费者服务针对所述目标消息体发起的回调请求报文的情况下，基于所述测试用例中配置的校验内容对所述回调请求报文进行校验；

如果所述测试用例中配置的校验方式是websocket报文，在通过所述模拟的生产者服务接收到所述消费者服务针对所述目标消息体发起的websocket报文的情况下，基于所述测试用例中配置的校验内容对所述websocket报文进行校验；

如果所述测试用例中配置的校验方式是数据库中的数据，基于所述测试用例中配置的校验内容以轮询方式在所述消费者服务对应的数据库中查询目标内容；如果查询结果表征在所述数据库中查询到所述目标内容，确定所述目标消息体的处理结果通过校验；

如果所述测试用例中配置的校验方式是日志系统中的日志，基于所述测试用例中配置的校验内容以轮询方式在所述日志系统中查询目标日志；根据查询结果表征在所述日志系统中查询到所述目标日志，确定所述目标消息体的处理结果通过校验。

上述方案中，所述基于所述测试用例中配置的校验内容对所述回调请求报文进行校验，包括：

基于所述测试用例中配置的校验内容在所述回调请求报文中提取目标内容；如果提取到所述目标内容或者所述目标内容满足预设条件，确定所述目标消息体的处理结果通过校验；

所述基于所述测试用例中配置的校验内容对所述websocket报文进行校验，包括：

基于所述测试用例中配置的校验内容在所述websocket报文中提取目标内容；如果提取到所述目标内容或者所述目标内容满足预设条件，确定所述目标消息体的处理结果通过校验。

上述方案中，所述创建并编辑被测服务的测试用例，包括：

确定被测服务的配置信息，所述配置信息包括但不限于所述被测服务的业务触发方式、校验方式、校验内容、消息队列的地址、标题、标签；

基于所被测服务的配置信息创建所述被测服务的测试用例。

上述方案中，所述基于所述测试用例中消息队列的配置信息修改所述被测服务的配置文件，包括：

获取所述被测服务的配置文件；

基于所述测试用例中消息队列的地址、标题、标签修改所述配置文件，以形成所述测试用例的测试配置文件。

根据本申请的另一方面，提供一种电子设备，其特征在于，所述电子设备包括：

测试用例单元，用于创建并编辑被测服务的测试用例；

配置注入单元，用于基于所述测试用例中消息队列的配置信息修改所述被测服务的配置文件；

业务触发单元，用于在所述被测服务是生产者服务的情况下，基于所述测试用例中配置的业务触发方式触发所述生产者服务向消息队列中发送消息体；

模拟单元，用于在所述被测服务是生产者服务的情况下，通过模拟的消费者服务从所述消息队列中获取所述消息体；以及用于如果所述被测服务是消费者服务，通过模拟的生产者服务向所述消息队列发送消息体；

校验单元，用于对所述消息体进行校验；以及用于基于所述测试用例中配置的校验方式对所述消息体的处理结果进行校验。

上述方案中，所述业务触发单元至少包括以下组件之一：

第一触发器组件，用于如果所述测试用例中携带的对象标识表征所述业务触发方式为网络接口，触发所述生产者服务将所述测试用例中的测试数据封装成超文本传输协议HTTP请求的消息体向消息队列发送；以及用于如果所述对象标识表征所述业务触发方式为定时任务，触发所述生产者服务根据定时任务的函数将所述测试用例中的测试数据封装成HTTP请求的消息体向消息队列发送；

第二触发器组件，用于如果所述测试用例中携带的对象标识表征所述业务触发方式为消息队列，触发所述生产者服务将所述测试用例中的测试数据封装成队列消息向消息队列发送。

上述方案中，所述校验单元包括：

校验组件，用于在所述被测服务是生产者服务的情况下，基于所述测试用例中配置的校验方式和校验内容对所述消息体中的各属性信息进行校验。

上述方案中，所述校验单元至少还包括以下组件之一：

第一模拟组件，用于在所述被测服务是消费者服务的情况下，如果所述测试用例中配置的校验方式是回调接口的报文，绑定网络端口以监听所述消费者服务针对所述目标消息体发起的回调请求报文；以及向所述校验组件发送所述回调请求报文；

第二模拟组件，用于在所述被测服务是消费者服务的情况下，如果所述测试用例中配置的校验方式是websocket报文，接收所述消费者服务针对所述目标消息体发起的websocket报文，以及向所述校验组件发送所述websocket报文；

第一查询组件，用于在所述被测服务是消费者服务的情况下，如果所述测试用例中配置的校验方式是数据库中的数据，基于所述测试用例中配置的校验内容以轮询方式在所述消费者服务对应的数据库中查询目标内容；如果查询结果表征在所述数据库中查询到所述目标内容，确定所述目标消息体的处理结果通过校验；

第二查询组件，用于在所述被测服务是消费者服务的情况下，如果所述测试用例中配置的校验方式是日志系统中的日志，基于所述测试用例中配置的校验内容以轮询方式在所述日志系统中查询目标日志；根据查询结果表征在所述日志系统中查询到所述目标日志，确定所述目标消息体的处理结果通过校验；

所述校验组件，还用于基于所述测试用例中配置的校验内容对所述回调请求报文进行校验；以及用于基于所述测试用例中配置的校验内容对所述websocket报文进行校验。

根据本申请的第三方面，提供一种电子设备，其特征在于，所述电子设备包括：处理器和用于存储能够在处理器上运行的计算机程序的存储器，

其中，所述处理器用于运行所述计算机程序时，执行上述所述的任一种系统测试方法中的任一项方法步骤。

根据本申请的第四方面，提供一种计算机可读存储介质，其特征在于，用于存储计算机指令，所述计算机指令被处理器执行时，执行上述所述的任一种系统测试方法中的任一项方法步骤。

本发明实施例提供的系统测试方法、装置、电子设备及存储介质，通过在消息队列这一测试场景下，针对被测服务是生产者角色的服务采用测试用例中配置的业务触发方式对被测服务进行业务触发，针对被测服务是消费者角色的服务采用测试用例中配置的校验方式消息体的处理结果进行校验，可以保证被测服务的业务被正常触发和正常校验，降低业务触发的失败率和校验失败率。

附图说明

图1为本申请中系统测试方法的流程实现示意图一；

图2为本申请中对于被测生产者服务的测试流程实现示意图；

图3为本申请中对于被测消费者服务的测试流程实现示意图；

图4为本申请中电子设备的结构组成示意图一；

图5为本申请中电子设备的结构组成示意图二；

图6为本申请中电子设备的结构组成示意图三。

具体实施方式

下面结合附图对本发明的具体实施方式进行详细说明。应当理解的是，此处所描述的具体实施方式仅用于说明和解释本发明，并不用于限制本发明。

图1为本申请中系统测试方法的流程实现示意图一；如图1所示，该方法包括：

步骤101，创建并编辑被测服务的测试用例；

步骤102，基于所述测试用例中消息队列的配置信息修改所述被测服务的配置文件；

步骤103，如果所述被测服务是生产者服务，基于所述测试用例中配置的业务触发方式触发所述生产者服务向消息队列中发送消息体；通过模拟的消费者服务从所述消息队列中获取所述消息体，以对所述消息体进行校验；

步骤104，如果所述被测服务是消费者服务，通过模拟的生产者服务向所述消息队列发送消息体，通过所述消费者服务从所述消息队列中获取所述消息体，以基于所述测试用例中配置的校验方式对所述消息体的处理结果进行校验。

本申请中，该方法可以应用于基于消息队列进行系统测试的测试系统，该测试系统通常安装于电子设备，该电子设备包括但不限于服务器和个人计算机(PC，PersonalComputer)。

这里，消息队列是在消息的传输过程中保存消息的容器。消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。

在高平发的后端系统中，消息队列有着非常显著的优势：

一、异步处理数据，生产者(Producer)服务生产消息后将生产的消息放入消息队列即可处理其他业务，不需要等待消费者(Consumer)消费完毕，极大提高了业务处理的效率。

二、系统应用解耦，随着后端系统微服务化，微服务之间的依赖关系变得极为复杂，使用消息队列作为中间件可以降低微服务之间的耦合性。

三、流量削峰，当有海量请求并发时，服务或数据库可能出现严重的性能事故，而引入消息队列后，由其控制业务流量的吞吐，使得整个后端系统的业务处理速度更平滑。

本申请中，该电子设备通过该测试系统在创建被测服务的测试用例时，首先需要确定被测服务的配置信息，该被测服务的配置信息包括但不限于被测服务的业务触发方式、校验方式、校验内容、消息队列的地址、标题、标签；然后，基于该被测服务的配置信息创建和编辑该被测服务的测试用例。

这里，该被测服务的配置信息可以是由开发人员通过该测试系统的Web界面输入的信息，也可以是由系统预先设置好的默认配置信息。

本申请中，该电子设备在创建好测试用例后，还可以通过该测试系统接收针对该测试用例中配置信息的修改指令，基于该修改指令对应的修改信息可以对该测试用例中的配置信息进行修改，以使得修改后的测试用例更加符合开发人员对测试用例的预期效果。

这里，该修改信息可以是由开发人员通过该测试系统的Web界面输入的信息。

本申请中，该测试用例可以是一个，也可以是多个，具体视实际需求而定。

本申请中，对于系统后端生产者(Producer)服务或消费者(Consumer)服务的配置通常有两种实现方式：

1)通过配置文件的方式将生产者(Producer)服务或消费者(Consumer)服务的配置文件储存在本地，系统后端服务通过配置文件组件可以读取并解析该配置文件。

2)后端服务启动过程中通过网络通信访问配置中心系统(例中Nacos或Apollo等配置管理中心系统)，从配置中心系统中读取并解析生产者(Producer)服务或消费者(Consumer)服务所需的配置文件。

针对上述方式1)，开发者通过本申请的测试系统可以在该测试系统的web界面填写系统工程的根目录路径和配置文件的相对路径，该电子设备通过该系统工程的根目录路径和配置文件的相对路径可以定位到该被测服务在本地使用的配置文件，从而获取到该被测服务的配置文件。

针对上述方式2)，开发者通过本申请的测试系统可以在该测试系统的web界面可以填写配置中心系统的地址，该电子设备通过该配置中心系统的地址可以定位到被测服务在配置中心系统的配置文件，从而获取到该被测服务的配置文件。

本申请中，该电子设备通过该测试系统获取到被测服务的配置文件后，还可以基于该测试用例中配置的消息队列的配置信息(如地址、标题、标签)修改该被测服务的配置文件，以使得该被测服务的配置文件形成该测试用例的测试配置文件。通过该测试配置文件对该测试用例进行测试可以提高测试用例的测试成功率。然后，该电子设备可以使用该测试配置文件进行后端服务的构建、部署。

本申请中，该电子设备还可以根据该测试系统中针对被测服务配置的信息确定该被测服务的角色类型，如果该测试系统的配置信息中包括有业务触发方式，则确定当前的被测服务是生产者服务。如果该测试系统的配置信息中包括有校验方式，则确定当前的被测服务是消费者服务。

本申请中，如果该被测服务是生产者服务，该电子设备还可以基于测试用例中配置的业务触发方式触发该生产者服务向消息队列中发送消息体，然后通过模拟的消费者服务从该消息队列中获取该消息体，以对该消息体进行校验。

本申请中，该测试系统可以支持多种业务触发方式，基于不同的业务触发方式可以触发被测服务执行相关业务。

这里，该电子设备在基于测试用例中配置的业务触发方式触发该生产者服务向消息队列中发送消息体时，可以先获取测试用例中携带的对象标识，基于该对象标识确定被测服务的触发方式。

这里，当测试用例有多个时，该电子设备可以逐条执行测试用例的测试，针对不同的测试用例，可以使用不同的触发方式发起相关的业务。

这里，如果该对象标识表征该业务触发方式为网络接口(如应用程序编程接口(API，Application Programming Interface))，则触发该生产者服务将该测试用例中的测试数据封装成超文本传输协议(HTTP，Hyper Text Transfer Protocol)请求，并调用生产者服务的开放接口，触发业务，以将HTTP请求对应的消息体向消息队列发送。

本申请中，如果该对象标识表征该业务触发方式为定时任务，则触发被测的生产者服务根据定时任务的函数将该测试用例中的测试数据封装成HTTP请求的消息体向消息队列发送；

这里，对于定时任务，被测Producer需要作对应的改造，具体地，被测的生产者服务需要在源码中新增Controller类，原通过Java反射的方式根据接收的字符串动态调用定时任务的函数，将定时任务的函数触发方式改为接口触发方式。随后，该电子设备通过类似于API的方式请求该Controller映射的接口直接调用定时任务来触发业务。

这里，Controller类的作用是以接口的形式触发定时任务的业务执行。

本申请中，如果该对象标识表征该业务触发方式为消息队列，则触发该生产者服务将该测试用例中的测试数据封装成队列消息向消息队列发送。

本申请中，针对被测Producer服务，本申请提供了多种触发方式，可以保证绝大部分情况下Producer服务业务的触发，包括网络接口触发方式、定时任务触发方式、消息队列触发方式。同时，这些业务触发动作是通过测试系统自动运行的，使用者只需要在本申请的测试系统中通过web界面选择相关的触发方式以及输入该触发方式所需要的触发数据即可。

本申请中，对于被测的生产者服务，该电子设备采用模拟的消费者服务基于测试用例中消息队列的配置信息对消息队列中的消息体进行过滤，可以得到目标消息体；通过解析该目标消息体，可以得到该目标消息体对应的各属性信息(包括但不限于消息名称、身份标识号(ID，Identity Document)、内容等)；然后基于测试用例中配置的校验方式和校验内容对该消息体的各属性信息进行校验。如此，可以将测试和正式发布的过程分离，不影响正常部署工作。

本申请中，如果被测服务是消费者服务，该电子设备还可以基于测试用例中配置的校验方式对该消费者服务从消息队列中获取的消息体的处理结果进行校验。

这里，该测试系统可以支持多种校验方式，如果测试用例有多个，该电子设备可以逐条执行测试用例的测试，针对不同的测试用例，可以基于不同的校验方式对消息体的消费结果进行校验。

这里，该电子设备在对被测的消费者服务消费的消息体的结果进行校验时，可以先通过模拟的生产者服务向消息队列发送消息体，然后通过被测的消费者服务基于测试用例中消息队列的配置信息对该消息队列中的消息体进行过滤，以得到目标消息体。

这里，如果该测试用例中配置的校验方式是回调接口的报文，在通过该模拟的生产者服务监听到该消费者服务针对该目标消息体发起的回调请求报文的情况下，基于该测试用例中配置的校验内容对该回调请求报文进行校验。

一种实现中，该电子设备可以基于测试用例中配置的校验内容在该回调请求报文中提取目标内容；如果提取到该目标内容或者该目标内容满足预设条件，确定该目标消息体的处理结果通过校验。

比如，测试用例中配置的校验内容是“金额等于1000”，则在回调请求报文中提取到的目标内容表征金额是1000时，确业该目标内容满足预设条件；再比如，测试用例中配置的校验内容是“金额大于1000”，则在回调请求报文中提取到的目标内容表征金额是1001时，确业该目标内容满足预设条件。

本申请中，如果该测试用例中配置的校验方式是websocket报文，在通过该模拟的生产者服务接收到该消费者服务针对该目标消息体发起的websocket报文的情况下，基于该测试用例中配置的校验内容对该websocket报文进行校验。

一种实现中，该电子设备可以基于测试用例中配置的校验内容在该websocket报文中提取目标内容；如果提取到该目标内容或者该目标内容满足预设条件，确定该目标消息体的处理结果通过校验。

比如，测试用例中配置的校验内容是“满1000减200”，则在回调请求报文中提取到的目标内容表征金额是1000时，确业该目标内容满足预设条件；再比如，测试用例中配置的校验内容是“满1000减200”，则在回调请求报文中提取到的目标内容表征余额是800时，确业该目标内容满足预设条件。

本申请中，如果该测试用例中配置的校验方式是数据库中的数据，基于该测试用例中配置的校验内容以轮询方式在该消费者服务对应的数据库中查询目标内容；如果查询结果表征在该数据库中查询到该目标内容，确定该目标消息体的处理结果通过校验。

本申请中，如果该测试用例中配置的校验方式是日志系统中的日志，基于该测试用例中配置的校验内容以轮询方式在该日志系统中查询目标日志；根据查询结果表征在该日志系统中查询到所述目标日志，确定该目标消息体的处理结果通过校验。

本申请中，针对被测的消费者服务，本申请的测试系统提供了多种校验方式，可以保证绝大部分情况下Consumer服务业务的校验，包括回调接口校验、websocket广播信息校验、数据库轮询校验、日志轮询校验。同时，这些校验过程是通过测试系统自动运行的，使用者只需要在本申请的测试系统中通过web界面选择相关的校验方式以及输入该方式所需要的校验内容即可。

图2为本申请中对于被测生产者服务的测试流程实现示意图，如图2所示，包括：

步骤201，创建并编辑针对Producer服务的测试用例；

这里，由于Producer服务属于“生产者-消费者模型”的上游部分，负责生产消息并发送给消息队列。常规情况下，Producer服务中的一个业务由网络接口(API)、定时任务(@Schedule)或消息队列触发，本申请中的测试系统可以针对以上三种情况触发Producer服务的业务发起。

使用者在通过测试系统的web界面创建并编辑测试用例时，通过该web界面可以输入测试数据，并确认该测试用例使用的业务触发方式并输入相应的信息；

比如，对于API接口的触发方式需要输入接口信息，对于定时任务触发方式需要输入接口信息(使用接口触发定时任务函数方式)，对于消息队列触发方式(Producer服务作为消费方消费消息再触发业务)需要输入队列的网络地址、Topic(消息主题)、Tag(消息标签)。此外，使用者还需要通过该web界面定义校验方式以及校验内容。

这里，使用者通过web界面可以选择若干条测试用例作为测试计划，并输入消息队列的地址(例如RocketMQ的NameServer的地址)、Topic和Tag，建立该消息队列和该测试计划的对应关系，以绑定该测试计划。

这里，RocketMQ是企业级的消息队列，RocketMQ中有多个NameServer，不同的NameServer指向不同的系统，通过测试用例中消息队列的配置信息可以在RocketMQ中找到指定的NameServer，从而根据指定的NameServer就可以找到需要的消息体。

步骤202，修改被测Producer服务配置并使之生效；

这里，使用者可以通过web界面填写系统工程的根目录路径和配置文件的相对路径，本申请中的测试系统通过该系统工程的根目录路径和配置文件的相对路径便可以定位到被测Producer服务在本地使用的配置文件；

或者，使用者通过web界面填写配置管理中心所用配置的地址，该测试系统通过该配置管理中心的配置地址可以定位到被测Producer服务在配置管理中心的配置文件。

本申请中，该测试系统在获取到被测Producer服务的配置文件后，还可以在web界面呈现给使用者，然后使用者运行测试计划。该测试系统可以将测试用例中配置的消息队列的地址、标题、标签注入到后端服务工程或配置管理中心，以修改Producer服务的配置信息，得到测试用例的测试配置，最后使用该测试配置进行后端服务的构建、部署。

步骤203、运行测试用例，触发被测Producer服务发送消息；

使用者通过web界面运行测试计划，本测试系统自动启动模拟Consumer的服务，根据步骤202中与测试计划绑定的消息队列的地址连接消息队列并持续监听消息队列中是否有消息产生。

本申请中，测试系统可以逐条执行测试用例。针对不同的测试用例使用不同的触发方式发起相关的业务。

针对API接口，测试系统具备发送Http请求的能力，将测试用例中的测试数据序列化成Http请求的请求体并调用Producer服务的开放接口，触发业务。

针对定时任务，被测Producer需要作对应的改造，在源码中新增Controller类，通过Java反射的方式根据接收的字符串动态调用定时任务的函数，将定时任务的函数触发方式改为接口触发方式。随后，测试系统通过类似于API的方式请求该Controller映射的接口直接调用定时任务来触发业务。

针对消息队列，测试系统具备消息队列Producer的能力，将测试用例中的测试数据反序列化成消息体，并发送给Producer服务的消费的消息队列，触发业务。

Producer服务触发业务后会向消息队列发送消息。

步骤204，模拟Consumer服务获取消息并进行校验；

这里，测试系统通过模拟Consumer服务根据步骤202中输入的Topic订阅相关的主题以及Tag过滤出所需的消息(不符合指定Topic、Tag的消息不会被消费)进行消费。然后从获得的消息中解析出消息的各个属性(比如消息名称、ID、内容等)，并按步骤202测试用例中定义的校验方式和校验内容针对消息的各个属性进行校验，校验通过则该测试用例通过，否则该测试用例失败。

通过以上步骤201至步骤204，搭配不同的测试数据以及校验结果，可以测试出Producer服务的执行逻辑。

本申请将测试配置注入到被测服务的配置文件或配种中心中，保证了被测服务启动后使用的是测试配置。同时，并不影响正常部署工作，将测试和正式发布的过程分离。并且，该注入过程是自动的，使用者只需要在本申请提案的测试系统中通过web界面填写相关配置以及需要注入的区域即可。

针对被测Producer服务，本申请提供了多种触发方式，可以保证绝大部分情况下Producer服务业务的触发，包括网络接口触发方式、定时任务触发方式、消息队列触发方式。同时，这些业务触发动作是通过“业务触发单元”自动运行的，使用者只需要在本申请提案的测试系统中通过web界面选择相关的触发方式以及输入该方式所需要的触发数据即可。

图3为本申请中对于被测消费者服务的测试流程实现示意图，如图3所示，包括：

步骤301、创建并编辑针对Consumer服务的测试用例；

这里，由于Consumer服务属于“生产者-消费者模型”的下游部分，负责监听消息队列并消费消息。只要消费了消息，就会触发Consumer服务的业务。

类似于图2中步骤201，使用者通过web界面创建并编辑测试用例，输入测试数据，并确认每条测试用例的校验方式。

本申请的测试系统支持回调接口校验、轮询读取数据库校验、轮询读取日志系统如ELK校验。

使用者通过web界面选择若干条测试用例作为测试计划，并输入消息队列的地址(例如RocketMQ的NameServer的地址)、Topic和Tag，建立该消息队列与该测试计划的对应关系，以绑定该测试计划。

步骤302，修改被测Consumer服务配置并使之生效；

这里，类似于图2中的步骤202，使用者通过web界面选择需要执行的测试计划，随后本测试系统会根据步骤301中配置的Topic和Tag注入Consumer服务的配置文件或配置中心系统，构建并部署Consumer服务。

步骤303，运行测试用例，模拟Producer服务发送消息；

这里，使用者通过web界面运行测试计划，本测试系统可以自动启动模拟Producer的服务，根据步骤302中与测试计划绑定的消息队列的地址连接消息队列。

本测试系统可以逐条执行测试用例。模拟Producer获取测试用例中的测试数据，生成发送的消息体，并携带步骤302中测试计划绑定的Topic和Tag，将消息发送至消息队列。

步骤304，被测Consumer服务获取消息并进行校验。

这里，被测Consumer服务根据步骤302中输入的Topic订阅相关的主题以及Tag过滤出所需的消息(不符合指定Topic、Tag的消息不会被消费)进行消费，随后触发被测Consumer服务的业务。

通常情况下，作为Consumer服务，业务处理完毕后会回调Producer的接口，发送Consumer处理业务的结果。这种异步通信方式，比起Producer通过时间轮询的方式主动查询结果的方式要好得多，可以大量节省服务端的CPU和内存资源。也可能通过websocket的方式直接请求客户端浏览器，直接通知服务。

这里，如果被测Consumer使用的是Http回调接口的方式，则模拟Producer绑定网络端口进行监听，直到获取被测Consumer回调时的请求内容，从中提取想要校验的内容进行校验。

如果被测Consumer使用的是websocket的方式，则模拟Producer开启websocket客户端接收被测Consumer发出的websocket报文，从中提取想要校验的内容进行校验。同时，被测Consumer支持以时间轮询的方式对指定数据库、表、字段进行查询，获取字段值进行校验。并且，被测Consumer支持以时间轮询的方式在日志系统中查询日志，从日志中提取想要校验的内容进行校验。

通过以上步骤301至步骤304的步骤，搭配不同的测试数据以及校验结果，可以测试出Consumer服务的执行逻辑。

本申请通过使用了分层测试的方式，针对Producer和Consumer采用不同的测试方法。使用模拟Producer和Consumer，保证了另一端被测业务(Consumer和Producer)的完整性，保证其属于集成测试而非单元测试或端到端测试的范畴。另外，针对被测Consumer服务，本申请提供了多种结果校验方式，可以保证绝大部分情况下Consumer服务业务的校验，包括回调接口校验、websocket广播信息校验、数据库轮询校验、日志轮询校验。同时，这些校验过程是通过“结果校验单元”自动运行的，使用者只需要在本申请提案的装置中通过web选择相关的校验方式以及输入该方式所需要的校验内容即可。

本申请还提供了web界面，增强了使用者的交互体验，降低了系统的使用难度。并支持多用户同时使用，同时使用数据库存储测试过程流程中产生的各项数据，方便用户查看、调试，并可随时复用，进一步提高了整体测试的效率，降低了测试的复杂性。

图4为本申请中电子设备的结构组成示意图一，如图4所示，该电子设备包括：

测试用例单元401，用于创建并编辑被测服务的测试用例；

配置注入单元402，用于基于所述测试用例中消息队列的配置信息修改所述被测服务的配置文件；

业务触发单元403，用于在所述被测服务是生产者服务的情况下，基于所述测试用例中配置的业务触发方式触发所述生产者服务向消息队列中发送消息体；

模拟单元404，用于在所述被测服务是生产者服务的情况下，通过模拟的消费者服务从所述消息队列中获取所述消息体；以及用于如果所述被测服务是消费者服务，通过模拟的生产者服务向所述消息队列发送消息体；

校验单元405，用于对所述消息体进行校验；以及用于基于所述测试用例中配置的校验方式对所述消息体的处理结果进行校验。

优选方案中，所述业务触发单元403至少包括以下组件之一：

第一触发器组件4031，用于如果所述测试用例中携带的对象标识表征所述业务触发方式为网络接口，触发所述生产者服务将所述测试用例中的测试数据封装成超文本传输协议HTTP请求的消息体向消息队列发送；以及用于如果所述对象标识表征所述业务触发方式为定时任务，触发所述生产者服务根据定时任务的函数将所述测试用例中的测试数据封装成HTTP请求的消息体向消息队列发送；

第二触发器组件4032，用于如果所述测试用例中携带的对象标识表征所述业务触发方式为消息队列，触发所述生产者服务将所述测试用例中的测试数据封装成队列消息向消息队列发送。

优选方案中，所述校验单元405包括：

校验组件4051，用于在所述被测服务是生产者服务的情况下，基于所述测试用例中配置的校验方式和校验内容对所述消息体中的各属性信息进行校验。

第一模拟组件4052，用于在所述被测服务是消费者服务的情况下，如果所述测试用例中配置的校验方式是回调接口的报文，绑定网络端口以监听所述消费者服务针对所述目标消息体发起的回调请求报文；以及向所述校验组件4051发送所述回调请求报文；

第二模拟组件4053，用于在所述被测服务是消费者服务的情况下，如果所述测试用例中配置的校验方式是websocket报文，接收所述消费者服务针对所述目标消息体发起的websocket报文，以及向所述校验组件4051发送所述websocket报文；

第一查询组件4054，用于在所述被测服务是消费者服务的情况下，如果所述测试用例中配置的校验方式是数据库中的数据，基于所述测试用例中配置的校验内容以轮询方式在所述消费者服务对应的数据库中查询目标内容；如果查询结果表征在所述数据库中查询到所述目标内容，确定所述目标消息体的处理结果通过校验；

第二查询组件4055，用于在所述被测服务是消费者服务的情况下，如果所述测试用例中配置的校验方式是日志系统中的日志，基于所述测试用例中配置的校验内容以轮询方式在所述日志系统中查询目标日志；根据查询结果表征在所述日志系统中查询到所述目标日志，确定所述目标消息体的处理结果通过校验.

所述校验组件4051，还用于基于所述测试用例中配置的校验内容对所述回调请求报文进行校验；以及用于基于所述测试用例中配置的校验内容对所述websocket报文进行校验。

下面为本申请的一个实施例：

针对某个网购系统，存在若干个微服务，其中有N个产品微服务，提供产品使用相关功能。1个订单微服务，提供新增订单和订单管理等功能；基于服务解耦和流量削峰的考虑，用户和产品微服务通过接口通信，用户和订单微服务不直接交互，产品微服务和订单微服务之间使用消息队列进行业务通信。

现有一个测试场景是用户A选择商品后下单，A通过浏览器请求产品微服务的订购接口，产品微服务经过业务处理后产生消息放入消息队列；订单微服务消费消息，处理完毕后(可能需要比较长的时间)产生订单，更新数据库，产生日志，并回调产品微服务的接口通知产品微服务。

针对该场景，由于两个微服务之间使用了消息队列，整个系统是异步通信的，接口测试无法适配该场景。而本申请使用了分层测试的方式，针对Producer(产品微服务)和Consumer(订单微服务)采用不同的测试方法。使用模拟Producer和Consumer，保证了另一端被测业务(Consumer和Producer)的完整性，可以有针对性地对任何一个Producer或Consumer服务进行测试。

需要说明的是：上述实施例提供的电子设备在进行系统测试时，仅以上述各程序模块的划分进行举例说明，实际应用中，可以根据需要而将上述处理分配由不同的程序模块完成，即将装置的内部结构划分成不同的程序模块，以完成以上描述的全部或者部分处理。另外，上述实施例提供的电子设备与上述提供的系统测试方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

图5为本申请中电子设备的结构组成示意图二，如图5所示，该电子设备包括：

测试用例单元501：使用者通过web界面调用“测试用例管理组件5101”创建并编辑测试用例，为每一条测试用例创建测试数据以及校验方式和校验内容。再通过web界面调用“测试计划管理组件5102”，从“测试用例管理组件5101”获取所有已创建的测试用例，从中进行选择，组合成测试计划，如步骤5-1所示；并从web界面输入“消息队列505”的地址以及消息的Topic和Tag，将其绑定给当前的测试计划。

配置注入单元502：运行测试计划后，“测试计划管理组件5102”将“消息队列505”的地址以及消息的Topic和Tag传递给本单元，如步骤5-2所示。随后，再将其注入“被测系统506”的“配置中心5601”或配置文件，如步骤5-3所示。被测系统构建、部署后使用的就是来自于当前测试计划的测试配置。

业务触发单元503：运行测试计划后，“测试用例单元501”将当前测试用例的测试对象标识发送给本单元，决定将要运行的触发方式，如步骤5-4所示。

如果被测服务是Producer服务，本单元接收测试用例的对象标识，如果对象标识是http接口，则调用“http触发器组件5301”，将测试用例中的测试数据封装成http请求，发送至被测系统的“被测Producer服务5602”的接口，触发被测Producer服务的业务，使其产生需要被测试的消息，如步骤5-5所示。

如果对象标识是定时任务，也调用“http触发器组件5301”，将测试用例中的测试数据封装成http请求，发送至被测系统的“被测Producer服务5602”的定时任务对应的调用接口，触发定时任务，使其产生需要被测试的消息，如步骤5-5所示。

如果那个标识是消息队列，则调用“消息队列触发器组件5302”，将测试用例中的测试数据封装成消息，并将该消息放入至被测系统的“被测Producer服务5602”作为消费者连接的消息队列，供其消费，并触发随后的Producer服务，使其产生需要被测试的消息，如步骤5-5所示。

按以上5-5步骤，被测Producer服务5602的业务被触发后，产生需要被测试的消息，放入“消息队列505”，如步骤5-6所示。

本单元的“模拟Consumer组件5303”取代真实Consumer服务连接至消息队列，从“消息队列505”消费并解析被测Producer服务产生的消息，如步骤5-7所示。随后，会将解析后的消息发送至“结果校验单元504”的“校验组件5401”，供其校验消息中的消息体是否符合预期。

如果被测服务是Consumer服务，本单元的“模拟Producer组件5304”会取代真实Producer服务连接至消息队列，产生指定的消息发送消息至“消息队列505”，供被测Consumer服务消费，如步骤5-8所示。随后，被测系统的“被测Consumer服务5603”从“消息队列505”消费消息，从而触发被测服务的业务开始运行，如步骤5-9所示。随后，结果校验校验单元会按预设的方式来校验被测Consumer服务运行的的结果。

结果校验单元504：待业务触发后，本单元会按照测试用例中设定的校验内容，来校验测试结果是否符合预期。

如果被测服务是Producer服务，“模拟Consumer组件5303”会将解析后的消息发送至本单元的“校验组件5401”进行校验，校验组件会按照测试用例中设定的校验对象对消息体中的字段进行校验，如果消息体中的字段和测试用例中的校验对象的预期值相符合，则测试用例通过；如果不符合，则测试用例不通过，如步骤5-10所示。

如果被测服务是Consumer服务，按照测试用例中的测试对象采用不同的校验方式。如果测试对象是回调接口的报文，“被测Consumer服务5603”启动“模拟http服务组件5402”，绑定网端口并持续监听被测Consumer服务发起回调的http请求，收到http请求后解析并将请求体发送给“校验组件5401”。随后校验组件5401按照测试用例中的校验内容来校验请求体，如果相符合，则测试用例通过，反之则不通过。

如果测试对象是websocket报文，“被测Consumer服务5603”启动“模拟websocket客户端组件5403”，主动连接被测Consumer服务的websocket服务，被测Consumer业务完成后，其websocket服务会主动发送广播报文至“模拟websocket客户端组件5403”。“模拟websocket客户端组件5403”解析该websocket报文，获取报文体中的内容将其发送给“校验组件5401”。随后校验组件5401按照测试用例中的校验内容来校验websocket报文，如果相符合，则测试用例通过，反之则不通过。

如果被测对象是数据库中的数据，“被测Consumer服务5603”启动“数据库查询组件5404”，主动连接被测Consumer服务对应的数据库5604，按照测试用例中设定的测试内容，以轮询的方式主动查询数据库5604中是否存在该字段值，在超时时间内(预设10秒)查询到则终止查询，测试用例通过；如果在超时时间内没有查询到，则终止查询，测试用例失败。

如果被测对象是日志系统中的日志，“被测Consumer服务5603”启动“日志查询组件5405”，主动连接被测Consumer服务对应的日志系统5605，按照测试用例中设定的测试内容，以轮询的方式主动查询日志系统5605中是否存在预期的日志内容(日志时间段在测试用例开始至查询开始这段时间内)，在超时时间内(预设10秒)查询到则终止查询，测试用例通过；如果在超时时间内没有查询到，则终止查询，测试用例失败。

本申请的“配置注入单元”可以将测试配置注入到被测服务的配置文件或配种中心中，保证了被测服务启动后使用的是测试配置。同时，并不影响正常部署工作，将测试和正式发布的过程分离。并且，该注入过程是自动的，使用者只需要在本申请提案的装置中通过web填写相关配置以及需要注入的区域即可。

针对被测Producer服务，本申请提供了多种触发方式，可以保证绝大部分情况下Producer服务业务的触发，包括网络接口触发方式、定时任务触发方式、消息队列触发方式。同时，这些业务触发动作是通过“业务触发单元”自动运行的，使用者只需要在本申请提案的装置中通过web选择相关的触发方式以及输入该方式所需要的触发数据即可。如上例中的产品微服务，业务触发是通过浏览器调用本微服务的http接口实现的。随后，模拟订单微服务获取被测产品微服务产生的消息，拿消息体中的内容与测试用例中的预期内容进行校验，便可获知被测产品微服务的业务逻辑是否正确。

针对被测Consumer服务，本申请提供了多种结果校验方式，可以保证绝大部分情况下Consumer服务业务的校验，包括回调接口校验、websocket广播信息校验、数据库轮询校验、日志轮询校验。同时，这些校验过程是通过“结果校验单元”自动运行的，使用者只需要在本申请提案的装置中通过web选择相关的校验方式以及输入该方式所需要的校验内容即可。如上例中的订单微服务，获取模拟产品微服务产生的消息后，进行相关的业务处理，产生订单后写入数据库，回调模拟产品微服务的http接口进行通知，并产生日志。随后，校验单元的模拟http服务组件会接收被测订单微服务回调的http请求，数据库查询组件会轮询数据库中新增的订单，日志查询组件会轮询日志系统中新产生的日志，获取相应的内容和供校验组件进行校验，便可获知被测订单微服务的业务逻辑是否正确。

最后，本申请提供了web界面，增强了使用者的交互体验，降低了系统的使用难度。并支持多用户同时使用，同时使用数据库存储测试过程流程中产生的各项数据，方便用户查看、调试，并可随时复用，进一步提高了整体测试的效率，降低了测试的复杂性。

需要说明的是：上述实施例提供的电子设备在进行系统测试时，仅以上述各程序模块的划分进行举例说明，实际应用中，可以根据需要而将上述处理分配由不同的程序模块完成，即将装置的内部结构划分成不同的程序模块，以完成以上描述的全部或者部分处理。另外，上述实施例提供的电子设备与上述提供的系统测试方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

图6为本申请中电子设备的结构组成示意图三，电子设备600可以是基于Windows或Linux或MacOS操作系统的一种计算机设备，包括但不限于是计算机、数字广播终端、信息收发设备、医疗设备、健身设备、个人数字助理等终端或服务器，这里，服务器包括但不限于实体服务器、云服务器。图6所示的电子设备600包括：至少一个处理器601、存储器602、至少一个网络接口604和用户接口603。网络接口604可以与与外部数据库连通，进行数据访问和操作，该外部数据库可以非本计算机设备的硬件组成部分，而是部署在本设备之外的计算机设备上的数据库系统，并通过网络向外部提供数据库服务；网络接口604还可以与消息队列实体连通，将本硬件实体产生的消息放入消息队列实体，或从消息队列实体中消费消息，该消息队列可以非本计算机设备的硬件组成部分，而是部署在本设备之外的计算机设备上的消息队列系统，并通过网络向外部提供消息服务；网络接口604还可以与向被测系统的网络接口发送网络报文，并接收响应报文，该被测系统可以非本计算机设备的硬件组成部分，而是部署在本设备之外的计算机设备上的某个网络应用系统，并通过网络向外部提供应用服务。

电子设备600中的各个组件通过总线系统605耦合在一起。可理解，总线系统605用于实现这些组件之间的连接通信。总线系统605除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图6中将各种总线都标为总线系统605。

其中，用户接口603可以包括显示器、键盘、鼠标、轨迹球、点击轮、按键、按钮、触感板或者触摸屏等。

可以理解，存储器602可以是易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(ROM，Read Only Memory)、可编程只读存储器(PROM，Programmable Read-Only Memory)、可擦除可编程只读存储器(EPROM，Erasable Programmable Read-Only Memory)、电可擦除可编程只读存储器(EEPROM，Electrically Erasable Programmable Read-Only Memory)、磁性随机存取存储器(FRAM，ferromagnetic random access memory)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(CD-ROM，Compact Disc Read-Only Memory)；磁表面存储器可以是磁盘存储器或磁带存储器。易失性存储器可以是随机存取存储器(RAM，Random AccessMemory)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(SRAM，Static Random Access Memory)、同步静态随机存取存储器(SSRAM，Synchronous Static Random Access Memory)、动态随机存取存储器(DRAM，Dynamic Random Access Memory)、同步动态随机存取存储器(SDRAM，SynchronousDynamic Random Access Memory)、双倍数据速率同步动态随机存取存储器(DDRSDRAM，Double Data Rate Synchronous Dynamic Random Access Memory)、增强型同步动态随机存取存储器(ESDRAM，Enhanced Synchronous Dynamic Random Access Memory)、同步连接动态随机存取存储器(SLDRAM，SyncLink Dynamic Random Access Memory)、直接内存总线随机存取存储器(DRRAM，Direct Rambus Random Access Memory)。本申请实施例描述的存储器602旨在包括但不限于这些和任意其它适合类型的存储器。

本申请实施例中的存储器602用于存储各种类型的数据以支持电子设备600的操作。这些数据的示例包括：用于在电子设备600上操作的任何计算机程序，如操作系统6021和应用程序6022；联系人数据；电话簿数据；消息；图片；音频等。其中，操作系统6021包含各种系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务。应用程序6022可以包含各种应用程序，例如媒体播放器(Media Player)、浏览器(Browser)等，用于实现各种应用业务。实现本申请实施例方法的程序可以包含在应用程序6022中。

上述本申请实施例揭示的方法可以应用于处理器601中，或者由处理器601实现。处理器601可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器601中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器601可以是通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。处理器601可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤，可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于存储介质中，该存储介质位于存储器602，处理器601读取存储器602中的信息，结合其硬件完成前述方法的步骤。

在示例性实施例中，电子设备600可以被一个或多个应用专用集成电路(ASIC，Application Specific Integrated Circuit)、DSP、可编程逻辑器件(PLD，ProgrammableLogic Device)、复杂可编程逻辑器件(CPLD，Complex Programmable Logic Device)、现场可编程门阵列(FPGA，Field-Programmable Gate Array)、通用处理器、控制器、微控制器(MCU，Micro Controller Unit)、微处理器(Microprocessor)、或其他电子元件实现，用于执行前述方法。

在示例性实施例中，本申请实施例还提供了一种计算机可读存储介质，例如包括计算机程序的存储器602，上述计算机程序可由电子设备600的处理器401执行，以完成前述方法所述步骤。计算机可读存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、Flash Memory、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备，如移动电话、计算机、平板设备、个人数字助理等。

一种计算机可读存储介质，其上存储有计算机指令，该计算机指令被处理器执行时，执行上述任一种系统测试方法中任一项方法步骤。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的几个产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。

本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种系统测试方法，其特征在于，所述方法包括：

创建并编辑被测服务的测试用例；

基于所述测试用例中消息队列的配置信息修改所述被测服务的配置文件；

如果所述被测服务是生产者服务，基于所述测试用例中配置的业务触发方式触发所述生产者服务向消息队列中发送消息体；通过模拟的消费者服务从所述消息队列中获取所述消息体，以对所述消息体进行校验；

如果所述被测服务是消费者服务，通过模拟的生产者服务向所述消息队列发送消息体，通过所述消费者服务从所述消息队列中获取所述消息体，以基于所述测试用例中配置的校验方式对所述消息体的处理结果进行校验。

2.根据权利要求1所述的方法，其特征在于，所述基于所述测试用例中配置的业务触发方式触发所述生产者服务向消息队列中发送消息体，至少包括以下方法之一：

获取所述测试用例中携带的对象标识；

如果所述对象标识表征所述业务触发方式为网络接口，触发所述生产者服务将所述测试用例中的测试数据封装成超文本传输协议HTTP请求的消息体向消息队列发送；

如果所述对象标识表征所述业务触发方式为定时任务，触发所述生产者服务根据所述定时任务的函数将所述测试用例中的测试数据封装成HTTP请求的消息体向消息队列发送；

如果所述对象标识表征所述业务触发方式为消息队列，触发所述生产者服务将所述测试用例中的测试数据封装成队列消息向消息队列发送。

3.根据权利要求1所述的方法，其特征在于，所述通过模拟的消费者服务从所述消息队列中获取所述消息体，以对所述消息体进行校验，包括：

通过模拟的消费者服务，基于所述测试用例中消息队列的配置信息对所述消息队列中的消息体进行过滤，得到目标消息体；

解析所述目标消息体，得到所述目标消息体对应的各属性信息；

基于所述测试用例中配置的校验方式和校验内容对所述各属性信息进行校验。

4.根据权利要求1所述的方法，其特征在于，所述通过消费者服务从所述消息队列中获取所述消息体，以基于所述测试用例中配置的校验方式对所述消息体的处理结果进行校验，至少包括以下方法之一：

通过所述消费者服务，基于所述测试用例中消息队列的配置信息对所述消息队列中的消息体进行过滤，得到目标消息体；

如果所述测试用例中配置的校验方式是回调接口的报文，在通过所述模拟的生产者服务监听到所述消费者服务针对所述目标消息体发起的回调请求报文的情况下，基于所述测试用例中配置的校验内容对所述回调请求报文进行校验；

如果所述测试用例中配置的校验方式是websocket报文，在通过所述模拟的生产者服务接收到所述消费者服务针对所述目标消息体发起的websocket报文的情况下，基于所述测试用例中配置的校验内容对所述websocket报文进行校验；

如果所述测试用例中配置的校验方式是数据库中的数据，基于所述测试用例中配置的校验内容以轮询方式在所述消费者服务对应的数据库中查询目标内容；如果查询结果表征在所述数据库中查询到所述目标内容，确定所述目标消息体的处理结果通过校验；

如果所述测试用例中配置的校验方式是日志系统中的日志，基于所述测试用例中配置的校验内容以轮询方式在所述日志系统中查询目标日志；根据查询结果表征在所述日志系统中查询到所述目标日志，确定所述目标消息体的处理结果通过校验。

5.根据权利要求4所述的方法，其特征在于，所述基于所述测试用例中配置的校验内容对所述回调请求报文进行校验，包括：

基于所述测试用例中配置的校验内容在所述回调请求报文中提取目标内容；如果提取到所述目标内容或者所述目标内容满足预设条件，确定所述目标消息体的处理结果通过校验；

所述基于所述测试用例中配置的校验内容对所述websocket报文进行校验，包括：

基于所述测试用例中配置的校验内容在所述websocket报文中提取目标内容；如果提取到所述目标内容或者所述目标内容满足预设条件，确定所述目标消息体的处理结果通过校验。

6.根据权利要求1所述的方法，其特征在于，所述创建并编辑被测服务的测试用例，包括：

确定被测服务的配置信息，所述配置信息至少包括所述被测服务的业务触发方式、校验方式、校验内容、消息队列的地址、标题、标签中的一种；

基于所被测服务的配置信息创建所述被测服务的测试用例。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述基于所述测试用例中消息队列的配置信息修改所述被测服务的配置文件，包括：

获取所述被测服务的配置文件；

基于所述测试用例中消息队列的地址、标题、标签修改所述配置文件，以形成所述测试用例的测试配置文件。

8.一种系统测试装置，其特征在于，所述系统测试装置包括：

测试用例单元，用于创建并编辑被测服务的测试用例；

配置注入单元，用于基于所述测试用例中消息队列的配置信息修改所述被测服务的配置文件；

业务触发单元，用于在所述被测服务是生产者服务的情况下，基于所述测试用例中配置的业务触发方式触发所述生产者服务向消息队列中发送消息体；

模拟单元，用于在所述被测服务是生产者服务的情况下，通过模拟的消费者服务从所述消息队列中获取所述消息体；以及用于如果所述被测服务是消费者服务，通过模拟的生产者服务向所述消息队列发送消息体；

校验单元，用于对所述消息体进行校验；以及用于基于所述测试用例中配置的校验方式对所述消息体的处理结果进行校验。

9.一种电子设备，其特征在于，所述电子设备包括：处理器和用于存储能够在处理器上运行的计算机程序的存储器，

其中，所述处理器用于运行所述计算机程序时，执行上述权利要求1至7所述的任一种系统测试方法中的任一项方法步骤。

10.一种计算机可读存储介质，其特征在于，用于存储计算机指令，所述计算机指令被处理器执行时，执行上述权利要求1至7所述的任一种系统测试方法中的任一项方法步骤。