自动化测试工程师最常犯的 3 个错误

• 原文地址：Top 3 Mistakes Every Test Automation Engineer Makes
• 原文作者：Dilpreet Johal
• 译文出自：掘金翻译计划

在这篇文章中，我想和你们讲讲我所见过的每个自动化测试工程师都会犯的或在他们职业生涯中的某个时候犯过的 3 个错误。让我们开始吧——

错误 #1: 在你的代码中使用 “Sleep”

这是我见过的每个人在需要“fix”一个测试时最常犯的错误之一。也许你现在已经知道或听说过在你的代码中使用“sleep”是不好的，但是让我们看看为什么它是不好的 —

完成测试需要的时间更长了

很明显，你添加了固定时长的 sleep 它当然需要更长的时间来完成。更快的反馈很重要因为这是敏捷方法的全部意义所在，如果你的一些测试花费了 30 分钟到一个小时甚至更多的时间，那就会在你的构建队列中增加很多额外的时间。

如果你认为我知道我在这里加了 2 秒但没人在乎或者没人会注意到，那让我们看下一点。

无意识地使用 “sleep”

在下图中，我们使用了一个名为 .open() 的方法，在此之后，我们会等待 2 秒以确保页面加载。

但是让我们看下 .open() 方法内部发生了什么。这个方法内部我们又等了 2 秒。所以最有可能的情况是，之前添加了 2 秒等待的人并不知道这个等待已经在 .open 方法中了。

虽然总共 4 秒的等待可能看起来不是那么糟糕，但考虑到大型项目中有 10 到 100 个文件，如果到处都使用 sleep 命令，这将是一个大问题。

使你的测试不稳定（剥落感）

添加 sleep 会使测试不稳定，因为你不知道加载特定页面或元素需要等待多长时间。再看一遍我们之前的例子 ——

• A 在写原始测试时增加了 2 秒

• 由于速度慢，B 使用 2 秒有问题，所以又增加了 2 秒

现在想象一下，如果你在运行环境中的测试速度很慢，那么这些测试可能会再次失败，所以你所能做的就是返回并增加测试的时间，那我们又回到了这个问题！

现在我希望你已经意识到使用 sleep 命令的问题，那么我们应该做什么呢？

99% 的情况下，你可以用适当的“wait”命令代替“sleep”命令

如果你在想为什么只有 99%？这是因为你可能会遇到一些 wait 命令不生效的情况，虽然这很极端，但有时你确实会遇到这些情况。在这种特殊情况下，使用 sleep 是好的，但我们可以再次回到这个问题并思考是否有更好的方法来实现这个解决方案。

错误 #2: 测试过于复杂

另一个我多年来看到的常见错误是编写过于复杂测试，如上图所示。在上面的图像中需要注意的一件关键事情是，在底部需要测试所需要完成的时间太长，我们有 180 秒即 3 分钟的超时。

因此，如果您正在编写这样的测试，那么让我们谈谈编写这样的测试的缺点 ——

不知道测试的目的是什么

这个很有趣，因为有时候我写了很长很复杂的测试，几个月后当我回过头来，我完全不知道我的测试要做什么。当然，您可以想象其他团队成员在阅读这类代码时的感受(我只能说那时我不想接近他们!)

测试完成的时间太长

很明显当你编写长测试时，测试完成所需要的时间也很长，这就是为什么我们在上面的图像中看到 3 分钟超时。

越长的测试越会导致测试剥落感

当我们编写长测试时会发生什么？长时间的测试通常更不稳定，因为有很多事情在进行，正因为如此它失败的几率更大。

调试代码困难

让我们看最后一点:当测试失败时，哦天哪！祝您=你调试顺利。您将运行一个基本上需要 3-5 分钟才能完成的测试，并试图找出问题所在行以及如何修复它。如果你还没有遇到这个问题，那么我会说你很幸运，因为这是相当痛苦的工作。

那么我们应该怎么做呢？我是这么想的 ——

测试应该一次专注于做一件事。

现在别把这句话放在心上，它可能是你和你的团队决定的事情——可以是一个功能，一个组件，一个在合理的时间内完成的(理想情况下少于 1 分钟) E2E 的工作流。

只要测试有一个每个人都能理解的单一目的，我认为这就足够了。

错误 #3: 测试依赖

在上面的例子中，第二个测试依赖于第一个测试，因为我们在第一个测试中打开要测试的页面的 URL。这很糟糕，原因如下:

无法在失败时运行单个测试

如果第二个测试由于某些原因失败，您将无法运行该测试，因为它取决于我们打开 URL 的第一个测试。你唯一的选择是运行两个测试，这将花费更长的时间来执行，或者你将不得不重构你的测试，我们将很快讨论这个问题。

更改测试顺序将导致测试失败

如果另一个人来了并简单地更改了这些测试的顺序，它将再次开始失败，因为它们的测试的顺序与之前不同。这是另一个大问题，因为现在你需要知道每个测试的顺序，以便将来运行它们。

使得重构代码变得困难

现在当你决定做重构在你的测试中，这将是很痛苦的，你需要了解所有这些依赖项工作，必须修复所有这些问题以便能够进行任何类型的重构，这将占用你更多的时间。

那么我们应该怎么做呢？

测试应该是独立的/分离的。

你的目标应该是编写可以独立运行的测试，而无需依赖任何其他测试甚至任何其他数据。如果你想在将来进行任何重构或简单地重新组织测试，这将给你带来更多的灵活性。

回顾

让我们快速总结一下本文中所涉及的所有内容 ——

• 避免在你的代码中使用 “Sleep”

• 不编写长而复杂的测试

• 测试不应该相互依赖

如果你能够避免这些错误，那就有望创建一个稳定而高效的测试框架。