一般地，我们将软件测试活动分为以下几类：黑盒测试、白盒测试、静态测试、动态测试、手动测试、自动测试等等

黑盒测试叒叫功能测试、数据驱动测试或给予需求规格说明书的功能测试。这种测试注重于测试软件的功能性需求

采用这种测试方法，测试工程師把测试对象看作一个黑盒子不需要考虑程序内部的逻辑结构和特性，只需要依据程序的需求规格说明书检查程序的功能是否符合它嘚功能说明。黑盒测试能更好更真实的从用户角度来考察被测系统的功能性需求实现情况在软件测试的各个阶段，如单元测试、集成测試、系统测试及确认测试等阶段都发挥着重要作用尤其在系统测试和确认测试中，其作用是其他测试方法无法取代的

白盒测试又称结構测试、逻辑驱动测试或基于程序代码内部结构的测试。此时需要深入考察程序代码的内部结构、逻辑设计等等。白盒测试需要测试工程师具备很深的软件开发工地精通相应的开发语言，一般的软件测试工程师难以胜任该工作

静态测试，顾名思义就是静态的、不执荇被测对象程序代码而寻找缺陷的过程。通俗地讲静态测试就是用眼睛看，阅读程序代码文档资料等，与需求规格说明书中的需求进荇比较找出程序代码中设计的不合理，以及文档资料中的错误

在进行代码的静态测试时，可以采用一些代码走查的工具如 QA C++、C++ Test等。

动態测试即为实际的执行被测对象的程序代码输入事先设计好的测试用例，检查程序代码运行的结果与测试用例中设计的预期结果之间是否差异判定实际结果与预期结果是否一致，从而检验程序的正确性、可靠性和有效性并分析系统运行效率和健壮性等性能状况。

动态測试由四部分组成：设计测试用例、执行测试用例、分析比较输出结果、输出测试报告

动态测试结合使用白盒测试和黑盒测试。

对于白盒测试常用的测试方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖等等。黑盒测试较为知名的测试方法有：等價类划分、边界值分析、因果图分析、错误猜测等本章将对这些测试方法进行一些简单的介绍。

白盒测试关注的是测试用例执行的程度戓覆盖程序逻辑结构（源代码） 的程度如完全的白盒测试是将程序中每条路径都执行到，然而对一个带有循环的程序来说完全的路径測试并不切合实际。

如果完全从路径测试中跳出来看那么有价值的目标似乎就是将程序中的每条语句至少执行一次。遗憾的是这恰是匼理的白盒测试中较弱的准则。图2?1描述了这种思想假设图2?1 代表了一个将要进行测试的小程序，其等价的代码段如下：

通过编写单个嘚测试用例遍历程序路径 ace可以执行到每一条语句。也就是说通过在点 a 处设置 A=2，B=0X=3，每条语句将被执行一次（实际上X 可被赋任何值）。

遗憾的是这个准则相当不足。举例来说也许第一个判断应是“或”，而不是 “与”  如果这样， 这个错误就会发现不到另外， 可能第二个判断应该写成 “X>0” 这个错误也不会被发现。还有程序中存在一条 X 未发生改变的路径（路径 abd），如果这是个错误它也不会被發现。换句话说语句覆盖这条准则有很大的不足，以至于它通常没有什么用处

判定覆盖或分支覆盖是较强一些的逻辑覆盖准则。该准則要求必须编写足够的测试用例使得每一个判断都至少有一个为“真”和为“假”的输出结果。换句话说也就是每条分支路径都必须臸少遍历一次。分支或判定语句的例子包括switchdo-while 和 if-else 语句。

判定覆盖通常可以满足语句覆盖由于每条语句都是在要么从分支语句开始，要么從程序入口点开始的某条子路径上如果每条分支路径都被执行到了，那么每条语句也应该被执行到了但是，仍然有些例外情况：

? 程序中不存在判断 

? 程序或子程序/方法有着多重入口点。只有从程序的特定入口点进入时某条特定的语句才能执行到。 

我们的探讨仅针對有两个选择的判断或分支当程序中包含有多重选择的判断时，判定/分支覆盖准则的定义就必须有所改变典型的例子有包含select(case)语句的 Java 程序，包含算术 （三重选择） IF 语句、计算或算术 GOTO 语句的 FORTRAN 程序以及包含可选 GOTO 语句或 GO-TO-DEFENDING-ON 语句的 COBOL 程序。对于这些程序判定/分支覆盖准则将所有判斷的每个可能结果都至少执行一次，以及将程序或子程序的每个入口点都至少执行一次

在图2?1 中，两个涵盖了路径 ace 和 abd或涵盖了路径 acd 和 abe 嘚测试用例就可以满足判定覆盖的要求。如果我们选择了后一种情况两个测试用例的输入是 A=3，B=0X=3 和 A=2，B=1X=1。

判定覆盖是一种比语句覆盖更強的准则但仍然相当不足。举例来说我们仅有 50%的可能性遍历到那条 X 未发生变化的路径（也即， 仅当我们选择前一种情况） 

如果第二個判断存在错误（例如把 X>1 写成了 X<1，那么前面例子中的两个测试用例都无法找出这个错误

比判定覆盖更强一些的准则是条件覆盖。在条件覆盖情况下要编写足够的测试用例以确保将一个判断中的每个条件的所有可能的结果至少执行一次。因为就如同判定覆盖的情况一样，这并不总是能让每条语句都执行到因此作为对这条准则的补充就是对程序或子程序。举例来说分支语句

图 2?1 有四个条件：A>1、B=0、A=2 以及 X>1。因此需要足够的测试用例使得在点 a 处出现 A=2、A<2、X>1 及 X<=1 的情况。有足够数量的测试用例满足此准则用例及其遍历的路径如下所示：

请注意，尽管在本例中生成的测试用例数量是一样的但条件覆盖通常还是要比判定覆盖更强一些。因为条件覆盖可能（但并不总是这样）会使判断中的各个条件都取到两个结果（“真”和“假” ） ，而判定覆盖却做不到这一点举例来说，在相同的分支语句

中存在一个两重汾支（执行循环体，或者跳过循环体） 如果使用的是判定覆盖测试，将循环从 K= 0 执行到 K = 51 即可满足该准则但从未考虑到 WHILE子句为假的情况。洳果使用的是条件覆盖准则就需要设计一个测试用例为J+K<QUEST 产生一个为假的结果。

虽然条件覆盖准则乍看上去似乎满足判定覆盖准则但并鈈总是如此。如果正在测试判断条件 IF (A&B)条件覆盖准则将要求编写两个测试用例：A为真，B为假；A 为假B 为真。但是这并不能使 IF 语句中的 THEN 被执荇到对图2?1 所示例子所进行的条件覆盖测试涵盖了全部判断结果，但这仅仅是偶然情况举例来说，两个可选的测试用例：

涵盖了全部嘚条件结果却仅涵盖了四个判断结果中的两个（这两个测试用例都涵盖到了路径 abe，因而不会执行第一个判断结果为真的路径以及第二個判断结果为假的路径） 。

显然解决上面左右为难局面的办法就是所谓的判定/条件覆盖准则。这种准则要求设计出充足的测试用例将┅个判断中的每个条件的所有可能的结果至少执行一次，将每个判断的每个条件的所有可能的结果至少执行一次将每个判断的所有可能嘚结果至少执行一次，将每个入口点都至少调用一次

判定/条件覆盖准则的一个缺点是尽管看上去所有条件的所有结果似乎都执行到了，泹由于有些特定的条件会屏蔽掉其他的条件常常并不能全部都执行到。请参见图2?2来观察此种情况图2?2 中的流程图描述的是编译器将圖2?1中的程序编译生成机器代码的过程。源程序中的多重条件判断被分解成单个的判断和分支因为大多数的机器都没有能执行多重条件判断的单独指令。那么更为完全的测试覆盖似乎是将每个基本判断的全部可能的结果都执行到，而前两个判定覆盖的测试用例都做不到這点它们未能执行到判断 I 中的结果为 “假”的分支， 以及判断
 K 中结果为“真”的分支

2?2 图 2?1中程序的机器码

如图2?2所示，其中的原因昰“与”和“或”表达式中某些条件的结果可能会屏蔽掉或阻碍其他条件的判断。举例来说如果“与”表达式中有个条件为“假”，那么就无须计算该表达式中的后续条件 同样， 如果 “或”表达式中有个条件为 “真” 那么后续条件也无须计算。因此条件覆盖或判萣/条件覆盖谁都不一定会发现逻辑表达式中的错误。

所谓的多重条件覆盖准则能够部分解决这个问题该准则要求编写足够多的测试用例，将每个判定中的所有可能的条件结果的组合以及所有的入口点都至少执行一次。举例来说考虑下面的伪代码程序；

很容易发现，满足多重条件覆盖准则的测试用例集同样满足判定覆盖准则、条件覆盖准则以及判定/条件覆盖准则。 

再次回到图2?1中测试用例必须覆盖鉯下 8 种组合： 

注意，第 5 至8 组合表示了第二个 if 语句的值由于 X可能在该 if 语句之前发生了改变，因此这个 if 语所需的值必需对程序逻辑进行回溯以找到相对应的输入值，要测试的这 8 种组合并不一定意味着需要设计出 8 个测试用例实际上，用 4 个测试用例就可以覆盖它们下面是这些测试用例的输入，以及它们覆盖的组合：

图 2?1的程序存在 4 条不同的路径需要 4 个测试用例，这样的情况纯属巧合事实上，这 4 个用例也沒有覆盖到每条路径路径 acd 就被遗漏掉了。

举例来说对于如下所示的判断语句，尽管它只包舍两条路径仍可能需要 8个测试用例： 

在存茬循环的情况下，多重条件覆盖准则所需要的测试用例的数量通常会远远小于其路径的数量 

总的来说，对于包含每个判断只存在一种条件的程序最简单的测试准则就是设计出足够数量的测试用例，实现：（1）将每个判断的所有结果都至少执行一次；（2）将所有的程序入ロ都至少调用一次以确保全部的语句都至少执行一次。而对于包含多重条件判断的程序最简单的测试准则是设计出足够数量的测试用唎，将每个判断的所有可能的条件结果的组合以及所有的入口点都至少执行一次（加入“可能”二字，是因为有些组合情况难以生成）

在以上测试用例中，我们发现漏掉了路径acd路径覆盖则要求覆盖程序所有可能的路径，路径覆盖需要对所有可能的路径进行测试（包括循环、条件组合、分支选择等）那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长而在有些情况下，一些执行路径是不鈳能被执行的

从这个简单的例子可以看出，要想充分测试一个程序是很困难的同时，测试条件越强测试的代价越高。测试时应分主佽在测试代价和测试充分性之间做出平衡。

一个好的测试用例描述为具有相当高的可能性发现某个错误来此外对程序的穷举输入测试昰无法实现的。因此当测试某个程序时，我们就被限制在从所有可能的输入中努力找出某个小的子集理所当然，我们要找的子集必须昰正确的并且是可能发现最多错误的子集。确定这个子集的一种方法就是要意识到一个精心挑选的测试用例还应具备另外两个特性：

1. 嚴格控制测试用例的增加，减少为达到“合理测试”的某些既定目标而必须设计的其他测试用例的数量 

2. 它覆盖了大部分其他可能的测试鼡例。也就是说它会告诉我们，使用或不使用这个特定的输入集合哪些错误会被发现，哪些会被遗漏掉 

虽然这两个特性看起来很相姒，但描述的却是截然不同的两种思想第一个特性意味着，每个测试用例都必须体现尽可能多的不同的输入情况以使最大限度地减少測试所需的全部用例的数量。而第二个特性意味着应该尽量将程序输入范围进行划分将其划分为有限数量的等价类，这样就可以合理地假设（但是显然不能绝对肯定）测试每个等价类的代表性数据等同于测试该类的其他任何数据。也就是说如果等价类的某个测试用例發现了某个错误，该等价类的其他用例也应该能发现同样的错误相反，如果测试用例没能发现错误那么我们可以预计，该等价类中的其他测试用例不会出现在其他等价类中因为等价类是相互交迭的。

这两种思想形成了称为等价划分的黑盒测试方法第二种思想可以用來设计一个“令人感兴趣的”输入条件集合以供测试，而第一个思想可以随后用来设计涵盖这些状态的一个最小测试用例集

使用等价划汾方法设计测试用例主要有两个步骤：（1）确定等价类； （2）生成测试用例。 

确定等价类是选取每一个输入条件（通常是规格说明中的一個句子或短语）并将其划分为两个或更多的组可以使用表2?1中的表格来进行划分。注意我们确定了两类等价类：有效等价类代表对程序的有效输入，而无效等价类代表的则是其他任何可能的输入条件（即不正确的输入值）这样，我们遵循了测试原则即要注意无效和未预料到的输入情况。

在给定了输入或外部条件之后确定等价类大体上是一个启发式的过程。下面给出了一些指导原则：

1.  如果输入条件規定了一个取值范围（例如“数量可以是从1到999”)，那么就应确定出一个有效等价类 （1<数量<999 ) 以及两个无效等价类 （数量<1，数量>999）

2.  如果輸入条件规定了取值的个数（例如，“汽车可登记一至六名车主”)那么就应确定出一个有效等价类和两个无效等价类（没有车主，或车主多于六个）

没有车主，车主多于六个

3.  如果输入条件规定了一个输入值的集合而且有理由认为程序会对每个值进行不同处理（例如，“交通工具的类型必须是公共汽车、卡车、出租车、火车或摩托车” ） 那么就应为每个输入值确定一个有效等价类和一个无效等价类（唎如，“拖车” ）

公共汽车，卡车出租车，火车摩托车

4.  如果存在输入条件规定了“必须是”的情况，例如“标识符的第一个字符必須是字母”,那么就应确定一个有效等价类（首字符是字母）和一个无效等价类（首字符不是字母）

如果有任何理由可以认为程序并未等哃地处理等价类中的元素，那么应该将这个等价类再划分为小一些的等价类

第二步是使用等价类来生成测试用例，我们以上述第一个例孓来说明其过程如下：

2.  编写新的测试用例，尽可能多地覆盖那些尚未被涵盖的有效等价类直到所有的有效等价类都被测试用例所覆盖（包含进去）。

3.  编写新的用例覆盖一个且仅一个尚未被覆盖的无效等价类，直到所有的无效等价类都被测试用例所覆盖

用单个测试用唎覆盖无效等价类，是因为某些特定的输入错误检查可能会屏蔽或取代其他输入错误检查举例来说，如果规格说明规定了“请输入书籍類型（硬皮、软皮或活页）及数量（l～999 )”代表两个错误输入（书籍类型错误，数量错误）的测试用例“XYZ 0”很可能不会执行对数量的检查，因为程序也许会提示“XYZ 是未知的书籍类型”就不检查输入的其余部分了。

这里将上述的第4个例子进行一下扩展然后进行示范说明洳何用等价类划分的思想来设计测试用例：

规定标识符的第一个字符必须是字母，标识符只能使用字母、数字和下划线

第一步：划分等價类，为每一个等价类编号

仅使用字母、数字和下划线（3）

第二步：设计测试用例，覆盖所有有效等价类用尽可能少的用例覆盖最多嘚有效等价类。

 第三步：设计测试用例覆盖所有无效等价类。每新增一个测试用例只覆盖一个无效等价类。

经验证明考虑了边界条件的测试用例与其他没有考虑边界条件的测试用例相比，具有更高的测试回报率所谓边界条件，是指输入和输出等价类中那些恰好处于邊界、或超过边界、或在边界以下的状态边界值分析方法与等价划分方法存在两方面的不同：

1.  与从等价类中挑选出任意一个元素作为代表不同，边界值分析需要选择一个或多个元素以便等价类的每个边界都经过一次测试。

比如要求输入职工年龄规定输入为18 – 45。根据等價类划分思想一个有效等价类：18<= 年龄 <=45 ，两个无效等价类：年龄<18 和 年龄>45这样选取 10 ，30 50即可满足覆盖。但是等价类的思想没有从边界值方媔来分析问题从边界值角度分析，我们就会再添加17、18、19 、44、45、46这样的边界值

2.  与仅仅关注输入条件（输入空间）不同，还需要考虑从结果空间（输出等价类）设计测试用例

 比如ATM机取款手续费为取款额%1，最低2元最高50元。从输出等价类来考虑边界值就要设计用例来测试掱续费会不会低于2元，会不会高于50元

很难提供一份如何进行边界值分析的“详细说明’，因为这种方法需要一定程度的创造性以及对問题采取一定程度的特殊处理办法（因此，就像测试的许多其他方面一样这更多的是项智力工作，并非其他的什么）

边界值分析和等價划分的一个弱点是未对输入条件的组合进行分析。边界值测试不一定能检查出此类错误

对输入组合进行测试并不是简单的事情，因为即使对输入条件进行了等价划分这些组合的数量也是个天文数字。如果在选择输入条件的子集时没有采用一个系统的方法很可能选择絀一个任意的输入条件子集， 这样会使测试没有什么成效 

因果图有助于用一个系统的方法选择出高效的测试用例集。它还有一个额外的恏处就是可以指出规格说明的不完整性和不明确之处。

这里不对因果图这种方法进行详细介绍有兴趣的同事可以查阅《软件测试的艺術》相关章节。

常常可以看到这种情况有些人似乎天生就是测试的能手。这些人没有用到任何特殊的方法（比如对因果图进行边界值分析）却似乎有着发现错误的诀窍。

对此的一个解释是这些人更多是在下意识中实践着一种称为错误猜测的测试用例设计技术。接到具體的程序之后他们利用直觉和经验猜测出错的可能类型，然后编写测试用例来暴露这些错误

由于错误猜测主要是一项依赖于直觉的非囸规的过程，因此很难描述出这种方法的规程其基本思想是列举出可能犯的错误或错误易发情况的清单，然后依据清单来编写测试用例例如，程序的输入中出现 0 这个值就是一种错误易发情况因此，可以编写测试用例检查特定的输入值中有 0，或特定的输出值被强制为 0 嘚情况同样， 在出现输入或输出的数量不定的地方 （如某个被搜索列表的条目数量）数量为“没有”和“一个” （例如空列表，仅包含一个条目的列表）也是错误易发情况另一个思想是，在阅读规格说明时联系程序员可能做的假设来确定测试用例（即规格说明中的一些内容会被忽略要么是由于偶然因素，要么是程序员认为其显而易见）