...接第一部分Android应用开发之(如何进行软件测试一)
在测试环境中工作
对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上。