黑盒测试白盒测试
软件测试中，最常听到“黑盒测试”与“白盒测试”，它们是软件测试中最基本的测试方法。
那么究竟何为“黑盒”，何为“白盒”呢？下面就对其概念与常用方法进行一下介绍。
黑盒测试，白盒测试与灰盒测试的比较和区别如下所示：
| 黑盒测试 | 白盒测试 | 灰盒测试 |
|---|---|---|
| 不需要了解内部工作结构(代码)。测试用例只需要GUI(图形用户界面)。 | 测试需要了解内部工作结构(软件编码)。 | 部分了解内部工作结构。 |
| 黑盒测试也称为功能测试，数据驱动测试和封闭盒测试。 | 白盒测试也称为结构测试，透明盒测试，基于代码的测试和透明测试。 | 灰盒测试也称为半透明测试，因为测试人员对编码知识有限。 |
| 测试方法包括试验技术和错误猜测方法，因为测试人员不需要知道软件的内部编码。 | 通过验证软件中固有的系统边界和数据域来进行白盒测试，因为不缺乏内部编码知识。 | 如果测试人员具有编码知识，则通过验证软件的数据域和内部系统边界来进行。 |
| 输入表的测试空间(用于创建测试用例的输入)非常庞大，在所有测试空间中最大。 | 与黑盒测试相比，输入表的测试空间(用于创建测试用例的输入)较少。 | 输入表的测试空间(用于创建测试用例的输入)小于黑盒和白盒测试。 |
| 发现软件的隐藏错误非常困难，因为错误可能是由于黑盒测试未知的内部工作造成的。 | 发现隐藏错误很简单，因为它可能是由于内部工作，这在白盒测试中得到了深入探索。 | 很难发现隐藏的错误，可在用户级测试中找到。 |
| 它不适用于算法测试。 | 它非常适合并推荐用于算法测试。 | 它不被考虑用于算法测试。 |
| 黑盒测试中的时间消耗取决于功能规范的可用性。 | 由于冗长的代码，白盒测试需要很长时间来设计测试用例。 | 测试用例设计可以在短时间内完成。 |
| 测试人员，开发人员和最终用户可以参与测试。 | 只有测试人员和开发人员才能参与测试; 最终用户不能涉及。 | 测试人员，开发人员和最终用户可以参与测试。 |
| 这是所有测试过程中耗时最少的过程。 | 在所有测试过程中，整个测试过程是最耗时的。 | 比白盒测试耗时更少。 |
| 黑盒测试涵盖了抵御病毒攻击的弹性和安全性。 | 白盒测试不包括针对病毒攻击的弹性和安全性。 | 灰盒测试不包括针对病毒攻击的弹性和安全性。 |
| 黑盒测试的基础是外部期望内部行为未知。 | 灰盒测试的基础是编码，负责内部工作。 | 基于高级数据库图表和数据流图进行测试。 |
| 它不像白盒和灰盒测试方法那么详尽。 | 黑盒和灰盒测试方法之间最为详尽。 | 部分详尽; 取决于基于编码或基于GUI的测试用例的类型。 |
黑盒测试：
也称功能测试、数据驱动测试，它将被测软件看作一个打不开的黑盒，主要根据功能需求设计测试用例，进行测试。
概念：黑盒测试是从一种从软件外部对软件实施的测试，也称功能测试或基于规格说明的测试。其基本观点是：任何程序都可以看作是从输入定义域到输出值域的映射，这种观点将被测程序看作一个打不开的黑盒，黑盒里面的内容(实现)是完全不知道的，只知道软件要做什么。因无法看到盒子中的内容，所以不知道软件是如何实现的，也不关心黑盒里面的结构，只关心软件的输入数据和输出结果。
检测软件功能能否按照需求规格说明书的规定正常工作，是否有功能遗漏；
检测是否有人机交互错误，是否有数据结构和外部数据库访问错误，是否能恰当地接收数据并保持外部信息（如数据库或文件）等的完整性；
检测行为、性能等特性是否满足要求等； 检测程序初始化和终止方面的错误等。
优点：
① 与软件具体实现无关，如果软件实现发生了变化，测试用例仍可用；
② 设计黑盒测试用例可以和软件实现同时进行，因此可压缩项目总开发时间。
黑盒测试常用方法
等价类划分
边界值分析
因果图
决策表分析
等价类划分
完全不考虑程序的内部结构，只根据程序规格说明书对输入范围进行划分，把所有可能的输入数据，即程序输入域划分为若干个互不相交的子集，称为等价类，然后从每个等价类中选取少数具有代表性的数据作为测试用例，进行测试。
划分原则：区间、数值、数值集合、限制条件或规则、细分等价类
边界值分析
边界值和等价类密切相关，输入等价类和输出等价类的边界是要着重测试的边界情况。在等价类的划分过程中产生了许多等价类边界。边界是最容易出错的地方，所以，从等价类中选取测试数据时应该关注边界值。
在等价类划分基础上进行边界值分析测试的基本思想是，选取正好等于、刚刚大于或刚刚小于等价类边界的值作为测试数据，而不是选取等价类中的典型值或任意值做为测试数据。
对于一个n变量的程序，边界值分析测试会产生4n+1个测试用例。
因果图
（1）确定软件规格中的原因和结果。分析规格说明中哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。
（2）确定原因和结果之间的逻辑关系。分析软件规格说明中的语义，找出原因与结果之间、原因与原因之间对应的关系，根据这些关系画出因果图。
（3）确定因果图中的各个约束。由于语法或环境的限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。
（4）把因果图转换为决策表。
（5）根据决策表设计测试用例。
决策表分析
在所有的黑盒测试方法中，基于决策表的测试是最严格，最具有逻辑性的测试方法。
决策表是把作为条件的所有输入的各种组合值以及对应输出值都罗列出来而形成的表格。
它能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用决策表能够设计出完整的测试用例集合。
步骤：
（1）列出所有的条件桩和动作桩。
（2）确定规则的个数。
（3）填入条件项。
（4）填入动作项，得到初始决策表。
（5）简化决策表，合并相似规则。
对于n个条件的决策表，相应有2n个规则
决策表合并原则：即若表中有两条以上规则具有相同的动作，并且在条件项之间存在极为相似的关系，便可以合并。
白盒测试：
也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。
白盒测试常用方法
基本覆盖标准：逻辑驱动、循环、基路测试等，主要用于软件验证。
“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。
“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。
原因：
第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。
第二，穷举路径测试不可能查出程序中因遗漏路径而出错。
第三，穷举路径测试可能发现不了一些与数据相关的错误。
白盒测试逻辑驱动方法
语句覆盖
判定覆盖
条件覆盖
判定/条件覆盖
条件组合覆盖
路径覆盖