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

Um teste

Atest é uma ferramenta de linha de comando que permite aos usuários construir, instalar e executar testes Android localmente, acelerando enormemente teste re-runs sem exigir conhecimento do equipamento de teste da Federação do Comércio opções de linha de comando. Esta página explica como usar o Atest para executar testes do Android.

Para obter informações gerais sobre a escrita de testes para Android, consulte Android plataforma de teste .

Para obter informações sobre a estrutura geral do Atest, consulte Atest Guia do desenvolvedor .

Para obter informações sobre a execução de testes em arquivos TEST_MAPPING através Atest, consulte execução de testes em arquivos TEST_MAPPING .

E para adicionar um recurso para Atest, siga Atest desenvolvedor de fluxo de trabalho .

Configurando seu ambiente

Para executar o Atest, siga as etapas nas seções abaixo para configurar seu ambiente.

Definir variável de ambiente

Set test_suite para Soong ou LOCAL_COMPATIBILITY_SUITE de Make per Embalagem regras script de construção .

Execute envsetup.sh

Na raiz da verificação de origem do Android, execute:

source build/envsetup.sh

Almoçar

Execute o lunch comando para abrir um menu de dispositivos suportados. Encontre o dispositivo e execute esse comando.

Por exemplo, se você tiver um dispositivo ARM conectado, execute o seguinte comando:

lunch aosp_arm64-eng

Isso define várias variáveis de ambiente necessárias para a execução de Atest e adiciona o comando Atest para o seu $PATH .

Uso básico

Os comandos Atest têm o seguinte formato:

atest test-to-run [optional-arguments]

Argumentos opcionais

Abaixo estão os argumentos mais comumente usados. Uma lista completa está disponível através atest --help .

Opção Opção longa Descrição
-b --build Constrói alvos de teste. (predefinição)
-i --install Instala artefatos de teste (APKs) no dispositivo. (predefinição)
-t --test Executa os testes. (predefinição)
-s --serial Executa os testes no dispositivo especificado. Um dispositivo pode ser testado por vez.
-d --disable-teardown Desativa a desmontagem e limpeza de teste.
--info Mostra as informações relevantes dos destinos e saídas especificados.
--dry-run A seco executa um teste sem construir, instalar e executar testes na realidade
-m --rebuild-module-info Forças uma reconstrução do module-info.json arquivo.
-w --wait-for-debugger Aguarda o depurador antes da execução. Apenas para testes de instrumentação.
-v --verbose Exibe o registro do nível DEBUG.
--iterations Loop executa testes até que a iteração máxima seja alcançada. (10 por padrão)
--rerun-until-failure [COUNT=10] Executa todos os testes novamente até que ocorra uma falha ou a iteração máxima seja atingida. (10 por padrão)
--retry-any-failure [COUNT=10] Executa novamente os testes com falha até passar ou até que a iteração máxima seja atingida. (10 por padrão)
--start-avd Cria automaticamente um AVD e executa testes no dispositivo virtual.
--acloud-create Cria AVDs usando o acloud command.
--[CUSTOM_ARGS] Especifica argumentos personalizados para os executores de teste.
-a --all-abi Executa os testes para todas as arquiteturas de dispositivo disponíveis.
--host Executa o teste completamente no host sem um dispositivo.
(Nota: A execução de um teste de acolhimento que exige um dispositivo com --host irá falhar.)
--flakes-info Mostra o resultado do teste com informações de flocos.
--history Mostra o resultado do teste em ordem cronológica.
--latest-result Imprime o resultado do teste mais recente.

Para mais informações sobre -b , -i e -t , consulte Especificando passos: construir, instalar, ou correr.

Testes para executar

Você pode executar um ou mais testes usando test-to-run . Para executar vários testes, separe as referências de teste com espaços. Por exemplo:

atest test-to-run-1 test-to-run-2

aqui estão alguns exemplos:

atest FrameworksServicesTests
atest example/reboot
atest FrameworksServicesTests CtsVideoTestCases
atest FrameworksServicesTests:ScreenDecorWindowTests

Para mais informações sobre como fazer referência a um teste, consulte Identificar testes.

Identificando testes

Você pode especificar o test-to-run argumento com o nome do teste de módulo, Módulo: Class, nome da classe, teste de integração TF, caminho do arquivo ou nome do pacote.

Nome do módulo

Para executar um módulo de teste inteiro, use seu nome de módulo. Digite o nome que aparece nas LOCAL_MODULE ou LOCAL_PACKAGE_NAME variáveis em que o teste Android.mk ou Android.bp arquivo.

Exemplos:

atest FrameworksServicesTests
atest CtsVideoTestCases

Módulo: Classe

Para executar uma única classe dentro de um módulo, use Módulo: Class. Módulo é a mesma conforme descrito em nome de módulo . Classe é o nome da classe de teste no .java arquivo e pode ser o nome de classe totalmente qualificado ou o nome básico.

Exemplos:

atest FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
atest CtsVideoTestCases:VideoEncoderDecoderTest

Nome da classe

Para executar uma única classe sem declarar explicitamente um nome de módulo, use o nome da classe.

Exemplos:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Usando o módulo: Referência de Classe é recomendada sempre que possível, uma vez Atest requer mais tempo para procurar a árvore fonte completo para partidas potenciais, se nenhum módulo é indicado.

Exemplos (ordenados do mais rápido para o mais lento):

atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
atest FrameworksServicesTests:ScreenDecorWindowTests
atest ScreenDecorWindowTests

Teste de integração TF

Para executar testes que estão integradas directamente TradeFed (não-módulos de entrada), o nome, uma vez que aparece na saída da tradefed.sh list configs comando. Por exemplo:

Para executar o reboot.xml teste :

atest example/reboot

Para executar o native-benchmark.xml teste :

atest native-benchmark

Caminho de arquivo

Você pode executar testes baseados em módulo e testes baseados em integração inserindo o caminho para seu arquivo ou diretório de teste, conforme apropriado. Você também pode executar uma única classe especificando o caminho para o arquivo Java da classe. Ambos os caminhos relativos e absolutos são suportados.

Exemplo: Duas maneiras de executar o CtsVideoTestCases módulo via caminho

  1. Execute módulo do Android repo-root :

    atest cts/tests/video
    
  2. De Android repo-root / cts / tests / vídeo:

    atest .
    

Exemplo: Executar uma classe específica dentro CtsVideoTestCases módulo através de um caminho. De Android repo-root :

atest cts/tests/video/src/android/video/cts/VideoEncoderDecoderTest.java

Exemplo: execute um teste de integração por meio do caminho. De Android repo-root :

atest tools/tradefederation/contrib/res/config/example/reboot.xml

Nome do pacote

Atest oferece suporte a testes de pesquisa por nome de pacote.

Exemplos:

atest com.android.server.wm
atest com.android.uibench.janktests

Especificando etapas: construir, instalar ou executar

Você pode especificar quais os passos para executar usando a -b , -i , e -t opções. Se você não especificar uma opção, todas as etapas serão executadas.

  • Alvos de compilação apenas: atest -b test-to-run
  • Executar testes apenas: atest -t test-to-run
  • Instale apk e executar testes: atest -it test-to-run
  • Construir e executar, mas não instale: atest -bt test-to-run

O Atest pode forçar um teste a pular a etapa de limpeza / desmontagem. Muitos testes, tais como CTS, limpar o dispositivo após o teste é executado, de modo a tentar executar novamente o teste com -t irá falhar sem a --disable-teardown parâmetro. Use -d antes -t para pular o passo a limpeza e teste de forma iterativa.

atest -d test-to-run
atest -t test-to-run

Execução de métodos específicos

Você pode executar métodos específicos em uma classe de teste. Embora todo o módulo precise ser construído, isso reduz o tempo necessário para executar os testes. Para executar métodos específicos, identifique a classe usando qualquer uma das formas suportadas para identificar uma classe (Módulo: Classe, caminho do arquivo, etc) e anexe o nome do método.

atest reference-to-class#method1

Você pode especificar vários métodos com vírgulas.

atest reference-to-class#method1,method2,method3

Exemplos:

atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecors
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval

Os dois exemplos seguintes mostram as formas preferidas para executar um método único, testFlagChange . Esses exemplos têm preferência em vez de usar apenas o nome da classe porque a especificação do módulo ou do local do arquivo Java permite que o Atest encontre o teste muito mais rápido:

  1. Módulo de Uso: Classe

    atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange
    
  2. De Android repo-root

    atest frameworks/base/services/tests/wmtests/src/com/android/server/wm/ScreenDecorWindowTests.java#testFlagChange
    

Vários métodos podem ser executados a partir de diferentes classes e módulos:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

Executando várias classes

Para executar várias classes, separe-as com espaços da mesma maneira que executa vários testes. Atest constrói e executa classes com eficiência, portanto, especificar um subconjunto de classes em um módulo melhora o desempenho em relação à execução de todo o módulo.

Exemplos:

  • Duas classes no mesmo módulo:

    atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests
    
  • Duas classes em módulos diferentes:

    atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest
    

Executando testes nativos

Atest pode executar testes nativos. Use -a para executar os testes para todas as arquitecturas de dispositivos disponíveis, que neste exemplo são armeabi-v7a (ARM de 32 bits) e arm64-V8A (ARM de 64 bits).

Exemplos:

  • Testes de entrada:

    atest -a libinput_tests inputflinger_tests
    

Para selecionar um teste nativo específico a ser executado, use dois pontos (:) para especificar o nome do teste e hashtag (#) para especificar um método individual. Por exemplo, para a definição seguinte teste:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Você pode executar o teste usando

atest inputflinger_tests:InputDispatcherTest

ou um método de ensaio individual utilizando

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Executando testes em TEST_MAPPING

Atest pode executar testes em arquivos TEST_MAPPING.

  1. Execute testes de pré-envio implicitamente nos arquivos TEST_MAPPING nos diretórios atuais, pai ou específicos.

    Testes presubmit executado nos arquivos TEST_MAPPING em diretórios atuais e pai:

    atest
    

    Testes presubmit executado nos arquivos TEST_MAPPING em /path/to/project e seus diretórios pai:

    atest --test-mapping /path/to/project
    

  2. Executar um grupo de teste especificado na TEST_MAPPING arquivos; grupos de teste disponíveis são: presubmit (padrão), postsubmit , mainline-presubmit e all .

    • Testes postsubmit executado nos arquivos TEST_MAPPING em diretórios atuais e pai:

      atest :postsubmit
      

    • Executar testes de todos os grupos em arquivos TEST_MAPPING:

      atest :all
      

    • Testes postsubmit executado nos arquivos TEST_MAPPING em /path/to/project e seus diretórios pai

      atest --test-mapping /path/to/project:postsubmit
      

    • Executar testes de linha principal em arquivos TEST_MAPPING em /path/to/project e seus diretórios pai

      atest --test-mapping /path/to/project:mainline-presubmit
      

  3. Execute testes em arquivos TEST_MAPPING incluindo subdiretórios.

Por padrão, atest procura apenas testes em arquivos TEST_MAPPING para cima (do atual ou do fornecido para seus diretórios pais). Se você também deseja executar testes em arquivos TEST_MAPPING nas sub-diretórios, você pode usar a opção --include-subdirs para forçar atest para incluir esses testes também.

Testes presubmit executado nos arquivos TEST_MAPPING na corrente, pai e sub-diretórios:

atest --include-subdirs /path/to/project

Execução de testes na iteração

Para executar testes em iteração, simplesmente passar o --iterations argumento. Se passar ou falhar, atest não para de testar até que a iteração máxima seja atingida.

Exemplos:

Por padrão, atest itera 10 vezes, fornecendo um número inteiro para alterar a rodada de iteração.

atest test-to-run --iterations
atest test-to-run --iterations 5

Duas abordagens que ajudam os usuários a detectar testes instáveis:

Abordagem 1: execute todos os testes até que ocorra uma falha ou a iteração máxima seja atingida.

  • Pare quando ocorrer uma falha ou a iteração atingir a 10ª rodada (por padrão).
    atest test-to-run --rerun-until-failure
    
  • Pare quando ocorrer uma falha ou a iteração atingir a 100ª rodada.
    atest test-to-run --rerun-until-failure 100
    

Abordagem 2: Execute apenas testes com falha até passar ou até a iteração máxima ser atingida.

  • Suponha test-to-run tem cinco casos de teste e um dos testes falhar. Execute apenas o teste com falha 10 vezes ou até que o teste seja aprovado.
    atest test-to-run --retry-any-failure
    
  • Pare de executar o teste que falhou quando ele passar ou atingir a 100ª rodada.
    atest test-to-run --retry-any-failure 100
    

Execução de testes em AVDs

Atest é capaz de executar testes com o AVD recém-criado. Atest pode construir artefatos, juntamente com o funcionamento de acloud create e executar testes após a AVD foi criado com sucesso.

Exemplos:

  • Iniciar um AVD antes de executar testes no dispositivo recém-criado:

    acloud create && atest test-to-run
    
    Agora ele pode ser simplificado por:
    atest test-to-run --start-avd
    

  • Comece AVDs por specifing acloud create argumentos e executar testes no dispositivo recém-criado.

    atest test-to-run --acloud-create "--build-id 6509363 --build-target aosp_cf_x86_phone-userdebug --branch aosp_master"
    

Para obter detalhes sobre o uso do argumento, execute acloud create --help .

Passar opções para o módulo

Atest é capaz de passar opções para os módulos. O formato breve na linha de comando Atest para adicionar opção de linha de comando TradeFed é

atest test-to-run -- [CUSTOM_ARGS]
Os [CUSTOM_ARGS] devem seguir os formatos de linha de comando opção Tradefed.

Exemplos de aprovação de opções de módulo de teste para preparadores de destino ou executores de teste definidos no arquivo de configuração de teste:

atest test-to-run -- --module-arg module-name:option-name:option-value
atest GtsPermissionTestCases -- --module-arg GtsPermissionTestCases:ignore-business-logic-failure:true

Exemplos de opções de passagem para o tipo ou classe de corredor:

atest test-to-run -- --test-arg test-class:option-name:option-value
atest CtsVideoTestCases -- --test-arg com.android.tradefed.testtype.JarHosttest:collect-tests-only:true

Para mais informações sobre teste únicas opções, consulte opções de passe para os módulos