中国测试平台网

 

 

联盟宣传墙 【专题】 测试入门—Android应用测试指南(1)! ...
查看: 9914|回复: 15
go

【专题】 测试入门—Android应用测试指南(1)!

Rank: 9Rank: 9Rank: 9Rank: 9Rank: 9Rank: 9Rank: 9Rank: 9Rank: 9

  20140328162721-1658756519.jpg (29.86 KB, 下载次数: 11)

       第1章  测 试 入 门
  本章介绍了不同类型的测试方法,它们在软件开发项目工程中的基本用法以及在Android项目中特殊用法。
  关于"Android"和"开放
手机联盟",很多书中都有谈及,我们就不累述。本书涉及更高级的主题,我们希望在您阅读本书之前,最好有Android程序开发经验。不过,我们会先回顾一下测试的基本概念、技术、框架以及Android平台上的测试工具。
  1.1  简史
  Android平台是在2007年末引进的。那时候,基于Android平台测试的技术支持很少,而且我们中一些人习惯于边开发边测试,将测试作为开发流程中紧密耦合的一部分,因此,是时候开发一些框架和工具来支持这种测试方式了。
  那时候,Android平台用Junit提供了一些不够成熟的功能支持
单元测试,但是,支持力度不够并且帮助文档很少。
  在我编写自己的库和工具的过程中,发现了Phil Smith的Positron库。他的库是开源的,非常适用于
Android测试。于是,我在他的杰作基础上进行补充,新增功能、弥补不足。他们的库中不包含某些自动化测试的东西,所以我新起了一个项目与之互补,项目命名为Electron。Positron和Electron两个项目,当然不是像真正的正反粒子那样互斥,相反,它们像正反粒子那样蕴含着大能量,能产生大量的光波。
  后来,2008年初,Electron项目参加第一届Android开发挑战赛。虽然在一些类目中,Electron的分数不错,但是在框架类项目比赛中毫无立足之地。那个时候,Eclipse上已经可以执行单元测试了。但是,并不是在真机上执行测试,而是在本地开发机上的JVM虚拟机上。
  
Google也提供了执行应用程序的模拟器代码,通过Instrumention类实现了这一功能。当你打开模拟器运行程序时,Instrument类会在你应用程序之前初始化,可以通过Instrument来模拟各种系统交互,执行程序。我们通过AndriodManifest.xml文件来设置模拟器。
  在Android发展演变早期,我开始在博客里写一些文章来弥补这块测试的空白。本书就是将这些工作的演变和完成过程,用一种有序、容易理解的方式写下来,让你接触那些Android测试中的问题。
  1.2  软件Bug
  无论你多努力,代码设计花费多少时间,编程时候有多小心,你的程序中都会有Bug,这是不可避免的。
  Bug和软件开发是息息相关的。硬件工程中,用Bug这个单词来描述瑕疵、问题、错误已经有几十年了,甚至比计算机出现得还早。尽管如此,关于Bug这个单词的故事是由哈佛大学的Mark II计算机操作员创造的,1878年,在托马斯爱迪生给普斯卡斯蒂瓦达的信中可以看到这个单词的早期应用。
  "我所有的发明都如此。第一步是直觉,随之是头脑风暴,然后困难都浮现出来。这些困难一点点被解决,然后Bug出现了,这些Bug就是所谓的小错误和困难。Bug出现后,需要投入几个月的精力去密切观察、学习,最终达到商业上的成功,否则,必然失败。"
  Bug是如何严重影响你的项目的呢?
  众所周知,Bug会从很多方面对你的项目工程造成影响,越早发现修复越好。无论你是为了优化用户体验, 开发一个简单的Android程序;还是为设备操作员新建一个Android客户版本,Bug都在延迟你的交付时间,燃烧你的金钱。
  在所有的软件研发模式中,"测试驱动开发"是软件开发流程中最敏捷的方式。它驱使你在开发过程中更早地发现、面对Bug,你也很可能预先解决更多的问题。
  此外,比起那些在最后才进行测试的团队,利用这种测试驱动开发模式的研发团队,生产效率更高。如果你在
移动行业参与软件开发,有理由相信赶时间的情况下,"测试驱动开发"这种方案不合适。因为,通常这种方式解决的问题都很可能是已经规避了的,这点很有趣。
  2002年美国国家研究所的一项研究调查表明,每年软件Bug损失595亿美元,如果
软件测试执行得更好的话,超过三分之一的损失是可以避免的。
  然而,请别误解以上所说的。软件开发没有特效药,是什么让你高效,让你的项目易于管理?是你有条理地利用这些方法和技术,掌控你的项目。

cceb6d9d42af6829012d67d43c1031eb.png (34.55 KB, 下载次数: 11)



    1.3  为什么要测试、测什么、如何测、何时测试
  大家都清楚早期发现Bug会节约一大笔项目资源、减少软件维护费用。这就是为开发项目写测试用例的最好理由,不久你就会发现效率提高了。
  另外,写测试用例的过程中,迫使你对需求了解更透彻,对要解决的问题了解更深入全面。如果你不了解被测对象,是不可能写好测试用例的。同样,写好测试用例可以清晰了解老程序和第三方代码,让你能力倍增,更加有信心升级(老程序、第三方)代码。
  测试覆盖率越高,发现隐藏Bug的概率就越高。通过覆盖率分析,发现测试用例没有覆盖到的地方,就应该新增测试用例。
  测试覆盖技术需要Android平台构造一个特殊的监控器来收集监测数据,但是不能发布,因为它会影响性能,从而严重影响应用的表现。
  为了弥补这个空白,请访问EMMA(http://emma.sourceforge.net)。它是一个开源工具,用于测量和报告Java代码测试覆盖率,可以衡量类的覆盖率。它的报告有几个维度:
  "  类覆盖率;
  "  方法覆盖率;
  "  行覆盖率;
  "  基础块覆盖率。
  覆盖率报告同样可以设置成不同的格式。从某种程度上说,EMMA是基于Andoid框架的,所以,可以建一个带EMMA模拟器版本的Android系统。
  我们将在第10章分析EMMA在Android系统上的用法,带大家完成一次完整的覆盖率测试,采用非传统的测试策略。
  图1.1展示了在装了兼容的plugin后,经过Emma覆盖率分析后,用Eclipse编辑器打开分析的文件,绿色的代码行表示该行已经覆盖到了。

   http://www.51testing.com/attachments/2016/03/14982672_201603091526431aUAg.jpg


  图1.1  Emma覆盖率分析结果


  不幸的是,这个插件不支持Android测试,因此,你只能用它来做Junit单元测试,而且你只能通过HTML来看Android覆盖率分析报告。
  测试应该有自动化,每当你更改或者新增代码时,你就可以跑一部分或者全量测试用例来确保之前的逻辑是对的,以及新代码逻辑也是符合测试预期的。这就是我们说的持续集成,第8章我们将介绍。它依赖于自动化测试和自动化构建过程。
  如果你没用到自动化测试,那实际上不可能把持续集成作为开发过程的一部分,而且很难保证代码变更情况下,不破坏现有代码逻辑。
  1.3.1  测试的内容是什么呢
  一个Android应用,测试点是什么呢?严格地说,代码的每一行都应该经过测试。不过,根据不同的测试标准,你可以采用只需要覆盖到重要的路径分支或者一部分重要内容的方法。通常,有一些不可能被打破而产生Bug的地方就没有必要测试。比如:getter方法和setter方法测起来就没啥意思。这就好比编译器早就有自己的测试工程,而你也不可能在自己的代码中来测试编译器一样。
  除了程序功能属于测试要点之外,Android应用还有一些特殊的地方需要考虑。我们将在下面几节进行描述。
  1.3.2  Activity生命周期中的事件
  Activity对生命周期中的事件是否能够正确响应是一个测试点。
  比如,你的Activity在OnPause()事件和OnDestroy()事件中需要保存自身的状态,然后在OnCreate(Bandle savedInstanceState)时恢复状态。那么,你应该重复执行并验证在这些条件下状态是否能够正确保存、是否能恢复正常。
  在测Activity时,还需要验证配置项变化事件的响应。因为配置变化后,当前的Activity需要重新生成。此时,你要验证新生成的Activity对事件的响应是否正常以及先前的状态是否恢复正常。定时循环事件也会触发配置的变化。因此,你还要看看应用是否能够正确处理这些事件。
  1.3.3  数据库和文件系统的操作
  数据库操作和文件的正确读写也是一个测试点。对这些操作的测试应该在底层系统测试中完成,在ContentProviders中进行高层次的测试,需要跟应用本身隔离开。
  要对这些部件进行独立的测试,Android提供了mock对象的工具,在andriod.test.mock包中。
  1.3.4  设备的物理特征
  在你发布应用程序之前,要确保它能在不同的设备上正常运行。至少你能把握大概的情况并想好对策。
  在设备的物理特性中,有以下几个测试点:
  "  网络容量;
  "  屏幕分辨率;
  "  屏幕厚度;
  "  屏幕尺寸;
  "  传感器;
  "  键盘和其他输入设备;
  "  GPS;
  "  扩容。
  由于有上述几个方面需要测试,虚拟器尤为重要。因为虚拟器可以让你通过简单配置达到上述条件的硬件特性。但是,如之前提到的,到最后的测试阶段,还是要用真机来操作,模拟真实用户的使用过程来测试。

   1.4  测试的种类
  在开发过程中,任何时间段都可以参与测试,这取决于采用何种测试方案。但是,我们推荐测试工作在项目开发早期就介入,甚至可以在完整需求出来之后、刚开始开发的时候就开始做准备。
  基于被测对象的不同,有好几种不同的测试方法。但是无论采用哪种测试方法,测试用例都包含执行条件和执行结果,执行结果返回True或者False来表示用例是否正确。
  1.4.1  单元测试
  单元测试,指的是程序员在开发阶段写的测试用例。这种测试用例需要将被测对象独立隔离起来,也就是mock掉外部关联对象。单元测试用例应用是可以重复执行的。这也是为什么我们常把单元测试和mock对象关联在一起。因为你要通过mock对象来模拟外部交互从而达到隔离被测对象的目的。当然,这样的用例可以重复执行任何次数。例如,假设你要从数据库中删除某些数据,但是下一次执行这个用例时这些数据还需要用,因此不想这些数据真正被删除,这时候mock数据库的返回,假装数据已经删除成功了。
  Junit是约定俗成的标准单元测试框架。它是一个简单、开源的自动化单元测试框架,由ErichGamma和KentBeck两位作者创建。
  Android要用Junit 3。这个版本没有注释,而是通过内部自查来感知测试用例的。一个典型的Junit测试用例写法如框1.1中所示的代码,其中测试方法用高亮度显示:
  框1.1  Junit测试代码样例

/**
* Android Application Testing Guide
*/
package com.example.aatg.test;
import JUnit.framework.TestCase;
/**
* @author diego
*/
public class MyUnitTests extends TestCase {
private int mFixture;
/**
* @param name test name
*/
public MyUnitTests(String name) {
super(name);
}
/* (non-Javadoc)
* @see JUnit.framework.TestCase#setUp()
*/
protected void setUp() throws Exception {
super.setUp();
mFixture = 1234;
}
/* (non-Javadoc)
* @see JUnit.framework.TestCase#tearDown()
*/
protected void tearDown() throws Exception {
super.tearDown();
}
/**
* Preconditions
*/
public void testPreconditions() {
}
/**
* Test method
*/
public void testSomething() {
fail("Not implemented yet");
}
}


  如果你购买了Packt书,可以访问http://www.PacktPub.com,在个人账户中下载样本源代码。如果你是从其他地方购买的书,可以访问http://www.PacktPub.com/support来注册用户,然后我们将源码文件直接发E-mail给您。
  我们将在下一节详细阐述测试用例的每个细节。
  1.测试套件
  测试套件是个为人熟知的名词,它表示执行用例的标准流程模式。每个测试用例都用同一套标准流程。因此,它也是测试用例设计的基础。
  通常情况下,按照Android的约定,它由一系列成员变量构成。通常以m开头,如: mActivity。但是,它也有一些扩展数据,作为数据库和文件系统操作的特殊入口。
  2.setUp方法
  这个方法是用来初始化测试套件用的。
  通过重载这个方法,你可以新建对象,初始化元素。在每个测试用例执行之前,这个SetUp方法都会执行一次。
  3.tearDown方法
  tearDown方法是在测试套件中最后执行的函数。
  在测试用例执行过程中,会初始化一些对象,这些对象可以在tearDown函数中进行销毁。因为tearDown函数是每个测试用例最后必须执行的,是销毁对象的最佳阶段。
  比如:你可以在tearDown中释放掉数据库连接以及网络连接。
  Junit设计的流程是这样的:首先,将整个库的用例都编译完。然后,在第二阶段再执行测试用例。因此,在测试执行过程中,执行器对所有用例都有强依赖。也就是说,对于那些用例很多、耗时很长的用例来说,在所有用例完成之前,是不会对变量、对象进行回收的。这点在Android测试中特别重要,因为在某些设备上测试失败的原因不是因为固有的逻辑问题,而是因为用例执行太多导致资源不足了。
  因此,在Android应用中,你若测试使用了额外的、有限的资源,比如Services服务或者contentProvides,那么,你应该注意要及时释放掉。在tearDown方法中,严格遵守将对象设置成null的规则,以便及时回收,避免一直占用资源,一直到所有用例跑完才释放。
   4.测试前期条件
  通常,前置条件没法按照正常流程来测,因为常规的测试用例次序是随机的。因此,通常会写一个testPrecondition用例来专门测前置条件。虽然没法保证测试用例以一个特别指定的顺序进行,但是将所有测前置条件的用例放在指定的地方是一个好的习惯,可以提高用例的可读性。
  5.实际测试
  所有公有类型、返回值为void并且以test开头的函数都会被当作测试用例。Junit 3不采用标注来标识测试用例,而采用函数名,这点与Junit 4相反。在Android测试框架中,标注有@SmallTest、@MediumTest、@LargeTest,但是这些注释不会将一个函数标识为测试函数,他们是将测试用例分组的注释。通过分组,你可以选择性地执行某个组下面的所有用例。
  实际测试的第一条规则,用描述性名字来命名测试用例,或者以测试条件命名。
  比如testValues()、testConversionError()、testConversionToString(),这种命名方式是靠谱的。
  测试时,要注意不仅仅是走正常的用例,异常和错误的测试用例也要覆盖到。在特定条件下执行用例后,要注意检查周边影响以及函数返回值,是否跟预期一致。Junit提供了一系列的断言assert*函数,它们将预期和真实结果作对比,不一致的时候抛出异常。这样,测试执行器将会处理这些异常,并在最终的结果中展现出来。
  断言方法有很多,可以接受不同类型的参数,包括:
  "  assertEquals();
  "  assertFalse();
  "  asssertNotNull();
  "  assertNotSame();
  "  assertNull();
  "  assertSame();
  "  assertTrue();
  "  fail()。
  除了Junit提供的以上断言方法,Andriod扩展了两个特别的断言类:
  "  MoreAsserts;
  "  ViewAsserts。
  6.Mock对象
  Mock对象是指不调用真实的对象,而是调用模拟对象,获得指定结果,以达到将测试单元隔离的目的。
  通常,使用这种方法是为了保证被测对象能够正常调用,并且,就像上面提到的,将被测对象跟周边环境隔离开。这样一来,测试用例就可以不受外部影响了,可以独立执行,并且可以重复执行。
  Android测试框架支持Mock多个对象,这点对编写测试用例十分有用。当然,这些编译测试用例需要依赖一些东西。
  Andriod测试框架提供的几个Mock类如下:
  "  MockApplication;
  "  MockContentProvider;
  "  MockContentResolver;
  "  MockContext;
  "  MockCursor;
  "  MockDialogInterface;
  "  MockPackageManager;
  "  MockResources。
  几乎平台上所有与你交互的部件都可以由以上几个类来生成。但是,它们并非真正执行,而是在每个方法产生UnsupportedOperationException的地方打桩,这样一来,你就可以创建你真正的Mock的对象,实现Mock的内容了。
  7.UI测试
  最后,你在测UI部件的时候,需要考虑一些特殊因素。众所周知,在Android应用中只有主线程才允许更改界面交互。只有带有@UIThreadTest标记的函数才会在主线程执行,因此用来测界面的用例需要打这个标记。另一方面,如果你想在UI线程中执行一部分测试用例,可以使用Activity.runOnUiThread方法,这个方法提供了可执行的测试操作。
  TouchUtils是一个帮助类,提供了UI测试的常用帮助,指引你调用一般的事件方法,将事件传递到界面上,比如:
  "  Click点击;
  "  drag拖曳;
  "  long click长点击;
  "  scroll滚动;
  "  tap拍;
  "  ouch触摸。
  通过上述方法,你可以在测试用例中真实地远程控制您的应用程序。
  8.Eclipse和其他IDE支持
  Eclipse完全支持Junit,而AndroidADT插件方便你测试Android工程。更有甚者,你无需使用IDE也可以执行测试用例和分析测试结果。
  Eclipse也有个优势:在Eclipse里执行测试用例,执行不正确的时候,可以通过debug的方式,同时调试用例和代码。
  在图1.2所示中,我们可以看到Eclipse执行了18个测试用例,花了20.008秒的时间,没发现问题,0失败。测试用例的名称以及执行过程都有展示。如果有一个失败了,错误跟踪会显示相关的信息。

http://www.51testing.com/attachments/2016/03/14982672_201603091531031asvt.jpg


  其他IDE,像ItelliJ和Netbeans虽然集成Android开发的插件,但是并没有官方支持。
  如果你现在没有在IDE中开发,你可以用ant来执行测试用例(如果你不熟悉这个ant工具请访问http://ant.apache.org)。通过Android命令行,用create test-project命令来启动,这个命令的帮助文字如框1.2所示。
  框1.2  命令帮助信息

$ android --help create test-project
Usage:
android [global options] create test-project [action options]
Global options:
-v --verbose Verbose mode: errors, warnings and informational messages
are printed.
-h --help Help on a specific command.
-s --silent Silent mode: only errors are printed out.
Action "create test-project":
Creates a new Android project for a test package.
Options:
-p --path The new project's directory [required]
-m --main Path to directory of the app under test, relative to the
test project directory [required]
-n --name Project name


  1.4.2  集成测试
  集成测试目的是用来测试模块与模块之间的交互情况。一般情况下,模块先会经过独立的单元测试,然后再组装在一起集成测试。
  通常,Android应用上的活动需要跟操作系统进行交互。它们通过ActivityManager来控制活动的生命周期,访问资源、文件系统和数据库。
  其他组件,譬如Services(服务组件)和ContentProviders(共享数据)也是同样的原理。它们也需要跟系统的其他部分进行交互来完成相应的功能。
  在所有的测试用例中,Android测试框架提供了特殊的测试用例,以便测试上述组件。
  1.4.3  功能或者验收测试
  在敏捷开发项目中,功能测试或者说验收测试一般是由业务方和测试人员来编写。这些用例通常是以业务场景的表达方式来给大家展现的。这里会有高层次的测试用例,用来测试一个用户需求或者特性的正确性和完整性。虽然这些测试用例是由客户、业务分析员、测试人员和开发人员协商制定的理想结果,但客户(产品的拥有者)是这些测试用例的首要负责人。
  在这方面,有一些框架和工具可以帮助你,最著名的FitNesse,如图1.3所示,一句话,他们让你在Android开发阶段,轻松集成测试。另外还可以创建测试用例并且验证结果。

 http://www.51testing.com/attachments/2016/03/14982672_201603091531032x7le.jpg 


图1.3  fitness集成测试结果图


  最近,"行为驱动开发"BDD的新型模式风靡起来,简单说来,可以理解成"测试驱动开发"TDD的革新。"行为驱动开发"的目的在于在业务和技术人员之间建立起统一的术语以便增加相互之间的沟通理解。
  "行为驱动开发"可以理解为基于活动的框架,有以下三个原则
  "  业务与技术要以相同的方式来描述系统。
  "  任何系统都要有确认的、可以衡量的业务价值。
  "  从最开始的分析、设计以及计划,都需要有明确的产出。
  有了以上几个原则,业务人员通常都会参与测试用例的场景设计,并站在业务的角度,利用一些工具实现,比如jbehave(http://jbehave.org)。在下面的例子中,测试用例用类似于编程语言的方式表达出场景。
  试用例场景描述
  我们举个非常简单的例子来描述将场景转换成代码的方法:
  场景如框1.3中所述。
  框1.3  场景描述
  假设我有一个温度转换器,
  当我输入100摄氏度时,
  我得到的结果是212华氏温度。
  这个场景翻译成代码如框1.4中所示。
  框1.4  对应框1.3翻译出来的伪代码

@Given("我有一个温度转换器")
public void createTemperatureConverter(){
// do nothing
}
@When("我将摄氏温度输入对应的文本框")
public void setCelsius(int celsius){
mCelsius=Celsius;
}
@Then("我将在华氏温度的字段看到相应的华氏温度")
public void testCelsiusToFahrenheir(int fahrenheit){
assertEquals(Fahrenheit,
TemperatureConverter.celsiusToFahrenheit
(mCelsius));
}

    1.4.4  性能测试
  性能测试,是用重复的方式来探测部件中某些特点的性能。如果说,应用的某些地方对性能提升有要求,那么最好的衡量优化效果的办法,就是拿优化之前和优化之后给出的性能报告做对比。
  众所周知,一次考虑不周到的优化带来的后果总是弊大于利的,因此,为了避免优化后不仅没达到效果,反而把之前的功能影响到了,最好对应用的整体性能有个清晰的了解,明确升级之后对应用的影响。
  Android 2.2里面的Dalvik JIT编译器改变了一些Android开发中常使用的优化方案。迄今,在Android开发中,每一个性能优化升级都推荐有性能测试保证。
  1.4.5  系统测试
  系统测试是将部件组合起来作为一个整体来测试,检查部件之间的交互情况,软件和硬件都会涉及。通常,系统测试包括以下额外的测试类,比如:
  "  界面GUI测试;
  "  冒烟测试;
  "  性能测试;
  "  安装测试。

dffb799f62245e9be081a4c25b84bc82.png (51.45 KB, 下载次数: 10)



  1.5  Android测试框架
  Android提供了一个高级的测试框架,这个框架是Junit的一个扩展,在标准Junit的基础上插入了方便执行上述测试的插件。有的情况下,我们需要再装一些工具,而且集成这些工具大多情况下都很简单和直接。
  Android测试环境的关键特性包括以下这些:
  "  Android在Junit框架基础上扩展了访问系统对象的方法。
  "  通过模拟器框架可以测试应用和控制器。
  "  提供了常用的、不同版本的系统对象的模拟器。
  "  提供了执行单个用例、用例集的工具,无须模拟器。
  "  提供测试用例、工程的管理工具,在ADT的Eclipse插件中,用命令行来控制。
  1.5.1  模拟器
  模拟器框架是测试框架的基础。模拟器控制被测的应用,并且允许插入桩来模拟应用的某些部件的执行。比如,你可以在应用启动之前创建模拟的Context,应用程序将会用模拟的Context来执行。
  所有的应用程序跟周边环境的交互都可以通过上述方式来控制。你可以将应用程序封闭到一个十分严谨单一的条件下来得到预期的结果,强行设置某些方法的输出或者模拟ContentProvider中的常量、数据库、甚至文件系统的内容。
  一个标准的Android工程都会有相应的测试工程,这个测试通常以Test开头。在Test工程中,AndriodManifest.xml中定义了使用的机器。
  举个例子描述,假设你的工程配置文件如框1.5所示。
  框1.5  主工程的AndriodManifest.xml配置文件

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.aatg.sample"
android:versionCode="1"
android:versionName="1.0">
<application android:icon="@drawable/icon"
android:label="@string/app_name">
<activity android:name=".SampleActivity"
android:label="@string/app_name">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name=
"android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
<uses-sdk android:minSdkVersion="7" />
</manifest>


  在这个项目里,相关的测试工程配置文件AndriodManifest.xml如框1.6所示。
  框1.6  测试工程的AndriodManifest.xml配置文件

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.aatg.sample.test"
android:versionCode="1" android:versionName="1.0">
<application android:icon="@drawable/icon"
android:label="@string/app_name">
<uses-library android:name="android.test.runner" />
</application>
<uses-sdk android:minSdkVersion="7" />
<instrumentation
android:targetPackage="com.example.aatg.sample"
android:name="android.test.InstrumentationTestRunner"
android:label="Sample Tests" />
<uses-permission android:name="
android.permission.INJECT_EVENTS" />
</manifest>


  这里的模拟器包作为主项目包,带着.test后缀。
  定义模拟器的时候,会指定目标包和测试执行器,在这个情况下,默认的客户端执行器是android.test.InstrumentationTestRunner。
  另外,被测应用和测试工程一样,都是apk安装的Android程序。它们都在同一个进程中,因此,能访问相同的功能特性。
  当你执行一个测试应用程序的时候,行为管理器(http://developer.andriod.com/intl/de/
  reference/andriod/app/ActivityManager.html)利用模拟器框架来启动和控制测试执行器,然后测试执行器反过来利用模拟器工具来关闭主程序运行的实例,启动测试进程,最后在同一个进程中启动主程序。这种方式使得各种各样的测试应用可以直接在主应用中工作。
  1.5.2  测试对象
  在项目开发过程中,你的测试用例必须在不同的设备上执行。从操作简单、方便,到响应速度等方面考虑,都要求最后必须在具体设备上测试,并且是在所有类型的设备上测试。
  当然,有的测试用例会在本地JVM虚拟机上执行,有的用例在开发机上执行,有的在Dalvik或者活动虚拟机上执行,具体情况取决于测试用例的特点。
  上述执行用例的方式都有各自的优缺点,幸运的是,你可以自由决定如何来执行你的用例。
  仿真器是一个非常棒的执行平台,可能是最强大的,因为它可以让你修改测试过程中所有的参数、配置以及各种执行环境。测试最根本的目的是让你的程序能够正确处理所有场景,因此,最好在程序发布之前发现所有的问题。
  性能测试需要使用真机,因为模拟仿真设备多少跟真机会有不同的地方。只有用真机才能体会到用户的真实感受。渲染、滚屏、投掷以及其他场景都需要发布之前用真机测试一次。
  1.6  小结
  我们复习了软件测试中的主要概念以及Android测试中的特殊点。这些知识为我们开启探索软件测试的优点提供了必备条件。
  本章节主要讲述了以下内容:
  "  我们回顾了早期Android测试以及当前可选的测试框架。
  "  我们简短分析了测试背后的四个W:为什么测试(Why),测什么(What),如何测(How),何时测(When)。在如何测试上,我们后面会进行更加深入分析,假设你有固定参数输入,那么你将如何进行探索性测试呢?
  "  我们列举了项目中你需要的不同的、最通用的测试方法,描述了测试工具箱中的一些工具,并且用一个例子详细介绍了Junit单元测试如何做,方便大家理解。
  我们还从Android测试的角度分析了这些技术,提到了用模拟器来执行测试用例的方法。下面几章,我们将开始用实例来分析上面提到的技术、框架、工具使用的细节。





Rank: 9Rank: 9Rank: 9Rank: 9Rank: 9Rank: 9Rank: 9Rank: 9Rank: 9

请楼主继续发好贴

Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8

支持你

Rank: 1

看过必回

Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8

人品超好!

Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8

回不回呢?

Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8

;P

Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6

好帖要顶

Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8

顶先

Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8

确实值得好好看看

Copyright (C) 1997-2013 Chinabyte.com, All Rights Reserved

GMT,

Powered by Discuz!

© 2001-2010 Comsenz Inc.