#48 楼 @james88233 最近没在做。
logcat 如果程序没出错基本不需要看，但出错了你就必须看了。你可以改一下 logcat 的 level，让它不要所有 log 都输出来就好了。

#46 楼 @chenhengjie123 请问你是在做 android 的测试吗？那么它生成的 logcat 你会看吗？这个东西具有什么样的价值？我看跑一条 1 小时的 case 生成好几万行的 logcat，看的我一头雾水

#46 楼 @chenhengjie123 受教了 谢谢

#45 楼 @james88233 appium 既可以测 iOS，也能测 android 的啊。测这两个平台除了一些设置参数不一样大部分一样的。
python 简单是相对于 java，C 而言的。无论学什么，多练都是必须的。如果它简单到一两天就能熟练使用，那么它能做的事情会变得很有限。
入门 python 推荐看看《a byte of python》，网上有免费 pdf

#44 楼 @chenhengjie123 我感觉我还是没有入门。。。都说 python 简单，我还是出了英文什么都看不懂。。。那你用 python 写的脚本面向的测试对象都是 android 的设备吗？ios 上能用么？

#43 楼 @james88233 别叫我大师，我还很年轻……
新发现是指什么新发现？最近在学习 appium 源码 +android 开发。
语言的话我主要用 python 啊。我目前做自动化测试主要用 python，写起来比较简单。

#41 楼 @chenhengjie123 大师 最近有什么新的发现吗？你用什么语言编写 ios 测试的脚本呢？

#41 楼 @chenhengjie123 谢谢 我马上去看

sample code 在另一个地方：https://github.com/appium/sample-code
建议你先读文档，有个大概了解（特别是可能出现的问题和解决方案），再去跑 sample code。
否则直接跑 sample code 你会遇到很多问题不知道怎么解决。

#39 楼 @chenhengjie123 呵呵 追赶大师的脚步，不过我在您说的网站https://github.com/testerhome/appium/tree/master/docs/cn/ 里搜索 sample code 并没有相关的介绍，是不是必须要把 ios 环境配好，appuim 也装好了才能调用那些 sample 查看？

#38 楼 @james88233 我又升级了。。。你看完文档后自己参考 sample code 写一写简单的脚本，你对怎么用 Appium 应该就大致了解了。
webdriver 已经封装好很多方法，你直接拿来用就好了，方法名称和用法还是挺直观的。

#37 楼 @chenhengjie123 感谢大师，更清楚了。我的目的就是 UI 的自动化测试，主要是第三方 app 的

#36 楼 @james88233 额，我这是个比喻。。。这个 “server”（实际上不一定是个 server）没有执行命令时和你平时把一个应用放在后台的压力差不多，不会把手机拖慢的。而且你没有运行 appium 脚本时，这个 server 什么都不会做。
另外，自动化测试有分很多种，Appium 主要是 UI 自动化。而压力测试是另一种自动化，性能测试又是另一种自动化。UI 自动化的目的主要是保证功能的正确性（在 UI 层面），至于是否完全模拟用户操作取决于你的 “完全” 定义是什么。如果说和用户实际操作顺序/动作基本一样，这个是没问题的，如果你说连输入方式都一样（例如输入中文还能通过拼音 + 选字/手写来输入）这个不行。
自动化不是万能的，至少不能完全替代手工测试。但用在适当的地方会很有用（例如需要重复执行的、基本不会再变化用例，如回归测试的用例）。

#35 楼 @chenhengjie123 谢谢 我马上去看 十分感谢 以测试的角度，在手机上另外开一个小的 server 是不是会对测试结果产生未知的影响啊。。。比如给手机一些非 enduser 所带来的压力？是不是就不能完全模拟用户操作了？

个人建议你看看 Appium 的一些文档：
https://github.com/testerhome/appium/tree/master/docs/cn/
这些文档都看完的话，你对 appium 基本有个整体了解了。

#33 楼 @james88233 额，先澄清一下，我不是老师，我也在学习中。。。
Appium 的运行原理是通过 appium server 操作 Android UIAutomator（Android 4.3 以上）/Selendroid（Android 4.3 以下，2.3 以上）/UIAutomation（iOS），这些操作通过网络通讯进行控制（你可以理解为在手机上另外开了一个小的 server），而不是简单的翻译成其他其他语言的脚本。
原封不动地跑起来这个可能性不大。因为界面是不可能完全一模一样的。即使你看起来是一模一样，但页面实际布局方式、控件的 id 等基本不会一样，所以元素的定位方式会不一样。但如果把元素定位分离出来做成独立的存储库（如 excel），脚本可重用性会高很多。
简单的说，一个元素的 click 方法在 Android 和 iOS 都能用，效果都一样。不同的是你查找元素的方法有很大可能会不一样（毕竟源码不可能一样）。

单种语言实现跨平台操作这个听起来很高大上，实际上就是通过网络通讯实现嘛。网络通讯用来发命令（语言无关，如使用 json 格式），接收方（Android 用 Java，iOS 用类 javascript）只要能识别这个命令并执行操作就好了。

#31 楼 @chenhengjie123 我再追问一下：Appruim 遵循 webDriver 规范，使得单种语言实现跨平台操作成为可能这个怎么理解？好比说我用 java 写了一条关于微信的测试脚本，在安卓手机上运行没有问题，是不是通过 appium 可以原封不动地让 iphone6 也跑起来这条 case 啊？这其中的原理您能不能给我简单说说？

#31 楼 @chenhengjie123 谢谢这位老师的解答！太感谢了。我对 Appuim 又多了一分了解，也就是说没有编程基础的人用 Appuim 来做 ios 自动化测试很困难吧？我只会一点点 java，以前是做 adroid 自动化测试的，也就是会调用已经封装好的方法执行个脚本，这种程度。现在让我做 ios 的自动化测试，出了问题是不是很大的麻烦？因为按照我目前的理解，我写的 java 的脚本是会被 Appuim 转译成 ios 认可的 JSP 或者其他语言的脚本执行的对吗？我有 UDID 绑定了开发者账号，目的是做真机的 app 自动化测试。

#29 楼 @weamylady 额，我现在也才刚申请到 mac，刚开始用。不过研究 appium 的时候跑过一下它自带的用例，就以我的了解给些参考吧：

1、你指的 绑定 UDID 是指绑定 UDID 到开发者账号吗？如果是，这个是一定要的。真机调试必须绑定 UDID（除非你是 299 美刀一年的那种高级开发者账号，有 in-house 分发功能），否则你的 app 只能在模拟器上跑。至于 in-house 分发的能否通过 appium 来做自动化测试，我没试过，所以不清楚。

2、优点是遵循 webdriver 规范，可以使用各种语言的 client 编写，支持真机、webview，而且基本不需要改动应用代码。缺点的话环境配置可能算一个（要装的东西有点多，不过都是 iOS 开发必装的），不过因为没怎么实际用过使用其它方式做 ios 自动化测试的框架（如 calabash, monkeyTalk），所以也比较不了太多。

3、执行效率和人工点击不会相差太大，某些时候甚至会慢一点。不要想着会有 selenium+web 那样飞一样的速度，因为移动设备的 UI 有很多切换动画，即使做到这么快的速度你也会因为动画不得不放慢速度。不过优势是重复执行不需要花费人力。

4、没有代码基础的话难度相对于 MonkeyTalk 比较大（有录制和没录制的质的区别）。其实 Appium 的最大优势是遵循 webdriver 规范和基本不需要改动被测应用。如果这两点你都不需要，那么最容易产生产出的应该是 MonkeyTalk。

#29 楼 @weamylady 谢谢 反应的如此迅速。我是一个不懂编程的门外汉，但是为了饭碗我必须要学会用自动化测试工具，请多多指教。Appuim 这个工具是老大给我的第一个研究任务，我希望得到各位的帮助，我想知道这款开源的软件现在发展到什么程度了？用 java 给 android 写的脚本也能在 ios 的系统上执行吗？（假如 UI 完全一样）

#28 楼 @james88233 Appium 的代码部分都不是很难，自动化测试的难点在于自动化的实现策略、脚本的管理和维护、执行记录结果管理和统计等等。在开展代码编写之前最好要有一个框架的概念，各个难点怎么去解决，结合项目实际的需求制定一个可行的详细计划。如果想着摸着石头过河的策略先上来直接看着案例写脚本，后续你会掉入很多很多的坑。
iOS Appium 我以前接触过，但是由于现在的项目还没有环境未实际在项目中使用，你可以请教一下 @chenhengjie123

我也是一名自动化的 tester，很初级的那种，这两天正在调研 appuim 这款工具，请问上面的各位大神：
1.如果我选择用 appuim 来做 ios 的 app 测试的话，需要绑定 UDID 吗？
2.appuim 对于 ios 的 app 测试来说它的优点和缺点都有什么？
3.执行效率和人工点击比相较如何？
4.如果我没有代码基础，appuim 这款软件对于要做 ios App 自动化测试的我来说开荒难度有多大？

烦请大神指教@weamylady

Monkeytalk 需要安装 ajdt，但是我下载之后装不上是什么原因？Win7 64 位，有人碰到这个问题没？

#24 楼 @weamylady 同上，我也不是大神。我目前对 Appium 以外的框架都停留在了解水平。。。

#24 楼 @weamylady 你可别误导别人，我不算大神。

#23 楼 @april46 你可以向真正的大神请教请教。@seveniruby @monkey @lihuazhang @doctorq @chenhengjie123

#22 楼 @weamylady 非常感谢你的回复。。。对我非常有用~。。。就因为这些问题考虑的太多。。。至今也没有找到一款工具。。。Android 的话，初步想用 Robotium，但是 iOS 还没决定~

#21 楼 @april46 主要看你们的需求了，App 类型是 Native 还是 Hybrid？是否允许测试版本中插码？功能测试案例中是否可以全部在手机上完成 (有一些验证是否需要在 PC 查询数据库等等)？是否考虑集成到现有的测试框架、案例管理平台？是否由专门自动化测试人员编写脚本，还是推广到业务测试人员来编写自动化案例 (需要封装，封装效果不同，所需的技术能力也不同)？自动化实施的紧急程度？
先列个表格，对所有知道的工具进行一下总结，再对应自己的需求来确定工具吧。开源的工具一般对使用人员的编码能力有一定的要求，如果想降低门槛提升实施的速度可以考虑购买一些收费的软件，例如 HP、IBM、腾讯、Borland、Soasta 以及各大外包公司都会有这一类的服务的。

#15 楼 @weamylady 看了你的文章和大神的各种回复，真是学到饿了。。
真的要和你握握手了。。。我也对 UiAutomator、Appium（Java）、Robotium、MonkeyTalk，MonkeyRunnner 等工具都进行了一定的了解和尝试。老大想让我找一个可用的工具。。。我半天也没找好。。。最近在看 MonkeyTalk~~~可以 iOS 连不上真机。。。。我试了一个网段的。就是连不上。。。高大的开发不给代码，so，我也没法用模拟器。你有什么建议吗？

#19 楼 @farrah 我也是新手，共同进步吧！^{_____^}

#17 楼 @weamylady 向各位大神学习了，我也在学习 MonkeyTalk，现在也是在做 APP 测试，希望拜读你翻译大作。

#17 楼 @weamylady 好 我也想了解下他的技术细节 看看是不是有改造的空间

#16 楼 @seveniruby 我这星期已经把 MonkeyTalk 英文文档都看了一遍了，回家准备在论坛上把它们全部翻译成中文^{__多一个人使用，以后就有多一个交流的人。}

#15 楼 @weamylady 国外最近几年流行 in-app 技术 功能 性能 安全 监控 运营都以 sdk 的方式来做 这也是未来主流 结合运行时插桩技术 也可以做到非常的易用 appium 的确有点重 有点慢 不过使用 selendroid 模式 应该会好些 两套工具感觉都不错 录制器 appium 也有 不过不够好 我有时间也好好研究下 monkeytalk 看

#14 楼 @seveniruby 谢谢建议！ 我对 UiAutomator、Appium(Python)、Robotium、MonkeyTalk 等工具都进行了一定的了解和尝试。不选 Robotium 的主要原因是它无法在脚本执行中查询数据库来 Verify 案例执行结果 (它需要重签名并把执行脚本打包成 app 放到 device 端执行)，我们的 case 中有这个需求；以前用过两年的 UiAutomator，它灵活性更低，还不如 Robotium；Appium(Java) 也仔细研究过一段时间，的确可以很好地满足我们的需求，主要考虑到它执行的速度实在有点慢~ 而且没有录制功能；MonkeyTalk 也可以满足我们的需求，而且更加轻量级、好封装、执行速度快，所以才在 MonkeyTalk 和 Appium 中间进行对比选择一个。
云测平台只有简单的兼容性测试是比较合适我们项目的 (我们 App 的兼容性目前没有发现问题)，我们 App 功能测试对环境的要求很苛刻，云端要部署我们的测试环境会非常的麻烦。

#12 楼 @weamylady 目前国内的云平台都只是简单的支持上传测试 apk 所以还是首推 robotium 如果你需要自己维护较多的设备做兼容性测试 那 appium selendroid 可以考虑 selendroid 资料更少 appium 封装了 selendriod 所以可以看看 appium appium+robotium 基本可以满足所有需求

#11 楼 @seveniruby 学习了。

#11 楼 @seveniruby 多谢兄弟详尽的答复！我们邀请过 Soasta 人员来讲解过，就是觉得他们产品捆绑销售太贵了 STO 我后续会研究下 Selendroid 以及问问 MonkeyTalk 的服务

总体来说, 我看好插桩的框架. monkeytalk 算是做的很好的自动化框架之一. 是个成熟的商业化产品 .国外的云平台也有支持 monkeytalk 脚本的.

基于插码的框架不一定都需要开发者配合, 有一些技术手段是可以绕过的. 所以也可以做到无植入.好像 monkeytalk 在专业版中也已经提供了这个功能.
插码的好处是很多的. 比如可以获得更多的数据和更高 level 的行为录制. 将来插码的框架会大行其道的.
基于外层黑盒的测试框架, 比如 uiautomator 之类的, 使用的场景是非常受限的.

目前 appium 的 github star 数是一千多, selendroid 是一百多, monkeytalk 代码藏的很深,得不到详细的数据. 不过他的生态倒是很丰富. 这家公司做的应该也会比 robotium 更深入. 我目前对他们了解的还不多.

appium 的缺点也很多, 第一个是 nodejs 开发的, 而且扩展机制没做起来.导致扩展起来需要较多的工作量. 第二个是他的测试用例, 已经不再跨平台. 不像老版本那样提供抽象封装了. 当然我们自己可以在上层再封装.
我更看好 selendroid 框架. 遵循标准协议, 开源, 而且有固定的公司维护. 只是他们的维护力量赶不上 saucelabs 和 cloudmonkey. 生态太弱.

MonkeyTalk 对比 Appium
1，MonkeyTalk 支持录制功能 (Appium 目前在 Android 上没有录制工具)，而且录制更能更加强大而简单。
目前还没一个好用的录制工具. 是真的, 我挺看重录制器的, 不过没有一个做好的.
一个好的工具是不应该把代码,编译等环节暴露出来的.

2，MonkeyTalk 的执行速度比 Appium 快 5 倍以上 (亲测执行速度快的飞起！)。
这个的确是的, 它的速度应该是介于 robotium 和 appium 之间. appium 的定位方法较慢. 尤其是是 uiautomator 模式.

3，MonkeyTalk 编码简单，代码更加简单易懂（更类似与 Robotium 的风格）。
这个肯定没有 selenium 的 webdriver 标准 api 更清晰. 已经成为行业标准了

4，MonkeyTalk 不需要另外搭建 Server，脚本直接与 Device 上的 Agent 通信。
其实 appium, selendroid 都是可以和 agent 通讯的. 他们选择了做一个 server 是基于架构考虑.
尤其是当在很多设备上并行执行测试的时候. 屏蔽具体的设备, 提供集群管理还是很有用的.
绕过 appium 的 server, 直接跟 agent 通讯也是可以的
设备上运行的逻辑不宜太重. 不然会影响设备性能.
理想的架构是一个 server 管理所有设备, 这样每个设备上的一些通用逻辑就不需要在不同的平台上重复实现了.

5，MonkeyTalk 自带有日志输出功能，可自动生成 xml 报告，Appium 没有此功能。
appium 使用 xunit 框架, 也照样有日志输出功能. 不知道 monkeytalk 的内容有哪些. 这方面没经验.
appium 自身的 xunit 可以基本使用. appium+robotframework 提供的报告也很强大.
至于关键词驱动, 报表之类的,其实都是外层封装, 这个实用但是只要遵循标准的框架协议, 基本都可以做到不错效果的. 比如 appium+RobotFramework 的报表. 或者其他的基于 xunit 的一些 jenkins 图表扩展.
monkeytalk 是个商业产品,这方面应该也做了不少的定制.

总体建议是, 如果是个商业性的不差钱大公司, 自身的技术力量薄弱, 可以适当考虑 monkeytalk 这种商业级别的产品.

#9 楼 @weamylady 嗯。我觉得腻如果职责所在，其实如果自动化不能实现，就做半自动化，或者提升效率提升的工具，这点方向我觉得很对的。

其实职责的融合是一个趋势，是公司的一种方向。但我并不是说要改变现状，不是改变，是一种过渡。腻说的那些素质放在那边的人压根就不会纯做手工了，就是会被淡出市场。我是这个意思。＝ ＝

#8 楼 @monkey 确实每家公司的项目不一样，自动化的作用不能一概而论。对于版本迭代频繁改动多的新产品，回归测试自动化就能节省很多人力 (例如我上家公司)；对于产品特别稳定改动少的应用来说，UI 自动化作用就不大。T_T 我们现在产品属于后者，不能为了自动化而自动化，但是我的职责就是这个。目前我也就想到了两个方向：1，兼容性、app 性能监控、分析方向；2，辅助测试工具推广/编写，例如 Emulator、DDMS、MAT 等，这些也属于自动化范畴，只要能对项目有所帮助，能节省人力物力。
另外，技术测试和手工测试虽然会有融合趋势，但是我觉得这个只是个理想，毕竟人员素质放在那儿，不是说培养就培养的。

#7 楼 @weamylady 嗯。是的。其实之前你说的都是对的。但我其实主要就觉得，其一，技术测试和手工测试其实没有那么大的区别了慢慢的，而且现在也是这样一个合并的趋势。其二就是，其实现在很多人讨论来讨论去都是 UI 的框架，而 UI 的框架门槛高不高，其实推不推在目前 app 层面的测试我感觉效果都不会太大或者太小，总而言之，不是那种决定性的作用。

#6 楼 @monkey 自动化测试的推广感觉还是要简单化，手动测试人员会录制运行脚本就行了，越简单越好。至于深一步的工具研究脚本编写啥的，还是交给技术测试吧。让技术测试人员去实现所有的案例脚本的工作量太大了，而且业务也不熟悉，所以我觉得 MonkeyTalk 的门槛比较低一点适合推广，Appium 要求门槛比较高，推不动，就怕最后的结果是我们天天在那里写脚本、维护脚本。@monkey大神怎么看？

#5 楼 @lihuazhang 现在用啥都属于这样的 level。。。测试本身定位不清楚，所以真还不如自己去做开发

#4 楼 @weamylady 他们用的厉害，不代表他们真正用的厉害。基本都是开发帮插桩，然后他们录制录制脚本。我问过 4 个微策略的人，基本停留在这样的水平。

#3 楼 @lihuazhang 我猜国内少人用的主要原因还是因为要插码吧。国内绝大部分公司的测试人员都不允许接触源码的，开发人员高高在上，想插码真是难过登天哎 >_< 哥们有听微策略的人说起 MonkeyTalk 还有什么致命缺点没？ 我在做工具预研，希望可以听听经验人士意见。

#2 楼 @weamylady 嗯 我知道 我粗略看过。 因为微策略公司用这个用的比较多。然后微策略裁员出来面试的人比较多。都会说起这个 MonkeyTalk。

#1 楼 @lihuazhang MonkeyTalk 的 Pro 版本没找到有开源的，但是普通版本在 Github 上有源代码的

MonkeyTalk 部分开源吧。而且需要植入。