各种自动化测试类型
可以在任何给定系统上运行各种类型的软件测试，从需求的功能/验证测试到安全或性能测试。这些测试基本上都可以划分到一两个分类中：黑盒测试（Black-box Testing）和白盒测试（White-box Testing）。介于二者之间的是灰盒测试（Gray-box Testing）。
白盒测试用于测试该系统的软件内部。单元测试和代码覆盖率测试是例子。测试时必须了解一些代码和设计的运作知识。不管执行的是哪种类型的测试，它们终的目的是验证系统是否成功地达到了功能需求。
黑盒测试通过与用户界面的交互，调用各种系统“调用”（名词，相当于函数）来试验系统的大部分功能。黑盒测试将测试的系统当作“黑盒子”，因为不知道系统内部的运作机制，而且也不需要去了解。
例如，如果用户通过用户界面输入数据，向应用的数据库添加一条记录，有多个层被执行了，比如数据库层、用户界面层、业务逻辑层。黑盒测试人员只需要通过查看用户界面输出来验证正确性。
因为用户界面（黑盒）测试无法发现所有缺陷，为了提高测试效率，必须使用灰盒测试。
灰盒测试。对于灰盒测试已有各种各样的定义，但根据本书的目的，我们对灰盒测试的解释和定义如下：使用黑盒测试时，有些时候因为软件的错误报告机制存在缺陷，用户界面不会报告错误。比如，应用程序插入数据库失败了，但没有报告这个错误到用户界面?用户界面从底层代码中获得了“漏报”信息后继续执行，而没有把错误显示给用户。灰盒测试要求了解组成系统的底层组件知识。测试工程师只有了解了应用的架构和底层组件，才能精确地定位应用程序各个方面的输出结果。构建灰盒测试的测试人员可以完善黑盒测试方法的不足。在灰盒测试过程中，测试人员可以具体地局限在系统运行失败的部分。比如，测试工程师可以查看那些因为功能复杂或仅仅是由于新加入的代码造成不稳定性而有可能失败的地方。
以下一些实例说明如何更深入地了解系统的架构可以帮助测试工程师。
提高执行探索性测试的能力
一旦测试失败，如有必要，测试人员通常必须通过修改原先的测试场景执行一些“重点”测试，来确定应用程序的“中断点”或造成（没造成）系统中断的因素。在这项工作中，对SUT架构的了解对测试人员将大有帮助。测试工程师可以执行更有用和更具体的探测测试，还可能让他跳过额外多余的和完全无关的测试，因为对底层组件的了解，可以让他们确定问题的更多信息。例如，如果应用程序遇到了数据库连接问题，那么它没有必要尝试用不同的数据值来操作。相反，在继续进行测试之前，工作的重点将是解决连接问题。
增强缺陷报告
在前面一节已经讨论过，如果能改进构建调查研究测试的能力，默认情况下，可以编写更好的缺陷报告了，因为可以提供更多的详细信息。大部分测试过程是基于需求的，因此有一些固定路径会贯穿整个系统。当这个路径上出错了，如果测试人员具备这种能力，会在缺陷报告上包含与系统架构相关的信息，这对于系统开发人员非常有帮助。比如，如果某个对话框不能显示，测试人员经过查找会发现是由于从数据库查询信息出了问题或有可能是应用无法连接到另外一个服务器导致的。
提高测试精度
灰盒测试尝试通过用户界面或直接针对底层组件来测试应用，同时监视系统内部组件的行为来确定测试是成功还是失败。灰盒测试自然会产生与缺陷原因相关的信息，因为监视特定组件的行为是这个测试策略的一部分。一般来说，在测试过程中会遇到如下四类问题。
■ 组件碰到某些类型的错误，导致操作被终止。用户界面一般会显示系统发生了错误。
■ 测试执行中产生了错误的结果，意味着测试结果和预期的测试结果不符。也是说，系统某个组件处理数据不正确，导致错误的结果。
■ 在执行期间组件出错了，但是没有把这个错误通知给用户界面，这是所谓的“漏报”。比如，输入数据，但并没有保存进数据库，然而没有将该错误报告给用户。
■ 系统报告了错误，但实际上处理过程一切正常?测试产生了“误报”。显示一个不正确的错误消息。
在第一种情况下，得到有用的描述性错误信息是非常重要的，然而往往并非如此。例如，如果数据库在操作时发生错误，通常用户界面显示的错误信息是“无法完成操作”，而没有更多细节来描述为什么失败。更有用的错误信息应该给出更多细节，比如，“因为数据库错误，操作无法完成”。而在内部，应用还可以在错误日志里记录更多信息。如果测试人员具有系统组件的知识，可以使用所有可用的工具，包括日志文件和其他监视机制来更精确地测试系统，而不是完全依赖于用户界面的消息。
有些测试还是需要人工参与，比如，可用性测试只有一小部分可以自动化，如Section 508 adherence。类似如Bobby的工具可以用来检验网站是否遵循了可访问性需求。可用性测试另一部分的作用是测试系统是否满足了它计划的目的。对于这种类型的测试适合的是网页可用性测试，在这种测试中，雇用一个潜在用户顾问组像他们通常那样做的使用Web页面，来测试网页固有的“用户友好性”。这种类型的测试是为了确保用户了解如何浏览页面得到想要的信息或执行期望的交易。可用性测试研究本身是一个完整领域，许多公司都投身到这个领域中来。
其他类型的测试更适合自动化。附录B提供了各种类型测试的列表。其目的是突出那些手动方式几乎不能完成的测试。
安全测试、浸泡测试（soak testing）、并发测试、代码覆盖率测试、内存泄漏检测等测试类型都适合自动化，而且都难以手动测试。手动地进行这些测试非常容易出错，通常会出现不一致的输入，并且整个测试期间成本高昂、艰辛且耗时。
除了较低级别自下而上的测试，比如单元测试，或安全测试中的静态和动态的代码分析外，自动化测试提供了诸如可重复性的好处。一些适合自动化的典型测试类型包括：
单元测试，如在应用的源代码里验证独立的单元。
回归测试，如验证以前可工作的功能是否还可运行。
功能测试，如验证系统是否满足了功能需求。
安全测试，如验证系统是否符合安全要求。
性能测试，如验证系统是否满足性能要求。
压力测试，如验证系统在压力下能否“正常”工作，而不至崩溃。
并发测试，如验证系统能否处理并发线程和用户。
代码覆盖率的验证，如评估系统代码已被测试套件检验的百分比。
