Alcuni moduli di test potrebbero richiedere una configurazione personalizzata e passaggi di smontaggio che non da eseguire all'interno dello scenario di test stesso. Ecco alcuni esempi tipici:
- installa altri APK (oltre all'APK di prova)
- esegui il push di alcuni file sul dispositivo
- esegui i comandi (ad es. adb shell pm...)
In passato, i team dei componenti di solito ricorrono a scrivere un test lato host svolgere tali attività, il che richiede la conoscenza dello e in genere aumenta la complessità di un modulo di test .
Prendendo in prestito da CTS, abbiamo introdotto il concetto di configurazione dei moduli di test per supportare per svolgere queste attività, l'elenco delle attività comuni sopra riportato può essere eseguito con . Per la massima flessibilità, puoi anche implementare il tuo target preparatorio, come definito da ITargetPreparer o ITargetCleaner, e configurarle per l'uso nella configurazione dei tuoi moduli di test.
La configurazione di un modulo di test è un file XML obbligatorio aggiunto all'inizio del modulo di livello, denominata "AndroidTest.xml". Il file XML segue il formato di un file di configurazione usato dal sistema di automazione dei test della Trade Federation. Attualmente i tag principali gestiti tramite le configurazioni dei moduli di test sono "target_preparer" e "test" i tag.
Preparatori del target
Un tag "target_preparer", come suggerisce il nome, definisce un preparatore di destinazione (vedi ITargetPreparer). che offre un metodo di configurazione, che viene chiamato prima dell'esecuzione del modulo di test per i test; e se anche la classe a cui si fa riferimento nel tag "target_preparer" implements ITargetCleaner il suo metodo di disinstallazione verrà richiamato al termine del modulo di test.
Per utilizzare la configurazione comune integrata dei moduli, aggiungi un nuovo file "AndroidTest.xml" all'indirizzo la cartella di primo livello per il modulo di test e compilala con le contenuti:
<?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 (nel commento "insert" 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 cablaggio di test per:
- prima di richiamare il modulo di test, esegui il comando shell "settings put secure Accessibility_enabled da 1" sul dispositivo
- dopo aver completato il modulo di test, esegui il comando shell "settings put secure accessibilità_enabled di 0"
In questo particolare esempio, l'accessibilità viene attivata/disattivata prima/dopo il dell'esecuzione del modulo di test. Con un semplice esempio dimostrato, per illustrare in dettaglio come viene utilizzato il tag "option". Come mostrato sopra, il tag può avere due attributi: nome, valore. L'attributo nome deve fare riferimento a una delle opzioni offerte dal redattore.
Lo scopo esatto del campo del valore dipende da come è stato definito il preparatore l'opzione: può essere una stringa, un numero, un valore booleano o perfino un percorso di file. Ecco un riepilogo dei tre responsabili di preparazione dei target più comuni:
nome della classe: PushFilePreparer
- short name: push-file
- function: esegue il push dei file arbitrari dalla cartella dello scenario di test alla destinazione sul dispositivo
- note:
- .
- questo preparatore può eseguire il push da una cartella all'altra o da un file all'altro; che è che non puoi eseguire il push di un file in una cartella sul dispositivo: devi specificare il nome file di destinazione anche all'interno di quella cartella.
- opzioni:
- .
- push-file: una specifica push che specifica il file locale nel percorso in cui deve essere eseguito il push sul dispositivo. Può essere ripetuto. Se più sono configurati per essere inviati allo stesso percorso remoto, verrà inviato l'ultimo.
- push: (deprecato) una specifica push, formattata 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 della directory stessa. - post-push: un comando da eseguire sul dispositivo (con "
adb shell <your command>") dopo aver tentato tutti i push. Utilizzo tipico nel caso in cui venga usato chmod per le autorizzazioni
nome della classe: InstallApkSetup
- short name:install-apk
- function: spinge i file apk arbitrari sotto nella destinazione su dispositivo
- opzioni:
- .
- test-file-name: il nome dell'APK da installare su dispositivo.
- install-arg: argomenti aggiuntivi da passare all'installazione pm incluso il trattino iniziale, ad esempio "-d". Può essere ripetuto
nome classe: RunCommandTargetPreparer
- nome breve: run-command
- function: esegue comandi di shell arbitrari prima o dopo il test esecuzione del modulo
- opzioni:
- .
- run-command:adb della shell da eseguire. Può essere ripetuto
- teardown-command:il comando shell adb da eseguire durante la fase di disinstallazione. Può essere ripetuto
Corso di prova
Una classe di test è la classe della Trade Federation 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
- function: un test che esegue un pacchetto di test nativo sul dispositivo specificato.
- opzioni:
- .
- native-test-device-path: il percorso sul dispositivo in cui si trovano i test nativi.
nome della classe: InstrumentationTest
- short name: strumentazione
- function: un test che esegue un pacchetto di test della strumentazione sul dispositivo specificato
- opzioni:
- .
- package: nome del pacchetto manifest dell'applicazione Android test da eseguire.
- class: il nome della classe di test da eseguire.
- method: il nome del metodo di test da eseguire.
nome della classe: AndroidJUnitTest
- function: un test che esegue un pacchetto di test di strumentazione su un dispositivo che utilizza il comando android.support.test.runner.AndroidJUnitRunner Questo è il modo principale per eseguire un test di strumentazione.