1. 软件测试工程师培训
软件测试方法论
1

2. 主要内容
 1 软件测试方法概述
 2 软件测试规范
 3 软件测试用例设计－黑盒测试
 4 软件测试用例设计－白盒测试
 5 小结
2

3. 1 软件测试方法概述
 1.1 软件测试活动及信息流
 1.2 测试方法
 1.3 生成测试用例的信息来源
 1.4 小结
3

4. 1.1 软件测试活动及信息流
 测试是从大量的测试用例中选择有限的测试用例发现
软件中的大部分缺陷的一种技术
 好的测试用例的 4 个特性：
1. 检测软件质量的有效性，是否能发现缺陷，或至少可
能发现缺陷；
2. 可仿效的测试用例可以测试很多内容，因而减少测试
用例的数量；
3. 经济性，测试用例的执行、分析和调试是否经济
4. 测试用例的可修改性，每次软件修改后对测试用例的
维护成本
4

5. 测试活动
标识 标志测试条件（确定测试什么）和测试的优先级
设计 设计测试用例（确定怎么测试）
开发 开发测试（设计脚本、数据等）
执行 执行测试用例
将测试结果与
比较 期望进行比较
5

6. 测试活动
 1 测试条件取决于被测试验证的项目或
事件。如等价划分、边界值分析、因果
图等。
测试条件是被测环境的描述，可以用多
种方式描述：如简单的语言，表格项形
式或类似于流图的图表形式；
标识测试条件的活动最好与开发活动
（即 V 模型左边的活动）并行开展
6

7. 测试活动
 2 设计测试用例
确定“怎样测试”。
测试用例（ test case ）是按一定顺序执行的
与测试目标（ test object, 测试理由或目的）
相关的一系列测试。测试用例设计将产生许多
测试所包括的输入值、期望结果及其他任何运
行测试的有关信息，如环境要求。
期望输出包括应输出或建立的内容，应修改或
更新或应删除的内容。期望输出集可以是一个
很大的集合。
7

8. 测试活动
测试用例：POS1036
一个测
先决条件：

作为数据输入员注册到定单系统显示的主菜单
试用例 数据库系统必须含有标准数据集合
确保系统中没有其他活跃的新定单活动
步骤 输入 期望输出 测试条件
1 建立用任何一个标准的 显示订单确认信息 VB10
订单项建立一个新订 VB20
单，设置订单数为 100
2 确认订单 打印具有正确细目购 VB10
置订单
3 打印新订单报表 打印的新订单报表就 VB10
是新创建的订单 VB23
4 取消订单 打印正确的取消购置 VB8
订单信息
5 打印新订单报表 无打印订单输出 VB8
8

9. 测试活动
 3 开发测试用例
包括准备测试脚本、测试输入、测试数据以及期望输出。
测试脚本（ test script ）是 具有正规语法的数据和指令的集合，
在测试执行自动工具使用中，通常以文件形式保存；
必须先完成测试用例的先决条件（ precondition ），然后再执行
测试。测试用例可能要求专门的硬件或软件，如网络环境或打印
机等；
期望输出可以组成成文件形式用于自动工具。对于手动测试，期
望输出仅仅只是简单地记录在手工测试过程或脚本中。设置用于
自动比较的期望输出比设置用于手工测试的期望输出复杂得多。
在自动工具中要求每项内容都要拼写正确，而在手工测试中要求
没这么严格。
测试开发的任何工作可以提前进行（相对 V 模型左边的活动进
行），以后可以节省时间。
9

10. 测试活动
 4 执行测试用例
对于手动测试来讲，测试者按事先准
备好的手工过程进行测试，测试者输入
数据、观察输出、记录发现的问题。
对于自动测试，可能只需要启动测试
工具，并告诉工具执行哪些测试用例；
测试执行只能在软件开发完成后进行
，即 V 模型右边的活动。
10

11. 测试活动
 5 将测试结果与期望输出进行比较
应该对每次测试的实际输出进行分析研究，判
断软件功能是否正确。
该验证可以是非正的测试者主观判断，也可以
是将实际输出与期望输出进行严格准确的比较。
一些信息比较，如可以在执行测试时进行显示
屏幕上的信息，另一些输出比较，如修改数据
库记录，只能在测试执行结束后进行。自动测
试一般结合了这两种方法。
11

12. 测试阶段的信息流
被测模块 设 软 系统 客
单元
计 件 其他 户
测试
信 需 元素 参
息 求 与
被测模块
单元 集成 确认 系统 验收
测试 测试 测试 测试 测试
被测模块 已经测 已 集 已 确 可 交
单元
试过的 成 的 认 的 付 的
测试
模块 软件 软件 软件
12

13. 测试阶段的信息流
测试阶段的输入信息有两类：
 软件配置：这是测试的对象，包括需求说明书、设计
说明书和被测的源程序等。
 测试配置：包括测试计划、测试步骤、测试用例（测
试数据），以及具体实施测试的测试程序、测试工具
等
13

14. 1.2 测试方法
 静态方法
 动态方法
 黑盒测试
 白盒测试
14

15. 静态方法和动态方法
 静态方法的主要特征是在用计算机测试源程序
时，计算机并不真正运行被测试的程序，只对
被测程序进行特性分析。因此，静态方法常称
为“分析”，静态分析是对被测程序进行特性分
析的一些方法的总称。
 动态方法的主要特征是计算机必须真正运行被
测试的程序，通过输入测试用例，对其运行情
况 ( 输入 / 输出的对应关系 ) 进行分析。
15

16. 黑盒测试
黑盒测试（ Black—box Testing ）又称功
能测试、数据驱动测试或基于规格说明的测试，
是一种从用户观点出发的测试。用这种方法进行
测试时，被测程序被当作一个黑盒，在不考虑程
序内部结构和内部特性，测试者只知道该程序输
入和输出之间的关系或程序的功能的情况下，依
靠能够反映这一关系和程序功能的需求规格说明
书考虑确定测试用例和推断测试结果的正确性。
软件的黑盒测试被用来证实软件功能的正确性和
可操作性。
16

17. 白盒测试
白盒测试（ White—box Testing ）又
称结构测试、逻辑驱动测试或基于程序的
测试。它依赖于对程序细节的严密检验，
针对特定条件和 / 与循环集设计测试用例
，对软件的逻辑路经进行测试。在程序的
不同点检验“程序的状态”以判定其实际情
况是否和预期的状态相一致。软件的白盒
测试用来分析程序的内部结构。
17

18. 白盒测试
 白盒测试要求对某些程序的结构特性做到一定程度的
覆盖，或者说是“基于覆盖的测试” 。最为常见的程序
结构覆盖有 ：
 语句覆盖：它要求被测程序的每一可执行语句在测试中尽可
能都检验过，这是最弱的逻辑覆盖准则；
 分支覆盖或判定覆盖：要求程序中所有判定的分支尽可能得
到检验；
 条件覆盖：当判定式中含有多个条件时，要求每个条件的取
值均得到检验；
 判定／条件覆盖：同时考虑条件的组合值及判定结果的检验
；
 路径覆盖：只考虑对程序路径的全面检验。
取得测试覆盖的方法——程序插装
18

19. 白盒测试
 既然黑盒测试是测试软件与需求的一致
性，为什么还要白盒测试？
 编程是容易发生逻辑错误和作出不正确的假
设
 如对执行路径假设不正确，会产生设计错误
，白盒测试能发现这样的错误
 录入错误是随机的
19

20. 黑盒测试与白盒测试的比较
黑盒测试 白盒测试
根据用户的规格说明，即针对命
令、信息、报表等用户界面及体 根据程序的内部结构，比如语句的
测试规划 现它们的输入数据与输出数据之 控制结构，模块间的控制结构以及
间的对应关系，特别是针对功能 内部数据结构等进行测试。
进行测试。
优点 能站在用户立场上进行测试。 能够对程序内部的特定部位进行覆
特 盖测试。
点 • 不能测试程序内部特定部位。 • 无法检验程序的外部特性。
缺点 • 如果规格说明有误，则无法发现 • 无法对未实现规格说明的程序内
。 部欠缺部分进行测试。
语句覆盖
基于图的测试 判定覆盖
等价类划分
方法举例 边值分析
条件覆盖
判定 / 条件覆盖
比较测试 基本路径覆盖
循环覆盖
模块接口测试
20

21. 测试阶段与测试方法
测试阶段 目的 执行者 测试方法
单元测试 查找独立模块中逻辑错误、 软件工程师 白盒测试
数据错误和算法错误
集成测试 查找模块之间接口错误 软件工程师 白盒测试、自顶向
测试人员 下或自底向上
确认测试 确认软件是否满足软件需求 测试人员 黑盒测试
模拟用户操作
系统测试 对系统中各个组成部分进行 测试人员 黑盒测试
综合性检验 模拟用户操作
回归测试 确认软件变更后是否仍满足 测试人员 黑盒测试
软件需求 模拟用户操作
α 测试与 β 用户 黑盒测试
测试 模拟用户操作
验收测试 确认软件是否满足用户需求 用户、项目组 黑盒测试
测试人员 模拟用户操作
21

22. 1.3 测试信息来源
 基于软件规约生成测试用例
 基于软件设计生成测试用例
 基于程序生存测试用例
22

23. 1.4 小结
 软件测试主要工作就是确定合适的测试
用例；
 测试过程贯穿在整个软件开发活动中；
 测试方法： 动态、静态、黑盒、白盒等
23

24. 2 软件测试用例设计－黑盒测试
 2.0 概述
 2.1 等价类划分
 2.2 因果图
 2.3 边值分析
 2.4 判定表驱动测试
 2.5 正交实验设计法
 2.6 自动测试用例生成方法
 2.7 小结
24

25. 2.0 概述
 这种方法是把测试对象看做一个黑
测试对象
盒子，测试人员完全不考虑程序内
盒子
部的逻辑结构和内部特性，只依据
程序的需求规格说明书，检查程序
的功能是否符合它的功能说明。
 黑盒测试又叫做功能测试或数据驱
功能测试
动测试。
动测试
25

26. 黑盒测试目标
 黑盒测试方法是在程序接口上进行
测试，主要是为了发现以下错误 :
 是否有不正确或遗漏了的功能 ?
 在接口上，输入能否正确地接受 ?
能否输出正确的结果 ?
 是否有数据结构错误或外部信息
( 例如数据文件 ) 访问错误 ?
 性能上是否能够满足要求 ?
 是否有初始化或终止性错误 ?
26

27.  用黑盒测试发现程序中的错误
，必须在所有可能的输入条件
和输出条件中确定测试数据，
和输出条件
来检查程序是否都能产生正确
的输出。
 但这是不可能的。
不可能
27

28.  假设一个程序 P 有输入量 X 和 Y 及输出量
Z 。在字长为 32 位的计算机上运行。若 X 、
Y 取整数，按黑盒方法进行穷举测试：
 可能采用的
测试数据组：
2 32 × 2 32
＝ 2 64
 如果测试一
组数据需要 1 毫秒，一年工作 365 × 24 小时
，完成所有测试需 5 亿年。
28

29. 2.1 测试用例设计方法－等价
类划分
 选取测试用例
 等价类划分的办法是把程序的输入域划
分成若干部分，然后从每个部分中选取
少数代表性数据当作测试用例。
 在分析需求规格说明的基础上划分等价
类，列出等价类表。
29

30. 2.1.1 等价类
 所谓等价类是指某个输入域的集合。它
表示，如果用集合中的一个输入条件作
为测试数据进行测试不能发现程序中的
错误，那么使用集合中的其它输入条件
进行测试也不可能发现错误。也就是说
，对揭露程序中的错误来说，集合中的
每个输入条件是等效的。
30

31. 有效等价类和无效等价类
 在考虑等价类时，应该注意区别两种不同的情
况：
 * 有效等价类：有效等价类指的是对程序的规
格说明是有意义的、合理的输入数据所构成的
集合。在具体问题中，有效等价类可以有一个
，也可以是多个。
 * 无效等价类：无效等价类指对程序的规格说
明是不合理的或无意义的输入数据所构成的集
合。对于具体的问题，无效等价类至少应有一
个，也可能有多个。
31

32. 等价类
 输入条件 有效等价类 无效等价类
 输入条件：…项数可以从 1 到 999…
 有效等价类为“ 1 〈项数〈 999”
 无效等价类为“项数 <1” 及“项数 >999”
32

33. 有效等价类 号 无效等价类 号码
2.1.2 经典例
型 码
a 为非整数 12
一边为非整数 b 为非整数 13
输 c 为非整数 14
输 整数 1 15
a,b 为非整数
子
16
入 两边为非整数 b,c 为非整数
a,c 为非整数 17
18
三边 a，b，c 均为非整数
入 三 只给 a 19
只给一边 只给 b 20
只给 c 21
个 三个数 2 22
只给 ab
“ 输入三个整数
条 23
只给两边 只给 b,c
 只给 ac
24
整 25
给出三个以上
作为三边的边长
件
a为0 26
一边为零 b为0 27
数
构成三角形。当
c为0 28
非零数 3 29
a,b 为 0
b,c 为 0 30
二边为零
此三角形为一般
31
a,c 为 0
32
三边 a,b,c 均为 0
a<0 33
三角形、等腰三 一边< 0 b<0
c<0
34
35
角形及等边三角
正数 a<0 且 b<0 36
4 37
二边<0 a<0 且 c<0
38
b<0 且 c<0
形时，分别做计
39
三边均<0：a<0 且 b<0 且 c<0
a+b>c 5 a+b<0 40
算…”
输 a+b=0 41
构成一般 b+c>a 6 b+c<a 42
出 三角形 b+c=a 43
7 44
a+c>b
注意输入和输出
a+c<b
条 45
 8
a+c=b
a=b
件
条件
构成等腰 b=c 且两边 9
三角形 10
之和
a=c 大 于第
三边
构成等腰 a=b=c 11
三角形
表 4.1
33
例 1 的等价类型表

34. 有效等价类
 覆盖有效等价类的测试用例：
 a b c 覆盖等价类号码
 3 4 5 （ 1 ） -- （ 7 ）
 4 4 5 （ 1 ） -- （ 7 ），（ 8 ）
 4 5 5 （ 1 ） -- （ 7 ），（ 9 ）
 5 4 5 （ 1 ） -- （ 7 ），
（ 10 ）
 4 4 4 （ 1 ） -- （ 7 ），
（ 11 ） 34

35. 无效等价类
35

36. 2. 1.3 问题讨论
 问题：给出下面的有效和无效等价类
 输入条件：“…统计全国各省、市、自治
区的人口…”
 输入条件：“标识符应以字母开头…”
 输入条件：长度为 1-20 的字符串
 输入条件：数据库中的值域 , CHAR(20),
NOT NULL
36

37. 2. 2 测试方法－因果图
 采用因果图方法（ Cause 一 Effect
Graphics ）能够帮助我们按一定步骤，
高效率地选择测试用例，同时还能为我
们指出，程序规格说明描述中存在着什
么问题。
37

38. 2. 2.1 因果图介绍
 4 种符号分别表示了规格
说明中向 4 种因果关系
 因果图中使用了简单的逻
辑符号，以直线联接左右 C1 e1 C1 e1
结点。左结点表示输入状
态（或称原因），右结点 （a）恒等 ( b) 非
表示输出状态（或称结 C1
果）。
C1
V A
 Ci 表示原因，通常置于图 C2 e1 e1
的左部； ei 表示结果，通 C2
常在图的右部。 ci 和 ei C3
均可取值 0 或 1 ， 0 表示 （c）或 (d)与
某状态不出现， 1 表示某 图 4.1 因果图的基本符号
状态出现。
38

39. 关系
 ① 恒等：若 ci 是 1 ，则 ei 也是 1 ；否则
ei 为 0 。
 ② 非：若 ci 是 1 ，则 ei 是 0 ；否则 ei
是1。
 ③ 或：若 c1 或 c2 或 c3 是 1 ，则 ei 是
1 ；否则 ei 为 0 。“或”可有任意个输入。
 ④ 与：若 c1 和 c2 都是 1 ，则 ei 为 1 ；
否则 ei 为 0 。“与”也可有任意个输入。
39

40. 约束
 输入状态相互之
间还可能存在某
些依赖关系
 某些输入条件本
身不可能同时出
现。输出状态之
间也往往存在约
束
40

41. 输入条件约束类型
 对于输入条件的约束有以下 4 类：
 ① E 约束（异）： a 和 b 中至多有一个可能为
1 ，即 a 和 b 不能同时为 1 。
 ② I 约束（或）： a 、 b 和 c 中至少有一个必
须是 1 ，即 a 、 b 和 c 不能同时为 0 。
 ③ O 约束（唯一）； a 和 b 必须有一个，且仅
有 1 个为 1 。
 ④R 约束（要求）： a 是 1 时， b 必须是 1 ，
即不可能 a 是 1 时 b 是 0 。
41

42. 输出条件约束类型
 输出条件的约束只有：
 M 约束（强制）：若结果 a 是 1 ，则结
果 b 强制为 0 。
42

43. 2. 2.2 步骤
 ① 分析程序规格说明的描述中，哪些是原
因，哪些是结果。原因常常是输入条件或是
输入条件的等价类。而结果是输出条件。
 ② 分析程序规格说明的描述中语义的内容，
并将其表示成连接各个原因与各个结果的“因
果图”。
43

44. 步骤
 ③ 由于语法或环境的限制，有些原因和
结果的组合情况是不可能出现的。为表
明这些特定的情况，在因果图上使用若
干个特殊的符号标明约束条件。
 ④ 把因果图转换成判定表。
 ⑤ 把判定表中每一列表示的情况写成测试用例
。
44

45. 2. 2.3 例子
 软件规格说明书
 “ 第一列字符必须是 A 或 B ，第二列字
符必须是一个数字，在此情况下进行文
件的修改。但如果第一列字符不正确，
则给出信息 L ，如果第二列字符不是数
字，则给出信息 M 。”
45

46. 原因和结果
 原因：
 1—— 第一列字符是 A ；
 2—— 第一列字符是 B ；
 3—— 第二列字符是一数字。
 结果：
 21—— 修改文件；
 22 —— 给出信息 L ；
 23—— 给出信息 M 。
46

47. 因果图和具有约束的因果图
 11 为中间节点；
 考虑到原因 1 和原因 2 不可能同时为 1 ，因此
在因果图上施加 E 约束。
47

48. 判定表
 根据因果图建立如下的判定表
1 2 3 4 5 6 7 8
1 1 1 1 1 0 0 0 0
条 2 1 1 0 0 1 1 0 0
件 3 1 0 1 0 1 0 1 0 原
11 ////// ////// 1 1 1 1 0 0 因
动 22 // // 0 0 0 0 1 1
作 21 // // 1 0 1 0 0 0 结
23 // // 0 1 0 1 0 1 果
测试 // // A3 AM B5 BN C2 DY
用例 ////// ////// A8 A？ B4 B！ X6 P；
表中 8 种情况的左面两列情况中，原因①和原因②同时为 1 ，这是不可
能出现的，故应排除这两种情况。表的最下一栏给出了 6 种情况的测试
用例，这是我们所需要的数据。
48

49. 2. 2.4 讨论
 在较为复杂的问题中，这个方法常常是
十分有效的，它能有力地帮助我们确定
测试用例
 如果哪个开发项目在设计阶段就采用了
判定表，也就不必再画因果图，而是可
以直接利用判定表设计测试用例了。
49

50. 2. 3 测试用例设计方法－边值
分析
 在软件设计和程序编写中，常常对于规
格说明中的输入域边界或输出域边界不
够注意，以致形成一些差错。实践证明
，在设计测试用例时，对边界附近的处
理必须给予足够的重视，为检验边界附
近的处理专门设计测试用例，常常取得
良好的测试效果。
50

51. 2. 2.1 边值分析遵循的原则
 ① 如果输入条件规定了取值范围，或是规定
了值的个数，应以该范围的边界内及刚刚超出
范围的边界外的值，或是分别对最大、最小个
数及稍小于最小、稍大于最大个数作为测试用
例。例如，如果程序的规格说明中规定：“重
量在 10 公斤至 50 公斤范围内的邮件，其邮
费计算公式为……”。作为测试用例，我们应
取 10 及 50 ， 还 应 取 10.01,49.99,9.99 及
50.01 等。如果另一问题规格说明规定：“某输
入文件可包含 1 至 255 个记录，……”，则测
试用例可取 1 和 255 ，还应取 0 及 256 等。
51

52. 遵循以下几条原则
 ② 针对规格说明的每个输出条件使用前
面的第（ 1 ）条原则。例如，某程序的
规格说明要求计算出“每月保险金扣除额
为 0 至 1165 ． 25 元”，其测试用例可取
0 ． 00 及 1165 ． 2 、还可取一 0 ． 01
及 1165 ． 26 等。如果另一程序属于情
报检索系统，要求每次”最多显示 1 条情
报摘要”，这时我们应考虑的测试用例包
括 1 和 4 ，还应包括 0 和 5 等。
52

53. 遵循以下几条原则
 ③ 如果程序规格说明中提到的输入或输
出域是个有序的集合（如顺序文件、表
格等），就应注意选取有序集的第一个
和最后一个元素作为测试用例。
 ④ 分析规格说明，找出其它的可能边界
条件。
53

54. 2. 2.2 例子
 某一为学生考试试卷评分和成绩统计的程序，其规格说明指出了对程序的要求：
 程序的输入文件由 80 个字符的一些记录组成，这些记录分为三组：
 ① 标题
 这一组只有一个记录，其内容为输出报告的名字。
 ② 试卷各题标准答案记录
 每个记录均在第 80 个字符处标以数字“ 2” 。该组的第一个记录的第 1 至第 3 个
字符为题目编号（取值为 1 一 999 ）。第 10 至第 59 个字符给出第 1 至第 50 题
的答案（每个合法字符表示一个答案）。该组的第 2 ，第 3…… 个记录相应为第
51 至第 100 ，第 101 至第 150 ，…题的答案。
 ③ 每个学生的答卷描述
 该组中每个记录的第 80 个字符均为数字“ 3” 。每个学生的答卷在若干个记录中
给出。如甲的首记录第 1 至第 9 字符给出学生姓名及学号，第 10 至第 59 字符列
出的是甲所做的第 1 至第 50 题的答案。若试题数超过 50 ，则第 2 ，第 3…… 纪
录分别给出他的第 51 至第 100 ，第 101 至第 150…… 题的解答。然后是学生乙
的答卷记录。
若学生最多为 200 人，输入数据的形式如图 4 。 15 所示。
54

55.  学生考卷
评分和成
绩统计程
序输入数
据的形式
55

56.  该程序应给出 4 个输出报告，即：
 ① 按学生学号排序，每个学生的成绩
（答对的百分比）和等级报告。
 ② 按学生得分排序，每个学生的成绩
。
 ③ 平均分数，最高与最低分之差。
 ④ 按题号排序，每题学生答对的百分
比。 56

57. 输入条件 测试用例
输入文件 空输入文件 输出条件 测试用例
标题 无标题记录 学生得分 所有学生得分相同
只有 1 个字符的标题 所有学生得分不同
具有 80 个字符的标题 一些学生（不是全部）得分相同（用以计算等级）
出题个数 除了 1 个题 1 个学生得 0 分
除了 50 个题 1 个学生得 100 分
除了 51 个题 1 个学生编号最小（检查排序）
输出报告
除了 100 个题 (1),(2) 1 个学生编号最大
除了 999 个题
没有出题 学生数恰好使报告印满一页（检查打印）
题目是非数值量 学生数使报告 1 页打印不够，恰好多 1 人
答案记录 标题记录后没有标准答案记录 输出报告（3） 平均值取最大值（所有学生都得满分）
标准答案记录多 1 个 平均值为 0（所有学生都得 0 分）
标准答案记录少 1 个 标准偏差取最大值（1 学生得 0 分，1 学生得 100 分）
学生人数 学生人数为 0 标准偏差相同（所有学生得分相同）
学生人数为 1 输出报告(4) 所有学生都答对第 1 题
学生人数为 200 所有学生都答错第 1 题
学生人数为 201 所有学生都答对最后 1 题
学生答题 某学生只有 1 个答卷记录，但有两个标准答案记录 所有学生都答错最后 1 题
该学生是文件中的第 1 个学生 题数恰好使报告打印在 1 页上
该学生是文件中的最后 1 个学生
报告打印完 1 页后，恰剩 1 题未打
学生答题 某学生有 2 个答卷记录，但只有 1 个标准答案记录
该学生是文件中的第 1 个学生
该学生是文件中的最后 1 个学生
57

58. 2. 4 判定表驱动测试
 在一些数据处理问题中，某些操作是否
实施依赖于多个逻辑条件的取值。也即
在这些逻辑条件取值的组合所构成的多
种情况下，分别执行不同的操作。处理
这类问题的一个非常有力的分析和表达
工具是判定表（ Decision Table ）。
58

59. 2. 3.1 例子 1
 一张关于科技书阅读指南的判定驱动
表： 3 个问题 8 种情况
1 2 3 4 5 6 7 8
问 你觉得疲倦吗？ Y Y Y Y N N N N
题 你对内容感兴趣吗？ Y Y N N Y Y N N
书中内容使你胡涂吗？ Y N Y N Y N Y N
请回到本章开头重读 x x
建 继续读下去 x x
议 跳到下一章去读 x x
停止阅读，请休息 x x
”读书指南”判定表
59

60. 判定表组成
 条件桩（ Condition Stub ）
 动作桩（ Action Stub ）
 条件项（ Condition Entity ）
 动作项（ Action Entity ）
60

61. 规则及规则合并
 任何一个条件组合的特定取值及其相应要执
行的操作称为规则。在判定表中贯穿条件项
和动作项的一列就是一条规则。显然，判定
表中列出多少组条件取值，也就有多少条规
则，即条件项和动作项有多少列。
 化简 就是规则合并
有两条或多条规则
具有相同的动作，
并且其条件项之间
存在着极为相似的关系
两条规则合并成一条 两条规则的进一步合并
61

62. 一个规则合并的例子
 一个规则合并的例子
1 2 3 4
问 你觉得疲倦吗？ - - Y N
题 你对内容感兴趣吗？ Y Y N N
书中内容使你胡涂吗？ Y N - -
请回到本章开头重读 x
建 继续读下去 X
议 跳到下一章去读 x
停止阅读，请休息 x
化减后的”读书指南”判定表
62

63. 2. 3.2 例子 2
 问题要求：”……对功率大于 50 马力的
机器、维修记录不全或已运行 10 年以上
的机器，应给予优先的维修处理……”
 假定，“维修记录不全”和“优先维修处理”
均已在别处有更严格的定义
 按 5 步建立判定表
63

64. 建立判定表的步骤
 ① 确定规则的个数。这里有 3 个条件，每个条
件有两个取值，故应有 2*2*2=8 种规则。
 ② 列出所有的条件茬和动作茬。
 ③ 填人条件项。为防止遗漏可从最后 1 行条件
项开始，逐行向上填满乙如第三行是：
YNYNYNYN
第二行是：
YYNNYYNN
等等。
64

65. 建立判定表的步骤
 ④ 填人动作桩和动作顶。这样便得到
形如图的初始判定表。
1 2 3 4 5 6 7 8
条 功率大于 50 马力吗？ Y Y Y Y N N N N
件 维修记录不全吗？ Y Y N N Y Y N N
运行超过 10 年吗？ Y N Y N Y N Y N
动 进行优先处理 x x X X X
作 作其他处理 X x x
初始判定表
65

66. 建立判定表的步骤
 ⑤ 化简。合并相似规则后得到图。
1 2 3 4 5
条 功率大于 50 马力吗？ Y Y Y N N
件 维修记录不全吗？ Y N N - -
运行超过 10 年吗？ - Y N Y N
动 进行优先处理 x x X
作 作其他处理 x x
化减后的判定表
66

67. 2. 3.3 判定表在功能测试中的
应用
 一软件规格说明
 (1) 当条件 1 和条件 2 满足，并且条件 3
和条件 4 不满足，或者当条件 1 、 3 和
条件 4 满足时，要执行操作 1 。
 (2) 在任一个条件都不满足时，要执行操
作2。
 (3) 在条件 1 不满足，而条件 4 被满足时
，要执行操作 3 。
67

68. 规则
 只给出了 16 种规则中的 4 种
规则 1 规则 1 规则 1 规则 1 规则 5 规则 6 规则 7 规则 8
条件 1 Y Y N N
条件 1 - N Y Y
条件 2 Y - N -
条件 2 - Y Y N
条件 3 N Y N -
N Y N Y 条件 3 Y N N N
条件 4
操作 1 x x 条件 4 N N Y -
操作 2 x 默许操作 x x x x
操作 3 x
默许的规则
根据规则说明得到的判定表
根据规格说明得到的判定表 默许的规则
68

69. 2.3.4 判定表的优点和缺点
 优点：
它能把复杂的问题按各种可能的情况一
一列举出来，简明而易于理解，也可避
免遗漏。
 缺点：
不能表达重复执行的动作，例如循环结
构。
其他？？
69

70. 使用判定表设计测试用例的
Beizer 条件
 ① 规格说明以判定表形式给出，或是很容易转换成
判定表。
 ② 条件的排列顺序不会也不应影响执行哪些操作。
 ③ 规则的排列顺序不会也不应影响执行哪些操作。
 ④ 每当某一规则的条件已经满足，并确定要执行的
操作后，不必检验别的规则。
 ⑤ 如果某一规则得到满足要执行多个操作，这些操
作的执行顺序无关紧要。
 B 。 Beizer 提出这 5 个必要条件的目的是为了使操
作的执行完全依赖于条件的组合。其实对于某些不满
足这几条的判定表，同样可以借以设计测试用例，只
不过尚需增加其它的测试用例罢了。
70

71. 2.5 正交实验设计法
 把软件功能测试作为实验的一种，从大量的实
验点中选出适量有代表性的点，应用依据伽罗
瓦理论导出的“正交表”，合理安排实验的一种
科学的实验设计方法。
 从规约中找出影响其功能实现的操作对象和外
部因素作为因子，因子的取值作为状态，构造
因素分析表，利用正交表进行各因子的专题组
合，构造有效的测试数据集，并由此建立因果
图。
71

72. 2.6 自动测试用例设计
 一些测试工具可以进行部分测试用例自动化，
“测试输入生成工具”，该方法也可以用于某些
场合，但自动工具不可能完全替代智力的测试
活动；
 自动方式可以生成大量的测试用例，但他不区
分哪些测试是最重要的。这些要求有创造力的
智力活动只能由测试人员完成。
 所有测试生成工具依赖于生成测试的算法，工
具比使用相同算法的测试人员的测试更彻底、
更精确，但人工测试时可以考虑附加测试。
72

73. 三种测试输入生成工具
 基于代码测试输入生成
 基于界面测试生成
 基于规格说明测试生成
73

74. 基于代码测试输入生成
 通过检测软件代码结构生成测试输入。
通过代码的路径由判断点确定的段组成。
自动生成每个路径段逻辑覆盖条件的轮 规格说明 期望输出
廓文件。与覆盖工具一起使用较好。
 只产生测试输入，还需要对测试输出进
行比较，不能判断软件产生的输出是否
测试输入 代码 测试输出
正确，只是说明代码应该做什么。也不
能发现丢失的代码
 另一种方法：可以生成满足较小变化测
试准则的测试。变化测试（ Mutation
test ）是指代码或输入做较小的改变，
检测系统是否可以正确地处理或测试稍
微改变的版本。该方法可以检查系统的
容错能力和测试套件的充分性。
74

75. 基于界面测试生成
 用于某些定义好的界面如 GUI 或 Web
应用生成测试。如果屏幕含有各种菜规格说明 期望输出
单、按钮及检查框，则工具生成访问
每个控件的测试事例。
 还可以测试 Internet 和 Intranet 页面。
测试输入 代码 测试输出
工具可激活 WWW 页面的每个链接，
然后对每页做相同的测试；该方法对
于发现某类缺陷是有效的，可以部分
生成期望输出，即连接存在或断开状
况，但不能判断连接是否在正确的位
置；
 该方法可以执行部分测试事例设计活
动，产生测试输出，对于检测“ roll-
call” 即某个东西确实在某处确实有用。 75

76. 基于规格说明测试生成
 在规格说明形式化并可被工具分析的前
规格说明 期望输出
提下，基于规格说明测试工具可以生成
测试输入及期望结果；如果面向对象规
格说明足够严格的话，这种工具还可以
进行面向对象规格说明的测试。 测试输入 代码 测试输出
 例如，如果一个输入域的允许范围被严
格定义，那么工具可以产生边界值以及
有效等价类和无效等价类的样值。
 某些基于规格说明的工具可以进行结构
化的英文规格说明或因果图的测试，可
以发现一些规格说明的缺陷，如规格说
明含混或冗长
 好处是检查软件应该做什么，而不是软
件做了什么。
 从规格说明中推导测试用例越枯燥，则
这类工具的潜力就越大。 76

77. 自动测试用例生成的优点
 自动化测试用例生成用于设计的繁琐部
分，如激活每个菜单项或者从已知的数
据范围计算边界值；
 可以生成针对源程序的一套完成的测试
用例（代码、界面和规格说明）
 可以发现某种类型的缺陷，如丢失连接
，非工作窗口项或者不符合规格说明的
软件；
77

78. 自动测试用例生成的限制
 基于代码方法不能生成期望输出
 基于界面方法只能产生部分期望输出
 基于代码和基于界面方法不能发现规格说明的
缺陷；
 基于规格说明的方法依赖于规格说明的质量；
 所有的方法可以产生大量的测试，而实际操作
起来比较困难；
 测试前仍需要专家判断产生的测试的必要性，
并考虑任何工具都无法产生的测试；
78

79. 2.7 小结
 理解和熟练使用 4 种进行测试用例设计
的方法：等价类划分、因果图、边值分
析、判定表驱动；
 自动测试用例设计的原理和方法，
79

80. 4 、 软件测试用例设计－白盒测
试
 3.0 概述
 3.1 程序结构分析
 3.2 逻辑覆盖
 3.3 路径分析
 3.4 域测试
 3.5 程序插装
 3.6 程序变异
 3.7 小结
80

81. 3.0 概述
 此方法把测试对象看做一个透明的
盒子，它允许测试人员利用程序内
盒子
部的逻辑结构及有关信息，设计或
选择测试用例，对程序所有逻辑路
径进行测试。
 通过在不同点检查程序的状态，确
定实际的状态是否与预期的状态一
致。因此白盒测试又称为结构测试
或逻辑驱动测试。 81

82.  软件人员使用白盒测试方法，主要想对程序
模块进行如下的检查：
 对程序模块的所有独立的执行路径至少测
所有独立的执行路径
试一次；
 对所有的逻辑判定，取“真”与取“假”的两种
所有的逻辑判定
情况都至少测试一次；
情况都至少测试一次
 在循环的边界和运行界限内执行循环体；
 测试内部数据结构的有效性，等。
内部数据结构的有效性
82

83.  对一个具有多重选择和循环嵌套的
多重选择和循环嵌套
程序，不同的路径数目可能是天文
数字。给出一个小程序的流程图，
数字
它包括了一个执行 20 次的循环。
 包含的不同执行路径数达 5 20 条，
对每一条路径进行测试需要 1 毫秒
，假定一年工作 365 × 24 小时，
要想把所有路径测试完，需 3170
年。 83

84. 84

85. 3.1 程序结构分析－基本路径测
试
 基本路径测试方法把覆盖的路径数压缩
到一定限度内，程序中的循环体最多只
执行一次。
执行一次
 它是在程序控制流图的基础上，分析控
制构造的环路复杂性，导出基本可执行
制构造的环路复杂性
路径集合，设计测试用例的方法。设计
路径集合 设计测试用例的
出的测试用例要保证在测试中，程序的
每一个可执行语句至少要执行一次。
85

86. 3.1.1. 程序的控制流图
 符号○为控制流图的一个结点，表
示一个或多个无分支的 PDL 语句
或源程序语句。箭头为边，表示控
制流的方向。
86

87.  在选择或多分支结构中，分支的汇聚处
应有一个汇聚结点。
 边和结点圈定的区域叫做区域，当对区
域计数时，图形外的区域也应记为一个
区域。
 如果判断中的条件表达式是由一个或多
个逻辑运算符 (OR, AND, NAND,
NOR) 连接的复合条件表达式，则需
要改为一系列只有单条件的嵌套的判断
。 87

88. 88

89. 89

90. 3.1.2. 程序环路复杂性
 程序的环路复杂性给出了程序基本
路径集中的独立路径条数，这是确
路径集中的独立路径条数
保程序中每个可执行语句至少执行
一次所必需的测试用例数目的上界
。
 从控制流图来看，一条独立路径是
至少包含有一条在其它独立路径中
从未有过的边的路径。 90

91.  例如，在图示的控制流图中，一组独立
的路径是
path1 ： 1 - 11
path2 ： 1 - 2 - 3 - 4 - 5 - 10 - 1 -
11
path3 ： 1 - 2 - 3 - 6 - 8 - 9 - 10 -
1 - 11
path4 ： 1 - 2 - 3 - 6 - 7 - 9 - 10 -
1 - 11
 路径 path1 ， path2 ， path3 ， path4
组成了控制流图的一个基本路径集。 91

92. 3.1.2. 导出测试用例
 导出测试用例，确保基本路径
集中的每一条路径的执行。
集中的每一条路径的执行
 根据判断结点给出的条件，选
择适当的数据以保证某一条路
径可以被测试到 — 用逻辑覆盖
方法。
方法
92

93.  每个测试用例执行之后，与预期结果进
测试用例执行之后
行比较。如果所有测试用例都执行完毕
行比较
，则可以确信程序中所有的可执行语句
至少被执行了一次。
 必须注意，一些独立的路径 ( 如例中的
路径 1) ，往往不是完全孤立的，有时它
是程序正常的控制流的一部分，这时，
这些路径的测试可以是另一条路径测试
的一部分。
93

94. 3.2 逻辑覆盖
逻辑覆盖是以程序内部的逻辑结构为
基础的设计测试用例的技术。它属白
基础
盒测试。
 语句覆盖  判定－条件覆盖
  条件组合覆盖
判定覆盖  路径覆盖。
路径覆盖

94

95. 95

96. L1(a → c → e)
= { ( A > 1) and ( B = 0) } and { ( A = 2) or ( X A > 1) }
= ( A > 1) and ( B = 0) and ( A = 2) or
( A > 1) and ( B = 0) and ( X A > 1)
= ( A = 2) and ( B = 0) or
( A > 1) and ( B = 0) and ( X A > 1)
96

97. L2 (a → b → d)
= { ( A > 1) and ( B = 0) } and { ( A = 2) or ( X > 1) }
{ } {
= ( A > 1) or ( B = 0) and ( A = 2) and ( X > 1) }
= ( A > 1) and ( A = 2) and ( X > 1) or
( B = 0) and ( A = 2) and ( X > 1)
= ( A ≤ 1) and ( X ≤ 1) or
( B ≠ 0) and ( A ≠ 2) and ( X ≤ 1)
97

98. L3 (a → b → c)
= { ( A > 1) and ( B = 0) } and { ( A = 2) or ( X > 1) }
{ }
= ( A > 1) or ( B = 0) and { ( A = 2) or ( X > 1) }
= ( A > 1) and ( X > 1) or
( B = 0) and ( A = 2) or ( B = 0) and ( X > 1)
= ( A ≤ 1) and ( X > 1) or
( B ≠ 0) and ( A = 2) or ( B ≠ 0) and ( X > 1)
98

99. L4 (a → c → d)
= { ( A > 1) and ( B = 0) } and { ( A = 2) or ( X A > 1) }
= ( A > 1) and ( B = 0) and ( A ≠ 2) and ( X A ≤ 1)
99

100. 3.2.1 语句覆盖
 语句覆盖就是设计若干个测试用例
，运行被测程序，使得每一可执行
语句至少执行一次。
语句至少执行一次
 在图例中，正好所有的可执行语句
都在路径 L1 上，所以选择路径 L1
设计测试用例，就可以覆盖所有的
可执行语句。
100

101.  测试用例的设计格式如下
【输入的 (A, B, X) ，输出的 (A, B, X) 】
 为图例设计满足语句覆盖的测试用例是 :
语句覆盖
【 (2, 0, 4) ， (2, 0, 3) 】
覆盖 ace 【 L1 】
( A = 2) and ( B = 0) or
( A > 1) and ( B = 0) and ( X A > 1)
101

102. 3.2.2 判定覆盖
 判定覆盖就是设计若干个测试用
例，运行被测程序，使得程序中
每个判断的取真分支和取假分支
至少经历一次。
至少经历一次
 判定覆盖又称为分支覆盖。
分支覆盖
 对于图例，如果选择路径 L1 和
L2 ，就可得满足要求的测试用例
:
102

103. 【 (2, 0, 4) ， (2, 0, 3) 】覆盖
ace 【 L1 】
【 (1, 1, 1) ， (1, 1, 1) 】覆盖
( ) (
Aabd2【and】B = 0 or
= L2 )
( A > 1) and ( B = 0) and ( X A > 1)
( A ≤ 1) and ( X ≤ 1) or
( B ≠ 0) and ( A ≠ 2) and103X ≤ 1)
(

104.  如果选择路径 L3 和 L4 ，还可得另一组可用的测试用
例:
【 (2, 1, 1) ， (2, 1, 2) 】覆盖 abe 【 L3 】
【 (3, 0, 3) ， (3, 1, 1) 】覆盖 acd 【 L4 】
( A ≤ 1) and ( X > 1) or ( B ≠ 0) and
( A = 2) or ( B ≠ 0) and ( X > 1)
( A > 1) and ( B = 0) and ( A ≠ 2) and
(104 A ≤ 1)
X

105. 3.2.3 条件覆盖
 条件覆盖就是设计若干个测试用例，
运行被测程序，使得程序中每个判断
的每个条件的可能取值至少执行一次
。
 在图例中，我们事先可对所有条件的
取值加以标记。例如，
 对于第一个判断：
T1 T1
T2 T2
 条件 A ＞ 1 取真为 ，取假为
条件 B ＝ 0 取真为 ，取假为
105

106.  对于第二个判断：

T
条件 A ＝ 2 取真为 3 ，取假为 T3
条件 X ＞ 1 取真为 ，取假为
T4
T4
测试用例 覆盖分支 条件取值
【 (2, 0, 4) ， (2, 0, 3) 】 L1(c,T1T2T3T4
e)
【 (1, 0, 1) ， (1, 0, 1) 】 L2(b, T1T2 T3T4
d)
【 (2, 1, 1) ， (2, 1, 2) 】 L3(b, T1T2T3T4
e)
106

107. 或
测 试 用 例覆盖分支 条件取值
【 (1, 0, 3) ， (1, 0, 4) 】 L3(b, e)1T2 T3T4
T
【 (2, 1, 1) ， (2, 1, 2) 】 L3(b, e) 1T2T3T4
T
107

108. 3.2.4 判定－条件覆盖
 判定－条件覆盖就是设计足够的测
试用例，使得判断中每个条件的所
有可能取值至少执行一次，同时每
有可能取值至少执行一次
个判断中的每个条件的可能取值至
少执行一次。
少执行一次
108

109. 测试用例 覆盖分支 条件取值
【 (2, 0, 4) ， (2, 0, 3) 】 L1(c, T1T2T3T4
e)
【 (1, 1, 1) ， (1, 1, 1) 】 L2(b, T1T2 T3T4
d)
( A = 2) and ( B = 0) or
( A > 1) and ( B = 0) and ( X A > 1)
( A ≤ 1) and ( X ≤ 1) or
( B ≠ 0) and ( A ≠ 2) and ( X ≤ 1)
109

110. 110

111. 3.2.5 条件组合覆盖
 条件组合覆盖就是设计足够的测试用
例，运行被测程序，使得每个判断的
所有可能的条件取值组合至少执行一
次。
记 ① A ＞ 1, B ＝ 0 作1T2
T
② A ＞ 1, B≠0 作 T1T2
③ A≯1, B ＝ 0 作 T1T2
④ A≯1, B≠0 作 T1T2
111

112. ⑤ A ＝ 2, X ＞ 1 作3T4
T
⑥ A ＝ 2, X≯1 作 3T4
T
⑦ A≠2, X ＞ 1 作 3T4
T
⑧ A≠2, X≯1 作 T3T4
112

113. 测试用例 覆盖条件 覆盖组合
【 (2, 0, 4), (2, 0, 3) 】 (L1) 1T2T3T4
T
①, ⑤
【 (2, 1, 1), (2, 1, 2) 】 (L3)
②, ⑥
T1T2T3T4
【 (1, 0, 3), (1, 0, 4) 】 (L3) 1T2 T3T4
T
③, ⑦
【 (1, 1, 1), (1, 1, 1) 】 (L2) 1T2 T3T4
T
④, ⑧
113

114. 3.3 路径测试
 路径测试就是设计足够的测试用例，覆
盖程序中所有可能的路径。
盖程序中所有可能的路径
测试用例 通过路径 覆盖条件
【 (2, 0, 4), (2, 0, 3) 】 ace (L1)1T2T3T4
T
T1T2 T3T4
【 (1, 1, 1), (1, 1, 1) 】 abd (L2)
【 (1, 1, 2), (1, 1, 3) 】 abe (L3)1T2 T3T4
T
T1T2T3T4
【 (3, 0, 3), (3, 0, 1) 】 acd (L4)
114

115. 3.2.1 条件测试路径选择
 当程序中判定多于一个时，形成的分支
结构可以分为两类：嵌套型分支结构和
嵌套型分支结构
连锁型分支结构。
连锁型分支结构
 对于嵌套型分支结构，若有 n 个判定语
嵌套型分支结构
句，需要 n +1 个测试用例；
 对于连锁型分支结构， 若有 n 个判定语
连锁型分支结构
句，需要有 2 n 个测试用例，覆盖它的 2 n
条路径。当 n 较大时将无法测试。
115

116. 116

117. 3.2.2 循 环 测 试 路 径 选
择
 循环分为 4 种不同类型：
 简单循环
 连锁循环
 嵌套循环
 非结构循环。
非结构循环
117

118. 118

119. (1) 简单循环
① 零次循环：从循环入口到出口
② 一次循环：检查循环初始值
③ 二次循环：检查多次循环
④ m 次循环： 检查在多次循环
⑤ 最大次数循环、比最大次数多
一次、少一次的循环。
119

120. (2) 嵌套循环
① 对最内层循环做简单循环的全部测试。
所有其它层的循环变量置为最小值；
② 逐步外推，对其外面一层循环进行测试。
测试时保持所有外层循环的循环变量取最
小值，所有其它嵌套内层循环的循环变量
取“典型”值。
③ 反复进行，直到所有各层循环测试完毕
。
④ 对全部各层循环同时取最小循环次数，
或者同时取最大循环次数 120

121. （ 3 ）连锁循环
如果各个循环互相独立，则可以
用与简单循环相同的方法进行测
试。但如果几个循环不是互相独
立的，则需要使用测试嵌套循环
的办法来处理。
121

122. (4) 非结构循环
 这一类循环应该使用结构化程序
设计方法重新设计测试用例。
122

123. 3.4 域测试
 基于程序结构的测试方法
 针对域错误，对输入空间进行分析，选
择适当的测试点，检验输入空间中的每
个输入是否产生正确的结果。
 假设限制过多，难以运用到实际中。
123

124. 3.5 符号测试
 另辟途径解决测试用例选择问题。
 基于代数运算执行测试，是测试和验证
的折衷方法
124

125. 3.6 程序插装
 借助往被测程序中插入操作来实现测试
目的的方法。
125

126. 3.7 程序变异
 是一种错误驱动测试，针对某类特定程
序错误实现测试。
 程序强变异
 程序弱变异
126

127. 3.8 小结
 白盒测试方法分类
 基本路径测试
 逻辑覆盖测试
 路径测试
127

128. 专题小结
 软件测试用例设计－黑盒测试
测试的关键就是确定正确的测试用例。
本部分详细介绍几种软件测试用例设计
方法：等价类划分、因果图、边值分析
、判定表驱动测试和测试用例自动生成
原理和方法。
128

129. 专题小结
 软件测试用例设计－白盒测试
 程序结构分析
 逻辑覆盖测试
 路径
129

130. 专题小结
 学习要求：
1. 理解软件开发过程中每一阶段的软件测试方
法，理解他们的作用和意义。能够根据问题
选择正确的软件测试方法
2. 熟练掌握软件测试用例的设计方法，将设计
得到的测试用例编到软件测试用例表中，根
据软件测试用例表进行软件测试、填写软件
测试记录。
3. 结合实际的测试用例设计过程，理解自动测
试用例的原理和方法。
130

131. 专题小结
 训练：
1. 测试用例的设计
2. 编制软件测试用例表，进行软件测试
131

132. 谢谢 !
132