Executar testes (Atest)

O Atest é uma ferramenta de linha de comando que permite aos usuários criar, instalar e executar Testes do Android localmente, acelerando muito as novas execuções, sem a necessidade conhecimento sobre o arquinho de testes da Trade Federation opções da linha de comando. Esta página explica como usar o Atest para executar o Android provas.

Para informações gerais sobre a criação de testes para Android, consulte Testes de plataforma Android.

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

Para ver informações sobre como executar testes em arquivos TEST_MAPPING por meio do Atest, consulte Execução de testes em arquivos TEST_MAPPING.

Para adicionar um recurso ao Atest, siga as Fluxo de trabalho do desenvolvedor de teste.

Configurar o ambiente

Para configurar o ambiente do Atest, siga as instruções em Configurar o ambiente, Escolher um destino e Criar o código.

Uso básico

Os comandos do 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 é disponíveis pelo app atest --help.

Para mais informações sobre -b, -i e -t, consulte a Especificar as etapas: criar, instalar ou executar.

Especificar testes

Para executar testes, especifique um ou mais testes usando uma das opções a seguir: identificadores:

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

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

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 aparece nas variáveis LOCAL_MODULE ou LOCAL_PACKAGE_NAME no arquivo Android.mk ou Android.bp do teste.

Exemplos:

atest FrameworksServicesTests
atest CtsVideoTestCases

Módulo: classe

Para executar uma única classe em um módulo, use Module:Class. Module é o igual ao descrito em Nome do módulo. Class é o nome da classe de teste no arquivo .java e pode ser o nome de classe totalmente qualificado 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 o nome de um módulo, use a classe nome.

Exemplos:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Teste de integração do Tradefed

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

Para executar o teste reboot.xml:

atest example/reboot

Para executar Teste native-benchmark.xml:

atest native-benchmark

Caminho do arquivo

O Atest oferece suporte à execução de testes com base em módulo e em integração, inserindo o caminho para o arquivo ou diretório de teste, conforme apropriado. Ela também suporta a execução de uma única classe especificando o caminho para o arquivo Java da classe. Há suporte para caminhos relativos e absolutos.

Executar um módulo

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

Execute no Android repo-root:

atest cts/tests/video

Executar no Android repo-root/cts/tests/video:

    atest .

Executar uma classe de teste

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

No Android repo-root:

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

Executar um teste de integração

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

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

Nome do pacote

O Atest é compatível com a pesquisa de testes pelo nome do pacote.

Exemplos:

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

Especificar as etapas: criar, instalar ou executar

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

• Criar apenas destinos: atest -b test-to-run
• Executar apenas testes: atest -t test-to-run
• Instale o apk e execute testes: atest -it test-to-run
• Crie 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 CTS, limpe o dispositivo depois que o teste for executado. Tente executar o teste de novo com -t vai falhar sem o parâmetro --disable-teardown. Use -d antes de -t para pular a etapa de limpeza do teste e testar de forma iterativa.

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

Executar métodos específicos

O Atest oferece suporte à execução de métodos específicos em uma classe de teste. Embora todo precisa ser criado, isso reduz o tempo necessário para executar os testes. Para executar métodos específicos, identifique a classe usando qualquer uma das formas com suporte para identificar uma classe (Module:Class, 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 maneiras preferidas de executar um único método, testFlagChange: Esses exemplos são preferidos ao uso exclusivo do nome da classe, porque especificar o módulo ou o local do arquivo Java permite que o Atest encontre o teste muito mais rapidamente.

Como usar Module:Class:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

No Android repo-root:

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

Vários métodos podem ser executados em diferentes classes e módulos:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

Executar várias turmas

Para dar várias classes, separe-as por espaços, da mesma forma que você faz vários testes. O Atest compila e executa classes de forma eficiente, portanto, subconjunto de classes em um módulo melhora o desempenho em relação à execução de todo o mais tarde neste 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 do GTest

O Atest pode executar binários do GTest. Use -a para executar esses testes para todos os itens disponíveis do dispositivo, que neste exemplo são armeabi-v7a (ARM 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 do GTest específico para execução, use dois-pontos (:) para especificar o 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 comando 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

O 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 atuais e pai:

atest

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

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 atuais e principais:

atest :postsubmit

Execute testes de todos os grupos em arquivos TEST_MAPPING:

atest :all

Execute testes pós-envio em arquivos TEST_MAPPING em /path/to/project e nos diretórios pais:

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

Execute testes de linha principal em arquivos TEST_MAPPING em /path/to/project e seus diretórios pais:

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

Executar testes em subdiretórios

Por padrão, o Atest só pesquisa testes em arquivos TEST_MAPPING superiores (de diretório atual ou do determinado diretório aos diretórios pai). Se você também quiser executar testes em arquivos TEST_MAPPING nos subdiretórios, use --include-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 transmitindo o argumento --iterations. Se ela passa ou falhar, o Atest repetirá o teste até que a iteração máxima seja alcançada.

Exemplos:

Por padrão, o Atest faz a iteração 10 vezes. O número de iterações precisa 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 instáveis:

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

• É interrompido quando ocorre uma falha ou a iteração atinge a 10a rodada (por padrão).

  atest test-to-run --rerun-until-failure
  

• É interrompido quando ocorrer uma falha ou a iteração chegar à 100a rodada.

  atest test-to-run --rerun-until-failure 100
  

Abordagem 2: execute somente testes com falha até ser aprovado ou até a iteração máxima ser atingida.

• Suponha que test-to-run tenha vários casos de teste e um dos durante os testes. Execute somente o teste com falha 10 vezes (por padrão) ou até que o passar no teste.

  atest test-to-run --retry-any-failure
  

• Pare de executar o teste com falha quando ele for aprovado ou chegar à 100a rodada.

  atest test-to-run --retry-any-failure 100
  

Executar testes em AVDs

O Atest pode executar testes em um AVD recém-criado. Execute acloud create para criar um AVD e artefatos de compilação. Depois, use os exemplos a seguir para executar os 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 mais informações, execute acloud create --help.

Transmitir opções para o módulo

O Atest é capaz de transmitir opções para módulos de teste. Para adicionar a linha de comando do TradeFed à execução do teste, use a estrutura a seguir e verifique se as configurações sigam o formato de opção de linha de comando do Tradefed.

atest test-to-run -- [CUSTOM_ARGS]

Transmita as opções do módulo de teste para os preparadores ou executores de teste de destino 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

Transmita opções para um tipo ou classe de executor:

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 opções somente para teste, consulte Transmitir opções para os módulos.