Dépannage et questions fréquentes concernant Test Lab

Pourquoi mon test prend-il autant de temps ?

Lorsque vous sélectionnez un appareil avec un niveau de capacité élevé dans le catalogue Test Lab, les tests peuvent démarrer plus rapidement. Lorsque la capacité d'un appareil est faible, l'exécution des tests peut prendre plus de temps. Si le nombre de tests appelés est bien supérieur à la capacité des appareils sélectionnés, les tests peuvent prendre plus de temps.

Les tests exécutés sur n'importe quel niveau de capacité d'appareil 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 survenir à tout moment. Pour vérifier si une infrastructure est signalée pour Test Lab, consultez le tableau de bord d'état Firebase.

Pour en savoir plus sur la capacité des appareils dans Test Lab, consultez les informations sur la capacité des appareils pour Android et iOS.

Pourquoi les résultats de mes tests ne sont-ils pas concluants ?

Les résultats de test non concluants sont généralement dus à des exécutions de test annulées ou à des erreurs d'infrastructure.

Les erreurs d'infrastructure sont causées par des problèmes internes à Test Lab, comme des erreurs réseau ou des comportements inattendus de l'appareil. Test Lab retire en interne les exécutions de test qui produisent des erreurs d'infrastructure plusieurs fois avant de signaler un résultat non concluant. Toutefois, vous pouvez désactiver ces nouvelles tentatives à l'aide de failFast.

Pour déterminer la cause de l'erreur, procédez comme suit :

1. Vérifiez si des pannes sont connues dans le tableau de bord d'état Firebase.

2. Réessayez le test dans Test Lab pour vérifier qu'il est reproductible.

3. Essayez d'exécuter le test sur un autre appareil ou un autre type d'appareil, le cas échéant.

Si le problème persiste, contactez l'équipe Test Lab sur le canal #test-lab de Firebase Slack.

Pourquoi le partitionnement a-t-il allongé la durée d'exécution de mes tests ?

La segmentation peut allonger la durée d'exécution de vos tests lorsque le nombre de segments que vous avez spécifié dépasse le nombre d'appareils disponibles dans Test Lab. Pour éviter ce problème, essayez d'utiliser un autre appareil. Pour en savoir plus sur le choix d'un autre appareil, consultez Capacité de l'appareil.

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 d'exécuter des tests sur un appareil. Normalement, ce processus se termine en 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 test sont planifiées et restent dans une file d'attente jusqu'à ce qu'un appareil soit prêt à les exécuter. Tant que toutes les exécutions de test ne sont pas terminées, l'état de la matrice est "En attente" (que les exécutions de test soient dans la file d'attente ou en cours d'exécution).

Pourquoi mon test met-il autant de temps à se terminer ?

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 être affectée par la quantité et la taille des artefacts.

L'application ne renvoie pas de données et ne trouve pas les captures d'écran

Les artefacts d'exécution de test (tels que les captures d'écran et les fichiers journaux) sont stockés dans Google Cloud Storage et affichés directement dans la console Firebase. Si l'exécution de votre test a eu lieu au cours des 90 derniers jours, vérifiez que vous avez attribué des rôles au niveau du projet (propriétaire du projet, éditeur du projet ou lecteur du projet). Veuillez également vous assurer que Cloud Audit Logging n'est pas activé pour votre projet ou votre organisation.

Si l'exécution a été effectuée il y a plus de 90 jours, il est fort probable que les artefacts de test aient été automatiquement supprimés. Vous pouvez vérifier la configuration du bucket de résultats en cliquant sur l'onglet Résultats des tests dans le tableau de bord Test Lab. Le bucket de résultats par défaut est configuré pour conserver les objets pendant 90 jours.

Pour conserver vos artefacts de test plus longtemps, exécutez la commande gcloud firebase test android run avec l'option --results-bucket et transmettez le nom du bucket de résultats. Pour plus d'informations, consultez la documentation de référence de gcloud firebase test android run.

Pourquoi les résultats de mes scénarios de test d'instrumentation sont-ils partiels ou manquants ?

Lorsque vous exécutez des tests d'instrumentation, vous pouvez voir des erreurs de test indiquant des résultats partiels qui contiennent des messages tels que Test run failed to complete. Expected x tests, received y (où y est inférieur à x). Cette erreur signifie que Test Lab n'a pas pu 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 les causes courantes de ce problème :

Quels sont les quotas sans frais pour Test Lab ? Que dois-je faire si je n'en dispose plus ?

Firebase Test Lab propose des quotas sans frais pour les tests sur les appareils et l'utilisation des API Cloud. Notez que le quota de test utilise le forfait Firebase standard, contrairement aux quotas de l'API Cloud.

• Quota de test

  Les quotas de test sont déterminés par le nombre d'appareils utilisés pour exécuter les tests. Le forfait Spark de Firebase inclut un quota de tests fixe sans frais pour les utilisateurs. Pour le forfait Blaze, vos quotas peuvent augmenter si votre utilisation de Google Cloud s'accroît au fil du temps. Si vous atteignez votre quota de tests, attendez le lendemain ou passez au forfait Blaze si vous utilisez actuellement le forfait Spark. Si vous utilisez déjà le forfait Blaze, vous pouvez demander une augmentation de quota. Pour en savoir plus, consultez Tester le quota.

  Vous pouvez surveiller l'utilisation de votre quota de test dans la console Google Cloud.

• Quotas de l'API Cloud Testing

  L'API Cloud Testing est soumise à deux limites de quota : le nombre de requêtes par jour et par projet, et le nombre de requêtes toutes les 100 secondes et par projet. Vous pouvez surveiller votre utilisation dans la console Google Cloud.

• Quotas de l'API Cloud Tool Results

  L'API Cloud Tool Results est soumise à deux limites de quota : les requêtes par jour et par projet, et les requêtes toutes les 100 secondes et par projet. Vous pouvez surveiller votre utilisation dans la console Google Cloud.

  Pour en savoir plus sur les limites d'API, consultez Quotas d'API Cloud pour Test Lab. Si vous avez atteint un quota d'API :

  • Envoyez une demande d'augmentation de vos quotas en modifiant vos quotas directement dans la console Google Cloud (notez que la plupart des limites sont définies sur le maximum par défaut).

  • Demandez des quotas d'API plus élevés en remplissant un formulaire de demande dans la console Google Cloud ou en contactant l'assistance Firebase.

Comment savoir si le trafic qui atteint mon backend provient de Test Lab ?

Depuis votre backend, vous pouvez déterminer si le trafic provient d'appareils de test hébergés par Firebase en comparant l'adresse IP source à nos plages d'adresses IP.

Test Lab fonctionne-t-il avec VPC-SC ?

Test Lab ne fonctionne pas avec VPC-SC, qui bloque la copie des applications et d'autres artefacts de test entre l'espace de stockage interne de Test Lab et les buckets de résultats des utilisateurs.

Comment détecter les tests irréguliers dans Test Lab ?

Pour détecter un comportement irrégulier dans vos tests, nous vous recommandons d'utiliser l'option --num-flaky-test-attempts . Les réexécutions de tests instables 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 :

• L'intégralité de l'exécution du test est relancée lorsqu'un échec est détecté. Il n'est pas possible de relancer uniquement les scénarios de test ayant échoué.
• Les exécutions de nouvelles tentatives de déflaking sont planifiées pour s'exécuter en même temps, mais il n'est pas garanti qu'elles s'exécutent en parallèle, par exemple lorsque le trafic dépasse le nombre d'appareils disponibles.

Test Lab est-il compatible avec Appium, Flutter/FlutterDriver, ReactNative/Jest ou Cucumber ?

Bien que certains de ces éléments figurent sur notre feuille de route, nous ne sommes actuellement pas en mesure de nous engager à prendre en charge ces plates-formes de test et de développement d'applications.

Où puis-je trouver les détails de l'appareil, comme la résolution, etc.?

Des informations détaillées sur l'appareil sont disponibles via l'API et sont accessibles depuis le client gcloud à l'aide de la commande describe :

gcloud firebase test ios models describe MODEL

Puis-je utiliser la segmentation avec les tests iOS ?

Le partitionnement n'est pas compatible de manière native avec Test Lab pour iOS. Toutefois, vous pouvez utiliser le client Flank pour segmenter les scénarios de test iOS.

Pour ce faire, définissez la clé et les valeurs OnlyTestIdentifiers dans le fichier .xctestrun. Pour en savoir plus, consultez la page man pour xcodebuild.xctestrun.

Pourquoi mon test iOS ne contient-il pas de vidéos dans les résultats ?

Pour iOS 18 ou version ultérieure, nous ne pouvons pas afficher de vidéos dans les résultats.

Est-ce que Test Lab est compatible avec les accessoires connectés ?

Oui. Test Lab est compatible avec la Google Pixel Watch. Vous pouvez désormais exécuter des tests sur votre application Wear autonome sur les Google Pixel Watch. Pour en savoir plus sur les appareils Test Lab, consultez Tester sur les appareils disponibles.

Test Lab est-il compatible avec les derniers appareils Google ?

Oui. Test Lab 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 Test Lab, consultez Tester sur les appareils disponibles.

Comment détecter un test en cours d'exécution dans Test Lab ?

Si vous testez votre application dans Firebase ou que vous exécutez des tests pour un rapport pré-lancement dans la Play Console, vous pouvez détecter si un test est exécuté sur un appareil hébergé par Firebase en vérifiant la propriété système firebase.test.lab dans votre fichier MainActivity. Vous pouvez ensuite exécuter des instructions supplémentaires en fonction de la valeur booléenne de testLabSetting. Pour en savoir plus, consultez Comportements de test modifiés.

Test Lab est-il compatible avec Appium, Flutter/FlutterDriver, ReactNative/Jest ou Cucumber ?

Bien que certains de ces éléments figurent sur notre feuille de route, nous ne sommes actuellement pas en mesure de 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 l'exécuter dans Test Lab.

Test Lab est-il compatible avec les tests d'applications obscurcies, par exemple avec ProGuard ou R8 ?

Test Lab n'est pas explicitement compatible avec l'obscurcissement ou la désobscurcissement. Même si l'application s'exécute, 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 pliables lors des tests sur Test Lab ?

Oui. Vous pouvez tester votre appareil pliable dans les états et positions des appareils pliables.

Les appareils pliables ont différents états, comme FLAT (entièrement ouvert) ou HALF_OPENED (entre complètement ouvert et complètement fermé).

Les positions, quant à elles, consistent en une orientation spécifique de l'appareil et 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 pliables pour effectuer des tests sur différents états et postures.

Les états disponibles sont spécifiques à l'appareil et peuvent être utilisés avec 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-states sur l'appareil pliable.

$ 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},
]

$ 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 Test Lab si je n'ai pas d'application ?

Contrairement à d'autres produits Firebase, vous n'avez pas besoin d'ajouter un SDK Firebase pour utiliser Test Lab. Si vous n'avez pas encore d'application, vous pouvez télécharger un APK en ligne ou créer une application et un APK de test à partir de l'un des exemples du dépôt GitHub AndroidX. Notez que vous n'avez besoin que du fichier APK de votre application pour exécuter un test Robo, tandis qu'un test d'instrumentation nécessite à la fois un APK d'application et un APK de test créés à partir du code source. Pour en savoir plus, consultez Tests instrumentés.

Pour en savoir plus sur les fonctionnalités de Test Lab, consultez Premiers pas avec les tests pour Android avec Firebase Test Lab.

Quels sont les meilleurs appareils pour les tests de comparaison de captures d'écran ?

Les tests de comparaison de captures d'écran sont des assertions de test basées sur la comparaison d'images d'écran obtenues lors de l'exécution d'un test avec 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 d'émulation Arm (*.arm) pour ce type de test. Les appareils d'émulation Arm utilisent des images très similaires ou identiques aux émulateurs "génériques" d'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 présence de modifications attendues.

Est-ce que Test Lab met à jour les appareils virtuels ?

Oui. Les appareils virtuels sont mis à jour lorsque les modifications suivantes sont apportées :

1. Mises à jour des images existantes
2. Abandon des niveaux d'API antérieurs
3. De nouveaux niveaux d'API Android sont ajoutés

Comment activer les rapports de couverture ?

Pour activer les rapports de couverture, ajoutez coverage=true au champ environmentVariables. Si vous utilisez Android Test Orchestrator, vous devez fournir un répertoire pour stocker les résultats de couverture :

--environment-variables coverage=true,coverageFilePath=/sdcard/Download/

Si vous n'utilisez pas Orchestrator, vous pouvez spécifier un chemin d'accès au fichier :

--environment-variables coverage=true,coverageFile=/sdcard/Download/coverage.ec

Où puis-je trouver des informations sur l'appareil, comme la résolution, les ABI compatibles, etc.?

Des informations détaillées sur l'appareil sont disponibles via l'API et sont accessibles depuis le client gcloud à l'aide de la commande describe :

gcloud firebase test android models describe MODEL

Comment me connecter à une application Wear sans téléphone ?

Si votre application est compatible avec Google Sign-In, cela devrait fonctionner automatiquement avec un compte de test. Sinon, si votre application nécessite normalement un téléphone pour se connecter, vous pouvez créer une variante de compilation qui ignore la connexion et utilise un jeton intégré à votre build de test, ou lire des fichiers sur le disque généralement transférés à l'aide de --other-files option. Pour en savoir plus, consultez Connexion personnalisée et saisie de texte avec les tests Robo.

CAPTCHA de connexion

Le test Robo ne peut pas contourner les écrans de connexion qui nécessitent une action supplémentaire de l'utilisateur au-delà de la saisie des identifiants de connexion, par exemple, la saisie d'un CAPTCHA.

Connexion automatique

La connexion automatique avec un compte Google n'est pas compatible avec les tests Robo pour iOS+ (bêta).

Compatibilité avec les frameworks d'UI

Le test Robo fonctionne mieux avec les applications qui utilisent des éléments d'interface utilisateur du framework d'interface utilisateur Android (y compris les objets View, ViewGroup et WebView). Si vous utilisez le test Robo pour tester des applications qui utilisent d'autres frameworks d'interface utilisateur, y compris des applications qui utilisent le moteur de jeu Unity, le test peut se terminer sans explorer au-delà du premier écran.