软件测试用例的设计

软件测试用例的设计

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

　　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、测试用例设计的误区

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