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 questo elenco possa sembrare limitativo, ti consente di definire con precisione le esigenze di configurazione del modulo 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. Lo scopo è evitare che questi oggetti eseguano effettivamente un'attività all'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 directory di cui eseguire il pull e il log 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à informazioni sulla build. 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
Un gran numero di moduli di test include 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 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 durante l'invio precedente se un componente non esistente viene aggiunto a un modulo CTS.
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
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 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 di 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 essenziali per i test delle prestazioni.
I collezionisti di metriche e i post-processor a livello di modulo possono essere specifici per il modulo.
Non è consigliabile specificare i post-processor sia a livello di primo livello sia a livello di modulo.
Una configurazione del modulo di test di rendimento deve includere i metadati test-type con valore performance, ad esempio:
xml
<option name="config-descriptor:metadata" key="test-type" value="performance" />
In caso contrario, se una configurazione del test include metric_collector diverso da
FilePullerLogCollector o qualsiasi metric_post_processor, il test
non va a buon fine nella fase di 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>