大家好，今天来介绍robotium和appium区别(appium安卓自动化测试)的问题，以下是渲大师小编对此问题的归纳和整理，感兴趣的来一起看看吧！
Appium和Robotium在文字输入上的区别
appium 应该埋轿是发送键盘点击事件来输入。robotium的则是获取输入圆历框对象，直接通橘液搜过EditText对象的方法setText来设置文本
.png "robotium和appium区别(appium和uiautomator)")
怎样使用Appium进行Android自动化测试
1、Robotium——安卓测试工具 Robotium是安卓系统最常用的自动化测试工具，并且是一款免费的安卓UI测试工具。它适合于各种不同的安卓版本及其下行版本。软件开发者经常把它称作安卓。Robotium创建的测试使用Java写的。事实上，Robotium是一个个体测试数据库。 但是Robotium需要花费很长时间努力去创建测试，就像为了自动化程序创建的源代码。它不适合互动的软件系统，不能锁住和解锁智能手机。Robotium没有记录和播放功能，它不支持截屏。 2、MonkeyRunner——安卓App测试工具 MonkeyRunner是最流行的有自动化功能的安卓软件测试工具。MonkeyRunner比起Robotium要低端一些。它并不处理源代码。测试创建是用Python写的，其中可能使用记录工具，为了创建测试。MonkeyRunner可以在连接状态的PC或者模拟器上运行测试。它有一个应用程序接口可以控制智能手机或者模拟器。但手机APP测试工具的最大缺陷是每个设备都要编写脚本。另一个缺陷就是，每次测试程序发生改变时都要调整。 3、Ranorex——安卓App测试工具 Ranorex是一个不错的自动化测试工具，不仅最新版本，Android 2.2.以上版本都是可以的。Ranorex的好处在于它有详细的截屏报告。他可以通过WiFi上网连接智能手机或者平板电脑。通过这个 Android 工具，自动化的测试工程师可以详细描述数据驱动测试，但不包括 XML 数据格式。Ranorex可以很轻松地创建测试，自动化测试工程师只需点击鼠标。Ranorex允许附加的程序模块。这个模块可以被用于开发更为复杂的测试场景中。Ranorex是一个商业化的移动应用程序的工具;其许可价格是 1990欧元/年。Ranorex搜索相当慢;它需要 30 秒的时间来执行操作。其中一个必须为Ranorex文书的 APK 文件拆耐。否则它不能通过这个工具进行自动化测试，它只能在APK 文件下工作。 4、Appium——安卓自动化测试工具 Appium是为iOS和安卓系统创建的自动化测试框架，是一个免费工具。它支持 2.3 及更高版本的 Android 系统。Appium利用WebDriver界面运行测试。它支持许多编程语言，如 Java、 C#、Ruby和其他的WebDriver数据库。它可以在移动设备上控制 Safari 和Chrome。但是，一些自动化的测试工程师抱怨它提供的报告不足。它的缺点也减少了对于XPath在移动设备上的支持。 5、UI Automator——安卓自动化测试 谷歌最近推出了这一工具。它支持从4.1开始的安卓版本。我们应该选择另一个更早期的安卓应用程序进行自动化测试。UI Automator能够与各类安卓系统兼容，包括系统的应用程序。这使得旁毁UI Automator可以锁定和解锁智能手机或平板电脑。通过该工具创建的脚本可以在许多不同的安卓平台上执行。它允许复制用户的操作复杂的序列。UI Automator也可以利旅启春用外部按钮的装置调节，打开和关闭设备的按钮。 UI Automator可以与测试框架TestNG集成。在这种情况下，用户界面自动可以生成内容丰富和详细的报告，类似于由Ranorex生成的报告。此工具搜索速度还非常快。在许多安卓平台上测试后，软件测试专家认为UI Automator是质量最好的移动应用程序。它是安卓做好的应用程序之一，它由谷歌推出。 通常大约 80%的新软件的 bug 都会重现支持的平台。其余 20%出现在其他平台上。这意味着，在大多数情况下，事先测试软件产品比盲目使用更好。 目前， Android 4.1 版本安装了约 66%操作系统的设备。这就是为什么许多自动化的测试工程师经常决定UI Automator是最合适的解决方案。
如何选择Android自动化框架的几点拙见
首先由于我自己也是个新手，也是在学习各种框架然后给公司项目选定相应自动化框架，研究移动自动化测试框架也就近段时间而已，所以我只能从我自己今天为止的认知角度给各个框架抒发我自己的拙见，你看是否能从中接纳一二吧（对于我自己的话还需要再花一段时间去学习各个框架才能确定哪个/些是适合我们项目的了,也许到时我会写个正式的总结)。
根据你的要求，应该不会考虑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/seledroidAppium ServerSelenium/AppiumDriverTest Case （《Appium架构框架图整理》http://blog.csdn.net/zhubaitian/article/details/39453505）,导致框架有点复杂，当问题出现的时候调试起来比较难以定位，不知道哪个模块出错了。但是说道调试，总比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()n device.”,而只有直接调用个构造函数实例化的device = MonkeyDevice（xxx）才能做到，这个我不相信是我配置的问题，换了个jython标准编译器以调用标准库问题同样存在。
Android 手机自动化测试工具有哪几种
1、Monkey是Android SDK自带的测试工具，在测试过程中会向系统发送伪随机的用户事件流，如按键输入、触摸屏输入、手势输入等)，实现对正在开发的应用程序进行压力测试，也有日志输出。实际上该工具只能做程序做一些压力测试，由于测试事件和数据都是随机的，不能自定义，所以有很大的局限性。
2、MonkeyRunner也是Android SDK提供的测试工具。严格意义上来说MonkeyRunner其实是一个Api工具包，比Monkey强大，可以编写测试脚本来自定义数据、事件。缺点是脚本用Python来写，对测试人员来说要求较高，有比较大的学习成本。
3、Instrumentation是早期Google提供的Android自动化测试工具类，虽然在那时候JUnit也可以对Android进行测试，但是Instrumentation允许你对应用程序做更为复杂的测试，甚至是框架层面的。通过Instrumentation你可以模拟按键按下、抬起、屏幕点击、滚动等事件。Instrumentation是通过将主程序和测试程序运行在同一个进程来实现这些功能，你可以把Instrumentation看成一个类似Activity或者Service并且不带界面的组件，在程序运行期间监控你的主程序。缺点是对测试人员来说编写代码能力要求较高，需要对Android相关知识有一定了解，还需要配置AndroidManifest.xml文件，不能跨多个App。
4、UiAutomator也是Android提供的自动化测试框架，基本上支持所有的Android事件操作，对比Instrumentation它不需要测试人员了解代码实现细节（可以用UiAutomatorviewer抓去App页面上的控件属性而不看源码）。基于Java，测试代码结构简单、编写容易、学习成本，一次编译，所有设备或模拟器都能运行测试，能跨App（比如：很多App有选择相册、打开相机拍照，这就是跨App测试）。缺点是只支持SDK 16（Android 4.1）及以上，不支持Hybird App、WebApp。
5、Espresso是Google的开源自动化测试框架。相对于Robotium和UIAutomator，它的特点是规模更小、更简洁，API更加精确，编写测试代码简单，容易快速上手。因森罩为是基于Instrumentation的，所以不能跨App。配合Android Studio来编写测试的简单例子
6、Selendroid：也是基于Instrumentation的测试框架，可以测试Native App、Hybird App、Web App，但是网上资料较少，社区活跃度也不大。
7、Robotium也是基于Instrumentation的测试框架，目前国内外用的比较多，资料比较多，社区也比较活跃。缺点是对测试人员来说要有一定的Java基础，了解Android基本组件，不能跨App。
8、Athrun是淘宝出的一个移动测试框架/平台，同时支持iOS和Android。Android部分也是基于Instrumentation，在Android原有的ActivityInstrumentationTestCase2类基础上进行了扩展，提供一整套面向对象的API。这里有详细介绍。
9、Appium是最近比较热门的框架，社区也很活跃。这个框架应该是是功能最强大的，
它的优点：
它的哲理是：
它的设计理念：
相关限制：
总结：
在iOS部分是封装了UIAutomation；Android 4.2以上是用UiAutomator，Android 2.3 ~ 4.1用的此让闹是 Instrumentation，也就说Appium同时封装了UiAutomator和Instrumentation。滑启所以Appium拥有了以上几大框架的所有优点：跨App，支持Native App、Hybird App、Web App，还支持N种语言来编写你的测试脚本。
如果你在Windows使用Appium，你没法使用预编译专用于OS X的.app文件，因为Appium依赖OS X专用的库来支持iOS测试，所以在Windows平台你不能测试iOS Apps。这意味着你只能通过在Mac上来运行iOS测试。
Client/Server架构，运行的时候Server端会监听Client端发过来的命令，翻译这些命令发送给移动设备或模拟器，然后移动设备或模拟器做出响应的反应。正是因为这种架构，所以Client可以使用Appium client libraries多种语言的测试脚本，而且Server端完全可以部署在服务器上，甚至云服务器。
Session，每个Client连接到Server以后都会有一个Session ID，而且Client发送命令到Server端都需要这个Session ID，因为这个seesion id代表了你所打开的浏览器或者是移动设备的模拟器。所以你甚至可以打开N个Session，同时测试不同的设备或模拟器。
Desired Capabilities，其实就是一个键值对，设置一些测试的相关信息来告诉Server端，我们需要测试iOS、还是Android，或者换是WebApp等信息。
Appium Server是Node.js写的，所以可以直接用NPM来进行安装。
Appium Clients，Mac OS和Win下提供GUI，不需要装Node.js，方便测试人员操作。
用Appium自动化测试不需要重新编译App；
支持很多语言来编写测试脚本，Java、Javascript、PHP、Python、C#、Ruby等主流语言；
不需要为了自动化测试来重造轮子，因为扩展了WebDriver。（WebDriver是测试WebApps的一种简单、快速的自动化测试框架，所以有Web自动化测试经验的测试人员可以直接上手）；
移动端自动化测试应该是开源的；
开源；
支持Native App、Hybird App、Web App；
支持Android、iOS、Firefox OS；
Server也是跨平台的，你可以使用Mac OS X、Windows或者Linux；