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

Bienvenue dans 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 XCTest.

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

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

Capacités clés

Device Run de Developer Device Platform est un service Google Cloud qui vous permet d'exécuter des suites de tests automatisés sur des appareils mobiles physiques et virtuels. Conçu pour les workflows d'intégration et de livraison continues (CI/CD) modernes, 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 faire évoluer des suites de tests sur du matériel dédié et des environnements virtuels.

1. Tests automatisés multiplates-formes

  • 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 listés dans le catalogue d'appareils à l'aide d'identifiants d'OS et de modèle (par exemple, des modèles Pixel ou iPhone) via l'option --device.
  • 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 options --device.

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

  • Envois synchrones et asynchrones : les tests s'exécutent de manière synchrone par défaut, et un résumé s'affiche une fois l'opération terminée. L'ajout de l'option --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 des limites de durée d'exécution avec --instrumentation-timeout ou --xctest-timeout.
  • Nouvelles tentatives de tests irréguliers : définissez le nombre maximal de nouvelles tentatives pour les exécutions de tests irréguliers à l'aide de l'option --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 des tests.
  • 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é du bucket : utilise automatiquement par défaut un bucket de projet nommé PROJECT_ID-devicerun ou redirige vers un bucket personnalisé spécifié via l'option --bucket-name. Vous contrôlez entièrement ce bucket et devrez supprimer manuellement son contenu lorsqu'il ne sera plus nécessaire, 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 d'accès cloud directs : référencez directement les chemins d'accès gs:// existants pour les fichiers volumineux afin d'éliminer les frais 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 d'application partagé et isoler les plantages de l'application.
  • Segmentation des tests :
    • Segmentation uniforme : répartit uniformément les scénarios de test sur un nombre spécifié de segments (--sharding-option=uniform).
    • Segmentation intelligente : utilise les données d'historique d'exécution des tests pour équilibrer dynamiquement les scénarios de test entre les segments, en ciblant une durée d'exécution totale spécifique (--sharding-option=smart).

6. Gestion et diagnostic des sessions

  • Contrôle total de la session : listez, décrivez, filtrez ou annulez des tests actifs ou historiques à l'aide de sessions list, sessions describe et sessions cancel.
  • Validation précoce des entrées : effectue une validation automatique des binaires de test et des artefacts de configuration envoyés, en affichant des détails explicites sur les erreurs et leurs causes (par exemple, des incohérences de package cible) lorsque des erreurs se produisent.

Paramètres de base

Options obligatoires

Notez que ces options 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 communes aux sessions Device Run.

Chemins d'accès Cloud Storage d'entrée et de sortie

  • 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 de l'option --bucket-name=, la Google Cloud CLI utilisera un bucket par défaut nommé PROJECT_ID-devicerun.
  • Fichiers d'entrée : lorsque vous spécifiez un chemin d'accès local avec les options --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 d'accès cloud : l'importation de fichiers volumineux pouvant prendre du temps, vous pouvez les référencer directement à l'aide de leurs chemins d'accès Cloud Storage gs:// pour gagner du temps.
  • 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 un ERROR plutôt qu'un PASSED ou un FAILED lorsqu'il rencontre une entrée erroné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

Étapes suivantes

Exécutez un test d'instrumentation Android, un exécutable Android ou un XCTest iOS avec Developer Device Platform.