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 di Trade Federation test harness. Questa pagina spiega come utilizzare Atest per eseguire test Android.
Per informazioni generali sulla scrittura di test per Android, vedi Test della piattaforma Android.
Per informazioni sulla struttura generale di Atest, consulta la Guida per gli sviluppatori di Atest.
Per informazioni sull'esecuzione dei test nei file TEST_MAPPING tramite Atest, vedi Esecuzione dei test nei file TEST_MAPPING.
Per aggiungere una funzionalità ad Atest, segui il flusso di lavoro per sviluppatori di Atest.
Configura l'ambiente
Per configurare l'ambiente Atest, segui le istruzioni riportate in Configurazione dell'ambiente, Scelta di una destinazione e Compilazione del codice.
Utilizzo di base
I comandi atest hanno il seguente formato:
atest test-to-run [optional-arguments]
Argomenti facoltativi
La tabella seguente elenca gli argomenti più utilizzati. Un elenco completo è
disponibile tramite atest --help
.
Opzione | Opzione lunga | Descrizione |
---|---|---|
-b |
--build |
Crea target 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 solo dispositivo alla volta. |
-d |
--disable-teardown |
Disattiva l'eliminazione e la pulizia dei test. |
|
--dry-run |
Esegue Atest in modalità di prova senza eseguire la build, l'installazione o l'esecuzione dei test. |
-m |
--rebuild-module-info |
Forza la ricompilazione del file module-info.json . |
-w |
--wait-for-debugger |
Attende il completamento del debugger prima dell'esecuzione. |
-v |
--verbose |
Visualizza la registrazione a livello DEBUG. |
|
--iterations |
Esegue i test in loop fino a raggiungere il numero massimo di iterazioni. (10 per impostazione predefinita) |
|
--rerun-until-failure [COUNT=10] |
Esegue nuovamente tutti i test finché non si verifica un errore o non viene raggiunto il numero massimo di iterazioni. (10 per impostazione predefinita) |
|
--retry-any-failure [COUNT=10] |
Esegue nuovamente i test non riusciti fino a quando non vengono superati o non viene raggiunto il numero massimo di iterazioni. (10 per impostazione predefinita) |
|
--start-avd |
Crea automaticamente un AVD ed esegue 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 dei 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
non andrà a buon fine. |
|
--history |
Mostra i risultati del test in ordine cronologico. |
|
--latest-result |
Stampa l'ultimo risultato del test. |
Per saperne di più su -b
, -i
e -t
, consulta la sezione
Specificare i passaggi: build, installazione o esecuzione.
Specificare i test
Per eseguire i test, specifica uno o più test utilizzando uno dei seguenti identificatori:
- Nome modulo
- Modulo:Class
- Nome del corso
- Test di integrazione Tradefed
- Percorso del file
- Nome pacchetto
Separa i riferimenti a più test con degli spazi, in questo modo:
atest test-identifier-1 test-identifier-2
Nome modulo
Per eseguire un intero modulo di test, utilizza 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:Class
Per eseguire una singola classe all'interno di un modulo, utilizza Modulo:Classe. Modulo è lo stesso descritto in Nome modulo. Class è il nome della
classe di test nel file .java
e può essere il nome di classe completo o il
nome di base.
Esempi:
atest CtsVideoTestCases:VideoEncoderDecoderTest
atest FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
Nome del corso
Per eseguire una singola classe senza specificare esplicitamente un nome di modulo, utilizza 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 come appare nell'output del comando tradefed.sh list configs
. Per
esempio:
Per eseguire il
reboot.xml
test:
atest example/reboot
Per eseguire il
native-benchmark.xml
test:
atest native-benchmark
Percorso del file
Atest supporta l'esecuzione di test basati su moduli e test basati sull'integrazione inserendo il percorso del file o della directory di test, a seconda dei casi. Supporta anche l'esecuzione di una singola classe specificando il percorso del file Java della classe. Sono supportati sia i percorsi relativi che quelli assoluti.
Eseguire un modulo
Gli esempi seguenti mostrano due modi per eseguire il modulo CtsVideoTestCases
utilizzando
un percorso file.
Esegui da Android repo-root
:
atest cts/tests/video
Esegui da Android repo-root/cts/tests/video
:
atest .
Eseguire una classe di test
L'esempio seguente mostra come eseguire una classe specifica all'interno del modulo CtsVideoTestCases
utilizzando un percorso file.
Da Android repo-root
:
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
da Android repo-root
:
atest tools/tradefederation/contrib/res/config/example/reboot.xml
Nome pacchetto
Atest supporta la ricerca di test per nome del pacchetto.
Esempi:
atest com.android.server.wm
atest com.android.uibench.janktests
Specifica i passaggi: build, installazione o esecuzione
Utilizza le opzioni -b
, -i
e -t
per specificare i passaggi da eseguire. Se non specifichi un'opzione, vengono eseguiti tutti i passaggi.
- Solo target di build:
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
- Crea ed esegui, ma non installare:
atest -bt test-to-run
Atest può forzare un test a saltare il passaggio di pulizia o smontaggio. Molti test, come
CTS, puliscono il dispositivo dopo l'esecuzione del test, quindi il tentativo di eseguire nuovamente il test
con -t
non riuscirà senza il parametro --disable-teardown
. Utilizza -d
prima di
-t
per saltare il passaggio di pulizia del test ed eseguire test iterativi.
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 creare l'intero modulo, 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 del file e così via) e aggiungi il nome del metodo:
atest reference-to-class#method1
Quando specifichi più metodi, separali con le 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 preferibili all'utilizzo del solo nome della classe
perché la specifica del modulo o della posizione del file Java consente ad Atest di trovare il
test molto più rapidamente.
Utilizzo di Module:Class:
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange
Da Android repo-root:
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
Eseguire più classi
Per eseguire più classi, separale con degli spazi nello stesso modo in cui si esegue più test. Atest compila 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
Esegui i file binari GTest
Atest può eseguire i file 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).
Test di input di esempio:
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 il cancelletto (#) per specificare ulteriormente un singolo metodo.
Ad esempio, per la seguente definizione di test:
TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)
Esegui il comando seguente per specificare l'intero test:
atest inputflinger_tests:InputDispatcherTest
In alternativa, esegui un test individuale utilizzando il seguente comando:
atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents
Esegui test in TEST_MAPPING
Atest può eseguire test nei file TEST_MAPPING
.
Eseguire implicitamente i test pre-invio
Esegui i test di pre-invio nei file TEST_MAPPING
nelle directory corrente e principale:
atest
Esegui i test di preinvio nei file TEST_MAPPING
in /path/to/project e
nelle relative directory principali:
atest --test-mapping /path/to/project
Eseguire un gruppo di test specifico
I gruppi di test disponibili sono: presubmit
(impostazione predefinita), postsubmit
,
mainline-presubmit
e all
.
Esegui test post-invio nei file TEST_MAPPING nelle directory corrente e principale:
atest :postsubmit
Esegui i test di 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 mainline nei file TEST_MAPPING in /path/to/project e nelle relative directory principali:
atest --test-mapping /path/to/project:mainline-presubmit
Eseguire 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 relative directory principali). Se vuoi anche
eseguire test nei file TEST_MAPPING nelle sottodirectory, utilizza --include-subdirs
per forzare Atest a includere anche questi test:
atest --include-subdirs /path/to/project
Eseguire test in iterazione
Esegui i test in iterazione passando l'argomento --iterations
. Che superi
o meno il test, Atest lo ripeterà fino a raggiungere il numero massimo di iterazioni.
Esempi:
Per impostazione predefinita, Atest esegue 10 iterazioni. 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 irregolari:
Approccio 1: esegui tutti i test finché non si verifica un errore o non viene raggiunto il numero massimo di iterazioni.
- L'iterazione si interrompe quando si verifica un errore o raggiunge il decimo round (per impostazione predefinita).
atest test-to-run --rerun-until-failure
- Interrompi quando si verifica un errore o l'iterazione raggiunge il 100° round.
atest test-to-run --rerun-until-failure 100
Approccio 2: esegui solo i test non riusciti finché non vengono superati o non viene raggiunto il numero massimo di iterazioni.
- Supponiamo che
test-to-run
abbia più scenari di test e che uno dei test non riesca. Esegui solo il test non riuscito 10 volte (per impostazione predefinita) o finché non viene superato.atest test-to-run --retry-any-failure
- Interrompi l'esecuzione del test non riuscito quando viene superato o raggiunge il 100° 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:
acloud create --local-instance --local-image && atest test-to-run
Avvia un AVD nell'ambito di un test:
atest test-to-run --acloud-create "--local-instance --local-image"
Per ulteriori informazioni, esegui acloud create --help
.
Passare opzioni al modulo
Atest è in grado di passare opzioni ai moduli di test. Per aggiungere opzioni della riga di comando di TradeFed all'esecuzione del test, utilizza la seguente struttura e assicurati che gli argomenti personalizzati seguano il formato dell'opzione della riga di comando di Tradefed.
atest test-to-run -- [CUSTOM_ARGS]
Trasferisci le opzioni del modulo di test ai preparatori di test o ai runner di 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
Passa le opzioni a un tipo di runner o a una classe:
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 saperne di più sulle opzioni di solo test, vedi Passare opzioni ai moduli.