多谢关注，增加了 “补充说明” 部分。核心的发布流程脚本实际是验证可行的，但这毕竟是个夭折的项目，有些理想化的功能，还没有走到实践中验证，希望能给有需求的朋友一些启发。

大佬说的比较全面了。C 某 DN，一堆复制机器人，平台还不管理，确实有点恶心。

加了个平台简介部分，不知是否是你要的内容。

已经自己搭了

楼主有心了，正好在撸图像元素识别，讲解很细致。

感谢认可，接口系统目前也在重构。

消灭 0 回复

是的，无需同步，实时根据输入数据去 jira 搜索的

社群运营小建议：

1. 二维码定时更新
2. 放个小号个人二维码，弄个机器人回复关键字自动拉群。

给面试官表演下量子速读

3

不错哦，jar 提取部分，希望希望能细说下。

各家的具体要求不一样，我们的 jira task 就是需求

不需要，配置好开发环境，都可以。Mac 方便些

权重部分没有启用，大家都一样的。

抱歉 docker 版本的没有更新，新版本目前只有手动部署。详见：https://github.com/t880216t/iat

print(testunit)

实际可以理解为一个深度定制的云代理工具，平台化的运行，可将流量信息归档复用。还有个实时对比功能，可以实时对比不同版本，同样操作的返回信息，这部分已经开发，还没写帖子。

我的中间人代理采用的是二次开发的 mitmproxy 作为采集器，用 mitmweb 来可视化和过滤流量，借助 mitmdump 来保存流量文件和回放。一开始也设计了基于 sandbox 的方案，考虑到对源码的 0 入侵，后来也尝试了 goreplay，但是没法解决上面的问题 2，我们的是多个域名来回调的，单个服务的录制回放，用户的行为可能是中断，数据很难串联上。

多谢关注，敬请期待

有幸也在做流量回放系统，不过我用的是中间人代理，有些疑问请教：
1.网页应用 html 的结果对比咋处理的呢？
2.操作流程涉及多个域名的不同服务的流量如何序列化的？

用 RF 的考虑是可以进一步扩展移动 UI、和接口。

恩，谢谢

对比 rf-ride
缺点：

1. 所有数据都依赖接口交互，交互操作流畅性不如本地的 ride
2. 多个用例组合调试的需建临时任务，不如 ride 勾选运行方便

优点：

1. 关键词库、运行环境都有一个服务端维护，其他人不需要本地安装配置，打开网页即可使用
2. 数据实时入库，方便多人协作。
3. 报告优化，展示简洁
4. 操作可扩展（自动联想、插件交互等）

之前是把接口自动化和 UI 自动化写一个工程里的，现在觉得这样不好维护，就剥离了，详细的操作文档还未剥离出来。可以参考下
https://t880216t.github.io/vft_doc/ui_project/