软件测试工程师培训
软件测试方法论
主要内容
1 软件测试方法概述
2 软件测试规范
3 软件测试用例设计－黑盒测试
4 软件测试用例设计－白盒测试
5小结
1 软件测试方法概述
软件测试活动及信息流
测试方法
生成测试用例的信息来源
小结
软件测试活动及信息流
测试是从大量的测试用例中选择有限的测试用例发现
软件中的大部分缺陷的一种技术
好的测试用例的4个特性：
1. 检测软件质量的有效性，是否能发现缺陷，或至少可
能发现缺陷；
2. 可仿效的测试用例可以测试很多内容，因而减少测试
用例的数量；
3. 经济性，测试用例的执行、分析和调试是否经济
4. 测试用例的可修改性，每次软件修改后对测试用例的
维护成本
测试活动
测试活动
1 测试条件取决于被测试验证的项目或事
件。如等价划分、边界值分析、因果图
等。
测试条件是被测环境的描述，可以用多
种方式描述：如简单的语言，表格项形
式或类似于流图的图表形式；
标识测试条件的活动最好与开发活动
（即V模型左边的活动）并行开展
测试活动
2 设计测试用例
确定“怎样测试”。
测试用例（test case）是按一定顺序执行的与
测试目标（test object, 测试理由或目的）相关
的一系列测试。测试用例设计将产生许多测试
所包括的输入值、期望结果及其他任何运行测
试的有关信息，如环境要求。
期望输出包括应输出或建立的内容，应修改或
更新或应删除的内容。期望输出集可以是一个
很大的集合。
测试活动
一个测
试用例
测试活动
3 开发测试用例
包括准备测试脚本、测试输入、测试数据以及期望输出。
测试脚本（test script）是 具有正规语法的数据和指令的集合，
在测试执行自动工具使用中，通常以文件形式保存；
必须先完成测试用例的先决条件（precondition），然后再执行测
试。测试用例可能要求专门的硬件或软件，如网络环境或打印机
等；
期望输出可以组成成文件形式用于自动工具。对于手动测试，期
望输出仅仅只是简单地记录在手工测试过程或脚本中。设置用于
自动比较的期望输出比设置用于手工测试的期望输出复杂得多。
在自动工具中要求每项内容都要拼写正确，而在手工测试中要求
没这么严格。
测试开发的任何工作可以提前进行（相对V模型左边的活动进行）
，以后可以节省时间。
测试活动
4 执行测试用例
对于手动测试来讲，测试者按事先准
备好的手工过程进行测试，测试者输入
数据、观察输出、记录发现的问题。
对于自动测试，可能只需要启动测试
工具，并告诉工具执行哪些测试用例；
测试执行只能在软件开发完成后进行，
即V模型右边的活动。
测试活动
5 将测试结果与期望输出进行比较
应该对每次测试的实际输出进行分析研究，判
断软件功能是否正确。
该验证可以是非正的测试者主观判断，也可以
是将实际输出与期望输出进行严格准确的比较。
一些信息比较，如可以在执行测试时进行显示
屏幕上的信息，另一些输出比较，如修改数据
库记录，只能在测试执行结束后进行。自动测
试一般结合了这两种方法。
测试阶段的信息流
测试阶段的信息流
测试阶段的输入信息有两类：
软件配置：这是测试的对象，包括需求说明书、设计
说明书和被测的源程序等。
测试配置：包括测试计划、测试步骤、测试用例（测
试数据），以及具体实施测试的测试程序、测试工具
等
测试方法
静态方法
动态方法
黑盒测试
白盒测试
静态方法和动态方法
静态方法的主要特征是在用计算机测试源程序
时，计算机并不真正运行被测试的程序，只对
被测程序进行特性分析。因此，静态方法常称
为“分析”，静态分析是对被测程序进行特性
分析的一些方法的总称。
动态方法的主要特征是计算机必须真正运行被
测试的程序，通过输入测试用例，对其运行情
况(输入/输出的对应关系)进行分析。
黑盒测试
黑盒测试（Black—box Testing）又称功能
测试、数据驱动测试或基于规格说明的测试，是
一种从用户观点出发的测试。用这种方法进行测
试时，被测程序被当作一个黑盒，在不考虑程序
内部结构和内部特性，测试者只知道该程序输入
和输出之间的关系或程序的功能的情况下，依靠
能够反映这一关系和程序功能的需求规格说明书
考虑确定测试用例和推断测试结果的正确性。软
件的黑盒测试被用来证实软件功能的正确性和可
操作性。
白盒测试
白盒测试（White—box Testing）又
称结构测试、逻辑驱动测试或基于程序的
测试。它依赖于对程序细节的严密检验，
针对特定条件和/与循环集设计测试用例，
对软件的逻辑路经进行测试。在程序的不
同点检验“程序的状态”以判定其实际情
况是否和预期的状态相一致。软件的白盒
测试用来分析程序的内部结构。
白盒测试
白盒测试要求对某些程序的结构特性做到一定程度的
覆盖，或者说是“基于覆盖的测试” 。最为常见的程
序结构覆盖有 ：
语句覆盖：它要求被测程序的每一可执行语句在测试中尽可
能都检验过，这是最弱的逻辑覆盖准则；
分支覆盖或判定覆盖：要求程序中所有判定的分支尽可能得
到检验；
条件覆盖：当判定式中含有多个条件时，要求每个条件的取
值均得到检验；
判定／条件覆盖：同时考虑条件的组合值及判定结果的检验；
路径覆盖：只考虑对程序路径的全面检验。
取得测试覆盖的方法——程序插装
白盒测试
既然黑盒测试是测试软件与需求的一致
性，为什么还要白盒测试？
编程是容易发生逻辑错误和作出不正确的假
设
如对执行路径假设不正确，会产生设计错误，
白盒测试能发现这样的错误
录入错误是随机的
黑盒测试与白盒测试的比较
黑 盒 测 试 白 盒 测 试
测 试 规 划
根据用户的规格说明，即针对命
令、信息、报表等用户界面及体
现它们的输入数据与输出数据之
间的对应关系，特别是针对功能
进行测试。
根据程序的内部结构，比如语句的
控制结构，模块间的控制结构以及
内部数据结构等进行测试。
特
点
优 点 能站在用户立场上进行测试。 能够对程序内部的特定部位进行覆
盖测试。
缺 点 •不能测试程序内部特定部位。
•如果规格说明有误，则无法发现。
• 无法检验程序的外部特性。
• 无法对未实现规格说明的程序内
部欠缺部分进行测试。
方 法 举 例
基于图的测试
等价类划分
边值分析
比较测试
语句覆盖
判定覆盖
条件覆盖
判定/条件覆盖
基本路径覆盖
循环覆盖
模块接口测试
测试阶段与测试方法
测试阶段 目的 执行者 测试方法
单元测试 查找独立模块中逻辑错误、
数据错误和算法错误
软件工程师 白盒测试
集成测试 查找模块之间接口错误 软件工程师
测试人员
白盒测试、自顶向
下或自底向上
确认测试 确认软件是否满足软件需求 测试人员 黑盒测试
模拟用户操作
系统测试 对系统中各个组成部分进行
综合性检验
测试人员 黑盒测试
模拟用户操作
回归测试 确认软件变更后是否仍满足
软件需求
测试人员 黑盒测试
模拟用户操作
α测试与β
测试
用户 黑盒测试
模拟用户操作
验收测试 确认软件是否满足用户需求 用户、项目组
测试人员
黑盒测试
模拟用户操作
测试信息来源
基于软件规约生成测试用例
基于软件设计生成测试用例
基于程序生存测试用例
小结
软件测试主要工作就是确定合适的测试
用例；
测试过程贯穿在整个软件开发活动中；
测试方法： 动态、静态、黑盒、白盒等
2软件测试用例设计－黑盒测试
概述
等价类划分
因果图
边值分析
判定表驱动测试
正交实验设计法
自动测试用例生成方法
小结
黑盒测试概述
这种方法是把测试对象看做一个黑
盒子，测试人员完全不考虑程序内
部的逻辑结构和内部特性，只依据
程序的需求规格说明书，检查程序
的功能是否符合它的功能说明。
黑盒测试又叫做功能测试或数据驱
动测试。
黑盒测试方法是在程序接口上进行
测试，主要是为了发现以下错误:
是否有不正确或遗漏了的功能?
在接口上，输入能否正确地接受?
能否输出正确的结果?
是否有数据结构错误或外部信息(例
如数据文件)访问错误?
性能上是否能够满足要求?
是否有初始化或终止性错误?
黑盒测试目标
用黑盒测试发现程序中的错误，
必须在所有可能的输入条件和
输出条件中确定测试数据，来
检查程序是否都能产生正确的
输出。
但这是不可能的。
假设一个程序P有输入量X和Y及输出量Z。在
字长为32位的计算机上运行。若X、Y取整数，
按黑盒方法进行穷举测试：
可能采用的
测试数据组：
232×232
＝264
如果测试一
组数据需要1毫秒，一年工作365× 24小时，
完成所有测试需5亿年。
测试用例设计方法－等价
类划分
选取测试用例
等价类划分的办法是把程序的输入域划
分成若干部分，然后从每个部分中选取
少数代表性数据当作测试用例。
在分析需求规格说明的基础上划分等价
类，列出等价类表。
等价类
所谓等价类是指某个输入域的集合。它
表示，如果用集合中的一个输入条件作
为测试数据进行测试不能发现程序中的
错误，那么使用集合中的其它输入条件
进行测试也不可能发现错误。也就是说，
对揭露程序中的错误来说，集合中的每
个输入条件是等效的。
有效等价类和无效等价类
在考虑等价类时，应该注意区别两种不同的情
况：
*有效等价类：有效等价类指的是对程序的规
格说明是有意义的、合理的输入数据所构成的
集合。在具体问题中，有效等价类可以有一个，
也可以是多个。
*无效等价类：无效等价类指对程序的规格说
明是不合理的或无意义的输入数据所构成的集
合。对于具体的问题，无效等价类至少应有一
个，也可能有多个。
等价类
输入条件 有效等价类 无效等价类
输入条件：…项数可以从1到999…
有效等价类为“1〈项数〈999”
无效等价类为“项数<1”及“项数>999”
经典例子
“输入三个整数
作为三边的边长
构成三角形。当
此三角形为一般
三角形、等腰三
角形及等边三角
形时，分别做计
算…”
注意输入和输出
条件
有效等价类
覆盖有效等价类的测试用例：
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）
无效等价类
2. 问题讨论
问题：给出下面的有效和无效等价类
输入条件：“…统计全国各省、市、自
治区的人口…”
输入条件：“标识符应以字母开头…”
输入条件：长度为1-20的字符串
输入条件：数据库中的值域, CHAR(20),
NOT NULL
2. 2 测试方法－因果图
采用因果图方法（Cause一Effect
Graphics）能够帮助我们按一定步骤，高
效率地选择测试用例，同时还能为我们
指出，程序规格说明描述中存在着什么
问题。
2. 因果图介绍
4种符号分别表示了规格
说明中向4种因果关系
因果图中使用了简单的逻
辑符号，以直线联接左右
结点。左结点表示输入状
态（或称原因），右结点
表示输出状态（或称结果）
。
Ci表示原因，通常置于图
的左部；ei表示结果，通
常在图的右部。ci和ei均
可取值0或1，0表示某状
态不出现，1表示某状态
出现。
关系
①恒等：若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。“与”也可有任意个输入。
约束
输入状态相互之
间还可能存在
某些依赖关系
某些输入条件本
身不可能同时
出现。输出状
态之间也往往
存在约束
输入条件约束类型
对于输入条件的约束有以下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。
输出条件约束类型
输出条件的约束只有：
M约束（强制）：若结果a是1，则结果b
强制为0。
2. 步骤
①分析程序规格说明的描述中，哪些是原因，
哪些是结果。原因常常是输入条件或是输入
条件的等价类。而结果是输出条件。
②分析程序规格说明的描述中语义的内容，
并将其表示成连接各个原因与各个结果的“
因果图”。
步骤
③由于语法或环境的限制，有些原因和
结果的组合情况是不可能出现的。为表
明这些特定的情况，在因果图上使用若
干个特殊的符号标明约束条件。
④把因果图转换成判定表。
⑤把判定表中每一列表示的情况写成测试用例。
2. 例子
软件规格说明书
“第一列字符必须是A或B，第二列字符
必须是一个数字，在此情况下进行文件
的修改。但如果第一列字符不正确，则
给出信息L，如果第二列字符不是数字，
则给出信息M。”
原因和结果
原因：
1——第一列字符是A；
2——第一列字符是B；
3——第二列字符是一数字。
结果：
21——修改文件；
22 ——给出信息L；
23——给出信息M。
因果图和具有约束的因果图
11为中间节点；
考虑到原因1和原因2不可能同时为1，因此在
因果图上施加E约束。
判定表
根据因果图建立如下的判定表
表中8种情况的左面两列情况中，原因①和原因②同时为1，这是不可能
出现的，故应排除这两种情况。表的最下一栏给出了6种情况的测试用
例，这是我们所需要的数据。
2. 讨论
在较为复杂的问题中，这个方法常常是
十分有效的，它能有力地帮助我们确定
测试用例
如果哪个开发项目在设计阶段就采用了
判定表，也就不必再画因果图，而是可
以直接利用判定表设计测试用例了。
2. 3 测试用例设计方法－边值
分析
在软件设计和程序编写中，常常对于规
格说明中的输入域边界或输出域边界不
够注意，以致形成一些差错。实践证明，
在设计测试用例时，对边界附近的处理
必须给予足够的重视，为检验边界附近
的处理专门设计测试用例，常常取得良
好的测试效果。
2. 边值分析遵循的原则
①如果输入条件规定了取值范围，或是规定了
值的个数，应以该范围的边界内及刚刚超出范
围的边界外的值，或是分别对最大、最小个数
及稍小于最小、稍大于最大个数作为测试用例。
例如，如果程序的规格说明中规定：“重量在
10公斤至50公斤范围内的邮件，其邮费计算
公式为……”。作为测试用例，我们应取10
及50，还应取,,及等。
如果另一问题规格说明规定：“某输入文件可
包含1至255个记录，……”，则测试用例可
取1和255，还应取0及256等。
遵循以下几条原则
②针对规格说明的每个输出条件使用前
面的第（1）条原则。例如，某程序的规
格说明要求计算出“每月保险金扣除额
为0至1165．25元”，其测试用例可取0
．00及1165．2、还可取一0．01及1165
．26等。如果另一程序属于情报检索系
统，要求每次”最多显示1条情报摘要”
，这时我们应考虑的测试用例包括1和4
，还应包括0和5等。
遵循以下几条原则
③如果程序规格说明中提到的输入或输
出域是个有序的集合（如顺序文件、表
格等），就应注意选取有序集的第一个
和最后一个元素作为测试用例。
④分析规格说明，找出其它的可能边界
条件。
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所示。
学生考卷评
分和成绩
统计程序
输入数据
的形式
该程序应给出4个输出报告，即：
①按学生学号排序，每个学生的成绩
（答对的百分比）和等级报告。
②按学生得分排序，每个学生的成绩。
③平均分数，最高与最低分之差。
④按题号排序，每题学生答对的百分
比。
2. 4 判定表驱动测试
在一些数据处理问题中，某些操作是否
实施依赖于多个逻辑条件的取值。也即
在这些逻辑条件取值的组合所构成的多
种情况下，分别执行不同的操作。处理
这类问题的一个非常有力的分析和表达
工具是判定表（Decision Table）。
2. 例子1
一张关于科技书阅读指南的判定驱动
表：3个问题8种情况
判定表组成
条件桩（Condition Stub）
动作桩（Action Stub）
条件项（Condition Entity）
动作项（Action Entity）
规则及规则合并
任何一个条件组合的特定取值及其相应要执
行的操作称为规则。在判定表中贯穿条件项
和动作项的一列就是一条规则。显然，判定
表中列出多少组条件取值，也就有多少条规
则，即条件项和动作项有多少列。
化简 就是规则合并
有两条或多条规则
具有相同的动作，
并且其条件项之间
存在着极为相似的关系
两条规则合并成一条 两条规则的进一步合并
一个规则合并的例子
一个规则合并的例子
2. 例子2
问题要求：”……对功率大于50马力的
机器、维修记录不全或已运行10年以上
的机器，应给予优先的维修处理……”
假定，“维修记录不全”和“优先维修
处理”均已在别处有更严格的定义
按5步建立判定表
建立判定表的步骤
①确定规则的个数。这里有3个条件，每个条
件有两个取值，故应有2*2*2=8种规则。
②列出所有的条件茬和动作茬。
③填人条件项。为防止遗漏可从最后1行条件
项开始，逐行向上填满乙如第三行是：
Y N Y N Y N Y N
第二行是：
Y Y N N Y Y N N
等等。
建立判定表的步骤
④填人动作桩和动作顶。这样便得到
形如图的初始判定表。
建立判定表的步骤
⑤化简。合并相似规则后得到图。
2. 判定表在功能测试中的
应用
一软件规格说明
(1)当条件1和条件2满足，并且条件3和
条件4不满足，或者当条件1、3和条件4
满足时，要执行操作1。
(2)在任一个条件都不满足时，要执行操
作2。
(3)在条件1不满足，而条件4被满足时，
要执行操作3。
规则
只给出了16种规则中的4种
根据规格说明得到的判定表 默许的规则
判定表的优点和缺点
优点：
它能把复杂的问题按各种可能的情况一
一列举出来，简明而易于理解，也可避
免遗漏。
缺点：
不能表达重复执行的动作，例如循环结
构。
其他？？
使用判定表设计测试用例的
Beizer条件
①规格说明以判定表形式给出，或是很容易转换成判
定表。
②条件的排列顺序不会也不应影响执行哪些操作。
③规则的排列顺序不会也不应影响执行哪些操作。
④每当某一规则的条件已经满足，并确定要执行的操
作后，不必检验别的规则。
⑤如果某一规则得到满足要执行多个操作，这些操作
的执行顺序无关紧要。
B。Beizer提出这5个必要条件的目的是为了使操作的
执行完全依赖于条件的组合。其实对于某些不满足这
几条的判定表，同样可以借以设计测试用例，只不过
尚需增加其它的测试用例罢了。
正交实验设计法
把软件功能测试作为实验的一种，从大量的实
验点中选出适量有代表性的点，应用依据伽罗
瓦理论导出的“正交表”，合理安排实验的一
种科学的实验设计方法。
从规约中找出影响其功能实现的操作对象和外
部因素作为因子，因子的取值作为状态，构造
因素分析表，利用正交表进行各因子的专题组
合，构造有效的测试数据集，并由此建立因果
图。
自动测试用例设计
一些测试工具可以进行部分测试用例自动化，
“测试输入生成工具”，该方法也可以用于某
些场合，但自动工具不可能完全替代智力的测
试活动；
自动方式可以生成大量的测试用例，但他不区
分哪些测试是最重要的。这些要求有创造力的
智力活动只能由测试人员完成。
所有测试生成工具依赖于生成测试的算法，工
具比使用相同算法的测试人员的测试更彻底、
更精确，但人工测试时可以考虑附加测试。
三种测试输入生成工具
基于代码测试输入生成
基于界面测试生成
基于规格说明测试生成
基于代码测试输入生成
通过检测软件代码结构生成测试输入。
通过代码的路径由判断点确定的段组成。
自动生成每个路径段逻辑覆盖条件的轮
廓文件。与覆盖工具一起使用较好。
只产生测试输入，还需要对测试输出进
行比较，不能判断软件产生的输出是否
正确，只是说明代码应该做什么。也不
能发现丢失的代码
另一种方法：可以生成满足较小变化测
试准则的测试。变化测试（Mutation
test）是指代码或输入做较小的改变，
检测系统是否可以正确地处理或测试稍
微改变的版本。该方法可以检查系统的
容错能力和测试套件的充分性。
基于界面测试生成
基于规格说明测试生成
在规格说明形式化并可被工具分析的前
提下，基于规格说明测试工具可以生成
测试输入及期望结果；如果面向对象规
格说明足够严格的话，这种工具还可以
进行面向对象规格说明的测试。
例如，如果一个输入域的允许范围被严
格定义，那么工具可以产生边界值以及
有效等价类和无效等价类的样值。
某些基于规格说明的工具可以进行结构
化的英文规格说明或因果图的测试，可
以发现一些规格说明的缺陷，如规格说
明含混或冗长
好处是检查软件应该做什么，而不是软
件做了什么。
从规格说明中推导测试用例越枯燥，则
这类工具的潜力就越大。
自动测试用例生成的优点
自动化测试用例生成用于设计的繁琐部
分，如激活每个菜单项或者从已知的数
据范围计算边界值；
可以生成针对源程序的一套完成的测试
用例（代码、界面和规格说明）
可以发现某种类型的缺陷，如丢失连接，
非工作窗口项或者不符合规格说明的软
件；
自动测试用例生成的限制
基于代码方法不能生成期望输出
基于界面方法只能产生部分期望输出
基于代码和基于界面方法不能发现规格说明的
缺陷；
基于规格说明的方法依赖于规格说明的质量；
所有的方法可以产生大量的测试，而实际操作
起来比较困难；
测试前仍需要专家判断产生的测试的必要性，
并考虑任何工具都无法产生的测试；
小结
理解和熟练使用4种进行测试用例设计的
方法：等价类划分、因果图、边值分析、
判定表驱动；
自动测试用例设计的原理和方法，
4、 软件测试用例设计－白盒测试
概述
程序结构分析
逻辑覆盖
路径分析
域测试
程序插装
程序变异
小结
概述
此方法把测试对象看做一个透明的
盒子，它允许测试人员利用程序内
部的逻辑结构及有关信息，设计或
选择测试用例，对程序所有逻辑路
径进行测试。
通过在不同点检查程序的状态，确
定实际的状态是否与预期的状态一
致。因此白盒测试又称为结构测试
或逻辑驱动测试。
软件人员使用白盒测试方法，主要想对程序
模块进行如下的检查：
对程序模块的所有独立的执行路径所有独立的执行路径至少测
试一次；
对所有的逻辑判定所有的逻辑判定，取取““真真””与取与取““假假””
的两种情况都至少测试一次的两种情况都至少测试一次；
在循环的边界和运行界限内执行循环体；
测试内部数据结构的有效性内部数据结构的有效性，等。
对一个具有多重选择和循环嵌套的
程序，不同的路径数目可能是天文
数字。给出一个小程序的流程图，
它包括了一个执行20次的循环。
包含的不同执行路径数达520条，
对每一条路径进行测试需要1毫秒，
假定一年工作365 × 24小时，要
想把所有路径测试完，需3170年。
程序结构分析－基本路径测试
基本路径测试方法把覆盖的路径数压缩
到一定限度内，程序中的循环体最多只
执行一次。
它是在程序控制流图的基础上，分析控
制构造的环路复杂性，导出基本可执行
路径集合，设计测试用例的方法。设计
出的测试用例要保证在测试中，程序的
每一个可执行语句至少要执行一次。
. 程序的控制流图
符号○为控制流图的一个结点，表
示一个或多个无分支的PDL语句或
源程序语句。箭头为边，表示控制
流的方向。
在选择或多分支结构中，分支的汇聚处
应有一个汇聚结点。
边和结点圈定的区域叫做区域，当对区
域计数时，图形外的区域也应记为一个
区域。
如果判断中的条件表达式是由一个或多
个逻辑运算符 (OR, AND, NAND,
NOR) 连接的复合条件表达式，则需
要改为一系列只有单条件的嵌套的判断。
. 程序环路复杂性
程序的环路复杂性给出了程序基本
路径集中的独立路径条数，这是确
保程序中每个可执行语句至少执行
一次所必需的测试用例数目的上界。
从控制流图来看，一条独立路径是
至少包含有一条在其它独立路径中
从未有过的边的路径。
例如，在图示的控制流图中，一组独立
的路径是
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组成
了控制流图的一个基本路径集。
. 导出测试用例
导出测试用例，确保基本路径
集中的每一条路径的执行。
根据判断结点给出的条件，选
择适当的数据以保证某一条路
径可以被测试到 — 用逻辑覆盖
方法。
每个测试用例执行之后，与预期结果进
行比较。如果所有测试用例都执行完毕，
则可以确信程序中所有的可执行语句至
少被执行了一次。
必须注意，一些独立的路径(如例中的
路径1)，往往不是完全孤立的，有时它
是程序正常的控制流的一部分，这时，
这些路径的测试可以是另一条路径测试
的一部分。
逻辑覆盖
语句覆盖
判定覆盖
条件覆盖
判定－条件覆盖
条件组合覆盖
路径覆盖。
逻辑覆盖是以程序内部的逻辑结构为
基础的设计测试用例的技术。它属白
盒测试。
语句覆盖
语句覆盖就是设计若干个测试用例，
运行被测程序，使得每一可执行语
句至少执行一次。
在图例中，正好所有的可执行语句
都在路径L1上，所以选择路径 L1设
计测试用例，就可以覆盖所有的可
执行语句。
测试用例的设计格式如下
【输入的(A, B, X)，输出的(A, B, X)】
为图例设计满足语句覆盖语句覆盖的测试用例是:
【(2, 0, 4)，(2, 0, 3)】
覆盖 ace【L1】
判定覆盖
判定覆盖就是设计若干个测试用
例，运行被测程序，使得程序中
每个判断的取真分支和取假分支
至少经历一次。
判定覆盖又称为分支覆盖。
对于图例，如果选择路径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, 1, 1)】覆盖 acd【L4】
条件覆盖
条件覆盖就是设计若干个测试用例，
运行被测程序，使得程序中每个判断
的每个条件的可能取值至少执行一次。
在图例中，我们事先可对所有条件的
取值加以标记。例如，
对于第一个判断：
条件 A＞1 取真为 ，取假为
条件 B＝0 取真为 ，取假为
对于第二个判断：
条件A＝2 取真为 ，取假为
条件X＞1 取真为 ，取假为
测试用例 覆盖分支 条件取值
【(2, 0, 4)，(2, 0, 3)】L1(c, e)
【(1, 0, 1)，(1, 0, 1)】L2(b, d)
【(2, 1, 1)，(2, 1, 2)】L3(b, e)
或
测 试 用 例 覆盖分支 条件取值
【(1, 0, 3)，(1, 0, 4)】 L3(b, e)
【(2, 1, 1)，(2, 1, 2)】 L3(b, e)
判定－条件覆盖
判定－条件覆盖就是设计足够的测
试用例，使得判断中每个条件的所
有可能取值至少执行一次，同时每
个判断中的每个条件的可能取值至
少执行一次。
测 试 用 例 覆盖分支 条件取值
【(2, 0, 4)，(2, 0, 3)】L1(c, e)
【(1, 1, 1)，(1, 1, 1)】L2(b, d)
条件组合覆盖
条件组合覆盖就是设计足够的测试用
例，运行被测程序，使得每个判断的
所有可能的条件取值组合至少执行一
次。
记 ① 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 作
测 试 用 例 覆盖条件 覆盖组合
【(2, 0, 4), (2, 0, 3)】(L1)
①, ⑤
【(2, 1, 1), (2, 1, 2)】(L3)
②, ⑥
【(1, 0, 3), (1, 0, 4)】(L3)
③, ⑦
【(1, 1, 1), (1, 1, 1)】(L2)
④, ⑧
路径测试
路径测试就是设计足够的测试用例，覆
盖程序中所有可能的路径。
测 试 用 例 通过路径 覆盖条件
【(2, 0, 4), (2, 0, 3)】 ace (L1)
【(1, 1, 1), (1, 1, 1)】 abd (L2)
【(1, 1, 2), (1, 1, 3)】 abe (L3)
【(3, 0, 3), (3, 0, 1)】 acd (L4)
条件测试路径选择
当程序中判定多于一个时，形成的分支
结构可以分为两类：嵌套型分支结构和
连锁型分支结构。
对于嵌套型分支结构，若有n个判定语句，
需要n+1个测试用例；
对于连锁型分支结构， 若有n个判定语
句，需要有2n个测试用例，覆盖它的2n
条路径。当n较大时将无法测试。
循环测试路径选择
循环分为4种不同类型：
简单循环
连锁循环
嵌套循环
非结构循环。
(1) 简单循环
① 零次循环：从循环入口到出口
② 一次循环：检查循环初始值
③ 二次循环：检查多次循环
④ m次循环： 检查在多次循环
⑤ 最大次数循环、比最大次数多
一次、少一次的循环。
(2) 嵌套循环
① 对最内层循环做简单循环的全部测试。
所有其它层的循环变量置为最小值；
② 逐步外推，对其外面一层循环进行测试。
测试时保持所有外层循环的循环变量取最
小值，所有其它嵌套内层循环的循环变量
取“典型”值。
③ 反复进行，直到所有各层循环测试完毕。
④ 对全部各层循环同时取最小循环次数，
或者同时取最大循环次数
如果各个循环互相独立，则可以
用与简单循环相同的方法进行测
试。但如果几个循环不是互相独
立的，则需要使用测试嵌套循环
的办法来处理。
（3）连锁循环
(4) 非结构循环
这一类循环应该使用结构化程序
设计方法重新设计测试用例。
域测试
基于程序结构的测试方法
针对域错误，对输入空间进行分析，选
择适当的测试点，检验输入空间中的每
个输入是否产生正确的结果。
假设限制过多，难以运用到实际中。
符号测试
另辟途径解决测试用例选择问题。
基于代数运算执行测试，是测试和验证
的折衷方法
程序插装
借助往被测程序中插入操作来实现测试
目的的方法。
程序变异
是一种错误驱动测试，针对某类特定程
序错误实现测试。
程序强变异
程序弱变异
小结
白盒测试方法分类
基本路径测试
逻辑覆盖测试
路径测试
专题小结
软件测试用例设计－黑盒测试
测试的关键就是确定正确的测试用例。
本部分详细介绍几种软件测试用例设计
方法：等价类划分、因果图、边值分析、
判定表驱动测试和测试用例自动生成原
理和方法。
专题小结
软件测试用例设计－白盒测试
程序结构分析
逻辑覆盖测试
路径
专题小结
学习要求：
1. 理解软件开发过程中每一阶段的软件测试方
法，理解他们的作用和意义。能够根据问题
选择正确的软件测试方法
2. 熟练掌握软件测试用例的设计方法，将设计
得到的测试用例编到软件测试用例表中，根
据软件测试用例表进行软件测试、填写软件
测试记录。
3. 结合实际的测试用例设计过程，理解自动测
试用例的原理和方法。
专题小结
训练：
1. 测试用例的设计
2. 编制软件测试用例表，进行软件测试
谢谢!
