Structure AndroidTest.xml

La structure globale de la configuration du module suit un modèle semblable à celui de la configuration XML Tradefed standard, mais avec certaines restrictions dues au fait qu'elles s'exécutent dans le cadre d'une suite.

Liste des balises autorisées

AndroidTest.xml ou plus généralement la configuration du module ne peut contenir que les balises XML suivantes : target_preparer, multi_target_preparer, test et metrics_collector.

Bien que cette liste semble restrictive, elle vous permet de définir précisément la configuration du module de test et le test à exécuter.

REMARQUE : Consultez la section Configuration XML Tradefed pour rafraîchir vos connaissances sur les différentes balises.

Les objets tels que build_provider ou result_reporter génèrent une ConfigurationException en cas de tentative d'exécution depuis un module configuration. Cela permet d'éviter que ces objets effectuent réellement une tâche dans un module.

Exemple de configuration du module

<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>

Cette configuration décrit un test qui nécessite l'installation de CtsGestureTestCases.apk et qui exécute une instrumentation sur le package android.gesture.cts.

Balises d'inclusion <include> et <template-include>

L'utilisation de <include> et <template-include> dans les configurations de module est déconseillée. Leur fonctionnement n'est pas garanti.

Cas particulier de la balisemetrics_collector

Le metrics_collector est autorisé, mais limité aux FilePullerLogCollector afin de spécifier un fichier ou un répertoire donné à extraire et à enregistrer. dans le module. Cela est utile si vous conservez les journaux à un emplacement spécifique si vous souhaitez les récupérer automatiquement.

Exemple de configuration :

<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>

Qu'en est-il des informations de compilation ou des téléchargements ?

La définition des balises autorisées peut donner l'impression erronée qu'un module ne recevra aucune information de compilation. C'est faux.

Les informations sur la compilation proviennent de la configuration partagé par tous les modules de la suite. Ainsi, une seule configuration de premier niveau pour la suite afin d'exécuter tous les modules de la suite.

Par exemple, au lieu que chaque module de la suite de tests de compatibilité (CTS) interroge individuellement les informations, les types d'appareils, etc., la configuration au niveau de la suite CTS (cts.xml) le fait une fois et chaque module recevra ces informations s'il les demande.

Pour que les objets d'un module reçoivent les informations de compilation, ils ont besoin faire la même chose qu'une configuration Tradefed standard: implémentez IBuildReceiver pour recevoir le IBuildInfo. Voir test avec un appareil pour en savoir plus.

Champs de métadonnées

De nombreux modules de test incluent des spécifications metadata, qui ont chacune un objectif unique.

Exemple :

  <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" />

Component

Les métadonnées component décrivent le composant Android général du module a l'intention de tester. Il n'a aucun impact direct sur l'exécution des tests. Il est principalement utilisé à des fins d'organisation.

La liste à jour des composants autorisés pour CTS est disponible dans CtsConfigLoadingTest. Ce test échoue en présoumission si un composant inexistant est ajouté à un module CTS.

Vous pouvez filtrer une exécution de suite en fonction des composants à l'aide de module-metadata-include-filter et module-metadata-exclude-filter.

Exemple :

  --module-metadata-include-filter component framework

Cet exemple n'exécute que le module de test annoté avec le composant framework.

Paramètre

Les métadonnées parameter sont informatives et ont un impact sur le test l'exécution. Il spécifie le mode Android auquel s'applique le module de test. Dans ce cas, les modes sont limités aux modes Android de haut niveau, tels que instant apps, secondary users ou different abis.

Lors de l'exécution de la suite, si le mode s'applique au test, plusieurs variantes du module de test sont créées en fonction du mode. Chaque variante exécute des tests similaires, mais dans différents modes.

  • instant_app : créez une variante des tests qui installent des APK en tant qu'applications instantanées.
  • multi_abi : créez une variante des tests pour chaque ABI compatible avec l'appareil.
  • secondary_user : créez une variante des tests qui installent des APK et exécutent des tests en tant qu'utilisateur secondaire.

Collecte de métriques et post-traitement pour les modules de test de performances

Pour les modules de test de performance, metrics_collector au niveau du module et Les metric_post_processor sont autorisées, car elles sont essentielles pour tester les performances. Les collecteurs de métriques et les post-processeurs au niveau du module peuvent être spécifiques à un module. Il est déconseillé de spécifier des post-traitements au niveau supérieur et au niveau du module.

Une configuration de module de test de performances doit inclure les métadonnées test-type avec la valeur performance, comme suit : xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> Sans cela, si une configuration de test inclut un metric_collector autre que FilePullerLogCollector ou un metric_post_processor, le test échoue lors de la présoumission.

Exemple de configuration du module de test des performances:

<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>