一、为什么要使用测试用例
1、理清思路,避免遗漏
如果我们测试的项目大而复杂,我们可以把项目功能细分,根据每一个功能通过编写用例的方式来整理我们测试系统的思路,避免遗漏掉要测试的功能点。
2、跟踪测试进展
通过编写测试用例,执行测试用例,我们可以很清楚的知道我们的测试进度。
3、历史参考
在我们所做的项目中,也许会有很多功能是相同或相近的,我们对这类功能设计了测试用例,便于以后我们遇到类似功能的时候可以做参考依据。
4、重复性
我们测试一个系统不是一个人测一遍就算测完的,需要多人反复的进行测试,那么我们就需要测试用例来规范和指导我们的测试行为。
5、测试确认
在少数高风险的测试中,必须证明确实执行了计划执行的测试。
二、测试用例-要素
1、用例编号
测试用例的编号有一定的规则,比如系统测试用例的编号这样定义规则: PROJECT1-ST-001 ,命名规则是项目名称+测试阶段类型(系统测试阶段)+编号。定义测试用例编号,便于查找测试用例,便于测试用例的跟踪。
2、测试标题
对测试用例的描述,测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时,软件的响应情况 ” 。
3、重要级别
定义测试用例的优先级别,可以笼统的分为 四个不同的等级
4、输入限制
提供测试执行中的各种输入条件。根据需求中的输入条件,确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性,如果软件需求中没有很好的定义需求的输入,那么测试用例设计中会遇到很大的障碍。
5、操作步骤
提供测试执行过程的步骤。对于复杂的测试用例,测试用例的输入需要分为几个步骤完成,这部分内容在操作步骤中详细列出。
6、预期结果
提供测试执行的预期结果,预期结果应该根据软件需求中的输出得出。如果在实际测试过程中,得到的实际测试结果与预期结果不符,那么测试不通过;反之则测试通过。
三、编写用例参考什么内容?
当根据客户的需求整理出项目需求分析文档时,我们就可以根据需求文档来编写测试用例了。
等到项目开发人员把项目开发出来,给我们系统文档、部署环境、数据库结构(如果系统牵涉到数据库的话),我们根据这些文档来设计测试用例。
我们编写的测试用例经过评审之后,随着需求的变更、功能的改进,测试用例也需要更新和变动。
测试执行过程中,应该注意及时更新测试用例。往往在测试执行过程中,才发现遗漏了一些测试用例,这时候应该及时的补充;往往也会发现有些测试用例在具体的执行过程中根本无法操作,这时候应该删除这部分用例;也会发现若干个冗余的测试用例完全可以由某一个测试用例替代,那么删除冗余的测试用例。
四、黑盒测试用例的设计方法
具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、场景法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。
这些方法是比较实用的,但采用什么方法,在使用时自然要针对开发项目的特点对方法加以适当的选择。
1、等价类划分法
*在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。
*在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类。
*在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。
*在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。
*在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。
*在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。
a)确定测试用例:
*为每一个等价类编号。
*设计一个测试用例,使其尽可能多地覆盖尚未被覆盖过的合理等价类。重复这步,直到所有合理等价类被测试用例覆盖。
*设计一个测试用例,使其只覆盖一个不合理等价类。
b)举例:
问题: “一个程序读入3个整数,把这三个数值看作一个三角形的3条边的长度值。这个程序要打印出信息,说明这个三角形是不等边的、是等腰的、还是等边的。”
我们可以设三角形的3条边分别为A,B,C。如果它们能够构成三角形的3条边,必须满足:
A>0,B>0,C>0,且A+B>C,B+C>A,A+C>B。
如果是等腰的,还要判断A=B,或B=C,或A=C。
如果是等边的,则需判断是否A=B,且B=C,且A=C。
根据以上分析,从而得到下图列表中的测试用例。
2、边界值分析法
使用边界值分析方法设计测试用例时一般与等价类划分结合起来。但它不是从一个等价类中任选一个例子作为代表,而是将测试边界情况作为重点目标,选取正好等于、刚刚大于或刚刚小于边界值的测试数据。
⑴如果输入条件规定了值的范围,可以选择正好等于边界值的数据作为合理的测试用例,同时还要选择刚好越过边界值的数据作为不合理的测试用例。如输入值的范围是[1,100],可取0,1,100,101等值作为测试数据。
⑵如果输入条件指出了输入数据的个数,则按最大个数、最小个数、比最小个数少1、比最大个数多1等情况分别设计测试用例。如,一个输入文件可包括1--255个记录,则分别设计有1个记录、255个记录,以及0个记录的输入文件的测试用例。
⑶对每个输出条件分别按照以上原则⑴或⑵确定输出值的边界情况。如,一个学生成绩管理系统规定,只能查询95--98级大学生的各科成绩,可以设计测试用例,使得查询范围内的某一届或四届学生的学生成绩,还需设计查询94级、99级学生成绩的测试用例(不合理输出等价类)。
由于输出值的边界不与输入值的边界相对应,所以要检查输出值的边界不一定可能,要产生超出输出值之外的结果也不一定能做到,但必要时还需试一试。
⑷如果程序的规格说明给出的输入或输出域是个有序集合(如顺序文件、线形表、链表等),则应选取集合的第一个元素和最后一个元素作为测试用例。
3、场景法
用例场景用来描述流经用例的路径,从用例开始到结束遍历这条路径上所有基本流和备选流。
按照上图中每个经过用例的路径,可以确定以下不同的用例场景:
场景 1 基本流
场景 2 基本流 备选流 1
场景 3 基本流 备选流 1 备选流 2
场景 4 基本流 备选流 3
场景 5 基本流 备选流 3 备选流 1
场景 6 基本流 备选流 3 备选流 1 备选流 2
场景 7 基本流 备选流 4
场景 8 基本流 备选流 3 备选流 4
注:为方便起见,场景 5、6 和 8 只考虑了备选流 3循环执行一次的情况。
4、错误推测法
概念:
基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法
基本思想:
列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例
5、因果图法
概念:
因果图法是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况
基本思想:
等价类划分法和边界值分析方法都是着重考虑输入条件,但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了,但多个输入条件组合起来可能出错的情况却被忽视了。
如果在测试时必须考虑输入条件的各种组合,则可能的组合数目将是天文数字,因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计,这就需要利用因果图(逻辑模型)。
6、判定表驱动法
概念:
判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
基本思想:
能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。因此,利用判定表能够设计出完整的测试用例集合。
在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作。判定表很适合于处理这类问题。
7、正交试验设计法
概念:
依据Galois理论,从大量的(实验)数据(测试例)中挑选适量的,有代表性的点(例),从而合理地安排实验(测试)的一种科学实验设计方法.类似的方法有:聚类分析方法,因子方法方法等.
基本思想:
利用因果图来设计测试用例时, 作为输入条件的原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到。往往因果关系非常庞大,以至于据此因果图而得到的测试用例数目多的惊人,给软件测试带来沉重的负担,为了有效地,合理地减少测试的工时与费用,可利用正交实验设计方法进行测试用例的设计。
8、功能图法
概念:
功能图由状态迁移图和布尔函数组成.状态迁移图用状态和迁移来描述.一个状态指出数据输入的位置(或时间),而迁移则指明状态的改变.同时要依靠判定表或因果图表示的逻辑功能.
从功能图生成测试用例的过程:
1) 生成局部测试用例:在每个状态中,从因果图生成局部测试用例.局部测试用例由原因值(输入数据)组合与对应的结果值(输出数据或状态)构成。
2) 测试路径生成:利用上面的规则(三种)生成从初始状态到最后状态的测试路径。
3) 测试用例合成:合成测试路径与功能图中每个状态中的局部测试用例.结果是初始状态到最后状态的一个状态序列,以及每个状态中输入数据与对应输出数据的组合。
五:测试方法选择的综合策略
在实际测试中,往往是综合使用各种方法才能有效提高测试效率和测试覆盖度,这就需要认真掌握这些方法的原理,积累更多的测试经验,以有效提高测试水平,以下是各种测试方法选择的综合策略,可在实际应用过程中参考。
*首先进行等价类划分,包括输入条件和输出条件的等价划分,将无限测试变成有限测试,这是减少工作量和提高测试效率的最有效方法。
*在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强。
*对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准,应当再补充足够的测试用例。
*对于业务流清晰的系统,可以利用场景法贯穿整个测试案例过程,在案例中综合使用各种测试方法。
网友评论