问你会提出什么理由来说服管理层，用户界面自动化是一项糟糕的投资？

EN

我假设您的意思是在减少全系统自动化测试的数量和增加低级测试的数量方面进行倒退。我已经在我的组织里推动了一段时间同样的事情，所以我有一些轶事的建议。

我认为测试金字塔是最好的起点。你听起来很熟悉，所以我会继续谈这个。如果您需要更多的背景知识，Martin写了一篇关于它的好文章http://martinfowler.com/bliki/TestPyramid.html

最近，我一直在问人们，他们认为不同类型测试的目的是什么。如果您有一个相当不错的测试金字塔，您基本上知道您的应用程序运行正常。那么，自动化UI测试实际上是什么呢？根据我的经验，他们主要是测试应用程序部署/安装是否正确，并且实际上正在运行。

我非常喜欢的另一个概念就是测试深度。如果您正在通过UI进行全部或大部分测试，那么您的测试就不可能有任何有用的焦点。这降低了测试的有用性，因为当一个测试失败时，导致失败的原因还不清楚。

除此之外，我想说的是，测试的有用性随着运行时间的增加而呈指数级下降。这更多地关系到测试运行的频率，而不是实际测试的执行时间，尽管它们通常是相关的。单元测试非常有用，因为它们运行得很快，而且开发人员已经习惯于运行它们。集成测试应该运行得相当快，因此开发人员在签入之前运行这些测试的障碍应该不会很痛苦。也许他们不想每次编译时都运行它们。自动化的UI测试，尤其是很多测试，都需要10分钟的时间，所以您不想那么频繁地运行它们，如果有的话。这使得测试变得不那么有用，因为它提供的反馈与它应该测试的实际更改有很大的脱节。

这往往是一个很难的论点，尤其是因为它经常将“测试”责任转移到开发人员身上，他们可能不希望处理编写单元或集成测试的问题，并且认为两者都没有价值。

我在这里发现以下几点是有帮助的：

• 将业务逻辑测试保持在单元测试或集成测试级别上所需的许可证和时间要便宜得多，每次构建运行时，它们都可以在几秒钟内运行。如果您有大量涉及业务逻辑/计算的UI级别测试，那么这个测试(几乎)就是一个gimme。(举个例子，在以前的工作场所，有数千个基于UI的测试，总共花费了将近12个小时。它们可以--而且应该是--用不同的输入参数对税收计算进行单元测试或集成测试。在该代码中没有单元测试，更糟糕的是，如果不进行重大重构，它是如此的不可测试。)
• 开发人员在代码库中内置的单元测试和集成测试越多，应用程序就越稳定，在不破坏现有功能的情况下修改就越容易--如果回归遇到许多问题，这是一件大事(在没有单元测试的公司，紧急补丁发布占用了测试团队一半以上的时间--这意味着新的开发测试和回归测试变得更短--这导致了更多的回归错误导致……你懂的)
• 即使是设计最完善的UI自动化也是脆弱和高维护的。即使已处理了记录/回放所引起的问题，但像使字段不可编辑这样简单的事情也会导致数小时的自动重构。
• UI自动化往往会遇到两个问题之一:要么有大量重复操作与重复代码对应的问题，要么测试运行高度依赖于先前完成的测试是否正确完成。在第一种情况下，您可以对UI进行小的更改，从而导致大量重构问题；在第二种情况下，运行早期的失败可能会在运行过程中进一步导致级联失败。我还没有遇到一种干净的方法来最大化干自动化代码，同时最小化依赖。
• 测试越接近它所测试的东西，就越容易(而且更快--因此更便宜)识别问题。如果单元测试失败，问题就在该单元或单元测试中。如果集成测试失败，问题可能出现在所涉及的任何单元、单元之间的通信接口或测试中。如果UI测试失败，您可以添加用户界面、计算机当时碰巧执行的其他任何操作(预定的病毒扫描会对UI自动化运行造成严重破坏)，以及UI和后端之间的通信。即使有了世界上最好的日志记录和测试设计，这也是UI测试自动化的一个挑战。

简短的版本是，如果您正在运行大量UI测试来验证业务逻辑，那么这些测试将更好地作为单元测试或集成测试来处理，以提高时间、成本和有效性。

主要的事情可以是最初的成本。但是为什么我们应该忽视自动化，如果有同样的技术，并且可以简化工作。我支持自动化，尽管我们不能仅仅依赖于任何一个工具，因为这可能不能提供精确性。