Dépannage et questions fréquentes concernant Test Lab
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cette page fournit une aide au 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
Pourquoi mon test prend-il autant de temps à s'exécuter ?
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 capacité faible, l'exécution des tests peut prendre plus de temps. Si le nombre de tests appelés est beaucoup plus élevé que 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 se produire à tout moment. Pour vérifier si une infrastructure a été 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 des tests sont-ils non concluants ?
Les résultats de tests non concluants sont généralement dus à des exécutions de tests annulées ou à des erreurs d'infrastructure.
Les erreurs d'infrastructure sont dues à des problèmes internes à Test Lab, comme des erreurs réseau ou des comportements inattendus de l'appareil. Test Lab met fin en interne aux exécutions de tests qui produisent des erreurs d'infrastructure à plusieurs reprises 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 :
Réessayez le test dans Test Lab pour vérifier qu'il est reproductible.
Si possible, essayez d'exécuter le test sur un autre appareil ou type d'appareil.
Si le problème persiste, contactez l'équipe Test Lab sur la chaîne #test-lab de Firebase Slack.
Pourquoi le partitionnement a-t-il rallongé la durée d'exécution de mes tests ?
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 pour une utilisation dans Test Lab. Pour éviter cette situation, essayez de passer à 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 de l'exécution des tests sur un appareil. Normalement, ce processus prend 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 à 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 prend-il autant de temps ?
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 dépendre du nombre et de la taille des artefacts.
Questions fréquentes
Quels sont les quotas sans frais pour Test Lab ? Que dois-je faire si je n'en ai plus ?
Firebase Test Lab propose des quotas sans frais pour les tests sur les appareils et pour 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 Firebase Spark inclut un quota de tests fixe sans frais pour les utilisateurs. Pour la formule 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 à la formule Blaze si vous utilisez actuellement la formule Spark.
Si vous utilisez déjà le forfait Blaze, vous pouvez demander une augmentation de quota.
Pour en savoir plus, consultez 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 soumise à deux limites de quota : le nombre de requêtes par jour et le nombre de 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 soumise à deux limites de quota : les requêtes par jour et les requêtes toutes les 100 secondes, toutes deux par projet. Vous pouvez surveiller votre utilisation dans la console Google Cloud.
Envoyez une demande d'augmentation de quota 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), 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.
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 sur Firebase en vérifiant l'adresse IP source par rapport à nos plages d'adresses IP.
Test Lab est-il compatible avec VPC-SC ?
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 buckets de résultats des utilisateurs.
Comment détecter les tests instables dans Test Lab ?
Pour détecter les comportements instables dans vos tests, nous vous recommandons d'utiliser l'option
--num-flaky-test-attempts
. Les réexécutions de tests pour éliminer les faux échecs sont facturées ou comptabilisées dans 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 réessayer uniquement les cas de test ayant échoué.
Les exécutions de nouvelle tentative de déflocage sont programmé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 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.
Où puis-je trouver des informations sur 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 le partitionnement avec les tests iOS ?
Le partitionnement n'est pas compatible en mode natif avec Test Lab pour iOS. Toutefois, vous pouvez utiliser le client Flank pour fragmenter les cas 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 des vidéos manquent-elles dans les résultats de mon test iOS ?
Pour iOS 18 ou version ultérieure, nous ne pouvons pas afficher de vidéos dans les résultats.
Problèmes connus
Captchas 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 pour se connecter, par exemple, la saisie d'un CAPTCHA.
Compatibilité avec les frameworks d'UI
Les tests Robo fonctionnent mieux avec les applications qui utilisent des éléments d'UI du framework d'UI Android (y compris les objets View, ViewGroup et WebView). Si vous utilisez le test Robo pour exercer 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.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/03 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/03 (UTC)."],[],[],null,["\u003cbr /\u003e\n\niOS Android \n\nThis page provides troubleshooting help and answers to frequently asked\nquestions about running tests with Firebase Test Lab. Known issues are also\ndocumented. If you can't find what\nyou're looking for or need additional help, join the [#test-lab\nchannel](https://firebase-community.slack.com/messages/test-lab) on\nFirebase Slack or contact [Firebase\nsupport](https://support.google.com/firebase/contact/support).\n\nTroubleshooting\n\n\u003cbr /\u003e\n\nWhy is my test taking so long to run?\n\n\u003cbr /\u003e\n\nWhen you select a device with a high capacity level in the Test Lab\ncatalog, tests may start faster. When a\ndevice has low capacity, tests might take longer to run. If the number of\ntests invoked is much larger than the capacity of the selected devices, tests\ncan take longer to finish.\n\n\nTests running on any level device capacity level may take longer due to the\nfollowing factors:\n\n- Traffic, which affects device availability and test speed.\n- Device or infrastructure failures, which can happen at any time. To check if there is a reported infrastructure for Test Lab, see the [Firebase status dashboard](https://status.firebase.google.com/summary).\n\n\nTo learn more about device capacity in Test Lab, see device capacity\ninformation for [Android](https://firebase.google.com/docs/test-lab/android/available-testing-devices#device-capacity) and [iOS](https://firebase.google.com/docs/test-lab/ios/available-testing-devices#device-capacity).\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy am I receiving inconclusive test results?\n\n\u003cbr /\u003e\n\nInconclusive test outcomes commonly occur either because of canceled test runs\nor infrastructure errors.\n\nInfrastructure errors are caused by internal Test Lab issues, like network\nerrors or unexpected device behaviors. Test Lab internally retires test runs\nthat produce infrastructure errors multiple times before reporting an\ninconclusive outcome; however, you can disable these retries using\n[failFast](/docs/test-lab/reference/testing/rest/v1/projects.testMatrices#TestMatrix.FIELDS.fail_fast).\n\nTo determine the cause of the error, follow these steps:\n\n1. Check for known outages in the [Firebase status dashboard](https://status.firebase.google.com/summary).\n2. Retry the test in Test Lab to verify that it is reproducible.\n\n | **Note:** Test Lab does not charge you for infrastructure errors.\n3. Try running the test on a different device or device type, if applicable.\n\nIf the issue persists, contact the Test Lab team in the\n[#test-lab channel](https://firebase-community.slack.com/messages/test-lab) on\nFirebase Slack.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy did sharding make my tests run\nlonger?\n\n\u003cbr /\u003e\n\nSharding can cause your tests to run longer when the number of shards you\nspecified exceeds the number of devices available for use in Test Lab. To\navoid this situation, try switching to a different device. For more information\nabout choosing a different device, see\n\n[Device Capacity](https://firebase.google.com/docs/test-lab/ios/available-testing-devices#device_capacity).\n\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy is it taking a long time for my\ntest to start?\n\n\u003cbr /\u003e\n\nWhen you submit a test request, your app is first validated, re-signed, etc. in\npreparation for running tests on a device. Normally, this process completes in\nless than a few seconds, but it can be affected by factors like the size of your\napp.\n\nAfter your app is prepared, test executions are scheduled and remain in a queue\nuntil a device is ready to run it. Until all test executions finish running,\nthe matrix status will be \"Pending\" (regardless of whether test executions are\nin the queue or actively running).\n| **Note:** The time your test spends waiting for an available device does not count toward your billing time.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy is it taking a long time for my\ntest to finish?\n\n\u003cbr /\u003e\n\nAfter the test execution is finished, test artifacts are downloaded from the\ndevice, processed, and uploaded to Cloud Storage. The duration of this step can\nbe affected by the amount and size of the artifacts.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nFrequently asked questions\n\n\u003cbr /\u003e\n\nWhat are the no-cost quotas\nfor Test Lab? What should I do if I run out?\n\n\u003cbr /\u003e\n\nFirebase Test Lab offers no-cost quotas for testing on devices and for using\nCloud APIs. Note that the testing quota uses the standard Firebase pricing plan,\nwhile the Cloud API quotas do not.\n\n- **Testing quota**\n\n Testing quotas are determined by the number of devices used to run tests.\n The Firebase Spark plan has a fixed testing quota at no cost to users. For\n the Blaze plan, your quotas might increase if your usage of Google Cloud\n increases over time. If you reach your testing quota, wait until the next\n day or upgrade to the Blaze plan if you are currently on the Spark plan.\n If you are already on the Blaze plan, you can request a quota increase.\n For more information, see\n [Testing quota](/docs/test-lab/usage-quotas-pricing#testing-quota).\n\n You can monitor your testing quota usage in the [Google Cloud console](https://console.cloud.google.com/apis/api/testing.googleapis.com/quotas).\n- **Cloud Testing API quota**\n\n The Cloud Testing API comes with two quota limits: requests per day per\n project, and requests per every 100 seconds per project. You can monitor your\n usage in the\n [Google Cloud console](https://console.cloud.google.com/apis/api/testing.googleapis.com/quotas).\n- **Cloud Tool Results API quota**\n\n The Cloud Tool Results API comes with two quota limits: queries per day per\n project, and queries per every 100 seconds per project. You can monitor your\n usage in the\n [Google Cloud console](https://console.cloud.google.com/apis/api/toolresults.googleapis.com/quotas).\n\n Refer to [Cloud API quotas for Test Lab](/docs/test-lab/usage-quotas-pricing#cloud-api-quota)\n for more information on API limits. If you've reached an API quota:\n - Submit a request for higher quotas by\n [editing your quotas](https://cloud.google.com/docs/quota#requesting_higher_quota)\n directly in the Google Cloud console (note that most limits are set to\n maximum by default), or\n\n - Request higher API quotas by filling out a request form in the\n Google Cloud console or by contacting\n [Firebase support](https://support.google.com/firebase/contact/support).\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nHow do I find out if the\ntraffic reaching my backend is coming from Test Lab?\n\n\u003cbr /\u003e\n\nFrom your backend, you can determine if traffic is coming from Firebase-hosted\ntest devices by checking the source IP address against our\n[IP ranges](https://firebase.google.com/docs/test-lab/android/get-started#ip-blocks).\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nDoes Test Lab work with\nVPC-SC?\n\n\u003cbr /\u003e\n\nTest Lab does not work with VPC-SC, which blocks the\ncopying of apps and other test artifacts between Test Lab's internal\nstorage and users' results buckets.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nHow do I detect flaky tests in\nTest Lab?\n\n\u003cbr /\u003e\n\nTo detect flaky behavior in your tests, we recommend using the\n\n[--num-flaky-test-attempts](https://cloud.google.com/sdk/gcloud/reference/firebase/test/ios/run#--num-flaky-test-attempts)\n\noption. Deflake reruns are billed or counted toward your daily quota the same as\nnormal test executions.\n\nKeep the following in mind:\n\n- The entire test execution runs again when a failure is detected. There's no support for retrying only failed test cases.\n- Deflake retry runs are scheduled to run at the same time, but are not guaranteed to run in parallel, for example, when traffic exceeds the number of available devices.\n\n| **Note:** Infrastructure errors are independent from the deflake feature and don't trigger deflake reruns.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nDoes Test Lab support\nAppium, Flutter/FlutterDriver, ReactNative/Jest, or Cucumber?\n\n\u003cbr /\u003e\n\nWhile some of these items are on our roadmap, we're currently unable to provide\ncommitment to supporting these testing and app development platforms.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhere can I find device details,\nlike resolution, etc.?\n\n\u003cbr /\u003e\n\nDetailed device information is available through the API and can be accessed\nfrom the gcloud client using the\n[describe command](https://cloud.google.com/sdk/gcloud/reference/firebase/test/android/models/describe):\n\n`gcloud firebase test ios models describe `\u003cvar translate=\"no\"\u003eMODEL\u003c/var\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nCan I use sharding with iOS tests?\n\n\u003cbr /\u003e\n\nSharding isn't natively supported within Test Lab for iOS. However, you can\nuse the [Flank](https://flank.github.io/flank/) client to shard iOS test cases.\n| **Note:** Using Flank iOS sharding creates separate test matrices for each shard.\n\nThis works by setting `OnlyTestIdentifiers` key and values in `.xctestrun` file.\nSee `man` page for `xcodebuild.xctestrun` for more details.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy is my iOS test missing videos in the\nresults?\n\n\u003cbr /\u003e\n\nFor iOS 18 or later, we are not able to support videos in the results.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nKnown issues\n\n\u003cbr /\u003e\n\nSign-in Captchas\n\n\u003cbr /\u003e\n\nRobo test cannot bypass sign-in screens that require\nadditional user action beyond entering credentials to sign in, for example,\ncompleting a CAPTCHA.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nUI framework support\n\n\u003cbr /\u003e\n\nRobo test works best with apps that use UI elements from the Android UI\nframework (including `View`, `ViewGroup`, and `WebView`\nobjects). If you use Robo test to exercise apps that use other UI\nframeworks, including apps that use the Unity game engine, the test may exit\nwithout exploring beyond the first screen.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e"]]
