Cette page fournit une aide au dépannage et répond aux questions fréquentes sur l'exécution de tests avec la plate-forme Developer Device. Si vous ne trouvez pas ce que vous cherchez ou si vous avez besoin d'aide, contactez-nous.
Dépannage
Pourquoi mon test prend-il autant de temps à s'exécuter ?
Lorsque vous sélectionnez un appareil avec un niveau de capacité élevé dans le catalogue Developer Device Platform, les tests peuvent démarrer plus rapidement. Lorsque la capacité d'un appareil est faible, les tests peuvent prendre plus de temps. Si le nombre de tests appelés est beaucoup plus élevé que la capacité des appareils sélectionnés, les tests peuvent prendre plus de temps à se terminer.
Les tests exécutés sur n'importe quel niveau de capacité des appareils peuvent prendre plus de temps en raison des facteurs suivants :
- le trafic, qui affecte la disponibilité des appareils et la vitesse des tests.
- Défaillances de l'appareil ou de l'infrastructure, qui peuvent se produire à tout moment. Pour vérifier si une infrastructure a été signalée pour la plate-forme d'appareils pour les développeurs, consultez le tableau de bord Google Cloud État de santé personnalisé des services.
Pour en savoir plus sur la capacité des appareils dans Developer Device Platform, consultez le catalogue d'appareils.
Pourquoi les résultats des tests ne sont-ils pas concluants ?
Les résultats de tests non concluants sont généralement dus à des exécutions de tests annulées ou à des erreurs d'infrastructure. En plus de PASSED et FAILED, la plate-forme Developer Device Platform peut renvoyer ERROR, TIMED_OUT et CANCELLED.
Les erreurs d'infrastructure sont dues à des problèmes internes de la plate-forme Developer Device, comme des erreurs réseau ou des comportements inattendus des appareils. La plate-forme pour les appareils des développeurs effectue en interne plusieurs nouvelles tentatives pour les tests qui génèrent des erreurs d'infrastructure avant de signaler un résultat non concluant.
Pour déterminer la cause de l'erreur, procédez comme suit :
- Recherchez les pannes connues dans le tableau de bord Service Health de Google Cloud.
Réessayez le test sur la plate-forme Developer Device pour vérifier qu'il est reproductible.
Si possible, essayez d'exécuter le test sur un autre appareil ou type d'appareil. Pour en savoir plus, consultez le catalogue d'appareils.
Pourquoi le partitionnement a-t-il rallongé l'exécution de mes tests ?
La segmentation peut entraîner une durée d'exécution plus longue de vos tests lorsque le nombre de segments que vous avez spécifié dépasse le nombre d'appareils disponibles pour une utilisation dans la plate-forme Developer Device. Pour éviter cette situation, limitez le nombre d'appareils au nombre de partitions. Pour en savoir plus sur le choix d'un autre appareil, consultez le catalogue d'appareils.
Pourquoi mon test met-il autant de temps à démarrer ?
Lorsque vous envoyez une demande de test, votre application est d'abord validée, signée à nouveau, etc., en vue de l'exécution des tests sur un appareil. Normalement, ce processus prend moins de quelques secondes, mais il peut être affecté par des facteurs tels que la taille de votre application.
Une fois votre application préparée, les exécutions de tests sont planifiées et restent dans une file d'attente jusqu'à ce qu'un appareil soit prêt à les exécuter.
Pourquoi mon test prend-il autant de temps ?
Une fois l'exécution du test terminée, les artefacts de test sont téléchargés depuis l'appareil, traités et importés dans Cloud Storage. La durée de cette étape peut dépendre du nombre et de la taille des artefacts.
Dépannage spécifique à Android
L'application ne renvoie pas de données et je ne trouve pas les captures d'écran
Les artefacts d'exécution des tests (tels que les captures d'écran et les fichiers journaux) sont stockés dans Cloud Storage et affichés directement dans la console Google Cloud . Vérifiez que vous avez attribué des rôles au niveau du projet.
Notez également que la plate-forme Developer Device dispose d'un agent de service dédié qui utilise ses propres identifiants plutôt que les vôtres pour :
- Lire et écrire dans des buckets et des objets Cloud Storage
- Télécharger les fichiers d'entrée Cloud Storage vers le système interne
- Importer des fichiers du système interne vers le bucket de sortie Cloud Storage
Il est possible que vous ayez accès à un bucket et à un fichier Cloud Storage, mais que ce bucket appartienne à un autre projet Google Cloud que celui utilisé dans DDP. Par conséquent, le compte de service de la plate-forme Developer Device n'y a pas accès.
Vous pouvez également disposer de contrôles d'accès supplémentaires sur des buckets individuels. Pour savoir comment inclure des fichiers dans vos tests, consultez Exécution sur l'appareil.
Pourquoi les résultats des scénarios de test d'instrumentation sont-ils partiels ou manquants ?
Lorsque vous exécutez des tests d'instrumentation, il est possible que le nombre total de scénarios de test soit inférieur à ce que vous attendiez. Cela est souvent dû au fait que la plate-forme de l'appareil de développement n'est pas en mesure d'analyser le logcat pour les repères de début ou de fin de scénario de test qui sont généralement générés par AndroidJUnitRunner.
Voici quelques causes courantes de ce problème :
| Description du problème | Solution possible |
|---|---|
| Le scénario de test n'a pas été exécuté en raison d'un délai d'attente dépassé. Si la durée totale des tests est supérieure à un délai d'attente que vous avez spécifié ou à un délai d'attente maximal, la plate-forme Developer Device annule le reste des scénarios de test. |
|
| Le scénario de test n'a pas pu être exécuté, car il s'est arrêté prématurément ou a été bloqué. Le cas de test peut se fermer prématurément en raison d'une exception non interceptée ou d'une erreur d'assertion. Les scénarios de test peuvent se retrouver bloqués dans une boucle infinie ou ne pas pouvoir se poursuivre, par exemple si l'application n'affiche pas la vue correcte et que le scénario de test ne peut pas effectuer l'action sur l'UI. |
Vérifiez la vidéo et le logcat pour déterminer où le test s'est arrêté.
|
Un lanceur de test personnalisé (y compris l'extension AndroidJUnitRunner) a planté de manière inattendue ou a écrit des marqueurs de début ou de fin de scénario de test inattendus dans logcat.
|
Vérifiez le code de votre programme de test. |
Un nombre excessif de journaux a été écrit dans logcat, ce qui a surchargé le tampon ou provoqué le plantage du processus logcat.
|
Réduisez les écritures à logcat.
|
| L'application testée a planté. | Déboguez votre application. |
Questions fréquentes (FAQ)
Où puis-je trouver des informations sur les tarifs de la plate-forme Developer Device ?
Pour en savoir plus, consultez Questions sur la tarification et la facturation.
Où puis-je trouver des informations sur l'appareil, comme la résolution, etc.?
Des informations détaillées sur l'appareil sont disponibles via l'API et sont accessibles à partir de la CLI Developer Device Platform avec la commande device-run devices describe <device-id> :
gcloud beta device-run devices describe DEVICE_ID
Comment savoir si le trafic qui atteint mon backend provient de la plate-forme Developer Device ?
Depuis votre backend, vous pouvez déterminer si le trafic provient d'appareils de test hébergés sur la plate-forme Developer Device en vérifiant l'adresse IP source par rapport à nos plages d'adresses IP.
La plate-forme Developer Device Platform fonctionne-t-elle avec VPC-SC ?
La plate-forme Developer Device ne fonctionne pas avec VPC-SC, qui bloque la copie d'applications et d'autres artefacts de test entre le stockage interne de la plate-forme Developer Device et les buckets de résultats des utilisateurs.
Comment réduire les tests instables sur la plate-forme Developer Device ?
Pour détecter les comportements instables dans vos tests, nous vous recommandons d'utiliser l'option --flaky-test-attempts. Les réexécutions de tests pour éliminer les faux échecs sont facturées ou décomptées de votre quota quotidien de la même manière que les exécutions de tests normales.
Tenez bien compte des éléments suivants :
- Par défaut, DDP exécute la nouvelle tentative de manière séquentielle pour réduire les coûts. Les utilisateurs doivent définir
--flaky-test-parallel-retrypour qu'il s'exécute en parallèle. - L'indicateur
--flaky-test-retry-leveldéfinit si la tentative doit être effectuée au niveaushardou au niveautestindividuel. La valeur par défaut estshard. Définissez-le surtestpour réduire la taille et la durée du test de nouvelle tentative.
Questions fréquentes spécifiques à iOS
La plate-forme Developer Device est-elle compatible avec Appium, Flutter/FlutterDriver, ReactNative/Jest ou Cucumber ?
Bien que certains de ces éléments figurent dans notre feuille de route, nous ne pouvons pas nous engager à prendre en charge ces plates-formes de test et de développement d'applications.
Pourquoi des vidéos manquent-elles dans les résultats de mon test iOS ?
La prise en charge des vidéos dans les résultats est prévue pour iOS 18 ou version ultérieure.
Questions fréquentes spécifiques à Android
La Developer Device Platform est-elle compatible avec les appareils connectés ?
Oui. La plate-forme Developer Device est compatible avec la Google Pixel Watch. Vous pouvez désormais exécuter des tests sur votre application Wear OS autonome sur des Google Pixel Watch. Pour en savoir plus sur les appareils Developer Device Platform, consultez le catalogue d'appareils.
La Developer Device Platform est-elle compatible avec les derniers appareils Google ?
Oui. La plate-forme Developer Device est compatible avec la Google Pixel Tablet et le Google Pixel Fold. Vous pouvez exécuter vos tests sur vos appareils physiques autonomes. Pour en savoir plus sur les appareils disponibles dans Developer Device Platform, consultez le catalogue d'appareils.
La plate-forme Developer Device est-elle compatible avec Appium, Flutter/FlutterDriver, ReactNative/Jest ou Cucumber ?
Bien que certains de ces éléments figurent dans notre feuille de route, nous ne pouvons pas nous engager à prendre en charge ces plates-formes de test et de développement d'applications. Toutefois, si vous avez créé votre application avec un framework compatible avec Espresso (par exemple, Flutter), vous pouvez écrire un test d'instrumentation à l'aide d'Espresso, puis exécuter le test dans la plate-forme Developer Device.
La plate-forme Developer Device Platform est-elle compatible avec le test d'applications obscurcies, par exemple avec ProGuard ou R8 ?
La plate-forme Developer Device ne prend pas explicitement en charge l'obscurcissement ni le désobscurcissement. Bien que l'application s'exécute probablement, toutes les données de l'application obscurcies, comme les traces de la pile, apparaîtront comme obscurcies dans les journaux.
Puis-je utiliser mon appareil pliable dans différents états et positions de pliage lors des tests sur la Developer Device Platform ?
Oui. Vous pouvez tester votre appareil pliable dans des états et positions pliés.
Les appareils pliables ont différents états, comme FLAT (entièrement ouvert) ou HALF_OPENED (entre complètement ouvert et complètement fermé).
Les postures, quant à elles, se composent d'une orientation spécifique de l'appareil et d'un état pliable. Par exemple, la position sur table, qui est un état HALF_OPENED en orientation horizontale, ou la position livre, qui est un état HALF_OPENED en orientation verticale.
Si vous exécutez des tests d'instrumentation, vous pouvez utiliser la bibliothèque Jetpack WindowManager et suivre la documentation Tester votre application sur des appareils pliables pour effectuer des tests dans différents états et positions.
Vous pouvez également interagir avec les états disponibles, qui sont spécifiques à l'appareil, à l'aide de adb
shell command cmd device_state.
- Pour lister l'état actuel, exécutez
adb shell cmd device_state state. - Pour définir ou remplacer l'état actuel, exécutez
adb shell cmd device_state state <IDENTIFIER>. - Pour réinitialiser l'état, exécutez
adb shell cmd device_state state reset. - Pour vérifier les états disponibles, exécutez la commande
adb shell cmd device_state print-statessur l'appareil pliable.
Google Pixel Fold (ID de modèle felix)
$ adb shell cmd device_state print-states
Supported states: [
DeviceState{identifier=0, name='CLOSED', app_accessible=true},
DeviceState{identifier=1, name='HALF_OPENED', app_accessible=true},
DeviceState{identifier=2, name='OPENED', app_accessible=true},
DeviceState{identifier=3, name='REAR_DISPLAY_STATE', app_accessible=true},
]
Samsung Galaxy Z Fold4 (ID de modèle q4q)
$ adb shell cmd device_state print-states
Supported states: [
DeviceState{identifier=0, name='CLOSE', app_accessible=true},
DeviceState{identifier=1, name='TENT', app_accessible=true},
DeviceState{identifier=2, name='HALF_FOLDED', app_accessible=true},
DeviceState{identifier=3, name='OPEN', app_accessible=true},
]
Puis-je essayer Developer Device Platform si je n'ai pas d'application ?
Contrairement aux autres produits Developer Device Platform, vous n'avez pas besoin d'ajouter un SDK Developer Device Platform pour utiliser Developer Device Platform. Si vous n'avez pas encore d'application, vous pouvez télécharger un fichier APK en ligne ou créer une application et un fichier APK de test à partir de l'un des exemples du dépôt GitHub AndroidX. Notez qu'un test d'instrumentation nécessite à la fois une application et un APK de test qui sont créés à partir du code source. Pour en savoir plus, consultez Tests instrumentés.
Pour en savoir plus sur les fonctionnalités de Developer Device Platform, consultez la présentation du produit DDP.
Quels sont les meilleurs appareils pour les tests de comparaison de captures d'écran ?
Le test de comparaison de captures d'écran consiste à comparer les images d'écran obtenues lors de l'exécution d'un test à des images de référence représentant le comportement attendu. Ces tests peuvent être plus fragiles sur certains types d'appareils que sur d'autres. Nous vous recommandons de cibler les appareils émulateurs Arm (*.arm) pour ces types de tests. Les appareils émulateurs Arm utilisent des images très similaires ou identiques aux émulateurs génériques Android Studio.
Nous vous recommandons également d'étudier les bibliothèques de test qui peuvent vous aider à rendre les tests de capture d'écran plus robustes en cas de modifications prévues.
La Developer Device Platform met-elle à jour les appareils virtuels ?
Oui. Les appareils virtuels sont mis à jour lorsque les modifications suivantes sont apportées :
- Mises à jour des images existantes
- Obsolescence des niveaux d'API antérieurs
- Ajout de nouveaux niveaux d'API Android
Comment activer les rapports sur la couverture ?
Pour activer les rapports de couverture, ajoutez coverage=true au champ additional-test-options.
Si vous utilisez Android Test Orchestrator, vous devez fournir un chemin d'accès au répertoire pour stocker les résultats de couverture :
--additional-test-options coverage=true,coverageFilePath=/sdcard/Download/
Si vous n'utilisez pas Orchestrator, vous pouvez spécifier un chemin d'accès au fichier :
--additional-test-options coverage=true,coverageFile=/sdcard/Download/coverage.ec
Comment me connecter à une application Wear sans téléphone ?
Si votre application nécessite normalement un téléphone pour la connexion, vous pouvez créer une variante de compilation qui ignore la connexion et utilise un jeton intégré à votre compilation de test, ou lire à partir de fichiers sur le disque généralement envoyés à l'aide de l'indicateur --other-files-to-push.