赞!收获还是不少的嘛。
建议后面麻烦排一下版,不同部分加一下小标题,代码用代码块,该加粗的加粗一下,该留空行的留一下空行。方便阅读。
请提供你的环境信息:
appium 版本
appium 类型(npm,app,exe,源码)
另外,试试brew install ideviceinstaller
,不知道brew
是什么麻烦自行百度。
#17 楼 @nancy2896 想法不错,你这个逻辑其实就是 waitForElement 的逻辑,问题在于 UIObject 取不到 toast。。。toast 不会出现在 dump 出来的 xml 中。
目前能获取 toast 的框架(Robotium,selendroid)都是通过 instrumentation 内的 getView() 方法获取(方法名我不是很确定是不是这个),不是 uiautomator。
#15 楼 @nancy2896 就是因为 uiautomator 没有这个 API,所以我们要另外想办法搞。。。
#11 楼 @springs412 你先确认一下从主机访问从机的入口(如http://172.17.6.173:4723/wd/hub
,172.17.6.173
是从机地址)看能否访问?
如果不行,检查一下网络(防火墙、是否在同一网络等)
appium server 在从机打开就好了。
logcat 命令有过滤器参数的:
http://www.miui.com/article-272-1.html
很不错的入门介绍。如果能把各个默认模板都有简单介绍就好了。
另外解答一下你的问题:
4.运行程序 building(这个我没有实现,不晓得哪里不对)
原文的意思:如果你想在 build 后在 Instruments 中运行被测应用,请长按 Run 按钮(像播放按钮的那个),然后在出现的菜单里选择 profile,或者直接在 Product 菜单里选择 profile。(实际上就是在 build 后自动打开 instruments 给你)
这个就是 WebDriver 的 RemoteDriver 的特性吧。Appium 本质上是一个 RemoteDriver(最早的时候它的 client 用的就是 RemoteDriver)。只要网络能联通,client 与 server 之间无论是否在同一台机器上都没问题的。
如果是用其他 webdriver(如 ChromeDriver),也可以用 SeleniumRC 来作为远程服务器,然后 client 连去服务器进而控制远程机器的 webdriver。
你的 URL 有很明显的问题,所以会出错。
这个 URL("http://127.0.0.1:4723/wd/hubappium")是 server 的 REST API 入口,至于入口为啥是这个、后面具体怎么使用请了解一下 WebDriver,RemoteDriver 的概念和规范。
额,其实我也在学习中。。。
我目前能想到的有:
单元测试:如果输入的不是号码会如何处理?传个不是号码/非法号码的值给 ACTION_CALL 会有什么后果,根据这个后果是否需要在传入前校验?(大多数拨号盘只有合法字符,而你使用输入框,所以需要自己做非法字符的处理)
UI 测试:UI 兼容性如何(2.x,4.x,主流手机系统,各个分辨率)?输入框或按钮在某些情况下会否被挡住(如低分辨率下)?
功能测试:没有获取到权限的话拨号功能会怎样(不少手机系统默认不给权限),是否有清晰的错误提示?输入非法字符是否能提示?点击按钮后是否能正确调用拨号应用?
推荐你看看剪烛 mm 的这个帖子,里面说得比较全面:
http://testerhome.com/topics/2272
#6 楼 @azdbaaaaaa 如果领导指明要求搞自动化,我觉得你可以和领导私下交流一下,搞清楚领导搞自动化的真正目的是什么,然后对症下药。有些领导搞自动化是为了业绩,那你可以搞一个简单的自动化平台给他(推荐搞个比较成熟且领导容易体验的,能够快速录制来更新,例如 MonkeyTalk),能够以最快速度搞出一个看起来很牛的用例。如果真的是为了软件质量,那得先看看哪里稳定了(除了 UI,还有接口、单元测试等可以做自动化的),然后对稳定的模块做自动化。
自动化是为了减少重复劳动。没有重复劳动搞自动化没啥意义。自动化如果经常要维护,那你想通过自动化降低手工成本其实不可能(一个用例跑一次就得改一次,改完还得调整,还不如直接手工),至于维护质量就更加无从谈起了(自动化用例的质量都保证不了,怎么保证软件质量)。
其实自动化不一定是测试的自动化的。你能把打包、部署这些搞到全自动化(其实就是一键完成)其实帮助也很大的。因为这些基本都是重复劳动。
UI 自动化投入产出比不是太高。之所以大部分人喜欢用是因为它可以直观地看到执行过程。
从你的描述来看,你的问题在于软件更新太快(特指 UI 层面),导致维护成本高。
对于这种问题,建议你找个可以录制的 UI 测试框架(如 MonkeyTalk)来做半自动化(不是全自动化,要有人在那里看着的,因为录制的结果大多不带有校验,不过你录脚本的时候其实也把测试用例执行完了。。。),达到尽量降低自己的劳动量的目的。
纯 UI 自动化其实和单元测试差不多,只是 UI 自动化只关注 UI,单元测试关注功能实现。目的都是保证版本没被改坏。自动化最大的意义就是以最快速度验证功能的正确性,并以最低成本定位问题代码,就如软件工程里所说,一个 bug 在刚出现的时候被发现的话,修复成本最低,越到后面修复成本越高。
举个例子:
开发提交了代码,然后 CI 上跑一下测试用例,发现这个版本的一些基本功能被改坏了,开发赶紧再去 review 一下刚提交的代码哪里有问题,赶紧 fix。否则一个包含了数十个提交的版本在手工测试的时候发现 bug,然后开发还得从几十个提交中慢慢找是哪次变更导致这个问题出现。
想法很好,但测试必须用到的 SDK 苹果没有开放给 windows 用(估计后面也不大可能开放给 windows),所以目前没有解决方法。
Android 能全平台都能跑是因为他的 SDK 主要用 java 写且支持跨平台。
也许某一天有人能把 SDK 移植到 windows,那时候可能就有戏了。
从 dump 出来的 xml 看到确实有 class 名为android.widget.TextView
的元素。而且代码也没看到啥问题。
鉴于你提到之前检测 webview 控件也有问题。建议你:
UISelector
能否找到元素基本足够了。我个人有个小问题:不是由button
触发call
函数的吗?我没看到onClick()
是因为截图中没截到?
下次的话软件代码给出关键代码(如配权限代码、call 函数)就好了。我们这个是移动测试论坛,除了软件开发技术,更关注的是对应的测试技术。后面再发帖的话能配套说一下有什么对应的测试代码(单元测试、UI 测试等)需要写、有什么测试点就更好了。
#6 楼 @james88233 我觉得会写代码和走自动化其实是两回事。
作为 IT 行业的一员,会写一些代码应该是基础技能(不要求能做很厉害的代码,但脚本基本应该是能写的)
目前能真正提高工作效率的测试用例基本都不可能使用纯录制(不能加验证是纯录制的最大缺点,而且纯录制复用度比较低)。
我觉得如 @lihuazhang 所说,测试要不往业务走(开发基本不可能精通业务),要不往开发走(不是指测试开发,而是懂得开发、懂得测试的且主要写测试代码的人)。
至于用户体验,那是 PM 和 UI/交互设计主要做的事情,测试提一下也行,不过大多会被忽略(在这方面没有话语权啊)。。。
#7 楼 @monkey 你这个是 waitForElement 这个方法的通用实现,确实和你说的一样,隔一段时间去 find 一下元素,直到超时或符合预期。但用在 toast 上默认 5s 的等待间隔太长了 (long 的 toast 是 3.5s,short 的是 2s)。所以对于 toast 应该有特殊处理,把时间间隔调低。
我觉得思寒想了解的是 selendroid 的 waitForElement 在查找By.partialLinkText("Your Toast message")
时是怎么进行查找的,即怎么调低默认时间间隔,findElement
怎么做到能支持查找toast
的吧。
从这个 API 的 By 属性来看,应该有做什么特殊处理的。否则光靠partialLinkText
内容来查找 toast 信息不是很准确,原因是上面 Accessibility Service 返回的 Event 信息除了包含 toast 还包含 Notification,不做进一步判断分不出来。
#5 楼 @seveniruby 好,后面我再详细看看它的实现。
#3 楼 @kasi 是的,我找到她的帖子了:
http://testerhome.com/topics/1483
不过她写的是 robotium 的。我这个主要面向 appium 。我这个文章主旨是通过 appium 那个帖子探究一下能通过什么方式获取到应用 toast 。
嗯。刚查到:
https://github.com/selendroid/selendroid/issues/86
晚些试验一下