La struttura complessiva della configurazione dei moduli segue uno schema simile alla normale configurazione XML di Tradefed ma con alcune restrizioni dovute al fatto che vengono eseguiti come parte di una suite.
Elenco dei tag consentiti
AndroidTest.xml o più in generale la configurazione del modulo può contenere solo i seguenti tag XML: target_preparer , multi_target_preparer , test e metrics_collector .
Anche se l'elenco sembra restrittivo, consente di definire con precisione le esigenze di configurazione del modulo di test e il test da eseguire.
NOTA: vedere la configurazione XML di Tradefed se è necessario un aggiornamento sui diversi tag.
Oggetti come build_provider o result_reporter solleveranno una ConfigurationException se si tenta di essere eseguiti dall'interno di una configurazione del modulo. Questo ha lo scopo di evitare l'aspettativa che questi oggetti eseguano effettivamente alcune attività dall'interno di un modulo.
Esempio di configurazione del modulo
<configuration description="Config for CTS Gesture test cases">
<option name="test-suite-tag" value="cts" />
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsGestureTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.gesture.cts" />
<option name="runtime-hint" value="10m50s" />
</test>
</configuration>
Questa configurazione descrive un test che richiede l'installazione CtsGestureTestCases.apk ed eseguirà una strumentazione sul pacchetto android.gesture.cts .
Tag di inclusione <include> e <template-include>
L'uso di <include> e <template-include> nelle configurazioni dei moduli è sconsigliato. Non è garantito che funzionino come previsto.
Caso speciale per il tag metrics_collector
Il metrics_collector è consentito ma limitato alla classe FilePullerLogCollector per specificare un determinato file o directory da estrarre e registrare per il modulo. Ciò è utile se lasci i registri in una posizione particolare e desideri recuperarli automaticamente.
Configurazione di esempio:
<configuration description="Config for CTS UI Rendering test cases">
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.uirendering.cts" />
<option name="runtime-hint" value="11m55s" />
<option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
<option name="isolated-storage" value="false" />
</test>
<!-- Collect the files in the dump directory for debugging -->
<metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
<option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
<option name="collect-on-run-ended-only" value="true" />
</metrics_collector>
</configuration>
Che dire delle informazioni sulla build o sui download?
La definizione dei tag consentiti potrebbe dare l'impressione errata che un modulo non otterrà alcuna informazione sulla build. Questo non è vero .
Le informazioni sulla build vengono fornite dalla configurazione a livello di suite e saranno condivise da tutti i moduli della suite. Ciò consente un'unica configurazione di primo livello per la suite al fine di eseguire tutti i moduli che fanno parte della suite.
Ad esempio, invece di ciascun modulo Compatibility Test Suite (CTS) che interroga individualmente le informazioni sul dispositivo, i tipi, ecc., la configurazione a livello di suite CTS ( cts.xml ) lo fa una volta e ciascun modulo riceverà tali informazioni se lo richiedono.
Affinché gli oggetti in un modulo ricevano le informazioni sulla build, devono fare la stessa cosa della normale configurazione Tradefed: implementare l'interfaccia IBuildReceiver per ricevere IBuildInfo . Vedi test con il dispositivo per maggiori dettagli.
Campi di metadati
Un gran numero di moduli di test includono alcune specifiche metadata , ciascuna con un obiettivo unico.
Esempio:
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
<option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
<option name="config-descriptor:metadata" key="parameter" value="secondary_user" />
Componente
I metadati del component descrivono il componente generale di Android che il modulo intende testare. Non ha alcun impatto diretto sull'esecuzione del test; viene utilizzato principalmente per scopi organizzativi.
L'elenco aggiornato dei componenti consentiti per CTS è disponibile in CtsConfigLoadingTest . Questo test fallisce nel preinvio se un componente inesistente viene aggiunto a un modulo CTS.
È possibile filtrare un'esecuzione della suite in base ai componenti utilizzando module-metadata-include-filter e module-metadata-exclude-filter .
Esempio:
--module-metadata-include-filter component framework
Questo esempio esegue solo il modulo di test annotato con il componente framework .
Parametro
I metadati parameter sono informativi e influiscono sull'esecuzione del test. Specifica a quale modalità Android si applica il modulo di test. In questo caso, le modalità sono limitate alle modalità Android di alto livello, come instant apps , secondary users o different abis .
Durante l'esecuzione della suite, se la modalità si applica al test, vengono create diverse variazioni del modulo di test in base alla modalità. Ogni variazione esegue test simili ma in modalità diverse.
-
instant_app: crea una variante dei test che installano gli APK come app istantanee. -
multi_abi: crea una variazione dei test per ogni ABI supportato dal dispositivo. -
secondary_user: crea una variante dei test che installano APK ed eseguono test come utente secondario.
Raccolta e post-elaborazione delle metriche per i moduli di test delle prestazioni
Per i moduli di test delle prestazioni, sono consentiti metrics_collector e metric_post_processor a livello di modulo poiché sono essenziali per i test delle prestazioni. I raccoglitori di parametri e i post-processori a livello di modulo possono essere specifici del modulo. Non è consigliabile specificare post-processori sia a livello superiore che a livello di modulo.
Una configurazione del modulo di test delle prestazioni deve includere i metadati test-type con il valore performance , come: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> Senza questo, se un test config include metric_collector diverso da FilePullerLogCollector o qualsiasi metric_post_processor , il test fallisce nel preinvio.
Esempio di configurazione del modulo di test delle prestazioni:
<configuration description="Runs sample performance test.">
<!-- Declare as a performance test module -->
<option name="config-descriptor:metadata" key="test-type" value="performance" />
<option name="test-tag" value="hello-world-performance-test" />
<test class="com.android.tradefed.testtype.HostTest" >
<option name="class" value="android.test.example.helloworldperformance.HelloWorldPerformanceTest" />
</test>
<!-- Add module-level post processor MetricFilePostProcessor -->
<metric_post_processor class="com.android.tradefed.postprocessor.MetricFilePostProcessor">
<option name="aggregate-similar-tests" value="true" />
<option name="enable-per-test-log" value="false" />
</metric_post_processor>
</configuration>