Modelli di test

AOSP include modelli di test per i moduli di test che non sono una sottoclasse di Python lato host di BaseTest del programma di esecuzione VTS.

Gli sviluppatori possono utilizzare questi modelli per ridurre al minimo lo sforzo necessario per integrare questi test. Questa sezione illustra la configurazione e l'utilizzo dei modelli di test (che si trovano nella directory testcases/template del VTS) e fornisce esempi di modelli di uso comune.

Modello BinaryTest

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

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

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

Integrare i test lato target con il 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 del modello.
• La specifica del percorso dell'host relativo dell'origine del file binario di test consente al modello di gestire la preparazione, il trasferimento dei file, l'esecuzione del test, l'analisi dei risultati e la pulizia.
• Il modello contiene metodi relativi alla creazione dei casi di test che le sottoclassi possono eseguire l'override.
• Il modello presuppone un test case per modulo binario di test e il nome del file di origine del binario viene utilizzato come nome del test case per impostazione predefinita.

Opzioni di configurazione

Il modello BinaryTest supporta le seguenti opzioni di configurazione:

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'esempioVtsDeviceTreeEarlyMountTest).

Testare 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 includi origini binarie con lo stesso nome, ma con diverse dimensioni in bit o directory principali. Ad esempio, per evitare collisioni di nomi di risultati o push di file 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 una dimensione in bit dell'ABI; ovvero i test con il tag _32bit non vengono eseguiti su ABI a 64 bit. Se non specifichi un tag, è come se utilizzassi 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 in 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. Se l'opzione binary-test-working-directory non viene specificata, vengono utilizzate le directory predefinite per ogni tag.

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

Integra i test lato target senza il modello BinaryTest

In VTS, il formato di test predefinito è costituito da test Python lato host estesi da BaseTest nel runner VTS. Per integrare i test lato target, devi prima eseguire il push dei file di test sul dispositivo, eseguire i test utilizzando i comandi shell e poi analizzare i risultati utilizzando gli script Python lato host.

Esegui il push dei file binari di test

Ti consigliamo di eseguire il push dei file utilizzando il preparatore del target VtsFilePusher. Esempio:

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

VtsFilePusher esegue le seguenti operazioni:

1. Controlla la connettività del dispositivo.
2. Determina il percorso assoluto del file di origine.
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 uno script di test Python lato host che segue una procedura simile.

Esegui test

Dopo aver eseguito il push dei file sul dispositivo, esegui il test utilizzando i comandi della 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 file binari di test GTest, ognuno dei quali in genere contiene più scenari di test. Questo modello estende il modello BinaryTest sostituendo i metodi di configurazione, creazione del caso di test e analisi dei risultati, in modo che tutte le configurazioni di BinaryTest vengano ereditate.

GtestBinaryTest aggiunge l'opzione gtest-batch-mode:

In generale, l'impostazione di gtest-batch-mode su true aumenta le prestazioni, diminuendo leggermente l'affidabilità. Nei test di conformità al VTS, molti moduli utilizzano la modalità batch per migliorare le prestazioni. Tuttavia, per motivi di affidabilità, se la modalità non è specificata, il valore predefinito è non batch.

Modalità non batch

La modalità non batch effettua singole chiamate al file GTest per ogni test case. Ad esempio, se il file binario GTest contiene 10 casi di test (dopo il filtro 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 test case, il modello genera e analizza un output XML univoco dei risultati di GTest.

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

• Isolamento dei casi di test. Un arresto anomalo o un blocco in uno scenario di test non influisce sugli altri scenari di test.
• Granularità. È più facile ottenere misurazioni di copertura/profiling per test case, systrace, bugreport, logcat e così via. I risultati e i log dei test vengono recuperati immediatamente al termine di ogni test case.

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 delle classi.
• Overhead di comunicazione. Al termine di un test, il dispositivo host e quello di destinazione comunicano per l'analisi dei risultati e i comandi successivi (possibili ottimizzazioni future).

Modalità batch

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

Quando utilizzi output.xml (valore predefinito):

Come in modalità non batch, il risultato del test viene analizzato tramite il file XML di output di GTest. Tuttavia, poiché il file XML di output viene generato al termine di tutti i test, se un test case ha causato un arresto anomalo del file binario o del dispositivo, non viene generato alcun file XML di risultato.

Quando utilizzi l'output del terminale:

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

I vantaggi dell'utilizzo della modalità batch includono:

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

Gli svantaggi dell'utilizzo della modalità batch includono:

• Costo di manutenzione. Se il formato di registrazione di GTest cambia, tutti i test non funzioneranno.
• Confusione. Uno scenario di test può stampare qualcosa di simile al formato di avanzamento di GTest, il che può creare confusione.

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 file eseguibili lato host che non esistono in altre directory o in 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 del criterio di sicurezza SELinux di VTS:

<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. Come per il modello BinaryTest, il nome del file binario viene utilizzato come nome del caso di test per impostazione predefinita.

Espandere 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 invitati a estendere qualsiasi modello esistente per eventuali requisiti di test specifici. Ecco alcuni dei motivi più comuni per estendere i modelli:

• Procedure di configurazione dei test speciali, ad esempio la preparazione di un dispositivo con comandi speciali.
• Generazione di diversi casi di test e nomi di test.
• Analisi dei risultati mediante la lettura dell'output del comando o l'utilizzo di altre condizioni.

Per semplificare l'estensione dei modelli esistenti, questi contengono metodi specializzati per ogni funzionalità. Se hai migliorato i design dei modelli esistenti, ti invitiamo a contribuire al codice di VTS.