O Google está comprometido em promover a equidade racial para as comunidades negras. Veja como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Um teste

O Atest é uma ferramenta de linha de comando que permite aos usuários criar, instalar e executar testes do Android localmente, acelerando muito a execução dos testes sem exigir o conhecimento das opções de linha de comando do equipamento de teste da Federação do 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 através do Atest, consulte Executando testes em arquivos TEST_MAPPING .

E para adicionar um recurso ao Atest, siga o Atest Developer Workflow .

Configurando seu ambiente

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

Definir variável de ambiente

Defina test_suite para Soong ou LOCAL_COMPATIBILITY_SUITE para regras de script de construção Make per Packaging .

1. Execute envsetup.sh

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

source build/envsetup.sh

2. Almoço

Execute o comando $ lunch para exibir 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 [ optional-arguments ] test-to-run

Argumentos opcionais

Você pode usar os seguintes argumentos opcionais com os comandos Atest.

Opção Opção longa Descrição
-b --build Cria alvos de teste.
-i --install Instala artefatos de teste (APKs) no dispositivo.
-t --test Executa os testes.
-s --serial Executa os testes no dispositivo especificado. Um dispositivo pode ser testado por vez.
-d --disable-teardown Desativa desmontagem e limpeza do teste.
--info Mostra as informações relevantes dos destinos e saídas especificados.
--dry-run Um sinônimo de --info.
-m --rebuild-module-info Força uma reconstrução do arquivo module-info.json.
-w --wait-for-debugger Aguarda o depurador antes da execução. Somente para testes de instrumentação.
-v --verbose Exibe o registro no nível DEBUG.
--generate-baseline Gera métricas de linha de base, executa 5 iterações por padrão.
--generate-new-metrics Gera novas métricas, executa 5 iterações por padrão.
--detect-regression Executa o algoritmo de detecção de regressão.
--[CUSTOM_ARGS] Especifica argumentos personalizados para os corredores de teste.
-a --all-abi Executa os testes para todas as arquiteturas de dispositivos disponíveis.
-h --help Mostra a mensagem de ajuda e sai.
--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á.)

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

Testes a serem executados

Você pode executar um ou mais testes usando o 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 CtsJankDeviceTestCases
atest FrameworksServicesTests:ScreenDecorWindowTests

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

Identificando testes

Você pode especificar o argumento de test-to-run com o nome do módulo do teste, Módulo: Classe, 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 o nome do 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 CtsJankDeviceTestCases

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 FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
atest CtsJankDeviceTestCases:CtsDeviceJankUi

Nome da classe

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

Exemplos:

atest ScreenDecorWindowTests
atest CtsDeviceJankUi

Utilizando o módulo: A referência de classe é recomendada sempre que possível, pois o Atest exige mais tempo para pesquisar possíveis correspondências na árvore de origem, se nenhum módulo for 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 integrados diretamente no 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

Você pode executar testes baseados em módulo e testes baseados em integração, inserindo o caminho em 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. Caminhos relativos e absolutos são suportados.

Exemplo: Duas maneiras de executar o módulo CtsJankDeviceTestCases por meio do caminho

  1. Execute o módulo do android repo-root :

    atest cts/tests/jank
    
  2. No Android repo-root / cts / tests / jank:

    atest .
    

Exemplo: execute uma classe específica no módulo CtsJankDeviceTestCases por meio do caminho. Do repo-root android:

atest cts/tests/jank/src/android/jank/cts/ui/CtsDeviceJankUi.java

Exemplo: Execute um teste de integração via caminho. Do repo-root android:

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

Nome do pacote

O Atest suporta a pesquisa de testes pelo nome do pacote.

Exemplos:

atest com.android.server.wm
atest android.jank.cts

Especificando etapas: criar, instalar ou executar

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

  • Construa apenas destinos: atest -b test-to-run
  • Execute apenas testes: atest -t test-to-run
  • Instale o apk e execute testes: atest -it test-to-run
  • Construa e execute, mas não instale: atest -bt test-to-run

A Atest pode forçar um teste a pular a etapa de limpeza / desmontagem. Muitos testes, como o CTS, limpam o dispositivo após a execução do teste, portanto, tentar executar o teste novamente com -t falhará sem o parâmetro --disable-teardown . Use -d antes -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

Você pode executar métodos específicos dentro de uma classe de teste. Embora o módulo inteiro 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 maneiras suportadas para identificar uma classe (Módulo: Classe, caminho do arquivo, etc.) e acrescente 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 a seguir mostram as maneiras preferidas de executar um único método, testFlagChange . Esses exemplos são preferidos ao usar apenas o nome da classe, porque especificar o módulo ou o local do arquivo Java permite que a Atest encontre o teste muito mais rapidamente:

  1. Usando o Módulo: Classe

    atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange
    
  2. Do repo-root android

    atest frameworks/base/services/tests/servicestests/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 a execução de vários testes. O Atest cria e executa classes de maneira eficiente, portanto, especificar um subconjunto de classes em um módulo melhora o desempenho da execução de todo o módulo.

Exemplos:

  • Duas classes no mesmo módulo:

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

    atest FrameworksServicesTests:ScreenDecorWindowTests CtsJankDeviceTestCases:CtsDeviceJankUi
    

Executando testes nativos

O Atest pode executar testes nativos.

Exemplos:

  • Testes de entrada:

    atest -a libinput_tests inputflinger_tests
    

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

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

 TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents) 

Você pode executar o teste inteiro usando

 atest inputflinger_tests:InputDispatcherTest 

ou um método de teste individual usando

 atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents 

Detectando regressão de métricas

Você pode gerar métricas pré-patch ou pós-patch sem executar a detecção de regressão. Você pode especificar o número de iterações, mas o padrão é cinco.

Exemplos:

atest test-to-run --generate-baseline [optional-iteration]
atest test-to-run --generate-new-metrics [optional-iteration]

A detecção de regressão local pode ser executada em três opções:

  1. Gere métricas de linha de base (pré-correção) e coloque-as em uma pasta. A Atest executa os testes pelas iterações especificadas, gera métricas pós-correção e as compara com as métricas existentes.

    Exemplo:

    atest test-to-run --detect-regression /path/to/baseline --generate-new-metrics [optional-iteration]
    
  2. Usando uma pasta contendo as métricas de pós-remendo previamente gerados, Atest corre os testes n iterações, gera um novo conjunto de métricas de pré-remendo, e compara os contra as previstas.

    Exemplo:

    atest test-to-run --detect-regression /path/to/new --generate-baseline [optional-iteration]
    
  3. Usando duas pastas que contêm métricas de pré e pós-patch, o Atest executa o algoritmo de detecção de regressão sem nenhum teste.

    Exemplo:

    atest --detect-regression /path/to/baseline /path/to/new