モジュール構成の全体的な構造は、通常の Tradefed XML 構成と同様のパターンに従いますが、スイートの一部として実行されるため、いくつかの制限があります。
許可されるタグのリスト
AndroidTest.xmlまたはより広範なモジュール構成には、次の XML タグのみを含めることができます: target_preparer 、 multi_target_preparer 、 testおよびmetrics_collector 。
このリストは制限的であるように見えますが、テスト モジュールのセットアップのニーズと実行するテストを正確に定義できます。
注: さまざまなタグについて復習が必要な場合は、 「Tradefed XML 構成」を参照してください。
build_providerやresult_reporterなどのオブジェクトをモジュール構成内から実行しようとすると、 ConfigurationExceptionが発生します。これは、これらのオブジェクトがモジュール内から実際に何らかのタスクを実行するという期待を避けることを目的としています。
モジュール構成例
<configuration description="Config for CTS Gesture test cases">
<option name="test-suite-tag" value="cts" />
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsGestureTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.gesture.cts" />
<option name="runtime-hint" value="10m50s" />
</test>
</configuration>
この構成では、 CtsGestureTestCases.apkインストールを必要とするテストについて説明し、 android.gesture.ctsパッケージに対してインストルメンテーションを実行します。
metrics_collector タグの特殊なケース
metrics_collector許可されていますが、モジュールのプルおよびログに記録される特定のファイルまたはディレクトリを指定するために、 FilePullerLogCollectorクラスに限定されます。これは、特定の場所にログを残しており、それらを自動的に回復したい場合に便利です。
構成例:
<configuration description="Config for CTS UI Rendering test cases">
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.uirendering.cts" />
<option name="runtime-hint" value="11m55s" />
<option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
<option name="isolated-storage" value="false" />
</test>
<!-- Collect the files in the dump directory for debugging -->
<metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
<option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
<option name="collect-on-run-ended-only" value="true" />
</metrics_collector>
</configuration>
ビルド情報やダウンロードについてはどうですか?
許可されるタグの定義により、モジュールがビルド情報を取得しないという誤った印象を与える可能性があります。これは真実ではありません。
ビルド情報はスイート レベルのセットアップから提供され、スイートのすべてのモジュールによって共有されます。これにより、スイートのすべてのモジュール部分を実行するために、スイートの単一のトップレベル設定が可能になります。
たとえば、各互換性テスト スイート (CTS)モジュールがデバイス情報、タイプなどを個別に照会する代わりに、CTS スイート レベルのセットアップ ( cts.xml ) がそれを 1 回実行し、各モジュールは要求に応じてその情報を受け取ります。
モジュール内のオブジェクトがビルド情報を受信するには、通常の Tradefed 構成と同じことを行う必要があります。つまり、 IBuildInfoを受信するためのIBuildReceiverインターフェイスを実装します。詳細については、「デバイスを使用したテスト」を参照してください。
メタデータフィールド
多数のテスト モジュールにはいくつかのmetadata仕様が含まれており、それぞれに固有の目標があります。
例：
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
<option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
<option name="config-descriptor:metadata" key="parameter" value="secondary_user" />
成分
componentメタデータは、モジュールがテストする一般的な Android コンポーネントを記述します。テストの実行には直接影響しません。主に組織的な目的で使用されます。
CTS で許可されているコンポーネントの最新のリストは、 CtsConfigLoadingTestで入手できます。存在しないコンポーネントが CTS モジュールに追加された場合、このテストは事前送信で失敗します。
module-metadata-include-filterおよびmodule-metadata-exclude-filterを使用して、コンポーネントに基づいてスイートの実行をフィルタリングできます。
例：
--module-metadata-include-filter component framework
この例では、 frameworkコンポーネントの注釈が付けられたテスト モジュールのみを実行します。
パラメータ
parameterメタデータは情報提供であり、テストの実行に影響を与えます。テスト モジュールが適用される Android モードを指定します。この場合、モードは、 instant apps 、 secondary users 、またはdifferent abisなどの高レベルの Android モードに限定されます。
スイートの実行中に、モードがテストに適用される場合、モードに基づいてテスト モジュールのいくつかのバリエーションが作成されます。各バリエーションは、異なるモードで同様のテストを実行します。
-
instant_app: APK をインスタント アプリとしてインストールするテストのバリエーションを作成します。 -
multi_abi: デバイスでサポートされている各 ABI のテストのバリエーションを作成します。 -
secondary_user: APK をインストールし、セカンダリ ユーザーとしてテストを実行するテストのバリエーションを作成します。