最好来张图,假设验证码数据也发出来看看
在有 UITableView 页面下用 XCUITEST 输出控件树超时很正常,具体原因和解决方法可以翻看下 Appium 里的 issues,可以暂时打开 WDA 工程全局搜- (BOOL) isWDVisible 把方法内实现都注释了 return false,在试试
sendKeys,正常的输入操作就行了吧,还是你想模拟点击 keyboard 键盘上的数字呢
信息太少了,没办法,可能是 webpack 没安装或者 node 版本问题,可以看看提示信息
所有页面都是这样,进入 Inspector 文件夹终端运行 cnpm install && cnpm run build 在试试看
页面是用 RN 或者跨平台语言开发的吗?
可以看下你之前发的截图 “个人中心” 元素的 visible 属性为 false,实际上是在屏幕可视范围内的,这是因为 WDA 计算元素的位置方法是有缺陷的,所以尽可能使用元素的 frame 作为点击的位置才比较靠谱
Appium 实现的 click 或 tap 方法是遵循 W3C 协议实现的,粗略看了下会根据 action item 设置优先策略的,可以在 FBW3CActionsSynthesizer.m 文件里全局搜 - (nullable NSValue *) hitpointWithElement: 方法里打印打印 hitPoint 坐标位置,应该就比较清晰了
拼下元素的中心位置 x + width / 2, y + height/ 2 调用坐标点击的 api 试试看
先把 click 前页面 PageSource 打印出来,查看下点击前的操作是否符合预期的页面,如果符合预期但是 click 没反应,可以转成坐标位置来点击吧,非预期页面用逻辑加以控制应该没啥问题的
试试 appium 里的 wda 吧 base-driver 现在都更新到 3.19.0 版本了,你的还是 3.17.0,最新的可能是依赖 3.19.0 版本的,具体变动要看下 java_client 或者 base-driver 依赖是不是有 commit 影响到了
/Applications/Appium.app/Contents/Resources/app/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent WDA 是用 appium 里的嘛
https://github.com/appium/appium/issues/12680 issue 很相似,可以看看
1、虽然弹层页面会获取到遮挡的页面元素,我们应该想办法过滤掉不可视的元素,这里也是有办法用微小的耗时方式过滤掉不可视的 UI 元素的,最后还是对于元素的精准识别探讨吧
2、XCUITEST 是可以拿到屏幕外的 cell 或者其他控件类型的元素,视频中有对屏幕之外的元素进行测试的演示,无论元素在横向或是纵向,都是可以计算的方式自动跟踪定位元素的
3、pickview 等自定义视图的非触点的控件来看,也是通过配置化的方式来做,还没想到更好的方式
4、cocos 还是不熟悉,这里面就不探讨了,后续用我原先的工具试跑下看效果,熟悉下
5、忙过这阵子也会开源出来的
值得交流下,看了你写的侵入性的 Monkey,无法做到精确的控件识别,应该是 Monkey 对于元素的精准识别还有提升的空间吧
1、用 XCUITEST 最重要是为了省事,一套代码兼容 Native、WebView、RN 等跨平台页面,对外无侵入性接入
2、Crash 捕获、网络数据 (proxy 或 mock)、性能监控、统计覆盖率,交给集成到客户端的 SDK 做些可测性改进,日志相关的回捞 SDK 的日志显示在报表上,场景构造相关的外部修改下数据。还有项目用 cocos 开发,也就是游戏相关的 Monkey 测试,归类为跨平台页面,一般是集成到 iOS 客户端上,我都会想办法对跨平台的页面做些可测性改进,这里需要具体分析,例如 RN 页面多个小 UI 组件会嵌套到一个大 UI 组件里,无法识别小 UI 组件就需要让研发在底层的 RN 框架里加上 Accessibility 辅助功能标签;Crash 捕获、性能监控、日志相关的只要做的到位也是可以用黑盒的方式做部分实现的
3、获取控件树,无论是侵入性 XCTEST 方式或是非侵入性 XCUITEST 的 Accessibility 辅助功能都是用来提取页面控件树,最显著的区别在于使用 XCUITEST 在 loadMore 功能的页面获取 source 控件树耗时相当长,还容易出现非正常的意外崩溃,不过最后这些问题也都解决了,提取每个页面的控件树只需要 0.3 秒左右,极个别页面最慢也不会超过 10 秒
4、最后还是建议你抽出代码,提取部分插桩能够用指令下发 UI 操作即可,离智能也会更近一些吧
5、我也有一段跟你相似写 Monkey 的经历,试过用 XCUITEST 无侵入性写的效果,录了一段 App 视频效果验收: https://pan.baidu.com/s/1wYc_ZETUICzSDa71fHzRrA#list/path=%2F
monkey 集成到 app 里面,另外的 monkeyrunner 用 iOS 自带的 UITESTS 作为执行器运行 monkey,起初为啥不直接在 UITEST 里写 monkey 相关的逻辑呢
iOS 常用功能注:iOS 的弹窗不能通过屏幕点击选择,请问是出于什么考虑呢
看下 readme,执行./Script/build.sh 脚本文件,还有错误查下 google 搜搜
Appium 逐步开始放弃兼容 Xcode8 IDE,尽快更新到 Xcode9.3 以上的版本在试试
“测试人员只需要在手机上操作一遍即可直接获取关键场景模型”,请问这里是将手机投影到浏览器上操作,还是直接在手机上操作呢?
读了几篇文章、了解几个框架,以为这就是全世界了!
用 xcodebuild 命令运行 WDA 指定-derivedDataPath 路径从里面找找看,加你了
(1)这里我也不太确定,也许是 RD 的代码不规范(2)getPageSource 实际是调用 tree 方法,tree 方法内部会通过调用 XCElementAttributes 类来调用元素的属性值,元素的属性值实际是从生产代码的 get 方法获取的,也许 RD 只实现了 set 方法,没有实现 get 方法引起的,后面几句是我猜的,让 RD 实现下上面提示元素的 get 方法看看效果吧?(3)替换 WebDriverAgent 为 facebook 的 WebDriverAgent 还是不行吗?
visible 属性主要是通过控件的 frame 属性来计算的,可以看到上面的截图元素的 frame 属性可能都为空了,所以 visible 也为 false,也许是最新的 WebDriverAgent 获取控件树 tree 方法更改对你司的 App 有影响,建议替换 appium 的 WDA 为 facebook 的 WebDriverAgent 或降低 appium 版本查看元素的 frame 属性是否还为空,同时查看一下有问题的 WebDriverAgent 的日志是否有 Failed to fetch hit point for 错误提示或者贴一下 WebDriverAgent 日志文件,大致情况就比较清晰了