1 黑盒测试

1.1 黑盒测试概述

• 黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用；
• 把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性；
• 黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试；
• “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。

1.2 黑盒测试的使用场景

• 是否有不正确或遗漏了的功能
• 在接口上，能否正确地接受输入数据，能否产生正确地输出信息
• 访问外部信息是否有错
• 性能上是否满足要求
• 界面是否错误，是否不美观
• 初始化或终止错误

1.3 “黑盒”的两种基本方法

• 黑盒测试有两种基本方法，即通过测试和失败测试。
• 在进行通过测试时，实际上是确认软件能做什么，而不会去考验其能力如何。软件测试员只运用最简单，最直观的测试案例。
• 在设计和执行测试案例时，总是先要进行通过测试。在进行破坏性试验之前，看一看软件基本功能是否能够实现。这一点很重要，否则在正常使用软件时就会奇怪地发现，为什么会有那么多的软件缺陷出现？
• 在确信了软件正确运行之后，就可以采取各种手段通过搞“垮”软件来找出缺陷。纯粹为了破坏软件而设计和执行的测试案例，被称为失败测试或迫使出错测试。

1.4 黑盒测试的优缺点

1.4.1 优点

• 比较简单，不需要了解程序内部的代码及实现；
• 与软件的内部实现无关；
• 从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；
• 基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；
• 在做软件自动化测试时较为方便。

1.4.2 缺点

• 不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%；
• 自动化测试的复用性较低。

1.5 黑盒测试的测试用例设计方法

• 等价类划分方法
• 边界值分析方法
• 错误推测方法
• 因果图方法
• 判定表驱动分析方法
• 功能图分析方法

2 白盒测试

2.1 白盒测试概述

• 白盒测试并不是简单的按照代码设计用例，而是需要根据不同的测试需求，结合不同的测试对象，使用适合的方法进行测试。
• 白盒测试与程序内部结构相关，需要利用程序结构的实现细节等知识，才能有效进行测试用例的设计工作。
• 白盒测试方法有程序控制流分析、数据流分析、逻辑驱动测试、域测试、符号测试、路径测试、程序插桩及程序变异等。

2.2 逻辑覆盖

包含语句覆盖、判定覆盖、条件覆盖、判定－条件覆盖、条件组合覆盖和路径覆盖。例：实现一个简单的数学运算

Dim a,b As Integer
Dim c As Double
If (a>0 And b>0) then
  c=c/a
End if
If (a>1 or c>1) Then
    c=c+1
End if
 c=b+c

由这个流程图(b)可以看出，该程序模块有4条不同的路径：

P1:(1-2-4)     P2:(1-2-5)
P3:(1-3-4)     P4:(1-3-5)

将里面的判定条件和过程记录如下：

条件M＝{a>0 and b>0}
条件N={a>1 or c>1}

这样，程序的4条不同路径可以表示为：

P1:(1-2-4)=M and N      P2:(1-2-5)=~M and N
P3:(1-3-4)=M and ~N     P4:(1-3-5)=~M and ~N

2.3 语句覆盖

2.3.1 基本思想是

设计若干测试用例，运行被测程序，使程序中每个可执行语句至少执行一次。
上面的例题，P1包含了所有可执行语句，按照语句覆盖的测试用例设计原则，可以使用P1来设计测试用例，如下：。

令a=2,b=1,c=6,此时满足条件M{a>0 and b>0}和条件N={a>1 or
c>1}（注：此时c=c/a=3），这样，测试用例的输入{a=2,b=1,c=6}和对应的输出{a=2,b=1,c=5}覆盖路径P1。

2.3.2 优点

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

2.3.3 缺点

此测试方法仅针对程序逻辑中显式存在的语句，但对于隐藏的条件和可能到达的隐式逻辑分支，是无法测试的。如在Do-While结构中，语句覆盖执行其中某一个条件分支。语句覆盖对于多分支的逻辑运算也是无法全面反映的，它只在乎运行一次，而不考虑其他情况。

2.4 判定覆盖

2.4.1 基本思想

设计若干测试用例，运行被测程序，使得程序中每个判断的取真分支何取假分支至少经历一次，即判断真假值均曾被满足。
p1和p4可以作为测试用例，其中p1作为取真的路径，p4作为取反的路径。

2.4.2 优点

判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。

2.4.3 缺点

判定语句是由多个逻辑条件组合而成（如，判定语句中包含AND、OR、CASE），若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。

2.5 条件覆盖

2.5.1 基本思想

设计若干测试用例，执行被测程序以后要使每个判断中每个条件的可能取值至少满足一次。

对于M：a>0取真时T1，取假时F1;
b>0取真时T2，取假时F2；

对于N：a>1取真时T3，取假时F3;
c>1取真时T4，取假时F4。

根据条件覆盖的基本思路，和这8个条件取值，组合测试用例：

2.5.2 优点

条件覆盖比判定覆盖，增加了对符合判定情况的测试，增加了测试路径。

2.5.3 缺点

要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。

2.6 判定－条件覆盖

2.6.1 基本思想

设计足够的测试用例，使得判断条件中的所有条件可能至少执行一次取值，同时，所有判断的可能结果至少执行一次。
应该至少保证判定条件M和N各取真/假一次，同时要保证8个条件取值至少执行一次：

2.6.2 优点

判定/条件覆盖满足判定覆盖准则和条件覆盖准则，弥补了二者的不足。

2.6.3 缺点

判定/条件覆盖准则的缺点是未考虑条件的组合情况。

2.7 条件组合覆盖

2.7.1 基本思想

设计足够的测试用例，使得判断中每个条件的所有可能至少出现一次，并且每个判断本身的判定结果也至少出现一次。

针对以上8种条件组合，来设计所有能覆盖这些组合的测试用例：

2.7.2 优点

多重条件覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。更改的判定/条件覆盖要求设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身的所有可能结果也至少出现一次。并且每个条件都显示能单独影响判定结果。

2.7.3 缺点

线性地增加了测试用例的数量。

2.8 路径覆盖

2.8.1 基本思想

设计所有的测试用例，来覆盖程序中的所有可能的执行路径：

2.8.2 优点

这种测试方法可以对程序进行彻底的测试，比前面五种的覆盖面都广。

2.8.3 缺点

由于路径覆盖需要对所有可能的路径进行测试（包括循环、条件组合、分支选择等），那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长。而在有些情况下，一些执行路径是不可能被执行的，如：

If  （A）B++；
　　If  （!A）D--；

这两个语句实际只包括了2条执行路径，即A为真或假时候对B和D的处理，真或假不可能都存在，而路径覆盖测试则认为是包含了真与假的4条执行路径。这样不仅降低了测试效率，而且大量的测试结果的累积，也为排错带来麻烦。

从前面的例子我们可以看到，采用任何一种覆盖方法都不能满足我们的要求，所以，在实际的测试用例设计过程中，可以根据需要和不同的测试用例设计特征，将不同的覆盖方法组合起来使用，以实现最佳的测试用例设计

采用条件组合和路径覆盖两种方法结合重新来设计测试用例：

---

【特别说明】：知识来源于网络、各种资料、书本、网站等，本文仅用于学习使用，不做他用，如果涉及版权问题，请联系博主删除，谢谢