Android的Testing和Instrumentation - Android - ITeye技术网站
Android提供了一系列强大的测试工具，它针对Android的环境，扩展了业内标准的JUnit测试框架。尽管你可以使用JUnit测试Android工程，但Android工具允许你为应用程序的各个方面进行更为复杂的测试，包括单元层面及框架层面。
Android测试环境的主要特征有：
l&& 可以访问Android系统对象。
l&& Instrumentation框架可以控制和测试应用程序。
l&& Android系统常用对象的模拟版本。
l&& 运行单个test或test suite的工具，带或不带Instrumentation。
l&& 支持以Eclipse的ADT插件和命令行方式管理Test和Test工程。
这篇文章是对Android测试环境和测试方法的简要介绍，并假设你已经拥有一定的Android应用程序编程及JUnit测试的经验。
Android测试环境的核心是一个Instrumentation框架，在这个框架下，你的测试应用程序可以精确控制应用程序。使用Instrumentation，你可以在主程序启动之前，创建模拟的系统对象，如Context；控制应用程序的多个生命周期；发送UI事件给应用程序；在执行期间检查程序状态。Instrumentation框架通过将主程序和测试程序运行在同一个进程来实现这些功能。
通过在测试工程的manifest文件中添加&instrumentation&元素来指定要测试的应用程序。这个元素的特性指明了要测试的应用程序包名，以及告诉Android如何运行测试程序。在Inustrumentation TestRunner章节有更多的细节描述。
下面的图片概要的描述了Android的测试环境：
在Android中，测试程序也是Android程序，因此，它和被测试程序的书写方式有很多相同的地方。SDK工具能帮助你同时创建主程序工程及它的测试工程。你可以通过Eclipse的ADT插件或者命令行来运行Android测试。Eclipse的ADT提供了大量的工具来创建测试用例，运行以及查看结果。
Testing API
Android提供了基于JUnit测试框架的测试API来书写测试用例和测试程序。另外，Android还提供了强大的Instrumentation框架，允许测试用例访问程序的状态及运行时对象。
下面的章节描述了Android中可利用的主要测试API。
JUnit TestCase类
继承自JUnit的TestCase，不能使用Instrumentation框架。但这些类包含访问系统对象（如Context）的方法。使用Context，你可以浏览资源，文件，数据库等等。基类是AndroidTestCase，一般常见的是它的子类，和特定组件关联。
l&& ApplicationTestCase----测试整个应用程序的类。它允许你注入一个模拟的Context到应用程序中，在应用程序启动之前初始化测试参数，并在应用程序结束之后销毁之前检查应用程序。
l&& ProviderTestCase2----测试单个ContentProvider的类。因为它要求使用MockContentResolver，并注入一个IsolatedContext，因此Provider的测试是与OS孤立的。
l&& ServiceTestCase----测试单个Service的类。你可以注入一个模拟的Context或模拟的Application（或者两者），或者让Android为你提供Context和MockApplication。
Instrumentation TestCase类
继承自JUnit TestCase类，并可以使用Instrumentation框架，用于测试Activity。使用Instrumentation，Android可以向程序发送事件来自动进行UI测试，并可以精确控制Activity的启动，监测Activity生命周期的状态。
基类是InstrumentationTestCase。它的所有子类都能发送按键或触摸事件给UI。子类还可以注入一个模拟的Intent。
l&& ActivityTestCase----Activity测试类的基类。
l&& SingleLaunchActivityTestCase----测试单个Activity的类。它能触发一次setup()和tearDown()，而不是每个方法调用时都触发。如果你的测试方法都是针对同一个Activity的话，那就使用它吧。
l&& SyncBaseInstrumentation----测试Content Provider同步性的类。它使用Instrumentation在启动测试同步性之前取消已经存在的同步对象。
l&& ActivityUnitTestCase----对单个Activity进行单一测试的类。使用它，你可以注入模拟的Context或Application，或者两者。它用于对Activity进行单元测试。
不同于其它的Instrumentation类，这个测试类不能注入模拟的Intent。
l&& ActivityInstrumentationTestCase2----在正常的系统环境中测试单个Activity的类。你不能注入一个模拟的Context，但你可以注入一个模拟的Intent。另外，你还可以在UI线程（应用程序的主线程）运行测试方法，并且可以给应用程序UI发送按键及触摸事件。
Android还继承了JUnit的Assert类，其中，有两个子类，MoreAsserts和ViewAsserts：
l&& MoreAsserts类包含更多强大的断言方法，如assertContainsRegex(String, String)，可以作正则表达式的匹配。
l&& 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中找到这些类。
l&& IsolatedContext----模拟一个Context，这样应用程序可以孤立运行。与此同时，还有大量的代码帮助我们完成与Context的通信。这个类在单元测试时很有用。
l&& RenamingDelegatingContext----当修改默认的文件和数据库名时，可以委托大多数的函数到一个存在的、常规的Context上。使用这个类来测试文件和数据库与正常的系统Context之间的操作。
l&& 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程序测试，你需要使用Android工具创建一个测试工程。工具会创建工程文件夹、文件和所需的子文件夹。工具还会创建一个manifest文件，指定被测试的应用程序。
一个测试程序包含一个或多个测试用例，它们都继承自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上。
测试什么？
除了一些功能测试外，这里还有一些你应该考虑测试的内容：
l&& Activity生命周期事件：你应该测试Activity处理生命周期事件的正确性。例如，一个Activity应该在pause或destroy事件时保存它的状态。记住一点的是屏幕方向的改变也会引发当前Activity销毁，因此，你需要测试这种偶然情况确保不会丢失应用程序状态。
l&& 数据库操作：你应该确保数据库操作能正确处理应用程序状态的变化。使用android.test.mock中的模拟对象。
l&& 屏幕大小和分辨率：在发布程序之前，确保在所有要运行的屏幕大小和分辨率上测试通过。你可以使用***D来测试，或者使用真实的目标设备进行测试。
附加：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 mA // MyActivity is the class name of the app under test
& private Spinner mS
& 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文件中添加一个权限，然后就能在程序中关闭键盘保护。注意，你必须在发布程序之前移除这个，或者在发布的程序中禁用这个功能。
在&manifest&元素下添加&uses-permission android:name=”androd.permission.DISABLE_KEYGUARD”/&。为了关闭键盘保护，在你测试的Activity的onCreate()方法中添加以下代码：
& mKeyGuardManager = (KeyguardManager)getSystemService(KEYGUARD_SERVICE);
& mLock = mKeyGuardManager.newKeyguardLock("activity_classname");
& mLock.disableKeyguard();
这里，activity_classname是Activity的类名。
浏览 13752
yelinsen05
浏览: 367238 次
来自: 杭州
请教一个问题，使用测试项目测试Activity时，因为应用一般 ...
android:sharedUserId=&andr ...
fengyuxing168 写道yelinsen05 写道fe ...
yelinsen05 写道fengyuxing168 写道 很 ...
fengyuxing168 写道 很酷哈~~~什么？您所在位置： &
 &  & 
基于Android平台的自动化测试的研究和实现.pdf59页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
文档加载中...广告还剩秒
需要金币：200 &&
你可能关注的文档：
??????????
??????????
THESTUDYAND ASED OFANDROID．B TESTⅢGFRAMEWORK l|IIIIIIIIIIIIIIIIIIIHIIIIIIIIII AThesisSubmittedto Southeast University FortheAcademicofMasterof Degree Engineering BY LIU Ming Supervisedby Prof．XUZaoLin S．E．Ⅲ7ANGW．enXm ofSoftware College Engineering Southeast University 2012 September 东南大学学位论文独创性声明 本人声明所呈交的学位论文是我个人在导师指导下进行的研究工作及取得
的研究成果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包
含其他人已经发表或撰写过的研究成果，也不包含为获得东南大学或其它教育
机构的学位或***而使用过的材料。与我一同工作的同志对本研究所做的任何
贡献均已在论文中作了明确的说明并表示了谢意。 研究生签名： 堂!l!兰垄： 日
期： 圣垒!兰：l2．24 东南大学学位论文使用授权声明 东南大学、中国科学技术信息研究所、国家图书馆有权保留本人所送交学
位论文的复印件和电子文档，可以采用影印、缩印或其他复制手段保存论文。
本人电子文档的内容和纸质论文的内容相一致。除在保密期内的保密论文外，
允许论文被查阅和借阅，可以公布 包括刊登 论文的全部或部分内容。论文
的公布 包括刊登 授权东南大学研究生院办理。
研究生签名： 赵3皇圣：
．导师签名：名替日 期：2。R-2．2咿 摘要 捅要 在移动互联网快速发展的环境下，智能手机操作系统开始快速普及，
Android、IOS等操作系统占据市场绝大部分的份额。与此同时，终端上的应用
软件种类也越来越多，功能越来越丰富，在带给用于方便的同时，也给软件的
质量保证带来了挑战。在软件测试中，自动化测试是对手工测试的一种补充，
同时，自动化测试也是软件测试发展的一个必然趋势，随着软件
正在加载中，请稍后...关注51Testing
如何设计Android App测试用例
发表于： 10:53 &作者：Erik Nijkamp & 来源：51Testing软件测试网采编
推荐标签：
　　在当今竞争激烈的市场上一个APP的成功离不开一个可靠的用户界面（UI）。因此，对功能和用户体验有一些特殊关注和照顾的UI的全面是必不可少的。当涉及到安卓平台及其提出的独特问题的数量（安卓就UI提出显著挑战）时，挑战变得更加复杂。关键字“碎片化”象征着应用全面测试的最大障碍，还表明了发布到市场上的所有形态、大小、配置类型的安卓设备所引起的困难。本文将介绍安卓模拟器如何能通过使用一些技巧和简单的实践提供覆盖大量设备类型的广泛测试。　　简介—分散装置里的测试　　一般安卓开发者在其日常中面临的最大挑战之一是：终端设备和版本的范围太广。OpenSignal进行的一项研究表明，2013年7月市场上有超过11，828的不同安卓终端设备，所有设备在类型/大小/屏幕分辨率以及特定配置方面有所不同。考虑到前一年的调查仅记录有3，997款不同设备，这实在是一个越来越大的挑战障碍。　　图1.11，828 款安卓设备类型（ OpenSignal研究， 2013年7月[ 1 ] ）分布　　从一个移动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 ）。　　图2.16款安卓版本分布（OpenSignal研究，2013年7月[1]）　　考虑设备显示器，一项TechCrunch从2013年4月进行的研究显示，绝大多数（79.9％）有效设备正在使用尺寸为3和4.5英寸的“正常”屏幕。这些设备的屏幕密度在“MDPI”（160 DPI），“hdpi”（240 DPI）和“xhdpi”（320 DPI）之间变化。也有例外， 一种只占9.5％的设备屏幕密度低“hdpi”（120 DPI）且屏幕小。　　图3. 常见的屏幕尺寸和密度的分布（研究，2013年4月）[2]　　如果这种多样性在质量保证过程中被忽略了，那么绝对可以预见：bugs会潜入应用程序，然后是bug报告的风暴，最后 Play Store中出现负面用户评论。因此，目前的问题是：你怎么使用合理水平的测试工作切实解决这一挑战？定义及一个伴随测试过程是一个应付这一挑战的有效武器。　　用例—“在哪测试”、“测试什么”、“怎么测试”、“何时测试”？　　“在哪测试”　　为了节省你测试工作上所花的昂贵时间，我们建议首先要减少之前所提到的32个安卓版本组合及代表市场上在用的领先设备屏的5-10个版本的显示屏。选择参考设备时，你应该确保覆盖了足够广范围的版本和屏幕类型。作为参考，您可以使用OpenSignal的调查或使用检测的信息图[3]，来帮助选择使用最广的设备。
搜索风云榜
51Testing官方微信
51Testing官方微博
测试知识全知道