CN117743183A

CN117743183A - 业务流程测试方法、装置、电子设备及存储介质

Info

Publication number: CN117743183A
Application number: CN202311798963.6A
Authority: CN
Inventors: 周倩兰; 廖蕊; 苏更殊; 陈争气; 张存国
Original assignee: China Telecom Corp Ltd
Current assignee: China Telecom Corp Ltd
Priority date: 2023-12-25
Filing date: 2023-12-25
Publication date: 2024-03-22

Abstract

本公开提供了一种业务流程测试方法、装置、电子设备及存储介质，涉及计算机技术领域。该方法包括：获取业务流程模板；生成业务流程模板的流程实例，流程实例包括业务流程模板的各个执行路径，其中，各个执行路径中的服务实例基于服务接口协议生成；获取每一执行路径的输入参数，基于流程实例分别对每一输入参数进行处理，记录每一输入参数在流程实例中的处理路径；根据每一输入参数对应的执行路径与处理路径，生成第一测试结果。此方式节省了人工及时间成本，各个执行路径中的服务实例基于服务接口协议生成，可以使得测试测试覆盖更加全面，对业务流程的测试也更加完整，进而可以使得通过测试的业务流程更加不易出现问题。

Description

业务流程测试方法、装置、电子设备及存储介质

技术领域

本公开涉及计算机技术领域，尤其涉及一种业务流程测试方法、装置、电子设备及存储介质。

背景技术

在计算机技术领域中，处理工单等内容的业务流程具有复杂度高的特点，在业务流程设计完成后，需要对业务流程进行测试，以检测出业务流程设计中存在的问题。

相关技术中，完成业务流程的设计后，由人工对业务流程进行测试。

然而，人工对业务流程进行全路径覆盖测试的时间成本和人工成本高。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开提供一种业务流程测试方法、装置、电子设备及存储介质，至少在一定程度上克服了相关技术中对业务流程进行全路径覆盖测试的时间成本和人工成本高的问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的一个方面，提供一种业务流程测试方法，包括：获取业务流程模板；生成所述业务流程模板的流程实例，所述流程实例包括所述业务流程模板的各个执行路径，其中，各个执行路径中的服务实例基于服务接口协议生成；获取每一执行路径的输入参数，基于所述流程实例分别对每一输入参数进行处理，记录每一输入参数在所述流程实例中的处理路径；根据每一输入参数对应的执行路径与处理路径，生成第一测试结果。

在本公开的一个实施例中，所述生成所述业务流程模板的流程实例，包括：获取所述业务流程模板中每一服务的服务实例；将各个节点的流程环节信息登记在流程环节定义模型中；获取每一执行路径中的节点与服务实例之间的对应关系；根据所述服务实例、各个执行路径和所述对应关系，生成流程实例。

在本公开的一个实施例中，所述获取所述业务流程模板中每一服务的服务实例，包括：获取所述业务流程模板中每一服务的服务接口协议；生成每一服务接口协议对应的服务的基础信息，并将所述基础信息登记在服务定义模型中；根据服务接口协议，生成每一服务的多种服务返回结果实例，并将每种服务返回结果实例登记在服务返回结果模型中；根据所述服务定义模型和所述服务返回结果模型，生成每一服务的服务实例。

在本公开的一个实施例中，所述将各个节点的流程环节信息登记在流程环节定义模型中，包括：解析所述业务流程模板，得到各个节点的流程环节信息及流程环节关系；将各个流程节点的流程环节信息登记在流程环节定义模型中，以及将各个节点的流程环节关系登记在流程环节关系模型中；根据所述流程环节定义模型和所述流程环节关系模型，生成所述业务流程模板中的各个执行路径。

在本公开的一个实施例中，所述基于所述流程实例分别对每一输入参数进行处理，记录每一输入参数在所述流程实例中的处理路径，包括：获取上下文模型，所述上下文模型记录有所述流程实例中每一节点的输入参数与输出参数的对应关系；将每一执行路径的输入参数对应的节点作为各自执行路径中的当前节点，并对于每一执行路径执行进行以下处理：根据执行路径的输入参数，从所述上下文模型中获取当前节点的输出参数，并将当前节点的输出参数作为所述流程实例中下一个节点的输入参数，直至下一个节点为结束节点时记录所述服务实例中处理输入参数的处理路径。

在本公开的一个实施例中，还包括：对于每一执行路径的输入参数进行如下处理：记录输入参数按照所述流程实例处理后得到的第一输出参数；获取第二输出参数，所述第二输出参数是预设输入参数按照所述流程实例处理后得到结果；根据所述第一输出参数和所述第二输出参数，生成第二测试结果

在本公开的一个实施例中，还包括：获取所述流程实例中每一服务实例的至少一个非正常输出结果，每一非正常输出结果为输出异常、输出超时和输出错误中的一个；测试每一服务实例的每一非正常输出结果是否存在对应的执行路径，得到第三测试结果。

根据本公开的另一个方面，提供一种业务流程测试装置，包括：第一获取模块，用于获取业务流程模板；生成模块，用于生成所述业务流程模板的流程实例，所述流程实例包括所述业务流程模板的各个执行路径，其中，各个执行路径中的服务实例基于服务接口协议生成；获取及处理模块，用于获取每一执行路径的输入参数，基于所述流程实例分别对每一输入参数进行处理，记录每一输入参数在所述流程实例中的处理路径；所述生成模块，还用于根据每一输入参数对应的执行路径与处理路径，生成第一测试结果。

在本公开的一个实施例中，所述生成模块，用于获取所述业务流程模板中每一服务的服务实例；将各个节点的流程环节信息登记在流程环节定义模型中；获取每一执行路径中的节点与服务实例之间的对应关系；根据所述服务实例、各个执行路径和所述对应关系，生成流程实例。

在本公开的一个实施例中，所述生成模块，用于获取所述业务流程模板中每一服务的服务接口协议；生成每一服务接口协议对应的服务的基础信息，并将所述基础信息登记在服务定义模型中；根据服务接口协议，生成每一服务的多种服务返回结果实例，并将每种服务返回结果实例登记在服务返回结果模型中；根据所述服务定义模型和所述服务返回结果模型，生成每一服务的服务实例。

在本公开的一个实施例中，所述生成模块，用于解析所述业务流程模板，得到各个节点的流程环节信息及流程环节关系；将各个流程节点的流程环节信息登记在流程环节定义模型中，以及将各个节点的流程环节关系登记在流程环节关系模型中；根据所述流程环节定义模型和所述流程环节关系模型，生成所述业务流程模板中的各个执行路径。

在本公开的一个实施例中，获取及处理模块，用于获取上下文模型，所述上下文模型记录有所述流程实例中每一节点的输入参数与输出参数的对应关系；将每一执行路径的输入参数对应的节点作为各自执行路径中的当前节点，并对于每一执行路径执行进行以下处理：根据执行路径的输入参数，从所述上下文模型中获取当前节点的输出参数，并将当前节点的输出参数作为所述流程实例中下一个节点的输入参数，直至下一个节点为结束节点时记录所述服务实例中处理输入参数的处理路径。

在本公开的一个实施例中，所述装置还包括：处理模块，用于对于每一执行路径的输入参数进行如下处理：记录输入参数按照所述流程实例处理后得到的第一输出参数；获取第二输出参数，所述第二输出参数是预设输入参数按照所述流程实例处理后得到结果；根据所述第一输出参数和所述第二输出参数，生成第二测试结果。

在本公开的一个实施例中，所述获取模块，还用于获取所述流程实例中每一服务实例的至少一个非正常输出结果，每一非正常输出结果为输出异常、输出超时和输出错误中的一个；所述装置还包括：测试模块，用于测试每一服务实例的每一非正常输出结果是否存在对应的执行路径，得到第三测试结果。

根据本公开的再一个方面，提供一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述任一所述的业务流程测试方法。

根据本公开的又一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任一所述的业务流程测试方法。

根据本公开的又一个方面，提供一种计算机程序产品，所述计算机程序产品包括计算机程序或计算机指令，所述计算机程序或所述计算机指令由处理器加载并执行，以使计算机实现上述任一所述的业务流程测试方法。

本公开的实施例所提供的技术方案至少包括以下有益效果：

本公开的实施例所提供的技术方案，获取设计完成的业务流程模板，自动生成业务流程模板的流程实例，再针对业务流程实例中的每一执行路径获取相应的输入参数，利用业务流程实例对每一输入参数进行处理，并记录处理输入参数的处理路径，再利用执行路径与处理路径生成测试结果的方式，提供了一种自动全路径覆盖测试业务流程的方式，节省了人工及时间成本。

进一步地，各个执行路径中的服务实例基于服务接口协议生成，而可以使得测试测试覆盖更加全面，对业务流程的测试也更加完整，进而可以使得通过测试的业务流程更加不易出现问题。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出本公开一个实施例中的业务流程测试方法流程图；

图2示出本公开一个实施例中的业务流程模板的示意图；

图3示出本公开一个实施例中的生成服务实例的流程图；

图4示出本公开一个实施例中的生成各个执行路径的流程图；

图5示出本公开一个实施例中的向上下文模型中登记下文信息的流程图；

图6示出本公开一个实施例中的确定执行路径测试结论的流程图；

图7示出本公开一个实施例中的对业务流程的完整性进行测试的流程图；

图8示出本公开另一个实施例中的对业务流程的完整性进行测试的流程图；

图9示出本公开一个实施例中的业务流程测试装置示意图；

图10示出本公开一个实施例中的电子设备的结构框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

应当理解，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。

需要注意，本公开中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。

需要注意，本公开中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。

下面结合附图及实施例对本示例实施方式进行详细说明。

本公开实施例中提供了一种业务流程测试方法，该方法可以由任意具备计算处理能力的电子设备执行。例如，该电子设备包括但不限于智能手机、平板电脑、膝上型便携计算机、台式计算机、可穿戴设备、增强现实设备、虚拟现实设备等。

该电子设备还可以是提供各种服务器，在一个实施例中，该服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。

图1示出本公开一个实施例中的业务流程测试方法流程图，如图1所示，本公开实施例中提供的业务流程测试方法可以包括如下S101至S104。

S101，获取业务流程模板。

关于该业务流程模板具体为何种业务的流程模板，以及该业务流程具体如何设计得到，以及该业务流程模板具体包括多少个节点及执行路径本公开的实施例均不做限制。例如，该业务流程模板对应的业务流程可以是工单处理，或者为账号注册流程等等。

为便于理解业务流程模板，可参见图2，图2提供了一种业务流程模板。该业务流程模板包括开始节点21、节点22、输出错误221、结束节点23、判断节点(判断网关)24、节点25、结束节点26、节点27、结束节点28。

该业务流程模板处理业务的流程为：开始；输入服务1对应格式的输入参数，经服务1处理后，可以是输出参数，也可以是输出错误；在输出错误的情况下，流程结束；在输出参数的情况下，由判断节点(判断网关)24对参数进行判断，若输出参数为结果11，则将该参数输入至服务2，经服务2处理后结束，若输出参数为结果12，则将该参数输入至服务3，经服务3处理后结束。

需要说明的是，服务可以用于对数据进行处理，并得到处理后的数据。

在一个实施例中，业务成流程模板可以从其他设备中获取；或者，业务成流程模板可以在执行业务流程测试方法的设备中直接建立得到。

在一个实施例中，业务流程模板可以基于BPMN(Business Process ModelingNotation，业务流程建模标注)工具构建得到。

S102，生成业务流程模板的流程实例，流程实例包括业务流程模板的各个执行路径，其中，各个执行路径中的服务实例基于服务接口协议生成。

业务流程模板不是由计算机设备可以直接执行的实例，而是用于指导构建业务流程的模板，要实现自动化的业务流程测试需要先生成业务流程模板的流程实例，流程实例是计算机可以识别并处理的内容。

对于一个执行路径，其第一个节点为开始节点，最后一个节点为结束节点。对于执行路径的理解，可以参见图2对应的流程模板。其中，开始节点21、节点22、输出错误221、结束节点23为一个执行路径；开始节点21、节点22、判断节点(判断网关)24、节点25、结束节点26为一个执行路径；开始节点21、节点22、判断节点(判断网关)24、节点27、结束节点28为一个执行路径。

服务实例可以由计算机设备执行，向服务实例中输入符合该服务格式要求的参数后，计算机可以基于服务实例对参数的处理逻辑对输入的参数进行处理，从而输出处理得到的参数。

在业务流程涉及的服务中包括需要调用外部系统的服务时，执行业务流程的设备需要与该外部系统进行通信，以实现服务的调用，调用服务处理数据的过程中涉及到输入参数及接收返回结果的信息交换，而进行信息交换的接口需要遵从双方约定的通信方式和要求等，该双方约定的通信方式和要求等内容即为服务接口协议。例如，服务接口协议中规定了业务流程执行设备与外部系统之间数据报文的模板(也可理解为报文的格式)，包括业务流程执行设备向外部系统发送的入参报文的模板，以及外部系统向业务流程执行设备发送的出参报文的模板。

在一个实施例中，生成业务流程模板的流程实例，可以包括：获取业务流程模板中每一服务的服务实例；获取业务流程模板中的各个执行路径；获取每一执行路径中的节点与服务实例之间的对应关系；根据服务实例、各个执行路径和对应关系，生成流程实例。

在一个实施例中，获取业务流程模板中每一服务的服务实例，可以包括：获取业务流程模板中每一服务的服务接口协议；生成每一服务接口协议对应的服务的基础信息，并将基础信息登记在服务定义模型中；根据服务接口协议，生成每一服务的多种服务返回结果实例，并将每种服务返回结果实例登记在服务返回结果模型中；根据服务定义模型和服务返回结果模型，生成每一服务的服务实例。

关于如何获取每一服务的服务接口协议，本公开的实施例不做限制。例如，服务接口协议可以存在执行业务流程测试方法的电子设备中，需要获取每一服务的服务接口协议时，可以直接从存储器中获取。再例如，服务接口协议可以存储在其他设备中，执行业务流程测试方法的电子设备可以通过网络从存储服务接口协议的设备中获取每一服务的服务接口协议。

在一个实施例中，服务的基础信息包括可以包括：服务编码、入参报文模板和出参报文模板。或者，服务的基础信息可以包括：服务编码、接口类型、入参报文模板、出参报文模板和第一信息，第一信息包括服务名称和接口类型中的至少一个。

其中，服务编码用于唯一标识服务。入参报文模板是设备调用服务时，向该服务所在外部系统发送的报文的模板。出参报文模板是外部系统向该调用服务的设备返回服务处理结果时的报文的模板。接口类型为服务接口协议对应的接口的类型，例如，WebService(一种接口类型)或RESTFul(一种接口类型)。

服务定义模型用于存储服务的基础信息，以服务的基础信息包括：服务编码、接口类型、入参报文模板、出参报文模板和服务名称为例，则服务定义模型存储的数据类型可以如下表1所示。

表1

序号	属性名称
		1	服务编码
2	接口类型
		3	入参报文模板
4	出参报文模板
		5	服务名称

在一个实施例中，服务返回结果实例可以包括：服务编码、结果编码、服务结果类型；或者，服务返回结果实例可以包括：服务编码、结果编码、服务结果类型和第二信息，第二信息包括入参报文实例和出参报文实例中的至少一个。

其中，结果编码可以直接是服务返回的结果，也可以用于唯一标识一种服务返回的结果，例如，服务编码为10，对应的服务返回的结果可以是2。服务结果类型可以包括：异常、错误、超时、正常等。

服务返回结果模型用于存储服务返回结果实例，以服务返回结果实例可以包括：服务编码、结果编码、服务结果类型、入参报文实例和出参报文实例为例，则服务返回结果模型存储的数据类型可以如下表2所示。

表2

序号	属性名称
		1	服务编码
2	结果编码
		3	入参报文实例
4	出参报文实例
		5	服务结果类型

在一个实施例中，根据服务定义模型和服务返回结果模型，生成每一服务的服务实例，可以包括：根据服务定义模型和服务返回模型生成每一服务的代码实例，该代码实例即为服务实例。

在一个实施例中，服务实例可以对输入参数(即为入参报文，后续不再一一赘述)进行合法性、合理性检查。例如，输入参数的格式要求为数值型，则输入字符型的输入参数会检测不通过。服务实例还可以根据服务返回结果模型，返回输入参数对应的输出参数(即为出参报文，后续不再一一赘述)。

生成每流程实例中每一服务的服务实例后，可以对该服务实例进行存储，后续其他流程实例需要应用存储的服务实例时，可以直接根据服务编码获取相应的服务实例。也就是说，获取业务流程模板中每一服务的服务实例，可以包括：根据业务流程模板中每一服务的服务编码，从存储器中获取每一服务的服务实例。

下面将结合图3辅助说明如何生成服务实例，图3中生成服务实例的过程可以包括S301至S304。

S301，根据服务定义模型，获取服务的基础信息。

S302，根据服务返回结果模型，获取服务返回结果。

S303，根据服务的基础信息和服务返回结果，生成服务的代码实例。

S304，服务发布(服务实例可以被应用)。

下面继续对获取业务流程模板中的各个执行路径进行说明。

需要说明的是，执行路径可以被计算机识别，并可以使计算机按照执行路径的执行顺序对数据进行处理。

关于如何获取业务流程模板中的各个执行路径，本公开的实施例不做限制。在一个实施例中，获取业务流程模板中的各个执行路径，可以包括：解析业务流程模板，得到各个节点的流程环节信息及流程环节关系；将各个流程节点的流程环节信息登记在流程环节定义模型中，以及将各个节点的流程环节关系登记在流程环节关系模型中；根据流程环节定义模型和流程环节关系模型，生成业务流程模板中的各个执行路径。

流程环节信息用于描述流程实例中的一个节点，关于流程环节信息具体包括哪些信息，本公开的实施例不做限制，只要流程环节信息能够清楚描述流程实例中的节点即可。在一个实施例中，流程环节信息包括：业务流程模板编码、环节编码、服务编码和环节类型；其中，业务流程模板中的一个节点对应一个环节编码。

其中，业务流程模板编码用于唯一标识一个业务流程；环节编码用于唯一标识该业务流程中的一个节点；服务编码用于唯一标识与节点对应的服务；环节类型用于标识节点的类型，例如，环节类型包括：起始节点、服务、结束节点、判断网关(也可称网关，可参见图2中的判断网关24)。

流程环节关系用于描述流程实例中两个节点之间的连接关系，关于流程环节关系具体包括哪些信息，本公开的实施例不做限制，只要流程环节关系能够清楚描述两个节点之间连接关系即可。在一个实施例中，流程环节关系包括：业务流程模板编码、前环节编码、后环节编码和关系类型；其中，前环节编码和后环节编码用于表示两个节点之间的连接关系。

其中，前环节编码是存在连接关系的两个节点中一个节点的环节编码，且该节点相较于另一个节点更靠近起始节点。后环节编码是存在连接关系的两个节点中一个节点的环节编码，且该节点相较于另一个节点更为远离起始节点。关于类型用于表示存在连接关系的两个节点之间连接关系的类型，例如，连接关系包括：连接线、附属节点(参见图2中的输出错误221)

在一个实施例中，流程环节定义模型存储的数据类型如下表3所示。

表3

序号	属性名称
		1	业务流程模板编码
2	环节编码
		3	环节类型
4	服务编码

在一个实施例中，流程环节关系模型存储的数据类型如下表4所示。

表4

序号	属性名称
		1	业务流程模板编码
2	前环节编码
		3	后环节编码
4	关系类型

在一个实施例中，根据流程环节定义模型和所述流程环节关系模型，生成业务流程模板中的各个执行路径的流程可以如图4所示，可以包括如下S401至S415。

S401，根据流程环节定义模型，获取开始节点并将开始节点的节点信息记入执行路径明细模型。

流程环节定义模型中记录有节点的环节类型，可以直接根据环节类型获取到开始节点。

在一个实施例中，节点信息可以包括执行路径编码、顺序号和环节编码。其中，执行路径编码用于唯一标识一个执行路径。顺序号可以表示节点在执行路径中的顺序，例如，参见图2，对于执行路径：开始节点21、节点22、输出错误221、结束节点23，开始节点21对应的顺序号可以为1，节点22对应的顺序号可以为2，输出错误221对应的顺序号可以为3，结束节点23对应的顺序号可以为4。

执行路径明细模型存储的数据类型可以如下表5所示。

表5

序号	属性名称
		1	执行路径编码
2	顺序号
		3	环节编码

S402，根据流程环节关系模型，获取开始节点的下一个节点，将该下一个节点标记为当前节点。

流程环节关系模型中记录有节点之间的连接关系，根据该连接关系，可以获取到与开始节点存在连接关系的下一个节点。

S403，将当前节点的节点信息记入执行路径明细模型。

S404，判断当前节点是否为已处理节点，若当前节点不是已处理节点则进行S405，若当前节点是已处理节点则进行S412。

可以通过确定当前节点的环节编码是否记录在已处理列表中，来判断当前节点是否为已处理节点，当节点的环节编码记录在已处理列表中，则节点为已处理节点；当节点的环节编码未记录在已处理列表中，则节点不是已处理节点。

其中，一个业务流程模板对应一个已处理列表，节点经过处理后该节点的环节编码会登记在该已处理列表。

S405，将当前节点的环节编码记入已处理列表。

S406，判断当前节点是否为结束节点，若不是结束节点则进行S407，若是结束节点则进行412。

流程环节定义模型中记录有节点的环节类型，根据当前节点的环节编码，可以从流程环节定义模型中查询出该节点的环节类型，进而可以根据节点的环节类型确定节点是否为结束节点。

S407，判断当前节点具有的下一个节点的数量是否大于1，若大于1则进行S408，若不大于1则进行S409。

流程环节关系模型中记录有节点之间的连接关系，根据该连接关系，可以确定出在当前节点的环节变为为前环节编码时，具有的后环节编码的数量，进而可以确定出当前节点具有的下一个节点的数量。也就是说，根据当前节点的环节编码查询流程环节关系模型，可以确定该环节编码对应的后环节编码的数量，进而确定下一个节点的数量。

S408，将当前分支节点更新为当前节点，并进行S410。

S409，判断当前节点具有的下一个节点的数量是否等于1，等于1则进行S410，不等于1则进行S411。

其中，S409的具体实现方式与S407的实现方式相同。

S410，获取当前节点的下一个节点，将该下一个节点作为当前节点，进行S403。

将当前节点的环节编码作为前环节编码，查询流程环节关系模型，可以确定出相应的后环节编码，进而可以获取到下一个节点。

S411，结束。

若S409执行后直接执行S411，则表示一个执行路径的最后一个节点不是结束节点，也就是说，业务流程模板存在错误。

S412，根据已处理列表和流程环节关系模型，判断当前分支节点的多个下一个节点中是否存在未处理的节点，若存在未处理的节点则进行S413，若不存在未处理的节点则进行S414。

通过流程环节关系模型，可以查询出出当前分支节点的环节编码对应的多个后环节编码；再通过已处理列表，查询是否已经记录了该多个后环节编码，若已记录了该多个后环节编码，则确定当前分支节点不存在未处理的节点；若该多个后环节编码中存在未被已处理列表记录的后环节编码，则确定当前分支节点存在未处理的节点。

S413，根据已处理列表和流程环节关系模型，获取当前分支节点的下一个节点中未处理过的节点作为当前节点，并进行S403。

S414，判断当前分支节点是否存在上一个分支节点，若存在则进行S415，若不存在则进行S411。

S415，将当前分支节点更新为上一个分支节点，并进行S412。

根据所述流程环节定义模型和所述流程环节关系模型，生成所述业务流程模板中的各个执行路径的方式，可以得到一个业务流程模板完整的流程实例，该完成的流程实例是对业务流程进行全路径覆盖测试的基础。

在一个实施例中，对于业务流程模板，执行业务流程测试的设备还可以在生成业务流程实例后，将业务流程模板编码及相应的执行路径编码存储在业务流程实例模型中。执行路径编码用于唯一标识一个执行路径，业务流程模板编码用于唯一标识一个业务流程模板。一个业务流程模板中可能存在一个执行路径或存在多个执行路径，相应地，一个业务流程模板编码可以对应一个或多个执行路径编码。

其中，业务流程实例模型存储的数据类型可以如下表6所示。

表6

序号	属性名称
		1	业务流程模板编码
2	执行路径编码

通过业务流程实例模型和执行路径明细模型，可以实现对执行路径的存储，并能够记录哪些执行路径对应同一个业务流程模板，进而可以确定哪些执行路径可以组成一个流程实例。

下面对每一执行路径中的节点与服务实例之间的对应关系进行介绍。在一个实施例中，该对应关系的具体实现可以基于流程环节定义模型。流程环节定义模型中对应存储有环节编码和服务编码，也就是说，通过环节编码查询流程环节定义模型，可以得到相应的服务编码，进而确定出服务编码对应的服务实例。

仍然以图2对应的业务流程模板为例，且服务1、服务2和服务3能够返回的结果可以如表7所示。

表7

则根据该服务返回的结果，以及图2所示的业务流程模板，则生成的执行路径可以如下表8所示。

表8

需要说明的是，在图2中并未画出服务2和服务3的正常、异常和超时的返回结果及对应执行路径，以及未画出服务1的异常和超时的返回结果及对应执行路径。

对生成流程实例进行说明后，下面对如何利用流程实例测试业务流程进行说明。

S103，获取每一执行路径的输入参数，基于流程实例分别对每一输入参数进行处理，记录每一输入参数在流程实例中的处理路径。

其中，每一执行路径的输入参数是每一执行路径中开始节点后第一个节点的输入参数。以图2所示的业务流程模板为例，对于执行路径：开始节点21、节点22、判断节点(判断网关)24、节点25、结束节点26，则输入参数为输入到开始节点21中服务1的参数，且该输入参的设计需要使得服务1返回的结果为结果11。对于执行路径：开始节点21、节点22、判断节点(判断网关)24、节点27、结束节点28，输入参数依旧为输入到开始节点21中服务1的参数，且该输入参的设计需要使得服务1返回的结果为结果12。

根据预设的输入参数，按照业务流程模板预期的处理过程，则根据流程实例对输入参数进行处理的过程中，处理该输入参数的路径应该是执行路径，而实际进行测试时，由于业务流程设计的不合理性等错误，导致对输入参数处理的并非按照预期的流程进行，从而导致基于流程实例对输入参数进行处理，并记录得到的处理路径与该输入参数对应的执行路径不同。执行路径与处理路径的不同也就说明了该执行路径存在问题。

在一个实施例中，基于流程实例分别对每一输入参数进行处理，记录每一输入参数在流程实例中的处理路径，可以包括：获取上下文模型，上下文模型记录有流程实例中每一节点的输入参数与输出参数的对应关系；将每一执行路径的输入参数对应的节点作为各自执行路径中的当前节点，并对于每一执行路径执行进行以下处理：根据执行路径的输入参数，从上下文模型中获取当前节点的输出参数，并将当前节点的输出参数作为流程实例中下一个节点的输入参数，直至下一个节点为结束节点时记录服务实例中处理输入参数的处理路径。

在一个实施例中，上下文模型存储的数据类型可以如表9所示。

表9

序号	属性名称
		1	流程实例标识
2	环节编码
		3	输入编码
4	输出编码

表9中，输入编码可以是能够被服务直接处理的数据，也就是说，输入编码与输入参数相同；或者，输入编码也可以是用于唯一标识该输入参数的编码，也就是说，输入编码与输入参数之间存在对应关系。输出编码可以是能够被服务直接处理的数据，也就是说，输出编码与输出参数相同；或者，输出编码也可以是用于唯一标识该输出参数的编码。

表9中的输出编码与表2中的结果编码的格式可以相同，也可以不同，本公开的实施例对此不做限制。

表9中，流程实例标识用于唯一标识流程实例。

在一个实施例中，上下文模型中未记录该流程实例中每一节点的输入参数与输出参数之间的对应关系，在获取上下文模型之前，还需要向上下文模型中登记该流程实例中每一节点的上下文信息，该上下文信息包括：输入编码、输出编码、执行路径编码和环节编码，以使上下文模型中记录有流程实例中每一节点的输入参数与输出参数的对应关系。

在一个实施例中，如图5所示，向上下文模型中登记该流程实例中每一节点的上下文信息的过程可以包括S501至S505。

S501，获取流程实例中每一执行路径下每一节点的输入参数和输出参数。

其中，获取该输入参数和输出参数的方式可以是，由执行业务流程测试方法的设备直接生成，也可以是由人工通过该设备的输入装置，向设备中输入该输入参数与输出参数，还可以是通过网络从其他设备中获取该输入参数和输出参数。

S502，获取流程实例中每一执行路径的执行路径编码，得到至少一个执行路径编码。

S503，根据该至少一个执行路径编码，分别判断各个执行路径是否存在路径明细，若存在路径明细则进行S504，若不存在路径明细则进行S505。

S504，根据执行路径中每一节点的输入参数和输出参数，向上下文模型中登记上下文信息。

在输入参数与输入编码相同的情况下，则直接将输入参数作为输入编码登记在上下模型中；在输入参数与输入编码不同，即输入编码用于唯一标识输入参数，则根据输入参数查询输入参数与输入编码之间的对应关系，从而得到输入编码，再将输入编码登记在上下文模型中。在输出参数与输出编码相同的情况下，则直接将输出参数作为输出编码登记在上下模型中；在输出参数与输出编码不同，即输出编码用于唯一标识输出参数，则根据输出参数查询输出参数与输出编码之间的对应关系，从而得到输出编码，再将输出编码登记在上下文模型中。

在向上下文模型中登记输入编码和输出编码时，将节点的环节编码以及流程实例的流程实例标识一并登记在上下文模型中。

S505，结束。

其中，若不存在路径明细，则不向上下文模型中登记执行路径下每一节点的上下文信息。不存在路径明细的情况下，表示执行路径尚未生成或存在错误，需要重新生成该执行路径。

需要说明的是，S501可以在S504之前的任何一个步骤执行，例如，S501可以在S503执行后再执行，也可以在S502执行后执行，本公开的实施例不做限制。

在一个实施例中，S501在S503之后执行时，可以将获取流程实例中每一执行路径下每一节点的输入参数和输出参数，替换为，获取存在路径明显的执行路径中每一节点的输入参数和输出参数。

完成上下文模型的获取后，在对流程实例中的执行路径进行测试的过程中，可以从利用上下问模型，获取到执行路径中第一个节点对输入参数进行处理后的输出参数，之后，将该输入参数作为下一个节点的输入参数，再利用上下文模型获取新的输出结果，直至执行结束后，即可得到流程实例处理输入参数的处理路径。

S104，根据每一输入参数对应的执行路径与处理路径，生成第一测试结果。

在一个实施例中，根据每一输入参数对应的执行路径与处理路径，生成第一测试结果，可以包括：比较每一输入参数对应的执行路径与处理路径之间的异同，得到每一对执行路径与处理路径之间的第一异同关系；根据第一异同关系，生成第一测试结果。

若执行路径与处理路径不同，则该执行路径对应的第一测试结果为不通过。若执行路径与处理路径相同，执行路径对应的第一测试结果为通过。

在一个实施例中，本公开实施例中的业务流程测试方法，还包括对于每一执行路径的输入参数进行如下处理：记录输入参数按照流程实例处理后得到的第一输出参数；获取第二输出参数，第二输出参数是预设输入参数按照流程实例处理后得到结果；根据第一输出参数和第二输出参数，生成第二测试结果。

对于每一执行路径，设定出输入到流程实例的输入参数后，预期该输入参数在流程实例中的处理路口经即为该执行路径，从而得到的结果也预期的输出参数。而实际由于业务流程设计的不合理等问题，从而导致输入参数在流程实例中的处理路径与执行路径可能不同，即便处理路径与执行路径相同，也可能由于执行路径中服务处理逻辑的不合理性等原因，导致输入参数经流程实例处理后得到的输出参数与预设的输出参数不同。而在处理路径与执行路径不同时，得到的输出参数更容易与预设的输出参数不同。

在一个实施例中，根据第一输出参数和第二输出参数，生成第二测试结果，可以包括：比较第一输出参数和第二输出参数之间的异同，得到第一输出参数和第二输出参数第二异同关系；根据该第二异同关系，生成第二测试结果。

若第一输出参数和第二输出参数不同，则该执行路径对应的第二测试结果为不通过。若第一输出参数和第二输出参数相同，执行路径对应的第二测试结果为通过。

在一个实施例中，对于一个执行路径，第一测试结果与第二测试结果中只要有一个不同过，则该执行路径的测试结论为测试不通过，则在生成执行路径的测试结论时，可以在确定第一测试结果为不通过的情况下确定执行路径的测试结论为不通过，或者在第一测试结果为通过的情况下，再根据第二测试结果确定执行路径的测试结论是否通过。或者，可以在执行路径的第二测试结果为通过的情况下，再根据第一测试结果确定执行路径的测试结论是否通过。

以先在执行路径的第一测试结果为通过的情况下，再根据第二测试结果确定执行路径的测试结论是否通过为例，在一个实施例中，如图6所示，确定执行路径测试结论的过程可以包括S601至S60

S601，获取执行路径对应的处理路径。

S602，获取执行路径的路径明细。

可以用过执行路径的执行路径编码从执行路径明细模型中获取该路径明细，路径明细即执行路径下各个节点的环节编码及顺序号。

S603，根据路径明细，判断处理路径与执行路径是否相同，若相同则进行S604，若不相同则进行S607。

S604，获取第一输出参数和第二输出参数。

S605，判断第一输出参数和第二输出参数是否相同，若相同则进行S606，若不相同则进行S607。

S606，输出测试通过，结束。

S607，输出测试不通过，结束。

在一个实施例中，得到对流程实例的测试结论后将该测试结论存储在测试流程实例模型中，测试流程实例模型存储的数据类型可以如下表10所示。

表10

序号	属性名称
		1	流程实例标识
2	业务流程模板编码
		3	执行路径编码
4	测试开始时间
		5	测试结束时间
6	测试状态
		7	测试结论

其中，测试状态包括测试正在执行中、执行结束等。测试结论为通过或不通过。其中，测试状态、测试开始时间、测试结束时间皆可以在测试流程实例模型中存储，也可不存储。

需要说明的是，若只分析执行路径与处理路径之间的异同，而不考虑实际输出参数与预设的输出参数之间的异同，则测试流程实例模型中存储的测试结论即为第一测试结果。若只分析实际输出参数与预设的输出参数之间的异同，而不考虑执行路径与处理路径之间的异同，则测试流程实例模型中存储的测试结论即为第二测试结果。若分析执行路径与处理路径之间的异同，也考虑实际输出参数与预设的输出参数之间的异同，则测试流程实例模型中存储的测试结论根据第一测试结果和第二测试结果确定。

在一个实施例中，本公开的实施例中的业务流程测试方法，还包括对业务流程的完整性进行测试。其中，完整性测试包括测试业务流程中各个服务在输出超时、错误、异常等情况下是否存在对应的执行路径。对业务流程进行完整性测试，可以保证测试通过的业务流程具有完整的处理逻辑，能够处理各种非正常返回结果。

如图7所示，对业务流程的完整性进行测试的过程可以包括S701至S702。

S701，获取流程实例中每一服务实例的至少一个非正常输出结果，每一非正常输出结果为输出异常、输出超时和输出错误中的一个。

服务返回结果模型中存储有每一服务的各个非正常输出结果。流程环节定义模型中存储有环节编码及服务编码。获取流程实例中每一服务实例的至少一个非正常输出结果，可以包括：根据流程实例中每一节点的环节编码，从流程环节定义模型中获取环节编码对应的服务编码；再根据服务编码从服务返回结果模型中获取对应的非正常输出结果(非正常输出结果包括：服务结果类型为异常、超时、错误的结果编码)，得到每一服务实例的至少一个非正常输出结果。

S702，测试每一服务实例的每一非正常输出结果是否存在对应的执行路径，得到第三测试结果。

在一个实施例中，执行路径明细模型存储的数据类型可以如下表11所示。

表11

序号	属性名称
		1	执行路径编码
2	顺序号
		3	环节编码
4	结果编码

其中，结果编码用于唯一标识节点的输出结果，在执行路径明细模型中记录结果编码，用于记录在节点输出哪些结果的情况下，会按照该执行路径来处理数据。

在一个实施例中，测试每一服务实例的每一非正常输出结果是否存在对应的执行路径，得到第三测试结果，可以包括对每一非正常数据结果进行如下处理：根据该流程实例对应的业务流程模板编码，获取到该流程实例下各个执行路径的执行路径编码；再基于执行路径编码、服务所在节点的环节编码，查询执行路径明细模型中对应的结果编码，若查询到的结果编码中不存在与非正常输出结果相同的结果编码，则在第三测试结果中记录该非正常输出结果不存在对应的执行路径。

若查询到的结果编码中不存在与非正常输出结果相同的结果编码，则表示该非正常输出结果存在对应的执行路径，并且该结论也可以记载在第三测试结果中，也可以不记载。

为便于理解对业务流程的完整性进行测试的过程，下面将结合图8进一步说明。

S801，获取环节-服务编码列表。

其中，环节-服务编码列表中记录有流程实例中每一服务的服务编码及服务所在节点的环节编码，一个服务对应的环节编码与服务编码组成环节-服务编码列表中的一条记录。

流程环节定义模型中存储有流程实例对应业务流程模板编码，以及环节编码及服务编码，利用流程环节定义模型可以建立该环节-服务编码列表。

S802，判断环节-服务编码列表中是否存在下一条记录，若存在则进行S803，若不存在则进行S809。

S803，获取下一条记录。

S804，根据服务返回结果模型，获取该下一条记录中的服务编码对应的至少一个非正常输出结果。

S805，判断是否存在下一个非正常输出结果，若存在则进行S806，若不存在则进行S802。

S805的目的在于判断现在至少一个非正常输出结果中是否存在未进行检测过从非正常输出结果。

S806，获取下一个非正常输出结果。

S807，检测该下一个非正常输出结果是否存在对应的执行路径，若存在则进行S808，若不存在则进行S805。

S808，在第三测试结果中记录该非正常输出结果不存在对应的执行路径，并进行S805。

S809，结束。

基于同一发明构思，本公开实施例中还提供了一种业务流程测试装置，如下面的实施例所述。由于该装置实施例解决问题的原理与上述方法实施例相似，因此该装置实施例的实施可以参见上述方法实施例的实施，重复之处不再赘述。

图9示出本公开一个实施例中的业务流程测试装置示意图，如图9所示，该装置包括：第一获取模块901，用于获取业务流程模板；生成模块902，用于生成业务流程模板的流程实例，流程实例包括业务流程模板的各个执行路径，其中，各个执行路径中的服务实例基于服务接口协议生成；获取及处理模块903，用于获取每一执行路径的输入参数，基于流程实例分别对每一输入参数进行处理，记录每一输入参数在流程实例中的处理路径；生成模块902，还用于根据每一输入参数对应的执行路径与处理路径，生成第一测试结果。

在本公开的一个实施例中，生成模块902，用于获取业务流程模板中每一服务的服务实例；获取业务流程模板中的各个执行路径；获取每一执行路径中的节点与服务实例之间的对应关系；根据服务实例、各个执行路径和对应关系，生成流程实例。

在本公开的一个实施例中，生成模块902，用于获取业务流程模板中每一服务的服务接口协议；生成每一服务接口协议对应的服务的基础信息，并将基础信息登记在服务定义模型中；根据服务接口协议，生成每一服务的多种服务返回结果实例，并将每种服务返回结果实例登记在服务返回结果模型中；根据服务定义模型和服务返回结果模型，生成每一服务的服务实例。

在本公开的一个实施例中，生成模块902，用于解析业务流程模板，得到各个节点的流程环节信息及流程环节关系；将各个流程节点的流程环节信息登记在流程环节定义模型中，以及将各个节点的流程环节关系登记在流程环节关系模型中；根据流程环节定义模型和流程环节关系模型，生成业务流程模板中的各个执行路径。

在本公开的一个实施例中，获取及处理模块903，用于获取上下文模型，上下文模型记录有流程实例中每一节点的输入参数与输出参数的对应关系；将每一执行路径的输入参数对应的节点作为各自执行路径中的当前节点，并对于每一执行路径执行进行以下处理：根据执行路径的输入参数，从上下文模型中获取当前节点的输出参数，并将当前节点的输出参数作为流程实例中下一个节点的输入参数，直至下一个节点为结束节点时记录服务实例中处理输入参数的处理路径。

在本公开的一个实施例中，装置还包括：处理模块904，用于对于每一执行路径的输入参数进行如下处理：记录输入参数按照流程实例处理后得到的第一输出参数；获取第二输出参数，第二输出参数是预设输入参数按照流程实例处理后得到结果；根据第一输出参数和第二输出参数，生成第二测试结果。

在本公开的一个实施例中，获取模块901，还用于获取流程实例中每一服务实例的至少一个非正常输出结果，每一非正常输出结果为输出异常、输出超时和输出错误中的一个；装置还包括：测试模块905，用于测试每一服务实例的每一非正常输出结果是否存在对应的执行路径，得到第三测试结果。

所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

下面参照图10来描述根据本公开的这种实施方式的电子设备1000。图10显示的电子设备1000仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图10所示，电子设备1000以通用计算设备的形式表现。电子设备1000的组件可以包括但不限于：上述至少一个处理单元1010、上述至少一个存储单元1020、连接不同系统组件(包括存储单元1020和处理单元1010)的总线1030。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元1010执行，使得所述处理单元1010执行本说明书上述“具体实施方式”部分中描述的根据本公开各种示例性实施方式的步骤。

存储单元1020可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)1021和/或高速缓存存储单元1022，还可以进一步包括只读存储单元(ROM)1023。

存储单元1020还可以包括具有一组(至少一个)程序模块1025的程序/实用工具1024，这样的程序模块1025包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线1030可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备1000也可以与一个或多个外部设备1040(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备1000交互的设备通信，和/或与使得该电子设备1000能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口1050进行。并且，电子设备1000还可以通过网络适配器1060与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图10所示，网络适配器1060通过总线1030与电子设备1000的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备1000使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施方式的方法。

在本公开的示例性实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质可以是可读信号介质或者可读存储介质。其上存储有能够实现本公开上述方法的程序产品。在一些可能的实施方式中，本公开的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“具体实施方式”部分中描述的根据本公开各种示例性实施方式的步骤。

本公开中的计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

在本公开中，计算机可读存储介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可选地，计算机可读存储介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

在具体实施时，可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

在本公开的示例性实施例中，还提供了一种计算机程序产品，计算机程序产品包括计算机程序或计算机指令，计算机程序或计算机指令由处理器加载并执行，以使计算机实现本说明书上述“具体实施方式”部分中描述的根据本公开各种示例性实施方式的步骤。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

通过以上实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围由所附的权利要求指出。

Claims

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

获取业务流程模板；

生成所述业务流程模板的流程实例，所述流程实例包括所述业务流程模板的各个执行路径，其中，各个执行路径中的服务实例基于服务接口协议生成；

获取每一执行路径的输入参数，基于所述流程实例分别对每一输入参数进行处理，记录每一输入参数在所述流程实例中的处理路径；

根据每一输入参数对应的执行路径与处理路径，生成第一测试结果。

2.根据权利要求1所述的方法，其特征在于，所述生成所述业务流程模板的流程实例，包括：

获取所述业务流程模板中每一服务的服务实例；

将各个节点的流程环节信息登记在流程环节定义模型中；

获取每一执行路径中的节点与服务实例之间的对应关系；

根据所述服务实例、各个执行路径和所述对应关系，生成流程实例。

3.根据权利要求2所述的方法，其特征在于，所述获取所述业务流程模板中每一服务的服务实例，包括：

获取所述业务流程模板中每一服务的服务接口协议；

生成每一服务接口协议对应的服务的基础信息，并将所述基础信息登记在服务定义模型中；

根据服务接口协议，生成每一服务的多种服务返回结果实例，并将每种服务返回结果实例登记在服务返回结果模型中；

根据所述服务定义模型和所述服务返回结果模型，生成每一服务的服务实例。

4.根据权利要求2所述的方法，其特征在于，所述将各个节点的流程环节信息登记在流程环节定义模型中，包括：

解析所述业务流程模板，得到各个节点的流程环节信息及流程环节关系；

将各个流程节点的流程环节信息登记在流程环节定义模型中，以及将各个节点的流程环节关系登记在流程环节关系模型中；

根据所述流程环节定义模型和所述流程环节关系模型，生成所述业务流程模板中的各个执行路径。

5.根据权利要求1所述的方法，其特征在于，所述基于所述流程实例分别对每一输入参数进行处理，记录每一输入参数在所述流程实例中的处理路径，包括：

获取上下文模型，所述上下文模型记录有所述流程实例中每一节点的输入参数与输出参数的对应关系；

将每一执行路径的输入参数对应的节点作为各自执行路径中的当前节点，并对于每一执行路径执行进行以下处理：根据执行路径的输入参数，从所述上下文模型中获取当前节点的输出参数，并将当前节点的输出参数作为所述流程实例中下一个节点的输入参数，直至下一个节点为结束节点时记录所述服务实例中处理输入参数的处理路径。

6.根据权利要求1所述的方法，其特征在于，还包括：对于每一执行路径的输入参数进行如下处理：

记录输入参数按照所述流程实例处理后得到的第一输出参数；

获取第二输出参数，所述第二输出参数是预设输入参数按照所述流程实例处理后得到结果；

根据所述第一输出参数和所述第二输出参数，生成第二测试结果。

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

获取所述流程实例中每一服务实例的至少一个非正常输出结果，每一非正常输出结果为输出异常、输出超时和输出错误中的一个；

测试每一服务实例的每一非正常输出结果是否存在对应的执行路径，得到第三测试结果。

8.一种业务流程测试装置，其特征在于，包括：

第一获取模块，用于获取业务流程模板；

生成模块，用于生成所述业务流程模板的流程实例，所述流程实例包括所述业务流程模板的各个执行路径，其中，各个执行路径中的服务实例基于服务接口协议生成；

获取及处理模块，还用于获取每一执行路径的输入参数，基于所述流程实例分别对每一输入参数进行处理，记录每一输入参数在所述流程实例中的处理路径；

所述生成模块，还用于根据每一输入参数对应的执行路径与处理路径，生成第一测试结果。

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

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1～7中任意一项所述的业务流程测试方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1～7中任意一项所述的业务流程测试方法。