Questa pagina è stata tradotta dall'API Cloud Translation.

Struttura 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

La configurazione del modulo AndroidTest.xml o più generica può contenere solo 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 faranno emergere un ConfigurationException se il tentativo di eseguirlo dall'interno di un modulo configurazione. In questo modo si evitano di aspettarsi che eseguono alcune attività dall'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 è scoraggiati. 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 desidera recuperarle 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 non riceverà informazioni sulla build. Questo non è vero.

Le informazioni sulla build sono fornite dalla configurazione a livello di suite condiviso 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, invece di ogni Suite di test di compatibilità (Compatibility Test Suite, CTS) interrogare individualmente i dispositivi su informazioni, tipi e così via, il CTS la configurazione a livello di suite (cts.xml) esegue questa operazione una volta sola e ogni modulo riceverà informazioni, se richiesto.

Affinché gli oggetti in un modulo ricevano le informazioni sulla build, devono per fare lo stesso della normale configurazione Tradefed: implementare il 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 durante il pre-invio 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

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 sul test dell'esecuzione. 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, diverse varianti del modulo di test vengono create in base alla modalità. Ogni variante viene eseguita 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, metrics_collector a livello di modulo e metric_post_processor sono consentiti in quanto essenziali per i test del rendimento. I raccoglitori di metriche e i post-processori a livello di modulo possono essere specifici del modulo. Non è consigliabile specificare post-processori sia di livello superiore che di 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>