Activity测试依赖于Android Instrumentation测试框架。有其他组件不同的是Activity有更复杂的生命周期，这些生命周期函数不能直接地被调用，而只能通过Instrumentation发送事件来触发它们。
这篇文档描述了怎么样使用Instrumentation和其他测试工具来进行自动化测试。在阅读它之前，你应该先阅读Android测试基础，它介绍了何为Android自动化测试与Instrumentation框架。
Activity测试的基类是InstrumentationTestCase, 它为Activity测试所用的几个类提供Instrumentation支持。
在Activity测试中，这个基类能够提供以下三个功能：
生命周期控制：你可以使用Instrumentation来调用Activity的onResume、onPause、onDestroy等方法, 从而控制它的生命周期。
依赖注入：你可以使用Instrumentation制造出伪Context或伪Application，这样能够帮助你更好地控制测试环境，通过自定义Intent启动Activity。
用户界面交互：你可以使用Instrumentation直接发送按键信息和触屏事件。
Activity测试类通过继承TestCase和Assert实现了JUnit测试框架，你可以在测试的过程中使用。
两个主要用的测试子类是ActivityInstrumentationTestCase2和ActivityUnitTestCase，不过当Activity的launchMode设置为非standard属性时，你需要用SingleLaunchActivityTestCase;
这个类可以用来测试同一个应用的多个Activity，它拥有正常的应用实例环境和Context，可以接触到正常的系统结构（文件、数据库等）。你可以发送伪装的Intent给Activity，测试你的程序是否对接收到的各种Intent进行了正确处理。 注意:这个类中不能伪Context和伪Application，所以你无法将测试从系统环境中独立出来。
这个类是用来测试单个Activity的。它可以运行在独立的测试环境中，你可以通过在启动Activity前设置Context或Application（当然都设置也可以）来实现模拟环境。你可以在自己的虚拟环境中测试程序而不会对系统、文件等造成实际的影响。在这个测试类下你无法向正在测试的Activity发送Intent，不过你可以在启动Activity的时候调用Activity.startActivity(Intent)来查看接收到的参数。
这个类可以很方便地用来测试单个Activity。由于它只会调用一次setUp()和tearDown()（而不是每次方法都中都会调用），所以在这个实例中的所有测试方法共享一个测试环境。在这个类中不允许你加入任何的伪Object。
这个类在测试Activity的launchMode属性不是standard的时候非常有用，它保证了测试环境的不变，所以你可以用它来测试Activity是否对多次重复调用做出了正确应对。
这一段内容是要告诉你怎么在Android测试中使用android.test.mock包中所定义的一系列伪Object。
MockApplication只可以在ActivityUnitTestCase中使用，你可以通过setApplication()来指定它（必须在startActivity之前调用）。若不指定的话，ActivityUnitTestCase会自己生成一个伪Application。(MockContext可以通过setActivityContext()指定)
ViewAsserts定义了供View使用的一些判断语句，它可以检查View内容的位置、对其情况和状态。
输入合法性：你可以测试Activity是否对EditText的各类输入做出了正常反应。通过模拟输入一串信息发送给Activity，使用findViewById(int)来检查View的状态。你可以通过设置一个Button当输入异常时disable，输入正常时enable来，然后通过assertEquals(button.isEnabled(), true)检测。你还可以通过设置错误输入检查Activity是否进行了合适的处理。
生命周期控制：你可以测试程序中的Activity是否正常处理了生命周期的各个轮转情况。一个合格的Activity应该在pause或destroy时保存一些下次运行时需要的状态。 记住若屏幕布局方向改变（如竖屏变为横屏）会引起Activity的destroy过程，你应该保证设备外部移动不会引起应用数据丢失。
Intent测试：你可以测试每个Activity是否正常处理了它在manifest文件下ActivityInstrumentationTestCase2测试中发送伪Intent给Activity。
运行时设置改动： 你可以模拟设备的设置改变（如屏幕方向改变、语言改变等）来测试正在运行中的Activity的应对是否正确。在Handling Runtime Changes一文中讲述了Activity如何应对运行时设备设置改变。
设备尺寸以及分辨率的适配: 在你的应用要发布之前，你应该保证它在各式各样的屏幕上运行正常，可以通过ViewAsserts来自动化检测布局情况。你可以在各式各样的安卓虚拟机上运行测试，或在直接目标机型上运行。你可以在Support Multiple Screens上查看应用如何支持多样化屏幕。
在Testing from Eclipse with ADT一文中讲述了怎么使用Eclipse来进行Android自动化测试，Testring from Other IDEs一文中讲述了其他开发工具的Android测试使用。
你可以通过Activity Testing Tutorial来循序渐进地学习如何做Activity自动化测试，这篇文章为你提供了测试以Activity为主的应用的方案。
以下这部分内容是对于一些UI测试的tips，特别是当你要测试主线程中的动作（触屏、输入和锁屏等事件）时，你应该仔细看一下这部分内容。
应用的Activities是运行在主线程上的。一旦UI界面实例化（举个简单的例子：当Activity的onCreate方法经调用后UI即会实例化），那么所有和UI界面交互的事件都必须在主线程里面发生。当你正常启动应用时，必须按照这个规则程序才能够正常运行。但是在以Instrumentation为基础的测试中（其他类测试不可以），你可以在测试程序中对UI进行操作。
如果要让整个测试函数都在主线程中运行，你可以给函数加上注解@UiThreadTest，但是这种情况下会让整个函数中的所有语句都运行在主线程中，这种情况下不和UI组件交互的语句是不允许的（如Instrumentation.waitForIdleSync()）。
让一个测试函数中的一部分在主线程中运行，你可以调用的appActivity.runOnUiThread()办法（appActivity是你在测试中拥有的Activity实例），将你想要运行在主线程中的东西放入一个匿名内部类Runnable中然后传给它。
举个例子，这段代码测试了一个Activity实力，控制Spinner获取焦点，并发送给它一个触屏事件。注意waitForIdleSync和sendKeys是不允许运行在主线程中的。
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);为了让模拟器或者设备接收到测试程序的按键，你需要屏蔽掉设备的物理的按键和触屏事件。如果不这么做的话，测试程序发来的此类事件是不会起作用的。
你可以通过调用ActivityInstrumentationTestCase2.setActivityTouchMode(false)来做到这点（在getActivity()之间调用这条语句才会起到作用）。 注意，你不能在运行在主线程的语句中调用它，所以它不可以出现在含有@UiThreadTest注解的函数中，实际上最好的办法就是在setUp()方法中做这件事。
你可能发现UI测试在屏幕锁屏（或其他加密手段）时是无法使用的，因为在这种情况下应用无法接收到sendKeys()发送的事件。最好的解决办法就是先解锁设备再进行测试。
当然你也可以通过在onCreate中加上以下这段代码来显式地禁用锁屏，不过你需要为应用加上权限<uses-permission android:name="android.permission.DISABLE_KEYGUARD"/>。
mKeyGuardManager = (KeyguardManager) getSystemService(KEYGUARD_SERVICE);
mLock = mKeyGuardManager.newKeyguardLock("activity_classname");
mLock.disableKeyguard();这部分列出了一些在UI测试中比较多发生的错误。
WrongThreadException:
问题:
遇到错误消息：android.view.ViewRoot$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.而导致测试崩溃。
可能的原因：
如果从非UI线程中和UI进行交互就会发生这个问题。当在测试中UI控件交互而你不加@UiThreadTest注解或者不在runOnUiThread()方法中进行的话，它会在非主进程中执行这些命令，这个错误就会发生。
建议：
在主进程中和UI交互，并且使用支持Instrumentation的测试类。你可以在Testing on UI Thread找到更多消息。
java.lang.RuntimeException:
问题：
由错误消息java.lang.RuntimeException: This method can not be called from the main application thread所导致的测试崩溃。
可能的原因：
这个错误经常发生在你在@UiThreadTest注解的函数中调用了runOnUiThread()或其他不在UI进程中运行的语句。
建议：
你可以通过尝试去掉@UiThreadTest注解，或去掉runOnUiThread()，或重写测试程序来尝试解决。
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8