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

Console de commande CTS v2

Utiliser la console CTS v2

Pour Android 7.0 ou version ultérieure, utilisez CTS v2.

Sélectionner des forfaits

Les plans de test disponibles incluent les suivants:

cts : exécute CTS à partir d'une installation CTS préexistante.
cts-camera : exécute la caméra CTS à partir d'une installation CTS préexistante.
cts-java : exécute les tests Java principaux à partir d'une installation CTS préexistante.
cts-pdk : exécute des tests utiles pour valider un build de fusion PDK.
tout : configuration courante pour les suites de compatibilité.

Les autres configurations disponibles sont les suivantes:

basic-reporters : configuration avec des reporters CTS de base.
collect-tests-only : exécute CTS à partir d'une installation CTS préexistante.
common-compatibility-config : configuration commune pour les suites de compatibilité.
cts-filter-sample : configuration courante pour les suites de compatibilité.
cts-known-failures : configuration avec échecs connus de CTS.
cts-preconditions : configurations de conditions préalables CTS
host : exécute un seul test basé sur l'hôte sur un appareil existant.
instrument : exécute un seul test d'instrumentation Android sur un appareil existant.
native-benchmark : exécute un test de contrainte natif sur un appareil existant.
native-stress : exécute un test de contrainte natif sur un appareil existant.
recharge : test fictif qui attend les appareils presque déchargés et les maintient en charge.
testdef : exécute les tests contenus dans les fichiers test_def.xml sur un appareil existant.
util/wifi : configuration de l'utilitaire pour configurer le Wi-Fi sur l'appareil.
util/clear : efface les données utilisateur de l'appareil.

Tous ces plans et configurations peuvent être exécutés à l'aide de la commande run cts.

Documentation de référence sur les commandes de la console CTS v2

Ce tableau récapitule les commandes de la console CTS v2 pour pour diverses utilisations.

Hôte	Description
`help`	Afficher un résumé des commandes les plus couramment utilisées
`help all`	Afficher la liste complète des commandes disponibles
`version`	Affichez la version.
`exit`	Quittez progressivement la console CTS. La console se ferme lorsque toutes les tests en cours d'exécution sont terminés.
`extdir`	Le fichier de téléchargement compressé est décompressé sous la forme `extdir`. Si vous souhaitez supprimez la sortie gonflée, utilisez l'option `-q`: `unzip -q android-cts-9.0_r15-linux_x86-arm.zip -d extdir` Si vous souhaitez décompresser le fichier dans le répertoire actuel, n'utilisez pas l'option `-d`, il vous suffit d'exécuter la commande suivante: `unzip -q android-cts-9.0_r15-linux_x86-arm.zip`
Exécuter	Description
`run cts`	Sous Android 10, exécutez le forfait CTS par défaut et CTS-Instant (c'est-à-dire l'appel CTS complet). Pour Android 9 ou version antérieure, exécutez la Forfait CTS uniquement. Utilisez cette option complète (y compris les conditions préalables) pour la validation des appareils. Consultez le fichier cts.xml pour plus d'informations sur les éléments à inclure. La console CTS peut accepter d'autres commandes pendant que les tests sont en cours. Si aucun appareil n'est connecté, la machine de bureau CTS (ou hôte) attendra pour qu'un appareil soit connecté avant de commencer les tests. Si plusieurs l'appareil est connecté, l'hôte CTS choisit un appareil automatiquement.
`run cts-instant`	Pour Android 9, exécutez le forfait CTS-Instant par défaut.
`run cts --module-parameter INSTANT_APP`	Sous Android 10, exécutez le forfait CTS-Instant par défaut.
`run cts --module-parameter INSTANT_APP --module/-m test_module_name`	Sous Android 10, exécutez le module de test CTS-Instant spécifié ou modules.
`run retry`	Pour Android 9 ou version ultérieure uniquement. Relancer tous les tests qui ont échoué ou qui n'ont pas été exécutés des sessions précédentes. Par exemple, `run retry --retry -s` ou `run retry --retry --shard-count` avec la segmentation TF. `run cts --retry` n'est pas pour Android 9 ou version ultérieure.
`run cts-sim`	Pour Android 11 ou version ultérieure. Exécute le sous-ensemble de tests sur un appareil avec carte SIM.
`--device-token`	Pour Android 8.1 ou versions antérieures. Indique qu'un appareil donné dispose de la valeur à partir d'un jeton d'accès. (par exemple, `--device-token 1a2b3c4d:sim-card`).
`--enable-token-sharding`	Pour Android 10 ou version ultérieure uniquement. Automatiquement correspond au test que nécessite le type de SIM respectif. Pas besoin de fournir un numéro de série d'appareil pour exécuter Scénarios de test liés à la carte SIM Cartes SIM compatibles: `SIM_CARD`, `UICC_SIM_CARD`, et `SECURE_ELEMENT_SIM_CARD`.
`run cts-dev`	Exécutez le plan CTS par défaut (c'est-à-dire l'appel CTS complet), mais ignorer les conditions préalables afin de gagner du temps d'exécution pour le développement itératif d'un nouveau test. Cela permet de contourner la vérification et la configuration configuration de l'appareil, par exemple pour transférer des fichiers multimédias ou rechercher une connexion Wi-Fi comme lors de l'utilisation de l'option `--skip-preconditions`. Ce ignore également la collecte des informations sur les appareils et tous les vérificateurs d’état du système. Il y a aussi exécute les tests sur une seule ABI. Pour la validation des appareils, évitez cette optimisation et inclure toutes les conditions préalables et les vérifications. Voir cts-dev.xml pour les exclusions La console CTS peut accepter d'autres commandes pendant que les tests sont en cours. Si aucun appareil n'est connecté, la machine de bureau CTS (ou hôte) attendra pour qu'un appareil soit connecté avant de commencer les tests. Si plusieurs l'appareil est connecté, l'hôte CTS choisit un appareil automatiquement.
`--subplan subplan_name`	Exécutez le sous-plan spécifié.
`--module/-m test_module_name --test/-t test_name`	Exécutez le module et le test spécifiés. Par exemple : `run cts -m Gesture --test android.gesture.cts.GestureTest#testGetStrokes` exécute le package, la classe ou le test spécifique. Attention: N'utilisez pas cette option lorsque vous utilisez l'option `--include-filter`.
`--retry`	Relancez tous les tests qui ont échoué ou qui n'ont pas été exécutés à partir des sessions précédentes. Utilisez `list results` pour obtenir l'ID de session.
`--retry-type NOT_EXECUTED`	Ne relancez que les tests qui n'ont pas été exécutés à partir des sessions précédentes. Utilisez `list results` pour obtenir l'ID de session.
`--shards number_of_shards`	Pour Android 8.1 ou version antérieure Segmenter un CTS un nombre donné de fragments indépendants, pour s'exécuter sur plusieurs appareils en parallèle.
`--shard-count number_of_shards`	Pour Android 9 Segmenter un CTS sur un nombre donné de des fragments indépendants, pour qu'ils s'exécutent sur plusieurs appareils en parallèle.
`--serial/-s deviceID`	Exécutez CTS sur l'appareil concerné.
`--include-filter "test_module_name test_name"`	Exécuter avec les modules spécifiés, ou les packages de test, les classes et les cas. Par exemple : `run cts --include-filter "CtsCalendarcommon2TestCases android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking"` inclut le module spécifié. Cette option de commande n'est pas disponible lors de l'exécution de "Réessayer". Attention: N'utilisez pas cette option lorsque vous utilisez l'option `--module/-m`.
`--exclude-filter "test_module_name test_name"`	Excluez les modules, ou les packages de test, les classes et les cas spécifiés de l'exécution. Par exemple : `run cts --exclude-filter "CtsCalendarcommon2Test android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking"` exclut le module spécifié.
`--log-level-display/-l log_level`	Exécuter avec le niveau de journalisation minimal spécifié affiché sur `STDOUT` Valeurs valides: [`VERBOSE`, `DEBUG`, `INFO`, `WARN` `ERROR`, `ASSERT`].
`--abi abi_name`	Forcez l'exécution du test sur l'ABI donnée (32 ou 64). CTS par défaut exécute un test une fois pour chaque ABI compatible avec l'appareil.
`--logcat-on-failure`, `--bugreport-on-failure`, `--screenshoot-on-failure`	Elles offrent une meilleure visibilité sur les défaillances et peuvent faciliter les diagnostics.
`--device-token`	Spécifie qu'un appareil donné possède le jeton donné, par exemple `--device-token 1a2b3c4d:sim-card`
`--skip-device-info`	Ignore la collecte d'informations sur l'appareil. Attention: N'utilisez pas cette option lors de l'exécution de CTS pour approbation.
`--skip-preconditions`	Ignorer les conditions préalables afin de gagner du temps d'exécution pour le développement itératif d'une un nouveau test. Cela permet de contourner la vérification et la configuration configuration de l'appareil, par exemple pour transférer des fichiers multimédias ou rechercher une connexion Wi-Fi .
Liste	Description
`list modules`	Répertorie tous les modules de test disponibles dans le dépôt.
`list plans` ou `list configs`	Répertorier tous les plans de test (configurations) disponibles dans le dépôt.
`list subplans`	Répertoriez tous les sous-plans disponibles dans le dépôt.
`list invocations`	Répertorie les commandes run en cours d'exécution sur les appareils.
`list commands`	Répertorie toutes les commandes run figurant dans la file d'attente en attente d'attribution à des appareils.
`list results`	Répertorie les résultats CTS actuellement stockés dans le dépôt.
`list devices`	Répertoriez les appareils actuellement connectés et leur état. Les appareils disponibles sont opérationnels, inactifs et disponibles pour effectuer des tests. Les appareils indisponibles sont des appareils visibles via adb, mais qui ne répondent pas à adb. et ne seront pas allouées aux tests. Les appareils alloués sont ceux qui exécutent des tests.
Vider	Description
`dump logs`	Videz les journaux échangés pour tous les appels en cours d'exécution.
Ajouter	Description
`add subplan --name/-n subplan_name --result-type [passed \| failed \| not_executed] [--session session_id]`	Créer un sous-plan issu de la session précédente cette option génère un sous-plan qui peut être utilisé pour exécuter un sous-ensemble de tests. Le seul l'option obligatoire est `--session`. D'autres sont facultatifs, mais lorsque doit être suivie d'une valeur. La L'option `--result-type` est reproductible. Exemple : `add subplan --session 0 --result-type passed --result-type failed` est valide.