La struttura complessiva della configurazione del modulo segue un pattern simile alla normale configurazione XML Tradefed, ma con alcune restrizioni dovute al fatto che vengono eseguite 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.
Sebbene l'elenco sembri restrittivo, consente di definire con precisione le esigenze di configurazione dei moduli di test e il test da eseguire.
NOTA: consulta la sezione Configurazione XML di Tradefed se hai bisogno di un ripasso sui diversi tag.
Oggetti come build_provider o result_reporter genereranno un
ConfigurationException se si tenta di eseguirli dall'interno di una configurazione
del modulo. in modo da evitare che questi oggetti
svolgano effettivamente alcune attività dall'interno di un modulo.
Configurazione di esempio 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 di CtsGestureTestCases.apk ed eseguirà una misurazione sul pacchetto android.gesture.cts.
Tag di inclusione <include> e <template-include>
L'utilizzo di <include> e <template-include> nelle configurazioni dei moduli è sconsigliato. Non è garantito che funzionino come previsto.
Caso speciale per il tag metrics_collector
metrics_collector è consentito, ma limitato alla classe
FilePullerLogCollector per specificare un determinato file o una determinata directory da estrarre e registrare per il
modulo. Questa operazione è utile se lasci i log in una determinata posizione e vuoi 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 di informazioni sulla compilazione o download?
La definizione dei tag consentiti potrebbe dare l'impressione errata che un modulo non riceverà alcuna informazione di compilazione. Non è vero.
Le informazioni sulla compilazione vengono fornite dalla configurazione a livello di suite e saranno condivise da tutti i moduli della suite. In questo modo è possibile eseguire una singola configurazione di primo livello per la suite in modo da eseguire tutti i moduli della suite.
Ad esempio, anziché ogni
modulo Compatibility Test Suite (CTS)
eseguire query singolarmente sulle informazioni, sui tipi e così via del dispositivo, la configurazione
a livello di suite CTS (cts.xml) lo fa una volta e ogni modulo riceverà queste
informazioni se le richiede.
Affinché gli oggetti di un modulo ricevano le informazioni sulla compilazione, devono eseguire la stessa operazione eseguita nella normale configurazione di TradeFed: implementare l'interfaccia IBuildReceiver per ricevere IBuildInfo. Per ulteriori dettagli, consulta la sezione Test con il dispositivo.
Campi dei metadati
Molti moduli di test includono alcune specifiche di metadata,
che hanno ciascuna 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 component descrivono il componente Android generale che il modulo intende testare. Non ha alcun impatto diretto sull'esecuzione del test; viene principalmente utilizzato per scopi organizzativi.
L'elenco aggiornato dei componenti consentiti per CTS è disponibile in CtsConfigLoadingTest. Questo test non va a buon fine nella fase precedente all'invio se a un modulo CTS viene aggiunto un componente inesistente.
Puoi filtrare l'esecuzione di una suite in base ai componenti utilizzando
module-metadata-include-filter e module-metadata-exclude-filter.
Esempio:
--module-metadata-include-filter component framework
In questo esempio viene eseguito solo il modulo di test annotato con il componente framework.
Parametro
I metadati parameter sono informativi e influiscono sull'esecuzione del test. Specifica la modalità Android a cui 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 varianti del modulo di test in base alla modalità. Ogni variante 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 variante dei test per ogni ABI supportata dal dispositivo.secondary_user: crea una variante dei test che installano gli APK e esegui i test come utente secondario.
Raccolta delle metriche e post-elaborazione 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, in quanto sono essenziali per i test delle prestazioni.
I raccoglitori di metriche e i post-processori a livello di modulo possono essere specifici del modulo.
Non è consigliabile specificare i post-processor sia a livello di primo livello sia a livello di modulo.
La configurazione di un modulo di test delle prestazioni deve includere i metadati test-type
con valore performance, ad esempio:
xml
<option name="config-descriptor:metadata" key="test-type" value="performance" />
Senza questi valori, se una configurazione di test include metric_collector diversi da
FilePullerLogCollector o metric_post_processor, il test
non va a buon fine durante l'invio.
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>