CN115080449A

CN115080449A - 测试方法、装置、设备、介质和程序产品

Info

Publication number: CN115080449A
Application number: CN202210906024.8A
Authority: CN
Inventors: 罗秉安; 朱乐和; 程灿权; 林芝峰
Original assignee: Industrial and Commercial Bank of China Ltd ICBC
Current assignee: Industrial and Commercial Bank of China Ltd ICBC
Priority date: 2022-07-29
Filing date: 2022-07-29
Publication date: 2022-09-20

Abstract

本公开提供了一种测试方法，涉及测试技术领域，可以应用于金融领域或其他领域。该测试方法包括：对目标事务发起交易测试，目标事务包括多阶段分布式事务；基于混沌工程，在交易测试的过程中注入至少一种故障，以使目标事务在预设阶段发生堵塞；获取在交易测试过程中生成的响应信息；根据响应信息，确定在发生堵塞后执行的第一流程；根据第一流程，确定目标事务的第一测试结果。本公开还提供了一种测试装置、设备、介质和程序产品。

Description

测试方法、装置、设备、介质和程序产品

技术领域

本公开涉及测试技术领域，具体地涉及一种测试方法、装置、电子设备、存储介质和程序产品。

背景技术

事务(transaction)是指由一个或多个资源管理操作构成的一个操作序列。分布式事务是指操作序列中的操作涉及多个数据库(database，DB)的事务。

在分布式事务正式上线前，需要对分布式事务进行测试。目前，主要通过对事件状态进行修改以模拟异常，继而发起测试。但是，分布式事务的结构和运行环境复杂，导致某种异常的原因多种多样，例如，除已知的事件状态错误导致异常A外，还有可能因为运行环境的不稳定导致异常A。因此，仅通过上述修改事件状态的方式模拟异常具有局限性，测试覆盖率较低。

发明内容

鉴于上述问题，本公开提供了一种测试方法、装置、电子设备、存储介质和程序产品。

根据本公开的第一个方面，提供了一种测试方法，其中，包括：

对目标事务发起交易测试，所述目标事务包括多阶段分布式事务；

基于混沌工程，在所述交易测试的过程中注入至少一种故障，以使所述目标事务在预设阶段发生堵塞；

获取在所述交易测试过程中生成的响应信息；

根据所述响应信息，确定在发生所述堵塞后执行的第一流程；

根据所述第一流程，确定所述目标事务的第一测试结果。

根据本公开的实施例，所述对目标事务发起交易测试，包括：

对所述目标事务的输入和输出进行解析，以得到业务数据字段、非业务数据字段以及与所述业务数据字段相匹配的第一赋值；

对非业务数据字段的至少部分进行自适应赋值，以得到第二赋值；

根据所述业务数据字段、所述非业务数据字段、所述第一赋值和所述第二赋值，生成测试案例；

根据所述测试案例，对所述目标事务发起交易测试。

根据本公开的实施例，所述测试方法还包括：

获取测试脚本，所述测试脚本包括多个测试流程；

所述根据所述测试案例，对所述目标事务发起交易测试，包括：

根据所述测试脚本的多个所述测试流程，从所述测试案例中加载数据，以对所述目标事务发起交易测试；

其中，多个测试流程包括数据预处理流程、环境备份流程、交易测试流程和环境恢复流程。

根据本公开的实施例，所述预设阶段包括多阶段分布式事务的数据准备阶段，所述基于混沌工程，在所述交易测试的过程中注入至少一种故障，以使所述目标事务在预设阶段发生堵塞，包括：

基于混沌工程，在所述交易测试的过程中注入至少一种延时故障，以使所述目标事务在所述数据准备阶段发生堵塞；

所述根据所述响应信息，确定在发生所述堵塞后执行的第一流程，包括：

根据所述响应信息，利用断言分析，确定所述第一流程是否包括执行空回滚的流程。

根据本公开的实施例，所述基于混沌工程，在所述交易测试的过程中注入至少一种故障，以使所述目标事务在预设阶段发生堵塞，还包括：

基于混沌工程，在执行所述空回滚流程之后，解除所述堵塞；

根据所述响应信息，利用断言分析，确定所述第一流程是否包括防悬挂流程。

根据本公开的实施例，根据所述第一流程，确定所述目标事务的第一测试结果，包括：

当所述第一流程包括所述空回滚流程和所述防悬挂流程时，确定所述第一测试结果为测试通过。

根据本公开的实施例，所述延时故障包括网络延时故障和/或SQL延时故障。

根据本公开的实施例，所述测试方法还包括：

在所述交易测试过程中，基于混沌工程，对用于执行所述目标事务的服务器注入至少一种故障，以使所述服务器中用于处理所述目标事务的容器出现异常；

根据所述响应信息，确定在容器出现异常后执行的第二流程；

根据所述第二流程，确定所述目标事务的第二测试结果。

根据本公开的实施例，在所述交易测试过程中，基于混沌工程，对用于执行所述目标事务的服务器注入至少一种故障，以使所述服务器中用于处理所述目标事务的容器出现异常，包括：

基于混沌工程，对用于执行所述目标事务的服务器注入至少一种资源故障，以使所述服务器中用于处理所述目标事务的容器出现异常，所述资源故障包括：处理器故障、内存故障和磁盘故障中的至少一者。

根据本公开的实施例，所述测试方法还包括：

当所述第一测试结果和所述第二测试结果均为测试通过时，根据所述响应信息，利用断言分析，确定所述目标事务在每个阶段的处理结果；

当每个阶段的处理结果均满足预期时，确定第三测试结果为测试通过。

本公开的第二方面提供了一种测试装置，其中，包括：

测试模块，用于对目标事务发起交易测试，所述目标事务包括多阶段分布式事务；

混沌工程模块，用于基于混沌工程，在所述交易测试的过程中注入至少一种故障，以使所述目标事务在预设阶段发生堵塞；

获取模块，用于获取在所述交易测试过程中生成的响应信息；

第一处理模块，用于根据所述响应信息，确定在发生所述堵塞后执行的第一流程；

第二处理模块，用于根据所述第一流程，确定所述目标事务的第一测试结果

本公开的第三方面提供了一种电子设备，包括：一个或多个处理器；存储器，用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得一个或多个处理器执行上述的测试方法。

本公开的第四方面还提供了一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器执行上述的测试方法。

本公开的第五方面还提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述的测试方法。

上述一个或多个实施例具有如下优点或益效果：

在本公开实施例中，在交易测试过程中，基于混沌工程能够通过注入各种故障的方式模拟异常(也即“目标事务在预设阶段发生堵塞”)，较于传统方案仅通过修改特定数据(预期的测试条件)模拟异常的方案而言，本公开实施例在结合混沌工程后，可以使得测试案例大幅增加，从而涵盖各种可能的情况，提高测试覆盖率。

更重要的是，基于混沌工程，能够模拟“目标事务在预设阶段发生堵塞”这一异常，进而制造通过传统手段(例如修改事件状态)难以模拟的空回滚和防悬挂等场景。通过获取响应信息，分析发生空回滚和防悬挂等场景之后的处理流程，能够对目标事务在空回滚和防悬挂场景下的响应进行测试，从而增加测试维度。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述内容以及其他目的、特征和优点将更为清楚，在附图中：

图1示意性示出了根据本公开实施例的测试方法、装置、电子设备、存储介质和程序产品的应用场景图；

图2示意性示出了根据本公开实施例的测试方法的流程图之一；

图3示意性示出了根据本公开实施例的发起交易测试的流程图；

图4示意性示出了根据本公开实施例的注入故障的流程图；

图5示意性示出了根据本公开实施例的断言分析的流程图；

图6示意性示出了根据本公开实施例的发起交易测试的流程图之二；

图7示意性示出了根据本公开实施例的发起交易测试的流程图之三；

图8示意性示出了根据本公开实施例的测试装置的结构框图；

图9示意性示出了根据本公开实施例的适于实现测试方法的电子设备的方框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的***”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的***等)。

需要说明的是，本公开的实施例提供的测试方法、装置、电子设备、存储介质和程序产品涉及测试技术领域。本公开的实施例提供的测试方法、装置、电子设备、存储介质和程序产品可应用于金融领域或者除金融领域之外的任意领域，例如，本公开的实施例提供的测试方法、装置、电子设备、存储介质和程序产品可应用于金融领域中的分布式事务的测试业务中。本公开对测试方法、装置、电子设备、存储介质和程序产品的应用领域不做限定。

在本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供、公开和应用等处理，均符合相关法律法规的规定，采取了必要保密措施，且不违背公序良俗。

本公开的实施例提供了一种测试方法，其中，包括：对目标事务发起交易测试，目标事务包括多阶段分布式事务；基于混沌工程，在交易测试的过程中注入至少一种故障，以使目标事务在预设阶段发生堵塞；获取在交易测试过程中生成的响应信息；根据响应信息，确定在发生堵塞后执行的第一流程；根据第一流程，确定目标事务的第一测试结果。

图1示意性示出了根据本公开实施例的测试方法、装置、电子设备、存储介质和程序产品的应用场景图，如图1所示，根据该实施例的应用场景100可以包括终端设备101、102、103、网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对用户利用终端设备101、102、103所浏览的网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的用户请求等数据进行分析等处理，并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备。

需要说明的是，本公开实施例所提供的测试方法一般可以由服务器105执行。相应地，本公开实施例所提供的测试装置一般可以设置于服务器105中。本公开实施例所提供的测试方法也可以由不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群执行。相应地，本公开实施例所提供的测试装置也可以设置于不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

以下将基于图1描述的场景，通过图2～图7对公开实施例的测试方法进行详细描述。

图2示意性示出了根据本公开实施例的测试方法的流程图之一，如图2所示，该实施例的测试方法包括步骤S210～步骤S250。

需要说明的是，虽然图2中的各步骤按照箭头的指示依次显示，但是，这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，图中的至少部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替的执行。

在步骤S210，对目标事务发起交易测试，目标事务包括多阶段分布式事务。

在本公开实施例中，多阶段分布式事务可以包括二阶段分布式事务，二阶段分布式事务可以通过TCC(Try-Confirm-Cancel)服务实现。为描述清楚，下文以二阶段分布式事务作为目标事务为例，对本公开实施例的多阶段分布式事务进行说明，但是，应当理解的是，这并不构成对本公开实施例的中多阶段分布式事务的限制，例如，多阶段分布式事务还可以包括三阶段分布式事务等。

在本公开实施例中，二阶段分布式事务的处理过程包括两个阶段，其中，一阶段包括Try阶段(下文也称为数据准备阶段)，二阶段包括Confirm或Cancel阶段。

在Try阶段：事务协调者向TCC服务发起Try请求，以执行业务检查，预留必须的业务资源，从而保证Try阶段成功完成后，Confirm阶段一定能成功。

在Confirm阶段：事务协调者向TCC服务发起Confirm请求，以执行业务逻辑，在这一阶段，可以不做任何业务检查，只使用Try阶段预留的业务资源。

在Cancel阶段：事务协调者向TCC服务发起Cancel请求，以执行回滚，从而释放Try阶段预留的业务资源。

在本公开实施例中，二阶段分布式事务应能满足多种原则，例如，允许空回滚和防悬挂等。

示例性地，在一阶段，可能由于网络延迟等原因导致Try请求被堵塞进而引发超时处理，此时，事务协调者触发二阶段的Cancel请求，而这使得TCC服务在接收到Try请求之前接收到Cancel请求，这种场景可以被称为空回滚。二阶段分布式事务应能允许空回滚的执行。

示例性地，在发生空回滚后，当TCC服务接收到被堵塞的Try请求时，二阶段分布式事务应能拒绝Try请求的执行，这种场景可以被称为防悬挂。

在步骤S220，基于混沌工程，在交易测试的过程中注入至少一种故障，以使目标事务在预设阶段发生堵塞。

在本公开实施例中，混沌工程是一种提高技术架构弹性能力的复杂技术手段，可以通过主动制造故障，测试***在各种压力下的行为，识别并修复故障问题，避免造成严重后果。其中ChaosBlade是一款分布式***提升容错性和可恢复性的混沌工程工具，在本公开实施例中，可以通过ChaosBlade实现故障注入。

在本公开实施例中，预设阶段可以包括二阶段事务的数据准备阶段，也即上文提到的Try阶段。基于混沌工程，可以从多种故障中随机抽取一种或多种进行注入，以使二阶段事务在Try阶段发生堵塞。例如，基于混沌工程，可以从网络延时故障和SQL延时故障等多种故障中，随机抽取一种或多种进行注入。

在上述过程中，基于混沌工程，可以通过随机注入故障的方式，使二阶段事务在Try阶段发生堵塞，从而制造空回滚场景和防悬挂场景。

在步骤S230，获取在交易测试过程中生成的响应信息。

在步骤S240，根据响应信息，确定在发生堵塞后执行的第一流程。

在本公开实施例中，响应信息可以包括在交易测试过程中生成的响应报文等，响应报文中可以记录有能够表征在交易测试过程中发生的关键事件的信息，例如，特定错误码、交易失败记录等等。进而，根据这些信息，能够确定出在交易测试过程中，在发生堵塞后是否执行了预期的流程，例如，在发生空回滚后，是否执行了空回滚流程，在发生悬挂后，是否执行了防悬挂流程等。

在步骤S250，根据第一流程，确定目标事务的第一测试结果。

在本公开实施例中，可以根据第一流程是否包括预期的流程，判断第一测试结果为通过或者是不通过，例如，当第一流程包括全部预期的流程时，可以确定第一测试结果为通过，否则，则确定第一测试结果为未通过。

下面结合图2至图7对本公开实施例的测试方法进行进一步的说明。

图3示意性示出了根据本公开实施例的发起交易测试的流程图，如图3所示，在一些具体实施例中，步骤S210包括步骤S211至步骤S214。

在步骤S211，对目标事务的输入和输出进行解析，以得到业务数据字段、非业务数据字段以及与业务数据字段相匹配的第一赋值。

在本公开实施例中，在生成测试案例时，业务数据字段的赋值可以使用目标事务中业务数据字段的赋值，也即，使用第一赋值。非业务数据字段可以包括公共字段，例如工作日期和交易序号等。

在本公开实施例中，可以通过分析接口源码，使用JAVA反射的方式，对输入和输出解析，以获取输入和输出的所有字段及其第一赋值。例如，可以使用getFields获取IO类的成员变量，然后对所有成员属性进行分析，如果是int、boolean、Date、String等基本属性变量，则直接保存该成员变量；如果成员是List或者Map，则首先构造对应的List和Map；如果成员是一个实体类，则嵌套从头循环调用，最终得到完整的输入字段定义。

在本公开实施例中，可以获取各字段的属性定义，例如，使用注解的方式定义字段，进而解析此字段的注解及参数得到字段属性。

在步骤S212，对非业务数据字段的至少部分进行自适应赋值，以得到第二赋值。

在本公开实施例中，自适应赋值可以是指，在对非业务数据字段进行赋值以得到第二赋值后，第二赋值满***易测试对非业务数据的要求。例如，对于工作日期，可以以发起交易测试当天的日期进行赋值，从而使得测试案例中的工作日期能够满足测试要求，在交易测试中，不会由于工作日期导致测试失败。

在步骤S213，根据业务数据字段、非业务数据字段、第一赋值和第二赋值，生成测试案例。

在本公开实施例中，测试案例可以是表格(EXCEL)形式的测试案例。测试案例的主要内容可以根据实际需要确定，在此不作限制，例如，测试案例的主要内容可以包括输入类名、参数名、类型、最大长度以及各种赋值等。

在本公开实施例中，测试人员可以根据业务流程，补充丰富测试案例。

在步骤S214，根据测试案例，对目标事务发起交易测试。

在本公开实施例中，可以通过测试脚本自动地完成对目标事务的交易测试。

在一些具体实施例中，测试方法还包括步骤S310。

在步骤S310，获取测试脚本，测试脚本包括多个测试流程。

在本公开实施例中，可以获取目标事务输入通讯区和输出通讯区的JAVA定义文件；对输入和输出定义，通过静态代码分析的方式，自动分析获取被目标事务的类型和调起方式(如RPC或HTTP等)，并生成对应的JAVA格式的测试脚本，以及EXCEL格式的测试案例。

在一些具体实施例中，步骤S214包括步骤S2141。

在步骤S2141，根据测试脚本的多个测试流程，从测试案例中加载数据，以对目标事务发起交易测试。其中，多个测试流程包括数据预处理流程、环境备份流程、交易测试流程和环境恢复流程。

在本公开实施例中，测试脚本可以基于TestNG框架从测试案例中加载测试数据。

在本公开实施例中，对于一个目标事务，可以发起一次或多次交易测试。在每次交易测试中，可以首先将测试案例里面的数据，打包成MAP格式的交易请求报文；之后，调起测试脚本，对目标事务自动发起对应的交易调用(http或者RPC等方式)。

在一些具体实施例中，可以建立对测试脚本和测试案例的管理机制。通过管理机制可以定时自动调度执行脚本和案例，并保存和分析交易测试的结果。

示例性地，可以按照一定的规则(例如CPCP规则)来定义测试案例，并按照定义结果分层次集中管理。其中，通过CPCP规则可以是指：按照渠道(C)、产品(P)、客户(C)和合作方(P)这四个维度对测试案例进行定义。其中，“渠道维度”包括交易发起的渠道，例如网银。“产品维度”包括提供给客户的产品，例如***。“客户维度”包括客户特征，例如客户的交易介质(例如卡片)。“合作方维度”包括合作方特征，例如个性分支描述(例如信息查询)。

示例性地，可以建立定时计划，例如，在每天下班前自动进行交易测试。并将失败的测试案例自动发送给干系人，并生成相应提示，例如提示干系人尽快解决。可选地，可以分析测试案例的整体情况和人员情况，例如，测试案例的整体情况可以包括测试案例总数和成功率等，人员情况可以包括编写测试案例的人员，各自的案例数和成功率等。

在一些具体实施例中，预设阶段包括多阶段分布式事务的数据准备阶段，也即，前文提到的Try阶段，下文相同，故不再赘述。图4示意性示出了根据本公开实施例的注入故障的流程图，如图4所示，步骤S220包括步骤S221。

在步骤S221，基于混沌工程，在交易测试的过程中注入至少一种延时故障，以使目标事务在数据准备阶段发生堵塞。

在一些具体实施例中，延时故障包括网络延时故障和/或SQL延时故障。

在本公开实施例中，可以通过混沌工程工具ChaosBlade注入网络延时故障，模拟调用某个服务时出现网络延迟的场景。例如，可以对指定服务(实现接口的JAVA类)和方法(实现接口的JAVA方法)进行调用延时，以Dubbo服务为例，可以使用ChaosBlade对ServiceA的MethodZ注入延时40000毫秒的网络延时故障。

在本公开实施例中，可以通过混沌工程工具ChaosBladeSQL调用发起延时故障注入，模拟执行某个SQL语句时出现时间较长，或者超过超时时间的场景。例如，可以使用ChaosBladeSQL对IPA端口3306的dbD数据库的tableT表中，insert的sql语句注入延迟7500毫秒的故障。

图5示意性示出了根据本公开实施例的断言分析的流程图，如图5所示，在一些具体实施例中，步骤S240包括步骤S241。

在步骤S241，根据响应信息，利用断言分析，确定第一流程是否包括执行空回滚的流程。

在本公开实施例中，可以判断事务的回滚有无被触发，事务是否被正确回滚，例如，当转账交易被回滚时，需要判断转出和转入账号的金额是否都恢复回交易请求前的值。

在本公开实施例中，在判断第一流程是否包括执行空回滚的流程时，可以通过断言分析是否存在一笔失败的子事务记录，是否存在回滚子事务直接完成的记录，以及是否存在特定错误码。当上述判断均为“是”时，确定第一流程包括执行空回滚的流程，否则，确定第一流程不包括执行空回滚的流程，或者执行空回滚的流程不正确等。

在一些具体实施例中，在进行断言分析之前，可以先判断是否发生了空回滚，例如可以通过特定错误码确定是否发生了空回滚，当发生了空回滚后，可以执行步骤S241。否则，说明未发生空回滚，此时，可以则跳过对空回滚的断言。

如图4所示，在一些具体实施例中，步骤S220还包括步骤S222。

在步骤S222，基于混沌工程，在执行空回滚流程之后，解除堵塞，例如，恢复网络等，从而制造防悬挂场景。

如图5所示，在一些具体实施例中，步骤S240包括步骤S242。

在步骤S242，根据响应信息，利用断言分析，确定第一流程是否包括防悬挂流程。

在本公开实施例中，在交易测试后，可以通过断言分析，断言防悬挂的操作流程是否正确处理。例如，断言是否包含以下处理过程：在空回滚后，当再接到Try阶段请求时，根据主事务ID查询数据库事务记录，判断已经有一笔其他状态的记录，则抛出异常，并拒绝处理此次请求。也即，判断是否有抛出悬挂异常，且存在拒绝Try阶段请求记录。当抛出悬挂异常，且存在拒绝Try阶段请求记录，确定第一流程包括防悬挂流程，否则，则确定第一流程不包括防悬挂流程，或者，防悬挂流程不正确等。

在一些具体实施例中，在进行断言分析之前，可以先判断是否发生了空回滚，例如可以通过特定错误码确定是否发生了空回滚以及悬挂，当发生了空回滚以及防悬挂后，可以执行步骤S242。否则，说明未发生悬挂，此时，可以跳过对防悬挂的断言。

在一些具体实施例中，步骤S250包括步骤S251。

在步骤S251，当第一流程包括空回滚流程和防悬挂流程时，确定第一测试结果为测试通过，也即，确定通过空回滚和防悬挂测试。否则，确定第一测试结果为测试失败。

图6示意性示出了根据本公开实施例的发起交易测试的流程图之二，如图6所示，在一些具体实施例中，测试方法还包括步骤S410至步骤S430。

在步骤S410，在交易测试过程中，基于混沌工程，对用于执行目标事务的服务器注入至少一种故障，以使服务器中用于处理目标事务的容器出现异常。

在本公开实施例中，容器(Linux Container)可以理解为通过资源隔离技术，将物理机的资源(比如处理器，内存，磁盘等)划分为多个资源池，使得某个应用程序可以独立的使用某个资源池而不受其他应用程序的影响。可以将划分出来的资源池和使用这部分资源池的应用程序称为一个容器。可以理解的是，物理机器是一台实体的服务器，包括硬件和***，比如Linux服务器。

在本公开实施例中，通过向服务器注入故障，可以进行健壮性等测试，例如，当容器出现异常时，容器应当可以自愈等。

在一些具体实施例中，步骤S410包括步骤S411。

在步骤S411，基于混沌工程，对用于执行目标事务的服务器注入至少一种资源故障，以使服务器中用于处理目标事务的容器出现异常。

在一些具体实施例中，资源故障包括：处理器故障、内存故障和磁盘故障中的至少一者。例如，处理器满负载或内存满负载等。

在步骤S420，根据响应信息，确定在容器出现异常后执行的第二流程。

在一些具体实施例中，步骤S420包括步骤S421。

在步骤S421，根据响应信息，利用断言分析，确定第二流程是否包括容器自愈流程。

在本公开实施例中，对于目标事务，可以根据实际需要注入资源故障，以使目标事务涉及的部分或者全部容器处于异常。对于定向到异常容器交易请求，断言为交易失败可以确定异常容器处于自愈流程，也即第二流程包括自愈流程。否则，则确定第二流程不包括自愈流程，自愈流程处理不正确。

在步骤S430，根据第二流程，确定目标事务的第二测试结果。

在一些具体实施例中，步骤S430包括步骤S431。

在步骤S431，当第二流程包括容器自愈流程时，确定第二测试结果为测试通过，否则，确定第二测试结果为测试失败。

图7示意性示出了根据本公开实施例的发起交易测试的流程图之三，如图7所示，在一些具体实施例中，测试方法还包括步骤S510和步骤S520。

在步骤S510，根据响应信息，利用断言分析，确定目标事务在每个阶段的处理结果。

在步骤S520，当每个阶段的处理结果均满足预期时，确定第三测试结果为测试通过，也即目标事务的执行结果通过测试，否则，确定第三测试结果为测试失败。

在本公开实施例中，可以对处理结果进行断言分析，进而确定第三测试结果。例如，可以通过断言分析响应信息中与交易结果相关的字段的值是否符合预期，交易后数据库表的更新是否符合预期，目标事务的事件状态是否符合预期等。

示例性地，对于回滚的事务，则可以分为两阶段进行处理结果的断言，在一阶段结束后，如做完一个从账户A到账户B的转账交易，则查询账户A金额的减少值和账户B金额增加值是否符合预期。在回滚后，再判断账户A和账户B的金额是否都已经恢复回原来的数值状态。

在一些具体实施例中，可以结合第一测试结果、第二测试结果和第三测试结果给出最终的测试结果。例如，当第一测试结果、第二测试结果和第三测试结果均为测试通过时，确定最终的测试结果为测试通过，也即，目标事务通过交易测试。否则，则确定最终的测试结果为测试失败。此时，可以推送至干系人，告知干系人及时处理。

通过上述方式，不仅能在发生异常时，对处理流程(是否包括正确的空回滚执行流程和防悬挂流程)进行测试，同时，还能对执行结果进行测试，相较于传统方案而言，测试覆盖面大大增加。

在一些具体实施例中，可以在一次交易测试中，按照实际需要，执行资源故障的注入、网络延时故障的注入和/或SQL故障的注入。例如，可以按照预设顺序，当然，依次执行资源故障的注入、网络延时故障的注入和/或SQL故障的注入，或者，从中选出部分来依次注入。

在一些具体实施例中，可以在全部的故障注入，交易测试完成后，获取响应信息，进而根据响应信息，通过断言分析，对交易测试中的相关流程和交易结果是否符合与其进行分析，继而得到第一测试结果、第二测试结果和第三测试结果。

在一些具体实施例中，对交易结果的测试可以在

基于上述的测试方法，本公开还提供了一种测试装置。以下将结合图8对该装置进行详细描述。

图8示意性示出了根据本公开实施例的测试装置的结构框图，如图8所示，该实施例的测试装置800包括测试模块810、混沌工程模块820、获取模块830、第一处理模块840和第二处理模块850。

测试模块810用于对目标事务发起交易测试，目标事务包括多阶段分布式事务。在一实施例中，测试模块810可以用于执行前文描述的步骤S210，在此不再赘述。

混沌工程模块820用于基于混沌工程，在交易测试的过程中注入至少一种故障，以使目标事务在预设阶段发生堵塞。在一实施例中，混沌工程模块820可以用于执行前文描述的步骤S220，在此不再赘述。

获取模块830用于获取在交易测试过程中生成的响应信息。在一实施例中，获取模块830可以用于执行前文描述的步骤S230，在此不再赘述。

第一处理模块840用于根据响应信息，确定在发生堵塞后执行的第一流程。在一实施例中，第一处理模块840可以用于执行前文描述的步骤S240，在此不再赘述。

第二处理模块850用于根据第一流程，确定目标事务的第一测试结果。在一实施例中，第二处理模块850可以用于执行前文描述的步骤S250，在此不再赘述。。

根据本公开的实施例，测试模块810、混沌工程模块820、获取模块830、第一处理模块840和第二处理模块850中的任意多个模块可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，测试模块810、混沌工程模块820、获取模块830、第一处理模块840和第二处理模块850中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上***、基板上的***、封装上的***、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，测试模块810、混沌工程模块820、获取模块830、第一处理模块840和第二处理模块850中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

在一些具体实施例中，测试模块810具体用于执行以下步骤：

对目标事务的输入和输出进行解析，以得到业务数据字段、非业务数据字段以及与业务数据字段相匹配的第一赋值。

对非业务数据字段的至少部分进行自适应赋值，以得到第二赋值。

根据业务数据字段、非业务数据字段、第一赋值和第二赋值，生成测试案例。

根据测试案例，对目标事务发起交易测试。

在一些具体实施例中，测试装置还包括第三处理模块。第三处理模块用于执行以下步骤：

获取测试脚本，测试脚本包括多个测试流程。

根据测试案例，对目标事务发起交易测试，包括：

根据测试脚本的多个测试流程，从测试案例中加载数据，以对目标事务发起交易测试。

在一些具体实施例中，预设阶段包括多阶段分布式事务的数据准备阶段，混沌工程模块820具体用于执行以下步骤：

基于混沌工程，在交易测试的过程中注入至少一种延时故障，以使目标事务在数据准备阶段发生堵塞。

根据响应信息，确定在发生堵塞后执行的第一流程，包括：

根据响应信息，利用断言分析，确定第一流程是否包括空回滚流程。

在一些具体实施例中，混沌工程模块820具体用于执行以下步骤：

基于混沌工程，在执行空回滚流程之后，解除堵塞。

根据响应信息，确定在发生堵塞后执行的第一流程，包括：

根据响应信息，利用断言分析，确定第一流程是否包括防悬挂流程。

在一些具体实施例中，第二处理模块850具体用于执行以下步骤：

当第一流程包括空回滚流程和防悬挂流程时，确定第一测试结果为测试通过。

在一些具体实施例中，混沌工程模块820还用于执行以下步骤：

在交易测试过程中，基于混沌工程，对用于执行目标事务的服务器注入至少一种故障，以使服务器中用于处理目标事务的容器出现异常。

在一些具体实施例中，测试装置还包括第四处理模块，第四处理模块用于执行以下步骤：

根据响应信息，确定在容器出现异常后执行的第二流程。

根据第二流程，确定目标事务的第二测试结果。

在一些具体实施例中，在交易测试过程中，混沌工程模块820具体还用于执行以下步骤：

基于混沌工程，对用于执行目标事务的服务器注入至少一种资源故障，以使服务器中用于处理目标事务的容器出现异常。

在一些具体实施例中，第四处理模块具体用于执行以下步骤：

根据响应信息，确定在容器出现异常后执行的第二流程，包括：

根据响应信息，利用断言分析，确定第二流程是否包括容器自愈流程。

当第二流程包括容器自愈流程时，确定第二测试结果为测试通过。

在一些具体实施例中，资源故障包括：处理器故障、内存故障和磁盘故障中的至少一者。

在一些具体实施例中，测试装置还包括第五处理模块，第五处理模块用于执行以下步骤：

根据响应信息，利用断言分析，确定目标事务在每个阶段的处理结果。

图9示意性示出了根据本公开实施例的适于实现测试方法的电子设备的方框图，如图9所示，根据本公开实施例的电子设备900包括处理器901，其可以根据存储在只读存储器(ROM)902中的程序或者从存储部分908加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和处理。处理器901例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))等等。处理器901还可以包括用于缓存用途的板载存储器。处理器901可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在RAM 903中，存储有电子设备900操作所需的各种程序和数据。处理器901、ROM902以及RAM 903通过总线904彼此相连。处理器901通过执行ROM 902和/或RAM 903中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除ROM 902和RAM 903以外的一个或多个存储器中。处理器901也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，电子设备900还可以包括输入/输出(I/O)接口905，输入/输出(I/O)接口905也连接至总线904。电子设备900还可以包括连接至I/O接口905的以下部件中的一项或多项：包括键盘、鼠标等的输入部分906；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分907；包括硬盘等的存储部分908；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至I/O接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入存储部分908。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/***中所包含的；也可以是单独存在，而未装配入该设备/装置/***中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的测试方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的ROM 902和/或RAM 903和/或ROM 902和RAM 903以外的一个或多个存储器。

本公开的实施例还包括一种计算机程序产品，其包括计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。当计算机程序产品在计算机***中运行时，该程序代码用于使计算机***实现本公开实施例所提供的测试方法。

在该计算机程序被处理器901执行时执行本公开实施例的***/装置中限定的上述功能。根据本公开的实施例，上文描述的***、装置、模块、单元等可以通过计算机程序模块来实现。

在一种实施例中，该计算机程序可以依托于光存储器件、磁存储器件等有形存储介质。在另一种实施例中，该计算机程序也可以在网络介质上以信号的形式进行传输、分发，并通过通信部分909被下载和安装，和/或从可拆卸介质911被安装。该计算机程序包含的程序代码可以用任何适当的网络介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

在这样的实施例中，该计算机程序可以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911被安装。在该计算机程序被处理器901执行时，执行本公开实施例的***中限定的上述功能。根据本公开的实施例，上文描述的***、设备、装置、模块、单元等可以通过计算机程序模块来实现。

根据本公开的实施例，可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例提供的计算机程序的程序代码，具体地，可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。程序设计语言包括但不限于诸如Java，C++，python，“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本公开各种实施例的***、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的***来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合或/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。

Claims

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

获取在所述交易测试过程中生成的响应信息；

根据所述第一流程，确定所述目标事务的第一测试结果。

2.根据权利要求1所述的测试方法，其特征在于，所述对目标事务发起交易测试，包括：

根据所述测试案例，对所述目标事务发起交易测试。

3.根据权利要求2所述的测试方法，其特征在于，所述测试方法还包括：

获取测试脚本，所述测试脚本包括多个测试流程；

4.根据权利要求1所述的测试方法，其特征在于，所述预设阶段包括多阶段分布式事务的数据准备阶段，所述基于混沌工程，在所述交易测试的过程中注入至少一种故障，以使所述目标事务在预设阶段发生堵塞，包括：

5.根据权利要求4所述的测试方法，其特征在于，所述基于混沌工程，在所述交易测试的过程中注入至少一种故障，以使所述目标事务在预设阶段发生堵塞，还包括：

6.根据权利要求5所述的测试方法，其特征在于，根据所述第一流程，确定所述目标事务的第一测试结果，包括：

7.根据权利要求4所述的测试方法，其特征在于，所述延时故障包括网络延时故障和/或SQL延时故障。

8.根据权利要求1至7中任一项所述的测试方法，其特征在于，所述测试方法还包括：

根据所述第二流程，确定所述目标事务的第二测试结果。

9.根据权利要求8所述的测试方法，其特征在于，所述在所述交易测试过程中，基于混沌工程，对用于执行所述目标事务的服务器注入至少一种故障，以使所述服务器中用于处理所述目标事务的容器出现异常，包括：

10.根据权利要求8所述的测试方法，其特征在于，所述测试方法还包括：

11.一种测试装置，其特征在于，包括：

第二处理模块，用于根据所述第一流程，确定所述目标事务的第一测试结果。

12.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器执行根据权利要求1～10中任一项所述的测试方法。

13.一种计算机可读存储介质，其特征在于，其上存储有可执行指令，该指令被处理器执行时使处理器执行根据权利要求1～10中任一项所述的测试方法。

14.一种计算机程序产品，其特征在于，包括计算机程序，所述计算机程序被处理器执行时实现根据权利要求1～10中任一项所述的测试方法。