每个新的测试模块都必须具有配置文件,以使用模块元数据、编译时依赖项和打包指令来指引编译系统。现在,Android 使用 Soong 编译系统来实现更简单的测试配置。
Soong 使用与 JSON 类似的 Blueprint 文件(即 .bp
文件)来对要编译的模块进行简单的声明性描述。此格式取代了以前的版本中使用的基于 Make 的系统。如需了解完整详情,请参阅持续集成信息中心上的 Soong 参考文件。
要适应自定义测试或使用 Android 兼容性测试套件 (CTS),请改为按照复杂的测试配置操作。
示例
以下条目均来自这一示例 Blueprint 配置文件:/platform_testing/tests/example/instrumentation/Android.bp
为方便起见,下面附上快照:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["android-support-test"],
certificate: "platform",
test_suites: ["device-tests"],
}
请注意,开头的 android_test
声明表示这是一个测试。相反,如果开头为 android_app
,则表示这是一个编译软件包。
设置
下面对各项设置进行了解释:
name: "HelloWorldTests",
如果指定了 android_test
模块类型(在代码块的开头),则需要 name
设置。此设置会为模块命名,生成的 APK 将与模块名称相同,不过带有 .apk
后缀。例如,在本例中,生成的测试 apk 将命名为 HelloWorldTests.apk
。此外,此设置还可以为模块定义 make 目标名称,以便您可以使用 make [options]
<HelloWorldTests>
编译测试模块及其所有依赖项。
static_libs: ["android-support-test"],
static_libs
设置指示编译系统将已命名模块的内容合并到当前模块生成的 apk 中。这意味着,每个已命名模块都会生成 .jar
文件,其内容将用于在编译期间解析类路径引用,以及合并到生成的 apk 中。
在本例中,可能对测试普遍有用的内容如下:
android-support-test
是 Android 测试支持库的预编译项,包括新的测试运行器 AndroidJUnitRunner
:它替代了现已弃用的内置 InstrumentationTestRunner
,并且支持 JUnit4 测试框架。如需了解详情,请参阅在 Android 平台上测试应用。
如果要编译一个新的插桩模块,则开始时应始终将 android-support-test
库作为测试运行器。平台源代码树还包括其他有用的测试框架,如 ub-uiautomator
、mockito-target
、easymock
等等。
certificate: "platform",
certificate
设置指示编译系统使用与核心平台相同的证书对 apk 进行签名。如果您的测试使用受签名保护的权限或 API,则需要此设置。请注意,此设置适合平台连续测试,但不应该用于 CTS 测试模块。另请注意,本例使用此证书设置只是为了进行说明:示例中的测试代码实际上不需要使用特殊平台证书对测试 apk 进行签名。
如果您要为系统服务器之外的组件(也就是说,它的打包方式多少有些类似于常规应用 apk,只不过它内置到系统映像中并且可能是特权应用)编写插桩,那么插桩可能会以组件的应用软件包(请参阅下面关于清单的部分)为目标。在这种情况下,应用 makefile 可能具有自己的 certificate
设置,并且插桩模块应保留相同的设置。这是因为,要以受测应用上的插桩为目标,必须使用同一证书对测试 apk 和应用 apk 进行签名。
在其他情况下,根本不需要此设置:编译系统将直接使用默认的内置证书(基于编译变体)对其进行签名,并且它通常称为 dev-keys
。
test_suites: ["device-tests"],
test_suites
设置使 Trade Federation 自动化测试框架很容易发现测试。可在此处添加其他套件(如 CTS),以便共享此测试。
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk