RPC 也是基于 TCP 协议的，goreplay 支持 TCP 会话录制回放，不过效果好不好不敢肯定，确实没试过。这个录制回放其实就是把字节码再传一遍，直接传对于会话鉴权这种可能还是会有问题，我在实验中 http 请求也是用了 middleware 来处理会话 cookie
goreplay 还有个收费的 pro 版本功能更强大一些

这点确实是最难的

嗯嗯，可以的，goreplay 录制时每个请求上面都有个 uuid 和时间戳，可以标记每次请求，可以做到接口级别的 diff

不想争论太多哈，xpath 和 id 想对来说用的还是自认为还是比较熟，而且 jquery 和 vue 我都用过写过页面，对这两种前端框架还是有一点了解，你可以找一个 vue 的页面写个 selenium 脚本试试看。
xpath 定位是不难，但是如果每一个元素都需要从父级或者父级的父级，或者 n 代祖宗开始，你就知道有多蛋疼了，请问原来 jquery 页面会是这样吗？即便你玩的 xpath 玩的很溜，这都基本不影响你效率，那项目内推广呢，后续维护呢？你是不是需要想再回想下 xpath 的层级关系

1、我说 id 只是一个比较浅显的比方，其实这是涉及到前端开发数据交互的一种方式，原来类似与 jquery，前端需要考虑数据交换，比方说一个输入框，他需要获取这个款输入的值，他也会主动的在的个控件上加个 id(即使不加也会在上级加个标识 class 之类)，这个跟自动化测试其实是一致的，就是说你需要操作这个控件，前端也需要，他们会主动加。换成 vue 就不一定了 (实际上在大多数场景下不要了，而且大多数开发者认为 vue 下直接操作 dom 会影响性能，会尽量避免），这就造成现在的 vue 页面控件基本上没有人为设置的属性标识。对于这样一种页面，有些 xapth 玩的溜的也可以定位，但是效率会大打折扣。
2、当然有些大佬在团队内有话语权，推动前端去主动加 id，这个问题对于他们是不存在的

最大的痛点我认为是现在 vue 采用数据双向绑定，前端不会在控件上加类似 id 进行标识，以方便操作 dom，用 selenium 做自动化时由于页面上大部分控件都没有特殊标识，定位很麻烦（不是说不行，可以通过 xpath 用文本等方式定位，但相比 id 定位这种方式复杂很多）

模拟输入键值或移动鼠标这些是不行的

enter...enter...enter

大佬辛苦了

引入 jar 包，直接用 junit 或 testng 写用例就好了