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. Ainsi, une seule configuration de premier niveau 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é à 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>