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

1、Monkey是

SDK自带的测试工具，在

中会向系统发送伪随机的用户事件流，如按键输入、触摸屏输入、手势输入等)，实现对正在开发的应用程序进行

，也有日志输出。实际上该工具只能做程序做一些

，由于测试事件和数据都是随机的，不能自定义，所以有很大的局限性。

2、MonkeyRunner也是

SDK提供的测试工具。严格意义上来说MonkeyRunner其实是一个Api工具包，比Monkey强大，可以编写

来自定义数据、事件。缺点是脚本用Python来写，对测试人员来说要求较高，有比较大的学习成本。

3、Instrumentation是早期Google提供的

自动化测试工具类，虽然在那时候JUnit也可以对Android进行测试，但是Instrumentation允许你对应用程序做更为复杂的测试，甚至是框架层面的。通过Instrumentation你可以模拟按键按下、抬起、屏幕点击、滚动等事件。Instrumentation是通过将主程序和测试程序运行在同一个进程来实现这些功能，你可以把Instrumentation看成一个类似Activity或者Service并且不带界面的组件，在程序运行期间监控你的主程序。缺点是对测试人员来说编写代码能力要求较高，需要对Android相关知识有一定了解，还需要配置AndroidManifestxml文件，不能跨多个App。

4、UiAutomator也是Android提供的

，基本上支持所有的Android事件 *** 作，对比Instrumentation它不需要测试人员了解代码实现细节（可以用UiAutomatorviewer抓去App页面上的控件属性而不看源码）。基于Java，测试代码结构简单、编写容易、学习成本，一次编译，所有设备或模拟器都能运行测试，能跨App（比如：很多App有选择相册、打开相机拍照，这就是跨App测试）。缺点是只支持SDK 16（Android

）及以上，不支持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是最近比较热门的框架，社区也很活跃。这个框架应该是是功能最强大的，

单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

在一种传统的结构化编程语言中，比如C，要进行测试的单元一般是函数或子过程。在像C++这样的面向对象的语言中， 要进行测试[1] 的基本单元是类。对Ada语言来说，开发人员可以选择是在独立的过程和函数，还是在Ada包的级别上进行单元测试。单元测试的原则同样被扩展到第四代语言（4GL)的开发中，在这里基本单元被典型地划分为一个菜单或显示界面。

经常与单元测试联系起来的另外一些开发活动包括代码走读（Code review)，静态分析（Static analysis)和动态分析（Dynamic analysis)。静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。

在当今竞争激烈的市场上一个APP的成功离不开一个可靠的用户界面（UI）。因此，对功能和用户体验有一些特殊关注和照顾的UI的全面测试是必不可少的。当涉及到安卓平台及其提出的独特问题的数量（安卓就UI提出显著挑战）时，挑战变得更加复杂。关键字“碎片化”象征着移动应用全面测试的最大障碍，还表明了发布到市场上的所有形态、大小、配置类型的安卓设备所引起的困难。本文将介绍安卓模拟器如何能通过使用一些技巧和简单的实践提供覆盖大量设备类型的广泛测试。

简介—分散装置里的测试

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

图1 11，828 款安卓设备类型（ OpenSignal研究， 2013年7月[ 1 ] ）分布

从一个移动APP开发角度出发，定义终端设备有四个基本特征：

1． *** 作系统：由“API指标”（ 1 ～18 ）专业定义的安卓 *** 作系统版本（ 11～ 43 ），。

2．显示器：屏幕主要是由屏幕分辨率（以像素为单位），屏幕像素密度（ 以DPI为单位），和/或屏幕尺寸（以英寸为单位）定义的。

3．CPU：该“应用程序二进制接口” （ABI ）定义CPU的指令集。这里的主要区别是ARM和基于Intel的CPU。

4．内存：一个设备包括内存储器（ RAM）和Dalvik 虚拟存储器（ VM堆）的预定义的堆内存。

这是前两个特点， *** 作系统和显示器，都需要特别注意，因为他们是直接由最终用户明显感受，且应该不断严格地被测试覆盖。至于安卓的版本， 2013年7月市场上有八个同时运行导致不可避免的碎片的不同版本。七月，近90％这些设备中的341 ％正在运行Gingerbread版本（ 233-237 ），323 ％正在运行Jelly Bean（ 41x版），233 ％正在运行Ice Cream Sandwich（ 403 - 404 ）。

图2 16款安卓版本分布（OpenSignal研究，2013年7月[1]）

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

图3 常见的屏幕尺寸和密度的分布（谷歌研究，2013年4月）[2]

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

用例—“在哪测试”、“测试什么”、“怎么测试”、“何时测试”？

“在哪测试”

为了节省你测试工作上所花的昂贵时间，我们建议首先要减少之前所提到的32个安卓版本组合及代表市场上在用的领先设备屏的5-10个版本的显示屏。选择参考设备时，你应该确保覆盖了足够广范围的版本和屏幕类型。作为参考，您可以使用OpenSignal的调查或使用手机检测的信息图[3]，来帮助选择使用最广的设备。

为了满足好奇心，可以从安卓文件[5]将屏幕的尺寸和分辨率映射到上面数据的密度（“ldpi”，“mdpi”等）及分辨率（“小的”，“标准的”，等等）上。

图5 多样性及分布很高的安卓终端设备的六个例子（手机检测研究，2013年2月）[3]

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

“测试什么”

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

图6 测试安卓设备的各个方面

有必要提前准备覆盖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是一个重大的挑战，但它可以用一个结构化的方法和正确的工具集合以及专业知识被有效解决掉。

Eclipse开发的Android程序可以直接在手机上运行。

运行方式：

1 手机打开 USB调式模式（具体：“设置”->“应用程序”->“开发”->“USB调试”）(不同的手机 *** 作可能打开方式不一样)。

2 将手机连接到电脑。

3 电脑上安装手机USB驱动程序。

4 运行android 应用。

点击工程 run as android application后，系统就会查找已经连接到电脑的设备,选择已经连接的设备即可运行在手机上了。

新建项目：

①打开Eclipse，单击菜单栏的“File”->把鼠标光标移动到“New”->在d出的列表框中，如果直接能看到“Android Applicaion Project”选项项，则直接单击此选项，否则选择最下面的“Other”,在d出的窗口中，展开“Android”项，选择“Android Applicaion Project”，然后“Next”;

②在新d出的窗口中填写相关信息，一路“Next”，直到点击“Finish”，这样第一个Android程序就创建好了，会发现Eclipse左边多了一个新创建的Android项目。

编译Android项目：

选中项目->单击鼠标右键，在d出的列表框中选择“Run As”->单击“Android Application”,这时会发现模拟器自动启动，等到模拟器完全启动好后，就可以看到项目的编译结果了。有没有看到一些东西觉得很眼熟呢？其实那是在创建这个项目时做的，开启Android之旅吧。

以上就是关于android app自动化测试工具有哪些全部的内容，包括:android app自动化测试工具有哪些、Android单元测试都是测一些什么、如何设计Android APP测试用例等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！