Estrutura do AndroidTest.xml

A estrutura geral da configuração do módulo segue um padrão semelhante à configuração XML normal do Tradefed, mas com algumas restrições devido ao fato de serem executadas como parte de um pacote.

Lista de tags permitidas

AndroidTest.xml ou, de modo mais geral, a configuração do módulo 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.

OBSERVAÇÃO: consulte a configuração XML do Tradefed se precisar de uma atualização sobre as diferentes tags.

Objetos como build_provider ou result_reporter vão gerar uma ConfigurationException se tentarem ser executados de dentro de uma configuração de módulo. Isso evita a expectativa de que esses objetos realmente realizem alguma tarefa de dentro de um módulo.

Exemplo de configuração 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>

Essa configuração descreve um teste que exige a instalação do CtsGestureTestCases.apk e executa 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 de módulo não é recomendado. Não há garantia de que elas funcionem como esperado.

Caso especial para a tag metrics_collector

O metrics_collector é permitido, mas limitado à FilePullerLogCollector classe para especificar um 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.

Exemplo de configuração:

<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 as informações ou downloads de build?

A definição das tags permitidas pode dar a impressão incorreta de que um módulo não vai receber nenhuma informação de build. Isso não é verdade.

As informações de build são fornecidas pela configuração no nível do pacote e serão compartilhadas por todos os módulos do pacote. Isso permite uma única configuração de nível superior para o pacote, a fim de executar todos os módulos que fazem parte dele.

Por exemplo, em vez de cada módulo do conjunto de teste de compatibilidade (CTS) consultar individualmente as informações do dispositivo, os tipos etc., a configuração do conjunto do CTS (cts.xml) faz isso uma vez, e cada módulo recebe essas informações se as solicitar.

Para que os objetos em um módulo recebam as informações de build, eles precisam fazer o mesmo que na configuração normal do Tradefed: implementar a interface IBuildReceiver para receber o IBuildInfo. Consulte Testes com dispositivos para mais detalhes.

Campos de metadados

Um grande número de módulos de teste inclui algumas especificações de 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. Ele não tem impacto direto na execução do teste. É usado principalmente para fins organizacionais.

A lista atualizada de componentes permitidos para o CTS está disponível em CtsConfigLoadingTest. Esse teste falha na pré-confirmação se um componente não existente for adicionado a um módulo do CTS.

É possível filtrar uma execução de pacote 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 afetam a execução do teste. Eles especificam a qual modo do Android o módulo de teste se aplica. Nesse caso, os modos são limitados a modos de alto nível do Android, como instant apps, secondary users ou different abis.

Durante a execução do pacote, se o modo se aplicar ao teste, várias 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: cria uma variação dos testes que instalam APKs como apps instantâneos.
  • multi_abi: cria uma variação dos testes para cada ABI compatível com o dispositivo.
  • secondary_user: cria uma variação dos testes que instalam APKs e executam testes como um usuário secundário.

Coleta de métricas e pós-processamento para módulos de teste de desempenho

Para módulos de teste de desempenho, metrics_collector e metric_post_processor no nível do módulo são permitidos, já que são essenciais para testes de desempenho. Os coletores e pós-processadores de métricas no nível do módulo podem ser específicos do módulo. Não é recomendável especificar pós-processadores nos níveis superior e do módulo.

Uma configuração de módulo de teste de desempenho precisa incluir os test-type metadados com valor performance, como: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> Sem isso, se uma configuração de teste incluir metric_collector diferente de FilePullerLogCollector ou qualquer metric_post_processor, o teste vai falhar na pré-confirmação.

Exemplo de configuração de 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>