O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Esta página foi traduzida pela API Cloud Translation.

Estrutura de AndroidTest.xml

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

Lista de tags permitidas

AndroidTest.xml ou uma configuração de módulo mais ampla pode conter apenas o 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 a execução do teste.

OBSERVAÇÃO: consulte Configuração XML do Tradefed se precisar de uma revisão nas diferentes tags.

Objetos como build_provider ou result_reporter geram uma ConfigurationException se tentou ser executado dentro de um módulo configuração do Terraform. Isso evita a expectativa dessas objetos que realizam alguma tarefa em 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>

Essa configuração descreve um teste que exige que CtsGestureTestCases.apk para será instalado e vai executar uma instrumentação no android.gesture.cts .

Tags de inclusão `<include>` e `<template-include>`

O uso de <include> e <template-include> nas configurações do módulo é desanimado. Não há garantia de que elas vão funcionar como esperado.

Caso especial da tag metrics_collector

O metrics_collector é permitido, mas limitado aos FilePullerLogCollector para especificar um determinado arquivo ou diretório a ser puxado e registrado para no módulo. Isso é útil se você está deixando registros em um local específico e gostaria de 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 quanto às informações da versão ou aos downloads?

A definição das tags permitidas pode dar a impressão incorreta de que um não receberá informações de build. Isso não é verdade.

As informações de versão são fornecidas a partir da configuração no nível da suíte e serão compartilhada por todos os módulos do pacote. Isso permite uma única configuração de nível superior, do pacote para executar todos os módulos que fazem parte do pacote.

Por exemplo, em vez de cada Conjunto de teste de compatibilidade (CTS) consultando individualmente as informações, os tipos etc. do dispositivo, o CTS a configuração no nível do pacote (cts.xml) faz isso uma vez, e cada módulo recebe esse informações caso elas solicitem.

Para que os objetos em um módulo recebam as informações do build, eles precisam para fazer o mesmo da configuração normal do Tradefed: implemente o IBuildReceiver para receber o IBuildInfo. Consulte teste com dispositivo para mais detalhes.

Campos de metadados

Um grande número de módulos de teste inclui algumas especificações metadata, com um objetivo único.

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 que pretende testar. Não tem nenhum impacto direto na execução do teste. é usada principalmente para fins organizacionais.

A lista atualizada de componentes permitidos para o CTS está disponível em CtsConfigLoadingTest. Este teste vai falhar no pré-envio se um componente inexistente 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 só executa o módulo de teste anotado com a framework componente.

Parâmetro

Os metadados parameter são informativos e afetam o teste execução. Ele especifica a qual modo do Android o módulo de teste se aplica. Nesse caso, os modes estão limitados aos 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 são criadas com base no modo. Cada variação é executada semelhantes, mas com modos diferentes.

instant_app: cria uma variação dos testes que instalam APKs como e apps instantâneos.
multi_abi: cria uma variação dos testes para cada ABI compatível com as dispositivo.
secondary_user: cria uma variação dos testes que instalam APKs e executar 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, os módulos metrics_collector e metric_post_processor são permitidas porque 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 para cada módulo. Não é recomendado especificar pós-processadores em no nível do módulo.

A configuração de um módulo de teste de desempenho precisa incluir os metadados test-type. com o 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 diferentes FilePullerLogCollector ou qualquer metric_post_processor, o teste falha 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>