第 十 一 讲
测试（ Testing)
本讲（第七章）的主要内容
一、软件测试及其目标
二、软件测试准则
三、测试方法
四、测试阶段的信息流
五、测试阶段
一,Myers的软件测试的定义
? 测试是为了发现程序中的错误而执行程序
的过程；
? 好的测试方案是极可能发现迄今为止尚未
发现的错误的测试方案；
? 成功的测试是发现了迄今为止尚未发现的
错误的测试 。
测试的意义和几点说明
? 软件质量保证的最重要手段
– 是否达到需求说明的功能和预期的指标
? 测试耗时费力，应用最小的测试代价获得最大
的测试效果。
? 测试是为了发现错误，不是为了证明程序无错
误。
? 测试不能证明程序中没有错误。
? 测试的可信度（ dependability)问题。
― Testing is the unavoidable part of any
responsible effort to develop a software
system.‖
— William Howden
― Optimism is the occupational hazard of
programming; testing is the treatment.‖
— Kent Beck
“Errors are more common,more
pervasive,and more troublesome in
software than other technologies.”
— David Parnas
― The first mistake that people make is
thinking that the testing team is
responsible for assuring quality.‖
— Brian Marick
―Every program does something right;
it just may not be the thing we want it
to do.‖
— we unknown
二、软件测试准则
? 所有的测试都应追溯到用户需求，从用户角度看，
最严重的错误是不能满足需求。
? 制定测试计划，并严格执行，排除随意性。测试
计划在需求分析阶段就开始了，详细的测试用例
在设计阶段确定。
? Pareto原则：所发现错误的 80%很可能源于程序模
块的 20%中。
? 测试应当从‘小规模’开始，逐步转向‘大规
模’。
? 穷举测试是不可能的（ Exhaustive testing）。
? 由独立的第三方或专门的测试小组进行独立测试。
Cont.
? 测试用例由输入数据和相应的预期输出组成。
? 测试用例不仅选用合理的输入数据，还要选择不
合理的。
? 不仅检查程序是否做了应该做的事，还应该检查
是否不应该做的。
? 长期保留测试用例，以便进行回归测试和维护。
三、测试技术的分类
? 静态测试
– 代码会审 code inspection
– 走查 walk-through
– 办公桌检查 desk checking
– 例如,Yourdon结构化走通,IBM的 Fagan检查
? 动态测试
– 黑盒测试
– 白盒测试
– 穷举和选择测试。
静态测试
? 定义,人工方式进行的代码复审。又称 人工测试，
代码复审。
? 目的：检查程序的静态结构，找出编译不能发现
的错误和人的主观认识上的偏差。
? 范围：需求定义、设计文档、源代码（着重分析）
? 特点：
– Myers的研究表明，对于某些类型的错误，静态
测试更有效 。
– 经验表明，组织良好的代码复审可以发现程序
中 30%到 70%的编码和逻辑设计错误。
– 不存在错误定位问题。
动态测试
? 定义, 机器测试，在设定的测试数据上执行被
测试程序的过程。
? 目的, 通过执行程序代码动态地验证结果的正
确性。
? 三个过程, 设计测试用例；执行被测试程序；
分析执行结果并发现错误。
? 三个要素,程序、测试数据、需求定义
? 两个方面, 在测试数据上程序是对的；测试
数据是正确的。
黑盒测试（ Black-Box Testing)
? 定义
– 已知产品应该具有的功能，通过测试检验其
每个功能是否都能够正常使用。又称功能测
试
? 用途
– 把程序看成一个黑盒子，仅仅考虑输入和输
出的对应关系和程序接口，完全不考虑它的
内部结构和处理过程。一般用于综合测试、
系统测试等
白盒测试 （ White-Box Testing)
? 定义
– 已知产品内部的工作过程，通过测试检验产
品内部动作是否都能按照需求定义的规定正
常使用。又称 Glass box testing，结构测试。
? 用途
– 必须完全了解程序的内部结构和处理过程，
才能按照程序内部的逻辑测试，以检验程序
中每条路径是否正确，因此 一般用于规模较
小软件。
穷举测试（ Exhaustive Testing）
? 定义：包含所有可能情况的测试。
? 对于黑盒测试，必须对所有输入数据的各种可
能值的排列组合都进行测试。
? 对于白盒测试，程序中每条可能的路径在每种
可能的输入数据下至少执行一次。
? 穷举测试是不可能的
– 对于黑盒是不可能的。例如，对 C编译器进行测试，
一方面要编出所有合法程序让它编译；另一方面又要
编出一切不合法的程序，考察它能否指出程序的非法
性质。显然，这两类程序的数量是无限的。
– 对于白盒也是不可能的。
选择测试
? 仅选择一些具有代表的、典型的测试
用例，进行有限的测试。
? 以最少的测试用例发现最多的程序错
误。
四、测试阶段的信息流程
正确
可靠性
错误
错误率数据
预期结果
测试结果
测试配置
软件配置
测试 评价
调试
可靠性
模型
五、软件测试的阶段
1,单元测试 （模块测试）：目的是保证每个模块
作为一个单元能正确运行。主要测试编码和详
细设计阶段的错误。
2,子系统测试,把经过单元测试的模块放在一起
形成子系统。注重模块接口。
3,系统测试 （集成测试）：测试由子系统组成的
整个系统，不仅测试模块间的协调和通信能力。
还要测试设计错误、需求说明中的功能错误。
4,验收测试,确认系统能够满足用户的需求，方
法同系统测试，主要强调用户的参与（ alpha测
试），测试需求说明中的功能错误。
5,平行运行, beta测试
单元测试 (unit testing)
? 单元测试主要评价模块的五个特性：
– 模块接口（ 具体细节参照 P143）
– 局部数据类型
– 重要的执行通路
– 出错处理通路
– 影响以上特性的边界条件
? 单元测试过程
– 代码审查
– 设计驱动软件（驱动模块 driver）
? 代替上级模块
– 设计存根软件 （桩模块 stub）
? 代替下级模块
集成测试 (Integration Testing)
? 模块单元 → 子系统测试 → 系统测试
? 主要发现与接口有关的问题
? 两种集成方法：
– 非渐增式集成测试（莽撞测试 big bang testing)
– 渐增式集成测试（ incremental testing )
两种集成测试方法的比较
? 渐增式测试利用已测试过的模块作为部分测试
程序，所要编写测试程序少，工作量小；
? 渐增式测试能够较早发现接口错误；
? 渐增式测试利于错误的诊断和定位；
? 渐增式测试对程序的测试更彻底（已测试的模
块可以在新条件下验证）
? 渐增式测试虽然所要编写测试程序少，但机器
资源开销大
? 非渐增式测试可以并行测试所有模块，能够充
分利用人力，以加快工程进度。
渐增式测试策略
1,自顶向下 ( top-down)
2,自底向上 ( bottom-up)
3,混合方法（ Sandwich)
1,自顶向下 ( top-down)
? 两种结合策略
– 深度优先：先组装软件结构中一条主控通路上的模块。
– 宽度优先：沿软件结构水平移动，把处于同一个控制
层次上的所有模块组装起来。
? 测试步骤
– 测试主控模块，由桩模块代替所有直属模块
– 根据所确定的组合策略增加一个模块，设计新的桩模
块。
– 测试，如果在新的条件下发现新的错误，执行下一步；
否则执行上一步。
– 回归测试（全部或部分地重复已做过的测试并返回）
2,自底向上 ( bottom-up)测试步骤
? 由一个叶模块开始，自底向上逐步添加新模
块，组成程序的一个子系统或具有某一功能
的模块族（群 Cluster)
? 设计驱动程序，协调测试数据的输入和输出
? 测试
? 去掉驱动模块，沿软件结构自下而上移动，
把有关的子系统结合，形成更大的子系统。
3,混合方法（ Sandwich)
? 对上层模块采用自顶向下，较早显示程
序的总体轮廓。
? 对某些关键模块（如具有 I/O功能的模块、
功能重要或含有特殊算法的模块）或子
系统采用自底向上组装和测试，以便容
易地产生测试用例或减少重复测试次数。
两种渐进式测试策略的比较
? 自顶向下
– 能够较早地显示整个系统地轮廓和总体结构。
– 不用设计驱动模块。
– 上层模块有更多地测试机会。
? 自底向上
– 不能够较早地显示整个系统地轮廓。
– 不用设计桩模块（一般编写桩模块比编写驱
动模块困难），容易产生测试用例。
– 下层模块有更多地测试机会。
验收测试 (validation testing)
? 确认测试：确认所开发的系统是否符合需求规
范的要求,其目标是验证软件的有效性。
? 软件的有效性：如果软件的功能和性能如同用
户所合理期待的那样,软件就是有效的。
? 依据：根据 SRS对质量保证的要求，制定“验
证与确认计划”，即复审和验收的依据。
? 验证 (verification)：是否实现了所设计的要求？
? 确认 (validation)：满足用户的需求？
验收测试的具体内容
? 功能测试
? 性能测试（响应时间、处理速度、
容量开销等）
? 强度测试（对强负荷的承受能力）
? 对文档配置的复审
友情提示：验收测试
一般采用黑盒测试，
其测试范围与系统测
试略有不同，如弱化
一些技术性的测试，
强化用户所关心的功
能和性能测试等。
平行测试
? 在运行现有系统的同时，实际运行目标
系统。
? Alpha 测试与 Beta测试。
完成测试的标准（ Criteria)
? 规定测试的方法和应该达到的条件，如
白盒测试的语句覆盖达到 90%等。可以
开发有关的工具。
? 根据可靠性模型，规定至少要查出的错
误数。
? 测试的可信度（ Dependability）问题。
第 十 二 讲
白盒测试的测试方案设计
测试方案与测试用例
? 测试方案,测试目的 +输入数据 +期望结果
? 测试用例,输入数据 +期望结果
? 设计测试方案的基本目标
– 确定能够最大可能发现错误的测试用例
针对不同的测试技术设计测试方案
? 适用于白盒测试的技术,逻辑覆盖
? 适用于黑盒测试的技术
– 等价类划分
– 边界值分析
– 错误猜测法
– 因果图法
逻辑覆盖（ Logic Coverage)
1,语句覆盖
2,判定覆盖（分支覆盖）
3,条件覆盖
4,判定 /条件覆盖：同时满足判定覆盖和条件覆盖。
5,条件组合覆盖
6,点覆盖：与语句覆盖相同。
7,边覆盖：执行路径至少经过程序图中每条边一次。
8,路径覆盖：每条可能路径都至少执行一次。
9,基本路径覆盖
1,语句覆盖
? 每条语句至少执行一次
语句覆盖示例
7
4
6
5
3
T
T
2 F
X=X/A
F
1
X=X + 1
入口
出口
A>1 AND B=0
A=2 OR X>1
PROC EXPA（ A,B,X,REAL）；
BEGIN
IF (A>1 AND B=0 )
THEN X=X/A；
IF (A=2 OR X>1)
THEN X=X + 1；
END；
A=2,B=0,X=4
即两个判定都为真
？如果把 AND 误
写成 OR，这组测
试用例有效否
路径,1—4—5—6—7
2,判定覆盖
? 分支覆盖，不仅每条语句至少执行一次，
而且每个判定的每个分支都至少执行一
次。
判定覆盖示例
测试用例：
A=3,B=0,X=3
A=2,B=1,X=1
两个判定分别
为真和假各一次
路径,1—4—5—3 IF1=T,IF2=F
1—2—6—7 IF1= F,IF2= T
7
4
6
5
3
T
T
2 F
X=X/A
F
1
X=X + 1
入口
出口
A>1 AND B=0
A=2 OR X>1
3,条件覆盖
? 不仅每条语句至少执行一次，而且使判
定表达式的每个条件都取得各种可能的
结果。
条件覆盖示例
测试用例：
A=2,B=0,X=4
A=1,B=1,X=1
即两个判定中的
四个条件表达式
分别为真和假一次
？满足条件覆盖是
否
一定满足判定覆
盖
路径,1—4—5—6—7 满足,A>1,B=0,A=2,X>1
1—2—3 满足,A≤1,B≠0,A≠2,X ≤ 1
A=2,B=0,X=1
A=1,B=1,X=2
满足条件覆盖
不满足判定覆盖
满足判定覆盖
7
4
6
5
3
T
T
2 F
X=X/A
F
1
X=X + 1
入口
出口
A>1 AND B=0
A=2 OR X>1
4,判定 /条件覆盖
? 既满足判定覆盖又满足条件覆盖。
? 有时，并不比条件覆盖更强。
? 有时，并不比判定覆盖更强。
5,条件组合覆盖
? 每个判定表达式中条件的各种组合至少
出现一次。
条件组合覆盖示例
A>1,B=0
A>1,B≠0
A≤1,B=0
A≤1,B≠0
A=2,X>1
A=2,X ≤ 1
A≠2,X>1
A≠2,X ≤ 1
共八种组合：
测试用例 满足的组合 覆盖的路径
A=2,B=0,X=4 A>1,B=0,A=2,X>1 1—4—5—6—7
A=2,B=1,X=1 A>1,B≠0,A=2,X ≤ 1 1—2—6—7
A=1,B=0,X=2 A≤1,B=0,A≠2,X>1 1—2—6—7
A=1,B=1,X=1 A≤1,B≠0,A≠2,X ≤ 1 1—2—3
7
4
6
5
3
T
T
2 F
X=X/A
F
1
X=X + 1
入口
出口
A>1 AND B=0
A=2 OR X>1
6,点覆盖
? 如果连通图 G的子图 G`是连通的，且包
含 G的所有节点，则称 G`是 G的点覆盖。
G`? G ∧ G` 连通 ∧ V（ G`） = V（ G） → 点覆
盖
? 与语句覆盖相同
7,边覆盖
? 如果连通图 G的子图 G`是连通的，且包
含 G的所有边，则称 G`是 G的边覆盖。
G`? G ∧ G` 连通 ∧ E（ G`） = E（ G） → 边覆盖
? 执行路径至少经过程序图中每条边一次。
8,路径覆盖
? 路径
? 每条可能路径都至少执行一次
9,基本路径覆盖
? 独立路径
– 指包括一组以前没有处理的语句或条件的一
条路径。
– 从程序图来看，一条独立路径至少包含一条
其它独立路径中未有过的边。
? 基本路径
– 一组独立路径集
确定基本路径的步骤
1,源程序，程序流程图等 → 程序图
2,计算环域复杂度 N
3,确定 N各独立路径
4,设计测试数据
基本路径示例
2
3
4 5
7
6 8
9
1
计算它的环形复杂度
V（ G）
= 判定数 +1
= 3+1 = 4
求它的一组独立路径
路径 1,1-9
路径 2,1-2-7-8-1-9
路径 3,1-2-3-4-6-8-1-9
路径 4,1-2-3-5-6-8-1-9
第 十 三 讲
黑盒测试的测试方案设计
黑盒测试所发现的错误类型
? 功能不正确或遗漏
? 界面错误
? 数据结构错误或外部数据库访问错误
? 性能错误
? 初始化和终止错误
设计黑盒测试方案所考虑的问题
? 怎样测试功能的有效性？
? 哪些类型的输入可以构成好测试用例？
? 系统是否对特定的输入值特别敏感？
? 怎样划定数据类的边界？
? 系统能够承受什么样的数据率和数据量？
? 数据的特定组合将对系统运行产生什么
影响？
设计黑盒测试方案所满足的标准
? 在达到合理测试要求的前提下，使得
测试用例总数尽量的少。
? 所设计的测试用例能够告诉我们，是
否存在某些类型的错误，而不是仅仅
指出与特定测试相关的错误是否存在。
黑盒测试方案设计技术
1,等价类划分
2,边界值分析
3,错误猜测法
4,因果图法
1,等价类划 （ Equivalence Partitioning）
? 把软件的输入域或输入空间看作一个集合，
那么，可以根据 一定的规则 确定这个集合
的多个等价类 (数据类）。等价类是集合的
子集，它可以产生一个集合的划分。
? 例如集合 {1,5,3.1,5.2,a,b,J,K}
{{1,5 },{3.1,5.2 },{a,b},{J,K }}
等价类划分的启发式规则
1,如果规定了输入值的范围，则可以划分出一个有效等价
类和两个无效等价类；
2,如果规定了输入值的个数，则可以划分出一个有效等价
类和两个无效等价类；
3,如果规定了输入数据的已组值，而且程序对不同输入值
做不同处理，则每个允许的输入值就是一个有效等价类，
和一个无效等价类；
4,如果规定了 输入数据必须遵循的规则,则可以划分出一
个有效等价类和若干个无效等价类；
5,如果规定了 输入数据为整型,则可以划分出正整数、零
和负整数 3个有效等价类；
6,如果程序的处理对象是表格，则应该使用空表，以及含
有一项或多项的表。
根据等价类设计测试方案的步骤
1.重复设计一个新的测试用例，以尽可能多
地覆盖尚未被覆盖的有效等价类，直到所
有的有效等价类被覆盖为止； (P163)
2.重复设计一个新的测试用例，使它覆盖一
个且只覆盖一个尚未被覆盖的无效等价类，
直到所有的有效等价类被覆盖为止。
根据等价类设计测试方案的实例
p163
2,边界值分析 (Boundary Value Analysis)
? 边界值
– 对于一个变量,指它的 定义域边界附近的值。
– 对于一个数据结构，如二维表，空表、满表、仅
含有一行的表都属于它的边界值。同样链表、队
列、数据等都是如此。
– 对于循环体，循环变量等于 0,1,N-1,N等。
– 等价类也有边界。不应该仅仅选取等价类的典型
值和任意值。
? 选取的测试数据为刚好等于、刚刚小于和刚刚大
于边界的边界值。
3,错误猜测法 Error Guessing
? 定义：凭测试人员直觉和经验
? 常用的技术与经验
– 根据常见的错误进行总结
– 利用 Pareto规则
– IBM的经验（ IBM OS/370,47%错误 对应于 4%
的模块）
– 等价划分和边界值分析法没有考虑的输入数据
的组合效应。
– 人工代码检查中修改的地方要重点关注
– 建立相应的可靠性模型
4,因果图法
? 通过对“多种输入条件的组合，相应产
生多个动作”的描述，进行测试用例设
计。
? 因果图法最终生成的是判定表。
因果图法生成测试用例的基本步骤
1,分析软件需求规范说明书，确定哪些是原因（输
入条件或其等价类），哪些是结果（输出条件），
并给每个原因和结果赋予一个标识符。
2,找出原因于结果之间，原因和原因之间的对应关
系，画出因果图。
3,对一些不可能出现的情况用一些记号表明其限制
条件或约束。
4,把因果图转换成判定表。
5,以判定表中的每一列为依据，设计测试用例。
利用因果图设计测试用例的实例
以 5角为单价的饮料自动售货机的规格说明：
若投入 5角或 1元的硬币，按下 橙汁 或 啤酒 按
钮，则相应的饮料就送出来。
若售货机没有零钱找，则一个显示 零钱找完
的红灯亮，这时在投入 1元硬币并按下按钮后，售
货机不送出饮料并退出 1元硬币；
若售货机有零钱找，则显示 零钱找完 的红灯
灭，这时在投入 1元硬币并按下按钮后，售货机送
出饮料并找零 5角硬币。
第一步,确定原因和结果
原 因
1,售货机有零钱找
2,投入 1元硬币
3,投入 5角硬币
4,按下 橙汁 按钮
5,按下 啤酒 按钮
结 果
21.零钱找完 灯亮
22.退还 1元硬币
23.退还 5角硬币
24.送出橙汁饮料
25.送出啤酒
第二步,建立中间结点并画出因果图
中间结点：表示处理的中间状态
11.投入 1元硬币并按下饮料按钮
12.按下 橙汁 或 啤酒 按钮
13.应当找 5角硬币且售货机有零钱找
14.钱已付清
有零
钱找
钱付清
按下按钮
可找 5角该找 5角
按下
啤酒
按下
橙汁
投入
5角
投入
1元
送出
啤酒
送出
橙汁
找回
5 角
退还
1 元
零钱找
完 灯亮
11 13
12 14
25
24
23
22
21
5
4
2
3
1
E
E
∨
∧
∧
∧
∧
∧
∨
第三步,描述约束条件
1,E(互斥）
2,I（包含）
3,O（唯一）
4,R（要求）
5,M（屏蔽）
2
1
E,
O 2
1
R,
M
2
3
1
I
第四步,转换成判定表
见 Word 文档
实用测试策略
? 通常用黑盒法设计基本的测试方案，
再用白盒法补充，其具体的实用策略：
– 在任何情况下都应该使用边界值分析法；
– 必要时用等价划分法补充
– 必要时用错误推测法补充
– 对照程序逻辑，检查已经设计出的测试方
案，根据可靠性要求和没有达到的覆盖标
准，适当提高逻辑覆盖率
? 测试方案实例
调 试 Debugging
? 目的：改正错误
? 两个调试过程
– 错误定位：确定程序中可疑错误的确切性质
和位置
– 错误改正：对程序（设计，编码）进行修改，
排除错误
调试技术
? 输出存储器内容（ Memory Dump)
– 很难把内存地址和源程序变量对应；
– 输出的是程序某个时刻的静态图像，常常不是
程序出错状态；
– 输出信息的形式不易阅读和解释。
? 打印语句
– 把打印语句插在源程序关键部位，如关键变量
改变、重要分支、子程序调用部位，以提供线索
? 自动工具（设置断点，交互式地分析程序动
态过程）
调试策略
? 蛮干法，试探法（一般避免使用）
? 回溯法（从发现症状的地方开始，人工
沿程序的控制流回溯追踪源代码，直到
找到错误原因为止）
? 对分查找法
? 归纳法
? 演绎法
归纳法排错的基本思想
? 从特殊推断一般的系统化的思考方法。
先把和错误有关的数据组织起来进行分
析，以便发现可能的错误原因。即从一
些线索数据（错误征兆）着手，通过分
析它们之间的关系找出错误。
归纳法排错的分析步骤
? 收集线索数据
– 已知的测试用例、执行结果
? 组织数据
– 整理线索以便发现一些规律。
? 提出关于出错原因的假设
– 分析线索之间的关系，利用在线索结构中的矛盾现
象，提出假设。
? 证明假设
– 把假设与原始线索比较，若能完全解释一切现象，
则假设得到证明；否则，就认为假设不合理，或不
完全，或存在多个错误，只能消除部分。
演绎法排错的基本思想
? 从一般原理或前提出发，经过排除和精化的过程来推导出结论的思考方法。
? 首先根据已有的测试用例，设想及枚举
出所有可能出错的原因作为假设；然后
再用原始测试数据或新的测试，从中逐
个排除不可能正确的假设；最后，用测
试数据验证余下的假设确是出错的原因。
演绎法排错的分析步骤
? 收集线索数据：已知的测试用例、执行结果
? 组织数据：整理线索以便发现一些规律。
? 提出关于出错原因的假设：分析线索之间的
关系，利用在线索结构中的矛盾现象，提出
假设。
? 列举所有可能出错原因的假设,用已有数据
排除不正确的假设。
? 证明假设成立否。
软件可靠性 (Software Reliability)
? 见 WORD文档
? 软件可靠性 是指软件在规定的运行环境中
和规定的时间内无失效运行的概率 。 所以
它是时间 t的函数，我们用 R( t )来表示。
? 软件故障率 (failure rate)是指在单位时
间内软件发生故障的概率。
? 测试完成率, 已完成的测试用例占预先确定
的全部测试用例的百分比。
? 以测试完成率结合测试时间使用率为依据，
来估计软件开发的成功与否。
? 三个阶段, 曲线缓升 ； 曲线陡升 ； 曲线趋平
日立预测法 —测试完成率模型
日立预测法 —错误发现率模型
? 错误发现率：单位时间内发现的错误数
? 以错误发现率的变化，预测工程的前景。
错误发现率曲线在预定期限内的某一点
达到峰值，计算刚过峰值点以后错误发
现率曲线的导数（ -0.3到 0预示失败； -
0.3到 -1预示成功）
自动测试工具
? 测试数据生成程序
? 动态分析程序
? 静态分析程序
? 文件比较程序
测试（ Testing)
本讲（第七章）的主要内容
一、软件测试及其目标
二、软件测试准则
三、测试方法
四、测试阶段的信息流
五、测试阶段
一,Myers的软件测试的定义
? 测试是为了发现程序中的错误而执行程序
的过程；
? 好的测试方案是极可能发现迄今为止尚未
发现的错误的测试方案；
? 成功的测试是发现了迄今为止尚未发现的
错误的测试 。
测试的意义和几点说明
? 软件质量保证的最重要手段
– 是否达到需求说明的功能和预期的指标
? 测试耗时费力，应用最小的测试代价获得最大
的测试效果。
? 测试是为了发现错误，不是为了证明程序无错
误。
? 测试不能证明程序中没有错误。
? 测试的可信度（ dependability)问题。
― Testing is the unavoidable part of any
responsible effort to develop a software
system.‖
— William Howden
― Optimism is the occupational hazard of
programming; testing is the treatment.‖
— Kent Beck
“Errors are more common,more
pervasive,and more troublesome in
software than other technologies.”
— David Parnas
― The first mistake that people make is
thinking that the testing team is
responsible for assuring quality.‖
— Brian Marick
―Every program does something right;
it just may not be the thing we want it
to do.‖
— we unknown
二、软件测试准则
? 所有的测试都应追溯到用户需求，从用户角度看，
最严重的错误是不能满足需求。
? 制定测试计划，并严格执行，排除随意性。测试
计划在需求分析阶段就开始了，详细的测试用例
在设计阶段确定。
? Pareto原则：所发现错误的 80%很可能源于程序模
块的 20%中。
? 测试应当从‘小规模’开始，逐步转向‘大规
模’。
? 穷举测试是不可能的（ Exhaustive testing）。
? 由独立的第三方或专门的测试小组进行独立测试。
Cont.
? 测试用例由输入数据和相应的预期输出组成。
? 测试用例不仅选用合理的输入数据，还要选择不
合理的。
? 不仅检查程序是否做了应该做的事，还应该检查
是否不应该做的。
? 长期保留测试用例，以便进行回归测试和维护。
三、测试技术的分类
? 静态测试
– 代码会审 code inspection
– 走查 walk-through
– 办公桌检查 desk checking
– 例如,Yourdon结构化走通,IBM的 Fagan检查
? 动态测试
– 黑盒测试
– 白盒测试
– 穷举和选择测试。
静态测试
? 定义,人工方式进行的代码复审。又称 人工测试，
代码复审。
? 目的：检查程序的静态结构，找出编译不能发现
的错误和人的主观认识上的偏差。
? 范围：需求定义、设计文档、源代码（着重分析）
? 特点：
– Myers的研究表明，对于某些类型的错误，静态
测试更有效 。
– 经验表明，组织良好的代码复审可以发现程序
中 30%到 70%的编码和逻辑设计错误。
– 不存在错误定位问题。
动态测试
? 定义, 机器测试，在设定的测试数据上执行被
测试程序的过程。
? 目的, 通过执行程序代码动态地验证结果的正
确性。
? 三个过程, 设计测试用例；执行被测试程序；
分析执行结果并发现错误。
? 三个要素,程序、测试数据、需求定义
? 两个方面, 在测试数据上程序是对的；测试
数据是正确的。
黑盒测试（ Black-Box Testing)
? 定义
– 已知产品应该具有的功能，通过测试检验其
每个功能是否都能够正常使用。又称功能测
试
? 用途
– 把程序看成一个黑盒子，仅仅考虑输入和输
出的对应关系和程序接口，完全不考虑它的
内部结构和处理过程。一般用于综合测试、
系统测试等
白盒测试 （ White-Box Testing)
? 定义
– 已知产品内部的工作过程，通过测试检验产
品内部动作是否都能按照需求定义的规定正
常使用。又称 Glass box testing，结构测试。
? 用途
– 必须完全了解程序的内部结构和处理过程，
才能按照程序内部的逻辑测试，以检验程序
中每条路径是否正确，因此 一般用于规模较
小软件。
穷举测试（ Exhaustive Testing）
? 定义：包含所有可能情况的测试。
? 对于黑盒测试，必须对所有输入数据的各种可
能值的排列组合都进行测试。
? 对于白盒测试，程序中每条可能的路径在每种
可能的输入数据下至少执行一次。
? 穷举测试是不可能的
– 对于黑盒是不可能的。例如，对 C编译器进行测试，
一方面要编出所有合法程序让它编译；另一方面又要
编出一切不合法的程序，考察它能否指出程序的非法
性质。显然，这两类程序的数量是无限的。
– 对于白盒也是不可能的。
选择测试
? 仅选择一些具有代表的、典型的测试
用例，进行有限的测试。
? 以最少的测试用例发现最多的程序错
误。
四、测试阶段的信息流程
正确
可靠性
错误
错误率数据
预期结果
测试结果
测试配置
软件配置
测试 评价
调试
可靠性
模型
五、软件测试的阶段
1,单元测试 （模块测试）：目的是保证每个模块
作为一个单元能正确运行。主要测试编码和详
细设计阶段的错误。
2,子系统测试,把经过单元测试的模块放在一起
形成子系统。注重模块接口。
3,系统测试 （集成测试）：测试由子系统组成的
整个系统，不仅测试模块间的协调和通信能力。
还要测试设计错误、需求说明中的功能错误。
4,验收测试,确认系统能够满足用户的需求，方
法同系统测试，主要强调用户的参与（ alpha测
试），测试需求说明中的功能错误。
5,平行运行, beta测试
单元测试 (unit testing)
? 单元测试主要评价模块的五个特性：
– 模块接口（ 具体细节参照 P143）
– 局部数据类型
– 重要的执行通路
– 出错处理通路
– 影响以上特性的边界条件
? 单元测试过程
– 代码审查
– 设计驱动软件（驱动模块 driver）
? 代替上级模块
– 设计存根软件 （桩模块 stub）
? 代替下级模块
集成测试 (Integration Testing)
? 模块单元 → 子系统测试 → 系统测试
? 主要发现与接口有关的问题
? 两种集成方法：
– 非渐增式集成测试（莽撞测试 big bang testing)
– 渐增式集成测试（ incremental testing )
两种集成测试方法的比较
? 渐增式测试利用已测试过的模块作为部分测试
程序，所要编写测试程序少，工作量小；
? 渐增式测试能够较早发现接口错误；
? 渐增式测试利于错误的诊断和定位；
? 渐增式测试对程序的测试更彻底（已测试的模
块可以在新条件下验证）
? 渐增式测试虽然所要编写测试程序少，但机器
资源开销大
? 非渐增式测试可以并行测试所有模块，能够充
分利用人力，以加快工程进度。
渐增式测试策略
1,自顶向下 ( top-down)
2,自底向上 ( bottom-up)
3,混合方法（ Sandwich)
1,自顶向下 ( top-down)
? 两种结合策略
– 深度优先：先组装软件结构中一条主控通路上的模块。
– 宽度优先：沿软件结构水平移动，把处于同一个控制
层次上的所有模块组装起来。
? 测试步骤
– 测试主控模块，由桩模块代替所有直属模块
– 根据所确定的组合策略增加一个模块，设计新的桩模
块。
– 测试，如果在新的条件下发现新的错误，执行下一步；
否则执行上一步。
– 回归测试（全部或部分地重复已做过的测试并返回）
2,自底向上 ( bottom-up)测试步骤
? 由一个叶模块开始，自底向上逐步添加新模
块，组成程序的一个子系统或具有某一功能
的模块族（群 Cluster)
? 设计驱动程序，协调测试数据的输入和输出
? 测试
? 去掉驱动模块，沿软件结构自下而上移动，
把有关的子系统结合，形成更大的子系统。
3,混合方法（ Sandwich)
? 对上层模块采用自顶向下，较早显示程
序的总体轮廓。
? 对某些关键模块（如具有 I/O功能的模块、
功能重要或含有特殊算法的模块）或子
系统采用自底向上组装和测试，以便容
易地产生测试用例或减少重复测试次数。
两种渐进式测试策略的比较
? 自顶向下
– 能够较早地显示整个系统地轮廓和总体结构。
– 不用设计驱动模块。
– 上层模块有更多地测试机会。
? 自底向上
– 不能够较早地显示整个系统地轮廓。
– 不用设计桩模块（一般编写桩模块比编写驱
动模块困难），容易产生测试用例。
– 下层模块有更多地测试机会。
验收测试 (validation testing)
? 确认测试：确认所开发的系统是否符合需求规
范的要求,其目标是验证软件的有效性。
? 软件的有效性：如果软件的功能和性能如同用
户所合理期待的那样,软件就是有效的。
? 依据：根据 SRS对质量保证的要求，制定“验
证与确认计划”，即复审和验收的依据。
? 验证 (verification)：是否实现了所设计的要求？
? 确认 (validation)：满足用户的需求？
验收测试的具体内容
? 功能测试
? 性能测试（响应时间、处理速度、
容量开销等）
? 强度测试（对强负荷的承受能力）
? 对文档配置的复审
友情提示：验收测试
一般采用黑盒测试，
其测试范围与系统测
试略有不同，如弱化
一些技术性的测试，
强化用户所关心的功
能和性能测试等。
平行测试
? 在运行现有系统的同时，实际运行目标
系统。
? Alpha 测试与 Beta测试。
完成测试的标准（ Criteria)
? 规定测试的方法和应该达到的条件，如
白盒测试的语句覆盖达到 90%等。可以
开发有关的工具。
? 根据可靠性模型，规定至少要查出的错
误数。
? 测试的可信度（ Dependability）问题。
第 十 二 讲
白盒测试的测试方案设计
测试方案与测试用例
? 测试方案,测试目的 +输入数据 +期望结果
? 测试用例,输入数据 +期望结果
? 设计测试方案的基本目标
– 确定能够最大可能发现错误的测试用例
针对不同的测试技术设计测试方案
? 适用于白盒测试的技术,逻辑覆盖
? 适用于黑盒测试的技术
– 等价类划分
– 边界值分析
– 错误猜测法
– 因果图法
逻辑覆盖（ Logic Coverage)
1,语句覆盖
2,判定覆盖（分支覆盖）
3,条件覆盖
4,判定 /条件覆盖：同时满足判定覆盖和条件覆盖。
5,条件组合覆盖
6,点覆盖：与语句覆盖相同。
7,边覆盖：执行路径至少经过程序图中每条边一次。
8,路径覆盖：每条可能路径都至少执行一次。
9,基本路径覆盖
1,语句覆盖
? 每条语句至少执行一次
语句覆盖示例
7
4
6
5
3
T
T
2 F
X=X/A
F
1
X=X + 1
入口
出口
A>1 AND B=0
A=2 OR X>1
PROC EXPA（ A,B,X,REAL）；
BEGIN
IF (A>1 AND B=0 )
THEN X=X/A；
IF (A=2 OR X>1)
THEN X=X + 1；
END；
A=2,B=0,X=4
即两个判定都为真
？如果把 AND 误
写成 OR，这组测
试用例有效否
路径,1—4—5—6—7
2,判定覆盖
? 分支覆盖，不仅每条语句至少执行一次，
而且每个判定的每个分支都至少执行一
次。
判定覆盖示例
测试用例：
A=3,B=0,X=3
A=2,B=1,X=1
两个判定分别
为真和假各一次
路径,1—4—5—3 IF1=T,IF2=F
1—2—6—7 IF1= F,IF2= T
7
4
6
5
3
T
T
2 F
X=X/A
F
1
X=X + 1
入口
出口
A>1 AND B=0
A=2 OR X>1
3,条件覆盖
? 不仅每条语句至少执行一次，而且使判
定表达式的每个条件都取得各种可能的
结果。
条件覆盖示例
测试用例：
A=2,B=0,X=4
A=1,B=1,X=1
即两个判定中的
四个条件表达式
分别为真和假一次
？满足条件覆盖是
否
一定满足判定覆
盖
路径,1—4—5—6—7 满足,A>1,B=0,A=2,X>1
1—2—3 满足,A≤1,B≠0,A≠2,X ≤ 1
A=2,B=0,X=1
A=1,B=1,X=2
满足条件覆盖
不满足判定覆盖
满足判定覆盖
7
4
6
5
3
T
T
2 F
X=X/A
F
1
X=X + 1
入口
出口
A>1 AND B=0
A=2 OR X>1
4,判定 /条件覆盖
? 既满足判定覆盖又满足条件覆盖。
? 有时，并不比条件覆盖更强。
? 有时，并不比判定覆盖更强。
5,条件组合覆盖
? 每个判定表达式中条件的各种组合至少
出现一次。
条件组合覆盖示例
A>1,B=0
A>1,B≠0
A≤1,B=0
A≤1,B≠0
A=2,X>1
A=2,X ≤ 1
A≠2,X>1
A≠2,X ≤ 1
共八种组合：
测试用例 满足的组合 覆盖的路径
A=2,B=0,X=4 A>1,B=0,A=2,X>1 1—4—5—6—7
A=2,B=1,X=1 A>1,B≠0,A=2,X ≤ 1 1—2—6—7
A=1,B=0,X=2 A≤1,B=0,A≠2,X>1 1—2—6—7
A=1,B=1,X=1 A≤1,B≠0,A≠2,X ≤ 1 1—2—3
7
4
6
5
3
T
T
2 F
X=X/A
F
1
X=X + 1
入口
出口
A>1 AND B=0
A=2 OR X>1
6,点覆盖
? 如果连通图 G的子图 G`是连通的，且包
含 G的所有节点，则称 G`是 G的点覆盖。
G`? G ∧ G` 连通 ∧ V（ G`） = V（ G） → 点覆
盖
? 与语句覆盖相同
7,边覆盖
? 如果连通图 G的子图 G`是连通的，且包
含 G的所有边，则称 G`是 G的边覆盖。
G`? G ∧ G` 连通 ∧ E（ G`） = E（ G） → 边覆盖
? 执行路径至少经过程序图中每条边一次。
8,路径覆盖
? 路径
? 每条可能路径都至少执行一次
9,基本路径覆盖
? 独立路径
– 指包括一组以前没有处理的语句或条件的一
条路径。
– 从程序图来看，一条独立路径至少包含一条
其它独立路径中未有过的边。
? 基本路径
– 一组独立路径集
确定基本路径的步骤
1,源程序，程序流程图等 → 程序图
2,计算环域复杂度 N
3,确定 N各独立路径
4,设计测试数据
基本路径示例
2
3
4 5
7
6 8
9
1
计算它的环形复杂度
V（ G）
= 判定数 +1
= 3+1 = 4
求它的一组独立路径
路径 1,1-9
路径 2,1-2-7-8-1-9
路径 3,1-2-3-4-6-8-1-9
路径 4,1-2-3-5-6-8-1-9
第 十 三 讲
黑盒测试的测试方案设计
黑盒测试所发现的错误类型
? 功能不正确或遗漏
? 界面错误
? 数据结构错误或外部数据库访问错误
? 性能错误
? 初始化和终止错误
设计黑盒测试方案所考虑的问题
? 怎样测试功能的有效性？
? 哪些类型的输入可以构成好测试用例？
? 系统是否对特定的输入值特别敏感？
? 怎样划定数据类的边界？
? 系统能够承受什么样的数据率和数据量？
? 数据的特定组合将对系统运行产生什么
影响？
设计黑盒测试方案所满足的标准
? 在达到合理测试要求的前提下，使得
测试用例总数尽量的少。
? 所设计的测试用例能够告诉我们，是
否存在某些类型的错误，而不是仅仅
指出与特定测试相关的错误是否存在。
黑盒测试方案设计技术
1,等价类划分
2,边界值分析
3,错误猜测法
4,因果图法
1,等价类划 （ Equivalence Partitioning）
? 把软件的输入域或输入空间看作一个集合，
那么，可以根据 一定的规则 确定这个集合
的多个等价类 (数据类）。等价类是集合的
子集，它可以产生一个集合的划分。
? 例如集合 {1,5,3.1,5.2,a,b,J,K}
{{1,5 },{3.1,5.2 },{a,b},{J,K }}
等价类划分的启发式规则
1,如果规定了输入值的范围，则可以划分出一个有效等价
类和两个无效等价类；
2,如果规定了输入值的个数，则可以划分出一个有效等价
类和两个无效等价类；
3,如果规定了输入数据的已组值，而且程序对不同输入值
做不同处理，则每个允许的输入值就是一个有效等价类，
和一个无效等价类；
4,如果规定了 输入数据必须遵循的规则,则可以划分出一
个有效等价类和若干个无效等价类；
5,如果规定了 输入数据为整型,则可以划分出正整数、零
和负整数 3个有效等价类；
6,如果程序的处理对象是表格，则应该使用空表，以及含
有一项或多项的表。
根据等价类设计测试方案的步骤
1.重复设计一个新的测试用例，以尽可能多
地覆盖尚未被覆盖的有效等价类，直到所
有的有效等价类被覆盖为止； (P163)
2.重复设计一个新的测试用例，使它覆盖一
个且只覆盖一个尚未被覆盖的无效等价类，
直到所有的有效等价类被覆盖为止。
根据等价类设计测试方案的实例
p163
2,边界值分析 (Boundary Value Analysis)
? 边界值
– 对于一个变量,指它的 定义域边界附近的值。
– 对于一个数据结构，如二维表，空表、满表、仅
含有一行的表都属于它的边界值。同样链表、队
列、数据等都是如此。
– 对于循环体，循环变量等于 0,1,N-1,N等。
– 等价类也有边界。不应该仅仅选取等价类的典型
值和任意值。
? 选取的测试数据为刚好等于、刚刚小于和刚刚大
于边界的边界值。
3,错误猜测法 Error Guessing
? 定义：凭测试人员直觉和经验
? 常用的技术与经验
– 根据常见的错误进行总结
– 利用 Pareto规则
– IBM的经验（ IBM OS/370,47%错误 对应于 4%
的模块）
– 等价划分和边界值分析法没有考虑的输入数据
的组合效应。
– 人工代码检查中修改的地方要重点关注
– 建立相应的可靠性模型
4,因果图法
? 通过对“多种输入条件的组合，相应产
生多个动作”的描述，进行测试用例设
计。
? 因果图法最终生成的是判定表。
因果图法生成测试用例的基本步骤
1,分析软件需求规范说明书，确定哪些是原因（输
入条件或其等价类），哪些是结果（输出条件），
并给每个原因和结果赋予一个标识符。
2,找出原因于结果之间，原因和原因之间的对应关
系，画出因果图。
3,对一些不可能出现的情况用一些记号表明其限制
条件或约束。
4,把因果图转换成判定表。
5,以判定表中的每一列为依据，设计测试用例。
利用因果图设计测试用例的实例
以 5角为单价的饮料自动售货机的规格说明：
若投入 5角或 1元的硬币，按下 橙汁 或 啤酒 按
钮，则相应的饮料就送出来。
若售货机没有零钱找，则一个显示 零钱找完
的红灯亮，这时在投入 1元硬币并按下按钮后，售
货机不送出饮料并退出 1元硬币；
若售货机有零钱找，则显示 零钱找完 的红灯
灭，这时在投入 1元硬币并按下按钮后，售货机送
出饮料并找零 5角硬币。
第一步,确定原因和结果
原 因
1,售货机有零钱找
2,投入 1元硬币
3,投入 5角硬币
4,按下 橙汁 按钮
5,按下 啤酒 按钮
结 果
21.零钱找完 灯亮
22.退还 1元硬币
23.退还 5角硬币
24.送出橙汁饮料
25.送出啤酒
第二步,建立中间结点并画出因果图
中间结点：表示处理的中间状态
11.投入 1元硬币并按下饮料按钮
12.按下 橙汁 或 啤酒 按钮
13.应当找 5角硬币且售货机有零钱找
14.钱已付清
有零
钱找
钱付清
按下按钮
可找 5角该找 5角
按下
啤酒
按下
橙汁
投入
5角
投入
1元
送出
啤酒
送出
橙汁
找回
5 角
退还
1 元
零钱找
完 灯亮
11 13
12 14
25
24
23
22
21
5
4
2
3
1
E
E
∨
∧
∧
∧
∧
∧
∨
第三步,描述约束条件
1,E(互斥）
2,I（包含）
3,O（唯一）
4,R（要求）
5,M（屏蔽）
2
1
E,
O 2
1
R,
M
2
3
1
I
第四步,转换成判定表
见 Word 文档
实用测试策略
? 通常用黑盒法设计基本的测试方案，
再用白盒法补充，其具体的实用策略：
– 在任何情况下都应该使用边界值分析法；
– 必要时用等价划分法补充
– 必要时用错误推测法补充
– 对照程序逻辑，检查已经设计出的测试方
案，根据可靠性要求和没有达到的覆盖标
准，适当提高逻辑覆盖率
? 测试方案实例
调 试 Debugging
? 目的：改正错误
? 两个调试过程
– 错误定位：确定程序中可疑错误的确切性质
和位置
– 错误改正：对程序（设计，编码）进行修改，
排除错误
调试技术
? 输出存储器内容（ Memory Dump)
– 很难把内存地址和源程序变量对应；
– 输出的是程序某个时刻的静态图像，常常不是
程序出错状态；
– 输出信息的形式不易阅读和解释。
? 打印语句
– 把打印语句插在源程序关键部位，如关键变量
改变、重要分支、子程序调用部位，以提供线索
? 自动工具（设置断点，交互式地分析程序动
态过程）
调试策略
? 蛮干法，试探法（一般避免使用）
? 回溯法（从发现症状的地方开始，人工
沿程序的控制流回溯追踪源代码，直到
找到错误原因为止）
? 对分查找法
? 归纳法
? 演绎法
归纳法排错的基本思想
? 从特殊推断一般的系统化的思考方法。
先把和错误有关的数据组织起来进行分
析，以便发现可能的错误原因。即从一
些线索数据（错误征兆）着手，通过分
析它们之间的关系找出错误。
归纳法排错的分析步骤
? 收集线索数据
– 已知的测试用例、执行结果
? 组织数据
– 整理线索以便发现一些规律。
? 提出关于出错原因的假设
– 分析线索之间的关系，利用在线索结构中的矛盾现
象，提出假设。
? 证明假设
– 把假设与原始线索比较，若能完全解释一切现象，
则假设得到证明；否则，就认为假设不合理，或不
完全，或存在多个错误，只能消除部分。
演绎法排错的基本思想
? 从一般原理或前提出发，经过排除和精化的过程来推导出结论的思考方法。
? 首先根据已有的测试用例，设想及枚举
出所有可能出错的原因作为假设；然后
再用原始测试数据或新的测试，从中逐
个排除不可能正确的假设；最后，用测
试数据验证余下的假设确是出错的原因。
演绎法排错的分析步骤
? 收集线索数据：已知的测试用例、执行结果
? 组织数据：整理线索以便发现一些规律。
? 提出关于出错原因的假设：分析线索之间的
关系，利用在线索结构中的矛盾现象，提出
假设。
? 列举所有可能出错原因的假设,用已有数据
排除不正确的假设。
? 证明假设成立否。
软件可靠性 (Software Reliability)
? 见 WORD文档
? 软件可靠性 是指软件在规定的运行环境中
和规定的时间内无失效运行的概率 。 所以
它是时间 t的函数，我们用 R( t )来表示。
? 软件故障率 (failure rate)是指在单位时
间内软件发生故障的概率。
? 测试完成率, 已完成的测试用例占预先确定
的全部测试用例的百分比。
? 以测试完成率结合测试时间使用率为依据，
来估计软件开发的成功与否。
? 三个阶段, 曲线缓升 ； 曲线陡升 ； 曲线趋平
日立预测法 —测试完成率模型
日立预测法 —错误发现率模型
? 错误发现率：单位时间内发现的错误数
? 以错误发现率的变化，预测工程的前景。
错误发现率曲线在预定期限内的某一点
达到峰值，计算刚过峰值点以后错误发
现率曲线的导数（ -0.3到 0预示失败； -
0.3到 -1预示成功）
自动测试工具
? 测试数据生成程序
? 动态分析程序
? 静态分析程序
? 文件比较程序
