北京理工大学
软件工程实践
汤铭端
中国航天科工集团公司 706所
第六讲
软件测试
内容和目的
? 测试的目的和策略
? 测试的活动
? 测试的产品
? 测试的方法和度量要求
? 测试用例构造技术
测试的目标
? Myers
? 测试是一个为了寻找错
误而运行的过程
? 一个好的测试用例是指
很可能找到迄今为止尚
未发现的错误的用例
? 一个成功的测试是指揭
示了迄今为止尚未发现
的错误的测试
? IEEE
? 由人工或自动方法来
执行或评价系统或系
统部件的过程，以验
证它是否满足规定的
需求；或识别出期望
的结果和实际结果之
间有无差别。
两种软件测试目的
? 从 用户的角度 出发，普遍希望通过
软件测试 暴露软件中隐藏的错误和
缺陷,以考虑是否可接受该产品。
? 从 软件开发者的角度 出发，则希望
测试成为 表明软件产品中不存在错
误 的过程，验证该软件已正确地实
现了用户的要求，确立人们对软件
质量的信心。
测试的目的
? 想以最少的时间和人力,系统地找出软件中潜
在的各种错误和缺陷 。如果我们成功地实施了
测试，我们就能够发现软件中的错误。
? 测试的附带收获是，它 能够证明软件的功能和
性能与需求说明相符合 。
? 实施测试收集到的测试结果数据为可靠性分析
提供了依据。
? 测试不能表明软件中不存在错误，它只能说明
软件中存在错误。
软件测试的原则
1,应当把,尽早地和不断地进行软件测试,作为软件开发者的座右
铭。
2,测试用例应由 测试输入数据 和对应的 预期输出结果 这两部分组成。
3,程序员应避免检查自己的程序。
4,在设计测试用例时，应当包括 合理的输入条件 和 不合理的输入条
件 。
5,充分注意测试中的群集现象。
经验表明，测试后 程序中残存的错误数目与该程序中已发现的错
误数目成正比 。
6,严格执行测试计划,排除测试的随意性 。
7,应当对每一个测试结果做全面检查。
8,妥善保存测试计划，测试用例，出错统计和最终分析报告，为维
护提供方便。
Myers软件测试十原则
? 程序员应避免测试自己编制的程序
? 测试用例的设计必须包括预期的输出结果
? 测试用例应包括有效的和期望的输入情况，也要包括无效的和不
期望的输入情况
? 彻底检查每个测试结果
? 只检查程序是否做了它应该做的事仅仅完成了测试工作的一半，
另一半则是要检查程序是否做了它不该做的事
? 避免不可重复的即兴测试，保留全部测试用例
? 一段程序中存在错误的概率与在这段程序中已发现的错误数成正
比
? 测试是一项非常复杂、创造性的和需要高度智慧的挑战性任务
? 不要为了便于测试擅自修改程序
? 测试工作必须有明确的目标
测试的原则（ DAVIE）
? 所有的测试都应追溯到需求
? 应该在测试工作真正开始前的较长时间就进行
测试计划
? Pareto（ 20-80） 原则应用于软件测试
? 测试应从, 小规模, 开始，逐步转向, 大规模,
? 穷举测试是不可能的
? 为了达到最佳效果，应该由独立的第三方来构
造测试
软件测试的对象
? 软件测试并不等于程序测试。 软件测试
应贯穿于软件定义与开发的整个期间 。
? 需求分析, 概要设计, 详细设计以及程
序编码 等各阶段所得到的 文档,包括需
求规格说明、概要设计规格说明、详细
设计规格说明以及源程序,都应成为软
件测试的对象 。
? 为把握软件开发各个环节的正确性，需
要进行各种 确认 和 验证 工作。
验证和确认
? 确认 (Validation),是一系列的活动和过
程，目的是想证实在一个给定的外部环
境中软件的逻辑正确性。
? 需求规格说明的确认
? 程序的确认 (静态确认、动态确认 )
? 验证 (Verification),试图证明在软件生存
期各个阶段，以及阶段间的逻辑协调性、
完备性和正确性。
测试信息流
测试信息流
? 软件配置,软件需求规格说明、软件设计规格说明、
源代码等；
? 测试配置,测试计划、测试用例、测试程序等；
? 测试工具,测试数据自动生成程序、静态分析程序、
动态分析程序、测试结果分析程序、以及驱动测试的
测试数据库等等。
? 测试结果分析,比较实测结果与预期结果，评价错误
是否发生。
? 排错 (调试 )：对已经发现的错误进行错误定位和确定
出错性质，并改正这些错误，同时修改相关的文档。
? 修正后的文档再测试,直到通过测试为止。
测试策略途径
? 测试开始于模块层，然后延伸到整个基
于计算机的系统集合中
? 不同的测试技术适用于不同的时间点
? 测试是由软件的开发人员和（对大型系
统来说）独立的测试组来管理的
? 测试和调试是不同的活动，但是调试必
须能够适应任何的测试策略
测试完成准则
? 资源耗尽
? 采用的测试方法满足某种测试充分性要求
? 满足覆盖率等可度量的测试要求
? 一段时期没有发现问题且所有发现问题均已解
决
? 通过测试评估出软件达到要求的可靠度
? 测试发现频率和趋势达到预先计划的限度之下
（限度根据要求、经验和历史数据得到）
? 在一段时期没有出现等级高的问题
测试概图
? 阶段活动
? 单元
? 集成
? 合格性
? 系统
? 技术方法
? 静态测试
? 静态分析
? 代码审查
? 动态测试
? 白盒测试
? 白盒测试用例技术
? 黑盒测试
? 黑盒测试用例技术
测试与软件开发各阶段的关系
? 软件开发过程是一个自顶向下，逐步细
化的过程
? 测试过程是依相反顺序安排的自底向上，
逐步集成的过程
测试模型
V模型
系统需求
软件需求
概要设计
详细设计 单元测试
集成测试
编码
合格性测试
系统测试
详细设计
概要设计
软件需求
系统需求
软件任务
编译后的单元
测试后的单元
集成的软件
测试后的软件
交付软件
验证
验证
验证
验证
验证
验证
验证与确认
验证与确认
J.McDermid于 1994年在
,软件工程师参考手册, 中
提出
测试活动
? 单元测试（ UNIT）
? 集成测试（ INTERGRATION）
? 合格性测试（ QUALIFICATION）
? 系统测试（ SYSTEM）
单元测试
? 对软件单元进行测试，确实保证它作为
一个单元能正常地工作
? 单元测试的目的是验证单元满足功能、
性能和接口等的要求
? 单元测试采用的技术：静态分析、代码
审查、白盒动态测试
? 测试的充分性由各种测试覆盖率来度量
单元动态测试的内容
? 主要针对下列模块的五个基本特性进行,
? 模块接口
? 局部数据结构
? 重要的执行路径
? 出错处理路径
? 影响以上各点的边界条件
(1) 模块接口测试
? 对通过被测模块的
数据流 进行测试,
? 调用本模块的输入
参数是否正确；
? 本模块调用子模块
时输入给子模块的
参数是否正确；
? 全局量的定义在各
模块中是否一致
? 在做 内外存交换 时要考虑,
? 文件属性是否正确；
? OPEN与 CLOSE语句是否正确；
? 缓冲区容量与记录长度是否
匹配；
? 在进行读写操作之前是否打
开了文件；
? 在结束文件处理时是否关闭
了文件；
? 正文书写／输入错误,
? I／ O错误是否检查并做了处
理。
(2) 局部数据结构测试
? 不正确或不一致的数据类型说明
? 使用尚未赋值或尚未初始化的变量
? 错误的初始值或错误的缺省值
? 变量名拼写错或书写错
? 不一致的数据类型
? 全局数据对模块的影响
(3) 路径测试
? 选择适当的测试用例，对模块中 重要的
执行路径 进行测试。
? 应当设计测试用例查找由于 错误的计算,
不正确的比较 或 不正常的控制流 而导致
的错误。
? 对基本执行路径和循环进行测试可以发
现大量的路径错误。
(4) 错误处理测试
? 出错的描述是否难以理解
? 出错的描述是否能够对错误定位
? 显示的错误与实际的错误是否相符
? 对错误条件的处理正确与否
? 在对错误进行处理之前，错误条件是否
已经引起系统的干预等
(5) 边界测试
? 注意数据流、控制流中刚好等于、大于
或小于确定的比较值时出错的可能性。
对这些地方要仔细地选择测试用例，认
真加以测试。
? 如果对模块运行时间有要求的话，还要
专门进行关键路径测试，以确定最坏情
况下和平均意义下影响模块运行时间的
因素。
单元测试用例的要求
１）用指定值、异常值和极限值验证全部
计算；
２ ） 验证全部输入数据的各种选择；
３ ） 验证全部输出数据的各种选择和格式；
４ ） 每个单元的全部可执行语句至少执行
一次；
５ ） 在每个分支点进行选择的测试 。
单元测试用例的内容
１ ） 指明被验证的需求或功能；
２ ） 解释测试如何进行, 说明验证代码与单元设
计一致的准则和技术, 以验证接口满足需求；
３ ） 指明测试使用的支持软件, 如测试工具, 驱
动模块, 桩模块, 动态路径分析工具等；
４ ） 说明全部输入数据和 （ 或 ） 驱动程序等；
５ ） 说明预期的输出, 包括数据值或其它可以验
证的结果；
６ ） 通过准则 。
单元测试的环境
? 模块并不是一个独立的程序，在考虑测
试模块时，同时要考虑它和外界的联系，
用一些辅助模块去模拟与被测模块相联
系的其它模块。
? 驱动模块 (driver)
? 桩模块 (stub) ── 存根模块
单元测试执行环境
驱动模块
被测单元
桩模块 B 桩模块 C 桩模块 A
单元测试环境配置
集成测试
? 依据软件设计确定的软件结构, 按照软
件集成, 工序,, 把各个软件单元逐步
集成为完整的软件系统, 并不断发现和
排除错误, 以保证联接, 集成的正确性 。
集成测试的内容
1） 软件单元的接口测试；
2） 软件部件的功能, 性能测试；
3） 全面数据结构测试；
4） 必要的运行时间, 存贮空间, 计算精度
测试；
5） 边界条件和非法输入的测试 。
集成测试的要求
1） 必须对有调用关系的软件单元之间的所有调
用进行测试, 验证每个调用接口的完整性和一
致性；
2） 应对软件进行正确处理的能力的经受错误影
响的能力进行测试；
3） 应测试在各种外部输入下, 从外部接口采集
和 （ 或 ） 发送数据的能力, 包括对正确数据及
状态的处理, 对接口错误, 数据错误, 协议错
误的识别及处理 。
集成测试的通过准则
1） 软件单元无错误地连接；
2） 满足各项功能, 性能要求；
3） 对错误的输入有正确处理的能力；
4） 对测试中的异常有合理解释；
5） 人机界面, 对外接口正确无误；
软件集成策略
1） 非增量方式
? 先测试好每一个软件单元,然后一次组装在
一起再测试整个程序 。
2） 增量方式
? 逐步把下一个要被组装的软件单元或部件,
同已测好的软件部件结合起来测试 。
? 增量方式主要包括自顶向下, 自底向上, 自
顶向下与自底向上相结合等方法 。
集成方式
? 非增量方式
? Big Bang
? 增量方式
? 自顶向下方法
? 自底向上方法
?, 三明治, 方法
增量和非增量方式的优缺点
? 增量方式的优点,
a.增量方式占用人工较少 。
b.增量方式可以较早地发现模块接口错误 。
c.增量方式容易排错 。
d.增量方式测试效果好, 比较彻底 。
? 非增量方式的优点,
a.非增量方式占用机器时间较少 。
b.非增量方式有利于并行开发 。
非增量方式
? 有一种很直接, 原始的组装方式, 它把所有通
过单元测试的模块一古脑儿地全部集成在一起,
直接组装成软件系统, 并对它进行测试 。
? 这种被贬义地称作大爆炸 （ Big Bang） 的组装
方式, 目前仍在许多场合使用 。
? 人们期望它可以带来方便, 快捷的组装效果 。
? 这种方法遭到广大测试专家的批评, 普遍认为
它会引起混乱, 且难以确定错误源的位置 。
Big Bang示意
增殖式组装方式
? 又称 渐增式组装
? 首先对一个个模块进行模块测试，然后
将这些模块逐步组装成较大的系统
? 在组装的过程中边连接边测试，以发现
连接过程中产生的问题
? 通过增殖逐步组装成为要求的软件系统。
自顶向下方法
? 自顶向下集成法是一个模块一个模块地组装软件
的方法 。
? 按照控制的结构, 从主控模块 （ 主程序 ） 开始,
向下地逐个把模块连接起来 。
? 集成的方式有两种：深度优先组装法及宽度优先
组装法 。
? 深度优先法是先把结构中的一条主要的控制路经
上的全部模块逐步组装起来 。 然后再连接其它的
控制路径 。
? 宽度优先法是从结构的顶层开始逐层往下组装 。
自顶向下集成的过程步骤
1） 主控模块用作为测试驱动器 。 直接附属于主
控模块的各模块全都用桩模块代替 。
2） 按照所选的组装法 （ 即深度优先或宽度优先 ）
每次用一个真模块取代一个附属的桩模块 。
3） 当装入每个真模块时都要进行测试 。
4） 作完每一组测试后又再用一个真模块代替另
一个桩模块 。
5） 可以进行回复测试 （ 即重新再作过去作过的
全部或部分测试 ）, 以便肯定没有新的错误发
生 。
自顶向下集成示意
自底向上方法
? 自底向上集成测试方法是从软件结构中
最底层的, 最基本的软件单元开始进行
集成和测试 。
? 由于在逐步向上组装过程中下层模块总
是存在的, 也就是说不再需要桩模块了,
但却需要调用这些模块开展工作的驱动
模块 。
自底向上 集成的过程步骤
1） 低层的模块组成簇, 以执行某个特定的软件
子功能 。
2） 编写一个驱动模块作为测试的控制程序, 和
被测试的簇连在一起, 负责安排测试用例的输
入及输出 。
3） 对簇进行测试 。
4） 拆去各个小簇的驱动模块,把几个小簇合并成
大簇,再重复做 2,3及 4步 。 这样在软件结构上
逐步向上组装 。
自底向上 集成示意
“三明治”方法
? 自顶向下测试的主要优点是能较早显示出整个程
序的轮廓 。 主要缺点是, 当测试上层模块时使用
桩模块较多, 很难模拟出真实模块的全部功能,
使部分测试内容被迫推迟, 直至换上真实模块后
再补充测试 。
? 自底向上测试从下层模块开始, 设计测试用例比
较容易, 但是在测试的早期不能显示出程序的轮
廓 。
? 针对自顶向下, 自底向上方法各自的优点和不足,
人们提出了自顶向下和自底向上相结合, 从两头
向中间逼近的混合式组装方法, 被形象称之为
,三明治, 方法 。
“三明治”方法的步骤
? 步骤,
1） 对上层模块采取自顶向下测试；
2） 对关键模块或子系统采取自底向上测试 。
? 混合式的, 三明治, 方法, 综合了自顶向下, 自底向
上两种方法的长处, 扬了长避了短 。
? 例如, 对关键模块采取自底向上测试, 就可能把输入
输出模块提前组装进程序, 使设计测试用例变得较为
容易；或者使具有重要功能的模块早点与有关的模块
相连, 以便及早暴露可能存在的问题 。 除关键模块及
少数与之相关的模块外, 对其余模块尤其是上层模块
仍采取自顶向下的测试方法, 以便收到较早显示程序
总体轮廓的效果 。
合格性测试
? 根据软件需求规格说明中定义的全部功
能、性能、可靠性等需求，测试整个软
件是否达到要求。
合格性测试内容
? 功能测试
? 性能测试
? 资源和余量测试
? 边界测试
? 操作测试
? 外部接口测试
? 强度测试
? 可靠性测试
? 安全性测试
? 恢复性测试
? 安装性测试
? 移植性测试
? 保密性测试
? 回归测试
功能测试
? 功能测试是在规定的一段时间内运行软件系统的所有功能,
以验证这个软件系统有无严重错误
? 根据功能需求进行测试, 以确认软件与软件功能需求的一
致
? 功能测试应达到以下要求,
a.每一个软件功能都必须被测试用例或被认可的异常所覆
盖 （ 或由于异常情况的出现而未达到期望的覆盖, 但该
异常已被测试者认识到, 并进行了处理 ） ；
b.用一系列合理的数据类型和数据值运行, 测试软件在正
常, 超负荷, 饱和和其它, 最坏, 情况下的结果；
c.用假想的数据类型和数据值运行, 以测试软件排斥不规
则 （ 非法 ） 输入的能力 。
性能测试
? 性能测试是要检查系统是否满足在需求
说明书中规定的性能。特别是对于实时
系统或嵌入式系统。
? 对软件是否与所需定量的性能需求一致
进行确认。
? 性能测试常常 需要与强度测试结合起来
进行，并常常要求 同时进行硬件和软件
检测 。
性能测试内容
? 通常，对软件性能的检测表现在以下几个方面：
响应时间, 吞吐量, 辅助存储区,例如缓冲区，
工作区的大小等,处理精度,等等。
? 包括,
a.软件在获得定量结果时计算的精确性；
b.有时间要求的软件, 其实际的运行时间；
c.软件完成功能所能处理的数据量；
d.软件各部分的协调性；
e.其它性能指标 。
资源和余量测试
? 测试是否符合软件需求规格说明中提出
的处理时间, 储存空间和内存, 输入／
输出通道等资源使用的要求, 并在设计
中为这些资源留出了余量 。
? 通常情况下, 应保证在储存空间和内存,
输入／输出通道, 以及处理时间的占用
上至少有２０ ％ 的余量 。
边界测试
? 测试软件在输入域和 （ 或 ） 输出域, 数
据结构, 状态转换, 过程参数, 功能界
限等边界点或端点情况下的运行状态 。
操作测试
? 操作测试包括对用户接口, 人机接口和
人机交互要求的所有测试 。
? 应以常规操作, 非常规操作, 误操作,
快速操作等情况来检验界面的可靠性 。
? 操作测试工作还包括对照软件使用说明,
逐条进行相应的操作, 以检测软件使用
说明的完整性, 正确性, 与软件程序的
一致性 。
外部接口测试
? 确认软件与其外部接口要求的一致性 。
? 测试内容,
a.测试所有外部接口, 检测接口信息的格式和
内容 。
b.对每一个外部输入／输出接口应进行正常和
异常情况测试 。
? 如果软件不能在运行环境中测试, 则有
必要使用模拟程序或其它测试工具 。
强度测试
? 强度测试是要检查 在系统运行环境不正常乃至
发生故障的情况下, 系统可以运行到何种程度
的测试
? 强度测试是在预先规定的一段时间内, 在软件
设计的极限状态下, 进而在超设计能力的状态
下, 运行软件以测试软件的所有功能 。
? 可以允许在饱和点上性能降级, 但必须保证仍
能顺利运行 。
强度测试内容示例
? 把输入数据速率提高一个数量级, 确定输入功能将如何响
应 。
? 设计需要占用最大存储量或其它资源的测试用例进行测试 。
? 设计出在虚拟存储管理机制中引起, 颠簸, 的测试用例进
行测试 。
? 设计出会对磁盘常驻内存的数据过度访问的测试用例进行
测试 。
? 强度测试的一个变种就是 敏感性测试 。在程序有效数据界
限内一个小范围内的一组数据可能引起极端的或不平稳的
错误处理出现，或者导致极度的性能下降的情况发生。此
测试用以发现可能引起这种不稳定性或不正常处理的某些
数据组合。
可靠性测试
? 软件可靠性测试是以能获得可用来评估软件可靠性的
数据为目的的一种软件测试 。
? 例如, 基于软件运行剖面设计软件测试用例, 并用这
些测试用例按出现概率进行随机输入以模拟软件真实
运行状态, 运行软件以获得失效数据, 进而给出软件
的可靠性度量, 这就是一种软件可靠性测试 。
? 软件运行剖面是指,
1)软件运行期间执行各个任务的事件和各事件相应概
率的集合 。
2)系统使用条件的一种定义, 系统输入值用其按时间
或在可能输入范围中以概率分布来定义 。
可靠性指标示例
① 平均失效间隔时间 MTBF
(Mean Time Between Failures) 是否超过
规定时限?
② 因故障而停机的时间 MTTR
(Mean Time To Repairs) 在一年中应不超
过多少时间。
安全性测试
? 针对程序中危险防止和危险处理设施进行的测试, 以
验证其是否有效 。
? 安全性测试应包括下面的工作,
a.全面检验软件在软件需求规格说明中规定的防止危险状
态措施的有效性和在每一个危险状态下的反应；
b.对软件设计中用于提高安全性的结构, 算法, 容错, 冗
余, 中断处理等方案, 进行针对性测试；
c.在异常条件下测试软件, 以表明不会因可能的单个或多
个输入错误而导致不安全状态 。
d.用错误的安全性关键操作进行测试, 以验证系统对这些
操作错误的反应；
e.对安全性关键的软件单元和软件部件, 要单独进行加强
的测试, 以确认其满足安全性需求 。
恢复性测试
? 恢复测试是要证实在 克服硬件故障 (包括
掉电、硬件或网络出错等 )后, 系统能否
正常地继续进行工作,并不对系统造成
任何损害。
? 对有恢复或重置 （ RESET） 功能的软件,
应专门对每一类导致恢复或重置的情况
进行测试, 以确认恢复或重置功能 。
恢复性测试内容
? 可采用各种人工干预的手段，模拟硬件故障，故意造
成软件出错。并由此检查,
? 错误探测功能 ──系统能否发现硬件失效与故障；
? 能否 切换或启动备用的硬件 ；
? 在故障发生时能否 保护正在运行的作业和系统状态 ；
? 在系统恢复后能否 从最后记录下来的无错误状态开
始继续执行作业,等等。
? 掉电测试,其目的是测试软件系统在发生电源中断
时能否 保护当时的状态且不毁坏数据,然后在 电源
恢复时从保留的断点处重新进行操作 。
安装性测试
? 按规程进行安装正确性测试, 包括参数
装订, 程序加载等 。
移植性测试
? 在所有要求的移植环境中运行软件以验
证软件的移植性 。
保密性测试
? 验证软件是否提供了软件需求规格说明
中规定的保密机制, 使软件的机密性,
完整性和有效性不被破坏 。
启动／停止测试
? 这 类测试的目的是验证 在机器启动及关
机阶段,软件 系统正确处理的能力 。
这类测试包括
? 反复启动软件系统 (例如，操作系统
自举、网络的启动、应用程序的调用
等 )
? 在尽可能多的情况下关机 。
回归测试
? 回归测试是一种选择性重新测试, 目的
是检测系统或系统组成部分在修改期间
产生的缺陷, 用于验证已进行的修改并
未引起不希望的有害效果, 或确认修改
后的系统或系统组成部分仍满足规定的
要求 。
Alpha测试和 Beta测试
? 开发者想预见用户的使用过程是不可能的
? 对于通用软件产品，让每个用户都进行接收
（验收）测试是不切实际的
? 采用 Alpha测试和 Beta测试来发现只有最终用
户才能发现的问题
? Alpha测试：由一个用户在开发者的场所、在
开发者指导下进行测试
? Beta测试：由最终用户在一个或多个用户场所
单独地进行测试
α测试
? α测试 是由一个 用户在开发环境下进行的测试,
也可以是 公司内部的用户在模拟实际操作环境
下进行的测试 。
? α测试 的目的是评价软件产品的 FLURPS（ 即
功能、局域化、可使用性、可靠性、性能和支
持）。尤其注重产品的界面和特色。
? α测试 可以从软件产品编码结束之时开始，或
在模块（子系统）测试完成之后开始，也可以
在确认测试过程中产品达到一定的稳定和可靠
程度之后再开始。
β测试
? β测试 是由软件的 多个用户在实际使用环境下进行的测
试 。这些用户返回有关错误信息给开发者。
? 测试时，开发者通常不在测试现场。因而,β测试 是在
开发者无法控制的环境下进行的软件现场应用。
? 在 β测试中，由用户记下遇到的所有问题，包括真实的
以及主观认定的，定期向开发者报告。
? β测试 主要衡量产品的 FLURPS。 着重于产品的支持性，
包括文档、客户培训和支持产品生产能力。
? 只有当 α测试 达到一定的可靠程度时，才能开始 β测试 。
它处在整个测试的最后阶段。同时，产品的所有手册
文本也应该在此阶段完全定稿。
系统测试
? 软件与与系统中其它的软, 硬件对接并
测试其接口的过程
? 系统测试的目的, 是在真实的系统工作
环境下检验软件是否能与系统正确连
接,,并确认软件是否与用户需求 （ 系
统需求 ） 一致
系统测试内容
? 安装性测试
? 功能测试
? 性能测试
? 操作测试
? 外部接口测试
? 安全性测试：注意进行硬件和软件在各种故障模式下
的测试；最坏配置情况下的测试；错误操作情况下的
测试；多机系统出现故障切换时, 系统的功能, 性能
连续平稳性测试
? 性能强度测试
? 降级能力强度测试
独立 （ 第三方 ） 测试
? 第三方指的是与软件项目甲方, 乙方相对独立
的其它机构 。
? 进行独立测试的目的是进一步加强软件质量保
证工作, 提高软件的质量, 并对软件产品进行
客观评价 。
? 进行第三方独立测试通常有以下优点,
1） 发挥专业技术优势；
2） 发挥独立性优势；
3） 进一步促进承办方的工作 。
测试方法
? 静态测试
? 静态分析
? 代码审查
? 代码走查
? 技术评审
? 桌面检查
? 动态测试
? 白盒测试
? 控制流覆盖
? 数据流覆盖
? 黑盒测试
? 功能分解
? 等价类划分
? 边值分析
? 因果图
? 随机测试
? 猜错法
静态测试
? 代码审查：小组集体阅读讨论检查代码
? 代码走查：小组集体用, 脑, 执行并检查代码
? 桌面检查：由程序员阅读自己编写的程序
? 技术评审：会议形式讨论检查代码
? 静态分析：对代码的机械性、程式化的特性分
析方法，包括控制流分析、数据流分析、接口
分析、表达式分析
黑盒测试
? 这种方法是把 测试对象 看做 一个黑
盒子,测试人员完全不考虑程序内
部的逻辑结构和内部特性，只依据
程序的需求规格说明书，检查程序
的功能是否符合它的功能说明。
? 黑盒测试又叫做 功能测试 或 数据驱
动测试 。
黑盒测试的作用
? 黑盒测试方法是在程序接口上进行测试，
主要是为了发现以下错误,
? 是否有不正确或遗漏了的功能?
? 在接口上,输入能否正确地接受? 能否输出
正确的结果?
? 是否有数据结构错误或外部信息 (例如数据
文件 )访问错误?
? 性能上是否能够满足要求?
? 是否有初始化或终止性错误?
黑盒测试的局限
? 用黑盒测试发现程序中的错误，
必须在 所有可能的输入条件和输
出条件 中确定测试数据，来检查
程序是否都能产生正确的输出。
? 但这是 不可能 的。
示例
? 假设一个 程序 P有 输入量
X和 Y及 输出量 Z。 在字
长为 32位的计算机上运
行。若 X,Y取整数，按
黑盒方法进行穷举测试,
? 可能采用的测试数据组：
232× 232＝ 264
? 如果测试一 组数据需要
1毫秒，一年工作 365×
24小时，完成所有测试
需 5亿年。
白盒测试
? 此方法 把测试对象看做一个透明的盒子,
它允许测试人员利用程序内部的逻辑结
构及有关信息，设计或选择测试用例，
对程序所有逻辑路径进行测试。
? 通过在不同点检查程序的状态，确定实
际的状态是否与预期的状态一致。因此
白盒测试又称为结构测试或逻辑驱动测
试。
白盒测试的作用
? 软件人员使用白盒测试方法，主要想对
程序模块进行如下的检查,
? 对程序模块的 所有独立的执行路径 至少测试
一次；
? 对 所有的逻辑判定, 取, 真, 与取, 假, 的
两种情况都至少测试一次 ；
? 在循环的边界和运行界限内执行循环体；
? 测试 内部数据结构的有效性,等。
白盒测试的局限
? 对一个具有 多重选择和循环嵌套 的程序，
不同的路径数目可能是天文数字 。给出
一个小程序的流程图，它包括了一个执
行 20次的循环。
? 包含的不同执行路径数达 520条，对每一
条路径进行测试需要 1毫秒，假定一年工
作 365 × 24小时，要想把所有路径测试
完，需 3170年。
白盒测试与黑盒测试对比
黑盒测试 白盒测试
优
点
?适用于各测试阶段
?从产品功能角度测试
?容易入手生成测试数据
?可以构成测试数据使特定程
序部分得到测试
?有一定的充分性度量手段
?可获得较多工具支持
缺
点
?某些代码段得不到测试
?如果规格说明有误则无法发
现
?不易进行充分性度量
?不易生成测试数据
?无法对未实现规格说明得部
分测试
?工作量大，通常只用于单元
测试，有引用局限
性
质
是一种确认技术，回答, 我
们在构造一个正确得系统
吗？,
是一种验证技术，回答, 我们
在正确地构造一个系统吗？,
白盒测试
? 控制流（逻辑）测试
? 语句覆盖
? 分支覆盖
? 条件覆盖
? 条件组合覆盖
? 路径覆盖
? 数据流测试
? 全定义使用路径
? 全使用路径
? 全定义路径
? 数据流异常状态图
测试覆盖率
? 采用白盒法进行测试时, 考虑的是测试
用例对程序内部逻辑的覆盖程度 。
? 最彻底的白盒法是覆盖程序中的每一条
路径, 但这往往大到无法实现 。
? 因此采用其它一些标准来量度覆盖的程
度, 并希望覆盖程度尽可能高些 。
例子
func(int A,B,X)
{
if((A>1)&&(B=0))
{X:=X/A};
if((A=2)||(X>1))
{X:=X+1};
}
A>1 and B=0
A=2 OR X>1
X=X/A
X=X/A
YES
YES
NO
NO
a
b
c
e
d
路径
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)
L2 ( a? b ? d )= not{(A>1) and (B=0)} and not{(A=2) or (X>1)}
= { not (A>1) or not (B=0) } and { not (A=2) and not (X>1) }
= not (A>1) and not (A=2) and not (X>1) or
not (B=0) and not (A=2) and not (X>1)
L3 ( a? b? e)= not {(A>1) and (B=0)} and {(A=2) or (X>1)}
= { not (A>1) or not (B=0)} and {(A=2) or (X>1)}
= not (A>1) and (A=2) or not (A>1) and (X>1) or
not (B=0) and (A=2) or not (B=0) and (X>1)
L4 ( a? c ? d )= {(A>1) and (B=0)} and not {(A=2) or (X/A>1)}
= (A>1) and (B=0) and not (A=2) and not (X/A>1)
逻辑覆盖测试的 5种标准
发现错误
的能力 标 准 含 义
1(弱 ) 语句覆盖 每条 语 句至少执行一次
2 判定覆盖 每一判定的每个 分支 至少执行一次
3 条件覆盖
每一判定中的每个 条件,分别按
,真,,
,假, 至少各执行一次
4 判定 /条件覆盖 同时满足 判定覆盖 和 条件覆盖 的要求
5 (强 ) 条件组合覆盖
求出判定中 所有条件的各种可能组合
值，每一可能的条件组合至少执行一
次
测试覆盖率示例（ 1）
覆盖标准 程序结构举例 测试用例 应满足的条件
语句覆盖 A^B=.T,
判定覆盖 A^B=.T,A^B=.F,
A^B T F
A^B T F
测试覆盖率示例（ 2）
覆盖标准 程序结构举例 测试用例应 满足的条件
条件覆盖 A=.T,A=.F,B=.T,B=.F,
判定 /条件
覆盖
A^B=.T.,A^B=.F,
A=.T,A=.F,B=.T,B=.F,
条件组合
覆盖
A=.T,^ B=.T,
A=.T,^ B=.F,
A=.F,^ B=.T
A=.F,^ B=.F,
A^B T F
A^B T F
A^B T F
语句覆盖
? 语句覆盖：选择足够的测试用例, 使得
程序中每个语句至少都能被执行一次 。
? 语句覆盖率：已执行的可执行语句占程
序中可执行语句总数的百分比 。
语句覆盖例
? 测试用例的设计格式
如下
? ?输入的 (A,B,X)，
输出的 (A,B,X)?
? 正好所有的可执行语
句都在 路径 L1上
? 测试用例
? ? (2,0,4),(2,0,3)?
A>1 and B=0
A=2 OR X>1
X=X/A
X=X/A
YES
YES
NO
NO
a
b
c
e
d
分支覆盖
? 分支覆盖又称判定覆盖 。
? 分支覆盖：执行足够的测试用例, 使得
程序中每个判定都获得一次, 真, 值和
,假, 值, 或者说使得程序中的每一个
分支至少都通过一次 。
? 分支覆盖率：已取过, 真, 和, 假, 两
个值的判定占程序中所有条件判定个数
的百分比 。
分支覆盖例
? 选择 路径 L1和 L2
? ? (2,0,4),(2,0,3)?
? 覆盖 ace? L1?
? ? (1,1,1),(1,1,1)?
? 覆盖 abd? L2?
? 或选择路径 L3和 L4
? ? (2,1,1),(2,1,2)?
? 覆盖 abe? L3?
? ? (3,0,3),(3,0,1)?
? 覆盖 acd? L4?
A>1 and B=0
A=2 OR X>1
X=X/A
X=X/A
YES
YES
NO
NO
a
b
c
e
d
条件覆盖
? 条件覆盖：执行足够的测试用例, 使得
判定中的每个子条件都获得所有可能的
结果 。
条件覆盖例 A>1 and B=0
A=2 OR X>1
X=X/A
X=X/A
YES
YES
NO
NO
a
b
c
e
d
判断 条件 取真值 取假值
判断
(一 )
A>1 T1 T1
B=0 T2 T2
判断
(二 )
A=2 T3 T3
X>1 T4 T4
设条件的取值标记
判定 /条件覆盖可选取的 测试用例 如下表
测试用例 通过路径 条件取值 覆盖分支
? (1,0,3),(1,0,4)? abe(L3) b,e
? (2,1,1),(2,1,2)? abe(L3) b,e T1 T2 T3 T4
T1 T2 T3 T4
分支 /条件覆盖
? 分支 /条件覆盖：执行足够的测试用例,
使得判定中每个子条件取到各种可能的
值, 并使每个判定取到各种可能的结果 。
分支 /条件覆盖例 A>1 and B=0
A=2 OR X>1
X=X/A
X=X/A
YES
YES
NO
NO
a
b
c
e
d
判断 条件 取真值 取假值
判断
(一 )
A>1 T1 T1
B=0 T2 T2
判断
(二 )
A=2 T3 T3
X>1 T4 T4
设条件的取值标记
判定 /条件覆盖可选取的 测试用例 如下表
测试用例 通过路径 条件取值 覆盖分支
? (2,0,4),(2,0,3)? ace(L1) c,e
? (1,1,1),(1,1,1)? abd(L2) b,d
T1 T2 T3 T4
T1 T2 T3 T4
条件组合覆盖
? 条件组合覆盖：执行足够的测试用例,
使得每个判定中各条件的所有可能的组
合都出现一次 。
条件组合覆盖例
条件 标记 第一个判断取 真假 分支
A>1
B=0
A>1
B ≠ 0
A ≯ 1
B = 0
A ≯ 1
B ≠ 0
判断 条件 取真值 取假值
判断
(一 )
A>1 T1 T1
B=0 T2 T2
判断
(二 )
A=2 T3 T3
X>1 T4 T4
设条件的取值标记
T1 T2 ① 取 真 分支
T1 T2
T1 T2
② 取 假 分支
③ 取 假 分支
④ 取 假 分支 T1 T2
A>1 and B=0
A=2 OR X>1
X=X/A
X=X/A
YES
YES
NO
NO
a
b
c
e
d
条件组合覆盖例 判断 条件 取真值 取假值
判断
(一 )
A>1 T1 T1
B=0 T2 T2
判断
(二 )
A=2 T3 T3
X>1 T4 T4
设条件的取值标记
A>1 and B=0
A=2 OR X>1
X=X/A
X=X/A
YES
YES
NO
NO
a
b
c
e
d
条件 标记 第二个判断取 真假 分支
A=2
X>1
A=2
X≯ 1
A≠2
X>1
A≠2
X≯ 1
T3 T4 ⑤ 取 真 分支
T3 T4
T3 T4
⑥ 取 真 分支
⑦ 取 真 分支
⑧ 取 假 分支 T3 T4
条件组合覆盖例
测试用例 通过路径 条件取值 覆盖组合号
? (2,0,4),(2,0,3)? ace L1 T1 T2 T3 T4 ①,⑤
? (2,1,1),(2,1,2)? abe L3 T1 T2 T3 T4 ②,⑥
? (1,0,3),(1,0,4)? abe L3 T1 T2 T3 T4 ③,⑦
? (1,1,1),(1,1,1)? abd L2 T1 T2 T3 T4 ④,⑧
设条件的取值标记 条件 标记
第一个判断取
真假 分支
A>1 B=0 T1 T2 ① 取 真 分支
A>1 B≠0 T1 T2 ② 取 假 分支
A≯ 1 B=0 T1 T2 ③ 取 假 分支
A≯ 1 B≠0 T1 T2 ④ 取 假 分支
A>1 and B=0
A=2 OR X>1
X=X/A
X=X/A
YES
YES
NO
NO
a
b
c
e
d
路径覆盖
? 路径测试就是设计足够的测试用例, 覆
盖程序中每一条可能的程序 执行路径 至
少测试一次 。
路径覆盖例
测试用例 通过路径 条件取值
? (2,0,4),(2,0,3)? ace L1 T1 T2 T3 T4
? (1,1,1),(1,1,1)? abd L2
? (1,1,2),(1,1,3)? abe L3
? (3,0,3),(3,0,1)? acd L4
T1 T2 T3 T4
A>1 and B=0
A=2 OR X>1
X=X/A
X=X/A
YES
YES
NO
NO
a
b
c
e
d
T1 T2 T3 T4
T1 T2 T3 T4
条件测试路径选择
? 当程序中判定多于一个时，形成的分支
结构可以分为两类,嵌套型分支结构 和
连锁型分支结构 。
? 对于嵌套型分支结构，若有 n个判定语句，
需要 n+1个测试用例；
? 对于连锁型分支结构,若有 n个判定语
句，需要有 2n个测试用例，覆盖它的 2n条
路径。
循环测试路径选择
? 循环分为 4种不同类型,
? 简单循环
? 连锁循环
? 嵌套循环
? 非结构循环
(1)简单循环
① 零次循环,从循环入口到出口
② 一次循环,检查循环初始值
③ 二次循环,检查多次循环
④ m次循环,检查在多次循环
⑤ 最大次数循环、比最大次数多一次、少
一次的循环
例：求最小值
k = i;
for ( j = i+1; j <= n; j++ )
if ( A[j] < A[k] ) k = j;
k = i ; j = i+1;
j <= n?
A[j]<A[k]?
k = j
j ++
f
d
c
a
b
e
测试用例选择
循环 i n A[ i ] A[ i +1] A[ i +2] k 路 径
0
1
2
1 1 i a c
1 2 1 2 i a b e f c
2 1 i +1 a b d f c
1 3 1 2 3 i a b e f e f c
2 3 1 i +2 a b e f d f c
3 2 1 i +2 a b d f d f c
3 1 2 i +1 a b d f e f c
d 改改 kk 的的 值值,,ee 不不 改改 kk 的的 值值
(2) 嵌套循环
① 对最内层循环做简单循环的全部测试。
所有其它层的循环变量置为最小值；
② 逐步外推，对其外面一层循环进行测试。
测试时保持所有外层循环的循环变量取
最小值，所有其它嵌套内层循环的循环
变量取?典型?值。
③ 反复进行，直到所有各层循环测试完毕。
④ 对全部各层循环同时取最小循环次数，
或者同时取最大循环次数。
连锁循环与非结构循环
(3) 连锁循环
? 如果各个循环 互相
独立,则可以用与
简单循环相同的方
法进行测试。但如
果几个循环不 是互
相独立 的，则需要
使用测试嵌套循环
的办法来处理。
(4) 非结构循环
? 这一类循环应该使
用结构化程序设计
方法重新设计测试
用例。
基本路径测试
? 基本路径测试方法把覆盖的路径数压缩
到一定限度内,程序中的循环体最多只
执行一次 。
? 它是在程序控制流图的基础上,分析控
制构造的环路复杂性, 导出基本可执行
路径集合, 设计测试用例的 方法。设计
出的测试用例要保证在测试中，程序的
每一个可执行语句至少要执行一次。
流图符号
1,程序的控制流图
? 符号○为控制流图的一个结点，表示一
个或多个无分支的 PDL语句或源程序语
句。箭头为边，表示控制流的方向。
流图说明
? 在选择或多分支结构中，分支的汇聚处
应有一个汇聚结点。
? 边和结点圈定的区域叫做区域,当对区
域计数时，图形外的区域也应记为一个
区域。
? 如果判断中的条件表达式是由一个或多
个逻辑运算符 (OR,AND,...) 连接的复
合条件表达式，则需改为 一系列 只有单
个条件的嵌套的判断 。
2,程序环路复杂性
? 程序的环路复杂性给出了 程序基本路径
集中的独立路径条数,这是确保程序中
每个可执行语句至少执行一次所必需的
测试用例数目的上界。
? 从控制流图来看，一条独立路径是至少
包含有一条在其它独立路径中从未有过
的边的路径。
例如
? 在图示的控制流图中，一组独立的
路径是
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
组成了控制流图的一个基本路径集。
3,导出测试用例
? 导出测试用例,确保基本路径集中的每一条路径
的执行 。
? 根据判断结点给出的条件，选择适当的数据以保
证某一条路径可以被测试到 — 用逻辑覆盖方法 。
? 每个 测试用例执行之后, 与预期结果进行比较 。
如果所有测试用例都执行完毕，则可以确信程序
中所有的可执行语句至少被执行了一次。
? 必须注意，一些独立的路径 (如例中的路径 1)，往
往不是完全孤立的，有时它是程序正常的控制流
的一部分，这时，这些路径的测试可以是另一条
路径测试的一部分。
覆盖率要求
? 对单元测试来说, 语句覆盖和分支覆盖
是最基本的要求 。
? 由于程序中错误 （ 异常 ） 处理工作的重
要性以及其结构相对简单, 要求错误处
理要做到路径覆盖 。
? 对质量要求高的软件单元, 可根据情况
提出条件覆盖, 分支／条件覆盖, 条件
组合覆盖以及其它更高的覆盖要求 。
控制流测试的测试用例生成
? 经验测试法
? 通过研究程序选择初始测试用例
? 通过测试执行和覆盖率统计增加测试用例
? 不断运行直至达到要求的测试覆盖率
? 与黑盒测试结合
? 纯粹白盒测试方法
? 列出为实现覆盖所需的全部路径
? 根据每个路径设计测试用例
? 注意测试零次循环、一次循环和最大次数循环
黑盒测试
? 功能分解
? 等价类划分
? 边值分析
? 因果图
? 猜错法
功能分解
? 使用功能抽象的方法把程序分解为功能
单元
? 使用数据抽象的方法产生测试每个功能
单元的数据
? 注意测试功能序列组合和输入数据组合
等价类划分
? 等价类划分是一种典型的黑盒测试方法，
使用这一方法时,完全不考虑程序的内
部结构, 只依据程序的规格说明来设计
测试用例 。
? 使用这一方法设计测试用例要经历 划分
等价类 （列出等价类表）和 选取测试用
例 两步。
划分等价类
? 所谓等价分类，就是把输入数据的可能值划分
为若干 等价类 (等价类是指某个输入域的子集
合。
? 在该集合中，各个输入数据对于揭露程序中的
错误都是等价的 )。
? 因此，可以把全部输入数据合理地划分为若干
等价类，在每一个等价类中取一个数据作为测
试的输入条件，这样就可以少量的代表性测试
数据，来取得较好的测试结果。
有效等价类和无效等价类
① 有效等价类,
? 是指对于程序的规
格说明来说，是合
理的，有意义的输
入数据构成的集合 。
② 无效等价类,
? 是指对于程序的规
格说明来说，是不
合理的，无意义的
输入数据构成的集
合。
? 在设计测试用例时，要同时考虑有效等
价类和无效等价类的设计。
划分等价类等价类的原则,1
? 如果输入条件规定了取值范围，或值的个数，
则可以确立一个有效等价类和两个无效等价类。
? 例如对输入 ? …… 项数可以从 1到 999 …… ?
? 则有效等价类是? 1≤项数 ≤999?
? 两个无效等价类是
? ? 项数＜ 1?或? 项数＞ 999?
划分等价类等价类的原则,2
? 如果输入条件规定了输入值的集合，或
者是规定了? 必须如何 ?的条件，这时
可确立一个有效等价类和一个无效等价
类。
? 例如在 Pascal语言中对变量标识符规定为
? 以字母打头的 …… 串 ?
? 所有以字母打头的构成有效等价类
? 不在此集合内（不以字母打头）的归于无效
等价类。
划分等价类等价类的原则,3
? 如果输入条件是一个布尔量，则可以确
定一个有效等价类和一个无效等价类。
划分等价类等价类的原则,4
? 如果规定了输入数据的一组值，而且程序要对
每个输入值分别进行处理。 这时可为 每一个输
入值确立一个有效等价类，此外针对这组值确
立一个无效等价类，它是所有不允许的输入值
的集合。
? 例如，在教师上岗方案中规定对教授、副教授、讲师
和助教分别计算分数，做相应的处理。因此可以确定 4
个有效等价类为教授、副教授、讲师和助教，一个无
效等价类，它是所有不符合以上身分的人员的输入值
的集合。
划分等价类等价类的原则,5
? 如果规定了输入数据必须遵守的规则，
则可以确立一个有效等价类（符合规则）
和若干个无效等价类（从不同角度违反
规则）。
? 例如,Pascal语言规定 ?一个语句必须
以分号‘ ;’结束?。这时，可以确定一
个有效等价类 ?以‘ ;’结束?，若干个
无效等价类 ?以‘,’结束?、?以‘,’
结束?、?以‘ ’结束?、?以 LF结束?
等。
注意点
1,划分等价类不仅要要考虑代表, 有效,
输入值的有效等价类，还需考虑代表,
无效, 输入值的无效等价类。
2,每一无效等价类至少要用一个测试用例
，不然就可能漏掉某一类错误，但允许
若干有效等价类合用同一个测试用例，
以便进一步减少测试的次数。
确立测试用例
? 在确立了等价类之后，建立等价类表，
列出所有划分出的等价类。
确立测试用例
再从划分出的等价类中按以下原则选择测
试用例,
(1) 为每一个等价类规定一个唯一编号；
(2) 设计一个新的测试用例，使其 尽可能多地
覆盖尚未被覆盖的有效等价类,重复这一步，
直到所有的有效等价类都被覆盖为止；
(3) 设计一个新的测试用例，使其 仅覆盖一个
尚未被覆盖的无效等价类,重复这一步，直到
所有的无效等价类都被覆盖为止。
等价类划分设计测试用例实例
? 某一 PASCAL语言版本中规定,
? ? 标识符是由字母开头, 后跟字母或
数字的任意组合构成 。 有效字符数为 8
个, 最大字符数为 80个 。?
? ? 标识符必须先说明, 再使用 。?
? 在同一说明语句中, 标识符至少必
须有一个 。?
建立输入等价类表
覆盖所有等价类的测试用例
① VAR x,T1234567,REAL； BEGIN x,= 3.414； T1234567,=
2.732；,..…
(1),(2),(4),(8),(9),(12),(14)
② VAR, REAL； (3)
③ VAR x，,REAL; (5)
④ VAR T12345678,REAL； (6)
⑤ VAR T12345......,REAL； (7) 多于 80个字符
⑥ VAR T$,CHAR； (10)
⑦ VAR GOTO,INTEGER； (11)
⑧ VAR 2T,REAL； (13)
⑨ VAR PAR,REAL ； BEGIN,....,PAP,= SIN (3.14 * 0.8) / 6；
(15)
边值分析
? 长期经验表明,大量的错误是发生在输入或输
出范围的边界上，而不是在输入范围的内部
? 边界是指相当于输入等价类和输出等价类而言，
稍高于其边界值及稍低于其边界值的一些特定
情况
? 使用边界值分析方法设计测试用例，应对确定
的边界,选取正好等于，刚刚大于，或刚刚小
于边界的值做为测试数据,而不是选取等价类
中的典型值或任意值做为测试数据
示例
? 在做三角形计算时，要输入三角形的三个边长
A,B和 C
? 这三个数值应当满足
A＞ 0,B＞ 0,C＞ 0,
A＋ B＞ C,A＋ C＞ B,B＋ C＞ A
? 如果把六个不等式中的任何一个大于号?＞?
错写成大于等于号? ≥?，那就不能构成三角
形
? 问题恰出现在容易被疏忽的边界附近
边值分析使用原则
? 如果输入条件规定了取值范围或数据个
数，则可选择正好等于边界值、刚刚在
边界范围内和刚刚超越边界外的值进行
测试
? 针对规格说明的每个输入条件，使用上
述原则
? 对于有序数列，选择第一个和最后一个
因果图的适用范围
? 如果在测试时必须考虑 输入条件的
各种组合,可使用一种适合于描述
对于多种条件的组合，相应产生多
个动作的形式来设计测试用例，这
就需要利用因果图。
? 因果图方法最终生成的就是判定表。
它适合于检查程序输入条件的各种
组合情况。
因果图的基本步骤
(1) 分析软件规格说明描述中，哪些是原因 (即输入条
件或输入条件的等价类 )，哪些是结果 (即输出条件 )，
并给每个原因和结果赋予一个标识符。
(2) 分析软件规格说明描述中的语义，找出原因与结果
之间，原因与原因之间对应的是什么关系? 根据这些
关系，画出因果图。
(3) 由于语法或环境限制，有些原因与原因之间，原因
与结果之间的组合情况不可能出现。为表明这些特殊
情况，在因果图上用一些记号标明约束或限制条件。
(4) 把因果图转换成判定表。
(5) 把判定表的每一列拿出来作为依据，设计测试用例 。
因果图基本符号
? 通常在因果图中用 Ci表示原因，用 Ei表示结果，
各结点表示状态，可取值? 0?或? 1?。? 0?
表示某状态不出现，? 1?表示某状态出现。
? 主要的原因和结果之间的关系有,
因果图基本符号
? 表示约束条件的符号：为了表示原因与原因之
间，结果与结果之间可能存在的约束条件，在
因果图中可以附加一些表示约束条件的符号。
示例
? 有一个处理单价为 5角钱的饮料的自动售货机
软件测试用例的设计。其规格说明如下,
? 若 投入 5角钱或 1元钱的硬币,押下 〖橙汁〗
或〖啤酒〗的按钮，则相应的饮料就送出来。
? 若售货机 没有零钱找,则一个显示〖零钱找
完〗的红灯亮，这时在投入 1元硬币并押下
按钮后，饮料不送出来而且 1元硬币也退出
来；
? 若 有零钱找,则显示〖零钱找完〗的红灯灭，
在送出饮料的同时退还 5角硬币。?
示例
(1) 分析这一段说明，列出原因和结果
原因, 1,售货机有零钱找
2,投入 1元硬币
3,投入 5角硬币
4,押下橙汁按钮
5,押下啤酒按钮
建立中间结点，表示处理中间状态
11,投入 1元硬币且押下饮料按钮
12,押下〖橙汁〗或〖啤酒〗的按钮
13,应当找 5角零钱并且售货机有零钱找
14,钱已付清
示例
结果,21,售货机〖零钱找完〗灯亮
22,退还 1元硬币
23,退还 5角硬币
24,送出橙汁饮料
25,送出啤酒饮料
(2) 画出因果图。 所有原因结点列在左边，所有结果结点
列在右边。
(3) 由于 2 与 3, 4 与 5 不能同时发生,分别加上约束条
件 E。
(4) 因果图
(5) 转换成判定表
?
随机测试
? 从所有可能的输入值中随机选取测试输
入数据的方法
? 使数据在规定的取值范围内并服从预期
的概率分布
? 基于运行剖面的测试方法是可靠性测试
的主要方法
? 预期结果可以由人工或定性的方法确定
? 是强度测试的有效手段
猜错法
? 可以靠经验和直觉推测程序中可能存在的各种
错误，从而有针对性地编写检查这些错误的例
子
? 列举出程序中所有可能有的错误和容易发生错
误的特殊情况，根据它们选择测试用例
? 有力的补充
? 充分发挥敏锐、经验等能力
? 直接切入可能的错误，直接定位
? 需要丰富的经验和领域知识
测试产品（文档）
? 测试计划
? 测试说明
? 测试报告
? 测试用例单
? 测试记录
? 问题报告单
软件测试计划
1 范围
1.1 标识
1.2 系统概述
1.3 文档概述
1.4 与其它计划的关系
2 引用文档
3 软件测试环境
3.1 软件项
3.2 硬件和固件项
3.3 权限
3.4 安装、测试和控制
4 正式合格性测试
4.X CSCI名称和项目唯一
标识号
4.X.1 总体测试要求
4.X.2 测试级
4.X.3 测试类
4.X.4 测试定义
4.X.4.Y 测试名称和项目唯
一标识号
4.X.5 测试进度
5 数据记录、整理和分析
软件测试说明
1 范围
1.1 标识
1.2 系统概述
1.3 文档概述
1.4 与其它计划的关系
2 引用文档
3 正式合格性测试准备
3.X 测试名称和项目唯一标识号
3.X.1 计划
3.X.2 测试准备过程
3.X.2.1 硬件要求
3.X.2.2 软件准备
3.X.2.3 其它测试准备
4 正式合格性测试说明
4.X 测试名称和项目唯一标识号
4.X.Y 测试用例名称和项目唯一
标识号
4.X.Y.1 需求可追踪性
4.X.Y.2 初始化
4.X.Y.3 测试输入
4.X.Y.4 预期测试结果
4.X.Y.5 评估测试结果的标准
4.X.Y.6 测试过程
4.X.Y.7 前提和约束
软件测试报告
1 范围
1.1 标识
1.2 系统概述
1.3 文档概述
1.4 与其它计划的关系
2 引用文档
3 测试概述
3.1 正式合格性测试名称及
项目的唯一标识号
3.1.1 小结
3.1.2 测试记录
4 测试结果
4.X 正式合格性测试名称及
项目的唯一标识号测试
结果
4.X.Y 测试用例名称和项目
唯一标识号
4.X.Y.1 测试结果
4.X.Y.2 测试过程中的差异
情况
5 CSCI评估和建议
5.1 CSCI评估
5.2 改进建议
测试记录表
测试用例标识
测试完成日期
结果
问题报告单
软件问题报告
编号
日期
提出人
1 软件项标题,
2 软件项版本 /发布号,
3 优先级,
关键／紧急／常规 （ 划出选择 ）
4 问题描述,
5 环境描述,
6 建议解决办法,
7 评审决定,
8备注,
谢谢！
68389085（ O）
68389504（ H）
mdtang@btamail.net.cn
软件工程实践
汤铭端
中国航天科工集团公司 706所
第六讲
软件测试
内容和目的
? 测试的目的和策略
? 测试的活动
? 测试的产品
? 测试的方法和度量要求
? 测试用例构造技术
测试的目标
? Myers
? 测试是一个为了寻找错
误而运行的过程
? 一个好的测试用例是指
很可能找到迄今为止尚
未发现的错误的用例
? 一个成功的测试是指揭
示了迄今为止尚未发现
的错误的测试
? IEEE
? 由人工或自动方法来
执行或评价系统或系
统部件的过程，以验
证它是否满足规定的
需求；或识别出期望
的结果和实际结果之
间有无差别。
两种软件测试目的
? 从 用户的角度 出发，普遍希望通过
软件测试 暴露软件中隐藏的错误和
缺陷,以考虑是否可接受该产品。
? 从 软件开发者的角度 出发，则希望
测试成为 表明软件产品中不存在错
误 的过程，验证该软件已正确地实
现了用户的要求，确立人们对软件
质量的信心。
测试的目的
? 想以最少的时间和人力,系统地找出软件中潜
在的各种错误和缺陷 。如果我们成功地实施了
测试，我们就能够发现软件中的错误。
? 测试的附带收获是，它 能够证明软件的功能和
性能与需求说明相符合 。
? 实施测试收集到的测试结果数据为可靠性分析
提供了依据。
? 测试不能表明软件中不存在错误，它只能说明
软件中存在错误。
软件测试的原则
1,应当把,尽早地和不断地进行软件测试,作为软件开发者的座右
铭。
2,测试用例应由 测试输入数据 和对应的 预期输出结果 这两部分组成。
3,程序员应避免检查自己的程序。
4,在设计测试用例时，应当包括 合理的输入条件 和 不合理的输入条
件 。
5,充分注意测试中的群集现象。
经验表明，测试后 程序中残存的错误数目与该程序中已发现的错
误数目成正比 。
6,严格执行测试计划,排除测试的随意性 。
7,应当对每一个测试结果做全面检查。
8,妥善保存测试计划，测试用例，出错统计和最终分析报告，为维
护提供方便。
Myers软件测试十原则
? 程序员应避免测试自己编制的程序
? 测试用例的设计必须包括预期的输出结果
? 测试用例应包括有效的和期望的输入情况，也要包括无效的和不
期望的输入情况
? 彻底检查每个测试结果
? 只检查程序是否做了它应该做的事仅仅完成了测试工作的一半，
另一半则是要检查程序是否做了它不该做的事
? 避免不可重复的即兴测试，保留全部测试用例
? 一段程序中存在错误的概率与在这段程序中已发现的错误数成正
比
? 测试是一项非常复杂、创造性的和需要高度智慧的挑战性任务
? 不要为了便于测试擅自修改程序
? 测试工作必须有明确的目标
测试的原则（ DAVIE）
? 所有的测试都应追溯到需求
? 应该在测试工作真正开始前的较长时间就进行
测试计划
? Pareto（ 20-80） 原则应用于软件测试
? 测试应从, 小规模, 开始，逐步转向, 大规模,
? 穷举测试是不可能的
? 为了达到最佳效果，应该由独立的第三方来构
造测试
软件测试的对象
? 软件测试并不等于程序测试。 软件测试
应贯穿于软件定义与开发的整个期间 。
? 需求分析, 概要设计, 详细设计以及程
序编码 等各阶段所得到的 文档,包括需
求规格说明、概要设计规格说明、详细
设计规格说明以及源程序,都应成为软
件测试的对象 。
? 为把握软件开发各个环节的正确性，需
要进行各种 确认 和 验证 工作。
验证和确认
? 确认 (Validation),是一系列的活动和过
程，目的是想证实在一个给定的外部环
境中软件的逻辑正确性。
? 需求规格说明的确认
? 程序的确认 (静态确认、动态确认 )
? 验证 (Verification),试图证明在软件生存
期各个阶段，以及阶段间的逻辑协调性、
完备性和正确性。
测试信息流
测试信息流
? 软件配置,软件需求规格说明、软件设计规格说明、
源代码等；
? 测试配置,测试计划、测试用例、测试程序等；
? 测试工具,测试数据自动生成程序、静态分析程序、
动态分析程序、测试结果分析程序、以及驱动测试的
测试数据库等等。
? 测试结果分析,比较实测结果与预期结果，评价错误
是否发生。
? 排错 (调试 )：对已经发现的错误进行错误定位和确定
出错性质，并改正这些错误，同时修改相关的文档。
? 修正后的文档再测试,直到通过测试为止。
测试策略途径
? 测试开始于模块层，然后延伸到整个基
于计算机的系统集合中
? 不同的测试技术适用于不同的时间点
? 测试是由软件的开发人员和（对大型系
统来说）独立的测试组来管理的
? 测试和调试是不同的活动，但是调试必
须能够适应任何的测试策略
测试完成准则
? 资源耗尽
? 采用的测试方法满足某种测试充分性要求
? 满足覆盖率等可度量的测试要求
? 一段时期没有发现问题且所有发现问题均已解
决
? 通过测试评估出软件达到要求的可靠度
? 测试发现频率和趋势达到预先计划的限度之下
（限度根据要求、经验和历史数据得到）
? 在一段时期没有出现等级高的问题
测试概图
? 阶段活动
? 单元
? 集成
? 合格性
? 系统
? 技术方法
? 静态测试
? 静态分析
? 代码审查
? 动态测试
? 白盒测试
? 白盒测试用例技术
? 黑盒测试
? 黑盒测试用例技术
测试与软件开发各阶段的关系
? 软件开发过程是一个自顶向下，逐步细
化的过程
? 测试过程是依相反顺序安排的自底向上，
逐步集成的过程
测试模型
V模型
系统需求
软件需求
概要设计
详细设计 单元测试
集成测试
编码
合格性测试
系统测试
详细设计
概要设计
软件需求
系统需求
软件任务
编译后的单元
测试后的单元
集成的软件
测试后的软件
交付软件
验证
验证
验证
验证
验证
验证
验证与确认
验证与确认
J.McDermid于 1994年在
,软件工程师参考手册, 中
提出
测试活动
? 单元测试（ UNIT）
? 集成测试（ INTERGRATION）
? 合格性测试（ QUALIFICATION）
? 系统测试（ SYSTEM）
单元测试
? 对软件单元进行测试，确实保证它作为
一个单元能正常地工作
? 单元测试的目的是验证单元满足功能、
性能和接口等的要求
? 单元测试采用的技术：静态分析、代码
审查、白盒动态测试
? 测试的充分性由各种测试覆盖率来度量
单元动态测试的内容
? 主要针对下列模块的五个基本特性进行,
? 模块接口
? 局部数据结构
? 重要的执行路径
? 出错处理路径
? 影响以上各点的边界条件
(1) 模块接口测试
? 对通过被测模块的
数据流 进行测试,
? 调用本模块的输入
参数是否正确；
? 本模块调用子模块
时输入给子模块的
参数是否正确；
? 全局量的定义在各
模块中是否一致
? 在做 内外存交换 时要考虑,
? 文件属性是否正确；
? OPEN与 CLOSE语句是否正确；
? 缓冲区容量与记录长度是否
匹配；
? 在进行读写操作之前是否打
开了文件；
? 在结束文件处理时是否关闭
了文件；
? 正文书写／输入错误,
? I／ O错误是否检查并做了处
理。
(2) 局部数据结构测试
? 不正确或不一致的数据类型说明
? 使用尚未赋值或尚未初始化的变量
? 错误的初始值或错误的缺省值
? 变量名拼写错或书写错
? 不一致的数据类型
? 全局数据对模块的影响
(3) 路径测试
? 选择适当的测试用例，对模块中 重要的
执行路径 进行测试。
? 应当设计测试用例查找由于 错误的计算,
不正确的比较 或 不正常的控制流 而导致
的错误。
? 对基本执行路径和循环进行测试可以发
现大量的路径错误。
(4) 错误处理测试
? 出错的描述是否难以理解
? 出错的描述是否能够对错误定位
? 显示的错误与实际的错误是否相符
? 对错误条件的处理正确与否
? 在对错误进行处理之前，错误条件是否
已经引起系统的干预等
(5) 边界测试
? 注意数据流、控制流中刚好等于、大于
或小于确定的比较值时出错的可能性。
对这些地方要仔细地选择测试用例，认
真加以测试。
? 如果对模块运行时间有要求的话，还要
专门进行关键路径测试，以确定最坏情
况下和平均意义下影响模块运行时间的
因素。
单元测试用例的要求
１）用指定值、异常值和极限值验证全部
计算；
２ ） 验证全部输入数据的各种选择；
３ ） 验证全部输出数据的各种选择和格式；
４ ） 每个单元的全部可执行语句至少执行
一次；
５ ） 在每个分支点进行选择的测试 。
单元测试用例的内容
１ ） 指明被验证的需求或功能；
２ ） 解释测试如何进行, 说明验证代码与单元设
计一致的准则和技术, 以验证接口满足需求；
３ ） 指明测试使用的支持软件, 如测试工具, 驱
动模块, 桩模块, 动态路径分析工具等；
４ ） 说明全部输入数据和 （ 或 ） 驱动程序等；
５ ） 说明预期的输出, 包括数据值或其它可以验
证的结果；
６ ） 通过准则 。
单元测试的环境
? 模块并不是一个独立的程序，在考虑测
试模块时，同时要考虑它和外界的联系，
用一些辅助模块去模拟与被测模块相联
系的其它模块。
? 驱动模块 (driver)
? 桩模块 (stub) ── 存根模块
单元测试执行环境
驱动模块
被测单元
桩模块 B 桩模块 C 桩模块 A
单元测试环境配置
集成测试
? 依据软件设计确定的软件结构, 按照软
件集成, 工序,, 把各个软件单元逐步
集成为完整的软件系统, 并不断发现和
排除错误, 以保证联接, 集成的正确性 。
集成测试的内容
1） 软件单元的接口测试；
2） 软件部件的功能, 性能测试；
3） 全面数据结构测试；
4） 必要的运行时间, 存贮空间, 计算精度
测试；
5） 边界条件和非法输入的测试 。
集成测试的要求
1） 必须对有调用关系的软件单元之间的所有调
用进行测试, 验证每个调用接口的完整性和一
致性；
2） 应对软件进行正确处理的能力的经受错误影
响的能力进行测试；
3） 应测试在各种外部输入下, 从外部接口采集
和 （ 或 ） 发送数据的能力, 包括对正确数据及
状态的处理, 对接口错误, 数据错误, 协议错
误的识别及处理 。
集成测试的通过准则
1） 软件单元无错误地连接；
2） 满足各项功能, 性能要求；
3） 对错误的输入有正确处理的能力；
4） 对测试中的异常有合理解释；
5） 人机界面, 对外接口正确无误；
软件集成策略
1） 非增量方式
? 先测试好每一个软件单元,然后一次组装在
一起再测试整个程序 。
2） 增量方式
? 逐步把下一个要被组装的软件单元或部件,
同已测好的软件部件结合起来测试 。
? 增量方式主要包括自顶向下, 自底向上, 自
顶向下与自底向上相结合等方法 。
集成方式
? 非增量方式
? Big Bang
? 增量方式
? 自顶向下方法
? 自底向上方法
?, 三明治, 方法
增量和非增量方式的优缺点
? 增量方式的优点,
a.增量方式占用人工较少 。
b.增量方式可以较早地发现模块接口错误 。
c.增量方式容易排错 。
d.增量方式测试效果好, 比较彻底 。
? 非增量方式的优点,
a.非增量方式占用机器时间较少 。
b.非增量方式有利于并行开发 。
非增量方式
? 有一种很直接, 原始的组装方式, 它把所有通
过单元测试的模块一古脑儿地全部集成在一起,
直接组装成软件系统, 并对它进行测试 。
? 这种被贬义地称作大爆炸 （ Big Bang） 的组装
方式, 目前仍在许多场合使用 。
? 人们期望它可以带来方便, 快捷的组装效果 。
? 这种方法遭到广大测试专家的批评, 普遍认为
它会引起混乱, 且难以确定错误源的位置 。
Big Bang示意
增殖式组装方式
? 又称 渐增式组装
? 首先对一个个模块进行模块测试，然后
将这些模块逐步组装成较大的系统
? 在组装的过程中边连接边测试，以发现
连接过程中产生的问题
? 通过增殖逐步组装成为要求的软件系统。
自顶向下方法
? 自顶向下集成法是一个模块一个模块地组装软件
的方法 。
? 按照控制的结构, 从主控模块 （ 主程序 ） 开始,
向下地逐个把模块连接起来 。
? 集成的方式有两种：深度优先组装法及宽度优先
组装法 。
? 深度优先法是先把结构中的一条主要的控制路经
上的全部模块逐步组装起来 。 然后再连接其它的
控制路径 。
? 宽度优先法是从结构的顶层开始逐层往下组装 。
自顶向下集成的过程步骤
1） 主控模块用作为测试驱动器 。 直接附属于主
控模块的各模块全都用桩模块代替 。
2） 按照所选的组装法 （ 即深度优先或宽度优先 ）
每次用一个真模块取代一个附属的桩模块 。
3） 当装入每个真模块时都要进行测试 。
4） 作完每一组测试后又再用一个真模块代替另
一个桩模块 。
5） 可以进行回复测试 （ 即重新再作过去作过的
全部或部分测试 ）, 以便肯定没有新的错误发
生 。
自顶向下集成示意
自底向上方法
? 自底向上集成测试方法是从软件结构中
最底层的, 最基本的软件单元开始进行
集成和测试 。
? 由于在逐步向上组装过程中下层模块总
是存在的, 也就是说不再需要桩模块了,
但却需要调用这些模块开展工作的驱动
模块 。
自底向上 集成的过程步骤
1） 低层的模块组成簇, 以执行某个特定的软件
子功能 。
2） 编写一个驱动模块作为测试的控制程序, 和
被测试的簇连在一起, 负责安排测试用例的输
入及输出 。
3） 对簇进行测试 。
4） 拆去各个小簇的驱动模块,把几个小簇合并成
大簇,再重复做 2,3及 4步 。 这样在软件结构上
逐步向上组装 。
自底向上 集成示意
“三明治”方法
? 自顶向下测试的主要优点是能较早显示出整个程
序的轮廓 。 主要缺点是, 当测试上层模块时使用
桩模块较多, 很难模拟出真实模块的全部功能,
使部分测试内容被迫推迟, 直至换上真实模块后
再补充测试 。
? 自底向上测试从下层模块开始, 设计测试用例比
较容易, 但是在测试的早期不能显示出程序的轮
廓 。
? 针对自顶向下, 自底向上方法各自的优点和不足,
人们提出了自顶向下和自底向上相结合, 从两头
向中间逼近的混合式组装方法, 被形象称之为
,三明治, 方法 。
“三明治”方法的步骤
? 步骤,
1） 对上层模块采取自顶向下测试；
2） 对关键模块或子系统采取自底向上测试 。
? 混合式的, 三明治, 方法, 综合了自顶向下, 自底向
上两种方法的长处, 扬了长避了短 。
? 例如, 对关键模块采取自底向上测试, 就可能把输入
输出模块提前组装进程序, 使设计测试用例变得较为
容易；或者使具有重要功能的模块早点与有关的模块
相连, 以便及早暴露可能存在的问题 。 除关键模块及
少数与之相关的模块外, 对其余模块尤其是上层模块
仍采取自顶向下的测试方法, 以便收到较早显示程序
总体轮廓的效果 。
合格性测试
? 根据软件需求规格说明中定义的全部功
能、性能、可靠性等需求，测试整个软
件是否达到要求。
合格性测试内容
? 功能测试
? 性能测试
? 资源和余量测试
? 边界测试
? 操作测试
? 外部接口测试
? 强度测试
? 可靠性测试
? 安全性测试
? 恢复性测试
? 安装性测试
? 移植性测试
? 保密性测试
? 回归测试
功能测试
? 功能测试是在规定的一段时间内运行软件系统的所有功能,
以验证这个软件系统有无严重错误
? 根据功能需求进行测试, 以确认软件与软件功能需求的一
致
? 功能测试应达到以下要求,
a.每一个软件功能都必须被测试用例或被认可的异常所覆
盖 （ 或由于异常情况的出现而未达到期望的覆盖, 但该
异常已被测试者认识到, 并进行了处理 ） ；
b.用一系列合理的数据类型和数据值运行, 测试软件在正
常, 超负荷, 饱和和其它, 最坏, 情况下的结果；
c.用假想的数据类型和数据值运行, 以测试软件排斥不规
则 （ 非法 ） 输入的能力 。
性能测试
? 性能测试是要检查系统是否满足在需求
说明书中规定的性能。特别是对于实时
系统或嵌入式系统。
? 对软件是否与所需定量的性能需求一致
进行确认。
? 性能测试常常 需要与强度测试结合起来
进行，并常常要求 同时进行硬件和软件
检测 。
性能测试内容
? 通常，对软件性能的检测表现在以下几个方面：
响应时间, 吞吐量, 辅助存储区,例如缓冲区，
工作区的大小等,处理精度,等等。
? 包括,
a.软件在获得定量结果时计算的精确性；
b.有时间要求的软件, 其实际的运行时间；
c.软件完成功能所能处理的数据量；
d.软件各部分的协调性；
e.其它性能指标 。
资源和余量测试
? 测试是否符合软件需求规格说明中提出
的处理时间, 储存空间和内存, 输入／
输出通道等资源使用的要求, 并在设计
中为这些资源留出了余量 。
? 通常情况下, 应保证在储存空间和内存,
输入／输出通道, 以及处理时间的占用
上至少有２０ ％ 的余量 。
边界测试
? 测试软件在输入域和 （ 或 ） 输出域, 数
据结构, 状态转换, 过程参数, 功能界
限等边界点或端点情况下的运行状态 。
操作测试
? 操作测试包括对用户接口, 人机接口和
人机交互要求的所有测试 。
? 应以常规操作, 非常规操作, 误操作,
快速操作等情况来检验界面的可靠性 。
? 操作测试工作还包括对照软件使用说明,
逐条进行相应的操作, 以检测软件使用
说明的完整性, 正确性, 与软件程序的
一致性 。
外部接口测试
? 确认软件与其外部接口要求的一致性 。
? 测试内容,
a.测试所有外部接口, 检测接口信息的格式和
内容 。
b.对每一个外部输入／输出接口应进行正常和
异常情况测试 。
? 如果软件不能在运行环境中测试, 则有
必要使用模拟程序或其它测试工具 。
强度测试
? 强度测试是要检查 在系统运行环境不正常乃至
发生故障的情况下, 系统可以运行到何种程度
的测试
? 强度测试是在预先规定的一段时间内, 在软件
设计的极限状态下, 进而在超设计能力的状态
下, 运行软件以测试软件的所有功能 。
? 可以允许在饱和点上性能降级, 但必须保证仍
能顺利运行 。
强度测试内容示例
? 把输入数据速率提高一个数量级, 确定输入功能将如何响
应 。
? 设计需要占用最大存储量或其它资源的测试用例进行测试 。
? 设计出在虚拟存储管理机制中引起, 颠簸, 的测试用例进
行测试 。
? 设计出会对磁盘常驻内存的数据过度访问的测试用例进行
测试 。
? 强度测试的一个变种就是 敏感性测试 。在程序有效数据界
限内一个小范围内的一组数据可能引起极端的或不平稳的
错误处理出现，或者导致极度的性能下降的情况发生。此
测试用以发现可能引起这种不稳定性或不正常处理的某些
数据组合。
可靠性测试
? 软件可靠性测试是以能获得可用来评估软件可靠性的
数据为目的的一种软件测试 。
? 例如, 基于软件运行剖面设计软件测试用例, 并用这
些测试用例按出现概率进行随机输入以模拟软件真实
运行状态, 运行软件以获得失效数据, 进而给出软件
的可靠性度量, 这就是一种软件可靠性测试 。
? 软件运行剖面是指,
1)软件运行期间执行各个任务的事件和各事件相应概
率的集合 。
2)系统使用条件的一种定义, 系统输入值用其按时间
或在可能输入范围中以概率分布来定义 。
可靠性指标示例
① 平均失效间隔时间 MTBF
(Mean Time Between Failures) 是否超过
规定时限?
② 因故障而停机的时间 MTTR
(Mean Time To Repairs) 在一年中应不超
过多少时间。
安全性测试
? 针对程序中危险防止和危险处理设施进行的测试, 以
验证其是否有效 。
? 安全性测试应包括下面的工作,
a.全面检验软件在软件需求规格说明中规定的防止危险状
态措施的有效性和在每一个危险状态下的反应；
b.对软件设计中用于提高安全性的结构, 算法, 容错, 冗
余, 中断处理等方案, 进行针对性测试；
c.在异常条件下测试软件, 以表明不会因可能的单个或多
个输入错误而导致不安全状态 。
d.用错误的安全性关键操作进行测试, 以验证系统对这些
操作错误的反应；
e.对安全性关键的软件单元和软件部件, 要单独进行加强
的测试, 以确认其满足安全性需求 。
恢复性测试
? 恢复测试是要证实在 克服硬件故障 (包括
掉电、硬件或网络出错等 )后, 系统能否
正常地继续进行工作,并不对系统造成
任何损害。
? 对有恢复或重置 （ RESET） 功能的软件,
应专门对每一类导致恢复或重置的情况
进行测试, 以确认恢复或重置功能 。
恢复性测试内容
? 可采用各种人工干预的手段，模拟硬件故障，故意造
成软件出错。并由此检查,
? 错误探测功能 ──系统能否发现硬件失效与故障；
? 能否 切换或启动备用的硬件 ；
? 在故障发生时能否 保护正在运行的作业和系统状态 ；
? 在系统恢复后能否 从最后记录下来的无错误状态开
始继续执行作业,等等。
? 掉电测试,其目的是测试软件系统在发生电源中断
时能否 保护当时的状态且不毁坏数据,然后在 电源
恢复时从保留的断点处重新进行操作 。
安装性测试
? 按规程进行安装正确性测试, 包括参数
装订, 程序加载等 。
移植性测试
? 在所有要求的移植环境中运行软件以验
证软件的移植性 。
保密性测试
? 验证软件是否提供了软件需求规格说明
中规定的保密机制, 使软件的机密性,
完整性和有效性不被破坏 。
启动／停止测试
? 这 类测试的目的是验证 在机器启动及关
机阶段,软件 系统正确处理的能力 。
这类测试包括
? 反复启动软件系统 (例如，操作系统
自举、网络的启动、应用程序的调用
等 )
? 在尽可能多的情况下关机 。
回归测试
? 回归测试是一种选择性重新测试, 目的
是检测系统或系统组成部分在修改期间
产生的缺陷, 用于验证已进行的修改并
未引起不希望的有害效果, 或确认修改
后的系统或系统组成部分仍满足规定的
要求 。
Alpha测试和 Beta测试
? 开发者想预见用户的使用过程是不可能的
? 对于通用软件产品，让每个用户都进行接收
（验收）测试是不切实际的
? 采用 Alpha测试和 Beta测试来发现只有最终用
户才能发现的问题
? Alpha测试：由一个用户在开发者的场所、在
开发者指导下进行测试
? Beta测试：由最终用户在一个或多个用户场所
单独地进行测试
α测试
? α测试 是由一个 用户在开发环境下进行的测试,
也可以是 公司内部的用户在模拟实际操作环境
下进行的测试 。
? α测试 的目的是评价软件产品的 FLURPS（ 即
功能、局域化、可使用性、可靠性、性能和支
持）。尤其注重产品的界面和特色。
? α测试 可以从软件产品编码结束之时开始，或
在模块（子系统）测试完成之后开始，也可以
在确认测试过程中产品达到一定的稳定和可靠
程度之后再开始。
β测试
? β测试 是由软件的 多个用户在实际使用环境下进行的测
试 。这些用户返回有关错误信息给开发者。
? 测试时，开发者通常不在测试现场。因而,β测试 是在
开发者无法控制的环境下进行的软件现场应用。
? 在 β测试中，由用户记下遇到的所有问题，包括真实的
以及主观认定的，定期向开发者报告。
? β测试 主要衡量产品的 FLURPS。 着重于产品的支持性，
包括文档、客户培训和支持产品生产能力。
? 只有当 α测试 达到一定的可靠程度时，才能开始 β测试 。
它处在整个测试的最后阶段。同时，产品的所有手册
文本也应该在此阶段完全定稿。
系统测试
? 软件与与系统中其它的软, 硬件对接并
测试其接口的过程
? 系统测试的目的, 是在真实的系统工作
环境下检验软件是否能与系统正确连
接,,并确认软件是否与用户需求 （ 系
统需求 ） 一致
系统测试内容
? 安装性测试
? 功能测试
? 性能测试
? 操作测试
? 外部接口测试
? 安全性测试：注意进行硬件和软件在各种故障模式下
的测试；最坏配置情况下的测试；错误操作情况下的
测试；多机系统出现故障切换时, 系统的功能, 性能
连续平稳性测试
? 性能强度测试
? 降级能力强度测试
独立 （ 第三方 ） 测试
? 第三方指的是与软件项目甲方, 乙方相对独立
的其它机构 。
? 进行独立测试的目的是进一步加强软件质量保
证工作, 提高软件的质量, 并对软件产品进行
客观评价 。
? 进行第三方独立测试通常有以下优点,
1） 发挥专业技术优势；
2） 发挥独立性优势；
3） 进一步促进承办方的工作 。
测试方法
? 静态测试
? 静态分析
? 代码审查
? 代码走查
? 技术评审
? 桌面检查
? 动态测试
? 白盒测试
? 控制流覆盖
? 数据流覆盖
? 黑盒测试
? 功能分解
? 等价类划分
? 边值分析
? 因果图
? 随机测试
? 猜错法
静态测试
? 代码审查：小组集体阅读讨论检查代码
? 代码走查：小组集体用, 脑, 执行并检查代码
? 桌面检查：由程序员阅读自己编写的程序
? 技术评审：会议形式讨论检查代码
? 静态分析：对代码的机械性、程式化的特性分
析方法，包括控制流分析、数据流分析、接口
分析、表达式分析
黑盒测试
? 这种方法是把 测试对象 看做 一个黑
盒子,测试人员完全不考虑程序内
部的逻辑结构和内部特性，只依据
程序的需求规格说明书，检查程序
的功能是否符合它的功能说明。
? 黑盒测试又叫做 功能测试 或 数据驱
动测试 。
黑盒测试的作用
? 黑盒测试方法是在程序接口上进行测试，
主要是为了发现以下错误,
? 是否有不正确或遗漏了的功能?
? 在接口上,输入能否正确地接受? 能否输出
正确的结果?
? 是否有数据结构错误或外部信息 (例如数据
文件 )访问错误?
? 性能上是否能够满足要求?
? 是否有初始化或终止性错误?
黑盒测试的局限
? 用黑盒测试发现程序中的错误，
必须在 所有可能的输入条件和输
出条件 中确定测试数据，来检查
程序是否都能产生正确的输出。
? 但这是 不可能 的。
示例
? 假设一个 程序 P有 输入量
X和 Y及 输出量 Z。 在字
长为 32位的计算机上运
行。若 X,Y取整数，按
黑盒方法进行穷举测试,
? 可能采用的测试数据组：
232× 232＝ 264
? 如果测试一 组数据需要
1毫秒，一年工作 365×
24小时，完成所有测试
需 5亿年。
白盒测试
? 此方法 把测试对象看做一个透明的盒子,
它允许测试人员利用程序内部的逻辑结
构及有关信息，设计或选择测试用例，
对程序所有逻辑路径进行测试。
? 通过在不同点检查程序的状态，确定实
际的状态是否与预期的状态一致。因此
白盒测试又称为结构测试或逻辑驱动测
试。
白盒测试的作用
? 软件人员使用白盒测试方法，主要想对
程序模块进行如下的检查,
? 对程序模块的 所有独立的执行路径 至少测试
一次；
? 对 所有的逻辑判定, 取, 真, 与取, 假, 的
两种情况都至少测试一次 ；
? 在循环的边界和运行界限内执行循环体；
? 测试 内部数据结构的有效性,等。
白盒测试的局限
? 对一个具有 多重选择和循环嵌套 的程序，
不同的路径数目可能是天文数字 。给出
一个小程序的流程图，它包括了一个执
行 20次的循环。
? 包含的不同执行路径数达 520条，对每一
条路径进行测试需要 1毫秒，假定一年工
作 365 × 24小时，要想把所有路径测试
完，需 3170年。
白盒测试与黑盒测试对比
黑盒测试 白盒测试
优
点
?适用于各测试阶段
?从产品功能角度测试
?容易入手生成测试数据
?可以构成测试数据使特定程
序部分得到测试
?有一定的充分性度量手段
?可获得较多工具支持
缺
点
?某些代码段得不到测试
?如果规格说明有误则无法发
现
?不易进行充分性度量
?不易生成测试数据
?无法对未实现规格说明得部
分测试
?工作量大，通常只用于单元
测试，有引用局限
性
质
是一种确认技术，回答, 我
们在构造一个正确得系统
吗？,
是一种验证技术，回答, 我们
在正确地构造一个系统吗？,
白盒测试
? 控制流（逻辑）测试
? 语句覆盖
? 分支覆盖
? 条件覆盖
? 条件组合覆盖
? 路径覆盖
? 数据流测试
? 全定义使用路径
? 全使用路径
? 全定义路径
? 数据流异常状态图
测试覆盖率
? 采用白盒法进行测试时, 考虑的是测试
用例对程序内部逻辑的覆盖程度 。
? 最彻底的白盒法是覆盖程序中的每一条
路径, 但这往往大到无法实现 。
? 因此采用其它一些标准来量度覆盖的程
度, 并希望覆盖程度尽可能高些 。
例子
func(int A,B,X)
{
if((A>1)&&(B=0))
{X:=X/A};
if((A=2)||(X>1))
{X:=X+1};
}
A>1 and B=0
A=2 OR X>1
X=X/A
X=X/A
YES
YES
NO
NO
a
b
c
e
d
路径
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)
L2 ( a? b ? d )= not{(A>1) and (B=0)} and not{(A=2) or (X>1)}
= { not (A>1) or not (B=0) } and { not (A=2) and not (X>1) }
= not (A>1) and not (A=2) and not (X>1) or
not (B=0) and not (A=2) and not (X>1)
L3 ( a? b? e)= not {(A>1) and (B=0)} and {(A=2) or (X>1)}
= { not (A>1) or not (B=0)} and {(A=2) or (X>1)}
= not (A>1) and (A=2) or not (A>1) and (X>1) or
not (B=0) and (A=2) or not (B=0) and (X>1)
L4 ( a? c ? d )= {(A>1) and (B=0)} and not {(A=2) or (X/A>1)}
= (A>1) and (B=0) and not (A=2) and not (X/A>1)
逻辑覆盖测试的 5种标准
发现错误
的能力 标 准 含 义
1(弱 ) 语句覆盖 每条 语 句至少执行一次
2 判定覆盖 每一判定的每个 分支 至少执行一次
3 条件覆盖
每一判定中的每个 条件,分别按
,真,,
,假, 至少各执行一次
4 判定 /条件覆盖 同时满足 判定覆盖 和 条件覆盖 的要求
5 (强 ) 条件组合覆盖
求出判定中 所有条件的各种可能组合
值，每一可能的条件组合至少执行一
次
测试覆盖率示例（ 1）
覆盖标准 程序结构举例 测试用例 应满足的条件
语句覆盖 A^B=.T,
判定覆盖 A^B=.T,A^B=.F,
A^B T F
A^B T F
测试覆盖率示例（ 2）
覆盖标准 程序结构举例 测试用例应 满足的条件
条件覆盖 A=.T,A=.F,B=.T,B=.F,
判定 /条件
覆盖
A^B=.T.,A^B=.F,
A=.T,A=.F,B=.T,B=.F,
条件组合
覆盖
A=.T,^ B=.T,
A=.T,^ B=.F,
A=.F,^ B=.T
A=.F,^ B=.F,
A^B T F
A^B T F
A^B T F
语句覆盖
? 语句覆盖：选择足够的测试用例, 使得
程序中每个语句至少都能被执行一次 。
? 语句覆盖率：已执行的可执行语句占程
序中可执行语句总数的百分比 。
语句覆盖例
? 测试用例的设计格式
如下
? ?输入的 (A,B,X)，
输出的 (A,B,X)?
? 正好所有的可执行语
句都在 路径 L1上
? 测试用例
? ? (2,0,4),(2,0,3)?
A>1 and B=0
A=2 OR X>1
X=X/A
X=X/A
YES
YES
NO
NO
a
b
c
e
d
分支覆盖
? 分支覆盖又称判定覆盖 。
? 分支覆盖：执行足够的测试用例, 使得
程序中每个判定都获得一次, 真, 值和
,假, 值, 或者说使得程序中的每一个
分支至少都通过一次 。
? 分支覆盖率：已取过, 真, 和, 假, 两
个值的判定占程序中所有条件判定个数
的百分比 。
分支覆盖例
? 选择 路径 L1和 L2
? ? (2,0,4),(2,0,3)?
? 覆盖 ace? L1?
? ? (1,1,1),(1,1,1)?
? 覆盖 abd? L2?
? 或选择路径 L3和 L4
? ? (2,1,1),(2,1,2)?
? 覆盖 abe? L3?
? ? (3,0,3),(3,0,1)?
? 覆盖 acd? L4?
A>1 and B=0
A=2 OR X>1
X=X/A
X=X/A
YES
YES
NO
NO
a
b
c
e
d
条件覆盖
? 条件覆盖：执行足够的测试用例, 使得
判定中的每个子条件都获得所有可能的
结果 。
条件覆盖例 A>1 and B=0
A=2 OR X>1
X=X/A
X=X/A
YES
YES
NO
NO
a
b
c
e
d
判断 条件 取真值 取假值
判断
(一 )
A>1 T1 T1
B=0 T2 T2
判断
(二 )
A=2 T3 T3
X>1 T4 T4
设条件的取值标记
判定 /条件覆盖可选取的 测试用例 如下表
测试用例 通过路径 条件取值 覆盖分支
? (1,0,3),(1,0,4)? abe(L3) b,e
? (2,1,1),(2,1,2)? abe(L3) b,e T1 T2 T3 T4
T1 T2 T3 T4
分支 /条件覆盖
? 分支 /条件覆盖：执行足够的测试用例,
使得判定中每个子条件取到各种可能的
值, 并使每个判定取到各种可能的结果 。
分支 /条件覆盖例 A>1 and B=0
A=2 OR X>1
X=X/A
X=X/A
YES
YES
NO
NO
a
b
c
e
d
判断 条件 取真值 取假值
判断
(一 )
A>1 T1 T1
B=0 T2 T2
判断
(二 )
A=2 T3 T3
X>1 T4 T4
设条件的取值标记
判定 /条件覆盖可选取的 测试用例 如下表
测试用例 通过路径 条件取值 覆盖分支
? (2,0,4),(2,0,3)? ace(L1) c,e
? (1,1,1),(1,1,1)? abd(L2) b,d
T1 T2 T3 T4
T1 T2 T3 T4
条件组合覆盖
? 条件组合覆盖：执行足够的测试用例,
使得每个判定中各条件的所有可能的组
合都出现一次 。
条件组合覆盖例
条件 标记 第一个判断取 真假 分支
A>1
B=0
A>1
B ≠ 0
A ≯ 1
B = 0
A ≯ 1
B ≠ 0
判断 条件 取真值 取假值
判断
(一 )
A>1 T1 T1
B=0 T2 T2
判断
(二 )
A=2 T3 T3
X>1 T4 T4
设条件的取值标记
T1 T2 ① 取 真 分支
T1 T2
T1 T2
② 取 假 分支
③ 取 假 分支
④ 取 假 分支 T1 T2
A>1 and B=0
A=2 OR X>1
X=X/A
X=X/A
YES
YES
NO
NO
a
b
c
e
d
条件组合覆盖例 判断 条件 取真值 取假值
判断
(一 )
A>1 T1 T1
B=0 T2 T2
判断
(二 )
A=2 T3 T3
X>1 T4 T4
设条件的取值标记
A>1 and B=0
A=2 OR X>1
X=X/A
X=X/A
YES
YES
NO
NO
a
b
c
e
d
条件 标记 第二个判断取 真假 分支
A=2
X>1
A=2
X≯ 1
A≠2
X>1
A≠2
X≯ 1
T3 T4 ⑤ 取 真 分支
T3 T4
T3 T4
⑥ 取 真 分支
⑦ 取 真 分支
⑧ 取 假 分支 T3 T4
条件组合覆盖例
测试用例 通过路径 条件取值 覆盖组合号
? (2,0,4),(2,0,3)? ace L1 T1 T2 T3 T4 ①,⑤
? (2,1,1),(2,1,2)? abe L3 T1 T2 T3 T4 ②,⑥
? (1,0,3),(1,0,4)? abe L3 T1 T2 T3 T4 ③,⑦
? (1,1,1),(1,1,1)? abd L2 T1 T2 T3 T4 ④,⑧
设条件的取值标记 条件 标记
第一个判断取
真假 分支
A>1 B=0 T1 T2 ① 取 真 分支
A>1 B≠0 T1 T2 ② 取 假 分支
A≯ 1 B=0 T1 T2 ③ 取 假 分支
A≯ 1 B≠0 T1 T2 ④ 取 假 分支
A>1 and B=0
A=2 OR X>1
X=X/A
X=X/A
YES
YES
NO
NO
a
b
c
e
d
路径覆盖
? 路径测试就是设计足够的测试用例, 覆
盖程序中每一条可能的程序 执行路径 至
少测试一次 。
路径覆盖例
测试用例 通过路径 条件取值
? (2,0,4),(2,0,3)? ace L1 T1 T2 T3 T4
? (1,1,1),(1,1,1)? abd L2
? (1,1,2),(1,1,3)? abe L3
? (3,0,3),(3,0,1)? acd L4
T1 T2 T3 T4
A>1 and B=0
A=2 OR X>1
X=X/A
X=X/A
YES
YES
NO
NO
a
b
c
e
d
T1 T2 T3 T4
T1 T2 T3 T4
条件测试路径选择
? 当程序中判定多于一个时，形成的分支
结构可以分为两类,嵌套型分支结构 和
连锁型分支结构 。
? 对于嵌套型分支结构，若有 n个判定语句，
需要 n+1个测试用例；
? 对于连锁型分支结构,若有 n个判定语
句，需要有 2n个测试用例，覆盖它的 2n条
路径。
循环测试路径选择
? 循环分为 4种不同类型,
? 简单循环
? 连锁循环
? 嵌套循环
? 非结构循环
(1)简单循环
① 零次循环,从循环入口到出口
② 一次循环,检查循环初始值
③ 二次循环,检查多次循环
④ m次循环,检查在多次循环
⑤ 最大次数循环、比最大次数多一次、少
一次的循环
例：求最小值
k = i;
for ( j = i+1; j <= n; j++ )
if ( A[j] < A[k] ) k = j;
k = i ; j = i+1;
j <= n?
A[j]<A[k]?
k = j
j ++
f
d
c
a
b
e
测试用例选择
循环 i n A[ i ] A[ i +1] A[ i +2] k 路 径
0
1
2
1 1 i a c
1 2 1 2 i a b e f c
2 1 i +1 a b d f c
1 3 1 2 3 i a b e f e f c
2 3 1 i +2 a b e f d f c
3 2 1 i +2 a b d f d f c
3 1 2 i +1 a b d f e f c
d 改改 kk 的的 值值,,ee 不不 改改 kk 的的 值值
(2) 嵌套循环
① 对最内层循环做简单循环的全部测试。
所有其它层的循环变量置为最小值；
② 逐步外推，对其外面一层循环进行测试。
测试时保持所有外层循环的循环变量取
最小值，所有其它嵌套内层循环的循环
变量取?典型?值。
③ 反复进行，直到所有各层循环测试完毕。
④ 对全部各层循环同时取最小循环次数，
或者同时取最大循环次数。
连锁循环与非结构循环
(3) 连锁循环
? 如果各个循环 互相
独立,则可以用与
简单循环相同的方
法进行测试。但如
果几个循环不 是互
相独立 的，则需要
使用测试嵌套循环
的办法来处理。
(4) 非结构循环
? 这一类循环应该使
用结构化程序设计
方法重新设计测试
用例。
基本路径测试
? 基本路径测试方法把覆盖的路径数压缩
到一定限度内,程序中的循环体最多只
执行一次 。
? 它是在程序控制流图的基础上,分析控
制构造的环路复杂性, 导出基本可执行
路径集合, 设计测试用例的 方法。设计
出的测试用例要保证在测试中，程序的
每一个可执行语句至少要执行一次。
流图符号
1,程序的控制流图
? 符号○为控制流图的一个结点，表示一
个或多个无分支的 PDL语句或源程序语
句。箭头为边，表示控制流的方向。
流图说明
? 在选择或多分支结构中，分支的汇聚处
应有一个汇聚结点。
? 边和结点圈定的区域叫做区域,当对区
域计数时，图形外的区域也应记为一个
区域。
? 如果判断中的条件表达式是由一个或多
个逻辑运算符 (OR,AND,...) 连接的复
合条件表达式，则需改为 一系列 只有单
个条件的嵌套的判断 。
2,程序环路复杂性
? 程序的环路复杂性给出了 程序基本路径
集中的独立路径条数,这是确保程序中
每个可执行语句至少执行一次所必需的
测试用例数目的上界。
? 从控制流图来看，一条独立路径是至少
包含有一条在其它独立路径中从未有过
的边的路径。
例如
? 在图示的控制流图中，一组独立的
路径是
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
组成了控制流图的一个基本路径集。
3,导出测试用例
? 导出测试用例,确保基本路径集中的每一条路径
的执行 。
? 根据判断结点给出的条件，选择适当的数据以保
证某一条路径可以被测试到 — 用逻辑覆盖方法 。
? 每个 测试用例执行之后, 与预期结果进行比较 。
如果所有测试用例都执行完毕，则可以确信程序
中所有的可执行语句至少被执行了一次。
? 必须注意，一些独立的路径 (如例中的路径 1)，往
往不是完全孤立的，有时它是程序正常的控制流
的一部分，这时，这些路径的测试可以是另一条
路径测试的一部分。
覆盖率要求
? 对单元测试来说, 语句覆盖和分支覆盖
是最基本的要求 。
? 由于程序中错误 （ 异常 ） 处理工作的重
要性以及其结构相对简单, 要求错误处
理要做到路径覆盖 。
? 对质量要求高的软件单元, 可根据情况
提出条件覆盖, 分支／条件覆盖, 条件
组合覆盖以及其它更高的覆盖要求 。
控制流测试的测试用例生成
? 经验测试法
? 通过研究程序选择初始测试用例
? 通过测试执行和覆盖率统计增加测试用例
? 不断运行直至达到要求的测试覆盖率
? 与黑盒测试结合
? 纯粹白盒测试方法
? 列出为实现覆盖所需的全部路径
? 根据每个路径设计测试用例
? 注意测试零次循环、一次循环和最大次数循环
黑盒测试
? 功能分解
? 等价类划分
? 边值分析
? 因果图
? 猜错法
功能分解
? 使用功能抽象的方法把程序分解为功能
单元
? 使用数据抽象的方法产生测试每个功能
单元的数据
? 注意测试功能序列组合和输入数据组合
等价类划分
? 等价类划分是一种典型的黑盒测试方法，
使用这一方法时,完全不考虑程序的内
部结构, 只依据程序的规格说明来设计
测试用例 。
? 使用这一方法设计测试用例要经历 划分
等价类 （列出等价类表）和 选取测试用
例 两步。
划分等价类
? 所谓等价分类，就是把输入数据的可能值划分
为若干 等价类 (等价类是指某个输入域的子集
合。
? 在该集合中，各个输入数据对于揭露程序中的
错误都是等价的 )。
? 因此，可以把全部输入数据合理地划分为若干
等价类，在每一个等价类中取一个数据作为测
试的输入条件，这样就可以少量的代表性测试
数据，来取得较好的测试结果。
有效等价类和无效等价类
① 有效等价类,
? 是指对于程序的规
格说明来说，是合
理的，有意义的输
入数据构成的集合 。
② 无效等价类,
? 是指对于程序的规
格说明来说，是不
合理的，无意义的
输入数据构成的集
合。
? 在设计测试用例时，要同时考虑有效等
价类和无效等价类的设计。
划分等价类等价类的原则,1
? 如果输入条件规定了取值范围，或值的个数，
则可以确立一个有效等价类和两个无效等价类。
? 例如对输入 ? …… 项数可以从 1到 999 …… ?
? 则有效等价类是? 1≤项数 ≤999?
? 两个无效等价类是
? ? 项数＜ 1?或? 项数＞ 999?
划分等价类等价类的原则,2
? 如果输入条件规定了输入值的集合，或
者是规定了? 必须如何 ?的条件，这时
可确立一个有效等价类和一个无效等价
类。
? 例如在 Pascal语言中对变量标识符规定为
? 以字母打头的 …… 串 ?
? 所有以字母打头的构成有效等价类
? 不在此集合内（不以字母打头）的归于无效
等价类。
划分等价类等价类的原则,3
? 如果输入条件是一个布尔量，则可以确
定一个有效等价类和一个无效等价类。
划分等价类等价类的原则,4
? 如果规定了输入数据的一组值，而且程序要对
每个输入值分别进行处理。 这时可为 每一个输
入值确立一个有效等价类，此外针对这组值确
立一个无效等价类，它是所有不允许的输入值
的集合。
? 例如，在教师上岗方案中规定对教授、副教授、讲师
和助教分别计算分数，做相应的处理。因此可以确定 4
个有效等价类为教授、副教授、讲师和助教，一个无
效等价类，它是所有不符合以上身分的人员的输入值
的集合。
划分等价类等价类的原则,5
? 如果规定了输入数据必须遵守的规则，
则可以确立一个有效等价类（符合规则）
和若干个无效等价类（从不同角度违反
规则）。
? 例如,Pascal语言规定 ?一个语句必须
以分号‘ ;’结束?。这时，可以确定一
个有效等价类 ?以‘ ;’结束?，若干个
无效等价类 ?以‘,’结束?、?以‘,’
结束?、?以‘ ’结束?、?以 LF结束?
等。
注意点
1,划分等价类不仅要要考虑代表, 有效,
输入值的有效等价类，还需考虑代表,
无效, 输入值的无效等价类。
2,每一无效等价类至少要用一个测试用例
，不然就可能漏掉某一类错误，但允许
若干有效等价类合用同一个测试用例，
以便进一步减少测试的次数。
确立测试用例
? 在确立了等价类之后，建立等价类表，
列出所有划分出的等价类。
确立测试用例
再从划分出的等价类中按以下原则选择测
试用例,
(1) 为每一个等价类规定一个唯一编号；
(2) 设计一个新的测试用例，使其 尽可能多地
覆盖尚未被覆盖的有效等价类,重复这一步，
直到所有的有效等价类都被覆盖为止；
(3) 设计一个新的测试用例，使其 仅覆盖一个
尚未被覆盖的无效等价类,重复这一步，直到
所有的无效等价类都被覆盖为止。
等价类划分设计测试用例实例
? 某一 PASCAL语言版本中规定,
? ? 标识符是由字母开头, 后跟字母或
数字的任意组合构成 。 有效字符数为 8
个, 最大字符数为 80个 。?
? ? 标识符必须先说明, 再使用 。?
? 在同一说明语句中, 标识符至少必
须有一个 。?
建立输入等价类表
覆盖所有等价类的测试用例
① VAR x,T1234567,REAL； BEGIN x,= 3.414； T1234567,=
2.732；,..…
(1),(2),(4),(8),(9),(12),(14)
② VAR, REAL； (3)
③ VAR x，,REAL; (5)
④ VAR T12345678,REAL； (6)
⑤ VAR T12345......,REAL； (7) 多于 80个字符
⑥ VAR T$,CHAR； (10)
⑦ VAR GOTO,INTEGER； (11)
⑧ VAR 2T,REAL； (13)
⑨ VAR PAR,REAL ； BEGIN,....,PAP,= SIN (3.14 * 0.8) / 6；
(15)
边值分析
? 长期经验表明,大量的错误是发生在输入或输
出范围的边界上，而不是在输入范围的内部
? 边界是指相当于输入等价类和输出等价类而言，
稍高于其边界值及稍低于其边界值的一些特定
情况
? 使用边界值分析方法设计测试用例，应对确定
的边界,选取正好等于，刚刚大于，或刚刚小
于边界的值做为测试数据,而不是选取等价类
中的典型值或任意值做为测试数据
示例
? 在做三角形计算时，要输入三角形的三个边长
A,B和 C
? 这三个数值应当满足
A＞ 0,B＞ 0,C＞ 0,
A＋ B＞ C,A＋ C＞ B,B＋ C＞ A
? 如果把六个不等式中的任何一个大于号?＞?
错写成大于等于号? ≥?，那就不能构成三角
形
? 问题恰出现在容易被疏忽的边界附近
边值分析使用原则
? 如果输入条件规定了取值范围或数据个
数，则可选择正好等于边界值、刚刚在
边界范围内和刚刚超越边界外的值进行
测试
? 针对规格说明的每个输入条件，使用上
述原则
? 对于有序数列，选择第一个和最后一个
因果图的适用范围
? 如果在测试时必须考虑 输入条件的
各种组合,可使用一种适合于描述
对于多种条件的组合，相应产生多
个动作的形式来设计测试用例，这
就需要利用因果图。
? 因果图方法最终生成的就是判定表。
它适合于检查程序输入条件的各种
组合情况。
因果图的基本步骤
(1) 分析软件规格说明描述中，哪些是原因 (即输入条
件或输入条件的等价类 )，哪些是结果 (即输出条件 )，
并给每个原因和结果赋予一个标识符。
(2) 分析软件规格说明描述中的语义，找出原因与结果
之间，原因与原因之间对应的是什么关系? 根据这些
关系，画出因果图。
(3) 由于语法或环境限制，有些原因与原因之间，原因
与结果之间的组合情况不可能出现。为表明这些特殊
情况，在因果图上用一些记号标明约束或限制条件。
(4) 把因果图转换成判定表。
(5) 把判定表的每一列拿出来作为依据，设计测试用例 。
因果图基本符号
? 通常在因果图中用 Ci表示原因，用 Ei表示结果，
各结点表示状态，可取值? 0?或? 1?。? 0?
表示某状态不出现，? 1?表示某状态出现。
? 主要的原因和结果之间的关系有,
因果图基本符号
? 表示约束条件的符号：为了表示原因与原因之
间，结果与结果之间可能存在的约束条件，在
因果图中可以附加一些表示约束条件的符号。
示例
? 有一个处理单价为 5角钱的饮料的自动售货机
软件测试用例的设计。其规格说明如下,
? 若 投入 5角钱或 1元钱的硬币,押下 〖橙汁〗
或〖啤酒〗的按钮，则相应的饮料就送出来。
? 若售货机 没有零钱找,则一个显示〖零钱找
完〗的红灯亮，这时在投入 1元硬币并押下
按钮后，饮料不送出来而且 1元硬币也退出
来；
? 若 有零钱找,则显示〖零钱找完〗的红灯灭，
在送出饮料的同时退还 5角硬币。?
示例
(1) 分析这一段说明，列出原因和结果
原因, 1,售货机有零钱找
2,投入 1元硬币
3,投入 5角硬币
4,押下橙汁按钮
5,押下啤酒按钮
建立中间结点，表示处理中间状态
11,投入 1元硬币且押下饮料按钮
12,押下〖橙汁〗或〖啤酒〗的按钮
13,应当找 5角零钱并且售货机有零钱找
14,钱已付清
示例
结果,21,售货机〖零钱找完〗灯亮
22,退还 1元硬币
23,退还 5角硬币
24,送出橙汁饮料
25,送出啤酒饮料
(2) 画出因果图。 所有原因结点列在左边，所有结果结点
列在右边。
(3) 由于 2 与 3, 4 与 5 不能同时发生,分别加上约束条
件 E。
(4) 因果图
(5) 转换成判定表
?
随机测试
? 从所有可能的输入值中随机选取测试输
入数据的方法
? 使数据在规定的取值范围内并服从预期
的概率分布
? 基于运行剖面的测试方法是可靠性测试
的主要方法
? 预期结果可以由人工或定性的方法确定
? 是强度测试的有效手段
猜错法
? 可以靠经验和直觉推测程序中可能存在的各种
错误，从而有针对性地编写检查这些错误的例
子
? 列举出程序中所有可能有的错误和容易发生错
误的特殊情况，根据它们选择测试用例
? 有力的补充
? 充分发挥敏锐、经验等能力
? 直接切入可能的错误，直接定位
? 需要丰富的经验和领域知识
测试产品（文档）
? 测试计划
? 测试说明
? 测试报告
? 测试用例单
? 测试记录
? 问题报告单
软件测试计划
1 范围
1.1 标识
1.2 系统概述
1.3 文档概述
1.4 与其它计划的关系
2 引用文档
3 软件测试环境
3.1 软件项
3.2 硬件和固件项
3.3 权限
3.4 安装、测试和控制
4 正式合格性测试
4.X CSCI名称和项目唯一
标识号
4.X.1 总体测试要求
4.X.2 测试级
4.X.3 测试类
4.X.4 测试定义
4.X.4.Y 测试名称和项目唯
一标识号
4.X.5 测试进度
5 数据记录、整理和分析
软件测试说明
1 范围
1.1 标识
1.2 系统概述
1.3 文档概述
1.4 与其它计划的关系
2 引用文档
3 正式合格性测试准备
3.X 测试名称和项目唯一标识号
3.X.1 计划
3.X.2 测试准备过程
3.X.2.1 硬件要求
3.X.2.2 软件准备
3.X.2.3 其它测试准备
4 正式合格性测试说明
4.X 测试名称和项目唯一标识号
4.X.Y 测试用例名称和项目唯一
标识号
4.X.Y.1 需求可追踪性
4.X.Y.2 初始化
4.X.Y.3 测试输入
4.X.Y.4 预期测试结果
4.X.Y.5 评估测试结果的标准
4.X.Y.6 测试过程
4.X.Y.7 前提和约束
软件测试报告
1 范围
1.1 标识
1.2 系统概述
1.3 文档概述
1.4 与其它计划的关系
2 引用文档
3 测试概述
3.1 正式合格性测试名称及
项目的唯一标识号
3.1.1 小结
3.1.2 测试记录
4 测试结果
4.X 正式合格性测试名称及
项目的唯一标识号测试
结果
4.X.Y 测试用例名称和项目
唯一标识号
4.X.Y.1 测试结果
4.X.Y.2 测试过程中的差异
情况
5 CSCI评估和建议
5.1 CSCI评估
5.2 改进建议
测试记录表
测试用例标识
测试完成日期
结果
问题报告单
软件问题报告
编号
日期
提出人
1 软件项标题,
2 软件项版本 /发布号,
3 优先级,
关键／紧急／常规 （ 划出选择 ）
4 问题描述,
5 环境描述,
6 建议解决办法,
7 评审决定,
8备注,
谢谢！
68389085（ O）
68389504（ H）
mdtang@btamail.net.cn
