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é, les tests peuvent prendre plus de temps à s'exécuter. Si le nombre de tests invoqués est bien supérieur à la capacité des périphériques sélectionnés, les tests peuvent prendre plus de temps à se terminer.
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 :
- Le trafic, qui affecte la disponibilité de l'appareil et la vitesse de test.
- Les 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 .
Des 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 de Test Lab, comme des erreurs de réseau ou des comportements inattendus de l'appareil. Test Lab supprime en interne les exécutions de test qui produisent plusieurs fois des erreurs d'infrastructure 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 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 allonger 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 périphérique, consultezCapacité du périphérique .
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 test 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 test soient terminées, le statut de la matrice sera "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 à partir de 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.
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 test utilise le plan 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 plan Firebase Spark a un quota de test fixe sans frais pour les utilisateurs. Pour le forfait Blaze, vos quotas peuvent augmenter si votre utilisation de Google Cloud augmente avec le temps. Si vous atteignez votre quota de test, attendez le lendemain ou passez au plan Blaze si vous êtes actuellement sur le plan Spark. Si vous êtes déjà sur le plan 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 test dans Google Cloud Console .
Quota d'API de test cloud
L'API Cloud Testing est fournie avec deux limites de quota : les demandes par jour et par projet et les demandes toutes les 100 secondes par projet. Vous pouvez surveiller votre utilisation dans Google Cloud Console .
Quota de l'API Cloud Tool Results
L'API Cloud Tool Results est fournie avec 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 Google Cloud Console .
Reportez-vous à Quotas d'API Cloud pour Test Lab pour plus d'informations sur les limites d'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 sur le 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 .
À partir de votre backend, vous pouvez déterminer si le trafic provient d'appareils de test hébergés sur Firebase en vérifiant l'adresse IP source par rapport à nos plages d'adresses IP .
Test Lab ne fonctionne pas avec VPC-SC, qui bloque la copie d'applications et d'autres artefacts de test entre le stockage interne de Test Lab et les compartiments de résultats des utilisateurs. Pour le moment, une demande de fonctionnalité a été déposée pour ajouter la prise en charge de VPC-SC dans une future version.
Pour détecter un comportement instable dans vos tests, nous vous recommandons d'utiliser l'option--num-flaky-test-attempts. Les rediffusions de Deflake sont facturées ou comptabilisées dans votre quota quotidien de la même manière que les exécutions de test normales.
Gardez à l'esprit ce qui suit :
- L'intégralité de l'exécution du test s'exécute à nouveau lorsqu'une défaillance est détectée. Il n'y a pas de prise en charge pour 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 describe :
gcloud firebase test ios models describe MODEL
Le partitionnement n'est pas pris en charge de manière native dans Test Lab pour iOS. Cependant, vous pouvez utiliser le client Flank pour partitionner des 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.