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.
--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".
--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.
--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.