白盒测试和黑盒测试

白盒测试和黑盒测试 目录 1.    软件测试基本分类    1 2.    测试方法    2 2.1    白盒测试    2 2.1.1    语句覆盖    2 2.1.2    判定（分支）覆盖    3 2.1.3    条件覆盖    3 2.1.4    判定/条件覆盖    4 2.1.5    多重条件覆盖    5 2.1.6    路径覆盖    7 2.2    黑盒测试    7 2.2.1    等价划分    7 2.2.2    边界值分析    9 2.2.3    因果图    10 2.2.4    错误猜测    10 软件测试基本分类 一般地，我们将软件测试活动分为以下几类：黑盒测试、白盒测试、静态测试、动态测试、手动测试、自动测试等等。 黑盒测试 黑盒测试又叫功能测试、数据驱动测试或给予需求规格书的功能测试。这种测试注重于测试软件的功能性需求。 采用这种测试方法，测试工程师把测试对象看作一个黑盒子，不需要考虑程序内部的逻辑结构和特性，只需要依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。黑盒测试能更好更真实的从用户角度来考察被测系统的功能性需求实现情况。在软件测试的各个阶段，如单元测试、集成测试、系统测试及确认测试等阶段都发挥着重要作用。尤其在系统测试和确认测试中，其作用是其他测试方法无法取代的。 白盒测试 白盒测试又称结构测试、逻辑驱动测试或基于程序代码内部结构的测试。此时，需要深入考察程序代码的内部结构、逻辑等等。白盒测试需要测试工程师具备很深的软件开发工地，精通相应的开发语言，一般的软件测试工程师难以胜任该工作。 静态测试 静态测试，顾名思义，就是静态的、不执行被测对象程序代码而寻找缺陷的过程。通俗地讲，静态测试就是用眼睛看，阅读程序代码，文档资料等，与需求规格说明书中的需求进行比较，找出程序代码中设计的不合理，以及文档资料中的错误。 在进行代码的静态测试时，可以采用一些代码走查的工具，如 QA C++、C++ Test等。 动态测试 动态测试即为实际的执行被测对象的程序代码，输入事先设计好的测试用例，检查程序代码运行的结果与测试用例中设计的预期结果之间是否差异，判定实际结果与预期结果是否一致，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能状况。 动态测试由四部分组成：设计测试用例、执行测试用例、分析比较输出结果、输出测试报告。 动态测试结合使用白盒测试和黑盒测试。 测试方法 对于白盒测试，常用的测试方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖等等。黑盒测试较为知名的测试方法有：等价类划分、边界值分析、因果图分析、错误猜测等。本章将对这些测试方法进行一些简单的介绍。 白盒测试 白盒测试关注的是测试用例执行的程度或覆盖程序逻辑结构 （源代码） 的程度。如完全的白盒测试是将程序中每条路径都执行到，然而对一个带有循环的程序来说，完全的路径测试并不切合实际。 图 21被测试的小程序 语句覆盖 如果完全从路径测试中跳出来看，那么有价值的目标似乎就是将程序中的每条语句至少执行一次。遗憾的是，这恰是合理的白盒测试中较弱的准则。图 21描述了这种思想。假设图 21 代表了一个将要进行测试的小程序，其等价的代码段如下： Public void foo(int a, int b, int x) { if (a > 1 && b == 0) { x = x / a; } if (a == 2 || x > 1) { X = x + 1; } } 通过编写单个的测试用例遍历程序路径 ace，可以执行到每一条语句。也就是说，通过在点 a 处设置 A=2，B=0，X=3，每条语句将被执行一次（实际上，X 可被赋任何值） 。 遗憾的是，这个准则相当不足。举例来说，也许第一个判断应是“或” ，而不是 “与” 。 如果这样， 这个错误就会发现不到。 另外， 可能第二个判断应该写成 “X>0” ，这个错误也不会被发现。还有，程序中存在一条 X 未发生改变的路径（路径 abd） ，如果这是个错误，它也不会被发现。换句话说，语句覆盖这条准则有很大的不足，以至于它通常没有什么用处。 判定（分支）覆盖 判定覆盖或分支覆盖是较强一些的逻辑覆盖准则。该准则要求必须编写足够的测试用例，使得每一个判断都至少有一个为“真”和为“假”的输出结果。换句话说，也就是每条分支路径都必须至少遍历一次。分支或判定语句的例子包括switch，do-while 和 if-else 语句。 判定覆盖通常可以满足语句覆盖。由于每条语句都是在要么从分支语句开始，要么从程序入口点开始的某条子路径上，如果每条分支路径都被执行到了，那么每条语句也应该被执行到了。但是，仍然有些例外情况： ?  程序中不存在判断。 ?  程序或子程序/方法有着多重入口点。只有从程序的特定入口点进入时，某条特定的语句才能执行到。 我们的探讨仅针对有两个选择的判断或分支，当程序中包含有多重选择的判断时，判定/分支覆盖准则的定义就必须有所改变。典型的例子有包含 select(case)语句的 Java 程序， 包含算术 （三重选择） IF 语句、 计算或算术 GOTO 语句的 FORTRAN 程序，以及包含可选 GOTO 语句或 GO-TO-DEFENDING-ON 语句的 COBOL 程序。对于这些程序，判定/分支覆盖准则将所有判断的每个可能结果都至少执行一次，以及将程序或子程序的每个入口点都至少执行一次。 在图 21 中，两个涵盖了路径 ace 和 abd，或涵盖了路径 acd 和 abe 的测试用例就可以满足判定覆盖的要求。如果我们选择了后一种情况，两个测试用例的输入是 A=3，B=0，X=3 和 A=2，B=1，X=1。 判定覆盖是一种比语句覆盖更强的准则，但仍然相当不足。举例来说，我们仅有 50%的可能性遍历到那条 X 未发生变化的路径 （也即， 仅当我们选择前一种情况） 。 如果第二个判断存在错误（例如把 X>1 写成了 X<1，那么前面例子中的两个测试用例都无法找出这个错误。 条件覆盖 比判定覆盖更强一些的准则是条件覆盖。在条件覆盖情况下，要编写足够的测试用例以确保将一个判断中的每个条件的所有可能的结果至少执行一次。因为，就如同判定覆盖的情况一样，这并不总是能让每条语句都执行到，因此作为对这条准则的补充就是对程序或子程序。举例来说，分支语句 DO K=0 to 50 WHILE (J+K50 （达到循环的最后一次迭代） 以及J+K=QUEST的情况设计测试用例。 图 21 有四个条件：A>1、B=0、A=2 以及 X>1。因此需要足够的测试用例，使得在点 a 处出现 A=2、A<2、X>1 及 X<=1 的情况。有足够数量的测试用例满足此准则，用例及其遍历的路径如下所示： 1．A=2，B=0，X=4  ace 2．A=1，B=1，X=1  adb 请注意，尽管在本例中生成的测试用例数量是一样的，但条件覆盖通常还是要比判定覆盖更强一些。因为，条件覆盖可能（但并不总是这样）会使判断中的各个条件都取到两个结果（ “真”和“假” ） ，而判定覆盖却做不到这一点。举例来说，在相同的分支语句 DO  K=0 to 50 WHILE (J+K