Struttura di AndroidTest.xml

La struttura complessiva della configurazione del modulo segue uno schema simile alla normale configurazione XML Tradefed, ma con alcune restrizioni dovute a il fatto che vengano 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, ti consente di definire con precisione di configurazione del modulo di test e il test da eseguire.

NOTA: consulta Configurazione XML scambiato se avete 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 moduli 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 CtsGestureTestCases.apk per verrà installato ed eseguirà una strumentazione sul android.gesture.cts pacchetto.

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

L'autorizzazione metrics_collector è consentita, ma limitata FilePullerLogCollector per specificare un determinato file o directory da estrarre e registrare nel 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>

E per quanto riguarda le informazioni sulle build o i 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. Ciò consente un'unica configurazione di primo livello per la suite, in modo da poter eseguire tutti i moduli che fanno parte 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. Consulta eseguire test con il dispositivo per ulteriori informazioni.

Campi dei metadati

Molti moduli di test includono alcune specifiche per metadata, ognuno dei quali ha un obiettivo specifico.

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 del modulo che intende testare. Non ha alcun impatto diretto sull'esecuzione del test. è principalmente a scopo organizzativo.

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 framework di strumento di authoring.

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 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 APK e eseguire 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 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, come: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> Senza questo valore, se una configurazione di test include metric_collector diversi da FilePullerLogCollector o metric_post_processor, il test non riesce prima dell'invio.

Esempio di configurazione di un 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>