|
随着更先进的技术进入由AI/ML支持的连续测试领域，组织尤其是测试从业人员常常正在争论哪种更好，是通过编程语言完成自动化测试还要采用无代码测试解决方案呢？
对于这个辩论，没有一个神奇的答案，也没有一种方法可以长久解决问题。
本文中将提供各种注意事项以在两种测试自动化方法之间进行切换/组合。
注意事项
为了更好地解决何时以及为何使用这两种方法的问题，以下是要首先考虑的内容，排名不分先后，因为不一样的团队可能涉及不同的目标和优先级：
有哪些应用程序用例和流程（不限于测试）可以自动化？
由哪个角色创建和维护这些方案？
团队/个人中从事这项工作的技能是什么？
该应用程序运行的系统和环境如何分布？
项目的迭代时间多久，发布进度怎么样（每周/每月）？
测试套件是否集成到其他工具（CI/CD/Frameworks）？
是否有高级自动化方案（机器人、物联网、GPS、音视频等）？
成本边界是多少（工具、项目、技术探索等）
测试套件是否大规模执行？
该项目是新的项目，还是现有基于代码的套件之上的附属？
更深层次
上文列出了一些重要的考虑因素，现在让我们更深入地解释它们。
对于一个已经在进行项目（Web/移动）并且已实现大量实践的，嵌入到流程，CI/CD和其他触发器中的基于代码的测试团队来讲，应认真考虑这样的考虑因素：什么是改变的动力？基于代码的套件中是否存在覆盖空白？现有的测试代码是否有过多的冗余？基于上述动机，团队才应考虑将无代码测试场景添加到其工作流中。
另一方面，对于刚开始一个新项目的团队来说，这是提升整个团队技能，基于的技术来决定使用哪种工具的最佳时机。如果是一个新创建的网站，它结合了Selenium框架，由Java/JavaScript开发人员领导的SDET与业务测试人员可以通过机器学习驱动的无代码Selenium工具消除其中的一些技术困难。
完成最开始的用例覆盖之后，现有测试套件、新项目与现有项目的质量，还应考虑分配给项目的时间范围和成本预算。显然，与使用Java、Python或其他开发语言编码相同的方案相比，无代码脚本平均要快6-10倍。它涉及到设置平台和测试环境、编码、调试、大规模执行、文档声明等。显然，这也可以节省更多的时间和精力。另一方面，并非所有测试场景都可以轻松记录，因为对于某些高级流程，编码是一种更好的方法，并且随着时间的推移更容易维护。这就是为什么有时最好在着手编写脚本之前先看一下要完成的工作。
高覆盖率是关键
问题辩论的下一个话题是组织内部的生态系统和工具格局。一项新技术并不容易推广，通常不被人们所接受，而且也不总是符合当下场景的。在当今的现实中，当小队团队一起工作并且由技能、目标和偏好的各种资源组成时，需要考虑适当的因素，并结合具体情况，使其在工作中发挥良好作用，来完成新技术的集成。在这种情况下，无代码工具应填补团队中的重要空白，并与现有CI/CD和其他流程很好地集成在一起，最好不要造成工作重复或额外的工作内容。
最后谈谈测试自动化脚本的维护成本。对于任何测试自动化团队来说，这都是最值得关注的问题之一。一次编写脚本，使其随时间跨版本运行，说起来容易做起来难。应用程序在不断变化，被测平台（移动设备/OS版本、浏览器）也在不断变化，因此，自动化测试用例需要正确地维护，以确保测试结果的准确和用例的稳定运行。无代码通过元素定位方式的自我修复，测试步骤等以多种方式解决了此类挑战。也可以在基于代码的项目中通过高级的报告和分析以及自动的根本原因分析和其他方法来实现，但是在这种情况下，无代码确实表现得最为出色。例如：Selenium4 IDE特性：弹性测试、循环和逻辑判断中提到的测试用例的弹性。
总结
如本文所写，在采用无代码工具之前，还有很多问题需要解决，包括如何在现有的基于代码的套件中将其组合。坦白说，将这两种方法结合起来是未来的发展方向，并且是最大化整个测试自动化范围并在整个团队中提高效率的方法。
无论是在代码自动化测试和无代码自动化测试中间的任何一点找到平衡，这种平衡都不是长久稳定的，要以一个变化的心态看待过去、现在和将来。以人为本，更重要是对人的技能重视，而不是期望工具或者方法解决人的问题。
欢迎大家来测试大佬云集资料共享群：646294456
|