众所周知，无代码革命正在进行中，带来了曾经不可能实现的各种新方法和解决方案。这种持续转变的一些更明显的例子是 Squarespace 和 Wix 等网站，它们允许用户在不了解任何代码的情况下制作网站。尽管如此，各种各样的其他解决方案也正在进入专家领域，包括以前乏味和复杂的领域，如医疗行业和测试我们在日常生活中使用的应用程序。
然而，与技术领域的任何根本性转变一样，无代码革命有时会遭到误解。我遇到的一些批评是正确的——无代码毕竟是一种不断发展和发展的技术——但其他批评是基于对旧形式技术的接受，还有一些只是简单的误解。
在本文中，我想讨论我个人在无代码革命前沿遇到的六种不同的误解。虽然这些误解可能只针对我的背景——无代码移动应用程序测试——但其他行业的专家可能会发现这些听起来很熟悉他们正在经历的事情。
六个误解
所以，不分先后，让我们来看看：
1. 无代码更昂贵
我亲眼目睹了一种奇怪的说法，即无代码比手动代码贵很多倍。虽然我不确定这个概念最终从何而来，但我怀疑这是由于在传统现状上引入无代码解决方案的初始标价成本所致。当操作依赖于其他流程时，无代码的前期成本似乎令人生畏。
然而，随着人员配置变得越来越具有挑战性，并且公司将注意力转向获得投资回报，一切照旧的做法变得越来越明显，根本不会削减它。反过来，在过去几年里，我很少看到这种讨论，尤其是在过去一年我们看到的招聘困难和裁员的不确定形势下，这种讨论也很少见。
2. 无代码无法处理复杂场景
这个更像是一个混合包。目前，并非所有测试用例都适合无代码移动应用程序测试。例如，在 Unity 上运行的游戏不会成为出色的无代码移动应用程序测试用例。
然而，大多数移动应用程序测试需求很容易适应最新的无代码移动应用程序测试解决方案。除了测试非游戏移动应用程序和虚拟现实或增强现实等专门方法之外，无代码越来越可以做到这一切。无代码应用测试征服那些快速变化且通常是试验性的应用类别所需的特殊场景只是时间问题。
3. 无代码不能为我的用例定制
在许多方面，这与第二个误解非常相似。我怀疑这源于早期版本的无代码。事实上，无代码移动应用程序测试在过去一年中取得了突飞猛进的发展。
在我创立和领导的公司 Sofy，仅去年一年，我们就见证了无代码移动应用程序测试平台的巨大变化和极大扩展的功能。我毫不怀疑该领域的所有其他无代码移动应用程序测试平台都见证了同样的情况。
4. 无代码无法治理
当代无代码解决方案的主要目标之一是与现有系统集成。没有人愿意引入一些破坏或不适合他们最喜欢的CI/CD设置的东西。另一方面，没有人愿意在他们的生态系统中引入一种无法治理的新方法。幸运的是，如今，无代码解决方案通常支持系统开发生命周期(SDLC)。
5. 无代码无法扩展
这是此列表中最大的误解之一。实际上，今天的无代码移动应用程序测试可以轻松处理任何规模的测试工作，从最小的测试工作到最大的测试工作。这在过去可能是一个限制，但现在肯定不是。
根据测试需求进行扩展的能力是无代码相对于传统手动编码方法的最大优势之一，也是公司在引入无代码移动应用程序测试时看到巨大投资回报率的主要领域。在投资回报率突然成为众多公司关注焦点的时期，这是一种巨大的力量。
6. 无代码需要大量维护
我遇到的第六大误解是，无代码移动应用程序需要大量维护和维护，例如要求QA 团队重新创建场景而不是更改代码（即文件替换）。也许是早期无代码测试阶段的遗留问题，但今天根本不是这样。
与传统的手动代码自动化测试相比，无代码移动应用程序测试的主要好处之一是它对测试人员的要求非常少。当然大家在生产的时候要尽可能早的左移，尽可能多的去测试。尽管如此，没有人愿意花时间摆弄自动化，这无疑是无代码测试真正擅长的另一个领域。
理解和观察进化
无代码可能看起来很新奇，但事实并非如此：无代码方法——无论是在测试环境中还是在其他环境中——源自一个自然的甚至可预测的过程，称为抽象。通过这个过程，复杂变得简单，让用户花更少的时间为事情的发生做准备，而花更多的时间让事情发生。
例如，今天，我们认为操作系统的好处是理所当然的。无论我们使用的是 Microsoft 的 Windows、Apple 的 macOS 和/或 iOS，还是 Google 的 Android，我们中的许多人整天都在通过操作系统与工具进行交互，并且不会再考虑它。没有人需要知道代码才能使用计算机或移动设备。感觉完全自然。为此，我们要感谢抽象。
与那些众所周知的界面的早期一样，无代码测试解决方案正在经历快速的创新、变化和更新。他们将继续这样做，直到未来出现另一层抽象。与此同时，我建议避免用任何先入为主的概念来描绘无代码——一种快速发展和扩展的技术。
如果抽象的历史有任何迹象，我希望我们只会看到越来越多的无代码解决方案，有了它们，误解就会越来越少。
