白盒测试:理论基础
白盒测试:理论基础
2016-08-23
白盒测试的概念
2 白盒测试的主要目的
3 测试覆盖标准
4 白盒测试的主要方法
4.1 逻辑驱动测试
4.1.1 语句覆盖
4.1.2 判定覆盖(分支覆盖)
4.1.3 条件覆盖
4.1.4 判定/条件覆盖
4.1.5 条件组合覆盖
4.1.6 黑盒法补充测试用例
4.2 路径测试
4.2.1 基本路径测试
1) 控制流图
2) 独立路径
3) 基本路径测试
4) 工具方法:图形矩阵
5 控制结构测试的其他变种
5.1 条件测试
5.1.1 条件
5.1.2 条件测试的目的
5.1.3 条件测试策略
5.2 循环测试
6 面向对象的白盒测试
6.1 类测试方式
6.1.1 结构性测试
7 白盒测试工具
8 总结
8.1 白盒测试的主要方法的优缺点
8.2 穷举路径测试的局限性
返回
白盒测试也称结构测试或逻辑驱动测试,是一种测试用例设计方法,它从程序的控制结构导出测试用例。(测试用例由测试输入数据以及与之对应的输出结果组成。)
白盒测试使用被测单元内部如何工作的信息,允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例,对程序的逻辑路径进行测试。基于一个应用代码的内部逻辑知识,测试是基于覆盖全部代码、分支、路径、条件。
返回
- 保证一个模块中的所有独立路径至少被执行一次;
- 对所有的逻辑值均需要测试真、假两个分支;
- 在上下边界及可操作范围内运行所有循环;
- 检查内部数据结构以确保其有效性。
返回
白盒法特点:以程序的内部逻辑为基础设计测试用例,所以又称为逻辑覆盖法。应用白盒法时,手头必须有程序的规格说明以及程序清单。
白盒法考虑的是测试用例对程序内部逻辑的覆盖程度。最彻底的白盒法是覆盖程序中的每一条路径,但是由于程序中一般含有循环,所以路径的数目极大,要执行每一条路径是不可能的,只能希望覆盖的程度尽可能高些。
图1 程序流程图
图1包括了一个执行达20次的循环。那么它所包含的不同执行路径数高达520(=1013)条,若要对它进行穷举测试,覆盖所有的路径。假使测试程序对每一条路径进行测试需要1毫秒,同
样假定一天工作24小时,一年工作365天, 那么要想把如图所示的小程序的所有路径测试完,则需要3170年。
为了衡量测试的覆盖程度,需要建立一些标准,目前常用的一些覆盖标准从低到高分别是:
- 语句覆盖:是一个比较弱的测试标准,它的含义是:选择足够的测试用例,使得程序中每个语句至少都能被执行一次。它是最弱的逻辑覆盖,效果有限,必须与其它方法交互使用。
- 判定覆盖(也称为分支覆盖):执行足够的测试用例,使得程序中的每一个分支至少都通过一次。判定覆盖只比语句覆盖稍强一些,但实际效果表明,只是判定覆盖,还不能保证一定能查出在判断的条件中存在的错误。因此,还需要更强的逻辑覆盖准则去检验判断内部条件。
- 条件覆盖:执行足够的测试用例,使程序中每个判断的每个条件的每个可能取值至少执行一次;条件覆盖深入到判定中的每个条件,但可能不能满足判定覆盖的要求。
- 判定/条件覆盖:执行足够的测试用例,使得判定中每个条件取到各种可能的值,并使每个判定取到各种可能的结果。判定/条件覆盖有缺陷。从表面上来看,它测试了所有条件的取值。但是事实并非如此。往往某些条件掩盖了另一些条件。会遗漏某些条件取值错误的情况。为彻底地检查所有条件的取值,需要将判定语句中给出的复合条件表达式进行分解,形成由多个基本判定嵌套的流程图。这样就可以有效地检查所有的条件是否正确了。
- 条件组合覆盖:执行足够的例子,使得每个判定中条件的各种可能组合都至少出现一次。这是一种相当强的覆盖准则,可以有效地检查各种可能的条件取值的组合是否正确。它不但可覆盖所有条件的可能取值的组合,还可覆盖所有判断的可取分支,但可能有的路径会遗漏掉。测试还不完全。
返回
- 逻辑驱动测试
- 语句覆盖
- 判定覆盖(分支覆盖)
- 条件覆盖
- 判定/条件覆盖
- 条件组合覆盖
-
基本路径测试
- 设计足够多的测试用例,运行所测程序,要覆盖程序中所有可能的路径。这是最强的覆盖准则。但在路径数目很大时,真正做到完全覆盖是很困难的,必须把覆盖路径数目压缩到一定限度。
返回
- 语句覆盖
- 判定覆盖(分支覆盖)
- 条件覆盖
- 判定/条件覆盖
- 条件组合覆盖
基本路径测试
- 设计足够多的测试用例,运行所测程序,要覆盖程序中所有可能的路径。这是最强的覆盖准则。但在路径数目很大时,真正做到完全覆盖是很困难的,必须把覆盖路径数目压缩到一定限度。
前面所述的基本路径测试技术是控制结构测试技术之一。尽管基本路径测试简单高效,但是,其本身并不充分。下面讨论控制结构测试的其他变种,这些测试覆盖并提高了白盒测试的质量。包括:
- 条件测试
- 数据流测试 (略)
- 循环测试。
返回
对OO软件的类测试相当于传统软件的单元测试。和传统软件的单元测试不同,他往往关注模块的算法细节和模块接口间流动的数据,OO软件的类测试是由封装在类中的操作和类的状态行为所驱动的。OO软件测试的特点:
- 因为属性和操作是被封装的,对类之外操作的测试通常是徒劳的。封装使对对象的状态快照难于获得。
- 继承也给测试带来了难度,即使是彻底复用的,对每个新的使用语境也需要重新测试。
- 多重继承更增加了需要测试的语境的数量,使测试进一步复杂化。如果从超类导出的测试用例被用于相同的问题域,有可能对超类导出的测试用例集可以用于子类的测试,然而,如果子类被用于完全不同的语境,则超类的测试用例将没有多大用途,必须设计新的测试用例集。
返回
内存资源泄漏检查:Numega中的bouncechecker,Rational的Purify等;
代码覆盖率检查:Numega中的truecoverage,Rational的Purecoverage,Telelogic公司的logiscope,Macabe公司的Macabe等;
开源覆盖率测试软件gCov等。
返回
图5。
8.2 穷举路径测试的局限性
“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误:
- 第一、穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序;
- 第二、穷举路径测试不可能查出程序中因遗漏路径而出错。
- 第三、穷举路径测试可能发现不了一些与数据相关的错误。