软件测试用例的设计

一个测试用例,就是设定输入数据,运行被测试函数,然后判断实际输出是否符合预期。输入数据是测试用例的核心,输入数据的定义是:被测试函数所读取的外部数据及这些数据的初始值。

  1、自动测试工具的选择

  目前通过使用自动化工具对于软件的质量进行保障已经司空见惯,我们可以通过在测试中应用自动化工具来大幅度提高软件测试的效率和质量。常用的白盒测试自动化工具有Telelogic公司的Logiscope软件、Compuware公司的DevPartner软件和IBM公司的Rational Purify等;而黑盒测试工具主要有IBM公司的Rational系列如TeamTest、Robot,Com-puware公司的QACenterm等。

  2、测试用例中输入数据的选择

  用一定的规则选择有代表性的数据作为输入数据,主要有三种:正常、边界、非法输入,每种输入还可以分类,也就是平常说的等价类法,每类取一个数据作为输入数据,如果测试通过,可以肯定同类的其他输入也是可以通过的。下面举例说明:

  (1)正常输入

  例如字符串的Trim函数,功能是将字符串前后的空格去除,那么正常的输入可以有四类:前面有空格;后面有空格;前后均有空格;前后均无空格。

  (2)边界输入

  例中空字符串可以看作是边界输入。再如一个表示成绩的参数,它的有效范围是0-100(百分制),那么边界输入有两个:0和100。

  (3)非法输入

  非法输入是正常取值范围以外的数据,或使代码不能完成正常功能的输入,如上例中表示成绩的参数,小于0或大于100都是非法输入,再如一个进行文件操作的函数,非法输入有这么几类:文件不存在;目录不存在;文件正在被其他程序打开;权限错误。单元测试与代码编写是“一体两面”的关系,编码时对上述三种输入都是必须考虑的,否则代码的健壮性就会成问题。

  在设计测试用例时,应当包括合理的输入条件和不合理的输入条件。合理的输入条件是指能验证软件的输入条件;不合理的输入条件则是指异常的、临界的、可能引起问题异变的条件。用不合理的输入条件测试软件能核实软件的容错能力和完全性,往往比合理的输入条件能发现更多的错误。

  3、预测输出结果

  合理设计测试用例,适当选择测试方法完整的测试用例不但需要测试的输入数据,而且需要对应这些输入数据的预期输出结果。

  在使用白盒测试时,最理想的情况是希望能够执行到每条路径,但由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素,哪怕是一个极其简单的程序,要想穷尽所有逻辑路径,所有输入数据和验证所有结果是非常困难的一件事情。在这里我们举一个简单的例子。

#include <jostrcan。h>
void main( )
{ int a,b,c,t,I;
cout<<”input x,y,z”<<endI;
cin>>x>>y>>z;
if (x>y) {t=x;x=y;y=t;}
if(x>z) {t=x;x=z;z=t;}
if(y>z) {t=y;y=z;z=t;}
cout<<”the result is:”< <x< <y< <z< <endi;}

  这个例子基本上保证了每条路径至少被执行了一次,代码中没有循环,只有三个if语句,它就是代码中的多路径源,共形成了6条路径,如表1所示。

  表1 三个if语句形成的6条路径


条件


If


If


If


结果


x>y

x<y

x< >z

x<z

y>z

y<z


x< >y

x<y

y< >z


x<y

 x>z

 x<z

 x<z

 x<y<z

 x<y<z

  为了测试这些数据,必须组织6组数据,每组数据测一条路径。请看表2的测试套和期望结果。

  表2 6组数据的测试套和期望结果


输入


第一步


第二步


第三步


期望结果


5,4,6

4,5,6

6,5,4

5,6,4

4,6,5

6,4,5


4,5,6

 4,5,6

 5,6,4

 5,6,4

 4,6,5

 4,6,5


4,5,6

 4,5,6

 4,6,5

 4,6,5

 4,6,5

 4,6,5


4,5,6

 4,5,6

 4,5,6

 4,5,6

 4,5,6

 4,5,6


4,5,6

 4,5,6

 4,5,6

 4,5,6

 4,5,6

 4,5,6

  4、妥善保留全部测试用例

  软件测试开发过程中,一定要做好测试用例的保存工作,这样在测试人员发生变动或者开展回归测试时会减少许多工作。我们在在程序改良或者Bug改正后需要重新测试时,就避免大量的枯燥乏味的重复工作,从而在提高测试效果的同时也相应的节省了软件开发成本。

  5、测试用例设计的误区

  在确定测试用例设计目标时,一些项目管理人员强调测试用例“越详细越好”。这种做法和观点最大的危害就是耗费了很多的测试用例设计时间和资源,可能等到测试用例设计、评审完成后,留给实际执行测试的时间所剩无几了。因为当前软件公司的项目团队在规划测试阶段,分配给测试的时间和人力资源是有限的,而软件项目的成功要坚持“质量、时间、成本”的最佳平衡,没有足够多的测试执行时间,就无法发现更多的软件缺陷,测试质量更无从谈起了。

====================================分割线================================

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-09-25 13:24:30

软件测试用例的设计的相关文章

软件测试用例的设计心得

1.了解软件的原始需求(测试目的) 在编写一个软件或者模块的测试用例时候,一定要明白这个功能的原始需求,也就是软件的使用者(客户)的需求.理解原始需求后,编写的测试用例才更有目的性. 2.熟悉软件的功能需求(测试点) 这个功能需求是指软件的细化需求点,这个一般在需求文档里面都会体现.这里要做的是把 "粗略"的需求,细化成一个个小需求点.熟悉功能需求后,要知道软件是怎么使用的,这也才能覆盖到各种操作. 总之,测试用例一定要全部覆盖所有的需求点,这是最基本的一点. 3.熟悉软件的实现原理(

软件测试用例的认识误区

软件测试用例是为了有效发现软件缺陷而编写的包含测试目的.测试步骤.期望测试结果的特定集合.正确认识和设计软件测试用例可以提高软件测试的有效性,便于测试质量的度量,增强测试过程的可管理性. 在实际软件项目测试过程中,由于对软件测试用例的作用和设计方法的理解不同,测试人员(特别是刚从事软件测试的新人)对软件测试用例存在不少错误的认识,给实际软件测试带来了负面影响,本文对这些认识误区进行列举和剖析. 误区之一:测试输入数据设计方法等同于测试用例设计方法 现在一些测试书籍和文章中讲到软件测试用例的设计方

浅谈手机软件测试用例设计方法

手机产品和用户交互非常紧密,手机的软件质量就显得尤其重要.要使最终用户对手机软件感到满意,必须要在手机软件发布之前进行充分的测试.而不完全.不彻底是软件测试的致命缺陷,但是我们又不可能进行穷举测试,任何程序只能进行少量而有限的测试.为了节省时间和资源,提高测试效率,我们必须要从数量极大的可用测试数据中精心挑选出具有代表性或者特殊性的测试数据进行测试.测试用例在此情况下产生.测试用例是为特定的目的而设计的一组测试输入.执行条件和预期的结果.简单地说,测试用例就是设计一个场景,使软件程序在这种场景下

手机软件测试用例设计实践

一.测试用例设计概述 测试伴随在整个手机软件开发的各个阶段中,测试质量的高低直接关系到手机软件的可用性,友好性,可靠性.可以说,测试环节是手机软件开发的重要环节,是整个开发过程的"中枢神经".同时,测试用例的设计在测试过程中是非常重要的一个环节,是重中之重. 一般来说,设计测试用例应该考虑如下几方面: 1)有效性:测试用例是测试人员测试过程中的重要参考依据.不同的测试人员依据相同的测试用例所得到的输出应该是一致的. 2)可复用性:良好的测试用例具有重复使用的功能,使得测试过程事半功倍,

软件测试用例设计方法

前面有曰:测试结果的准确性取决于测试用例的设计,故测试用例设计显得尤为重要.今天就好好梳理下,测试用例的相关内容. 重要性:Test Case贯穿整个测试执行过程,分两大类:数值计算类和数据处理类 概述:编写一组前提条件,输入,执行条件,预期结果的组合方案.完成对某个特定需求或目标的测试,体现测试方案,方法,技术和策略的文档. 1.什么是测试用例,为什么要编写? 测试用例就是编写一组条件,输入,执行条件,预期结果的并完成对特定需求或目标的测试,体现测试方案,方法,技术和策略的文档. 由于测试用例

如何设计软件测试用例

设计测试用例是个很大的主题,而且其中所需要的方法也很多.我计划一点一点的总结并记录下来.我这次讨论的不是针对一个软件的测试用例设计,而是针对一个模块或多个模块用例的设计. 今天我要写的主要是我自己在工作中所用的一些方法,当然不是最好用的.但我一直在研究最高效,最实用的方法. 首先我们要了解一下为什么要设计测试用例以及它在软件测试中的地位. 影响软件测试的因素很多,软件本身的复杂程度,开发人员的素质(包括分析,设计,编程和测试),测试方法和技术的应用.那么如何保证测试质量的稳定呢?测试用例就可以把

如何有效评估软件测试用例的质量?

软件测试用例质量的评估,可以考虑下面3个方面的因素: 第一,根据测试用例的形式评估其质量,主要包括: 1)测试用例与需求规格说明中需求条目的可追溯性,例如:我们要求每个需求条目至少有1个测试用例与之对应.目的是为了评估测试的需求覆盖率,以及分析需求发生变更的时候,对测试修改工作的影响程度: 2)测试用例有无明确的期望结果.通常来说,测试用例的每个执行步骤,都应该明确描述期望的结果,以保证测试人员可以与测试实际结果进行比较,并分析是否需要提交缺陷报告,或者修改测试用例. 3)是否满足公司内部定义的

浅析软件测试用例管理

2.2 测试用例执行结果分析 测试用例执行结果可以从覆盖率.执行率.通过率等几个方面进行分析和考察.测试用例覆盖率是指测试用例覆盖的功能与测试需求功能的比值:测试用例执行率是指已执行的测试用例数与测试用例总数的比值:测试用例通过率是指成功执行的测试用例数与测试用例总数的比值. 测试用例的覆盖率需要达到100%,也就是说,测试用例必须覆盖全部的测试需求,否则测试用例的设计则是不全面的,无法保证测试质量,需要补充或者重新设计相应测试用例.测试用例执行率是衡量测试效率的因素,一般说来,在测试完成时测试

【软件测试】4、测试用例的设计

众所周知,试图对软件进行完全的测试并发现全部的问题是一件不可能的任务,对于测试而言,最有效的思想就是努力使测试尽可能完全. 在这个过程中,测试用例的设计至关重要.因为软件测试最关键的问题是:如何从所有可能的测试用例全集中寻找可能发现错误最多的子集. 1.白盒测试 白盒测试的重点在于测试用例的执行程度,或测试用例覆盖程序源码逻辑结构的程度.完整的白盒测试将走过程序运行路径的每一种可能,然而这是不可能的.因此需要设定一些准则来约束并不完善的测试用例子集,以求尽可能多的发现程序中的潜在错误. (1)语