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
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 Si vous souhaitez décompresser dans le répertoire actuel, n'utilisez pas l'option |
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 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, |
--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 : |
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 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 | 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. |