Modelli di test

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

Gli sviluppatori possono utilizzare questi modelli per ridurre al minimo l'impegno richiesto integrare questi test. Questa sezione illustra la configurazione e l'utilizzo del test (disponibile nella sezione casi di test/modello ) e fornisce esempi di modelli di uso comune.

Modello BinaryTest

Utilizza la Test binario per integrare i test eseguiti sul dispositivo di destinazione in VTS. I test lato target includono:

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

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

Integra i test lato target con Modello BinaryTest

Il modello BinaryTest è progettato per aiutare gli sviluppatori a integrare facilmente i test lato target. 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 per modello.
• La specifica del percorso dell'host relativo dell'origine binaria di test abilita il modello per gestire preparazione, push dei file, esecuzione dei test, analisi dei risultati la pulizia.
• Il modello contiene metodi relativi alla creazione degli scenari di test per le sottoclassi eseguire l'override.
• Il modello presuppone uno scenario di test per modulo binario di test e il codice binario il nome del file di origine viene utilizzato come nome dello scenario di test per impostazione predefinita.

Opzioni di configurazione

Il modello BinaryTest supporta le seguenti opzioni di configurazione:

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

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

Tag di test

Puoi aggiungere tag di test aggiungendoli come prefisso alle opzioni con strings valori e utilizzando :: come delimitatore. I tag di test sono soprattutto utile quando si includono origini binarie con lo stesso nome ma con origini binarie bitness o directory principali. Ad esempio, per evitare il push del file o il nome dei risultati esiste una collisione per origini con lo stesso nome ma da directory di origine diverse, puoi specificare tag diversi per queste sorgenti.

Come mostrato nell'esempio VtsDeviceTreeEarlyMountTest con due origini dt_early_mount_test, i tag di test sono Prefissi _32bit:: e _64bit:: attivati binary-test-source. I tag che terminano con 32bit o 64bit contrassegna automaticamente i test come disponibili per un'unica quantità di bit ABI; Ad esempio, i test con il tag _32bit non vengono eseguiti su ABI a 64 bit. No 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. Per Ad esempio, binary-test-args con il tag _32bit è applicata solo a binary-test-source con lo stesso tag ed eseguita in binary-test-working-directory con lo stesso tag. La L'opzione binary-test-working-directory è facoltativa per i test binari, che ti consente di specificare un'unica directory di lavoro per un tag. Quando L'opzione binary-test-working-directory non è specificata (impostazione predefinita) vengono utilizzate per ogni tag.

Il nome del tag viene aggiunto direttamente al nome dello scenario di test nel report sui risultati. Ad esempio, scenario di test testcase1 con tag _32bit viene visualizzato come testcase1_32bit nel report sui risultati.

Integra i test lato target senza Modello BinaryTest

In VTS, il formato di test predefinito è costituito dai test Python lato host estesi da BaseTest in VTS runner. Per integrare i test lato destinazione, devi prima eseguire il push testare i file sul dispositivo, eseguire i test utilizzando i comandi della shell, quindi analizzare utilizzando gli script Python lato host.

File binari del test push

Ti consigliamo di eseguire il push dei 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>

Lo VtsFilePusher esegue le seguenti operazioni:

1. Controlla la connettività del dispositivo.
2. Determina il percorso del file di origine assoluto.
3. Esegue il push dei file utilizzando il comando adb push.
4. Elimina i file al termine dei test.

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

Esegui test

Dopo aver inviato i file al dispositivo, esegui il test utilizzando i comandi della shell in un dello 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

La GtestBinaryTest modello ospita file binari di test GTest, ognuno dei quali di solito contiene più scenari di test. Questo modello estende il modello BinaryTest eseguendo l'override configurazione, creazione degli scenari di test e metodi di analisi dei risultati, in modo che tutti vengono ereditate.

GtestBinaryTest aggiunge l'opzione gtest-batch-mode:

Nome opzione	Tipo di valore	Descrizione
tipo di test binario	string	Tipo di modello. Utilizza il valore gtest.
modalità-batch-gtest	boolean	Esegui i programmi binari Gtest in modalità batch. Esempio: true

In generale, l'impostazione del criterio gtest-batch-mode su true aumenta le prestazioni diminuendo leggermente l'affidabilità. In conformità a VTS molti moduli usano la modalità batch per migliorare le prestazioni. Per l'affidabilità Tuttavia, se la modalità non è specificata, il valore predefinito sarà non batch.

Modalità non batch

La modalità non batch effettua chiamate individuali al programma binario GTest per ogni scenario di test. Per Ad esempio, se il file binario GTest contiene 10 scenari di test (dopo avere applicato un filtro per host ), il programma binario viene chiamato 10 volte sulla shell del dispositivo con un filtro di test diverso. Per ogni scenario di test, un output univoco di risultati GTest Il file XML viene generato e analizzato dal modello.

I vantaggi dell'utilizzo della modalità non batch includono:

• Isolamento degli scenari di test. Un arresto anomalo o un blocco in uno scenario di test non influisce su altri scenari di test.
• Granularità. Ottenere profilazione/copertura per ogni caso di test più semplice misurazioni, systrace, bugreport, logcat ecc. I risultati e i log dei test recuperate immediatamente al termine di ogni scenario di test.

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

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

Modalità batch

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

Quando utilizzi output.xml (impostazione predefinita):

Come in modalità non batch, il risultato del test viene analizzato nel file XML di output di GTest . Tuttavia, poiché il file XML di output viene generato dopo che tutti i test completato, se uno scenario di test ha causato l'arresto anomalo del file binario o del dispositivo, nessun risultato XML generati.

Quando utilizzi l'output del terminale:

Mentre GTest è in esecuzione, stampa il log di test e l'avanzamento al terminale in un formato che può essere analizzato dal framework per conoscere lo stato, i risultati e logaritmi.

I vantaggi della modalità batch includono:

• Isolamento degli scenari di test. Offre lo stesso livello di test isolamento dei casi come modalità non batch se il framework riavvia il file binario/dispositivo Dopo un arresto anomalo con un filtro di test ridotto (escluso il test completato e con arresti anomali casi).
• Granularità. Fornisce la stessa granularità dello scenario di test modalità non batch.

Gli svantaggi dell'utilizzo della modalità batch includono:

• Costi di manutenzione. Se il formato del logging di GTest cambia, tutti i test non andranno a buon fine.
• Confusione. Uno scenario di test può stampare qualcosa di simile a GTest formato di avanzamento, che può confondere il formato.

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

Modello HostBinaryTest

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

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

Un esempio è la VTS Test lato host del criterio SELinux di sicurezza:

<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 un modello simile configurazioni di test. Nell'esempio precedente, binary-test-source specifica un percorso relativo lato host per l'eseguibile di test e binary-test-type è host_binary_test. Simile a BinaryTest, il nome del file binario viene utilizzato come nome dello scenario di test predefinito.

Estendi i modelli esistenti

Puoi utilizzare i modelli direttamente nella configurazione di test per includere test non Python oppure estendili in una sottoclasse per gestire requisiti di test specifici. Modelli in il repository VTS ha le seguenti estensioni:

Gli sviluppatori sono invitati a estendere qualsiasi modello esistente per qualsiasi i requisiti per i test. Di seguito sono riportati alcuni motivi comuni per estendere i modelli:

• Procedure speciali di configurazione di test, come la preparazione di un dispositivo con speciali tramite comandi SQL.
• Generazione di scenari di test e nomi di test diversi.
• Analizzare i risultati leggendo l'output comando o utilizzando altre condizioni.

Per facilitare l'estensione dei modelli esistenti, i modelli contengono metodi specializzato per ciascuna funzionalità. Se hai migliorato i design di modelli esistenti modelli, ti invitiamo a contribuire al codebase VTS.