如何选择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/seledroid<->Appium Server<->Selenium/AppiumDriver<->Test Case （《Appium架构框架图整理》>

1元素标签(tagname) 通过UI的控件类型ListtextFieldsList=driverfindElements(BytagName( textfield ))；

元素的位置(xpath) 具有一定约束的路径抽象标示, 基于XPath方式；

元素的值(name) driverfindElement(Byname( Save ))click();通过元素的文本, 标签, 或者id标示；

元素的IDdriverfindElement(Byid(comexampleandroidcontactmanager:id/contactNameEditText ))getText()；

以上就是关于如何选择Android自动化框架的几点拙见全部的内容，包括:如何选择Android自动化框架的几点拙见、appium android怎么获取元素、等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！