CN113220599B - 测试用例集的生成方法、装置、设备及存储介质 - Google Patents

Abstract

本申请提供一种测试用例集的生成方法、装置、设备及存储介质，应用于系统测试领域，可根据获取到的规则化的业务条款数据以及用例生成条件，确定测试用例集的第一部分以及测试用例集中每个测试用例的第二部分，其中，第一部分为测试用例集中每个测试用例的公共部分，第二部分包括每个测试用例的业务步骤，将第一部分与每个测试用例的第二部分组合，可得到针对该业务条款的测试用例集。通过上述方法生成的测试用例集，为系统测试补充业务制度相关案例，能够有效提升系统测试质量，保障系统业务流程的合法合规。

Description

测试用例集的生成方法、装置、设备及存储介质

技术领域

本申请涉及软件开发领域，尤其涉及一种测试用例集的生成方法、装置、设备及存储介质。

背景技术

随着银行业务逐渐向线上化发展，银行业务面临的网络风险不断加剧，如何防范网络风险，保障客户资金安全也变得越来越重要。防范网络风险，首先要保障银行软件系统的安全。银行软件系统安全不仅包括系统的技术安全，系统业务流程的合法合规也至关重要。

软件测试作为保障系统质量的重要手段，补充涉及系统相关制度条款的测试用例有利于验证系统业务流程的合规性，提升银行系统安全性。目前有关生成测试用例的研究，主要关注于测试数据、用户需求，案例模块等。但是，有关系统设计是否合规，业务流程是否合理相关的研究非常少。

因此，亟需构建一定数量的用于验证系统操作流程合规性的测试用例，提升系统测试质量，保障系统合法合规。

发明内容

本申请实施例提供一种测试用例集的生成方法、装置、设备及存储介质，为系统测试补充业务制度相关案例，可有效提升系统测试质量。

第一方面，本申请实施例提供一种测试用例集的生成方法，包括：

获取规则化的业务条款数据以及用例生成条件，所述业务条款数据用于指示业务流程的输入输出关系；

根据所述业务条款数据以及所述用例生成条件，确定所述测试用例集的第一部分以及所述测试用例集中每个测试用例的第二部分，所述第一部分为每个测试用例的公共部分，所述第二部分包括每个测试用例的业务步骤；

将所述第一部分与每个测试用例的第二部分组合，生成针对所述业务条款的测试用例集。

在本申请的一个可选实施例中，所述业务条款数据包括：业务条款的所属系统、所属业务板块、所属类型、输入条件以及预期结果。

在本申请的一个可选实施例中，所述用例生成条件包括：是否生成反向测试用例，是否生成预期结果，是否生成设计者。

在本申请的一个可选实施例中，所述根据所述业务条款数据以及所述用例生成条件，确定所述测试用例集的第一部分，包括：

根据所述业务条款数据的所属系统、所属业务板块以及预设的测试用例模板，生成针对所述业务条款的测试用例集中每个测试用例的第一部分，所述第一部分包括测试用例的描述，编号，优先级，交易类型以及测试类型。

在本申请的一个可选实施例中，所述根据所述业务条款数据以及所述用例生成条件，确定所述测试用例集中每个测试用例的第二部分，包括：

根据所述业务条款数据的所属类型、输入条件、预期结果，以及所述用例生成条件，确定所述测试用例集中每个测试用例的业务步骤，所述业务步骤包括所述输入条件的步骤以及所述预期结果的步骤。

在本申请的一个可选实施例中，所述业务条款数据的所属类型包括约束控制类、流程串联类以及其他类型；

所述约束控制类用于根据所述业务条款数据的N个输入条件，生成N个正向测试用例以及1个反向测试用例；

所述流程串联类用于根据所述业务条款数据的N个输入条件，生成1个正向测试用例以及N个反向测试用例；

所述其他类型用于根据所述业务条款数据的N个输入条件，生成1个正向测试用例以及1个反向测试用例，其中N为正整数。

第二方面，本申请实施例提供一种测试用例集的生成装置，包括：

获取模块，用于获取规则化的业务条款数据以及用例生成条件，所述业务条款数据用于指示业务流程的输入输出关系；

处理模块，用于根据所述业务条款数据以及所述用例生成条件，确定所述测试用例集的第一部分以及所述测试用例集中每个测试用例的第二部分，所述第一部分为每个测试用例的公共部分，所述第二部分包括每个测试用例的业务步骤；

处理模块，还用于将所述第一部分与每个测试用例的第二部分组合，生成针对所述业务条款的测试用例集。

在本申请的一个可选实施例中，所述业务条款数据包括：业务条款的所属系统、所属业务板块、所属类型、输入条件以及预期结果。

在本申请的一个可选实施例中，所述用例生成条件包括：是否生成反向测试用例，是否生成预期结果，是否生成设计者。

在本申请的一个可选实施例中，所述处理模块，具体用于：

根据所述业务条款数据的所属系统、所属业务板块以及预设的测试用例模板，生成针对所述业务条款的测试用例集中每个测试用例的第一部分，所述第一部分包括测试用例的描述，编号，优先级，交易类型以及测试类型。

在本申请的一个可选实施例中，所述处理模块，具体用于：

根据所述业务条款数据的所属类型、输入条件、预期结果，以及所述用例生成条件，确定所述测试用例集中每个测试用例的业务步骤，所述业务步骤包括所述输入条件的步骤以及所述预期结果的步骤。

在本申请的一个可选实施例中，所述业务条款数据的所属类型包括约束控制类、流程串联类以及其他类型；

所述约束控制类用于根据所述业务条款数据的N个输入条件，生成N个正向测试用例以及1个反向测试用例；

所述流程串联类用于根据所述业务条款数据的N个输入条件，生成1个正向测试用例以及N个反向测试用例；

所述其他类型用于根据所述业务条款数据的N个输入条件，生成1个正向测试用例以及1个反向测试用例，其中N为正整数。

第三方面，本申请实施例提供一种电子设备，包括：

存储器，处理器以及计算机程序；

其中，所述计算机程序存储在所述存储器中，并被配置为由所述处理器执行以实现如第一方面中任一项所述的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行以实现如第一方面中任一项所述的方法。

第五方面，本申请实施例提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现第一方面中任一项所述的方法。

本申请实施例提供一种测试用例集的生成方法、装置、设备及存储介质，应用于系统测试领域。该方法包括：获取规则化的业务条款数据以及用例生成条件，根据规则化的业务条款数据以及用例生成条件，确定测试用例集的第一部分以及测试用例集中每个测试用例的第二部分，其中，第一部分为测试用例集中每个测试用例的公共部分，第二部分包括每个测试用例的业务步骤，将第一部分与每个测试用例的第二部分组合，可得到针对该业务条款的测试用例集。通过上述方法生成的测试用例集，为系统测试补充业务制度相关案例，能够有效提升系统测试质量，保障系统业务流程的合法合规。

附图说明

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

图1为本申请实施例提供的测试用例集的生成方法的流程示意图；

图2为本申请实施例提供的用例生成条件的获取窗口的示意图；

图3为本申请实施例提供的测试用例的生成装置的结构示意图；

图4为本申请实施例提供的电子设备的硬件结构图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

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

本申请实施例的说明书、权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述之外的顺序实施。

应当理解，本文中使用的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本申请实施例的描述中，术语“对应”可表示两者之间具有直接对应或间接对应的关系，也可以表示两者之间具有关联关系，也可以是指示与被指示、配置与被配置等关系。

首先对本申请实施例涉及的专业术语进行简要介绍。

测试用例集，是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。

软件规格说明书，又称为软件需求说明书，是指在研究用户需求的基础上，完成可行性分析和投资效益分析以后，有软件工程师或分析员编写的说明书。它详细定义了信息流和界面，功能需求，设计要求和限制，测试准则和质量保证要求。

随着金融市场不断发展，利率逐渐走向市场化，产品走向多元化。为顺应时代发展，提升银行竞争力，商业银行利用金融科技赋能，使银行向数字化，智能化转型。移动支付，线上产品，无一不依赖复杂的软件系统。随着银行业务逐渐向线上化发展，银行软件系统的功能亟待完善，软件测试作为保证银行软件系统质量的重要手段，起着至关重要的作用。

目前，有关测试用例的研究包括以下几点：

以数据为依据生成测试用例方面，关注的是测试数据集，即需要输入哪些数据，再根据数据的不同生成测试用例。测试方法只关注输入是什么，并没有关注中间流程，流程是否合理以及是否符合相应的法律法规，测试过程中不能发现数据输入合理但是操作步骤不合理的情况。

基于整个软件系统或软件规格说明书生成全量的测试用例，该类方法根据系统的不同特点生成了全量测试用例，覆盖了所有功能点。但测试用例生成过程中，只是针对系统本身生成测试用例，并未考虑系统设计的合理性，业务流程是否符合业务制度或法律法规。

基于流程图或其他可视化界面生成测试用例，该类方法可以直观的看到测试用例执行流程应该是怎么样的，有利于理解和执行。但是该方法只是展示了流程是怎么样的，并未根据现有的制度、规范设计相关测试用例，验证系统流程是否合理，操作是否合规。

对系统的部分模块，修改内容，或部分特征生成回归或者补充用例。该种方法考虑了不同模块的特点补充测试用例。但是补充案例并没有考虑系统相关的制度和法规，没有补充这一部分的测试用例。

根据需求分析结果生成测试用例，该类方法通过与业务沟通需求，形成需求文档，并以此为基准生成测试用例，可以大大提升测试用例质量。但如何校验需求设计是否合理并未提及。

综上描述，目前有关生成测试用例的研究，主要关注于数据、需求、功能模块等，但是有关系统设计是否合规，业务流程是否合理的研究非常少。测试人员往往不具备相关的业务制度理论基础，即使是业务验收测试，业务人员往往也不能掌握全部条款，造成由于对业务规章理解不够透彻，导致系统测试过程中缺少符合相关制度要求的测试用例，最终导致系统存在操作不合规，甚至违背相关业务条款的风险。因此，亟需构建一定数量的用于验证系统操作流程合规性的测试用例，提升系统测试质量，保障系统合法合规。

为了解决上述问题，本申请实施例提出一种测试用例集的生成方法，可根据已经梳理好的条目化条款、测试人员输入的用例生成条件，按照条款的不同类型，基于不同的用例生成规则，自动生成能够验证业务流程合法合规性的测试用例集，为系统测试补充与业务制度相关的测试用例，可有效提升系统测试质量及安全性。

下面通过具体实施例对本申请实施例提供的技术方案进行详细说明。需要说明的是，本申请实施例提供的技术方案可以包括以下内容中的部分或全部，下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

图1为本申请实施例提供的测试用例集的生成方法的流程示意图，如图1所示，本实施例的测试用例集的生成方法，包括如下步骤：

步骤101、获取规则化的业务条款数据以及用例生成条件，业务条款数据用于指示业务流程的输入输出关系。

本实施例中，规则化的业务条款数据是指按照一定规则编制成特定模式的业务条款数据，该业务条款数据以表格形式存储。

在本实施例的一个示例中，业务条款数据包括：业务条款的所属系统，所属业务板块，所属类型，输入条件以及预期结果。业务条款数据还包括业务条款所属的业务制度名称。

其中，业务条款的所属类型(即条款类型)包括约束控制类，流程串联类，其他类型。根据业务条款的内容，可确定业务条款对应的输入条件、预期结果，当满足输入条件时，预期结果是什么。本实施例对输入条件的数量不作限定，可以是一个，也可以是多个。

下面结合一个具体实例，对业务条款数据进行举例说明。

以银行领域为例，应理解，一项银行业务制度通常包括多条业务条款，可基于银行业务制度文件，生成该业务制度对应的业务条款表格，如表1所示，表格中的每一行对应一条业务条款数据。

表1

需要指出的是，针对每一条业务条款数据，可生成对应的测试用例集，用于验证针对该项业务条款的业务步骤是否合规。

具体示例如下：

业务制度的制度名称为：《XX银行XX管理办法》，

业务条款内容为：第XX条符合以下条件之一的XX类资产，损失阶段划分结果不得高于标准X：

(一)逾期XX天(不含)至XX天(含)。

(二)风险分类形态为XX类。

(三)目标对象当前违约概率较初始确认时出现明显上升。

(四)其他表明资产风险已显著增加的情形。(以上为制度原文)

上述业务条款的所属类型为约束控制类，所属系统为业务条款对应的目标系统，所属业务板块为XX管理板块(目标系统对应的菜单项)。

输入条件包括：输入条件1：逾期XX天(不含)至XX天(含)；输入条件2：风险分类形态为XX类；输入条件3：目标对象当前违约概率较初始确认时出现明显上升；输入条件4：其他表明资产风险已显著增加的情形(根据制度原文生成的规则化的输入条件)。

预期结果包括：该笔XX类资产损失阶段划分结果不得高于标准X(正向)，该笔XX类资产损失阶段划分结果高于标准X(反向)。(系统可能产生的结果)

在本实施例的一个示例中，用例生成条件包括：

是否生成反向测试用例，是否生成预期结果，是否生成设计者。

示例性的，图2为本申请实施例提供的用例生成条件的获取窗口的示意图，如图2所示，可通过弹窗的形式提示测试人员进行用例生成内容的选择，获取用例生成条件。

步骤102、根据业务条款数据以及用例生成条件，确定测试用例集的第一部分以及测试用例集中每个测试用例的第二部分。

其中，第一部分为测试用例集中每个测试用例的公共部分，第二部分包括测试用例集中每个测试用例的业务步骤。

在本实施例的一个示例中，可根据业务条款数据的所属系统、所属业务板块以及预设的测试用例模板，生成测试用例集中每个测试用例的第一部分。其中，第一部分包括测试用例的描述，编号，优先级，交易类型以及测试类型。

预设的测试用例模板中包括多项默认内容：用例优先级，交易类型，测试类型，关联需求编号，自动化测试用例编号，自动化测试用例执行方式，前置条件等。

示例性的，用例优先级默认为高，交易类型默认为联机，测试类型默认为功能测试，关联需求编号、自动化测试用例编号、自动化测试用例执行方式以及前置条件均默认为空。

在本实施例的一个示例中，可根据业务条款数据的所属类型、输入条件、预期结果，以及用例生成条件，确定测试用例集中每个测试用例的业务步骤。其中，业务步骤包括输入条件的步骤以及预期结果的步骤。

本实施例中，业务条款数据的所属类型包括约束控制类、流程串联类以及其他类型。其中，约束控制类用于根据业务条款数据的N个输入条件，生成N个正向测试用例以及1个反向测试用例；流程串联类用于根据业务条款数据的N个输入条件，生成1个正向测试用例以及N个反向测试用例；其他类型用于根据业务条款数据的N个输入条件，生成1个正向测试用例以及1个反向测试用例，其中N为正整数。

下面针对上述业务条款数据的所属类型，如何生成测试用例的业务步骤进行详细说明。

(1)约束控制类

对业务条款数据的输入条件进行拆分，假设有N个输入条件则生成N个正向测试用例和1个反向测试用例。具体格式如下：

①正向测试用例

[步骤]名称＝满足+输入条件1、2...N的内容

[步骤]预期(正向)＝预期结果列中“/”前的内容

②反向测试用例

[步骤]名称＝不满足+输入条件1或2或...或N

[步骤]预期(反向)＝预期结果列中“/”后的内容

(2)流程串联类

对业务条款数据的输入条件进行拆分，假设有N个输入条件，输入条件之间的顺序是固定的，生成1个正向测试用例和N个反向测试用例。

需要说明的是，本示例中的输入条件可以理解为输入步骤，N个步骤之间的顺序是固定的，顺序不对或者缺少步骤都会被判定流程不合规。

具体格式如下：

①正向测试用例

[步骤]名称＝输入条件1+2+...+N的内容

[步骤]预期(正向)＝预期结果列中“/”前的内容

②反向测试用例

[步骤]名称＝输入条件1、2、...、N中缺失一个步骤

[步骤]名称＝输入条件1、2、...、N乱序排列

[步骤]预期(反向)＝预期结果列中“/”后的内容

(3)其他类型

根据业务条款数据的输入条件，生成1个正向测试用例和1个反向测试用例。具体格式如下：

①正向测试用例

[步骤]名称＝满足+输入条件的内容

[步骤]预期(正向)＝预期结果列中“/”前的内容

③反向测试用例

[步骤]名称＝不满足+输入条件的内容

[步骤]预期(反向)＝预期结果列中“/”后的内容

需要说明的是，若用例生成条件中测试人员设置了不生成反向测试用例，则测试用例集仅保留正向测试用例。

步骤103、将第一部分与每个测试用例的第二部分组合，生成针对业务条款的测试用例集。

本实施例提供的测试用例集的生成方法，可根据获取到的规则化的业务条款数据以及用例生成条件，确定测试用例集的第一部分以及测试用例集中每个测试用例的第二部分，其中，第一部分为测试用例集中每个测试用例的公共部分，第二部分包括每个测试用例的业务步骤，将第一部分与每个测试用例的第二部分组合，可得到针对该业务条款的测试用例集。通过上述方法生成的测试用例集，为系统测试补充业务制度相关案例，能够有效提升系统测试质量，保障系统业务流程的合法合规。

基于上述实施例的技术方案，下面以步骤101中的示例业务条款为例，分别列举测试用例集中每个测试用例。

<正向测试用例1>

测试用例编号：XX管理板块-0001

用例描述：损失阶段划分结果不得高于标准X

用例优先级：高

交易类型：联机

测试类型：功能测试

用例属性：正向

步骤描述：满足逾期XX天(不含)至XX天(含)。

步骤预期：该笔XX类资产损失阶段划分结果不得高于标准X

<正向测试用例2>

测试用例编号：XX管理板块-0002

用例描述：损失阶段划分结果不得高于标准X

用例优先级：高

交易类型：联机

测试类型：功能测试

用例属性：正向

步骤描述：风险分类形态为XX类。

步骤预期：满足该笔XX类资产损失阶段划分结果不得高于标准X

<正向测试用例3>

测试用例编号：XX管理板块-0003

用例描述：损失阶段划分结果不得高于标准X

用例优先级：高

交易类型：联机

测试类型：功能测试

用例属性：正向

步骤描述：满足目标对象当前违约概率较初始确认时出现明显上升。

步骤预期：该笔XX类资产损失阶段划分结果不得高于标准X

<正向测试用例4>

测试用例编号：XX管理板块-0004

用例描述：损失阶段划分结果不得高于标准X

用例优先级：高

交易类型：联机

测试类型：功能测试

用例属性：正向

步骤描述：满足其他表明资产风险已显著增加的情形。

步骤预期：该笔XX类资产损失阶段划分结果不得高于标准X

<反向测试用例1>

测试用例编号：XX管理板块-0005

用例描述：满足损失阶段划分结果不得高于标准X

用例优先级：高

交易类型：联机

测试类型：功能测试

用例属性：反向

步骤描述：不满足逾期XX天(不含)至XX天(含)，不满足风险分类形态为XX类，不满足目标对象当前违约概率较初始确认时出现明显上升，不满足其他表明资产风险已显著增加的情形。

步骤预期：该笔XX类资产损失阶段划分结果高于标准X。

作为软件测试的重要交付物，测试用例是软件测试必不可少的一环，它有用于指导测试实施，是评估测试结果的度量基准。因此，基于更为全面的测试用例进行系统测试有利于提升系统质量。根据对测试用例生产研究的分析，基于系统业务制度相关测试用例鲜有涉及。

为弥补该部分测试用例的缺失，本申请提出了一种测试用例集的生成方法，将可操作的规则化后的银行业务制度(包括多项业务条款)，按照不同的业务条款的所属类型转化为可直接应用的测试用例。在日常工作中，只需维护规则化后的业务制度，将维护后的制度与需求相关联，就能生成系统业务制度相关测试用例，不但节省了大量时间，对测试资源库的维护也提供了有力支撑。该工具将测试工作前移，提高测试人员对实际业务需求的理解能力，简化编制测试用例的工作，为提高测试效率、提升测试质量提供了有力保障。

本申请技术方案主要有以下优势：一是目前系统测试过程中，较少关注流程是否合规类问题，本申请为系统测试补充业务制度相关案例，使系统测试更为全面；二是通过已梳理完成的制度条款自动生成测试用例，大大减少案例编写时间，提升测试效率；三是制度条款与需求相匹配可为业务安全测试提供指导，验证系统设计是否合理，业务流程是否合规。

本申请实施例可以根据上述方法实施例，对测试用例集的生成装置进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以使用硬件的形式实现，也可以使用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。下面以使用对应各个功能划分各个功能模块为例进行说明。

图3为本申请实施例提供的测试用例集的生成装置的结构示意图。如图3所示，测试用例集的生成装置200，包括：获取模块201以及处理模块202。

获取模块201，用于获取规则化的业务条款数据以及用例生成条件，所述业务条款数据用于指示业务流程的输入输出关系；

处理模块202，用于根据所述业务条款数据以及所述用例生成条件，确定所述测试用例集的第一部分以及所述测试用例集中每个测试用例的第二部分，所述第一部分为每个测试用例的公共部分，所述第二部分包括每个测试用例的业务步骤；

处理模块202，还用于将所述第一部分与每个测试用例的第二部分组合，生成针对所述业务条款的测试用例集。

在本申请的一个可选实施例中，所述业务条款数据包括：业务条款的所属系统、所属业务板块、所属类型、输入条件以及预期结果。

在本申请的一个可选实施例中，所述用例生成条件包括：是否生成反向测试用例，是否生成预期结果，是否生成设计者。

在本申请的一个可选实施例中，所述处理模块202，具体用于：

根据所述业务条款数据的所属系统、所属业务板块以及预设的测试用例模板，生成针对所述业务条款的测试用例集中每个测试用例的第一部分，所述第一部分包括测试用例的描述，编号，优先级，交易类型以及测试类型。

在本申请的一个可选实施例中，所述处理模块202，具体用于：

根据所述业务条款数据的所属类型、输入条件、预期结果，以及所述用例生成条件，确定所述测试用例集中每个测试用例的业务步骤，所述业务步骤包括所述输入条件的步骤以及所述预期结果的步骤。

在本申请的一个可选实施例中，所述业务条款数据的所属类型包括约束控制类、流程串联类以及其他类型；

所述约束控制类用于根据所述业务条款数据的N个输入条件，生成N个正向测试用例以及1个反向测试用例；

所述流程串联类用于根据所述业务条款数据的N个输入条件，生成1个正向测试用例以及N个反向测试用例；

所述其他类型用于根据所述业务条款数据的N个输入条件，生成1个正向测试用例以及1个反向测试用例，其中N为正整数。

本实施例提供的测试用例集的生成装置，可以执行前述方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

图4为本申请实施例提供的电子设备的硬件结构图，如图4所示，本实施例提供的电子设备300，包括：

存储器301；

处理器302；以及

计算机程序；

其中，计算机程序存储在存储器301中，并被配置为由处理器302执行以实现前述方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

可选的，存储器301既可以是独立的，也可以跟处理器302集成在一起。当存储器301是独立于处理器302之外的器件时，电子设备300还包括：总线303，用于连接存储器301和处理器302。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器302执行以实现前述方法实施例中的技术方案。

本申请实施例提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现前述方法实施例中的技术方案。

本申请实施例还提供了一种芯片，包括：处理模块与通信接口，该处理模块能执行前述方法实施例中的技术方案。

进一步地，该芯片还包括存储模块(如，存储器)，存储模块用于存储指令，处理模块用于执行存储模块存储的指令，并且对存储模块中存储的指令的执行使得处理模块执行前述所示方法实施例中的技术方案。

应理解，上述处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：DigitalSignal Processor，简称：DSP)、专用集成电路(英文：Application SpecificIntegrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。

总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component，PCI)总线或扩展工业标准体系结构(ExtendedIndustry Standard Architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(Application SpecificIntegrated Circuits，简称：ASIC)中。当然，处理器和存储介质也可以作为分立组件存在于电子设备中。

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

Claims (6)

1.一种测试用例集的生成方法，其特征在于，包括：

获取规则化的业务条款数据以及用例生成条件，所述业务条款数据用于指示业务流程的输入输出关系；所述规则化的业务条款为按照预设规则编制成的预设模式的业务条款数据，业务条款为业务制度下的条款；所述用例生成条件包括：是否生成反向测试用例，是否生成预期结果，是否生成设计者；

根据所述业务条款数据以及所述用例生成条件，确定所述测试用例集的第一部分以及所述测试用例集中每个测试用例的第二部分，所述第一部分为每个测试用例的公共部分，所述第二部分包括每个测试用例的业务步骤；

将所述第一部分与每个测试用例的第二部分组合，生成针对所述业务条款的测试用例集；

所述根据所述业务条款数据以及所述用例生成条件，确定所述测试用例集中每个测试用例的第二部分，包括：

根据所述业务条款数据的所属类型、输入条件、预期结果，以及所述用例生成条件，确定所述测试用例集中每个测试用例的业务步骤，所述业务步骤包括所述输入条件的步骤以及所述预期结果的步骤；

所述业务条款数据包括N个输入条件；

在所述业务条款数据的类型为约束控制类且所述用例生成条件包括生成反向测试用例时，所述测试用例集包括N个正向测试用例以及1个反向测试用例；所述N个输入条件和该N个正向测试用例一一对应；

在所述业务条款数据的类型为流程串联类且所述用例生成条件包括生成反向测试用例时，所述测试用例集包括1个正向测试用例以及N个反向测试用例，该正向测试用例中的N个输入条件顺序固定；

在所述业务条款数据的类型为其他类型且所述用例生成条件包括生成反向测试用例时，所述测试用例集包括1个正向测试用例以及1个反向测试用例。

2.根据权利要求1所述的方法，其特征在于，所述业务条款数据包括：业务条款的所属系统、所属业务板块、所属类型、输入条件以及预期结果。

3.根据权利要求1或2所述的方法，其特征在于，

所述根据所述业务条款数据以及所述用例生成条件，确定所述测试用例集的第一部分，包括：

根据所述业务条款数据的所属系统、所属业务板块以及预设的测试用例模板，生成针对所述业务条款的测试用例集中每个测试用例的第一部分，所述第一部分包括测试用例的描述，编号，优先级，交易类型以及测试类型。

4.一种测试用例集的生成装置，其特征在于，包括：

获取模块，用于获取规则化的业务条款数据以及用例生成条件，所述业务条款数据用于指示业务流程的输入输出关系；所述规则化的业务条款为按照预设规则编制成的预设模式的业务条款数据，业务条款为业务制度下的条款；所述用例生成条件包括：是否生成反向测试用例，是否生成预期结果，是否生成设计者；

处理模块，用于根据所述业务条款数据以及所述用例生成条件，确定所述测试用例集的第一部分以及所述测试用例集中每个测试用例的第二部分，所述第一部分为每个测试用例的公共部分，所述第二部分包括每个测试用例的业务步骤；

所述处理模块，还用于将所述第一部分与每个测试用例的第二部分组合，生成针对所述业务条款的测试用例集；

所述处理模块，具体于根据所述业务条款数据的所属类型、输入条件、预期结果，以及所述用例生成条件，确定所述测试用例集中每个测试用例的业务步骤，所述业务步骤包括所述输入条件的步骤以及所述预期结果的步骤；

所述业务条款数据包括N个输入条件；

在所述业务条款数据的类型为约束控制类且所述用例生成条件包括生成反向测试用例时，所述测试用例集包括N个正向测试用例以及1个反向测试用例；所述N个输入条件和该N个正向测试用例一一对应；

在所述业务条款数据的类型为流程串联类时，所述测试用例集包括1个正向测试用例以及N个反向测试用例，该正向测试用例中的N个输入条件顺序固定；

在所述业务条款数据的类型为其他类型时，所述测试用例集包括1个正向测试用例以及1个反向测试用例。

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

存储器；

处理器；以及

计算机程序；

其中，所述计算机程序存储在所述存储器中，并被配置为由所述处理器执行以实现如权利要求1-3中任一项所述的方法。

6.一种计算机可读存储介质，其特征在于，其上存储有计算机程序，所述计算机程序被处理器执行以实现如权利要求1-3中任一项所述的方法。