自动化测试的缺点是什么？

这个站点上有许多问题，可以提供有关自动测试可以带来的好处的大量信息。但是我没有看到代表硬币另一面的东西：缺点是什么？生活中的所有事情都是折衷方案，没有万灵药，因此，一定有一些正当理由不进行自动化测试。这些是什么？

以下是我提出的一些建议：

• 给定功能需要更多的初始开发时间
• 需要团队成员更高的技能水平
• 增加工具需求（测试执行者，框架等）
• 遇到失败的测试时，需要进行复杂的分析-该测试是由于我的更改而过时还是在告诉我我做错了？

编辑
我应该说我是自动化测试的坚定支持者，并且我不希望这样做。我想了解缺点是什么，所以当我去公司提出理由时，我看起来好像并没有扔下一个想象中的银弹。

另外，我明确地是不希望有人对我的上述示例提出异议。我确实认为必须存在一些不利因素（所有因素都需要权衡），我想了解它们是什么。

您几乎钉住了最重要的那些。我添加了一些次要的内容，以及实际上无法成功进行测试的缺点-当您真的不希望它们执行时（请参阅下文）。

• 开发时间：对于测试驱动的开发，已经在单元测试中计算出来了，但是您仍然需要集成和系统测试，这也可能需要自动化代码。一次编写的代码通常在以后的几个阶段中进行测试。

• 技能水平：当然，必须支持工具。但这不仅是您自己的团队。在较大的项目中，您可能有一个单独的测试团队，该团队编写测试以检查团队产品与其他产品之间的接口。因此，更多的人必须拥有更多的知识。

• 模具需求：就在那儿。没有太多要补充的。

• 测试失败：这是真正的错误（无论如何对我来说）。有很多不同的原因，每个原因都可以看作是不利条件。最大的缺点是需要时间来确定哪些原因真正适用于您的失败测试。

  • 因实际错误而失败。（仅出于完整性考虑，这当然是有利的）
  • 失败，因为您的测试代码是用传统的错误编写的。
  • 失败，因为您的测试代码是为产品的较旧版本编写的，并且不再兼容
  • 失败，因为要求已更改，并且已将测试的行为视为“正确”

• 非失败测试：这些也是缺点，并且可能非常糟糕。当您改变事物并接近亚当的回答时，它通常会发生。如果您更改了产品代码中的某些内容，但是测试根本没有考虑到它，那么它会给您这种“错误的安全感”。

  非失败测试的一个重要方面是，需求变更会导致较早的行为变为无效。如果您具有良好的可追溯性，那么需求变更应该能够与您的测试代码相匹配，并且您知道您将不再信任该测试。当然，保持这种可追溯性是另一个缺点。如果你不这样做，你结束了一个测试，并没有失败，但实际上验证您的产品的工程错误。在某个地方，这会打击您..通常在您最不期望的时间/位置。

• 额外的部署成本：您不只是在自己的计算机上以开发人员身份运行单元测试。借助自动化测试，您希望在某个中心位置根据其他人的提交执行它们，以找出某人何时中断您的工作。这很好，但也需要设置和维护。

刚开始在我们的团队中尝试自动化测试时，我看到的最大缺点是，很难将其应用到并非针对自动化测试而设计的遗留代码中。从长远来看，这无疑会改善我们的代码，但是在短期内保持自动化的同时，进行自动化测试所需的重构水平是一个非常高的壁垒，这意味着我们在引入自动化方面必须要非常有选择性。单元测试，以满足我们的短期承诺。换句话说，当您已经负债累累时，还清信用卡要困难得多。

也许最重要的缺点是... 测试是生产代码。您编写的每个测试都会将需要维护和支持的代码添加到您的代码库中。不这样做会导致您不相信测试结果，因此您别无选择。别误会我-我是自动化测试的大力提倡者。但这一切都是有代价的，这是一个很大的代价。

我不会说这些是完全适用的缺点，但是我碰到最多的几个是：

• 在复杂的企业应用程序中设置测试所花费的时间。
• 处理错误地失败的旧测试，换句话说，系统已经进化，现在测试是错误的。
• 错误的信心来自不完整的或未知的测试范围。

零星的测试覆盖范围可能导致错误的安全感。如果您进行重构并使用测试来证明其有效性，那么哪些证明您的测试能够证明这一点？

创建测试所花费的时间有时对我们来说是个问题。我们的自动化测试不仅包括单元测试，还包括用例测试。这些往往更广泛，需要上下文。

当然，我的观点是从比单元测试更旧的应用程序中获取。

我要说的是，它们的主要问题是它们会提供错误的安全感。仅仅因为您进行了单元测试，并不意味着他们实际上在做任何事情，而是包括正确测试需求。

此外，自动化测试还可能包含错误本身，因此带来了一个问题，即单元测试是否需要自我测试，而不一定实现任何目的。

尽管自动化测试具有许多优点，但也有其自身的缺点。一些缺点是：

• 需要具备编写自动化测试脚本的能力。
• 调试测试脚本是主要问题。如果测试脚本中存在任何错误，有时可能会导致致命的后果。
• 对于播放方法，测试维护成本很高。即使在GUI中进行了微小的更改，也必须重新记录测试脚本或将其替换为新的测试脚本。
• 如果测试脚本测试更多屏幕，则维护测试数据文件将很困难。

上述某些缺点通常会从自动脚本获得的好处中扣除。尽管自动化测试有其优点和缺点，但它在世界范围内得到了广泛的应用。

我最近问了一个有关游戏开发中测试的问题 -顺便说一句，我是如何知道这一点的。那里的答案指出了一些奇怪的特定缺点：

1. 当您的代码应高度耦合时，这样做的成本很高。
2. 当您必须了解各种硬件平台，应该分析向用户的输出并且代码结果仅在更广泛的上下文中才有意义时，这很难做到。
3. UI和UX测试非常困难。
4. 尤其值得注意的是，自动化测试可能比一堆非常便宜（或免费）的beta测试器更昂贵，更不有效。

第四点使我想起了我的一些经验。我在一家非常精简，面向XP的Scrum管理的公司工作，强烈建议进行单元测试。但是，在迈向更简洁，更少官僚主义的道路上，该公司只是忽略了质量检查团队的建设-我们没有测试人员。因此，即使测试覆盖率超过95％，客户也经常在某些系统上发现琐碎的错误。所以我要补充一点：

• 自动化测试可能会让您感到质量检查和测试并不重要。

另外，我当时正在思考有关文档的问题，并提出了一个假设（对于较小的范围而言）可以有效地测试两个假设。我只是觉得代码发展如此之快，以至于很难使文档以这种速度发展，因此花时间使代码具有可读性比编写沉重而容易过时的文档更有价值。（当然，这不适用于API，而仅适用于内部实现。）该测试还存在相同的问题：与被测试的代码相比，编写可能会太慢。OTOH，这是一个较小的问题，因为测试警告它们已经过时，而您的文档将保持沉默，只要您不非常非常仔细地阅读它。

最后，我有时发现一个问题：自动化测试可能取决于工具，而这些工具的编写可能不正确。我前一段时间使用XUL开始了一个项目，伙计，为这种平台编写单元测试非常痛苦。我使用Objective-C，Cocoa和Xcode 3启动了另一个应用程序，并且在其上的测试模型基本上是一堆解决方法。

关于自动测试的缺点，我还有其他经验，但大多数经验都在其他答案中列出。尽管如此，我还是自动化测试的坚定拥护者。这省去了很多工作和头痛，我默认情况下始终建议这样做。与自动测试的好处相比，我认为这些缺点仅仅是细节。（重要的是在发表异端评论后，始终要表达自己的信念，以免出现自动辩护。）

未提及的两个是：

• 运行大型测试套件可能需要的时钟时间长度

我参与了自动质量检查工作，因为测试很慢，所以花了半天的时间来运行测试。如果您不小心编写测试，则测试套件也可能会出现这种情况。直到您现在正在管理该时间，这听起来并不重要，“哦，我刚刚进行了修复，但是需要4个小时来证明正确性”。

• 一些测试写作方法的脆弱

每次您转身时，某些测试方法（例如，使UI自动化）似乎都会中断。例如，如果您的脚本由于正在等待按钮出现而挂起测试过程而使测试挂起，则尤其痛苦，该按钮已被重命名。

这两种方法都可以通过良好的测试实践来解决：找到使测试套件保持快速运行的方法（即使您需要做一些技巧（例如在计算机/ CPU之间分配测试运行）。同样，可以采取一些措施避免编写测试的脆弱方法。

我想补充一点，一种错误的安全感。

除了很小的，定义明确的问题集以外，不可能创建全面的测试。我们的软件中可能仍然经常存在自动测试根本无法测试的错误。当自动化测试通过时，我们常常会假设代码中没有错误。

很难说服管理/风险资本家

• testautomation增加了前期成本。
• testautomation缩短了产品上市时间。
• 测试自动化的好处来自中期和对数。激烈的竞争更多地集中在短期利益上。

有关详细信息，请参见市场驱动的单元测试。

通过使用自学测试可以克服主要缺点之一。在这种情况下，预期结果将全部存储为数据，并且可以在自学模式下由测试套件用户进行最少的审核，从而进行更新（显示旧的预期结果与新的实际结果之间的差异-如果按y，则更新预期的结果）。需要谨慎使用此测试套件学习模式，因此不会将儿童的行为视为可接受。