CN114721930A - 一种数据处理方法、装置、设备及介质 - Google Patents

Abstract

本申请实施例提供一种数据处理方法、装置、设备及介质。其中的方法包括：获取需求数据；根据需求数据构建有向图；从有向图中探索得到目标用例路径，目标用例路径是指经过有向图中的目标关键业务节点的路径；获取目标关键业务节点所使用的业务规则，业务规则包括多个规则因子，多个规则因子相互独立；对多个规则因子进行级联展开处理，得到目标测试用例的前置条件。采用本申请实施例能够有效控制前置条件的数量。

Description

一种数据处理方法、装置、设备及介质

技术领域

本申请涉及计算机技术领域，具体涉及一种数据处理方法、装置、设备及计算机可读存储介质。

背景技术

软件测试在任意一款软件产品发布之前都是必不可少的步骤，如何编写测试用例用来进行软件测试显得尤为重要。

现有技术中需要对待测试业务的规则进行全展开，得到测试用例的所有前置条件，并为每一种前置条件生成相对应的测试用例，这使得生成的测试用例覆盖所有业务情况，丰富测试功能。但实践发现，生成的测试用例数量较多时会增加测试用例的维护成本。

发明内容

本申请实施例提供一种数据处理方法、装置、设备及介质，能够有效控制前置条件的数量。

一方面，本申请实施例提供一种数据处理方法，该方法包括：

获取需求数据，需求数据包括被测业务的业务路径及业务路径下的业务操作步骤；

根据需求数据构建有向图，有向图包括业务节点和边，业务节点用于表示被测业务中的业务操作步骤，边用于表示被测业务中的业务操作步骤之间的跳转逻辑；

从有向图中探索得到目标用例路径，目标用例路径是指经过有向图中的目标关键业务节点的路径；目标用例路径用于表示被测业务的一个业务操作序列，且目标用例路径用于生成目标测试用例；

获取目标关键业务节点所使用的业务规则，业务规则包括多个规则因子，多个规则因子相互独立；

对多个规则因子进行级联展开处理，得到目标测试用例的前置条件。

另一方面，本申请实施例提供一种数据处理装置，该装置包括：

获取单元，用于获取需求数据，需求数据包括被测业务的业务路径及业务路径下的业务操作步骤；

处理单元，用于根据需求数据构建有向图，有向图包括业务节点和边，业务节点用于表示被测业务中的业务操作步骤，边用于表示被测业务中的业务操作步骤之间的跳转逻辑；以及，从有向图中探索得到目标用例路径，目标用例路径是指经过有向图中的目标关键业务节点的路径；目标用例路径用于表示被测业务的一个业务操作序列，且目标用例路径用于生成目标测试用例；

获取单元，还用于获取目标关键业务节点所使用的业务规则，业务规则包括多个规则因子，多个规则因子相互独立；

处理单元，还用于对多个规则因子进行级联展开处理，得到目标测试用例的前置条件。

在一种实施方式中，目标关键业务节点所使用的业务规则包括M个规则因子，M为正整数；

处理单元，具体用于：

从M个规则因子中选取第i个规则因子；

保持述M个规则因子中除选取的第i个规则因子之外的其余规则因子不展开，并对M个规则因子中选取第i个规则因子进行展开处理，得到第i个规则因子的x_i种规则项；

重复上述步骤，直至M个规则因子均被展开处理为止；

根据述M个规则因子中展开处理得到的规则项，生成述目标测试用例的P种前置条件；

其中，设M个规则因子中第i个规则因子包括x_i种规则项，则P的值为

在一种实施方式中，处理单元，还用于：

从目标用例路径中提取目标用例步骤；

基于目标用例步骤和前置条件，生成与目标用例路径相对应的目标测试用例。

在一种实施方式中，处理单元，具体用于：

从目标用例路径表示的业务操作序列中提取一组或多组组合步骤；

将一组或多组组合步骤形成的序列确定为目标用例步骤；

其中，任一组组合步骤用于表示被测业务中的用户与被测业务之间的一个界面交互行为，任一组组合步骤包括第一业务操作步骤和第二业务操作步骤，第一业务操作步骤是指由被测业务向用户提供交互界面的步骤，第二业务操作步骤是指由用户在交互界面中产生交互行为，并由被测业务对交互行为进行感知反馈的步骤。

在一种实施方式中，被测业务包括N个业务操作步骤；有向图包括N个业务节点；处理单元，具体用于：

将被测业务的第i个业务操作步骤确定为有向图中的第i个业务节点，将被测业务的第j个业务操作步骤确定为有向图中的第j个业务节点；以及，

将第i个业务操作步骤与第j个业务操作步骤之间的跳转逻辑确定为有向图中第i个业务节点与第j个业务节点之间的边；

依据确定的业务节点和边构建有向图；

其中，N为大于1的整数，i、j均为正整数，并且i≤N，j≤N。

在一种实施方式中，处理单元，还用于：

遍历有向图中的业务节点，得到用例路径集合，用例路径集合中包含至少一条用例路径，每一条用例路径分别用于表示被测业务的一个业务操作序列；目标用例路径是用例路径集合中经过有向图中的目标关键业务节点的路径；

其中，用例路径集合中的用例路径的类型包括主用例路径或关键用例路径，目标用例路径的类型为关键用例路径。

在一种实施方式中，业务路径包括基本业务路径，基本业务路径下包含N个业务操作步骤；M为正整数；有向图还包括起始节点和结束节点；处理单元，还用于：

从起始节点开始，按照基本业务路径下的N个业务操作步骤的执行顺序，依次遍历有向图中的N个业务节点，直至结束节点停止；N个业务节点与基本业务路径下的N个业务操作步骤一一对应；

将穿过起始节点、N个业务节点以及结束节点的遍历路径确定为主用例路径。

在一种实施方式中，目标用例路径的用例类型是关键用例路径；有向图还包括起始节点和结束节点；处理单元，具体用于：

在有向图中确定目标关键业务节点；

采用最短路径图遍历算法在有向图中遍历查找起始节点与目标关键业务节点之间的第一路径；以及，在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径；

将第一路径与第二路径拼接形成的路径确定为目标用例路径。

在一种实施方式中，处理单元，具体用于：

若目标关键业务节点的类型为第一类型，则在有向图中探索得到主用例路径，沿结束节点的方向在有向图中探索从目标关键业务节点返回至主用例路径，并沿主用例路径到达结束节点的第二路径；或者，

若目标关键业务节点的类型为第一类型，采用最短路径图遍历算法在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径；或者，

若目标关键业务节点的类型为第二类型，则将目标关键业务节点与结束节点相连接形成的路径确定为第二路径；

其中，若目标关键业务节点用于表示由被测业务向被测业务中的用户提供交互界面的业务操作步骤，则目标关键业务节点的类型为第一类型；若目标关键业务节点用于表示由用户在交互界面中产生交互行为，并由被测业务对交互行为进行感知反馈的业务操作步骤，则目标关键业务节点的类型为第二类型。

在一种实施方式中，用例路径集合包括第一用例路径集合和第二用例路径集合，第一用例路径集合和第二用例路径集合中均包含一条或多条用例路径，其中，第一用例路径集合中的用例路径用于生成验证业务操作行为的测试用例，第二用例路径集合中的用例路径用于生成验证业务规则的测试用例；处理单元，还用于：

对第一用例路径集合和第二用例路径集合进行优化处理。

在一种实施方式中，处理单元，具体用于：

若第一用例路径集合与第二用例路径集合包含相同的用例路径，则在第一用例路径集合中删除相同的用例路径。

在一种实施方式中，处理单元，具体用于：

获取需求描述文档，需求描述文档用于描述被测业务的业务操作流程，且需求描述文档为第一格式的文档；

对需求描述文档进行解析，得到需求数据，需求数据为第二格式的数据。

另一方面，本申请实施例提供一种数据处理设备，该设备包括：

处理器，适于执行计算机程序；

计算机可读存储介质，计算机可读存储介质中存储有计算机程序，计算机程序被处理器执行时，实现如上述的数据处理方法。

另一方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序适于由处理器加载并执行如上述的数据处理方法。

另一方面，本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述的数据处理方法。

本申请实施例中，可获取目标关键业务节点所使用的业务规则，并对业务规则包含的相互独立的这一部分规则因子进行级联展开处理，得到目标测试用例的前置条件。相比于将目标关键业务节点所使用的业务规则全部展开而言，可较好地控制目标测试用例的前置条件的数量，使得最终生成的目标测试用例的数量可控，降低目标测试用例的维护成本。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了本申请一个示例性实施例提供的一种系统用例的示意图；

图2a示出了本申请一个示例性实施例提供的一种数据处理系统的架构示意图；

图2b示出了本申请一个示例性实施例提供的一种数据处理架构的架构示意图；

图2c示出了本申请一个示例性实施例提供的一种需求管理模块的数据处理的时序示意图；

图3a示出了本申请一个示例性实施例提供的一种上传需求描述文档的界面示意图；

图3b示出了本申请一个示例性实施例提供的一种查看需求描述文档的处理流程的示意图；

图3c示出了本申请一个示例性实施例提供的一种查阅业务路径步骤的界面示意图；

图3d示出了本申请一个示例性实施例提供的一种查阅补充约束的界面示意图；

图3e示出了本申请一个示例性实施例提供的一种修改需求描述文档的界面示意图；

图4示出了本申请一个示例性实施例提供的一种测试用例的示意图；

图5示出了本申请一个示例性实施例提供的一种数据处理方法的流程示意图；

图6a示出了本申请一个示例性实施例提供的一种有向图的示意图；

图6b示出了本申请一个示例性实施例提供的一种有向图的示意图；

图7示出了本申请一个示例性实施例提供的一种确定用例路径集合的流程图；

图8示出了本申请一个示例性实施例提供的一种业务规则表的示意图；

图9示出了本申请一个示例性实施例提供的一种引用规则因子的示意图；

图10示出了本申请一个示例性实施例提供的另一种数据处理方法的流程示意图；

图11示出了本申请一个示例性实施例提供的一种数据处理装置的结构示意图；

图12示出了本申请一个示例性实施例提供的一种数据处理设备的结构示意图。

具体实施方式

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

下面先对本申请涉及的一些术语及概念进行说明：

本申请实施例涉及软件测试(Software Testing)，软件测试是软件开发过程中的一个重要的组成部分，是贯穿整个软件开发生命周期、对软件产品(包括阶段性产品)进行验证和确认的活动过程，其目的是尽快尽早地发现在软件产品中所存在的各种问题，例如软件产品与用户需求不一致的问题、软件产品的功能与预先定义的功能不一致的问题等等。通过对软件产品进行测试，能够及时发现软件产品中存在的问题，以便于开发人员对软件产品进行优化。

MBT(Model Based Testing，基于模型的测试)是属于软件测试领域的一种测试方法，基于MBT思想的软件测试过程大致可以包括以下四个步骤：①获取业务系统中被测业务的业务需求，此处的业务系统是指为用户提供各类互联网业务的系统，包括但不限于：支付业务系统、即时通讯业务系统、内容社交业务系统等等。被测业务可以是业务系统本身(例如某个支付业务系统本身是一个支付类的软件产品)，也可以是业务系统中的任一个功能业务(例如某个即时通讯业务系统同时支持支付、即时通讯、电子地图等多种互联网业务，被测业务可以是其中的任一种功能业务)。业务需求可以采用需求描述文档来描述，需求描述文档往往是根据被测业务的业务需求编写的，需求描述文档通常是关于被测业务的功能方面的描述。②对需求描述文档中的业务需求进行分析，得到相应的测试用例。③通过测试用例对业务系统中的被测业务进行测试。

其中，测试用例(Test Case)可以是指对一项特定的软件产品(例如可以是一个新开发的业务系统)进行测试任务的描述，体现测试方案、测试方法、测试技术和测试策略；测试用例可以包括测试目标、测试环境、输入数据、用例步骤、预期结果、测试脚本等等。换句话说，测试用例是为某个特殊目标(例如，测试业务的某种功能)而编制的一组测试输入、执行条件以及预期结果，用于核实业务系统中的被测业务是否满足业务需求。

在软件测试场景中，根据被测业务的需求描述文档生成测试用例时，涉及的最主要数据包括：基本业务路径、扩展业务路径、前置条件、后置条件以及补充约束，这些数据是对被测业务的需求描述文档进行处理得到的，这些数据组成被测业务的系统用例。其中，组成系统用例的各部分数据之间的关系示意图可参见图1，图1示出了本申请一个示例性实施例提供的一种系统用例的示意图；如图1所示，系统用例主要包括：执行者、涉众利益、业务路径(包括基本业务路径、扩展业务路径)、前置条件、后置条件以及补充约束等等。其中，执行者包括主执行者和辅助执行者，例如，在支付测试场景中，主执行者可以是指已注册相关支付信息的用户，辅助执行者可以是指用于付款的银行系统。涉众利益是指与被测业务相关联的多方用户，这些用户可能与被测业务之间存在利益关系，分析各用户之间的利益关系对于生成测试用例具有指导性作用。前置条件是指触发开始执行测试用例的条件，若同一业务路径引用不同的前置条件，则可生成不同的测试用例。后置条件规定了测试用例的执行结果应该满足的条件，即后置条件可以对测试用例的执行结果进行校验。业务路径存在多个业务操作步骤，各业务操作步骤按照业务操作流程形成业务路径，其中，当把业务操作步骤理解为一个业务节点时，路径由多个业务节点组成；每一业务路径可生成一个测试用例。业务路径下的基本业务路径是指被测业务的基础业务操作步骤之间相连形成的路径。以及，业务路径下的扩展业务路径是指被测业务的扩展业务操作步骤之间相连形成的路径，扩展业务路径能够提供更多的测试场景。

基于上述描述可知，除了基于业务路径生成各业务功能对应的测试用例以外，由于被测业务还涉及多种前置条件，当某一路径包含多种前置条件时，可以生成该路径对应的各前置条件关联的测试用例，以满足被测业务的测试需求。

但实践发现，对被测业务的所有前置条件进行展开生成测试用例时，测试产出投入比例较高，实用性较低。基于此发现，本申请实施例提供一种数据处理方案，该数据处理方案能够获取目标关键业务节点(即目标用例路径所穿过的业务节点)所使用的业务规则，并将业务规则包括的相互独立的那部分规则因子级联展开处理，得到目标测试用例的前置条件。上述过程中，只将相互独立的规则因子进行级联展开，避免对目标关键业务节点所使用的所有业务规则均进行展开，不仅能够维持测试任务需求，而且控制目标测试用例的前置条件的数量，减少目标测试用例的数量，提高测试产出投入比例，降低测试用例的维护成本。

上述描述的用于生成测试用例的数据处理方案可应用于数据处理系统。数据处理系统可参见图2a，图2a示出了本申请一个示例性实施例提供的一种数据处理系统的架构示意图，该数据处理系统包括终端201和服务器202，本申请实施例对终端201和服务器202的数量不作限定。其中，终端201可以是指用来接收需求描述文档以及展现需求数据、执行结果等数据的设备。终端201可以包括但不限于：PC(Personal Computer，个人计算机)、PDA(平板电脑)、手机、可穿戴智能设备等等；终端往往配置有显示装置，显示装置也可为显示器、显示屏、触摸屏等等，触摸屏也可为触控屏、触控面板等等。服务器202可以为终端201提供计算和应用服务支持。服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端201和服务器202之间可以通过有线通信或者无线通信方式进行直接或间接地连接，本申请在此不做限制。

如图2a所示，数据处理系统还包括用例生成系统，该用例生成系统用于执行本申请提供的数据处理方案以生成测试用例，该用例生成系统包括需求管理模块2021、特征管理模块2022、用例生成模块2023。在一种实现方式中，该用例生成系统可以部署在服务器202，由服务器202为用例生成系统提供软硬件环境，其中，硬件环境参数可包括但不限于服务器机型、内存、中央处理器、硬盘等等；软件环境参数可包括但不限于操作系统、数据库、Web服务器、编程语言、开源软件等等。上述硬件环境参数以及软件环境参数仅用于示例，实际应用场景中，用例生成系统部署的硬件环境参数和软件环境参数还可以为其他情况，本申请实施例对此不做限定。

用例生成系统及终端201之间的数据处理架构可参见图2b，图2b示出了本申请一个示例性实施例提供的一种数据处理架构的架构示意图，用例生成系统中各模块之间以及用例生成系统与终端之间进行数据交互以实现生成目标测试用例的过程可简要地描述为：首先，用户的终端201向需求管理模块2021输入被测业务的业务需求(或需求描述文档)，需求管理模块2021可以对业务需求进行结构化处理，得到需求数据；其次，特征管理模块2022从需求管理模块2021中提取需求描述文档的语料信息，并对语料信息进行特征化和分类处理。所谓需求描述文档是用于描述被测业务的业务操作流程、且为第一格式的文档；第一格式可以是指DOCX格式。以及，用例生成模块203从需求管理模块2021中提取需求数据，以及从特征管理模块2022中读取语料分类信息和冲突语料信息。所谓需求数据是对需求描述文档进行解析得到的、为第二格式的数据；第二格式可以是指json(JavaScript ObjectNotation，JS对象简谱)格式，是一种轻量级的数据交换格式。最后，用例生成模块2023基于从需求管理模块2021和特征管理模块2022读取的数据(即需求数据、语料分类信息和冲突语料信息)生成被测业务的目标测试用例。

下面对数据处理系统的各设备的功能进行较为详细的介绍，其中：

一、需求管理模块2021。需求管理模块用于将通过自然语言描述(如docx格式)的需求描述文档转换为计算机语言(如json格式)描述的需求数据。需求管理模块2021是一个典型的管理信息系统，该系统是B/S(Browser/Server)架构模式，即浏览器-服务器架构模式。采用这种架构模式使得只需要在终端上运行浏览器以及在服务器部署数据库，就可以让浏览器与数据库之间进行数据交互。这能够简化需求管理模块的开发、维护和使用。

在生成测试用例的场景中，需求管理模块2021的这种B/S架构模式支持通过浏览器接收用户上传的被测业务的测试数据，测试数据可以是指用户上传的DOCX格式的需求描述文档，也可以是指用户在浏览器提供的需求管理界面中配置的、生成测试用例的数据。其中，需求管理界面可以按照UML用例规约进行设计，用户在需求管理界面中配置时按照UML用例规范编写数据。UML是一种建模语言，通常是指用模型元素来组建整个系统的模型，模型元素包括系统中的类、类和类之间的关联类的实例相互配合实现系统的动态行为等。

值得一提的是，需求管理模块2021将第一格式的需求描述文档转换为第二格式的需求数据，并提供对这些需求数据的增删改查功能。下面结合需求管理模块2021的数据处理时序图来对上述描述的增删改查功能进行较为详细的阐述。请参见图2c，图2c示出了本申请一个示例性实施例提供的一种需求管理模块的数据处理的时序示意图；如图2c所示，数据处理时序包括三个数据处理周期，分别为：新增数据周期、查阅数据周期以及修改数据周期。其中，在新增数据周期内，用户可上传被测业务的需求内容；在查阅数据周期内，用户可对上传的被测业务的需求内容进行查看；在修改数据周期内，用户可对上传的被测业务的需求内容进行修改、删除等操作。此处的需求内容可以是指前述描述的需求数据、需求描述文档。

1)数据处理时序为新增数据周期。在新增数据周期内，用户上传需求描述文档的界面示意图可参见图3a，图3a示出了本申请一个示例性实施例提供的一种上传需求描述文档的界面示意图；如图3a所示，在服务界面中显示有需求描述文档的上传入口301；当上传入口301被触发时，显示文档选取页面，并从文档选取页面中选取需求描述文档；当服务界面中的确认选项302被选中时，表示上传当前选取的需求描述文档，则将需求描述文档从浏览器上传至需求管理模块2021，并在服务界面中显示上传进度(如上传50％、上传100％......)。相应的，后台实现新增需求描述文档的流程可包括但不限于：s11，用户将自然语言描述的需求描述文档通过浏览器上传至需求管理模块2021的逻辑层；逻辑层对需求描述文档进行解析以得到json格式描述的需求数据。s12，逻辑层将处理得到的需求数据的语料信息上传至特征管理模块，并接收特征管理模块返回的上传结果(如上传成功)；以及，逻辑层还将需求数据发送至处理层，以便于处理层将需求数据发送至数据库进行录入(即存储)。s13，逻辑层接收处理层返回的录入结果，并将录入结果返回给浏览器进行显示，以便于用户确认录入结果。另外，当上传需求描述文档之后，可对需求描述文档的处理流程进行查看，例如：查看需求描述文档的合法性等。请参见图3b，图3b示出了本申请一个示例性实施例提供的一种查看需求描述文档的处理流程的示意图；如图3b所示，用户通过触发“上一步”标识303或“下一步”标识304可对新增需求描述文档的各个处理步骤进行查看。

2)数据处理时序为查阅数据周期。在查阅数据周期内，用户查阅需求描述文档的界面示意图可参见图3c和图3d，图3c示出了本申请一个示例性实施例提供的一种查阅业务路径步骤的界面示意图；图3d示出了本申请一个示例性实施例提供的一种查阅补充约束的界面示意图；如图所示，在服务界面中显示被测业务对应的系统用例(可参见前述对系统用例的描述)，在服务界面中显示有涉众利益选项、前置条件选项、后置条件选项、业务路径步骤选项以及补充约束选项等等；当用户选中任意选项时，服务界面显示被选中的选项对应的内容，以满足用户查阅被测业务的多种业务内容的需求。例如：选中路径步骤选项时，在服务界面中显示基本业务路径和扩展业务路径。相应的，后台响应查阅需求描述文档的流程可包括但不限于：用户通过浏览器发起查询请求；需求管理模块的逻辑层响应查询请求，并向处理层发送数据获取请求；处理层从数据库中获取数据，并将数据返回给逻辑层；逻辑层将数据发送至浏览器，以便于浏览器显示数据。这能帮助用户对上传的需求描述文档的数据进行确定，使得系统在正确的需求数据的基础之上执行后续的生成测试用例的步骤，提高测试用例的正确性和完整性。

3)数据处理时序为修改数据周期。在修改数据周期内，用户修改需求描述文档的界面示意图可参见图3e，图3e示出了本申请一个示例性实施例提供的一种修改需求描述文档的界面示意图；如图3e所示，在服务界面中显示有修改选项305，且当前服务界面中显示有补充约束选项下业务规则的信息；当用户存在对业务规则的修改需求时，用户可选中修改选型305，此时服务界面中业务规则所在区域306为可编辑状态，用户在可编辑状态下支持用户对业务规则进行编辑。相应的，后台响应修改需求描述文档的流程可包括但不限于：接收用户通过浏览器发起修改请求，修改请求中携带修改数据；需求管理模块的逻辑层响应修改请求，并向特征管理模块上传修改数据；特征管理模块向逻辑层返回修改数据的上传结果；逻辑层还向处理层发送修改请求，以便于处理层能够对数据库中存储的历史数据进行更新(包括：数据更新、删除以及新增)；逻辑层接收处理层返回的更新结果，并将更新结果返回给网页浏览器，以便于用户能够确认本次修改操作是否成功，例如：当更新结果为更新失败时，用户可再次执行编辑操作，直至更新结果显示为更新成功。这能帮助用户便捷地完善业务数据，丰富业务需求。

综上述，需求管理模块在接收到第一格式的需求描述文档之后，还可以接收对该需求描述文档的查阅、修改等操作，并基于最终确定的需求描述文档生成第二格式(即json格式)的需求数据。示例性地：一种支付业务场景下的json格式的需求数据如下代码所示：

通过json格式表示需求数据，能够较好地描述需求数据中各个数据(即前置条件、后置条件、执行者、业务路径以及业务路径下的业务操作步骤等等)之间的结构化关系。

二、特征管理模块2022。特征管理模块2022用于辅助需求管理模块将自然语言描述的需求描述文档转换为计算机语言描述的需求数据；此外，特征管理模块还用于对需求描述文档进行冲突校验，以确保需求描述文档的可行性。特征管理模块可以从需求管理模块2021中提取需求描述文档的语料信息，并对语料信息进行特征处理和冲突处理，处理后的数据可作为生成测试用例的参考素材。其中，所谓特征处理可以理解为将语料信息进行特征化处理，经过特征化后的语料被打上分类标签，以便于为每一类别的语料信息分配不同的实现方式(如分配接口)。所谓冲突处理可以理解为分析语料信息之间的关系，将矛盾的、重复的语料信息打上冲突标签，以便于后续处理语料信息时，将这些冲突的语料信息进行过滤。

三、用例生成模块2023。用例生成模块2023用于对需求数据进行分析处理，进而生成测试用例。用例生成模块2023通过从需求管理模块2021和特征管理模块2022中提取被测业务的数据，来生成测试用例。正如前述所描述的，用于生成测试用例的最主要数据包括：基本业务路径、扩展业务路径、前置条件、后置条件以及补充约束。其中，基本业务路径和扩展业务路径下会有业务路径关联的补充约束，补充约束包括字段列表、业务规则、非功能需求以及设计约束等，这些内容大多以表格形式进行展示。例如，根据被测业务的业务路径下的业务操作步骤的类型以及补充约束的类型可以将展示的表格分为三类，具体可参见表1。

表1

如表1所示，业务规则类型可以包括系统校验类型、系统处理类型以及系统反馈类型，每一种业务规则类型对应有多种业务规则表格类型。表1中业务规则类型也可以作为扩展业务路径下的各个业务操作步骤的步骤类型。

综上述，通过用例生成系统中各模块的处理，可生成被测业务的测试用例，测试用例可以以excel的形式进行展现，方便用户查看。其中，excel表的表头分别为：用例类型、自动化、用例名、前置条件、用例步骤及预期结果。以被测业务为支付业务为例，给出一种测试用例的excel的展现形式，可参见图4。图4示出了本申请一个示例性实施例提供的一种测试用例的示意图；如图4所示，excel的每一行代表一种测试用例，被测业务可对应多种测试用例这样提高测试用例的可读性。

本申请实施例通过级联展开相互独立的规则因子来生成前置条件，可以解决根据自然语言描述的产品需求文档自动生成测试用例的过程中，展开前置条件的数量较多的问题。通过控制前置条件的数量，减少测试用例的生成数量，进而降低测试用例的维护成本。

下面结合附图，对本申请实施例提供的数据处理方案进行详细介绍。

请参见图5，图5示出了本申请一个示例性实施例提供的一种数据处理方法的流程示意图。该数据处理方案可由上述描述的服务器来执行，具体由服务器中部署的用例生成模块来执行；该方案包括步骤S501-S505，其中：

S501、获取需求数据。

需求数据包括被测业务的业务路径以及业务路径下的业务操作步骤。业务路径用于指示各个业务操作步骤的执行顺序，以及业务操作步骤之间的跳转逻辑；例如，在转账时需要先输入转账金额，再进行密码验证，因此转账业务的业务路径包括“输入金额”和“身份验证”两个业务操作步骤，业务路径用于指示在完成“输入金额”后，进行“身份验证”，即执行完“输入金额”的操作步骤后，跳转至“身份验证”的操作步骤，在执行“身份验证”的操作步骤之前需要执行“输入金额”的操作步骤。其中，被测业务是由一条或多条计算机代码组成的集合；例如，被测业务可以是一个软件，也可以是一个应用子程序。

需要说明的是，获取需求数据的具体实施过程可参见图2b所示实施例的具体实施过程的相关描述，即用例生成模块从需求管理模块中获取需求管理模块处理得到的需求数据。详细内容在此不做赘述。

S502、根据需求数据构建有向图。

有向图是由有向边和业务节点组成的、用于描述被测业务的业务操作流程的一种图。有向图中的业务节点可以用于表示被测业务中的业务操作步骤，有向图中的边可以用于表示被测业务中的业务操作步骤之间的跳转逻辑。为了更好地理解有向图的概念，下面先对有向图涉及的相关术语和概念进行介绍，参见表2。

表2

如表2所描述的，有向图中的业务节点代表被测业务的业务路径中的一个步骤，换句话说，将被测业务的每一个业务操作步骤作为有向图的节点。业务节点按照不同维度进行划分，可得到不同的类型节点；例如，按照步骤之间的执行顺序将与当前节点相连的其他节点称为：子业务节点、父业务节点和兄弟业务节点；又如，按照步骤类型将业务节点类型分为用户选择节点、系统校验节点、系统反馈节点等等，不同类型的业务节点对应的步骤体现的界面反馈可能不相同。有向图中的边体现步骤与步骤之间的连接关系，即根据步骤之间的走向将业务节点连接起来就形成有向图的边。

下面以被测业务包括N个业务操作步骤为例，对构建有向图的实现方式进行阐述：将被测业务的第i个业务操作步骤确定为有向图中的第i个业务节点，将被测业务的第j个业务操作步骤确定为有向图中的第j个业务操作步骤；然后，将第i个业务操作步骤与第j个业务操作步骤之间的跳转逻辑确定为有向图中第i个业务节点与第j个业务节点之间的边，且该边的方向是由第i个业务节点指向第j个业务节点的；继而，根据N个业务节点和节点之间的边构建有向图。上述所描述的i、j均为正整数，且i≤N，j≤N。

需要说明的是，有向图中除包含上述所描述的N个业务节点外，还包括虚拟节点，虚拟节点包括起始节点S和结束节点E。将起始节点与被测业务的业务路径下第一个业务操作步骤对应的业务节点相连，以及将结束节点与被测业务的业务路径下最后一个业务操作步骤对应的业务节点相连，就形成一个完整的有向图。起始节点S和结束节点E的出现，可保证有向图的完整性，方便用户对有向图进行查阅和分析。

S503、从有向图中探索得到目标用例路径；目标用例路径是指经过有向图中的目标关键业务节点的路径。

基于前述描述可知，有向图中包含多个业务节点和边，那么遍历有向图中不同的业务节点，可得到穿过各业务节点的用例路径，所谓用例路径是指按照业务操作序列从起始节点S开始经过业务节点终止于结束节点E的路径，所有业务节点对应的用例路径组成用例路径集合。用例路径集合中包含至少一条用例路径，每一条用例路径分别用于表示被测业务的一个业务操作序列。

由于用例路径所穿过的业务节点的类型可能不同，则用例路径的类型也不相同。用例路径集合中的用例路径的类型主要包括主用例路径、关键用例路径，其中，目标用例路径的类型为关键用例路径。其中：

(1)主用例路径是指按照被测业务的基本业务路径从起始节点S开始穿过基本业务路径下包含的N个业务节点，并终止于结束节点E的一条路径，其中，N个业务节点与基本业务路径下的N个业务操作步骤一一对应。根据主用例路径生成的测试用例能够满足被测业务的基本测试需求。值得一提的是，在有向图中探索主用例路径的方法可包括：从起始节点S开始，按照基本业务路径下的N个业务操作步骤的执行顺序，依次遍历有向图中的N个业务节点，直至结束节点E停止；将穿过起始节点S、N个业务节点以及结束节点E的遍历路径确定为主用例路径。下面结合附图6a来对探索有向图中的主用例路径进行介绍，请参见图6a，图6a示出了本申请一个示例性实施例提供的一种有向图的示意图；如图6a所示，有向图中包括起始节点S，业务节点A，业务节点B，业务节点C1，业务节点C21，业务节点C22，业务节点D，业务节点E和结束节点E，业务节点A对应操作步骤1，业务节点B对应操作步骤2，业务节点C1对应操作步骤3，业务节点C21对应操作步骤4，业务节点C22对应操作步骤5，业务节点D对应操作步骤6，业务节点E对应操作步骤7，需求数据指示的基本业务路径下的业务操作步骤的执行顺序为：步骤1→步骤2→步骤3→步骤6→步骤7，则按照该基本业务路径下的5个业务操作步骤的执行顺序，将用例路径“起始节点→业务节点A→业务节点B→业务节点C1→业务节点D→业务节点E→结束节点”确定为主用例路径。

(2)关键用例路径是指从起始节点S开始穿过目标关键业务节点，终止于结束节点E的路径。基于此可知，目标用例路径的用例类型为关键用例路径。需要说明的是，有向图中的目标关键业务节点的数量可能不止一个，所以关键用例路径不止一条。其中，目标关键业务节点可以包括第一类型的业务节点和第二类型的业务节点。其中，第一类型的业务节点是指：由被测业务向被测业务中的用户提供交互界面的业务操作步骤的业务节点。第二类型的业务节点是指：由用户在交互界面中产生交互行为，并由被测业务对交互行为进行感知反馈的业务操作步骤的业务节点。

结合上述相关描述，下面给出从有向图中探索得到目标用例路径(或关键用例路径)的实现方式，该实现方式可包括步骤s11-s14，其中：

s11、在有向图中探索业务节点的类型为第一类型或第二类型的业务节点，并将探索得到的业务节点确定为目标关键业务节点。

s12、采用最短路径图遍历算法在有向图中遍历查找起始节点S与目标关键业务节点之间的第一路径。此处的最短路径图遍历算法旨在寻找从起始节点S到目标关键业务节点之间的最短路径；该最短路径相比于从起始节点S到目标关键业务节点的其他路径来说，其穿过的业务节点的数量最少。最短路径图遍历算法可包括但不限于Dijkstra算法、floyd算法等等，本申请实施例对此不作限定。

s13、在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径。此处根据目标关键业务节点的类型不同，探索第二路径的方式也有所不同。在一种实施方式中，目标关键业务节点的类型为第一类型，则在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径的方式可包括：从目标关键业务节点开始沿结束节点E的方向在有向图中探索从目标关键业务节点返回至主用例路径，并沿主用例路径到达结束节点E的路径，将该路径作为第二路径。当不存在从目标关键业务节点沿结束节点E的方向返回主用例路径时，可以将采用最短路径图遍历算法在有向图中遍历查找目标关键业务节点与结束节点S之间的最短路径，并将该最短路径作为第二路径。在另一种实现方式中，目标关键业务节点的类型为第二类型，则在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径的方式可包括：将目标关键业务节点与结束节点E相连接形成的路径确定为第二路径。

s14、将步骤s12得到的第一路径和步骤s13得到的第二路径拼接形成的路径确定为目标用例路径。

下面结合附图6b来对步骤s11-s14所描述的探索有向图中的关键用例路径进行介绍，请参见图6b，图6b示出了本申请一个示例性实施例提供的一种有向图的示意图；如图6b所示，假设业务节点C21为目标关键业务节点，主用例路径为起始节点S→业务节点A→业务节点B1→业务节点C1→业务节点D→业务节点F→结束节点E。那么探索起始节点S与业务节点C21之间的第一路径可包括：首先，探索起始节点S与业务节点C21之间的所有路径，如所有路径可以包括以下两种：起始节点S→业务节点A→业务节点B1→业务节点C21，以及起始节点S→业务节点A→业务节点B21→业务节点B22→业务节点C21；其次，由于起始节点S→业务节点A→业务节点B1→业务节点C21包含的节点数量最少，因此将该路径确定为起始节点与业务节点C21之间的第一路径。探索业务节点C21与结束节点E之间的第二路径可包括：确定目标关键业务节点的类型；当目标关键业务节点的类型为第一类型时，探索从业务节点C21到主用例路径的最短路径，按照最短路径所包含的节点数最少的原则，可探索得到第二路径：业务节点C21-业务节点C22-业务节点D-业务节点F-结束节点E，在这种情况下，穿过业务节点C21的关键用例路径为：起始节点S→业务节点A→业务节点B1→业务节点C21-业务节点C22-业务节点D-业务节点F-结束节点E。当目标关键业务节点的类型为第二类型时，将从业务节点C21到结束节点E之间的路径作为第二路径，即，业务节点C21-结束节点E，在这种情况下，穿过业务节点C21的关键用例路径为：起始节点S→业务节点A→业务节点B1→业务节点C21-结束节点E。

正如前述所描述的，目标关键业务节点的类型包括第一类型和第二类型，那么遍历有向图得到的用例路径集合中可包括第一用例路径集合和第二用例路径集合。第一用例路径集合中包含业务节点的类型为第一类型的业务节点所对应的用例路径，即第一用例路径集合中的用例路径用于生成验证业务操作行为(即用例路径所穿过的目标关键业务节点用于表示由用户在交互界面中产生交互行为，并由被测业务对交互行为进行感知反馈的业务操作步骤)的测试用例。第二用例路径集合中包含业务节点的类型为第二类型的业务节点所对应的用例路径，即第二用例路径集合中的用例路径用于生成验证业务规则(即用例路径所穿过的目标关键业务节点用于表示由述被测业务向被测业务中的用户提供交互界面的业务操作步骤)的测试用例。

本申请实施例还支持对第一用例路径集合和第二用例路径集合进行优化处理。所谓优化处理可以理解为去重处理，即若第一用例路径集合与第二用例路径集合包含相同的用例路径，则在第一用例路径集合中删除相同的用例路径。通过这种去重的方式，可以避免重复生成同一测试任务的测试用例，减少测试用例生成成本。

基于步骤S501-S503所描述的实施过程可得到被测业务的主用例路径和关键用例路径，基于主用例路径和关键用例路径可生成被测业务的多种测试用例。下面结合附图7对步骤S501-S503所描述的实施过程进行总结性描述，请参见图7，图7示出了本申请一个示例性实施例提供的一种确定用例路径集合的流程图；如图7所示，首先，通过分析被测业务的业务路径下的业务操作步骤和业务操作序列，构建得到有向图；其次，采用上述方法遍历得到主用例路径，以及为每个目标关键业务节点生成目标用例路径；最后，对第一用例路径集合和第二用例路径集合进行优化处理，得到优化处理后的用例路径集合。基于优化后的用例路径集合即可生成满足测试需求的多个测试用例。

S504、获取目标关键业务节点所使用的业务规则，业务规则包括多个规则因子，多个规则因子相互独立。

S505、对多个规则因子进行级联展开处理，得到目标测试用例的前置条件。

步骤S504-S505中，经前述描述可知，目标关键业务节点对应的目标用例路径代表着确定性的业务操作序列，如果目标关键业务节点未挂载业务规则(即目标关键业务节点未使用业务规则)，那么按照该业务操作序列执行可得到确定的执行结果。例如，如果目标关键业务节点的类型为第二类型，且目标关键业务节点上未挂载业务规则，则按照模板关键业务节点对应的业务操作序列执行后，可给到用户确定的界面反馈。反之，如果目标关键业务节点上挂载有业务规则(即目标关键业务节点使用业务规则)，那么即使按照该业务操作序列执行，也可得到多种可能的执行结果。这是由于目标关键业务节点上挂载的业务规则所包含的多个规则项导致的，一个规则项对应一种前置条件；当执行的规则项不同时，执行结果就可能不相同。

需要说明的是，目标关键业务节点上挂载的业务规则可以以表的形式进行呈现，即目标关键业务节点上挂载业务规则表，该业务规则表包括一列或多列的规则列，本申请实施例将规则列称为规则项。业务规则表可参见图8，图8示出了本申请一个示例性实施例提供的一种业务规则表的示意图；如图8所示，该业务规则表中包括5列规则项，代表着该业务规则表所挂载的目标关键业务节点所在的目标用例路径至少有5种前置条件，对应可生成至少5种测试用例。

另外，目标关键业务节点所关联的业务规则表的任意规则项还可以引用其他业务规则表，本申请实施例将规则项所引用的业务规则表称为规则因子。这种情况下，目标关键业务节点的前置条件的数量会跟随规则因子的数量增加，对应的测试用例的生成数量也相应增加。其中，规则项引用业务规则表的示意图可参见图9，图9示出了本申请一个示例性实施例提供的一种引用规则因子的示意图；如图9所示，目标关键业务节点上挂载的业务规则表中的规则项引用了其他多个规则因子，当规则项与一个或多个规则因子进行组合时，可得到多种前置条件。例如：规则项与规则因子A组合得到前置条件A；规则项与规则因子A和规则因子B组合得到前置条件B；等等。基于图9所描述的可知，如果对规则项所引用的所有规则因子均展开，这样生成的前置条件的数量是巨大的，且基于这些前置条件生成测试用例时很有可能得到测试功能相同的测试用例，使得测试用例生成成本较高。

基于此，本申请实施例支持分析规则项所引用的规则因子之间的引用关系，并只将引用关系为相互独立的规则因子进行级联展开处理，得到一定数量的前置条件，并基于这些条件生成测试用例。这样能够有效降低测试用例生成成本，且由于规则因子之间是相互独立的，能够覆盖影响界面反馈的所有的前置条件，保证测试功能的完整性。其中，分析规则因子之间的引用关系是否为相互独立的方式可包括但不限于：(1)根据规则因子之间的写法规则来判断规则因子之间是否为相互独立。具体地，语义识别各规则因子的语义信息；若各规则因子的语义信息均不相同，则确定各规则因子之间的引用关系为相互独立，反之为非独立。(2)采用白盒测试来判断规则因子之间是否为相互独立。具体地，执行被测业务的业务操作序列，分析执行结果对应的界面反馈之间的跳转关系；若界面反馈之间的跳转关系为独立的，则判断界面反馈对应的规则因子之间为相互独立。当然，还可以采用其他的方式来验证规则因子之间是否相互独立，本申请实施例对此不作限定。

确定目标关键业务节点所使用的业务规则包括的M个规则因子为相互独立时，可对N个规则因子进行级联展开处理，得到目标测试用例的前置条件。下面以目标关键业务节点上搭载的业务规则表的某一规则项引用4个相互独立的规则因子为例，来对上述描述的对多个规则因子进行级联展开处理，得到目标测试用例的前置条件进行详细介绍。假设4个相互独立的规则因子分别为第一规则因子、第二规则因子、第三规则因子及第四规则因子，第一规则因子包含1个规则项(即x1)、第二规则因子包含2个规则项(即x2)、第三规则因子包括3个规则项(即x3)及第四规则因子包含4个规则项(即x4)，则对4个规则因子进行级联展开处理，得到目标测试用例的前置条件，包括：

s11，从4个规则因子中选取第i个规则因子，例如i＝2，表示选取第二规则因子。

s12，保持4个规则因子中除选取的第二规则因子之外的其余规则因子不展开，并对4个规则因子中选取第二规则因子进行展开处理，得到第二规则因子的x_i种规则项。换句话说，若当前选取的规则因子为第二规则因子，则保持第一规则因子、第三规则因子及第四规则因子不展开(即不处理)，对第二规则因子展开，得到x_i种规则项，x_i＝1*x2，其中，数值1表示引用4个规则因子的一列规则项，x2表示第二规则因子所包含的2列规则项。

s13，对4个规则因子中每一个规则因子均执行步骤s11-s12的操作，得到第一规则因子展开的1*x1种前置条件、第二规则因子展开的1*x2种前置条件、第三规则因子展开的1*x3种前置条件、第四规则因子展开的1*x4种前置条件。

s14，根据4个规则因子中展开处理得到的规则项，生成目标测试用例的P种前置条件；其中，P＝1*x1+1*x2+1*x3+1*x4＝10。

综上述，对相互独立的4个规则因子进行级联展开处理，可得到10种前置条件，相比于对4个规则因子全展开得到的1*x1*x2*x3*x4＝24种前置条件而言，有效地减少了前置条件的数量，进而减少了测试用例的生成数量，降低测试用例的维护成本。

下面请参见图10，图10示出了本申请一个示例性实施例提供的另一种数据处理方法的流程示意图；该数据处理方案可由上述描述的服务器来执行，具体由服务器中部署的用例生成模块来执行；该方案包括步骤S1001-S1006，其中：

S1001，获取需求数据。

S1002，根据需求数据构建有向图。

S1003，从有向图中探索得到目标用例路径，目标用例路径是指经过有向图中的目标关键业务节点的路径。

S1004，获取目标关键业务节点所使用的业务规则，业务规则包括多个规则因子，多个规则因子相互独立。

S1005，对多个规则因子进行级联展开处理，得到目标测试用例的前置条件。

需要说明的是，步骤S1001-S1005所示的具体实施过程可参见图5所示实施例中步骤S5001-S5005所描述的具体实施过程的相关描述，在此不作赘述。

S1006，基于目标测试用例的前置条件，生成与目标用例路径相对应的目标测试用例。

基于目标测试用例的前置条件生成目标测试用例的具体实现方式可包括：从目标用例路径中提取目标用例步骤；基于目标用例步骤和前置条件，生成与目标用例路径相对应的目标测试用例。换句话说，目标测试用例的一个前置条件与目标用例步骤可生成目标用例路径的一种测试用例，如果目标测试用例存在P种前置条件时，可生成目标用例路径的P种目标测试用例。

上述生成目标测试用例的步骤中，从目标用例路径中提取目标用例步骤的具体实现方式可包括：(1)从目标用例路径表示的业务操作序列中提取一组或多组组合步骤；其中，任一组组合步骤用于表示被测业务中的用户与被测业务之间的一个界面交互行为，任一组组合步骤包括第一业务操作步骤和第二业务操作步骤，第一业务操作步骤是指由被测业务向用户提供交互界面的步骤，第二业务操作步骤是指由用户在交互界面中产生交互行为，并由被测业务对交互行为进行感知反馈的步骤。(2)将一组或多组组合步骤形成的序列确定为目标用例步骤。需要说明的是，采用图2b所示实施例中的用例生成模块来生成目标测试用例的过程中，用例生成模块还需要参考从特征管理模块中读取的语料信息和冲突信息，以过滤一些矛盾的、重复的语料，提高生成的测试用例的可行性。

下面以支付业务场景中的一个业务操作序列为例进行说明，支付业务场景中的业务操作需求如下所示：

业务操作步骤1.【被测业务】请求用户确认XX信息

业务操作步骤2b.【被测业务】验证用户反馈的结果为确认XX信息，且需要引导用户绑定银行卡

业务操作步骤2b1.【被测业务】请求用户添加银行卡

业务操作步骤2b11.【被测业务】获取银行卡卡号

业务操作步骤2b12.【被测业务】验证银行卡卡号

业务操作步骤2b13.【被测业务】请求获取银行支付授权

业务操作步骤2b14.【被测业务】验证支付权限

业务操作步骤2b15.【被测业务】进入业务操作步骤2

业务操作步骤2d.【被测业务】验证用户反馈的结果为确认XX信息，且需要引导用户实名认证

业务操作步骤2d1.【被测业务】请求用户提交实名认证信息

业务操作步骤2d2.【被测业务】验证用户反馈的结果为提交实名认证信息业务操作步骤2d3.【被测业务】进入业务操作步骤2

业务操作步骤2.【被测业务】请求用户提交支付密码

业务操作步骤3.【被测业务】验证用户反馈的结果为提交支付密码

上述业务操作序列中，业务操作步骤后面的数字或字母表示业务操作步骤的编号，业务操作步骤的编号中不包含字母的业务操作步骤1至业务操作步骤3所形成的业务操作序列对应主用例路径。业务操作步骤2d中，由用户在交互界面中产生交互行为(即通过交互界面反馈XX信息)，并由被测业务对交互行为进行感知反馈(即对反馈的XX信息的结果进行校验)，由此可知，业务操作步骤2d对应的业务节点是第一类型的目标关键业务节点。由业务操作步骤1至业务操作步骤2d所形成的业务操作序列对应第一路径；由业务操作步骤2d至业务操作步骤2所形成的业务操作序列，对应从目标关键业务节点返回主用例路径的路径；由业务操作步骤2至业务操作步骤3所形成的业务操作序列，对应沿主用例路径到达结束节点的路径；即由业务操作步骤2d至业务操作步骤4所形成的业务操作序列对应第二路径。同理，业务操作步骤2b对应的业务节点是第一类型的目标关键业务节点。由业务操作步骤1至业务操作步骤2b所形成的业务操作序列对应第一路径；由业务操作步骤2b至业务操作步骤2所形成的业务操作序列，对应从目标关键业务节点返回主用例路径的路径；由业务操作步骤2至业务操作步骤3所形成的业务操作序列，对应沿主用例路径到达结束节点的路径；即由业务操作步骤2b至业务操作步骤3所形成的业务操作序列对应第二路径。

根据上述支付业务场景中的业务操作序列提取到的组合用例步骤如下所示：

组合步骤1.【被测业务】请求用户确认XX信息_【被测业务】验证用户反馈的结果为确认XX信息，且需要引导用户实名认证

组合步骤2.【被测业务】请求用户提交实名认证信息_【被测业务】验证用户反馈的结果为提交实名认证信息

组合步骤3.【被测业务】请求用户添加银行卡_【被测业务】验证银行卡卡号

组合步骤4.【被测业务】请求获取银行支付授权_【被测业务】验证支付权限

组合步骤5.【被测业务】请求用户提交XX密码_【被测业务】验证用户反馈的结果为提交XX密码

由上述组合用例步骤可知，组合用例步骤包括信息获取步骤和信息验证步骤。以组合步骤1为例，组合步骤1包括的第一业务操作步骤为业务操作步骤1，组合步骤1包括的第二业务操作步骤为业务操作步骤2d，业务操作步骤1是指由被测业务向用户提供包含XX信息的交互界面的步骤(即信息获取步骤)，业务操作步骤2d是指由用户在交互界面中产生交互行为(即通过包含XX信息的交互界面反馈确认XX信息)，并由被测业务对交互行为进行感知反馈(即对反馈的XX信息的结果进行校验)的步骤(即信息验证步骤)。业务操作步骤1和业务操作步骤2d组成组合步骤1，组合步骤1表示了被测业务中的用户与被测业务之间的一个界面(包含XX信息的交互界面)交互行为。以此类推，可以从上述支付场景下的业务操作序列中继续提取目标用例步骤中的组合步骤2至组合步骤5。

从目标遍历路径中提取得到目标用例步骤之后，可以根据目标用例步骤和前置条件生成目标用例路径对应的目标测试用例。当采用目标测试用例用来对被测业务执行测试时，可得到测试结果，该测试结果的好坏用于评判软件产品的质量。

本申请实施例中，通过将每一前置条件与目标用例步骤组合生成多种目标测试用例，可扩展一条目标用例路径的多种可能的测试用例，提高测试任务的完整性。

上述详细阐述了本申请实施例的方法，为了便于更好地实施本申请实施例的上述方案，相应地，下面提供了本申请实施例的装置。

请参见图11，图11示出了本申请一个示例性实施例提供的一种数据处理装置的结构示意图，该数据处理装置可以搭载在服务器中；该数据处理装置可以是数据处理设备中的一个应用程序或插件。图11所示的数据处理装置可以用于执行上述图5和图10所描述的方法实施例中的部分或全部功能。其中，各个单元的详细描述如下：

获取单元1101，用于获取需求数据，需求数据包括被测业务的业务路径及业务路径下的业务操作步骤；

处理单元1102，用于根据需求数据构建有向图，有向图包括业务节点和边，业务节点用于表示被测业务中的业务操作步骤，边用于表示被测业务中的业务操作步骤之间的跳转逻辑；以及，从有向图中探索得到目标用例路径，目标用例路径是指经过有向图中的目标关键业务节点的路径；目标用例路径用于表示被测业务的一个业务操作序列，且目标用例路径用于生成目标测试用例；

获取单元1101，还用于获取目标关键业务节点所使用的业务规则，业务规则包括多个规则因子，多个规则因子相互独立；

处理单元1102，还用于对多个规则因子进行级联展开处理，得到目标测试用例的前置条件。

在一种实施方式中，目标关键业务节点所使用的业务规则包括M个规则因子，M为正整数；处理单元1102用于，对多个规则因子进行级联展开处理，得到目标测试用例的前置条件，具体用于：

从M个规则因子中选取第i个规则因子；

保持述M个规则因子中除选取的第i个规则因子之外的其余规则因子不展开，并对M个规则因子中选取第i个规则因子进行展开处理，得到第i个规则因子的x_i种规则项；

重复上述步骤，直至M个规则因子均被展开处理为止；

根据述M个规则因子中展开处理得到的规则项，生成述目标测试用例的P种前置条件；

其中，设M个规则因子中第i个规则因子包括x_i种规则项，则P的值为

在一种实施方式中，处理单元1102还用于：

从目标用例路径中提取目标用例步骤；

基于目标用例步骤和前置条件，生成与目标用例路径相对应的目标测试用例。

在一种实施方式中，处理单元1102用于，从目标用例路径中提取目标用例步骤，具体用于：

从目标用例路径表示的业务操作序列中提取一组或多组组合步骤；

将一组或多组组合步骤形成的序列确定为目标用例步骤；

其中，任一组组合步骤用于表示被测业务中的用户与被测业务之间的一个界面交互行为，任一组组合步骤包括第一业务操作步骤和第二业务操作步骤，第一业务操作步骤是指由被测业务向用户提供交互界面的步骤，第二业务操作步骤是指由用户在交互界面中产生交互行为，并由被测业务对交互行为进行感知反馈的步骤。

在一种实施方式中，被测业务包括N个业务操作步骤；有向图包括N个业务节点；处理单元1102用于，根据需求数据构建有向图，具体用于：

将被测业务的第i个业务操作步骤确定为有向图中的第i个业务节点，将被测业务的第j个业务操作步骤确定为有向图中的第j个业务节点；以及，

将第i个业务操作步骤与第j个业务操作步骤之间的跳转逻辑确定为有向图中第i个业务节点与第j个业务节点之间的边；

依据确定的业务节点和边构建有向图；

其中，N为大于1的整数，i、j均为正整数，并且i≤N，j≤N。

在一种实施方式中，处理单元1102还用于：

遍历有向图中的业务节点，得到用例路径集合，用例路径集合中包含至少一条用例路径，每一条用例路径分别用于表示被测业务的一个业务操作序列；目标用例路径是用例路径集合中经过有向图中的目标关键业务节点的路径；

其中，用例路径集合中的用例路径的类型包括主用例路径或关键用例路径，目标用例路径的类型为关键用例路径。

在一种实施方式中，业务路径包括基本业务路径，基本业务路径下包含N个业务操作步骤；M为正整数；有向图还包括起始节点和结束节点；处理单元1102用于，遍历有向图中的业务节点，得到用例路径集合，具体用于：

从起始节点开始，按照基本业务路径下的N个业务操作步骤的执行顺序，依次遍历有向图中的N个业务节点，直至结束节点停止；N个业务节点与基本业务路径下的N个业务操作步骤一一对应；

将穿过起始节点、N个业务节点以及结束节点的遍历路径确定为主用例路径。

在一种实施方式中，目标用例路径的用例类型是关键用例路径；有向图还包括起始节点和结束节点；处理单元1102用于，从有向图中探索得到目标用例路径，具体用于：

在有向图中确定目标关键业务节点；

采用最短路径图遍历算法在有向图中遍历查找起始节点与目标关键业务节点之间的第一路径；以及，在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径；

将第一路径与第二路径拼接形成的路径确定为目标用例路径。

在一种实施方式中，处理单元1102用于，在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径，具体用于：

若目标关键业务节点的类型为第一类型，则在有向图中探索得到主用例路径，沿结束节点的方向在有向图中探索从目标关键业务节点返回至主用例路径，并沿主用例路径到达结束节点的第二路径；或者，

若目标关键业务节点的类型为第一类型，采用最短路径图遍历算法在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径；或者，

若目标关键业务节点的类型为第二类型，则将目标关键业务节点与结束节点相连接形成的路径确定为第二路径；

其中，若目标关键业务节点用于表示由被测业务向被测业务中的用户提供交互界面的业务操作步骤，则目标关键业务节点的类型为第一类型；若目标关键业务节点用于表示由用户在交互界面中产生交互行为，并由被测业务对交互行为进行感知反馈的业务操作步骤，则目标关键业务节点的类型为第二类型。

在一种实施方式中，用例路径集合包括第一用例路径集合和第二用例路径集合，第一用例路径集合和第二用例路径集合中均包含一条或多条用例路径，其中，第一用例路径集合中的用例路径用于生成验证业务操作行为的测试用例，第二用例路径集合中的用例路径用于生成验证业务规则的测试用例；处理单元1102还用于：

对第一用例路径集合和第二用例路径集合进行优化处理。

在一种实施方式中，处理单元1102用于，对第一用例路径集合和第二用例路径集合进行优化处理，具体用于：

若第一用例路径集合与第二用例路径集合包含相同的用例路径，则在第一用例路径集合中删除相同的用例路径。

在一种实施方式中，处理单元1102用于，获取需求数据，具体用于：

获取需求描述文档，需求描述文档用于描述被测业务的业务操作流程，且需求描述文档为第一格式的文档；

对需求描述文档进行解析，得到需求数据，需求数据为第二格式的数据。

根据本申请的一个实施例，图5和图10所示的数据处理方法所涉及的部分步骤可由图11所示的数据处理装置中的各个单元来执行。例如，图5中所示的步骤S501、S504可由图11所示的获取单元1101执行，步骤S502、步骤S503及步骤S505可由图11所示的处理单元1102执行。图10中所示的步骤S1001和步骤S1004可由图11所示的获取单元1101执行，步骤S1002、步骤S1003、步骤S1005及步骤S1006可由图11所示的处理单元1102执行。图11所示的数据处理装置中的各个单元可以分别或全部合并为一个或若干个另外的单元来构成，或者其中的某个(些)单元还可以再拆分为功能上更小的多个单元来构成，这可以实现同样的操作，而不影响本申请的实施例的技术效果的实现。上述单元是基于逻辑功能划分的，在实际应用中，一个单元的功能也可以由多个单元来实现，或者多个单元的功能由一个单元实现。在本申请的其它实施例中，数据处理装置也可以包括其它单元，在实际应用中，这些功能也可以由其它单元协助实现，并且可以由多个单元协作实现。

根据本申请的另一个实施例，可以通过在包括中央处理单元(CPU)、随机存取存储介质(RAM)、只读存储介质(ROM)等处理元件和存储元件的例如计算机的通用计算装置上运行能够执行如图5和图10中所示的相应方法所涉及的各步骤的计算机程序(包括程序代码)，来构造如图11中所示的数据处理装置，以及来实现本申请实施例的数据处理方法。计算机程序可以记载于例如计算机可读记录介质上，并通过计算机可读记录介质装载于上述计算装置中，并在其中运行。

本申请实施例中，获取单元1101可获取目标关键业务节点所使用的业务规则；相应的，处理单元1102对业务规则包含的相互独立的这一部分规则因子进行级联展开处理，进而得到目标测试用例的前置条件。采用本申请实施例相比于将目标关键业务节点所使用的业务规则全部展开而言，可较好地控制目标测试用例的前置条件的数量，使得最终生成的目标测试用例的数量可控，降低目标测试用例的维护成本。

请参阅图12，图12示出了本申请一个示例性实施例提供的一种数据处理设备的结构示意图，该数据处理设备可以是上传需求描述文档的用户所使用的终端设备；该数据处理设备至少包括处理器1201、通信接口1202和存储器1203。其中，处理器1201、通信接口1202和存储器1203可通过总线或其他方式连接，本申请实施例以通过总线连接为例。其中，处理器1201(或称中央处理器(Central Processing Unit，CPU))是数据处理设备的计算核心以及控制核心，其可以解析终端设备内的各类指令以及处理终端设备的各类数据，例如：CPU可以用于解析用户向终端设备所发送的开关机指令，并控制终端设备进行开关机操作；再如：CPU可以在终端设备内部结构之间传输各类交互数据，等等。通信接口1202可选的可以包括标准的有线接口、无线接口(如WI-FI、移动通信接口等)，受处理器1201的控制可以用于收发数据；通信接口1202还可以用于终端设备内部数据的传输以及交互。存储器1203(Memory)是终端设备中的记忆设备，用于存放程序和数据。可以理解的是，此处的存储器1203既可以包括终端设备的内置存储器，当然也可以包括终端设备所支持的扩展存储器。存储器1203提供存储空间，该存储空间存储了终端设备的操作系统，可包括但不限于：Android系统、iOS系统、Windows Phone系统等等，本申请对此并不作限定。

在本申请实施例中，处理器1201通过运行存储器1203中的可执行程序代码，执行如下操作：

获取需求数据，需求数据包括被测业务的业务路径及业务路径下的业务操作步骤；

根据需求数据构建有向图，有向图包括业务节点和边，业务节点用于表示被测业务中的业务操作步骤，边用于表示被测业务中的业务操作步骤之间的跳转逻辑；以及，从有向图中探索得到目标用例路径，目标用例路径是指经过有向图中的目标关键业务节点的路径；目标用例路径用于表示被测业务的一个业务操作序列，且目标用例路径用于生成目标测试用例；

获取目标关键业务节点所使用的业务规则，业务规则包括多个规则因子，

多个规则因子相互独立；

对多个规则因子进行级联展开处理，得到目标测试用例的前置条件。

在一种实施方式中，目标关键业务节点所使用的业务规则包括M个规则因子，M为正整数；处理器1201在对多个规则因子进行级联展开处理，得到目标测试用例的前置条件的具体实施方式为：

从M个规则因子中选取第i个规则因子；

保持述M个规则因子中除选取的第i个规则因子之外的其余规则因子不展开，并对M个规则因子中选取第i个规则因子进行展开处理，得到第i个规则因子的x_i种规则项；

重复上述步骤，直至M个规则因子均被展开处理为止；

根据述M个规则因子中展开处理得到的规则项，生成述目标测试用例的P种前置条件；

其中，设M个规则因子中第i个规则因子包括xi种规则项，则P的值为

在一种实施方式中，处理器1201通过运行存储器1203中的可执行程序代码，还执行如下操作：

从目标用例路径中提取目标用例步骤；

基于目标用例步骤和前置条件，生成与目标用例路径相对应的目标测试用例。

在一种实施方式中，处理器1201在从目标用例路径中提取目标用例步骤的具体实施方式为：

从目标用例路径表示的业务操作序列中提取一组或多组组合步骤；

将一组或多组组合步骤形成的序列确定为目标用例步骤；

其中，任一组组合步骤用于表示被测业务中的用户与被测业务之间的一个界面交互行为，任一组组合步骤包括第一业务操作步骤和第二业务操作步骤，第一业务操作步骤是指由被测业务向用户提供交互界面的步骤，第二业务操作步骤是指由用户在交互界面中产生交互行为，并由被测业务对交互行为进行感知反馈的步骤。

在一种实施方式中，被测业务包括N个业务操作步骤；有向图包括N个业务节点；处理器1201在根据需求数据构建有向图的具体实施方式为：

将被测业务的第i个业务操作步骤确定为有向图中的第i个业务节点，将被测业务的第j个业务操作步骤确定为有向图中的第j个业务节点；以及，

将第i个业务操作步骤与第j个业务操作步骤之间的跳转逻辑确定为有向图中第i个业务节点与第j个业务节点之间的边；

依据确定的业务节点和边构建有向图；

其中，N为大于1的整数，i、j均为正整数，并且i≤N，j≤N。

在一种实施方式中，处理器1201通过运行存储器1203中的可执行程序代码，还执行如下操作：

遍历有向图中的业务节点，得到用例路径集合，用例路径集合中包含至少一条用例路径，每一条用例路径分别用于表示被测业务的一个业务操作序列；目标用例路径是用例路径集合中经过有向图中的目标关键业务节点的路径；

其中，用例路径集合中的用例路径的类型包括主用例路径或关键用例路径，目标用例路径的类型为关键用例路径。

在一种实施方式中，业务路径包括基本业务路径，基本业务路径下包含N个业务操作步骤；M为正整数；有向图还包括起始节点和结束节点；处理器1201在遍历有向图中的业务节点，得到用例路径集合的具体实施方式为：

从起始节点开始，按照基本业务路径下的N个业务操作步骤的执行顺序，依次遍历有向图中的N个业务节点，直至结束节点停止；N个业务节点与基本业务路径下的N个业务操作步骤一一对应；

将穿过起始节点、N个业务节点以及结束节点的遍历路径确定为主用例路径。

在一种实施方式中，目标用例路径的用例类型是关键用例路径；有向图还包括起始节点和结束节点；处理器1201在从有向图中探索得到目标用例路径的具体实施方式为：

在有向图中确定目标关键业务节点；

采用最短路径图遍历算法在有向图中遍历查找起始节点与目标关键业务节点之间的第一路径；以及，在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径；

将第一路径与第二路径拼接形成的路径确定为目标用例路径。

在一种实施方式中，处理器1201在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径的具体实施方式为：

若目标关键业务节点的类型为第一类型，则在有向图中探索得到主用例路径，沿结束节点的方向在有向图中探索从目标关键业务节点返回至主用例路径，并沿主用例路径到达结束节点的第二路径；或者，

若目标关键业务节点的类型为第一类型，采用最短路径图遍历算法在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径；或者，

若目标关键业务节点的类型为第二类型，则将目标关键业务节点与结束节点相连接形成的路径确定为第二路径；

其中，若目标关键业务节点用于表示由被测业务向被测业务中的用户提供交互界面的业务操作步骤，则目标关键业务节点的类型为第一类型；若目标关键业务节点用于表示由用户在交互界面中产生交互行为，并由被测业务对交互行为进行感知反馈的业务操作步骤，则目标关键业务节点的类型为第二类型。

在一种实施方式中，用例路径集合包括第一用例路径集合和第二用例路径集合，第一用例路径集合和第二用例路径集合中均包含一条或多条用例路径，其中，第一用例路径集合中的用例路径用于生成验证业务操作行为的测试用例，第二用例路径集合中的用例路径用于生成验证业务规则的测试用例；处理器1201通过运行存储器1203中的可执行程序代码，还执行如下操作：

对第一用例路径集合和第二用例路径集合进行优化处理。

在一种实施方式中，处理器1201在对第一用例路径集合和第二用例路径集合进行优化处理的具体实施方式为：

若第一用例路径集合与第二用例路径集合包含相同的用例路径，则在第一用例路径集合中删除相同的用例路径。

在一种实施方式中，处理器1201在获取需求数据的具体实施方式为：

获取需求描述文档，需求描述文档用于描述被测业务的业务操作流程，且需求描述文档为第一格式的文档；

对需求描述文档进行解析，得到需求数据，需求数据为第二格式的数据。

本申请实施例中，处理器1201可获取目标关键业务节点所使用的业务规则，并对业务规则包含的相互独立的这一部分规则因子进行级联展开处理，得到目标测试用例的前置条件。采用本申请实施例相比于将目标关键业务节点所使用的业务规则全部展开而言，可较好地控制目标测试用例的前置条件的数量，使得最终生成的目标测试用例的数量可控，降低目标测试用例的维护成本。

本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，该计算机程序适于由处理器加载并执行上述方法实施例的数据处理方法。

本申请实施例还提供一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述数据处理的方法。

需要说明的是，对于前述的各个方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某一些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

本申请实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。

本申请实施例装置中的单元可以根据实际需要进行合并、划分和删减。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，可读存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(RandomAccess Memory，RAM)、磁盘或光盘等。

以上所揭露的仅为本申请一种较佳实施例而已，当然不能以此来限定本申请之权利范围，本领域普通技术人员可以理解实现上述实施例的全部或部分流程，并依本申请权利要求所作的等同变化，仍属于申请所涵盖的范围。

Claims (15)

1.一种数据处理方法，其特征在于，包括：

获取需求数据，所述需求数据包括被测业务的业务路径及所述业务路径下的业务操作步骤；

根据所述需求数据构建有向图，所述有向图包括业务节点和边，所述业务节点用于表示所述被测业务中的业务操作步骤，所述边用于表示所述被测业务中的业务操作步骤之间的跳转逻辑；

从所述有向图中探索得到目标用例路径，所述目标用例路径是指经过所述有向图中的目标关键业务节点的路径；所述目标用例路径用于表示所述被测业务的一个业务操作序列，且所述目标用例路径用于生成目标测试用例；

获取所述目标关键业务节点所使用的业务规则，所述业务规则包括多个规则因子，所述多个规则因子相互独立；

对所述多个规则因子进行级联展开处理，得到所述目标测试用例的前置条件。

2.如权利要求1所述的方法，其特征在于，所述目标关键业务节点所使用的业务规则包括M个规则因子，M为正整数；

所述对所述多个规则因子进行级联展开处理，得到所述目标测试用例的前置条件，包括：

从所述M个规则因子中选取第i个规则因子；

保持所述M个规则因子中除选取的第i个规则因子之外的其余规则因子不展开，并对所述M个规则因子中选取第i个规则因子进行展开处理，得到第i个规则因子的x_i种规则项；

重复上述步骤，直至所述M个规则因子均被展开处理为止；

根据所述M个规则因子中展开处理得到的规则项，生成所述目标测试用例的P种前置条件；

其中，设M个规则因子中第i个规则因子包括x_i种规则项，则P的值为

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

从所述目标用例路径中提取目标用例步骤；

基于所述目标用例步骤和所述前置条件，生成与所述目标用例路径相对应的目标测试用例。

4.如权利要求3所述的方法，其特征在于，所述从所述目标用例路径中提取目标用例步骤，包括：

从所述目标用例路径表示的业务操作序列中提取一组或多组组合步骤；

将所述一组或多组组合步骤形成的序列确定为目标用例步骤；

其中，任一组所述组合步骤用于表示被测业务中的用户与被测业务之间的一个界面交互行为，任一组所述组合步骤包括第一业务操作步骤和第二业务操作步骤，所述第一业务操作步骤是指由所述被测业务向所述用户提供交互界面的步骤，所述第二业务操作步骤是指由所述用户在所述交互界面中产生交互行为，并由所述被测业务对所述交互行为进行感知反馈的步骤。

5.如权利要求1所述的方法，其特征在于，所述被测业务包括N个业务操作步骤；所述有向图包括N个业务节点；所述根据所述需求数据构建有向图，包括：

将所述被测业务的第i个业务操作步骤确定为所述有向图中的第i个业务节点，将所述被测业务的第j个业务操作步骤确定为所述有向图中的第j个业务节点；以及，

将所述第i个业务操作步骤与所述第j个业务操作步骤之间的跳转逻辑确定为所述有向图中所述第i个业务节点与第j个业务节点之间的边；

依据确定的业务节点和边构建所述有向图；

其中，N为大于1的整数，i、j均为正整数，并且i≤N，j≤N。

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

遍历所述有向图中的业务节点，得到用例路径集合，所述用例路径集合中包含至少一条用例路径，每一条用例路径分别用于表示所述被测业务的一个业务操作序列；所述目标用例路径是所述用例路径集合中经过有向图中的目标关键业务节点的路径；

其中，所述用例路径集合中的用例路径的类型包括主用例路径或关键用例路径，所述目标用例路径的类型为关键用例路径。

7.如权利要求6所述的方法，其特征在于，所述业务路径包括基本业务路径，所述基本业务路径下包含N个业务操作步骤；M为正整数；所述有向图还包括起始节点和结束节点；

所述遍历所述有向图中的业务节点，得到用例路径集合，包括：

从所述起始节点开始，按照所述基本业务路径下的N个业务操作步骤的执行顺序，依次遍历所述有向图中的N个业务节点，直至所述结束节点停止；所述N个业务节点与所述基本业务路径下的N个业务操作步骤一一对应；

将穿过所述起始节点、所述N个业务节点以及所述结束节点的遍历路径确定为所述主用例路径。

8.如权利要求6所述的方法，其特征在于，所述目标用例路径的用例类型是关键用例路径；所述有向图还包括起始节点和结束节点；

所述从所述有向图中探索得到目标用例路径，包括：

在所述有向图中确定目标关键业务节点；

采用最短路径图遍历算法在所述有向图中遍历查找所述起始节点与所述目标关键业务节点之间的第一路径；以及，在所述有向图中遍历查找所述目标关键业务节点与所述结束节点之间的第二路径；

将所述第一路径与所述第二路径拼接形成的路径确定为所述目标用例路径。

9.如权利要求8所述的方法，其特征在于，所述在所述有向图中遍历查找所述目标关键业务节点与所述结束节点之间的第二路径，包括：

若所述目标关键业务节点的类型为第一类型，则在所述有向图中探索得到主用例路径，沿所述结束节点的方向在所述有向图中探索从所述目标关键业务节点返回至所述主用例路径，并沿所述主用例路径到达所述结束节点的第二路径；或者，

若所述目标关键业务节点的类型为第一类型，采用最短路径图遍历算法在所述有向图中遍历查找所述目标关键业务节点与所述结束节点之间的第二路径；或者，

若所述目标关键业务节点的类型为第二类型，则将所述目标关键业务节点与所述结束节点相连接形成的路径确定为第二路径；

其中，若所述目标关键业务节点用于表示由所述用户在所述交互界面中产生交互行为，并由所述被测业务对所述交互行为进行感知反馈的业务操作步骤，则所述目标关键业务节点的类型为第一类型；若所述目标关键业务节点用于表示由所述被测业务向所述被测业务中的用户提供交互界面的业务操作步骤，则所述目标关键业务节点的类型为第二类型。

10.如权利要求6所述的方法，其特征在于，所述用例路径集合包括第一用例路径集合和第二用例路径集合，所述第一用例路径集合和所述第二用例路径集合中均包含一条或多条用例路径，其中，所述第一用例路径集合中的用例路径用于生成验证业务操作行为的测试用例，所述第二用例路径集合中的用例路径用于生成验证业务规则的测试用例；所述方法还包括：

对所述第一用例路径集合和所述第二用例路径集合进行优化处理。

11.如权利要求10所述的方法，其特征在于，所述对所述第一用例路径集合和所述第二用例路径集合进行优化处理，包括：

若所述第一用例路径集合与所述第二用例路径集合包含相同的用例路径，则在所述第一用例路径集合中删除所述相同的用例路径。

12.如权利要求1所述的方法，其特征在于，所述获取需求数据，包括：

获取需求描述文档，所述需求描述文档用于描述所述被测业务的业务操作流程，且所述需求描述文档为第一格式的文档；

对所述需求描述文档进行解析，得到所述需求数据，所述需求数据为第二格式的数据。

13.一种数据处理装置，其特征在于，包括：

获取单元，用于获取需求数据，所述需求数据包括被测业务的业务路径及所述业务路径下的业务操作步骤；

处理单元，用于根据所述需求数据构建有向图，所述有向图包括业务节点和边，所述业务节点用于表示所述被测业务中的业务操作步骤，所述边用于表示所述被测业务中的业务操作步骤之间的跳转逻辑；

所述处理单元，用于从所述有向图中探索得到目标用例路径，所述目标用例路径是指经过所述有向图中的目标关键业务节点的路径；所述目标用例路径用于表示所述被测业务的一个业务操作序列，且所述目标用例路径用于生成目标测试用例；

所述获取单元，用于获取所述目标关键业务节点所使用的业务规则，所述业务规则包括多个规则因子，所述多个规则因子相互独立；

所述处理单元，用于对所述多个规则因子进行级联展开处理，得到所述目标测试用例的前置条件。

14.一种数据处理设备，其特征在于，包括：

处理器，适于执行计算机程序；

计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序被所述处理器执行时，实现如权利要求1-12任一项所述的数据处理方法。

15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序适于由处理器加载并执行如权利要求1-12任一项所述的数据处理方法。

Images