无代码自动化工具适用于大型测试套件吗？

Question

基于人工智能的无代码自动化工具正在兴起.他们中有很多人甚至声称拥有灵活性和可重用性。

对于拥有数千个测试用例的大型复杂测试套件，它们是否足够好？

在使用这些工具时，自动化不需要强大的编程技能吗？

三个例子：

Leapwork：https://www.leapwork.com/blog/codeless-test-automation

“无代码硒与AI维护”

完美：https://www.perfecto.io/codeless-automation

人工智能驱动的测试自动化创建

应用程序：https://applitools.com/

人工智能驱动功能和视觉测试

Answer 1

在许多情况下，没有

第一个自动化案例很容易编写--没有页面对象，不需要使用DRY，等等。

在第100次测试中，您需要大量的编程或无代码的自动化套件。

当您继续使用

add or change functionality or bug discovered / fixed
  \|/
write new UI test
  \|/
repeat

测试套件开始增长，不久就需要第一个小时，然后几天才能运行。测试用例的数量不断增加(我已经看到了数万个)，还有那些断断续续的错误，这些错误破坏了增加价值的测试的信心。将测试用例与浏览器、设备、版本和方向相乘，宇宙可能会结束。最终，快速反馈的初衷消失了，QA变成了一个单独的功能，它可以进行检查和验证，但不会直接影响开发人员创建应用程序代码的质量。测试是为了测试而进行的，质量不会长期提高。

显然，您应该遵循单元、集成和UI层的敏捷测试金字塔背后的原则，仅仅使用工具来编写更多的UI案例并不能促进组织内部的这种对话和操作。

目前，诸如“将测试套件保持在15分钟以下，决定需要哪一个端到端的UI测试，以及哪些现有的测试可以转移到集成或单元测试”这样的方法，据我所知，并不是AI测试自动化能够处理的方法。也许谷歌内部也有。

Answer 2

这是我的两美分。

我尝试了Applitools (免费帐户)，我认为它提供了一些优秀的特性，比如测试创建和修改的速度、编写的代码较少以及容易捕获可视化bug。与标准自动化测试相比，另一个优势是可以捕获意外(可视化)错误。例如，您通常会为已知的web元素编写断言(它们是可见的，包含正确的文本等等)，但是通常不会断言另一个元素会变得可见，或者页面布局会改变。

一些缺点是价格(很明显)和测试速度的执行，因为这些类型的工具需要上传屏幕截图到服务器。

一种可以从可视化测试中受益的方法是保留通常的测试套件，但也可能添加一个可视测试用例(每页一个)来检查页面布局。