Exécution d'appareils sur la plate-forme Developer Device pour Android

Aperçu

Ce produit ou cette fonctionnalité sont soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une compatibilité limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Ce guide explique comment exécuter un test d'instrumentation Android à l'aide de la CLI gcloud beta device-run et comment trouver vos résultats dans la console Google Cloud . Il suppose que vous disposez d'un compte Google Cloud et d'un projet.

Pour utiliser cette Google Cloud CLI, vous devrez fournir l'ID de votre projet Google Cloud . Pour obtenir un récapitulatif des commandes, consultez gcloud beta device-run.

Avant de commencer

Ces étapes supposent que vous avez déjà :

1. Vous avez créé un projet Google Cloud .
2. Configurez la plate-forme Developer Device Platform en suivant le guide de démarrage rapide.
3. Authentification avec gcloud dans le terminal.
4. Consultez la présentation de Device Run pour obtenir des informations générales.
5. Vous avez créé un test instrumenté pour Android.

Étape 1 : Choisir des appareils

À l'aide de la CLI device-run, les tests Android peuvent être exécutés sur les appareils physiques et virtuels disponibles. Pour afficher la liste complète des appareils disponibles, consultez le catalogue interactif des appareils ou exécutez la commande suivante :

gcloud beta device-run devices list

Exemple de résultat :

ID        MAKE    NAME     MODEL FORM      OS_VERSION CAPACITY  AVAILABILITY  PRODUCTS
tegu-35   Google  Pixel 9a tegu  PHYSICAL  35         MEDIUM    LOW           Automation, Streaming
tokay-34  Google  Pixel 9  tokay PHYSICAL  34         HIGH      HIGH          Automation, Streaming

Consultez le catalogue d'appareils pour découvrir comment filtrer cette liste. Pour cibler un appareil spécifique pour l'exécution de vos tests, utilisez son ID correspondant (par exemple, tegu-35) dans la commande d'envoi.

Étape 2 : Exécuter votre test d'instrumentation

Notez que ces options sont obligatoires pour les tests Android :

• Appareil : spécifiez un appareil à l'aide de --device : --device shiba-35
• Test : spécifiez l'APK de test à l'aide de --test : --test /path/to/test.apk

Pour exécuter votre test, émettez une commande semblable à la suivante, mais avec vos propres ID d'appareil et chemin d'accès au test :

gcloud beta device-run sessions submit instrumentation \
--device shiba-34 \
--apps /path/to/app.apk \
--test /path/to/test.apk

Le dossier du rapport de résultats du job se trouve dans un chemin d'accès Cloud Storage tel que gs://BUCKET_NAME/automation/sessions/SESSION_ID/. Consultez le résultat du test pour le lien, qui ressemble à ceci : https://console.cloud.google.com/storage/browser/BUCKET_NAME/automation/sessions/SESSION_ID/.

Étape 3 : Configurer l'exécution du test

Conseil : Pour afficher toutes les options disponibles pour la commande submit instrumentation, exécutez gcloud beta device-run sessions submit instrumentation --help.

Maintenant que vous avez exécuté un test, explorez certaines options de configuration :

• Plusieurs appareils : pour exécuter les mêmes tests sur plusieurs appareils, fournissez l'indicateur --device avec plusieurs ID d'appareil séparés par des virgules, comme --device shiba-34,tokay-36, ou avec plusieurs indicateurs --device, chacun spécifiant un ID d'appareil distinct (par exemple, --device shiba-34 --device tokay-36).
• Applications supplémentaires : vous pouvez éventuellement spécifier un ou plusieurs APK à installer avant d'exécuter vos tests à l'aide de l'indicateur --apps=path1,path2,...,path_n. L'ordre que vous spécifiez correspond à l'ordre dans lequel ces applications sont installées.
• Délai d'expiration du test : limitez la durée d'exécution : --instrumentation-timeout=10m (la plage de valeurs autorisée est comprise entre 1m et 1h, et la valeur par défaut est 5m).
• Bucket Cloud Storage personnalisé : si vous ne spécifiez pas de bucket Cloud Storage à l'aide du flag --bucket-name=, la Google Cloud CLI utilisera un bucket par défaut nommé PROJECT_ID-devicerun.
• Nouvelles tentatives pour les tests instables : définissez le nombre maximal de tentatives pour relancer les tests instables : --flaky-test-attempts=3 (la valeur par défaut est de 1 tentative).

Étape 4 : Utiliser le sharding

Pour inclure la plate-forme Developer Device dans un workflow d'intégration et de livraison continues (CI/CD), vous devez envisager de partitionner vos tests. Le partitionnement des tests divise un ensemble de tests en sous-groupes (partitions) qui s'exécutent séparément de manière isolée. La plate-forme Developer Device exécute automatiquement chaque shard en parallèle à l'aide de plusieurs appareils et termine l'ensemble des tests en moins de temps.

Attention : Les tests de partitionnement peuvent entraîner des coûts supplémentaires. Bien que le partitionnement des tests réduise le temps nécessaire à l'exécution de tous vos tests, la surcharge liée au démarrage de votre application sur chaque partition peut augmenter les temps individuels des appareils.

Étape 4.1. Choisir une option de partitionnement

Si vos jobs ne comportent qu'un petit nombre de cas de test ou si la durée d'exécution totale de tous les cas de test n'est pas longue, il n'est pas nécessaire d'utiliser le partitionnement. Si vous avez un grand nombre de scénarios de test ou si la durée d'exécution totale de tous vos scénarios de test est longue, envisagez d'utiliser le partitionnement.

La plate-forme Developer Device est compatible avec le partitionnement intelligent et uniforme. Lorsque vous décidez comment partitionner vos tests, tenez compte des options suivantes :

• Si tous les cas de test prennent un temps similaire, utilisez le partitionnement uniforme en divisant tous les cas de test en n partitions.

• Utilisez le partitionnement intelligent lorsque le temps d'exécution de différents cas de test varie considérablement. La plate-forme Developer Device utilise l'historique du temps d'exécution des tests pour créer différents shards et tente de terminer tous les shards dans une durée similaire.

Remarque : Le nombre de partitions est configurable. Par conséquent, lorsque la plate-forme Developer Device exécute de nombreuses partitions en parallèle, les exécutions de tests peuvent être limitées par la disponibilité des appareils. Pour cette raison, nous vous recommandons de spécifier un nombre d'appareils dans l'indicateur --device inférieur ou égal au nombre de segments.

Segmentation uniforme

Pour partitionner vos tests avec un partitionnement uniforme, incluez les indicateurs --sharding-option=uniform et --uniform-sharding-count= dans la commande sessions submit instrumentation comme suit :

gcloud beta device-run sessions submit instrumentation \
    --test path/to/test.apk \
 --device shiba-34,tokay-36 \
    --sharding-option=uniform \
    --uniform-sharding-count=2

Vous devriez obtenir un résultat indiquant Job status: 2 running. Le service crée deux jobs, un pour chaque appareil. Étant donné que les entrées des deux jobs sont identiques, le service centralise la validation et ne l'effectue qu'une seule fois.

Une fois la commande terminée, les deux jobs s'affichent séparément dans le résultat final :

JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   execution-000   PASSED
job-001   execution-000   PASSED

Partitionnement intelligent

Pour fragmenter vos tests avec le smart sharding, incluez les indicateurs --sharding-option=smart, --smart-sharding-max-shard-count=, --smart-sharding-target-duration= (en minutes ou en heures) et --smart-sharding-record-name= dans la commande sessions submit instrumentation comme suit :

gcloud beta device-run sessions submit instrumentation \
    --test path/to/test.apk \
    --device shiba-34,shiba-35,tokay-36 \
    --sharding-option=smart \
    --smart-sharding-max-shard-count=3 \
    --smart-sharding-target-duration=5m \
    --smart-sharding-record-name=test.yaml

Vous devriez voir un résultat final indiquant que trois jobs ont été exécutés :

Session [session-3cd0564a] finished with result [ERROR].
JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   execution-000   PASSED
job-001   execution-000   PASSED
job-002   execution-000   PASSED

Voici un récapitulatif des indicateurs de sharding intelligent utilisés ici :

• --smart-sharding-max-shard-count=SMART_SHARDING_MAX_SHARD_COUNT : spécifiez le nombre maximal de partitions à créer pour le partitionnement intelligent. Si elle n'est pas définie ou si elle est définie sur 0, les limites maximales définies par le système sont utilisées. La plage valide est comprise entre 0 et 20 pour les appareils physiques, et entre 0 et 200 pour les appareils virtuels.

• --smart-sharding-target-duration=SMART_SHARDING_TARGET_DURATION : spécifiez le temps d'exécution cible (par exemple, 2m, 10m, 1h) par shard pour le sharding intelligent. La plage de valeurs autorisée est comprise entre 2 minutes et 1 heure. Obligatoire lorsque --sharding-option=smart.

• --smart-sharding-record-name=SMART_SHARDING_RECORD_NAME : spécifiez le nom du fichier d'enregistrement du partitionnement intelligent, sans l'extension de fichier. Obligatoire lorsque --sharding-option=smart. Ce fichier YAML se trouve dans le bucket Storage Google Cloudspécifié par --bucket-name dans le répertoire smart-sharding/. Si le fichier n'existe pas, il sera créé automatiquement. Sinon, son contenu sera mis à jour à la fin de la session.

Étape 5 : Explorer et gérer votre série de tests

Pour les modes asynchrone et synchrone de la commande sessions submit instrumentation, vous pouvez utiliser la commande sessions describe pour interroger l'état du job pendant l'exécution ou obtenir le résultat une fois qu'il est terminé :

gcloud beta device-run sessions describe SESSION_ID

La sortie récapitule les résultats des tests et fournit des liens vers les résultats dans la console Google Cloud . Exemple :

Session SESSION_ID finished with result [FAILED].
Result files are stored at [https://console.cloud.google.com/storage/browser/BUCKET_NAME/automation/sessions/SESSION_ID/].
JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   all             FAILED: 2 test cases failed, 5 passed

Utilisez la commande suivante pour lister toutes vos sessions en cours et terminées :

gcloud beta device-run sessions list

Vous recevrez un résultat contenant la liste des sessions de votre projet, qui ressemblera à ceci :

SESSION_ID                                    START_TIME                STATE
session-4825e153                              2026-07-28T16:38:43.155Z  DONE
session-813ca602                              2026-07-28T22:40:32.415Z  DONE
session-67cd0570                              2026-07-16T08:25:55.474Z  DONE
session-17cc299c                              2026-07-14T14:31:33.649Z  DONE
session-911d0763                              2026-07-09T00:39:02.051Z  DONE
session-4e943fea                              2026-07-15T23:08:32.252Z  DONE
session-0132e458                              2026-08-20T18:33:19.751Z  DONE
session-1077f07b                              2026-07-28T22:35:43.848Z  DONE
session-71b054c6                              2026-07-15T01:15:41.643Z  DONE
session-4f8b2e45                              2026-08-06T23:11:56.161Z  DONE

La commande sessions list est compatible avec toutes les options standards des indicateurs Google Cloud CLI. Exemple :

gcloud beta device-run sessions list --limit 5

Les résultats ressemblent à ce qui suit :

SESSION_ID                            START_TIME                STATE
session-4825e153                      2026-07-28T16:38:43.155Z  DONE
session-813ca602                      2026-07-28T22:40:32.415Z  DONE
93ec2df2-d5bf-4c36-b7f7-c2a4fb0dc3ce  2026-07-03T05:10:58.015Z  DONE
session-67cd0570                      2026-07-16T08:25:55.474Z  DONE
session-17cc299c                      2026-07-14T14:31:33.649Z  DONE

Pour trouver toutes les sessions en cours d'exécution, exécutez la commande suivante :

gcloud beta device-run sessions list --filter RUNNING

Si vous avez des sessions en cours d'exécution, vous verrez des résultats semblables à ceux-ci :

SESSION_ID        START_TIME  STATE
session-d7ff8b81              RUNNING

Sinon, vous recevrez Listed 0 items..

Pour annuler une session en cours d'exécution, exécutez cette commande avec votre ID de session :

gcloud beta device-run sessions cancel SESSION_ID

La commande répond immédiatement, car la session est uniquement marquée comme devant être annulée. L'annulation s'effectue de manière asynchrone dans le backend.

Si la session est déjà terminée, seul l'état actuel est imprimé. Demander l'annulation d'une session terminée n'est pas une erreur.

Étapes suivantes

Ensuite, recherchez et analysez les journaux.