何为低代码测试
传统上，功能、 UI、端到端等测试自动化的实现都涉及编写测试脚本，代替测试人员执行重复的手动测试任务。自动化脚本的开发工作通常由 QA 工程师或开发人员完成，这需要编写大量代码。
而低代码甚至无代码的理念也是在自动化测试技术比较成熟之后出现的。需要特别说明的是，这里的无代码不是说没有测试代码，而是测试人员不用自己开发测试代码，使用Codeless测试工具可以帮助我们生成可以执行的测试用例集。如此将大大降低自动化测试的技术门槛，没有编程经验的测人员甚至是业务分析人员也可以很快上手。
低代码自动化的发展
无代码自动化起源于20世纪末的软件自动化快速发展的过程。在软件开发的早期，几乎所有工作都是手工完成的，从编写代码到测试执行。但随着软件系统的规模和复杂性增长，手工流程变得越来越不切实际且容易出错。对更高效方法的测试需求加速了自动化工具的发展，这些工具可以比人类更快、更准确地处理重复性高的测试任务。
然而，这些早期的自动化测试工具通常需要一定的编程知识才能使用，这限制了工具本身的发展。因此这导致了如何提供非程序员使用的无代码自动化工具的发展。无代码自动化最初出现在2010年代初，当时市面上有具有简单功能的录制和回放工具。但自那时以来，技术已经有了相当大的进步，而现代无代码工具利用AI和机器学习来提供更高级别的功能和多功能性。
录制和回放工具的缺点
用户通过简单地按下录制开关，执行测试用例步骤，然后按下停止键，并存储可执行的测试用例。许多自动化工具都有这个功能，但是它也会导致测试用例非常混乱，需要进行许多优化才能实现可读性和稳定性。自动化工程师在进一步清理和改进这些测试用例。这种工具的一个大缺点是测试记录器通常是一个浏览器插件，这意味着录制的用例不能实现任何跨平台的端到端测试。
低代码测试的优点
让我们深入研究一下为什么无代码测试可以显著提高软件开发和质量保证过程：
1. 导航复杂的框架：传统的测试脚本通常涉及复杂的框架设置。这些需要特定的技术专长和大量的时间投入，这可能会分散产品开发其他重要方面的资源。相比之下，无代码测试工具通常提供直观的界面和自动化的设置过程，使您的测试环境更容易、更快地启动和运行。
2. 减少编写脚本的时间：手动编写测试脚本可能是一个漫长而艰苦的过程，特别是对于具有广泛功能的复杂应用程序。无代码自动化，凭借其自动化的测试生成功能，可以大大减少编写脚本的时间。这种效率使团队能够更快地设计和实现全面的测试场景，从而加快开发周期的测试阶段。
3. 减轻测试代码维护工作：代码维护是传统测试中一个经常被忽视但很重要的方面。每当应用程序更新时，测试脚本需要相应地修改和更新，这可能是一个耗时的工作。无代码测试，特别是具有自修复功能的工具，可以自动适应应用程序的变化，从而最小化测试维护所需的工作。
4. 提高生产力：无代码测试的所有这些好处最终都提高了生产力。通过减少测试所需的技术障碍和时间，开发人员和测试人员都可以将他们的技能和精力集中在他们的主要任务上：构建和改进产品。这不仅加快了产品开发，而且还提高了产品的质量，因为团队可以投入更多的时间来设计更好的功能和纠正问题。
5. 用更少的资源做更多的事：今天的软件团队通常期望以快速的速度和有限的资源交付高质量的产品。这给开发周期的所有阶段都带来了巨大的压力，特别是测试。无代码测试可以通过简化和加速测试过程来缓解这种压力，使团队能够用可用的资源实现更多的目标。
6. 改变QA测试的视角：无代码测试可以改变组织内部质量保证的角色和观念。与其被视为需要专业技能的技术性、耗时的任务，测试可以成为整个开发过程中更具包容性和完整性的一部分。使用无代码工具，团队中的任何人都可以创建和运行测试，促进更好的协作和产品质量的共享所有权。
低代码自动化的实践
测试用例自动化生成已经不算什么高深的技术了。作者在前东家工作时候就有过自动化用例生成的实践，并且有产出专利。我认为 用例生成的核心思想就是 数据源+用例模板化+模板引擎。正如上述我们介绍的单接口、组合接口模板，我们可以归类所有POST请求可以共用一套模板，所有GET请求可以共用一套模板，其他请求方法类似。当然亦可以汇总所有请求方法为同一个模板中；而数据源可以来源于POSTMAN导出的JSON文件、SWAGGER文档，Charles的Har文件，甚至JMeter的JMX文件，当然我们需要写解析这些文件的脚本才能获取到需要的数据。而模板引擎可以使用FreeMarker。
接口测试，从功能上可以把接口当做黑盒进行输入以观察其输出，根据不同的输入去测试其内部的逻辑，我们可以借助边界值分析、等价类等方法设计用例。非功能上要测试接口性能、安全、幂等。此外，如果所测接口存在上下接口调用的依赖，则还需要进行全链路联调测试（不部分接口不是独立存在的，都是和其他接口相互调用的），联调测试是为了保证上下联路接口之间契约的准确性。
而接口测试内容中契约参数测试则比较实现低代码测试。我当时的思路就是基于契约文档（swagger）一键生成接口参数测试用例，涉及到边界值、非空、必传值等测试场景的用例生成。
下面是一个简单的实现样例：
（1）测试数据生成
圈红处的可以作为变量值，从数据源中提取出来并填充到key键的值。
（2）测试用例生成
而测试用例文件中，上述圈红处可以作为变量，从数据源中提取需要的数据进行填充。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
