La structure globale de la configuration du module suit un modèle similaire à celui de la configuration XML Tradefed standard, mais avec quelques restrictions, car ils 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 les besoins de configuration du module de test et le test à exécuter.
REMARQUE : Consultez Configuration XML Tradefed 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 erreur ConfigurationException s'ils sont exécutés à partir d'une configuration de module. L'objectif est d'éviter que ces objets soient censés effectuer 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 l'installation de CtsGestureTestCases.apk et qui 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. Leur fonctionnement n'est pas garanti.
Cas particulier pour le tag metrics_collector
metrics_collector est autorisé, mais limité à la classe FilePullerLogCollector afin de spécifier un fichier ou un répertoire donné à extraire et à consigner pour le module. Cela peut être utile si vous laissez des journaux à un emplacement spécifique et que 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 les versions ou des téléchargements ?
La définition des tags autorisés peut donner l'impression erronée qu'un module n'obtiendra aucune information de compilation. C'est faux.
Les informations de compilation sont fournies par la configuration au niveau de la suite et seront partagées par tous les modules de la suite. Cela permet une configuration unique de premier niveau pour la suite afin d'exécuter tous les modules qui en font partie.
Par exemple, au lieu que chaque module Compatibility Test Suite (CTS) interroge individuellement les informations, les types, etc. de l'appareil, la configuration au niveau de la suite CTS (cts.xml) le fait une seule 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 doivent procéder de la même manière que dans la configuration Tradefed habituelle : implémenter l'interface IBuildReceiver pour recevoir le IBuildInfo. Pour en savoir plus, consultez Tester avec un appareil.
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" />
Component
Les métadonnées component décrivent le composant Android général que le module entend 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 l'exécution d'une 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 fournies à titre informatif et ont une incidence sur l'exécution du test. Il spécifie le mode Android auquel le module de test s'applique.
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 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 compatible avec l'appareil.secondary_user: créez une variante des tests qui installe des APK et exécute des tests en tant qu'utilisateur secondaire.
Collecte et post-traitement des métriques pour les modules de test de performances
Pour les modules de test de performances, les 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 à un module.
Il n'est pas recommandé de spécifier des post-processeurs à la fois au niveau supérieur et au niveau du module.
La configuration d'un 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 metric_collector autre que FilePullerLogCollector ou metric_post_processor, le test échoue lors de la pré-soumission.
Exemple de configuration du 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>