Diese Seite bietet Hilfe zur 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
Wenn Sie im Testlaborkatalog ein Gerät mit hoher Kapazität auswählen, können Tests schneller beginnen. Wenn ein Gerät über eine geringe Kapazität verfügt, kann die Ausführung von Tests länger dauern. 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 jeder Gerätekapazitätsstufe ausgeführt werden, können aufgrund der folgenden Faktoren länger dauern:
- Datenverkehr, der sich auf die Geräteverfügbarkeit und Testgeschwindigkeit auswirkt.
- Geräte- oder Infrastrukturausfälle, die jederzeit passieren können. Um zu überprüfen, ob eine gemeldete Infrastruktur für Test Lab vorhanden ist, sehen Sie sich das Firebase-Status-Dashboard an.
Weitere Informationen zur Gerätekapazität im Testlabor finden Sie in den Informationen zur Gerätekapazität für Android und iOS .
Nicht schlüssige Testergebnisse treten häufig aufgrund abgebrochener Testläufe oder Infrastrukturfehlern auf.
Infrastrukturfehler werden durch interne Testlaborprobleme wie Netzwerkfehler oder unerwartetes Geräteverhalten verursacht. Das Testlabor stellt intern mehrere Testläufe ein, die zu Infrastrukturfehlern führen, bevor ein nicht schlüssiges Ergebnis gemeldet wird. Sie können diese Wiederholungsversuche jedoch mit failFast deaktivieren.
Um die Fehlerursache zu ermitteln, gehen Sie folgendermaßen vor:
- Suchen Sie im Firebase-Status-Dashboard nach bekannten Ausfällen.
Wiederholen Sie den Test im Testlabor, um sicherzustellen, dass er reproduzierbar ist.
Versuchen Sie ggf., den Test auf einem anderen Gerät oder Gerätetyp auszuführen.
Wenn das Problem weiterhin besteht, kontaktieren Sie das Testlabor-Team im #test-lab-Kanal auf Firebase Slack.
Sharding kann dazu führen, dass Ihre Tests länger laufen, wenn die Anzahl der von Ihnen angegebenen Shards die Anzahl der für die Verwendung im Testlabor verfügbaren Geräte übersteigt. Um diese Situation zu vermeiden, versuchen Sie, zu einem anderen Gerät zu wechseln. Weitere Informationen zur Auswahl eines anderen Geräts finden Sie unterGerätekapazität .
Wenn Sie eine Testanfrage senden, wird Ihre App zunächst validiert, neu signiert usw., um die Ausführung von Tests auf einem Gerät vorzubereiten. Normalerweise ist dieser Vorgang in weniger als ein paar Sekunden abgeschlossen, er kann jedoch durch Faktoren wie die Größe Ihrer App beeinflusst werden.
Nachdem Ihre App vorbereitet ist, werden Testausführungen geplant und bleiben in einer Warteschlange, bis ein Gerät zur Ausführung bereit ist. Bis die Ausführung aller Testausführungen abgeschlossen ist, lautet der Matrixstatus „Ausstehend“ (unabhängig davon, ob sich Testausführungen in der Warteschlange befinden oder aktiv ausgeführt werden).
Nachdem die Testausführung abgeschlossen ist, werden Testartefakte vom Gerät heruntergeladen, verarbeitet und in den Cloud-Speicher hochgeladen. Die Dauer dieses Schritts kann durch die Menge und Größe der Artefakte beeinflusst werden.
Testausführungsartefakte (wie Screenshots und Protokolldateien) werden in Google Cloud Storage gespeichert und direkt in der Firebase-Konsole gerendert. Wenn Ihre Testausführung innerhalb der letzten 90 Tage durchgeführt wurde, überprüfen Sie, ob Ihnen Rollen auf Projektebene zugewiesen sind (Projekteigentümer, Projektbearbeiter oder Projektbetrachter). Bitte stellen Sie außerdem sicher, dass Cloud Audit Logging für Ihr Projekt oder Ihre Organisation nicht aktiviert ist.
Wenn die Ausführung mehr als 90 Tage zurückliegt, wurden die Testartefakte höchstwahrscheinlich automatisch gelöscht. Sie können die Konfiguration des Ergebnis-Buckets überprüfen, indem Sie im Testlabor-Dashboard auf die Registerkarte Testergebnisse klicken. Der Standard-Ergebnis-Bucket ist so konfiguriert, dass Objekte 90 Tage lang aufbewahrt werden.
Um Ihre Testartefakte länger aufzubewahren, führen Sie den Befehl gcloud firebase test android run
mit dem Flag --results-bucket
und übergeben Sie den Namen des Ergebnis-Buckets. Weitere Informationen finden Sie in der Referenzdokumentation gcloud firebase test android run
.
Wenn Sie Instrumentierungstests ausführen, werden möglicherweise Testfehler angezeigt, die auf Teilergebnisse hinweisen, die Meldungen wie Test run failed to complete. Expected x tests, received y
(wobei y
kleiner als x
ist). Dieser Fehler bedeutet, dass Test Lab den Logcat nicht nach Start- oder Endmarkierungen für Testfälle analysieren konnte, die normalerweise von AndroidJUnitRunner generiert werden.
Die folgenden sind häufige Ursachen für dieses Problem:
Fehlerbeschreibung | Mögliche Lösung |
---|---|
Der Testfall wurde aufgrund einer Zeitüberschreitung nicht ausgeführt. Wenn die Gesamtdauer der Tests länger als ein von Ihnen angegebenes Timeout oder länger als ein maximales Timeout ist, bricht Test Lab die restlichen Testfälle ab. |
|
Der Testfall konnte nicht abgeschlossen werden, weil er vorzeitig beendet wurde oder hängen blieb. Der Testfall wird möglicherweise aufgrund einer nicht abgefangenen Ausnahme oder eines Assertionsfehlers vorzeitig beendet. Testfälle können in einer Endlosschleife stecken bleiben oder möglicherweise nicht fortgesetzt werden, beispielsweise wenn die App nicht die richtige Ansicht anzeigt und der Testfall die Aktion auf der Benutzeroberfläche nicht ausführen kann. | Sehen Sie sich das Video und den logcat an, um herauszufinden, wo der Test gestoppt wurde. |
Ein benutzerdefinierter Testläufer (einschließlich der Erweiterung von AndroidJUnitRunner) stürzte unerwartet ab oder schrieb unerwartete Start- oder Endmarkierungen für Testfälle in logcat . | Überprüfen Sie Ihren Testläufercode. |
Es wurden zu viele Protokolle in logcat geschrieben, was den Puffer überlastete oder den logcat Prozess zum Absturz brachte. | Reduzieren Sie Schreibvorgänge in logcat . |
Die getestete App ist abgestürzt. | Debuggen Sie Ihre App. |
Häufig gestellte Fragen
Firebase Test Lab bietet kostenlose Kontingente für Tests auf Geräten und für die Nutzung von Cloud-APIs. Beachten Sie, dass das Testkontingent den Standard-Firebase-Preisplan verwendet, während dies bei den Cloud-API-Kontingenten nicht der Fall ist.
Testquote
Die Testkontingente werden durch die Anzahl der Geräte bestimmt, die zum Ausführen von Tests verwendet werden. Der Firebase Spark-Plan verfügt über ein festes Testkontingent, das für Benutzer kostenlos ist. Beim Blaze-Plan können sich Ihre Kontingente erhöhen, wenn Ihre Nutzung von Google Cloud im Laufe der Zeit zunimmt. Wenn Sie Ihr Testkontingent erreicht haben, warten Sie bis zum nächsten Tag oder führen Sie ein Upgrade auf den Blaze-Plan durch, wenn Sie derzeit den Spark-Plan nutzen. Wenn Sie bereits den Blaze-Plan nutzen, können Sie eine Kontingenterhöhung beantragen. Weitere Informationen finden Sie unter Kontingent testen .
Sie können die Nutzung Ihres Testkontingents in der Google Cloud Console überwachen.
Cloud Testing API-Kontingent
Die Cloud Testing API verfügt über zwei Kontingentgrenzen: Anfragen pro Tag und Projekt und Anfragen alle 100 Sekunden pro Projekt. Sie können Ihre Nutzung in der Google Cloud Console überwachen.
Cloud Tool Results API-Kontingent
Für die Cloud Tool Results API gibt es zwei Kontingentgrenzen: Abfragen pro Tag und Projekt und Abfragen alle 100 Sekunden pro Projekt. Sie können Ihre Nutzung in der Google Cloud Console überwachen.
Weitere Informationen zu API-Grenzwerten finden Sie unter Cloud-API-Kontingente für Testlabor . Wenn Sie ein API-Kontingent erreicht haben:
Senden Sie eine Anfrage für höhere Kontingente, indem Sie Ihre Kontingente direkt in der Google Cloud Console bearbeiten (beachten Sie, dass die meisten Limits standardmäßig auf Maximum eingestellt sind), oder
Fordern Sie höhere API-Kontingente an, indem Sie ein Anfrageformular in der Google Cloud Console ausfüllen oder sich an den Firebase-Support wenden.
Von Ihrem Backend aus können Sie feststellen, ob der Datenverkehr von auf Firebase gehosteten Testgeräten kommt, indem Sie die Quell-IP-Adresse mit unseren IP-Bereichen vergleichen.
Test Lab funktioniert nicht mit VPC-SC, das das Kopieren von Apps und anderen Testartefakten zwischen dem internen Speicher von Test Lab und den Ergebnis-Buckets der Benutzer blockiert.
Um unzuverlässiges Verhalten in Ihren Tests zu erkennen, empfehlen wir die Verwendung der Option--num-flaky-test-attempts. Deflake-Wiederholungen werden wie normale Testausführungen in Rechnung gestellt oder auf Ihr Tageskontingent angerechnet.
Beachten Sie Folgendes:
- Die gesamte Testausführung wird erneut ausgeführt, wenn ein Fehler erkannt wird. Es gibt keine Unterstützung für die Wiederholung nur fehlgeschlagener Testfälle.
- Die gleichzeitige Ausführung von Deflake-Wiederholungsversuchen ist geplant, es kann jedoch nicht garantiert werden, dass sie parallel ausgeführt werden, beispielsweise wenn der Datenverkehr die Anzahl der verfügbaren Geräte übersteigt.
Ja! Das Testlabor unterstützt Google Pixel Watch. Sie können jetzt Tests für Ihre eigenständige Wear-App auf Google Pixel Watches durchführen. Weitere Informationen zu Testlaborgeräten finden Sie unter Testen auf verfügbaren Geräten .
Ja! Test Lab unterstützt das Google Pixel Tablet und Google Pixel Fold. Sie können Ihre Tests auf Ihren eigenständigen physischen Geräten ausführen. Weitere Informationen zu Testlaborgeräten finden Sie unter Testen auf verfügbaren Geräten .
Wenn Sie Ihre App in Firebase testen oder Tests für einen Pre-Launch-Bericht in der Play Console ausführen, können Sie erkennen, ob ein Test auf einem von Firebase gehosteten Gerät ausgeführt wird, indem Sie nach der Systemeigenschaft firebase.test.lab
in suchen Ihre MainActivity
Datei. Anschließend können Sie weitere Anweisungen basierend auf dem booleschen Wert für testLabSetting
ausführen. Weitere Informationen finden Sie unter Geändertes Testverhalten .
Obwohl einige dieser Punkte auf unserer Roadmap stehen, können wir derzeit keine Zusage zur 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 im Test Lab ausführen.
Test Lab unterstützt die Verschleierung oder Entschleierung nicht ausdrücklich. Während die App wahrscheinlich ausgeführt wird, werden alle verschleierten App-Daten, wie etwa Stack-Traces, in den Protokollen als verschleiert angezeigt.
Ja! Sie können Ihr faltbares Gerät in faltbaren Zuständen und Haltungen testen.
Faltbare Geräte können in verschiedenen zusammengeklappten Zuständen vorliegen, z. B. FLAT
(vollständig geöffnet) oder HALF_OPENED
(zwischen vollständig geöffnet und vollständig geschlossen).
Haltungen hingegen bestehen aus einer bestimmten Geräteausrichtung und einem faltbaren Zustand. Zum Beispiel eine Tischhaltung, die in horizontaler Ausrichtung einen HALF_OPENED
Zustand hat, oder eine Buchhaltung, die in vertikaler Ausrichtung einen HALF_OPENED
Zustand hat.
Wenn Sie Instrumentierungstests ausführen, können Sie die Jetpack WindowManager- Bibliothek verwenden und die Dokumentation zum Testen Ihrer App auf faltbaren Geräten befolgen, um verschiedene Zustände und Stellungen zu testen.
Alternativ sind die verfügbaren Zustände gerätespezifisch und können mit dem adb shell command cmd device_state
interagiert werden.
- Um den aktuellen Status aufzulisten, führen Sie
adb shell cmd device_state state
aus. - Um den aktuellen Status festzulegen oder zu überschreiben, führen Sie
adb shell cmd device_state state <IDENTIFIER>
aus. - Um den Status zurückzusetzen, führen Sie
adb shell cmd device_state state reset
aus. - Um die verfügbaren Status zu überprüfen, führen Sie den Befehl
adb shell cmd device_state print-states
auf dem faltbaren Gerät aus.
Google Pixel Fold (Modell-ID felix
)
$ adb shell cmd device_state print-states Supported states: [ DeviceState{identifier=0, name='CLOSED', app_accessible=true}, DeviceState{identifier=1, name='HALF_OPENED', app_accessible=true}, DeviceState{identifier=2, name='OPENED', app_accessible=true}, DeviceState{identifier=3, name='REAR_DISPLAY_STATE', app_accessible=true}, ]
Samsung Galaxy Z Fold4 (Modell-ID q4q
)
$ adb shell cmd device_state print-states Supported states: [ DeviceState{identifier=0, name='CLOSE', app_accessible=true}, DeviceState{identifier=1, name='TENT', app_accessible=true}, DeviceState{identifier=2, name='HALF_FOLDED', app_accessible=true}, DeviceState{identifier=3, name='OPEN', app_accessible=true}, ]
Im Gegensatz zu anderen Firebase-Produkten müssen Sie kein Firebase SDK hinzufügen, um Test Lab nutzen zu können. Wenn Sie noch keine App haben, können Sie eine APK online herunterladen oder eine App und eine Test-APK aus einem der Beispiele im AndroidX GitHub-Repository erstellen. Beachten Sie, dass Sie zum Ausführen eines Robo-Tests nur die APK-Datei Ihrer App benötigen, während für einen Instrumentierungstest sowohl eine App als auch ein Test-APK erforderlich sind, die aus Quellcode erstellt werden. Weitere Informationen finden Sie unter Instrumentierte Tests .
Weitere Informationen zu den Test Lab-Funktionen finden Sie unter Erste Schritte mit dem Testen für Android mit Firebase Test Lab .
Bei Screenshot-Diff-Tests basieren Testaussagen auf dem Vergleich von Bildschirmbildern, die während der Durchführung eines Tests erhalten wurden, mit goldenen Bildern, die das erwartete Verhalten darstellen. Solche Tests können bei einigen Gerätetypen spröder sein als bei anderen. Wir empfehlen, für diese Art von Tests Arm-Emulatorgeräte ( *.arm
) als Ziel zu verwenden. Arm-Emulatorgeräte verwenden Bilder, die den „allgemeinen“ Android Studio-Emulatoren sehr ähnlich oder identisch sind.
Wir empfehlen Ihnen außerdem, Testbibliotheken zu untersuchen, die dazu beitragen können, Screenshot-Tests bei erwarteten Änderungen robuster zu machen.
Ja! Virtuelle Geräte werden aktualisiert, wenn die folgenden Änderungen vorgenommen werden:
- Aktualisierungen vorhandener Bilder
- Abschaffung früherer API-Ebenen
- Neue Android-API-Ebenen werden hinzugefügt
Um Abdeckungsberichte zu aktivieren, fügen Sie coverage=true
zum Feld environmentVariables
hinzu. Wenn Sie Android Test Orchestrator verwenden, müssen Sie ein Verzeichnis zum Speichern der Abdeckungsergebnisse bereitstellen:
--environment-variables coverage=true,coverageFilePath=/sdcard/Download/
Wenn Sie Orchestrator nicht verwenden, können Sie einen Dateipfad angeben:
--environment-variables coverage=true,coverageFile=/sdcard/Download/coverage.ec
Detaillierte Geräteinformationen sind über die API verfügbar und können über den gcloud-Client mit dem Befehl „beschreiben“ abgerufen werden:
gcloud firebase test android models describe MODEL
Bekannte Probleme
Der Robo-Test kann Anmeldebildschirme nicht umgehen, die über die Eingabe von Anmeldeinformationen hinaus zusätzliche Benutzeraktionen erfordern, beispielsweise das Ausfüllen eines CAPTCHA.
Robo-Test funktioniert am besten mit Apps, die UI-Elemente aus dem Android-UI-Framework verwenden (einschließlich View
, ViewGroup
und WebView
Objekte). Wenn Sie den Robo-Test verwenden, um Apps zu testen, die andere UI-Frameworks verwenden, einschließlich Apps, die die Unity-Spiel-Engine verwenden, wird der Test möglicherweise beendet, ohne über den ersten Bildschirm hinauszugehen.