La estructura general de la configuración del módulo sigue un patrón similar a la configuración XML de Tradefed normal, pero con algunas restricciones debido al hecho de que se ejecutan como parte de una suite.
Lista de etiquetas permitidas
AndroidTest.xml o, en términos más generales, la configuración del módulo puede contener solo las siguientes etiquetas XML: target_preparer , multi_target_preparer , test y metrics_collector .
Aunque esa lista parece restrictiva, le permite definir con precisión las necesidades de configuración del módulo de prueba y la prueba a ejecutar.
NOTA: Consulte Configuración XML de Tradefed si necesita un repaso de las diferentes etiquetas.
Objetos como build_provider o result_reporter generarán una ConfigurationException si se intenta ejecutar desde dentro de la configuración de un módulo. Esto tiene como objetivo evitar la expectativa de que estos objetos realmente realicen alguna tarea desde dentro de un módulo.
Ejemplo de configuración del módulo
<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>
Esta configuración describe una prueba que requiere la instalación CtsGestureTestCases.apk y ejecutará una instrumentación en el paquete android.gesture.cts .
Etiquetas de inclusión <include> y <template-include>
Se desaconseja el uso de <include> y <template-include> en las configuraciones del módulo. No se garantiza que funcionen como se esperaba.
Caso especial para la etiqueta metrics_collector
El metrics_collector está permitido pero limitado a la clase FilePullerLogCollector para especificar un archivo o directorio determinado que se extraerá y registrará para el módulo. Esto es útil si deja registros en una ubicación particular y desea recuperarlos automáticamente.
Configuración de ejemplo:
<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>
¿Qué pasa con la información de compilación o las descargas?
La definición de las etiquetas permitidas puede dar la impresión incorrecta de que un módulo no obtendrá ninguna información de compilación. Esto no es verdad .
La información de compilación se proporciona desde la configuración a nivel de suite y será compartida por todos los módulos de la suite. Esto permite una única configuración de nivel superior para la suite con el fin de ejecutar todos los módulos que forman parte de la suite.
Por ejemplo, en lugar de que cada módulo del Conjunto de pruebas de compatibilidad (CTS) consulte individualmente la información del dispositivo, los tipos, etc., la configuración a nivel del conjunto de CTS ( cts.xml ) lo hace una vez y cada módulo recibirá esa información si la solicita.
Para que los objetos en un módulo reciban la información de compilación, deben hacer lo mismo que en la configuración normal de Tradefed: implementar la interfaz IBuildReceiver para recibir IBuildInfo . Consulte Prueba con el dispositivo para obtener más detalles.
Campos de metadatos
Una gran cantidad de módulos de prueba incluyen algunas especificaciones metadata , cada una de las cuales tiene un objetivo único.
Ejemplo:
<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" />
Componente
Los metadatos del component describen el componente general de Android que el módulo pretende probar. No tiene ningún impacto directo en la ejecución de la prueba; se utiliza principalmente con fines organizativos.
La lista actualizada de componentes permitidos para CTS está disponible en CtsConfigLoadingTest . Esta prueba falla en el envío previo si se agrega un componente no existente a un módulo CTS.
Puede filtrar la ejecución de un conjunto en función de los componentes utilizando module-metadata-include-filter y module-metadata-exclude-filter .
Ejemplo:
--module-metadata-include-filter component framework
Este ejemplo solo ejecuta el módulo de prueba anotado con el componente framework .
Parámetro
Los metadatos parameter son informativos y afectan la ejecución de la prueba. Especifica a qué modo de Android se aplica el módulo de prueba. En este caso, los modos se limitan a modos de Android de alto nivel, como instant apps , secondary users o different abis .
Durante la ejecución de la suite, si el modo se aplica a la prueba, se crean varias variaciones del módulo de prueba en función del modo. Cada variación ejecuta pruebas similares pero en modos diferentes.
-
instant_app: crea una variación de las pruebas que instalan APK como aplicaciones instantáneas. -
multi_abi: crea una variación de las pruebas para cada ABI admitida por el dispositivo. -
secondary_user: crea una variación de las pruebas que instalan APK y ejecuta pruebas como usuario secundario.
Recopilación de métricas y posprocesamiento para módulos de pruebas de rendimiento
Para los módulos de prueba de rendimiento, se permiten metrics_collector y metric_post_processor a nivel de módulo, ya que son esenciales para las pruebas de rendimiento. Los recolectores de métricas y postprocesadores a nivel de módulo pueden ser específicos del módulo. No se recomienda especificar postprocesadores tanto en el nivel superior como en el nivel de módulo.
La configuración de un módulo de prueba de rendimiento debe incluir metadatos test-type con valor performance , como: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> Sin esto, si se realiza una prueba config incluye metric_collector que no sea FilePullerLogCollector o cualquier metric_post_processor , la prueba falla en el envío previo.
Ejemplo de configuración del módulo de prueba de rendimiento:
<configuration description="Runs sample performance test.">
<!-- Declare as a performance test module -->
<option name="config-descriptor:metadata" key="test-type" value="performance" />
<option name="test-tag" value="hello-world-performance-test" />
<test class="com.android.tradefed.testtype.HostTest" >
<option name="class" value="android.test.example.helloworldperformance.HelloWorldPerformanceTest" />
</test>
<!-- Add module-level post processor MetricFilePostProcessor -->
<metric_post_processor class="com.android.tradefed.postprocessor.MetricFilePostProcessor">
<option name="aggregate-similar-tests" value="true" />
<option name="enable-per-test-log" value="false" />
</metric_post_processor>
</configuration>