莉莉丝是真的大气 hhh

向大佬学习。

渐渐也感受到了分布式系统开发的便利，之前做的一个测试平台，开始没有想好分布式，为了兼容 UI 自动化后端选择了 Nodejs，放弃了 Golang。

后面灵感一闪，还是做成了任务调度的分布式系统，只用基于 worker 实现任务解析执行即可。

现在想来，既然做成了分布式，就不再绑定特定语言了，而 Golang 无论从性能还是分布式上，都是优选，希望有时间能用 Golang 重构一下，开源分享给大家。

之前还在纠结是否继续使用 Golang 作为我的主流，现在看到了大佬的实践，坚定了我的想法 hhh

1. 同一套动作，可以在 dev / test / staging / prod 等环境复用。
2. 同一套动作，在埋点测试里面，每个用例里面拦截的 url 是不同的。

你 UI 自动化的核心是啥？selenium 吗？怎么解决维护成本问题？

校验当然是以埋点文档为标准，自动化触发完以后，再神策对比。

多玩多用多踩坑，用着用着就炉火纯青了

已经落地投入使用了 hhh 本质上是 worker 实现了解析脚本的功能，跟系统是分离的，系统只是管理和调度任务而已。每个人都可以根据自己的项目去定制开发自己的 worker。

比如你的平台用例就是一个 python 脚本，一个 js 脚本，一个 go 脚本。https://testerhome.com/topics/27297

一样的，你平台支持调度执行你做的脚本就行。本质上平台只是为了方便数据统计和过往回归结果统计。

羡慕，副业真难想 hhh

1. 系统是 jwt 设计的话，拿到 screct 自己就可以搞，去掉 expire 即可。

2. 如果非 jwt 的单点登录的话，在开始 ui js 脚本前，手写 request 前置登录即可。

嗯，后端数据逻辑本来就更适合做在接口测试里面，没必要跟 UI 测试耦合在一起。

所有 UI 所需的数据，都内置 mock 做处理。

而且虽然脚本是录制的，但是其实不是只能录制，本质上只是个 js 脚本的 string 类型，所以很多处理可以根据业务自己用 js 去适配写些功能，后面这块准备抽出来单独做个业务的数据工厂和业务的函数工厂。

反手就是一个怒赞 hhh

也感谢大佬的日常技术交流分享和鼎力支持 hhh

现在后端写什么鸭 hhh

大佬面前不敢当 hhh

你可以的 hhh 加油鸭 hhh

还是萌新 hhh

所以现在在做哪行

前排沙发打 call !

一起加油鸭 hhh

好滴鸭 hhh

申请开通专栏~

回放对比的时候，回放路径的所有中间件和数据库肯定要保持一致性，所以如果是修改适配中间件保持其一致性，成本有点高，还是做规则校验和 interface 层面的 fake 与 mock 更解耦一点。