Executando testes (Atest),Executando testes (Atest)

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

Para obter informações gerais sobre como escrever testes para Android, consulte Teste de plataforma Android .

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

Para obter informações sobre como executar testes em arquivos TEST_MAPPING por meio do Atest, consulte Executando testes em arquivos TEST_MAPPING .

Para adicionar um recurso ao Atest, siga o Atest Developer Workflow .

Configurando seu ambiente

Siga as etapas nas seções a seguir para configurar seu ambiente Atest.

Definir variável de ambiente

Defina test_suite para Soong ou LOCAL_COMPATIBILITY_SUITE para Criar as seguintes regras de script de compilação do Packaging .

Execute envsetup.sh

Na raiz do checkout de origem do Android, execute:

source build/envsetup.sh

Executar lunch

Execute o comando lunch 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 executar o Atest e adiciona o comando Atest ao seu $PATH .

Uso básico

Os comandos Atest têm o seguinte formato:

atest test-to-run [optional-arguments]

Argumentos opcionais

A tabela a seguir lista os argumentos mais usados. Uma lista completa está disponível em atest --help .

Opção Opção longa Descrição
-b --build Cria destinos 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 o teste de desmontagem e limpeza.
<c> --info Mostra as informações relevantes sobre os destinos especificados e sai.
<c> --dry-run Executa o Atest sem realmente construir, instalar ou executar testes.
-m --rebuild-module-info Força uma reconstrução do arquivo module-info.json .
-w --wait-for-debugger Aguarda a conclusão do depurador antes de executar.
-v --verbose Exibe o log de nível DEBUG.
<c> --iterations O loop executa testes até que a iteração máxima seja alcançada. (10 por padrão)
<c> --rerun-until-failure [COUNT=10] Executa novamente todos os testes até que ocorra uma falha ou a iteração máxima seja atingida. (10 por padrão)
<c> --retry-any-failure [COUNT=10] Executa novamente os testes com falha até que seja aprovado ou a iteração máxima seja atingida. (10 por padrão)
<c> --start-avd Cria automaticamente um AVD e executa testes no dispositivo virtual.
<c> --acloud-create Cria um AVD usando o comando acloud .
<c> --[CUSTOM_ARGS] Especifica argumentos personalizados para os executores de teste.
-a --all-abi Executa os testes para todas as arquiteturas de dispositivos disponíveis.
<c> --host Executa o teste completamente no host sem um dispositivo.
Nota: A execução de um teste de host que requer um dispositivo com --host falhará.
<c> --flakes-info Mostra o resultado do teste com informações de flocos.
<c> --history Mostra os resultados do teste em ordem cronológica.
<c> --latest-result Imprime o resultado do teste mais recente.

Para obter mais informações sobre -b , -i e -t , consulte a seção Especificar etapas: construir, instalar ou executar .

Especificar testes

Para executar testes, especifique um ou mais testes usando um dos seguintes identificadores:

  • Nome do módulo
  • Módulo: Classe
  • Nome da classe
  • Teste de integração Tradefed
  • Caminho de arquivo
  • Nome do pacote

Separe as referências a vários testes com espaços, assim:

atest test-identifier-1 test-identifier-2

Nome do módulo

Para executar um módulo de teste inteiro, use o nome do módulo. Insira o nome como aparece nas variáveis LOCAL_MODULE ou LOCAL_PACKAGE_NAME no arquivo Android.mk ou Android.bp desse teste.

Exemplos:

atest FrameworksServicesTests
atest CtsVideoTestCases

Módulo: Classe

Para executar uma única classe dentro de um módulo, use Module:Class . O módulo é o mesmo descrito em Nome do módulo . Classe é o nome da classe de teste no arquivo .java e pode ser o nome completo da classe ou o nome básico.

Exemplos:

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

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

Teste de integração Tradefed

Para executar testes que são integrados diretamente ao TradeFed (não módulos), insira o nome como ele aparece na saída do comando tradefed.sh list configs . Por exemplo:

Para executar o teste reboot.xml :

atest example/reboot

Para executar o teste native-benchmark.xml :

atest native-benchmark

Caminho de arquivo

O Atest suporta a execução de testes baseados em módulo e testes baseados em integração inserindo o caminho para seu arquivo ou diretório de teste conforme apropriado. Ele também suporta a execução de uma única classe especificando o caminho para o arquivo Java da classe. Ambos os caminhos relativos e absolutos são suportados.

Executar um módulo

Os exemplos a seguir mostram duas maneiras de executar o módulo CtsVideoTestCases usando um caminho de arquivo.

Execute a partir do repo-root do Android:

atest cts/tests/video

Execute a partir do Android repo-root/cts/tests/video :

    atest .

Executar uma aula de teste

O exemplo a seguir mostra como executar uma classe específica dentro do módulo CtsVideoTestCases usando um caminho de arquivo.

Do repo-root do Android:

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

Execute um teste de integração

O exemplo a seguir mostra como executar um teste de integração usando um caminho de arquivo do Android repo-root :

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

Nome do pacote

Atest suporta a busca de testes por nome de pacote.

Exemplos:

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

Especifique as etapas: Construir, instalar ou executar

Use as opções -b , -i e -t para especificar quais etapas executar. Se você não especificar uma opção, todas as etapas serão executadas.

  • Apenas destinos de compilação: atest -b test-to-run
  • Executar apenas testes: atest -t test-to-run
  • Instale o apk e execute os testes: atest -it test-to-run
  • Compile e execute, mas não instale: atest -bt test-to-run

O Atest pode forçar um teste a pular a etapa de limpeza ou desmontagem. Muitos testes, como o CTS, limpam o dispositivo após a execução do teste, portanto, tentar executar novamente seu teste com -t falhará sem o parâmetro --disable-teardown . Use -d antes de -t para pular a etapa de limpeza do teste e testar iterativamente.

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

Executando métodos específicos

Atest suporta a execução de métodos específicos dentro de 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

Ao especificar vários métodos, separe-os 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 a seguir mostram as formas preferidas de executar um único método, testFlagChange . Esses exemplos são preferíveis a usar apenas o nome da classe porque especificar o módulo ou o local do arquivo Java permite que o Atest encontre o teste muito mais rapidamente.

Usando Módulo: Classe:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Do repo-root do Android:

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 forma que para executar vários testes. O Atest cria e executa classes com eficiência, portanto, especificar um subconjunto de classes em um módulo melhora o desempenho ao executar todo o módulo.

Para executar duas classes no mesmo módulo:

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

Para executar duas classes em módulos diferentes:

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

Executar binários GTest

Atest pode executar binários GTest. Use -a para executar esses testes para todas as arquiteturas de dispositivos disponíveis, que neste exemplo são armeabi-v7a (ARM de 32 bits) e arm64-v8a (ARM de 64 bits).

Exemplo de teste de entrada:

atest -a libinput_tests inputflinger_tests

Para selecionar um binário GTest específico a ser executado, use dois pontos (:) para especificar o nome do teste e uma hashtag (#) para especificar melhor um método individual.

Por exemplo, para a seguinte definição de teste:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Execute o seguinte para especificar todo o teste:

atest inputflinger_tests:InputDispatcherTest

Ou execute um teste individual usando o seguinte:

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Executar testes em TEST_MAPPING

Atest pode executar testes em arquivos TEST_MAPPING .

Executar testes de pré-envio implicitamente

Execute testes de pré-envio em arquivos TEST_MAPPING nos diretórios atual e pai:

atest

Execute testes de pré-envio em arquivos TEST_MAPPING em /path/to/project e seus diretórios pai:

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

Executar um grupo de teste especificado

Os grupos de teste disponíveis são: presubmit (padrão), postsubmit , mainline-presubmit e all .

Execute testes pós-envio em arquivos TEST_MAPPING nos diretórios atual e pai:

atest :postsubmit

Execute testes de todos os grupos em arquivos TEST_MAPPING:

atest :all

Execute testes postsubmit em arquivos TEST_MAPPING em /path/to/project e seus diretórios pai:

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

Execute 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

Executar testes em subdiretórios

Por padrão, o Atest só procura por testes em arquivos TEST_MAPPING para cima (do diretório atual ou determinado para seus diretórios pai). Se você também deseja executar testes em arquivos TEST_MAPPING nos subdiretórios, use --include --include-subdirs subdirs para forçar o Atest a incluir esses testes também:

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

Executar testes em iteração

Execute testes em iteração passando o argumento --iterations . Seja aprovado ou reprovado, o Atest repetirá o teste até que a iteração máxima seja alcançada.

Exemplos:

Por padrão, o Atest itera 10 vezes. O número de iterações deve ser um número inteiro positivo.

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

As abordagens a seguir facilitam a detecção de testes escamosos:

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é que seja aprovado ou a iteração máxima seja alcançada.

  • Suponha test-to-run tenha vários casos de teste e um dos testes falhe. Execute apenas o teste com falha 10 vezes (por padrão) ou até que o teste seja aprovado.
    atest test-to-run --retry-any-failure
    
  • Pare de executar o teste com falha quando ele passar ou atingir a 100ª rodada.
    atest test-to-run --retry-any-failure 100
    

Executar testes em AVDs

Atest é capaz de executar testes em um AVD recém-criado. Execute acloud create para criar um AVD e construir artefatos e, em seguida, use os exemplos a seguir para executar seus testes.

Inicie um AVD e execute testes nele:

acloud create --local-instance --local-image && atest test-to-run

Inicie um AVD como parte de uma execução de teste:

atest test-to-run --acloud-create "--local-instance --local-image"

Para obter mais informações, execute acloud create --help .

Passar opções para o módulo

Atest é capaz de passar opções para módulos de teste. Para adicionar opções de linha de comando TradeFed à sua execução de teste, use a estrutura a seguir e certifique-se de que seus argumentos personalizados seguem o formato de opção de linha de comando Tradefed.

atest test-to-run -- [CUSTOM_ARGS]

Passe as opções do módulo de teste para os 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

Opções de passe para um 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 obter mais informações sobre opções somente de teste, consulte Opções de passagem para os módulos .