这种定位方式其实就是根据元素的属性进行定位,但是页面上很多的元素的属性其实基本上是一样的,对于这种元素有没有好的办法进行定位呢
做 UI 先得考虑你的 app 是否合适,是否已经到了比较稳定的阶段,然后就去考虑应用场景,比如用于主流程回归、冒烟等,其次是用例方面的选择,这些都考虑好了,就要考虑易用性,比如集成到 jenkisn 一键执行,方便其他测试同学使用。
至于所说的维护成本高,我觉得只要是做 UI 就得做好成本高的打算,而且 PO 其实已经使维护成本降到比较低了,如果你说开发三天两头就改个 UI,那我不得不说你们的 app 是真的不适合做 UI,不要为了 UI 而 UI,想楼上所说的接口自动化更适合你们。
google 了一个方法,可以通过 adb nodaemon server -a 运行 adb 服务就好了
学习了,最近马上要弄这一块东西,提前了解下
应该是基于 python 的 requests 库,再安装 robotframework 官方的 obotframework-requests 库进行 http 接口的测试的吧
已解决,是 maven-surefire 插件自己的 bug,更新版本后就可以了
针对你的三点进行答复:
@AndroidFindBy(id = "button")
@FindBy(id = "button")
private AndroidElement button;
private By button_by = By.id("button");
另:我查了官方的 pagefactory 文档说明,也没有任何 的显示等待方法,只是有一种更加 “智能” 的隐式等待,即针对某些特定元素设置特定的隐式等待时间,如下方,而隐式等待实际的长短肯定会影响 case 的执行效率,所以还是一个比较慎重的考虑,最好是有能够像 WebDriverWait() 类似的显示等待可以立即反馈。
@AndroidFindBy(id = "button")
@FindBy(id = "button")
@WithTimeOut(time=5000, unit=TimeUnit.MILLISECONDS)
private AndroidElement button;
神奇了, 我降级了也可以用了。。
补充一句, 再次进到 webview 页面, 还是有几率报错 session not created
unittest 主要是方便组织管理运行 case。
我很好奇,你们每个 H5 需求都需要测这么多吗?
据我了解,H5 的需求一般都很快,我们都是测业务逻辑、以及部分兼容性(比如安卓和 ios 自带浏览器减),楼主所说性能、兼容性以及其他专项测试很少涉及,告诉我,真的不是我一个人吗?
暂时没有办法、官方 api 只支持 ios
666、深夜被萌到不行、致敬楼主学习精神
找到一个暂时解决问题的办法,在再次进入一个 h5 页面的时候,先切回 native,然后再切一次到 webview 就可以进行后续操作了,大家可以试试
循环找,没找到就 scroll,找到了就跳出循环并返回元素
碰到个问题,我也是采用 git+jenkins+maven+testng 来进行自动化的,中间碰到个问题,在我执行自动化的过程中我手动点击取消构架的按钮,自动化依然还在跑,然后自己搭了 linux 下的 jenkins 环境查看了下服务器进程,有个 maven-surefire-plugin 插件一直在跑,手动关掉才会停止自动化,有碰到过该问题吗,怎么解决呢?
感谢主办方,感谢分享,这期活动很棒,期待下一次的沙龙
#3 楼 @jinjun0620 还是不行,没有用。
#1 楼 @jinjun0620 是的 chrome 的调试工具是可以识别该页面的,但是卡住的这个时候去点击 inspect 会解析不了页面,提示冲突
试试直接使用 adb 命令模拟事件呢?
adb input tap x, y
之前就觉得 scrollTo 方法不好用,
那这样,打开任务管理器,把 node.exe 这个进程都 kill 了,再重新启动呢
#6 楼 @blue_momo2009 直接 ctrl+c 就好了、然后再输入 appium 启动服务