从你的 log 看,你的 adb 执行
"D:\Program Files (x86)\seleniumTools\adt-bundle-windows-x86-20130917\sdk\platform-tools\adb.exe" -s emulator-5554 "shell \"echo 'ping'\""
这条命令时出错了,把 adb 命令的帮助信息打印出来了。(看起来是命令有语法错误,不过我之前没遇到过,需要你给一下 appium 版本才能确认)
然后由于这个出错,appium 重启了 adb server。然后后面出现了:
info: [debug] Starting logcat capture
info: [debug] Attempting to uninstall app
info: [debug] Not uninstalling app since server not started with --full-reset
info: [debug] Cleaning up android objects
info: [debug] Cleaning up appium session
表示终于成功连上设备了,但在它准备卸载应用时由于 appium server 启动参数中没有加入 --full-reset
,所以没有卸载,然后就关闭 session 了。
建议你把测试脚本完整代码、appium 版本、appium 启动参数都提供一下。
PS:代码块不要用引用语法。。。看得比较痛苦。。。
最好的资料就是 appium 官方的文档。
#4 楼 @xcgspring 关于你这个框架,我大致看了一下介绍,有些问题想问一下。如果问得不好或理解不对的地方,请见谅:
1、 你的目标群体是什么?手工测试人员/写过自动化脚本的人/对自动化测试和开发都有较深入了解的人/开发?看了你的示例代码后感觉前两个类型的人不一定搞的定,后两个类型的可能会偏向于使用符合一些规范的工具,如 selenium,selendroid,appium,他们都符合 webdriver API 规范。
2、从你的描述来看,你希望解决的痛点是 如果没有好的编程经验,一段时间的迭代之后,测试脚本库就会臃肿不堪,没法维护,于是我们又得重写脚本 , 对于 tester,换一个项目的成本很高,之前项目的经验有时候很难在现有的项目复用,但通过你的示例代码我没看出 AXUI 对于这两个痛点有很好的解决办法(目前只发现它相比 webdriver 多了对 windows desktop 程序的支持)
3、把 UI 逻辑和测试脚本分离是一个很好的想法,但通过 xml 来实现会不会导致易用性/可读性不是太友好?而且 selenium 的 PageObject 设计模式也能做到类似效果。
4、通过扩展支持更多 API 这个想法也很赞,而且拓展方法看起来也不是太复杂。不过你的框架本来是为了 windows desktop 的 UI 自动化设计的,让它完整支持其他 API 会不会有难度?通过扩展支持大量平台的测试框架目前我比较了解的是 robotframework ,它的办法是 API 什么的都不限定,只限定用例的编写格式,降低跨平台用例的学习难度。
请附上 appium server 的 log 。
光凭上面你给的信息定位不了原因。
升级是指使用其他浏览器?
你可以看看 crosswalk,把 chrome 内核打包到 app 中。
#6 楼 @wangquan2596489 麻烦更新一下标题并把尽量详细的解决方案附到正文中,方便后面的人查看。谢谢!
#3 楼 @wangquan2596489 好吧,刚才细看了一下你的 log,问题不止 ideviceinstaller :
info: [debug] Starting iOS device log capture via deviceconsole
error: Log capture did not start in a reasonable amount of time
info: [debug] Cleaning up appium session
error: Failed to start an Appium session, err was: Error: Log capture did not start in a reasonable amount of time
info: [debug] Error: Log capture did not start in a reasonable amount of time
at null._onTimeout (/Applications/Appium.app/Contents/Resources/node_modules/appium/lib/devices/ios/ios-log.js:137:10)
at Timer.listOnTimeout (timers.js:110:15)
你把 deviceName 补充上去吧。具体要用什么 deviceName 参照 https://github.com/appium/appium/blob/master/docs/cn/writing-running-appium/caps.cn.md
装了之后重启了 appium server 了吗?
正常来说装了之后应该就没问题了。即使有问题,也不会是同一个问题。
brew install ideviceinstaller
。appium.app build-in 的貌似是那个用不了的。不知道什么是 brew 的请搜索 homebrew #1 楼 @lihuazhang 在它的文档找到这段:
AXUI provide built-in drivers for:
windows native UIAutomation Client API for windows desktop UI
selenium project for web UI
appium project for Android and IOS UI
和
AXUI is first developed for easy use of windows UIAutomation API, then restructure to add support for WebDriver API used by selenium
and appium
. So if your UI automation is similar to windows UIAutomation API or WebDriver API, it will be easy to add support for it in AXUI.
应该是可以通吃的。只是最主要支持的是 windows desktop ,然后扩展支持 webdriver 。
#4 楼 @fanlei1014 麻烦更新一下标题并把尽量详细的解决方案附到正文中,方便后面的人查看。谢谢!
在网上查到用 adb 命令可以切换输入法:
http://www.itcao.com/post_1291.html
但切换后会不会对 appium 输入有影响就不大清楚了。
那可能是多看的 app 没有开 web debug 了。
从日志上看,chromedriver 起来后 appium server 就没有收到 client 的任何请求(卡在 chromedriver 的开 session 这里了,appium 发送了开 session 的请求后 chromedriver 一直没有反应),所以 session timeout 退出了。
原因应该是因为切换 context 这个请求一直没有返回消息给 client 端,所以 client 一直停在切换 context 那一行等待 server 的返回消息,即切换 context 后的所有代码都没有执行过,所以你说的找元素和取源码都没有效果。
建议的解决方案:
这个就是我想让你做的封装啊。把你原来的 swipe 代码做成更通用的形式。
封装只是专业点的说法,说白了就是把你原来要几行代码干的活放到一个函数里一次性搞定嘛。
PS:这不能说是缺陷,是 webdriver api 没有这个方法而已。
#15 楼 @mzl19860128 这不是模拟器与真机的区别,是你的手机 ROM 和原版系统的区别。模拟器运行的是原版系统。
你再换个 4.4 的手机试试吧。
#13 楼 @mzl19860128 你升级后的 Android SDK Tools 版本是多少?应该至少 24 以上了。
确认版本够高后,你用个 4.4 的模拟器试试?
虽然可能性很低,但还有可能是真机的系统对 uiautomator 部分做了更改。如果 4.4 模拟器可以那就可以排除 uiautomatorviewer 的版本问题了。