软件工程
电子教案
王树林
Chapter 17 SOFTWARE TESTING
STRATEGIES
软件测试策略把软件测试用例的设计方法集成
到一系列已经周密计划的过的步骤中去，从
而使得软件开发得以成功完成。
17.1 软件测试的策略途径
测试是一系列可以事先计划并且可以系统地进
行管理的活动。
? 测试开始于模块层，然后延伸到整个计算机
系统。
? 不同的测试技术适用于不同的时间点。
? 测试是由软件开发人员和独立的测试组来管
理的。
Chapter 17 SOFTWARE TESTING
STRATEGIES
? 测试和调试是不同的活动，但是调试必须能
够适应任何的测试策略。
软件测试策略必须提供可以用来检验一小段原
代码是否得以正确实现的底层测试，同时也
提供能验证整个系统的功能是否符合用户需
求的高层测试。
17.1.1 验证和确认
测试是质量可以被评估，错误可以被发现的
最后壁垒，但是，测试不应当被视为一个安
全网。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.1.2 软件测试组织
软件开发者总是负责程序的单个单
元的测试，保证每个单元能够完成设计
的功能。在很多情况下，开发者也进行
集成测试。仅仅在软件体系结构完成后，
独立测试组织（ ITG） 才开始介入。
17.1.3 一种软件测试策略
Chapter 17 SOFTWARE TESTING
STRATEGIES
C
U
D
R
S
I
V
ST
系统工程
需求
设计
编码 单元测试
集成测试
确认测试
系统测试测试策略
Chapter 17 SOFTWARE TESTING
STRATEGIES
软件工程的过程可以看成是一个螺旋结
构。最初，系统工程定义了软件的功能，
从而引出了软件需求分析，建立了软件
的信息域、功能、行为、性能、约束和
确认标准。沿着螺旋向内前进，经过设
计阶段，最终到达编码。为了开发计算
机软件，我们沿着流线的螺旋前进，每
一圈都会降低软件的抽象层次。
Chapter 17 SOFTWARE TESTING
STRATEGIES
高层测试
集成测试
单元测试
软件测试步骤
需求分析
设计
编码
Chapter 17 SOFTWARE TESTING
STRATEGIES
对数泊松执行时间模型（ logarithmic possion
execution-time model） 的软件故障模型为：
F(t)=(1/p)ln(l0pt+1) ;
瞬时的故障密度,l（ t） =l0 /（ l0 pt+1） 。
测试人员可以预测测试进程中错误的急剧减少。
如果这个预测模型与实际所收集的错误吻合
的话，那么这个模型就可以用来预测为了达
到一个可以接受的低故障密度，以及测试过
程所需要的时间。
Chapter 17 SOFTWARE TESTING
STRATEGIES
每
小
时
的
故
障
数
l0
预期的故障密度,l（ t）
执行时间,t
Chapter 17 SOFTWARE TESTING
STRATEGIES
通过在软件测试过程中收集数据和利用现有的
软件可靠性模型，就可以回答：测试什么时
候完成。
17.2 策略问题
明确地指出测试目标。测试的特定目标应当
用可以测度的术语来描述。比如测试有效性、
测试覆盖率、故障出现的平均时间、发现和
改正缺陷的开销、允许剩余的缺陷密度或出
现频率。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.3 单元测试
单元测试完成对最小的软件设计单元 — 模
块的验证工作。使用过程设计描述作为指南，
对重要的控制路径进行测试以发现模块内的
错误。
17.3.1 单元测试考虑
对模块接口的测试保证在测试时进出程序单元
的数据流是正确的，对局部数据结构的检查
保证临时存储的数据在算法执行的整个过程
中都能维持其完整性，对边界条件的测试保
证模块在极限的情形下仍然能够正确执行。
Chapter 17 SOFTWARE TESTING
STRATEGIES
接口测试：
1,输入的形参数目是否等于实参的数目？
2,实参和形参的属性是否匹配？
3,实参和形参的单元系统是否匹配？
4,传递给被调用模块的实参是否等于形
参的数目？
等等。
Chapter 17 SOFTWARE TESTING
STRATEGIES
当一个模块执行外部 I/O操作的时候，必 须进
行附加的接口测试。
1,文件属性是否正确？
2,OPEN/CLOSE语句是否正确？
3,格式规约是否和 I/O语句匹配？
4,缓冲区大小是否和记录大小匹配？
5,文件是否在打开之前被使用？
6,是否处理了文件结束条件？
7,是否处理了 I/O错误？
等等。
Chapter 17 SOFTWARE TESTING
STRATEGIES
模块的局部数据结构是经常出现的错误源。
应设计测试用例发现下列类型的错误：
1。不正确的类型描述。
2。错误的初始化或缺省值。
3。不正确的变量名字。
4。不一致的数据类型。
5。下溢、上溢和地址错误。
Chapter 17 SOFTWARE TESTING
STRATEGIES
在错误处理部分应当考虑的潜在错误：
1。对错误描述的莫名其妙。
2。所报的错误与真正遇到的错误不一致。
3。错误条件在错误处理之前就引起了系
统异常。
4。例外条件处理不正确。
5。错误描述没有提供足够的信息来帮助
确定错误发生的位置。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.3.2 单元测试规程
单元测试通常看成为是编码步骤的附属
品。
Chapter 17 SOFTWARE TESTING
STRATEGIES
驱动器
测试模块
stub stub
接口
局部数据结构
边界条件
独立的路径
错误处理路径
测试用例
单元测试环境
结果
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.4 集成测试
集成测试是通过测试发现和接口有关的问题来
构造程序结构的系统化技术，它的目标是把
通过了单元测试的模块拿来，构造一个在设
计中所描述的程序结构。使用一步到位的方
法来构造程序。所有的模块都预先结合到一
起，整个程序作为一个整体来进行测试，其
结果通常都是混乱不堪。错误的修正也是很
困难的。
Chapter 17 SOFTWARE TESTING
STRATEGIES
增量集成是一步到位的方法的对立面。程序先
分成小的部分进行构造测试，这时错误比较
容易分离和修正。接口也容易测试。
17.4.1 自顶向下集成
是一种构造程序结构的增量实现方法。模
块集成的顺序是首先集成主控模块，然后按
照控制层次结构向下进行集成。按广度优先
和深度优先的顺序来集成模块。
Chapter 17 SOFTWARE TESTING
STRATEGIES
M1
M2
M5
M8
M6
M3
M7
M4
自顶向下集成
Chapter 17 SOFTWARE TESTING
STRATEGIES
集成的整个过程由下列五个步骤组成：
（ 1）主控模块作为测试驱动器，所有的稳定桩替换为
直接隶属于主控模块的模块。
（ 2）根据集成的实现方法（如深度或广度优先），下
层的稳定桩一次一个地被替换为真正的模块。
（ 3）在每一个模块集成的时候都要进行测试。
（ 4）在完成了每一次测试之后，又一个稳定桩被用真
正的模块替换。
（ 5）可以用回归测试来保证没有引进新的错误。
整个过程回到第二步继续进行，直至这个系统结构被构
造完成。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.4.2 自底向上集成
自底向上的测试是从原子模块开始来进行构
造和测试的。
自底向上的集成策略可以使用下列步骤来实现：
1,底层模块组合成能够实现软件特定子功能的
簇。
2,写一个驱动程序（一个供测试用的控制程序）
来协调测试用例的输入输出。
3,对簇进行测试。
4,移走驱动程序，沿着程序结构的层次向上对
簇进行组合。
Chapter 17 SOFTWARE TESTING
STRATEGIES
Mc
Ma Mb
D1 D2 D3
簇 3
簇 1
簇 2
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.4.3 回归测试
每当一个新的模块被当作集成测试的一
部分加进来的时候，软件就发生来改变。
在集成测试策略中，回归测试是对某些
已经进行过的测试的某些子集再重新做
一遍，以保证上述改变不会传播无法预
料的副作用。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.4.4 关于集成测试的讨论
选择一种集成策略依赖于软件的特性，
有时还有进度安排。一般来说，组合自
底向上和自顶向下的方法是一个折中的
方法；在程序结构的高层使用自顶向下
策略，而在底层中使用自底向上策略。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.4.5 集成测试文档
软件集成的总体计划和详细的测试描述
要按照测试规约来写入文档。规约是软
件工程中的重要文件，是软件配置的重
要组成部分。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.5 确认测试
当集成测试结束的时候，软件就全部组
装到一起了，接口错误已经被发现并修
正了，而软件测试的最后一部分就可以
开始了，这就是确认测试。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.5.1 确认测试的标准
软件测试通过一系列证明软件功能和需求一
致的黑盒测试来达到。
在每个确认测试实例进行时，会出现,（ 1）和
需求说明一致的功能或性能是可接受的，（ 2）
和需求说明的偏差被发现时要列出问题清单。
还要进一步确认文档是否齐全合理，需求是否
满足。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.5.2 配置复审
配置复审有时称为审计（ audit）,
目的是保证软件配置的所有元素都已进行了正
确地开发和分类。
17.5.3 Alpha和 Beta测试
软件开发者要想预见到用户是如何实际地
使用程序实质上是不可能的。
如果是为一个客户开发的软件，需要进行
一系列的接受测试来保证客户对所有的需求
都满意。
Chapter 17 SOFTWARE TESTING
STRATEGIES
如果一个软件是给许多客户使用的。那么让每
一个用户都进行接受测试是不切实际的。
Alpha测试
Beta测试
17.6 系统测试
软件是一个大的计算机系统的一个构成成
分这个事实。软件要和其他的系统成分（如
硬件、信息）集成起来，然后要进行系统集
成和确认测试。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.6.1 恢复测试
恢复测试是通过各种手段，让软件强制性
地出现故障，然后来验证恢复是否能正常进
行的一种系统测试方法。
17.6.2 安全测试
任何管理敏感信息或者能够对个人造成不正
当的或非法侵入的目标。
系统设计者的任务就是要把为攻破系统所付出
的代价大于攻破系统之后得到的信息的价值。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.6.3 压力测试
白盒和黑盒技术对正常的程序功能和性能进
行了详尽的检查。压力测试的目的是要对付
非正常的情形。
17.6.4 性能测试
在实时系统和嵌入系统中，提高符合功能
需求但不符合性能需求的软件是不能接受的。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.7 调试的技巧
调试就是在测试发现一个错误后消除错误的
过程。就是发现问题症状的原因。
17.7.1 调试过程
调试是比较困难的，
（ 1）症状和原因可能相隔很远。
（ 2）症状可能是和时间相关的。
（ 3）症状可能是由不太容易跟踪的人工错误引
起的。
Chapter 17 SOFTWARE TESTING
STRATEGIES
（ 4）症状可能是时有时无的。
17.7.2 心理考虑
调试的本领属于一种个人的先天本领。
177.3 调试方法
? 蛮力法
? 回溯法
? 原因排除法
小结
软件测试在软件过程中占有最大百分比的
技术工作量，而我们只是刚刚开始理解
系统化测试的计划、执行和控制的一些
表面知识。
电子教案
王树林
Chapter 17 SOFTWARE TESTING
STRATEGIES
软件测试策略把软件测试用例的设计方法集成
到一系列已经周密计划的过的步骤中去，从
而使得软件开发得以成功完成。
17.1 软件测试的策略途径
测试是一系列可以事先计划并且可以系统地进
行管理的活动。
? 测试开始于模块层，然后延伸到整个计算机
系统。
? 不同的测试技术适用于不同的时间点。
? 测试是由软件开发人员和独立的测试组来管
理的。
Chapter 17 SOFTWARE TESTING
STRATEGIES
? 测试和调试是不同的活动，但是调试必须能
够适应任何的测试策略。
软件测试策略必须提供可以用来检验一小段原
代码是否得以正确实现的底层测试，同时也
提供能验证整个系统的功能是否符合用户需
求的高层测试。
17.1.1 验证和确认
测试是质量可以被评估，错误可以被发现的
最后壁垒，但是，测试不应当被视为一个安
全网。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.1.2 软件测试组织
软件开发者总是负责程序的单个单
元的测试，保证每个单元能够完成设计
的功能。在很多情况下，开发者也进行
集成测试。仅仅在软件体系结构完成后，
独立测试组织（ ITG） 才开始介入。
17.1.3 一种软件测试策略
Chapter 17 SOFTWARE TESTING
STRATEGIES
C
U
D
R
S
I
V
ST
系统工程
需求
设计
编码 单元测试
集成测试
确认测试
系统测试测试策略
Chapter 17 SOFTWARE TESTING
STRATEGIES
软件工程的过程可以看成是一个螺旋结
构。最初，系统工程定义了软件的功能，
从而引出了软件需求分析，建立了软件
的信息域、功能、行为、性能、约束和
确认标准。沿着螺旋向内前进，经过设
计阶段，最终到达编码。为了开发计算
机软件，我们沿着流线的螺旋前进，每
一圈都会降低软件的抽象层次。
Chapter 17 SOFTWARE TESTING
STRATEGIES
高层测试
集成测试
单元测试
软件测试步骤
需求分析
设计
编码
Chapter 17 SOFTWARE TESTING
STRATEGIES
对数泊松执行时间模型（ logarithmic possion
execution-time model） 的软件故障模型为：
F(t)=(1/p)ln(l0pt+1) ;
瞬时的故障密度,l（ t） =l0 /（ l0 pt+1） 。
测试人员可以预测测试进程中错误的急剧减少。
如果这个预测模型与实际所收集的错误吻合
的话，那么这个模型就可以用来预测为了达
到一个可以接受的低故障密度，以及测试过
程所需要的时间。
Chapter 17 SOFTWARE TESTING
STRATEGIES
每
小
时
的
故
障
数
l0
预期的故障密度,l（ t）
执行时间,t
Chapter 17 SOFTWARE TESTING
STRATEGIES
通过在软件测试过程中收集数据和利用现有的
软件可靠性模型，就可以回答：测试什么时
候完成。
17.2 策略问题
明确地指出测试目标。测试的特定目标应当
用可以测度的术语来描述。比如测试有效性、
测试覆盖率、故障出现的平均时间、发现和
改正缺陷的开销、允许剩余的缺陷密度或出
现频率。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.3 单元测试
单元测试完成对最小的软件设计单元 — 模
块的验证工作。使用过程设计描述作为指南，
对重要的控制路径进行测试以发现模块内的
错误。
17.3.1 单元测试考虑
对模块接口的测试保证在测试时进出程序单元
的数据流是正确的，对局部数据结构的检查
保证临时存储的数据在算法执行的整个过程
中都能维持其完整性，对边界条件的测试保
证模块在极限的情形下仍然能够正确执行。
Chapter 17 SOFTWARE TESTING
STRATEGIES
接口测试：
1,输入的形参数目是否等于实参的数目？
2,实参和形参的属性是否匹配？
3,实参和形参的单元系统是否匹配？
4,传递给被调用模块的实参是否等于形
参的数目？
等等。
Chapter 17 SOFTWARE TESTING
STRATEGIES
当一个模块执行外部 I/O操作的时候，必 须进
行附加的接口测试。
1,文件属性是否正确？
2,OPEN/CLOSE语句是否正确？
3,格式规约是否和 I/O语句匹配？
4,缓冲区大小是否和记录大小匹配？
5,文件是否在打开之前被使用？
6,是否处理了文件结束条件？
7,是否处理了 I/O错误？
等等。
Chapter 17 SOFTWARE TESTING
STRATEGIES
模块的局部数据结构是经常出现的错误源。
应设计测试用例发现下列类型的错误：
1。不正确的类型描述。
2。错误的初始化或缺省值。
3。不正确的变量名字。
4。不一致的数据类型。
5。下溢、上溢和地址错误。
Chapter 17 SOFTWARE TESTING
STRATEGIES
在错误处理部分应当考虑的潜在错误：
1。对错误描述的莫名其妙。
2。所报的错误与真正遇到的错误不一致。
3。错误条件在错误处理之前就引起了系
统异常。
4。例外条件处理不正确。
5。错误描述没有提供足够的信息来帮助
确定错误发生的位置。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.3.2 单元测试规程
单元测试通常看成为是编码步骤的附属
品。
Chapter 17 SOFTWARE TESTING
STRATEGIES
驱动器
测试模块
stub stub
接口
局部数据结构
边界条件
独立的路径
错误处理路径
测试用例
单元测试环境
结果
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.4 集成测试
集成测试是通过测试发现和接口有关的问题来
构造程序结构的系统化技术，它的目标是把
通过了单元测试的模块拿来，构造一个在设
计中所描述的程序结构。使用一步到位的方
法来构造程序。所有的模块都预先结合到一
起，整个程序作为一个整体来进行测试，其
结果通常都是混乱不堪。错误的修正也是很
困难的。
Chapter 17 SOFTWARE TESTING
STRATEGIES
增量集成是一步到位的方法的对立面。程序先
分成小的部分进行构造测试，这时错误比较
容易分离和修正。接口也容易测试。
17.4.1 自顶向下集成
是一种构造程序结构的增量实现方法。模
块集成的顺序是首先集成主控模块，然后按
照控制层次结构向下进行集成。按广度优先
和深度优先的顺序来集成模块。
Chapter 17 SOFTWARE TESTING
STRATEGIES
M1
M2
M5
M8
M6
M3
M7
M4
自顶向下集成
Chapter 17 SOFTWARE TESTING
STRATEGIES
集成的整个过程由下列五个步骤组成：
（ 1）主控模块作为测试驱动器，所有的稳定桩替换为
直接隶属于主控模块的模块。
（ 2）根据集成的实现方法（如深度或广度优先），下
层的稳定桩一次一个地被替换为真正的模块。
（ 3）在每一个模块集成的时候都要进行测试。
（ 4）在完成了每一次测试之后，又一个稳定桩被用真
正的模块替换。
（ 5）可以用回归测试来保证没有引进新的错误。
整个过程回到第二步继续进行，直至这个系统结构被构
造完成。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.4.2 自底向上集成
自底向上的测试是从原子模块开始来进行构
造和测试的。
自底向上的集成策略可以使用下列步骤来实现：
1,底层模块组合成能够实现软件特定子功能的
簇。
2,写一个驱动程序（一个供测试用的控制程序）
来协调测试用例的输入输出。
3,对簇进行测试。
4,移走驱动程序，沿着程序结构的层次向上对
簇进行组合。
Chapter 17 SOFTWARE TESTING
STRATEGIES
Mc
Ma Mb
D1 D2 D3
簇 3
簇 1
簇 2
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.4.3 回归测试
每当一个新的模块被当作集成测试的一
部分加进来的时候，软件就发生来改变。
在集成测试策略中，回归测试是对某些
已经进行过的测试的某些子集再重新做
一遍，以保证上述改变不会传播无法预
料的副作用。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.4.4 关于集成测试的讨论
选择一种集成策略依赖于软件的特性，
有时还有进度安排。一般来说，组合自
底向上和自顶向下的方法是一个折中的
方法；在程序结构的高层使用自顶向下
策略，而在底层中使用自底向上策略。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.4.5 集成测试文档
软件集成的总体计划和详细的测试描述
要按照测试规约来写入文档。规约是软
件工程中的重要文件，是软件配置的重
要组成部分。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.5 确认测试
当集成测试结束的时候，软件就全部组
装到一起了，接口错误已经被发现并修
正了，而软件测试的最后一部分就可以
开始了，这就是确认测试。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.5.1 确认测试的标准
软件测试通过一系列证明软件功能和需求一
致的黑盒测试来达到。
在每个确认测试实例进行时，会出现,（ 1）和
需求说明一致的功能或性能是可接受的，（ 2）
和需求说明的偏差被发现时要列出问题清单。
还要进一步确认文档是否齐全合理，需求是否
满足。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.5.2 配置复审
配置复审有时称为审计（ audit）,
目的是保证软件配置的所有元素都已进行了正
确地开发和分类。
17.5.3 Alpha和 Beta测试
软件开发者要想预见到用户是如何实际地
使用程序实质上是不可能的。
如果是为一个客户开发的软件，需要进行
一系列的接受测试来保证客户对所有的需求
都满意。
Chapter 17 SOFTWARE TESTING
STRATEGIES
如果一个软件是给许多客户使用的。那么让每
一个用户都进行接受测试是不切实际的。
Alpha测试
Beta测试
17.6 系统测试
软件是一个大的计算机系统的一个构成成
分这个事实。软件要和其他的系统成分（如
硬件、信息）集成起来，然后要进行系统集
成和确认测试。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.6.1 恢复测试
恢复测试是通过各种手段，让软件强制性
地出现故障，然后来验证恢复是否能正常进
行的一种系统测试方法。
17.6.2 安全测试
任何管理敏感信息或者能够对个人造成不正
当的或非法侵入的目标。
系统设计者的任务就是要把为攻破系统所付出
的代价大于攻破系统之后得到的信息的价值。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.6.3 压力测试
白盒和黑盒技术对正常的程序功能和性能进
行了详尽的检查。压力测试的目的是要对付
非正常的情形。
17.6.4 性能测试
在实时系统和嵌入系统中，提高符合功能
需求但不符合性能需求的软件是不能接受的。
Chapter 17 SOFTWARE TESTING
STRATEGIES
17.7 调试的技巧
调试就是在测试发现一个错误后消除错误的
过程。就是发现问题症状的原因。
17.7.1 调试过程
调试是比较困难的，
（ 1）症状和原因可能相隔很远。
（ 2）症状可能是和时间相关的。
（ 3）症状可能是由不太容易跟踪的人工错误引
起的。
Chapter 17 SOFTWARE TESTING
STRATEGIES
（ 4）症状可能是时有时无的。
17.7.2 心理考虑
调试的本领属于一种个人的先天本领。
177.3 调试方法
? 蛮力法
? 回溯法
? 原因排除法
小结
软件测试在软件过程中占有最大百分比的
技术工作量，而我们只是刚刚开始理解
系统化测试的计划、执行和控制的一些
表面知识。
