La estructura general de la configuración del módulo sigue un patrón similar con la configuración XML normal de Tradefed, pero con algunas restricciones debido a el hecho de que se ejecuten como parte de un paquete.
Lista de etiquetas permitidas
La configuración de módulos de AndroidTest.xml o de forma más amplia puede contener solo el
las siguientes etiquetas XML: target_preparer, multi_target_preparer, test y
metrics_collector
Aunque esa lista parece restrictiva, te permite definir con precisión las necesidades de configuración del módulo de prueba y la prueba para ejecutarse.
NOTA: Consulta Configuración de XML de Tradefed. si necesitas repasar las diferentes etiquetas.
Los objetos como build_provider o result_reporter generarán un
ConfigurationException si se intenta ejecutar desde un módulo
configuración. Esto es para evitar la expectativa de que estos
que realizan alguna tarea desde un módulo.
Ejemplo de configuración de 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 que CtsGestureTestCases.apk haga lo siguiente:
se instalará y ejecutará una instrumentación con el android.gesture.cts
.
Etiquetas de inclusión <include> y <template-include>
El uso de <include> y <template-include> en la configuración de los módulos es
desalentado. No se garantiza que funcionen como se espera.
Caso especial de la etiqueta metrics_collector
Se permite el metrics_collector, pero se limita a lo siguiente:
FilePullerLogCollector
para especificar un archivo o directorio determinado para extraer y registrar
el módulo. Esto es útil si deja registros en una ubicación en particular
y quieres 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é sucede con las descargas o la información sobre compilaciones?
La definición de las etiquetas permitidas podría dar la impresión incorrecta de que un este módulo no obtendrá información de compilación. Esto no es cierto.
La información de compilación se proporciona a partir de la configuración a nivel de paquete y se compartidas por todos los módulos del paquete. Esto permite una sola configuración de nivel superior del paquete con el fin de ejecutar todos los módulos del paquete.
Por ejemplo, en lugar de cada
Conjunto de pruebas de compatibilidad (CTS)
consulta de forma individual la información del dispositivo, los tipos, etc., el CTS
configuración a nivel de paquete (cts.xml) lo hace una vez y cada módulo recibirá ese
información adicional si la solicita.
Para que los objetos de un módulo reciban la información de compilación, deben
haga lo mismo que en la configuración regular
de Tradefed: implemente el
IBuildReceiver para recibir la IBuildInfo. Consulta
con un dispositivo
para obtener más información.
Campos de metadatos
Una gran cantidad de módulos de prueba incluyen algunas especificaciones de metadata,
cada una con 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 component describen el componente general de Android que se incluye en el módulo.
tiene el objetivo de probar. No tiene ningún impacto directo en la ejecución de prueba. es
usarse 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 que no existe a una Módulo de CTS
Puedes filtrar la ejecución de un paquete según los componentes
module-metadata-include-filter y module-metadata-exclude-filter.
Ejemplo:
--module-metadata-include-filter component framework
En este ejemplo, solo se ejecuta el módulo de prueba con la anotación framework
este componente.
Parámetro
Los metadatos parameter son informativos y tienen un impacto en la prueba
ejecución. Especifica a qué modo de Android se aplica el módulo de prueba.
En este caso, los modos se limitan a los modos de Android de alto nivel, como
instant apps, secondary users o different abis.
Durante la ejecución del paquete, si el modo se aplica a la prueba, varias variaciones del módulo de prueba se crean en función del modo. Cada variación se ejecuta pruebas similares, pero en modos diferentes.
instant_app: Crea una variación de las pruebas que instalan los APK como las apps instantáneas.multi_abi: Crea una variación de las pruebas para cada ABI compatible con la dispositivo.secondary_user: Crea una variación de las pruebas que instalan los APK y y ejecutar pruebas como usuario secundario.
Recopilación y procesamiento posterior de métricas para los módulos de prueba de rendimiento
Para los módulos de prueba de rendimiento, se puede usar metrics_collector de nivel de módulo y
Se permiten las metric_post_processor, ya que son esenciales para las pruebas de rendimiento.
Los recopiladores de métricas y los posprocesadores a nivel de módulo pueden ser específicos de cada módulo.
No se recomienda especificar postprocesadores en los niveles superiores
nivel de módulo.
Una configuración del módulo de prueba de rendimiento debe incluir los metadatos test-type
con el valor performance, por ejemplo:
xml
<option name="config-descriptor:metadata" key="test-type" value="performance" />
Sin esto, si una configuración de prueba incluye metric_collector distinto de
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>