android界面测试

⑴ android自动化测试工具有哪些

1、 Robotium 安卓测试工具

Robotium是一款经常使用的自动化测试工具软件，支持Android。
Robotium是一个免费的Android UI测试工具。它适用于为不同的安卓版本和子版本测试自动化。软件开发人员经常把它描述为Android Selenium。Robotium测试是用java写的。事实上，Robotium是一个单元测试库。
但通过Robotium创建测试需要花费很多时间和努力，因为为了自动化测试还需要修改程序源代码。该工具也不适合与系统软件的交互，它不能锁定和解锁智能手机或平板电脑。Robotium也没有录制回放功能，也不提供截图。
2、MonkeyRunner 安卓应用测试

Monkeyrunner是一款流行的Android测试工具，用于自动化功能测试。
这个工具比Robotium更低一层次。这个不必处理源代码来做自动化测试。这个测试可以用Python写，并且可以使用录制工具来创建测试。
Monkeyrunner可以连接到电脑或模拟真实设备运行测试。该工具有一个接口，用它来控制智能手机，平板电脑或外部模拟器的Android代码。
这个测试工具的缺点是，它必须为每个设备编写脚本。另一个问题是，每次测试程序的用户界面变化都需要调整测试脚本。
3、Ronaorex 安卓测试应用工具
Ranrex 是一款不仅可以支持最新Android版本，也支持从Android2.2开始的早期版本和分支版本。
Ranorex的优势是它有详细的截屏报告。它能通过Wifi连接智能手机和平板电脑。
一个自动化测试工程师通过这个Android工具可以不用XML数据格式来详细编写数据驱动的测试。Ranorex工作室使自动化测试工程师只要点击鼠标就可容易地创建测试。它允许详细声明额外的程序模块，来用于在后期开发周期中测试更复杂的场景。
它是一个商业的移动应用工具，其许可价格为1990欧元。不过Ranorex搜索功能相当慢；它需要30秒来完成这样的操作。我们必须为Ranorex配备apk文件设备，否则无法通过这个工具实现自动化测试，因为它只能在APK文件设备上工作。

⑵ 如何设计Android App测试用例

一般安卓开发者在其日常工作中面临的最大挑战之一是：终端设备和[url=]操作系统[/url]版本的范围太广。OpenSignal进行的一项研究表明，2013年7月市场上有超过11，828的不同安卓终端设备，所有设备在类型/大小/屏幕分辨率以及特定配置方面有所不同。考虑到前一年的调查仅记录有3，997款不同设备，这实在是一个越来越大的挑战障碍。

从一个移动APP开发角度出发，定义终端设备有四个基本特征：
1．操作系统：由“API指标”（ 1 ～18 ）专业定义的安卓操作系统版本（ 1.1～ 4.3 ），。
2．显示器：屏幕主要是由屏幕分辨率（以像素为单位），屏幕像素密度（ 以DPI为单位），和/或屏幕尺寸（以英寸为单位）定义的。
3．CPU：该“应用程序二进制接口” （ABI ）定义CPU的指令集。这里的主要区别是ARM和基于Intel的CPU。
4．内存：一个设备包括内存储器（ RAM）和Dalvik 虚拟存储器（ VM堆）的预定义的堆内存。
这是前两个特点，操作系统和显示器，都需要特别注意，因为他们是直接由最终用户明显感受，且应该不断严格地被测试覆盖。至于安卓的版本， 2013年7月市场上有八个同时运行导致不可避免的碎片的不同版本。七月，近90％这些设备中的34.1 ％正在运行Gingerbread版本（ 2.3.3-2.3.7 ），32.3 ％正在运行Jelly Bean（ 4.1.x版），23.3 ％正在运行Ice Cream Sandwich（ 4.0.3 - 4.0.4 ）。

考虑设备显示器，一项TechCrunch从2013年4月进行的研究显示，绝大多数（79.9％）有效设备正在使用尺寸为3和4.5英寸的“正常”屏幕。这些设备的屏幕密度在“MDPI”（～160 DPI），“hdpi”（～240 DPI）和“xhdpi”（～320 DPI）之间变化。也有例外， 一种只占9.5％的设备屏幕密度低“hdpi”（～120 DPI）且屏幕小。

如果这种多样性在质量保证过程中被忽略了，那么绝对可以预见：bugs会潜入应用程序，然后是bug报告的风暴，最后Google Play Store中出现负面用户评论。因此，目前的问题是：你怎么使用合理水平的测试工作切实解决这一挑战？定义测试用例及一个伴随测试过程是一个应付这一挑战的有效武器。

用例—“在哪测试”、“测试什么”、“怎么测试”、“何时测试”？
“在哪测试”
为了节省你测试工作上所花的昂贵时间，我们建议首先要减少之前所提到的32个安卓版本组合及代表市场上在用的领先设备屏的5-10个版本的显示屏。选择参考设备时，你应该确保覆盖了足够广范围的版本和屏幕类型。作为参考，您可以使用OpenSignal的调查或使用手机检测的信息图[3]，来帮助选择使用最广的设备。
为了满足好奇心，可以从安卓文件[5]将屏幕的尺寸和分辨率映射到上面数据的密度（“ldpi”，“mdpi”等）及分辨率（“小的”，“标准的”，等等）上。

有了2013手机检测研究的帮助，很容易就找到了代表性的一系列设备。有一件有趣的琐事：30％印度安卓用户的设备分辨率很低只有240×320像素，如上面列表中看到的，三星Galaxy Y S5360也在其中。另外，480×800分辨率像素现在最常用（上表中三星Galaxy S II中可见）。

“测试什么”
移动APP必须提供最佳用户体验，以及在不同尺寸和分辨率（关键字“响应式设计”）的各种智能手机和平板电脑上被正确显示（UI测试）。与此同时，apps必须是功能性的和兼容的（兼容性测试），有尽可能多的设备规格（内存，CPU，传感器等）。加上先前获得的“直接”碎片化问题（关于安卓的版本和屏幕的特性）， “环境相关的”碎片化有着举足轻重的作用。这种作用涉及到多种不同的情况或环境，其中用户正在自己的环境中使用的终端设备。作为一个例子，如果网络连接不稳定，来电中断，屏幕锁定等情况出现，你应该慎重考虑压力测试[4]和探索性测试以确保完美无错。

有必要提前准备覆盖app最常用功能的所有可能的测试场景。早期bug检测和源代码中的简单修改，只能通过不断的测试才能实现。

“怎么测试”
将这种广泛的多样性考虑在内的一种务实方法是， 安卓模拟器 - 提供了一个可调节的工具，该工具几乎可以模仿标准PC上安卓的终端用户设备。简而言之，安卓模拟器是QA流程中用各种设备配置（兼容性测试）进行连续回归测试（用户界面，单元和集成测试）的理想工具。探索性测试中，模拟器可以被配置到一个范围广泛的不同场景中。例如，模拟器可以用一种能模拟连接速度或质量中变化的方式来设定。然而，真实设备上的QA是不可缺少的。实践中，用作参考的虚拟设备依然可以在一些小的（但对于某些应用程序来说非常重要）方面有所不同，比如安卓操作系统中没有提供程序特定的调整或不支持耳机和蓝牙。真实硬件上的性能在评价过程中发挥了自身的显着作用，它还应该在考虑了触摸硬件支持和设备物理形式等方面的所有可能终端设备上进行测试（可用性测试）。

“何时测试”
既然我们已经定义了在哪里（参考设备）测试 ，测试什么（测试场景），以及如何（ 安卓模拟器和真实设备）测试，简述一个过程并确定何时执行哪一个测试场景就至关重要了。因此，我们建议下面的两级流程：
1 ．用虚拟设备进行的回归测试。
这包括虚拟参考设备上用来在早期识别出基本错误的连续自动化回归测试。这里的理念是快速地、成本高效地识别bugs。
2 ．用真实设备进行的验收测试。
这涉及到：“策划推广”期间将之发布到Google Play Store前在真实设备上的密集测试（主要是手动测试），（例如，Google Play[ 5 ]中的 alpha和beta测试组） 。
在第一阶段，测试自动化极大地有助于以经济实惠的方式实现这一策略。在这一阶段，只有能轻易被自动化（即可以每日执行）的测试用例才能包含在内。
在一个app的持续开发过程中，这种自动化测试为开发人员和测试人员提供了一个安全网。日常测试运行确保了核心功能正常工作，app的整体稳定性和质量由测试数据透明地反映出来，认证回归可以轻易地与最近的变化关联。这种测试可以很轻易地被设计并使用SaaS解决方案（如云中的TestObject的UI移动app测试）从测试人员电脑上被记录下来。
当且仅当这个阶段已被成功执行了，这个过程才会在第二阶段继续劳动密集测试。这里的想法是：如果核心功能通过自动测试就只投入测试资源，使测试人员能够专注于先进场景。这个阶段可能包括测试用例，例如性能测试，可用性测试，或兼容性测试。这两种方法相结合产生了一个强大的移动apps质量保证策略[ 7 ] 。

结论 - 做对测试
用正确的方式使用，测试可以在对抗零散的安卓的斗争中成为一个有力的工具。一个有效的测试策略的关键之处在于定义手头app的定制测试用例，并定义一个简化测试的工作流程或过程。测试一个移动app是一个重大的挑战，但它可以用一个结构化的方法和正确的工具集合以及专业知识被有效解决掉。

⑶ android 哪些函数会引起界面重新测量

横屏和竖屏
、新建一个Activity，并把各个生命周期打印出来

2、运行Activity，得到如下信息

onCreate-->
onStart-->
onResume-->

3、按crtl+f12切换成横屏时

onSaveInstanceState-->
onPause-->
onStop-->
onDestroy-->
onCreate-->
onStart-->
onRestoreInstanceState-->
onResume-->

4、再按crtl+f12切换成竖屏时，发现打印了两次相同的log

onSaveInstanceState-->
onPause-->
onStop-->
onDestroy-->
onCreate-->
onStart-->
onRestoreInstanceState-->
onResume-->
onSaveInstanceState-->
onPause-->
onStop-->
onDestroy-->
onCreate-->
onStart-->
onRestoreInstanceState-->
onResume-->

5、修改AndroidManifest.xml，把该Activity添加 android:configChanges="orientation"，执行步骤3

onSaveInstanceState-->
onPause-->
onStop-->
onDestroy-->
onCreate-->
onStart-->
onRestoreInstanceState-->
onResume-->

6、再执行步骤4，发现不会再打印相同信息，但多打印了一行onConfigChanged

onSaveInstanceState-->
onPause-->
onStop-->
onDestroy-->
onCreate-->
onStart-->
onRestoreInstanceState-->
onResume-->
onConfigurationChanged-->

7、把步骤5的android:configChanges="orientation" 改成 android:configChanges="orientation|keyboardHidden"，执行步骤3，就只打印onConfigChanged

onConfigurationChanged-->

8、执行步骤4

onConfigurationChanged-->
onConfigurationChanged-->

总结：

1、不设置Activity的android:configChanges时，切屏会重新调用各个生命周期，切横屏时会执行一次，切竖屏时会执行两次

2、设置Activity的android:configChanges="orientation"时，切屏还是会重新调用各个生命周期，切横、竖屏时只会执行一次

3、设置Activity的android:configChanges="orientation|keyboardHidden"时，切屏不会重新调用各个生命周期，只会执行onConfigurationChanged方法

总结一下整个Activity的生命周期

补充一点，当前Activity产生事件弹出Toast和AlertDialog的时候Activity的生命周期不会有改变

Activity运行时按下HOME键(跟被完全覆盖是一样的)：onSaveInstanceState --> onPause --> onStop onRestart -->onStart--->onResume

Activity未被完全覆盖只是失去焦点：onPause--->onResume

⑷ Android 手机自动化测试工具有哪几种

1、Monkey
Android SDK自带的测试工具，在测试过程中会向系统发送伪随机的用户事件流，如按键输入、触摸屏输入、手势输入等)，实现对正在开发的应用程序进行压力测试，也有日志输出。

2、MonkeyRunner
也是Android SDK提供的测试工具。严格意义上来说MonkeyRunner其实是一个Api工具包，比Monkey强大，可以编写测试脚本来自定义数据、事件。

3、Instrumentation
早期Google提供的Android自动化测试工具类，虽然在那时候JUnit也可以对Android进行测试，但是Instrumentation允许你对应用程序做更为复杂的测试，甚至是框架层面的。通过Instrumentation你可以模拟按键按下、抬起、屏幕点击、滚动等事件。Instrumentation是通过将主程序和测试程序运行在同一个进程来实现这些功能，你可以把Instrumentation看成一个类似Activity或者Service并且不带界面的组件，在程序运行期间监控你的主程序。

5、Espresso
Google的开源自动化测试框架。相对于Robotium和UIAutomator，它的特点是规模更小、更简洁，API更加精确，编写测试代码简单，容易快速上手。

6、Robotium也是基于Instrumentation的测试框架，目前国内外用的比较多，资料比较多，社区也比较活跃。缺点是对测试人员来说要有一定的Java基础，了解Android基本组件，不能跨App。

⑸ 怎样使用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 studio instrumentation 做UI测试

一个项目代表一个完整的Android应用程序。Android Studio项目包含一个或多个mol... 测试或调试。mole包含您的应

⑺ 如何测试安卓（Android）系统的流畅度

测试方法一：系统自带-开发者模式

实际上，为了方便开发者测试，安卓本身就内置了流畅度检测的功能。不过，这需要我们开启隐藏的开发者选项。如果你在用原生系统，那么开启开发者选项的方法很简单，进入到设置菜单“关于手机”页面，点击数次“版本号”，即可开启开发者选项。如果用的是其他ROM，方法也许有所不同，比如说魅族的Flyme开启开发者选项的方法是在拨号界面输入“*#*#6961#*#*”，其他机器方法也各有不同，大家可以参照厂商的说明。

进入到开发者选项，可以看到有“GPU呈现模式分析”的选项，开启后即可以条形图和线形图的方法显示系统的界面响应速度，可以用以观察系统流畅度。那么要如何根据曲线判断系统是否流畅呢？实际上这个曲线表达的是GPU绘制每一帧界面的时间，只要不超过顶部绿线，都可以视为足够流畅。

开启GPU呈现模式分析

FPS Meter可以显示最大最小帧数以及平均帧数

FPS Meter可以测试界面帧数，不过某些手机如果界面静止，帧数会为0。FPS Meter除了测量系统界面帧数外，还可以用来测量游戏的帧数，所以用FPS Meter来测试某部安卓机游戏性能多强也是个很好的选择。

当然，FPS Meter也并非十全十美。由于属于第三方App，所以可能会有一些兼容性问题。某些安卓机或者ROM使用FPS Meter可能会不兼容，即使成功开启了帧数显示也没法测量到准确数值，而某些设备使用FPS Meter甚至会死机。不过在大多数情况下，这款App还是相当值得信任的。

安卓在多个版本中都通过新技术提升了流畅度，比如说安卓2.3引入Dalvik、安卓4.0引入GPU界面绘制、安卓4.1引入黄油计划、安卓4.3引入Trim以及安卓4.4引入ART等等。

H5页面加载速度：window.performance.timing

Android以上测试方法不适用h5页面

如何分析页面整体加载速度：

主要是查看指标值PAGET_页面加载时间,此指标指的是页面整体加载时间但不含(onload事件和redirect), 此指标值可直接反应用户体验, 从此项指标可以知道指定某时间段的页面加载速度值,以及和天,周,月的对比状况.也可以查询指标ALLT_页面完全加载时间, 可以查询到从浏览器开始导航(用户点击链接或在地址栏输入url或点刷新,后退按钮)到页面onload 事件js完全跑完的所有时间.如果发现页面加载速度有增加或减少,则可以分项查询前面表格中的每个指标值,总的来说他们的关系如下:

dom开始加载前所有花费时间=重定向时间+域名解析时间+建立连接花费时间+请求花费时间+接收数据花费时间

pageLoadTime页面加载时间=域名解析时间+建立连接花费时间+请求花费时间+接收数据花费时间+解析dom花费时间+加载dom花费时间

allLoadTime页面完全加载时间=重定向时间+域名解析时间+建立连接花费时间+请求花费时间+接收数据花费时间+解析dom花费时间+加载dom花费时间+执行onload事件花费时间

resourcesLoadedTime资源加载时间=解析dom花费时间+加载dom花费时间

流畅度暂时没有发现好用的测试衡量工具，开发层面了解，主要是根据log分析

⑻ 如何 测试 android app

使用eclipse新建android app并测试运行结果
一、新建android app
在文件菜单中打开新建，选择new android application。然后会出现一个对话框。

在上面一步的各输入框中填写相应信息。注意包的名字一般是域名的倒写。如果书写不规范，它会提示一个红色的叉。然后单击下一步。

配置启动图标，可以选择自己本地有的图标。这个图标就是app在手机应用上快捷方式所产生的图标。

如果选择clipart,它会提供许多图标进行选择。

下一步建立一个"activity"。有7个可供选择。选择第一个blank activity。表示空白活动。

下一步一般没有修改的必要，点击finish。

完成之后，它会创建一个项目，包含了几个文件夹，有装源代码的，还有装需要用到的资料的。

二、运行与测试
右击工程名，下面这个就是Firstprj，然后选择run as android application。它会启动模拟器。提示调试信息。

上一步选择yes，它会提示log信息。

最终的运行结果如下。

注意事项：
在开发之前，确保电脑已经配置好开发环境。

⑼ android 测试框架怎么用

随着Android应用得越来越广，越来越多的公司推出了自己移动应用测试平台。例如，网络的MTC、东软易测云、Testin云测试平台……。由于自己所在项目组就是做终端测试工具的，故抽空了解了下几种常见的基于UI层面的自动化测试工具。趁晚上有空总结下，好记心不如烂笔头呀！
一 常见Android自动化测试框架及其应用
目前，Android基于UI层面的自动化测试工具，都可以理解为是基于Android控件层面的，涉及Widgets和WebView两大类。其主流的测试方法主要有以下几种。一种是通过Android提供的各种服务，来获取当前窗口的视图信息。然后，在当前视图内查找目标控件，并根据该控件属性信息计算出该控件中心点的坐标，进而构造出一个Android Input事件来实现对应用的自动化测试。其主要特点是：测试代码和被测应用各自运行在各自的进程内，相互独立。其代表有Uiautomator。另一种则是基于Instrumentation，通过把测试代码和应用代码，确切地说是测试APK和被测APK，运行在同一个进程中，通过Java反射机制，来获取当前窗口所有视图，并根据该视图查找到目标控件的属性信息，并计算出目标控件中心点坐标。然后，利用Instrument内部接口，实现点击操作。其代表有Robotium。
我们先来看下第一种。这类方法通常需要满足两个功能，一是能获取屏幕视图；二是能产生输入事件。这样，用户就可以通过屏幕视图查找到目标控件，进而计算出其中心点坐标，并由此产生一个输入事件来模拟用户操作。通常，这类框架还会提供一个截屏功能，方便用户对照。例如，分析定位问题等等。
目前，这类测试方法常见应用模式有以下几种：（1）、Hierachyview+monkey；（2）、uiautomator；（3）、accessibilityservice。（4）其他。先来说下第一种，Hierachyview+monkey的组合方式。
我们先来说下第一种，Hierachyview+monkey。其实现原理如下：
首先，hierahcyview通过socket与设备侧ViewServer建立连接，端口为4939。其次，通过命令“mp -1”获取控件属性信息。信息存入ViewNode中。第三，根据ViewNode信息，遍历控件树，查找到目标控件，并根据其bounds信息，计算出其中心点坐标。第四，根据计算出的坐标信息，发送一个点击该点的monkey命令给设备侧的monkey服务。除点击操作外，我们还可以通过Monkey服务进行输入、硬按键类操作。至此，对设备的一个自动化操作就完成了。这里需要说明的是，绝大部分商用手机ViewServer服务的开启都需要系统权限。故采用这种模式，手机一般需要root权限。另外，关于Hierachyview，CSDN上有一篇很好地介绍Hierachyview实现原理的文章，其连接地址如下：
http://www.cnblogs.com/vowei/archive/2012/08/08/2627614.html。现摘录其部分内容，关于从设备侧ViewServer获取控件层次结构图的过程，以便大家更好地理解该模式。
HierachyViewerDirector.java（即Controller）通过DeviceBridge.java来和Android设备通信，而DeviceBridge.java具体是通过AndroidDebugBridage.java和DeviceConnection.java来和设备通信。备注：Hierachyview本身采用MVC模式。
AndroidDebugBridge.java : AndroidDebugBridge.java是ADB API，位于ddmlib项目中。它实现了命令行版adb一样的功能，在HierarchyViewer中主要用到其连接设备，forward端口，启动ViewServer等操作。
DeviceConnection.java: 负责和ViewServer通信，向ViewServer发送命令并接受其返回的信息。从而获取Activity列表、控件层次结构图、截图等。
第二种应用模式Uiautomator。UiAutomator是Google仿照微软Uiautomation提供的一套自动化框架，基于Android AccessilibilityService提供（注：Android AccessilibilityService，是一个可访问服务，是一个为增强用户界面并帮助残疾用户的应用程序，或者用户可能无法完全与设备的交互。例如，用户在开车。那么用户就有可能需要添加额外的或者替代的用户反馈方式）。其应用方式有以下几种，一种是UiAutomatorView+monkey，另一种是直接调用UiAutomator API。其中，第一种方法同hierachyview+monkey差不多。其区别是：UiAutomatorView通过ADB向设备侧发送一个mp命令，而不是建立一个socket，下载一个包含当前界面控件布局信息的xml文件。相比较hierachyview下载的内容而言，该文件小很多。因此，从效率上讲，这种方法比第一种应用模式快很多。第二种方法，则是直接调用UiAutomator框架对外提供的API，主要有UiDevice、UiSelector、UiObject等。其原理与第一种方式，即HierachyView+Monkey，差不多。其过程大致是：首先，UiAutomator测试框架通过Accessibilityservice，获取当前窗口的控件层次关系及属性信息，并查找到目标控件。若是点击事件，则计算出该控件的中心点坐标。其次，UiAutomator通过测试框架，注入用户事件（点击、输入类操作），从而实现模拟人的操作。UiAutomator对外提供UiAutomatorTestCase、UiDevice、UiSelector、UiObject、UiCollection、UiScrollable等类，其作用如下：
l UiAutomatorTestCase ：继承自Junit TestCase （Junit），对外提供setup、teardown等，以便初始化用例、清除环境等。
l UiDevice：此类主要包含了获取设备状态信息，和模拟用户至于设备的操作两类API。UiSelector，主要是通过一定查询方式，定位到所要操作的UI元素。
l UiObject：UiObject可代表页面的任意元素，它的各种属性定位通常通过UiSelector来完成。
l UiCollection：UiCollection一般与UiSelector连用，如它的构造函数也要求提供Uiselector: UiCollection(UiSelector selector)。它的API较少，主要用以从Uiselector筛选出的元素集中挑出所要的元素:getChildByDescription(), getChildByInstance(), getChildByText() ,以及统计元素集的个数getChildCount()。
l UiScrollable：UiScrollable 用来表示可以滑动的界面元素,其继承关系为UiObject -> UiCollection ->UiScrollable。
但UiAutomator的实现方式与HierachyView+Monkey有很大不一样。以控件点击操作为例，其实现流程大致如下：
定义一个点击对象Object，该对象则通过UiSelector对象定位到具体的控件。而UiSelector则通过UiAutomatorBridge（它可看做是UiSelector与AccesibilityService之间的连接器），将查询内容（AccessibilityNodeInfo）和输入事件（AccessibilityEvent）传给AccessibilityService。实际业务过程比这复杂的多。这样，就实现了对某个控件的查找或点击操作。备注：AccessibilityEvent，所有可操纵的UI元素都定义为一个AccessibilityEeventt；AccessibilityNodeInfo指视窗中的组件树节点。
第三种则是accessibilityservice。先来介绍下Accessibilityserveice服务。前面已经讲过，它是一个Android的一个服务。若是用Accessibilityservice进行自动化，我们需要继承Accessibilityservice开发一个服务。这样，我们就可以依据这个服务获取当前界面的控件属性信息。其获取内容跟Uiautomator一样，都是AccessibilityNodeInfo。控件信息获取到后，若是要进行点击等操作，则可通过Monkey或其他方式，如Input等，来模拟点击操作。
上述几种Android测试方法中，UiAutomator比较正统，是Google正式推出的，也是应用范围最广的。另外几种方法，则见得不多，其中Hierachyview+monkey的方式，公司内部Ares就采用了。这类测试工具的一个好处就是可以跨应用。但不足之处也很多，速度慢、不支持WebView等（这种模式下，对WebView控制有限，无法注入Java Script）。
接下来说下第二种框架，即Instrumentation，它是Android对外提供的一系列的测试方法的核心。Instumentation可看成一系列控制函数的集合，作用于系统和应用之间，类似于Windows中的Hook。在该测试框架下，主程序和测试程序需要运行在同一个进程中
需要说明的是，在Android系统中，测试程序也是应用程序，我们可以将其看成一个没有UI的应用。
其实现过程大致如下：如图，InstrumentationTestRunner通过调用Instrumentation杀除应用程序的进程，再用Instrumentation重启该应用。这时，测试应用和被测应用就运行在同一进程下。测试应用怎么知道该测试哪个应用呢？嗯，这是通过在测试工程的mainfest文件中添加元素来实现的。当测试应用和被测应用运行在同一个进程里，它们之间就可以通过Instrumentation来进行消息交互，从而达到测试效果。当Instrumentation与某个程序交互时，其大致采用如下步骤：
首先，启动时，初始化测试APK的配置文件AndroidManifest.xml文件中。该配置文件中标明了所使用的测试运行类、被测目标应用、包名等。然后，启动被测应用的Activity。同时，将测试ActivityThread做为一个引用进行初始化。此时，如果找不到目标应用则会报错。其次，执行测试脚本。测试时，测试工程中任何对目标应用进行的操作，都会用异步的方式，将消息体放在目标程序的MessageQueue中。这样，目标程序在查看到自己的MessageQueue中有内容时就会执行。
基于Android Instrumentiaon开发的测试工具有很多，其中最有名的恐怕要数Robotium了。目前，网络上很多移动应用测试平台，如网络移动应用测试平台MTC，都支持Robotium。
二 各类Android测试工具的TestCase继承关系
Android提供了很多测试工具，如Monkey、Instrumentation、UiAutomator。其中，基于Android测试工具进行二次开发的测试工具也很多，如Robotium、Espresso。它们的继承关系下图：
UiAutomator Testcase类继承自JUnit的TestCase类。而Robotium、Espresso则继承自。从这个继承关系，我们也能理解为什么采用Robotium的方式，应用需要签名。而采用UiAutomator则不需要。其原因是：采用Robotium的方式，其测试代码本质上是一个APK。根据Android的安全机制，应用是需要签名的。