第 六 章
6.1软件测试的基本概念一、软件测试的目的和重要性因为开发工作的前期不可避免地会引入错误，测试的 目的是为了发现和改正错误,这对于某些涉及人的生命安全或重要的军事、经济目标的项目显得尤其重要。
1963年美国飞往火星的火箭爆炸，原因是
FORTRAN程序,DO 5 I=1,3
误写为,DO 5 I=1,3 损失 1000万美元。
1967年苏联“联盟一号”宇宙飞船返回时因忽略一个小数点，在进入大气层时打不开降落伞而烧毁。
二、软件测试的 特点
1、软件测试的开销大按照 Boehm的统计，软件测试的开销大约占总成本的 30%-50%。例如,APPOLLO登月计划，
80%的经费用于软件测试。
2、不能进行“穷举”测试只有将所有可能的情况都测试到，才有可能检查出所有的错误。但这是不可能的：
例：程序 P有两个整型输入量 X,Y,输出量为 Z，
在 32位机上运行。所有的测试数据组（ Xi,Yi） 的数目为,2 2 = 2 1毫秒执行 1次，共需 5
亿年。
32 32 64
P
X
Y Z
二、软件测试的 特点 —结论
3、软件测试难度大根据上述分析，既然不能进行,穷举”测试，
又要查出尽可能多的错误，软件测试工作的难度大。只有选择 —
“高效的测试用例”
什么是,高效的测试用例”？
如何选择,高效的测试用例”？
这就是本章讨论的主要问题！！！
三、软件测试的基本原则
3、充分注意测试中的群集现象。
1、尽量不由程序设计者进行测试。
2、关键是注重测试用例的选择。
输入数据的组成（输入数据、预期的输出结果）
既有合理输入数据，也有不合理的输入数据。
用例既能检查应完成的任务，也能够检查不应该完成的任务。
长期保存测试用例。
四、测试的基本步骤模块测试整体测试功能测试预测试系统测试验收测试安装测试概要设计审查详细设计审查代码审查测试
(单元测试）
（组装测试）
（有效性测试）
（确认测试）{
{
6.2 软件测试方法软件测试方法分为两类：静态分析、动态测试一、静态分析方法指以人工的,非形式化的方法对程序进行分析和测试 。
桌前检查 代码会审 步行检查步行检查时，还常使用以下分析方法：
① 调用图从语义的角度考察程序的控制路线。
② 数据流分析图检查分析变量的定义和引用情况。
① 调用图无论 Y 为何值，都不能够调用子程序 。
READY
Y>0 N
X:=Y
X<0
Y
N
Y
调用子程序
A
B
C
D
E
即执行 ABC后，是不可能执行路径
CDE的。
② 数据流分析图节点 —表示单个语句。
有向边 —表示控制结构。
d — 定义
r — 引用
u — 未引用
R,duuuuu
S,uruuur
Y,uuddru
R=0.5
W=1/S
Y=A**W
Y=E*W
Z=X+Y
C=Z*S
1
2
3
4
5
6
只定义不用未定义引用连续定义二、动态测试方法 （ 1）
通过选择适当的测试用例，执行程序。
常用的方法：
1、白盒法分析程序的内部逻辑结构,注意选择适当的覆盖标准,设计测试用例,对主要路径进行尽可能多的测试 。
2、黑盒法不考虑程序的内部结构与特性,只根据程序功能或程序的外部特性设计测试用例 。
白盒法白盒法又称为逻辑覆盖法，其测试用例选择，
是按照不同覆盖标准确定的。
语句覆盖判定覆盖条件覆盖判定条件覆盖条件组合覆盖弱 强
① 语句覆盖,选择足够的测试用例,使得程序中每个语句至少都能被执行一次 。
② 判定覆盖,执行足够的测试用例，使得程序中每个判定至少都获得一次,真,值和,假,值。
③ 条件覆盖,执行足够的测试用例,使得判定中的每个条件获得各种可能的结果 。
④ 判定 /条件覆盖,执行足够的测试用例,使得判定中每个条件取到各种可能的值,并使每个判定取到各种可能的结果 。
⑤ 条件组合覆盖,执行足够的例子,使得每个判定中条件的各种可能组合都至少出现一次 。
白盒法 常用的覆盖标准白盒法步骤：
例：用 白盒法测试以下程序段：
Procedure（ VAR 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;
1）选择逻辑覆盖标准。
2）按照覆盖标准列出所有情况。
3）选择确定测试用例。
4）验证分析运行结果与预期结果。
逻辑结构白盒法举例
Procedure （ VAR 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>1
AND
B=0
X:=X/A
A=2
OR
X>1
X:=X+1
Y
N
Y
N
逻辑结构
1、语句覆盖 使得程序中每个语句至少都能被执行一次。
A>1
AND
B=0
X:=X/A
A=2
OR
X>1
X:=X+1
a
b
c
d
e
满足语句覆盖的情况：
执行路径,ace
选择用例：
[(2,0,4),(2,0,3)]
用例格式：
[输入 (A,B,X)，输出 (A,B,X)]
Y
N
Y
N
2、判定覆盖使得程序中每个判定至少为
TRUE 或 FALSE各一次。
A>1
AND
B=0
X:=X/A
A=2
OR
X>1
X:=X+1
a
b
c
d
e
覆盖情况,应执行路径
ace ∧ abd 或,acd ∧ abe
选择用例 (其一）：
⑴ [(2,0,4),(2,0,3)] ace
[(1,1,1),(1,1,1)] abd
⑵ [(2,1,1),(2,1,2)] abe
[(3,0,3),(3,1,1)] acd
Y
Y
N
N
3、条件覆盖
A>1
AND
B=0
X:=X/A
A=2
OR
X>1
X:=X+1
a
b
c
d
e
使得判定中的每个条件获得各种可能的结果。
应满足以下覆盖情况：
判定一,A>1,A≤1,B=0,B≠0
判定二,A=2,A≠2,X>1,X≤1
选择用例：
[(2,0,4),(2,0,3)]
[(1,1,1),(1,1,1)]
N
N
Y
Y
A≤1
A≠2
B=0
X>1
B≠0
X≤1
注意,[(1,0,3),(1,0,4)]
[(2,1,1),(2,1,2)]
满足条件覆盖，但不满足判断覆盖。
4、判定 /条件覆盖 同时满足判断覆盖和条件覆盖。
A>1
AND
B=0
X:=X/A
A=2
OR
X>1
X:=X+1
a
b
c
d
e
应满足以下覆盖情况：
条件,A>1,A≤1,B=0,B≠0
A=2,A≠2,X>1,X≤1
应执行路径
ace ∧ abd 或,acd ∧ abe
选择用例：
[(2,0,4),(2,0,3)]（ ace)
[(1,1,1),(1,1,1)] (abd)
Y
Y
N
N
5、条件组合覆盖 使得每个判定中条件的各种可能组合都至少出现一次。
A>1
X:=X/A
A=2
X:=X+1
a
b
c
d
e
B=0
X>1
Y
N
Y
N
Y
N
Y
N
编译系统下的执行情况：
部分路径未被执行。
满足以下覆盖情况：
① 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)] ① ⑤
[(2,1,1),(2,1,2)] ② ⑥
[(1,0,3),(1,0,4)] ③ ⑦
[(1,1,1),(1,1,1)] ④ ⑧
作业,
退出上页首页 下页 末页用 C语言编写选择排序的程序,并用白盒法进行测试,
二、动态测试方法 （ 2）
等价分类法边值分析法错误推测法因果图法
(2)黑盒法不考虑程序的内部结构与特性，
只根据程序功能或程序的外部特性设计测试用例。
1、等价分类法基本思想,根据程序的 I/O特性,将程序的定义域划分为有限个等价区段 —,等价类,,从等价类中选择出的用例,具有,代表性,。
等价类分为：
有效等价类 — 对于程序的规格说明是合理的,
有意义的输入数据构成的集合 。
无效等价类 —对于程序的规格说明，是不合理的，是没有意义的输入数据构成的集合。
等价分类法步骤应 按照输入条件 （ 如输入值的范围,值的个数,值的集合,输入条件必须如何 ） 划分为有效等价类和无效等价类 。
例如：每个学生可选修 1-3门课程可以划分一个有效等价类：选修 1-3门课程 。
可以划分两个无效等价类：未选修课,选修课超过 3门 。
又如：标识符的第一个字符必须是字母 。
可以划分为一个有效等价类：第一个字符是字母 。
可以划分一个无效等价类：第一个字符不是字母 。
① 划分,等价类,
显然,关键是如何划分等价类
A,为每个等价类编号；
B,使一个测试用例尽可能覆盖多个有效等价类
C,特别要注意的是：一个测试用例只能覆盖一个无效等价类 。
② 选择测试用例等价分类法步骤
2、边值分析法基本思想,选择等价类的边缘值作为测试用例,
让每个等价类的边界都得到测试,选择测试用例既考虑 输入 亦考虑 输出 。
分析步骤：
A,先划分等价类。
B,选择测试用例，测试等价类边界。
边界 选择原则：
A,按照输入值范围的边界。
B,按照输入 /输出值个数的边界。
C,输出值域的边界。
D,输入 /输出有序集的边界。
A,按照输入值范围的边界 。
例如：输入值的范围是 -1.0至 1.0,则可选择用例 –1.0、
1.0,-1.001,1.001。
B,按照输入 /输出值个数的边界 。
例如：输入文件可有 1-255个记录,则 设计用例：文件的记录数为 0个,1个,255个,256个 。
C,输出值域的边界 。
例如：检索文献摘要,最多 4篇 。 设计用例：可检索 0篇,
1篇,4篇,和 5篇 （ 错误 ） 。
D,输入 /输出有序集 （ 如顺序文件,线性表 ） 的边界 。
应选择第一个元素和最后一个元素 。
边值分析法举例黑盒法应用实例对 FORTRAN编译系统中的 DIMENSION语句进行测试。
语句格式为,DIMENSION ad[,ad] … ad为数组描述符，
形式为 n（ d[,] … 其中,n－ 数组名,字母打头的字母数字串,长 6。
D为界偶 （ 1-7个 ）,[ld:]nd ld 和 nd 的值为 1-65535,ld缺省为 1。
输入条件 合理的等价类 不合理的等价类数组描述的个数 1个（ 1）、多于 1个（ 2） 没有数组描述（ 3）
数组名的字符数 1—6个（ 4） 0（ 5）,>6（ 6）
数组名 有字母（ 7）有数字（ 8） 有其他字符（ 9）
数组名的第 1个字符为字母 是（ 10） 不是（ 11）
维数 1—7（ 12） 0（ 13）,>7（ 14）
上界 常数（ 15） 数组元素名（ 16
40 个等价类
3、错误推测法凭经验或直觉推测可能的错误，列出程序中可能有的错误和容易发生错误的特殊情况，选择测试用例。
把输入条件视为,因,,把输出条件视为
,果,,将黑盒看成是从因到果的网络图,采用逻辑图的形式来表达功能说明书中输入条件的各种组合与输出的关系 。 根据这种关系可选择高效的测试用例 。
因果图是一种形式化语言,是一种组合逻辑网络图 。
4、因果图法
4、因果图法（ cause effcet graphicei）
⑴ 因果图的基本符号
0 - 表示“不出现” 1 - 表示“出现”
恒等若 a为 1，则 b为 1，否则 b为 0。
,非,函数若 a为 1，则 b为 0，否则 b为 1。
,或,函数若 a或 b为 1，则 d为 1，否则 d为 0。
,与,函数若 a与 b同为 1，则 d为 1，否则 d为 0。
a b
a b
a
b
d∨
a
b
d∧
4、因果图法 （ cause effcet graphicei）
对,与,,,或,函数的限制符号
E约束（异） — 排斥即 a,b不能同时为 1。
I约束（或） — 包容
a,b,c不能同时为 0。
O约束（唯一 ） — 选一
a,b中仅有一个为 1。
R约束（要求 ） — 需要
a为 1时,b必须为 1
M约束（强制 ） — 屏蔽若 a为 1时，则 b强制为 1。
a
b
E
a
b
c
I
a
bR
a
bO
a
b
M
⑵ 因果图法的步骤分析规范，即将问题分为若干可工作的步骤。
标识出规范中的原因与结果。
原因 —输入条件结果 —输出或系统变换将因果图转换为有限项判断表。
将判断表的每一列，转换为一个测试用例。
分析规范语义、内容，转换为因果图。
⑶ 因果图法应用举例规范：文件名第一列字符必须为 A或 B,第二列字符必须为数字。满足则修改文件。第一字符不正确发出信息 X12,第二个字符不正确发出信息 X13。
①、分析规范原 因 结 果
1 — 第一列字符为 A 50—修改文件
2 — 第一列字符为 B 51—发信息 X12
3 — 第二列字符为数字 52—发信息 X13
②画出因果图中间结点 是导出结果的进一步原因 。
考虑到原因 1,2不可能同时为 1，加上 E约束。
11
11∨
51
50
3 52
∧
1
2
E
发 X 12
发 X 13
修改文件
③将因果图转换为判断表
1 2 3 4 5 6 7 8
条件原因
① 1 1 1 1 0 0 0 0
② 1 1 0 0 1 1 0 0
③ 1 0 1 0 1 0 1 0
1 1 1 1 0 0
动作结果
0 0 0 0 1 1
1 0 1 0 0 0
0 1 0 1 0 1
测试用例 A3
A8
AM
A？
B5
B4
BN
B！
C2
X6
DY
PI
11
51
50
52
6.3 软件测试的步骤测试步骤及策略所有测试过程都应采用综合测试策略；即先作静态分析，再作动态测试。并事先制订测试计划。测试过程通常可分 4步进行：
单元测试单元测试单元测试被测模块被测模块集成测试设计信息已测试的模块确认测试已集成的模块软件需求系统测试已确认的软件可交付的软件系统其他元素一、模块测试 （ Module Testing）
1、测试内容模块模块接口测试局部数据结构测试重要路径测试错误处理测试边界条件测试
I/O 参数值的个数、类型、次序、格式是否正确,I/O文件属性、操作是否正确等。
数据说明是否正确、
一致，变量及其初值定义是否正确等。
检查“错误处理程序”本身的错误。
边界条件常包括循环边界，最大最小值、控制流中等于、大于、小于的比较值等。
重要 路径通常是指完成模块功能的主要路径，
一般是控制结构。
也称单元测试（ unit testing )
2、模块测试步骤考虑到被测模块与其它模块的联系，因此测试时需要使用两类 辅助模块 来模拟其他模块。
驱动模块 （ driver） — 模拟主程序功能，用于向被测模块传递数据，
接收、打印从被测模块返回的数据。
桩模块 （ stub） — 又称为假模块，
用于模拟那些由被测模块所调用的下属模块功能。
一般，驱动模块比桩模块容易设计。但都是额外开销。测试方法以白盒法为主。
被测模块驱动模块桩模块桩模块 桩模块二、组装测试 （ Integration Testing）
1、组装测试的任务
①确定模块组装方案，将经过测试的模块组装为一个完整的系统。组装方案分为 渐增式 及 非渐增式。
②测试方法以黑盒法为主，按照组装方案进行测试。
也称为 联合测试 或 集成测试,重点测试模块的接口部分，需设计测试过程使用的驱动模块或桩模块。
问题,渐增式与非渐增式各有何优、缺点？为什么通常采用渐增式？
2、渐增式组装测试渐增式是先进行模块测试，然后将这些模块逐步组装成较大的系统，每连接一个模块进行一次测试 。 两种方案：
设计驱动模块或桩模块，对每一个新组装的子系统进行测试，对发现问题较多的子系统或模块应该用白盒法作回归测试。
自顶而下增值自底而上 增值自顶而下增值
M1
M4M3M2
M6M5
程序模块示意图S5
M1
S1 S2 S3
第一步,测试主控模块 M1设计桩模块 S1,S2,S3,模拟被 M1调用的 M2,M3,M4。
M2 M3 M4
第二步,依次用 M2,M3、
M4替代桩模块 S1,S2,S3，
每替代一次进行一次测试 。
S4
第三步,对由主控模块 M1和模块 M2,M3,M4构成的子系统进行测试,设计桩模块
S4,S5。
M5 M6
第四步,依次用模块 M5和
M6替代桩模块 S4,S5,并同时进行新的测试 。 组装测试完毕 。
自底而上 增值
M3
M6M5
D1
D2
D3M2 M4
M1
第四步,把已测试的子系统按程序结构连接起来完成程序整体的组装测试 。
D4 D5 M1
M4M3M2
M6M5
程序模块示意图第一步,对最底层的模块 M3、
M5,M6进行测试,设计驱动模块 D1,D2,D3来模拟调用 。
第三步,设计驱动模块 D4,D5
和 D6模拟调用,分别对新子系统进行测试 。
第二步,用实际模块 M2、
M1和 M4替换驱动模块 D1、
D2,D3。
D6
深度优先与宽度优先无论是 自顶而下增值还是自底而上增值，还可选择深度优先 或者 宽度优先 增值。
举例：按自顶而下增值法，写出下图中分别按照 深度优先 或者 宽度优先 增值的模块组装次序。
A
B C D
HG
J
E F I
K L M N
问 题
（ 1）自顶而下增值与 自底而上 增值各有何优、
缺点？
（ 2）为什么在实际的组装测试中，都应该采用混合增值的方法？
（ 3）请自己设计 2-3个混合增值的测试方法。
确定集成过程的原则自顶而下增值优点：能够尽早发现系统主控方面的问题。
缺点：无法验证桩模块是否完全模拟了下属模块的功能。
自底而上 增值优点：驱动模块较容易编写桩模块，能够尽早查出底层涉及较复杂的算法和实际的 I/O模块中的错误。
缺点：最后才能发现系统主控方面的问题。
集成过程的原则
① 尽早测试关键模块。
② 尽早测试包含 I/O的模块。
3、混合增值常见的 混合增值方案：
衍变的自顶而下先自底而上集成子系统，再自顶而下集成总系统。
自底而上 —自顶而下增值对含有读操作的子系统采用自底而上。
对含有写操作的子系统采用自顶而下。
回归测试在回归测试中自底而上，对其余部分（尤其是对修改过的子系统）采用自顶而下。
三、确认测试 (validation testing)
1、任务又称为有效性测试或功能测试。其任务是验证系统的功能、性能等特性是否符合需求规格说明。
选择测试人员选择测试用例实际运行测试软件计划用户文档开发文档源程序文本支持环境有效性测试软件配置审查管理机构裁决专家鉴定会交用户运行维护测试报告软件配置
2、确认测试步骤
（ 1）有效性测试制定测试计划，运用黑盒法，验证软件特性是否与需求符合。
（ 2） 软件配臵复查软件配臵 — 指软件工程过程中所产生的所有信息项,文档,报告,程序,表格,数据 。 随着软件工程过程的进展软件配臵项 （ SCI software
Configuration Item） 快速增加和变化 。 应复查
SCI是否齐全 。
（ 3）?测试和?测试
测试 是在开发机构的监督下，由个别用户在确认测试阶段后期对软件进行测试，目的是评价软件的 FLURPS（ 功能、局域化、可使用性、可靠性、性能和支持）,注重界面和特色。
测试 由 支持软件预发行 的客户对 FLURPS进行测试，主要目的是测试系统的可支持性。
Function Testing 功能测试
Local Area Testing 局域化测试
Usability Testing 可使用性测试
Regression Testing 回归测试
Performance Testing 性能测试
Supportability Testing 可支持 性测试四、系统测试 （ system testing ）
将经过确认测试的软件，与计算机硬件、外设、
支持软件等一起，在实际运行环境下测试。
五、验收测试（ acceptance testing）
验收测试是以用户为主的测试。软件工程课程设计的验收测试,19周进行。
1、步骤为：
（ 1）由课题组根据测试用例，自己演示系统所有功能。
（ 2）由教师进行测试。
2、软件工程课程设计验收表文档文档数量 文档质量 文档与系统 一致性 创新性 总体
（ 12分） （ 15分） （ 5分） （ 3分） （ 35分）
系统运行系统运行功能、性能系统结构总体设计合理性用户界面操作简便、
帮助信息有无创新系统特色总体
（ 25分） （ 10分） （ 10分） （ 5分） （ 50分）
其它个人工作量验收操作独立分析解决问题能力团结协作精 神爱护公物遵守纪律 总体
（ 9分） （ 4分） （ 1分） （ 1分） （ 15分）
3、软件测试文档模块测试报告至少选择一个典型模块进行测试。
A,综合测试策略（静态分析、白盒法为主，辅以黑盒法）
B,测试情况（根据覆盖标准列出）
C,测试用例（保留）
D,查错记录（数量、位臵）、分析结果。
组装测试报告
A,组装次序、测试方法（以黑盒法为主）
B,测试情况
C,测试用例（保留）
D,查错记录（数量、位臵）、分析结果。
功能测试与系统测试 与上类似。
6.4 面向对象的测试传统的观点认为测试要在编码之后才进行，假设测试的对象是程序代码。
需求和设计是代码产生的基础，需要对需求和设计进行测试。
需求或设计的测试通常以两种方式进行,
一是在没有代码的情况下进行测试；
二是在有代码的情况下进行测试。
面向对象的测试，既要使用许多传统的成熟的软件测试方法和技术，也有其不同的特点；主要反映在测试对象和内容的不同。
6.4.1 分析模型测试的重要性在不同的软件开发过程模型中,需求,设计和编码总是有一定的时序特性 。 需求模型,设计模型和实现代码之间还具备解释特性,即设计解释了需求,实现代码解释了设计 。
1,需求的质量影响并决定了设计的质量,进而影响并决定了代码,直至整个系统的最终质量 。
必须首先重视需求的质量,而测试是质量保证的重要手段 。
2,需求测试可以较早地发现需求中不合理的项目,以及错误地理解了用户需求的项目,避免对于成本和资源的消耗 。
同时也减少了返工的几率,应尽早发现并解决这些问题 。
3,减少需求的模糊性,用户需求是用户对待实现的系统的要求,通常以一种非正规的形式给出,具有一定的模糊性 。 这种模糊性带入了设计,甚至代码中,将可能引发几倍,甚至几十倍的错误,这必将极大地消耗系统的资源和成本 。
6.4.2 测试方法基于代码 —— 代码走查（方法同传统测试）
静态基于非代码 —— 评审 (需求和设计规格说明 )
动态 —— 测试用例驱动代码执行测试什么：
模型测试； 系统（子系统）测试；
类测试； 接受测试；
交互测试； 发布 /自我测试；
也分为静态测试和动态测试两类：
正式 —— 承担责任，写出评审报告评审非正式评审的目的是对具体的工作产品集 (如文档,源代码 )进行评价,并对管理提供以下信息：
是否符合制定的软件规格；
是否按照项目的标准和方法完成；
是否所有的更改都正确地得到完成 。
在 UML中，对需求模型的测试：
● 评审；
● 事务流 (场景 )模型等方法测试 (需结合具体的模型描述 )；
测试的目的是发现代码中的错误，测试的关键是确定高效的测试用例。测试的主要步骤有：
１、面向对象的单元测试测试 单元 为封装的类和对象，但不能孤立地测试单个操作，应把操作作为类的一部分来测试。
２、面向对象的集成测试集成测试的策略有：
①基于线程的测试 (Thread-based testing)
②基于使用的测试 (Use-based testing)
3、面向对象的确认测试类似传统的确认测试和系统测试，根据动态模型和描述系统行为的脚本来设计测试用例，可用黑盒法。
一、评审计划需要列出的项目 (解决测什么，什么时候测，
谁来测 )：
哪些人将参加评审会，各自的职责是什么；
需要准备哪些材料；
必须满足什么条件；
要完成的检查单或其他的指标；
评审会完成所必须满足的条件或准则；
评审会结束后需要保留归档的记录和文档。
二、参加评审人员：
用户，软件项目负责人，软件工程师，软件配臵管理人员，软件质量保证人员；软件独立验证与确认人员，软件开发无关的专家。
评审计划测试实际上也是一个项目。
测试也有需求,设计和实现,并且测试本身也会有测试
(测试中的测试 )。
测试作为项目开发活动中的一部分，在时间上应该有明确的要求，测试计划对于测试来说也是至关重要的。
UML分析模型的每个模式，从严格意义上说都应该经过测试。实际上，通常对用例模型、类对象模型以及用例中典型场景进行测试。
6.4.3 测试过程通常测试步骤如下：
测试用例模型? 测试某些用例中的典型场景?
类及对象模型? 某些类测试其状态模型
1、用例模型测试重点是检查用例模型作为整体是否实现了用户需求。相当于系统测试。通过系统的用户对系统的功能需求来设计测试用例。
3、类模型测试对类模型的测试是分析模型的核心，通常是根据问题域来进行测试。
— 黑盒法
2,用例测试是对某些用例中的典型场景进行测试，典型场景的测试关心的是用例的执行情况。
— 评审
4、状态模型测试对重要的状态模型进行测试，分析阶段的测试只能采用 评审法,测试对象的生命期和转移事件的条件。
分析模型测试内容用例模型的测试相当于系统测试，测试的主要目标是用例模型对于用户需求的可跟踪性。
用例模型的测试可以通过系统的可能用户对系统的功能要求来设计测试用例。
以系统的用户为主要的出发点设计测试用例，通过模拟某个系统用户的行为来测试整个系统，对于该用户的服务提供情况，从而检查系统功能的完整性，用户需求可跟踪性等情况。
用例模型的测试从系统用户的角度测试系统的服务，并不关心每个测试用例所实现的功能如何，所以应该是黑盒测试。
6.4.1 用例模型的测试下面以一个订货中心系统的用例模型为例说明测试用例的设计。
识别五个主要的系统角色 (用户 )：
管理者 (Manager)、发货人员 (Shipper)
收款人员 (Toll collector)、商务客户 (Customer)
信用卡 (Creditcard)
从各个角色出发通过下边的问题识别用例：
角色要求系统提供的功能有哪些？系统在提供这些功能的时候该角色需要做什么？
角色需要创建、阅读、销毁或存储系统的哪些信息？
系统中的哪些事件需要通知该角色？
以管理者为例：
(1)管理者要求系统为他提供什么功能？管理者需要做哪些工作？
答：管理者要求系统提供
a.接受顾客订货请求并创建订单；
b.计算订单的价钱；
c.根据订单信息选择仓库，并将订单发送给仓库；
d.查询订单货物发送情况；
e.查询客户订单付款情况；
f.评价商务结果；
g.顾客退货处理；
h.把仓库返回的订单发送到收费处；
i.商品价格更新。
管理者需要做,生成订单；查询订单时输入订单号。
(2)管理者需要阅读创建、销毁、更新或者存储系统哪些信息？
答：信息包括：订单、职员 (仓库人员、收费人员等 )信息、
顾客信息、物品条目及价格信息、仓库信息和税务信息 。
(3)系统中的事件一定要告诉管理者吗？
答：是。这些事件包括：仓库有关物品短缺以致无法满足某订单；订单数据出现错误；顾客超过期限未付款。
可见，管理者要使用系统的十个功能，因此至少可以设计出十个测试用例。
下面以第三条功能,根据订单信息选择仓库，并将订单发送给该仓库,为例,显然，不同的订单产生的结果可能是送往不同的仓库来处理。
系统用户考虑分配订单到某仓库的因素：
(1)首先仓库必须能够满足订单上的货物要求；
(2)选择地理位臵与发货点较近的仓库发货；
(3)信誉满意度越高的客户就越应该以较高的服务质量来回报。
三个订单信息如下：
订单号 送货地点 货物名称及数量 客户信誉订单 1 北城某集团公司 G1(200),G5(100),G10(40) 95
订单 2 东城某街道 G5(10),G6(5) 80
订单 3 北城某街道 G4(10) 85
仓库名称 仓库位臵 存货品名及数量 订单处理客户信誉度
A 东城 G1(200),G5(100),G6(1000)，G10(70),G11(90) 85
B 西城 G1(1000),G2(100),G5(250)，G8(150),G10(98) 95
C 北城 G1(220),G4(300),G5(350)，G7(400),G10(700) 80
结合考虑上面三个因素，以最少的成本取得最好的收益，
测试用例 1：
输入：订单 1
预期结果：选择仓库 B来处理订单 (三个均可，大宗订单，
客户信誉度高 )；
测试用例 2：
输入：订单 2
预期结果：选择仓库 A来处理订单 (个人订单，客户信誉一般 )；
测试用例 3：
输入：订单 3
预期结果：选择仓库 C来处理订单。
以上测试未触及某个具体用例，体现了用例模型测试和用例测试的区别。
类模型是分析模型中的核心，它抽象出了问题域中的对象和实体，以及它们在问题域中的职责。
为确保类模型的正确性和完整性，只根据问题域测试类模型。测试方法是 评审会 。
类图实际上由类和类之间的关系组成，评审会的检查单可从以下两个方面制定。
6.4.5 类模型的测试针对每个类提问：
(1)该类在问题域中对应的实体 (或对象 )是什么？
(2)履行什么职责？
(3)在类图中被赋予了哪些职责？
(4)该类在问题域中的职责和在类图中的职责能匹配吗？
(5)该类的每个数据属性都是问题域所关心的吗？
针对类图中的类之间的关系提问：
(1)这种类关系是反映了问题域本质的关系还是为管理类模型而引入的关系？ (如果类之间的关系并非反映问题域的本质,
那么这个关系的存在就值得怀疑 。 )
(2)仔细检查每个继承关系,到底是聚集关系还是继承关系？
(3)针对关联关系中的关联数目,提一些问题结合实际场景来考察 。
从模型的角度可以关心如下问题：
(1)状态模型刻画了对象的生命周期吗？
(2)针对每个状态而言，状态转移触发条件是状态转移的充分条件吗？
(3)对象在问题域需要响应的所有条件是否在状态模型中都有响应？
(4)关心对象在某些状态中的动作，如果对象需要发送消息给其它对象，那么此时接收该消息的对象处在其声明周期的什么阶段？
(5)从初始状态开始,每个状态都可以达到吗？
6.4.6 类状态模型的测试类状态模型描述了一个对象在问题域中的活动历程。
在分析阶段，识别的对象还只是停留在较粗的层次上，因此，对象状态模型的测试通常只能采用评审会的办法。只测试在问题域中非常重要的对象，如电梯系统中的电梯对象。
上述五个问题可以作为评审会问题检查单的选择。
对问题 (1)：
检查状态模型对于对象状态的划分，一旦出现识别的状态不足，或者某些状态超出问题域的关心，分析原因，分析员在评审会报告想法和理由。
对问题 (2)：
检查状态转移条件，验证当触发条件满足时是否会出现状态转移，要求触发条件是最简化的 (无冗余条件 )。
对问题 (3)：
通过一张对照表可以找出答案。
对问题 (4)：
检查较复杂，容易发现分析错误的一个环节。通常，分析员以为进行交互的其它对象都处于,良好,状态，但这个假设常常不能成立，因为两个不同的对象可能与相应的事件会有交叉 (如定时事件 )。因此，当当前分析的对象发生了状态转移时，其它对象也发生了状态转移，所以在对象发送消息给其它对象时，也要注意接收该消息的对象是否处于合适的状态中。
对问题 (5)：
如果某个状态根本就不可达到，那么可以断定分析模型有错误。
类级别的单元测试中，状态模型可以辅助进行测试用例的模型。
顺着不同的状态演变路径来测试对象的动作行为 (操作序列 )，
如帐号对象的状态图。
open setup
deposit (initial)
deposit
withdrawbalance count
withdraw (final)
close
空帐号 帐号设置工作帐号无效帐号 当空帐号银行帐号共有 5个生命周期状态，设计下面的测试用例：
(1)测试用例 1：
open,setup,deposit (initial),withdraw (final),close;
(2)测试用例 2：
open,setup,deposit (initial),deposit,balance count,
withdraw (final),close;
(3)测试用例 3：
open,setup,deposit (initial),deposit,withdraw,balance
count,withdraw (final),close.
上述测试用例覆盖每个状态，并增量测试每个状态的转移。
该例不涉及复杂对象之间的交互情况，有对象交互的测试用例设计将更加困难。
如果通过覆盖状态模型中的每个状态和每个状态转移，
那么就可以测试到对象之间的各种情况。
类状态模型的测试典型场景是指系统用户经常使用系统的方式。典型场景是用例模型的一个实例。
典型场景测试主要关注用例执行情况，典型场景测试可能涉及到不止一个用例，通常测试的是系统的功能。
测试可以根据需求分析出发列出的一些典型场景 (顺序图模型所描述 )进行 。 如果无典型场景的顺序图模型,
可以把几个不同用例的顺序图模型联合起来,并选择一条对象交互链作为一个典型场景,这个场景就是测试用例 。
4.3.6 典型场景的测试
6.5 软件纠错技术软件测试的目的是发现错误，在发现错误后，
则应按照一定的技术去纠正它。纠错的关键是
“错误定位”。
一、纠错的原则
1、注意错误的“群集现象”。
2、不能只修改错误的征兆、表现。还应该修改错误的本质。
3、注意在修改一个错误的同时，又引入新的错误。
二、纠错的技术
1、硬性纠错又称为蛮干法，是使用较多，效率较低的方法。
主存信息转储法关键部分设臵打印语句使用自动纠错工具
2、回 溯法排错适用于小程序。发现错误时，人工沿控制流追踪源代码程序。
3、归纳法从测试结果发现的错误入手，分析它们之间的联系查找错误。是一种从特殊推断一般的系统化思考方法。
收集有关数据 组织数据研究数据间的关系 提出假设证明假设纠正错误能能不能不能列出所有已知的测试用例和程序执行结果常用的构造线索的技术是“分类法”
分析线索之间的关系，找出矛盾，设计出错原因的假设归纳排错法步骤将假设与原始线索或数据进行比较，
能否解释现象，证明假设。
yes no
What
When
where
How
4、演绎法排错演绎法是一种从一般原理出发，经过排除和精化的过程，推导出结论的方法。
列举可能的原因排除不适当的原因对保留的假设继续推断证明假设纠正错误收集更多的数据没有剩余不能能有剩余演绎法排错的步骤
6.1软件测试的基本概念一、软件测试的目的和重要性因为开发工作的前期不可避免地会引入错误，测试的 目的是为了发现和改正错误,这对于某些涉及人的生命安全或重要的军事、经济目标的项目显得尤其重要。
1963年美国飞往火星的火箭爆炸，原因是
FORTRAN程序,DO 5 I=1,3
误写为,DO 5 I=1,3 损失 1000万美元。
1967年苏联“联盟一号”宇宙飞船返回时因忽略一个小数点，在进入大气层时打不开降落伞而烧毁。
二、软件测试的 特点
1、软件测试的开销大按照 Boehm的统计，软件测试的开销大约占总成本的 30%-50%。例如,APPOLLO登月计划，
80%的经费用于软件测试。
2、不能进行“穷举”测试只有将所有可能的情况都测试到，才有可能检查出所有的错误。但这是不可能的：
例：程序 P有两个整型输入量 X,Y,输出量为 Z，
在 32位机上运行。所有的测试数据组（ Xi,Yi） 的数目为,2 2 = 2 1毫秒执行 1次，共需 5
亿年。
32 32 64
P
X
Y Z
二、软件测试的 特点 —结论
3、软件测试难度大根据上述分析，既然不能进行,穷举”测试，
又要查出尽可能多的错误，软件测试工作的难度大。只有选择 —
“高效的测试用例”
什么是,高效的测试用例”？
如何选择,高效的测试用例”？
这就是本章讨论的主要问题！！！
三、软件测试的基本原则
3、充分注意测试中的群集现象。
1、尽量不由程序设计者进行测试。
2、关键是注重测试用例的选择。
输入数据的组成（输入数据、预期的输出结果）
既有合理输入数据，也有不合理的输入数据。
用例既能检查应完成的任务，也能够检查不应该完成的任务。
长期保存测试用例。
四、测试的基本步骤模块测试整体测试功能测试预测试系统测试验收测试安装测试概要设计审查详细设计审查代码审查测试
(单元测试）
（组装测试）
（有效性测试）
（确认测试）{
{
6.2 软件测试方法软件测试方法分为两类：静态分析、动态测试一、静态分析方法指以人工的,非形式化的方法对程序进行分析和测试 。
桌前检查 代码会审 步行检查步行检查时，还常使用以下分析方法：
① 调用图从语义的角度考察程序的控制路线。
② 数据流分析图检查分析变量的定义和引用情况。
① 调用图无论 Y 为何值，都不能够调用子程序 。
READY
Y>0 N
X:=Y
X<0
Y
N
Y
调用子程序
A
B
C
D
E
即执行 ABC后，是不可能执行路径
CDE的。
② 数据流分析图节点 —表示单个语句。
有向边 —表示控制结构。
d — 定义
r — 引用
u — 未引用
R,duuuuu
S,uruuur
Y,uuddru
R=0.5
W=1/S
Y=A**W
Y=E*W
Z=X+Y
C=Z*S
1
2
3
4
5
6
只定义不用未定义引用连续定义二、动态测试方法 （ 1）
通过选择适当的测试用例，执行程序。
常用的方法：
1、白盒法分析程序的内部逻辑结构,注意选择适当的覆盖标准,设计测试用例,对主要路径进行尽可能多的测试 。
2、黑盒法不考虑程序的内部结构与特性,只根据程序功能或程序的外部特性设计测试用例 。
白盒法白盒法又称为逻辑覆盖法，其测试用例选择，
是按照不同覆盖标准确定的。
语句覆盖判定覆盖条件覆盖判定条件覆盖条件组合覆盖弱 强
① 语句覆盖,选择足够的测试用例,使得程序中每个语句至少都能被执行一次 。
② 判定覆盖,执行足够的测试用例，使得程序中每个判定至少都获得一次,真,值和,假,值。
③ 条件覆盖,执行足够的测试用例,使得判定中的每个条件获得各种可能的结果 。
④ 判定 /条件覆盖,执行足够的测试用例,使得判定中每个条件取到各种可能的值,并使每个判定取到各种可能的结果 。
⑤ 条件组合覆盖,执行足够的例子,使得每个判定中条件的各种可能组合都至少出现一次 。
白盒法 常用的覆盖标准白盒法步骤：
例：用 白盒法测试以下程序段：
Procedure（ VAR 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;
1）选择逻辑覆盖标准。
2）按照覆盖标准列出所有情况。
3）选择确定测试用例。
4）验证分析运行结果与预期结果。
逻辑结构白盒法举例
Procedure （ VAR 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>1
AND
B=0
X:=X/A
A=2
OR
X>1
X:=X+1
Y
N
Y
N
逻辑结构
1、语句覆盖 使得程序中每个语句至少都能被执行一次。
A>1
AND
B=0
X:=X/A
A=2
OR
X>1
X:=X+1
a
b
c
d
e
满足语句覆盖的情况：
执行路径,ace
选择用例：
[(2,0,4),(2,0,3)]
用例格式：
[输入 (A,B,X)，输出 (A,B,X)]
Y
N
Y
N
2、判定覆盖使得程序中每个判定至少为
TRUE 或 FALSE各一次。
A>1
AND
B=0
X:=X/A
A=2
OR
X>1
X:=X+1
a
b
c
d
e
覆盖情况,应执行路径
ace ∧ abd 或,acd ∧ abe
选择用例 (其一）：
⑴ [(2,0,4),(2,0,3)] ace
[(1,1,1),(1,1,1)] abd
⑵ [(2,1,1),(2,1,2)] abe
[(3,0,3),(3,1,1)] acd
Y
Y
N
N
3、条件覆盖
A>1
AND
B=0
X:=X/A
A=2
OR
X>1
X:=X+1
a
b
c
d
e
使得判定中的每个条件获得各种可能的结果。
应满足以下覆盖情况：
判定一,A>1,A≤1,B=0,B≠0
判定二,A=2,A≠2,X>1,X≤1
选择用例：
[(2,0,4),(2,0,3)]
[(1,1,1),(1,1,1)]
N
N
Y
Y
A≤1
A≠2
B=0
X>1
B≠0
X≤1
注意,[(1,0,3),(1,0,4)]
[(2,1,1),(2,1,2)]
满足条件覆盖，但不满足判断覆盖。
4、判定 /条件覆盖 同时满足判断覆盖和条件覆盖。
A>1
AND
B=0
X:=X/A
A=2
OR
X>1
X:=X+1
a
b
c
d
e
应满足以下覆盖情况：
条件,A>1,A≤1,B=0,B≠0
A=2,A≠2,X>1,X≤1
应执行路径
ace ∧ abd 或,acd ∧ abe
选择用例：
[(2,0,4),(2,0,3)]（ ace)
[(1,1,1),(1,1,1)] (abd)
Y
Y
N
N
5、条件组合覆盖 使得每个判定中条件的各种可能组合都至少出现一次。
A>1
X:=X/A
A=2
X:=X+1
a
b
c
d
e
B=0
X>1
Y
N
Y
N
Y
N
Y
N
编译系统下的执行情况：
部分路径未被执行。
满足以下覆盖情况：
① 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)] ① ⑤
[(2,1,1),(2,1,2)] ② ⑥
[(1,0,3),(1,0,4)] ③ ⑦
[(1,1,1),(1,1,1)] ④ ⑧
作业,
退出上页首页 下页 末页用 C语言编写选择排序的程序,并用白盒法进行测试,
二、动态测试方法 （ 2）
等价分类法边值分析法错误推测法因果图法
(2)黑盒法不考虑程序的内部结构与特性，
只根据程序功能或程序的外部特性设计测试用例。
1、等价分类法基本思想,根据程序的 I/O特性,将程序的定义域划分为有限个等价区段 —,等价类,,从等价类中选择出的用例,具有,代表性,。
等价类分为：
有效等价类 — 对于程序的规格说明是合理的,
有意义的输入数据构成的集合 。
无效等价类 —对于程序的规格说明，是不合理的，是没有意义的输入数据构成的集合。
等价分类法步骤应 按照输入条件 （ 如输入值的范围,值的个数,值的集合,输入条件必须如何 ） 划分为有效等价类和无效等价类 。
例如：每个学生可选修 1-3门课程可以划分一个有效等价类：选修 1-3门课程 。
可以划分两个无效等价类：未选修课,选修课超过 3门 。
又如：标识符的第一个字符必须是字母 。
可以划分为一个有效等价类：第一个字符是字母 。
可以划分一个无效等价类：第一个字符不是字母 。
① 划分,等价类,
显然,关键是如何划分等价类
A,为每个等价类编号；
B,使一个测试用例尽可能覆盖多个有效等价类
C,特别要注意的是：一个测试用例只能覆盖一个无效等价类 。
② 选择测试用例等价分类法步骤
2、边值分析法基本思想,选择等价类的边缘值作为测试用例,
让每个等价类的边界都得到测试,选择测试用例既考虑 输入 亦考虑 输出 。
分析步骤：
A,先划分等价类。
B,选择测试用例，测试等价类边界。
边界 选择原则：
A,按照输入值范围的边界。
B,按照输入 /输出值个数的边界。
C,输出值域的边界。
D,输入 /输出有序集的边界。
A,按照输入值范围的边界 。
例如：输入值的范围是 -1.0至 1.0,则可选择用例 –1.0、
1.0,-1.001,1.001。
B,按照输入 /输出值个数的边界 。
例如：输入文件可有 1-255个记录,则 设计用例：文件的记录数为 0个,1个,255个,256个 。
C,输出值域的边界 。
例如：检索文献摘要,最多 4篇 。 设计用例：可检索 0篇,
1篇,4篇,和 5篇 （ 错误 ） 。
D,输入 /输出有序集 （ 如顺序文件,线性表 ） 的边界 。
应选择第一个元素和最后一个元素 。
边值分析法举例黑盒法应用实例对 FORTRAN编译系统中的 DIMENSION语句进行测试。
语句格式为,DIMENSION ad[,ad] … ad为数组描述符，
形式为 n（ d[,] … 其中,n－ 数组名,字母打头的字母数字串,长 6。
D为界偶 （ 1-7个 ）,[ld:]nd ld 和 nd 的值为 1-65535,ld缺省为 1。
输入条件 合理的等价类 不合理的等价类数组描述的个数 1个（ 1）、多于 1个（ 2） 没有数组描述（ 3）
数组名的字符数 1—6个（ 4） 0（ 5）,>6（ 6）
数组名 有字母（ 7）有数字（ 8） 有其他字符（ 9）
数组名的第 1个字符为字母 是（ 10） 不是（ 11）
维数 1—7（ 12） 0（ 13）,>7（ 14）
上界 常数（ 15） 数组元素名（ 16
40 个等价类
3、错误推测法凭经验或直觉推测可能的错误，列出程序中可能有的错误和容易发生错误的特殊情况，选择测试用例。
把输入条件视为,因,,把输出条件视为
,果,,将黑盒看成是从因到果的网络图,采用逻辑图的形式来表达功能说明书中输入条件的各种组合与输出的关系 。 根据这种关系可选择高效的测试用例 。
因果图是一种形式化语言,是一种组合逻辑网络图 。
4、因果图法
4、因果图法（ cause effcet graphicei）
⑴ 因果图的基本符号
0 - 表示“不出现” 1 - 表示“出现”
恒等若 a为 1，则 b为 1，否则 b为 0。
,非,函数若 a为 1，则 b为 0，否则 b为 1。
,或,函数若 a或 b为 1，则 d为 1，否则 d为 0。
,与,函数若 a与 b同为 1，则 d为 1，否则 d为 0。
a b
a b
a
b
d∨
a
b
d∧
4、因果图法 （ cause effcet graphicei）
对,与,,,或,函数的限制符号
E约束（异） — 排斥即 a,b不能同时为 1。
I约束（或） — 包容
a,b,c不能同时为 0。
O约束（唯一 ） — 选一
a,b中仅有一个为 1。
R约束（要求 ） — 需要
a为 1时,b必须为 1
M约束（强制 ） — 屏蔽若 a为 1时，则 b强制为 1。
a
b
E
a
b
c
I
a
bR
a
bO
a
b
M
⑵ 因果图法的步骤分析规范，即将问题分为若干可工作的步骤。
标识出规范中的原因与结果。
原因 —输入条件结果 —输出或系统变换将因果图转换为有限项判断表。
将判断表的每一列，转换为一个测试用例。
分析规范语义、内容，转换为因果图。
⑶ 因果图法应用举例规范：文件名第一列字符必须为 A或 B,第二列字符必须为数字。满足则修改文件。第一字符不正确发出信息 X12,第二个字符不正确发出信息 X13。
①、分析规范原 因 结 果
1 — 第一列字符为 A 50—修改文件
2 — 第一列字符为 B 51—发信息 X12
3 — 第二列字符为数字 52—发信息 X13
②画出因果图中间结点 是导出结果的进一步原因 。
考虑到原因 1,2不可能同时为 1，加上 E约束。
11
11∨
51
50
3 52
∧
1
2
E
发 X 12
发 X 13
修改文件
③将因果图转换为判断表
1 2 3 4 5 6 7 8
条件原因
① 1 1 1 1 0 0 0 0
② 1 1 0 0 1 1 0 0
③ 1 0 1 0 1 0 1 0
1 1 1 1 0 0
动作结果
0 0 0 0 1 1
1 0 1 0 0 0
0 1 0 1 0 1
测试用例 A3
A8
AM
A？
B5
B4
BN
B！
C2
X6
DY
PI
11
51
50
52
6.3 软件测试的步骤测试步骤及策略所有测试过程都应采用综合测试策略；即先作静态分析，再作动态测试。并事先制订测试计划。测试过程通常可分 4步进行：
单元测试单元测试单元测试被测模块被测模块集成测试设计信息已测试的模块确认测试已集成的模块软件需求系统测试已确认的软件可交付的软件系统其他元素一、模块测试 （ Module Testing）
1、测试内容模块模块接口测试局部数据结构测试重要路径测试错误处理测试边界条件测试
I/O 参数值的个数、类型、次序、格式是否正确,I/O文件属性、操作是否正确等。
数据说明是否正确、
一致，变量及其初值定义是否正确等。
检查“错误处理程序”本身的错误。
边界条件常包括循环边界，最大最小值、控制流中等于、大于、小于的比较值等。
重要 路径通常是指完成模块功能的主要路径，
一般是控制结构。
也称单元测试（ unit testing )
2、模块测试步骤考虑到被测模块与其它模块的联系，因此测试时需要使用两类 辅助模块 来模拟其他模块。
驱动模块 （ driver） — 模拟主程序功能，用于向被测模块传递数据，
接收、打印从被测模块返回的数据。
桩模块 （ stub） — 又称为假模块，
用于模拟那些由被测模块所调用的下属模块功能。
一般，驱动模块比桩模块容易设计。但都是额外开销。测试方法以白盒法为主。
被测模块驱动模块桩模块桩模块 桩模块二、组装测试 （ Integration Testing）
1、组装测试的任务
①确定模块组装方案，将经过测试的模块组装为一个完整的系统。组装方案分为 渐增式 及 非渐增式。
②测试方法以黑盒法为主，按照组装方案进行测试。
也称为 联合测试 或 集成测试,重点测试模块的接口部分，需设计测试过程使用的驱动模块或桩模块。
问题,渐增式与非渐增式各有何优、缺点？为什么通常采用渐增式？
2、渐增式组装测试渐增式是先进行模块测试，然后将这些模块逐步组装成较大的系统，每连接一个模块进行一次测试 。 两种方案：
设计驱动模块或桩模块，对每一个新组装的子系统进行测试，对发现问题较多的子系统或模块应该用白盒法作回归测试。
自顶而下增值自底而上 增值自顶而下增值
M1
M4M3M2
M6M5
程序模块示意图S5
M1
S1 S2 S3
第一步,测试主控模块 M1设计桩模块 S1,S2,S3,模拟被 M1调用的 M2,M3,M4。
M2 M3 M4
第二步,依次用 M2,M3、
M4替代桩模块 S1,S2,S3，
每替代一次进行一次测试 。
S4
第三步,对由主控模块 M1和模块 M2,M3,M4构成的子系统进行测试,设计桩模块
S4,S5。
M5 M6
第四步,依次用模块 M5和
M6替代桩模块 S4,S5,并同时进行新的测试 。 组装测试完毕 。
自底而上 增值
M3
M6M5
D1
D2
D3M2 M4
M1
第四步,把已测试的子系统按程序结构连接起来完成程序整体的组装测试 。
D4 D5 M1
M4M3M2
M6M5
程序模块示意图第一步,对最底层的模块 M3、
M5,M6进行测试,设计驱动模块 D1,D2,D3来模拟调用 。
第三步,设计驱动模块 D4,D5
和 D6模拟调用,分别对新子系统进行测试 。
第二步,用实际模块 M2、
M1和 M4替换驱动模块 D1、
D2,D3。
D6
深度优先与宽度优先无论是 自顶而下增值还是自底而上增值，还可选择深度优先 或者 宽度优先 增值。
举例：按自顶而下增值法，写出下图中分别按照 深度优先 或者 宽度优先 增值的模块组装次序。
A
B C D
HG
J
E F I
K L M N
问 题
（ 1）自顶而下增值与 自底而上 增值各有何优、
缺点？
（ 2）为什么在实际的组装测试中，都应该采用混合增值的方法？
（ 3）请自己设计 2-3个混合增值的测试方法。
确定集成过程的原则自顶而下增值优点：能够尽早发现系统主控方面的问题。
缺点：无法验证桩模块是否完全模拟了下属模块的功能。
自底而上 增值优点：驱动模块较容易编写桩模块，能够尽早查出底层涉及较复杂的算法和实际的 I/O模块中的错误。
缺点：最后才能发现系统主控方面的问题。
集成过程的原则
① 尽早测试关键模块。
② 尽早测试包含 I/O的模块。
3、混合增值常见的 混合增值方案：
衍变的自顶而下先自底而上集成子系统，再自顶而下集成总系统。
自底而上 —自顶而下增值对含有读操作的子系统采用自底而上。
对含有写操作的子系统采用自顶而下。
回归测试在回归测试中自底而上，对其余部分（尤其是对修改过的子系统）采用自顶而下。
三、确认测试 (validation testing)
1、任务又称为有效性测试或功能测试。其任务是验证系统的功能、性能等特性是否符合需求规格说明。
选择测试人员选择测试用例实际运行测试软件计划用户文档开发文档源程序文本支持环境有效性测试软件配置审查管理机构裁决专家鉴定会交用户运行维护测试报告软件配置
2、确认测试步骤
（ 1）有效性测试制定测试计划，运用黑盒法，验证软件特性是否与需求符合。
（ 2） 软件配臵复查软件配臵 — 指软件工程过程中所产生的所有信息项,文档,报告,程序,表格,数据 。 随着软件工程过程的进展软件配臵项 （ SCI software
Configuration Item） 快速增加和变化 。 应复查
SCI是否齐全 。
（ 3）?测试和?测试
测试 是在开发机构的监督下，由个别用户在确认测试阶段后期对软件进行测试，目的是评价软件的 FLURPS（ 功能、局域化、可使用性、可靠性、性能和支持）,注重界面和特色。
测试 由 支持软件预发行 的客户对 FLURPS进行测试，主要目的是测试系统的可支持性。
Function Testing 功能测试
Local Area Testing 局域化测试
Usability Testing 可使用性测试
Regression Testing 回归测试
Performance Testing 性能测试
Supportability Testing 可支持 性测试四、系统测试 （ system testing ）
将经过确认测试的软件，与计算机硬件、外设、
支持软件等一起，在实际运行环境下测试。
五、验收测试（ acceptance testing）
验收测试是以用户为主的测试。软件工程课程设计的验收测试,19周进行。
1、步骤为：
（ 1）由课题组根据测试用例，自己演示系统所有功能。
（ 2）由教师进行测试。
2、软件工程课程设计验收表文档文档数量 文档质量 文档与系统 一致性 创新性 总体
（ 12分） （ 15分） （ 5分） （ 3分） （ 35分）
系统运行系统运行功能、性能系统结构总体设计合理性用户界面操作简便、
帮助信息有无创新系统特色总体
（ 25分） （ 10分） （ 10分） （ 5分） （ 50分）
其它个人工作量验收操作独立分析解决问题能力团结协作精 神爱护公物遵守纪律 总体
（ 9分） （ 4分） （ 1分） （ 1分） （ 15分）
3、软件测试文档模块测试报告至少选择一个典型模块进行测试。
A,综合测试策略（静态分析、白盒法为主，辅以黑盒法）
B,测试情况（根据覆盖标准列出）
C,测试用例（保留）
D,查错记录（数量、位臵）、分析结果。
组装测试报告
A,组装次序、测试方法（以黑盒法为主）
B,测试情况
C,测试用例（保留）
D,查错记录（数量、位臵）、分析结果。
功能测试与系统测试 与上类似。
6.4 面向对象的测试传统的观点认为测试要在编码之后才进行，假设测试的对象是程序代码。
需求和设计是代码产生的基础，需要对需求和设计进行测试。
需求或设计的测试通常以两种方式进行,
一是在没有代码的情况下进行测试；
二是在有代码的情况下进行测试。
面向对象的测试，既要使用许多传统的成熟的软件测试方法和技术，也有其不同的特点；主要反映在测试对象和内容的不同。
6.4.1 分析模型测试的重要性在不同的软件开发过程模型中,需求,设计和编码总是有一定的时序特性 。 需求模型,设计模型和实现代码之间还具备解释特性,即设计解释了需求,实现代码解释了设计 。
1,需求的质量影响并决定了设计的质量,进而影响并决定了代码,直至整个系统的最终质量 。
必须首先重视需求的质量,而测试是质量保证的重要手段 。
2,需求测试可以较早地发现需求中不合理的项目,以及错误地理解了用户需求的项目,避免对于成本和资源的消耗 。
同时也减少了返工的几率,应尽早发现并解决这些问题 。
3,减少需求的模糊性,用户需求是用户对待实现的系统的要求,通常以一种非正规的形式给出,具有一定的模糊性 。 这种模糊性带入了设计,甚至代码中,将可能引发几倍,甚至几十倍的错误,这必将极大地消耗系统的资源和成本 。
6.4.2 测试方法基于代码 —— 代码走查（方法同传统测试）
静态基于非代码 —— 评审 (需求和设计规格说明 )
动态 —— 测试用例驱动代码执行测试什么：
模型测试； 系统（子系统）测试；
类测试； 接受测试；
交互测试； 发布 /自我测试；
也分为静态测试和动态测试两类：
正式 —— 承担责任，写出评审报告评审非正式评审的目的是对具体的工作产品集 (如文档,源代码 )进行评价,并对管理提供以下信息：
是否符合制定的软件规格；
是否按照项目的标准和方法完成；
是否所有的更改都正确地得到完成 。
在 UML中，对需求模型的测试：
● 评审；
● 事务流 (场景 )模型等方法测试 (需结合具体的模型描述 )；
测试的目的是发现代码中的错误，测试的关键是确定高效的测试用例。测试的主要步骤有：
１、面向对象的单元测试测试 单元 为封装的类和对象，但不能孤立地测试单个操作，应把操作作为类的一部分来测试。
２、面向对象的集成测试集成测试的策略有：
①基于线程的测试 (Thread-based testing)
②基于使用的测试 (Use-based testing)
3、面向对象的确认测试类似传统的确认测试和系统测试，根据动态模型和描述系统行为的脚本来设计测试用例，可用黑盒法。
一、评审计划需要列出的项目 (解决测什么，什么时候测，
谁来测 )：
哪些人将参加评审会，各自的职责是什么；
需要准备哪些材料；
必须满足什么条件；
要完成的检查单或其他的指标；
评审会完成所必须满足的条件或准则；
评审会结束后需要保留归档的记录和文档。
二、参加评审人员：
用户，软件项目负责人，软件工程师，软件配臵管理人员，软件质量保证人员；软件独立验证与确认人员，软件开发无关的专家。
评审计划测试实际上也是一个项目。
测试也有需求,设计和实现,并且测试本身也会有测试
(测试中的测试 )。
测试作为项目开发活动中的一部分，在时间上应该有明确的要求，测试计划对于测试来说也是至关重要的。
UML分析模型的每个模式，从严格意义上说都应该经过测试。实际上，通常对用例模型、类对象模型以及用例中典型场景进行测试。
6.4.3 测试过程通常测试步骤如下：
测试用例模型? 测试某些用例中的典型场景?
类及对象模型? 某些类测试其状态模型
1、用例模型测试重点是检查用例模型作为整体是否实现了用户需求。相当于系统测试。通过系统的用户对系统的功能需求来设计测试用例。
3、类模型测试对类模型的测试是分析模型的核心，通常是根据问题域来进行测试。
— 黑盒法
2,用例测试是对某些用例中的典型场景进行测试，典型场景的测试关心的是用例的执行情况。
— 评审
4、状态模型测试对重要的状态模型进行测试，分析阶段的测试只能采用 评审法,测试对象的生命期和转移事件的条件。
分析模型测试内容用例模型的测试相当于系统测试，测试的主要目标是用例模型对于用户需求的可跟踪性。
用例模型的测试可以通过系统的可能用户对系统的功能要求来设计测试用例。
以系统的用户为主要的出发点设计测试用例，通过模拟某个系统用户的行为来测试整个系统，对于该用户的服务提供情况，从而检查系统功能的完整性，用户需求可跟踪性等情况。
用例模型的测试从系统用户的角度测试系统的服务，并不关心每个测试用例所实现的功能如何，所以应该是黑盒测试。
6.4.1 用例模型的测试下面以一个订货中心系统的用例模型为例说明测试用例的设计。
识别五个主要的系统角色 (用户 )：
管理者 (Manager)、发货人员 (Shipper)
收款人员 (Toll collector)、商务客户 (Customer)
信用卡 (Creditcard)
从各个角色出发通过下边的问题识别用例：
角色要求系统提供的功能有哪些？系统在提供这些功能的时候该角色需要做什么？
角色需要创建、阅读、销毁或存储系统的哪些信息？
系统中的哪些事件需要通知该角色？
以管理者为例：
(1)管理者要求系统为他提供什么功能？管理者需要做哪些工作？
答：管理者要求系统提供
a.接受顾客订货请求并创建订单；
b.计算订单的价钱；
c.根据订单信息选择仓库，并将订单发送给仓库；
d.查询订单货物发送情况；
e.查询客户订单付款情况；
f.评价商务结果；
g.顾客退货处理；
h.把仓库返回的订单发送到收费处；
i.商品价格更新。
管理者需要做,生成订单；查询订单时输入订单号。
(2)管理者需要阅读创建、销毁、更新或者存储系统哪些信息？
答：信息包括：订单、职员 (仓库人员、收费人员等 )信息、
顾客信息、物品条目及价格信息、仓库信息和税务信息 。
(3)系统中的事件一定要告诉管理者吗？
答：是。这些事件包括：仓库有关物品短缺以致无法满足某订单；订单数据出现错误；顾客超过期限未付款。
可见，管理者要使用系统的十个功能，因此至少可以设计出十个测试用例。
下面以第三条功能,根据订单信息选择仓库，并将订单发送给该仓库,为例,显然，不同的订单产生的结果可能是送往不同的仓库来处理。
系统用户考虑分配订单到某仓库的因素：
(1)首先仓库必须能够满足订单上的货物要求；
(2)选择地理位臵与发货点较近的仓库发货；
(3)信誉满意度越高的客户就越应该以较高的服务质量来回报。
三个订单信息如下：
订单号 送货地点 货物名称及数量 客户信誉订单 1 北城某集团公司 G1(200),G5(100),G10(40) 95
订单 2 东城某街道 G5(10),G6(5) 80
订单 3 北城某街道 G4(10) 85
仓库名称 仓库位臵 存货品名及数量 订单处理客户信誉度
A 东城 G1(200),G5(100),G6(1000)，G10(70),G11(90) 85
B 西城 G1(1000),G2(100),G5(250)，G8(150),G10(98) 95
C 北城 G1(220),G4(300),G5(350)，G7(400),G10(700) 80
结合考虑上面三个因素，以最少的成本取得最好的收益，
测试用例 1：
输入：订单 1
预期结果：选择仓库 B来处理订单 (三个均可，大宗订单，
客户信誉度高 )；
测试用例 2：
输入：订单 2
预期结果：选择仓库 A来处理订单 (个人订单，客户信誉一般 )；
测试用例 3：
输入：订单 3
预期结果：选择仓库 C来处理订单。
以上测试未触及某个具体用例，体现了用例模型测试和用例测试的区别。
类模型是分析模型中的核心，它抽象出了问题域中的对象和实体，以及它们在问题域中的职责。
为确保类模型的正确性和完整性，只根据问题域测试类模型。测试方法是 评审会 。
类图实际上由类和类之间的关系组成，评审会的检查单可从以下两个方面制定。
6.4.5 类模型的测试针对每个类提问：
(1)该类在问题域中对应的实体 (或对象 )是什么？
(2)履行什么职责？
(3)在类图中被赋予了哪些职责？
(4)该类在问题域中的职责和在类图中的职责能匹配吗？
(5)该类的每个数据属性都是问题域所关心的吗？
针对类图中的类之间的关系提问：
(1)这种类关系是反映了问题域本质的关系还是为管理类模型而引入的关系？ (如果类之间的关系并非反映问题域的本质,
那么这个关系的存在就值得怀疑 。 )
(2)仔细检查每个继承关系,到底是聚集关系还是继承关系？
(3)针对关联关系中的关联数目,提一些问题结合实际场景来考察 。
从模型的角度可以关心如下问题：
(1)状态模型刻画了对象的生命周期吗？
(2)针对每个状态而言，状态转移触发条件是状态转移的充分条件吗？
(3)对象在问题域需要响应的所有条件是否在状态模型中都有响应？
(4)关心对象在某些状态中的动作，如果对象需要发送消息给其它对象，那么此时接收该消息的对象处在其声明周期的什么阶段？
(5)从初始状态开始,每个状态都可以达到吗？
6.4.6 类状态模型的测试类状态模型描述了一个对象在问题域中的活动历程。
在分析阶段，识别的对象还只是停留在较粗的层次上，因此，对象状态模型的测试通常只能采用评审会的办法。只测试在问题域中非常重要的对象，如电梯系统中的电梯对象。
上述五个问题可以作为评审会问题检查单的选择。
对问题 (1)：
检查状态模型对于对象状态的划分，一旦出现识别的状态不足，或者某些状态超出问题域的关心，分析原因，分析员在评审会报告想法和理由。
对问题 (2)：
检查状态转移条件，验证当触发条件满足时是否会出现状态转移，要求触发条件是最简化的 (无冗余条件 )。
对问题 (3)：
通过一张对照表可以找出答案。
对问题 (4)：
检查较复杂，容易发现分析错误的一个环节。通常，分析员以为进行交互的其它对象都处于,良好,状态，但这个假设常常不能成立，因为两个不同的对象可能与相应的事件会有交叉 (如定时事件 )。因此，当当前分析的对象发生了状态转移时，其它对象也发生了状态转移，所以在对象发送消息给其它对象时，也要注意接收该消息的对象是否处于合适的状态中。
对问题 (5)：
如果某个状态根本就不可达到，那么可以断定分析模型有错误。
类级别的单元测试中，状态模型可以辅助进行测试用例的模型。
顺着不同的状态演变路径来测试对象的动作行为 (操作序列 )，
如帐号对象的状态图。
open setup
deposit (initial)
deposit
withdrawbalance count
withdraw (final)
close
空帐号 帐号设置工作帐号无效帐号 当空帐号银行帐号共有 5个生命周期状态，设计下面的测试用例：
(1)测试用例 1：
open,setup,deposit (initial),withdraw (final),close;
(2)测试用例 2：
open,setup,deposit (initial),deposit,balance count,
withdraw (final),close;
(3)测试用例 3：
open,setup,deposit (initial),deposit,withdraw,balance
count,withdraw (final),close.
上述测试用例覆盖每个状态，并增量测试每个状态的转移。
该例不涉及复杂对象之间的交互情况，有对象交互的测试用例设计将更加困难。
如果通过覆盖状态模型中的每个状态和每个状态转移，
那么就可以测试到对象之间的各种情况。
类状态模型的测试典型场景是指系统用户经常使用系统的方式。典型场景是用例模型的一个实例。
典型场景测试主要关注用例执行情况，典型场景测试可能涉及到不止一个用例，通常测试的是系统的功能。
测试可以根据需求分析出发列出的一些典型场景 (顺序图模型所描述 )进行 。 如果无典型场景的顺序图模型,
可以把几个不同用例的顺序图模型联合起来,并选择一条对象交互链作为一个典型场景,这个场景就是测试用例 。
4.3.6 典型场景的测试
6.5 软件纠错技术软件测试的目的是发现错误，在发现错误后，
则应按照一定的技术去纠正它。纠错的关键是
“错误定位”。
一、纠错的原则
1、注意错误的“群集现象”。
2、不能只修改错误的征兆、表现。还应该修改错误的本质。
3、注意在修改一个错误的同时，又引入新的错误。
二、纠错的技术
1、硬性纠错又称为蛮干法，是使用较多，效率较低的方法。
主存信息转储法关键部分设臵打印语句使用自动纠错工具
2、回 溯法排错适用于小程序。发现错误时，人工沿控制流追踪源代码程序。
3、归纳法从测试结果发现的错误入手，分析它们之间的联系查找错误。是一种从特殊推断一般的系统化思考方法。
收集有关数据 组织数据研究数据间的关系 提出假设证明假设纠正错误能能不能不能列出所有已知的测试用例和程序执行结果常用的构造线索的技术是“分类法”
分析线索之间的关系，找出矛盾，设计出错原因的假设归纳排错法步骤将假设与原始线索或数据进行比较，
能否解释现象，证明假设。
yes no
What
When
where
How
4、演绎法排错演绎法是一种从一般原理出发，经过排除和精化的过程，推导出结论的方法。
列举可能的原因排除不适当的原因对保留的假设继续推断证明假设纠正错误收集更多的数据没有剩余不能能有剩余演绎法排错的步骤
