软件测试之测试策略：黑盒和白盒

软件测试策略：黑盒测试和白盒测试

1. 基本概念

测试，是通过运行代码的方式来检验程序和需求的符合性。不管我们使用什么样的测试策略，最终都是需要运行一个个测试用例，检验合理性。个人认为，黑盒和白盒，更多是两种不同的设计测试用例的思想。

1.1 什么叫做黑盒测试？

黑盒测试，是争对功能性的测试，又叫做功能测试。
基本思想就是黑箱思想，将我们的代码模块看作一个只有输入、输出，而忽略其内部的具体实现和代码逻辑的黑匣子。通过判断输入和输出的对应关系是否合理，达到功能测试的结果。
从测试阶段来看，我们在系统的模块测试，集成测试，系统测试，验收测试这些阶段都会使用黑盒测试技术。一般测试人员都会使用黑盒测试策略来完成测试，这样可以不用阅读源代码。

1.2 什么叫做白盒测试

白盒测试是了解了代码的内部的实现，基于控制流来设计我们的测试用例。通常是使用覆盖测试的方法。具体方法我们下面会介绍。
最完备的测试应该尝试遍历代码块之间的每一条运行路径（可以理解为执行的顺序），但是这个数据往往会比较庞大，我们就基于一些理论，思想，从这些路径中筛选出最有效的一些路径来测试。这些方法，就是我们下面介绍的白盒测试的一些设计方法。
白盒测试一般在我们进行单元测试的时候使用！一般建议有程序员来完成这个测试工作，因为程序员对于程序了解更多。这样能够节省阅读代码的时间。

2. 黑盒测试的设计方法

2.1 划分法

划分法，又叫做等价类划分法。是将输入划分为多个区域（等价类），每个类中选择一个代表性输入作为测试用例，因为其是一个等价类，所以一个测试用例代表了这一类输入，以较少的测试用例达到尽可能好的测试效果。

以等价类的效果，我们定义了两种等价类
有效等价类：有效，输入是有效的，用于验证功能实现的正确性
无效等价类：输入是无效的，用于验证模块对于非法输入的处理，可以说是验证系统的鲁棒性。

确定等价类的原则：
a. 取值范围或取值个数：确定一个有效等价类和两个无效等价类。例如：输入 a 要求 1-20 之间，那么一个有效等价类 1-20，两个无效等价类， <1 和 >20
b. 输入值的集合和必须条件：一个有效和一个无效。
c. bool 变量：一个有效和一个无效
d. 继续细分等价类
e. 多个输入从输入的单个要求去分析，也要从输入量之间的关系去分析

基于等价类设计测试用例：

给等价类编号
设计一个测试用例，尽可能多的包含有效等价类。重复这个步骤，直到所有的有效等价类被覆盖。（为什么要尽可能多？第一，减少测试用例的数量，第二，有的有效等价类不覆盖，这个测试用例的就是用于验证非法的输入的测试用例了。如账号长度等。当然也有一些是无法一次性覆盖的，例如可以有数字，那是不是对有数字和无数字都得考虑呢？）
设计一个测试用例，覆盖且仅覆盖一个无效等价类。（为什么只能有一个？多了你就无法判断争对具体非法输入的处理是否生效了）

2.2 边界值法

思想来源：实践总结中发现，很多缺陷，往往在边界值方面出现问题。所以在等价类划分的基础上，我们加上边界值分析法（选取等价类的边界）来确定测试用例。
？问题：边界值的设计，是否要考虑无效等价类，还是对有效等价类的边界细分。这个是都有必要考虑的。
通常一次只选取一个边界来考虑
健壮性的边界值法：这种边界值考虑，不仅需要考虑合法的边界，同样对于边界的非合法的值也需要设计测试用例。
举例说明不同之处：
一般的边界值：对于 a>= 0 需要考虑 a=0,a=1 的情形
健壮性的边界值：对于上面的例子，还需要考虑 a=-1的情形。

2.3 决策表法

列举所有可能的条件，然后列举条件组合和对应的输出结果。将其整理为表格，设计测试用例。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
如何理解这四个项：
条件桩：一般是量的分类
动作桩：一般是所有动作，不可能动作的列举
条件项：是变量与具体条件的对应表
动作项：是条件与动作的对应表
规则：这个是条件项与动作项对应关系的说明
从竖向来看，一列条件项对应了一个满足条件的输入，其对应的动作项表示对该输入的输出。

我们由此得到一个步骤去得到我们的决策表：

列举所有条件桩、动作桩
确定规则的个数
填入条件项、填入输出项
合并简化
需要说明的是合并和简化的一些方法：一般来说是条件具有某种相似性，而动作是一致的。

3. 白盒测试方法

上面已经介绍了白盒测试的基本概念和白盒测试设计方法的基本思想。下面具体介绍设计方法。

3.1 路径覆盖

为什么最先谈这个往往放在最后的设计方法呢？个人认为这个方法能够比较好体现了白盒测试的思想。
路径覆盖的基本思想：就是设计测试用例，用例要覆盖程序中的所有可能的执行路径。
如下面的程序，我们就需要针对每一条路径：
1->2->3 ->4->5
1->3->4->5
1->2->3->5
1->3->5
都设计一个测试用例

优点：这种测试方法能够进行彻底的测试，覆盖范围是文中介绍的几种中最广的（是不是所有最广的没有研究）。
缺点：缺点也是显而易见的，就是测试用例数量会无比庞大，当然这个例子看不出来，如果我们在这个例子外面加上一个20次的循环有感触了，可以计算一下。

下面的介绍就从最简单的开始，介绍我们达不到覆盖所有路径的情况下使用什么样的测试方法呢？

3.2 语句覆盖（SC）

最简单，最弱的覆盖。要求：每个代码行至少执行一次。
这个方法优缺点很明确，优点是很简单，缺点就是太过简单了，没有太多测试的效果。

double test(double a, double b){if(b == 0){b++;}if(a == 1){a++;}return 1;
}

上面的代码啊，只需要一个测试用例就可以完成语句覆盖。{1,0}.

3.3 判定覆盖(DC)

从这个方法开始我们开始考虑这个逻辑关系了。判定覆盖要求：每个分支语句（通常if嘛）得每个分支都得运行一遍。
对于语句覆盖中的例子，进行判定覆盖就没法一个测试用例搞定了。至少得两个。{1，0} : 两个判定都为true, {0,1}:两个判定都为false。这样就完成的判定覆盖。
也还是很简单的能够完成设计，但是其力度还是太弱了，测试效果不佳。

3.4 条件覆盖(CC)

上述的判定覆盖只是对分支语句的一个路径的覆盖，确保每个分支都会运行一次。然而，对于分支的判定语句中有多个条件的话，那么可能很多条件都是没有考虑过的。

if( a>1 && c>2 || d>3){}

例如上面的，判定覆盖可以是{2，3，1}，{1，3，1}.但是这三个条件只有 a>1这个条件发生了改变。我们希望能够覆盖每个条件。
所以，条件覆盖**要求：**每个条件的可能取值都要取一次。
其实我们可以看出，条件覆盖一般来说两个测试用例就可以完成了，一个全真，一个全假。而且条件覆盖和判定覆盖不是一个包含关系，意味着我们满足了条件覆盖，不一定就满足分支覆盖。如上面的例子。取{2，3，2}，{1，1，4}. 这个是条件覆盖了，但是不是判定覆盖。

3.5 判定-条件覆盖(C/DC)

结合判定和条件覆盖的要求，每个分支都需要执行到，且每个条件的true 和false 取值也要覆盖到。

3.6 修正的判定-条件覆盖（MC/DC）

这个是在判定和条件覆盖基础上进一步增强。在判定和条件的基础上，证明每个条件都能够单独影响判定的结果。（意味，在其他条件不变的情况下，改变这个条件，能够改变判定结果）
继续使用条件覆盖中的例子：如果我们取{2,3,4},{0,0,0}就完成了一个判定条件覆盖，每个条件的可能取值都取到了，每个分支都执行到了。但是这个不是修正的判定-条件覆盖。对吧！
我们可以尝试以下：将测试1中a的值由2改变为0，条件取值改变，但是整个判定没有改变，继续尝试后面的和第二个测试用例，我们发现，这两个用例没有证明每个条件都能够单独影响结果啊！

那么修正的条件覆盖应该是什么样的：{0，3，0}，{0，3，1}，这两个对比说明了d的取值条件能够单独影响结果。然后{2，3，0}，{2，0，0}

3.7 条件组合覆盖

需要所有条件的可能取值的组合至少执行一次。这个比较好理解，就不多写了。