计划测试_白盒测试
穷举测试
一次循环中,从程序入口到出口,假设有5条路径,循环次数假定为20次。
穷举测试总路径数为: \(5^{20}=9.53674E+13\)
假定每执行1次测试花费1ms,那么穷举测试时间为: 3024.1年
白盒测试:结构测试或逻辑驱动测试
- 测试对象:源程序(程序的内部逻辑)
分类:
- 静态白盒测试技术:代码检查、静态结构分析
- 动态白盒测试技术:程序插桩、逻辑覆盖、基本路径测试、域测试
如何实现路径压缩、问题简化
逻辑覆盖 和 基本路径测试
逻辑覆盖 和 基本路径测试 都是动态白盒测试
逻辑覆盖
逻辑覆盖的类型
-
语句覆盖:使得每一可执行语句至少执行一次
矩形框
-
判定(分支)覆盖:使得程序中的每一个判断至少获得一次“真”和一次“假”,即使得程序流程图中的每一个真假分支至少被执行一次。
-
条件覆盖:使每个判定表达式中的每个条件都取到各种可能的结果
不考虑条件C1,C2间的关系,覆盖每个条件的正负即可
-
判定/条件覆盖:每个判断的所有可能的条件取值组合
判定和条件覆盖的并
-
条件组合覆盖:每个判断的所有可能的条件取值组合
-
路径覆盖:每条可能的路径
注:
- 判定 就是选择(菱形框);条件是 选择的条件(菱形框内的条件)
- 测试用例必须是真值或者空 ,不能为“-”, 真值表/判定表 的内容为
T/F/-
。
由于类型容易混淆,因此需要分类设计、严卡概念
,为了方便理解,对分类在进行分类:
案例程序3.1:连锁选择结构
function js(float A,float B,float X) { if(A>1&&B==0) X=X/A; if(A==2||X>1) X=X+1; }
注意:
- 不是由程序推出的测试用例
- 测试用例没有特殊要求,随意取值
(一)、只考虑整体
-
语句覆盖:每条可执行语句
-
判定(分支)覆盖:每条分支路径
-
路径覆盖:每条可能的路径
(二)、只考虑局部
- 条件覆盖
- 条件组合覆盖
(三)、兼顾整体局部
- 判定/条件覆盖
(一)、只考虑整体
1.语句覆盖:使得每一可执行语句至少执行一次矩形框
优点:
缺点:
- 无法预测隐藏条件和分支
- 无法检查出条件语句错误
- 无法检查出逻辑运算错误
- 无法检查出循环语句错误
2. 判定覆盖:每个判定的所有可能取值
使得程序中的每一个判断至少获得一次“真”和一次“假”,即使得程序流程图中的每一个真假分支至少被执行一次。
判定覆盖比语句覆盖严格,能消除隐式分支,但是仍不能保证判断条件的正确性。
对于两个连锁选择结构有两种情况:
-
同真同假(发现错误能力较弱)
-
交叉取值(发现错误能力较强)
优点
- 比语句覆盖具有更强的测试能力;
- 具有简单性,无须细分每个判定即可得到测试用例
缺点:
往往大部分的判定语句是由多个逻辑条件组合而成,若仅仅判断其最终结果,而忽略每个条件的取值情况,必然会遗漏部分测试路径
3. 路径覆盖:每条可能的路径
对于连锁选择结构就是覆盖所有的路径:
优点:根据多缺陷,覆盖完全。
缺点:效率低。
(二)、只考虑局部
1. 条件覆盖:使每个判定表达式中的每个条件都取到各种可能的结果不考虑条件C1,C2间的关系,覆盖每个条件的正负即可
对于两个连锁选择结构有两种情况:
-
同真同假(发现错误能力较弱)
关注的是对于c1、c2、c3、c4的T、F ,不关注 D1和D2 。 -
交叉取值(发现错误能力较强)
优点:增加了对符合判定情况的测试,增加了测试路径
缺点:需要足够多的测试用例,但条件覆盖并不能保证分支覆盖。条件覆盖只能保证每个条件至少有一次为真,而不考虑所有的判定结果
注:条件覆盖和判定覆盖 两者不是包含关系,但是有交集;两者各有优点和缺点
2. 条件组合覆盖:每个判断的所有可能的条件取值组合
优点:同时满足判定覆盖、条件覆盖和判定/条件覆盖准则
缺点:线性的增加了测试用例的数量
满足条件组合覆盖的测试数据,也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准
(三)、兼顾整体局部
判定/条件覆盖 同真同假
优点:同时满足判定覆盖和条件覆盖准则,弥补了二者的不足
缺点:未考虑条件的组合情况
由判定覆盖和条件覆盖的综合特性以及逻辑与和逻辑或本身的特性决定,该准则并不一定会发现逻辑表达式中的错误(与、或)
基本路径测试
单缺陷
基本路径测试是在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例的方法。
- 在基本路径测试中,设计出的测试用例要保证在被测程序的每一条可执行语句上至少执行一次
和 语句覆盖 的路径不同
2. 基本路径测试的步骤
- 画出程序控制流程图
- 计算程序环路复杂性
- 确定独立路径集合
- 准备测试用例
1. 画出程序控制流程图
控制流图只允许出现弧到节点连线,不允许出现弧到弧的弧和节点到弧的弧。
因此增加汇合点即可
程序控制流程图单入口,单出口
,且由以下内容组成:
- 结点:代表操作、条件判断及汇合点
- 控制流线或弧:控制的顺序
- 区域:弧与结点圈定的部分
且由以下四个结构:
- 处理:入度和出度≤1
- 判定:出度≥2
- 汇合点:入度≥2
对于图的转换注意以下几点:
- 复合条件下判定语句需拆分,控制流程图需保证每个条件结点出度等于2
- 图的绘制保证单入口单出口
- 根据情况适当增加汇合点
- 标明区域(注意开放的区域)
1. 化简
1. 化简:若在一个节点序列中没有分支,则可以把这个序列的节点都合并成一个节点。
2. 遇到复合条件进行拆分。
if a and b then x else y
/*********** ⇃⇩⇂ ***********/
if a then
if b then x else y
else
y
2. 计算程序环路复杂性
计算程序复杂度的三种方法:
-
将程序复杂度定义为程序控制流图中的区域数
注意图形外围也是一个区域
-
若设P为程序控制流图中的判定结点数,则有\(V(G)=P+1\)
条件结点
-
设 \(E\) 为程序控制流图的边数,\(N\) 为图的结点数,则定义程序的复杂度为\(V(G)=E-N+2\)
注意:计算时需要写出计算过程
3. 确定独立路径集合
独立路径是一种基本路径
独立路径是指从入口到出口的一条通路
- 和其他的独立路径相比,至少引入一个新处理语句(结点),或一条新的控制流线(弧)
注意:
-
程序的独立路径数 \(<= V(G)\)
没有循环 或 是存粹的嵌套关系,是 \(= V(G)\)
有循环 或 连锁(上个条件,影响下个条件的取值) 或 不合理的路径,是 \(< V(G)\) -
独立路径的关键是覆盖所有的弧,是弧的覆盖。
-
需要排除不合理的情况
控制流线
4. 准备测试用例
尽量基于 单缺陷假设。
实例
-
画出程序控制流程图
-
计算程序环路复杂性
V(G)=区域数=4
V(G)=E-N+2=11-9+2=4
V(G)=P+1=3+1=4
得出:独立路径数≤环路复杂性=4
-
确定独立路径集合
P1:1-2-9
P2:1-2-3-4-9
P3:1-2-3-5-6-8-2-9
P4:1-2-3-5-7-8-2-9
-
准备测试用例
例二
① 复合条件下判定语句需拆分
② 控制流程图需保证每个条件结点出度等于2
③ 图的绘制保证单入口单出口
④ 根据情况适当增加汇合点
其他动态白盒测试方法
程序插桩
方法简介
- 向源程序中添加一些语句,实现对程序语句的执行、变量的变化等情况进行检查
- 了解一个程序在某次运行中所有可执行语句被覆盖的情况,或是每个语句的实际执行次数
例:
查看 计算整数X和整数Y的最大公约数程序 的是否满足语句覆盖:插入计数
设计插桩程序时需要考虑的问题:
-
探测哪些信息;
-
在程序的什么部位设置探测点;
程序块的第一个可执行语句之前
有标号的可执行语句处
Do、Do While、Do Until、for等循环语句处
If、ElseIf、Else及End If等条件语句各分支处
输入/输出语句之后
函数、过程、子程序调用语句之后
Return语句之后
Goto语句之后 -
需要设置多少个探测点;
-
如何在程序中特定部位插入某些用以判断变量特性的语句。
断言语句
在程序的特定部位插入某些用以判断变量特性的语句,使得程序执行中这些语句得以证实,从而使程序的运行特性得以证实,这些语句称为断言(assertions)
遇到错误即停止程序
域测试
域测试是一种基于程序结构的测试方法,之前常用于对模块的测试。
Howden(提出者)对程序中出现的错误分类:
-
主要用来:如果程序的控制流有错误,对于某一特定的输入可能执行的是一条错误路径,这种错误称为路径错误,也叫做域错误
即x>=1
与x>1
,x>1
与x>0
的错误 -
如果对于特定输入执行的是正确路径,但由于赋值语句的错误致使输出结果不正确,则称此为计算型错误
-
程序某处缺少判定谓词引起的错误是丢失路径错误
域测试方法基于对输入空间的分析
- 测试的理想结果就是检验输入空间中的每一个输入元素是否都产生正确的结果
- 输入空间可分类为不同的子空间,子空间的划分是由程序中分支语句的谓词决定的
等价类
- 域测试正是在分析输入域的基础上,选择适当的测试点以后进行测试的
边界值
示例:
READ I, J;
IF I<=J+1
THEN K=I+J-1;
ELSE K=2*I+1;
IF K>=I+1
THEN L=I+1;
ELSE L=J-1;
IF I=5
THEN M=2*L-K;
ELSE M=L+2*K-1
WRITE M
1. 输入空间的划分
2. 测试点的选择:
- ON点:位于域的边界上
- OFF点:离边界有一个小距离ε,并在被测域之外
如果将ON点与OFF点交替选择,即让OFF点在两个ON点所决定直线上的投影在ON点之间,可较好的测出由于边界错误导致的域错误
判断测试点是否给出正确结果的依据是此测试点是否属于其应属的域中
注意: 即使ABC三点都满足要求也不一定程序正确,比如如果程序边界为P和Q即测试不出。因此要求不能随便取值。
错误边界距离正确边界相差不大的情况称为边界位移
边界位移错误、谓词中运算符错误
静态白盒测试
静态白盒测试是指 不运行被测程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程
静态测试可采用手工或软件工具进行
代码检查法
代码检查法主要对以下内容进行检查:
(1) 检查代码和设计的一致性;
(2) 代码的可读性以及对软件设计标准的遵循情况;
(3) 代码逻辑表达的正确性;
(4) 代码结构的合理性;
(5) 程序中不安全、不明确和模糊的部分;
(6) 编程风格方面的问题等
分类:
-
桌面检查:程序员自己检查自己所编写的程序
-
代码审查:代码审查组由组长、资深程序员、程序编写者与专职测试人员等,组长不能是被测程序的编写者
-
代码走查:代码走查的讨论过程是非正式的
-
技术评审:最正式的审查类型,具有高度的组织化,要求每一个参与者都接受训练
注意:审查法和走查法比较相似,一般只采用其中一个
桌面检查
正式程度最低,编写完代码即可进行
程序设计人员
对源程序代码进行分析、检查,并补充相关文档,发现程序中的错误- 检查内容:变量,标号,子程序、宏、函数,等价性,常量,设计标准检查,风格检查,比较控制流,选择、激活路径,对照程序的规格说明,详细阅读源代码
- 效率极低
- 违反测试原则(可选择互审)
代码审查
代码审查组 组成:开发组内部进行,不少于4人,包括组长、资深程序员、程序编写者与专职测试人员
代码审查步骤:由4个步骤组成,包括准备、程序阅读、审查会(头脑风暴)、编写报告
代码审查方式:
- 由程序编码人员逐条语句讲述程序的逻辑结构
- 对照历来常见的编码错误列表或代码审查清单分析程序
- 有正式的计划、流程和结果报告
走查
人员充当编译器的角色
-
人员组成:由程序设计人员和测试人员组成5人审查小组
资深程序员、有程序经验的测试人员、没有介入项目的新人 -
形式:通过逻辑运行程序查找错误
-
审查期间活动:依据测试用例数据逻辑运行程序,并把程序的状态(如变量的值)记录在纸张或白板上以供监视
注:此时的测试用例不需要精挑细选,只要覆盖逻辑即可。
技术评审
推向市场之前的最后一个步骤,形式上和走查/审查法类似。
-
人员组成:由开发组、测试组和相关人员(QA、产品经理等)联合进行
-
形式:综合运用走查、审查技术,逐行、逐段的检查软件
-
技术评审与走查和审查的不同之处在于表述代码的表述者
-
检查要点是设计需求、代码标准/规范/风格和文档的完整性与一致
总结
优点:
- 一旦发现错误,即可在代码中精确定位,降低调试的成本;
- 还可发现成批的错误
效果:通常是能够有效地查找出30%-70%的逻辑设计和编码错误,但不能有效地查找出高层次的设计错误,且耗费时间较多
地位:是与计算机的测试互补的
黑盒测试与白盒测试的比较
黑盒测试 | 白盒测试 | |
---|---|---|
测试规划 | 根据用户的规格说明,即针对命 令、信息、报表等用户界面及体 现它们的输入数据与输出数据之 间的对应关系,特别是针对功能 进行测试。 |
根据程序的内部结构,比如语句的控制结构, 模块间的控制结构以及内部数据结构等进行测试。 |
优点 | 能站在用户立场上进行测试。 | 能够对程序内部的特定部位进行覆盖测试。 |
缺点 | 不能测试程序内部特定部位。 如果规格说明有误,则无法发现。 |
无法检验程序的外部特性。 无法对未实现规格说明的程序内部欠缺部分进行测试。 |
方法举例 | 因果图分析 等价类划分 边界值分析 判定表驱动 |
语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 基本路径覆盖 循环覆盖 模块接口测试 |
白盒与黑盒这两类测试是从完全不同的角度出发看待测试对象的
白盒测试只考虑测试软件产品,不保证完整的需求规格是否被满足;而黑盒测试只考虑需求规格,不保证实现的所有部分是否被测试到
黑盒测试会发现遗漏的缺陷,指出规格的哪些部分没有被完成;而白盒测试会发现提交的缺陷,指出哪些实现的部分是错误的
白盒测试的成本比黑盒测试高得多。它需要在测试可以被计划之前先有源代码
一个白盒测试的失败会导致一次修改,这需要所有的黑盒测试被重复执行并且重新决定白盒测试路径
白盒测试的优点:
迫使测试人员去仔细思考软件的实现
可以检测代码中的每条分支和路径
揭示隐藏在代码中的错误
对代码的测试比较彻底
最优化
白盒测试的缺点:
昂贵
无法检测源代码中遗漏的路径和数据敏感性错误
不验证规格的正确性
黑盒测试的优点:
对于较大的代码单元(子系统或系统级),黑盒测试比白盒测试效率要高
测试人员不需要了解实现的细节,包括特定的编程语言
测试人员和编码人员是彼此独立的
从用户的视角进行测试,很容易被理解和接受
有助于暴露任何规格不一致或有歧义的问题
测试用例可以在规格说明完成后马上作出来
黑盒测试的缺点:
只有一小部分可能的输入被测试到,要测试每个可能的输入流几乎是不可能的
若没有清晰和简明的规格说明,测试用例很难设计
会有很多程序路径没被测试到
不能直接针对特定程序(模块)测试,这些程序可能很复杂(因此可能隐藏更多的问题)