A estrutura geral da configuração do módulo segue um padrão semelhante à configuração regular do Tradefed XML, mas com algumas restrições devido ao fato de serem executados como parte de um conjunto.
Lista de tags permitidas
AndroidTest.xml ou configuração de módulo mais ampla pode conter apenas as seguintes tags XML: target_preparer , multi_target_preparer , test e metrics_collector .
Embora essa lista pareça restritiva, ela permite definir com precisão as necessidades de configuração do módulo de teste e o teste a ser executado.
NOTA: Consulte Configuração XML do Tradefed se precisar de uma atualização sobre as diferentes tags.
Objetos como build_provider ou result_reporter gerarão uma ConfigurationException se tentarem ser executados de dentro de uma configuração de módulo. O objetivo é evitar a expectativa de que esses objetos realmente executem alguma tarefa dentro de um módulo.
Exemplo de configuração do 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 configuração descreve um teste que requer a instalação de CtsGestureTestCases.apk e executará uma instrumentação no pacote android.gesture.cts .
Tags de inclusão <include> e <template-include>
O uso de <include> e <template-include> nas configurações do módulo é desencorajado. Não há garantia de que funcionem conforme o esperado.
Caso especial para tag métricas_collector
metrics_collector é permitido, mas limitado à classe FilePullerLogCollector para especificar um determinado arquivo ou diretório a ser extraído e registrado para o módulo. Isso é útil se você estiver deixando registros em um local específico e quiser recuperá-los automaticamente.
Configuração de exemplo:
<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>
E quanto a informações de construção ou downloads?
A definição das tags permitidas pode dar a impressão incorreta de que um módulo não receberá nenhuma informação de construção. Isso não é verdade .
As informações de construção são fornecidas na configuração em nível de suíte e serão compartilhadas por todos os módulos da suíte. Isso permite uma única configuração de nível superior para o conjunto, a fim de executar todos os módulos que fazem parte do conjunto.
Por exemplo, em vez de cada módulo do Compatibility Test Suite (CTS) consultar individualmente as informações do dispositivo, tipos, etc., a configuração no nível do conjunto CTS ( cts.xml ) faz isso uma vez e cada módulo receberá essas informações se solicitar.
Para que os objetos em um módulo recebam as informações de construção, eles precisam fazer o mesmo que na configuração normal do Tradefed: implementar a interface IBuildReceiver para receber o IBuildInfo . Consulte testes com dispositivo para obter mais detalhes.
Campos de metadados
Um grande número de módulos de teste inclui algumas especificações metadata , cada uma com um objetivo exclusivo.
Exemplo:
<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
Os metadados component descrevem o componente geral do Android que o módulo pretende testar. Não tem nenhum impacto direto na execução do teste; é usado principalmente para fins organizacionais.
A lista atualizada de componentes permitidos para CTS está disponível em CtsConfigLoadingTest . Este teste falha no pré-envio se um componente inexistente for adicionado a um módulo CTS.
Você pode filtrar uma execução de conjunto com base nos componentes usando module-metadata-include-filter e module-metadata-exclude-filter .
Exemplo:
--module-metadata-include-filter component framework
Este exemplo executa apenas o módulo de teste anotado com o componente framework .
Parâmetro
Os metadados parameter são informativos e impactam a execução do teste. Ele especifica a qual modo Android o módulo de teste se aplica. Neste caso, os modos são limitados a modos Android de alto nível, como instant apps , secondary users ou different abis .
Durante a execução do conjunto, se o modo se aplicar ao teste, diversas variações do módulo de teste serão criadas com base no modo. Cada variação executa testes semelhantes, mas em modos diferentes.
-
instant_app: crie uma variação dos testes que instalam APKs como aplicativos instantâneos. -
multi_abi: Crie uma variação dos testes para cada ABI suportada pelo dispositivo. -
secondary_user: crie uma variação dos testes que instalam APKs e executam testes como usuário secundário.
Coleta e pós-processamento de métricas para módulos de teste de desempenho
Para módulos de teste de desempenho, metrics_collector e metric_post_processor em nível de módulo são permitidos, pois são essenciais para testes de desempenho. Os coletores de métricas e pós-processadores em nível de módulo podem ser específicos do módulo. Não é recomendado especificar pós-processadores tanto no nível superior quanto no nível do módulo.
Uma configuração do módulo de teste de desempenho deve incluir os metadados test-type com valor performance , como: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> Sem isso, se um teste config incluir metric_collector diferente de FilePullerLogCollector ou qualquer metric_post_processor , o teste falhará no pré-envio.
Exemplo de configuração do módulo de teste de desempenho:
<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>