Structure AndroidTest.xml

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

Liste des balises autorisées

AndroidTest.xml ou plus largement la configuration du module peut contenir uniquement les balises XML suivantes : target_preparer , multi_target_preparer , test et metrics_collector .

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

REMARQUE : Voir la configuration XML de Tradefed si vous avez besoin d'un rappel sur les différentes balises.

Les objets tels que build_provider ou result_reporter déclencheront une ConfigurationException s'ils tentent d'être exécutés depuis l'intérieur d'une configuration de module. Cela vise à éviter que ces objets exécutent réellement certaines tâches à 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 l'installation CtsGestureTestCases.apk et exécutera 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. Il n’est pas garanti qu’ils fonctionnent comme prévu.

Cas particulier de la balise metrics_collector

Le metrics_collector est autorisé mais limité à la classe FilePullerLogCollector afin de spécifier un fichier ou un répertoire donné à extraire et à enregistrer pour le module. Ceci est utile si vous laissez des journaux dans un emplacement particulier et 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 build ou des téléchargements ?

La définition des balises autorisées peut donner la fausse impression qu'un module ne recevra aucune information de construction. Ce n'est pas vrai .

Les informations de build sont fournies à partir de la configuration au niveau de la suite et seront partagées par tous les modules de la suite. Cela permet une seule configuration de niveau supérieur pour la suite afin d'exécuter tous les modules faisant partie de la suite.

Par exemple, au lieu que chaque module CTS (Compatibility Test Suite) interroge individuellement les informations sur le périphérique, les types, etc., la configuration au niveau de la suite CTS ( cts.xml ) le fait une fois et chaque module recevra ces informations s'il le demande.

Pour que les objets d'un module reçoivent les informations de construction, ils doivent faire la même chose que dans la configuration Tradefed normale : implémenter l'interface IBuildReceiver pour recevoir le IBuildInfo . Voir les tests avec l'appareil pour plus de détails.

Champs de métadonnées

Un grand nombre de 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" />

Composant

Les métadonnées du component décrivent le composant Android général que le module a l'intention de tester. Cela n'a aucun impact direct sur l'exécution du test ; il est principalement utilisé à des fins organisationnelles.

La liste à jour des composants autorisés pour CTS est disponible dans CtsConfigLoadingTest . Ce test échoue lors de la 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 module-metadata-include-filter et module-metadata-exclude-filter .

Exemple:

  --module-metadata-include-filter component framework

Cet exemple exécute uniquement le module de test annoté avec le composant framework .

Paramètre

Les métadonnées parameter sont informatives et ont un impact sur l’exécution du test. Il précise à quel mode Android s'applique le module de test. Dans ce cas, les modes sont limités aux modes Android de haut niveau, comme 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 des modes différents.

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

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

Pour les modules de tests de performances, metrics_collector et metric_post_processor au niveau du module sont autorisés car ils sont essentiels aux tests de performances. Les collecteurs de métriques et les post-processeurs au niveau du module peuvent être spécifiques au module. Il n'est pas recommandé de spécifier des post-processeurs à la fois 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 : xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> Sans cela, si un test config inclut metric_collector autre que FilePullerLogCollector ou tout metric_post_processor , le test échoue lors de la présoumission.

Exemple de configuration de module de test de 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>