CN114691517A - 一种测试方法、装置、设备及存储介质 - Google Patents

Abstract

本公开提供了一种测试方法、装置、设备及存储介质，涉及计算机技术领域，尤其涉及互联网通信技术领域。具体实现方案为：获取初始消息包，初始消息包包含目标测试场景所需的测试数据；对初始消息包进行重构，得到测试消息包；获取测试消息包对应的消息消费策略；根据消息消费策略，下发测试消息包至被测业务端。本公开提供的一种测试方法、装置、设备及存储介质，可以自行根据目标测试场景的需求定制化下发测试消息包，不需要与上游业务端进行沟通，被动等待上游业务端提供测试消息包，因此，可以解除对消息中间件的依赖，提高测试效率。

Description

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

技术领域

本公开涉及计算机技术领域，尤其涉及互联网通信技术领域的一种测试方法、装置、设备及存储介质。

背景技术

中大型的互联网公司系统架构越来越复杂，因此系统架构的业务模块之间开始使用消息中间件来实现异步解耦，目前，在解耦场景的测试中，主要采用以下两种方案来推送测试消息包：

1、申请多个消息中间件资源，由消息中间件将测试消息包推送至被测业务端；

2、被测业务端自行从消费接口反拼装测试消息包，并自主调用测试消息包。

发明内容

本公开提供了一种效率更高的测试方法、装置、设备以及存储介质。

根据本公开的一方面，提供了一种测试方法，包括：获取初始消息包，所述初始消息包包含目标测试场景所需的测试数据；对所述初始消息包进行重构，得到测试消息包；获取所述测试消息包对应的消息消费策略；根据所述消息消费策略，下发所述测试消息包至被测业务端。

根据本公开的另一方面，提供了一种测试装置，包括：第一获取模块，用于获取初始消息包，所述初始消息包包含目标测试场景所需的测试数据；重构模块，用于对所述初始消息包进行重构，得到测试消息包；第二获取模块，用于获取所述测试消息包对应的消息消费策略；下发模块，用于根据所述消息消费策略，下发所述测试消息包至被测业务端。

根据本公开的另一方面，提供了一种电子设备，包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本公开所述的方法。

根据本公开的另一方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行本公开所述的方法。

根据本公开的另一方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现本公开所述的方法。

本公开提供的一种测试方法、装置、设备及存储介质，在对被测业务端进行测试时，可以自行根据目标测试场景的需求定制化下发测试消息包，不需要与上游业务端进行沟通，被动等待上游业务端提供测试消息包，因此，可以解除对消息中间件的依赖，提高测试效率。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1是根据本公开第一实施例的一种测试方法的流程示意图；

图2是根据本公开第一实施例的一种测试方法的应用场景图；

图3是根据本公开第二实施例的一种测试方法的流程示意图；

图4是根据本公开第四实施例的一种测试方法的流程示意图；

图5是根据本公开第六实施例的一种测试方法的流程示意图；

图6是根据本公开第八实施例的一种测试装置的结构示意图；

图7是用来实现本公开实施例的一种测试方法的电子设备的框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

图1是本公开第一实施例的一种测试方法的流程示意图，如图1所示，该方法主要包括：

步骤S101，获取初始消息包，初始消息包包含目标测试场景所需的测试数据。

在本实施例中，首先需要获取初始消息包，可以在线上日志中抓取初始消息包，初始消息包一般包括消息头和消息体，消息体内会包含目标测试场景所需的测试数据，例如，在订单流程业务中，消息体内可能包含用户名、订单状态、订单数量等，不同的目标测试场景对应的消息体内可以包含不同的数据。

在一可实施方式中，业务场景产生的消息包都会存储在线上日志中，因此，线上日志中的初始消息包会包括各种测试场景所需的测试数据，从而在一定程度上避免了在测试过程中会遗漏某些场景的问题。具体地，在线上日志中抓取初始消息包时，可以根据当前的目标测试场景，在线上日志中抓取对应的初始消息包。

步骤S102，对初始消息包进行重构，得到测试消息包。

在本实施例中，获得初始消息包之后，需要对初始消息包进行重构。具体地，初始消息包是在业务场景中产生的，其中包含的业务数据未必能够覆盖目标测试场景所需的全部测试数据，因此需要对初始消息包进行重构，即根据目标测试场景所需的测试数据，对初始消息包重新进行构造，从而得到测试消息包。

在一可实施方式中，可以针对目标测试场景的不同需求，生成对应的测试数据，然后将所有的测试数据进行存储，在获取到初始消息包之后，可以利用存储的测试数据对初始消息包进行重构，即利用存储的测试数据一一替换初始消息包中的测试数据，从而得到多个与目标测试场景对应的测试消息包。

步骤S103，获取测试消息包对应的消息消费策略。

在本实施例中，得到测试消息包之后，还需要获取测试消息包对应的消息消费策略，消息消费策略用于指示下发测试消息包的方式。

在一可实施方式中，消息消费策略可以是测试人员根据目标测试场景确定的，例如，测试人员根据目标测试场景中被测业务端的地址，确定测试消息包的消费地址；根据目标测试场景中的测试过程，确定如何触发测试消息包的下发；根据目标测试场景中的测试需求，确定测试消息包下发失败之后如何处理等，消息消费策略的内容可以根据目标测试场景确定，测试人员还可以设置其他相关策略。具体地，可以设置一个用户界面供测试人员输入消息消费策略，下发测试消息包时，可以直接获取测试人员输入的消息消费策略。

步骤S104，根据消息消费策略，下发测试消息包至被测业务端。

在本实施例中，根据获取到的消息消费策略，将测试消息包下发至被测业务端。具体地，被测业务端可以是被测的系统、软件或装置等，是测试环境的下游。

在一可实施方式中，首先获取消息消费策略中的测试消息包的消费地址，即被测业务端的地址，若消息消费策略中指示自动触发消息测试包的下发，则根据预设的触发频率，将测试消息包下发至被测业务端；若消息消费策略中指示手动触发测试消息包，则在获取到测试人员的指令时，按照测试消息包的消费地址将测试消息包下发至被测业务端。

图2是根据本公开第一实施例的一种测试方法的应用场景图，如图2所示，在一种业务场景中，生产环境上游和生产环境下游之间通过消息中间件通信，此时如果要对生产环境下游进行测试，就必须依赖生产环境上游提供测试消息包，若生产环境上游没有及时提供测试消息包，就会导致对生产环境下游的测试延迟，测试效率降低。

因为线上日志中会存储生产环境上游和生产环境下游之间的交互数据，所以线上日志中必然包含目标测试场景所需的测试数据。在本公开第一实施例中，测试平台会提供解耦消息服务，抓取线上日志中的初始消息包，并对其进行保存；若测试环境下游有需要的测试消息包，测试平台可以根据保存的初始消息包，自行构造测试环境下游所需的测试消息包，然后按照消息消费策略将测试消息包推送测试环境下游，即被测业务端。

在本公开第一实施例中，首先获取初始消息包，然后对初始消息包进行重构得到测试消息包，并按照获取的消息消费策略，实现测试消息包的下发。在本公开第一实施例中，可以对获取的初始消息包进行定制化的开发，从而在测试场景中对消息中间件解除依赖，提高了测试效率，并保证了测试消息包满足目标测试场景的需求。

图3是根据本公开第二实施例的一种测试方法的流程示意图，如图3所示，步骤S101主要包括：

步骤S201，在线上日志中抓取目标测试场景对应的消费接口的初始消息包列表。

步骤S202，对初始消息包列表进行去重操作，得到初始消息包。

在本实施例中，由于线上日志中存储了大量业务场景中产生的消息包，很多消息包并非目标测试场景所需的消息包，因此，在抓取初始消息包时，可以抓取目标测试场景对应的消费接口的初始消息包列表。在不同的业务场景中，消息包的消费接口是不同的，因此在抓取初始消息包时，只需要抓取目标测试场景对应的消费接口的初始消息包即可，得到初始消息包列表，由于线上日志可能存在大量的初始消息包，因此还需要对得到的初始消息包列表进行去重操作，从而得到去重后的初始消息包。

在一可实施方式中，可以根据初始消息包中的关键字段，对初始消息包列表进行去重操作。例如，在订单流程业务中，通常初始消息包中的关键字段可以为：日期和订单状态，若某些初始消息包中的日期和订单状态相同，此时可以对这些初始消息包进行去重操作，只保留其中一个初始消息包即可，这样可以减小存储消耗。

在本公开第二实施例中，直接抓取目标测试场景对应的消费接口的初始消息包列表，并对初始消息包列表进行去重操作，得到初始消息包。在本实施例中，可以提高获取初始消息包的效率，并且通过对初始消息包的去重操作，可以减小存储消耗。

在本公开第三实施例中，步骤S101还包括：根据搭建的线下环境中间件，获取上游业务端配合下发的初始消息包。

在本实施例中，虽然线上日志中会存储大量业务场景的消息包，但是其未必包含目标测试场景所需的全部数据，例如，在订单流程业务中，通常包括用户下单、支付、配送和接收等流程，但是用户在进行订单流程时，可能会出现订单中断的现象，如用户下完单之后就取消订单，或者用户支付失败等情况，这些情况对应的数据在线上日志中可能不存在或者数量较少，不满足测试需求，此时就需要上游业务端配合下发对应的初始消息包。

在本实施例中，首先可以根据搭建的线下环境中间件，获取上游业务端配合下发的初始消息包。在一可实施方式中，在与搭建好的线下环境中间件取得连接之后，可以联调上游业务端构造目标测试场景所需的初始消息包，然后经过线下环境中间件获取新增的初始消息包，并将新增的初始消息包进行存储，丰富测试场景，以便日后对于此类测试场景的测试。

在本公开第三实施例中，根据搭建好的线下环境中间件，获取上游业务端配合下发的初始消息包，可以保证获取到目标测试场景所需的全部测试数据，丰富测试场景，保证测试结果的准确性。

图4是本公开第四实施例的一种测试方法的流程示意图，如图4所示，步骤S102主要包括：

步骤S401，对初始消息包进行解析，得到初始消息包的消息体。

在本实施例中，首先需要解析得到初始消息包的消息体，因为初始消息包是特定格式的消息包，要想得到其中的测试数据，就需要对初始消息包进行解析，得到初始消息包的消息体。具体地，可以根据初始消息包的封装规则，对初始消息包进行解析，本公开不对初始消息包解析的方法进行限定。

在一可实施方式中，某订单流程业务的一个初始消息包的消息体可以为：

可以看出，在此消息体中，订单编号order_id的值为123，订单状态status的值为express，即快递中。

步骤S402，将消息体中目标测试场景需要监听的字段值替换为对应的变量，得到消息体模板。

在本实施例中，解析得到的消息体中数据是固定的，不方便构造测试消息包，因此，在解析得到消息体时，可以将消息体中目标测试场景需要监听的字段值替换为对应的变量，得到消息体模板，以便利用消息体模板构造测试消息包。

在一可实施方式中，对于订单流程业务，通常需要监听订单编号和订单状态告知下游方处理各自的业务，因此，对于上述订单流程业务的消息体，可以将需要监听订单编号order_id和订单状态status的值替换为对应的变量，例如，使用${order_id}$替换规则替换123，使用${status}$的规则替换express，替换完成之后得到的消息体模板为：

其中，${order_id}$和${status}$均为变量，可以替换为不同的数据，方便后续根据目标测试场景的需求构造测试消息包。

步骤S403，根据目标测试场景和变量，创建测试数据列表。

在本实施例中，得到消息体模板之后，还需要根据目标测试场景和变量，创建测试数据列表，测试数据列表中包含各种目标测试场景所需的测试数据。

在一可实施方式中，若将订单流程业务中需要监听订单编号order_id和订单状态status的值替换为对应的变量${order_id}$和${status}$，此时可以根据目标测试场景的需求和变量的不同取值，创建测试数据列表。

例如，对于该订单流程业务对应的目标测试场景，创建的测试数据列表可以为：

消息业务	order_id	status
			订单状态下发	123	pay
订单状态下发	123	express
			订单状态下发	123	signed
订单状态下发	123456	express
			订单状态下发	123456	cancel

其中，${order_id}$的可能取值有123和123456，${status}$的可能取值为pay(支付)、express(快递中)、signed(已签收)和cancel(取消)，当然，${order_id}$和${status}$还可以为目标测试场景所需的其他取值。

步骤S404，根据消息体模板和测试数据列表，构造得到测试消息包。

在本实施例中，可以根据消息体模板和测试数据列表，构造得到测试消息包。

在一可实施方式中，可以将测试数据列表中的测试数据，一一填写至消息体模板中，并对填写之后的消息体模板进行打包，得到测试消息包。例如，将测试数据order_id＝123和status＝pay写入之前得到的消息体模板中，可以得到新的消息体：

然后对新的消息体进行打包，得到测试消息包。具体地，可以将测试数据列表中的所有测试数据均写入消息体模板中，得到多个测试消息包，从而丰富测试消息包。

在本公开第四实施例中，将初始消息包的消息体中需要监听的字段值替换为对应的变量，得到消息体模板，然后根据消息体模板和创建的测试数据列表，构造得到测试消息包。在本实施例中，可以根据目标测试场景的需求，自行构造测试消息包，即对测试消息包进行了定制化开发，保证测试消息包符合目标测试场景的需求，而且自行构造的测试消息包包含的测试数据丰富，可以保证测试的准确率。

在本公开第五实施例中，消息消费策略可以包括：消息消费地址、消息触发方式、消息自动消费频率和消息下发失败策略；消息消费地址用于指示被测业务端的地址；消息触发方式用于指示测试消息包的触发方式为自动触发还是手动触发；消息自动消费频率用于指示在测试消息包的触发方式为自动触发的情况下，测试消息包的下发频率；消息下发失败策略用于指示在测试消息包下发失败时，对测试消息包的处理策略。

在一可实施方式中，测试人员可以根据目标测试场景中的被测业务端的地址，首先确定消息消费地址，若在此目标测试场景中需要对测试过程进行分析，且无法确定分析的时间，那么就可以将消息触发方式配置为手动触发，即测试人员可以手动控制测试消息包的消费频率；若在此目标测试场景中能够确定测试的时间，则可以将消息触发方式配置为自动触发，并将消息自动消费频率设置在合适的取值，从而控制测试消息包的消费频率；为了方便测试流程，可以将消息下发失败策略设置为消息下发失败后重试，重试的次数可以根据实际情况设定，也可以将消息下发失败策略设置为消息下发失败后不重试。

在本公开第五实施例中，消息消费策略可以包括：消息消费地址、消息触发方式、消息自动消费频率和消息下发失败策略。本实施例可以根据实际情况确定测试消息包的下发方式，简便了测试流程，方便测试人员进行测试。

图5是根据本公开第六实施例的一种测试方法的流程示意图，如图5所示，步骤S104具体包括：

步骤S501，判断消息触发方式是否为自动触发。

步骤S502，消息触发方式为自动触发，根据消息自动消费频率和消息消费地址，自动下发测试消息包至被测业务端。

步骤S503，消息触发方式不为自动触发，获取消息触发指令。

步骤S504，根据消息触发指令和消息消费地址，下发测试消息包至被测业务端。

在本实施例中，首先需要确定消息消费策略中的消息触发方式是否为自动触发，若消息触发方式为自动触发，则根据消息自动消费频率和消息消费地址，自动下发测试消息包至被测业务端；若消息触发方式不为自动触发，则获取消息触发指令，然后根据消息触发指令和消息消费地址，下发测试消息包至被测业务端。

在一可实施方式中，若消息触发方式为自动触发，则获取消息自动消费频率，消息自动消费频率为在自动触发时，测试消息包的下发频率，然后根据消息自动消费频率，将获取的多个测试消息包一一下发至被测业务端；若消息触发方式不为自动触发，则需要测试人员手动触发测试消息包，在获取到测试人员下发的消息触发指令后，再将测试消息包下发至被测业务端。

在本公开第六实施例中，根据消息消费策略，下发测试消息包至被测业务端，可以根据目标测试场景对应的消息消费策略，确定测试消息包的下发方式，简便了测试流程，方便测试人员进行测试。

在本公开第七实施例中，若测试消息包下发失败，则根据消息下发失败策略，对测试消息包进行与消息下发失败策略对应的处理操作。

在一可实施方式中，若消息下发失败策略为消息下发失败后重试两次，则在测试消息包下发失败之后，重新按照消息消费策略下发测试消息包至被测业务端，若下发仍然失败，则继续按照消息消费策略下发测试消息包至被测业务端，若下发仍然失败，则不继续重试；消息下发失败策略也可以为消息下发失败后不重试。具体地，消息下发失败策略还可以为其他处理策略，本公开不对其进行限定。

在本公开第七实施例中，在测试消息包下发失败时，根据消息下发失败策略，对测试消息包进行与消息下发失败策略对应的处理操作，考虑了消息下发失败之后对测试消息包的处理，有利于测试的顺利进行。

图6是根据本公开第八实施例的一种测试装置的结构示意图，如图6所示，该装置具体包括：

第一获取模块60，用于获取初始消息包，初始消息包包含目标测试场景所需的测试数据；重构模块61，用于对初始消息包进行重构，得到测试消息包；第二获取模块62，用于获取测试消息包对应的消息消费策略；下发模块63，用于根据消息消费策略，下发测试消息包至被测业务端。

在一可实施方式中，第一获取模块60包括：抓取子模块，用于在线上日志中抓取目标测试场景对应的消费接口的初始消息包列表；去重子模块，用于对初始消息包列表进行去重操作，得到初始消息包。

在一可实施方式中，第一获取模块60还包括：第三获取模块，用于根据搭建的线下环境中间件，获取上游业务端配合下发的初始消息包。

在一可实施方式中，重构模块61包括：解析子模块，用于对初始消息包进行解析，得到初始消息包的消息体；替换子模块，用于将消息体中目标测试场景需要监听的字段值替换为对应的变量，得到消息体模板；创建子模块，用于根据目标测试场景和变量，创建测试数据列表；构造子模块，用于根据消息体模板和测试数据列表，构造得到测试消息包。

在一可实施方式中，消息消费策略包括：消息消费地址、消息触发方式、消息自动消费频率和消息下发失败策略；消息消费地址用于指示被测业务端的地址；消息触发方式用于指示测试消息包的触发方式为自动触发还是手动触发；消息自动消费频率用于指示在测试消息包的触发方式为自动触发的情况下，测试消息包的下发频率；消息下发失败策略用于指示在测试消息包下发失败时，对测试消息包的处理策略。

在一可实施方式中，下发模块63包括：判断子模块，用于判断消息触发方式是否为自动触发；第一下发子模块，用于消息触发方式为自动触发，根据消息自动消费频率和消息消费地址，自动下发测试消息包至被测业务端；获取子模块，用于消息触发方式不为自动触发，获取消息触发指令；第二下发子模块，用于根据消息触发指令和消息消费地址，下发测试消息包至被测业务端。

在一可实施方式中，该装置还包括：处理模块，用于若测试消息包下发失败，则根据消息下发失败策略，对测试消息包进行与消息下发失败策略对应的处理操作。

本公开的技术方案中，所涉及的用户个人信息的获取，存储和应用等，均符合相关法律法规的规定，且不违背公序良俗。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

图7示出了可以用来实施本公开的实施例的示例电子设备700的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图7所示，设备700包括计算单元701，其可以根据存储在只读存储器(ROM)702中的计算机程序或者从存储单元708加载到随机访问存储器(RAM)703中的计算机程序，来执行各种适当的动作和处理。在RAM 703中，还可存储设备700操作所需的各种程序和数据。计算单元701、ROM 702以及RAM 703通过总线704彼此相连。输入/输出(I/O)接口705也连接至总线704。

设备700中的多个部件连接至I/O接口705，包括：输入单元706，例如键盘、鼠标等；输出单元707，例如各种类型的显示器、扬声器等；存储单元708，例如磁盘、光盘等；以及通信单元709，例如网卡、调制解调器、无线通信收发机等。通信单元709允许设备700通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元701可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元701的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元701执行上文所描述的各个方法和处理，例如一种测试方法。例如，在一些实施例中，一种测试方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元708。在一些实施例中，计算机程序的部分或者全部可以经由ROM 702和/或通信单元709而被载入和/或安装到设备700上。当计算机程序加载到RAM 703并由计算单元701执行时，可以执行上文描述的一种测试方法的一个或多个步骤。备选地，在其他实施例中，计算单元701可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行一种测试方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以为分布式系统的服务器，或者是结合了区块链的服务器。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (11)

1.一种测试方法，包括：

获取初始消息包，所述初始消息包包含目标测试场景所需的测试数据；

对所述初始消息包进行重构，得到测试消息包；

获取所述测试消息包对应的消息消费策略；

根据所述消息消费策略，下发所述测试消息包至被测业务端。

2.根据权利要求1所述的方法，其中，所述获取初始消息包，包括：

在线上日志中抓取目标测试场景对应的消费接口的初始消息包列表；

对所述初始消息包列表进行去重操作，得到所述初始消息包。

3.根据权利要求1所述的方法，其中，所述获取初始消息包，还包括：

根据搭建的线下环境中间件，获取上游业务端配合下发的所述初始消息包。

4.根据权利要求1所述的方法，其中，所述对初始消息包进行重构，得到测试消息包，包括：

对所述初始消息包进行解析，得到所述初始消息包的消息体；

将所述消息体中目标测试场景需要监听的字段值替换为对应的变量，得到消息体模板；

根据所述目标测试场景和变量，创建测试数据列表；

根据所述消息体模板和测试数据列表，构造得到所述测试消息包。

5.根据权利要求1至4任一项所述的方法，其中，所述消息消费策略包括：消息消费地址、消息触发方式、消息自动消费频率和消息下发失败策略；

所述消息消费地址用于指示所述被测业务端的地址；

所述消息触发方式用于指示所述测试消息包的触发方式为自动触发还是手动触发；

所述消息自动消费频率用于指示在所述测试消息包的触发方式为自动触发的情况下，所述测试消息包的下发频率；

所述消息下发失败策略用于指示在所述测试消息包下发失败时，对所述测试消息包的处理策略。

6.根据权利要求5所述的方法，其中，所述根据消息消费策略，下发所述测试消息包至被测业务端，包括：

判断所述消息触发方式是否为自动触发；

所述消息触发方式为自动触发，根据所述消息自动消费频率和消息消费地址，自动下发所述测试消息包至所述被测业务端；

所述消息触发方式不为自动触发，获取消息触发指令；

根据所述消息触发指令和消息消费地址，下发所述测试消息包至所述被测业务端。

7.根据权利要求6所述的方法，其中，所述方法还包括：

若所述测试消息包下发失败，则根据所述消息下发失败策略，对所述测试消息包进行与所述消息下发失败策略对应的处理操作。

8.一种测试装置，包括：

第一获取模块，获取初始消息包，所述初始消息包包含目标测试场景所需的测试数据；

重构模块，用于对所述初始消息包进行重构，得到测试消息包；

第二获取模块，用于获取所述测试消息包对应的消息消费策略；

下发模块，用于根据所述消息消费策略，下发所述测试消息包至被测业务端。

9.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1－7中任一项所述的方法。

10.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据权利要求1－7中任一项所述的方法。

11.一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据权利要求1－7中任一项所述的方法。

Images