Modelli di prova

AOSP include modelli di test per moduli di test che non sono sottoclassi Python lato host di BaseTest del runner VTS.

Figura 1. Architettura del modello di test.

Gli sviluppatori possono utilizzare questi modelli per ridurre al minimo lo sforzo richiesto dall'integrazione di tali test. Questa sezione copre la configurazione e l'utilizzo dei modelli di test (situati nella directory testcases/template di VTS) e fornisce esempi di modelli comunemente utilizzati.

Modello BinaryTest

Utilizza il modello BinaryTest per integrare i test eseguiti sul dispositivo di destinazione in VTS. I test sul lato target includono:

  • Test basati su C++ compilati e inviati al dispositivo
  • Test Python lato destinazione compilati come binari
  • Script di shell eseguibili sui dispositivi

Questi test possono essere integrati in VTS con o senza il modello BinaryTest.

Integra i test lato destinazione con il modello BinaryTest

Il modello BinaryTest è progettato per aiutare gli sviluppatori a integrare facilmente i test lato destinazione. Nella maggior parte dei casi, puoi aggiungere alcune semplici righe di configurazione in AndroidTest.xml . Configurazione di esempio da VtsDeviceTreeEarlyMountTest :

<configuration description="Config for VTS VtsDeviceTreeEarlyMountTest.">
  ...
<test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
<option name="test-module-name" value="VtsDeviceTreeEarlyMountTest"/>
<option name="binary-test-source" value="_32bit::DATA/nativetest/dt_early_mount_test/dt_early_mount_test" />
<option name="binary-test-source" value="_64bit::DATA/nativetest64/dt_early_mount_test/dt_early_mount_test" />
<option name="test-timeout" value="5m"/>
</test>
</configuration>

In questa configurazione:

  • binary-test-source e binary-test-type sono specifici del modello.
  • Specificare il percorso host relativo dell'origine binaria di test consente al modello di gestire la preparazione, il push dei file, l'esecuzione del test, l'analisi dei risultati e la pulizia.
  • Il modello contiene metodi relativi alla creazione dei test case per le sottoclassi da sovrascrivere.
  • Il modello presuppone un test case per modulo binario di test e il nome del file di origine binario viene utilizzato come nome del test case per impostazione predefinita.

Opzioni di configurazione

Il modello BinaryTest supporta le seguenti opzioni di configurazione:

Nome dell'opzione Tipo di valore Descrizione
sorgente-test-binario stringhe Percorsi binari dell'origine del test relativi alla directory del caso di test vts sull'host.
Esempio: DATA/nativetest/test
directory-test-di-lavoro-binario stringhe Directory di lavoro (percorso lato dispositivo).
Esempio: /data/local/tmp/testing/
test-binario-envp stringhe Variabili d'ambiente per binario.
Esempio: PATH=/new:$PATH
argomenti-test-binario stringhe Testare argomenti o flag.
Esempio: --gtest_filter=test1
percorso-libreria-test-ld-binario stringhe Variabile di ambiente LD_LIBRARY_PATH .
Esempio: /data/local/tmp/lib
framework-disabilita-test-binario booleano Esegui adb stop per disattivare Android Framework prima del test. Esempio: true
test-binario-stop-server-nativi booleano Arrestare tutti i server nativi correttamente configurati durante il test. Esempio: true
tipo-test-binario corda Tipo di modello. Altri tipi di modello si estendono da questo modello, ma non è necessario specificare questa opzione per questo modello perché hai già specificato binary-test-source .

Per le opzioni con tipo di valore strings , puoi aggiungere più valori ripetendo le opzioni nella configurazione. Ad esempio, imposta binary-test-source due volte (come mostrato nell'esempio VtsDeviceTreeEarlyMountTest ).

Prova i tag

Puoi aggiungere tag di test anteponendoli alle opzioni con valori strings e utilizzando :: come delimitatore. I tag di test sono particolarmente utili quando si includono sorgenti binarie con lo stesso nome ma con bitness o directory principali diverse. Ad esempio, per evitare il push dei file o la collisione dei nomi dei risultati per origini con lo stesso nome ma provenienti da directory di origine diverse, puoi specificare tag diversi per queste origini.

Come mostrato nell'esempio VtsDeviceTreeEarlyMountTest con le due origini dt_early_mount_test , i tag di test sono i prefissi _32bit:: e _64bit:: su binary-test-source . I tag che terminano con 32bit o 64bit contrassegnano automaticamente i test come disponibili per un bit ABI; cioè i test con il tag _32bit non vengono eseguiti su ABI a 64 bit. Non specificare un tag equivale a utilizzare un tag con una stringa vuota.

Le opzioni con gli stessi tag vengono raggruppate e isolate dagli altri tag. Ad esempio, binary-test-args con il tag _32bit viene applicato solo a binary-test-source con lo stesso tag ed eseguito nella binary-test-working-directory con lo stesso tag. L'opzione binary-test-working-directory è facoltativa per i test binari e consente di specificare una singola directory di lavoro per un tag. Quando l'opzione binary-test-working-directory non viene specificata, vengono utilizzate le directory predefinite per ciascun tag.

Il nome del tag viene aggiunto direttamente al nome del test case nel report dei risultati. Ad esempio, il test case testcase1 con tag _32bit viene visualizzato come testcase1_32bit nel report dei risultati.

Integra test lato destinazione senza il modello BinaryTest

In VTS, il formato di test predefinito sono i test Python lato host estesi da BaseTest nel runner VTS. Per integrare i test lato destinazione, devi prima inviare i file di test al dispositivo, eseguire i test utilizzando i comandi della shell, quindi analizzare i risultati utilizzando gli script Python lato host.

File binari di test push

Ti consigliamo di inviare file utilizzando il preparatore di destinazione VtsFilePusher . Esempio:

<target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher">
        <option name="push" value="DATA/test->/data/local/tmp/test"/>
    </target_preparer>

Il VtsFilePusher fa quanto segue:

  1. Controlla la connettività del dispositivo.
  2. Determina il percorso assoluto del file di origine.
  3. Invia i file utilizzando il comando adb push .
  4. Elimina i file una volta completati i test.

In alternativa, puoi eseguire il push dei file manualmente utilizzando uno script di test Python lato host che segue una procedura simile.

Esegui dei test

Dopo aver inviato i file al dispositivo, esegui il test utilizzando i comandi shell in uno script di test Python lato host. Esempio:

device = self.android_devices[0]
res = device.shell.Execute(["chmod a+x /data/local/tmp/test", "/data/local/tmp/test"])
asserts.AssertFalse(any(res[return_codes]))

Modello GtestBinaryTest

Il modello GtestBinaryTest ospita i binari di test GTest, ognuno dei quali solitamente contiene più casi di test. Questo modello estende il modello BinaryTest sovrascrivendo la configurazione, la creazione del test case e i metodi di analisi dei risultati, quindi tutte le configurazioni BinaryTest vengono ereditate.

GtestBinaryTest aggiunge l'opzione gtest-batch-mode :

Nome dell'opzione Tipo di valore Descrizione
tipo-test-binario corda Tipo di modello. Utilizza il valore gtest .
modalità batch gtest booleano Esegui i binari Gtest in modalità batch. Esempio: true

In generale, l'impostazione di gtest-batch-mode su true aumenta le prestazioni riducendo leggermente l'affidabilità. Nei test di conformità VTS, molti moduli utilizzano la modalità batch per migliorare le prestazioni. Per motivi di affidabilità, tuttavia, se la modalità non è specificata, per impostazione predefinita viene impostata su non batch.

Modalità non batch

La modalità non batch effettua chiamate individuali al binario GTest per ogni caso di test. Ad esempio, se il file binario GTest contiene 10 casi di test (dopo il filtraggio in base alla configurazione lato host), il file binario viene chiamato 10 volte sulla shell del dispositivo, ogni volta con un filtro di test diverso. Per ogni caso di test, un XML di output del risultato GTest univoco viene generato e analizzato dal modello.

Figura 2. Modalità non batch.

I vantaggi derivanti dall'utilizzo della modalità non batch includono:

  • Isolamento del caso di test . Un arresto anomalo o un blocco in un caso di test non influisce sugli altri casi di test.
  • Granularità . È più semplice ottenere misurazioni di profilazione/copertura per caso di test, systrace, bugreport, logcat, ecc. I risultati e i registri dei test vengono recuperati immediatamente al termine di ogni caso di test.

Gli svantaggi dell'utilizzo della modalità non batch includono:

  • Caricamento ridondante . Ogni volta che viene chiamato il binario GTest, carica le librerie correlate ed esegue le configurazioni iniziali della classe.
  • Sovraccarico di comunicazione . Al termine di un test, l'host e il dispositivo di destinazione comunicano per l'analisi dei risultati e i comandi successivi (sono possibili ottimizzazioni future).

Modalità batch

In modalità batch GTest, il file binario di test viene chiamato solo una volta con un valore di filtro di test lungo contenente tutti i casi di test filtrati dalla configurazione lato host (questo evita il problema di caricamento ridondante in modalità non batch). Puoi analizzare i risultati del test per GTest utilizzando output.xml o utilizzando l'output del terminale.

Quando si utilizza output.xml (impostazione predefinita):

Figura 3. Modalità batch, output.xml.

Come nella modalità non batch, il risultato del test viene analizzato tramite il file xml di output di GTest. Tuttavia, poiché l'xml di output viene generato dopo che tutti i test sono stati completati, se un test case provoca l'arresto anomalo del binario o del dispositivo, non viene generato alcun file xml di risultati.

Quando si utilizza l'uscita del terminale:

Figura 4. Modalità batch, uscita terminale.

Mentre GTest è in esecuzione, stampa il registro del test e l'avanzamento sul terminale in un formato che può essere analizzato dal framework per lo stato del test, i risultati e i registri.

I vantaggi derivanti dall'utilizzo della modalità batch includono:

  • Isolamento del caso di test . Fornisce lo stesso livello di isolamento dei test case della modalità non batch se il framework riavvia il file binario/dispositivo dopo un arresto anomalo con un filtro di test ridotto (esclusi i casi di test finiti e arrestati in modo anomalo).
  • Granularità . Fornisce la stessa granularità del test case della modalità non batch.

Gli svantaggi dell'utilizzo della modalità batch includono:

  • Costo di manutenzione . Se il formato di registrazione GTest cambia, tutti i test verranno interrotti.
  • Confusione . Un test case può stampare qualcosa di simile al formato di avanzamento GTest, che può confondere il formato.

A causa di questi svantaggi, abbiamo temporaneamente rimosso l'opzione per utilizzare l'output della riga di comando. Rivisiteremo questa opzione in futuro per migliorare l'affidabilità di questa funzione.

Modello HostBinaryTest

Il modello HostBinaryTest include eseguibili lato host che non esistono in altre directory o negli script Python. Questi test includono:

  • Binari di test compilati eseguibili sull'host
  • Script eseguibili in shell, Python o altri linguaggi

Un esempio è il test lato host della policy VTS Security SELinux :

<configuration description="Config for VTS  Security SELinux policy host-side test cases">
    ...
    <test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
        <option name="test-module-name" value="VtsSecuritySelinuxPolicyHost"/>
        <option name="binary-test-source" value="out/host/linux-x86/bin/VtsSecuritySelinuxPolicyHostTest" />
        <option name="binary-test-type" value="host_binary_test"/>
    </test>
</configuration>

HostBinaryTest non estende il modello BinaryTest ma utilizza configurazioni di test simili. Nell'esempio precedente, l'opzione binary-test-source specifica un percorso relativo lato host all'eseguibile del test e binary-test-type è host_binary_test . Similmente al modello BinaryTest, il nome del file binario viene utilizzato come nome del test case per impostazione predefinita.

Estendi i modelli esistenti

Puoi utilizzare i modelli direttamente nella configurazione del test per includere test non Python o estenderli in una sottoclasse per gestire requisiti di test specifici. I modelli nel repository VTS hanno le seguenti estensioni:

Figura 5. Estensione dei modelli esistenti nel repository VTS.

Gli sviluppatori sono incoraggiati ad estendere qualsiasi modello esistente per eventuali requisiti di test specifici. I motivi comuni per estendere i modelli includono:

  • Procedure speciali di configurazione del test, come la preparazione di un dispositivo con comandi speciali.
  • Generazione di diversi casi di test e nomi di test.
  • Analisi dei risultati leggendo l'output del comando o utilizzando altre condizioni.

Per facilitare l'estensione dei modelli esistenti, i modelli contengono metodi specializzati per ciascuna funzionalità. Se hai migliorato la progettazione dei modelli esistenti, ti invitiamo a contribuire alla base di codice VTS.