Firebase Test Lab is deprecated and will be fully shut down on September 30, 2027. To
maintain your testing workflows, you can migrate to the Developer Device Platform on Google
Cloud. See the
Developer Device Platform Migration Guide
and FAQ for more
details.
Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.
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-Channel in 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. Im Firebase-Status-Dashboard können Sie nachsehen, ob es ein gemeldetes Infrastrukturproblem für Test Lab gibt.
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 führt intern mehrere Wiederholungsversuche für Testläufe durch, bei denen wiederholt Infrastrukturfehler auftreten, 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.
Wenn das Problem weiterhin besteht, wenden Sie sich an das Test Lab-Team im Kanal „#test-lab“ auf Firebase Slack.
Warum dauern meine Tests durch Sharding länger?
Durch Sharding können Ihre Tests länger dauern, wenn die Anzahl der von Ihnen angegebenen Shards die Anzahl der Geräte überschreitet, die in Test Lab verfügbar sind. Um dies zu vermeiden, versuche es mit einem anderen Gerät. 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 nur wenige Sekunden, kann aber 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, ist der Matrixstatus „Ausstehend“ (unabhängig davon, ob Testläufe in der Warteschlange sind 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 durch die Menge und Größe der Artefakte beeinflusst werden.
Android-spezifische Fehlerbehebung
App gibt keine Daten zurück und Screenshots sind nicht zu finden
Artefakte der Testausführung (z. B. Screenshots und Logdateien) werden in Google Cloud Storage gespeichert und direkt in der Firebase-Konsole gerendert. Wenn Ihre Testausführung in den letzten 90 Tagen durchgeführt wurde, prüfen Sie, ob Sie Rollen auf Projektebene zugewiesen haben (Projektinhaber, Projektbearbeiter oder Projektbetrachter).
Achten Sie außerdem darauf, dass Cloud-Audit-Logging nicht für Ihr Projekt oder Ihre Organisation aktiviert ist.
Wenn die Ausführung vor mehr als 90 Tagen erfolgt ist, wurden die Testartefakte höchstwahrscheinlich automatisch gelöscht. Sie können die Konfiguration der Ergebnisgruppe auf dem Tab Testergebnisse im Test Lab-Dashboard prüfen. Der Standard-Ergebnis-Bucket ist so konfiguriert, dass Objekte 90 Tage lang aufbewahrt werden.
Wenn Sie Ihre Testartefakte länger behalten möchten, führen Sie den Befehl gcloud firebase test android run mit dem Flag --results-bucket aus und übergeben Sie den Namen des Ergebnis-Buckets. Weitere Informationen finden Sie in der Referenzdokumentation zu gcloud firebase test android run.
Warum erhalte ich nur teilweise oder gar keine Ergebnisse für Instrumentierungstests?
Wenn Sie Instrumentierungstests ausführen, werden möglicherweise Testfehler angezeigt, die auf Teilergebnisse hinweisen, z. B. Test run failed to complete. Expected
x tests, received y (wobei y kleiner als x ist). Dieser Fehler bedeutet, dass Test Lab das logcat nicht nach Markierungen für den Beginn oder das Ende des Testlaufs parsen konnte, die normalerweise von AndroidJUnitRunner generiert werden.
Häufige Ursachen für dieses Problem:
Problembeschreibung
Mögliche Lösung
Der Testlauf wurde aufgrund einer Zeitüberschreitung nicht ausgeführt. Wenn die Gesamtdauer der Tests länger als ein von Ihnen angegebener oder ein maximaler Timeout ist, werden die restlichen Testläufe von Test Lab abgebrochen.
Erhöhen Sie das Zeitlimit für die Matrix, damit alle Tests abgeschlossen werden können.
Teilen Sie die Tests in Shards auf, falls Sie das noch nicht getan haben. So wird in jedem Shard nur eine Teilmenge der Tests ausgeführt und die Ausführung dauert weniger lange.
Wenn Sie Sharding bereits aktiviert haben, erhöhen Sie die Anzahl der Shards.
Der Testlauf konnte nicht abgeschlossen werden, da er vorzeitig beendet wurde oder hängen geblieben ist.
Der Testlauf kann aufgrund einer nicht abgefangenen Ausnahme oder eines Zusicherungsfehlers vorzeitig beendet werden. Testläufe können in einer Endlosschleife hängen bleiben oder nicht fortgesetzt werden, z. B. wenn in der App nicht die richtige Ansicht angezeigt wird und der Testlauf die Aktion auf der Benutzeroberfläche nicht ausführen kann.
Sehen Sie sich das Video und die logcat an, um herauszufinden, wo der Test beendet wurde.
Ein benutzerdefinierter Test-Runner (einschließlich der Erweiterung von AndroidJUnitRunner) ist unerwartet abgestürzt oder hat unerwartete Markierungen für den Start oder das Ende von Testläufen in logcat geschrieben.
Prüfen Sie den Code des Test-Runners.
Es wurden zu viele Logs in logcat geschrieben, wodurch der Puffer überlastet wurde oder der logcat-Prozess abgestürzt ist.
Schreibvorgänge für logcat reduzieren.
Die getestete App ist abgestürzt.
Fehler in der App beheben
FAQ
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-Preismodell, 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 beantragen.
Weitere Informationen finden Sie unter Testkontingent.
Sie können die Nutzung Ihres Testkontingents in der Google Cloud-Konsole überwachen.
Kontingente für die Cloud Testing API
Für die Cloud Testing API gelten zwei Kontingentlimits: Anfragen pro Tag und Anfragen alle 100 Sekunden pro 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 pro Projekt und Abfragen alle 100 Sekunden pro Projekt. Sie können Ihre Nutzung in der Google Cloud-Konsole überwachen.
Sie können ein höheres Kontingent anfordern, indem Sie Ihre Kontingente direkt in der Google Cloud Console bearbeiten. Die meisten Limits sind standardmäßig auf das Maximum festgelegt. Alternativ können Sie
Sie können höhere API-Kontingente anfordern, indem Sie ein Antragsformular in der Google Cloud Console ausfüllen oder sich an den Firebase-Support wenden.
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 prüfen, ob der Traffic von Firebase-gehosteten Testgeräten stammt. IP-Bereiche
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 instabile Verhalten in Ihren Tests zu erkennen, empfehlen wir die Verwendung der Option
--num-flaky-test-attempts
. Deflake-Wiederholungen werden Ihnen in Rechnung gestellt 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 für die Fehlerbehebung werden so geplant, dass sie gleichzeitig ausgeführt werden. Es kann jedoch vorkommen, dass sie nicht parallel ausgeführt werden, z. B. wenn der Traffic die Anzahl der verfügbaren Geräte übersteigt.
Häufig gestellte Fragen zu iOS
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 Zusicherung für die Unterstützung dieser Test- und App-Entwicklungsplattformen geben.
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 müssen Sie den Schlüssel OnlyTestIdentifiers und die Werte in der Datei .xctestrun festlegen.
Weitere Informationen finden Sie auf der Seite man 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.
Android-spezifische FAQs
Unterstützt Test Lab Wearables?
Sehr gut. Test Lab unterstützt die Google Pixel Watch. Sie können jetzt Tests für Ihre eigenständige Wear-App auf Google Pixel Watches ausführen. Weitere Informationen zu
Test Lab-Geräten
Unterstützt Test Lab die neuesten Google-Geräte?
Sehr gut. Test Lab unterstützt das Google Pixel Tablet und das Google Pixel Fold. Sie können Ihre Tests auf Ihren eigenständigen physischen Geräten ausführen.
Weitere Informationen zu
Test Lab-Geräten
Wie kann ich einen laufenden Test in Test Lab erkennen?
Wenn Sie Ihre App in Firebase testen oder Tests für einen Pre-Launch-Testbericht in der Play Console ausführen, können Sie erkennen, ob ein Test auf einem von Firebase gehosteten Gerät ausgeführt wird. Suchen Sie dazu in Ihrer MainActivity-Datei nach der Systemproperty firebase.test.lab. Anschließend können Sie basierend auf dem booleschen Wert für testLabSetting zusätzliche Anweisungen ausführen. Weitere Informationen finden Sie unter Geänderte Testverhalten.
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 Zusicherung für die Unterstützung dieser Test- und App-Entwicklungsplattformen geben. Wenn Sie Ihre App jedoch mit einem Framework erstellt haben, das Espresso unterstützt (z. B. Flutter), können Sie einen Instrumentierungstest mit Espresso schreiben und den Test dann in Test Lab ausführen.
Unterstützt Test Lab das Testen von verschleierten Apps, z. B. mit ProGuard oder R8?
Test Lab unterstützt die Verschleierung oder Entschleierung nicht explizit. Die App wird wahrscheinlich ausgeführt, aber alle verschleierten App-Daten, z. B. Stacktraces, werden in den Logs verschleiert angezeigt.
Kann ich mein faltbares Gerät in verschiedenen faltbaren Zuständen und Positionen verwenden, während ich auf Test Lab teste?
Faltbare Geräte können sich in verschiedenen gefalteten Zuständen befinden, z. B. FLAT (vollständig geöffnet) oder HALF_OPENED (zwischen vollständig geöffnet und vollständig geschlossen).
Posen bestehen dagegen aus einer bestimmten Geräteausrichtung und einem bestimmten Zustand des faltbaren Geräts. Beispiele sind die Tischposition, die ein HALF_OPENED-Zustand in horizontaler Ausrichtung ist, oder die Buchposition, die ein HALF_OPENED-Zustand in vertikaler Ausrichtung ist.
Kann ich Test Lab ausprobieren, wenn ich keine App habe?
Im Gegensatz zu anderen Firebase-Produkten müssen Sie kein Firebase SDK hinzufügen, um Test Lab zu verwenden. Wenn Sie noch keine App haben, können Sie ein APK online herunterladen oder eine App und ein Test-APK aus einem der Beispiele im AndroidX-GitHub-Repository erstellen.
Für einen Robo-Test benötigen Sie nur die APK-Datei Ihrer App. Für einen Instrumentationstest sind sowohl eine App als auch ein Test-APK erforderlich, die aus Quellcode erstellt werden. Weitere Informationen zu instrumentierten Tests
Welche Geräte eignen sich am besten für das Testen von Screenshot-Differenzen?
Beim Screenshot-Diff-Test basieren Testassertions auf dem Vergleich von Screenshots, die während eines Tests aufgenommen wurden, mit Golden Images, die das erwartete Verhalten darstellen. Solche Tests sind auf einigen Gerätetypen möglicherweise anfälliger als auf anderen. Wir empfehlen, für diese Art von Tests Arm-Emulatoren (*.arm) zu verwenden. Für Arm-Emulatorgeräte werden Images verwendet, die den generischen Emulatoren von Android Studio sehr ähnlich oder identisch sind.
Wir empfehlen außerdem, Testbibliotheken zu verwenden, mit denen Screenshot-Tests bei erwarteten Änderungen robuster werden.
Werden virtuelle Geräte von Test Lab aktualisiert?
Sehr gut. Virtuelle Geräte werden aktualisiert, wenn die folgenden Änderungen vorgenommen werden:
Aktualisierungen vorhandener Bilder
Einstellung früherer API-Levels
Neue Android-API-Levels werden hinzugefügt
Wie aktiviere ich Abdeckungsberichte?
Wenn Sie Berichte zur Abdeckung aktivieren möchten, fügen Sie dem Feld environmentVariablescoverage=true hinzu.
Wenn Sie Android Test Orchestrator verwenden, müssen Sie ein Verzeichnis angeben, in dem die Ergebnisse der Codeabdeckung gespeichert werden sollen:
Wo finde ich Gerätedetails wie Auflösung und unterstützte ABIs?
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 android models describe MODEL
Wie melde ich mich in einer Wear-App ohne Smartphone an?
Wenn Ihre App Google Sign-in unterstützt, sollte dies automatisch mit einem Testkonto funktionieren. Wenn für die Anmeldung in Ihrer App normalerweise ein Smartphone erforderlich ist, können Sie eine Build-Variante erstellen, bei der die Anmeldung übersprungen wird und ein in Ihren Test-Build eingebettetes Token verwendet wird. Alternativ können Sie Daten aus Dateien auf dem Laufwerk lesen, die normalerweise mit --other-files option übertragen werden. Weitere Informationen finden Sie unter Benutzerdefinierte Anmeldung und Texteingabe mit Robo-Tests.
Bekannte Probleme
Anmelde-Captchas
Robo-Tests können Anmeldebildschirme nicht umgehen, die über die Eingabe von Anmeldedaten hinaus zusätzliche Nutzeraktionen erfordern, z. B. das Ausfüllen eines CAPTCHA.
Bekannte iOS-spezifische Probleme
Automatische Anmeldung
Die automatische Anmeldung mit einem Google-Konto wird bei Robo-Tests für iOS+ (Beta) nicht unterstützt.
Android-spezifische bekannte Probleme
Unterstützung von 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: 2026-10-07 (UTC)."],[],[]]