我每天在大型 Web 系统上运行包含 1000 多个测试的测试套件的真实体验是，您的预感是正确的，而且他们没有发现那么多错误。

但他们所做的是两个关键的事情：

1. 他们腾出了宝贵的时间，否则测试人员将不得不花费回归测试来进行发现错误的探索性测试。

2. 它们使您有机会快速自信地进行大量重构或进行重大更改。

之前的海报是正确的——自动化永远无法找到新的错误，这只能通过智能测试来完成——但是自动化会发现回归错误，而且通常不是你正在寻找的错误。然而，对自动化测试结果的智能分析可以发现重大问题。

我为我的上一个项目举了一个例子，我们每天通过 UI 运行近 1000 个自动化测试。我们曾经遇到过一些测试间歇性地失败并且没有任何明确原因的情况（该区域周围的代码很稳定并且有一段时间没有被触及）。

因此，当我查看测试结果时，我无法立即看到任何东西。测试标准之一是页面标题是“foo”，当我查看断言失败的位置时，我可以看到实际页面标题包含“http 403”。

仅仅通过查看那个失败的断言，我立即有了一个粗略的失败时间表，并且可以更快地隔离完全不相关的问题，该问题会无意中导致网站宕机几个小时，也许每周一次。

我不能说如果没有回归套件，我们的测试团队是否会发现该错误，但肯定会花费更长的时间。

您必须了解以下内容...

自动化永远不会发现新的错误。

如果您的系统更新，它会发现错误。如果系统由于某种原因而关闭并且您正在床上睡觉并且您在一夜之间启用了自动化，它会发现错误。它会向您发送一封紧急电子邮件，您将在早上阅读该网站已关闭一个小时左右的信息。

它不会找到人类通过错误回归找到的错误。它不会在系统中发现需要分析和不断敲击的错误。它不会发现隐藏的错误。它只会发现它被编程查找的错误。

也就是说......自动化可以帮助您专注于那些隐藏的错误。它会让你承受很多考验。像多浏览器一样，无休止地输入各种数据组合。整理诸如创建测试数据、公司、用户等任务。压力测试、负载测试、功能。所有可以覆盖的。

因此，自动化测试的成功将确保如果开发人员签入代码，您可以确定应用程序的主要部分在您熟睡时会在晚上回归。而且您可以确定它会发现更改，更新产生的缺陷，除非您没有为它编写测试，否则任何事情都不会被忽视。

我发现自动化测试通常对于确保旧功能不会被新代码破坏非常有用，并且我已经看到旧回归测试发现的新代码中的新错误。我尝试在没有 UI 的情况下尽可能多地测试功能，然后进行一些额外的集成测试，以确保在功能本身得到验证后 UI 调用了正确的功能。这种做法会导致更易于维护的测试。

由于可维护性成本，当不需要从测试中获取我想要的信息时，我更愿意避免 UI 测试。根据我的经验，与其他形式的自动化相比，UI 自动化在减少技术债务方面的作用较小，因为这种持续的维护债务。我更喜欢先编写更易于维护的功能测试，然后在时间用完时手动测试 UI（其他条件相同）。当然，有些项目的 UI 测试维护债务比其他项目更高，因此应该优先考虑自动化工作。在我从事的项目中，维护问题的两个主要来源是 UI 更改和时间更改。如果 UI 测试没有看到预期的行为，它们往往会超时，因此一个失败的测试不会阻止其余测试的执行，

当我最终达到 UI 测试是剩下的最高优先级自动化测试的地步时，我发现 UI 测试的一些问题可以通过良好的设计大大缓解。所有超时值和 CSS / XPath / 可访问性导航 / 等字符串都应该放在一个可以轻松配置的地方。虽然我没有听说过这个名字，但我已经通过反复试验学会了使用“页面对象”技术，它对我们的 UI 测试设计有很大帮助。与开发人员的良好沟通也是必须的，以避免花费大量时间编写由于 UI 更改而立即中断的测试。开发人员通常还可以将他们的代码设计为尽可能可通过其他自动化测试进行测试，因此您可以最小化 UI 测试的目标范围，只检查 GUI 逻辑和与其余代码的交互，而不是功能测试。