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, consultezCapacité de l'appareil .
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.
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 Google Cloud Console .
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 Google Cloud Console .
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 Google Cloud Console .
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 Google Cloud Console (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 Google Cloud Console 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.
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.
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 ios models describe MODEL
Le partage n’est pas pris en charge de manière native dans Test Lab pour iOS. Cependant, vous pouvez utiliser le client Flank pour fragmenter les cas de test iOS.
Cela fonctionne en définissant la clé et les valeurs OnlyTestIdentifiers dans le fichier .xctestrun . Voir la page man de xcodebuild.xctestrun pour plus de détails.
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.