AOSP include modelli di test per moduli di test che non sono sottoclassi Python lato host di BaseTest del runner VTS.
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
ebinary-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:
- Controlla la connettività del dispositivo.
- Determina il percorso assoluto del file di origine.
- Invia i file utilizzando il comando
adb push
. - 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.
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):
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:
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:
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.