Configurazione di prova complessa

Alcuni moduli di test potrebbero richiedere passaggi di installazione e smontaggio personalizzati che non possono essere eseguiti all'interno del test case stesso. Esempi tipici possono includere:

  • installa altri apk (oltre all'apk di prova)
  • inviare alcuni file al dispositivo
  • esegui comandi (es. adb shell pm ...)

In passato, i team dei componenti di solito ricorrevano alla scrittura di un test lato host per eseguire tali attività, il che richiede la comprensione del cablaggio di Trade Federation e in genere aumenta la complessità di un modulo di test.

Prendendo in prestito da CTS, abbiamo introdotto il concetto di configurazione del modulo di test per supportare tali attività, l'elenco delle attività comuni sopra può essere ottenuto con poche righe di configurazione. Per la massima flessibilità, è possibile anche implementare il proprio preparatore di destinazione, come definito dal ITargetPreparer o ITargetCleaner , e configurarli in modo da utilizzare nel proprio modulo di test di configurazione.

Una configurazione del modulo di test per un modulo di test è un file XML richiesto aggiunto alla cartella di origine del modulo di livello superiore, denominato "AndroidTest.xml". L'XML segue il formato di un file di configurazione utilizzato dal cablaggio di automazione dei test di Trade Federation. Attualmente i tag principali gestiti tramite le configurazioni del modulo di test sono i tag "target_preparer" e "test".

Preparatori target

Un tag “target_preparer”, come suggerisce il nome, definisce un preparatore bersaglio (vedi ITargetPreparer ) che offre un metodo di impostazione, che viene chiamato prima modulo di test viene eseguito per testare; e se la classe si fa riferimento nel tag “target_preparer” implementa anche ITargetCleaner , il suo metodo teardown verrà richiamato dopo che il modulo di test è terminato.

Per utilizzare la configurazione del modulo comune integrata, aggiungi un nuovo file "AndroidTest.xml" nella cartella di livello superiore per il tuo modulo di test e popolalo con il seguente contenuto:

<?xml version="1.0" encoding="utf-8"?>
<!-- [insert standard AOSP copyright here] -->
<configuration description="Test module config for Foo">
<!-- insert options here -->
</configuration>

Ad esempio, possiamo aggiungere i seguenti tag di opzione (al commento "inserisci" sopra):

    <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
        <option name="run-command" value="settings put secure accessibility_enabled 1" />
        <option name="teardown-command" value="settings put secure accessibility_enabled 0" />
    </target_preparer>

Le opzioni configureranno il test harness per:

  1. prima che venga richiamato il modulo di test, eseguire il comando shell "settings put secure accessability_enabled 1" sul dispositivo
  2. dopo che il modulo di test è terminato, esegui il comando shell "settings put secure access_enabled 0"

In questo particolare esempio, l'accessibilità è abilitata/disabilitata rispettivamente prima/dopo l'esecuzione del modulo di test. Con un semplice esempio dimostrato, è necessario fornire maggiori dettagli su come viene utilizzato il tag "opzione". Come mostrato sopra, il tag può avere due attributi: nome, valore. L'attributo name indica il nome dell'opzione ed è ulteriormente suddiviso in due parti separate da due punti: nome breve per il preparatore e il nome effettivo dell'opzione offerto dal preparatore.

Lo scopo esatto del campo del valore dipende da come il preparatore ha definito l'opzione: può essere una stringa, un numero, un booleano o anche un percorso di file, ecc. Nell'esempio sopra, il nome "esegui-comando:esegui-comando" significa che stiamo impostando un valore per l'opzione "run-command" definita da un preparatore di destinazione con il nome breve "run-command"; e il nome "run-command:teardown-command" significa che stiamo impostando il valore per l'opzione "teardown-command" definita anche dallo stesso preparatore di destinazione con il nome breve "run-command". Ecco un riepilogo dei tre comuni preparatori di target:

  • nome della classe: PushFilePreparer

    • Nome breve: push-lima
    • Funzione: spinge file arbitrari sotto cartella in caso di test di destinazione sul dispositivo
    • note:
      • questo preparatore può eseguire il push da cartella a cartella o da file a file; cioè, non è possibile inserire un file in una cartella sul dispositivo: è necessario specificare anche il nome del file di destinazione in quella cartella
    • opzioni:
      • push: Una spinta-spec, formattati come ' /path/to/srcfile.txt->/path/to/destfile.txt ' o ' /path/to/srcfile.txt->/path/to/destdir/ '. Può essere ripetuto Questo percorso può essere relativo alla directory del modulo di test o alla stessa directory out.
      • ** post-push: il comando ** A per eseguire sul dispositivo (con ` adb shell <your command> `) dopo che tutte le spinte sono state tentate. Il caso d'uso tipico sarebbe usare chmod per i permessi
  • nome della classe: InstallApkSetup

    • nome breve: install-apk
    • Funzione: spinge i file apk arbitrari sotto nella destinazione sul dispositivo
    • opzioni:
      • test-file-name: il nome del apk per essere installato sopra al dispositivo.
      • install-arg: Argomenti aggiuntivi da passare al pm installazione di comando, anche delle più importanti trattino, ad esempio, “-d" può essere ripetuto.
  • nome della classe: RunCommandTargetPreparer

    • Nome breve: comando eseguito
    • funzione: esegue arbitrario comandi shell prima o dopo l'esecuzione modulo di test
    • opzioni:
      • run-comando: comando adb shell per eseguire. Può essere ripetuto
      • teardown-comando: comando adb shell per eseguire durante teardown fase. Può essere ripetuto

Classe di prova

Una classe di test è la classe della Federazione dei Mercanti da utilizzare per eseguire il test.

<test class="com.android.tradefed.testtype.AndroidJUnitTest">
  <option name="package" value="android.test.example.helloworld"/>
  <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>

Ecco tre classi di test comuni:

  • nome della classe: GTEST

    • nome breve: GTEST
    • Funzione: una prova che esegue un pacchetto di test nativo su dato dispositivo.
    • opzioni:
      • native-test-percorso-dispositivo: il percorso sul dispositivo in cui si trovano prove nativi.
  • nome della classe: InstrumentationTest

    • nome breve: strumentazione
    • Funzione: una prova che esegue un pacchetto di test di strumentazione dato dispositivo
    • opzioni:
      • Pacchetto: Il manifesto nome del pacchetto dell'applicazione di prova per l'esecuzione di Android.
      • classe: Il nome della classe di prova per l'esecuzione.
      • Metodo: Il nome del metodo di prova per l'esecuzione.
  • nome della classe: AndroidJUnitTest

    • Funzione: una prova che esegue un pacchetto di test di strumentazione dato dispositivo utilizzando l'android.support.test.runner.AndroidJUnitRunner Questo è il modo principale per eseguire un test di strumentazione.