测试用例设计

引言
测试设计遵循与软件设计相同的工程原则。好的软件设计包含几个对测试设计进行精心
描述的阶段。这些阶段是：
测试策略
测试计划
测试描述
测试过程
上述四个测试设计阶段适用于从单元测试到系统测试各个层面的测试。
测试设计由软件设计说明所驱动。单元测试用于验证模块单元实现了模块设计中定义的
规格。一个完整的单元测试说明应该包含正面测试（Positive Testing）和负面的测试
（Negative Testing）。正面测试验证程序应该执行的工作，负面测试验证程序不应该执行
的工作。
设计富有创造性的测试用例是测试设计的关键。本文档介绍了测试说明的一般设计过
程，描述了一些结构化程序设计单元测试中采用的用例设计技术，同时也增加了面向对象编
程中对类进行单元测试所采用的测试用例设计技术，这些可作为软件测试人员的参考阅读资
料。 2 设计单元测试说明
一旦模块单元设计完毕，下一个开发阶段就是设计单元测试。值得注意的是，如果在书
写代码之前设计测试，测试设计就会显得更加灵活。一旦代码完成，对软件的测试可能会倾
向于测试该段代码在做什么（这根本不是真正的测试），而不是测试其应该做什么。单元测
试说明实际上由一系列单元测试用例组成，每个测试用例应该包含4 个关键元素：
被测单元模块初始状态声明，即测试用例的开始状态（仅适用于被测单元维持了调
用间状态的情况）；
被测单元的输入，包含由被测单元读入的任何外部数据值；
该测试用例实际测试的代码，用被测单元的功能和测试用例设计中使用的分析来说
明，如：单元中哪一个决策条件被测试；
测试用例的期望输出结果，测试用例的期望输出结果总是应该在测试进行之前在测
试说明中定义。
以下描述进行测试用例设计，书写测试说明的7步通用过程。

 

2.1 测试用例设计步骤
2.1.1 步骤1：首先使被测单元运行
任何单元测试说明的第一个测试用例应该是以一种可能的简单方法执行被测单元。看到
被测单元第一个测试用例的运行成功可用增强人的自信心。如果不能正确执行，最好选择一
个尽可能简单的输入对被测单元进行测试/调试。
这个阶段适合的技术有：
模块设计导出的测试
对等区间划分
2.1.2 步骤2：正面测试(Positive Testing)
正面测试的测试用例用于验证被测单元能够执行应该完成的工作。测试设计者应该查阅
相关的设计说明；每个测试用例应该测试模块设计说明中一项或多项陈述。如果涉及多个设
计说明，最好使测试用例的序列对应一个模块单元的主设计说明。
适合的技术：
设计说明导出的测试
对等区间划分
状态转换测试
2.1.3 步骤3：负面测试(Negative Testing)
负面测试用于验证软件不执行其不应该完成的工作。这一步骤主要依赖于错误猜测，需
要依靠测试设计者的经验判断可能出现问题的位置。
适合的技术有：
错误猜测
边界值分析
内部边界值测试
状态转换测试
2.1.4 步骤4：设计需求中其它测试特性用例设计
如果需要，应该针对性能、余量、安全需要、保密需求等设计测试用例。
在有安全保密需求的情况下，重视安全保密分析和验证是方便的。针对安全保密问题的
测试用例应该在测试说明中进行标注。同时应该加入更多的测试用例测试所有的保密和安全
冒险问题。
适合的技术：
设计说明导出的测试

 

2.1.5 步骤5：覆盖率测试用例设计
应该或已有测试用例所达到的代码覆盖率。应该增加更多的测试用例到单元测试说明中
以达到特定测试的覆盖率目标。一旦覆盖测试设计好，就可以构造测试过程和执行测试。覆
盖率测试一般要求语句覆盖率和判断覆盖率。
适合的技术：
分支测试
条件测试
数据定义－使用测试
状态转换测试 2.1.6 步骤6：测试执行
使用上述5 个步骤设计的测试说明在大多少情况下可以实现一个比较完整的单元测伀????ń??o??/试。
到这一步，就可以使用测试说明构造实际的测试过程和用于执行测试的测试过程。该测试过
程可能是特定测试工具的一个测试脚本。
测试过程的执行可以查出模块单元的错误，然后进行修复和重新测试。在测试过程中的
动态分析可以产生代码覆盖率测量值，以指示覆盖目标已经达到。因此需要在测试设计说明
中需要增加一个完善代码覆盖率的步骤。
2.1.7 步骤7：完善代码覆盖
由于模块单元的设计文档规范不一，测试设计中可能引入人为的错误，测试执行后，复
杂的决策条件、循环和分支的覆盖率目标可能并没有达到，这时需要进行分析找出原因，导
致一些重要执行路径没有被覆盖的可能原因有：
不可行路径或条件 ―― 应该标注测试说明证明该路径或条件没有测试的原因。
不可到达或冗余代码 ―― 正确处理方法是删除这种代码。这种分析容易出错，特
别是使用防卫式程序设计技术（Defensive Programming Techniques）时，如有疑
义，这些防卫性程序代码就不要删除。
测试用例不足 ―― 应该重新提炼测试用例，设计更多的测试用例添加到测试说明
中以覆盖没有执行过的路径
理想情况下，覆盖完善阶段应该在不阅读实际代码的情况下进行。然而，实际上，为达
到覆盖率目标，看一下实际代码也是需要的。覆盖完善步骤的重要程度相对小一些。最有效
的测试来自于分析和说明，而不是来自于试验，依赖覆盖完善步骤补充一份不好的测试设计。
适合的技术：
分支测试
条件测试
设计定义――试验测试
状态转换测试

2.2 用例设计的一般原则
注意到前面产生测试说明步骤可以用下面的方法完成：
通常应该避免依赖先前测试用例的输出，测试用例的执行序列早期发现的错误可能
导致其他的错误而减少测试执行时实际测试的代码量；
测试用例设计过程中，包括作为试验执行这些测试用例时，常常可以在软件构建前
就发现BUG。还有可能在测试设计阶段比测试执行阶段发现更多的BUG。
在整个单元测试设计中，主要的输入应该是被测单元的设计文档。在某些情况下，
需要将试验实际代码作为测试设计过程的输入，测试设计者必须意识到不是在测试
代码本身。从代码构建出来的测试说明只能证明代码执行代码完成的工作，而不是
代码应该完成的工作。

 

3、测试用例设计技术
广义地分为两类：
黑盒测试：使用单元接口和功能描述，不需了解被测单元的内部结构
白盒测试：使用被测单元内部如何工作的信息
灰盒测试：借助于源代码和测试工具等手段，通过黑盒和白盒测试相结合的方法进行测试的技术。

测试设计最重要的因素是经验和常识。测试设计者不应该让某种测试技术阻碍经验和常识的
运用。

白盒测试用例设计：使用程序设计的控制结构导出测试用例。
采用白盒测试的目的主要是:

保证一个模块中的所有独立路径至少被执行一次；
对所有的逻辑值均需要测试真、假两个分支；
在上下边界及可操作范围内运行所有循环；
检查内部数据结构以确保其有效性。

黑盒测试用例设计：使用详细设计导出测试用例。

采用黑盒测试的目的主要是：

检查功能是否实现或遗漏；
检查人机界户是否错误；
数据结构或外部数据库访问错误；
性能等其它特性要求是否满足；
初始化盒终止错误伀????ń??o??/。

3.1 软件设计说明导出的测试

测试用例通过根据相关的软件设计说明文档进行设计。每个测试用例测试设计说明中一
项或多项陈述。通常为被测单元设计说明的一系列陈述建立一系列对应的设计用例。
例1：考虑下面计算实数平方根的函数的设计说明：
输入：实数
输出：实数
处理：当输入0或大于0时，返回输入数的平方根；当输入小于0时，显示：“Square root
error - illegal negative input"，并返回0；库函数Print_Line用于显示出错信息。
设计说明有3个陈述，可以2个测试用例来对应。
Test Case 1：输入4，返回2。 //执行第一个陈述
Test Case 2：输入－10，返回0，显示“Square root error - illegal negative input”//对应第二个和第三个陈述
设计说明导出的测试用例提供了与被测单元设计说明陈述序列很好的对应关系，增强了
测试说明的可读性和可维护性。但有软件设计说明导出测试是正面的测试用例设计技术。软
件设计说明导出的测试应该用负面测试用例进行补充，以提供一个完整的单元测试说明。
设计说明导出的测试设计技术还可用于安全分析、保密分析、软件冒险分析和其他给单
元设计的其他补充文档。

 

3．2 基本路径测试
基本路径测试是一种白盒测试技术。测试用例设计者导出一个过程设计的逻辑复杂性测
度，并使用改测度作为指南来定义执行路径的基本集，从该基本集导出的测试用例保证对程
序中的每一条执行语句至少执行一次。
基本路径测试的方法步骤如下：
3.2.1 画出控制流图
C/C++语句中的控制语句表示如下：
图中的每一个圆称为流图的节点，代表一条或多条语句。流图中的箭头称为边或连接，
代表控制流。
任何过程设计都要被翻译成控制流图。如下面的C 函数：
void Sort(int iRecordNum,int iType)
0 {
1 int x=0;
2 int y=0;
3 while (iRecordNum--)
4 {
5 if(0= =iType)
6 x=y+2;
7 else
8 if(1= =iType)
9 x=y+10;
10 else
11 x=y+20;
12 }
13 }

画出其对应的控制流图如下：

 

逐一：如果在程序中遇到复合条件，例如条件语句中的多个布尔运算符（逻辑OR、AND）
时，为每一个条件创建一个独立的节点，包含条件的节点称为判定节点，从每一个判定节点
发出两条或多条边。例如：
1 if ( a or b)
2 x
3 else
4 y
5 …
对应的逻辑为：

 

 

 

3.2.2计算圈复杂度

圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量，将该度量用于计算程序的基本的独立路径数目，为确保所有语句至少执行一次的测试数量的上界。独立路径必须包含一条在定义之前不曾用到的边。

有以下三种方法计算圈复杂度：

流图中区域的数量对应于环型的复杂性；

给定流图G的圈复杂度－V(G)，定义为V(G)=E-N+2，E是流图中边的数量，N是流图中节点的数量；

给定流图G的圈复杂度－V(G)，定义为V(G)=P+1，P是流图G中判定节点的数量。

 

对应3.2.1图一中代码的圈复杂度，计算如下：

流图中有四个区域；

V(G)=11条边-9节点+2=4;

V(G)=3个判定节点+1=4。

3.2.3导出测试用例

根据上面的计算方法，可得出四个独立的路径：

路径1：3-13

路径2：3-5-6-12-3-13

路径3：3-5-7-9-12-3-13

路径4：3-5-7-10-12-3-13

根据上面的独立路径，去设计输入数据，使程序分别执行到上面四条路径。

3.2对等区间（等价类划分）

对等区间划分是一种黑盒测试方法，该方法也成为等价类划分；

对等区间划分是测试用例设计的非常形式化的方法。它将被测软件的输入输出划分成一些区间，被测软件对一个特定区间的任何值都是等价的。形成测试区间的数据不只是函数/过程的参数，也可以是软件可以访问的全局变量，系统资源等，这些变量或资源可以是以时间形式存在的数据，或以状态形式存在的输入输出序列。

对等区间划分假定位于单个区间的所有值对测试都是对等的，应该为每个区间的一个值设计一个测试用例。

考虑前面的平方根函数的测试用例区间，有2个输入区间和2个输出区间，表示如下：

 

 

 

可以用2个测试用例测试4个区间：

测试用例1：输入4，返回 2 //区间 ii和a

测试用例 2：输入－10，返回0，输出"Square root error - illegal negative input" //区间i和b

后面的文章是讲解等价类划分、边界值分析、因果图、测试大纲、状态图、场景法设计测试用例了，因为这些方法在很多地方有参考资料，我在这里就不用添加了。在实际写测试用例时，要根据被测试软件的具体情况，来综合使用这种这些方法，而很少采用一种方法单独测试用例。设计测试用例是一个烦琐的工作，需要覆盖软件的需求，需要设计很多的测试用例，有些人在问，运行程序就能找出问题了，为什么花费这么多的时间设计测试用例呢？我想关于设计测试用例的好处在也不用多说了。

下面把面向对象的测试放在这里。

4、面向对象的单元测试

4.1面向对象测试的特点

自80年代中后期以来，面向对象软件开发技术发展迅速，获得了越来越广泛的应用，在面向对象的分析、设计技术以及面向对象的程序设计语言方面，均获得了很丰富的研究成果。与之相比，面向对象软件测试技术的研究还相对薄弱。例如，对面向对象的程序测试应当分为多少级尚未达成共识。基于结构的传统集成策略并不完全适于面向对象的程序。这是因为面向对象的程序的执行实际上是执行一个由消息连接起来的方法序列，而这个方法序列往往是由外部事件驱动的。在面向对象语言中，虽然信息隐藏和封装使得类具有较好的独立性，有利于提高软件的易测试性和保证软件的质量，但是，这些机制与继承机制和动态绑定给软件测试带来了新的课题。尤其是面向对象软件中类与类之间的集成测试和类中各个方法之间的集成测试具有特别重要的意义，与传统语言书写的软件相比，集成测试的方法和策略也应该有所不同。

从目前的研究现状来看，研究较多地集中在类和对象状态的测试方面。面向对象程序设计的继承和动态联编所带来的多态性对软件测试的影响，虽然有所论及，但是不仅缺乏针对这一特点的测试方法，而且还有许多问题有待进一步的研究。

软件测试中的另一个重要问题是测试的充分性问题，充分性准则对软件测试的揭错能力具有重要影响。对传统语言的软件测试已经存在多种充分性准则，但对面向对象的软件测试，目前尚无普遍接受的充分性准则。对这些方面的深入研究将会产生真正对软件测试的理论与实践有指导意义、有影响的成果。

对OO软件的类测试相当于传统软件的单元测试。和传统软件的单元测试不同，他往往关注模块的算法细节和模块接口间流动的数据，OO软件的类测试是由封装在类中的操作和类的状态行为所驱动的。因为属性和操作是被封装的，对类之外操作的测试通常是徒劳的。封装使对对象的状态快照难于获得，继承也给测试带来了难度，即使是彻底复用的，对每个新的使用语境也需要重新测试。多重继承更增加了需要测试的语境的数量，使测试进一步复杂化。如果从超类导出的测试用例被用于相同的问题域，有可能对超类导出的测试用例集可以用于子类的测试，然而，如果子类被用于完全不同的语境，则超类的测试用例将没有多大用途，必须设计新的测试用例集。