编译：TesterHome
原文标题：Best Test Automation tools in 2023
作者：Dmitry Yarygin，QA Engineer

以下为作者观点：

早在 2011 年，我的测试工程师生涯还处于起步阶段，当时已经有了用于浏览器自动化的 Selenium，每个人都在谈论测试自动化，但手工测试仍然是最重要的。

我一遍又一遍地做检查表，我知道，虽然网站的自动化是可能的，但移动应用程序是另一回事。

时间快进到 2023 年，自动化比过去有更广泛使用，即使是 WebDriver 也不像以前我认为的那样具有创新性了。在我看来，WebDriver 的主要问题有：

• 设置复杂，需要 chromedriver 或 firefoxdriver，并依赖它们。
• 没有内置的报告工具，因此需要使用外部工具。
• 需要一个确定的测试框架，当然可以是 TestNG 或 JUnit，但一定需要记住处理更新的版本。
• 没有简单的命令行处理。
• 慢，而且经常出现不稳定测试。

所以，让我们来看看现在有哪些更加 “好用” 的自动化测试工具：

TestCafe

我是 TestCafe 的超级粉丝，第一次使用它是在 2020 年初，当时我正在做一个令人兴奋的项目，它让我大吃一惊。

比如，你可以像这样用 npm 来安装这个工具

npm i -g testcafe

然后像这样运行测试:

testcafe chrome test.js

通过它测试很容易创建和维护，不需要担心超时，而且它输出的报告也很容易阅读。

唯一的缺点是，这个框架只适用于测试网站，不适用于移动测试。

Mobot.IO

现在很多的移动应用测试工具，比如 Appium，它们不能完全取代用户的行为，比如下面这些不确定性：

• 刷屏和手势。自动化这种事情并不简单，需要适应实际的移动屏幕。
• 与特定运营商有关的案例。想象一下，训练一个模拟器来模拟特定的网络问题，准确的号码的短信发送，等等。这也不是那么容易的，而是需要实际的设备来做到这一点。
• 用程序控制设备并不总是能得到正确的输出。

而 Mobot.IO 这个项目似乎要通过使用机器人在硬件上执行动作来解决这些问题。但是，在成本方面，特别是对于并行测试，还有需要慎重考虑的。

尽管如此，这是迄今为止我所看到的最具创新性的方法。

Appium

Appium 是一个开源的框架，具有类似 Webdriver 的语法，可以为移动设备（iOS 和 Android）运行测试。虽然它用起来比较好，但我还是遇到了一些问题：

• 需要模拟器来运行测试。这对于一个移动框架来说是意料之中的，但我仍然期待一些轻量级模式。
• Appium 服务器是必须的。考虑到它需要一个 Appium 服务器在本地或一些第三方服务器上一直运行。
• 并不快。一旦你在本地机器上运行它就会变慢，因为它需要上述所有的组件。
• CI/CD 整合很复杂。我认为在本地运行测试并没有太大的潜力，我们应该始终考虑远程运行这些测试。

不过，考虑到我们没有很多其他的移动测试工具可供选择，Appium 仍是一个很好的解决方案。

Espresso/Barista

当我们谈论 Android 测试时，有一个 Espresso 框架可用于测试。唯一的问题是，它需要集成到代码中，而不是在已经打包的 apk 文件上单独运行。

Barista 是一个建立在 Espresso 之上的框架，简化了语法，并提高了代码的可读性。

如果你所在的项目有一个原生的 Android 应用，而且也不打算推出 iOS 版本，那这个框架可能会很好地解决这个问题。

如果你所在的项目的应用是跨平台的，我认为 Appium 是一个更好的解决方案。

Jest

如果你的应用是一个 React Native 应用，那么你可能会使用 Jest 框架。像 Espresso 一样，它需要被整合到代码中。

我已经用 Jest 试验了一段时间，但因为一些事情，我又回到了 Appium，这是因为：

• 我不想改变应用程序的代码，也不想干扰开发者正在进行的工作。
• 我更喜欢用打包好的 APK 文件工作，而不是源代码。这是我的偏好，因为我喜欢把测试和实际代码分开。

Playwright

这让我想起了 TestCafe，但它内置了一个很好的报告工具。从 Playwright 出来的报告真的很酷。

另外，与 TestCafe 相比，它把所有主要的浏览器都打包进去了，你可以 “开箱即用”。

Playwright 框架也让人觉得是网络测试的未来，它安装简单，有很多潜力可以集成到持续集成工具中。

WinAppDriver

说到桌面自动化，我觉得有点难过，因为目前似乎所有的焦点都转移到了移动和网络测试。

而 WinAppDriver 就是实现 Windows 应用程序的自动化的一种途径，它也是基于 Webdriver 的，这意味着平常可以使用熟悉的命令。

但这也意味着开销，因为必须维护一个运行命令的服务器，而且框架需要定期更新。

我还看到一些为 Windows、Mac 或 Linux 应用程序自动化开发新工具的倡议。

总结

我仍然对现在的自动化工具的状况不满意，因为：

• 网络自动化已经足够成熟，但当涉及到移动测试时，目前的设置仍有很多问题。我希望能够指向一个特定的脚本，输入一个终端命令，并将我的测试集成到我想要的任何 CI/CD 解决方案中。
• 用于移动测试的 Device Farms 成本很高。目前有一些解决方案，比如：BrowserStack、Amazon DeviceFarm、Firebase Test Lab 等等。但所有这些都是专有的解决方案， 我也想要一些出色的本地移动测试工具。
• 目前我们仍然在很大程度上依赖于开发人员如何正确地标记应用程序中的项目。比如，如果代码中没有按钮的名称或 ID，那么不一定就能正确地设置自动化。
• 移动 UI 测试仍然需要变得越来越快。同样，模拟器的运行成本很高。

总之，我期待着未来能有更多的解决方案，它很可能是基于人工智能的，几乎不需要任何代码来操作。