CN114900569B - 一种测试脚本的获取方法及装置 - Google Patents

Abstract

本申请公开了一种测试脚本的获取方法及装置，可应用于分布式领域或金融领域。该方法包括：运行应用程序对应的第一测试脚本；基于第一测试脚本，获取应用程序对应的多个服务的报文信息；对报文信息进行分析，得到多个服务对应的第二测试脚本；第二测试脚本用于对多个服务进行测试。由于第一测试脚本是针对集中式架构下的应用程序的测试脚本，当应用程序划分为多个服务时，对外接口和整体功能保持不变，因此，可以借助第一测试脚本获取多个服务对应的第二测试脚本，而无需测试人员重新手动编写测试脚本，从而可以大大减轻测试人员的工作压力，提高测试人员的工作效率。

Description

一种测试脚本的获取方法及装置

技术领域

本申请涉及分布式技术领域，尤其涉及一种测试脚本的获取方法及装置。

背景技术

近年来，随着大数据、云计算等新兴技术的发展，传统的集中式架构正逐步向分布式架构迁移，技术架构下的服务粒度也随之变细，进而衍生出了微服务架构。微服务架构可以将单个应用程序划分为多个较小的服务，这些服务通过协调配合来实现该应用程序对应的业务功能。

对于应用程序的自动化测试来说，在传统的集中式架构中，测试人员需要编写测试脚本来验证整个应用程序的功能以及该应用程序的接口与外部接口之间的集成。而当集中式架构转型为微服务架构时，由于应用程序被划分为多个服务，因此，需要测试人员编写测试脚本来验证每个服务的功能以及每个服务的接口之间的集成，这会导致测试脚本编写的复杂度较高，加重测试人员的工作压力。

发明内容

本申请实施例提供了一种测试脚本的获取方法及装置，以在微服务架构下自动生成测试脚本，减轻测试人员的负担，提高测试人员的工作效率。

第一方面，本申请实施例提供了一种测试脚本的获取方法，包括：

运行应用程序对应的第一测试脚本；

基于所述第一测试脚本，获取所述应用程序对应的多个服务的报文信息；

对所述报文信息进行分析，得到所述多个服务对应的第二测试脚本；所述第二测试脚本用于对所述多个服务进行测试。

可选地，所述对所述报文信息进行分析，得到所述多个服务对应的第二测试脚本，包括：

从所述报文信息中确定报文字段、所述报文字段的标识信息和所述报文字段对应的值；

基于所述多个服务，并根据所述报文字段、所述报文字段的标识信息和所述报文字段对应的值，构建脚本配置信息；

基于所述脚本配置信息获得所述第二测试脚本。

可选地，所述基于所述第一测试脚本，获取所述应用程序对应的多个服务的报文信息，包括：

对所述第一测试脚本运行时的运行数据进行拦截，得到所述应用程序对应的基础报文信息；所述基础报文信息的类型包括基础请求报文和基础返回报文；

根据所述多个服务对所述基础请求报文和所述基础返回报文进行拆解，分别得到所述多个服务对应的请求报文和返回报文；

基于所述多个服务，并根据所述请求报文和所述返回报文，构建用于表征所述报文信息的报文表。

可选地，在所述运行应用程序对应的第一测试脚本之前，所述获取方法还包括：

在所述多个服务中注入用于对所述运行数据进行拦截的服务***，并启动所述服务***。

可选地，所述报文信息的类型包括返回报文；所述方法还包括：

利用所述第二测试脚本对所述返回报文进行校验，得到校验结果；

在所述校验结果表示返回报文异常时，发出提醒。

可选地，所述方法还包括：

响应于用户触发的服务变更指令，获取服务变更信息；

基于所述服务变更信息对所述第二测试脚本进行更新。

第二方面，本申请实施例提供了一种测试脚本的获取装置，包括：

脚本运行模块，用于运行应用程序对应的第一测试脚本；

信息获取模块，用于根据所述第一测试脚本，获取所述应用程序对应的多个服务的报文信息；

信息分析模块，用于对所述报文信息进行分析，得到所述多个服务对应的第二测试脚本；所述第二测试脚本用于对所述多个服务进行测试。

可选地，所述信息分析模块具体包括：

第一分析模块，用于从所述报文信息中确定报文字段、所述报文字段的标识信息和所述报文字段对应的值；

第二分析模块，基于所述多个服务，并根据所述报文字段、所述报文字段的标识信息和所述报文字段对应的值，构建脚本配置信息；

第三分析模块，用于基于所述脚本配置信息获得所述第二测试脚本。

可选地，所述信息获取模块具体包括：

第一获取模块，用于对所述第一测试脚本运行时的运行数据进行拦截，得到所述应用程序对应的基础报文信息；所述基础报文信息的类型包括基础请求报文和基础返回报文；

第二获取模块，用于根据所述多个服务对所述基础请求报文和所述基础返回报文进行拆解，分别得到所述多个服务对应的请求报文和返回报文；

第三获取模块，用于基于所述多个服务，并根据所述请求报文和所述返回报文，构建用于表征所述报文信息的报文表。

可选地，所述测试脚本的获取装置还包括：

服务***控制模块，用于在所述多个服务中注入用于对所述运行数据进行拦截的服务***，并启动所述服务***。

从以上技术方案可以看出，本申请实施例具有以下优点：

本申请实施例中，在运行应用程序对应的第一测试脚本时，可以根据第一测试脚本，获取应用程序对应的多个服务的报文信息，并进一步对报文信息进行分析，得到多个服务对应的第二测试脚本，以便利用第二测试脚本对多个服务进行测试。由于第一测试脚本是针对集中式架构下的应用程序的测试脚本，当应用程序划分为多个服务时，对外接口和整体功能保持不变，因此，可以借助第一测试脚本获取多个服务对应的第二测试脚本，而无需测试人员重新手动编写测试脚本，从而可以大大减轻测试人员的工作压力，提高测试人员的工作效率。

附图说明

图1为本申请实施例提供的一种测试脚本的获取方法的流程图；

图2为本申请实施例提供的另一种测试脚本的获取方法的流程图；

图3为本申请实施例提供的一种测试脚本的获取装置的结构示意图。

具体实施方式

正如前文所述，发明人在针对应用程序测试脚本的研究中发现：对于应用程序的自动化测试来说，在传统的集中式架构中，测试人员需要编写测试脚本来验证整个应用程序的功能以及该应用程序的接口与外部接口之间的集成。而当集中式架构转型为微服务架构时，由于应用程序被划分为多个服务，因此，需要测试人员编写测试脚本来验证每个服务的功能以及每个服务的接口之间的集成，这会导致测试脚本编写的复杂度较高，加重测试人员的工作压力。

为了解决上述问题，本申请实施例提供了一种测试脚本的获取方法，该方法包括：在运行应用程序对应的第一测试脚本时，可以根据第一测试脚本，获取应用程序对应的多个服务的报文信息，并进一步对报文信息进行分析，得到多个服务对应的第二测试脚本，以便利用第二测试脚本对多个服务进行测试。

由于第一测试脚本是针对集中式架构下的应用程序的测试脚本，当应用程序划分为多个服务时，对外接口和整体功能保持不变，因此，可以借助第一测试脚本获取多个服务对应的第二测试脚本，而无需测试人员重新手动编写测试脚本，从而可以大大减轻测试人员的工作压力，提高测试人员的工作效率。

需要说明的是，本发明提供的数据导入方法及装置可用于人工智能领域、区块链领域、分布式领域、云计算领域、大数据领域、物联网领域、移动互联领域、网络安全领域、芯片领域、虚拟现实领域、增强现实领域、全息技术领域、量子计算领域、量子通信领域、量子测量领域、数字孪生领域或金融领域。上述仅为示例，并不对本发明提供的数据导入方法及装置的应用领域进行限定。

为了使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

图1为本申请实施例提供的一种测试脚本的获取方法的流程图。结合图1所示，本申请实施例提供的测试脚本的获取方法，可以包括：

S101：运行应用程序对应的第一测试脚本。

应用程序对应的第一测试脚本，是指在传统的集中式架构中用于对应用程序进行测试的测试脚本。具体来说，第一测试脚本可以按照应用程序对应的预设业务需求，模拟将前端网页的请求报文发往后端***，并验证后端***的返回报文的准确性。以存款场景为例，在集中式架构中，第一测试脚本测试应用程序时可以模拟如下交易路径：将账户A、存款金额B，存款货币类型C等信息作为请求报文发送至银行核心***，并校验银行核心***反馈的返回报文是否包括用于表示存款交易成功的信息。

S102：基于第一测试脚本，获取应用程序对应的多个服务的报文信息。

应用程序对应的多个服务，是指在集中式架构向微服务架构转型时，应用程序可以被划分为多个对应的服务，这些服务协调工作，完成该应用程序原有的完整功能。报文信息是指多个服务之间所传输的信息，报文信息的类型具体可以包括请求报文和返回报文。仍以上述存款场景为例，在微服务架构中，银行核心***对应的多个服务可以包括网关服务、总控服务、账户查询服务和记账服务，则存款场景的完整交易路径可以体现为：网关服务将账户A、存款金额B和存款货币类型C作为请求报文发送至总控服务；总控服务将账户A作为新的请求报文发送至账户查询服务，账户查询服务将用于表示账户A存在的返回报文反馈至总控服务；总控服务再将账户A、存款金额B和存款货币类型C作为新的请求报文发送至记账服务，记账服务将用于表示存款成功的返回报文反馈至总控服务；总控服务再根据账户查询服务反馈的返回报文、记账服务反馈的返回报文，向网关服务反馈用于表示交易成功的返回报文，并由网管服务向交易发起方反馈该用于表示交易成功的返回报文。

另外，本申请实施例可以不限定应用程序对应的多个服务的报文信息的获取方式，为了便于理解，下面结合一种可能的实施方式进行说明。

在一种可能的实施方式下，S102可以包括：对第一测试脚本运行时的运行数据进行拦截，得到应用程序对应的基础报文信息；基础报文信息的类型包括基础请求报文和基础返回报文；根据多个服务对基础请求报文和基础返回报文进行拆解，分别得到多个服务对应的请求报文和返回报文；基于多个服务，并根据请求报文和返回报文，构建用于表征报文信息的报文表。其中，基础报文信息指的是采用第一测试脚本对集中式架构的应用程序进行测试时的报文信息。仍以上述存款场景为例，在集中式架构中，采用第一测试脚本测试应用程序时，基础请求报文可以包括账户A、存款金额B和存款货币类型C；基础返回报文可以包括用于表示存款交易成功的信息。由于第一测试脚本是针对集中式架构下的应用程序的测试脚本，当应用程序划分为多个服务时，对外接口和整体功能保持不变，因此，通过拦截第一测试脚本运行时的运行数据，便可对运行数据进行分析处理而得到多个服务对应的第二测试脚本，实现借助第一测试脚本得到第二测试脚本，而无需测试人员重新手动编写测试脚本，从而可以大大减轻测试人员的工作压力，提高测试人员的工作效率。

对应地，为了实现对运行数据的拦截，本申请实施例可以在运行应用程序对应的第一测试脚本之前，先在多个服务中注入用于对运行数据进行拦截的服务***，并启动该服务***，以利用该服务***拦截并记录运行数据。其中，服务***可以预先由Java(一种计算机编程语言)程序开发获得。服务***可以利用Spring框架(一种开源Java应用程序框架)的AOP(Aspect Oriented Programming，面向切面编程)切面技术，注入在多个服务的控制层以实现运行数据的拦截。

另外，对于报文表的表示形式，本申请实施例可不做具体限定，为了便于理解，下面以表1的形式对报文表进行说明。

表1

其中，多个服务各自的报文信息可以对应于同一报文表，也就是多个服务各自的报文信息表示于同一报文表，或者，多个服务各自的报文信息可以对应于不同的报文表，也就是多个服务各自的报文信息分别表示于各自的报文表，本申请实施例对此可不做具体限定。

S103：对报文信息进行分析，得到多个服务对应的第二测试脚本。

第二测试脚本是指对应用***拆分成的多个服务进行测试的测试脚本。仍以上述存款场景为例，在微服务架构中，第二测试脚本测试多个应用程序时可以模拟如下交易路径：将账户A、存款金额B和存款货币类型C作为网关服务的请求报文发送至总控服务；将账户A作为总控服务的请求报文发送至账户查询服务，校验账户查询服务反馈的返回报文中是否包括用于表示账户A存在的信息；将账户A、存款金额B和存款货币类型C作为总控服务的新的请求报文发送至记账服务，校验记账服务反馈的返回报文中是否包括用于表示存款成功的信息；将根据账户查询服务反馈的返回报文，以及记账服务反馈的返回报文所确定的报文作为总控服务的返回报文反馈至网关服务，校验总控服务反馈的返回报文中是否包括用于表示交易成功的信息。

对于第二测试脚本的获取过程，本申请实施例可不做具体限定。为了便于理解，下面结合一种可能的实施方式进行说明。

在一种可能的实施方式下，S103具体可以包括：从报文信息中确定报文字段、报文字段的标识信息和报文字段对应的值；基于多个服务，并根据报文字段、报文字段的标识信息和报文字段对应的值，构建脚本配置信息；基于脚本配置信息获得第二测试脚本。对于脚本配置信息的表示形式，本申请实施例可不做具体限定，为了便于理解，下面结合以表2的形式对脚本配置信息进行说明。

表2

其中，从同一服务的请求报文和返回报文中分别确定出的报文字段、报文字段的标识信息和报文字段对应的值，可以表示于同一表格，也可以分别表示于不同表格，本申请实施例对此不做具体限定。此外，从多个服务各自的请求报文和返回报文中分别确定的报文字段、报文字段的标识信息和报文字段对应的值，亦可表示于同一表格，或者，分别表示于不同表格，本申请实施例对此亦不做具体限定。

基于以上S101-S103的相关内容可知，在本申请实施例中，在运行应用程序对应的第一测试脚本时，可以根据第一测试脚本，获取应用程序对应的多个服务的报文信息，并进一步对报文信息进行分析，得到多个服务对应的第二测试脚本，以便利用第二测试脚本对多个服务进行测试。由于第一测试脚本是针对集中式架构下的应用程序的测试脚本，当应用程序划分为多个服务时，对外接口和整体功能保持不变，因此，可以借助第一测试脚本获取多个服务对应的第二测试脚本，而无需测试人员重新手动编写测试脚本，从而可以大大减轻测试人员的工作压力，提高测试人员的工作效率。

另外，为了测试服务是否符合预设业务需求，本申请实施例可以利用第二测试脚本对多个服务的报文信息进行校验，以判断服务是否符合预设业务需求。进一步地，为了提高测试效率，还可以只对返回报文进行校验，以判断服务是否准确完成，进而在提高测试效率的同时，提高服务的有效性。具体来说，可以利用第二测试脚本对返回报文进行校验，得到校验结果；在校验结果表示返回报文异常时，发出提醒。这里，返回报文异常可以体现为返回报文中返回字段对应的值与预设值不符。另外，本申请实施例可以通过多种实现方式发出提醒，下面举例说明。

作为一种示例，如果校验结果可以上传至云端服务器，则可以通过云端服务器下发指令的方式发出提醒。例如，云端服务器可以和测试人员关联的终端设备通信连接，以将校验结果和/或提醒信息发送给测试人员。

作为另一种示例，如果微服务架构搭载于配置有信息提醒装置的终端设备，则可以通过信息提醒装置发出提醒。例如，信息提醒装置可以为发光装置，通过发光装置亮起或闪烁等方式发出提醒。或者，信息提醒装置可以为发声装置，通过发声装置发出提示音的方式发出提醒。其中，提示音可以是测试人员预先设置的响铃音效，也可以是语音播报该异常的返回报文，本申请实施例对此可不做具体限定。

上述终端设备，例如为移动设备、计算机等，或其任意组合。在一些实施例中，移动设备可以包括手机、可穿戴设备、平板电脑、虚拟现实设备等，或其任意组合。

为了扩展第二测试脚本的可用性，提高测试脚本的获取方法的智能化程度，本申请实施例还可以提供另一种测试脚本的获取方法。下面分别结合实施例和附图，对该测试脚本的获取方法进行描述。

图2为本申请实施例提供的另一种测试脚本的获取方法的流程图。结合图2所示，本申请实施例提供的测试脚本的获取方法，可以包括：

S201：运行应用程序对应的第一测试脚本。

S202：基于第一测试脚本，获取应用程序对应的多个服务的报文信息。

S203：对报文信息进行分析，得到多个服务对应的第二测试脚本。

S204：响应于用户触发的服务变更指令，获取服务变更信息。

服务变更指令是指用户，也就是上文所说的测试人员基于业务的调整需求所触发的指令。对此，本申请实施例可不具体限定服务变更指令的触发方式。例如，可以是用户通过点击服务变更信息对应的控件触发服务变更指令，也可以是用户通过打开或更新服务变更信息的方式触发服务变更指令，还可以是用户预先设置的在预设时间点触发服务变更指令。

S205：基于服务变更信息对第二测试脚本进行更新。

这里，对第二测试脚本进行更新，可以体现为对上述实施例中的脚本配置信息进行更新，以覆盖原有的脚本配置信息，也可以体现为增加新的脚本配置信息，而保留原有的脚本配置信息。

另外，在后续利用更新后的第二测试脚本对多个服务进行测试时，可以利用更新后的第二测试脚本对全部服务进行测试，也可以利用更新后的第二测试脚本中与更新的服务对应的脚本，对该更新的服务进行测试，从而达到快速测试的效果。

基于上述实施例提供的测试脚本的获取方法，本申请实施例还提供了一种测试脚本的获取装置。下面分别结合实施例和附图，对该测试脚本的获取装置进行描述。

图3为本申请实施例提供的一种测试脚本的获取装置的结构示意图。结合图3所示，本申请实施例提供的测试脚本的获取装置300，可以包括：

脚本运行模块301，用于运行应用程序对应的第一测试脚本；

信息获取模块302，用于根据第一测试脚本，获取应用程序对应的多个服务的报文信息；

信息分析模块303，用于对报文信息进行分析，得到多个服务对应的第二测试脚本；第二测试脚本用于对多个服务进行测试。

作为一种实施方式，为了减轻测试人员的工作压力，提高测试人员的工作效率，信息分析模块303具体可以包括：

第一分析模块，用于从报文信息中确定报文字段、报文字段的标识信息和报文字段对应的值；

第二分析模块，基于多个服务，并根据报文字段、报文字段的标识信息和报文字段对应的值，构建脚本配置信息；

第三分析模块，用于基于脚本配置信息获得第二测试脚本。

作为一种实施方式，为了减轻测试人员的工作压力，提高测试人员的工作效率，信息获取模块302具体可以包括：

第一获取模块，用于对第一测试脚本运行时的运行数据进行拦截，得到应用程序对应的基础报文信息；基础报文信息的类型包括基础请求报文和基础返回报文；

第二获取模块，用于根据多个服务对基础请求报文和基础返回报文进行拆解，分别得到多个服务对应的请求报文和返回报文；

第三获取模块，用于基于多个服务，并根据请求报文和返回报文，构建用于表征报文信息的报文表。

作为一种实施方式，为了减轻测试人员的工作压力，提高测试人员的工作效率，该测试脚本的获取装置300还可以包括：

服务***控制模块，用于在多个服务中注入用于对运行数据进行拦截的服务***，并启动服务***。

作为一种实施方式，为了减轻测试人员的工作压力，提高测试人员的工作效率，该测试脚本的获取装置300还可以包括：

校验模块，用于利用第二测试脚本对返回报文进行校验，得到校验结果；

提醒模块，用于在校验结果表示返回报文异常时，发出提醒。

作为一种实施方式，为了减轻测试人员的工作压力，提高测试人员的工作效率，该测试脚本的获取装置300还可以包括：

服务变更信息获取模块，用于响应于用户触发的服务变更指令，获取服务变更信息；

更新模块，用于基于服务变更信息对第二测试脚本进行更新。

以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (6)

1.一种测试脚本的获取方法，其特征在于，包括：

运行应用程序对应的第一测试脚本；

基于所述第一测试脚本，获取所述应用程序对应的多个服务的报文信息；

对所述报文信息进行分析，得到所述多个服务对应的第二测试脚本；所述第二测试脚本用于对所述多个服务进行测试；

其中，所述对所述报文信息进行分析，得到所述多个服务对应的第二测试脚本，包括：

从所述报文信息中确定报文字段、所述报文字段的标识信息和所述报文字段对应的值；

基于所述多个服务，并根据所述报文字段、所述报文字段的标识信息和所述报文字段对应的值，构建脚本配置信息；所述脚本配置信息包括所述多个服务关联的标识信息、所述多个服务对应的接口关联的标识信息、所述报文字段、所述报文字段的标识信息和所述报文字段对应的值；

基于所述脚本配置信息获得所述第二测试脚本；

所述基于所述第一测试脚本，获取所述应用程序对应的多个服务的报文信息，包括：

对所述第一测试脚本运行时的运行数据进行拦截，得到所述应用程序对应的基础报文信息；所述基础报文信息的类型包括基础请求报文和基础返回报文；

根据所述多个服务对所述基础请求报文和所述基础返回报文进行拆解，分别得到所述多个服务对应的请求报文和返回报文；

基于所述多个服务，并根据所述请求报文和所述返回报文，构建用于表征所述报文信息的报文表。

2.根据权利要求1所述的方法，其特征在于，在所述运行应用程序对应的第一测试脚本之前，所述获取方法还包括：

在所述多个服务中注入用于对所述运行数据进行拦截的服务***，并启动所述服务***。

3.根据权利要求1或2所述的方法，其特征在于，所述报文信息的类型包括返回报文；所述方法还包括：

利用所述第二测试脚本对所述返回报文进行校验，得到校验结果；

在所述校验结果表示返回报文异常时，发出提醒。

4.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：

响应于用户触发的服务变更指令，获取服务变更信息；

基于所述服务变更信息对所述第二测试脚本进行更新。

5.一种测试脚本的获取装置，其特征在于，包括：

脚本运行模块，用于运行应用程序对应的第一测试脚本；

信息获取模块，用于根据所述第一测试脚本，获取所述应用程序对应的多个服务的报文信息；

信息分析模块，用于对所述报文信息进行分析，得到所述多个服务对应的第二测试脚本；所述第二测试脚本用于对所述多个服务进行测试；

其中，所述信息分析模块具体包括：

第一分析模块，用于从所述报文信息中确定报文字段、所述报文字段的标识信息和所述报文字段对应的值；

第二分析模块，基于所述多个服务，并根据所述报文字段、所述报文字段的标识信息和所述报文字段对应的值，构建脚本配置信息；所述脚本配置信息包括所述多个服务关联的标识信息、所述多个服务对应的接口关联的标识信息、所述报文字段、所述报文字段的标识信息和所述报文字段对应的值；

第三分析模块，用于基于所述脚本配置信息获得所述第二测试脚本；

所述信息获取模块具体包括：

第一获取模块，用于对所述第一测试脚本运行时的运行数据进行拦截，得到所述应用程序对应的基础报文信息；所述基础报文信息的类型包括基础请求报文和基础返回报文；

第二获取模块，用于根据所述多个服务对所述基础请求报文和所述基础返回报文进行拆解，分别得到所述多个服务对应的请求报文和返回报文；

第三获取模块，用于基于所述多个服务，并根据所述请求报文和所述返回报文，构建用于表征所述报文信息的报文表。

6.根据权利要求5所述的装置，其特征在于，所述测试脚本的获取装置还包括：

服务***控制模块，用于在所述多个服务中注入用于对所述运行数据进行拦截的服务***，并启动所述服务***。