【白盒测试概念】

白盒测试（也称结构测试或逻辑驱动测试），它从程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。

应用白盒法时，手头必须有程序的规格说明及程序清单。

白盒法考虑的是测试用例对程序内部逻辑的覆盖程度。穷举测试不可行，希望的是尽量提高覆盖的程度。

 

【测试覆盖标准】

1 测试覆盖率

为了衡量测试的覆盖程度，需建立一些标准。

测试覆盖率用于确定测试所执行到的覆盖项的百分比。

测试覆盖率包括：功能点覆盖率和逻辑覆盖率

（1）功能点覆盖率：大致用于表示软件已经实现的功能与软件需要实现的功能之间的比例关系。

（2）逻辑覆盖率：是指程序逻辑的覆盖率，可分为语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖。

 

2 覆盖标准

覆盖标准从低到高分别是：

（1）语句覆盖SC（Statement Coverage）

选择足够的测试用例，使得程序中每个语句至少都能被执行一次。

是最弱的逻辑覆盖，效果有限，必须与其他方法交互使用。

（2）判定覆盖（也成为分支覆盖）DC（Decision Coverage）

执行足够的测试用例，使得程序中的每一个分支至少都通过一次。

判定覆盖只比语句覆盖稍强。

（3）条件覆盖CC（Condition Coverage）

执行足够的测试用例，使程序中每个判断的每个条件的每个可能取值至少执行一次。

条件覆盖深入到判定中的每个条件，但可能不满足判定覆盖的要求。

（4）判定/条件覆盖CDC（Condition/Decision Coverage）

执行足够的测试用例，使得判定中每个条件取到各种可能的值，并使每个分支取到各种可能的值。

判定/条件覆盖有缺陷：从表面看，它测试了所有条件的取值，但其实往往是某些条件掩盖了另一些条件，会遗漏某些条件取值错误的情况。

（5）条件组合覆盖MCC（Multiple Condition Coverage）

执行足够的例子，使得每个判定中条件的各种可能组合都至少出现一次。

它不但可以覆盖所有条件的可能取值的组合，还可覆盖所有判断的可取分支，但可能有的路径会遗漏掉。

（6）路径覆盖

设计足够多的测试用例，要求覆盖程序中所有可能的路径。

 

【逻辑驱动测试】

1 概述

逻辑驱动测试是指设计足够多的测试用例，运行所测程序，满足某种测试覆盖率要求。

基本的有以上文章中描述的六种。

 

2 不同的逻辑驱动测试

2.1 语句覆盖

选择足够的测试用例，使得程序中每个语句至少都能被执行一次。

优点：可以很直观地从源代码得到测试用例，无须细分每条判定表达式。

缺点：语句覆盖很弱，无法发现判定中逻辑运算的错误，不是一种充分的检验方法。

 

2.2 判定覆盖/分支覆盖

执行足够的测试用例，使得程序中的每一个分支至少都通过一次。

 

2.3 条件覆盖

一个判定中往往包含若干个条件，”条件覆盖“是指：

执行足够的测试用例，使得判定中的每个条件获得各种可能的结果。

 

2.4 分支/条件覆盖

执行足够的测试用例，使得判定中每个条件取到各种可能的值，并使每个分支取到各种可能的值。

 

2.5 条件组合覆盖

执行足够的例子，使得每个判定中条件的各种可能组合都至少出现一次。

显然，满足“条件组合覆盖”的测试用例一定满足“分支覆盖”、“条件覆盖”和“分支/组合覆盖”的。

 

2.6 修正条件判定覆盖

在分支/条件覆盖的基础上，加上判定中的每一个条件必须能够独立影响一个判定的输出，即在其他条件不变的前提下，仅改变这个条件的值，使得判定结果改变。

举个栗子：

对于上图中的第一个判定，所有可能的条件组合为：

测试用例	A>1	B=0	结果
1	T	T	T
2	T	F	F
3	F	T	F
4	F	F	F

 

测试用例1和3表明，A>1独立影响判定的输出；

测试用例1和2表明，B=0独立影响判定的输出；

所以测试用例1、2、3是必须的。

 

2.7 路径覆盖

设计足够多的测试用例，要求覆盖程序中所有可能的路径。

满足路径覆盖不一定满足组合条件覆盖。

 

3 综合策略——黑盒法补充测试用例

（1）在任何情况下都使用边界值分析（注意应该包括对输入和输出的边界值进行分析）

（2）必要的话，再用等价类划分法补充一些测试用例

（3）再用错误推测法附加测试用例

（4）检查上述例子的逻辑覆盖程度，如果未能满足某些覆盖标准，则再增加足够的测试用例

（5）如果功能说明中含有输入条件的组合情况，则一开始就可先用因果图（判定表）法

 

【基本路径测试】

1 基本路径测试

基本路径测试在程序控制图的基础上，通过分析控制构造的环形复杂度，导出基本可执行路径集合，从而设计测试用例的方法。

设计出的测试用例要保证语句覆盖。

 

2 基本路径测试的4个步骤：

（1）画出程序的控制流图：

控制流图是描述程序控制流的一种图示方法。

将流程图映射到一个相应的流图（假设流程图的菱形决定框不包含复合条件）

a. 一个流程图的处理方框序列和一个菱形决策框可被映射为一个流图结点。

b. 流图中的箭头（边）类似于流程图中的箭头。一条边必须终止于一个结点，即使该结点并不代表任何语句。

 

（2）计算程序圈复杂度：

采用McCabe复杂性度量。

从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行一次的测试用例数目的上界。

三种计算圈复杂度的方法：

a. 流图中区域的数量对应于环形的复杂性；

b. 给定流图G的圈复杂度V(G) = E – N + 2，E是流图中边的数量，N是流图中结点的数量；

c. 给定流图G的圈复杂度V(G) = P +1，P是流图G中判定结点的数量。

 

（3）导出测试用例：

根据圈复杂度和程序结构设计测试用例。

a. 根据圈复杂度得到对应数目的独立路径

b. 根据独立路径，设计输入数据，使程序分别执行到各个独立路径

 

（4）准备测试用例：

确保基本路径集中的每一条路径的执行。

 

3 控制流图

流图只有两种图形符 ：

（1）?：流图的结点，代表一条或多条语句、一个处理框序列、一个条件判定框（假设不包含符合条件）

（2）→：称为边或连接，代表控制流

 

在将程序流程图简化成控制流图时，应该注意：

（1）包含条件或多分支的结点称为判定结点（也成为谓词结点），在选择或多分枝结构中，分支的汇聚处应有一个汇聚结点。

（2）边和结点圈定的区域叫做区域，当对区域计数时，图形外的区域也应该记为一个区域。

计算区域时，一定不要忘记区域外的部分。

 

如果判断中的条件表达式是由一个或多个逻辑运算符（OR, AND, NAND, NOR）连接的复合条件表达式，则需要改为一系列只有单条件的嵌套的判断。

举个栗子：

对应的逻辑为：

 

4 独立路径

独立路径是指至少沿一条新的边移动的路径

对所有独立路径的遍历，就是至少一次地执行了程序中的所有语句。

 

【控制结构测试的变种】

基本路径测试是控制结构测试技术之一，尽管其简单高效，但是其本身并不充分。

下面讨论控制结构测试的其他变种。

1 条件测试

条件测试方法注重测试程序中的条件，是检查程序模块中所包含逻辑条件的测试用例设计方法。

条件

程序中的条件分为简单条件和复合条件

简单条件：

是一个 布尔变量 或一个 可能带有NOT(“!”)操作符的关系表达式

关系表达式的形式如：E1 E2

复合条件：由简单条件通过逻辑运算符（AND、OR、NOT）和括 连接而成，不含关系表达式的条件称为布尔表达式。

因此，条件的成分类型包括：

布尔变量、关系操作符或算术表达式、逻辑运算符、括弧

 

条件的错误类型

（1）布尔变量错误

（2）关系操作符错误

（3）算术表达式错误

（4）逻辑运算符错误（遗漏、多余或不正确）

（5）括弧错误

 

条件测试的目的

条件测试是测试程序条件错误和程序的其他错误

如果程序的测试集能够有效地检测程序中的条件错误，则该测试集也会有效地检测程序中的其他错误；如果测试策略对检测条件错误有效，则它也可能有效地检测程序错误。

 

条件测试策略

（1）穷举测试

由n个变量的布尔表达式需要 2^n 个可能的测试。

（2）分支测试

分支测试是真假分支必须至少执行一次的路径策略。

对于复合条件C，C的真分支和假分支以及C中的每个简单条件都需要至少执行一次。

（3）域测试

域测试是对于大于、小于和等于值得测试策略。

域测试要求从有理表达式中导出三个或四个测试用例，

有理表达式的形式如：E1 E2

需要三个测试分别用于计算E1的值是大于、等于或小于E2的值。

（未完）

 

2 数据流测试

（未完）

 

3 循环测试

（未完）