写代码能跑的很稳定，已经很牛逼了，点点建用例并没有想得那么好吧，ms3.0 都去掉 ui 自动化了吧

无代码的自动化其实核心是需要使用门槛低/学习成本低，那么就得产品化，投入一个完整的项目资源，包括产品 + 设计 + 技术。但是现在挺多做法本末倒置，为了无代码而无代码，投入的人可能也就只有测试组，目前我们公司用的一套无代码 UI 自动化，是用 excle 中关键词来驱动模版代码运行，但是随着业务越来越复杂其实学习 excle 的成本已经不亚于直接写代码了。

要不大佬展开说说，用例如何设计的，简单平台如何搭建的，项目开源了没

老实说，ui 自动化很伪需求，真正有效的测试，还是接口加上 app 界面的手动验证的体验性测试。

建议你叼他一顿，你在教我做事？

上干货

关键字驱动，抽离脚本公共方法，只维护元素用例

我们现在采用的是录制用例，通过插件前端录制操作，自动生成脚本，你可以自己找找这方面的东西

这样的工具已经有现成的吧，比如 metersphere？

ui 自动化发展这么多年了，可以说是到目前为止还是老一套

大佬，UI 自动化中的关键字驱动，是不是类似于接口自动化的

Yaml 参数化一样的实现效果啊，现在在做 POM 封装，目前还没有实现 UI 自动化的关键字驱动，就像你说的但是随着业务越来越复杂其实学习 excle 的成本已经不亚于直接写代码了。这种关键字驱动不就是等于重新学了一个更复杂的平台吗？而且这平台随着业务越来越复杂，学习也越来越负责，要知道的关键字越来越多，感觉在 UI 自动化中需要实现的关键字驱动模式就是个伪命题，并不会节约时间成本，而且 UI 自动化去写已经封装好的代码的用例，感觉是比了解关键字去写用例要简单的。
还有 UI 自动化大部分公司的是用不到的吧，只是为了凸显专业性而已，在一个产品中，最经常的就是界面，UI 自动化的维护成本很高，要说价值吧，肯定也是有的，在回归 bug 与业务性测试能节约很多时间，但是全功能覆盖就是没啥太大的用处，除非界面已经不经常性的改动了
想问的是：UI 自动化的关键字驱动真的有可以用的地方吗？在什么情况下比学习已经封装好的代码去写代码用例更简单

底层是什么框架

哈哈，不至于，正常讨论交换意见而已

确实是这样

没用过，好像收费吧

正常的 UI 自动化的思路 1、定位路径 2、对这个元素做什么操作，拿每一行数据去转成对应的 ios、安卓的自动化代码执行（我用的 ios 的 wda，安卓的 uiautomator2）
主要是为了复用，多行数据组成一个小 case，N 个小 case 组成一条正常的业务流程

playwright 本身就支持录制的吧

看你们能投入的成本和最终想要的效果吧，比如自己封装 playwright 和 AIRTEST（主要是为了同时兼容 WEB 和 APP），然后可以直接录制维护自然语言的脚本了，问题关键是前端的 UI 自动化你要兼容的东西很多，Native, RN,H5 可能都不一样，要做的精细的话肯定成本更高的

UI 自动化最实际的用途最终都会走向各种抖音微博刷赞，刷回复这类的场景 :

底层的那些控制逻辑不可能做什么更新的，应用层玩出花也没用

老哥在公司有实际落地方案吗

没，目前方案还没定型，离实际落地执行还远，主要聊聊想法而已

自己摸索弄了这样一个雏形。效率有点低