Android测试之设备化测试Instrumented Tests，芯片老化测试设备

当我们需要使用到安卓框架的时候，也就是android.jar里面的api的时候，使用本地单元测试的方式就难以做到了。这时就要使用设备化的测试。

设备化测试分为

——设备化单元测试（Instrumented Unit Test）

——组件集成测试

——app集成测试。

以下是官网对这几种测试的特点简述和详细说明：

Building Instrumented Unit Tests: Build complex unit tests with Android dependencies that cannot be satisfied with mock objects.Automating User Interface Tests: Create tests to verify that the user interface behaves correctly for user interactions within a single app or 活动：慈云数据爆款香港服务器，CTG+CN2高速带宽、快速稳定、平均延迟10+ms 速度快，免备案，每月仅需19元！！ 点击查看for interactions across multiple apps.Testing App Component Integrations: Verify the behavior of components that users do not directly interact with, such as a?Service?or aContent Provider.

详细说明：

Type Subtype Description Unit tests Local Unit Tests Unit tests that run locally on the Java Virtual Machine (JVM). Use these tests to minimize execution time when your tests have no Android framework dependencies or when you can mock the Android framework dependencies. Instrumented unit tests Unit tests that run on an Android device or emulator. These tests have access to?Instrumentationinformation, such as the?Context?of the app you are testing. Use these tests when your tests have Android dependencies that mock objects cannot satisfy. Integration Tests Components within your app only This type of test verifies that the target app behaves as expected when a user performs a specific action or enters a specific input in its activities. For example, it allows you to check that the target app returns the correct UI output in response to user interactions in the app’s activities. UI testing frameworks like?Espressoallow you to programmatically simulate user actions and test complex intra-app user interactions. Cross-app Components This type of test verifies the correct behavior of interactions between different user apps or between user apps and system apps. For example, you might want to test that your app behaves correctly when the user performs an action in the Android Settings menu. UI testing frameworks that support cross-app interactions, such as?UI Automator, allow you to create tests for such scenarios.

设备化测试的类需要放在module-name/src/androidTests/java/这个目录下，类名和包名没有要求，但如果是suite类型的测试类，包名通常用.suite结尾。

对于支持到JUnit4的gradle版本，我们只需要按照junit4的写法来就可以了，关于这方面，可以参考另一篇博文。

下面讲一讲各种类型的设备化测试的基本实现流程：

设备化单元测试

首先

，你需要引入以下依赖：

dependencies {? ? androidTestCompile \’com.android.support:support-annotations:24.0.0\’? ? androidTestCompile \’com.android.support.test:runner:0.5\’? ? androidTestCompile \’com.android.support.test:rules:0.5\’? ? // Optional — Hamcrest library? ? androidTestCompile \’org.hamcrest:hamcrest-library:1.3\’? ? // Optional — UI testing with Espresso? ? androidTestCompile \’com.android.support.test.espresso:espresso-core:2.2.2\’? ? // Optional — UI testing with UI Automator? ? androidTestCompile \’com.android.support.test.uiautomator:uiautomator-v18:2.1.2\’} 如果你其它地方有引用到support-annotations这个包的话，那么它的版本有可能会跟着几个包所引用到的annotations包版本冲突，这时候可以把上面第一个引入删掉，并且对其它几个包都这样配置一下（就是去掉它们里面的这个包的依赖的意思）：

androidTestCompile (\’com.android.support.test.espresso:espresso-core:2.2.2\’, {

? ? ? ? exclude group: \’com.android.support\’, module: \’support-annotations\’

? ? })

然后

，你还需要在你当前需要测试的module的build.gradle文件里加入这个配置：

android {? ? defaultConfig {? ? ? ? testInstrumentationRunner \”android.support.test.runner.AndroidJUnitRunner\”? ? }}

最后

是代码部分，除了按照junit4的写法添加方法和注解外，只需要在类上添加一个@RunWith(AndroidJUnit4.class) 这样的注解。这样就可以在test方法里面调用安卓api的方法了。

组件集成测试

这个包括Service和ContentProvider的测试，支持进程间的通信。但不支持IntentService和广播。

其实Activity的集成测试也属于这部分，官方介绍时大概为了方便，直接只在app集成测试环节使用了activity的测试。其实也可以放到这里来，单个引用activity来做测试。

app集成测试部分只是综合使用了这几种引用模式。

其实这部分的话，除了上面单元测试的那几步都要以外，只要再加一个这样的申明就差不多了：

@Rule

? ??public ActivityTestRule mActivityRule = new ActivityTestRule(OneFlagActivity.class);//具体可看下面app集成测试的使用。

Service的集成测试跟单个应用内的测试比较相像。只不过把声明activity变成了声明service，不过没在声明的时候指定具体的service，而是在test方法里面再做绑定操作。

@Rulepublic final ServiceTestRule mServiceRule = new ServiceTestRule(); @Testpublic void testWithBoundService() throws TimeoutException {? ? // Create the service Intent.? ? Intent serviceIntent =? ? ? ? ? ? new Intent(InstrumentationRegistry.getTargetContext(),? ? ? ? ? ? ? ? LocalService.class);? ? // Data can be passed to the service via the Intent.? ? serviceIntent.putExtra(LocalService.SEED_KEY, 42L);? ? // Bind the service and grab a reference to the binder.? ? IBinder binder = mServiceRule.bindService(serviceIntent);? ? // Get the reference to the service, or you can call? ? // public methods on the binder directly.? ? LocalService service =? ? ? ? ? ? ((LocalService.LocalBinder) binder).getService();? ? // Verify that the service is working correctly.? ? assertThat(service.getRandomInt(), is(any(Integer.class)));}

这里的mServiceRule就相当于绑定service的那个activity。

App集成测试

这部分的测试是综合使用了上面的那些测试模式，尤其是activity的，让你引用activity的输入，模拟用户的ui操作。可以是应用内的操作，也可以跨应用操作。

嗯。。

给一段代码感受一下：

@Rulepublic ActivityTestRule mActivityRule = new ActivityTestRule(OneFlagActivity.class);//该变量起了一个加载activity的作用， // 不加的话就要在测试方法里面手动启动或者添加intent启动@Testpublic void mockClick(){ ViewInteraction vi = onView(withId(R.id.tv_textborad));//1.找到ui组件 vi.perform(click());//2.操作 onView(withId(R.id.tv_textborad2)).check(matches(isDisplayed()));//3.判断结果}

正如我在注释里写的那样，就是那么个作用和操作过程哈。个中的使用和其它api的使用一两句话也说不完，只有自己去写去慢慢摸索了。

关于更详细的这几个api的说明也可以看这文档：https://developer.android.com/training/testing/ui-testing/espresso-testing.html

另外，在启动这个测试前，最好要把开发者选项里面的关于动画的几个选项关闭掉，否则有可能会导致不可预期的错误。一般有下面这几个选项：

1.窗口动画缩放 ?2. ?过渡动画缩放 ?3.动画程序时长缩放

至于跨应用的操作，限于篇幅，这里就不展开说了，其配置也是按照上面单元测试的这些就可以了，只是模拟操作的代码使用了不同的api。要用到的是UIDevice、UIObject等几个类。

至此，关于as集成的几种测试方式就介绍这么多了。画了个图稍微概括一下这几种方式。

11229637

《Android测试之设备化测试Instrumented Tests，芯片老化测试设备》来自互联网同行内容，若有侵权，请联系我们删除！