写代码能跑的很稳定，已经很牛逼了，点点建用例并没有想得那么好吧，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 自动化最实际的用途最终都会走向各种抖音微博刷赞，刷回复这类的场景 :

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

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

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

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

https://testerhome.com/topics/40124

这种 IPC 类 APP，自动化需要设备配合，设备那边的稳定性、状态怎么处理比较好？如何添加，用什么方式初始化设备到出厂状态，怎么去断言设备状态

1、自动化流程中按用例功能执行，但是某些关键步骤可以加异常兜底处理（如我一开始的图中的扩展代码）
2、执行过程中遇到失败（可能是 app 端，也可能是设备端），当前流程失败，继续后续流程，当前流程集合执行完一轮后（按模块分的，或者设备分的 N 个流程集合），按预设条件判断某流程是否需要重新执行
3、如需要人机交互的直接剔除自动化，或者接口重置设备
4、设备添加的可以单独提取成一个流程集合，意味着你要有 2 套设备，一套日常挂机全功能可用，另外一套走添加已经添加后的普通校验一下可用（避免添加影响其他 case 的执行）

https://testerhome.com/topics/40809

你们做测试 我用来做业务，减少业务部门重复的操作