Esecuzione di test (Atest), Esecuzione di test (Atest)

Atest è uno strumento a riga di comando che consente agli utenti di creare, installare ed eseguire test Android in locale, velocizzando notevolmente le ripetizioni dei test senza richiedere la conoscenza delle opzioni della riga di comando del test Harness di Trade Federation . Questa pagina spiega come utilizzare Atest per eseguire test Android.

Per informazioni generali sulla scrittura di test per Android, vedere Android Platform Testing .

Per informazioni sulla struttura complessiva di Atest, fare riferimento alla Atest Developer Guide .

Per informazioni sull'esecuzione di test nei file TEST_MAPPING tramite Atest, vedere Esecuzione di test nei file TEST_MAPPING .

Per aggiungere una funzionalità ad Atest, segui il flusso di lavoro per sviluppatori Atest .

Imposta il tuo ambiente

Per configurare il tuo ambiente Atest, segui le istruzioni in Configurazione dell'ambiente , Scelta di un target e Compilazione del codice .

Utilizzo di base

I comandi Atest assumono la seguente forma:

atest test-to-run [optional-arguments]

Argomenti facoltativi

La tabella seguente elenca gli argomenti più comunemente usati. Un elenco completo è disponibile tramite atest --help .

Opzione	Opzione lunga	Descrizione
-b	--build	Crea obiettivi di test. (predefinito)
-i	--install	Installa artefatti di test (APK) sul dispositivo. (predefinito)
-t	--test	Esegue i test. (predefinito)
-s	--serial	Esegue i test sul dispositivo specificato. È possibile testare un dispositivo alla volta.
-d	--disable-teardown	Disabilita lo smontaggio e la pulizia del test.
	--info	Mostra le informazioni rilevanti sugli obiettivi specificati, quindi esce.
	--dry-run	Esegue Atest senza creare, installare o eseguire test.
-m	--rebuild-module-info	Forza una ricostruzione del file module-info.json .
-w	--wait-for-debugger	Attende il completamento del debugger prima dell'esecuzione.
-v	--verbose	Visualizza la registrazione a livello di DEBUG.
	--iterations	Esegue cicli di test finché non viene raggiunta l'iterazione massima. (10 per impostazione predefinita)
	--rerun-until-failure [COUNT=10]	Riesegue tutti i test finché non si verifica un errore o non viene raggiunta l'iterazione massima. (10 per impostazione predefinita)
	--retry-any-failure [COUNT=10]	Riesegue i test falliti finché non vengono superati o viene raggiunta l'iterazione massima. (10 per impostazione predefinita)
	--start-avd	Crea automaticamente un AVD ed esegue i test sul dispositivo virtuale.
	--acloud-create	Crea un AVD utilizzando il comando acloud .
	--[CUSTOM_ARGS]	Specifica argomenti personalizzati per i test runner.
-a	--all-abi	Esegue i test per tutte le architetture di dispositivi disponibili.
	--host	Esegue il test completamente sull'host senza un dispositivo. Nota: l'esecuzione di un test host che richiede un dispositivo con --host avrà esito negativo.
	--history	Mostra i risultati del test in ordine cronologico.
	--latest-result	Stampa l'ultimo risultato del test.

Per ulteriori informazioni su -b , -i e -t , vedere la sezione Specificare i passaggi: compilazione, installazione o esecuzione .

Specificare i test

Per eseguire i test, specificare uno o più test utilizzando uno dei seguenti identificatori:

• Nome del modulo
• Modulo:Classe
• Nome della classe
• Test di integrazione Tradefed
• Percorso del file
• Nome del pacchetto

Separare i riferimenti a più test con spazi, in questo modo:

atest test-identifier-1 test-identifier-2

Nome del modulo

Per eseguire un intero modulo di test, usa il suo nome di modulo. Immettere il nome come appare nelle variabili LOCAL_MODULE o LOCAL_PACKAGE_NAME nel file Android.mk o Android.bp del test.

Esempi:

atest FrameworksServicesTests
atest CtsVideoTestCases

Modulo:Classe

Per eseguire una singola classe all'interno di un modulo, utilizzare Module:Class . Il modulo è lo stesso descritto in Nome modulo . Class è il nome della classe di test nel file .java e può essere il nome completo della classe o il nome di base.

Esempi:

atest CtsVideoTestCases:VideoEncoderDecoderTest
atest FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests

Nome della classe

Per eseguire una singola classe senza dichiarare esplicitamente il nome di un modulo, utilizzare il nome della classe.

Esempi:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Test di integrazione Tradefed

Per eseguire test integrati direttamente in TradeFed (non moduli), inserire il nome così come appare nell'output del comando tradefed.sh list configs . Per esempio:

Per eseguire il test reboot.xml :

atest example/reboot

Per eseguire il test native-benchmark.xml :

atest native-benchmark

Percorso del file

Atest supporta l'esecuzione sia di test basati su moduli che di test basati sull'integrazione inserendo il percorso del loro file o directory di test come appropriato. Supporta anche l'esecuzione di una singola classe specificando il percorso del file Java della classe. Sono supportati sia percorsi relativi che assoluti.

Eseguire un modulo

Gli esempi seguenti mostrano due modi per eseguire il modulo CtsVideoTestCases utilizzando un percorso di file.

Esegui da Android repo-root :

atest cts/tests/video

Esegui da Android repo-root/cts/tests/video :

    atest .

Esegui una lezione di prova

L'esempio seguente mostra come eseguire una classe specifica all'interno del modulo CtsVideoTestCases utilizzando un percorso di file.

Da Android repo-root :

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

Eseguire un test di integrazione

L'esempio seguente mostra come eseguire un test di integrazione utilizzando un percorso file da Android repo-root :

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

Nome del pacchetto

Atest supporta la ricerca di test in base al nome del pacchetto.

Esempi:

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

Specificare i passaggi: compilazione, installazione o esecuzione

Utilizzare le opzioni -b , -i e -t per specificare i passaggi da eseguire. Se non specifichi un'opzione, vengono eseguiti tutti i passaggi.

• Solo obiettivi di compilazione: atest -b test-to-run
• Eseguire solo i test: atest -t test-to-run
• Installa apk ed esegui i test: atest -it test-to-run
• Compila ed esegui, ma non installare: atest -bt test-to-run

Atest può forzare un test a saltare la fase di pulizia o rimozione. Molti test, come CTS, puliscono il dispositivo dopo che il test è stato eseguito, quindi provare a eseguire nuovamente il test con -t fallirà senza il parametro --disable-teardown . Utilizzare -d prima di -t per saltare la fase di pulizia del test e testare in modo iterativo.

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

Esecuzione di metodi specifici

Atest supporta l'esecuzione di metodi specifici all'interno di una classe di test. Anche se l'intero modulo deve essere costruito, questo riduce il tempo necessario per eseguire i test. Per eseguire metodi specifici, identifica la classe utilizzando uno dei modi supportati per identificare una classe (Modulo:Classe, percorso file, ecc.) e aggiungi il nome del metodo:

atest reference-to-class#method1

Quando specifichi più metodi, separali con virgole:

atest reference-to-class#method1,method2,method3

Esempi:

atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecors
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval

I due esempi seguenti mostrano i modi preferiti per eseguire un singolo metodo, testFlagChange . Questi esempi sono preferiti all'uso del solo nome della classe perché specificare il modulo o la posizione del file Java consente ad Atest di trovare il test molto più rapidamente.

Utilizzo di Modulo:Classe:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Da Android repo-root :

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

Più metodi possono essere eseguiti da diverse classi e moduli:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

Esecuzione di più classi

Per eseguire più classi, separale con spazi allo stesso modo dell'esecuzione di più test. Atest crea ed esegue le classi in modo efficiente, quindi specificare un sottoinsieme di classi in un modulo migliora le prestazioni rispetto all'esecuzione dell'intero modulo.

Per eseguire due classi nello stesso modulo:

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

Per eseguire due classi in moduli diversi:

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

Eseguire i binari GTest

Atest può eseguire binari GTest. Utilizzare -a per eseguire questi test per tutte le architetture di dispositivi disponibili, che in questo esempio sono armeabi-v7a (ARM a 32 bit) e arm64-v8a (ARM a 64 bit).

Esempio di test di input:

atest -a libinput_tests inputflinger_tests

Per selezionare un binario GTest specifico da eseguire, utilizzare i due punti (:) per specificare il nome del test e un hashtag (#) per specificare ulteriormente un singolo metodo.

Ad esempio, per la seguente definizione di test:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Eseguire quanto segue per specificare l'intero test:

atest inputflinger_tests:InputDispatcherTest

Oppure esegui un test individuale utilizzando quanto segue:

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Eseguire i test in TEST_MAPPING

Atest può eseguire test nei file TEST_MAPPING .

Eseguire i test di preinvio in modo implicito

Esegui i test di TEST_MAPPING nei file TEST_MAPPING nelle directory corrente e principale:

atest

Esegui i test di TEST_MAPPING nei file TEST_MAPPING in /path/to/project e nelle relative directory principali:

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

Eseguire un gruppo di test specificato

I gruppi di test disponibili sono: presubmit (predefinito), postsubmit , mainline-presubmit e all .

Esegui i test post-invio nei file TEST_MAPPING nelle directory corrente e principale:

atest :postsubmit

Esegui test da tutti i gruppi nei file TEST_MAPPING:

atest :all

Esegui i test post-invio nei file TEST_MAPPING in /path/to/project e nelle relative directory principali:

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

Esegui i test della linea principale nei file TEST_MAPPING in /path/to/project e nelle relative directory principali:

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

Eseguire i test nelle sottodirectory

Per impostazione predefinita, Atest cerca solo i test nei file TEST_MAPPING verso l'alto (dalla directory corrente o data alle directory padre). Se vuoi anche eseguire i test nei file TEST_MAPPING nelle sottodirectory, usa --include-subdirs per forzare Atest a includere anche quei test:

atest --include-subdirs /path/to/project

Eseguire i test in iterazione

Eseguire i test in iterazione passando l'argomento --iterations . Indipendentemente dal fatto che venga superato o meno, Atest ripeterà il test fino al raggiungimento dell'iterazione massima.

Esempi:

Per impostazione predefinita, Atest esegue iterazioni 10 volte. Il numero di iterazioni deve essere un numero intero positivo.

atest test-to-run --iterations
atest test-to-run --iterations 5

I seguenti approcci semplificano il rilevamento dei test instabili:

Approccio 1: esegui tutti i test finché non si verifica un errore o non viene raggiunta l'iterazione massima.

• Interrompi quando si verifica un errore o l'iterazione raggiunge il decimo round (per impostazione predefinita).

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

• Fermati quando si verifica un errore o l'iterazione raggiunge il centesimo round.

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

Approccio 2: esegui solo i test non riusciti finché non vengono superati o viene raggiunta l'iterazione massima.

• Si supponga test-to-run abbia più casi di test e uno dei test abbia esito negativo. Esegui solo il test non riuscito 10 volte (per impostazione predefinita) o finché il test non viene superato.

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

• Interrompi l'esecuzione del test fallito quando passa o raggiunge il centesimo round.

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

Esegui test sugli AVD

Atest è in grado di eseguire test su un AVD appena creato. Esegui acloud create per creare un AVD e creare artefatti, quindi utilizza i seguenti esempi per eseguire i test.

Avvia un AVD ed esegui i test su di esso:

acloud create --local-instance --local-image && atest test-to-run

Avvia un AVD come parte di un'esecuzione di prova:

atest test-to-run --acloud-create "--local-instance --local-image"

Per ulteriori informazioni, esegui acloud create --help .

Passa le opzioni al modulo

Atest è in grado di passare le opzioni ai moduli di test. Per aggiungere le opzioni della riga di comando di TradeFed all'esecuzione del test, utilizza la struttura seguente e assicurati che i tuoi argomenti personalizzati seguano il formato dell'opzione della riga di comando di TradeFed.

atest test-to-run -- [CUSTOM_ARGS]

Passa le opzioni del modulo di test ai preparatori o ai test runner di destinazione definiti nel file di configurazione del test:

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

Passa le opzioni a un tipo o classe di runner:

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

Per ulteriori informazioni sulle opzioni di solo test, vedere passare le opzioni ai moduli .