Esecuzione di test (Atest), Esecuzione di test (Atest)

Atest è uno strumento da riga di comando che consente agli utenti di creare, installare ed eseguire test Android in locale, accelerando notevolmente le ripetizioni dei test senza richiedere la conoscenza delle opzioni della riga di comando del cablaggio di test di Trade Federation . Questa pagina spiega come utilizzare Atest per eseguire test Android.

Per informazioni generali sulla scrittura di test per Android, vedere Test della piattaforma Android .

Per informazioni sulla struttura generale di Atest, fare riferimento alla Guida per gli sviluppatori di Atest .

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 .

Configurare il tuo ambiente

Segui i passaggi nelle sezioni seguenti per configurare il tuo ambiente Atest.

Imposta la variabile d'ambiente

Imposta test_suite per Soong o LOCAL_COMPATIBILITY_SUITE per Crea seguendo le regole dello script di build Packaging .

Esegui envsetup.sh

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

source build/envsetup.sh

Corri il lunch

Esegui il comando lunch per visualizzare un menu di dispositivi supportati. Trova il dispositivo ed esegui quel comando.

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

lunch aosp_arm64-eng

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

Utilizzo di base

I comandi Atest assumono la forma seguente:

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 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.
<c> --info Mostra le informazioni rilevanti sui target specificati, quindi esce.
<c> --dry-run Atest eseguito a secco senza effettivamente 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.
<c> --iterations Il ciclo esegue i test fino al raggiungimento dell'iterazione massima. (10 per impostazione predefinita)
<c> --rerun-until-failure [COUNT=10] Riesegue tutti i test finché non si verifica un errore o viene raggiunta l'iterazione massima. (10 per impostazione predefinita)
<c> --retry-any-failure [COUNT=10] Riesegue i test non riusciti fino al superamento o al raggiungimento dell'iterazione massima. (10 per impostazione predefinita)
<c> --start-avd Crea automaticamente un AVD ed esegue i test sul dispositivo virtuale.
<c> --acloud-create Crea un AVD utilizzando il comando acloud .
<c> --[CUSTOM_ARGS] Specifica argomenti personalizzati per i corridori del test.
-a --all-abi Esegue i test per tutte le architetture di dispositivi disponibili.
<c> --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.
<c> --flakes-info Mostra il risultato del test con informazioni sui fiocchi.
<c> --history Mostra i risultati del test in ordine cronologico.
<c> --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, specifica 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

Separa i riferimenti a più test con spazi, come questo:

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 come appare nelle variabili LOCAL_MODULE o LOCAL_PACKAGE_NAME nel file Android.mk o Android.bp di quel 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 specificare in modo esplicito 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 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 di test basati su moduli e test di integrazione inserendo il percorso del file o della directory di test in base alle esigenze. Supporta anche l'esecuzione di una singola classe specificando il percorso del file Java della classe. Sono supportati entrambi i percorsi relativi e assoluti.

Esegui 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 usando un percorso di 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 di 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: compilare, installare o eseguire

Utilizzare le opzioni -b , -i e -t per specificare quali passaggi eseguire. Se non specifichi un'opzione, tutti i passaggi vengono eseguiti.

  • Crea solo destinazioni: atest -b test-to-run
  • Esegui solo test: atest -t test-to-run
  • Installa apk ed esegui 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 smontaggio. Molti test, come CTS, ripuliscono il dispositivo dopo l'esecuzione del test, quindi provare a rieseguire il test con -t fallirà senza il parametro --disable-teardown . Utilizzare -d prima di -t per saltare il passaggio 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. Sebbene sia necessario creare l'intero modulo, ciò 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 si specificano più metodi, separarli 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 al solo utilizzo del nome della classe perché specificando 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

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

Esecuzione di più classi

Per eseguire più classi, separale con spazi come per eseguire 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

Esegui i binari di GTest

Atest può eseguire i binari di GTest. Utilizzare -a per eseguire questi test per tutte le architetture di dispositivi disponibili, che in questo esempio sono armeabi-v7a (ARM 32 bit) e arm64-v8a (ARM 64 bit).

Esempio di test di input:

atest -a libinput_tests inputflinger_tests

Per selezionare un binario GTest specifico da eseguire, usa 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 i test in TEST_MAPPING

Atest può eseguire test nei file TEST_MAPPING .

Esegui implicitamente i test di preinvio

Esegui i test di TEST_MAPPING nei file TEST_MAPPING nelle directory correnti e principali:

atest

Esegui i test di TEST_MAPPING nei file TEST_MAPPING in /path/to/project e le sue 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 test post-invio nei file TEST_MAPPING nelle directory correnti e principali:

<pre>
<code class="devsite-terminal">atest :postsubmit</code>
</pre>

Esegui test da tutti i gruppi nei file TEST_MAPPING:

<pre>
<code class="devsite-terminal">atest :all</code>
</pre>

Esegui i test post-invio nei file TEST_MAPPING in /path/to/project e le sue directory principali:

<pre>
<code class="devsite-terminal">atest --test-mapping <var>/path/to/project</var>:postsubmit</code>
</pre>

Esegui i test della linea principale nei file TEST_MAPPING in /path/to/project e le sue directory principali:

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

Esegui 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 principali). Se vuoi eseguire test anche nei file TEST_MAPPING nelle sottodirectory, usa --include-subdirs per forzare Atest a includere anche quei test:

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

Esegui test in iterazione

Esegui i test nell'iterazione passando l'argomento --iterations . Indipendentemente dal fatto che superi 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 traballanti:

Approccio 1: eseguire tutti i test finché non si verifica un errore o 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 fino al superamento o al raggiungimento dell'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 fino al superamento del test.
    atest test-to-run --retry-any-failure
    
  • Interrompi l'esecuzione del test fallito quando supera o raggiunge il centesimo round.
    atest test-to-run --retry-any-failure 100
    

Esegui test su 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 opzioni per testare moduli. Per aggiungere le opzioni della riga di comando di TradeFed alla tua esecuzione di test, utilizza la struttura seguente e assicurati che i tuoi argomenti personalizzati seguano il formato delle opzioni della riga di comando di TradeFed.

atest test-to-run -- [CUSTOM_ARGS]

Supera le opzioni del modulo di test per indirizzare i preparatori o i corridori del 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, vedere Passa le opzioni ai moduli .

,

Atest è uno strumento da riga di comando che consente agli utenti di creare, installare ed eseguire test Android in locale, accelerando notevolmente le ripetizioni dei test senza richiedere la conoscenza delle opzioni della riga di comando del cablaggio di test di Trade Federation . Questa pagina spiega come utilizzare Atest per eseguire test Android.

Per informazioni generali sulla scrittura di test per Android, vedere Test della piattaforma Android .

Per informazioni sulla struttura generale di Atest, fare riferimento alla Guida per gli sviluppatori di Atest .

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 .

Configurare il tuo ambiente

Segui i passaggi nelle sezioni seguenti per configurare il tuo ambiente Atest.

Imposta la variabile d'ambiente

Imposta test_suite per Soong o LOCAL_COMPATIBILITY_SUITE per Crea seguendo le regole dello script di build Packaging .

Esegui envsetup.sh

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

source build/envsetup.sh

Corri il lunch

Esegui il comando lunch per visualizzare un menu di dispositivi supportati. Trova il dispositivo ed esegui quel comando.

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

lunch aosp_arm64-eng

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

Utilizzo di base

I comandi Atest assumono la forma seguente:

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 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.
<c> --info Mostra le informazioni rilevanti sui target specificati, quindi esce.
<c> --dry-run Atest eseguito a secco senza effettivamente 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.
<c> --iterations Il ciclo esegue i test fino al raggiungimento dell'iterazione massima. (10 per impostazione predefinita)
<c> --rerun-until-failure [COUNT=10] Riesegue tutti i test finché non si verifica un errore o viene raggiunta l'iterazione massima. (10 per impostazione predefinita)
<c> --retry-any-failure [COUNT=10] Riesegue i test non riusciti fino al superamento o al raggiungimento dell'iterazione massima. (10 per impostazione predefinita)
<c> --start-avd Crea automaticamente un AVD ed esegue i test sul dispositivo virtuale.
<c> --acloud-create Crea un AVD utilizzando il comando acloud .
<c> --[CUSTOM_ARGS] Specifica argomenti personalizzati per i corridori del test.
-a --all-abi Esegue i test per tutte le architetture di dispositivi disponibili.
<c> --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.
<c> --flakes-info Mostra il risultato del test con informazioni sui fiocchi.
<c> --history Mostra i risultati del test in ordine cronologico.
<c> --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, specifica 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

Separa i riferimenti a più test con spazi, come questo:

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 come appare nelle variabili LOCAL_MODULE o LOCAL_PACKAGE_NAME nel file Android.mk o Android.bp di quel 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 specificare in modo esplicito 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 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 di test basati su moduli e test di integrazione inserendo il percorso del file o della directory di test in base alle esigenze. Supporta anche l'esecuzione di una singola classe specificando il percorso del file Java della classe. Sono supportati entrambi i percorsi relativi e assoluti.

Esegui 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 usando un percorso di 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 di 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: compilare, installare o eseguire

Utilizzare le opzioni -b , -i e -t per specificare quali passaggi eseguire. Se non specifichi un'opzione, tutti i passaggi vengono eseguiti.

  • Crea solo destinazioni: atest -b test-to-run
  • Esegui solo test: atest -t test-to-run
  • Installa apk ed esegui 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 smontaggio. Molti test, come CTS, ripuliscono il dispositivo dopo l'esecuzione del test, quindi provare a rieseguire il test con -t fallirà senza il parametro --disable-teardown . Utilizzare -d prima di -t per saltare il passaggio 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. Sebbene sia necessario creare l'intero modulo, ciò 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 si specificano più metodi, separarli 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 al solo utilizzo del nome della classe perché specificando 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

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

Esecuzione di più classi

Per eseguire più classi, separale con spazi come per eseguire 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

Esegui i binari di GTest

Atest può eseguire i binari di GTest. Utilizzare -a per eseguire questi test per tutte le architetture di dispositivi disponibili, che in questo esempio sono armeabi-v7a (ARM 32 bit) e arm64-v8a (ARM 64 bit).

Esempio di test di input:

atest -a libinput_tests inputflinger_tests

Per selezionare un binario GTest specifico da eseguire, usa 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 i test in TEST_MAPPING

Atest può eseguire test nei file TEST_MAPPING .

Esegui implicitamente i test di preinvio

Esegui i test di TEST_MAPPING nei file TEST_MAPPING nelle directory correnti e principali:

atest

Esegui i test di TEST_MAPPING nei file TEST_MAPPING in /path/to/project e le sue 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 test post-invio nei file TEST_MAPPING nelle directory correnti e principali:

<pre>
<code class="devsite-terminal">atest :postsubmit</code>
</pre>

Esegui test da tutti i gruppi nei file TEST_MAPPING:

<pre>
<code class="devsite-terminal">atest :all</code>
</pre>

Esegui i test post-invio nei file TEST_MAPPING in /path/to/project e le sue directory principali:

<pre>
<code class="devsite-terminal">atest --test-mapping <var>/path/to/project</var>:postsubmit</code>
</pre>

Esegui i test della linea principale nei file TEST_MAPPING in /path/to/project e le sue directory principali:

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

Esegui 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 principali). Se vuoi eseguire test anche nei file TEST_MAPPING nelle sottodirectory, usa --include-subdirs per forzare Atest a includere anche quei test:

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

Esegui test in iterazione

Esegui i test nell'iterazione passando l'argomento --iterations . Indipendentemente dal fatto che superi 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 traballanti:

Approccio 1: eseguire tutti i test finché non si verifica un errore o 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 fino al superamento o al raggiungimento dell'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 fino al superamento del test.
    atest test-to-run --retry-any-failure
    
  • Interrompi l'esecuzione del test fallito quando supera o raggiunge il centesimo round.
    atest test-to-run --retry-any-failure 100
    

Esegui test su 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 opzioni per testare moduli. Per aggiungere le opzioni della riga di comando di TradeFed alla tua esecuzione di test, utilizza la struttura seguente e assicurati che i tuoi argomenti personalizzati seguano il formato delle opzioni della riga di comando di TradeFed.

atest test-to-run -- [CUSTOM_ARGS]

Supera le opzioni del modulo di test per indirizzare i preparatori o i corridori del 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, vedere Passa le opzioni ai moduli .