Atest è uno strumento da riga di comando che consente agli utenti di creare, installare ed eseguire test Android localmente, accelerando notevolmente le ripetizioni dei test senza richiedere la conoscenza delle opzioni della riga di comando del cablaggio di test della Trade Federation . Questa pagina spiega come utilizzare Atest per eseguire test Android.
Per informazioni generali sulla scrittura dei test per Android, consulta Test della piattaforma Android .
Per informazioni sulla struttura complessiva di Atest, fare riferimento alla Atest Developer Guide .
Per informazioni sull'esecuzione dei test nei file TEST_MAPPING tramite Atest, vedere Esecuzione dei test nei file TEST_MAPPING .
Per aggiungere una funzionalità ad Atest, seguire il flusso di lavoro per sviluppatori Atest .
Configura il tuo ambiente
Per configurare l'ambiente Atest, seguire le istruzioni in Configurazione dell'ambiente , Scelta di una destinazione e Creazione del codice .
Utilizzo di base
I comandi Atest assumono la forma seguente:
atest test-to-run [optional-arguments]
Argomenti facoltativi
Nella tabella seguente sono elencati gli argomenti utilizzati più comunemente. Un elenco completo è disponibile tramite atest --help
.
Opzione | Opzione lunga | Descrizione |
---|---|---|
-b | --build | Costruisce obiettivi di test. (predefinito) |
-i | --install | Installa gli 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. |
| --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 del livello DEBUG. |
| --iterations | Esegue i test in loop fino al raggiungimento dell'iterazione massima. (10 per impostazione predefinita) |
| --rerun-until-failure [COUNT=10] | Esegue nuovamente tutti i test finché non si verifica un errore o viene raggiunta l'iterazione massima. (10 per impostazione predefinita) |
| --retry-any-failure [COUNT=10] | Esegue nuovamente i test non riusciti 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 dispositivo. Nota: l'esecuzione di un test dell'host che richiede un dispositivo con --host non riuscirà. |
| --history | Mostra i risultati dei 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
Riferimenti separati 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, utilizzare il nome del modulo. Inserisci il nome così 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 . Classe è il nome della classe di prova 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 del modulo, utilizzare il nome della classe.
Esempi:
atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest
Test di integrazione Tradefed
Per eseguire test integrati direttamente in TradeFed (non moduli), inserisci 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 file o della directory di test, a seconda dei casi. Supporta inoltre l'esecuzione di una singola classe specificando il percorso del file Java della classe. Sono supportati sia i percorsi relativi che quelli assoluti.
Esegui un modulo
Gli esempi seguenti mostrano due modi per eseguire il modulo CtsVideoTestCases
utilizzando un percorso file.
Esegui dal 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 file.
Dal repo-root
Android:
atest cts/tests/video/src/android/video/cts/VideoEncoderDecoderTest.java
Esegui un test di integrazione
L'esempio seguente mostra come eseguire un test di integrazione utilizzando un percorso file dal repo-root
Android:
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
Specifica i passaggi: creazione, installazione o esecuzione
Utilizzare le opzioni -b
, -i
e -t
per specificare quali passaggi eseguire. Se non specifichi un'opzione, verranno eseguiti tutti i passaggi.
- Compila solo destinazioni:
atest -b test-to-run
- Esegui solo test:
atest -t test-to-run
- Installa l'apk ed esegui i test:
atest -it test-to-run
- Compila ed esegui, ma non installa:
atest -bt test-to-run
Atest può forzare un test a saltare la fase di pulizia o smontaggio. Molti test, come CTS, ripuliscono il dispositivo dopo l'esecuzione del test, quindi provare a eseguire nuovamente il test con -t
fallirà senza il parametro --disable-teardown
. Utilizzare -d
prima di -t
per saltare il passaggio di pulizia del test ed eseguire il test in modo iterativo.
atest -d test-to-run
atest -t test-to-run
Esegui metodi specifici
Atest supporta l'esecuzione di metodi specifici all'interno di una classe di test. Sebbene sia necessario costruire l'intero modulo, ciò riduce il tempo necessario per eseguire i test. Per eseguire metodi specifici, identificare la classe utilizzando uno dei modi supportati per identificare una classe (Modulo: Classe, percorso file, ecc.) e aggiungere 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 rispetto all'utilizzo 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 del Modulo:Classe:
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange
Dal repo-root Android:
atest frameworks/base/services/tests/wmtests/src/com/android/server/wm/ScreenDecorWindowTests.java#testFlagChange
È possibile eseguire più metodi da classi e moduli diversi:
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors
Esegui più lezioni
Per eseguire più classi, separarle con spazi nello stesso modo in cui si eseguono 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 lezioni in moduli diversi:
atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest
Esegui i binari GTest
Atest può eseguire i binari Gtest. Utilizza -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, utilizza 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
Esegui test in TEST_MAPPING
Atest può eseguire test nei file TEST_MAPPING
.
Esegui test di preinvio in modo implicito
Esegui test di preinvio nei file TEST_MAPPING
nelle directory corrente e principale:
atest
Esegui test di preinvio nei file TEST_MAPPING
in /path/to/project e nelle sue directory principali:
atest --test-mapping /path/to/project
Esegui un gruppo di test specificato
I gruppi di test disponibili sono: presubmit
(predefinito), postsubmit
, mainline-presubmit
e all
.
Esegui test post-invio nei file TEST_MAPPING nelle directory correnti e principali:
atest :postsubmit
Esegui test da tutti i gruppi nei file TEST_MAPPING:
atest :all
Esegui test post-invio nei file TEST_MAPPING in /path/to/project e nelle sue directory principali:
atest --test-mapping /path/to/project:postsubmit
Esegui test della linea principale nei file TEST_MAPPING in /path/to/project e nelle sue directory principali:
atest --test-mapping /path/to/project:mainline-presubmit
Esegui test nelle sottodirectory
Per impostazione predefinita, Atest cerca solo i test nei file TEST_MAPPING verso l'alto (dalla directory corrente o da quella specificata alle directory principali). Se vuoi eseguire test anche nei file TEST_MAPPING nelle sottodirectory, usa --include-subdirs
per forzare Atest a includere anche questi test:
atest --include-subdirs /path/to/project
Esegui test in iterazione
Esegui i test in iterazione passando l'argomento --iterations
. Sia che venga superato o meno, Atest ripeterà il test fino al raggiungimento dell'iterazione massima.
Esempi:
Per impostazione predefinita, Atest esegue l'iterazione 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: eseguire tutti i test finché non si verifica un errore o viene raggiunta l'iterazione massima.
- Interrompe quando si verifica un errore o l'iterazione raggiunge il 10° round (per impostazione predefinita).
atest test-to-run --rerun-until-failure
- Interrompere quando si verifica un errore o l'iterazione raggiunge il centesimo round.
atest test-to-run --rerun-until-failure 100
Approccio 2: eseguire solo i test falliti finché non vengono superati o viene raggiunta l'iterazione massima.
- Supponiamo
test-to-run
abbia più casi di test e che uno dei test fallisca. Esegui solo il test fallito 10 volte (per impostazione predefinita) o finché il test non viene superato.atest test-to-run --retry-any-failure
- Interrompere l'esecuzione del test fallito quando supera 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 gli esempi seguenti per eseguire i test.
Avvia un AVD ed esegui i test su di esso:
acloud create --local-instance --local-image && atest test-to-run
Avviare 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 opzioni per testare i moduli. Per aggiungere le opzioni della riga di comando TradeFed all'esecuzione del test, utilizza la struttura seguente e assicurati che gli argomenti personalizzati seguano il formato delle opzioni della riga di comando Tradefed.
atest test-to-run -- [CUSTOM_ARGS]
Passa le opzioni del modulo di test ai preparatori o ai partecipanti al test 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
Opzioni di passaggio a un tipo o classe di corridore:
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, consulta Passare opzioni ai moduli .