O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Um teste

Atest é uma ferramenta de linha de comando que permite aos usuários construir, instalar e executar testes do Android localmente, agilizando enormemente as reexecuções de teste sem exigir conhecimento das opções de linha de comando de teste da Federação Comercial . 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 da 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 de Atest, consulte Executando testes em arquivos TEST_MAPPING .

E para adicionar um recurso ao Atest, siga o Fluxo de trabalho do desenvolvedor do Atest .

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. Faça o almoço

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 [optional-arguments] test-to-run

Argumentos opcionais

Você pode usar os seguintes argumentos opcionais com 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 a desmontagem e limpeza de 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. Apenas para testes de instrumentação.
-v --verbose Exibe o registro do 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 executores de teste.
-a --all-abi Executa os testes para todas as arquiteturas de dispositivo disponíveis.
-h --help Mostra a mensagem de ajuda e sai.
--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 irá falhar.)

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

Testes para executar

Você pode executar um ou mais testes usando 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 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 seu nome de 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 é igual ao 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 declarar explicitamente um nome de módulo, use o nome da classe.

Exemplos:

atest ScreenDecorWindowTests
atest CtsDeviceJankUi

Usando o Módulo: A referência de classe é recomendada sempre que possível, pois Atest requer mais tempo para pesquisar a árvore de origem completa para possíveis correspondências se nenhum módulo for declarado.

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 que são 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

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

Exemplo: duas maneiras de executar o módulo CtsJankDeviceTestCases via caminho

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

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

    atest .
    

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

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

Exemplo: execute um teste de integração por meio do caminho. Do Android repo-root :

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

Nome do pacote

Atest oferece suporte a testes de pesquisa por nome de pacote.

Exemplos:

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

Especificando etapas: construir, 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.

  • Apenas alvos de compilação: atest -b test-to-run
  • Execute 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

Atest pode forçar um teste a pular a etapa de limpeza / desmontagem. Muitos testes, como o CTS, limpam o dispositivo depois que o teste é executado, 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 de teste e teste iterativamente.

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

Execução de métodos específicos

Você pode executar 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 maneiras suportadas para identificar uma classe (Módulo: Classe, caminho do arquivo, etc) e anexe 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 têm preferência em vez de usar apenas o nome da classe porque a especificação do módulo ou do local do arquivo Java permite que o Atest encontre o teste muito mais rápido:

  1. Módulo de Uso: Classe

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

    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 forma que executa vários testes. Atest constrói e executa classes de forma eficiente, portanto, especificar um subconjunto de classes em um módulo melhora o desempenho em relação à execução de todo o módulo.

Exemplos:

  • Duas classes no mesmo módulo:

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

    atest FrameworksServicesTests:ScreenDecorWindowTests CtsJankDeviceTestCases:CtsDeviceJankUi
    

Executando testes nativos

Atest pode executar testes nativos.

Exemplos:

  • Testes de entrada:

    atest -a libinput_tests inputflinger_tests
    

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

Para selecionar um teste nativo específico a ser executado, use dois pontos (:) para especificar o nome do teste e hashtag (#) para especificar 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é-patch) e coloque-as em uma pasta. Atest executa os testes por meio das iterações especificadas, gera métricas pós-patch 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 contendo métricas pré-patch e pós-patch, Atest executa o algoritmo de detecção de regressão sem quaisquer testes.

    Exemplo:

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