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 .