第六章 软件测试
§ 6.1 基本概念软件开发过程必须伴有质量保证活动。
软件测试是软件质量保证的关键元素，代表了规约、设计和编码的最终检查。
6.1.4 测试用例设计选择测试用例是软件测试员最重要的一项工作。
测试用例的属性,
属性 描述
name 测试用例的名称
location 可执行的完全路径名
input 输入数据或命令
oracle 与测试输入相比较的期待测试结果
log 测试生产的输出
6.1.5 软件测试信息流软件配置测试测试配置测试工具结果分析排错可靠性分析测试结果错误预期结果出错率改正的软件预测的可靠性需求规格说明书软件设计说明书被测源程序测试计划测试用例
(测试数据 )
测试驱动程序测试活动和相关工作产品项目协议对象设计 客户开发人员 用户集成策略系统分解功能性需求非功能性需求单元测试集成测试结构测试功能测试性能测试来自 ODD
来自 TP
来自 SDD
来自 RAD
来自 RAD
用户手册验收测试安装测试现场测试日常操作测试设计中需要考虑的 22种测试类型
黑盒测试
白盒测试
单元测试
累计综合测试
集成测试
功能测试
系统测试
端到端测试
健全测试
衰竭测试
接受测试
负载测试
强迫测试
性能测试
可用性测试
安装 /卸载测试
恢复测试
兼容测试
安全测试
比较测试
Alpha测试
Beta测试
6.1.6 测试的方法与技术软件测试的策略和方法静态测试方法动态测试方法人工测试方法计算机辅助静态分析方法白盒测试方法黑盒测试方法动态测试方法
(1)选取定义域有效值,或定义域外无效值,
(2)对已选取值决定 预期的结果
(3)用选取值执行程序
(4)执行结果 与 (2)结果相比,
不吻和程序有错,
动态黑盒测试 —闭着眼睛测试软件软件输入不深入代码细节的测试方法称为动态黑盒测试。
软件测试员充当客户来使用它。
输出动态白盒测试 —带上 X光眼镜测试软件
3581322.293419985680302829734315
250*(1+0.015)*((1+0.015)^360-1)/0.015 250*(1+0.015)*((1+0.015)^360-1)/0.015
假如知道一个盒子包含一台计算机,而另一个盒子是人用纸笔计算,就会选择不同的测试用例了解软件的运作方式会影响测试手段
§ 6.2 两种类型的测试
6.2.1 黑盒测试又称,功能测试数据驱动测试基于规格说明书的测试
6.2.2 白盒测试又称,开盒测试结构测试玻璃盒测试基于覆盖的测试,
根据被测程序的逻辑结构设计测试用例 ;
力求提高测试覆盖率 ;
黑盒测试与白盒测试比较黑盒测试 是从用户观点，按规格说明书要求的输入数据与输出数据的对应关系设计测试用例,
是根据程序 外部特征 进行测试。
白盒测试 是根据程序 内部逻辑结构 进行测试。
黑盒测试与白盒测试优缺点比较黑盒测试 白盒测试优点缺点性质
① 适用于各阶段测试
②从产品功能角度测试
③容易入手生成测试数据
① 可构成测试数据使特定程序部分得到测试
②有一定的充分性度量手段
③可或较多工具支持
① 某些代码得不到测试
②如果规格说明有误，
则无法发现
③不易进行充分性测试
① 不易生成测试数据 (通常 )
② 无法对未实现规格说明的部分进行测试
③工作量大，通常只用于单元测试，有应用局限是一种 确认 技术，回答
,我们在构造一个正确的系统吗？,
是一种 验证 技术，回答
,我们在正确 地构造一个系统吗？,
不论黑盒还是白盒测试都 不能进行穷尽测试,所以软件测试不可能发现程序中存在的所有错误,因此需精心设计测试方案,力争尽可能少的次数,测出尽可能多的错误,
黑盒测试与白盒测试能发现的错误
C BA
D
-只能用黑盒测试发现的错误A
-只能用白盒测试发现的错误
-两种方法都能发现的错误
-两种方法都不能发现的错误
BC
D
§ 6.3白盒测试的测试用例设计
6.3.1 逻辑覆盖法
(1)语句覆盖
(2)判定覆盖
(3)条件覆盖
(4)判定 /条件覆盖
(5)条件组合覆盖
(6)路径覆盖
(7)点覆盖
(8)边覆盖例,PROCEDURE SAMPAL
(A,B,REAL； VAR 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)
(A=2) OR (X>1)
返回
X=X/A
X=X+1
F
F
T
T
a
b
d
c
e
(1)语句覆盖使程序中每个语句至少执行一次语句覆盖 开始
(A>1) AND (B=0)
(A=2) OR (X>1)
返回
X=X/A
X=X+1
F
F
T
T
a
b
d
c
e
只需设计一个测试用例,
输入数据,A=2,B=0,X=4
即达到了语句覆盖 ;
语句覆盖是 最弱 的逻辑覆盖
(2)判定覆盖 (分支覆盖 )
使每个判定的真假分支都至少执行一次判定覆盖 开始
(A>1) AND (B=0)
(A=2) OR (X>1)
返回
X=X/A
X=X+1
F
F
T
T
a
b
d
c
e
例,可设计两组测试用例,
A=3,B=0,X=3 可覆盖 c,d分支
A=2,B=1,X=1 可覆盖 b,e分支两组测试用例可覆盖所有判定的真假分支语句覆盖仍是 弱 的逻辑覆盖
(3)条件覆盖使每个判定的每个条件的可能取值至少执行一次第一判定表达式,
设 条件 A>1 取真 记为 T1
假 T1
条件 B=1 取真 记为 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+1
F
F
T
T
a
b
d
c
e
满足条件,T1,T1,
T2,T2
T3,T3
T4,T4
测试用例 通过 满足的 覆盖
A B X 路径 条件 分支
1 0 3 abe T1,T2,T3,T4 b,e
2 1 1 abe T1,T2,T3,T4 b,e
两个测试用例 覆盖了四个条件八种可能取值 。
未覆盖 c,d分支,不满足判定覆盖的要求,
条件覆盖不一定包含判定覆盖判定覆盖也不一定包含条件覆盖
(4)判定 /条件覆盖选取足够多的测试用例,使判断中的每个条件的所有可能取值至少执行一次,同时每个判断本身的所有可能判断结果至少执行一次,
判定 /条件覆盖 开始
(A>1) AND (B=0)
(A=2) OR (X>1)
返回
X=X/A
X=X+1
F
F
T
T
a
b
d
c
e
满足条件,T1,T1,
T2,T2
T3,T3
T4,T4
测试用例 通过 满足的 覆盖
A B X 路径 条件 分支
2 0 4 ace T1,T2,T3,T4 c,e
2 1 1 abd T1,T2,T3,T4 b,d
能同时满足判定、条件两种覆盖标准。
取值。
测试用例 通过 满足的 覆盖
A B X 路径 条件 分支
2 0 3 ace T1,T2,T3,T4 c,e
2 1 1 abe T1,T2,T3,T4 b,e
1 0 3 abe T1,T2,T3,T4 b,e
1 1 1 abd T1,T2,T3,T4 b,d
(5)条件组合覆盖所有可能的条件取值组合至少执行一次
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
测试用例 通过 满足的 覆盖
A B X 路径 条件 分支
2 0 4 ace T1,T2,T3,T4 c,e
2 1 1 abe T1,T2,T3,T4 b,e
1 0 2 abd T1,T2,T3,T4 b,d
1 1 1 abd T1,T2,T3,T4 b,d
(6)路径覆盖覆盖每一个可能的路径测试用例 通过 满足的 覆盖
A B X 路径 条件 分支
1 1 1 abd T1,T2,T3,T4 b,d
1 1 2 abe T1,T2,T3,T4 b,e
3 0 1 acd T1,T2,T3,T4 c,d
2 0 4 ace T1,T2,T3,T4 c,e
基本路径测试法通过分析由控制构造的环路的复杂性，导出基本路径集合，从而设计测试用例，保证这些路径至少通过一次。
基本路径测试步骤：
导出程序流程图的拓扑结构 -流图
(程序图 )
计算流图 G的环路复杂度 V(G)
确定只包含独立路径的基本路径集
设计测试用例
导出程序流程图的拓扑结构 -流图
1
2,3
6 4,5
7
10
6
11
a
节点边 R4
区域
1
2
3
4
5
87
3
9
11
程序流程图
8
9
R1
R2R3
计算流图 G的环路复杂度 V(G)
V(G)= 区域个数 =4
V(G)=边的条数 -节点个数 +2=4
V(G)=判定节点个数 +1=4
确定只包含独立路径的基本路径集
path1:1-11
path1:1-2-3-4-5-10-1-11
path1:1-2-3-6-8-9-10-1-11
path1:1-2-3-6-7-9-10-1-11
一条新路径必须包含一条新边。
这 4条路径组成了一个基本路径集。 4(环路复杂度 V(G))是构成这个基本路径集的独立路径数的上界，也是设计 测试用例的数目。
设计测试用例，保证基本路径集中每条路径的执行。
§ 6.4黑盒测试的测试用例设计
6.4.1 等价类划分法把所有可能的输入数据 (有效的和无效的 )划分成若干个等价的子集
(称为等价类 ),使得每个子集中的一个典型值在测试中的作用与这一子集中所有其它值的作用相同,
可从每个子集中选取一组数据来测试程序例,某报表处理系统要求用户输入处理报表的日期，日期限制在 2001年 1
月至 2005年 12月，即系统只能对该段期间内的报表进行处理，如日期不在此范围内，则显示输入错误信息。
系统日期规定由年、月的 6位数字字符组成，前四位代表年，后两位代表月。
如何用等价类划分法设计测试用例,
来测试程序的日期检查功能？
如何划分等价类？
有效等价类 (合理等价类 )
无效等价类 (不合理等价类 )
划分等价类的标准：
覆盖
不相交
代表性划分等价类的规则
(1)如果输入条件规定了取值范围，
可定义一个有效等价类和两个无效等价类。
例 输入值是学生成绩，范围是 0～ 100
0 100
有效等价类
1≤ 成绩 ≤ 100
无效等价类成绩 >100
无效等价类成绩 <0
～
划分等价类的规则：
(2)如果输入条件代表集合的某个元素，则可定义一个有效等价类和一个无效等价类。
划分等价类的规则：
(3)如规定了输入数据的一组值,且程序对不同输入值做不同处理,
则每个允许的输入值是一个有效等价类,并有一个无效等价类
(所有不允许的输入值的集合 )。
例：输入条件说明学历可为,专科,本科,
硕士,博士 四种之一,则分别取这四种这四个值作为 四个有效等价类,另外把四种学历之外的任何学历作为无效等价类划分等价类的规则：
(4)如果规定了输入数据必须遵循的规则,可确定一个有效等价类 （ 符合规则 ） 和若干个无效等价类 （ 从不同角度违反规则 )。
(5)如已划分的等价类各元素在程序中的处理方式不同,则应将此等价类进一步划分成更小的等价类 。
用等价类划分法设计测试用例步骤：
(1)形成等价类表,每一等价类规定一个唯一的编号；
(2)设计一测试用例,使其尽可能多地覆盖尚未覆盖的有效等价类,
重复这一步骤,直到所有有效等价类均被测试用例所覆盖；
(3)设计一新测试用例,使其只覆盖一个无效等价类,重复这一步骤直到所有无效等价类均被覆盖；
第一步：等价类划分输入等价类 有效等价类 无效等价类报表日期的类型及长度 3位数字字符 (1)
有非数字字符 (4)
少于 6个数字字符 (5)
多于 6个数字字符 (6)
年份范围 在 2001～ 2005之间 (2) 小于 2001 (7)大于 2005 (8)
月份范围 在 1～ 12之间 (3)
“报表日期,输入条件的等价类表小于 1 (9)
大于 12 (10)
第二步,为有效等价类设计测试用例对表中编号为 1,2,3的 3个有效等价类用一个测试用例覆盖：
测试数据 期望结果 覆盖范围
200105 等价类 (1)(2)(3)输入有效第三步：为每一个无效等价类设至少计一个测试用例测试数据 期望结果 覆盖范围
001MAY 等价类 (4)输入无效
20015 等价类 (5)输入无效
2001005 等价类 (6)输入无效
200005 等价类 (7)输入无效
200805 等价类 (8)输入无效
200100 等价类 (9)输入无效
200113 等价类 (10)输入无效不能出现相同的测试用例本例的 10个等价类至少需要 8个测试用例例,对招干考试系统“输入学生成绩”
子模块设计测试用例招干考试分三个专业,准考证号第一位为专业代号,如,1-行政专业,
2-法律专业,
3-财经专业,
行政专业准考证号码为,110001～ 111215
法律专业准考证号码为,210001～ 212006
财经专业准考证号码为,310001～ 314015
例,准考证号码的等价类划分有效等价类,
(1) 110001 ～ 111215
(2) 210001 ～ 212006
(3) 310001 ～ 314015
无效等价类,
(4) -? ～ 110000
(5) 111216 ～ 210000
(6) 212007 ～ 31000
(7) 314016 ～ +?
例,计算给定月份中天数的方法接口
(java):
Class MyGregorianCalender{
……
public static in getNumDaysInMonth(int
month,int year){…}
……
}
getNumDaysInMonth( )方法有两个参数,月和年,年份的有效输入是从 0到 maxInt.
等价类划分 即把 输入空间分解成一系列子域,软件在一个子域内的行为应是等价的 。
软件错误分为两类,计算错误域错误
针对 计算错误的测试方法
针对 域错误 的测试方法,测试 域边界划定的正确性
6.4.2 边界值分析法边界值分析法与等价类划分法区别
(1)边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
(2)边界值分析不仅考虑输入条件，
还要考虑输出空间产生的测试情况被测试子 域测试内点测试外点软件边界与悬崖很类似边界条件类型如果软件测试问题包含确定的边界,那么数据类型可能是,
数值
字符
位置
数量
速度
地址
尺寸
……
还要考虑数据类型的特征,
第一个 /最后一个
最小值 /最大值
开始 /完成
空 /满
最慢 /最快
相邻 /最远
超过 /在内
……
测试边界线
测试临近边界的合法数据,以及刚超过边界的非法数据,
越界测试通常简单地加 1或很小的数
(对于最大值 )和减 1或很小的数 (对于最小值 ).
输入条件报表日期的类型及长度
1个数字字符
5个数字字符
7个数字字符有 1个非数字字符全部是非数字字符
6个数字字符显示出错显示出错显示出错显示出错显示出错输入有效日期范围月份范围
“报表日期,边界值分析法测试用 例测试用例说明 测试数据 期望结果 选取理由
5
20015
2001005
2001.5
MAY---
200105
月份为 1月月份为 12月月份 <1
月份 >12
200101
200112
200100
200113
200101
200512
200100
200513
输入有效输入有效显示出错显示出错输入有效输入有效显示出错显示出错在有效范围边界上选取数据仅有 1个合法字符比有效长度少 1
比有效长度多 1
只有 1个非法字符
6个非法字符类型及长度均有效最小日期最大日期刚好小于最小日期刚好大于最大日期最小月份最大月份刚好小于最小月份刚好大于最大月份
6.4.3 错误推测法 (error guessing)
根据经验来设计测试用例的方法例如，数据测试中的,
缺省值
空白
空值
零值
无
6.4.4 状态测试软件必须测试程序的状态及其转换。
测试软件的逻辑流程
建立状态转换图
减少要测试的状态及转换的数量空闲等待用户输入命令按下 Esc键显示口令框口令错误消除口令正确初始状态消失空闲等待用户输入命令按下 Esc键 口令正确口令错误不同形式的状态转换图设置 2Bwatch 上的时间的顺序图
:2Bwatch用户按下按钮 1和 2
:2Bwatch输入,2Bwatch显示,2Bwatch时间时间按下按钮 1
按下按钮 2
按下按钮 1和 2
闪烁小时闪烁分钟增加分钟刷新提交更新时间停止闪烁
2Bwatch 设置时间功能的状态图和测试结果按左按钮按右按钮按左按钮按右按钮
4,2分钟以后测量时间 设置时间电池没电
3.按下左右按钮
5.按下左右按钮 /蜂鸣
8,20年以后7,20年以后
6.2,1.
激励因素空集合 测量时间1.初始变迁测试的变迁 预期结果状态按下左边按钮 测量时间2.
同时按下两个按钮 设置时间3.
等 2分钟 测量时间4.超时
…… …………
失败状态测试找到测试软件失败的案例 。
竞争条件和时序错乱
重复
压迫
重负应联合使用，同时进行有效等价类和用来测试 getNumDaysInMonth()
方法所选的有效输入有效 等价类一个月有 31天,非闰年 19017(七月 )
一个月有 31天,闰年 19047(七月 )
一个月有 30天,非闰年 19016(六月 )
一个月有 30天,闰年 19046(六月 )
一个月为 28或 29天,非闰年 19012(二月 )
月份输入值年份输入值一个月为 28或 29天,闰年 2(二月 ) 1904
用来测试 getNumDaysInMonth()方法的附加边界值等价类可以被 400整除的闰年 20002(二月 )
可以被 100整除的非闰年 19002(二月 )
非正数无效月份 12910
正数无效月份 131513
月份输入值年份输入值
6.4.5 因果图法因果图适合于描述对于多种输入条件的组合，相应产生多个动作的形式来设计测试用例。
因果图方法最终生成的是判定表。
因果图方法实例某电力公司有 A,B,C,D四类收费标准,
并规定：
居民用电 <100度 /月 按 A类收费
≥ 100度 /月按 B类收费动力用电 <10000度 /月,非高峰,B类收费
≥ 10000度 /月,非高峰,C类收费
<10000度 /月,高峰,C类收费
≥ 10000度 /月,高峰,D类收费用因果图表明输入和输出间的逻辑关系
1 I1
2 B∨
∧
4
A
C3
5
∧
D
I4
I3I2 ∨∧
∧
∧
∧
把因果图转换为判定表组合条件条件
(原因 )
动作
(结果 )
A
B
C
1
2
3
1 2 3 4 5 6
1
0
1
1
0
0
0
1 1
0 0 0
1 1
0 0 0 0
1 0 0 0
0 1 1 0
4 1 0 1 0
5 0 0 1 1
D 0 0 0 1
1 0
0 1
0 0
0 0
测试用例为判定表每一列设计一个测试用例,
1列 居民电,90度 /月 A
2列 居民电,110度 /月 B
3列 动力电,非高峰,8000度 /月 B
4列 动力电,非高峰,1.2万度 /月 C
5列 动力电,高峰,0.9万度 /月 C
6列 动力电,高峰,1.1万度 /月 D
条件 测试用例 预期结果组合 (输入数据 ) (输出动作 )
§ 6.5 针对专门环境和应用的测试
6.5.1 GUI测试常见 GUI测试指南：?
对于窗口?
对于菜单和鼠标操作?
对于数据项
6.5.2 C/S体系结构的 测试整体 C/S测试策略 (三个不同层次 )
客户端应以,分离的,模式被测试
(不考虑服务器和底层网络的运行 )
客户端软件和关联的服务器端应用被一起测试 (网络运行不被明显考虑 )
完整的 C/S体系结构 (包括网络运行和性能 )
被测试
C/S常用测试方法
客户端应用功能测试
服务器测试 （ 协调和数据管理功能,
性能 ）
数据库测试
事务测试
网络通信测试
6.5.3 实时系统测试可采用以下四步策略：
(1) 任务测试
(2) 行为测试
(3) 任务间测试
(4) 系统测试
(1) 任务测试 (task testing)
对每一个任务进行单独测试
(白盒、黑盒测试 )，发现 逻辑和功能上错误,不能发现定时上和行为上错误 。
(2)行为 测试 (behavioral testing)
用 CASE工具创建应用系统模型，
模拟实时系统行为。
按类测试各种事件 (如中断、控制信号、数据 )。
测试过的事件以随机次序、随机频率送给系统,检查软件 行为方面的错误,
(3)任务间测试 (intertask testing)
检查 与时间有关错误 。
如用不同数据速率、处理负载测试相互通信的异步任务。
通过消息队列或数据存储测试任务间的通信来找出数据存储区错误的范围。
(4) 系统测试 (system testing)
软件、硬件组装后，找出 软、
硬件接口错误 。
软件测试的过程被测模块 单元测试设计信息集成测试被测模块 单元测试被测模块 单元测试测试过的模块确认测试系统测试软件需求其它系统元素装配好的软件确认的软件可运行的软件
§ 6.6软件测试的步骤软件测试策略单元测试U
C
D
R
S
I
V
ST
集成测试确认测试系统测试系统工程软件需求分析软件设计代码编写
6.6.1 单元测试一,单元测试的内容主要对模块的 五个基本特性 进行评价模块错误处理模块接口局部数据结构重要的执行路径 边界条件
1.常见错误类型
接口错误
I/O错误
数据结构错误
算法错误
比较及控制逻辑错误
错误处理错误
2,模块测试基本原则
至少一次测试所有语句
测试所有可能的执行或逻辑路径的组合
测试每个模块的所有入口和出口
3,确定单元测试数据集
值域
值类
离散值
值的次序集 (测试顺序文件和 表 )
二,单元测试的方法单元测试一般为编码步骤的附属部分,
模块不是独立的程序,自己不能运行,
要靠其它部分来调用和驱动,要为每个单元测试开发两个软件,
(1)驱动模块 (驱动程序 ):相当于主模块
(2)桩模块 (测试存根、连接程序 ),
代替所测模块调用的子模块单元测试的测试环境举例,
B
A
CD
E待测试模块单元测试的测试环境举例,
被测模块 B
驱动模块
(模拟模块 A)
桩模块 (测试存根 )
(模拟模块 E)
测试用例 测试结果许多模块不能用简单的软件进行充分的单元测试,此时,完全的测试可放到集成测试阶段再进行,
单元测试的测试环境举例,
实际软件华氏到慑氏转换模块温度数据实际配置测试用例数据结果测试驱动软件华氏到慑氏转换模块结果测试驱动际配置单元测试的测试环境举例温度显示模块温度接口模块实际配置 测试驱动际配置温度显示模块程序员编写的桩模块
(测试存根 )
温度值的测试文件结构性模式 (structural patterns)
适配器模式 (Adapter)—打包器 (Wrapper)
桥模式 (Bridge)—句柄 (Handle)
组合模式 (Composite)
修饰模式 (Decorator)—包装器 (Wrapper)
外观模式 (Facade)
轻量模式 (Flyweight)
代理模式 —(Proxy)
6.6.2 集成测试 (组装测试 )
集成测试需考虑的问题,
数据穿越接口可能丢失,
一模块可能破坏另一模块功能,
子功能组装可能未产生所要求的主功能,
全程数据结构可能出问题,
误差累积问题,
集成测试方法通常采用黑盒测试技术实施策略,
非渐增式测试
渐增式测试深度优先广度优先自顶向下结合自底向上结合一,非渐增式集成方式一次就把所有通过了单元测试的模块组合在一起进行全程序的测试,
缺点,发现错误难以诊断定位,
又称,莽撞测试,,
二,渐增式集成方式从一个模块开始,测一次添加一个模块,边组装边测试,以发现与接口相联系的问题 。
自顶向下结合方式举例,
A
DB
E
模块测试结合顺序
C
F
深度优先,A,B,E,C,D,F
广度优先,A,B,C,D,E,F
自顶向下结合方式举例,(深度优先 )
A
测试 A
S2S1 S3
A
加入 B
S2B S3
S4
A
加入 E
S2B S3
E
A
加入 C
CB S3
E
加入 D
CB D
E
加入 F
CB D
E
A A
FS5
自底向上结合方式举例,
A
CB D
FE
E
d1
C
d3
F
d4
B
d2
E
D
d5
F
自底向上结合方式举例,
Mc
D1
Ma Mb
D2 D3
簇 1
簇 2
簇 3
自顶向下 自底向上优点 可在测试早期 设计测试用例容易实现并验证系统主要功能不需驱动模块 不需桩模块缺点 需桩模块 只有到最后程序才能作为一个整体
3,混合集成测试方法
一般对软件结构的上层使用自顶向下结合的方法 ;
对下层使用自底向上结合的方法 ;
6.6.3 确认测试 (有效性测试 )
有效性测试软件配置审查管理机构裁决选择测试人员软件计划用户文档开发文档源程序文本支持环境交用户运行维护测试报告软件配置构造测试用例
(验收测试 )
实际运行测试 专家鉴定会一,有效性测试通过 黑盒测试,证实软件功能与用户需求是否一致,
二,软件配置审查与验收确认测试软件配置审查主管部门批准集成的软件软件需求用户文档设计文档源程序测试文档交付的软 件确认的软 件确认的配 置三,人工测试静态分析对源程序进行静态分析的方法：
生成各类引用表
静态错误分析
类型和单位分析
引用分析
表达式分析
接口分析对源程序进行静态分析的方法：
(1)桌前检查
检查变量、标号的交叉引用
检查子程序、宏、函数、
常量检查
标准、风格检查
(2)代码会审
(3)走查四,确认测试结果测试完成后可能出现两种情况,
(1)测试与预期相符,可接受,
(2)不相符,列出软件缺陷表,与用户协商解决,
五,α 测试和 β 测试
α 测试 (Alpha)
在开发者的场所由用户进行,在开发着关注和控制的环境下进行,
β 测试 (Beta)
最终用户在自己的场所进行,
6.6.4 系统测试软件只是计算机系统的一个元素，软件最终要与其他系统元素（如新硬件、信息等 )相结合，
进行各种集成测试和确认测试,
用于系统测试的测试类型,
(1)恢复测试
(2)安全性测试
(3)强度测试
(4)性能测试推测残留在程序中的错误数错误植入模型
Mills将 播种模型 用于程序中残留错误的估算,称 错误植入模型播种模型：
N,程序中原有残留的错误数
Nt：新植入的错误数
n,测试发现的原有错误数
nt,测试发现的植入错误数
N
N
n
n
t ≈ t
NN nn t=
t
Hyman对错误植入模型的改进
ET,程序中原有的残留错误数
E1,1号测试员在某一时间内发现的错误数
E2,2号测试员在同一时间内发现的错误数
E0,两位测试员共同发现的错误数
E
E
E
E
1 ≈ 0 =
2T E
T E1 E 2 /E0
(1)恢复测试以不同的方式强使软件出现故障,检测软件能否恰当地完成恢复,
自动恢复,检测重新初始化、
检测点设置、
数据恢复、
重新启动等是否正确,
人工干预恢复,检测平均恢复时间是否在允许范围内,
(2)安全性测试设计测试用例,突破软件安全保护机构的安全保密措施,检验系统预防机制的漏洞,
(3)强度测试设计测试用例,检验系统能力最高能达到的实际限度,让系统处于资源的异常数量、异常频率、异常批量的条件下测试系统的承受能力,
一般比平常限度高 5-10倍的限度做测试用例,
§ 6.6 面向对象的软件测试测试 目标,在现实的时间跨度内应用可管理的工作量去发现最大可能数量的错误?
基本目标不变，但由于 OO程序的性质改变了 测试策略和测试战术
更多的设计模式复用是否将减轻 OO系统的繁重 测试？
Binder,R.V.在,Object-Oriented Software Testing”中讨论改问题,
“每次复用是一个新的使用语境,并且重新测试是谨慎的,为了获得面向对象系统的高可靠性,似乎可能需要更多而不是更少的测试,”
强度测试 是一种敏感性测试技术,某种情况下,一包含在程序有效数据边界内的非常小范围的数据变动可能导致 极端的,甚至错误的处理,或使系统性能严重下降,
敏感性测试用来发现可能导致不稳定或不正确处理的有效输入类中的数据组合,
(4)性能测试设计测试用例，并记录软件运行性能，与性能要求比较，检验是否达到性能要求规格。
6.6.5 测试的步骤及相应的测试种类
§ 6.6 面向对象的软件测试测试 目标,在现实的时间跨度内应用可管理的工作量去发现最大可能数量的错误?
基本目标不变，但由于 OO程序的性质改变了 测试策略和测试战术
更多的设计模式复用是否将减轻 OO系统的繁重 测试？
Binder,R.V.在,Object-Oriented Software Testing”中讨论改问题,
“每次复用是一个新的使用语境,并且重新测试是谨慎的,为了获得面向对象系统的高可靠性,似乎可能需要更多而不是更少的测试,”
6.6.1 OOA和 OOD的 模型 测试每个阶段的所有面向对象模型都应被测试。
OOA和 OOD的模型不能被执行，对它们不能进行传统意义上的测试。
可通过技术复审检查 OOA和 OOD的模型的正确性和一致性。
扩大测试的视角
6.6.2 面向对象测试策略
信息隐蔽对测试的影响?
封装和继承对测试的影响面向对象程序的特点对软件测试的影响：
单元和集成测试策略必须有很大的改变
测试用例的设计必须考虑 OO软件的特征
1,OO的单元测试
一个类可以包含一组不同的操作，而一个特定的操作也可能存在于一组不同的类中。 不再孤立地测试单个操作 (这是传统单元测试的视角 )
OO软件的 类测试 等价于 传统的单元测试,
传统软件的单元测试关注算法细节和模块接口间流动的数据
OO软件的类测试是由封装在类中的操作和类的状态行为驱动的单元概念 的变化 —封装的类或对象作为最小的可测试单位
2,OO的集成测试
OO软件没有层次的控制结构,传统的自顶向下和自底向上的集成策略没有意义,
OO软件的集成两种策略,?
基于线程的测试 (thread-based testing)
集成响应系统的一个输入或事件所需的一组类,每个线程被个体地集成和测试,通过回归测试保证没有副作用产生 ;
基于使用的测试 (use-based testing)
通过测试几乎不使用服务器的类 (独立类 )来开始系统的构造,测试完独立类后,使用独立类按层逐步完成依赖类的测试直至完整的系统被构造 ;
3,OO的确认测试在确认和系统测试层次,类连接的细节消失,
和传统的确认测试一样,OO软件的确认关注用户可见的动作和用户可识别的系统输出,
为辅助确认测试的导出,应利用分析模型中的用例图提供的场景来提高交互需求中发现错误的可能性
6.6.3 OO软件的测试用例设计
每个测试用例应被唯一标识，并应显式地和与被测试类相关联?
测试的目的应被陈述?
对每个测试应开发一组测试步骤，包括：
将被测试对象的一组 特定状态
将被作为测试的结果使用的一组 消息和操作
当对象被测试时可能产生的一组异常
一组外部条件 (进行测试必须的软件外部环境的变化 )
将辅助理解或实现测试的补充信息
OO软件的测试用例设计还处于成型期,
Binder,R.V.在,Essays on Object-Oriented Software
Engineering”
中建议了对 OO软件的测试用例设计的整体方法,
1,OO概念的测试用例设计的含义
封装可能会成为测试的障碍测试需要报告对象的具体和抽象状态，而封装使得对象的状态快照难于获得。
继承，特别是多继承使测试复杂化子类继承或重载的父类成员函数的测试问题
继承的成员函数是否都不需要测试?
对父类中已经测试过的成员函数,两种情况需要在子类中重新测试,
继承的成员函数在子类中做了改动 ;
成员函数调用了改动过的成员函数的部分 ;
例如,
父类 Base有两个成员函数 Inherited()和 Redefined(),
子类 Derived只对 Redefined() 做了改动,
Derived ∷ Redefined() — 需要重新测试
Derived ∷ Inherited() — 如果它调用了 Redefined() 的语句,则需重新测试,否则不必子类继承或重载的父类成员函数的测试问题
对父类的测试是否能够照搬到子类?
上例中,Base∷ Redefined() 和 Derived ∷ Redefined() 已是 两个不同的成员函数,照理应对 Derived ∷ Redefined()
重新进行测试分析,设计测试用例,但由于它们的 相似性,只需在 Base∷ Redefined() 的测试要求和测试用例上添加对
Derived ∷ Redefined() 的新的测试要求和 增补相应的测试用例,
2,传统 测试用例设计方法的可用性
白盒测试方法可用于类定义的操作的测试
对具有简洁结构的类，白盒测试最好用于类级别的测试
黑盒测试方法也适合 OO系统
6.6.4 测试单个类的方法
（ 1） 随机测试例,银行系统的 account(帐户 )类有下列操作：
open(打开 )
setup(建立 )
deposit(存款 )
withdraw(取款 )
balance(余额 )
summarize(清单 )
creditLimit(透支限额 )
close(关闭 )
系统对 操作的限制：
必须在应用其它操作之前先打开帐户,在完成了全部操作之后才能关闭帐户 ;?……
在限制下还是存在 操作的许多排列一个 account类实例的最小行为历史包括下列操作,
open,setup,deposit,withdraw,close
account类的最小测试序列大量的其它行为可能在下面序列中发生,
open,setup,deposit,[deposit | withdraw | balance
| summarize | creditLimit] n,withdraw,close
一系列不同的操作序列可以随机地产生,例如,
测试用例 r1,open.setup.deposit.deposit.balance.
summarize.creditLimit.withdraw.close
测试用例 r2,open.setup.deposit.withdraw.deposit.
balance,creditLimit.withdraw.close
这些和其它的随机顺序测试被进行,以测试不同的类实例的生存历史,
测试单个类的方法
（ 2） 划分测试 (partition testing)
与测试传统软件时采用的等价类划分方法类似,
划分类别的方法,
基于状态的划分
基于属性的划分
基于功能的划分基于状态的划分根据类操作改变类状态的能力来划分类操作,
例：银行系统的 account(帐户 )类状态操作包括,deposit(存款 )
withdraw(取款 )
非状态操作包括,balance(余额 )
summarize(清单 )
creditLimit(透支限额 )
测试用例 p1(测试改变状态的操作 ),
open.setup.deposit.deposit..withdraw.close
测试用例 p2 (测试不改变状态的操作,在最小测试序列中的操作除外 ),
open.setup.deposit.summarize,creditLimit.withdraw.close
基于属性的划分根据类操作使用的属性来划分类操作,
例,银行系统的 account(帐户 )类可根据 balance属性来定义划分,把操作划分为三个类别,
使用 balance的操作
修改 balance的操作
不使用也不修改 balance的操作为上述每个类别设计测试序列基于功能的划分根据类操作所完成的功能来划分类操作,
例,银行系统的 account(帐户 )类中的操作可划分为三个类别,
初始化操作 (open,setup)
计算操作 (deposit,withdraw)
查询操作 (balance,summarize,creditLimit)
终止操作 (close)
为上述每个类别设计测试序列测试类和方法
（ 3） 基于故障的测试 (fault_based testing)
与测试传统软件时采用的错误推测法类似,
6.6.5 面向对象的集成测试
(类间测试用例的设计 )
在 OO系统的集成开始时,开始 类间的协作测试,
和单个类的测试一样,类协作测试可通过随机和划分方法以及基于场景的测试和行为测试来完成,
ATM Bank
银行系统的类协作图
ATM
User
Interface
AccountCashier
verifyAcct
verifyPIN
verifyPolicy
withdrawReq
depositReq
acctInfoReq
cardInserted
password
deposit
withdraw
accentStatus
terminate validPINvalidAcct
creditLimit
accentType
balance
withdraw
deposit
close
openAcct
initialDeposit
authorize
Card
deuthorize
closeAcct
Validation
Info
verifyStatus
depositStatus
dispense
Case
printAccent
Stat
readCardInfo
getCaseAmnt
OO集成测试方法
（ 1）多个类 测试
Kirani,S.and W.T.Tsai,在,Specification and Verification
of Object-Oriented Programs” 中建议了下面的步骤序列以生成多个类随机测试用例,
1.对每个客户类,使用类操作列表来生成一系列随机测试序列,这些操作发送消息给服务器类 ;
2.对生成的每个消息,确定在服务器对象中的协作者类和对应的操作 ;
3.对服务器对象中的每个操作 (已经被来自客户对象的消息调用 ),确定传递的消息 ;
4.对每个消息,确定下一层被调用的操作,并把这些操作结合进测试序列中,
ATM Bank
银行系统的类协作图
ATM
User
Interface
AccountCashier
verifyAcct
verifyPIN
verifyPolicy
withdrawReq
depositReq
acctInfoReq
cardInserted
password
deposit
withdraw
accentStatus
terminate validPINvalidAcct
creditLimit
accentType
balance
withdraw
deposit
close
openAcct
initialDeposit
authorize
Card
deuthorize
closeAcct
Validation
Info
verifyStatus
depositStatus
dispense
Case
printAccent
Stat
readCardInfo
getCaseAmnt
银行系统中 Bank类和 ATM类的操作序列,verifyAcct? verifyPIN? [[verifyPolicy?
withdrawReq] | depositReq | acctInfoReq]n
对 Bank类的随机测试用例可能是,
测试用例 r3,verifyAcct? verifyPIN? depositReq
为了考虑测试中涉及的协作者,需要考虑与测试用例 r3中每个操作相关联的消息,
Bank必须和 ValidationInfo协作以执行 verifyAcct和 verifyPIN
Bank还必须和 Account协作以执行 depositReq
因此,测试这些协作的新的测试用例是,
测试用例 r4:verifyAcctBank? [validAcctValidationInfo]?
verifyPINBank? [validPINValidationInfo]? depositReq?
[depositAccount]
OO集成测试方法
（ 2）从动态模型导出 测试用例设计的测试用例应达到完全的状态覆盖,即操作序列应导致 account类的变迁穿越所有允许的状态,
测试用例 s1,open?setupAccent?deposit(initial)?
withdraw(final)?close(最小测试序列 )
向最小序列中加入附加的测试序列,例如,
测试用例 s2:open?setupAccent?deposit(initial)?
deposit?balance?credit? withdraw(final)?close
测试用例 s3:open?setupAccent?deposit(initial)?
deposit?withdraw?accntInfo?withdraw(final)?close
……
导出更多的测试用例以保证该类的所有行为都被适当地测试
set up
acct
account类的状态转换图
empty
acct
dead
acct
setup Aaccent
balance
credit
acctInfo
close
deposit(initial)
deposit
withdraw
empty
acct
open
withdrawal(final)
nonworking
acct
§ 6.7 自动测试和测试工具自动化和工具的好处
速度
效率
准确度和精确度
坚持不懈
6.7.1 测试工具
静态分析工具
动态测试工具
测试数据自动生成工具
集成化测试环境查看器和监视器
1#计算机软件正在测试
2#计算机软件正在测试
3#计算机查看测试工具通信线路监听线路通信分析器可以查看两个系统之间传输的原始数据驱动程序普通系统配置测试驱动配置键盘电缆 鼠标电缆一台计算机可以作为驱动程序测试工具取代被测试系统的键盘和鼠标从外部计算机发送击键鼠标的移动信息,被测试他不被侵入,如果测试软件时在同一系统中执行驱动程序,它就会侵入系统,这种测试情况可能无法接受管道和仿真器普通系统配置 测试存根配置一台计算机可以充当管道,代替打印机,
能够对测试输出进行更有效的分析其它工具类型,
施压工具和增负工具?干扰发生器和噪声发生器?分析工具测试工具产品实例
Junit,Java单元测试工具
Dunit,Delphi的终极测试工具
6.7.2 测试测试自动化另一类软件测试工具,可以自动执行测试用例、查找软件缺陷、分析并记录测试结果。
测试工作台 (下游 CASE工具 )
源代码 预测器测试管理器测试预估模拟器 文件比较器报告生成器动态分析器 被测试的程序测试数据测试结果测试结果报告执行报告测试数据生成器 规约随机测试自动化工具,猴子测试员只要不停电,偶尔能够得到香蕉,猴子就会永远测试下去一个想法,
,如果让一百万只猴子在一百万只键盘上敲一百万年,
它们最终就可能写出莎士比亚话剧等巨著,,
猴子的进步笨猴子,一点也不懂测试软件,只是随机地单击或按键,
直至发生两件事情之一,完成循环或系统崩溃,
不太笨的猴子,具有崩溃辨认能力,
能够重新启动系统开始测试聪明猴子,能够从它的笨兄弟那里获得随机测试的结果,
增加了对环境的认知能力,
有目的地敲键盘,
不仅限于查找崩溃缺陷,同时查看数据,检查操作结果,找出与预期结果的差别自动化测试工具实例美国国际软件自动化（ ISA）公司 的 Panorama for
C/C++,j,Java和 VB产品，自动化功能包括：?
软件结构分析与逻辑框图的自动化?
软件静态分析?
数据分析?
复杂性分析与分析结果列表的自动化?
软件质量分析?
动态性能分析?
软件代码分支或条件覆盖率分析?
软件测试用例有效性分析与测试用例最小集的自动选取?
软件界面手工操作过程的自动记录与自动再执行
(Playback)
§ 6.8 测试中的可靠性分析开发过程中，利用测试的统计数据来估算软件的可靠性，以控制软件的质量。
推测错误的产生频度
推测残留在程序中的错误数
评价测试的精确度和覆盖率推测错误的产生频度
（推测错误产生的时间间隔）
1
K(ET/IT- Ec(t)/IT)
方法,估算平均故障时间 (MTTF估算公式 )
当故障率为独立于时间的常量 λ,
MTTF＝
K,经验常数
ET,程序中原有的残留错误数
IT,程序长度
t,测试时间
Ec(t):在 0-t期间内发现的错误总数
λ
1 =
推测残留在程序中的错误数错误植入模型
Mills将 播种模型 用于程序中残留错误的估算,称 错误植入模型播种模型：
N,程序中原有残留的错误数
Nt：新植入的错误数
n,测试发现的原有错误数
nt,测试发现的植入错误数
N
N
n
n
t ≈ t
NN nn t=
t
Hyman对错误植入模型的改进
ET,程序中原有的残留错误数
E1,1号测试员在某一时间内发现的错误数
E2,2号测试员在同一时间内发现的错误数
E0,两位测试员共同发现的错误数
E
E
E
E
1 ≈ 0 =
2T E
T E1 E 2 /E0
§ 6.1 基本概念软件开发过程必须伴有质量保证活动。
软件测试是软件质量保证的关键元素，代表了规约、设计和编码的最终检查。
6.1.4 测试用例设计选择测试用例是软件测试员最重要的一项工作。
测试用例的属性,
属性 描述
name 测试用例的名称
location 可执行的完全路径名
input 输入数据或命令
oracle 与测试输入相比较的期待测试结果
log 测试生产的输出
6.1.5 软件测试信息流软件配置测试测试配置测试工具结果分析排错可靠性分析测试结果错误预期结果出错率改正的软件预测的可靠性需求规格说明书软件设计说明书被测源程序测试计划测试用例
(测试数据 )
测试驱动程序测试活动和相关工作产品项目协议对象设计 客户开发人员 用户集成策略系统分解功能性需求非功能性需求单元测试集成测试结构测试功能测试性能测试来自 ODD
来自 TP
来自 SDD
来自 RAD
来自 RAD
用户手册验收测试安装测试现场测试日常操作测试设计中需要考虑的 22种测试类型
黑盒测试
白盒测试
单元测试
累计综合测试
集成测试
功能测试
系统测试
端到端测试
健全测试
衰竭测试
接受测试
负载测试
强迫测试
性能测试
可用性测试
安装 /卸载测试
恢复测试
兼容测试
安全测试
比较测试
Alpha测试
Beta测试
6.1.6 测试的方法与技术软件测试的策略和方法静态测试方法动态测试方法人工测试方法计算机辅助静态分析方法白盒测试方法黑盒测试方法动态测试方法
(1)选取定义域有效值,或定义域外无效值,
(2)对已选取值决定 预期的结果
(3)用选取值执行程序
(4)执行结果 与 (2)结果相比,
不吻和程序有错,
动态黑盒测试 —闭着眼睛测试软件软件输入不深入代码细节的测试方法称为动态黑盒测试。
软件测试员充当客户来使用它。
输出动态白盒测试 —带上 X光眼镜测试软件
3581322.293419985680302829734315
250*(1+0.015)*((1+0.015)^360-1)/0.015 250*(1+0.015)*((1+0.015)^360-1)/0.015
假如知道一个盒子包含一台计算机,而另一个盒子是人用纸笔计算,就会选择不同的测试用例了解软件的运作方式会影响测试手段
§ 6.2 两种类型的测试
6.2.1 黑盒测试又称,功能测试数据驱动测试基于规格说明书的测试
6.2.2 白盒测试又称,开盒测试结构测试玻璃盒测试基于覆盖的测试,
根据被测程序的逻辑结构设计测试用例 ;
力求提高测试覆盖率 ;
黑盒测试与白盒测试比较黑盒测试 是从用户观点，按规格说明书要求的输入数据与输出数据的对应关系设计测试用例,
是根据程序 外部特征 进行测试。
白盒测试 是根据程序 内部逻辑结构 进行测试。
黑盒测试与白盒测试优缺点比较黑盒测试 白盒测试优点缺点性质
① 适用于各阶段测试
②从产品功能角度测试
③容易入手生成测试数据
① 可构成测试数据使特定程序部分得到测试
②有一定的充分性度量手段
③可或较多工具支持
① 某些代码得不到测试
②如果规格说明有误，
则无法发现
③不易进行充分性测试
① 不易生成测试数据 (通常 )
② 无法对未实现规格说明的部分进行测试
③工作量大，通常只用于单元测试，有应用局限是一种 确认 技术，回答
,我们在构造一个正确的系统吗？,
是一种 验证 技术，回答
,我们在正确 地构造一个系统吗？,
不论黑盒还是白盒测试都 不能进行穷尽测试,所以软件测试不可能发现程序中存在的所有错误,因此需精心设计测试方案,力争尽可能少的次数,测出尽可能多的错误,
黑盒测试与白盒测试能发现的错误
C BA
D
-只能用黑盒测试发现的错误A
-只能用白盒测试发现的错误
-两种方法都能发现的错误
-两种方法都不能发现的错误
BC
D
§ 6.3白盒测试的测试用例设计
6.3.1 逻辑覆盖法
(1)语句覆盖
(2)判定覆盖
(3)条件覆盖
(4)判定 /条件覆盖
(5)条件组合覆盖
(6)路径覆盖
(7)点覆盖
(8)边覆盖例,PROCEDURE SAMPAL
(A,B,REAL； VAR 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)
(A=2) OR (X>1)
返回
X=X/A
X=X+1
F
F
T
T
a
b
d
c
e
(1)语句覆盖使程序中每个语句至少执行一次语句覆盖 开始
(A>1) AND (B=0)
(A=2) OR (X>1)
返回
X=X/A
X=X+1
F
F
T
T
a
b
d
c
e
只需设计一个测试用例,
输入数据,A=2,B=0,X=4
即达到了语句覆盖 ;
语句覆盖是 最弱 的逻辑覆盖
(2)判定覆盖 (分支覆盖 )
使每个判定的真假分支都至少执行一次判定覆盖 开始
(A>1) AND (B=0)
(A=2) OR (X>1)
返回
X=X/A
X=X+1
F
F
T
T
a
b
d
c
e
例,可设计两组测试用例,
A=3,B=0,X=3 可覆盖 c,d分支
A=2,B=1,X=1 可覆盖 b,e分支两组测试用例可覆盖所有判定的真假分支语句覆盖仍是 弱 的逻辑覆盖
(3)条件覆盖使每个判定的每个条件的可能取值至少执行一次第一判定表达式,
设 条件 A>1 取真 记为 T1
假 T1
条件 B=1 取真 记为 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+1
F
F
T
T
a
b
d
c
e
满足条件,T1,T1,
T2,T2
T3,T3
T4,T4
测试用例 通过 满足的 覆盖
A B X 路径 条件 分支
1 0 3 abe T1,T2,T3,T4 b,e
2 1 1 abe T1,T2,T3,T4 b,e
两个测试用例 覆盖了四个条件八种可能取值 。
未覆盖 c,d分支,不满足判定覆盖的要求,
条件覆盖不一定包含判定覆盖判定覆盖也不一定包含条件覆盖
(4)判定 /条件覆盖选取足够多的测试用例,使判断中的每个条件的所有可能取值至少执行一次,同时每个判断本身的所有可能判断结果至少执行一次,
判定 /条件覆盖 开始
(A>1) AND (B=0)
(A=2) OR (X>1)
返回
X=X/A
X=X+1
F
F
T
T
a
b
d
c
e
满足条件,T1,T1,
T2,T2
T3,T3
T4,T4
测试用例 通过 满足的 覆盖
A B X 路径 条件 分支
2 0 4 ace T1,T2,T3,T4 c,e
2 1 1 abd T1,T2,T3,T4 b,d
能同时满足判定、条件两种覆盖标准。
取值。
测试用例 通过 满足的 覆盖
A B X 路径 条件 分支
2 0 3 ace T1,T2,T3,T4 c,e
2 1 1 abe T1,T2,T3,T4 b,e
1 0 3 abe T1,T2,T3,T4 b,e
1 1 1 abd T1,T2,T3,T4 b,d
(5)条件组合覆盖所有可能的条件取值组合至少执行一次
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
测试用例 通过 满足的 覆盖
A B X 路径 条件 分支
2 0 4 ace T1,T2,T3,T4 c,e
2 1 1 abe T1,T2,T3,T4 b,e
1 0 2 abd T1,T2,T3,T4 b,d
1 1 1 abd T1,T2,T3,T4 b,d
(6)路径覆盖覆盖每一个可能的路径测试用例 通过 满足的 覆盖
A B X 路径 条件 分支
1 1 1 abd T1,T2,T3,T4 b,d
1 1 2 abe T1,T2,T3,T4 b,e
3 0 1 acd T1,T2,T3,T4 c,d
2 0 4 ace T1,T2,T3,T4 c,e
基本路径测试法通过分析由控制构造的环路的复杂性，导出基本路径集合，从而设计测试用例，保证这些路径至少通过一次。
基本路径测试步骤：
导出程序流程图的拓扑结构 -流图
(程序图 )
计算流图 G的环路复杂度 V(G)
确定只包含独立路径的基本路径集
设计测试用例
导出程序流程图的拓扑结构 -流图
1
2,3
6 4,5
7
10
6
11
a
节点边 R4
区域
1
2
3
4
5
87
3
9
11
程序流程图
8
9
R1
R2R3
计算流图 G的环路复杂度 V(G)
V(G)= 区域个数 =4
V(G)=边的条数 -节点个数 +2=4
V(G)=判定节点个数 +1=4
确定只包含独立路径的基本路径集
path1:1-11
path1:1-2-3-4-5-10-1-11
path1:1-2-3-6-8-9-10-1-11
path1:1-2-3-6-7-9-10-1-11
一条新路径必须包含一条新边。
这 4条路径组成了一个基本路径集。 4(环路复杂度 V(G))是构成这个基本路径集的独立路径数的上界，也是设计 测试用例的数目。
设计测试用例，保证基本路径集中每条路径的执行。
§ 6.4黑盒测试的测试用例设计
6.4.1 等价类划分法把所有可能的输入数据 (有效的和无效的 )划分成若干个等价的子集
(称为等价类 ),使得每个子集中的一个典型值在测试中的作用与这一子集中所有其它值的作用相同,
可从每个子集中选取一组数据来测试程序例,某报表处理系统要求用户输入处理报表的日期，日期限制在 2001年 1
月至 2005年 12月，即系统只能对该段期间内的报表进行处理，如日期不在此范围内，则显示输入错误信息。
系统日期规定由年、月的 6位数字字符组成，前四位代表年，后两位代表月。
如何用等价类划分法设计测试用例,
来测试程序的日期检查功能？
如何划分等价类？
有效等价类 (合理等价类 )
无效等价类 (不合理等价类 )
划分等价类的标准：
覆盖
不相交
代表性划分等价类的规则
(1)如果输入条件规定了取值范围，
可定义一个有效等价类和两个无效等价类。
例 输入值是学生成绩，范围是 0～ 100
0 100
有效等价类
1≤ 成绩 ≤ 100
无效等价类成绩 >100
无效等价类成绩 <0
～
划分等价类的规则：
(2)如果输入条件代表集合的某个元素，则可定义一个有效等价类和一个无效等价类。
划分等价类的规则：
(3)如规定了输入数据的一组值,且程序对不同输入值做不同处理,
则每个允许的输入值是一个有效等价类,并有一个无效等价类
(所有不允许的输入值的集合 )。
例：输入条件说明学历可为,专科,本科,
硕士,博士 四种之一,则分别取这四种这四个值作为 四个有效等价类,另外把四种学历之外的任何学历作为无效等价类划分等价类的规则：
(4)如果规定了输入数据必须遵循的规则,可确定一个有效等价类 （ 符合规则 ） 和若干个无效等价类 （ 从不同角度违反规则 )。
(5)如已划分的等价类各元素在程序中的处理方式不同,则应将此等价类进一步划分成更小的等价类 。
用等价类划分法设计测试用例步骤：
(1)形成等价类表,每一等价类规定一个唯一的编号；
(2)设计一测试用例,使其尽可能多地覆盖尚未覆盖的有效等价类,
重复这一步骤,直到所有有效等价类均被测试用例所覆盖；
(3)设计一新测试用例,使其只覆盖一个无效等价类,重复这一步骤直到所有无效等价类均被覆盖；
第一步：等价类划分输入等价类 有效等价类 无效等价类报表日期的类型及长度 3位数字字符 (1)
有非数字字符 (4)
少于 6个数字字符 (5)
多于 6个数字字符 (6)
年份范围 在 2001～ 2005之间 (2) 小于 2001 (7)大于 2005 (8)
月份范围 在 1～ 12之间 (3)
“报表日期,输入条件的等价类表小于 1 (9)
大于 12 (10)
第二步,为有效等价类设计测试用例对表中编号为 1,2,3的 3个有效等价类用一个测试用例覆盖：
测试数据 期望结果 覆盖范围
200105 等价类 (1)(2)(3)输入有效第三步：为每一个无效等价类设至少计一个测试用例测试数据 期望结果 覆盖范围
001MAY 等价类 (4)输入无效
20015 等价类 (5)输入无效
2001005 等价类 (6)输入无效
200005 等价类 (7)输入无效
200805 等价类 (8)输入无效
200100 等价类 (9)输入无效
200113 等价类 (10)输入无效不能出现相同的测试用例本例的 10个等价类至少需要 8个测试用例例,对招干考试系统“输入学生成绩”
子模块设计测试用例招干考试分三个专业,准考证号第一位为专业代号,如,1-行政专业,
2-法律专业,
3-财经专业,
行政专业准考证号码为,110001～ 111215
法律专业准考证号码为,210001～ 212006
财经专业准考证号码为,310001～ 314015
例,准考证号码的等价类划分有效等价类,
(1) 110001 ～ 111215
(2) 210001 ～ 212006
(3) 310001 ～ 314015
无效等价类,
(4) -? ～ 110000
(5) 111216 ～ 210000
(6) 212007 ～ 31000
(7) 314016 ～ +?
例,计算给定月份中天数的方法接口
(java):
Class MyGregorianCalender{
……
public static in getNumDaysInMonth(int
month,int year){…}
……
}
getNumDaysInMonth( )方法有两个参数,月和年,年份的有效输入是从 0到 maxInt.
等价类划分 即把 输入空间分解成一系列子域,软件在一个子域内的行为应是等价的 。
软件错误分为两类,计算错误域错误
针对 计算错误的测试方法
针对 域错误 的测试方法,测试 域边界划定的正确性
6.4.2 边界值分析法边界值分析法与等价类划分法区别
(1)边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
(2)边界值分析不仅考虑输入条件，
还要考虑输出空间产生的测试情况被测试子 域测试内点测试外点软件边界与悬崖很类似边界条件类型如果软件测试问题包含确定的边界,那么数据类型可能是,
数值
字符
位置
数量
速度
地址
尺寸
……
还要考虑数据类型的特征,
第一个 /最后一个
最小值 /最大值
开始 /完成
空 /满
最慢 /最快
相邻 /最远
超过 /在内
……
测试边界线
测试临近边界的合法数据,以及刚超过边界的非法数据,
越界测试通常简单地加 1或很小的数
(对于最大值 )和减 1或很小的数 (对于最小值 ).
输入条件报表日期的类型及长度
1个数字字符
5个数字字符
7个数字字符有 1个非数字字符全部是非数字字符
6个数字字符显示出错显示出错显示出错显示出错显示出错输入有效日期范围月份范围
“报表日期,边界值分析法测试用 例测试用例说明 测试数据 期望结果 选取理由
5
20015
2001005
2001.5
MAY---
200105
月份为 1月月份为 12月月份 <1
月份 >12
200101
200112
200100
200113
200101
200512
200100
200513
输入有效输入有效显示出错显示出错输入有效输入有效显示出错显示出错在有效范围边界上选取数据仅有 1个合法字符比有效长度少 1
比有效长度多 1
只有 1个非法字符
6个非法字符类型及长度均有效最小日期最大日期刚好小于最小日期刚好大于最大日期最小月份最大月份刚好小于最小月份刚好大于最大月份
6.4.3 错误推测法 (error guessing)
根据经验来设计测试用例的方法例如，数据测试中的,
缺省值
空白
空值
零值
无
6.4.4 状态测试软件必须测试程序的状态及其转换。
测试软件的逻辑流程
建立状态转换图
减少要测试的状态及转换的数量空闲等待用户输入命令按下 Esc键显示口令框口令错误消除口令正确初始状态消失空闲等待用户输入命令按下 Esc键 口令正确口令错误不同形式的状态转换图设置 2Bwatch 上的时间的顺序图
:2Bwatch用户按下按钮 1和 2
:2Bwatch输入,2Bwatch显示,2Bwatch时间时间按下按钮 1
按下按钮 2
按下按钮 1和 2
闪烁小时闪烁分钟增加分钟刷新提交更新时间停止闪烁
2Bwatch 设置时间功能的状态图和测试结果按左按钮按右按钮按左按钮按右按钮
4,2分钟以后测量时间 设置时间电池没电
3.按下左右按钮
5.按下左右按钮 /蜂鸣
8,20年以后7,20年以后
6.2,1.
激励因素空集合 测量时间1.初始变迁测试的变迁 预期结果状态按下左边按钮 测量时间2.
同时按下两个按钮 设置时间3.
等 2分钟 测量时间4.超时
…… …………
失败状态测试找到测试软件失败的案例 。
竞争条件和时序错乱
重复
压迫
重负应联合使用，同时进行有效等价类和用来测试 getNumDaysInMonth()
方法所选的有效输入有效 等价类一个月有 31天,非闰年 19017(七月 )
一个月有 31天,闰年 19047(七月 )
一个月有 30天,非闰年 19016(六月 )
一个月有 30天,闰年 19046(六月 )
一个月为 28或 29天,非闰年 19012(二月 )
月份输入值年份输入值一个月为 28或 29天,闰年 2(二月 ) 1904
用来测试 getNumDaysInMonth()方法的附加边界值等价类可以被 400整除的闰年 20002(二月 )
可以被 100整除的非闰年 19002(二月 )
非正数无效月份 12910
正数无效月份 131513
月份输入值年份输入值
6.4.5 因果图法因果图适合于描述对于多种输入条件的组合，相应产生多个动作的形式来设计测试用例。
因果图方法最终生成的是判定表。
因果图方法实例某电力公司有 A,B,C,D四类收费标准,
并规定：
居民用电 <100度 /月 按 A类收费
≥ 100度 /月按 B类收费动力用电 <10000度 /月,非高峰,B类收费
≥ 10000度 /月,非高峰,C类收费
<10000度 /月,高峰,C类收费
≥ 10000度 /月,高峰,D类收费用因果图表明输入和输出间的逻辑关系
1 I1
2 B∨
∧
4
A
C3
5
∧
D
I4
I3I2 ∨∧
∧
∧
∧
把因果图转换为判定表组合条件条件
(原因 )
动作
(结果 )
A
B
C
1
2
3
1 2 3 4 5 6
1
0
1
1
0
0
0
1 1
0 0 0
1 1
0 0 0 0
1 0 0 0
0 1 1 0
4 1 0 1 0
5 0 0 1 1
D 0 0 0 1
1 0
0 1
0 0
0 0
测试用例为判定表每一列设计一个测试用例,
1列 居民电,90度 /月 A
2列 居民电,110度 /月 B
3列 动力电,非高峰,8000度 /月 B
4列 动力电,非高峰,1.2万度 /月 C
5列 动力电,高峰,0.9万度 /月 C
6列 动力电,高峰,1.1万度 /月 D
条件 测试用例 预期结果组合 (输入数据 ) (输出动作 )
§ 6.5 针对专门环境和应用的测试
6.5.1 GUI测试常见 GUI测试指南：?
对于窗口?
对于菜单和鼠标操作?
对于数据项
6.5.2 C/S体系结构的 测试整体 C/S测试策略 (三个不同层次 )
客户端应以,分离的,模式被测试
(不考虑服务器和底层网络的运行 )
客户端软件和关联的服务器端应用被一起测试 (网络运行不被明显考虑 )
完整的 C/S体系结构 (包括网络运行和性能 )
被测试
C/S常用测试方法
客户端应用功能测试
服务器测试 （ 协调和数据管理功能,
性能 ）
数据库测试
事务测试
网络通信测试
6.5.3 实时系统测试可采用以下四步策略：
(1) 任务测试
(2) 行为测试
(3) 任务间测试
(4) 系统测试
(1) 任务测试 (task testing)
对每一个任务进行单独测试
(白盒、黑盒测试 )，发现 逻辑和功能上错误,不能发现定时上和行为上错误 。
(2)行为 测试 (behavioral testing)
用 CASE工具创建应用系统模型，
模拟实时系统行为。
按类测试各种事件 (如中断、控制信号、数据 )。
测试过的事件以随机次序、随机频率送给系统,检查软件 行为方面的错误,
(3)任务间测试 (intertask testing)
检查 与时间有关错误 。
如用不同数据速率、处理负载测试相互通信的异步任务。
通过消息队列或数据存储测试任务间的通信来找出数据存储区错误的范围。
(4) 系统测试 (system testing)
软件、硬件组装后，找出 软、
硬件接口错误 。
软件测试的过程被测模块 单元测试设计信息集成测试被测模块 单元测试被测模块 单元测试测试过的模块确认测试系统测试软件需求其它系统元素装配好的软件确认的软件可运行的软件
§ 6.6软件测试的步骤软件测试策略单元测试U
C
D
R
S
I
V
ST
集成测试确认测试系统测试系统工程软件需求分析软件设计代码编写
6.6.1 单元测试一,单元测试的内容主要对模块的 五个基本特性 进行评价模块错误处理模块接口局部数据结构重要的执行路径 边界条件
1.常见错误类型
接口错误
I/O错误
数据结构错误
算法错误
比较及控制逻辑错误
错误处理错误
2,模块测试基本原则
至少一次测试所有语句
测试所有可能的执行或逻辑路径的组合
测试每个模块的所有入口和出口
3,确定单元测试数据集
值域
值类
离散值
值的次序集 (测试顺序文件和 表 )
二,单元测试的方法单元测试一般为编码步骤的附属部分,
模块不是独立的程序,自己不能运行,
要靠其它部分来调用和驱动,要为每个单元测试开发两个软件,
(1)驱动模块 (驱动程序 ):相当于主模块
(2)桩模块 (测试存根、连接程序 ),
代替所测模块调用的子模块单元测试的测试环境举例,
B
A
CD
E待测试模块单元测试的测试环境举例,
被测模块 B
驱动模块
(模拟模块 A)
桩模块 (测试存根 )
(模拟模块 E)
测试用例 测试结果许多模块不能用简单的软件进行充分的单元测试,此时,完全的测试可放到集成测试阶段再进行,
单元测试的测试环境举例,
实际软件华氏到慑氏转换模块温度数据实际配置测试用例数据结果测试驱动软件华氏到慑氏转换模块结果测试驱动际配置单元测试的测试环境举例温度显示模块温度接口模块实际配置 测试驱动际配置温度显示模块程序员编写的桩模块
(测试存根 )
温度值的测试文件结构性模式 (structural patterns)
适配器模式 (Adapter)—打包器 (Wrapper)
桥模式 (Bridge)—句柄 (Handle)
组合模式 (Composite)
修饰模式 (Decorator)—包装器 (Wrapper)
外观模式 (Facade)
轻量模式 (Flyweight)
代理模式 —(Proxy)
6.6.2 集成测试 (组装测试 )
集成测试需考虑的问题,
数据穿越接口可能丢失,
一模块可能破坏另一模块功能,
子功能组装可能未产生所要求的主功能,
全程数据结构可能出问题,
误差累积问题,
集成测试方法通常采用黑盒测试技术实施策略,
非渐增式测试
渐增式测试深度优先广度优先自顶向下结合自底向上结合一,非渐增式集成方式一次就把所有通过了单元测试的模块组合在一起进行全程序的测试,
缺点,发现错误难以诊断定位,
又称,莽撞测试,,
二,渐增式集成方式从一个模块开始,测一次添加一个模块,边组装边测试,以发现与接口相联系的问题 。
自顶向下结合方式举例,
A
DB
E
模块测试结合顺序
C
F
深度优先,A,B,E,C,D,F
广度优先,A,B,C,D,E,F
自顶向下结合方式举例,(深度优先 )
A
测试 A
S2S1 S3
A
加入 B
S2B S3
S4
A
加入 E
S2B S3
E
A
加入 C
CB S3
E
加入 D
CB D
E
加入 F
CB D
E
A A
FS5
自底向上结合方式举例,
A
CB D
FE
E
d1
C
d3
F
d4
B
d2
E
D
d5
F
自底向上结合方式举例,
Mc
D1
Ma Mb
D2 D3
簇 1
簇 2
簇 3
自顶向下 自底向上优点 可在测试早期 设计测试用例容易实现并验证系统主要功能不需驱动模块 不需桩模块缺点 需桩模块 只有到最后程序才能作为一个整体
3,混合集成测试方法
一般对软件结构的上层使用自顶向下结合的方法 ;
对下层使用自底向上结合的方法 ;
6.6.3 确认测试 (有效性测试 )
有效性测试软件配置审查管理机构裁决选择测试人员软件计划用户文档开发文档源程序文本支持环境交用户运行维护测试报告软件配置构造测试用例
(验收测试 )
实际运行测试 专家鉴定会一,有效性测试通过 黑盒测试,证实软件功能与用户需求是否一致,
二,软件配置审查与验收确认测试软件配置审查主管部门批准集成的软件软件需求用户文档设计文档源程序测试文档交付的软 件确认的软 件确认的配 置三,人工测试静态分析对源程序进行静态分析的方法：
生成各类引用表
静态错误分析
类型和单位分析
引用分析
表达式分析
接口分析对源程序进行静态分析的方法：
(1)桌前检查
检查变量、标号的交叉引用
检查子程序、宏、函数、
常量检查
标准、风格检查
(2)代码会审
(3)走查四,确认测试结果测试完成后可能出现两种情况,
(1)测试与预期相符,可接受,
(2)不相符,列出软件缺陷表,与用户协商解决,
五,α 测试和 β 测试
α 测试 (Alpha)
在开发者的场所由用户进行,在开发着关注和控制的环境下进行,
β 测试 (Beta)
最终用户在自己的场所进行,
6.6.4 系统测试软件只是计算机系统的一个元素，软件最终要与其他系统元素（如新硬件、信息等 )相结合，
进行各种集成测试和确认测试,
用于系统测试的测试类型,
(1)恢复测试
(2)安全性测试
(3)强度测试
(4)性能测试推测残留在程序中的错误数错误植入模型
Mills将 播种模型 用于程序中残留错误的估算,称 错误植入模型播种模型：
N,程序中原有残留的错误数
Nt：新植入的错误数
n,测试发现的原有错误数
nt,测试发现的植入错误数
N
N
n
n
t ≈ t
NN nn t=
t
Hyman对错误植入模型的改进
ET,程序中原有的残留错误数
E1,1号测试员在某一时间内发现的错误数
E2,2号测试员在同一时间内发现的错误数
E0,两位测试员共同发现的错误数
E
E
E
E
1 ≈ 0 =
2T E
T E1 E 2 /E0
(1)恢复测试以不同的方式强使软件出现故障,检测软件能否恰当地完成恢复,
自动恢复,检测重新初始化、
检测点设置、
数据恢复、
重新启动等是否正确,
人工干预恢复,检测平均恢复时间是否在允许范围内,
(2)安全性测试设计测试用例,突破软件安全保护机构的安全保密措施,检验系统预防机制的漏洞,
(3)强度测试设计测试用例,检验系统能力最高能达到的实际限度,让系统处于资源的异常数量、异常频率、异常批量的条件下测试系统的承受能力,
一般比平常限度高 5-10倍的限度做测试用例,
§ 6.6 面向对象的软件测试测试 目标,在现实的时间跨度内应用可管理的工作量去发现最大可能数量的错误?
基本目标不变，但由于 OO程序的性质改变了 测试策略和测试战术
更多的设计模式复用是否将减轻 OO系统的繁重 测试？
Binder,R.V.在,Object-Oriented Software Testing”中讨论改问题,
“每次复用是一个新的使用语境,并且重新测试是谨慎的,为了获得面向对象系统的高可靠性,似乎可能需要更多而不是更少的测试,”
强度测试 是一种敏感性测试技术,某种情况下,一包含在程序有效数据边界内的非常小范围的数据变动可能导致 极端的,甚至错误的处理,或使系统性能严重下降,
敏感性测试用来发现可能导致不稳定或不正确处理的有效输入类中的数据组合,
(4)性能测试设计测试用例，并记录软件运行性能，与性能要求比较，检验是否达到性能要求规格。
6.6.5 测试的步骤及相应的测试种类
§ 6.6 面向对象的软件测试测试 目标,在现实的时间跨度内应用可管理的工作量去发现最大可能数量的错误?
基本目标不变，但由于 OO程序的性质改变了 测试策略和测试战术
更多的设计模式复用是否将减轻 OO系统的繁重 测试？
Binder,R.V.在,Object-Oriented Software Testing”中讨论改问题,
“每次复用是一个新的使用语境,并且重新测试是谨慎的,为了获得面向对象系统的高可靠性,似乎可能需要更多而不是更少的测试,”
6.6.1 OOA和 OOD的 模型 测试每个阶段的所有面向对象模型都应被测试。
OOA和 OOD的模型不能被执行，对它们不能进行传统意义上的测试。
可通过技术复审检查 OOA和 OOD的模型的正确性和一致性。
扩大测试的视角
6.6.2 面向对象测试策略
信息隐蔽对测试的影响?
封装和继承对测试的影响面向对象程序的特点对软件测试的影响：
单元和集成测试策略必须有很大的改变
测试用例的设计必须考虑 OO软件的特征
1,OO的单元测试
一个类可以包含一组不同的操作，而一个特定的操作也可能存在于一组不同的类中。 不再孤立地测试单个操作 (这是传统单元测试的视角 )
OO软件的 类测试 等价于 传统的单元测试,
传统软件的单元测试关注算法细节和模块接口间流动的数据
OO软件的类测试是由封装在类中的操作和类的状态行为驱动的单元概念 的变化 —封装的类或对象作为最小的可测试单位
2,OO的集成测试
OO软件没有层次的控制结构,传统的自顶向下和自底向上的集成策略没有意义,
OO软件的集成两种策略,?
基于线程的测试 (thread-based testing)
集成响应系统的一个输入或事件所需的一组类,每个线程被个体地集成和测试,通过回归测试保证没有副作用产生 ;
基于使用的测试 (use-based testing)
通过测试几乎不使用服务器的类 (独立类 )来开始系统的构造,测试完独立类后,使用独立类按层逐步完成依赖类的测试直至完整的系统被构造 ;
3,OO的确认测试在确认和系统测试层次,类连接的细节消失,
和传统的确认测试一样,OO软件的确认关注用户可见的动作和用户可识别的系统输出,
为辅助确认测试的导出,应利用分析模型中的用例图提供的场景来提高交互需求中发现错误的可能性
6.6.3 OO软件的测试用例设计
每个测试用例应被唯一标识，并应显式地和与被测试类相关联?
测试的目的应被陈述?
对每个测试应开发一组测试步骤，包括：
将被测试对象的一组 特定状态
将被作为测试的结果使用的一组 消息和操作
当对象被测试时可能产生的一组异常
一组外部条件 (进行测试必须的软件外部环境的变化 )
将辅助理解或实现测试的补充信息
OO软件的测试用例设计还处于成型期,
Binder,R.V.在,Essays on Object-Oriented Software
Engineering”
中建议了对 OO软件的测试用例设计的整体方法,
1,OO概念的测试用例设计的含义
封装可能会成为测试的障碍测试需要报告对象的具体和抽象状态，而封装使得对象的状态快照难于获得。
继承，特别是多继承使测试复杂化子类继承或重载的父类成员函数的测试问题
继承的成员函数是否都不需要测试?
对父类中已经测试过的成员函数,两种情况需要在子类中重新测试,
继承的成员函数在子类中做了改动 ;
成员函数调用了改动过的成员函数的部分 ;
例如,
父类 Base有两个成员函数 Inherited()和 Redefined(),
子类 Derived只对 Redefined() 做了改动,
Derived ∷ Redefined() — 需要重新测试
Derived ∷ Inherited() — 如果它调用了 Redefined() 的语句,则需重新测试,否则不必子类继承或重载的父类成员函数的测试问题
对父类的测试是否能够照搬到子类?
上例中,Base∷ Redefined() 和 Derived ∷ Redefined() 已是 两个不同的成员函数,照理应对 Derived ∷ Redefined()
重新进行测试分析,设计测试用例,但由于它们的 相似性,只需在 Base∷ Redefined() 的测试要求和测试用例上添加对
Derived ∷ Redefined() 的新的测试要求和 增补相应的测试用例,
2,传统 测试用例设计方法的可用性
白盒测试方法可用于类定义的操作的测试
对具有简洁结构的类，白盒测试最好用于类级别的测试
黑盒测试方法也适合 OO系统
6.6.4 测试单个类的方法
（ 1） 随机测试例,银行系统的 account(帐户 )类有下列操作：
open(打开 )
setup(建立 )
deposit(存款 )
withdraw(取款 )
balance(余额 )
summarize(清单 )
creditLimit(透支限额 )
close(关闭 )
系统对 操作的限制：
必须在应用其它操作之前先打开帐户,在完成了全部操作之后才能关闭帐户 ;?……
在限制下还是存在 操作的许多排列一个 account类实例的最小行为历史包括下列操作,
open,setup,deposit,withdraw,close
account类的最小测试序列大量的其它行为可能在下面序列中发生,
open,setup,deposit,[deposit | withdraw | balance
| summarize | creditLimit] n,withdraw,close
一系列不同的操作序列可以随机地产生,例如,
测试用例 r1,open.setup.deposit.deposit.balance.
summarize.creditLimit.withdraw.close
测试用例 r2,open.setup.deposit.withdraw.deposit.
balance,creditLimit.withdraw.close
这些和其它的随机顺序测试被进行,以测试不同的类实例的生存历史,
测试单个类的方法
（ 2） 划分测试 (partition testing)
与测试传统软件时采用的等价类划分方法类似,
划分类别的方法,
基于状态的划分
基于属性的划分
基于功能的划分基于状态的划分根据类操作改变类状态的能力来划分类操作,
例：银行系统的 account(帐户 )类状态操作包括,deposit(存款 )
withdraw(取款 )
非状态操作包括,balance(余额 )
summarize(清单 )
creditLimit(透支限额 )
测试用例 p1(测试改变状态的操作 ),
open.setup.deposit.deposit..withdraw.close
测试用例 p2 (测试不改变状态的操作,在最小测试序列中的操作除外 ),
open.setup.deposit.summarize,creditLimit.withdraw.close
基于属性的划分根据类操作使用的属性来划分类操作,
例,银行系统的 account(帐户 )类可根据 balance属性来定义划分,把操作划分为三个类别,
使用 balance的操作
修改 balance的操作
不使用也不修改 balance的操作为上述每个类别设计测试序列基于功能的划分根据类操作所完成的功能来划分类操作,
例,银行系统的 account(帐户 )类中的操作可划分为三个类别,
初始化操作 (open,setup)
计算操作 (deposit,withdraw)
查询操作 (balance,summarize,creditLimit)
终止操作 (close)
为上述每个类别设计测试序列测试类和方法
（ 3） 基于故障的测试 (fault_based testing)
与测试传统软件时采用的错误推测法类似,
6.6.5 面向对象的集成测试
(类间测试用例的设计 )
在 OO系统的集成开始时,开始 类间的协作测试,
和单个类的测试一样,类协作测试可通过随机和划分方法以及基于场景的测试和行为测试来完成,
ATM Bank
银行系统的类协作图
ATM
User
Interface
AccountCashier
verifyAcct
verifyPIN
verifyPolicy
withdrawReq
depositReq
acctInfoReq
cardInserted
password
deposit
withdraw
accentStatus
terminate validPINvalidAcct
creditLimit
accentType
balance
withdraw
deposit
close
openAcct
initialDeposit
authorize
Card
deuthorize
closeAcct
Validation
Info
verifyStatus
depositStatus
dispense
Case
printAccent
Stat
readCardInfo
getCaseAmnt
OO集成测试方法
（ 1）多个类 测试
Kirani,S.and W.T.Tsai,在,Specification and Verification
of Object-Oriented Programs” 中建议了下面的步骤序列以生成多个类随机测试用例,
1.对每个客户类,使用类操作列表来生成一系列随机测试序列,这些操作发送消息给服务器类 ;
2.对生成的每个消息,确定在服务器对象中的协作者类和对应的操作 ;
3.对服务器对象中的每个操作 (已经被来自客户对象的消息调用 ),确定传递的消息 ;
4.对每个消息,确定下一层被调用的操作,并把这些操作结合进测试序列中,
ATM Bank
银行系统的类协作图
ATM
User
Interface
AccountCashier
verifyAcct
verifyPIN
verifyPolicy
withdrawReq
depositReq
acctInfoReq
cardInserted
password
deposit
withdraw
accentStatus
terminate validPINvalidAcct
creditLimit
accentType
balance
withdraw
deposit
close
openAcct
initialDeposit
authorize
Card
deuthorize
closeAcct
Validation
Info
verifyStatus
depositStatus
dispense
Case
printAccent
Stat
readCardInfo
getCaseAmnt
银行系统中 Bank类和 ATM类的操作序列,verifyAcct? verifyPIN? [[verifyPolicy?
withdrawReq] | depositReq | acctInfoReq]n
对 Bank类的随机测试用例可能是,
测试用例 r3,verifyAcct? verifyPIN? depositReq
为了考虑测试中涉及的协作者,需要考虑与测试用例 r3中每个操作相关联的消息,
Bank必须和 ValidationInfo协作以执行 verifyAcct和 verifyPIN
Bank还必须和 Account协作以执行 depositReq
因此,测试这些协作的新的测试用例是,
测试用例 r4:verifyAcctBank? [validAcctValidationInfo]?
verifyPINBank? [validPINValidationInfo]? depositReq?
[depositAccount]
OO集成测试方法
（ 2）从动态模型导出 测试用例设计的测试用例应达到完全的状态覆盖,即操作序列应导致 account类的变迁穿越所有允许的状态,
测试用例 s1,open?setupAccent?deposit(initial)?
withdraw(final)?close(最小测试序列 )
向最小序列中加入附加的测试序列,例如,
测试用例 s2:open?setupAccent?deposit(initial)?
deposit?balance?credit? withdraw(final)?close
测试用例 s3:open?setupAccent?deposit(initial)?
deposit?withdraw?accntInfo?withdraw(final)?close
……
导出更多的测试用例以保证该类的所有行为都被适当地测试
set up
acct
account类的状态转换图
empty
acct
dead
acct
setup Aaccent
balance
credit
acctInfo
close
deposit(initial)
deposit
withdraw
empty
acct
open
withdrawal(final)
nonworking
acct
§ 6.7 自动测试和测试工具自动化和工具的好处
速度
效率
准确度和精确度
坚持不懈
6.7.1 测试工具
静态分析工具
动态测试工具
测试数据自动生成工具
集成化测试环境查看器和监视器
1#计算机软件正在测试
2#计算机软件正在测试
3#计算机查看测试工具通信线路监听线路通信分析器可以查看两个系统之间传输的原始数据驱动程序普通系统配置测试驱动配置键盘电缆 鼠标电缆一台计算机可以作为驱动程序测试工具取代被测试系统的键盘和鼠标从外部计算机发送击键鼠标的移动信息,被测试他不被侵入,如果测试软件时在同一系统中执行驱动程序,它就会侵入系统,这种测试情况可能无法接受管道和仿真器普通系统配置 测试存根配置一台计算机可以充当管道,代替打印机,
能够对测试输出进行更有效的分析其它工具类型,
施压工具和增负工具?干扰发生器和噪声发生器?分析工具测试工具产品实例
Junit,Java单元测试工具
Dunit,Delphi的终极测试工具
6.7.2 测试测试自动化另一类软件测试工具,可以自动执行测试用例、查找软件缺陷、分析并记录测试结果。
测试工作台 (下游 CASE工具 )
源代码 预测器测试管理器测试预估模拟器 文件比较器报告生成器动态分析器 被测试的程序测试数据测试结果测试结果报告执行报告测试数据生成器 规约随机测试自动化工具,猴子测试员只要不停电,偶尔能够得到香蕉,猴子就会永远测试下去一个想法,
,如果让一百万只猴子在一百万只键盘上敲一百万年,
它们最终就可能写出莎士比亚话剧等巨著,,
猴子的进步笨猴子,一点也不懂测试软件,只是随机地单击或按键,
直至发生两件事情之一,完成循环或系统崩溃,
不太笨的猴子,具有崩溃辨认能力,
能够重新启动系统开始测试聪明猴子,能够从它的笨兄弟那里获得随机测试的结果,
增加了对环境的认知能力,
有目的地敲键盘,
不仅限于查找崩溃缺陷,同时查看数据,检查操作结果,找出与预期结果的差别自动化测试工具实例美国国际软件自动化（ ISA）公司 的 Panorama for
C/C++,j,Java和 VB产品，自动化功能包括：?
软件结构分析与逻辑框图的自动化?
软件静态分析?
数据分析?
复杂性分析与分析结果列表的自动化?
软件质量分析?
动态性能分析?
软件代码分支或条件覆盖率分析?
软件测试用例有效性分析与测试用例最小集的自动选取?
软件界面手工操作过程的自动记录与自动再执行
(Playback)
§ 6.8 测试中的可靠性分析开发过程中，利用测试的统计数据来估算软件的可靠性，以控制软件的质量。
推测错误的产生频度
推测残留在程序中的错误数
评价测试的精确度和覆盖率推测错误的产生频度
（推测错误产生的时间间隔）
1
K(ET/IT- Ec(t)/IT)
方法,估算平均故障时间 (MTTF估算公式 )
当故障率为独立于时间的常量 λ,
MTTF＝
K,经验常数
ET,程序中原有的残留错误数
IT,程序长度
t,测试时间
Ec(t):在 0-t期间内发现的错误总数
λ
1 =
推测残留在程序中的错误数错误植入模型
Mills将 播种模型 用于程序中残留错误的估算,称 错误植入模型播种模型：
N,程序中原有残留的错误数
Nt：新植入的错误数
n,测试发现的原有错误数
nt,测试发现的植入错误数
N
N
n
n
t ≈ t
NN nn t=
t
Hyman对错误植入模型的改进
ET,程序中原有的残留错误数
E1,1号测试员在某一时间内发现的错误数
E2,2号测试员在同一时间内发现的错误数
E0,两位测试员共同发现的错误数
E
E
E
E
1 ≈ 0 =
2T E
T E1 E 2 /E0
