好文,后面学习 seledroid 就参照这个文章来撘环境了。
在 google 的规划中,webview 的自动化貌似是用 chromedriver 来做的,和 uiautomator 定位有所不同。
话说怎么那么多人写 xpath 都那么喜欢用工具生成的……自己写不是更灵活吗……
受教了,又学了一个很不错的设计模式!
先收藏了!
这压缩好强悍……我当时下源码搞了一个晚上……
话说下载链接干嘛用代码块……
根据我目前对那两个工具的了解,可能是你的自定义的 view 没有实现 accessibility 方面的方法,你提到的两个工具貌似都是通过 accessibility 服务获取控件的。
帮你找一下分析过这两个工具源码的人,看他的意见吧。@doctorq
#6 楼 @yangchengtest 对,你说的我都赞同,确实目前图片识别技术准确性还不能达到很高的实用价值,但在某些特定场景下(如文中的场景)可以起到很大的辅助作用。
我主要想分享一下它这种另类的解决思路(用较低成本达到较大的产出)而已。
#4 楼 @adfghzhang 有试过像我那样在 sendKeys 前先 clear 吗?效果如何?
#2 楼 @yangchengtest
文中第一部分已经说明图和关键字对应起来放数据库走不通。。。图库量太大了。。。所以要用识图工具。
百度识图不是单纯的数据库比对,里面有识别算法的,当然也包含大数据。简单地说就是它能识别近乎于任意图片的对应关键字,这样即使你图库再大,再怎么更新也不怕。
附上文中提到的知乎的讨论链接:http://www.zhihu.com/question/19738567
额,我分享这个的目的不是想让大家讨论抢票软件本身,只是想让大家开阔一下思维,遇到用常规方法做不了的事情时就突破常规,用非常规方法来解决。
框架/工具用得多很容易局限在它们以内。框架只是辅助工具,如同这里的百度识图一样。我们的价值不是熟练使用各种框架/工具,而是能快速找到合适的方法、采用合适的工具、以尽量快和低成本的方式解决问题。
个人觉得,测试和开发的主要区别就在于测试更需要开阔的眼界和思维,能跳出编程固有的思路来解决问题。这也是我选择做测试的原因之一。
刚刚用 appium 1.3.4.1 的 exe 试了一下(使用 python client):
username = self.driver.find_element_by_id("xxx")
username.send_keys("test")
username.send_keys("abcdefg")
执行完后 username 框的内容为"testabcdefg"
改为:
username = self.driver.find_element_by_id("xxx")
username.send_keys("test")
username.clear()
username.send_keys("abcdefg")
执行完后 username 框的内容为"abcdefg"
@adfghzhang 你可以试试加上 clear() 方法。
从日志上看,有可能是这里出的问题:
Pushing command to appium work queue: ["element:setText",{"elementId":"20","text":"2015-03-20","replace":false,"unicodeKeyboard":true}]
此处的"replace":false
可能会让 sendKeys 在原有字符在不清空的情况下继续输入。
@tspring 能否帮忙让你们组相应组员查查 BOOTSTRAP 这边对于"replace":false
实际是怎么执行的?
我们组这边会看看 1.3.4.1 的 Server 端在
> info: --> POST /wd/hub/session/4adf2a57-f5d7-4c32-9f2d-64621d825d7a/element/20/value {"id":"20","value":["2015-03-20"]}
> info: [debug] Pushing command to appium work queue: ["element:setText",{"elementId":"20","text":"2015-03-20","replace":false,"unicodeKeyboard":true}]
这两行日志之间根据什么设定replace
的。
另外,@adfghzhang 能否提供一下你使用的 client 的语言和版本?谢谢。
PS:我这边使用 python 的 Appium-Python-Client==0.11 作为客户端,Appium 1.2.0 作为服务端,真机使用 Android 4.3,使用 send_keys() 方法会清空输入框后再输入。
果断收藏~
赞一个!
robotframework 的测试用例用文本编辑器写确实比较费劲,而且介乎于表格与编程语言之间,编程的写得费劲,手工的表示看不懂。不过优势是根据编写方式的不同有很强的适应性,既可以关键字驱动,也可以数据驱动或者其他驱动方式。
PS:我们项目目前测试框架的 Mobile 部分就是基于 appiumlibrary 的,实际使用过程中会发现它提供的方法远不能满足项目需要,不少方法还得自己写。。。
#9 楼 @myf_1127 inspector 能正常打开的前提是被测应用已经被 appium 打开了。
对应文档:https://github.com/appium/appium-dot-app#inspector--recorder
有点失落很正常,毕竟是自己带领团队做出来的东西,团队成员未经允许就拿走了,换做我也会失落一段时间。
但换个角度想想,随着业务发展,这些旧代码肯定要修改/重构,他最多也就是带走了一个目前可用的工具,工具不改进很快就会被淘汰的。
至于追究责任,这是公司的事情了,你也没必要太操心。
#24 楼 @weamylady 同上,我也不是大神。我目前对 Appium 以外的框架都停留在了解水平。。。
关于第二个解决方案,那个 js 文件的注释不就写了怎么运行嘛:
/*
* Small tool, launching and monitoring ios-web-kit-proxy, and relauching
* on predefined errors.
*
* Usage:
* ./bin/ios-webkit-debug-proxy-launcher.js [args]
* args: ios-webkit-debug-proxy args (they will be passed over)
*
* Example:
* ./bin/ios-webkit-debug-proxy-launcher.js -c <UDID>:27753 -d
*
* Note:
* For iOS8.1 try this first:
* brew install --HEAD ideviceinstaller
*/
就是装了 node.js 后,运行./bin/ios-webkit-debug-proxy-launcher.js [args]
(这里的路径你自己知道怎么改了吧,参数列表请看https://github.com/google/ios-webkit-debug-proxy说明)。如果是 iOS 8.1,先用brew install --HEAD ideviceinstaller
安装 ideviceinstaller 后再运行ios-webkit-debug-proxy-launcher.js
然后建议你完整阅读这里的文档先:
https://github.com/testerhome/appium/tree/master/docs/cn/appium-setup
解决问题建议首先查文档,然后找官方论坛,然后 google,最后发帖。
你需要的是--full-reset
。
请提问关于 appium 的问题前先看看这个帖子:http://testerhome.com/topics/2182
尽量自己解决,解决不了也至少知道具体卡在那里了
你是不是没有把 appium.app 从 dmg 拷到 application 文件夹……
/Volumes/Appium
明显是挂载的 dmg 镜像地址……
如果后面还有Couldn't find ideviceinstaller
错误,请看官方 issue:https://github.com/appium/appium/issues/2276
工作年限不够……
既然是大公司,建议加上公司名称吧。
PS:最后一句 欢迎资讯 应该是 欢迎咨询 吧?
#34 楼 @mingway_hu 谢谢!抱歉那时候没看到……
#7 楼 @lihuazhang 有这功能吗?
我看到首页的帖子貌似每天都在变,最前面的总是最新的。
我觉得有些帖子还是需要置顶的,可以仿照其他论坛把置顶帖做成合集,甚至把某个 wiki 置顶也行。如【安装包】Appium 国内下载地址(百度云盘,已更新至 1.3.6),这个帖子就很值得置顶。