开发之初没有考虑到用户操作的习惯,以及上手成本,本身开发出来是提高工作效率的,最终搞得适得其反了
基于开发每次提交代码,查看修改了哪些类和方法,然后反推到具体影响到的是哪些接口。我们的接口自动化用例之前就已经做了一部分,然后根据每个接口通过 tag 区分,这样接口修改以后根据对应的 tag 去匹配到接口的自动化用例,然后再触发 Jenkins 上的接口自动化用例执行
是这样的,能够给团队真正提升工作效率的工具,才是有意义的,即使后期投入成本进行维护这也是值得的,对于只是面子工程的,真的就意义不大
我们去年搞了一套,完全处于 KPI,无实质用处,除了给领导看下,这个是测试的产出,并无他用,平时也没有任何用
之前也有想过结合 RobotFramework 开发一个 web 端的,这样可以跟平台做集成,没想到大佬都已经落地了,着实佩服
实在不行使用 UIRecord 录制一遍,或者用 Puppeteer 搞一下
如果想持续不断的跑,尽量还是要找个专门执行用例的服务器。实在没办法,自己本地只要不关机,保证都能正常执行也可
向大佬学习
是这样的,不过他那个可以在其他服务器上安装第三方浏览器,你这个之前能够真实模拟不同浏览器的 l 的操作吗
可以用阿里的 F2etest 进行浏览器兼容性测试,这个还比较好用