Atest è uno strumento a riga di comando che consente agli utenti di creare, installare ed eseguire Android esegue i test in locale, velocizzando notevolmente le esecuzioni successive senza richiedere conoscenza della trade Federation testata le opzioni della riga di comando. In questa pagina viene spiegato come utilizzare Atest per eseguire Android test.
Per informazioni generali sulla scrittura dei test per Android, vedi Test della piattaforma Android.
Per informazioni sulla struttura complessiva di Atest, consulta le Guida per gli sviluppatori più recente.
Per informazioni sull'esecuzione di test nei file TEST_MAPPING tramite Atest, vedi Esecuzione di test in file TEST_MAPPING.
Per aggiungere una funzionalità ad Atest, segui il Flusso di lavoro per gli sviluppatori di Atest.
Configura l'ambiente
Per configurare l'ambiente Atest, segui le istruzioni riportate in Configurazione dell'ambiente, Scelta di un target e Compilazione del codice.
Utilizzo di base
I comandi Atest hanno il seguente formato:
atest test-to-run [optional-arguments]
Argomenti facoltativi
Nella tabella seguente sono elencati gli argomenti più utilizzati. L'elenco completo è
disponibile fino al giorno atest --help
.
Opzione | Opzione lunga | Descrizione |
---|---|---|
-b |
--build |
Crea target di test. (predefinita) |
-i |
--install |
Installa gli elementi di test (APK) sul dispositivo. (predefinita) |
-t |
--test |
Esegue i test. (predefinita) |
-s |
--serial |
Esegue i test sul dispositivo specificato. È possibile testare un solo dispositivo alla volta. |
-d |
--disable-teardown |
Disabilita l'eliminazione e la pulizia dei test. |
|
--dry-run |
Esegue prove Atest senza creare, installare o eseguire test. |
-m |
--rebuild-module-info |
Forza la ricostruzione del file module-info.json . |
-w |
--wait-for-debugger |
Attende il completamento del debugger prima dell'esecuzione. |
-v |
--verbose |
Mostra la registrazione a livello di DEBUG. |
|
--iterations |
Il loop esegue i test fino al raggiungimento dell'iterazione massima. (10 per impostazione predefinita) |
|
--rerun-until-failure [COUNT=10] |
Esegue di nuovo tutti i test finché non si verifica un errore o finché non viene raggiunto il numero massimo di iterazioni raggiunto. (10 per impostazione predefinita) |
|
--retry-any-failure [COUNT=10] |
Esegue di nuovo 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 una durata di visualizzazione media utilizzando il comando acloud . |
|
--[CUSTOM_ARGS] |
Specifica gli argomenti personalizzati per i runner del test. |
-a |
--all-abi |
Esegue i test per tutte le architetture dei dispositivi disponibili. |
|
--host |
Esegue il test completamente sull'host senza un dispositivo. Nota: eseguire un test dell'host che richiede un dispositivo con --host
non riuscirà. |
|
--history |
Mostra i risultati del test in ordine cronologico. |
|
--latest-result |
Stampa il risultato dell'ultimo test. |
Per ulteriori informazioni su -b
, -i
e -t
, consulta la sezione
Specifica i passaggi: compila, installa o esegui.
Specifica i test
Per eseguire i test, specifica uno o più test utilizzando uno dei seguenti identificatori:
- Nome modulo
- Modulo:Corso
- Nome corso
- Test di integrazione scambiato
- Percorso del file
- Nome pacchetto
Separa i riferimenti a più test con 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ì com'è visualizzato
nella variabile LOCAL_MODULE
o LOCAL_PACKAGE_NAME
in quel test
Android.mk
o Android.bp
.
Esempi:
atest FrameworksServicesTests
atest CtsVideoTestCases
Modulo:Corso
Per eseguire un singolo corso all'interno di un modulo, utilizza Module:Class. Modulo è uguale a quello descritto in Nome modulo. Class è il nome del
classe di test nel file .java
e può essere il nome completo della classe oppure
il nome di base.
Esempi:
atest CtsVideoTestCases:VideoEncoderDecoderTest
atest FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
Nome corso
Per eseguire una singola classe senza indicare esplicitamente il nome di un modulo, utilizza la classe nome.
Esempi:
atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest
Test di integrazione scambiato
Per eseguire test integrati direttamente in TradeFed (non moduli), inserisci
esattamente come appare nell'output del comando tradefed.sh list configs
. Per
esempio:
Per eseguire
Test reboot.xml
:
atest example/reboot
Per eseguire il
test native-benchmark.xml
:
atest native-benchmark
Percorso del file
Atest supporta l'esecuzione di test basati su moduli e sull'integrazione inserendo il percorso appropriato del file o della directory di test. Inoltre, supporta 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
I seguenti esempi 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 .
Esegui 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: creazione, installazione o esecuzione.
Utilizza le opzioni -b
, -i
e -t
per specificare quali passaggi eseguire. Se non specifichi un'opzione, vengono eseguiti tutti i passaggi.
- Solo target 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 la fase di pulizia o eliminazione. Molti test, come CTS, puliscono il dispositivo dopo l'esecuzione del test, quindi il tentativo di eseguire nuovamente il test con -t
non andrà a buon fine senza il parametro --disable-teardown
. Usa -d
prima
-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 l'intero modulo deve essere creato, in questo modo si riduce il tempo necessario per eseguire i test. Per eseguire metodi specifici, identificare la classe usando uno dei metodi supportati identificando una classe (Module:Class, percorso file ecc.) e aggiungendo il nome del :
atest reference-to-class#method1
Quando specifichi più metodi, separali con una virgola:
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 solo del 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
Esegui più corsi
Per eseguire più classi, separale con spazi nello stesso modo in cui esegui più test. Atest crea ed esegue le classi in modo efficiente, quindi specificando un sottoinsieme di classi di un modulo migliora le prestazioni rispetto all'esecuzione dell'intero in maggior dettaglio più avanti in questo modulo.
Per tenere due corsi nello stesso modulo:
atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests
Per eseguire due classi in moduli diversi:
atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest
Esegui i binari GTest
Atest può eseguire i binari GTest. Usa -a
per eseguire questi test per tutti i test 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 file binario GTest specifico da eseguire, utilizza 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)
Esegui il comando seguente per specificare l'intero test:
atest inputflinger_tests:InputDispatcherTest
In alternativa, esegui un test individuale utilizzando quanto segue:
atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents
Esegui test in TEST_MAPPING
Atest può eseguire test in file TEST_MAPPING
.
Eseguire test pre-invio in modo implicito
Esegui i test di preinvio nei file TEST_MAPPING
nelle directory corrente e principale:
atest
Esegui test pre-invio nei file TEST_MAPPING
in /path/to/project e
tutte le directory principali:
atest --test-mapping /path/to/project
Esegui un gruppo di test specificato
I gruppi di test disponibili sono: presubmit
(valore predefinito), postsubmit
,
mainline-presubmit
e all
.
Esegui test postsubmit in file TEST_MAPPING nelle directory correnti e principali:
atest :postsubmit
Esegui test da tutti i gruppi in file TEST_MAPPING:
atest :all
Esegui test post-invio nei file TEST_MAPPING in /path/to/project e tutte le directory principali:
atest --test-mapping /path/to/project:postsubmit
Esegui i test principali nei file TEST_MAPPING in /path/to/project e nelle sue directory principali:
atest --test-mapping /path/to/project:mainline-presubmit
Esecuzione di test nelle sottodirectory
Per impostazione predefinita, Atest cerca i test solo nei file TEST_MAPPING verso l'alto (dalla directory corrente o da quella specificata alle relative directory principali). Se vuoi anche
per eseguire test 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 un'iterazione passando l'argomento --iterations
. Se passa
o non va a buon fine, Atest ripeterà il test fino a raggiungere l'iterazione massima.
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 inaffidabili:
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 ciclo (per impostazione predefinita).
atest test-to-run --rerun-until-failure
- Interrompi quando si verifica un errore o l'iterazione raggiunge il centesimo round.
atest test-to-run --rerun-until-failure 100
Approccio 2: esegui solo test non riusciti finché non vengono superati o non viene raggiunto il numero massimo di test.
- Supponiamo che
test-to-run
abbia più scenari di test e uno dei la verifica ha esito negativo. Esegui solo il test non riuscito 10 volte (per impostazione predefinita) o fino a quando il test non viene superato.atest test-to-run --retry-any-failure
- Interrompi l'esecuzione del test non riuscito una volta superato o raggiunto il 100° round.
atest test-to-run --retry-any-failure 100
Esegui test su AVD
Atest è in grado di eseguire test su una durata di visualizzazione media appena creata. Esegui acloud create
per creare
una durata di visualizzazione media e gli artefatti della build, quindi utilizza i seguenti esempi per eseguire i test.
Avvia una durata di visualizzazione media ed esegui i test:
acloud create --local-instance --local-image && atest test-to-run
Avvia una durata di visualizzazione media nell'ambito dell'esecuzione di un test:
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 la riga di comando TradeFed per l'esecuzione del test, utilizza la seguente struttura e assicurati che le seguono il formato dell'opzione della riga di comando Tradefed.
atest test-to-run -- [CUSTOM_ARGS]
Superare le opzioni dei moduli di test per raggiungere i preparativi o i runner del test definiti nella file di configurazione di test:
atest test-to-run -- --module-arg module-name:option-name:option-value
atest GtsPermissionTestCases -- --module-arg GtsPermissionTestCases:ignore-business-logic-failure:true
Opzioni per passare 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 ulteriori informazioni sulle opzioni di solo test, vedi Trasmettere le opzioni ai moduli.