可靠性测试用例（通用7篇）
可靠性测试用例 篇1
0 引言
软件可靠性工程是指为了满足软件的可靠性要求而进行的一系列设计、分析、测试等工作。
软件可靠性测试是在软件生存周期的系统测试阶段提高软件可靠性水平的有效途径。各种测试方法、测试技术都能发现导致软件失效的残存缺陷,排除这些缺陷后,一般来讲一定会实现软件可靠性的增长,但是排除这些缺陷对可靠性提高的作用却是不一样的。其中,软件可靠性测试能最有效地发现对可靠性影响大的缺陷,可以有效地提高软件的可靠性。
1 软件可靠性测试的基本概念
软件可靠性是指:(1)在规定的条件下,在规定的时间内,软件不引起系统失效的概率,该概率是系统输入和系统使用的函数,也是软件中存在的缺陷的函数。系统输入将确定是否会遇到已存在的缺陷;(2)在规定的时间周期内,在所述条件下程序执行所要求的功能的能力[1]。这个定义是经美国标准化研究所批准作为美国的国家标准。1989年,我国国标GB/T-11457[2]也采用了这个定义。
软件可靠性测试是为了满足软件可靠性要求、评估软件可靠性水平而对软件进行的测试。它的主要目的是通过测试发现并纠正软件中的缺陷,实现或验证用户对软件的可靠性要求,提高软件的可靠性[3]。它的基本思想是按照软件的测试模型对软件进行测试。因此,经过测试获得的失效数据与软件在实际使用中获得的失效数据比较接近,可直接用于软件的可靠性评估。
软件可靠性是软件质量特性中重要的固有特性和关键因素。软件可靠性测试是可靠性工作的重要组成部分,它既适用于软件开发过程,也适用于最终的软件产品。软件可靠性测试是提高软件可靠性、定量评定可靠性水平的关键技术,其中的难点和核心在于测试用例的设计和生成,它决定着软件测试质量的高低。
2 软件可靠性测试过程
我们可以将软件可靠性测试的一般流程表示如图一所示。
测试的主要活动包括:
(1)构造测试模型:可靠性测试所用的“测试模型”是关于如何使用系统的一种定量特征描述,即系统的输入值按其时间的分布或按它们在可能输入范围内出现概率的分布来描述。测试模型是否能真实的刻画软件的实际使用情形取决于可靠性工程人员对软件系统模式、功能、任务需求及相应输入的分析,取决于他们对用户使用这些系统模式、功能、任务概率的了解。测试模型构造的好坏,将对后续测试用例产生、可靠性测试的准确性产生重要影响。
(2)构建测试环境:可靠性测试应尽量在软件的真实运行环境中执行,这样测得数据的指导性才强。然而在真实的环境下进行可靠性测试大多不切实际,因此需要我们开发相应的仿真运行环境来支持可靠性测试的开展。
(3)生成、选取测试用例,执行测试:软件可靠性测试的用例是根据测试模型随机生成的。利用这些测试用例,在真实的或仿真的测试环境中,对系统进行可靠性测试。
(4)结果分析:对测试所得的结果进行分析,并作出可靠性预计。
(5)可靠性评价,确定测试是否停止:利用某种可靠性评价方法对测试结果进行分析,评价和预计软件的可靠性,以确定测试停止的时机。
3 基于UML的Markov链使用模型的构建
使用模型是指系统使用中所有可能的情形及其发生的概率。基于使用模型的可靠性测试就是建立软件的使用模型、根据使用模型产生测试用例(软件所有可能输入的一个子集)和度量软件的可靠性的过程。
本文基于UML扩展技术,构建了不同等级的Mar kov链使用模型,进而生成可靠性测试所需的测试用例,完成对软件的可靠性测试工作。下面是对构件使用模型的介绍。
3.1 什么是Mar kov模型
Mar kov模型用马尔可夫过程来描述软件的使用方式,该模型下,任何下一个事件的发生只和当前的状态有关,不涉及历史信息。
在Mar kov模型中,使用模型由状态和边组成。状态表示软件使用过程中的内部环境,边表示状态间的转移关系。每条边都有一个激励输入与之对应,表明在当前状态下输入这种激励使软件转移到下一个状态。每条边都有一个转移概率,转移概率标志了状态转移发生的可能性。特定状态的所有出边的转移概率之和应该为1。每一个使用模型都有唯一的初态和终态。初态是使用模型的初始状态,它是每一次软件使用的开始。终态是使用模型的终止状态,它是软件每一次使用的终结。软件的每一次使用或者说每一次操作都从初态开始经过若干个中间状态,最后到达终态。通常情况下,每个使用模型都有唯一的初态,终态可以有多个。
3.2 基于UML的软件Mar kov链使用模型的构建
Mar kov链使用模型由软件的需求分析文档或设计文档产生,而不需要软件的代码,因此它可以和软件的需求分析、设计同时进行,不必等到软件编码完成后再进行。
在软件UML模型中,用例和场景常用作需求描述的工具。用例从用户角度给出了软件系统级功能规范,反映用户实际使用软件的情况,可以为构建使用模型提供必要信息。一个用例包括多个场景,每个场景都描述了软件在完成这个用例的过程中,软件内部对象之间以及与外部对象的一次特定交互过程。场景可以理解为是用例的实例,是用例的子集。一个场景中对象之间的交互过程可以用序列图或协作图来描述。序列图描述了对象之间相互交换的消息在时间上的顺序,稍做处理可以用来产生测试用例。而协作图描述了各对象之间在空间上的交互和链接,不利于自动产生测试用例。因此,应选用序列图描述场景。
但是,仅由用例图、序列图提供的信息来构造使用模型是不够的,还需要用户对软件使用情况的统计以确定使用模型中的转移概率。因此,需要在用例图和序列图的基础上增加该信息,以满足软件可靠性测试要求。具体的构建流程如图二所示。
基于UML模型构建Mar kov链使用模型的过程可以分成3步:
第一步是确定Mar kov链使用模型的等级。模型构建人员首先构建软件的用例级Mar kov链使用模型。由于用例级Mar kov链使用模型中转移概率不易确定,需要通过场景级Mar kov链使用模型中的转移概率获得。故首先确定用例级Mar kov链使用模型的状态空间及状态转移,将状态转移进行细化,将用例细化为场景,通过改进的AHP方法确定场景的执行概率,构建场景级Mar kov链使用模型。如果需要得到用例级的Mar kov链使用模型,则将同一状态出发的所属同一用例的场景进行合并,其执行概率相加,形成用例级Mar kov链使用模型。描述场景的序列图包含多个消息,继续细化可以构建消息级Mar kov链使用模型。用例级、场景级和消息级Mar kov链使用模型都属于软件的使用模型,它们是使用模型构建过程中不同阶段的产物,是一个由粗到细,由整体到部分的构建过程。
第二步是对UML模型进行扩展。Mar kov链使用模型将软件中每传送一个消息进入的状态作为模型的一个状态,各个状态之间通过消息进行传递。所以在构建使用模型之前,必须知道用例的执行顺序才能将整个Mar kov链使用模型中的状态有序连接起来。因此该方法要求为UML模型进行可靠性评估扩展时,除了要求用例或场景前置条件和后置条件外,还要求加入用例执行顺序关系,而用例的执行顺序在软件设计之初是不好确定的。本文克服了该缺陷,将用例或场景的前置条件和后置条件作为状态,而将它们的执行作为状态之间的转移,这样根据相应的前置条件和后置条件可以直接确定各状态之间的转移顺序,而无需人为的给出用例执行顺序关系。
因此,从UML模型构建软件用例级/场景级Mar kov链使用模型,需要对UML模型进行以下可靠性评估扩展:
(1)用例/场景执行前置条件和执行后置条件;
(2)每个用例/场景的t r ans值。
第三步是生成Mar kov链使用模型。本文构建的Mar kov链使用模型将用例或场景的前置条件和后置条件作为Mar kov链使用模型的状态,状态之间的转移由执行的用例或场景驱动,转移概率由改进的AHP方法确定。待转移概率确定后,应用相应的算法分别构建出用例级和场景级Mar kov链使用模型。
无论是用例级Mar kov链使用模型构造算法还是场景级Mar kov链使用模型构造算法,都需要确定软件的初始状态和终止状态集。软件的初始状态和终止状态集应根据软件的实际使用情况确定。在这里,直接将用例或场景的初始条件作为用例级Mar kov链使用模型或场景级Mar kov链使用模型的初始状态,终止条件作为用例级Mar kov链使用模型或场景级Mar kov链使用模型的终止状态即可。
3.3 Mar kov链使用模型的描述
基于Mar kov链的使用模型可以用有向图、表格或矩阵的方式来描述。文中采用的是用有向图来表示Mar kov链模型(如图三所示),它的优点是直观易懂,通常用于小型系统或大型系统的高端表示。
4 可靠性测试用例的生成
在使用模型中,测试用例是从初始状态开始经过若干个中间状态到达终止状态的状态和边的序列。产生测试用例时,从初始状态开始,每经过一次状态转换都生成一个0~1间的随机数,根据这个随机数选择这个状态的一条出边,转移到下一个状态,直到到达终止状态。这样产生的测试用例是随机的,符合用户的使用习惯。
根据测试用例的定义,一个完整的测试用例应该包括两个部分[4]:一部分是测试输入;一部分是预期输出。预期输出根据软件的设计文档可直接获得。目前,测试输入确定后,预期输出往往由测试人员手工填写。所以,测试输入是测试用例的主要组成部分,它可以是一个命令,也可以是软件的函数和函数的参数值等等。本文所提方法主要是对测试用例中测试输入的自动生成展开研究。参考文献[5]建立的软件Mar kov链使用模型,将软件中每传送一个消息进入的状态作为Mar kov链使用模型的一个状态,状态之间的转移激励是消息,所以应用该使用模型产生的测试输入是消息序列,消息通常是一个函数,可以直接作为测试输入。而本文构建的使用模型属于场景级Mar kov链使用模型,如果直接按照场景级Mar kov链使用模型产生测试输入,那么产生的只是场景序列,还不属于软件的测试输入,因此,必须对场景序列进行进一步的细化,找出各个场景对应的测试输入。然后将各个场景对应的测试输入按顺序连接起来组成整个软件的测试输入序列,这样同样可以达到参考文献[5]中产生测试输入的效果。测试输入产生后,由测试人员依据软件设计文档,补充预期输出,这样,测试用例就生成了。
产生场景序列算法的伪代码如算法1所示:
I nput:M———场景级Mar kov链使用模型;
算法1软件一次执行生成场景序列的算法
最终生成测试用例的算法伪代码如算法2所示:
算法2场景级Mar kov链使用模型自动产生测试用例算法
5 结束语
本文研究了一种新的由UML模型生成Mar kov链使用模型的方法。主要提出了UML模型的扩展方法和基于扩展的UML模型生成Mar kov链使用模型的方法。该方法将用例/场景的前置条件和后置条件作为整个状态空间,而将用例/场景作为各状态之间的转移条件,这样大大减少了状态空间,克服了当软件规模很大时,容易造成状态空间爆炸的缺点。应用本文方法得到的Mar kov链使用模型可以较好的根据用户使用情况产生测试用例,用于软件的可靠性测试。
摘要：本文针对软件可靠性测试中测试用例设计方法不足、难以生成等问题,对软件的需求分析和设计文档进行了研究,提出一个基于UML的扩展模型,通过构建不同等级的Markov链使用模型最终解决了可靠性测试用例生成的难题。可靠性测试用例的生成是软件可靠性工程的一个重要组成部分,它对于指导软件测试过程、提高软件可靠性有重要的意义。
关键词：软件可靠性测试,Markov链使用模型,UML模型,可靠性测试用例
参考文献
[1]American National Standards Institute IEEE Standards-Board,"IEEE Standard Dictinary of Measures to Produce Reli-able Software,"IEEE Std982.1-1988,p.16,1988.
[2]"GB/T11457-95中华人民共和国国家标准——软件工程术语"。
[3]阮镰,刘斌,陈雪松.软件可靠性测试及其测试环境[J].测控技术,2009,19(2),9.
[4]季丽丽.基于UML状态图的测试用例自动生成研究[D].南京航空航天大学,2004,2:7-8.
[5]颜炯,王戟,陈火旺.基于UML的软件Markov链使用模型构造研究[J].软件学报,2005,16:1386-1394.
系统用例与测试用例的关系初探 篇2
关键词：系统用例,测试用例,复用,软件质量
1、引言
长期以来，软件质量问题一直困扰着大多数国内的软件企业。大多数企业，重开发、轻测试，认为软件测试是可有可无的事情。软件测试要么流于形式，由开发人员自己对自己的代码进行检查，要么根本没有，拿用户做实验，软件直接交给用户来测，待用户发现问题后再做补救。软件的质量根本无法保证。近年来，随着客户对软件质量的要求越来越高，软件行业也逐渐意识到，软件测试才是确保软件质量的最有效的手段。因此，近年来形成了比较完善的软件测试理论体系。但是，如何编写高效的测试用例。即，如何利用尽可能少的用例做到尽可能大的覆盖率，仍是每一个测试人员需要面对的问题。[1]
2、软件测试的一般方法
软件测试按照阶段划分一般分为：单元测试、集成测试、系统测试、验收测试。[1]单元测试针对每个模块进行的测试，通常在编码阶段进行，必要的时候要制作驱动模块和桩模块。单元测试的目的是看已完成的编码是否符合详细设计说明书上的要求。集成测试在单元测试的基础上，将所有模块按照设计要求组装成为系统，必须精心计划，应提交集成测试计划、集成测试规格说明和集成测试分析报告。集成测试着眼于各模块之间的接口是否正确。由于软件集成的过程是一个持续的过程，会形成多个临时版本。因此，在集成测试的过程中，需要不断地对系统进行冒烟测试，即对程序的主要功能进行测试。确认测试验证软件的功能和性能及其它特性是否与系统的概要设计说明书一致。系统测试和验收测试的目的在于检验系统的提供的功能是否与用户的要求一致，系统测试是在实际运行环境或相对真实的模拟环境下进行一系列的测试。
软件测试按照测试技术划分，一般分为：白盒测试和黑盒测试。白盒测试检查程序的代码设计。该方法将语句与判断作为研究对象，检查所有的结构和路径是否都是正确的。白盒测试以覆盖率作为衡量标准，覆盖率越高，其测试越充分。白盒测试一般分为语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖以及路径覆盖等[1]。然而100%的代码测试几乎是不可能的，白盒测试的成本非常高，除非在航空或军用领域，一般的应用系统只需针对最重要的核心代码进行白盒测试。
黑盒测试是从用户的角度对系统进行测试查找系统存在的缺陷。黑盒测试与需求紧密相关，系统业务需求分析的正确程度直接影响黑盒测试的质量。在进行嵌入式软件黑盒测试时，要把用户需求作为重要依据。黑盒测试针对的是系统的外在功能，因此对软件系统的分支覆盖率比白盒测试要低，在系统修改后，一般要进行回归测试。[5]
3、系统用例和测试用例的关系
作为分析建模活动的一部分，系统用例用来捕获信息的生产者、使用者和系统本身之间发生的交互。即，从某个特定参与者的角度用简单易懂的语言说明一个特定的使用场景。[2]下面通过一个实例来说明用例的组成与结构。
用例1：登录
[执行者]：员工
[基本路径]：
1）、员工插入安全锁触发系统登录过程。
2）、系统打开安全锁
3）、系统从安全锁中获取证书信息。
4）、系统验证证书的合法性。
5）、系统获取证书中的用户名。
6）、系统将用户的考勤信息存储至数据库。
7）、系统将用户的在线状态记录至数据库。
8）、系统从数据库中获得在线用户列表、通知列表、带接收文件列表、日程安排、收文回执列表等。
[扩展路径]：
2a、无法打开安全锁
2a1、提示用户安全锁错误。
2a2、用例结束
2b、PIN码不正确
2b1、输入未超过3次，要求用户重新输入PIN码
2b2、返回步骤2
2b1a、用户输入PIN码达到3次
2b1a1、用例结束
3a、无法获得安全锁中的证书
3a1、提示用户锁内证书无法获得
3a2、用例结束
4a、证书验证不合法
4a1、提示用户锁内证书不合法
4a2、用例结束
6a、无法存储至数据库
6a1、将登录信息存储至本地
6a2、重复尝试存储登录信息。
7a、无法存储至数据库
8 a 1、重复尝试存储在线信息。
这是一个利用硬件设备通过数字证书进行系统登录的用例。基本路径描述了自顶向下的易于理解的典型场景。在其中用户目标得以实现，风险承担者的利益也得到了保障。[4]扩展路径则表述了系统出现问题情况下的场景。扩展路径可以在执行后重新加入到基本路径中，也可以不再重新加入基本路径而终止用例。
我们在得到了系统用例之后，则可以通过该用例来设计测试用例。在设计过程中，不仅要考虑基本路径所产生的成功场景，也必须要考虑当扩展路径执行时的失败场景。
通过表1六个用例执行了系统用例中步骤1-4中的场景。用例1为正面测试用例，它沿着系统用例的基本路径执行，未发生任何偏差。用例2-6为负面测试用例，它们在系统出现偏差时沿着扩展路径执行。负面测试是相对于基本路径而言的，对于扩展路径来说用例2-6是正面测试。
通过系统用例生成测试用例非常方便，二者之间的转换是非常自然的过程。与其他方法不同，这个方法对系统用例的依赖程度高。因此，测试用例的成功与否，取决与系统需求分析的正确程度。只有真正捕获了用户的需求，并且编写出正确的系统用例，才能得到高效的测试用例。
4、用例复用
测试用例复用是指重复使用“为了复用目的而设计的测试用例”的过程。[3]相应地，可复用测试用例是指为了复用目的而设计的测试用例。与软件复用的概念相对应，软件的复用是为了支持软件在应用维的演化，使用“为复用而开发的软件 (构件) ”来更快、更好地开发新的应用系统。好的测试用例用来确保软件的质量，而有效复用现有的测试用例更能提升软件测试的效率。[2]测试用例的复用技术目前已成为一个新的研究热点，由于本人的水平有限，在这里只能根据自己的经验提出一点自己的体会。
传统上，我们都是针对特定的系统设计软件系统设计测试用例，过于局限于某一种产品，依赖性非常强，不利于测试用例的复用。
需求分析的结果取决于用户需求，系统分析结果是针对问题域的某些问题的抽象程度较高的结果，很少受到设计技术及实现条件的影响，因此复用的机会更多。一般可以从现有系统的分析结果中提取可复用构件。[2]因而通过系统用例生成测试用例的方法则可以凭借软件工程中的软件构件技术实现需求、系统和软件的需求规约的复用；继而确保由这些复用构件生成的测试用例达到复用的目的。
5、结束语
通过系统用例我们可以很方便的得到测试用例，进行系统测试。测试用例能够达到的效果取决于系统需求分析的准确程度。因此，要求我们在系统开发的过程中要高度重视系统的需求分析，准确把握用户的需求。测试用例可以与系统用例同步开发，将测试介入到软件开发过程的时间大大提前，从而确保软件开发的每一阶段，都能通过测试保证开发的质量。
需要注意的是, 本介绍的方法属于黑盒测试的范畴。覆盖率能够达到30-40%。因此, 对于系统的核心模块, 如有必要还必须借助白盒测试的方法进行全面的测试。
参考文献
[1]柳纯录.软件评测师教程.清华大学出版社.2005
[2]邵维忠.面向对象的系统分析.清华大学出版社.2005
[3]Roger Pressman.软件工程-实践者的研究方法.机械工业出版社.2007
[4]Alistair Cockburn.Writings Effective Use Case.机械工业出版社.2002
软件系统测试类型及测试用例设计 篇3
随着航空型号功能的日趋复杂, 软件在型号中的应用越来越多, 其规模和复杂度也日趋上升。由软件所导致的问题的比例也在上升, 软件已经成为影响航空型号产品质量和可靠性的关键因素之一。软件测试作为软件研制的重要环节, 其是否充分、有效, 将直接影响到软件产品的质量[1]。
软件测试类型按照开发阶段分为单元测试、部件测试、配置项测试和系统测试[2]。对于航空型号软件而言, 系统测试是最重要的测试, 它能够发现软件中潜藏的时序、软硬件接口等方面的问题。
1 系统测试概述
系统测试是在真实系统工作环境下或系统仿真环境下检验完整的软件配置项能否和系统正确连接, 并满足系统设计文档的要求[3]。系统测试过程描述见图1。
2 系统测试类型及测试用例设计要求
常见的系统测试类型分为功能测试、性能测试、边界测试、接口测试、余量测试、安全性测试、强度测试等[3]。不同的测试类型, 在设计测试用例时, 其测试点各有不同, 下面结合测试实践经验, 对不同的测试类型的测试点进行分析。
2.1 功能测试
功能测试是对软件需求规格说明中的功能需求逐项进行的测试, 以验证其功能是否满足要求。其测试点包括:
1) 用正常值的等价类输入数据值测试;
2) 用非正常的等价类输入数据值测试;
3) 进行每个功能的合法边界和非法边界值输入的测试;
4) 用一系列真实的数据类型和数据值运行, 测试超负荷、饱和及其他“最坏情况”的结果;
5) 对控制流程的正确性、合理性等进行验证。
功能测试是最基本的测试, 同时也是最重要的测试。在进行功能测试时, 首先要明确功能测试的正常等价类, 同时在用例设计中别遗漏了正常等价类;根据输入数据的属性展开想象, 设计非正常的功能测试用例, 并且注意预期结果;设计测试用例时, 一方面分析输入数据, 另一方面分析操作流程。
2.2 性能测试
性能测试是对软件需求规格说明中的性能需求逐项进行测试, 以验证其性能是否满足需求。其测试点包括:
1) 数据采集功能的测试;
2) 测试在获得定量结果时程序计算的精确性 (处理精度) ;
3) 测试其时间特性和实际完成功能的时间 (响应时间) ;
4) 测试为完成功能所处理的数据量;
5) 测试程序运行所占用的空间;
6) 测试负荷潜力;
7) 测试软件的性能和硬件性能的集成;
8) 测试系统对并发事物和并发用户访问的处理能力。
性能测试经常与余量测试、强度测试、容量测试一起进行, 基本的性能度量应当首先以没有争议的方式在主要的功能上被执行;其次在系统处于竞争模式下进行, 即在一种苛刻的环境中衡量资源的使用常常是必要的。
2.3 边界测试
边界测试是对软件处在边界或端点情况下运行状态的测试。边界测试测试点包括:
1) 软件的输入域或输出域的边界或端点的测试;
2) 状态转换的边界或端点的测试;
3) 功能界限的边界或端点的测试;
4) 性能界限的边界或端点的测试;
5) 容量界限的边界或端点的测试。
边界测试是最为普遍的测试类型之一, 几乎所有的软件都有边界测试。看到有范围和数值要求时, 应立刻联想到数值边界;同时注意不同分辨率 (数据精度) 的边界, 如整数和浮点数的范围、角度的范围、时间的范围等。
2.4 接口测试
接口测试是对软件需求规格中的接口需求逐项进行的测试。接口测试的测试点包括:
1) 测试所有外部接口, 检查接口信息的格式及内容;
2) 对每一个外部输入/输出接口必须做正常和异常情况的测试;
3) 测试硬件提供的接口是否便于使用;
4) 测试系统的特性 (如数据特性、错误特性、速度特性) 对软件功能、性能特性的影响;
5) 对所有的内部接口的功能、性能进行测试。
接口测试往往与软件的功能测试结合在一起, 但是接口测试的关注点是接口。接口测试同样需要考虑正常与异常数据的情况, 并且明确所测对象有哪些接口, 然后根据接口的格式特点设计用例。
2.5 余量测试
余量测试是对软件是否达到需求规格说明中要求的余量的测试。按照国军标要求, 一般至少留有20%的余量。余量测试的测试点为:
1) 全部存储量的余量;
2) 输入/输出及通道的吞吐能力余量;
3) 功能处理时间的余量。
余量测试需要分析能够进行余量测试的测试项。余量测试一般为隐含需求, 一般要求留有20%的余量;只要所测对象含有数据要求均可考察其余量, 目前比较重视主要是硬件配置方面的余量;余量测试需在任务较繁重的前提下进行, 并对余量提取是否合适进行确认。
2.6 安全性测试
安全性测试是检验软件中已存在的安全性、安全保密性措施是否有效的测试。其测试点包括:
1) 对安全性关键的软件部件, 必须单独测试安全性需求;
2) 在测试中全面检验防止危险状态措施的有效性和每个危险状态下的反应;
3) 对设计中用于提高安全性的结构、算法、容错、冗余及中断处理等方案, 必须进行针对性测试;
4) 对软件处于标准配置下其处理和保护能力的测试。
5) 应进行对异常条件下系统/软件的处理和保护能力的测试;
6) 对输入故障模式的测试;
7) 必须包含边界、界外及边界结合部的测试;
8) 对安全性关键的操作错误的测试;
9) 对具有防止非法进入软件并保护软件的数据完整性能力的测试;
10) 对重要数据的抗非法访问能力的测试。
2.7 强度测试
强度测试是强制软件运行在不正常到发生故障的情况下 (设计的极限状态到超出极限) , 检测软件可以运行到何种程度的测试。其测试点包括:
1) 最大处理的信息量;
2) 数据能力的饱和实验指标;
3) 最大存储范围 (如常驻内存、缓冲等) ;
4) 在人为错误 (如寄存器数据跳变、错误的接口) 状态下进行软件反应的测试;
5) 需进行持续一段规定的时间, 而且连续不能中断的测试。
3 软件系统测试设计
3.1 系统测试用例设计策略
具体的软件测试项目中, 设计测试用例有多种方法, 对于简单的功能, 选取一种适合的方法即可满足要求, 而对复杂的功能, 运用某一种方法设计出的用例显然不能全面的覆盖各个测试点, 应该联合使用各种的方法, 形成一种综合策略。具体地说, 可以归纳为下述策略:
1) 将测试需求分解为测试项, 选用的测试类型的集合要覆盖规定的测试类型, 对现有条件无法测试的测试项 (不可测项) 要给出不可测的原因, 并给出降低风险的方法;
2) 在编写某一测试类型测试用例时, 要尽可能多地覆盖相应的测试要求;
3) 对重要功能使用频度高的功能, 可适当增加测试用例数量 (包括对各种可能出现的异常情况的考虑) ;
4) 对静态分析中复杂度高的模块所对应的功能适当增加测试用例数量;
5) 在一个功能中发现缺陷后, 要生成用例测试其余功能是否存在同样缺陷;
6) 依靠专业积累, 彻底全面地思考测试场景, 发现并有效的找出隐错;
7) 测试类型并非正交的, 多个测试类型之间存在交叉, 设计测试用例时应把握二个原则:即不能重复、不能遗漏。
3.2 测试实践
在某软件系统测试过程中, 依据软件设计文档进行了测试需求分析和策划, 制定了测试计划, 明确了测试项, 并编制了测试说明, 对软件进行了全面的测试, 共设计了31个测试项目、648个测试用例, 覆盖了功能、性能、边界、接口、余量、强度和安全性所有的测试类型 (见表1) , 达到了国军标对软件测试类型的覆盖要求, 也对软件设计文档的各项设计要求及相关指标进行了测试验证。
表1测试项目及测试用例覆盖情况统计表
在设计测试用例过程中, 有些用例可以按照第2章节描述的方法进行独立设计, 但大部分测试用例的设计需要采用组合策略, 既满足覆盖性要求, 同时也提高测试的效率。表2列举了在测试过程中, 针对不同的测试类型分解的部分测试项的实例。从表2可以看出, 既有通过组合设计的测试项目, 也有进行独立设计的测试项目。
3.3 测试结果评价
在某软件的测试中, 根据以上测试类型综合设计测试项, 使设计出的测试用例更合理, 更全面。通过执行这些用例, 对软件功能进行了全面的测试, 发现了软件在设计方面存在的问题。软件测试工作通过了上级部门组织的评审, 对软件是否实现了预期的功能和是否可以进行系统联试起到了良好的评价作用。
4 结论
本文介绍了常见的系统测试类型及其用例设计方法, 这些方法都是在日常测试任务中实用的设计方法。在实际的测试过程中, 通过各种测试类型的交叉和组合应用来设计用例, 可以有效地对软件进行测试, 提高了测试效率, 降低了测试成本。该系统测试用例设计方法已用于多个型号软件的测试过程, 经证明是一个通用性强、切实有效的设计方法。
参考文献
[1]弹载软件系统测试方法研究.科学技术与工程[J].2008, 8 (13) :3559-3562.
[2]石柱.软件工程标准手册[M].北京:中国标准出版社, 2004.
可复用测试用例研究 篇4
随着软件测试的长期实施, 一般都会积累丰富的高质量的测试用例, 如果能够在以后的软件测试工作中利用现有的资源, 那么会减少测试用例设计的时间, 提高软件测试过程中发现软件缺陷的效率, 缩短软件测试的时间及成本, 保证软件产品的质量, 给软件产品的按时发布带来极大的可能。
在实际工作过程中, 测试用例在设计过程中过分依赖于被测软件, 只能在软件升级及改进的时候可以加以利用;测试用例之间一般都会存在或多或少的联系, 如有些测试用例的运行取决于其它测试用例的运行结果;每个测试工程师在设计测试用例的时候都有自己的喜好, 对测试用例的格式和结构也没有一个统一的定义, 并且对测试用例没有统一进行管理, 描述也不太充分, 这些都为测试用例的复用带来了很大的困难。
1 研究现状
随着人们对软件产品质量的重视程度的加强, 软件测试在软件开发中的重要性也越来越突出, 在软件开发中所占的成本也逐渐提高, 对于一些安全性较高的软件, 如银行系统等, 软件测试费用会所占的比重会更高。
测试用例的设计作为软件测试过程的核心, 它的优劣直接影响了软件测试的效率, 而测试用例的设计在很大程度上取决于测试人员的经验等, 如何利用已有的资源对测试用例进行重用避免软件测试过程中的重复工作, 提高软件质量, 就显的很有必要了, 很多学者对测试用例的复用进行了研究。
文献[1]提出了通过抽取测试用例操作步骤的关键词, 将其提炼为可复用的测试项集合的方法来实现对测试用例的复用, 此方法降低了测试用例复用与被测功能的相关性, 但是只是对测试用例的输入域进行复用, 对测试用例设计的思想, 设计步骤没有办法复用。文献[2]从测试用例的分类着手, 针对其具有的共性以及面向对象语言的特点, 将面向对象系统中的测试用例依据设计方法分为状态检查测试用例和状态比较测试用例, 进而提出了一个统一的测试用例生成、执行模式, 使测试用例能够独立于被测对象, 在理论上讨论了通过使用统一的调用模式, 以达到测试用例复用的目的。文献[3]针对第三方测试机构的特点给出了一种测试用例复用过程模型, 对测试用例进行统一建模组织, 并进行有效管理的思路。文献[4]提出了一种测试复用机制, 通过对测试用例进行可复用描述, 得到可复用的测试用例, 并利用刻面树作为逻辑结构, 生成测试用例库, 通过用例库的各种功能实现用例的复用。文献[5]给出了基于形式规格说明的测试用例库, 增强测试用例库中用例的复用程度。文献[6]针对航天测控软件的特点, 介绍了面向复用的测试用例的结构、组织方式, 用例复用的流程等技术, 实现了测试用例的管理和复用。
以上文献对测试用例可复用性的研究, 都把测试用例的描述作为研究重点, 分析测试用例可复用特征, 通过不同的测试用例复用策略, 生成不同程度的可复用测试用例库, 该文在上述研究的基础上, 对可复用测试用例的概念、设计思想进行详细分析, 给出了可复用测试用例库的模型, 对提高测试用例的复用程度有很好的效果。
2 测试用例复用
2.1 测试用例复用的概念
软件复用是指利用已开发成功的值得借鉴的成果、经验来开发新的软件产品的过程, 整个软件开发中的一切优秀成果都可以进行复用, 包含软件测试过程, 软件测试复用主要是重复利用测试过程中产生的测试理论、测试思想、测试策略、测试用例及测试文档等等。其中对软件测试的核心——测试用例的复用将会提高测试的效率。
测试用例的复用就是在软件测试过程中利用已经存在的测试用例的过程, 根据测试用例被复用的程度, 可以分为直接复用和改进复用, 如果搜索出来的测试用例与需求完全一致, 则直接复用现有测试用例, 一般情况下, 直接复用测试用例的情况很少, 如果搜索出来的测试用例与需求近似, 则对现有的测试用例进行修改和继承, 得到一个新的测试用例之后再复用, 即改进复用。
2.2 测试用例复用的类型
按照测试用例的复用[5]类型, 可分为以下几种:
1) 同一软件在不同测试阶段的测试用例复用
在项目开发过程中, 底层测试对象的测试用例可能部分地复用到高层对象的测试中, 例如单元测试的测试用例可以用到集成测试中。
2) 同一软件在不同时间测试下的测试用例复用
在项目开发过程中, 随着应用的推广, 新的需求会被提出来, 那么就会出现这种产品的多个版本, 在对一个软件多个版本的测试中, 如果软件在上一次测试过程中产生的大量测试用例被保存下来, 在新的一次测试中, 可以查询找到相关的测试用例, 进行测试用例的复用, 缩短了软件产品的升级时间及提高了后续版本的质量。
3) 类似软件之间的测试用例复用
同类软件的测试用例在设计思想、测试策略、测试数据、及测试步骤等都有类似之处, 通过借鉴原有的测试用例对发现被测软件的缺陷, 测试效率的提高有很大的帮助。
2.3 可复用测试用例的设计思想
要实现软件测试过程中对测试用例的复用, 必须满足以下条件:首先应该存在用于复用的软件测试用例, 如果没有测试用例可供选择, 对测试用例的复用将无从谈起;其次可复用的测试用例是有效的, 能够为将来的软件测试提供服务, 测试用例的描述应该完整, 并与被测软件的相关性降低到最小, 这样的测试用例才能满足将来的软件测试需求;最后软件测试工程师了解可复用测试用例的使用方法, 才能更好的实施测试用例的复用。在实际操作过程中, 需要对测试用例的结构有一个良好的定义, 这样才能在测试环境发生改变的时候, 测试用例能够继续利用, 那么在设计可复用的测试用例的时候要遵循的指导原则如下:
1) 测试用例之间的相关性尽量降低到最低;
2) 测试用例对被测软件的依赖尽量减弱;
3) 测试用例的描述要规范化;
4) 测试用例尽量不包含常量, 输入值用变量代替;
5) 测试用例的内容要完整, 结构要统一;
6) 测试用例的分类要合理。
3 基于复用的测试用例库模型
实现软件测试用例复用的有效途径就是建立一个测试用例库, 并按照适合领域、类型等进行多级合理的分类、组织、存储, 以便进行查找和利用现有测试用例。
软件测试的目的是尽可能的发现软件的缺陷, 发现缺陷越高的测试用例, 越有复用的必要, 在测试用例库的设计中添加测试用例发现的缺陷描述, 这样在复用测试用例的时候, 优先选择易于发现软件错误的优质测试用例;对于优质的测试用例, 被复用的测试也会越来越多, 那么, 在以后的测试用例的选取上, 也尽量选择复用次数较高的测试用例;对于复用效果好的测试用例, 或者对于测试用例复用的时候的一些心得体会也很重要, 可以指导后面的测试用例的选取, 在测试用例的结构中添加复用人的评论也至关重要。
随着测试用例库中的用例逐渐增加, 测试用例库逐渐庞大起来, 为了提高测试用例的搜索效率, 对于部分复用次数较少的测试用例, 或随着技术的不断改进, 对于不再具备实际运行的条件而成为过时的测试用例, 可将其删除或者移动到历史用例库。
在测试用例库中对测试用例发现的缺陷进行排序, 可以对相似类的软件系统所出现的缺陷有一定的预测作用。在复用测试用例的时候, 优先选择易于发现缺陷的测试用例和数据。
4 总结
软件测试对于软件产品质量的高低起着至关重要的作用, 如何提高软件测试的效率已经越来越影响软件产品是否能够按时发布, 作为软件测试的核心——测试用例的设计将变得更为重要。为了缩短软件测试的时间, 就需要重复利用以往的先进经验成果, 即复用测试用例。测试用例的复用程度, 取决于测试用例设计的独立程度及是否规范, 并且有一个有效的对测试用例进行规范管理的测试用例库。该文对可复用测试用例的设计思想进行详细分析, 提出了可复用测试用例库的模型, 对测试用例的复用有很好的效果。
摘要：软件测试是提高软件质量的关键步骤, 测试用例的设计又是软件测试的核心, 对已有的优秀的测试用例进行复用能够缩短软件测试的时间, 该文对介绍了可复用测试用例的概念及设计思想, 提出了可复用测试用例库的模型, 提高了测试用例的复用程度。
关键词：测试用例,复用,软件测试,测试用例库
参考文献
[1]胡珊, 杨丰玉, 张晔, 等.基于测试项抽取的测试用例复用方法[J].微电子学与计算机, 2010 (1) .
[2]徐仁佐, 陈斌, 陈波, 等.构造面向对象软件可复用测试用例的模式研究[J].武汉大学学报:理学版, 2003 (5) .
[3]卜国峰, 孙志刚, 丁小良.软件测试用例的复用研究[J].四川兵工学报, 2009 (5) .
[4]肖寒, 顾春华.一种基于Z规格说明的测试用例复用机制[J].计算机应用与软件, 2009 (12) .
[5]张红燕, 杨根兴, 蔡立志.基于形式化描述可复用测试用例库的研究与实现[J].计算机应用与软件, 2010 (7) .
优化测试用例的黑盒测试方法研究 篇5
关键词：黑盒测试,测试用例,分类树方法
0 引言
黑盒测试方法是一种从软件系统的功能说明书出发去寻找软件错误的测试方法, 测试软件系统功能。与白盒测试方法不同, 黑盒测试方法不关注软件的逻辑结构, 将待测试的软件看作一个黑盒子, 只关注软件功能的实现。常见的黑盒测试方法有:随机测试、等价类划分、边界值分析和因果图等。
1 常用黑盒测试方法
1.1 随机测试
该测试方法仅仅依靠测试者的直觉和个人经验去设计测试用例, 对软件进行随机测试, 因此较难发现错误, 效率较低, 大型软件一般很少使用。
1.2 等价类划分
该方法是从软件输入数据的限定条件出发, 或者从软件的输出数据倒推输入数据的特性, 从而划分为不同的类别, 每一个类别称为等价类, 每个等价类中可选取一组数据作为该等价类的代表, 对系统进行测试。如系统要求输入的数据为0~5之间的整数, 就可划分出3个等价类:小于0的整数;0~5的整数;大于5的整数。
1.3 边界值分析
此方法通常结合等价类划分方法一起使用。系统在边界处产生错误的概率较大, 因此有必要对边界处加强测试。选取的测试数据可以略大于、略小于或等于边界值。对上述等价类的例子而言, 可设定-1、0、1、4、5、6进行测试。
1.4 因果图
与等价类划分和边界值分析方法相比, 因果图方法既考虑了输入条件的组合关系, 又考虑了输出条件对输入条件的依赖关系, 效率较高。它将自然语言描述的规格说明转换为类似数字逻辑电路的因果图。步骤如下: (1) 将功能说明书分解成片段。将输入条件分成若干组, 分别对每个组使用因果图, 减少输入条件组合的数目; (2) 识别原因和结果, 并加以编号。原因是指输入条件或输入条件的等价类, 结果是指输出条件或系统变换。每个原因和结果都对应于因果图中的一个结点, 当原因或结果成立 (或出现) 时, 相应结点的值为1, 否则为0; (3) 根据功能说明中规定的原因与结果之间的关系画出因果图; (4) 根据功能说明在因果图中加上约束条件; (5) 根据因果图画出判定表; (6) 为判定表的每一列设计一个测试用例。
2 优化测试用例数量的黑盒测试方法
前述黑盒测试方法测试用例数量有时过多, 有必要采用化方法选取有代表性的测试用例来提高发现错误的概率。
2.1 分类树方法
该方法与等价类划分类似, 不同之处在于分类树方法是用树状图来表示各类别。操作步骤如下:
(1) 从软件系统的功能说明书中识别出不同的类别。以求两数中较大数的程序为例:假设程序要求的输入文件是File, File接收两个数据a和b。计算a-b的结果, 由得到的结果判断两数的大小。因此, 输入文件File有3个类别:不存在、存在但为空文件、存在但非空。a-b的值也可分为3类:大于0、小于0、等于0。
(2) 根据得到的类别构造分类树。
(3) 根据分类树的结点设计测试用例表。
(4) 从用例表中挑选可行的测试用例。
本文以企业员工考勤系统为例探讨分类树设计测试用例的方法。此考勤系统的功能说明书如下:
(1) 统计企业每月考勤结果。员工平时上下班刷卡的时间记录在考勤系统中。根据考勤记录统计员工的出勤情况。每个员工都有一个ID, 可唯一识别员工的个人信息, 如员工的姓名、岗位、工资等信息。
(2) 在考勤系统界面上输入员工ID, 系统information文件中存放员工个人信息, 根据该文件可识别员工的权限, 如果ID号码不合法, 或是离职员工, 系统将提示“无法统计出勤情况”。在职员工分为两类:一类是普通员工, 需进行功能说明书第3步的操作;另一类是特权员工, 如总经理等级别的员工, 常因出差、招标等原因外出, 因此考勤可以适当放宽, 执行功能说明书第4步操作。
(3) 上班时间为早上9:00到下午5:00, 刷卡时间允许前后波动15分钟。普通员工一个月内最多可迟到3次。超过3次, 每超过1次扣除员工月工资总额的1/30。假设刷卡时间为time, 月工资为salary, 迟到次数为count。迟到次数小于3次, 系统提示“无迟到记录”;迟到次数等于3次, 系统提示“本月迟到达到3次”;迟到次数大于3次, 系统计算本月应扣除工资:salary/30× (count-3) , 并将结果显示出来。
(4) 特权员工刷卡时间不作为考勤的唯一标准。统计此类员工考勤信息时, 系统弹出“特权员工不按照普通员工的考勤考核办法”。
根据考勤系统的功能说明书, 可以分析得出系统的不同类别, 如下表1所示。
由表1可知, 每个分类分别有3、2、2、3个类别, 将这些类别分别组合, 可知该系统的用例总数为3×2×2×3=36个。但其中有些用例是不合法的, 比如:“information文件的状态”如果是空, 则不可能与“员工ID状态”这个分类进行组合。此类不合法的测试用例无需进行测试。因此实际测试用例少于36个。构造系统分类树, 如图1所示。
该分类树中图形含义如下: (1) 圆点表示开始, 代表根结点, 表示系统的输入域。位于顶点下方的“information文件的状态”为顶层分类; (2) 矩形框表示按照功能说明进行的分类 (即表格1中第一列的项目) ; (3) 分类树的终端即叶子结点用列 (竖线) 来表示; (4) 分类树中的每一行代表一个测试用例。
分类树下方用横线隔开, 每一行可以设计一个测试用例。可设计如下7个测试用例: (1) 输入information文件状态为“不存在”, 预期输出:考勤系统弹出错误提示; (2) 输入information文件状态为“存在但为空”, 预期输出:考勤系统弹出错误提示; (3) 输入information文件状态为“存在但不空”, 员工ID状态为“无此ID”, 预期输出:考勤系统弹出“无法统计出勤情况”的提示; (4) 输入:information文件状态为“存在但不空”, 员工ID状态为“有此ID”, ID的权限为“特权员工”, 预期输出:考勤系统弹出“特权员工不按普通员工的考勤办法考核”; (5) 输入:information文件状态为“存在但不空”, 员工ID状态为“有此ID”, ID的权限为“普通员工”, 迟到次数count小于3, 预期输出:考勤系统弹出“无迟到记录”; (6) 输入:information文件状态为“存在但不空”, 员工ID状态为“有此ID”, ID的权限为“普通员工”, 迟到次数count等于3, 预期输出:考勤系统弹出“本月迟到达到3次”; (7) 输入:information文件状态为“存在但不空”, 员工ID状态为“有此ID”, ID的权限为“普通员工”, 迟到次数count大于3, 预期输出:考勤系统显示员工本月应扣工资金额。由图1可知, 由分类树设计的7个测试用例, 相比原先由组合关系得到的36个测试用例, 数量明显减少, 根据系统的输入数据域, 可全面测试系统功能。
2.2 正交试验设计
正交试验设计 (Orthogonal experimental design) 是研究多因素多水平的一种设计方法, 它根据正交表从全面试验中挑选出部分有代表性的点进行试验。正交表是均衡分散的, 在减少测试用例的同时, 也能对软件进行全面的测试。在正交测试中, 次数 (Runs) 表示测试用例的个数;因素数 (Factors) 表示影响某结果的变量个数;水平数 (Levels) 表示每个因素取值的个数;正交表的表现形式记为:Lruns (1evelsfactors) 。其操作步骤如下: (1) 找出与软件系统输出结果相关的因素与水平; (2) 根据不同的因素和水平, 选择适当的正交表。如果影响软件的水平数相同, 因素数刚好符合正交表, 则直接选用该正交表。如果水平数相同, 但在正交表中找不到相应的因素数, 则取因素数最接近但略大实际值的表; (3) 将正交表转化为含有因素的测试用例方案。
3 结语
分类树方法与等价类划分相似, 但主要采用树形图来设计测试用例, 可以减少用例数量。此方法对测试者软件项目经验要求不高, 而且可以不依赖自动化工具即可进行测试。正交试验设计法也可以优化用例的数量。该方法由正交表来设计测试用例, 减少试验次数。但利用正交试验设计法有时因素数和水平数与正交表不会恰好相符, 有一定的误差。本文两种方法各有优点。
参考文献
[1]段力军.软件产品黑盒测试的测试用例设计[J].测试技术学报, 2007, 21 (2) :160-162.
[2]CHEN TY, PAK LOK POON.Experience with teaching blackbox testing in a computer science/software engineering curriculum[J].Education, IEEE Transactions on Issue Date:Feb.2004, 47 (1) :42-50.
[3]郭学品, 钟声, 黄成.软件测试用例设计分析[J].海南广播电视大学学报, 2010 (4) :16-19.
软件测试中可复用测试用例研究 篇6
随着软件产业的快速发展, 软件作为一种产品被广泛应用于各个领域, 其功能越来越强大, 复杂度越来越高, 人们对软件质量的要求也越来越高。为满足不同领域、不同行业复杂多变的软件需求, 进一步提高软件开发的质量和效率, 软件开发者开始更多的关注和研究软件复用技术。软件复用技术的研究、应用给软件开发带来了效率、经济的双重好处。
在软件开发复用技术发展的影响下, 测试人员开始将复用的思想应用到软件测试领域, 特别是对测试用例复用的研究。测试用例复用就是将一个软件已经执行过的测试用例, 在不同时间、不同程度的应用到同一软件新的测试或是同类软件的测试中。有效的复用测试用例不仅能提高测试效率, 还能借鉴前人经验、解决经验不足的问题。测试用例是测试工作的指导, 是软件测试必须遵守的准则, 是编写测试脚本的“设计规格说明书”。目前对于测试用例复用的规范化、系统化方面仍有许多待解决的问题。
1 测试用例在软件测试中的作用
测试用例是软件测试过程的核心, 是测试执行的最根本依据。每个测试人员 (包括分析、设计、编程和测试人员) 的工作环境、技术背景、设计思路各不相同, 测试用例可以指导测试的实施, 控制测试的实施过程;规范测试数据的准备以及测试脚本的编写, 保证测试的规范性;测试工作组要有相应的测试审核部门, 通过一些量化的数据如测试覆盖率、测试合格率等衡量测试用例的优劣, 分析测试缺陷, 评估测试结果。
1.1 可复用测试用例的质量特性
文献[2]给出了可复用测试用例的特性, 以此来判定一个测试用例是否具有可复用性。本文在对大量测试用例及其复用情况进行了学习研究后, 认为可复用测试用例应具有以下四个必要质量特性:通用性、独立性、规范化和可维护性。
(1) 通用性
复用的测试用例要不局限于具体应用, 不过分依赖于开发的环境。一般来说, 在面向对象开发这样的主流模式中, 复用的组件或构件在功能上变化不大, 因此基于该模式开发的软件在测试过程中生成的测试用例可复用性很大。比如低层被测对象的测试用例或其部分内容常常被复用到对高层对象的测试中。
(2) 独立性
通常测试用例能否成功被复用, 很大程度上依赖于测试用例的独立性。测试用例之间往往存在着相互的联系, 一些测试用例的成功执行要取决于其他测试用例的执行状态。这就要求每个测试用例要完成的目标必须单一, 不能包含过多的实现细节。一个系统功能点集合F (F1, F2, ……, Fn) 对于任意两个功能点Fi、Fj (i≠j) , 则分别存在Fi、Fj对应的测试用例集Ti、Tj, 满足Ti∩Tj=φ。对一个项目测试产生的测试用例资源, 对其进行抽象化、规范化处理, 使其与被测项目的关联度降至最低, 此时生成的测试用例则可作为复用资源放入测试构件库中。
(3) 规范化
测试用例大都是测试人员根据个人经验和对被测软件的理解而设计的, 通常也都是用自然语言来描述, 没有统一的标准。一个好的测试用例不仅要体现软件的测试思想、技巧, 同时还要包含大量的测试数据、结果以及测试过程。用一定的规范将测试用例组织成一个统一的标准形式, 这样的测试用例才是可以被理解的、可复用的。此外对测试用例库的管理也要有一套规范的流程。
(4) 可维护性
对测试用例的复用研究其根本目的就是要形成一个成熟的、可靠的可复用测试用例库。通用性是可复用测试用例的基本特性, 那么对具体的测试而言就少了实现细节。因此为了应对不同被测软件的需求、设计和环境, 库中的测试用例应该能够稍加修改就可以在同一领域或相似领域进行广泛应用。
1.2 测试用例复用的优点和困难
通过大量研究实践得到如下测试用例复用的优点和困难。其优点如下: (1) 通过复用测试用例, 可以缩短软件的测试周期, 大大提高测试效率; (2) 在前人经验和测试用例库的基础上, 提高了测试的可靠性; (3) 降低了测试的费用, 节省了软件成本; (4) 在一定程度上解决了测试人员经验不足的问题。但是测试用例复用的困难也是不容忽视的, 其难点如下: (1) 测试用例的分类标准难以确定。测试用例库的组织方式有很多, 要让测试人员在最短的时间内检索到想要的可复用的测试用例, 需要对测试用例库的组织、存储进行科学有效的管理; (2) 最根本最关键的测试用例数据库的维护挑战, 相关人员 (如质量管理员、评审管理员、配置管理员等) 要对测试用例库进行有效、持续的科学管理; (3) 测试用例可复用度量标准的确定, 要有合理、准确的度量标准; (4) 被测软件之间的差异, 这就对可复用测试用例库的灵活性和可靠性提出了更高的要求。
2 软件测试中测试用例的复用
根据对软件测试复用经验和方法的研究得到了软件测试用例复用的组成:复用成分的获取、复用成分的管理和复用成分的利用。
(1) 复用成分的获取:通过分析确认有复用价值的测试用例, 对其进行标准化处理后, 按照领域、行业、项目等进行多级合理的分类, 并按一定的组织、存储方式, 将它们放入测试用例库中。同时提供检索机制, 以便于以后在库中能够迅速查找到最合适的用例。
(2) 复用成分的管理:对数据库中的测试用例实行有效维护。在维护中不断添加新的测试用例, 完善旧的测试用例, 删除有问题的测试用例。在软件的迭代开发中, 需求或功能不断变化, 所需的测试用例也要随着做相应的修改。对于软件需求没有变化, 只是入库的测试用例不是那么完善的, 在测试过程中要不断完善, 使测试效果更贴近用户需求;对于需求变化了, 功能增加了的, 需要设计新的测试用例, 新设计的测试用例经测试、评审、规范化后才可以放入到数据库中;对于需求变更, 有的功能模块被取消了的, 保留之前的测试用例, 有可能在同领域或功能相似的软件测试中会被用到。测试用例的维护模式如图1所示:
(3) 复用成分的利用:基于组件的软件工程, 在组件的开发过程中, 低层被测对象的测试用例或其部分内容常常被复用在高层被测对象的测试中[1].例如单元测试中产生的功能类测试用例资源在以后的集成测试或回归测试中就可以被拿来利用;软件的迭代开发过程中, 先前版本的测试用例可以复用到新版本的测试中去;同一行业不同项目之间的测试用例资源也可以相互借鉴利用。
3 测试用例复用的应用研究及实现过程
在同一领域的不同项目中, 或是基于组件开发的系统中, 都存在着测试用例复用的应用。测试用例是动态的, 要随测试环境、需求、设计、实现做相应的变化。本文主要对某大型物流系统仿真实际运行环境中满足需求的系统验收测试阶段产生的测试用例进行了分析研究。
用形式化的语言——六元组S={id, name, pre, in, ope, exp}来定义一个测试用例, 其中id为测试用例编号, name为测试用例名称, pre (取precondition前三个字母) 为测试的前置条件, in为测试输入, oper (取operation前四个字母) 为测试操作, exp (取expectation前三个字母) 为预期结果。
针对物流园车辆租赁的业务流程抽象出的场景测试流如图2所示:
需要进行测试的功能点集合F{F1, F2, ……, Fn}, 测试用例库为T{T1, T2, ……, Tn}, 输出满足条件的可复用测试用例的集合为S, 算法思想如下:
4 总结
测试用例的设计是软件测试中重要的一个环节, 其作为一种无形的有价值资产, 有效复用的研究意义重大。本文在学习研究大量可复用测试用例具体应用后, 提出了可复用测试用例的提取及数据库的维护过程。给某大型物流系统仿真实际运行环境的系统验收测试工作带来了便利。
摘要：软件测试是保证软件质量的重要手段, 测试用例是软件测试的关键环节, 测试用例的选择对测试质量有着至关重要的影响。为了提高测试效率、积累测试经验、节省测试成本, 测试用例复用的研究意义重大。本文在大量测试用例复用研究的基础上总结了可复用测试用例的质量特性、复用的优点以及存在的困难, 提出了可复用测试用例的提取及可复用测试用例数据库的维护过程。最后研究内容在某大型物流系统中进行了测试验证, 证明研究是有效的。
关键词：可复用性,质量特性,测试用例,提取,可复用测试用例库
参考文献
[1]徐仁佐, 陈斌, 陈波, 等.构造面向对象软件可复用测试用例的模式研究[J].武汉大学理工学报, 2003, 49 (5) :592-593.
[2]肖良, 杨根兴, 蔡立志.软件测试用例可复用性度量[J].计算机应用与软件, 2010, 27 (6) :46-49.
测试用例的设计和复用技术 篇7
长期以来,我国软件企业一直被软件质量问题所困扰,它有多方面的原因。其中对软件测试的忽视,是一个重要因素。事实上,软件测试可以检测软件中存在的错误,确保软件产品质量。
为了开发出高质量的软件,众多软件企业从之前单纯的以编码为核心向软件工程化方向进军,形成了一套比较完善的软件测试理论体系。软件测试越来越规范化,可以划分为单元测试,集成测试,确认测试和系统测试等,它往往占用了软件开发生命周期40%～60%的时间。但是在实际工作中,还有很多企业,设计出比较低劣的测试用例,时常有些地方被遗漏,不能完全覆盖;有的虽然考虑得面面俱到,但设计的测试用例庞大无比,冗余现象十分普遍,浪费人力物力;更有的企业在新的软件版本或者测试环境中,彻底抛弃原有的测试工作,重新开发测试用例,这是很不经济的。本文希望能够总结以往的经验,提出一些有效的测试用例设计和复用方法,用以帮助测试人员更有效地应用于整个测试流程。
1 测试用例的设计
所谓测试用例是指按照一定顺序执行的与测试目标相关的一系列测试。在测试阶段,软件测试方法可以分为单元测试,集成测试,功能测试和系统测试。单元测试是最小的单位,测试小段特定代码,由开发人员来主导完成;集成测试是把各个应用程序组合起来进行的测试;功能测试即黑盒测试,是立足于用户的角度来进行测试,根据需求和软件运行的平台进行测试;系统测试是把整个软件系统和它所依赖的其他软件或者硬件集成在一起,覆盖所有的功能进行测试:比如压力测试和性能测试等。如何设计出有效的测试用例?下面结合作者在工作中的经历,阐述一些测试用例设计中的问题。
其一,测试用例设计的时间性问题:越早地设计和执行测试用例越好。
目前很多测试模型都是V模型,就是将测试依次划分为几个阶段,进行完了一个阶段然后再展开下一个阶段的测试。这种分阶段测试最大的缺点就是定性地将测试分为几个固定的阶段,其实很多测试可以提前展开,尽早发现错误。而V模型显然有点违背了越早发现错误越有利的原则。在开发嵌入式产品VOIP网关时,我们采用了一种比较灵活的方法,将测试用例的设计提前进行。在需求阶段,便开始考虑和实施系统测试用例;当需求规格书确定后就开始设计功能性测试用例,同时概要设计也并行进行;等概要设计好了进行详细设计时,同时展开集成测试用例的设计。这样当开始编码的时候,我们便可以开始测试准备好的单元测试用例,而且也可以执行集成测试用例和系统测试用例;这样伴随编码同步地进行这些测试用例,可以及时发现错误,得到反馈信息,用以纠止软件设计中的错误。另外一个好处就是在编码阶段就展开集成测试、功能测试和系统测试,能尽早发现错误。
其二,在结构性测试用例设计中,我们要注意的原则:尽可能利用路径覆盖方法设计测试用例来覆盖程序所有可能路径,尤其在程序本身的复杂度高的情况下。
一般说来,在编码过程中,程序本身设计的复杂度也决定了测试用例设计的复杂度。下面结合VOIP网关产品中的状态机进行说明。对于一个VOIP系统,核心之一是有限状态机的设计。一般包含空闲状态,用户摘机状态,拨号状态,等待连接建立状态(其中又可以分为信令连接建立阶段,语音通道建立阶段),通话状态,对方挂机状态,对方电话忙碌状态等。在每一个状态下,事件源可以是:摘挂机事件,拨号事件,建立连接返回事件,如:对方不在线,无法连通因特网等。在某个状态下,接收到不同的事件驱动程序转向其他状态。每次通话过程从空闲状态重新回到空闲状态,这是一个非结构性的循环结构。在这种情况下,就需要采用路径覆盖的方法,来设计结构性测试用例,列出所有的可能性路径,针对其中的每一条路经设计出相应的测试用例。依据图1所展示的一个简单状态机,可能存在的路径包括:AB,ACEG,ADFG等,这就需要我们在进行测试用例设计的时候,细心地把存在的路径一个个找出来,才能设计出比较严谨的测试用例。
另外在结构性测试用例的设计中,还经常采用的方法有:
· 语句覆盖 就是使程序中的每个可执行语句至少执行一次。
· 判定覆盖 使程序中的每个判定至少都获得一次“真”和“假”值。
· 条件覆盖 使每个判定中的每个条件的可能取值至少满足一次。
· 判定/条件覆盖 使判定中的每个条件的可能结果和每个判定本身的判定结果均至少出现一次。
· 条件组合覆盖 使得每个判定中条件的各种可能组合都至少山现一次。
其三,在功能性测试用例设计中,我们常常需要:把百分之八十的精力投入到那些边界情况和失效数据作为输入的测试情况。
功能测试即黑盒测试,一般由测试人员来执行,而测试用例的设计,最好在需求阶段依据需求规格书进行设计。如果设计测试用例的人员没有完全理解需求规格书,这里面就会引起一些问题,到产品最后验收的时候,就会发现产品根本不能交付使用,大大延误了产品上市时间。测试人员依据功能测试用例来进行测试,对软件内部结构和运作并不了解。一般初期设计出来的测试用例往往又会遗漏很多边界条件。在我们开发的一套客户机/服务器系统中,就出现了不少类似问题。首先客户机安装后必须向服务器进行注册,用户的名字在服务器端数据库里面作了限定,由于客户机没有进行检测,最后导致服务器不能为部分用户服务。由于功能性测试在用例中没有包含进去,等产品交付使用后,才发现这个错误。这需要在设计功能性测试用例的时候,不仅仅要考虑有效等价类,那些无效的等价类更加重要,因为这些都是人们容易忽视的,无论开发人员还是测试人员,往往有定势思维,总感觉自己的产品没有问题,他们也习惯性地输入一些一定满足条件的数据进行测试,无形中掩盖了潜在的失效数据的处理。其次边界值划分法也是一种常用的方法。在我们那套客户机/服务器系统中,客户机每隔三分钟会把统计的资料信息传送到服务器。如果服务器正常,则返回正确消息;否则可能返回服务器忙碌信息,此时客户机需要调整策略,延长发送间隔,然后把累积统计的数据在下一次发送时传送给服务器。此外,服务器每天会定时在线备份,这个时段,客户机要调整发送间隔到十分钟,等服务器备份完毕,再提交统计的资料。这就需要我们在设计测试用例的时候,既要包括正常情况下的状况,也要把服务器在不同忙碌等级下的情况,服务器备份的情况统统包含进去。总之,边界情况和失效等价类是设计测试用例时必须要使用到的。这样才能设计出好的功能性测试用例。当然还有其他一些比较常用的方法,如错误推测法和因果图法。
2 测试用例的复用
设计出好的测试用例是确保软件质量的大前提,有效复用现有的测试用例更能提升企业软件开发过程。目前很多软件企业,对测试用例的复用没有引起足够的重视。软件开发往往时间紧张,客观上也成了开发测试人员的借口,设计出来的软件或者测试用例,过于局限于本产品使用,依赖性非常强,根本就不利于升级或者拓展。这里我们提到的就是测试用例的复用。我们要能够将所有的测试用例有效地组织起来,使得测试用例集合里面的每一个测试用例都能够独立地运行,这样才能提高软件测试用例的复用度。结合工作中的经验,传统的测试用例设计有很多方法,看上去相互间没有统一的结构。我们所需要注意的是:能够将测试用例综合起来分析,然后让所有的测试用例组织在一起,它们具有统一的输入、输出接口,并且每个测试用例独立性比较强,这样即使以后软件运行环境发生变化,测试用例还能够继续加以使用。拿我们的VOIP产品来说,我们在推出第一版的时候,测试用例设计得就非常的独立,可以有效地检测状态机的运作。等我们在添加了会议电话功能后,我们基于之前的测试用例,进行了最大程度的复用,节省了大量的时间和精力。测试用例独立性强,采用一致的结构,是测试用例复用度高的关键。
3 结 语
软件测试用例的设计,是软件测试中比较重要的一环。只有设计出更多更好地测试用例,才可以更快更好的发现潜在的错误与失效。使用最少的测试用例,实现最大的测试覆盖,可复用度好,并且在需求分析阶段提前展开测试用例的设计,是我们软件测试的目标。只有制定出完善的测试计划,有效的测试用例,进行测试结构分析以及文档管理,才能保证软件测试的成功。
摘要：软件测试是企业保证软件产品质量的一个重要手段,其中测试用例的设计是软件测试的关键,它一般包括功能测试用例的设计,结构测试用例设计以及系统方面的测试用例设计等。结合实际经验,系统地阐述了如何有效地进行测试用例的设计以及复用。并给出两个案例进行分析,探讨测试用例设计中的一些注意事项。
关键词：软件测试,测试用例,复用技术
参考文献
[1]Beizer B.Software Testing Techniques.Boston,International ThompsonComputer Press,1990.
[2]Pressman R.Software Engineering:A Practitioner s Approach.Boston,McGraw Hill,2001.
[3]郑人杰.计算机软件测试技术,北京:清华大学出版社,1992.