Un test

Atest è uno strumento a riga di comando che consente agli utenti di costruire, installare ed eseguire test di Android a livello locale, accelerando notevolmente prova repliche senza richiedere la conoscenza della Federazione dei Mercanti di test harness opzioni della riga di comando. Questa pagina spiega come utilizzare Atest per eseguire test Android.

Per informazioni di carattere generale sulla scrittura dei test per Android, vedi Android piattaforma di test .

Per informazioni sulla struttura complessiva del Atest, vedere Atest Guida per gli sviluppatori .

Per informazioni sull'esecuzione di test nei file TEST_MAPPING attraverso Atest, vedi i test Esecuzione in file TEST_MAPPING .

E per aggiungere una funzionalità per Atest, seguire Atest Developer Workflow .

Configura il tuo ambiente

Per eseguire Atest, segui i passaggi nelle sezioni seguenti per configurare il tuo ambiente.

Imposta variabile d'ambiente

Set test_suite per Soong o LOCAL_COMPATIBILITY_SUITE per Make per imballaggio regole script di build .

Esegui envsetup.sh

Dalla radice del checkout del codice sorgente di Android, esegui:

source build/envsetup.sh

Pranzo di corsa

Eseguire il lunch di comando per aprire un menu di dispositivi supportati. Trova il dispositivo ed esegui quel comando.

Ad esempio, se hai un dispositivo ARM connesso, esegui il seguente comando:

lunch aosp_arm64-eng

Questo imposta diverse variabili di ambiente richieste per l'esecuzione Atest e aggiunge il comando Atest al vostro $PATH .

Utilizzo di base

I comandi di Atest assumono la seguente forma:

atest test-to-run [optional-arguments]

Argomenti opzionali

Di seguito sono riportati gli argomenti più comunemente utilizzati. L'elenco completo è disponibile attraverso 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 il test di smontaggio e pulizia.
	--info	Mostra le informazioni rilevanti delle destinazioni e delle uscite specificate.
	--dry-run	Test di funzionamento a secco senza creare, installare ed eseguire test in realtà
-m	--rebuild-module-info	Forze una ricostruzione del module-info.json file.
-w	--wait-for-debugger	Attende il debugger prima dell'esecuzione. Solo per prove di strumentazione.
-v	--verbose	Visualizza la registrazione del livello di 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 fino a quando non si verifica un errore o non viene raggiunta l'iterazione massima. (10 per impostazione predefinita)
	--retry-any-failure [COUNT=10]	Riesegue i test non riusciti finché non vengono superati o non 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 AVDS utilizzando il acloud command.
	--[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 di host che richiede un dispositivo con --host avrà esito negativo.)
	--flakes-info	Mostra il risultato del test con informazioni sui fiocchi.
	--history	Mostra il risultato del test in ordine cronologico.
	--latest-result	Stampa l'ultimo risultato del test.

Per ulteriori informazioni su -b , -i e -t , vedere Specifica di passi: costruire, installare, o correre.

Test da eseguire

È possibile eseguire uno o più test utilizzando test-to-run . Per eseguire più test, separare i riferimenti ai test con spazi. Per esempio:

atest test-to-run-1 test-to-run-2

Ecco alcuni esempi:

atest FrameworksServicesTests
atest example/reboot
atest FrameworksServicesTests CtsVideoTestCases
atest FrameworksServicesTests:ScreenDecorWindowTests

Per ulteriori informazioni su come fare riferimento a una prova, vedere Identificare i test.

Test di identificazione

È possibile specificare il test-to-run discussione con il nome del test del modulo, Modulo: Classe, nome della classe, test di integrazione di TF, il percorso del file o il nome del pacchetto.

Nome del modulo

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

Esempi:

atest FrameworksServicesTests
atest CtsVideoTestCases

Modulo: Classe

Per eseguire una singola classe all'interno di un modulo, utilizzare il modulo: Classe. Modulo è la stessa descritta in nome del modulo . Class è il nome della classe di test nel .java file e può essere il nome completo della classe o il nome di base.

Esempi:

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

Nome della classe

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

Esempi:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Uso del modulo: di riferimento di classe è consigliata quando possibile, in quanto Atest richiede più tempo per cercare l'albero sorgente completo di possibili corrispondenze se nessun modulo è dichiarato.

Esempi (ordinati dal più veloce al più lento):

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

Test di integrazione TF

Per eseguire i test che sono integrati direttamente nei TradeFed (non moduli), ingresso il nome come appare nell'output della tradefed.sh list configs comando. Per esempio:

Per eseguire il reboot.xml di prova :

atest example/reboot

Per eseguire il native-benchmark.xml di prova :

atest native-benchmark

Percorso del file

È possibile eseguire sia test basati su moduli che test basati sull'integrazione immettendo il percorso del file o della directory di test in modo appropriato. Puoi anche eseguire una singola classe specificando il percorso del file Java della classe. Sono supportati sia percorsi relativi che assoluti.

Esempio: due modi per eseguire il CtsVideoTestCases modulo tramite percorso

1. Modulo di corsa da Android repo-root :

   atest cts/tests/video
   

2. Da Android repo-root / cts / test / video:

   atest .
   

Esempio: Eseguire una classe specifica all'interno CtsVideoTestCases modulo tramite percorso. Da Android repo-root :

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

Esempio: eseguire un test di integrazione tramite percorso. Da Android repo-root :

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

Nome del pacchetto

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

Esempi:

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

Specificazione dei passaggi: compilazione, installazione o esecuzione

È possibile specificare quali passi da eseguire utilizzando il -b , -i , e -t opzioni. Se non si specifica un'opzione, vengono eseguiti tutti i passaggi.

• Obiettivi costruire solo: atest -b test-to-run
• Eseguire i test solo: atest -t test-to-run
• Installare apk ed eseguire test: atest -it test-to-run
• Costruire e gestire, ma non installare: atest -bt test-to-run

Atest può forzare un test a saltare la fase di pulizia/smontaggio. Molti test, come CTS, pulito il dispositivo dopo il test viene eseguito, quindi cercando di eseguire nuovamente il test con -t non riuscirà senza il --disable-teardown parametro. Utilizzare -d prima -t per saltare il passo fino pulito prova e prova in modo iterativo.

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

Esecuzione di metodi specifici

È possibile eseguire metodi specifici all'interno di una classe di test. Sebbene l'intero modulo debba essere costruito, questo 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

Puoi specificare più metodi con le virgole.

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

Esempi:

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

I seguenti esempi mostrano due modi preferiti per eseguire un unico metodo, testFlagChange . Questi esempi sono preferiti rispetto 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ù velocemente:

1. Utilizzo del modulo:Classe

   atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange
   

2. 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

Gestire più classi

Per eseguire più classi, separale con spazi allo stesso modo dell'esecuzione di più test. Atest costruisce 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.

Esempi:

• Due classi nello stesso modulo:

  atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests
  

• Due classi in diversi moduli:

  atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest
  

Esecuzione di test nativi

Atest può eseguire test nativi. Usare -a per eseguire i test per tutte le architetture dispositivi disponibili, che in questo esempio sono armeabi-V7A (ARM a 32 bit) e arm64-V8A (ARM 64-bit).

Esempi:

• Test di ingresso:

  atest -a libinput_tests inputflinger_tests
  

Per selezionare uno specifico test nativo da eseguire, utilizzare i due punti (:) per specificare il nome del test e l'hashtag (#) per specificare ulteriormente un metodo individuale. Ad esempio, per la seguente definizione di prova:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

È possibile eseguire l'intera prova utilizzando

atest inputflinger_tests:InputDispatcherTest

o un metodo individuale utilizzando

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Esecuzione di test in TEST_MAPPING

Atest può eseguire test nei file TEST_MAPPING.

1. Esegui test di pre-invio implicitamente nei file TEST_MAPPING nelle directory correnti, padre o specifiche.

   Test presubmit eseguito in file TEST_MAPPING nelle directory corrente e genitori:

   atest
   

   Test presubmit eseguito in file TEST_MAPPING in /path/to/project e le sue directory principali:

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

2. Eseguire un gruppo di test specificato nel file TEST_MAPPING; gruppi di test disponibili sono: presubmit (default), postsubmit , mainline-presubmit e all .

   • Test postsubmit eseguito in file TEST_MAPPING nelle directory corrente e genitori:

     atest :postsubmit
     

   • Eseguire i test di tutti i gruppi di file TEST_MAPPING:

     atest :all
     

   • Test postsubmit eseguito in file TEST_MAPPING in /path/to/project e le sue directory principali

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

   • Eseguire i test mainline in file TEST_MAPPING in /path/to/project e le sue directory principali

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

3. Esegui test nei file TEST_MAPPING incluse le sottodirectory.

Per impostazione predefinita, atest cerca solo i test nei file TEST_MAPPING verso l'alto (dalla directory corrente o data alle sue directory padre). Se anche voi volete eseguire test nei file TEST_MAPPING nelle sub-directory, è possibile utilizzare l'opzione --include-subdirs per forzare atest per includere tali test pure.

Test presubmit eseguito in file TEST_MAPPING nella corrente, genitore e sottodirectory:

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

Esecuzione di test in iterazione

Per eseguire test in iterazione, semplicemente passare il --iterations argomento. Indipendentemente dal fatto che venga superato o meno, atest non interromperà il test fino al raggiungimento dell'iterazione massima.

Esempi:

Per impostazione predefinita, atest itera 10 volte, fornendo un numero intero per modificare il ciclo di iterazione.

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

Due approcci che aiutano gli utenti a rilevare i test traballanti:

Approccio 1: eseguire tutti i test fino a quando 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
  

• Interrompi 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 non riusciti finché non vengono superati o non viene raggiunta l'iterazione massima.

• Si supponga test-to-run ha cinque casi di test e uno dei test fallisce. Esegui solo il test fallito 10 volte 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 100° round.

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

Esecuzione di test sugli AVD

Atest è in grado di eseguire test con l'AVD appena creato. Atest può costruire artefatti con correndo acloud create , e test eseguito dopo l'intervallo AV è stato creato correttamente.

Esempi:

• Avviare un AVD prima di eseguire test su quel dispositivo appena creato:

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

• Inizia AVDS specifing acloud create argomenti e le prove eseguite su quel dispositivo appena creato.

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

Per ottenere i dettagli sull'uso del l'argomento, eseguire acloud create --help .

Passa le opzioni al modulo

Atest è in grado di passare opzioni ai moduli. Il formato breve, in linea di comando Atest per aggiungere l'opzione da riga di comando TradeFed è

atest test-to-run -- [CUSTOM_ARGS]

I [CUSTOM_ARGS] dovrebbero seguire i formati di linea di comando Tradefed.

Esempi di superamento delle opzioni del modulo di test per indirizzare i preparatori o i test runner 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

Esempi di opzioni di passaggio al tipo o alla 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 prove uniche opzioni, vedere le opzioni pass per i moduli