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
晚些试验一下
基本看懂了你想表达什么。不过既然你想让大家都看明白,麻烦不要直接把结论和代码给出来,附上上下文(代码里的 Intent 是什么、怎么用,从测试的角度分析一下这个简单的应用有哪些测试点)或者源代码(github 地址就好)会好很多。
否则这类学习笔记没必要放到论坛,放在自己博客或者笔记本里就好了。
这帖子干嘛匿名……看到几条重复回复就是为了显示身份的了……
就像前面的人所说,崩溃的话可以做崩溃分析,有很多现成工具的。你用 monkey 的话把 logcat 中对应这个应用的 Log 截下来给开发,基本开发就知道是什么回事了(logcat 一般会包含启动了什么 activity,执行了什么函数,闪退是由于什么 error 等,开发一看基本就知道你到底做过什么操作了)。monkey 自己的操作 log 用处相对来说不是太大。
而且按照你们这样的闪退率,崩溃后自动发送崩溃报告这种功能应该是必须的。
说的不错,质量意识确实是第一位的。
直接在现有用例里面增加一步来调用 adb 删除 apk 的命令满足不了你的需要?
赞!
今晚学习内容就这个了!
具体什么弹出框对象?
我不确定 appium 是否支持使用网络位置作为 app 路径。
你试试用本地绝对路径?
另外,最好把 server 从接到 request(一一>) 到返回 response(<——) 的完整 log 都贴上,更方便看执行了什么步骤
可以看看这里
http://nowherewoman.com/selenium-handle-wait/
我不大清楚 appium 是否实现了 wait,你可以试一下。