Présentation de l'exécution des appareils sur la plate-forme Developer Device

Aperçu

Ce produit ou cette fonctionnalité est soumis aux "Conditions des offres pré-DG" de la section "Conditions d'utilisation 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.

Bienvenue sur Developer Device Platform Device Run, qui vous permet d'exécuter des tests et des exécutables sur des appareils Android physiques et virtuels, ainsi que sur des appareils iOS physiques dans le cloud. Cette page récapitule les fonctionnalités et décrit les points communs entre l'exécution de tests d'instrumentation Android, d'exécutables Android et de tests iOS. Pour connaître les étapes spécifiques à la plate-forme, consultez Device Run for Android et Device Run for iOS pour

Si vous migrez de Firebase Test Lab vers Developer Device Platform, consultez notre guide de migration, traduction des commandes et des flags, ainsi que la compétence de migration pour les agents d'IA.

Pour utiliser cette Google Cloud CLI, vous devez fournir votre Google Cloud ID de projet. Pour obtenir un résumé des commandes, consultez : gcloud beta device-run

Conseil : Ajoutez --help à n'importe quelle commande gcloud pour afficher des informations d'utilisation détaillées.

Capacités clés

Developer Device Platform Device Run est un Google Cloud service qui vous permet d' exécuter des suites de tests automatisées sur des appareils mobiles physiques et virtuels. Conçu pour les workflows modernes d'intégration continue et de livraison continue (CI/CD), Device Run offre un contrôle en ligne de commande via la Google Cloud CLI (gcloud beta device-run), ce qui permet aux équipes d'exécuter, de gérer et de mettre à l'échelle des suites de tests sur du matériel dédié et des environnements virtuels.

1. Tests automatisés multiplateformes

• Compatibilité avec Android et iOS : Device Run est compatible avec les frameworks de test intégrés, y compris les tests d'instrumentation Android (.apk), les exécutables Android (binaires compilés) et les XCTests iOS (.ipa ou .zip).
• Ciblage flexible des appareils : ciblez des appareils physiques ou virtuels spécifiques répertoriés dans le catalogue d'appareils à l'aide d'identifiants d'OS et de modèle (par exemple, les modèles Pixel ou iPhone) via le --device flag.
• Exécution parallèle sur plusieurs appareils : exécutez des suites de tests identiques simultanément sur plusieurs appareils en spécifiant des ID d'appareil séparés par une virgule ou en fournissant plusieurs --device flags.

2. Modes d'exécution et contrôles flexibles

• Envois synchrones et asynchrones : les exécutions de test fonctionnent de manière synchrone par défaut et affichent un résumé une fois terminées. L'ajout du flag --async renvoie immédiatement un ID de session pour une exécution non bloquante, qui peut être surveillée ultérieurement à l'aide de gcloud beta device-run sessions wait.
• Délais d'exécution personnalisés*: configurez les limites de durée d'exécution avec --instrumentation-timeout ou --xctest-timeout.
• Nouvelles tentatives de test instable : définissez le nombre maximal de nouvelles tentatives pour les exécutions de test instables à l’aide du flag --flaky-test-attempts.

3. Gestion des versions logicielles et des dépendances

• Environnements de test configurables*: découvrez, inspectez et sélectionnez des versions d'environnement logiciel spécifiques , telles que AndroidX Test Orchestrator et Apple Xcode, avant de lancer les exécutions de test.
• Découverte de versions : utilisez les commandes gcloud beta device-run software-versions list et describe pour afficher les packages logiciels actifs, les versions d'OS compatibles et les spécifications d'exécution par défaut.

4. Gestion du stockage et des artefacts

• Intégration de Cloud Storage : les entrées de test (APK, IPA, applications compatibles) et les artefacts de sortie (journaux, rapports de test) sont stockés dans Cloud Storage.
• Flexibilité des buckets : par défaut, un bucket de projet nommé PROJECT_ID-devicerun est utilisé, ou un bucket personnalisé spécifié via le flag --bucket-name est utilisé. Vous contrôlez entièrement ce bucket et devrez supprimer manuellement son contenu lorsque vous n'en aurez plus besoin ou configurer la gestion automatisée du cycle de vie sur le bucket. Pour obtenir des instructions, consultez À propos de la suppression d'objets.
• Chemins cloud directs : référencez directement les chemins gs:// existants pour les fichiers volumineux afin d'éliminer la surcharge d'importation.

5. Fonctionnalités avancées de test Android

• Android Test Orchestrator : isolez l'exécution des tests en exécutant chaque test dans sa propre instance Instrumentation pour éviter l'état partagé de l'application et isoler les plantages de l'application.
• Segmentation des tests:
  • Segmentation uniforme : divise uniformément les scénarios de test sur un nombre spécifié de segments (--sharding-option=uniform).
  • Segmentation intelligente : utilise les données d'exécution de test historiques pour équilibrer dynamiquement les scénarios de test sur les segments, en ciblant une durée d'exécution totale spécifique (--sharding-option=smart).

6. Gestion des sessions et diagnostics

• Contrôle complet des sessions : listez, décrivez, filtrez ou annulez les exécutions de test actives ou historiques à l'aide de sessions list, sessions describe et sessions cancel.
• Validation anticipée des entrées : effectue une validation automatique sur les binaires de test et les artefacts de configuration envoyés, en affichant des détails explicites sur les erreurs et les causes profondes (telles que les incompatibilités de packages cibles) en cas d'erreur.

Paramètres de base

Flags obligatoires

Notez que ces flags sont obligatoires :

• Appareil : spécifiez un appareil à l'aide de --device : --device shiba-35 ou --device iphonese3-18-4
• Test ou exécutable : spécifiez le package de test à l'aide de --test (--test /path/to/test.apk ou --test /path/to/MyTests.zip) pour les exécutions de test, ou spécifiez le binaire ou le script exécutable à l'aide de --executable (--executable /path/to/my_executable) pour les exécutions d'exécutables Android.

Les options de configuration suivantes sont courantes dans les sessions Device Run.

Chemins d'entrée et de sortie Cloud Storage

• Bucket Cloud Storage personnalisé : vous pouvez spécifier un bucket Cloud Storage personnalisé pour les entrées et les sorties : --bucket-name=my-custom-bucket. Si vous ne spécifiez pas de bucket Cloud Storage à l'aide du flag --bucket-name=, la Google Cloud CLI utilise un bucket par défaut nommé PROJECT_ID-devicerun.
• Fichiers d'entrée : lorsque vous spécifiez un chemin local avec les flags --test, --executable, --apps, --additional-apps, --other-files-to-push, ou --xctestrun-file, la Google Cloud CLI le copie automatiquement dans votre bucket Cloud Storage sous gs://BUCKET_NAME/automation/inputs/DATE_TIME_FOUR_CHARS_SUFFIX/ chaque fois que vous exécutez la commande, où BUCKET_NAME est défini par défaut sur PROJECT_ID-devicerun.
• Chemins cloud : comme l'importation de fichiers volumineux peut prendre du temps, vous pouvez les référencer directement à l'aide de leurs chemins Cloud Storage gs:// pour gagner du temps d'importation.
• Fichiers de résultats : les artefacts de sortie sont importés dans votre bucket Cloud Storage sous gs://BUCKET_NAME/automation/sessions/session-[SESSION_ID]/.

Validation des entrées

Developer Device Platform tente de valider vos entrées, y compris les artefacts, et renvoie une ERROR plutôt que PASSED ou FAILED lorsqu'une entrée erronée est détectée :

Session [session-94b57778] finished with result [ERROR].
JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   execution-000   ERROR

Ajoutez maintenant --full à la commande sessions describe pour afficher plus de détails sur la session :

gcloud beta device-run sessions describe --full session-94b57778

Le résultat ressemble à ceci :

name: projects/user-test1/locations/global/sessions/session-94b57778
sessionConfig:
  displayName: instrumentation-session
  jobConfigs:
  -   action:
      androidInstrumentationTest:
        testInstallable:
          files:
          -   gcsInputFile:
              path: gs://user-test1-devicerun/automation/inputs/2026-09-16_18:55.17372947_EECF/my-test.apk
    allocationConfig:
      deviceConfigs:
      -   actions:
        -   androidLogcat: {}
        requirement:
          deviceId: mediumphone-arm-34
    displayName: job-000
  outputDirectoryConfig:
    gcsOutputDirectory:
      path: gs://user-test1-devicerun/automation/sessions
sessionReport:
  endTime: '2026-09-16T18:55:49.721Z'
  id: ed681f23-669b-4464-8a93-b28456e58136
  jobReports:
  -   displayName: job-000
    endTime: '2026-09-16T18:55:45.839Z'
    executionReports:
    -   displayName: execution-000
      endTime: '2026-09-16T18:55:46.694Z'
      id: ce370173-af94-4dd7-acc6-0863e4d2e9ec
      result:
        cause:
          summary:
            message: The instrumentation target package does not match any of the
              installable packages.
            reason: INSTRUMENTATION_TARGET_MISMATCH
            type: CUSTOMER
        resultType: ERROR
      startTime: '1970-01-01T00:00:00Z'
      status:
        statusType: PENDING
    id: 953b5106-3c20-40f0-aceb-18af89cd1b83
    result:
      cause:
        summary:
          message: The instrumentation target package does not match any of the installable
            packages.
          reason: INSTRUMENTATION_TARGET_MISMATCH
          type: CUSTOMER
      resultType: ERROR
    startTime: '2026-09-16T18:55:31.651Z'
    status:
      statusType: DONE
  result:
    resultType: ERROR
  startTime: '2026-09-16T18:55:24.442Z'
  status:
    statusType: DONE

Étape suivante

Exécutez un test ou un exécutable Android ou exécutez un test iOS avec Developer Device Platform.