Cette page fournit une aide au dépannage et des réponses aux questions fréquemment posées 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 le canal #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. Lorsqu’un appareil a une faible capacité, l’exécution des tests peut prendre plus de temps. Si le nombre de tests invoqué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é de l'appareil peuvent prendre plus de temps en raison des facteurs suivants :
- Trafic, qui affecte la disponibilité des appareils et la vitesse des tests.
- Pannes d’appareils ou d’infrastructures, qui peuvent survenir à tout moment. Pour vérifier s'il existe une infrastructure signalée pour Test Lab, consultez le tableau de bord d'état de 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 .
Les résultats des tests non concluants se produisent généralement en raison d’exécutions de tests annulées ou d’erreurs d’infrastructure.
Les erreurs d'infrastructure sont causées par des problèmes internes de Test Lab, comme des erreurs réseau ou des comportements inattendus des appareils. Test Lab abandonne en interne les exécutions de tests qui génèrent des erreurs d'infrastructure à plusieurs reprises avant de signaler un résultat non concluant ; cependant, vous pouvez désactiver ces tentatives à l'aide de failFast .
Pour déterminer la cause de l'erreur, procédez comme suit :
- Recherchez les pannes connues dans le tableau de bord d'état de Firebase .
Réessayez le test dans Test Lab pour vérifier qu'il est reproductible.
Essayez d'exécuter le test sur un autre appareil ou type d'appareil, le cas échéant.
Si le problème persiste, contactez l'équipe Test Lab sur le canal #test-lab sur Firebase Slack.
Le partitionnement peut prolonger l'exécution de vos tests lorsque le nombre de partitions que vous avez spécifié dépasse le nombre d'appareils disponibles pour une utilisation dans Test Lab. Pour éviter cette situation, essayez de passer à un autre appareil. Pour plus d'informations sur le choix d'un autre appareil, consultezDevice Capacité .
Lorsque vous soumettez une demande de test, votre application est d'abord validée, re-signée, 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 tests sont planifiées et restent dans une file d'attente jusqu'à ce qu'un appareil soit prêt à l'exécuter. Jusqu'à ce que toutes les exécutions de tests soient terminées, l'état de la matrice sera « En attente » (que les exécutions de tests 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 téléchargés sur 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 directement restitués 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 du projet, éditeur de projet ou visualiseur de 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 compartiment de résultats en cliquant sur l'onglet Résultats des tests dans le tableau de bord Test Lab. Le compartiment 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 plus d'informations, consultez la documentation de référence gcloud firebase test android run
.
Lorsque vous exécutez des tests d'instrumentation, vous pouvez voir des erreurs de test 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 marqueurs 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 :
Description du problème | Résolution possible |
---|---|
Le scénario de test n'a pas été exécuté en raison d'un délai d'attente. Si la durée totale des tests est supérieure à un délai d'attente que vous avez spécifié ou supérieure à un délai d'attente maximum , Test Lab annule le reste des cas de test. |
|
Le scénario de test n'a pas abouti car il s'est terminé prématurément ou est resté bloqué. Le scénario de test peut se terminer prématurément en raison d'une exception non détectée ou d'une erreur d'assertion. Les scénarios de test peuvent rester 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'interface utilisateur. | Vérifiez la vidéo et le logcat pour déterminer où le test s'est arrêté. |
Un exécuteur de test personnalisé (y compris l'extension d'AndroidJUnitRunner) s'est écrasé 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 votre code d'exécuteur de test. |
Des journaux excessifs ont été écrits dans logcat , ce qui a saturé le tampon ou fait planter le processus logcat . | Réduisez les écritures sur logcat . |
L'application testée est tombée en panne. | Déboguez votre application. |
Questions fréquemment posées
Firebase Test Lab propose des quotas gratuits pour les tests sur les appareils et pour l'utilisation des API Cloud. Notez que le quota de tests utilise le plan tarifaire Firebase standard, contrairement aux quotas de l'API Cloud.
Quota de tests
Les quotas de tests sont déterminés par le nombre d'appareils utilisés pour exécuter les tests. Le plan Firebase Spark dispose d'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 lendemain ou passez au plan Blaze si vous utilisez actuellement le plan Spark. Si vous bénéficiez déjà du forfait Blaze, vous pouvez demander une augmentation de quota. Pour plus d’informations, consultez Quota de test .
Vous pouvez surveiller l'utilisation de votre quota de tests dans la console Google Cloud .
Quota de l'API Cloud Testing
L'API Cloud Testing est soumise à deux limites de quota : requêtes par jour et par projet et requêtes toutes les 100 secondes par projet. Vous pouvez surveiller votre utilisation dans la console Google Cloud .
Quota de l'API des résultats de l'outil Cloud
L'API Cloud Tool Results est soumise à deux limites de quota : requêtes par jour et par projet et requêtes toutes les 100 secondes par projet. Vous pouvez surveiller votre utilisation dans la console Google Cloud .
Reportez-vous aux quotas de l'API Cloud pour Test Lab pour plus d'informations sur les limites de l'API. Si vous avez atteint un quota d'API :
Soumettez 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 au maximum par défaut), ou
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 vérifiant l'adresse IP source par rapport à nos plages IP .
Test Lab ne fonctionne pas avec VPC-SC, qui bloque la copie des applications et autres artefacts de test entre le stockage interne de Test Lab et les compartiments de résultats des utilisateurs.
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 Deflake sont facturées ou prises en compte dans votre quota quotidien de la même manière que les exécutions de tests normales.
Gardez les éléments suivants à l’esprit :
- L’intégralité de l’exécution du test s’exécute à nouveau lorsqu’un échec est détecté. Il n'est pas possible de réessayer uniquement les cas de test ayant échoué.
- Les nouvelles tentatives de Deflake 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.
Oui! Test Lab prend en charge Google Pixel Watch. Vous pouvez désormais exécuter des tests sur votre application Wear autonome sur les montres Google Pixel. Pour en savoir plus sur les appareils Test Lab, consultez Test sur les appareils disponibles .
Oui! Test Lab prend en charge la tablette Google Pixel et Google Pixel Fold. Vous pouvez exécuter vos tests sur vos appareils physiques autonomes. Pour en savoir plus sur les appareils Test Lab, consultez Test sur les appareils disponibles .
Si vous testez votre application dans Firebase ou exécutez des tests pour un rapport préalable au lancement dans la Play Console, vous pouvez détecter si un test est en cours d'exécution sur un appareil hébergé par Firebase en recherchant la propriété système firebase.test.lab
dans votre fichier MainActivity
. Vous pouvez ensuite exécuter des instructions supplémentaires basées sur la valeur booléenne de testLabSetting
. Pour plus d'informations, voir Comportements de test modifiés .
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 prenant en charge 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 ne prend pas explicitement en charge l’obscurcissement ou la désobscurcissement. Bien que l'application soit susceptible de s'exécuter, toutes les données d'application obscurcies, comme les traces de pile, apparaîtront comme obscurcies dans les journaux.
Oui! Vous pouvez tester votre appareil pliable dans des états et des postures pliables .
Les appareils pliables peuvent être dans différents états pliés, tels que FLAT
(complètement ouvert) ou HALF_OPENED
(entre complètement ouvert et complètement fermé).
Les postures, quant à elles, consistent en une orientation spécifique de l'appareil et un état pliable. Par exemple, la posture sur une table, qui est un état HALF_OPENED
en orientation horizontale, ou la posture du 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 les tests de votre application sur la documentation pliable pour tester sur différents états et postures.
Alternativement, les états disponibles sont spécifiques à l’appareil et peuvent être interagis à l’aide de adb shell command cmd device_state
.
- Pour répertorier 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 le périphérique 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}, ]
Contrairement aux 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 référentiel AndroidX GitHub . 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 construits à partir du code source. Pour plus d’informations, consultez la rubrique Tests instrumentés .
Pour en savoir plus sur les fonctionnalités de Test Lab, consultez Commencer à tester pour Android avec Firebase Test Lab .
Les tests de comparaison de captures d'écran sont l'endroit où les assertions de test sont basées sur la comparaison des images d'écran obtenues lors de l'exécution d'un test avec des images dorées 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 ces types de tests. 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 tests qui peuvent contribuer à rendre les tests de capture d'écran plus robustes en présence des modifications attendues.
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
- De nouveaux niveaux d'API Android sont ajoutés
Pour activer les rapports de couverture, ajoutez coverage=true
au champ environmentVariables
. Si vous utilisez Android Test Orchestrator, vous devrez 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 de fichier :
--environment-variables coverage=true,coverageFile=/sdcard/Download/coverage.ec
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 décrire :
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 supplémentaire de l'utilisateur au-delà de la saisie des informations d'identification pour se connecter, par exemple en complétant un CAPTCHA.
Le test robot 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.