市面上的自动化测试框架主要是 2 类。
第一类底层的 SDK，如 selenium、playwright，需要测试人员精通一门编程语言，有这水平的自动化测试人员都被老板拉去搞开发岗了。
第二类是封装好的工具，例如 APITest 平台，适合不懂编程的人使用，能力受限工具平台，遇到一些特殊场景时又不能扩展。
有没有第三类，介于两者之间，既能像平台工具那样封装大部分自动化测试能力，满足日常需求，又能预留接口让测试人员扩展？测试人员懂编程时，自己写点小脚本增强一下，不懂编程时，让开发来帮忙写。
RPA 类的平台、MeterSphere 类的平台，现在有很多了，都是低代码，只有内置组件不满足才会需要写组件
httprunner，httpfpt...
了解一下 robot framework ➕ selenium 或者 playwright， 自然语言描述就贴近低代码， 另外也有扩展的能力和空间。
Jerry li
回复
你这个组合就是我想要的 robot framework +bdd，既能自然语言级别的低代码，又能扩展编程。恕我孤陋寡闻了，哈哈，多谢大神。
低代码/无代码 - 这本身就是一个噱头。即简单（不需要写代码），又复杂（能表示现实世界），怎么会有这样的东西。
Jerry li
回复
rf 难用死了，维护成本高、问题定位速率慢、还一堆兼容性问题，搞多线程还会像 jmeter 一样卡界面
，我们之前团队架构重组，从其他部门接了十几个项目，自动化全是 rf，我全重构成 unittest、pytest....
Jerry li
回复
安装使用了一下，SeleniumLibrary 所有内置关键字（如 Open Browser、Input Text、Click Element）均使用英文命名，无官方中文关键字版本，需要通过英文关键字 + 中文参数 + 自定义封装 实现中文协作，中英文混杂，看着难受。在中文环境推广不起来。
flyfisher
回复
robot framework 框架 5 年前很强大，现在互联网技术迭代了很多次了，继续用 robot framework 个人感觉有点原始，总不能几年后还在 robot framework 为主吧，老项目可以用，新项目还是建议用新的主流框架。现在大部分还是 pytest、playwright（高级一点的可以用 playwright MCP）等
homin
回复
楼主的需求是要低代码，所以 RF 在方面是满足的。 至于性能，多线程，兼容性之类的， 要楼主自行判断和评估。
我们这边几十个人的团队，用了五六年 RF 问题也不大。
也试用了一下 Behave，可以将关键字封装得更通用一些，参数化比 RobotFramework 做得优雅一些，RF 的 XPATH 放在用例描述中，自然语言和技术语言混杂，看着头疼。
下面这个例子是 Behave 的封装：
我觉得要是做出来了，肯定能大幅提升自动化测试开发效率
试一下 Airtest 这个软件吧，既可以支持画面截图进行点击操作，也可以用 xpath 定位进行点击输入这些。而且提供了录制功能。有开发稍微提供一些操作模板的话，没有编程技术的同事也能做一些流程相关的事。
flyfisher
回复
RF 也是可以放在 keyword 那个层级去定位元素的，不建议直接在 test case 级别直接写。 这块完全是你自己可以去掌握。
Jerry li
回复
我之前的团队也是想低代码甚至 0 代码搞自动化，想质量部门测试人都具备自动化测试能力，我之前还从 0 到 1 搞了套纯数据驱动的自动化框架，编写 excel 用例即可自动生成自动化代码，底层用的是 unittest，但最后发现这些框架在执行阶段各种坑，整个执行周期甚至高于 unittest、pytest，特别是用例设计问题定位问题分析，按我现有的理解，能劝几个回头就劝几个吧。
要想推广至全平台，规范定义、技能提升、技术培训也是一个好方法。
homin
回复
这个其实还是要看团队的情况和选择。 有些团队成员的代码能力达不到预期的话， 直接写出来的代码也很难维护，反而这种搭积木式的用例会更适合。
homin
回复
对于懂 Python 编程的测试团队，pytest 无疑是合适的，不用再搞自然语言关键字。对于没有编程能力的测试团队，自然语言级的低代码是必要的。
低代码的自动化不是很适合 coding，稳定期另当别论。我之前的团队搞了 4 年低代码，功能太多，P0 场景覆盖搞了 800 条 case（APIAutomation），后面升级了一次接口版本，调试成本根本兜不住。需要寻求一种低成本的自动化方案，决定用低代码自动化测试低代码（考虑过 UI 自动化，录制脚本，但是后期即将要做的前端性能优化，这个方案也不可行）。如果你的低代码内有流程引擎，可以考虑用低代码自身测试低代码，配置触发器，设置业务逻辑，在流程内把所有节点放上去，最终校验数据、流程日志即可。这个方案最为简单，从原来跑一遍自动化需要 20 分钟左右，降低到了 5 分钟覆盖
Kyle的一路高歌
回复
我们之前也想过用同一套 RF 去做 API 的测试，但考虑到 API 其实涉及很多数据的传递， 组装，验证，是不适宜用自然语言去处理的； 而且 API 本身不怎么涉及业务流程，自然语言的优势也发挥不上来。 所以还是采取 pytest