• logcat 命令有过滤器参数的:
    http://www.miui.com/article-272-1.html

  • 很不错的入门介绍。如果能把各个默认模板都有简单介绍就好了。

    另外解答一下你的问题:

    4.运行程序 building(这个我没有实现,不晓得哪里不对)

    原文的意思:如果你想在 build 后在 Instruments 中运行被测应用,请长按 Run 按钮(像播放按钮的那个),然后在出现的菜单里选择 profile,或者直接在 Product 菜单里选择 profile。(实际上就是在 build 后自动打开 instruments 给你)

  • Appium 主从远程控制执行 at 2015年04月13日

    这个就是 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 的概念和规范。

  • 手机拨号器学习笔记 at 2015年04月13日

    额,其实我也在学习中。。。

    我目前能想到的有:
    单元测试:如果输入的不是号码会如何处理?传个不是号码/非法号码的值给 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,那时候可能就有戏了。

  • appium 检测不到界面控件 at 2015年04月13日

    从 dump 出来的 xml 看到确实有 class 名为android.widget.TextView的元素。而且代码也没看到啥问题。

    鉴于你提到之前检测 webview 控件也有问题。建议你:

    1. 换个电脑试试(检查电脑环境有没有问题)。如果换电脑还有问题换个手机/模拟器试试。
    2. 换个 appium 版本试试(检查 appium 本身有没有问题)
    3. 用 UIAutomator 写个用例,看直接用UISelector能否找到元素
  • 手机拨号器学习笔记 at 2015年04月13日

    基本足够了。我个人有个小问题:不是由button触发call函数的吗?我没看到onClick()是因为截图中没截到?

    下次的话软件代码给出关键代码(如配权限代码、call 函数)就好了。我们这个是移动测试论坛,除了软件开发技术,更关注的是对应的测试技术。后面再发帖的话能配套说一下有什么对应的测试代码(单元测试、UI 测试等)需要写、有什么测试点就更好了。

  • 测试之我见 (二) at 2015年04月13日

    #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
    晚些试验一下

  • #4 楼 @jennyhui 下面回复的那个就是 appium 的主力开发者。他的意思不是加入 toast 录制功能,而是通过这个获取 toast 的方法来实现验证 toast 是否出现。
    我可以想到的基本逻辑应该是在 bootstrap 中起个线程执行类似 toaster app 的代码来关注是否有 toast 出现,如果有就记下来。脚本询问是否有 toast 出现及 toast 的相关信息就用记下来的最新的那份数据来做校验。

  • 手机拨号器学习笔记 at 2015年04月10日

    基本看懂了你想表达什么。不过既然你想让大家都看明白,麻烦不要直接把结论和代码给出来,附上上下文(代码里的 Intent 是什么、怎么用,从测试的角度分析一下这个简单的应用有哪些测试点)或者源代码(github 地址就好)会好很多。
    否则这类学习笔记没必要放到论坛,放在自己博客或者笔记本里就好了。

  • 这帖子干嘛匿名……看到几条重复回复就是为了显示身份的了……
    就像前面的人所说,崩溃的话可以做崩溃分析,有很多现成工具的。你用 monkey 的话把 logcat 中对应这个应用的 Log 截下来给开发,基本开发就知道是什么回事了(logcat 一般会包含启动了什么 activity,执行了什么函数,闪退是由于什么 error 等,开发一看基本就知道你到底做过什么操作了)。monkey 自己的操作 log 用处相对来说不是太大。
    而且按照你们这样的闪退率,崩溃后自动发送崩溃报告这种功能应该是必须的。

  • 测试之我见 (二) at 2015年04月10日

    说的不错,质量意识确实是第一位的。

  • 直接在现有用例里面增加一步来调用 adb 删除 apk 的命令满足不了你的需要?

  • 赞!
    今晚学习内容就这个了!

  • 具体什么弹出框对象?

  • 我不确定 appium 是否支持使用网络位置作为 app 路径。
    你试试用本地绝对路径?
    另外,最好把 server 从接到 request(一一>) 到返回 response(<——) 的完整 log 都贴上,更方便看执行了什么步骤

  • 可以看看这里
    http://nowherewoman.com/selenium-handle-wait/
    我不大清楚 appium 是否实现了 wait,你可以试一下。