Cette page a été traduite par l'API Cloud Translation.

Structure du fichier AndroidTest.xml

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

Liste des balises autorisées

AndroidTest.xml ou plus généralement, la configuration de module ne peut contenir que le type 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 transférable. si vous avez besoin de vous rafraîchir la mémoire 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 les objets exécutant une tâche à partir d'un module.

Exemple de configuration de 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 CtsGestureTestCases.apk pour sera installé et exécutera une instrumentation avec android.gesture.cts d'un package.

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

L'utilisation de <include> et <template-include> dans les configurations de module est découragés. Il n'est pas garanti qu'elles fonctionnent comme prévu.

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 sur le build ou des téléchargements ?

La définition des tags autorisés peut donner l'impression incorrecte qu'un ne recevra aucune information sur la compilation. C'est faux.

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

Par exemple, au lieu de chaque Compatibility Test Suite (CTS) interrogeant individuellement les informations sur l'appareil, les types, etc., le CTS la configuration au niveau de la suite (cts.xml) ne l'effectue qu'une seule fois, et chaque module recevra cette d'informations s'ils le demandent.

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 Interface 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 pas d'impact direct sur l'exécution du test. il fait principalement utilisées à des fins organisationnelles.

La liste à jour des composants autorisés pour CTS est disponible dans CtsConfigLoadingTest. Ce test échoue lors de l'envoi préalable si un composant inexistant est ajouté à une 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 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.

Pendant 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 est exécutée des tests similaires mais dans des modes différents.

instant_app: créer une variante des tests qui installent les APK en tant que des applis instantanées.
multi_abi: créer une variante des tests pour chaque ABI compatible avec le appareil.
secondary_user: crée une variante des tests qui installent les APK et exécuter 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 définir les post-processeurs au niveau racine 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, par exemple: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> Sans cela, si une configuration de test inclut des metric_collector autres que FilePullerLogCollector ou metric_post_processor, le test échoue lors du pré-envoi.

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>