软件工程
电子教案
王树林
Chapter 16 SOFTWARE TESTING
TECHNIQUES
软件系统的开发包括一系列生产活动。
软件测试是软件质量保证的关键元素。代表
了规约、设计和编码的最终检查。软件开发
组织把 30%--40%的时间和精力花在测试上是
不足为怪的。
16.1 软件测试基础
从心理角度说，测试是摧毁性的，而不是建
设性的。测试要求开发者放弃刚开发的软件
是正确的观念，并克服发现错误时的心理矛
盾。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.1.1 测试目标
测试目标规则：
（ 1）测试是一个为了寻找错误而运行程
序的过程。
（ 2）一个好的测试用例是指很可能找到
迄今为止尚未发现的错误的用例。
（ 3）一个成功的测试是指揭示了迄今为
止尚未发现的错误的测试。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.1.2 测试原则
在设计有效的测试用例之前，软件工程师必
须理解软件测试的基本原则。
（ 1）所有的测试都应追溯到用户需求。
（ 2）应该在测试工作真正开始前的较长时间内
就进行测试计划。
（ 3） Pareto原则应用于软件测试。 Pareto原则：
测试发现的错误中的 80%很可能起源于程序模
块中的 20%。
（ 4）测试应从“小规模”开始，逐步转向“大
规模”。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
（ 5） 为了达到最佳效果，应该由独立的
第三方来构造测试。
16.1.3 可测试性
软件的可测试性就是一个计算机程
序能够被测试的容易程度。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.2 测试用例 设计
产品在出厂前都是要经过严格测试的。
下面我们考虑两种对任何产品都适用的一般
测试方法,
（ 1）若了解产品的功能，则构造测试，以证实
各功能完全可执行，同时在各功能中寻找错
误；这种方法被称为黑盒测试。
（ 2）若了解产品的内部构造，则构造测试，以
确保“所有齿轮吻合”，即内部操作依据规
约执行，而且所有的内部构件被充分利用。
这种方法被称为白盒测试。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
在计算机软件界，黑盒测试指在软件界面
上的测试，虽然设计黑盒测试是为了发
现错误，但他们却被用来证实软件功能
的可操作性，证实能很好地接受输入，
并正确地产生输出；以及证实对外部信
息完整性的保持。他测试系统的一些基
本特征，很少涉及软件的内部逻辑结构。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
软件的白盒测试依赖于对程序细节的严密
测试，使用特定的条件和循环集的测试用例，
对软件的逻辑路径进行测试，在不同的点检
验“程序的状态”以判定预期状态或待验证
状态与真实状态是否相符。
但是，一个很小的程序的逻辑程序路径也
可能异常庞大，不可能进行完全的穷举测试。
但白盒测试仍然是非常有用的。我们可以在
重要的逻辑路径上进行穷举测试。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.3 白盒测试
白盒测试是一种测试用例设计方法，使用
程序的控制结构导出测试用例。
测试用例,（ 1）保证一个模块中的所有独立
路径至少被使用一次；（ 2）对所有逻辑值均
需测试 TRUE和 FALSE；（ 3） 在上下界及可
操作范围内运行所有循环；（ 4）检查内部数
据结构以确保其有效性。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.4 基本路径测试
对程序中的每一条语句至少执行一次。
16.4.1 流图符号
流图也称为程序图，每一种结构化
构成元素有一个相应的流图符号。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
顺序语句 If 语句 While 语句
其中每个圆代表一个或多个无分支 PDL或原代码语
句 流图符号
Chapter 16 SOFTWARE TESTING
TECHNIQUES
CASE
语句Until 语句
其中每个圆代表一个或多个无分支 PDL或原代码语
句 流图符号
Chapter 16 SOFTWARE TESTING
TECHNIQUES
1
2
3
6 4
57 8
9
1011
程序流
程图
FLOW
CHART
Chapter 16 SOFTWARE TESTING
TECHNIQUES
1
2,3
6
7 8
9 10
11
4,5R2
R3 R1
R4
REGION
NODE
EDGE
流图 flow graph
Chapter 16 SOFTWARE TESTING
TECHNIQUES
流程图用来描述程序控制结构。假定流程 图
的菱形判决框中不包含复合语句。
每一个圆称为流图的节点，代表一个或多个语
句。
一个处理方框序列和一个菱形判决框可被影射
为一个节点。
流图中的箭头称为边或连接，代表控制流。
一条边必须终止于一个节点。即使该节点不代
表任何语句。
由边和节点限定的范围称为区域。计算区域时
应包括图外部的范围。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
任何过程设计表示法都可以被翻译
成流图。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
PDL（ Program design language）。
procedure,sort
1,do while records remain
read record;
2,if record field 1=0
3,then process record;
store in buffer;
Increment counter ;
4,elseif record field 2=0
5,then reset counter ;
6,else process record;
store in file;
7a,endif
endif
7b,enddo
8:end
Chapter 16 SOFTWARE TESTING
TECHNIQUES
1
2
4
6 5
7a 7b
8
3
将 PDL翻译为流图
流图
a
xb
y x
复合逻辑
判定节点
If a or b
then procedure x
else procedure y
endif 包含条件的节
点称为判定节
点，从每个判
定节点发出两
条或多条边。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.4.2 环行复杂性
独立路径是指程序中至少引进一个新的处理
语句集合或一个新条件的任一路径。
用流图的术语,独立路径必须至少包含一条在
定义路径之前不曾用到的边。
例如：
路径 1,1—11；
路径 2,1—2—3 –4 –5 –10—1– 11 ；
路径 3,1—2—3—6—8—9—10—1 —11；
路径 4,1—2—3—6—7—9—10—1 —11；
Chapter 16 SOFTWARE TESTING
TECHNIQUES
路径,1—2—3—4—5--10—1—2—3—6—8—
9—10—1—11不是一条独立路径，他只是已
有路径的简单合并，并未包含新边。
上面定义的四条基本路径包含了该流图的一个
基本集，
实际上，给定的过程设计可以派生出任意数量
的不同基本集。环行复杂性以图论为基础，
为我们提供了非常有用的软件度量。可用下
面三种方法之一来计算复杂性。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
（ 1）流图中区域的数量对应于环行的复
杂性。
（ 2）给定流图 G的环行复杂性 —V(G)，
定义为 V(G)=E-N+2,E是流图中边的
数量,N是流图节点数量。
（ 3）给定流图 G的环行复杂性 --
V(G)=P+1,P是流图 G中判定节点的数量。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
可采用上述任意一种算法来计算环形复杂
性。
1,流图有四个区域。
2,V(G)=11（ 边 )-9（节点） +2=4
3,V(G)=3（ 判定节点） +1=4
V(G)的值提供了组成基本集的独立路径数
量的上界，并由此得出覆盖所有程序
语句所需的测试设计数量的上界。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.4.3 导出测试用例
基本路径测试方法可用于过程设计或原代
码生产。
1,以设计或代码为基础，画出相应的流图。
2,确定结果流图的环形复杂性。
3,确定线性独立的路径的一个基本集。
4,准备测试用例，强制执行基本集中每条路径。
16.4.4 图矩阵
导出流图和决定基本测试路径的过程均
需要机械化，为了开发辅助基本路径测
试的软件工具，图矩阵是一种非常有用
的数据结构。
图矩阵是一个正方形矩阵，其大小等
于流图的节点数。每行和每列对应于标
识的节点，矩阵顶对应于节点间的连接，
1
3
4
2
5
g
f
e
b
c
d
a a
d b
c f
h e
1
2
3
4
5
1 2 3 4 5
Chapter 16 SOFTWARE TESTING
TECHNIQUES
该图中，流图的节点以数字标识，边以字母
标识，矩阵中的字母项对应于节点间的连接。
图矩阵只是流图的表格表示，然而，对每个
矩阵项加入连接权值，图矩阵就可以用于在
测试中评估程序的控制结构。连接权值可以
是下列属性：
（ 1） 执行连接的概率；
（ 2）穿越连接的处理时间；
（ 3）穿越连接时所需的内存；
（ 4）穿越连接时所需的资源。
利用这些技术，设计测试用例的分析就可以自
动化或部分自动化。
16.5 控制结构测试
基本路径测试技术是控制结构测试技术之
一。
16.5.1 条件测试
条件测试是检查程序模块中所包含逻辑条
件的测试用例设计方法。
16.5.2 数据流测试
16.5.3 循环测试
16.6 黑盒测试
黑盒测试注重于测试软件的功能需求，黑
盒测试不是用来代替白盒测试，而是用于辅
助白盒测试发现其他类型的错误。
黑盒测试主要用于发现以下类型的错误：
（ 1）功能不对或遗漏；
（ 2）界面错误；
（ 3）数据结构或外部数据库访问错误；
（ 4）性能测试
（ 5）初始化或终止错误。
白盒测试在测试的早期执行，黑盒测试在
测试的晚期执行。
16.6.1 基于图的测试方法
黑盒测试的第一步是理解软件所表
示的对象及其关系。软件测试首先是创
建对象及其关系图。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
对象 1
对象 3
对象 2
（节点权值）
间接连接 并行连接
有向连接
（连接权
值）
图的符号体系
Chapter 16 SOFTWARE TESTING
TECHNIQUES
新建文件
文档文本
文档窗口
表示为 包含
菜单选择生成
（生成时间 <1.0秒）
对象图的例子
允许编
辑
属性：
初始尺寸：缺省设
置
背景色：白色
文本颜色：缺省选
择
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.6.2 等价划分
等价划分是一种黑盒测试方法，将程序
的输入域划分为数据类，以便导出测试
用例。等价划分试图定义一个测试用例
以发现各类错误，从而减少必须开发的
测试用例数。
如果对象由具有对称性、传递性和自反性
的关系连接，就存在等价类。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
例如：考虑自动银行应用软件所维护的数据、
用户可以用自己的微机拨号到银行、提供六
位数的密码，并遵循一系列键盘命令以触发
各种银行功能。银行应用程序的软件可以接
受如下格式的数据：
区号：空或三位数字。
前缀：三位数字，但不是 0和 1开始。
后缀：四位数字。
密码：六位字母或数字。
命令：检查，存款，付款等。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
与银行应用程序各种数据元素相关的输入条件可
以表示为：
区号：输入条件，布尔 – 区号存在与否；
输入条件，范围 —定义在 200和 999之间的
数值，少数例外。
前缀：输入条件，范围 —大于 200不含 0的数值。
后缀：输入条件，值 —四位数字。
密码：输入条件，布尔 —密码存在与否；
输入条件，值 —六位字符串。
命令：输入条件，集合 —包含上述命令。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.6.3 边界值分析
输入域的边界比中间更加容易发生错
误，所以可用边界值分析（ boundary
value analysis,VBA） 作为一种测试技术。
边界值分析选择一组测试用例检查边界
值。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.6.4 比较测试
在某些情况下，如航空电子设备、
核电厂控制等，软件的可靠性是绝对重
要的。我们可以开发冗余的软件版本。
测试时，可以比较多个版本的输出结果。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.7 针对专门环境和应用的测试
16.7.1 GUI测试
图形用户界面（ GUI）。
16.7.2 客户 /服务器体系结构测试
16.7.3 测试文档和帮组设施
文档测试可以分为两个步骤。第一步为正
式的技术复审，检查文档的编辑错误；第二
步是活性测试（ live testing）,结合实际程序的
使用而使用文档。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.7.4 实时系统测试
实时系统的测试更加困难，因为测试时
必须考虑时间依赖性和异步性。不仅考
虑黑盒和白盒测试用例，而且包括事件
处理（如中断处理），数据的时间安排
以及处理数据的任务的并发性。
小结
测试用例设计的主要目标是导出有可能发现软
件错误的测试集，为此，有两种不同的测试
用例设计技术：白盒测试和黑盒测试。
白盒测试注重于程序控制结构。测试用例要保
证测试时程序的所有语句至少执行一次，而
且检查了所有的逻辑条件。是一种小规模测
试。
黑盒测试发现功能需求错误，而不考虑程序的
内部工作。
小结
有经验的软件开发者经常说：“测试永不
终止，只是从软件工程师转移到客户。
客户每次使用程序时，都是一次测试。”
通过设计测试用例，软件工程师可以进
行更广泛的测试，从而在“客户测试”
之前发现并修改尽可能多的错误。
电子教案
王树林
Chapter 16 SOFTWARE TESTING
TECHNIQUES
软件系统的开发包括一系列生产活动。
软件测试是软件质量保证的关键元素。代表
了规约、设计和编码的最终检查。软件开发
组织把 30%--40%的时间和精力花在测试上是
不足为怪的。
16.1 软件测试基础
从心理角度说，测试是摧毁性的，而不是建
设性的。测试要求开发者放弃刚开发的软件
是正确的观念，并克服发现错误时的心理矛
盾。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.1.1 测试目标
测试目标规则：
（ 1）测试是一个为了寻找错误而运行程
序的过程。
（ 2）一个好的测试用例是指很可能找到
迄今为止尚未发现的错误的用例。
（ 3）一个成功的测试是指揭示了迄今为
止尚未发现的错误的测试。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.1.2 测试原则
在设计有效的测试用例之前，软件工程师必
须理解软件测试的基本原则。
（ 1）所有的测试都应追溯到用户需求。
（ 2）应该在测试工作真正开始前的较长时间内
就进行测试计划。
（ 3） Pareto原则应用于软件测试。 Pareto原则：
测试发现的错误中的 80%很可能起源于程序模
块中的 20%。
（ 4）测试应从“小规模”开始，逐步转向“大
规模”。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
（ 5） 为了达到最佳效果，应该由独立的
第三方来构造测试。
16.1.3 可测试性
软件的可测试性就是一个计算机程
序能够被测试的容易程度。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.2 测试用例 设计
产品在出厂前都是要经过严格测试的。
下面我们考虑两种对任何产品都适用的一般
测试方法,
（ 1）若了解产品的功能，则构造测试，以证实
各功能完全可执行，同时在各功能中寻找错
误；这种方法被称为黑盒测试。
（ 2）若了解产品的内部构造，则构造测试，以
确保“所有齿轮吻合”，即内部操作依据规
约执行，而且所有的内部构件被充分利用。
这种方法被称为白盒测试。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
在计算机软件界，黑盒测试指在软件界面
上的测试，虽然设计黑盒测试是为了发
现错误，但他们却被用来证实软件功能
的可操作性，证实能很好地接受输入，
并正确地产生输出；以及证实对外部信
息完整性的保持。他测试系统的一些基
本特征，很少涉及软件的内部逻辑结构。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
软件的白盒测试依赖于对程序细节的严密
测试，使用特定的条件和循环集的测试用例，
对软件的逻辑路径进行测试，在不同的点检
验“程序的状态”以判定预期状态或待验证
状态与真实状态是否相符。
但是，一个很小的程序的逻辑程序路径也
可能异常庞大，不可能进行完全的穷举测试。
但白盒测试仍然是非常有用的。我们可以在
重要的逻辑路径上进行穷举测试。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.3 白盒测试
白盒测试是一种测试用例设计方法，使用
程序的控制结构导出测试用例。
测试用例,（ 1）保证一个模块中的所有独立
路径至少被使用一次；（ 2）对所有逻辑值均
需测试 TRUE和 FALSE；（ 3） 在上下界及可
操作范围内运行所有循环；（ 4）检查内部数
据结构以确保其有效性。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.4 基本路径测试
对程序中的每一条语句至少执行一次。
16.4.1 流图符号
流图也称为程序图，每一种结构化
构成元素有一个相应的流图符号。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
顺序语句 If 语句 While 语句
其中每个圆代表一个或多个无分支 PDL或原代码语
句 流图符号
Chapter 16 SOFTWARE TESTING
TECHNIQUES
CASE
语句Until 语句
其中每个圆代表一个或多个无分支 PDL或原代码语
句 流图符号
Chapter 16 SOFTWARE TESTING
TECHNIQUES
1
2
3
6 4
57 8
9
1011
程序流
程图
FLOW
CHART
Chapter 16 SOFTWARE TESTING
TECHNIQUES
1
2,3
6
7 8
9 10
11
4,5R2
R3 R1
R4
REGION
NODE
EDGE
流图 flow graph
Chapter 16 SOFTWARE TESTING
TECHNIQUES
流程图用来描述程序控制结构。假定流程 图
的菱形判决框中不包含复合语句。
每一个圆称为流图的节点，代表一个或多个语
句。
一个处理方框序列和一个菱形判决框可被影射
为一个节点。
流图中的箭头称为边或连接，代表控制流。
一条边必须终止于一个节点。即使该节点不代
表任何语句。
由边和节点限定的范围称为区域。计算区域时
应包括图外部的范围。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
任何过程设计表示法都可以被翻译
成流图。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
PDL（ Program design language）。
procedure,sort
1,do while records remain
read record;
2,if record field 1=0
3,then process record;
store in buffer;
Increment counter ;
4,elseif record field 2=0
5,then reset counter ;
6,else process record;
store in file;
7a,endif
endif
7b,enddo
8:end
Chapter 16 SOFTWARE TESTING
TECHNIQUES
1
2
4
6 5
7a 7b
8
3
将 PDL翻译为流图
流图
a
xb
y x
复合逻辑
判定节点
If a or b
then procedure x
else procedure y
endif 包含条件的节
点称为判定节
点，从每个判
定节点发出两
条或多条边。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.4.2 环行复杂性
独立路径是指程序中至少引进一个新的处理
语句集合或一个新条件的任一路径。
用流图的术语,独立路径必须至少包含一条在
定义路径之前不曾用到的边。
例如：
路径 1,1—11；
路径 2,1—2—3 –4 –5 –10—1– 11 ；
路径 3,1—2—3—6—8—9—10—1 —11；
路径 4,1—2—3—6—7—9—10—1 —11；
Chapter 16 SOFTWARE TESTING
TECHNIQUES
路径,1—2—3—4—5--10—1—2—3—6—8—
9—10—1—11不是一条独立路径，他只是已
有路径的简单合并，并未包含新边。
上面定义的四条基本路径包含了该流图的一个
基本集，
实际上，给定的过程设计可以派生出任意数量
的不同基本集。环行复杂性以图论为基础，
为我们提供了非常有用的软件度量。可用下
面三种方法之一来计算复杂性。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
（ 1）流图中区域的数量对应于环行的复
杂性。
（ 2）给定流图 G的环行复杂性 —V(G)，
定义为 V(G)=E-N+2,E是流图中边的
数量,N是流图节点数量。
（ 3）给定流图 G的环行复杂性 --
V(G)=P+1,P是流图 G中判定节点的数量。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
可采用上述任意一种算法来计算环形复杂
性。
1,流图有四个区域。
2,V(G)=11（ 边 )-9（节点） +2=4
3,V(G)=3（ 判定节点） +1=4
V(G)的值提供了组成基本集的独立路径数
量的上界，并由此得出覆盖所有程序
语句所需的测试设计数量的上界。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.4.3 导出测试用例
基本路径测试方法可用于过程设计或原代
码生产。
1,以设计或代码为基础，画出相应的流图。
2,确定结果流图的环形复杂性。
3,确定线性独立的路径的一个基本集。
4,准备测试用例，强制执行基本集中每条路径。
16.4.4 图矩阵
导出流图和决定基本测试路径的过程均
需要机械化，为了开发辅助基本路径测
试的软件工具，图矩阵是一种非常有用
的数据结构。
图矩阵是一个正方形矩阵，其大小等
于流图的节点数。每行和每列对应于标
识的节点，矩阵顶对应于节点间的连接，
1
3
4
2
5
g
f
e
b
c
d
a a
d b
c f
h e
1
2
3
4
5
1 2 3 4 5
Chapter 16 SOFTWARE TESTING
TECHNIQUES
该图中，流图的节点以数字标识，边以字母
标识，矩阵中的字母项对应于节点间的连接。
图矩阵只是流图的表格表示，然而，对每个
矩阵项加入连接权值，图矩阵就可以用于在
测试中评估程序的控制结构。连接权值可以
是下列属性：
（ 1） 执行连接的概率；
（ 2）穿越连接的处理时间；
（ 3）穿越连接时所需的内存；
（ 4）穿越连接时所需的资源。
利用这些技术，设计测试用例的分析就可以自
动化或部分自动化。
16.5 控制结构测试
基本路径测试技术是控制结构测试技术之
一。
16.5.1 条件测试
条件测试是检查程序模块中所包含逻辑条
件的测试用例设计方法。
16.5.2 数据流测试
16.5.3 循环测试
16.6 黑盒测试
黑盒测试注重于测试软件的功能需求，黑
盒测试不是用来代替白盒测试，而是用于辅
助白盒测试发现其他类型的错误。
黑盒测试主要用于发现以下类型的错误：
（ 1）功能不对或遗漏；
（ 2）界面错误；
（ 3）数据结构或外部数据库访问错误；
（ 4）性能测试
（ 5）初始化或终止错误。
白盒测试在测试的早期执行，黑盒测试在
测试的晚期执行。
16.6.1 基于图的测试方法
黑盒测试的第一步是理解软件所表
示的对象及其关系。软件测试首先是创
建对象及其关系图。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
对象 1
对象 3
对象 2
（节点权值）
间接连接 并行连接
有向连接
（连接权
值）
图的符号体系
Chapter 16 SOFTWARE TESTING
TECHNIQUES
新建文件
文档文本
文档窗口
表示为 包含
菜单选择生成
（生成时间 <1.0秒）
对象图的例子
允许编
辑
属性：
初始尺寸：缺省设
置
背景色：白色
文本颜色：缺省选
择
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.6.2 等价划分
等价划分是一种黑盒测试方法，将程序
的输入域划分为数据类，以便导出测试
用例。等价划分试图定义一个测试用例
以发现各类错误，从而减少必须开发的
测试用例数。
如果对象由具有对称性、传递性和自反性
的关系连接，就存在等价类。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
例如：考虑自动银行应用软件所维护的数据、
用户可以用自己的微机拨号到银行、提供六
位数的密码，并遵循一系列键盘命令以触发
各种银行功能。银行应用程序的软件可以接
受如下格式的数据：
区号：空或三位数字。
前缀：三位数字，但不是 0和 1开始。
后缀：四位数字。
密码：六位字母或数字。
命令：检查，存款，付款等。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
与银行应用程序各种数据元素相关的输入条件可
以表示为：
区号：输入条件，布尔 – 区号存在与否；
输入条件，范围 —定义在 200和 999之间的
数值，少数例外。
前缀：输入条件，范围 —大于 200不含 0的数值。
后缀：输入条件，值 —四位数字。
密码：输入条件，布尔 —密码存在与否；
输入条件，值 —六位字符串。
命令：输入条件，集合 —包含上述命令。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.6.3 边界值分析
输入域的边界比中间更加容易发生错
误，所以可用边界值分析（ boundary
value analysis,VBA） 作为一种测试技术。
边界值分析选择一组测试用例检查边界
值。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.6.4 比较测试
在某些情况下，如航空电子设备、
核电厂控制等，软件的可靠性是绝对重
要的。我们可以开发冗余的软件版本。
测试时，可以比较多个版本的输出结果。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.7 针对专门环境和应用的测试
16.7.1 GUI测试
图形用户界面（ GUI）。
16.7.2 客户 /服务器体系结构测试
16.7.3 测试文档和帮组设施
文档测试可以分为两个步骤。第一步为正
式的技术复审，检查文档的编辑错误；第二
步是活性测试（ live testing）,结合实际程序的
使用而使用文档。
Chapter 16 SOFTWARE TESTING
TECHNIQUES
16.7.4 实时系统测试
实时系统的测试更加困难，因为测试时
必须考虑时间依赖性和异步性。不仅考
虑黑盒和白盒测试用例，而且包括事件
处理（如中断处理），数据的时间安排
以及处理数据的任务的并发性。
小结
测试用例设计的主要目标是导出有可能发现软
件错误的测试集，为此，有两种不同的测试
用例设计技术：白盒测试和黑盒测试。
白盒测试注重于程序控制结构。测试用例要保
证测试时程序的所有语句至少执行一次，而
且检查了所有的逻辑条件。是一种小规模测
试。
黑盒测试发现功能需求错误，而不考虑程序的
内部工作。
小结
有经验的软件开发者经常说：“测试永不
终止，只是从软件工程师转移到客户。
客户每次使用程序时，都是一次测试。”
通过设计测试用例，软件工程师可以进
行更广泛的测试，从而在“客户测试”
之前发现并修改尽可能多的错误。
