■ 在执行期间组件出错了，但是没有把这个错误通知给用户界面，这就是所谓的“漏报”。比如，输入数据，但并没有保存进数据库，然而没有将该错误报告给用户。
■ 系统报告了错误，但实际上处理过程一切正常—测试产生了“误报”。显示一个不正确的错误消息。
在第一种情况下，得到有用的描述性错误信息是非常重要的，然而往往并非如此。例如，如果数据库在操作时发生错误，通常用户界面显示的错误信息是“无法完成操作”，而没有更多细节来描述为什么失败。更有用的错误信息应该给出更多细节，比如，“因为数据库错误，操作无法完成”。而在内部，应用还可以在错误日志里记录更多信息。如果测试人员具有系统组件的知识，就可以使用所有可用的工具，包括日志文件和其他监视机制来更精确地测试系统，而不是完全依赖于用户界面的消息。
有些测试还是需要人工参与，比如，可用性测试就只有一小部分可以自动化，如Section 508 adherence。类似如Bobby的工具可以用来检验网站是否遵循了可访问性需求。可用性测试另一部分的作用是测试系统是否满足了它计划的目的。对于这种类型的测试最适合的是网页可用性测试，在这种测试中，雇用一个潜在用户顾问组就像他们通常那样做的使用Web页面，来测试网页固有的“用户友好性”。这种类型的测试是为了确保用户了解如何浏览页面得到想要的信息或执行期望的交易。可用性测试研究本身就是一个完整领域，许多公司都投身到这个领域中来。
其他类型的测试更适合自动化。附录B提供了各种类型测试的列表。其目的是突出那些手动方式几乎不能完成的测试。
安全测试、浸泡测试（soak testing）、并发测试、代码覆盖率测试、内存泄漏检测等测试类型都适合自动化，而且都难以手动测试。手动地进行这些测试非常容易出错，通常会出现不一致的输入，并且整个测试期间成本高昂、艰辛且耗时。
除了较低级别自下而上的测试，比如单元测试，或安全测试中的静态和动态的代码分析外，自动化测试提供了诸如可重复性的好处。一些适合自动化的典型测试类型包括：
单元测试，如在应用的源代码里验证独立的单元。
回归测试，如验证以前可工作的功能是否还可运行。
功能测试，如验证系统是否满足了功能需求。
安全测试，如验证系统是否符合安全要求。
性能测试，如验证系统是否满足性能要求。
压力测试，如验证系统在压力下能否“正常”工作，而不至崩溃。
并发测试，如验证系统能否处理并发线程和用户。
代码覆盖率的验证，如评估系统代码已被测试套件检验的百分比。
相关链接：
