简介

自动化测试：一般是指软件测试的自动化，软件测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。
黑盒测试：黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

白盒测试：白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。深入到代码一级的测试，使用这种技术发现问题最早，效果也是最好的。
回归测试：回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
除此之外还有压力测试、安全性测试等等

自动化测试思想

自动化测试的发展，经历了传统的“录制-回放”（模拟用户对计算机的操作，类似于按键精灵，对环境的依赖性太强，对变化太过敏感），脚本化的自动化测试（在此开始了模块化与库思想），最后是现在的集成了包括数据驱动与关键字驱动思想的各种自动化测试软件。
模块化思想（就是将一个测试用例中的几个不同的测试点拆分并且将其单个点的测试步骤进行了封装，形成了一个模块。例如：一个测试用例要对一个登录程序进行测试，其中包括：用户名输入、密码输入、以及确定登录；那么就可以将用户名输入、密码输入、确定登录、取消登录四个操作分别封装在四个不同的模块中。测试时，只需调用其模块即可。这样的话，当一个模块有变化，你只需单独维护那个模块即可，也可以根据模块的不同组合成不同的测试用例。）
测试库思想（就是模块化思想的升华，其为应用程序的测试创造了库文件，这些库文件为一系列函数的集合。其与模块化思想不同的是，其拓展了接口思想，即可以通过接口去传递参数，而不是一个封死的模块。例如：还是以上那个测试用例，只是将用户名输入、密码输入、确定登录、取消登录封装成一个库，这个库含有一个函数Login，这个函数Login接收两个参数“用户名、密码”，对输入不同的用户名和密码可以进行不同的测试用例）
数据驱动思想（不同的数据导致了不同的结果的产生）
关键字思想（关键字驱动就是一种面向对象的思想，对象可以为一个数据或者一个关键字，对对象的抓取，可以将其测试对象封装为一个关键字（即可以将gui元素封装成了一个个关键字），这样可以对其关键对象进行各种操作了，不同的对象可以驱动不同的测试流向与结果。）

Android 自动化测试框架

Monkey： 是Android SDK自带的测试工具，在测试过程中会向系统发送伪随机的用户事件流，如按键输入、触摸屏输入、手势输入等)，实现对正在开发的应用程序进行压力测试，也有日志输出。实际上该工具只能做程序做一些压力测试，由于测试事件和数据都是随机的，不能自定义，所以有很大的局限性。使用moneky更多的是开发team，而不是纯粹的测试team，毕竟要求对android开发比较了解才用得了monkey。
MonkeyRunner： 也是Android SDK提供的测试工具。严格意义上来说MonkeyRunner其实是一个Api工具包，比Monkey强大，可以编写测试脚本来自定义数据、事件。缺点是脚本用Python来写，对测试人员来说要求较高，有比较大的学习成本。
Instrumentation： 是早期Google提供的Android自动化测试工具类，虽然在那时候JUnit也可以对Android进行测试，但是Instrumentation允许你对应用程序做更为复杂的测试，甚至是框架层面的。通过Instrumentation你可以模拟按键按下、抬起、屏幕点击、滚动等事件。Instrumentation是通过将主程序和测试程序运行在同一个进程来实现这些功能，你可以把Instrumentation看成一个类似Activity或者Service并且不带界面的组件，在程序运行期间监控你的主程序。缺点是对测试人员来说编写代码能力要求较高，需要对Android相关知识有一定了解，还需要配置AndroidManifest.xml文件，不能跨多个App。
UiAutomator： 也是Android提供的自动化测试框架，基本上支持所有的Android事件操作，对比Instrumentation它不需要测试人员了解代码实现细节（可以用UiAutomatorviewer抓取App页面上的控件属性而不看源码）。基于Java，测试代码结构简单、编写容易、学习成本，一次编译，所有设备或模拟器都能运行测试，能跨App（比如：很多App有选择相册、打开相机拍照，这就是跨App测试）。缺点是只支持SDK 16（Android 4.1）及以上，不支持Hybird App、WebApp。
Selendroid：是基于Instrumentation的测试框架，可以测试Native App、Hybird App、Web App，但是网上资料较少，社区活跃度也不大。
Robotium： 也是基于Instrumentation的测试框架，目前国内外用的比较多，资料比较多，社区也比较活跃。缺点是对测试人员来说要有一定的Java基础，了解Android基本组件，不能跨App。这家伙号称是黑盒，但是本人不太认同～因为使用robotium需要知道package和acitivity这样的细节，即便不是开发人员来做，也得从开发人员那里获得不少开发文档才能做。
Espresso： 是Google的开源自动化测试框架。相对于Robotium和UIAutomator，它的特点是规模更小、更简洁，API更加精确，编写测试代码简单，容易快速上手。因为是基于Instrumentation的，所以不能跨App。
Athrun： 是淘宝出的一个移动测试框架/平台，同时支持iOS和Android。Android部分也是基于Instrumentation，在Android原有的ActivityInstrumentationTestCase2类基础上进行了扩展，提供一整套面向对象的API。
Appium： 是最近比较热门的框架，社区也很活跃。这个框架应该是是功能最强大的，

它的优点：
- 开源；
- 支持Native App、Hybird App、Web App；
- 支持Android、iOS、Firefox OS；
- Server也是跨平台的，你可以使用Mac OS X、Windows或者Linux；
它的哲理是：
- 用Appium自动化测试不需要重新编译App；
- 支持很多语言来编写测试脚本，Java、Javascript、PHP、Python、C#、Ruby等主流语言；
- 不需要为了自动化测试来重造轮子，因为扩展了WebDriver。（WebDriver是测试WebApps的一种简单、快速的自动化测试框架，所以有Web自动化测试经验的测试人员可以直接上手）；
- 移动端自动化测试应该是开源的；
它的设计理念：
- 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，方便测试人员操作。
相关限制：
- 如果你在Windows使用Appium，你没法使用预编译专用于OS X的.app文件，因为Appium依赖OS X专用的库来支持iOS测试，所以在Windows平台你不能测试iOS Apps。这意味着你只能通过在Mac上来运行iOS测试。
总结：
- 在iOS部分是封装了UIAutomation；Android 4.2以上是用UiAutomator，Android 2.3 ~ 4.1用的是 Instrumentation，也就说Appium同时封装了UiAutomator和Instrumentation。所以Appium拥有了以上几大框架的所有优点：跨App，支持Native App、Hybird App、Web App，还支持N种语言来编写你的测试脚本。

IOS自动化测试可以使用automation框架，Android目前使用的是robotium，可以实现按指定路径进行操作和进行压测，并记录必要的信息，以及对保存下的图片进行比较得出是否图片处理结果正确的结论，但是appium是趋势，只是目前框架还不够成熟。
Robotium需要对app进行重签名，是一款国外的Android自动化测试框架，主要针对Android平台的应用进行黑盒自动化测试，它提供了模拟各种手势操作（点击、长按、滑动等）、查找和断言机制的API，能够对各种控件进行操作。Robotium结合Android官方提供的测试框架 Instrumentation达到对应用程序进行自动化的测试。另外，Robotium 4.0版本已经支持对WebView的操作。Robotium 对Activity，Dialog，Toast，Menu 都是支持的。

Instrumentation介绍

Testing API

Android提供了基于JUnit测试框架的测试API来书写测试用例和测试程序。另外，Android还提供了强大的Instrumentation框架，允许测试用例访问程序的状态及运行时对象。

JUnit TestCase类

继承自JUnit的TestCase，不能使用Instrumentation框架。但这些类包含访问系统对象（如Context）的方法。使用Context，你可以浏览资源，文件，数据库等等。基类是AndroidTestCase，一般常见的是它的子类，和特定组件关联。
子类有：

ApplicationTestCase——测试整个应用程序的类。它允许你注入一个模拟的Context到应用程序中，在应用程序启动之前初始化测试参数，并在应用程序结束之后销毁之前检查应用程序。
ProviderTestCase2——测试单个ContentProvider的类。因为它要求使用MockContentResolver，并注入一个IsolatedContext，因此Provider的测试是与OS孤立的。
ServiceTestCase——测试单个Service的类。你可以注入一个模拟的Context或模拟的Application（或者两者），或者让Android为你提供Context和MockApplication。

Instrumentation TestCase类

继承自JUnit TestCase类，并可以使用Instrumentation框架，用于测试Activity。使用Instrumentation，Android可以向程序发送事件来自动进行UI测试，并可以精确控制Activity的启动，监测Activity生命周期的状态。
基类是InstrumentationTestCase。它的所有子类都能发送按键或触摸事件给UI。子类还可以注入一个模拟的Intent。
子类有：

ActivityTestCase——Activity测试类的基类。
SingleLaunchActivityTestCase——测试单个Activity的类。它能触发一次setup()和tearDown()，而不是每个方法调用时都触发。如果你的测试方法都是针对同一个Activity的话，那就使用它吧。
SyncBaseInstrumentation——测试Content Provider同步性的类。它使用Instrumentation在启动测试同步性之前取消已经存在的同步对象。
ActivityUnitTestCase——对单个Activity进行单一测试的类。使用它，你可以注入模拟的Context或Application，或者两者。它用于对Activity进行单元测试。
不同于其它的Instrumentation类，这个测试类不能注入模拟的Intent。
ActivityInstrumentationTestCase2——在正常的系统环境中测试单个Activity的类。你不能注入一个模拟的Context，但你可以注入一个模拟的Intent。另外，你还可以在UI线程（应用程序的主线程）运行测试方法，并且可以给应用程序UI发送按键及触摸事件。

Assert类

Android还继承了JUnit的Assert类，其中，有两个子类，MoreAsserts和ViewAsserts：

MoreAsserts类包含更多强大的断言方法，如assertContainsRegex(String, String)，可以作正则表达式的匹配。
ViewAsserts类包含关于Android View的有用断言方法，如assertHasScreenCoordinates(View, View, int, int)，可以测试View在可视区域的特定X、Y位置。这些Assert简化了UI中几何图形和对齐方式的测试。

Mock对象类

Android有一些类可以方便的创建模拟的系统对象，如Application，Context，Content Resolver和Resource。Android还在一些测试类中提供了一些方法来创建模拟的Intent。因为这些模拟的对象比实际对象更容易使用，因此，使用它们能简化依赖注入。你可以在android.test和android.test.mock中找到这些类。
它们是：

IsolatedContext——模拟一个Context，这样应用程序可以孤立运行。与此同时，还有大量的代码帮助我们完成与Context的通信。这个类在单元测试时很有用。
RenamingDelegatingContext——当修改默认的文件和数据库名时，可以委托大多数的函数到一个存在的、常规的Context上。使用这个类来测试文件和数据库与正常的系统Context之间的操作。
MockApplication,MockContentResolver,MockContext,MockDialogInterface,MockPackageManager,MockResources——创建模拟的系统对象的类。它们只暴露那些对对象的管理有用的方法。这些方法的默认实现只是抛出异常。你需要继承这些类并重写这些方法。

Instrumentation TestRunner

Android提供了自定义的运行测试用例的类，叫做InstrumentationTestRunner。这个类控制应用程序处于测试环境中，在同一个进程中运行测试程序和主程序，并且将测试结果输出到合适的地方。IntrumentationTestRunner在运行时对整个测试环境的控制能力的关键是使用Instrumentation。注意，如果你的测试类不使用Instrumentation的话，你也可以使用这个TestRunner。
当你运行一个测试程序时，首先会运行一个系统工具叫做Activity Manager。Activity Manager使用Instrumentation框架来启动和控制TestRunner，这个TestRunner反过来又使用Intrumentation来关闭任何主程序的实例，然后启动测试程序及主程序（同一个进程中）。这就能确保测试程序与主程序间的直接交互。

在测试环境中工作

对Android程序的测试都包含在一个测试程序里，它本身也是一个Android应用程序。测试程序以单独的Android工程存在，与正常的Android程序有着相同的文件和文件夹。测试工程通过在manifest文件中指定要测试的应用程序。
每个测试程序包含一个或多个针对特定类型组件的测试用例。测试用例里定义了测试应用程序某些部分的测试方法。当你运行测试程序，Android会在相同进程里加载主程序，然后触发每个测试用例里的测试方法。

测试用例

一个测试程序包含一个或多个测试用例，它们都继承自Android TestCase类。选择一个测试用例类取决于你要测试的Android组件的类型以及你要做什么样的测试。一个测试程序可以测试不同的组件，但每个测试用例类设计时只能测试单一类型的组件。
一些Android组件有多个关联的测试用例类。在这种情况下，在可选择的类间，你需要判断你要进行的测试类型。例如，对于Activity来说，你有两个选择，ActivityInstrumentationTestCase2和ActivityUnitTestCase。
ActivityInstrumentationTestCase2设计用于进行一些功能性的测试，因此，它在一个正常的系统环境中测试Activity。你可以注入模拟的Intent，但不能是模拟的Context。一般来说，你不能模拟Activity间的依赖关系。
相比而言，ActivityUnitTestCase设计用于单元测试，因此，它在一个孤立的系统环境中测试Activity。换句话说，当你使用这个测试类时，Activity不能与其它Activity交互。
作为一个经验法则，如果你想测试Activity与Android的交互的话，使用ActivityInstrumentationTestCase2。如果你想对一个Activity做回归测试的话，使用ActivityUnitTestCase。

测试方法

每个测试用例类提供了可以建立测试环境和控制应用程序的方法。例如，所有的测试用例类都提供了JUnit的setUp()方法来搭建测试环境。另外，你可以添加方法来定义单独的测试。当你运行测试程序时，每个添加的方法都会运行一次。如果你重写了setUp()方法，它会在每个方法运行前运行。相似的，tearDown()方法会在每个方法之后运行。
测试用例类提供了大量的对组件启动和停止控制的方法。由于这个原因，在运行测试之前，你需要明确告诉Android启动一个组件。例如，你可以使用getActivity()来启动一个Activity。在整个测试用例期间，你只能调用这个方法一次，或者每个测试方法一次。甚至你可以在单个测试方法中，调用它的finishing()来销毁Activity，然后再调用getActivity()重新启动一个。

运行测试并查看结果

编译完测试工程后，你就可以使用系统工具Activity Manager来运行测试程序。你给Activity Manager提供了TestRunner的名（一般是InstrumentationTestRunner，在程序中指定）；名包括被测试程序的包名和TestRunner的名。Activity Manager加载并启动你的测试程序，杀死主程序的任何实例，然后在测试程序的同一个进程里加载主程序，然后传递测试程序的第一个测试用例。这个时候，TestRunner会接管这些测试用例，运行里面的每个测试方法，直到所有的方法运行结束。
如果你使用Eclipse，结果会在JUnit的面板中显示。如果你使用命令行，将输出到STDOUT上。

测试什么？

除了一些功能测试外，这里还有一些你应该考虑测试的内容：

Activity生命周期事件：你应该测试Activity处理生命周期事件的正确性。例如，一个Activity应该在pause或destroy事件时保存它的状态。记住一点的是屏幕方向的改变也会引发当前Activity销毁，因此，你需要测试这种偶然情况确保不会丢失应用程序状态。
数据库操作：你应该确保数据库操作能正确处理应用程序状态的变化。使用android.test.mock中的模拟对象。
屏幕大小和分辨率：在发布程序之前，确保在所有要运行的屏幕大小和分辨率上测试通过。你可以使用AVD来测试，或者使用真实的目标设备进行测试。

附加：UI测试

接下来的章节为应用程序UI的测试提供了一些提示，特别是帮助你在UI线程里处理动作，触屏和按键事件，和锁屏。

　UI线程中测试

Activity运行在程序的UI线程里。一旦UI初始化后，例如在Activity的onCreate()方法后，所有与UI的交互都必须运行在UI线程里。当你正常运行程序时，它有权限可以访问这个线程，并且不会出现什么特别的事情。
当你运行测试程序时，这一点发生了变化。在带有instrumentation的类里，你可以触发方法在UI线程里运行。其它的测试用例类不允许这么做。为了一个完整的测试方法都在UI线程里运行，你可以使用@UIThreadTest来声明线程。注意，这将会在UI线程里运行方法里所有的语句。不与UI交互的方法不允许这么做；例如，你不能触发Instrumentation.waitForIdleSync()。
如果让方法中的一部分代码运行在UI线程的话，创建一个匿名的Runnable对象，把代码放到run()方法中，然后把这个对象传递给appActivity.runOnUiThread()，在这里，appActivity就是你要测试的app对象。
例如，下面的代码实例化了一个要测试的Activity，为Spinner请求焦点，然后发送一个按键给它。注意：waitForIdleSync和sendKeys不允许在UI线程里运行：


private MyActivity mActivity; // MyActivity is the class name of the app under test 
  private Spinner mSpinner; 

  ... 

  protected void setUp() throws Exception { 
      super.setUp(); 
      mInstrumentation = getInstrumentation(); 

      mActivity = getActivity(); // get a references to the app under test 

      /* 
       * Get a reference to the main widget of the app under test, a Spinner 
       */ 
      mSpinner = (Spinner) mActivity.findViewById(com.android.demo.myactivity.R.id.Spinner01); 

  ... 

  public void aTest() { 
      /* 
       * request focus for the Spinner, so that the test can send key events to it 
       * This request must be run on the UI thread. To do this, use the runOnUiThread method 
       * and pass it a Runnable that contains a call to requestFocus on the Spinner. 
       */ 
      mActivity.runOnUiThread(new Runnable() { 
          public void run() { 
              mSpinner.requestFocus(); 
          } 
      }); 

      mInstrumentation.waitForIdleSync(); 

      this.sendKeys(KeyEvent.KEYCODE_DPAD_CENTER);

关闭触屏模式

为了控制从测试程序中发送给模拟器或设备的按键事件，你必须关闭触屏模式。如果你不这么做，按键事件将被忽略。
关闭触摸模式，你需要在调用getActivity()启动Activity之前调用ActivityInstrumentationTestCase2.setActivityTouchMode(false)。你必须在非UI线程中运行这个调用。基于这个原因，你不能在声明有@UIThread的测试方法调用。可以在setUp()中调用。

模拟器或设备的解锁

你可能已经发现，如果模拟器或设备的键盘保护模式使得HOME画面不可用时，UI测试不能正常工作。这是因为应用程序不能接收sendKeys()的事件。避免这种情况最好的方式是在启动模拟器或设备时关闭键盘保护模式。
你还可以显式地关闭键盘保护。这需要在manifest文件中添加一个权限，然后就能在程序中关闭键盘保护。注意，你必须在发布程序之前移除这个，或者在发布的程序中禁用这个功能。
在元素下添加。为了关闭键盘保护，在你测试的Activity的onCreate()方法中添加以下代码：


mKeyGuardManager = (KeyguardManager)getSystemService(KEYGUARD_SERVICE); 
mLock = mKeyGuardManager.newKeyguardLock("activity_classname"); 
mLock.disableKeyguard();

这里，activity_classname是Activity的类名。

Robotium(未完待整理)

项目创建流程与配置

Studio目前如果抛弃代码直接写测试用例运行会一直找不到被测试App，如果与项目一起编写，放于项目的anroidTest目录下，则可以共享资源与正常测试，时间问题暂时没找到原因，不知道是否是Studio的机制问题，毕竟创建一个项目它就自带了一个androidTest

Robotium 进阶

封装成APK，保存日志信息与截屏
跨应用测试

简介

自动化测试思想

Android 自动化测试框架

Instrumentation介绍

Testing API

JUnit TestCase类

Instrumentation TestCase类

Assert类

Mock对象类

Instrumentation TestRunner

在测试环境中工作

测试用例

测试方法

运行测试并查看结果

测试什么？

附加：UI测试

UI线程中测试

关闭触屏模式

模拟器或设备的解锁

Robotium(未完待整理)

项目创建流程与配置

Robotium 进阶

Appium(未完待整理)

　UI线程中测试