Fehlerbehebung in Test Lab & Häufig gestellte Fragen
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite finden Sie Hilfe bei der Fehlerbehebung und Antworten auf häufig gestellte Fragen zum Ausführen von Tests mit Firebase Test Lab. Bekannte Probleme werden ebenfalls dokumentiert. Wenn Sie nicht finden, wonach Sie suchen, oder zusätzliche Hilfe benötigen, treten Sie dem #test-lab-Kanal auf Firebase Slack bei oder wenden Sie sich an den Firebase-Support.
Fehlerbehebung
Warum dauert es so lange, bis mein Test ausgeführt wird?
Wenn Sie ein Gerät mit hoher Kapazität im Test Lab-Katalog auswählen, können Tests schneller gestartet werden. Wenn ein Gerät eine geringe Kapazität hat, kann es länger dauern, bis Tests ausgeführt werden. Wenn die Anzahl der aufgerufenen Tests viel größer ist als die Kapazität der ausgewählten Geräte, kann es länger dauern, bis die Tests abgeschlossen sind.
Tests, die auf Geräten mit einer beliebigen Kapazitätsstufe ausgeführt werden, können aus folgenden Gründen länger dauern:
Traffic, der sich auf die Geräteverfügbarkeit und die Testgeschwindigkeit auswirkt.
Geräte- oder Infrastrukturfehler, die jederzeit auftreten können. Ob es eine gemeldete Infrastruktur für Test Lab gibt, können Sie im Firebase-Status-Dashboard nachsehen.
Weitere Informationen zur Gerätekapazität in Test Lab finden Sie in den Informationen zur Gerätekapazität für Android und iOS.
Warum erhalte ich nicht aussagekräftige Testergebnisse?
Nicht eindeutige Testergebnisse sind in der Regel auf abgebrochene Testläufe oder Infrastrukturfehler zurückzuführen.
Infrastrukturfehler werden durch interne Test Lab-Probleme verursacht, z. B. Netzwerkfehler oder unerwartetes Geräteverhalten. Test Lab beendet intern Testläufe, die mehrmals Infrastrukturfehler verursachen, bevor ein nicht eindeutiges Ergebnis gemeldet wird. Sie können diese Wiederholungsversuche jedoch mit failFast deaktivieren.
Wiederholen Sie den Test in Test Lab, um zu prüfen, ob er reproduzierbar ist.
Führen Sie den Test gegebenenfalls auf einem anderen Gerät oder Gerätetyp aus.
Sollte das Problem weiterhin auftreten, wenden Sie sich an das Test Lab-Team im #test-lab-Kanal auf Firebase Slack.
Warum dauern meine Tests durch Sharding länger?
Die Fragmentierung kann dazu führen, dass Ihre Tests länger dauern, wenn die von Ihnen angegebene Anzahl von Shards die Anzahl der Geräte übersteigt, die in Test Lab verfügbar sind. Um dies zu vermeiden, kannst du versuchen, auf ein anderes Gerät zu wechseln. Weitere Informationen zur Auswahl eines anderen Geräts finden Sie unter
Gerätekapazität:
Warum dauert es so lange, bis mein Test beginnt?
Wenn Sie eine Testanfrage senden, wird Ihre App zuerst validiert, neu signiert usw., um sie für die Ausführung von Tests auf einem Gerät vorzubereiten. Normalerweise dauert dieser Vorgang weniger als einige Sekunden. Er kann jedoch durch Faktoren wie die Größe Ihrer App beeinflusst werden.
Nachdem Ihre App vorbereitet wurde, werden Testläufe geplant und in eine Warteschlange gestellt, bis ein Gerät für die Ausführung bereit ist. Bis alle Testläufe abgeschlossen sind, lautet der Status der Matrix „Ausstehend“ (unabhängig davon, ob sich Testläufe in der Warteschlange befinden oder aktiv ausgeführt werden).
Warum dauert es so lange, bis mein Test abgeschlossen ist?
Nach Abschluss der Testausführung werden Testartefakte vom Gerät heruntergeladen, verarbeitet und in Cloud Storage hochgeladen. Die Dauer dieses Schritts kann von der Anzahl und Größe der Artefakte abhängen.
Häufig gestellte Fragen
Welche kostenlosen Kontingente gibt es für Test Lab? Was soll ich tun, wenn meine Lizenzen aufgebraucht sind?
Firebase Test Lab bietet kostenlose Kontingente für Tests auf Geräten und für die Verwendung von Cloud-APIs. Das Testkontingent unterliegt dem Standard-Firebase-Abo, die Cloud API-Kontingente jedoch nicht.
Testkontingent
Testkontingente werden durch die Anzahl der Geräte bestimmt, die zum Ausführen von Tests verwendet werden.
Der Firebase Spark-Tarif umfasst ein festes Testkontingent, das für Nutzer kostenlos ist. Bei einer intensiveren Nutzung von Google Cloud können Ihre Kontingente entsprechend erhöht werden. Wenn Sie Ihr Testkontingent erreicht haben, warten Sie bis zum nächsten Tag oder führen Sie ein Upgrade auf den Blaze-Tarif durch, wenn Sie derzeit den Spark-Tarif nutzen.
Wenn Sie bereits den Blaze-Tarif nutzen, können Sie eine Kontingenterhöhung anfordern.
Weitere Informationen finden Sie unter Testkontingent.
Für die Cloud Testing API gelten zwei Kontingentlimits: Anfragen pro Tag und Projekt sowie Anfragen pro 100 Sekunden und Projekt. Sie können Ihre Nutzung in der Google Cloud-Konsole überwachen.
Kontingente für die Cloud Tool Results API
Für die Cloud Tool Results API gelten zwei Kontingentlimits: Abfragen pro Tag und Projekt sowie Abfragen pro 100 Sekunden und Projekt. Sie können Ihre Nutzung in der Google Cloud-Konsole überwachen.
Sie können eine Anfrage für höhere Kontingente senden, indem Sie Ihre Kontingente direkt in der Google Cloud-Konsole bearbeiten. Die meisten Limits sind standardmäßig auf das Maximum festgelegt.
Wenn Sie ein höheres API-Kontingent anfordern möchten, füllen Sie ein Antragsformular in der Google Cloud Console aus oder wenden Sie sich an den Firebase-Support.
Woher weiß ich, ob der Traffic, der mein Backend erreicht, von Test Lab stammt?
In Ihrem Backend können Sie anhand der Quell-IP-Adresse und unserer IP-Bereiche feststellen, ob der Traffic von Firebase-gehosteten Testgeräten stammt.
Funktioniert Test Lab mit VPC-SC?
Test Lab ist nicht mit VPC-SC kompatibel. Dadurch wird das Kopieren von Apps und anderen Testartefakten zwischen dem internen Speicher von Test Lab und den Ergebnis-Buckets der Nutzer blockiert.
Wie erkenne ich instabile Tests in Test Lab?
Um instabiles Verhalten in Ihren Tests zu erkennen, empfehlen wir die Verwendung der Option
--num-flaky-test-attempts
. Deflake-Wiederholungen werden genauso abgerechnet oder auf Ihr tägliches Kontingent angerechnet wie normale Testausführungen.
Beachten Sie Folgendes:
Die gesamte Testausführung wird wiederholt, wenn ein Fehler erkannt wird. Es gibt keine Unterstützung für das Wiederholen nur fehlgeschlagener Testläufe.
Wiederholungsdurchläufe werden für die gleichzeitige Ausführung geplant, aber es wird nicht garantiert, dass sie parallel ausgeführt werden, z. B. wenn der Traffic die Anzahl der verfügbaren Geräte übersteigt.
Unterstützt Test Lab Appium, Flutter/FlutterDriver, ReactNative/Jest oder Cucumber?
Einige dieser Elemente sind zwar auf unserer Roadmap, aber wir können derzeit keine Zusagen zur Unterstützung dieser Test- und App-Entwicklungsplattformen machen.
Wo finde ich Gerätedetails wie die Auflösung?
Detaillierte Geräteinformationen sind über die API verfügbar und können über den gcloud-Client mit dem Befehl „describe“ aufgerufen werden:
gcloud firebase test ios models describe MODEL
Kann ich Sharding mit iOS-Tests verwenden?
Sharding wird in Test Lab für iOS nicht nativ unterstützt. Sie können jedoch den Flank-Client verwenden, um iOS-Testläufe aufzuteilen.
Dazu werden der OnlyTestIdentifiers-Schlüssel und die Werte in der Datei .xctestrun festgelegt.
Weitere Informationen finden Sie auf der man-Seite für xcodebuild.xctestrun.
Warum fehlen in den Ergebnissen meines iOS-Tests Videos?
Bei iOS 18 oder höher können wir keine Videos in den Ergebnissen unterstützen.
Bekannte Probleme
Anmelde-Captchas
Beim Robo-Test können Anmeldebildschirme nicht umgangen werden, für die über die Eingabe von Anmeldedaten hinaus zusätzliche Nutzeraktionen erforderlich sind, z. B. das Ausfüllen eines CAPTCHA.
Unterstützung für UI-Frameworks
Robo-Tests funktionieren am besten mit Apps, die UI-Elemente aus dem Android-UI-Framework verwenden, einschließlich View-, ViewGroup- und WebView-Objekten. Wenn Sie Robo-Tests für Apps verwenden, die andere UI-Frameworks nutzen, einschließlich Apps, die die Unity-Game-Engine verwenden, wird der Test möglicherweise beendet, ohne dass mehr als der erste Bildschirm untersucht wird.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-05 (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"]]
