Dépannage et questions fréquentes concernant Test Lab

Cette page fournit une aide pour le dépannage et des réponses aux questions fréquentes sur l'exécution de tests avec Firebase Test Lab. Les problèmes connus sont également documentés. Si vous ne trouvez pas ce que vous cherchez ou si vous avez besoin d'aide supplémentaire, rejoignez la chaîne #test-lab sur Firebase Slack ou contactez l'assistance Firebase.

Dépannage

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, les tests peuvent prendre plus de temps. Si le nombre de tests appelés est beaucoup plus important que la capacité des appareils sélectionnés, leur exécution peut prendre plus de temps.

Les tests exécutés à n'importe quel niveau de capacité de l'appareil peuvent prendre plus de temps en raison des facteurs suivants:

  • Le trafic, qui affecte la disponibilité de l'appareil et la vitesse des tests.
  • Des pannes d'appareil ou d'infrastructure, qui peuvent se produire à 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é de l'appareil dans Test Lab, consultez les informations sur la capacité de l'appareil pour Android et iOS.

Les résultats de test non concluants se produisent généralement en raison d'exécutions de test annulées ou d'erreurs d'infrastructure.

Les erreurs d'infrastructure sont causées par des problèmes internes Test Lab, tels que des erreurs réseau ou des comportements inattendus de l'appareil. Test Lab retire en interne les exécutions de test qui génèrent 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. Recherchez les pannes 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.

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 dans Test Lab. Pour éviter cette situation, essayez d'utiliser un autre appareil. Pour en savoir plus sur le choix d'un autre appareil, consultez la section Capacité de l'appareil.

Lorsque vous envoyez une requête de test, votre application est d'abord validée, signée à nouveau, etc. en vue de l'exécution de 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).

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.

Les artefacts d'exécution des tests (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 été effectuée au cours des 90 derniers jours, vérifiez que vous avez attribué des rôles au niveau du projet (propriétaire, éditeur ou lecteur de projet). Assurez-vous également 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. Pour vérifier la configuration du bucket de résultats, cliquez sur l'onglet Résultats du test 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'indicateur --results-bucket et transmettez le nom du bucket de résultats. Pour en savoir plus, consultez la documentation de référence de gcloud firebase test android run.

Lorsque vous exécutez des tests d'instrumentation, des erreurs de test peuvent s'afficher, indiquant des résultats partiels contenant 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 du cas de test, qui sont généralement générés par AndroidJUnitRunner.

Voici les 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épassement de délai. Si la durée totale des tests est supérieure à un délai d'expiration que vous avez spécifié ou à un délai d'expiration maximal, Test Lab annule le reste des scénarios de test.
  • Augmentez le délai avant expiration de la matrice pour vous assurer que tous les tests peuvent être effectués.
  • Si vous ne l'avez pas déjà fait, segmentez les tests afin que chaque segment exécute un sous-ensemble des tests et se termine plus rapidement.
  • Si vous avez déjà activé la segmentation, augmentez le nombre de segments.
Le cas de test n'a pas pu être exécuté, car il s'est arrêté prématurément ou est bloqué. Le cas de test peut se terminer 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 continuer, 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 à quel moment le test s'est arrêté.
Un lanceur de test personnalisé (y compris l'extension d'AndroidJUnitRunner) a planté de manière inattendue ou a écrit des repères de début ou de fin de scénario de test inattendus dans logcat. Vérifiez le code de votre outil d'exécution de test.
Des journaux excessifs ont été écrits dans logcat, ce qui a saturé le tampon ou a planté le processus logcat. Réduire les écritures à logcat.
L'application en cours de test a planté. Déboguer votre application

Questions fréquentes

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 tarifaire 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 Firebase Spark 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 augmente au fil du temps. Si vous atteignez votre quota de tests, attendez le jour suivant 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 la section Quota de test.

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

  • Quotas de l'API Cloud Testing

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

  • Quota de l'API Cloud Tool Results

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

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

    • Envoyez une demande de quotas plus élevés en modifiant vos quotas directement dans la console Google Cloud (notez que la plupart des limites sont définies sur la valeur maximale 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.

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

Pour détecter un comportement instable dans vos tests, nous vous recommandons d'utiliser l'option --num-flaky-test-attempts . Les rediffusions de déflake sont facturées ou comptabilisées dans votre quota journalier de la même manière que les exécutions de test normales.

Tenez bien compte des éléments suivants :

  • L'ensemble de l'exécution du test est de nouveau exécuté lorsqu'un échec est détecté. Il n'est pas possible de ne relancer que les cas de test ayant échoué.
  • Les tentatives de déflaquage sont planifiées pour s'exécuter en même temps, mais leur exécution en parallèle n'est pas garantie, par exemple lorsque le trafic dépasse le nombre d'appareils disponibles.

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.

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.

Si vous testez votre application dans Firebase ou 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 la section Comportements de test modifiés.

Bien que certains de ces éléments figurent dans 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 compilé 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 Test Lab.

Test Lab n'est pas explicitement compatible avec l'obscurcissement ni le démasquage. Bien que l'application s'exécute probablement, toutes les données d'application masquées, telles que les traces de pile, apparaîtront comme masquées dans les journaux.

Oui ! Vous pouvez tester votre appareil pliable dans différents états et positions.

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, en revanche, correspondent à l'orientation et à l'état pliable spécifiques de l'appareil. Par exemple, la position à plat, qui correspond à un état HALF_OPENED en orientation horizontale, ou la position debout, qui correspond à 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 tester différents états et positions.

Les états disponibles sont également spécifiques à l'appareil et peuvent être utilisés avec adb shell command cmd device_state.

  • Pour afficher 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.
Google Pixel Fold (ID de modèle felix) Samsung Galaxy Z Fold4 (ID de modèle q4q)
$ 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},
]

Contrairement aux autres produits Firebase, vous n'avez pas besoin d'ajouter de SDK Firebase pour utiliser Test Lab. Si vous ne disposez 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 une application et un APK de test compilés à partir du code source. Pour en savoir plus, consultez la section 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.

Les tests de comparaison de captures d'écran sont basés sur la comparaison des 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 des appareils d'émulateur Arm (*.arm) pour ce type de tests. Les appareils d'émulateur Arm utilisent des images très similaires ou identiques aux émulateurs "génériques" d'Android Studio.

Nous vous recommandons également d'examiner les bibliothèques de tests qui peuvent contribuer à rendre les tests de captures d'écran plus robustes en cas de modifications attendues.

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 précédents
  3. Nouveaux niveaux d'API Android ajoutés

Pour activer les rapports sur la 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

Des informations détaillées sur l'appareil sont disponibles via l'API et peuvent être consultées à partir du client gcloud à l'aide de la commande describe:

gcloud firebase test android models describe MODEL

Problèmes connus

Le test robot ne peut pas contourner les écrans de connexion qui nécessitent une action utilisateur supplémentaire en plus de la saisie des identifiants pour se connecter, par exemple, en remplissant un CAPTCHA.

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'UI, y compris des applications qui utilisent le moteur de jeu Unity, le test peut se terminer sans explorer au-delà du premier écran.