在这篇文章中，我们将讲解白盒测试的基本概念，以及四大常用的白盒测试方法。

一、白盒测试基本概念

1、白盒测试的定义

白盒测试又称为结构测试或逻辑驱动测试，它是把测试对象看成一个透明的盒子，它允许测试人员利用程序内部的逻辑结构设计测试用例，对程序所有逻辑路径进行测试。

2、白盒测试的测试对象

白盒测试的测试对象是基于被测试程序的源代码，而不是软件的需求规格说明书。

使用白盒测试方法时，测试人员必须全面了解程序内部逻辑结构，检查程序的内部结构，从检查程序的逻辑着手，对相关的逻辑路径进行测试，最后得出测试结果。

3、白盒测试的原则

采用白盒测试方法必须遵循以下原则：

• 保证一个模块中的所有独立路径至少被测试一次。

• 对所有的逻辑判定均需测试取真和取假两种情况。

• 在上下边界及可操作范围内运行所有循环。

• 检查程序的内部数据结构，保证其结构的有效性。

4、白盒测试的分类

白盒测试方法有两大类：静态测试方法和动态测试方法。

静态测试： 不要求在计算机上实际执行所测试的程序，主要以一些人工的模拟技术对软件进行分析和测试，如代码检查法、静态结构分析法等；

动态测试： 是通过输入一组预先按照一定的测试准则构造实际数据来动态运行程序，达到发现程序错误的过程。白盒测试中的动态分析技术主要有逻辑覆盖法和基本路径测试法。（ ★ ★ ★ ）

下面将对两种白盒测试方法进行讲解。

二、静态白盒测试

1、代码检查法

（1）代码审查的定义

代码审查（Code Review）是指对计算机源代码进行系统地审查，找出并修正在软件开发初期未发现的错误，提升软件质量及开发者的技术。

（2）代码审查的目的

代码审查的目的是为了产生合格的代码，检查源程序编码是否符合详细设计的编码规定，确保编码与设计的一致性和可追踪性。

（3）代码审查的方法

代码审查包括桌面检查、代码审查和走查。

1）桌面检查（程序员自己检查）

这是一种传统的检查方法，由程序员检查自己编写的程序。程序员在程序通过编译之后，对源程序代码进行分析、检查，并补充相关的文档，目的是发现程序中的错误。

2）代码审查（审查小组通过读程序和对照错误检查表进行检查）

代码审查是由若干程序员和测试员组成一个审查小组，通过阅读、讨论和争议，对程序进行静态分析的过程。具体过程如下：

第一步， 小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为审查的依据。小组成员在充分阅读这些材料后，进入审查的下一步。

第二步，召开程序审查会。 每个成员将所发材料作为审查依据，但是由程序员讲解程序的结构、逻辑和源程序。在此过程中，小组成员可以提出自己的疑问；程序员在讲解自己的程序时，也能发现自己原来没有注意到的问题。

注意： 在进行代码检查前应准备好需求文档、程序设计文档、程序的源代码清单、代码编码标准、代码缺陷检查表和流程图等。

3）走查 （审查小组需要准备有代表性的测试用例沿程序逻辑运行）

走查与代码审查基本相同，其过程分为两步：

第一步： 把材料先发给走查小组每个成员，让他们认真研究程序。

第二步： 开会。

与代码审查不同的是，让审查小组成员“充当”计算机，即首先由测试组成员为所测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿着程序的逻辑运行一遍，随时记录程序的踪迹，提供给最后阶段的分析和讨论使用。

（4）代码检查规则

在代码检查中，需要依据被测试软件的特点，选用适当的标准与规则规范。

（5）代码检查项目

• 目录文件组织

• 检查函数

• 数据类型及变量

• 检查条件判断语句

• 检查循环体制

• 检查代码注释

• 桌面检查

• 其他检查

2、静态结构分析法

（1）定义

在静态结构分析法中，测试人员通常通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口、内部控制逻辑等内部结构，生成函数调用关系图、模块控制流图、内部文件调用关系图等各种图形、图表，清晰地标识整个软件的组成结构。

（2）目的

通过分析这些图表，包括控制流分析、数据流分析、接口分析、表达式分析等，使其便于阅读与理解，然后可以通过分析这些图表，检查软件有没有存在缺陷或错误。

（3）静态结构分析的两种方法

1）通过生成各种图表，来帮助对源程序的静态分析

常用的各种引用表主要有： ①标号交叉引用表；②变量交叉引用表；③子程序（宏、函数）引用表；④ 等价表；⑤常数表。

常用的各种关系图、控制流图主要有：

①函数调用关系图： 列出所有函数，用连线表示调用关系，通过应用程序各函数之间的调用关系展示了系统的结构。

②模块控制流图： 由许多结点和连接结点的边组成的图形，其中每个结点代表一条或多条语句，边表示节点间的控制流向，用于显示函数的内部逻辑结构。（★ ★ ★ ）

2) 错误静态分析

静态错误分析主要用于确定在源程序中是否有某类错误或“危险”结构。

①类型和单位分析： 数据类型的错误和单位上的不一致。

②引用分析： 引用异常，变量赋值先引用，或赋值未引用。

③表达式分析： 表达式错误，不正确使用括号，数组下标越界等。

④接口分析： 模块的接口，参数的一致性。

三、动态白盒测试

1、逻辑覆盖法

（1）定义

逻辑覆盖是以程序内部的逻辑结构为基础来设计测试用例的测试技术，通过对程序内部的逻辑结构的遍历来实现程序的覆盖。它属于白盒测试中动态测试技术之一。

（2）6种逻辑覆盖方法

从覆盖源程序语句的详尽程度分析，逻辑覆盖包括以下6种覆盖标准：

• 语句覆盖（SC）；

• 判定覆盖（DC）；

• 条件覆盖（CC）；

• 判定-条件覆盖（CDC）；

• 条件组合覆盖（MCC）；

• 路径覆盖。

接下来将对这6种逻辑覆盖方法进行一一讲解。

1）语句覆盖（SC）

①定义： 语句覆盖(Statement Coverage)的含义就是设计足够的测试用例，使得被测程序中每条语句至少执行一次。又称行覆盖、段覆盖、基本块覆盖，它是最常见的覆盖方式。

②例子展示🌰

Question：

如下java语言程序语句和对应的程序流程图：

public class Test{
    public void Test1(int x,int y,int z){
        if(y>1 && z==0){
            x=(int)(x/y)
        }
        if(y==2 || x>1){
            x=x+1
        }
    }
}

请使用语句覆盖来为该程序设计测试用例。

Answer：

为了使每条语句都能够至少执行一次，我们可以构造以下测试用例：

输入： x=4 , y=2 , z=0

执行路径为：sacbed

语句覆盖虽然可以测试执行语句是否被执行到，但却无法测试程序中存在的逻辑错误。因此，语句覆盖是一种弱覆盖。

例如，如果上述程序中的第一个逻辑判断符号 “&&” 误写了 “||” ，使用测试用例同样可以覆盖 sacbed 路径上的全部执行语句，但却无法发现错误。同样，如果第二个逻辑判断符号 “||” 误写了 “&&” ，使用同样的测试用例也可以执行 sacbed 路径上的全部执行语句，但却无法发现上述逻辑错误。

③语句覆盖的目的：

语句覆盖的目的是测试程序中的代码是否被执行，它只测试代码中的执行语句，这里的执行语句不包括头文件、注释、空行等。

语句覆盖在多分支的程序中，只能覆盖某一条路径，使得该路径中的每一个语句至少被执行一次，但不会考虑各种分支组合情况。

2）判定覆盖（DC）

①定义：

• 判定覆盖(Decision Coverage)又称为分支覆盖，其原则是设计足够的测试用例，使得程序中每个判定语句的取真和取假分支至少被执行一次。

• 除了双值的判定语句外，还有多值判定语句，如case语句，因此判定覆盖更一般的含义是：使得每一个判定获得每一种可能的结果至少一次。

②例子展示🌰

Question：

如下java语言程序语句和对应的程序流程图：

public class Test{
    public void Test2(int x,int y,int z){
        if(y>1 && z==0){
            x=(int)(x/y)
        }
        if(y==2 || x>1){
            x=x+1
        }
    }
}

请使用判定覆盖来为该程序设计测试用例。

Answer：

以上述代码为例，构造以下测试用例即可实现判定覆盖标准：

输入：① x=1,y=3,z=0 ，执行路径为 sacbd

（判断的结果分别为T，F）

输入：② x=3,y=1,z=1 ，执行路径为 sabed

（判断的结果分别为F，T）

上述两组测试用例不仅满足了判定覆盖，而且满足了语句覆盖，从这一点可以看出判定覆盖比语句覆盖更强一些。所以只要满足了判定覆盖就一定满足语句覆盖，反之则不然。

判定覆盖仍然具有和语句覆盖一样无法发现逻辑判断符号 “&&” 误写了 “||” 的逻辑错误。

判定覆盖仅仅判断判定语句执行的最终结果而忽略每个条件的取值，所以也属于弱覆盖。

3）条件覆盖（CC）

①定义：

条件覆盖(Condition Coverage)指的是设计足够的测试用例，使判定语句中的每个逻辑条件取真值与取假值至少出现一次。

例如，对于判定语句 if(a>1 OR c<0) 中存在 a>1、c<0 两个逻辑条件，设计条件覆盖测试用例时，要保证 a>1、c<0 的“真”、“假”值至少出现一次。

②例子展示🌰

Question：

如下java语言程序语句和对应的程序流程图：

public class Test{
    public void Test3(int x,int y,int z){
        if(y>1 && z==0){
            x=(int)(x/y)
        if(y==2 || x>1){
            x=x+1
        }
    }
}

请使用条件覆盖来为该程序设计测试用例。

Answer：

要使程序中每个判断的每个条件都至少取真值、假值一次，我们可以构造以下测试用例：

输入：① x=1,y=2,z=0 ，执行路径为 sacbed

（条件的结果分别为TTTF）

输入：② x=2,y=1,z=1 ，执行路径为 sabed

（条件的结果分别为FFFT）

从条件覆盖的测试用例可知，使用2个测试用例就达到了使每个逻辑条件取真值与取假值都至少出现了一次，但从测试用例的执行路径来看，条件分支覆盖的状态下仍旧不能满足判定覆盖，即没有覆盖 bd 这条路径。相比于语句覆盖与判定覆盖，条件覆盖达到了逻辑条件的最大覆盖率，但却不能保证判定覆盖。

4）判定-条件覆盖（CDC）

①定义：

• 要求设计足够的测试用例，使得判定语句中所有条件的可能取值至少出现一次，同时，所有判定语句的可能结果也至少出现一次。

• 例如，对于判定语句 if(a>1 AND c<1) ，该判定语句有 a>1、c<1 两个条件，则在设计测试用例时，要保证 a>1、c<1 两个条件取“真”、“假”值至少一次，同时，判定语句 if(a>1 AND c<1) 取“真”、“假”也至少出现一次。

②例子展示🌰

Question：

如下java语言程序语句和对应的程序流程图：

public class Test{
    public void Test3(int x,int y,int z){
        if(y>1 && z==0){
            x=(int)(x/y)
        }
        if(y==2 || x>1){
            x=x+1
        }
    }
}

请使用判定条件覆盖来为该程序设计测试用例。

Answer：

为满足判定-条件覆盖原则，我们可以构造以下测试用例：

输入：① x=4,y=2,z=0 ，覆盖路径：sacbed

（判断的结果分别为TT，条件的结果分别为：TTTT ）

输入：② x=1,y=1,z=1 ，覆盖路径：sabd

（判断的结果分别为FF，条件的结果分别为：FFFF ）

判定-条件覆盖满足了判定覆盖准则和条件覆盖准则，弥补了二者的不足。但是判定-条件覆盖不一定比条件覆盖的逻辑更强。

③判定-条件覆盖的缺点： 没有考虑条件的组合情况。

5）条件组合覆盖（MCC）

①定义：

条件组合(Multiple Condition Coverage)指的是设计足够的测试用例，使得每个判定中条件的各种可能组合都至少执行一次。满足了判定覆盖、条件覆盖、判定-条件覆盖准则。

②例子展示🌰

Question：

如下java语言程序语句和对应的程序流程图：

public class Test{
    public void Test4(int x,int y,int z){
        if(y>1 && z==0){
            x=(int)(x/y)
        }
        if(y==2 || x>1){
            x=x+1
        }
    }
}

请使用条件组合覆盖来为该程序设计测试用例。

Answer：

为满足条件组合覆盖原则，我们可以构造以下测试用例：

输入：① x=4,y=2,z=0 ，覆盖路径： sacbed （条件的结果分别为：TTTT ）

输入： ② x=1,y=2,z=1，覆盖路径： sabed （条件的结果分别为：TFTF ）

输入：③ x=2,y=1,z=0 ，覆盖路径： sabed （条件的结果分别为：FTFT ）

输入： ④ x=1,y=1,z=1，覆盖路径： sabd （条件的结果分别为：FFFF ）

由于这4个条件每个条件都有取“真”、“假”两个值，因此所有条件结果的组合有=16种。但是，当一个程序中判定语句较多时，其条件取值的组合数目也较多。需要设计的测试用例也会增加，这样反而会使测试效率降低。

6）路径覆盖

①定义：

路径覆盖指的是设计足够的测试用例，使得程序中的每一条可能组合的路径都至少执行一次。

②例子展示🌰

Question：

如下java语言程序语句和对应的程序流程图：

public class Test{
    public void Test5(int x,int y,int z){
        if(y>1 && z==0){
            x=(int)(x/y)
        }
        if(y==2 || x>1){
            x=x+1
        }
    }
}

请使用路径覆盖来为该程序设计测试用例。

Answer：

为满足路径覆盖原则，我们可以构造以下测试用例：

输入：① x=4,y=2,z=0 ，覆盖路径：sacbed

（判定的结果分别为：TT ）

输入：② x=1,y=2,z=1，覆盖路径： sabed

（判定的结果分别为：FT ）

输入：③ x=1,y=3,z=0 ，覆盖路径： sacbd

（判定的结果分别为：TF ）

输入：④ x=1,y=1,z=1 ，覆盖路径： sabd

（判定的结果分别为：FF ）

2、基本路径测试法

（1）独立路径

独立路径是指包括一组以前没有处理的的语句或条件的一条路径。

从控制流图来看，一条独立路径是至少包含一条在其他独立路径中从未有过的边的路径。

（2）程序控制流图

1）程序控制流图的定义

控制流程图是描述程序控制流的一种图示方式。（有向图）

2）控制流图的两种图形符号

• 图中的每一个圆圈称为流图的结点，表示一个或多个无分支的语句或源程序语句。

• 流图中的箭头称为边或连接，表示控制流线。

3）程序控制流图的5种基本结构

4）程序控制流图的描述

• 程序控制流图实际上可以看作是一种简化了的程序流程图。

• 在控制流图中，只关注程序的流程，不关心各个处理框的细节。

• 因此，原来程序流程图中的各个处理框（包括语句框、判断框、输入/输出框等）都被简化为结点，一般用圆圈表示，而原来程序流程图中的带有箭头的控制流变成了控制流图中的有向边。

5）举个栗子🌰

下图是典型的程序流程图转换为相对应的流图。对（a）图所示的程序流程图进行简化，得到（b）图所示的流图。

 6）注意事项

在将程序流程图简化成控制流图时，应注意如下几点：

• 一组顺序结构可以映射为一个单一的结点。

• 在选择多分支结构中分支的汇集处时，即使没有执行语句也应该添加一个汇聚结点。

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

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

（3）软件复杂度

• 软件复杂度是指理解和处理软件的难易程度。

• 程序复杂度是软件度量的重要组成部分。

• 度量方法： McCabe 度量法（环路度量）

（4）程序复杂度

环路复杂度又称为圈复杂度，是一种为程序逻辑复杂度提供定量尺度的软件度量。它可以提供程序基本路径集的独立路径数量，这是确保所有语句至少执行一次的过程所必须的最少测试用例数。常用于基本路径测试法。

（5）环路复杂度

McCabe 复杂性度量方式有如下三种：

⭐️⭐️⭐️

 1）通过控制流图的区域个数来计算

公式：V(G)＝区域数

程序的环路复杂性为控制流图的区域数（即封闭的区域数+1）。

在下图中可以看到，有 1 和 2 两个封闭区域，因此，环路复杂度V(G)＝2 + 1 = 3。

（２个封闭的区域＋１个开放区域）　

2）通过控制流图的边数和结点数来计算

公式：V(G) = e - n + 2

其中， e 即 edge ，表示图中边的数目； n 即 node ，表示结点个数。

下图中V(G)= e - n + 2 = ７条边 − ６个结点 + 2 = 3。

因此，环路复杂度V(G)＝３。

 3）通过控制流图中的判定结点个数来计算

公式：V(G) = P + 1

其中，P表示判定结点的数目。所谓判定节点数，即有多个分支的节点，比如下图中的节点 2 ，它可以走3或者5，这个时候它就需要做判断了。所以， 2 是一个判定节点。同样地，下面的 节点3 也像节点 2 一样分析。

因此，图中V(G)=２个判定结点＋1 = 3，所以环路复杂度为３。

讲到这里，我们来给环路复杂性做个小结。事实上，程序的环路复杂性给出了程序基本路径集中的独立路径条数，这是确保可执行语句至少执行一次所必需的测试用例数目的上界。

通过对以上三个例子的了解，相信大家对环路复杂度的三种求解方式有了一个新的认识。有了上面一系列内容的铺垫，我们来开始讲解基本路径测试法。

（6）基本路径测试法

1）基本路径测试法是什么

路径测试就是从一个程序的入口开始，执行所经历的各个语句的完整过程。从广义的角度讲，任何有关路径分析的测试都可以被称为路径测试。

完成路径测试的理想情况就是做到路径覆盖，但对于复杂性较大的程序要做到所有的路径覆盖（测试所有可执行路径）是不可能的。

在不能做到所有路径覆盖的情况下，如果某一程序的每一个独立路径都被执行到，那么就可以认为程序中的每个语句都已经检验过了，即达到了语句覆盖。这种测试方法就是通常所说的基路径测试法。

基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径的集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。

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

基本路径测试法包括以下4个步骤：

• 以详细设计或源代码作为基础，绘制程序的控制流图。

• 计算得到的控制流图G的环路复杂性V（G）。

• 确定独立路径的集合。通过程序控制流图导出基本路径集，列出程序的独立路径。所谓独立路径，是指至少包含一条新边的路径，也就是包含一些前面的路径未包含的语句，当所有的语句都包含了，基路径集就够了。（线性无关路径）

• 设计测试用例，确保基本路径集中每条路径的执行。

3）例子阐述1 🌰

依据以下代码，用基本路径测试法，设计该程序的测试用例。

if(a>8 && b>10)   //1,2
    m=m+1;       //3
if(a=10 || c>5)  //4,5
   m=m+5;       //6

解答：

①绘制程序控制流图，如下图所示。

②计算环路复杂度

V(G)=4（3个封闭区域+1个开放区域）

③确定线性无关路径：

路径1：1、4、6

路径2：1、4、5、6

路径3：1、2、4、5、6

路径4：1、2、3、4、5、6

④设计测试用例

编号	输入数据	预期输出	覆盖路径
1	a=2,b=3,c=4	m=0	1、4、6
2	a=2,b=3,c=8	m=5	1、4、5、6
3	a=10,b=6,c=8	m=5	1、2、4、5、6
4	a=10,b=15,c=8	m=6	1、2、3、4、5、6

4）例子阐述2 🌰

依据以下代码，用基本路径测试法，设计该程序的测试用例。

class Test{
    static void permute_args(int panonopt_start, int panonopt_end, int opt_eng, int ncycle){
        int cstart, cycle, i, j, nnonopts, nopts, pos; //1
    
        nnonopts = panonopt_end - panonopt_start;
        nopts = opt_end - panonopt_end;
        cyclelen = (opt_end - panonopt_start)/ncycle;
    
        for(i = 0; i < ncycle; i++){ //2
            cstart = panonopt_end + i; //3
            pos = cstart;
            for(j = 0; j < cyclelen; j++){ //4
                if(pos >= panonopt_end){ //5
                    pos -= nnonopts; //6
                }else{
                    pos += nopts; //7
                }
            }
        }
    } //8
}

【问题1】请针对上述java程序给出满足100%DC（判定覆盖）所需的逻辑条件。

【问题2】请画出上述程序的控制流图，并计算其控制流图的环路复杂度V(G)。

【问题3】请给出问题2种控制流图的线性无关路径。

解答：

【问题1】

满足100%判定的逻辑条件为：

i<ncycle;
i>=ncycle;
j<cyclelen;
j>=yclelen;
pos>=panonopt_end;
pos<panonopt_end; 

【问题2】

控制流图如下图所示，V(G)=4。

 【问题3】

线性无关路径：

路径1：1、2、8

路径2：1、2、3、4、2…

路径3：1、2、3、4、5、6、4…

路径4：1、2、3、4、5、7、4…

四、写在最后

        对于软件测试中的白盒测试来说，主要需要了解白盒测试的基本概念，静态和动态白盒测试的方法，内容较黑盒测试来说逻辑性会更强一些。同时，值得注意的是，在动态测试中的基本路径测试法中，线性无关路径的识别要尤为小心，在计算过程中很容易出现多写的问题。因此，在此基础上，大家可以再多找几道相关的题目进行练习，举一反三。

作者：中国移动云能力中心  ——周煜澄

概要：任何一个软件公司发布的产品都有缺陷，所以软件测试是产品开发过程中必不可少的一部分。经过长期的发展，软件测试方法不断完善，探索式测试方法也是其中的一种。本文将结合实际工作谈谈对探索式测试方法的理解。

    任何一个软件公司发布的产品都有缺陷，所以软件测试是产品开发过程中必不可少的一部分。经过长期的发展，软件测试方法不断完善，探索式测试方法也是其中的一种。本文将结合实际工作谈谈对探索式测试方法的理解。

    探索式测试方法主要分为两类：局部探索式测试法针对测试人员在运行任何一个测试用例时所需要作出的细微决定；全局探索式测试法针对测试人员在编制测试计划和测试用例设计时所需要考虑的广泛的战略性问题。 

一、局部探索式测试法 

1、输入：合法输入、非法输入
      1）输入筛选器
      第一，开发是否正确的实现了该功能？
      第二，是否可以绕过屏蔽器？或者当输入值进入系统后还可以修改？
      2）输入检查
      测试时必须仔细阅读每一条错误信息，检查该信息是否写错了，错误信息还可以透漏开发编程时的一些想法。
      3）异常处理
      如果测试看到一个通用出错信息，建议测试再反复测试同一段函数，继续使用刚才引发异常的输入数据，或稍微修改一下，看看会不会导致出错。尝试运行其他一些要调用该函数的测试用例，看看会发生什么情况。
      4）常规输入和非常规输入
      例如：和Ctrl、Alt、Esc按键组合的字符，操作系统、编程语言、浏览器和运行时环境的特定保留词或按键。
      5）使用输出来指导输入选择
      ①首先确定希望程序产生的输出结果，然后考察所有用户场景，来确定输入；
      ②先观察输出结果，再选择新的输入，使新的输出为重新计算后的结果。
2、状态
      软件的一个状态就是状态空间中的一个点，它由所有内部数据结构的取值来唯一确定。
      ①使用状态信息来帮助寻找相关的输入，如果两个或更多个输入在某种程度上关联，那么它们应该放在一起测；
      ②使用状态信息来辨识重要的输入序列，当一个输入导致状态信息被更新时，紧接着再多次使用同样的输入会导致一连串的状态变化。
      例如，对数据库中的表进行多次更新，查看数据是否会溢出。
3、代码路径
      测试需明确知道代码的所有选择结构，并理解哪些输入会导致软件走这条分支而不走另一条。
4、用户数据
     ①如何模仿真实的用户数据
     ②使用真实的用户数据时，应考虑如何解决“隐私问题”。
5、执行环境
     是指测试使用的操作系统及其当前的配置，还包括运行在同一操作系统上会和被测试软件进行交互的其他一些应用程序，以及会间接或直接影响被测试软件本身或影响被测试软件运行的任何驱动程序、代码、文件、设置等，还包括软件当前连接的网络情况、网络的可用带宽、性能等。

二、全局探索式测试法（漫游测试）

    在软件测试中，我们可以把整个测试过程比喻成游客在城市中旅游的过程，测试类型对应城市中的不同区域，针对每个区域制定不同的游览路线。以下将结合实际测试过程中的案例，来简单阐述全局探索式测试法的应用。
1、商业区测试类型（软件的重要功能模块）
    1）指南测试法：
    测试严格遵照用户手册的建议执行操作。在测试一个全新的软件之前，测试人员需要详细阅读需求文档或使用手册，积极与开发人员沟通以充分了解产品功能；在测试产品的新版本之前，查看jira中的新特性描述、新的需求文档以及之前版本存在bug的用例。
    2）地标测试法：
通过指南测试法确定关键的软件特性（地标），再确定地标的前后顺序，然后从一个地标执行到另一个地标来探索应用程序，直到访问了所有的地标。在这个过程中，需要记录已经使用过哪些地标。
    例如，在BC-ETL的某次测试过程中，需要测试数据流中的多个流程，此时每个流程都作为一个地标，通过多次调换、添加或删除流程的来测试整个数据流能否顺利执行。

    3）极限测试法
    也称找麻烦测试法，即故意设置各种障碍来观察软件如何反应。
    例如，在罗网项目某次迭代中，测试基站查询模块，选择使用基站名称查询，在搜索框中输入覆盖范围很大的区域名称（如：南通）进行查询，页面因加载时间过长导致卡死。

     4）深夜测试法：当下班之后软件执行各种维护任务，将数据归档，备份文件等，程序不自动执行的时候，测试人员强制程序执行。
2、历史区测试类型
    历史区：指遗留的代码，或是在前几个版本就已经存在的软件特性，也指那些用于修复已知bug的代码。
    1）恶邻测试法：某个区域代码bug很多，建议对邻近区域进行详细的测试，以此来验证那些修复已知bug的代码没有引入新的缺陷。
    2）博物馆测试法：找出遗留代码和老的可执行文件，并确保它们在测试中受到和新代码同样的待遇。在实际测试过程中，可以理解为对新版本中没有改动的功能进行回归冒烟测试。
    例如，在罗网项目的某次回归冒烟测试中，测试研判模型的多案时空碰撞模块，正确创建分析任务，在任务列表中查看分析结果，页面右上角提示出错，无法查看。

3、娱乐区测试类型（辅助特性）
    1）配角测试法：鼓励测试专注于某些特定功能，特别是紧邻主要功能的辅助功能。
    罗网项目的主要功能为通过研判模型对各类案件及人员进行分析，然而每次审批几乎都离不开新建工单的过程，所以测试时对研判模型的每个模块都增加了许多新建工单的用例。

    2）通宵测试法：即使程序长时间运行，不去关闭，观察程序是否会发生异常。
4、旅游区测试类型（快速访问软件的各种功能）
    1）收藏家测试法：收集软件的输出，越多越好。确保能观察到软件能生成的任何一个输出。此方法庞大，通常以小组为单位进行。
    例如，在广西上网行为分析项目中，为确保接收到的数据格式和内容都正确，需提前造出大量用户数据，模拟实际的运行环境批量发送数据，批量查看输出结果。
    3）超模测试法：只测试界面显示。
    例如，在采购部供应链大数据平台的某次测试中，由于前端页面没有设置按比例缩放，导致页面在小屏幕上无法显示完全。

5、旅馆区测试类型（经常被忽略或者在测试计划中较少描述的次要及辅助功能）
    1）取消测试法：启动操作然后停止它。可以对任何提供取消功能或者需要较长时间才能完成的功能做同样的操作。如果没有取消按钮，对于在浏览器中运行的程序可以试着按Esc键或是程序中的回退按钮。
    2）懒汉测试法：测试人员做尽量少的实际工作。接受所有默认值，保持输入字段继续为空，在表单中尽可能少填数据，在进入下一个界面时不点击任何按钮或者输入任何数据等等。
    传统的手工测试方法需要提前编写测试用例，然后严格地依次执行每一个用例，引入探索式测试方法可以在测试过程中更及时地发现问题并补充用例，两种方法相结合才能更有效地把控产品的质量。
    如果未来开发技术大幅进步，也许会有一天，测试人员不再是必需的了。这当然是软件厂商和用户的福音，但是在可预见的未来，检测软件缺陷的最好方法还是使用测试技术，而不是开发技术。原因很简单，太多的不确定因素，太多的场景，可能导致自动化测试失效的情况太多了，无法一一跟踪。这一切都需要“人脑”的介入，现在如此，下个十年不会变，再过几十年可以依然如此。

版权声明 (原创)：本文内容由移动云用户自发贡献，版权归原作者所有，移动云开发者社区不拥有其著作权，亦不承担相应法律责任。如果您发现本社区有涉嫌抄袭的内容，可填写举报信息，一经查实，本社区将立刻删除涉嫌侵权内容。

说明：该篇博客是博主一字一码编写的，实属不易，请尊重原创，谢谢大家！
接着上一篇博客继续往下写 ：https://blog.csdn.net/qq_41782425/article/details/103602467

一、测试方法的分类

• 静态测试方法

• 动态测试方法

1.静态测试方法

• 不执行程序的测试方法。

• 主要用于测试文档和代码（文档）。

2.动态测试方法

• 通过运行程序来发现缺陷的测试方法。
  √     黑盒测试方法
  √     白盒测试方法

2.1黑盒测试

• 也称为功能测试、数据驱动测试、基于规格说明书测试。
  

• 从用户观点出发，主要以软件规格说明书为依据，对程序功能和接口进行测试，对
  输入输出数据之间的对应关系进行测试。

• 它不涉及到程序的内部结构，如果外部特性本身有问题或规格说明书有问题，则无
  法察觉。
  √     安全性测试、互操作性测试也属于功能测试。
  √     方法如大纲法、场景法、等价类、边界值、决策表、错误猜测等。

• 黑盒测试方法还用于测试软件的非功能性特性。
  √     非功能测试用于测试系统工作的怎么样，包括但不限于
         ✰     可用性/可靠性/稳定性/健壮性/可恢复性测试
         ✰     可维护性测试
         ✰     易用性测试
         ✰     可移植性/兼容性测试
         ✰     配置测试
         ✰     文档测试
         ✰     国际化测试/本地化测试
  √     当不涉及程序内部结构时，上述测试类型也使用黑盒测试方法。

2.2白盒测试

• 也称结构测试、逻辑驱动测试、基于程序本身的测试、程序员测试。
  
• 结构测试需要完全了解程序结构和处理过程，按照程序内部逻辑测试程序，检验程
  序中每条通路是否按照预定要求工作。

2.3黑盒测试与白盒测试的区别

二、静态测试方法

静态测试方法包括评审和静态分析方法。

1.评审

1.1评审的含义、过程和目的

1.2评审的角色

1.3评审的分类

• 文档审查
• 代码审查
• 代码走查

1.4代码审查

1.4.1代码审查的含义、过程和目的

1.4.2代码审查的方法和范围

• 具体做法方法
  √     互查
• 通常合格的代码应具备正确性、清晰性、规范性、一致性和高效性，概括起来，
  代码审查的工作涵盖下列方面
  √     业务逻辑的审查
  √     算法的效率
  √     代码风格
         ✰     if（1j）与 if（j1），问：以上哪种代码风格较好？
         ✰     if（j>MAX_NUM）与 if（j>2000），哪个好？
  √     编程规则

1.5 代码走查

2.静态分析方法

2.1数据流分析

• 使用了未声明/定义的变量
• 变量声明了没有使用

2.2控制流分析

2.3复杂度分析

• 复杂度分析给出一组能描述程序代码的复杂度特征的度量。
  
• 计算复杂度
  
  复杂度为：边（17）- 点（13）+ 2 = 6

3.静态测试的意义

4.静态测试可以发现的缺陷

• 引用一个没有定义值的变量；
• 从未使用的变量；
• 模块和组件之间接口不一致；
• 不可达代码（unreachable code）或死代码（dead code）；
• 违背编程规则；
• 安全漏洞；
• 代码和软件模型的语法错误等。

5.一些静态分析工具

[OSS]代表开源软件，[PROPRIETARY]代表付费软件。

三、白盒测试方法

1.单元测试用例的设计方法

• 白盒测试方法
• 黑盒测试方法
• 以白盒测试方法为主，并适当地结合黑盒测试方法

2.白盒测试方法

• 逻辑覆盖法
  √     语句覆盖
  √     判定覆盖
  √     条件覆盖
  √     判定-条件覆盖
  √     条件组合覆盖

• 路径覆盖法

3.白盒测试方法的步骤

3.1获得需求、获得/画出程序流程图/算法图

3.2画出控制流图

• 根据需求来画
• 根据算法图/流程图来画
• 弄清预期结果
  

3.3选择覆盖方法设计测试用例

3.3.1语句覆盖法 C0

• 目标
  √     程序中的每个可执行语句至少被执行一次。

• 度量（覆盖率）
  √     被执行的语句数/所有可能的语句数。
  √     被执行的路径数/所有可能的路径数。
  

• 用例
  √     a=2，b=1，c=6
  √     用例对语句的覆盖率：100%
  √     用例对路径的覆盖率：25%

• 语句覆盖能发现语句错误
  

• 语句覆盖不能发现逻辑错误/条件错误
  

3.3.2 分支/判定覆盖 C1

• 目标
  √     程序中的每个判定的取真分支和取假分支至少执行一次。
  

• 用例
  √     a=2，b=1，c=6
  √     a=-1，b=1，c=1
  √     用例对语句的覆盖率：100%
  √     用例对路径的覆盖率：50%

• 分支/判定覆盖能发现逻辑错误
  

• 分支/判定覆盖不能发现组合判断中的条件错误
  

3.3.3 条件覆盖 C2

• 目标
  √     程序每个判定中每个条件的可能取值至少满足一次。
• 未必比 C1 更全面。
• 不能发现逻辑错误。
  
• 用例
  
• 思考：覆盖率？

3.3.4 判定-条件覆盖 C1+C2

• 目标
  √     每个条件中的所有可能取值至少执行一次，同时，每个判定的可能结果至少执行一次。

• 可能会导致某些条件掩盖了另一些条件。
  

• 用例
  

3.3.5 条件组合覆盖/多条件覆盖 C3

• 目标
  √     每个判定中的所有的条件取值组合至少执行一次。

• 比 C2 全面。
  

• 用例
  

3.3.6 路径覆盖 C4

• 目标
  √     用例覆盖程序中的所有可能的执行路径。

• 不切实际
  √     因为涉及到相当长和几乎无穷尽的路径数。
  √     任何可能的循环在程序段中都被视为是可能的路径。

• 用例
  

• 路径覆盖优化
  √     McCabe 的基路径方法
  
  √     从源节点到汇节点的线性独立路径数（根据圈复杂度计算）
         ✰     V（G）=e-n+2p=10-7+2=5
         ✰     当规模很小时，我们可以直观地标识独立路径。
  √     以下给出的是用节点/边序列表示的路径：
         ✰     p1：A,B,C,G/1，4，9
         ✰     p2：A,B,C,B,C, G/1,4,3,4,9
         ✰     p3：A,B,E,F,G/1,5,8,10
         ✰     p4：A,D,E,F,G/2,6,8,10
         ✰     p5：A,D,F,G/2,7,10

• 案例
  

四、白盒测试工具

• 内存资源泄漏检查工具
  √     如 Numega 中的 BounceChecker，Rational 的 Purify 等；

• 代码覆盖率检查工具
  √     如 Numega 的 TrueCoverage ， Rational 的 PureCoverage ， TeleLogic 公司的 Logiscope;

• 代码性能检查工具
  √     如 Logiscope 和 Macabe 等。

• 静态源代码分析工具
  √     类似于编译器，能够检查源代码，发现违反编程语言语法规则和大量定义编程规范的代码。

面试题：

答案：

• 语句覆盖：
  √     要求：A<5 & B=5 & A=2 | X>2
  √     用例：A=2，B=5，X=3（此时X=多少都无所谓，因为A=2已经满足了条件）

• 判定覆盖
  √     要求：
                  A<5 & B=5 对一次，错一次
                  A=2 | X>2 对一次，错一次
  √     用例：
                  A=2，B=5，X=3
                  A=6，B=6，X=1

• 条件覆盖
  √     要求：
                  A<5 对错各一次
                  B=5 对错各一次
                  A=2 对错各一次
                  X>2 对错各一次
  √     用例：
                  A=2，B=5，X=3
                  A=6，B=6，X=1

• 判定-条件覆盖
  √     要求：
                  A<5 对错各一次
                  B=5 对错各一次
                  A<5 & B=5 对一次，错一次
                  A=2 对错各一次
                  X>2 对错各一次
                  A=2 | X>2 对一次，错一次
  √     用例：
                  A=2，B=5，X=3
                  A=6，B=6，X=1

• 多条件覆盖
  √     要求：
                  A<5对，B=5对
                  A<5对，B=5错
                  A<5错，B=5对
                  A<5错，B=5错
                  A=2对，X>2对
                  A=2对，X>2错
                  A=2错，X>2对
                  A=2错，X>2错
  √     用例：
                  A=2，B=5，X=3
                  A=6，B=6，X=1
                  A=2，B=6，X=1
                  A=6，B=5，X=3

• 路径覆盖
  √     要求：
                  A<5 & B=5 对，A=2 | X>2 对
                  A<5 & B=5 对，A=2 | X>2 错
                  A<5 & B=5 错，A=2 | X>2 对
                  A<5 & B=5 错，A=2 | X>2 错
  √     用例：
                  A=2，B=5，X=3
                  A=6，B=6，X=1
                  A=2，B=6，X=1
                  A=4，B=5，X=1

• 最终的用例：（按照一条用例尽可能多的去覆盖其他测方法）
  A=2，B=5，X=3
  A=6，B=6，X=1
  A=2，B=6，X=1
  A=4，B=5，X=1
  A=6，B=5，X=3

五、使用 JUnit 进行单元测试

1.JUint 简介

• JUnit 是一个开放源代码的 Java 测试框架，用于编写和运行可重复的测试。

• JUnit 测试是程序员测试，即所谓白盒测试，是一个 Java 语言的单元测试框架，多数 Java 的开发环境都已经集成了 JUnit 作为单元测试的工具。

• JUnit 在极限编程和重构（refactor）中被极力推荐使用，因为在实现自动单元测试的情况下可以大大的提高开发的效率。

• 每编写完一个函数之后，都应该对这个函数的方方面面进行测试，这样的测试我们称之为单元测试。
  √     在编写大型程序的时候，需要写成千上万个方法或函数，也许我们在程序中只用到该函数的一小部分功能，并且经过调试可以确定，这一小部分功能是正确的。但是，我们同时应该确保每一个函数都完全正确，因为如果我们今后如果对程序进行扩展，用到了某个函数的其他功能，而这个功能有 bug 的话，那绝对是一件非常郁闷的事情。

2.JUnit 中的注解

• JUnit 使用注解进行单元测试。
  √     注解用于修饰测试方法或测试类，写在测试方法或测试类的前面。同时，使用这些注解时，需要导入相应的包。

• 比较重要的注解大致有 Fixture 注解、@Test 注解、@Ignore 注解、@Parameters 注解、@RunWith 注解。

2.1 Fixture 注解

• 表示“在某些阶段必然被调用的代码”。

• 一般包括@Before 注解、@After 注解、@BeforeClass 注解、@AfterClass 注解，这些注解一般用于修饰测试方法，测试方法名随意。

• @Before 注解
  √     @Before 修饰的方法在每个测试方法之前执行。

• @After 注解
  √     @After 修饰的方法在在每个测试方法之后执行。

• @BeforeClass 注解
  √     @BeforeClass 修饰的方法在所有测试方法执行之前执行。

• @AfterClass 注解
  √     @AfterClass 修饰的方法在所有测试方法执行之后执行。

2.2 @Test 注解

• @Test 注解
  √     用于修饰测试方法，表示要对被测试类的某个或某些方法进行测试。

• @Test(timeout=xxx)注解
  √     xxx 表示时间，以 ms 为单位；
  √     一般称为限时测试或超时测试，用于设置当前测试方法在一定时间内运行完，否则返回错误。
         ✰     对于那些逻辑很复杂，循环嵌套比较深的程序，很有可能出现死循环，因此一定要采取一些预防措施，限时测试是一个很好的解决方案，给测试函数或方法设定一个执行时间，超过了这个时间，程序就会被系统强行终止，并且系统还会汇报该函数结束的原因是因为超时，这样就可以发现这些Bug 了。

2.3 @Ignore 注解

• @Ignore 注解用于修饰测试方法，表示忽略测试用例；
• 其含义是“某些方法尚未完成，暂不参与此次测试”。这样的话测试结果就会提示你有几个测试被忽略，而不是失败。一旦你完成了相应函数，只需要把@Ignore 标注删去，就可以进行正常的测试。

2.4 @Parameters 注解

• 用于修饰产生数据集合的方法，用于参数化。
• 测试时，可能需要测试大量不同的路径，从而要使用大量的数据，使用@Parameters注解只需要编写一个测试代码即可众多数据进行多次测试。

2.5 @RunWith 注解

• 用于指定一个测试运行器（Runner），@RunWith 用来修饰类，而不能修饰函数。

• 要对一个类指定了 Runner，那么这个类中的所有函数都被这个 Runner 来调用。

• 常用的内置测试运行器有 Parameterized（参数化数据）和 Suite（测试集）。

3.JUnit 中的方法

3.1 断言

• 用来断定程序中是否存在缺陷。

• assertEquals(预期结果，实际结果)
  √     用于测试期望结果的断言，即测试两个对象是否相等，这个方法使用非常多。

• fail(错误消息内容)
  √     其中错误消息可选，假如提供，将会在发生错误时报告这个消息。该断言会使测试立即失败，通常用在测试不能达到的分支上（如异常）。

3.2 setUp 和 tearDown

说明： JUnit中的setUP和tearDown跟Python中的unittest框架的setUP和tearDown是一个道理；setUpBeforeClass和setUpAfterClass与setUpClass和tearDownClass同理

• 在实际的测试中我们测试某个类的功能是常常需要执行一些共同的操作，完成以后需要销毁所占用的资源（例如网络连接、数据库连接，关闭打开的文件等），JUnit提供了 setUp 方法、tearDown 方法、setUpBeforeClass 方法、tearDownAfterClass方法。

• setUp方法
  √     在每个测试方法之前都会运行。
  √     主要实现测试前的初始化工作。

• tearDown方法
  √     在每个测试方法结束以后都会执行。
  √     主要实现测试完成后的垃圾回收等工作。

• setUpBeforeClass方法
  √     在所有测试方法执行之前执行。

• tearDownAfterClass方法
  √     在所有测试方法执行之后执行。

• 实际使用时，setUp 方法可用@Before 注解代替，tearDown 方法可用@After 注解代替，setUpBeforeClass 方法可用@BeforeClass 代替，tearDownAfterClass 方法可用 @AfterClass 代替。