Console de commande CTS v2

Utiliser la console CTS v2

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

Sélectionnez les forfaits

Les plans de test disponibles incluent les éléments 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 de base à partir d'une installation CTS préexistante.
  • cts-pdk — Exécute des tests utiles pour valider une version de fusion PDK.
  • tout - Configuration commune pour les suites de compatibilité.

Les autres configurations disponibles sont les suivantes :

  • basic-reporters — Configuration avec les 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-filtered-sample — Configuration commune pour les suites de compatibilité.
  • cts-known-failures — Configuration avec les échecs connus de CTS.
  • cts-preconditions — Configurations de préconditions CTS.
  • hôte — Exécute un seul test basé sur l'hôte sur un périphérique existant.
  • instrument — Exécute un seul test d’instrumentation Android sur un appareil existant.
  • native-benchmark — Exécute un test de résistance natif sur un appareil existant.
  • native-stress — Exécute un test de stress natif sur un appareil existant.
  • recharge — Un faux test 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/wipe — Efface les données utilisateur sur l'appareil.

Tous ces plans et configurations peuvent être exécutés avec la commande run cts .

Référence des commandes de la console CTS v2

Ce tableau résume les commandes de la console CTS v2 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 Montrez la version.
exit Quittez gracieusement la console CTS. La console se ferme lorsque tous les tests en cours d'exécution sont terminés.
extdir

Le fichier de téléchargement compressé est décompressé en extdir . Si vous souhaitez vous débarrasser de 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 dans le répertoire actuel, n'utilisez pas l'option -d , exécutez simplement :

unzip -q android-cts-9.0_r15-linux_x86-arm.zip

Courir Description
run cts

Sous Android 10, exécutez le plan CTS par défaut et CTS-Instant ensemble (c'est-à-dire l'invocation CTS complète). Pour Android 9 ou version antérieure, exécutez uniquement le plan CTS par défaut. Utilisez cette option complète (y compris les conditions préalables) pour la validation des appareils. Voir cts.xml pour les inclusions.

La console CTS peut accepter d'autres commandes pendant que les tests sont en cours.

Si aucun périphérique n'est connecté, la machine de bureau CTS (ou l'hôte) attendra qu'un périphérique soit connecté avant de démarrer les tests. Si plusieurs appareils sont connectés, l'hôte CTS choisira automatiquement un appareil.

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 ou les modules de test CTS-Instant spécifiés.

run retry

Pour Android 9 ou version ultérieure uniquement. Réessayez tous les tests qui ont échoué ou n'ont pas été exécutés lors des sessions précédentes. Par exemple, run retry --retry -s ou run retry --retry --shard-count avec le partitionnement TF.

run cts --retry n'est pas autorisé pour Android 9 ou version ultérieure.

run cts-sim

Pour Android 11 ou versions supérieures. Exécute le sous-ensemble de tests sur un appareil doté d'une carte SIM.

--device-token

Pour Android 8.1 ou versions inférieures. Spécifie qu'un appareil donné possède le jeton donné. Par exemple, --device-token 1a2b3c4d:sim-card .

--enable-token-sharding

Pour Android 10 ou supérieur uniquement . Correspond automatiquement au test qui nécessite le type de carte SIM respectif. Pas besoin de fournir un numéro de série d'appareil pour exécuter des scénarios de test liés à la carte SIM. Cartes SIM prises en charge : 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'invocation CTS complète) mais ignorez les conditions préalables pour gagner du temps d'exécution pour le développement itératif d'un nouveau test. Cela contourne la vérification et la configuration de la configuration de l'appareil, comme l'envoi de fichiers multimédias ou la vérification de la connexion Wi-Fi, comme cela se fait lorsque l'option --skip-preconditions est utilisée. Cette commande ignore également la collecte d'informations sur le périphérique et tous les vérificateurs d'état du système. Il exécute également les tests sur un seul ABI. Pour la validation des appareils, évitez cette optimisation et incluez toutes les conditions préalables et 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 périphérique n'est connecté, la machine de bureau CTS (ou l'hôte) attendra qu'un périphérique soit connecté avant de démarrer les tests. Si plusieurs appareils sont connectés, l'hôte CTS choisira automatiquement un appareil.

--subplan subplan_name Exécutez le sous-plan spécifié.
--module/-m test_module_name --test/-t test_name Exécutez le module spécifié et testez. Par exemple, run cts -m Gesture --test android.gesture.cts.GestureTest#testGetStrokes pour exécuter le package, la classe ou le test spécifique.
--retry Réessayez tous les tests qui ont échoué ou n'ont pas été exécutés lors des sessions précédentes. Utilisez list results pour obtenir l’identifiant de session.
--retry-type NOT_EXECUTED Réessayez uniquement les tests qui n'ont pas été exécutés lors des sessions précédentes. Utilisez list results pour obtenir l’identifiant de session.
--shards number_of_shards Pour Android 8.1 ou versions inférieures . Partagez une exécution CTS en un nombre donné de morceaux indépendants, pour l'exécuter sur plusieurs appareils en parallèle.
--shard-count number_of_shards Pour Android 9 . Partagez une exécution CTS en un nombre donné de morceaux indépendants, pour l'exécuter sur plusieurs appareils en parallèle.
--serial/-s deviceID Exécutez CTS sur l’appareil spécifique.
--include-filter "test_module_name test_name" Exécutez 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" pour inclure le module spécifié.

Cette option de commande n’est pas prise en charge lors de l’exécution d’une nouvelle tentative.

--exclude-filter "test_module_name test_name" Excluez les modules spécifiés, ou les packages de test, les classes et les cas, 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 minimum spécifié affiché sur STDOUT . Valeurs valides : [ VERBOSE , DEBUG , INFO , WARN , ERROR , ASSERT ].
--abi abi_name Forcer l'exécution du test sur l'ABI donné, 32 ou 64. Par défaut, CTS exécute un test une fois pour chaque ABI pris en charge par l'appareil.
--logcat-on-failure ,
--bugreport-on-failure ,
--screenshoot-on-failure
Donne plus de visibilité sur les pannes et peut faciliter les diagnostics.
--device-token Spécifie qu'un appareil donné possède le jeton donné, tel que --device-token 1a2b3c4d:sim-card .
--skip-device-info Ignore la collecte d’informations sur l’appareil.
--skip-preconditions Ignorez les conditions préalables pour gagner du temps d’exécution lors du développement itératif d’un nouveau test. Cela contourne la vérification et la configuration de la configuration de l'appareil, comme l'envoi de fichiers multimédias ou la vérification de la connexion Wi-Fi.
Liste Description
list modules Répertoriez tous les modules de test disponibles dans le référentiel.
list plans ou list configs Répertoriez tous les plans de test (configurations) disponibles dans le référentiel.
list subplans Répertoriez tous les sous-plans disponibles dans le référentiel.
list invocations Répertorie les commandes « exécuter » en cours d'exécution sur les appareils.
list commands Répertoriez toutes les commandes « exécuter » actuellement dans la file d'attente en attente d'être attribuées aux appareils.
list results Répertoriez les résultats CTS actuellement stockés dans le référentiel.
list devices Répertoriez les appareils actuellement connectés et leur état.

Les appareils « disponibles » sont des appareils fonctionnels, inactifs, disponibles pour exécuter des tests.

Les appareils « indisponibles » sont des appareils visibles via adb, mais ne répondent pas aux commandes adb et ne seront pas alloués aux tests.

Les appareils « alloués » sont des appareils qui exécutent actuellement des tests.

Décharge Description
dump logs Videz les journaux échangés pour tous les appels en cours.
Ajouter Description
add subplan --name/-n subplan_name
--result-type
[pass | fail | timeout | notExecuted]
[--session session_id ]
Créer un sous-plan dérivé 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.

La seule option obligatoire est --session . D'autres sont facultatifs mais, lorsqu'ils sont inclus, doivent être suivis d'une valeur. L'option --result-type est répétable ; par exemple add subplan --session 0 --result-type passed --result-type failed est valide.