上一篇关于低代码测试框架的讨论挺热烈的，但是讨论逐渐偏向技术是否万能、是否覆盖 100% 场景，我认为没有万能的技术，能解决问题就是好技术，这里把我的想法展开讲讲，欢迎交流。
对原文讨论有兴趣的可以看看原文：好像市面上缺少自动化测试的低代码测试框架
低代码自动化框架应该具备极低的开发门槛，不要求掌握 Java\Python 等编程语言，以及丰富的积木模块，能够快速组装自动化用例。
是否值得引入或开发一个低代码框架，考虑 2 个核心因素：
考虑因素 1：投入产出
低代码自动化用例框架的出发点是提高用例转自动化的效率，引入低代码框架应有 2 点核心产出：
1、能显著降低对测试人员的编程技能要求，从而更容易从市场上招到人，这个在老板那里可以换算成人力成本。
2、能大幅缩短测试报告的输出时间，通过提升自动化用例占比，缩短测试周期，例如开发团队在下午下班给版本，测试次日上午输出质量报告。
考虑因素 2：低代码复用率
自动化用例的操作，其实大部分都是重复的相似的步骤，以 web 测试为例，通常包括输入数据、点击页面开始操作、等待 web 系统处理数据、导出结果、比对生产结果是否正确。低代码框架应该内置一套易于编排的测试能力，或者能够让不同的业务团队高效开发自己的测试能力。
市面上有些低代码框架就只是一个框架，积木要使用者一点点开发，没有经过专业设计的积木，演进到最后，一定是杂乱无章的，维护者最后不堪重负，换个新框架重开。
选型分析结论：
经过在原帖的讨论以及社区大神的提示，RobotFramework 是基本满足上面 2 个因素的，但是也存在 2 个关键问题：
（1）RobotFramework 没有中文关键字，对于中国人来说不容易阅读理解，写完用例还要在旁边加注释，可读性才好一点。例如这样：
（2）关键字格式定义呆板，技术痕迹浓厚，要像查函数一样查关键的输入输出。关键字语句读起来就很呆板，技术语言、自然语言混杂，又有点接近一套编程语言了。例如下面这里的 id=chat-textarea 是什么？看后面的注释才知道这是百度搜索的输入框。
下一步计划：
准备基于 RobotFramework 汉化一个自然语言关键字库，并解决格式呆板的问题，同时也会开放给大家。
个人感觉（结合一些经验），自动化测试其实写用例真的没多难（不管是关键字还是代码驱动），难点主要是在维护用例、环境、结果分析，如何能让自动化用例建设跟着版本发布的节奏走等等，跑一遍自动化很省事儿，但想跑的有价值，就需要环境 ok，数据 ok，这些其实也是要下功夫的地方
梦回 2020
小狄子
回复
你的团队应该是有比较多的自动化用例了，需要刷新接口、xpath、预期值来适应版本的变化，这是更高级的烦恼了。根据自然语言来分析问题失败在哪个环节，会比阅读 python 高效一点。
https://flybirds.readthedocs.io/zh-cn/latest/BDD-UI-Testing-Flybirds.html#id103 ，美团的已开源自动化框架。早几年前在顺丰也做过类似基于 behave 的自动化平台，不过没有开源出来。
想要形成真正提升效率，能落地，那就和开发平台一样了。apifox 在接口自动化现在越来越多公司使用了，可视化编排，落地的投入成本低，产出速度快。就这样还是有很多局限的地方。你这改改 RobotFramework 的关键字映射？做来玩玩还行，但感觉很难有实际效果
低代码作为业界的 “炒剩饭”，和二三十年前的模型驱动测试（MBT）的炒作，没有什么本质区别。而且什么分离不变性、参数化、内聚耦合的思想，都是软件设计模式三十年前讨论很多遍的。工程上找到适合自己团队的实践才是最佳实践，在 AI 加持下，也是一样的，可以多看看过去出版的一些经典著作，或许会有很多启示的。
我记得我 2014 的时候公司用的就是 cucumber，后来发现还是自己用 python 写代码比较好维护
在今天 AI 能够生成基础数据模型，封装接口，根据步骤结合工程上下文合理推导测试用例的今天。拥抱未来吧，这些真的是炒冷饭了。
出于兴趣，我自己写了一套基于大模型的框架。可以集成在 python appium、selenium、hypium 的体系下；也可以单独使用，使用纯中文进行 UI 自动化测试。
我推荐的最佳实践，还是集成到 appium 等现有体系下做，原生方案、智能方案在一起使用，既保留代码方案的灵活性，又能使用智能方案。
相比于自动生成，我觉着自动分析自动化失败原因，并能自行提交 MR 进行维护优化，这个用处更大。
自动化长期跑起来，维护和解决误报，这个才是日常投入最多的，尤其是 UI 自动化。