CN105988930A - 测试用例生成方法和装置 - Google Patents

Abstract

本申请公开了一种测试用例生成方法，包括：获取预设模型的状态数据集合；根据所述状态数据集合生成场景数据；根据所述场景数据生成所述预设模型的测试用例。本申请实施例还提供一种应用前述方法的测试用例生成装置。与现有技术相比，本申请公开的方法和装置中，预设模型的场景数据基于状态数据集合来生成，通过离散化数据来取代流程图表，降低了获取场景数据过程中计算机资源的耗费；同时在预设模型有更新功能时，仅需在已有状态数据集合内中增加更新的状态数据，再通过更新后状态数据集合来得到场景数据，提高了状态数据的通用性。

Description

测试用例生成方法和装置

技术领域

本申请涉及软件测试技术领域，尤其涉及一种测试用例生成方法和装置。

背景技术

测试用例是软件测试技术领域中一个广泛使用的概念，是为实现测试目标而编制的一组由测试输入数据、执行条件以及预期输出结果组成的参数集，通过执行测试用例即可实现测试某个程序路径是否满足设定需求。随着软件测试产业的快速发展，生成测试用例的需求也越来越多。

现有技术中，通常采用路径覆盖法来生成测试用例，该方法具体包括：首先，梳理软件系统运行过程中所涉及到的所有流程，将所有流程做图表化，再将流程图表输入计算机内，进而获取获得系统运行的所有路径，每条路径代表系统运行的一个场景数据；其次，为每个路径选择对应的测试数据，构造成所有场景数据的测试用例；最后，运行所有测试用例，来验证每个路径是否符合设定需求，从而实现测试目的。

该现有技术中，通过路径覆盖法来生成测试用例的基础在于：梳理软件系统运行过程中所涉及到的所有流程，将所有流程做图表化。然而，随着软件系统的流程越来越复杂，流程步骤数和流程交错均越来越多，通过流程图表来获取系统路径的过程中所耗费的计算机资源也越来越大；同时，在软件系统有更新功能时，还需对已有的、与该更新功能相关的流程图表进行重新绘制，该绘制过程费时费力，造成已有的流程图表通用性较差。

综上，现有技术中的测试用例生成方法存在着计算机资源耗费大、重复利用率低的问题。

申请内容

本申请实施例提供一种测试用例生成方法和装置，解决了现有技术中测试用例生成过程中计算机资源耗费大、重复利用率低的问题。

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

获取预设模型的状态数据集合；

根据所述状态数据集合生成场景数据；

根据所述场景数据生成所述预设模型的测试用例。

本申请实施例提供一种测试用例生成装置，包括：

状态获取模块，获取预设模型的状态数据集合；

场景生成模块，根据所述状态数据集合生成场景数据；

用例生成模块，根据所述场景数据生成所述预设模型的测试用例。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：本申请实施例中，预设模型的场景数据基于状态数据集合来生成，通过离散化数据来取代流程图表，降低了获取场景数据过程中计算机资源的耗费；同时在预设模型有更新功能时，仅需在已有状态数据集合内中增加更新的状态数据，再通过更新后状态数据集合来得到场景数据，提高了状态数据的通用性。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的测试用例生成方法的过程。

图2为本申请另一实施例提供的测试用例生成方法的过程。

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

具体实施方式

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

在通过路径覆盖法来生成测试用例的过程中，存在着计算机资源耗费大且方法通用性较差的问题，本申请实施例提供一种解决了前述问题的测试用例生成方法，以下结合附图详细描述本方法。

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

S20、获取预设模型的状态数据集合。

本申请的实施例中，预设模型由若干模块组成，每个模块在运行过程中有至少一个状态，使得预设模型具有多种业务场景。模块运行过程中的状态通过多组状态数据来描述，每组状态数据包括模块标识与状态内容，相同模块的状态数据的模块标识相同，状态内容根据模块运行过程中的状态来配置。

将预设模型的所有状态数据进行汇总，则得到了该预设模型的状态数据集合。

当然，本申请的其他实施例中，预设模型也可仅包括单个模块，仅汇总该模块的状态数据即为状态数据集合，在此不做赘述。

S40、根据状态数据集合生成场景数据。

本申请实施例中，状态数据集合内汇总了预设模型的所有状态数据，在状态数据集合内提取每个模块的任意一个状态数据，再将提取到的状态数据进行组合，则得到预设模型的一组场景数据。

以自动贩卖机内系统模型为例，自动贩卖机内系统模型包括：投币模块、库存模块、资金模块以及用户模块。

根据用户模块所采集到用户行为的不同，将系统模型的运行维度分为业务处理维度和系统控制维度。其中，在业务处理维度，用户模块采集购买者进行商品购买的操作行为；在系统控制维度，用户模块采集系统控制器发出的预处理、回滚及提交请求。

本申请实施例中，状态数据集合包括用户状态数据和系统状态数据，用户模块的状态数据为用户状态数据，投币模块、库存模块以及资金模块中任意一个模块的状态数据均为系统状态数据。

在业务处理维度，用户状态数据为业务操作数据，系统状态数据为业务处理数据，其具体可参照表1所示：

表1

当然，本申请的其他实施例中，随着预设模型的不同，业务操作数据和业务处理数据也做适应性调整，在此不做赘述。

在系统控制维度，用户状态数据为系统操作数据，系统状态数据为系统处理数据，其具体可参照表2所示：

表2

用户状态数据为系统状态数据变化的诱因，在用户状态数据发生改变时，系统状态数据也会随之变化，如此才构成完整业务处理流程或系统控制流程。本申请实施例中，通过在同一维度下，将用户状态数据和系统状态数据进行正交算法处理，使得每个场景数据中均有上述四个模块的任意一组状态数据。

在业务处理维度，将业务操作数据和业务处理数据做正交算法处理，得到该维度下的状态数据集合；例举其中3组场景数据，具体可参表3所示：

表3

在系统控制维度，将系统操作数据和系统处理数据做正交算法处理，得到该维度下的状态数据集合；例举其中3组场景数据，具体可参表4所示：

表4

由于场景数据覆盖了业务处理维度和系统控制维度，便于后续提供全面、完整的测试用例，从而实现对软件系统的多维度测试。

本申请实施例提供的测试用例生成方法，通过以预设模型的状态数据来获取场景数据，仅需每个模块的状态数据进行组合，相对于以流程图表作为系统路径(即场景数据)的方式，降低了获取场景数据过程中计算机资源的耗费。同时在预设模型有更新功能时，例如有增加新模块、或原有模块增加了新状态时，仅需在已有状态数据集合中增加对应的状态数据，再通过更新后状态数据集合来得到场景数据，提高了状态数据的通用性。

当然，本申请的其他实施例中，状态数据集合还可仅包括系统状态数据或用户状态数据。例如，预设模型为智能处理系统，该智能处理系统无需用户业务操作行为即可进行业务处理，则该模型的状态数据集合仅包括系统状态数据，在此不做赘述。

S60a、根据场景数据生成预设模型的测试用例。

本申请实施例中，将场景数据转化为可执行的测试自动化代码以及可指导手工执行的测试用例，此为本领域普通技术人员所熟知的技术，在此不做赘述。

仍然以自动贩卖机内系统模型为例，根据业务处理维度的场景数据所生成的测试用例，用于检测系统模型是否能够正常完成商品购买操作。而根据系统控制维度的场景数据所生成的测试用例，用于检测预设模型是否能够正常完成分布式处理请求。

本申请实施例提供的方法从上述两个维度来测试自动贩卖机内系统模型是否能够正常使用，相对于当前通过路径覆盖法来生成测试用例的方式，尤其适合在系统控制维度来生成测试用例，无需图表化相关流程，各个模块的状态也容易设定，有助于提高分布式系统的测试效率和完整性。

图2为本申请另一实施例中测试用例生成方法的过程，与前一实施例相比，区别在于，测试用例生成方法包括如下步骤：

S50、根据预设规则对场景数据进行过滤，以得到滤后数据。

其中，预设规则具体为：仅保留场景数据中的正面数据或去除场景数据中的负面数据。

正面数据可通过将用户需求的场景数据来设定，通过将用户需求的场景数据保留下来，后续直接测试这些场景数据所生成的测试用例，例如，预设模型的原有模块有状态增加时，可直接检测与该模块更新的状态数据相关的场景数据，避免执行原有测试用例导致的资源耗费，提高了测试目的性，保证测试效率。

仍以上述自动贩卖机内系统模型为例，在业务处理维度，对原有的用户模块增加：用户退款状态，则对应的正面数据为包含了用户退款这一状态数据的所有场景数据。例举3组正面数据，具体可参表5所示：

表5

负面数据可通过将明显逻辑错误的场景数据进行设定，还是以自动贩卖机内系统模型为例，系统模型的一组场景数据可为：投币模块为已投币且金额足够状态、库存模块为无库存状态、资金模块为收到资金状态，但用户模块却为选择取走商品状态。前述业务场景明显不符合现实，执行该场景数据所生成的测试用例也无意义。通过剔除场景数据中明显不符合现实的负面数据，降低了后续生成的测试用例的数量，提高了对预设模型进行测试的效率。

S60b、根据滤后数据生成预设模型的测试用例。

根据滤后数据生成测试用例的步骤可参前一实施例中步骤S60a所述，在此不做赘述。

图3为本申请实施例提供的测试用例生成装置的机构示意图，本申请实施例所提供的测试用例生成装置基于以上测试用例生成方法，故该装置的具体细节可参照以上处理方法，本文不再予以赘述。该测试用例生成装置包括：

状态获取模块20，获取预设模型的状态数据集合；

场景生成模块40，根据状态数据集合生成场景数据；

用例生成模块60，根据场景数据生成预设模型的测试用例。

本申请实施例中，状态数据集合包括用户状态数据和系统状态数据。

本申请实施例中，用户状态数据为业务操作数据，系统状态数据为业务处理数据。

本申请实施例中，用户状态数据为系统操作数据，系统状态数据为系统处理数据。

本申请实施例中，测试用例生成装置具体用于：将用户状态数据和系统状态数据进行正交处理，以生成场景数据。

本申请实施例中，测试用例生成装置还包括：场景过滤模块，根据预设规则对场景数据进行过滤，以得到滤后数据；用例生成模块具体用于：根据滤后数据生成预设模型的测试用例。

本申请实施例中，预设规则具体为：仅保留场景数据中的正面数据或去除场景数据中的负面数据。

本申请实施例提供的测试用例生成装置，预设模型的场景数据基于状态数据集合来生成，通过离散化数据来取代流程图表，降低了获取场景数据过程中计算机资源的耗费；同时在预设模型有更新功能时，仅需在已有状态数据集合内中增加更新的状态数据，再通过更新后状态数据集合来得到场景数据，提高了状态数据的通用性。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (14)

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

获取预设模型的状态数据集合；

根据所述状态数据集合生成场景数据；

根据所述场景数据生成所述预设模型的测试用例。

2.如权利要求1所述的测试用例生成方法，其特征在于，所述状态数据集合包括用户状态数据和系统状态数据。

3.如权利要求2所述的测试用例生成方法，其特征在于，所述用户状态数据为业务操作数据，所述系统状态数据为业务处理数据。

4.如权利要求2所述的测试用例生成方法，其特征在于，所述用户状态数据为系统操作数据，所述系统状态数据为系统处理数据。

5.如权利要求2所述的测试用例生成方法，其特征在于，根据所述状态数据集合生成场景数据，具体包括：

将用户状态数据和系统状态数据进行正交处理，以生成场景数据。

6.如权利要求1所述的测试用例生成方法，其特征在于，测试用例生成方法还包括：根据预设规则对所述场景数据进行过滤，以得到滤后数据；

根据所述场景数据生成所述预设模型的测试用例，具体包括：根据所述滤后数据生成所述预设模型的测试用例。

7.如权利要求6所述的测试用例生成方法，其特征在于，所述预设规则具体为：

仅保留所述场景数据中的正面数据或去除所述场景数据中的负面数据。

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

状态获取模块，获取预设模型的状态数据集合；

场景生成模块，根据所述状态数据集合生成场景数据；

用例生成模块，根据所述场景数据生成所述预设模型的测试用例。

9.如权利要求8所述的测试用例生成装置，其特征在于，所述状态数据集合包括用户状态数据和系统状态数据。

10.如权利要求9所述的测试用例生成装置，其特征在于，所述用户状态数据为业务操作数据，所述系统状态数据为业务处理数据。

11.如权利要求10所述的测试用例生成装置，其特征在于，所述用户状态数据为系统操作数据，所述系统状态数据为系统处理数据。

12.如权利要求10所述的测试用例生成装置，其特征在于，测试用例生成装置具体用于：将用户状态数据和系统状态数据进行正交处理，以生成场景数据。

13.如权利要求9所述的测试用例生成装置，其特征在于，测试用例生成装置还包括：场景过滤模块，根据预设规则对所述场景数据进行过滤，以得到滤后数据；所述用例生成模块具体用于：根据所述滤后数据生成所述预设模型的测试用例。

14.如权利要求13所述的测试用例生成装置，其特征在于，所述预设规则具体为：

仅保留所述场景数据中的正面数据或去除所述场景数据中的负面数据。