Struttura di AndroidTest.xml

La struttura generale della configurazione del modulo segue un pattern simile alla normale configurazione XML di Tradefed, ma con alcune limitazioni 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.

Sebbene questo elenco sembri restrittivo, ti consente di definire con precisione le esigenze di configurazione del modulo di test e il test da eseguire.

NOTA: consulta Configurazione XML di Tradefed se hai bisogno di un ripasso dei 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 l'aspettativa che questi oggetti eseguano effettivamente un'attività all'interno di un modulo.

Configurazione del modulo di esempio

<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 e che esegue una strumentazione 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 da estrarre e registrare per il modulo. Questa funzionalità è utile se lasci i log in una posizione specifica 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 delle informazioni sulle build o dei download?

La definizione dei tag consentiti potrebbe dare l'impressione errata che un modulo non riceverà informazioni sulla build. Non è vero.

Le informazioni sulla build vengono fornite dalla configurazione a livello di suite e verranno condivise da tutti i moduli della suite. Ciò consente una singola configurazione di primo livello per la suite per eseguire tutti i moduli che ne fanno parte.

Ad esempio, anziché interrogare individualmente le informazioni, i tipi e così via del dispositivo, ogni modulo della Compatibility Test Suite (CTS), la configurazione a livello di suite CTS (cts.xml) lo fa una sola volta e ogni modulo riceverà queste informazioni se le richiede.

Affinché gli oggetti di un modulo ricevano le informazioni sulla build, devono fare lo stesso della 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 numero elevato di moduli di test include alcune specifiche metadata, ognuna 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 utilizzato principalmente per scopi organizzativi.

L'elenco aggiornato dei componenti consentiti per CTS è disponibile in CtsConfigLoadingTest. Questo test non viene superato in pre-invio se viene aggiunto un componente inesistente 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 a quale modalità Android si applica il modulo di test. In questo caso, le modalità sono limitate alle modalità Android di alto livello, ad esempio 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 installa APK ed esegue i test come utente secondario.

Raccolta e post-elaborazione delle metriche per i moduli di test sulle 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 raccoglitori e i post-processori delle metriche a livello di modulo possono essere specifici per il modulo. Non è consigliabile specificare i post-processori sia a livello di primo livello sia a livello di modulo.

Una configurazione del modulo di test del rendimento deve includere i metadati test-type con valore performance, ad esempio: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> Senza questi metadati, se una configurazione di test include metric_collector diverso da FilePullerLogCollector o da qualsiasi metric_post_processor, il test non viene superato prima dell'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>