上一篇关于低代码测试框架的讨论挺热烈的，但是讨论逐渐偏向技术是否万能、是否覆盖 100% 场景，我认为没有万能的技术，能解决问题就是好技术，这里把我的想法展开讲讲，欢迎交流。
对原文讨论有兴趣的可以看看原文：好像市面上缺少自动化测试的低代码测试框架

低代码自动化框架应该具备极低的开发门槛，不要求掌握 Java\Python 等编程语言，以及丰富的积木模块，能够快速组装自动化用例。

是否值得引入或开发一个低代码框架，考虑 2 个核心因素：

考虑因素 1：投入产出

低代码自动化用例框架的出发点是提高用例转自动化的效率，引入低代码框架应有 2 点核心产出：
1、能显著降低对测试人员的编程技能要求，从而更容易从市场上招到人，这个在老板那里可以换算成人力成本。
2、能大幅缩短测试报告的输出时间，通过提升自动化用例占比，缩短测试周期，例如开发团队在下午下班给版本，测试次日上午输出质量报告。

考虑因素 2：低代码复用率

自动化用例的操作，其实大部分都是重复的相似的步骤，以 web 测试为例，通常包括输入数据、点击页面开始操作、等待 web 系统处理数据、导出结果、比对生产结果是否正确。低代码框架应该内置一套易于编排的测试能力，或者能够让不同的业务团队高效开发自己的测试能力。
市面上有些低代码框架就只是一个框架，积木要使用者一点点开发，没有经过专业设计的积木，演进到最后，一定是杂乱无章的，维护者最后不堪重负，换个新框架重开。

选型分析结论：

经过在原帖的讨论以及社区大神的提示，RobotFramework 是基本满足上面 2 个因素的，但是也存在 2 个关键问题：

（1）RobotFramework 没有中文关键字，对于中国人来说不容易阅读理解，写完用例还要在旁边加注释，可读性才好一点。例如这样：

（2）关键字格式定义呆板，技术痕迹浓厚，要像查函数一样查关键的输入输出。关键字语句读起来就很呆板，技术语言、自然语言混杂，又有点接近一套编程语言了。例如下面这里的 id=chat-textarea 是什么？看后面的注释才知道这是百度搜索的输入框。

下一步计划：

准备基于 RobotFramework 汉化一个自然语言关键字库，并解决格式呆板的问题，同时也会开放给大家。