是在 vscode 中对于 node 打的断点
天啊!被翻牌了!开心~
你 chromedriver 是 chromedriver=2.30.477700 对应的是 58-60
你的微信中的应该是 57 版本 chrome not reachable 你尝试一下将 chromedriver2.30 降为 2.29
我这边昨天遇到了 context 切换问题:
1.可以确定一下日志中打印出的 chromedriver 与 chrome 映射是否一致问题
[Chromedriver] Chromedriver version: '2.23.409710'
[Chromedriver] Webview version: 'Chrome/51.0.2704.110'
2.切换 context 时传的参数具体是什么?
我这边用 python 获取 context 时返回的是数组,里面既有原生也有 webview 然后切换 webview
[u'NATIVE_APP', u'WEBVIEW_com.tencent.mm:tools']
3.
一般进程 android_process 和 context 返回的值一致就可以~~~
https://testerhome.com/topics/15169
我这边是一边测试一边打断点 跑过几次半小时的时长 但是没有遇到 CPU 使用率 100% 的问题~
我这边是 python
python 启动脚本后 脚本里面
appium 启动 因为可能启动多个 appium 所以没有用默认的端口号 4723 以下为 shell 中的启动和 kill 命令
appium --session-override -p 4724
appium kill 命令
ps aux|grep appium|grep 4724|awk '{print $2}'|xargs kill -9
抱歉~不好意思哈~我这里是 python
就是用 python 代码执行 shell 中的命令
appium 启动 因为可能启动多个 appium 所以没有用默认的端口号 4723 以下为 shell 中的启动和 kill 命令
appium --session-override -p 4724
appium kill 命令
ps aux|grep appium|grep 4724|awk '{print $2}'|xargs kill -9
我这边是将 appium 直接写到测试脚本里 每次启动脚本启动 appium 脚本测试用例运行完毕 kill appium
我这边尝试执行了
self.driver.find_element_by_android_uiautomator('text(\"NFC\")').click()
其日志返回和你的查找朋友圈 text 一样 但是时间我这边用时是 165ms
所以我也不确定是什么原因了从日志里目前看不太出来~
和那 20000ms 没有关系 又看了一下日志对比
findElement 的时候 定位元素失败进行了重试
我这边测试时用的命令是:
el = self.driver.find_element_by_accessibility_id('Graphics')
el.click()
这两个命令执行的速度是很快的
或者你尝试一下换一下 find_element 的内容?
部署在服务器上的 jenkins 上 那么是以那台服务器为 slave? 那么如果执行脚本在那台 slave 上 ,一种方式可以全部装在那台服务器上,各种环境搭齐。
另一种方式在 jenkins 触发脚本的机器上安装:执行脚本 + 安卓客户端 +appium-client 端
appium-server 端在别的服务器上启动,通过 appium-port 远程连接
说的也不一定对哈·我这边是 jenkins 直接在自己电脑上搭了 slave,就整个一套环境都装了~
是不是没有加载 RoutingHTTPServer.framework
https://www.jianshu.com/p/00a4fcf720c1
这个地址里面有一张图是添加 framework 不知道是不是没有添加这个
在本地脚本中增加 启动 appium 的代码,增加启动 android 模拟器的代码 然后在 jenkins 的 shell 中触发这个本地脚本
在你的日志中有 [BaseDriver] Waiting up to 20000 ms for condition 这里是 20000ms 在我的日志里是 0 秒 不确定是不是这里引起的
是不是设置了 implicitWaitMs 这个属性为 20000ms?
有 uiautomator2 的日志吗?
简单看了下日志
在 click 时执行 20 秒
findElemnt 用了 10 秒 找到 elemnet 之后 click 用了 10 秒
我之前测试好像没有这么慢,回头看一下我这边的测试日志
先 mark 一下
如果你按照 xcodebuild test 之后仍然 appium 启动不成功 那我就不太清除了哈~
xcodebuild 重启 wda 是你说的那个样子 重启不成功 xcodebuild 会弹出弹框 重启成功手机就会装上 wda 然后之后 appium 再次启动时 wda 也是可以正常启动的 我这边这样测试时可以的
我这边遇到过这种无论怎么装都闪退的问题
闪退之后用 xcodebuild 重启 wda
如果 xcodebuild 报 too many instance……就重启手机
很奇怪的事情就是如果 xcodebuild 启动 wda 启动成功了 那么再次执行 appium 也可以成功
后来就加了个主动触发 xcodebuild 的脚本用来启动 wda
/usr/bin/xcodebuild build-for-testing test-without-building -project /usr/local/lib/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent/WebDriverAgent.xcodeproj -scheme WebDriverAgentRunner -destination id=此处添加udid test
我好像答非所问了……
我是直接开的命令行 desktop 就不太了解了~
appium 的日志里有的呀,是指这样的吗?
[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body
[debug] [JSONWP Proxy] Got response with status 200: "{\n \"value\" : {\n \"state\" : \"success\",\n \"os\" : {\n \"name\" : \"iOS\",\n \"version\" : \"11.2\",\n \"sdkVersion\" : \"11.2\"\n },\n \"ios\" : {\n \"simulatorVersion\" : \"11.2\",\n \"ip\" : \"192.168.0.102\"\n },\n \"build\" : {\n \"time\" : \"Jan 14 2018 23:25:10\"\n }\n },\n \"sessionId\" : \"17DE3FB9-3196-4C9C-9D55-3BFFDD0C1DEB\",\n \"status\" : 0\n}"
结论:并没有解决这个问题哈
之前遇到这个问题时:
打开 xcodebuild 日志:
会报出 TEST BUILD FAILD 的错误
或者:
Too many instances of this services are already running
当报出 TEST BUILD FAILD 时,在 xcodebuild 中启动后 再启动 appium 可正常启动 而且有一个现象就是一旦 wda 被移走了 appium 无论怎么启动都是失败的。
报出 too many 错误时重启了手机
这是我遇到的问题,但是也没有解决哈,欢迎讨论
文中对应的是 1.6.3 版本
在 1.7 版本中官方对于前两个 app 进行了处理
第三个的话更改源码调用一下官方代码即可~~~不过和 1.6 中直接更改源码的方式是类似哒~