编译：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测试仍然需要变得越来越快。同样，模拟器的运行成本很高。
总之，我期待着未来能有更多的解决方案，它很可能是基于人工智能的，几乎不需要任何代码来操作。
3.已开源！一款支持HarmonyOS NEXT系统的UI自动化框架hmdriver2发布
