目前 Appium 开源项目 issues 达到了 10000+,累计大小项目开源贡献者达到 300+,可见实践的用户群体和场景都是相当庞大的,且每个 PR 审核都有专业开发工程指导完成的,同样 Appium 社区的周报内容也是相当丰富的,只要愿意花时间熟读 appium https://appiumpro.com 周报和 issues 基本上都可以解决日常自动化问题,从目前的选择看 Appium 还是业界最好的开源测试框架,至于其他的功能测试框架或多或少可以看到同行的借鉴,用 xpath 定位或是 id 定位不准确的因素,也不是单靠 Appium 能解决的事情,这好比客户端爆出线上问题,端上的同学尽可能前期考虑到这种情况做些兜底处理,后端同学也可以做些防护措施
看了下,官方 java_client 没有提供 MJPEG_SERVER_PORT 参数,有可能是忘记加了,可以自己手动补充下这部分逻辑 String MJPEG_SERVER_PORT = "mjpegServerPort"; 初始化 driver 根据示例设置下值
https://github.com/appium/java-client/blob/master/src/main/java/io/appium/java_client/remote/IOSMobileCapabilityType.java#L197
初始化 driver 设置下 mjpegServerPort 也行,这里有示例:https://github.com/appium/java-client/blob/master/src/test/java/io/appium/java_client/ios/AppIOSTest.java#L30
API Doc 没有说明 mjpegServerPort 参数,实际上代码是有这部分逻辑的,访问视频录制接口携带过去行了 https://github.com/appium/appium-xcuitest-driver/blob/master/lib/commands/recordscreen.js#L238
你用的是 appium 里的 WebDriverAgent 吧,应该是运行 Script 没有完全安装成功,可以先暂时忽略,需要访问 inspector 可以先试用 facebook wda 试试看
日志上显示两部设备都是录制的 9100 端口的截图流,返回的是同一个视频,需要配下每部设备的 mjpegServerPort 端口
哈哈,挺有意思的,Appium 前世今生系列,有了解现在的 Appium 开发人员,也可以在讲讲呀
这样还是没找到问题的实质原因呀,WDA 不是最新的嘛,可以看看是不是在 Xcode 11 新增了 resolveOrRaiseTestFailure api 导致的
可以全局搜下 WDA 有无包含 resolveOrRaiseTestFailure 新增的 API,可以尝试更新最新的 WDA,看了下 commit 已经做了兼容
1、https://github.com/manishPatwari/WebDriverAgent 例子可以看提交的 commit,类似可以在 fb_tree、handleTap 等常用的方法对 xcuitest 相应的 api 嵌套@autoreleasepool ,可以及时释放内存,这种情况对于 Monkey 工具来说是有好处的,常规的业务自动化只能算是小优化吧,并不能解决你遇到的问题,重新看了下日志你这种情况更贴近第二种情况
2、页面底部存在 “加载更多” 功能,使用 XCUITEST 查找元素短时间内会频繁的创建对象,App 也会出现卡死的现象,可以找下有 Table 嵌套的 Cell 页面尝试复现,打开报告面板,观察 Memory 的变化,如果是这种情况解决方法需要研发配合下,具体可以看下 Appium issues 和 WDA issues
3、WDA 断开还有一种情况是端口转发的问题,我仔细复现过这个问题,iproxy 转发出现异常,实际 WDA 是正常运行的,当下一次在发送请求时 WDA 就挂了,所以需要在下一次向 WDA 发送请求时 kill iproxy、start iproxy,可以先加上类似的操作,以免干扰你的判断
1、有可能是 iproxy 的问题,即使用了其他端口映射的工具也有可能出现类似的问题,只是时间问题,可以在 python 逻辑程序中的访问 WDA 的接口的时候来个 try except 来捕获异常,重试代理
2、从日志上看,工具运行时间的挺长的,内存使用率达到一定峰值也会销毁 WDA,首先看你的写的逻辑是不是死循环,死循环定时退出循环,来个@autoreleases清理下内存,如果不是的话也只能重试 WDA
感谢分享,赞👍
打开 /usr/local/homebrew/lib/node_modules/app-inspector/node_modules/xctestwd/lib/xctest-client.js,把截图上这三处存在 xctestrun 相关代码都注释了,重新运行试试看看效果
可以在 iOS 工程中 UIScrollView 或 UIView 类 Hook addSubView 方法,返回 (BOOL) isAccessibilityElement 成 false,看看效果
ScrollView 标签设置 accessible={false} 属性看看
子元素的控件类型也可以详细说下,来一张截图会更好,我记得有些元素是需要手动添加属性打开的
可以跟你们开发商量下 Fork RN 工程,把上面的 PR 代码合进去,App 在开个新的分支引入 Fork RN 的版本打个包试试看。总之你跟开发聊下前因后果,官方有人提了 PR 解决了这个问题,让他们想办法打个包给你试试看
这是待测 App 工程源码,不是 WDA 源码
https://github.com/facebook/react-native/pull/24113/files 这是 RN RCTView 框架自身的问题,已经有人提了 PR,可以跟 RD 配合试试
iOS 可以用 xcode 打开 instruments 查看对应页面是否展示性能指标,可展示的话是可以做到无侵入提取性能数据的,可以先试试
https://testerhome.com/topics/12352 这篇帖子跟你反馈的问题是一样的
这样,先启动 WDA 分别访问/source?format=xml、 /source?format=json 接口,看下可以获取到页面控件树么,还是访问这两个接口的同时 App 出现了异常崩溃,我看你提供的日志应该是出现 Crash,如果出现异常崩溃可以让研发 hook UITableViewCellAccessibilityElement 方法 https://github.com/facebookarchive/WebDriverAgent/issues/382
先看下键盘的控件类型是 keyboard 还是 other ,用键盘点击验证码框框应该会自动聚焦吧,如果是 keyboard 类型 post 请求传入的 value 值转成数组在加以改造 handleKeys 方法,同时看看 waitUntilVisibleForApplication 实现应该没啥问题的。 当然 other 控件类型也是有办法的,感觉不太通用