注：本来这封信要发给Wonerfei网友的，可是由于每次仅仅能发200字，所以干脆贴到博客上，叫Wonderfei同学到这上面来看，也算是我自己的一个暂时总结吧。同一时候也希望大家给予Wonderfei对应的帮助,毕竟我自己的观点不一定正确和完整。
Hi Wonderfei,
你好，因为我是博客新手，所以没有留意到你给我发的私信，不好意思。
首先因为我自己也是个新手，也是在学习各种框架然后给公司项目选定对应自己主动化框架，研究移动自己主动化測试框架也就近段时间而已，所以我仅仅能从我自己今天为止的认知角度给各个框架抒发我自己的拙见，你看能否从中接纳一二吧（对于我自己的话还须要再花一段时间去学习各个框架才干确定哪个/些是适合我们项目的了,或许到时我会写个正式的总结)。
依据你的要求，应该不会考虑MonkeyRunner和Robotium，但我还是想跟你说下事实上Robotium还是挺不错的，假设你没有考虑跨进程调用其它APP的话。至于MonkeyRunner我就不大推荐了，你能够看下我对金阳光老师的一个评论的回复《MonkenRunner通过HierarchyViewer定位控件的方法和建议》（文章最后我干脆也贴出来了）。至于Robotium，你对照下本人博客里面各个框架编写的Note的測试演示样例就能够看出来Robotium相对其它框架会简单介绍非常多，况且发展的比UIAutomator和Appium长久非常多，所以也应该会更成熟，和Eclipse集成调试起来也非常方便。比起后两者假设有不足的话我认为就下面几点吧：
- 1. 全部的操作抽象到一个Solo类里面，缺乏面向对象的编程思想，有时会让人不适应。假设你熟悉C语言等面向过程的语言思想的话应该没有问题。
- 2. 获取控件的方法比較缺乏，大概就几种：通过Text，ID， ClassName，Index。没有后两者的多种多样
- 3. 跨进程：由于底层使用Instrument框架，測试包和被測应用包打包在一起作为一个进程执行而线程间通过instrumentaiton进行通信，导致了逃不出这个进程设沙箱（sandbox)
- 4. 做不了模拟键盘的測试（但同一时候这个也是Robotium很巨大的长处，由于不像后两者那样须要调用键盘导致输入的各种各样的问题），由于Robotium输入读出事实上是直接对控件的text属性进行操作没有通过键盘驱动的，你假设做过UI编程应该就明确我的意思了，由于记住你的測试代码和目标应用是打包在同一个进程中的，同一个进程中想訪问另外一个线程的某个变量，运用对应的IPC（Interprocess Communication)机制当然是没有问题的了。
然后到了你问的主题UIAutomator和Appium的对照，我个人是这样看的：
- 1. UIAutomator是亲爹（google）生的，所以能够保证兴许的开发维护力量，除非google倒闭（这里我有点不懂的是为什么google对Monkeyrunner的态度这么让人摸不着头脑，详细请看以上我说的对MonkeyRunner的评论）
- 2. Appium尽管不是亲爹生的，可是干爹实力雄厚把它武装的无所不能（android，ios，firefox，browser通杀），单单以android来说，底层用得还是UIAutomator，所以仅仅要它能及时跟上UIAutomator的更新，功能上面我不是非常操心。
- 3. 可是也这是Appium的这样的架构：UIautomator/seledroid<->Appium Server<->Selenium/AppiumDriver<->Test Case （《Appium架构框架图整理》）,导致框架有点复杂，当问题出现的时候调试起来比較难以定位，不知道哪个模块出错了。可是说道调试，总比UIAutomator好，起码Appium能够直接集成到eclipse上面进行debug，UiAutomator却每次都要push到目标机器然后再去运行，怎么调试呢？到如今为止我知道的仅仅能原始的print了。
- 4. 向下兼容问题：Appium能够通过底层UIAutomator/Selendroid（不记得是不是这名字了）通杀；UIAutomator仅仅能在API Level 17（包括）以上使用
- 5.语言支持：appium基本通杀，UIAutomator用java足矣
- 6.跨平台：如你所说的仅仅是android两者都没有问题，假设往后须要扩展到ios，那么建议appium
- 7.bug数量：UIAutomator有的问题Appium都会有，UIAutomator没有的问题Appium也有可能有^_^（只是我还是非常看好Appium的）
- 8. 输入问题，都有bug，详细请查看我对应blog，特别是中文输入，这就是为什么我刚才特意提出Robotum的原因之中的一个
- 9. WebView支持：UIAutomator据说今年年初已经開始支持，个人没有这方面要求所以没研究；Appium的框架用的Selenium本身就是PC上最流行的开源Web測试框架，所以必定支持了。注意这你你要有点android编程知识了，WebView指的不仅是WebView控件还包括如用sencha+phonegap把webview封装成一个跨平台app的情况了，详细假设不清楚请google。
其它差别我如今就没有想到了，希望能帮助到你，从我自己的角度来看，我认为UIAutomator继续往前发展是必定的了，可是它不可能终于支持ios。至于Appium我相同有非常大的信心它会继续往好的方向发展，且考虑到它的跨平台支持，基于node.js（如今非常流行哦），兼容性等，我假设是你的话我会考虑用Appium的（抛开Robotium不说，假设你又要考虑的话就须要你依据我之前说的再总结下了^_^）。
我认为这个能够类比之前的微软和Borland的关系，API是Windows，可是IDE是Borland的，各专所长了。可惜（或者庆幸）后来微软发力一下把Borland打得满地找牙一蹶不振，只是这是题外话了，略过......
对了，我有可能会对这封邮件整理下发到博客了，也希望其它网友能评点一二给你出主意。今晚本来想看下easy_monkey的知识了，给你写这个email变成暂时性总结了。^_^
给金阳光老师评论的回复例如以下（关于MonkeyRunner的个人观点）
-----------------------------------------------------------------------------------------------------------------
回复haorenmin2008：首先膜拜下，金老师大驾光临蓬荜生辉啊！
对于后者，确实如此，UIAutomator须要API Level17（包括）以上。
对于前者，由于还没有MonkeyRunner的项目经验，所以是否非常强大我就不敢妄加评论了，可是在我近来的tryout过程中，鄙人有下面的一些不成熟的认知：
- 1. 感觉功能不是非常稳定，之前尝试一个MonkeyDevice的getProperty方法，居然有时成功有时失败。
- 2. 性能不好，特别是当我们要用到hierarchyviewer的功能的时候非常明显。
- 3. 仅仅能用MonkeyImage的sameAs做截屏的对照，尽管加上hierarchyviewer后能够用它的getText，但还是非常有限。
- 4. 控件定位方面主要是坐标点和HierarchyViewer提供的依据ID。前这儿在UI布局略微有调整位置的话就须要跟着变动，没有像其它控件类框架那样做高层抽象除非换控件不然都不须要怎么变动；后者的话非常多控件是没有id或者是有多个控件id同样的。
- 5. 可调试性也不强（起码我摸索了这几天没有发现一个非常好的调试方法，比方IDE Ecilpse等的集成调试方法）
- 6. HierarchyViewer的稳定性也让我担忧，碰到过几次取控件信息的时候报exception的。
- 7. 资料稀缺，不仅百度，google也一样
- 8. Google支持让人认为摸不着头脑，sdk给出的API和官方提供的API居然不一致，以MonkeyDevice为样例，而sdk多出来的API居然还不能用，google出来的信息不超过10个page，还要非常多都是反复的石沉大海的网友报的问题。
- 9. 再一个的我真心搞不懂为什么本身java写的库非要搞个jython来调用，首先我不说性能损耗（这点肯定是有的，native库当然用native语言调用效率最好嘛），我想在eclipse上对下面的"device."做自己主动补全是做不到的“device = MonkeyRunner.waitForConnection() device.",而仅仅有直接调用个构造函数实例化的device = MonkeyDevice（xxx）才干做到，这个我不相信是我配置的问题，换了个jython标准编译器以调用标准库问题相同存在。
Best Regards
Kevin Zhu
-------------------------------------------------------------------------------------------------------------------
wonderfei : 你好，我看到你写了非常多Android的自己主动化測试相关的文章，我近期准备在项目中实施Android的UI自己主动化測试，主要用来做回归測试，当前比較流行的robotium和appium，你觉得哪一个更推荐使用以及未来使用？