UML软件工程组织

 

 

基于需求的测试用例设计方法研究

2008-11-07 作者:刘柏,唐龙利,陈大圣 来源:中电网

 

1.引言

测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。测试用例目前没有经典的定义,比较通常的说法是指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,并形成文档。

由于对软件测试用例的作用和设计方法的理解不同,测试人员对软件测试用例存在不少片面的认识,具体表现在以下三个方面:

(1)测试输入数据设计方法等同于测试用例设计方法

一些测试书籍和文章经常这样表述:测试用例的设计方法包括:等价类、边界值、因果图、错误推测法、场景设计法等。这种表述是不全面的,这些方法只是软件功能测试用例设计中如何确定测试输入数据的方法,而不是测试用例设计的全部内容。测试用例设计是确定测试的输人数据过程,包括如何根据测试需求、设计规格说明等文档确定测试用例的设计策略、设计用例的表示方法和组织管理形式等内容。

(2)测试用例设计得越详细越好

尽可能设计足够多的设计用例,制定详细的用例执行步骤,以达到“任何一个人都可以根据测试用例执行测试”,这些都不是测试用例设计的本意。编写测试用例的根本目的是高效的发现软件产品中可能存在的缺陷,因此设计测试用例时应把握用最少的测试用例尽可能的覆盖测试需求,从而达到“少花时间多办事”的效果。

(3)测试用例设计是一成不变的

在软件生命周期过程中,存在用户对软件的功能的变更,设计规格的更新,软件代码的细化等情况。因此,设计软件测试用例与软件开发设计应当并行开展,并随着软件设计的变化进行相应调整,以保证设计的用例满足测试需求。

软件的类别、用户需求和测试目的不同,其测试用例也是不同的。本文主要从用户对软件的需求为着眼点,结合系统测试用例的设计,说明软件需求对软件测试用例设计的影响,使得测试用例更趋于针对软件产品的功能、任务规则和任务处理所设计的测试方案。

2.基于需求的测试用例

2.1 软件测试需求分析

软件测试的需求有三个层次,即任务需求、用户需求、功能需求,测试需求分析和测试用例设计参照的是软件需求规格说明书。

在软件需求规格说明书中的功能需求描述了软件系统所应具有的外部行为。对一个大型系统来说,软件功能需求可能只是系统需求的一个子集。作为功能需求的补充,软件需求规格说明还应包括隐含需求,它描述了系统展现给用户的行为和执行的操作等。包括产品必须遵从的标准、规范和合约;外部界面的具体细节;性能要求;设计或实现的约束条件及质量属性。

测试需求的主要来源是系统需求规格说明书,但有些需求是无法从需求文档中获得,可借助概要设计文档或者详细设计文档中获得,或直接从最终的软件产品上获得。测试人员依据这些信息编写测试需求,为了提高需求分析的覆盖率,用例设计人员可通过分析软件的任务规则和工程测试经验,提出软件产品隐含的需求,以保证最终的测试需求满足测试要求。

2.2 测试用例设计

测试用例的设计也就是测试需求细化的过程,可以说,有多细的测试需求,就有多细的测试用例。在测试用例的具体设计中,通常采用等价类划分法划分有效和无效的数据集,采用边界值法找到被测软件的输入数据的边界值数据,在基于需求的测试用例设计中,此两种方法既是基础又是补充,当测试数据量比较大时,通常采用自动化测试工具或正交试验法。测试用例的内容项可依据具体情况而定,通常包含测试用例编号、测试操作步骤和预期结果等。在软件系统测试过程中,软件需求决定了测试用例设计,而测试用例设计的效果则直接决定了整个软件测试项目的成败,因此测试需求分析和测试用例设计是密不可分的,前者是后者的依据,后者是前者的体现,做好需求到测试用例的转化,才能保证整个测试项目的效果。

2.3 测试用例运行

在软件系统测试过程中,软件测试需求决定了测试用例设计,而测试用例设计关系到测试用例的运行,应该说,设计出了什么样的测试用例,就需要针对性的选择测试用例运行方式。测试用例的运行一般采用测试者手工运行,编写驱动程序运行、借助自动化工具(如QTP)等方式运行。测试用例设计的优劣直接关系着测试用例运行的工作量,编写脚本自动运行程序是解决此问题的不错方式。现阶段,编写脚本自动运行程序来驱动测试用例是用例运行的趋势,这不仅可以节约第一次测试的工作量,而且还可以减少后续的回归测试的工作量。

3.测试用例设计实例

本文在这里将举例说明基于需求的测试用例设计过程,被测软件如图1所示,并比较不同的需求对测试用例设计的影响。

3.1 软件需求

软件的基本功能是比较简单的,即定义梁拱的基本参数并保存。需选择长度单位(米或毫米);需选择梁拱形式(折线、抛物线和圆弧);当梁拱形式为折线时,需输入长L和高H的值,当梁拱形式为抛物线或圆弧时,需输入高H的值;保存所选择或填写的梁拱的参数。

3.2 软件测试需求分析

从被测软件功能可以看出,被洲软件所实现的功能是比较简单的,只是选择或输入参数并保存数据。根据上述功能的描述,可以进行软件的需求分析,这里的需求分析主要是被测软件的功能需求分析。

另外,被测软件的功能描述实际上已经进行了一定的需求分析的。

为了更好的发现软件功能需求分析对测试用例的影响,下面针对被测软件给出两组不同的软件功能需求。发现软什功能需求分析对测试甩

(1)软件功能需求一

被洲软件:选择长度单位,米或皂水不可同时选择:选择梁拱形式,折线、抛物线或圆弧不可同时选择:当梁拱形式为折线时,输入长L和高H的值,当梁拱形式为抛物线或圆弧时,输入高H的值:保存所选择或填写的梁拱的数据。

(2)软件功能需求二

被测软件:选择长度单位,水或毫米不可同时选择:选择梁拱形式,折线、抛物线或圆弧不可同时选择:当梁拱肜式为折线时,输入框L和输入框H显示,输入长L和高H的值,当梁拱形式为抛物线或圆弧时,输E显示,输入高H的值:保存所选择或填与的梁拱的数的数据。

软件功能需求一和软件功能需求二的区别仅仅在于输入框L和输入框H显示或是不显示,对大多数人会忽略这一点,而这一点又一定程度上影响着测试用例的设计,并可以看出软件需求对测试用例的影响。

3.1 测试用例设计

依据软件功能的上述需求,借助Bender—R8T测试用例设计软件,设计出基于需求的测试用例设计框图,从而得到软件功能的测试用例。针对软件功能需求一和软件功能需求二,所得到的测试用例设计框图一和测试用例设计框图二如图2、图3所示。

根据测试用例设计框图一和测试用例设计框图二得到两组测试用例。第一组由3个测试用例组成,如表1所示;第二组由6个测试用例组成,如表2所示。

3.2 结果对比分析

从上面的两组测试用例可以明显看出,测试用例的数目是不同的,因此,所测试的结果也是不同的,第一组测试用例显然没有第二组测试用例的效果好,有些被测软件功能是没有被测试到的,这就源于被测软件的需求分析的不同,有了好的需求分析,就可以设计出功能覆盖率高的测试用例,达到软件测试的目的。

4.结束语

目前,软件测试用例设计是软件测试的重要环节,基于需求的软件测试用例设计可以一定程度上解决软件功能流程的测试,可以高效的设计测试用例,但是,此种方法还不能完全设计出全面的测试用例,尤其是输入数据多而繁琐的情况下,这就需要结合此种方法,应用自动化测试工具完成软件的测试。

 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号