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

Executando testes (Atest),Executando testes (Atest)

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

O Atest é uma ferramenta de linha de comando que permite aos usuários criar, instalar e executar testes do Android localmente, acelerando muito 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 Android Platform Testing .

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 de Atest, consulte Executando testes em arquivos TEST_MAPPING .

Para adicionar um recurso ao Atest, siga o fluxo de trabalho do desenvolvedor do Atest .

Configure seu ambiente

Para configurar seu ambiente Atest, siga as instruções em Configurando o ambiente , Escolhendo um destino e Construindo o código .

Uso básico

Os comandos Atest assumem 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 Constrói alvos de teste. (padrão)
-i --install Instala artefatos de teste (APKs) no dispositivo. (padrão)
-t --test Executa os testes. (padrão)
-s --serial Executa os testes no dispositivo especificado. Um dispositivo pode ser testado por vez.
-d --disable-teardown Desativa a desmontagem e limpeza do teste.
--info Mostra as informações relevantes sobre os destinos especificados e sai.
--dry-run Execute o Atest sem realmente criar, instalar ou executar testes.
-m --rebuild-module-info Força uma reconstrução do arquivo module-info.json .
-w --wait-for-debugger Espera o depurador terminar antes de executar.
-v --verbose Exibe o log de nível DEBUG.
--iterations Testes executados em loop até que a iteração máxima seja atingida. (10 por padrão)
--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)
--retry-any-failure [COUNT=10] Executa novamente os testes com falha até que sejam aprovados ou 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 um AVD usando o comando acloud .
--[CUSTOM_ARGS] Especifica argumentos personalizados para os executores de teste.
-a --all-abi Executa os testes para todas as arquiteturas de dispositivos disponíveis.
--host Executa o teste completamente no host sem um dispositivo.
Observação: a execução de um teste de host que requer um dispositivo com --host falhará.
--history Mostra os resultados do teste em ordem cronológica.
--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:Aula
  • Nome da classe
  • Teste de integração negociado
  • 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 conforme ele 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:Aula

Para executar uma única classe dentro de um módulo, use Module:Class . O módulo é o mesmo descrito em Nome do módulo . Class é 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 negociado

Para executar testes integrados diretamente ao TradeFed (não módulos), insira o nome conforme 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 oferece suporte à execução de testes baseados em módulo e testes baseados em integração, inserindo o caminho para o 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 repo-root do Android:

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

Nome do pacote

Atest oferece suporte à pesquisa 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.

  • Construa apenas destinos: 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

Um teste 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 o 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 oferece suporte à execução de 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

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 ao uso apenas do nome da classe porque especificar o módulo ou o local do arquivo Java permite que o Atest localize 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

Múltiplos métodos podem ser executados a partir de diferentes classes e módulos:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

Executando várias aulas

Para executar várias classes, separe-as com espaços da mesma forma que para executar vários testes. Atest cria 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.

Para executar duas classes no mesmo módulo:

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

Para executar duas aulas em módulos diferentes:

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

Executar binários do 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 32 bits) e arm64-v8a (ARM 64 bits).

Exemplo de teste de entrada:

atest -a libinput_tests inputflinger_tests

Para selecionar um binário GTest específico para executar, use dois pontos (:) para especificar o nome do teste e uma hashtag (#) para especificar ainda mais 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 .

Execute 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 nos arquivos TEST_MAPPING:

atest :all

Execute testes pós-submissão 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 apenas procura testes em arquivos TEST_MAPPING para cima (do diretório atual ou fornecido 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 atingida.

Exemplos:

Por padrã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 seguintes abordagens facilitam a detecção de testes inconsistentes:

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 atingida.

  • 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 testar módulos. Para adicionar opções de linha de comando TradeFed à sua execução de teste, use a seguinte estrutura e certifique-se de que seus argumentos personalizados sigam 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 do teste:

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

Passe opções 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 .