CN102622294A - 生成用于不同测试类型的测试用例的方法和装置 - Google Patents

Abstract

本发明一个实施方式涉及生成用于不同测试类型的测试用例的方法和装置。在一个实施方式中，提供了一种为应用生成测试用例的方法，包括：基于应用的系统设计，创建应用的功能流程；针对至少一个测试类型，生成对应于功能流程各阶段的附加测试信息；以及基于附加测试信息和测试用例生成规则，生成测试用例。在另一实施方式中，提供了一种为应用生成测试用例的装置，包括：用于基于应用的系统设计、创建应用的功能流程的装置；用于针对至少一个测试类型、生成对应于功能流程各阶段的附加测试信息的装置；以及用于基于附加测试信息和测试用例生成规则、生成测试用例的装置。

Description

生成用于不同测试类型的测试用例的方法和装置

技术领域

本发明的各实施方式涉及数据处理，并且更具体地，涉及一种针对待测试应用生成用于不同测试类型的测试用例的方法、装置和相关计算机程序产品。

背景技术

随着计算机技术的发展，以硬件技术和软件技术为基础的各种应用为人们工作和生活提供了各种便捷的支持。然而在将这些应用投入正常使用之前，如何确保这些应用能够完全满足设计人员和开发人员的期望标准已经成为一个专门的研究方向。

目前，通常认为：测试是使用人工或自动化工具运行和测试某个系统的过程，目的在于验证它是否满足规定的需求或是检验预期结果与实际结果之间的差别。从中可以明确看出，测试是以确定是否满足需求为目标的。

为了保证全面完整地对待测试应用进行测试，测试类型通常可以分为：功能测试、系统测试、性能测试、安全测试、安全性测试、全球化测试以及可访问性(accessibility)测试，等等。测试用例(testcase)是为特定测试目标开发的测试输入、执行条件和预期结果的集合。针对不同测试类型需要设计相应的测试用例，以针对待测试应用的不同方面进行测试。现有技术中已经开发出了针对不同测试类型单独设计测试用例的方案。

发明内容

发明人发现，尽管在设计用于不同测试类型的测试用例时出发点不同，然而，因为待测试应用的预期实现目标是相同的，所以用于不同测试类型的测试用例彼此之间又是相关联的；这些测试用例从不同角度验证待测试应用是否满足预期标准。因而，针对不同测试类型的测试用例有可能共享测试步骤；如何在测试用例的设计、存储、执行时共享这些测试步骤，增强测试用例在针对不同测试类型的测试中的重用性成为一项难题。尽管现有技术中已经开发出了针对不同测试类型单独设计测试用例的方案，然而这些方案有可能造成人力、物力和时间上的浪费。在经验共享和资源重用理念的指导下，迫切需要一种可以针对待测试应用生成用于不同测试类型的测试用例的方法和装置。

因此，在尽量重用现有设置的前提下，如何实现针对待测试应用生成用于不同测试类型的测试用例成为一项亟待解决的问题。为此，提供了一种基于针对不同测试类型的附加测试信息，生成符合生成规则的测试用例的方法、装置和计算机程序产品。

在一个实施方式中，提供了一种为应用生成测试用例的方法，包括：基于应用的系统设计，创建应用的功能流程；针对至少一个测试类型，生成对应于功能流程各阶段的附加测试信息；以及基于附加测试信息和测试用例生成规则，生成测试用例。

根据本发明的又一实施方式，生成对应于功能流程各阶段的附加测试信息包括：基于与至少一个测试类型相关联的模板，生成对应于功能流程各阶段的附加测试信息。

根据本发明的又一实施方式，基于应用的系统设计、创建应用的功能流程包括：将应用抽象为：至少一个数据节点，至少一个活动节点(activity node)，以及至少一个数据节点和至少一个活动节点之间的关系。

根据本发明的又一实施方式，提供了一种为应用生成测试用例的装置，包括：用于基于应用的系统设计、创建应用的功能流程的装置；用于针对至少一个测试类型，生成对应于功能流程各阶段的附加测试信息的装置；以及用于基于附加测试信息和测试用例生成规则，生成测试用例的装置。

根据本发明的又一实施方式，用于生成对应于功能流程各阶段的附加测试信息的装置包括：用于基于与至少一个测试类型相关联的模板、生成对应于功能流程各阶段的附加测试信息的装置。

根据本发明的又一实施方式，用于基于应用的系统设计、创建应用的功能流程的装置包括：用于将应用抽象为以下的装置：至少一个数据节点，至少一个活动节点，以及至少一个数据节点和至少一个活动节点之间的关系。

采用根据本发明的各实施方式，解决了以往测试过程中测试用例。可以基于以往的最佳实践和经验积累，以规范化流程来管理设计测试用例的操作；并且还可以在针对不同待测试应用的测试过程中，不断积累经验并完善知识库的内容。

附图说明

结合附图并参考以下详细说明，本发明各实施方式的特征、优点及其他方面将变得更加明显，在附图中：

图1示意性示出了根据现有技术的生成用于不同测试类型的测试用例的方法的框图；

图2示意性示出了根据本发明一个实施方式的针对待测试应用生成用于不同测试类型的测试用例的数据流；

图3示意性示出了根据本发明一个实施方式的针对待测试应用生成用于不同测试类型的测试用例的方法的流程图；

图4示意性示出了根据本发明一个实施方式的针对待测试应用生成用于不同测试类型的测试用例的装置的数据结构设计图；

图5示意性示出了根据本发明一个实施方式如何基于生成规则生成用于不同测试类型的测试用例的示意图；以及

图6示意性示出了根据本发明一个实施方式的针对待测试应用生成用于不同测试类型的测试用例的装置的框图。

具体实施方式

下面参考附图详细描述本发明的各实施方式。

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

参考图1，图1示意性示出了根据现有技术的生成用于不同测试类型的测试用例的方法的框图100。在现有技术中，针对一个待测试应用，需要进行不同类型的测试，通常针对每种测试类型需要设计验证列表，在该验证列表中，定义了多个验证点，验证点也即在进行相应类型测试时需要验证的对象。在进行测试时，需要针对验证列表中的验证点逐个验证。如图1所示，在针对待测试应用160进行测试时，需要分别设计：用于性能测试的性能测试用例110及相关验证列表112、用于可访问性测试的可访问性测试用例120及相关验证列表122、用于功能测试的功能测试用例130及相关验证列表132、用于系统测试的系统测试用例140及相关验证列表142以及用于其他测试类型的测试用例150及相关验证列表152。

然而应当理解，图1所示的生成测试用例的方法中存在一定程度的资源浪费。例如仅以功能测试、性能测试和可访问性测试为例，说明用于不同测试类型的测试用例之间存在重用的可能性。简言之，功能测试一般指验证待测试应用是否能够完成期望的设计功能，性能测试一般指验证待测试应用是否能在期望时间内作出响应，而可访问性测试可以指验证待测试系统的界面设计或者语音提示等对用户是否有好并便于用户使用。

现在以自动存取款机(ATM)为示例说明图1所示现有技术方案的不足。在用户向ATM机中插卡后等待ATM响应的场景中，可以认为ATM在接受银行卡插入后是否转向预期的密码输入页面是一种功能测试，可以认为测试ATM的响应时间是否满足设计要求是一种性能测试，可以认为测试ATM在插卡后是否播放指示用户输入密码的语音提示是一种可访问性测试。在具体测试时，上述性能测试和可访问性测试不能脱离用户插卡并等待ATM响应这一应用场景而单独存在。也即，功能测试、性能测试、可访问性测试三种测试用例将可以共享某些测试步骤，三者区别在于用于不同测试的验证列表中的验证点有所不同。上述示例中性能测试的验证点可以是，ATM在用户插卡后的响应时间不超过3秒；而可访问性测试的验证点可以是，是否播放指示用户输入密码的语音提示。

在上文示例中，尽管三种测试类型在很大程度上共享了测试步骤，然而根据图1所示的方法，还需要针对不同测试类型重复设计测试用例并且设计相应的验证列表。这造成了人力、物力和时间等多方面的浪费。

此外，用户很难将不同测试类型的测试用例关联起来，比如上述的性能测试用例、功能测试用例以及可访问性测试用例之间存在关联关系，即需要执行相同的操作。但是在已有的测试用例设计方法中，这些测试用例之间都是相互独立的，需要测试者人工理解其间的相互关系。这样在测试的具体执行过程中也会造成人力，物力和时间等方面的浪费。

在下文中，将参考图2至图6详细描述根据本发明的实施方式，首先参考图2解释本发明一个实施方式的原理。如图2所示，该图示意性示出了本发明一个实施方式的针对待测试应用生成用于不同测试类型的测试用例的数据流200。各种类型测试的侧重点是不同的。在一个实施方式中，首先确定待测试应用的具体功能流程，然后在此基础上针对不同测试类型进行进一步操作，例如，设计出覆盖所有功能流程分支的验证点。

如图2所示，在分析得出待测试应用的功能流程210后，再针对不同测试类型，从不同角度出发设计每种类型测试中待测试应用应当满足的条件(例如，需要被验证的验证点及相关数据)，这对应于图2所示的附加测试信息220。应当注意，验证点是与待测试应用的功能流程相关联的，处于流程中不同的阶段，需要测试的验证点也不同。图2所示的附加测试信息220可以包括针对功能流程中不同阶段的附加测试信息，例如附加测试信息222、附加测试信息224和附加测试信息226等。由于这些附加测试信息220记录了各个步骤中待测试应用应当满足的条件，因而可以基于附加测试信息220和生成规则230，来生成用于不同测试类型的测试用例240。

采用本发明一个实施方式所述的方法，不同类型的测试用例是基于待测试应用的功能流程而生成的，因而不同类型的测试用例是彼此关联的，而并非现有技术中那样是孤立的测试用例，促使测试人员在设计测试用例过程中可以把精力集中在测试本身，而不是集中在对待测试应用流程的理解上。

在下文中，将仅以ATM作为待测试应用的具体示例描述根据本发明一个实施方式的方法和装置。应当注意，根据本发明的实施方式，待测试应用可以包括基于软件、基于硬件以及基于二者结合来实现特定预期功能的任何应用，采用ATM作为示意性实施方式的目的在于以人们熟知的自动存取款机的操作流程阐述如何生成用于不同测试类型的测试用例。

现在简要分析ATM的应用场景：ATM中存有一定数量的现金，用户可以向ATM插入银行卡，在输入密码验证通过后执行取款或者存款的操作。开发人员在开发ATM过程中，已经考虑了实际应用中可能出现的情况，例如：用户输入正确或者错误的密码、用户选择提取不同额度的现金、用户分几次取款/存款、一个银行有几个ATM同时被操作，等等。

针对上述情况，在测试ATM时可以存在多种类型的测试：针对在用户操作过程中出现的每个新的用户界面，进行可访问性测试；当出现数据变化(例如，用户存款、取款导致用户账户余额和ATM内现金余额变化)时，进行功能测试；对于每次执行的操作进行性能测试，等等。

现在参见图3详细描述本发明的实施方式，图3示意性示出了根据本发明一个实施方式的针对待测试应用生成用于不同测试类型的测试用例的方法的流程图300。在步骤302中，基于应用的系统设计，创建应用的功能流程。创建功能流程的目的包括，以功能流程的形式描述待测试应用的不同操作分支。例如，在用户向ATM插入银行卡并输入密码时，基于输入密码是正确还是错误，可以产生两个操作分支。在不同实施方式中，可以通过多种方式从系统设计创建功能流程，该系统设计例如可以包括应用程序代码、标准设计流程以及人工输入等。

应当理解，应用程序代码和标准设计流程是完整描述待测试应用的功能的文档，因而通过导入程序代码或者标准设计流程(例如以UML描述)，可以获得描述待测试应用在多种情况(包括正常情况和异常情况)下操作的操作流程分支。该操作流程的分支可以作为后续添加附加测试数据的基础。根据一个实施方式，可以采用导入程序代码和/或标准设计流程实现，或者还可以包括人工输入，例如人工选择程序代码和标准设计相结合的方式。

继而在步骤304中，针对至少一个测试类型，生成对应于功能流程各阶段的附加测试信息。附加测试信息可以是针对不同测试类型设置的，在添加附加测试信息的过程中，即引入了不同测试类型所关注信息。也即，完整的附加测试信息可以从不同角度表示：在多种类型测试中待测试应用应当满足什么条件。在步骤S306中，基于附加测试信息和测试用例生成规则，生成测试用例。在一个实施方式中，可以指定一项或者多项生成规则，或者使用默认生成规则。

在一个实施方式中，生成对应于功能流程各阶段的附加测试信息包括：基于与至少一个测试类型相关联的模板，生成对应于功能流程各阶段的附加测试信息。在这里，可以针对添加的任何附加测试信息定义模板，并且模板可以针对不同的测试类型(功能测试、系统测试、性能测试、安全性测试、全球化测试以及可访问性测试等)存储，也可以按照不同的应用类型存储。应当注意，对于不同的待测试应用，并不需要针对每种测试类型都设置模板，而是可以根据需要针对应用的哪些方面执行测试而进行定制。例如对于待测试应用A，可以设置与功能测试、系统测试相关联的模板；而针对待测试应用B，可以设置与性能测试、安全性测试、全球化测试相关联的模板。

设置模板的目的包括统一测试人员在设计测试用例时的思路，并且模板可以记录测试团队总结的最佳实践，并作为测试团队的知识管理工具，来实现将以往总结的测试经验应用于新的待测试应用。此外，模板还可以自动集成测试数据的生成算法。并且还可以随着针对新的待测试应用的操作而不断积累和丰富多种模板。

在一个实施方式中，基于应用的系统设计、创建应用的功能流程包括：将应用抽象为：至少一个数据节点，至少一个活动节点，以及至少一个数据节点和至少一个活动节点之间的关系。

对于不同测试类型而言，需要基于待测试应用在应用运行过程中不同情况下的数据或者活动来执行验证，因而本发明一个实施方式的方法采取了以数据节点和活动节点来描述待测试应用功能流程的方式。应当注意，当采用数据节点和活动节点来描述待测试应用的功能流程时，数据节点表示应用操作过程中涉及的数据的集合，而活动节点表示推进功能流程向前运动的活动。在一个实施方式中，数据节点中还包括输入变量集合。输入变量的含义是，在待测试应用进行到某阶段时所涉及变量的集合。例如，在用户向ATM插入银行卡并输入密码时，输入变量集合可以包括{ATM中现金余额，用户卡号，用户输入的密码}。在上文ATM的示例的用户插卡、输入密码并取款的过程可以抽象为如表1所述的数据节点，以及如表2所述的活动节点。应当注意，在表1中，第三列“输入变量集合”表示数据节点中包括的输入变量；在表2中，第三列“描述”表示动作节点所代表动作的概括介绍。

表1 数据节点

表2 活动节点

在一个实施方式中，附加测试信息包括以下至少一项：至少一个数据节点的输入数据集合；至少一个数据节点的验证点集合；至少一个活动节点的验证点集合；至少一个数据节点之间的关联关系；至少一个活动节点之间的关联关系；以及输入数据集合与验证点集合之间的相关关系。

现在将针对上文所述的附加测试信息的类型，详述模板的含义以及具体生成过程。由于附加测试信息可以包括多项内容，可以针对其中某些内容设置公共模板，而针对与测试类型有关内容(诸如测试点)设置与测试类型相关联的模板。用于输入数据集合的模板可以描述与输入数据集合相关的来源，例如输入数据集合模板中的数据可以通过如下方式获取：(1)普通数据输入(依据不同输入数据类型可以分为文本，数字等)；(2)与具体数据内容文件的接口(例如，在验证待测试应用是否满足多语言支持时，可以采用excel等文件存储包括不同语言的测试数据用作输入)；(3)与数据生成器的接口(例如，产生随机字符串、随机数等)。

此外，还可以针对输入数据集合的关系定义模板，例如包括：(1)通用的数据变量间关系(定义变量间数学关系，或者来自于文件的位置关系)；(2)与算法(例如，正交测试数据准备算法、等价类测试数据准备算法等)工具的接口，用户可以选择不同数据节点上的变量，为每个变量生成相应的值的集合，然后调用与算法工具的接口为这些变量生成指定关系的数据集合。比如，用户分别选择了如下文表3表示的输入变量：

表3 输入变量及相应的输入数据集合

序号	输入变量	输入数据集合
			1	VAR1	{1，2}
2	VAR2	{5，6}
			3	VAR6	{7，8}

当需要定义(VAR1，VAR2，VAR6)的正交数据时，则可以调用正交测试数据准备接口以生成适当输入数据集合{1，5，7}，{1，6，8}，{2，6，7}。

此外，还可以针对验证点设置模板，例如，(1)为不同的测试类型定义验证点池(如，性能测试验证点池、安全性测试验证点池、功能测试验证点池、其他测试类型的验证点池，等)，各验证点池中的验证点可以预先定制，也可以被不同的生成测试用例的方法共享)；(2)验证点相关变量(数据节点-变量名称)；(3)以及验证关系。

应当注意，设置验证点池可以极大地重复利用测试团队在以往测试中积累的经验，以便将来设置验证点时作为参考。就安全验证测试验证点池而言，可以将以往测试进行用户验证时使用的验证点加入验证点池，例如验证点可以包括：当用户输入密码时，以“*”显示输入的密码；在用户输入密码的界面中，语音提示用户注意身边是否有陌生人，等等。由于验证点池的存在，在针对ATM进行测试时，可以直接采用从验证点池中选择适合的验证点模板，而无需用户重复设计验证点。应当注意，针对不同的测试类型设置相应的验证点池，有助于在后续的生成步骤中生成用于不同测试类型的相应验证点。

在下文中，将结合ATM的具体示例描述如何利用与不同测试类型相关联的模板，向如表1所示的数据节点以及表2所示的活动节点添加附加测试信息。

1.数据节点Data0

该数据节点Data0的输入变量集合为{ATM中现金余额VAR1，用户卡号VAR2，用户输入的密码VAR3}。在定义输入数据集合时，上下文引用关系为建立数据和分支之间的关系，此时可能出现的数据分支是(1)自动取款机验证卡号/密码成功；(2)自动取款机验证卡号/密码失败。

此时需要生成两组输入数据，一组用于使操作流程前进至分支(1)中的正确的卡号/密码，而另一组用于使操作流程前进至分支(2)中的错误的卡号/密码。假设此时预先设置了保存正确卡号/密码的数据文件(例如，excel文件)，并且卡号和密码分别位于该文件中同一行的两个字段中，则针对分支(1)可以选择上文所述的“与具体数据内容文件的接口”模板来生成卡号/密码，并且此时输入变量的关系为，卡号VAR2和密码VAR3来自数据文件中的同一行。对于分支(2)，则可以选择上文所述的“与数据生成器的接口”模板，采用随机生成的字符串来作为输入数据卡号VAR2和密码VAR3。由于采用两个随机字符串分别作为卡号和密码的输入值，则可以认为这样生成的卡号和密码不可能是相匹配的正确卡号和密码。此时即可得出分别用于分支(1)的能够验证通过的卡号/密码、和用于分支(2)的不能验证通过的卡号/密码的输入数据集合。

2.活动节点Activity1-1

现在描述向节点Activity1-1添加附加测试信息的细节。节点Activity1-1是活动节点，该活动的具体描述是，ATM验证卡号/密码成功，提示可以允许的操作。此时可以分别添加用于性能测试和安全测试的验证点。也即应用性能测试验证点池，选取其中的验证点模板：当并发用户为N时，验证响应时间不超过M秒，此时仅需要在模板中填写具体的M和N的数值即可。并且应用安全测试验证点池，选取其中的验证点模板：验证用户输入的密码为不可见字符串(例如，以“*”表示)。

3.数据节点Data1-2

现在描述向节点Data1-2添加附加测试信息的细节。数据节点Data1-2的输入变量集合为{卡片余额VAR4，允许用户输入的取款数额VAR5}。在定义输入数据集合时，上下文引用关系为建立当前输入数据和其他数据之间的关系满足如下条件：在当前逻辑分支中，卡片余额VAR4-允许用户输入的取款数额VAR5＞＝0，并且在当前逻辑分支中，ATM中现金余额-允许用户输入的取款数额VAR5＞＝0。由此可以选取“与数据生成器的接口”模板(比如，生成随机数等)。并且附加数据关系模板为“通用的数据变量间关系”，如情况1：VAR4-VAR5＞＝0，情况2：VAR5-VAR4＞0。

由于在该数据节点的输入变量包括允许用户输入的取款数额VAR5，由此涉及用户输入，在定义验证点时还可以应用接入性测试验证点池，选取如下验证点模板：验证操作时有语音提示，以方便盲人可以操作。

另外，在此数据节点中需要验证取款之前的卡片余额与账户当前余额是否相等，因而可以应用“验证相关变量”模板，选择变量为Data1-2数据节点中的变量卡片余额VAR4，验证值为在数据节点Data0中的用户卡号为VAR2的卡片余额。

4.活动节点Activity1-3

现在描述向节点Activity1-3添加附加测试信息的细节。节点Activity1-3是活动节点，其活动描述为：ATM取款给用户，卡片余额和ATM中现金余额减少。此时仅需应用性能测试验证点池，选取其中的验证点模板：当并发用户为N时，验证响应时间不超过M秒，此时仅需要在模板中填写具体的M和N的数值即可。

5.数据节点Data1-4

该数据节点对应的输入数据集合是{卡片余额VAR6，ATM中现金余额VAR7}。由于此时无上下文引用，因而无需定义输入数据集。在定义验证点是，选择“验证相关变量”模板，并选择变量为数据节点Data1-4中的卡片余额VAR6，验证值为数据节点Data1-2中的卡片余额VAR4-允许用户输入的取款数额VAR5。

6.活动节点Activity2-1

该节点对应活动为ATM验证卡号/密码失败，提示重新操作。与针对活动节点Activitiy1-1时相同，此时可以分别添加用于性能测试和安全测试的验证点。也即应用性能测试验证点池，选取其中的验证点模板：当并发用户为N时，验证响应时间不超过M秒，此时仅需要在模板中填写具体的M和N的数值即可。并且应用安全测试验证点池，选取其中的验证点模板：验证用户输入的密码为不可见字符串(例如，以“*”表示)。

7.数据节点Data2-2

该数据节点对应的输入变量集合为{允许用户输入的卡号VAR2，密码VAR3}。定义输入数据集合时的上下文为，自动取款机验证卡号/密码失败，因而可以选择引用之前生成的同变量名数据模板，也即，使用在数据节点Data0中生成变量VAR2和变量VAR3，或者，还可以选择上文所述的“与数据生成器的接口”模板，采用随机生成的字符串来作为输入数据卡号VAR2和密码VAR3。注意，只要此时输入数据集合中的数据是不能验证通过的卡号/密码即可。并且应用功能测试验证点池，选取其中验证点模板：认证失败。

8.活动节点Activity2-3

该活动节点对应的活动是，输入密码3次失败，锁卡。与针对活动节点Activitiy1-1时相同，此时可以分别添加用于性能测试和安全测试的验证点。也即应用性能测试验证点池，选取其中的验证点模板：当并发用户为N时，验证响应时间不超过M秒，此时仅需要在模板中填写具体的M和N的数值即可。并且应用安全测试验证点池，选取其中的验证点模板：验证用户输入的密码为不可见字符串(例如，以“*”表示)。

在上文中，已经针对功能流程中的各数据节点和活动节点描述了如何利用模板添加附加测试数据的具体示例，现在描述输入数据集合以及验证点集合之间的关系。

在一个实施方式中，还包括将关联关系指定为以下之一：前驱关系、后继关系和并行关系。由于关联关系包括数据节点之间的关联和活动节点之间的关联，由此可以指定数据节点之间的关系，进而将与数据节点相对应的输入数据集之间的关系指定为：前驱关系、后继关系以及并行关系。可以认为关联关系描述的是在具体测试用例中，数据节点之间以及活动节点之间的时间顺序关系，这种时间顺序可以是串行关系(包括前驱关系和后继关系)还可以是并行关系。例如可以指定如下的前驱、后继关系：Data0→Data2-2→Data1-2→Data1-4，则会生成一个测试用例为：用户先输入错误的密码，之后输入了正确的密码并取款成功。又例如，可以指定活动节点之间的关系：前驱关系、后继关系以及并行关系。例如指定Activity2-1与Activity1-1并行，则会生成一个测试用例，表示同一个用户在取款的同时也在进行密码的修改。

在一个实施方式中，还包括将相关关系指定为以下之一：验证关系和并行关系。验证关系基于添加验证点而自动生成，例如：为验证数据节点Data1-4中的卡片余额VAR6，相应的验证值为数据节点Data1-2中卡片余额VAR4-允许用户输入的取款数额VAR5。

在一个实施方式中，系统设计包括以下至少一个：应用程序代码、标准设计流程以及人工输入。

在一个实施方式中，至少一个测试类型包括以下之一：功能测试、系统测试、性能测试、安全性测试、全球化测试以及可访问性测试。在一个实施方式中，生成规则包括以下至少一项：测试用例类型以及用户指定规则。根据本发明的又一实施方式，测试用例属于以下类型之一：手工测试用例、静态测试用例以及自动化脚本测试用例。应当注意，用户指定规则是指由用户指定测试用例生成规则参数。例如，用户可以指定每个测试用例包含的验证点不超过5个，不同测试用例之间共有的步骤不超过5个。

应当注意，测试用例的类型不同于测试的类型，测试类型是指上文所述的功能测试、系统测试、性能测试、安全性测试、全球化测试以及可访问性测试等，并且在设置验证点池时可以针对不同的测试类型来进行设置。而测试用例类型是指该测试用例在什么样的条件下使用，例如在测试人员的手工测试中使用，在静态测试中使用或者在自动化脚本测试中使用。

现在继续参见图4，图4示意性示出了根据本发明一个实施方式的针对待测试应用生成用于不同测试类型的测试用例的装置的数据结构设计图400。如图4所示，本发明一个实施方式的装置在数据结构设计上可以分为三个层次，即功能流程层420、附加测试信息层430以及测试规则层440。其中功能流程层420中的数据来自待测试应用，例如在需要对待测试应用一410-1进行测试时，可以将待测试应用一410-1的应用程序代码或者标准设计流程以及相关人工输入作为输入数据。又例如，如果待测试应用是一个应用系统，包括存在调用关系的多个应用时，还可以将涉及到的全部待测试应用(例如，待测试应用一410-1、待测试应用二410-2、…、待测试应用N 410-N)用作输入，以便生成整体反映待测试应用系统操作的功能流程。

附加测试信息层430中的附加测试信息是针对功能流程层420中生成的功能流程中各个步骤应当满足关系的细化，例如可以从模板库432中选取有关数据。最后基于附加测试信息层430和测试规则层440来生成测试用例450。

参见图5，图5示意性示出了根据本发明一个实施方式如何基于生成规则生成用于不同测试类型的测试用例的示意图500。基于前文描述可知，本发明一个实施方式的方法可以针对不同测试类型生成测试用例，其中，针对不同测试类型，添加关于功能流程中每个步骤的附加测试信息，以及设置多种模板并建立了用于不同测试类型的验证点池，在添加附加测试数据时仅需要从适当的验证点池选取验证点模板即可获得用于不同测试类型的验证列表。

如图5中框图510所示，在添加附加测试数据时考虑了多种测试类型(如，功能测试511、系统测试512、性能测试513、可访问性测试514以及其他的测试类型)，并且在测试规则中考虑到了用户指定规则530、以及多种测试用例类型(手工测试用例521、静态测试用例522、自动化脚本测试用例523和其他测试用例524)，因而在生成测试用例540时，可以将上述所有可选因素进行组合，在生成测试用例中引入了极大的灵活性，并且实现了测试经验的充分共享，继而允许测试人员基于待测试应用的功能流程动态定制测试用例。

继续上文中ATM的示例，现在详述用于基于附加测试信息、生成符合生成规则的测试用例的具体示例。在以下具体示例中将充分体现结合图5所示的本发明一个实施方式的优势。用户可以指定如下生成规则：测试用例类型为手工测试用例、静态测试用例以及自动化脚本测试用例，并且用户指定规则为每个测试用例包含的验证点不超过5个，不同测试用例之间共有的步骤不超过5个。根据本发明的一个实施方式，将自动生成如下文表4、表5和表6所示的测试用例。

表4 测试用例1

表5 测试用例2

表6 测试用例3

3.自动化脚本测试用例(针对表1中的手工测试用例)
	将“用户输入、系统显示、验证、点击等”手工测试用例中的关键

应当注意，可以将所生成的测试用例进行拆分和/或组合。根据一个实施方式，可以将步骤较长的测试用例拆分为多个步骤较短的测试用例。例如，针对如下测试用例：用户先输入错误的密码，之后输入了正确的密码并取款成功，可以将其拆分为两个测试用例：(1)用户输入错误的密码，和(2)用户输入了正确的密码并取款成功。根据另一实施方式，还可以将上述两个单独的测试用例组合为一个测试用例。

参见图6，该图示意性示出了根据本发明一个实施方式的针对待测试应用生成用于不同测试类型的测试用例的装置600的框图。图6与图4中的数据结构设计图相对应，并从装置中各个模块完成功能的角度示出了装置600的构成。

在一个实施方式中，提供了一种为应用生成测试用例的装置600，包括：创建装置610，基于应用的系统设计、创建应用的功能流程；添加装置620，针对至少一个测试类型，生成对应于功能流程各阶段的附加测试信息；以及生成装置630，基于附加测试信息和测试用例生成规则，生成测试用例。

在另一实施方式中，用于生成对应于功能流程各阶段的附加测试信息的装置包括：用于基于与至少一个测试类型相关联的模板、生成对应于功能流程各阶段的附加测试信息的装置。

在另一实施方式中，用于基于应用的系统设计、创建应用的功能流程的装置包括：用于将应用抽象为以下的装置：至少一个数据节点，至少一个活动节点，以及至少一个数据节点和至少一个活动节点之间的关系。

在另一实施方式中，附加测试信息包括以下至少一项：至少一个数据节点的输入数据集合；至少一个数据节点的验证点集合；至少一个活动节点的验证点集合；至少一个数据节点之间的关联关系；至少一个活动节点之间的关联关系；以及输入数据集合与验证点集合之间的相关关系。

在另一实施方式中，还包括用于将关联关系指定为以下之一的装置：前驱关系、后继关系和并行关系。

在另一实施方式中，还包括用于将相关关系指定为以下之一的装置：验证关系和并行关系。

在另一实施方式中，系统设计包括以下至少一个：应用程序代码、标准设计流程以及人工输入。

在另一实施方式中，至少一个测试类型包括以下之一：功能测试、系统测试、性能测试、安全性测试、全球化测试以及可访问性测试。

在另一实施方式中，生成规则包括以下至少一项：测试用例类型以及用户指定规则。

在另一实施方式中，测试用例属于以下类型之一：手工测试用例、静态测试用例以及自动化脚本测试用例。

相对于现有技术，本发明的实施方式优势包括，可以规范测试团队的操作流程，重用测试团队在以往测试中积累的经验，并且还可以将用于不同测试类型的测试用例进行关联。

本发明一个实施方式可以采取硬件实施方式、软件实施方式或既包含硬件组件又包含软件组件的实施方式的形式。在优选实施方式中，本发明一个实施方式实现为软件，其包括但不限于固件、驻留软件、微代码等。

而且，本发明一个实施方式还可以采取可从计算机可用或计算机可读介质访问的计算机程序产品的形式，这些介质提供程序代码以供计算机或任何指令执行系统使用或与其结合使用。出于描述目的，计算机可用或计算机可读机制可以是任何有形的装置，其可以包含、存储、通信、传播或传输程序以由指令执行系统、装置或设备使用或与其结合使用。

介质可以是电的、磁的、光的、电磁的、红外线的、或半导体的系统(或装置或器件)或传播介质。计算机可读介质的例子包括半导体或固态存储器、磁带、可移动计算机磁盘、随机访问存储器(RAM)、只读存储器(ROM)、硬磁盘和光盘。目前光盘的例子包括紧凑盘-只读存储器(CD-ROM)、压缩盘-读/写(CD-R/W)和DVD。

适合于存储/或执行程序代码的数据处理系统将包括至少一个处理器，其直接地或通过系统总线间接地耦合到存储器元件。存储器元件可以包括在程序代码的实际执行期间所利用的本地存储器、大容量存储器、以及提供至少一部分程序代码的临时存储以便减少执行期间从大容量存储器必须取回代码的次数的高速缓存存储器。

输入/输出或I/O设备(包括但不限于键盘、显示器、指点设备等等)可以直接地或通过中间I/O控制器耦合到系统。

网络适配器也可以耦合到系统，以使得数据处理系统能够通过中间的私有或公共网络而耦合到其他数据处理系统或远程打印机或存储设备。调制解调器、线缆调制解调器以及以太网卡仅仅是当前可用的网络适配器类型的几个例子。

从上述描述应当理解，在不脱离本发明真实精神的情况下，可以对本发明各实施方式进行修改和变更。本说明书中的描述仅仅是用于说明性的，而不应被认为是限制性的。本发明的范围仅受所附权利要求书的限制。

Claims (20)

1.一种为应用生成测试用例的方法，包括：

基于所述应用的系统设计，创建所述应用的功能流程；

针对至少一个测试类型，生成对应于所述功能流程各阶段的附加测试信息；以及

基于所述附加测试信息和测试用例生成规则，生成所述测试用例。

2.根据权利要求1所述的方法，其中生成对应于所述功能流程各阶段的附加测试信息包括：

基于与所述至少一个测试类型相关联的模板，生成对应于所述功能流程各阶段的所述附加测试信息。

3.根据权利要求1或2所述的方法，其中基于所述应用的系统设计、创建所述应用的功能流程包括：将所述应用抽象为：

至少一个数据节点，

至少一个活动节点，以及

所述至少一个数据节点和所述至少一个活动节点之间的关系。

4.根据权利要求3所述的方法，其中所述附加测试信息包括以下至少一项：

所述至少一个数据节点的输入数据集合；

所述至少一个数据节点的验证点集合；

所述至少一个活动节点的验证点集合；

所述至少一个数据节点之间的关联关系；

所述至少一个活动节点之间的关联关系；以及

所述输入数据集合与所述验证点集合之间的相关关系。

5.根据权利要求4所述的方法，还包括将所述关联关系指定为以下之一：前驱关系、后继关系和并行关系。

6.根据权利要求4所述的方法，还包括将所述相关关系指定为以下之一：验证关系和并行关系。

7.根据权利要求1或2所述的方法，其中所述系统设计包括以下至少一个：应用程序代码、标准设计流程以及人工输入。

8.根据权利要求1或2所述的方法，其中所述至少一个测试类型包括以下之一：功能测试、系统测试、性能测试、安全性测试、全球化测试以及可访问性测试。

9.根据权利要求1或2所述的方法，其中所述生成规则包括以下至少一项：测试用例类型以及用户指定规则。

10.根据权利要求1或2所述的方法，其中所述测试用例属于以下类型之一：手工测试用例、静态测试用例以及自动化脚本测试用例。

11.一种为应用生成测试用例的装置，包括：

用于基于所述应用的系统设计、创建所述应用的功能流程的装置；

用于针对至少一个测试类型、生成对应于所述功能流程各阶段的附加测试信息的装置；以及

用于基于所述附加测试信息和测试用例生成规则、生成所述测试用例的装置。

12.根据权利要求11所述的装置，其中用于生成对应于所述功能流程各阶段的附加测试信息的装置包括：

用于基于与所述至少一个测试类型相关联的模板、生成对应于所述功能流程各阶段的所述附加测试信息的装置。

13.根据权利要求11或12所述的装置，其中用于基于所述应用的系统设计、创建所述应用的功能流程的装置包括：用于将所述应用抽象为以下的装置：

至少一个数据节点，

至少一个活动节点，以及

所述至少一个数据节点和所述至少一个活动节点之间的关系。

14.根据权利要求13所述的装置，其中所述附加测试信息包括以下至少一项：

所述至少一个数据节点的输入数据集合；

所述至少一个数据节点的验证点集合；

所述至少一个活动节点的验证点集合；

所述至少一个数据节点之间的关联关系；

所述至少一个活动节点之间的关联关系；以及

所述输入数据集合与所述验证点集合之间的相关关系。

15.根据权利要求14所述的装置，还包括用于将所述关联关系指定为以下之一的装置：前驱关系、后继关系和并行关系。

16.根据权利要求14所述的装置，还包括用于将所述相关关系指定为以下之一的装置：验证关系和并行关系。

17.根据权利要求11或12所述的装置，其中所述系统设计包括以下至少一个：应用程序代码、标准设计流程以及人工输入。

18.根据权利要求11或12所述的装置，其中所述至少一个测试类型包括以下之一：功能测试、系统测试、性能测试、安全性测试、全球化测试、可访问性测试。

19.根据权利要求11或12所述的装置，其中所述生成规则包括以下至少一项：测试用例类型以及用户指定规则。

20.根据权利要求11或12所述的装置，其中所述测试用例属于以下类型之一：手工测试用例、静态测试用例以及自动化脚本测试用例。

Images