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 FrameworksServicesTestsatest 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:VideoEncoderDecoderTestatest FrameworksServicesTests:ScreenDecorWindowTestsatest 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 ScreenDecorWindowTestsatest 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-runatest -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#testMultipleDecorsatest 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/projectExecutar 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 --iterationsatest 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-runtenha 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-valueatest 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-valueatest 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 .