• 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写用例就好了