可以在任何给定系统上运行各种类型的软件测试，从需求的功能/验证测试到安全或性能测试。这些测试基本上都可以划分到一两个分类中：黑盒测试（Black-box Testing）和白盒测试（White-box Testing）。介于二者之间的是灰盒测试（Gray-box Testing）。

　　白盒测试用于测试该系统的软件内部。单元测试和代码覆盖率测试就是例子。测试时必须了解一些代码和设计的运作知识。不管执行的是哪种类型的测试，它们最终的目的就是验证系统是否成功地达到了功能需求。

　　黑盒测试通过与用户界面的交互，调用各种系统“调用”（名词，相当于函数）来试验系统的大部分功能。黑盒测试将测试的系统当作“黑盒子”，因为不知道系统内部的运作机制，而且也不需要去了解。

　　例如，如果用户通过用户界面输入数据，向应用的数据库添加一条记录，就有多个层被执行了，比如数据库层、用户界面层、业务逻辑层。黑盒测试人员只需要通过查看用户界面输出来验证正确性。

　　因为用户界面（黑盒）测试无法发现所有缺陷，为了提高测试效率，就必须使用灰盒测试。

　　灰盒测试。对于灰盒测试已有各种各样的定义，但根据本书的目的，我们对灰盒测试的解释和定义如下：使用黑盒测试时，有些时候因为软件的错误报告机制存在缺陷，用户界面不会报告错误。比如，应用程序插入数据库失败了，但没有报告这个错误到用户界面—用户界面从底层代码中获得了“漏报”信息后继续执行，而没有把错误显示给用户。灰盒测试要求了解组成系统的底层组件知识。测试工程师只有了解了应用的架构和底层组件，才能精确地定位应用程序各个方面的输出结果。构建灰盒测试的测试人员可以完善黑盒测试方法的不足。在灰盒测试过程中，测试人员可以具体地局限在系统运行失败的部分。比如，测试工程师可以查看那些因为功能最复杂或仅仅是由于新加入的代码造成不稳定性而最有可能失败的地方。

　　以下一些实例说明如何更深入地了解系统的架构可以帮助测试工程师。

　　提高执行探索性测试的能力

　　一旦测试失败，如有必要，测试人员通常必须通过修改原先的测试场景执行一些“重点”测试，来确定应用程序的“中断点”或造成（没造成）系统中断的因素。在这项工作中，对SUT架构的了解对测试人员将大有帮助。测试工程师就可以执行更有用和更具体的探测测试，还可能让他跳过额外多余的和完全无关的测试，因为对底层组件的了解，可以让他们确定问题的更多信息。例如，如果应用程序遇到了数据库连接问题，那么它没有必要尝试用不同的数据值来操作。相反，在继续进行测试之前，工作的重点将是解决连接问题。

　　增强缺陷报告

　　在前面一节已经讨论过，如果能改进构建调查研究测试的能力，默认情况下，就可以编写更好的缺陷报告了，因为可以提供更多的详细信息。大部分测试过程是基于需求的，因此有一些固定路径会贯穿整个系统。当这个路径上出错了，如果测试人员具备这种能力，就会在缺陷报告上包含与系统架构相关的信息，这对于系统开发人员非常有帮助。比如，如果某个对话框不能显示，测试人员经过查找会发现是由于从数据库查询信息出了问题或有可能是应用无法连接到另外一个服务器导致的。

　　提高测试精度

　　灰盒测试尝试通过用户界面或直接针对底层组件来测试应用，同时监视系统内部组件的行为来确定测试是成功还是失败。灰盒测试自然会产生与缺陷原因相关的信息，因为监视特定组件的行为是这个测试策略的一部分。一般来说，在测试过程中会遇到如下四类问题。

　　■ 组件碰到某些类型的错误，导致操作被终止。用户界面一般会显示系统发生了错误。

　　■ 测试执行中产生了错误的结果，意味着测试结果和预期的测试结果不符。也就是说，系统某个组件处理数据不正确，导致错误的结果。