Fehlerbehebung in Test Lab & Häufig gestellte Fragen

iOS Android

Auf dieser Seite finden Sie 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 das Gesuchte nicht finden oder zusätzliche Hilfe benötigen, nehmen Sie an unserem #test-lab-Kanal auf Firebase Slack teil oder wenden Sie sich an den Firebase-Support.

Fehlerbehebung

Warum dauert der Test so lange?

Wenn Sie im Test Lab-Katalog ein Gerät mit hoher Kapazität auswählen, können Tests schneller gestartet werden. Wenn ein Gerät eine geringe Kapazität hat, kann die Ausführung von Tests länger dauern. Wenn die Anzahl der aufgerufenen Tests viel größer als die Kapazität der ausgewählten Geräte ist, kann es länger dauern, bis die Tests abgeschlossen sind.

Tests auf jeder Gerätekapazitätsebene können aufgrund der folgenden Faktoren 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 für Test Lab eine Infrastruktur gemeldet wurde, sehen Sie im Firebase-Status-Dashboard.

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 treten häufig aufgrund von abgebrochenen Tests oder Infrastrukturfehlern auf.

Infrastrukturfehler werden durch interne Test Lab-Probleme wie Netzwerkfehler oder unerwartetes Geräteverhalten verursacht. Test Lab beendet interne Testläufe, die mehrmals zu Infrastrukturfehlern führen, bevor ein nicht eindeutiger Testbericht erstellt wird. Sie können diese Wiederholungen jedoch mit failFast deaktivieren.

So ermitteln Sie die Ursache des Fehlers:

1. Im Firebase-Status-Dashboard können Sie nach bekannten Ausfällen suchen.

2. Wiederholen Sie den Test in Test Lab, um zu prüfen, ob er reproduzierbar ist.

   Hinweis: Test Lab berechnet Ihnen keine Kosten für Infrastrukturfehler.

3. 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 haben meine Tests durch das Sharding länger gedauert?

Die Ausführung Ihrer Tests kann länger dauern, wenn die von Ihnen angegebene Anzahl von Shards die Anzahl der Geräte übersteigt, die in Test Lab verwendet werden können. Versuche, ein anderes Gerät zu verwenden, um dieses Problem zu vermeiden. 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 Tests auf einem Gerät auszuführen. Normalerweise dauert dieser Vorgang weniger als ein paar Sekunden. Er kann jedoch von Faktoren wie der Größe Ihrer App beeinflusst werden.

Nachdem Ihre App vorbereitet wurde, werden Testausführungen geplant und bleiben in der Warteschlange, bis ein Gerät bereit ist, sie auszuführen. Bis alle Testausführungen abgeschlossen sind, lautet der Matrixstatus „Ausstehend“, unabhängig davon, ob Testausführungen in der Warteschlange stehen oder aktiv ausgeführt werden.

Hinweis :Die Zeit, die Ihr Test auf ein verfügbares Gerät wartet, wird nicht auf die Abrechnungszeit angerechnet.

Warum dauert es so lange, bis mein Test abgeschlossen ist?

Nach Abschluss der Testausführung werden Testartefakte vom Gerät heruntergeladen, verarbeitet und auf Cloud Storage hochgeladen. Die Dauer dieses Schritts kann von der Anzahl und Größe der Artefakte beeinflusst werden.

Die App gibt keine Daten zurück und Screenshots können nicht gefunden werden

Artefakte zur Testausführung (z. B. Screenshots und Protokolldateien) werden in Google Cloud Storage gespeichert und direkt in der Firebase-Konsole gerendert. Wenn die Testausführung in den letzten 90 Tagen stattgefunden hat, prüfen Sie, ob Sie Rollen auf Projektebene zugewiesen haben (Projektinhaber, Projektbearbeiter oder Projektbetrachter). Cloud-Audit-Logging darf für Ihr Projekt oder Ihre Organisation nicht aktiviert sein.

Wenn die Ausführung vor mehr als 90 Tagen stattgefunden hat, wurden die Testartefakte höchstwahrscheinlich automatisch gelöscht. Sie können die Konfiguration des Ergebnis-Buckets prüfen, indem Sie im Test Lab-Dashboard auf den Tab Testergebnisse klicken. Der Standardergebnis-Bucket ist so konfiguriert, dass Objekte 90 Tage lang aufbewahrt werden.

Wenn Sie Ihre Testartefakte länger aufbewahren möchten, führen Sie den Befehl gcloud firebase test android run mit dem Flag --results-bucket aus und geben Sie den Namen des Ergebnis-Buckets an. Weitere Informationen finden Sie in der gcloud firebase test android run-Referenzdokumentation.

Warum erhalte ich nur teilweise oder keine Ergebnisse für Testfälle mit Instrumentierung?

Wenn Sie Instrumentierungstests ausführen, werden möglicherweise Testfehler angezeigt, die auf teilweise Ergebnisse hinweisen und Meldungen wie Test run failed to complete. Expected x tests, received y enthalten, wobei y kleiner als x ist. Dieser Fehler bedeutet, dass Test Lab das Logcat nicht für Start- oder Endmarkierungen des Testfalls parsen konnte, die normalerweise von AndroidJUnitRunner generiert werden.

Das kann folgende Ursachen haben:

Problembeschreibung	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 Zeitlimit oder länger als eine maximale Zeitüberschreitung ist, werden die restlichen Testfälle von Test Lab abgebrochen.	Erhöhen Sie das Zeitlimit für die Matrix, damit alle Tests abgeschlossen werden können. Sharden Sie die Tests, falls Sie dies noch nicht getan haben, damit auf jedem Shard ein Teil der Tests ausgeführt wird und der Test in kürzerer Zeit abgeschlossen wird. Wenn Sie die Sharding-Funktion bereits aktiviert haben, erhöhen Sie die Anzahl der Shards.
Der Testfall konnte nicht abgeschlossen werden, weil er vorzeitig beendet wurde oder hängengeblieben ist. Der Testfall wird möglicherweise aufgrund einer nicht abgefangenen Ausnahme oder eines Assertion-Fehlers vorzeitig beendet. Testfälle können in einer endlosen Schleife stecken bleiben oder nicht fortgesetzt werden, z. B. wenn in der App nicht die richtige Ansicht angezeigt wird und die Aktion im Testfall nicht auf der Benutzeroberfläche ausgeführt werden 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 Testfall-Start- oder Endmarkierungen in logcat geschrieben.	Prüfen Sie den Code des Testlaufs.
In logcat wurden zu viele Protokolle geschrieben, wodurch der Puffer überlastet oder der logcat-Prozess abgestürzt ist.	Schreibvorgänge auf logcat reduzieren
Die getestete App ist abgestürzt.	Debuggen Sie Ihre App.

Häufig gestellte Fragen

Wie hoch sind die kostenlosen Kontingente für Test Lab? Was soll ich tun, wenn meine Guthabenpunkte aufgebraucht sind?

Firebase Test Lab bietet kostenlose Kontingente für Tests auf Geräten und für die Verwendung von Cloud APIs. Für das Testkontingent gilt der standardmäßige Firebase-Preisplan, für die Cloud API-Kontingente hingegen nicht.

• Testkontingent

  Testkontingente richten sich nach der Anzahl der Geräte, auf denen Tests ausgeführt werden. Der Firebase Spark-Tarif bietet Nutzern ein kostenloses, festes Testkontingent. Beim Blaze-Tarif können Ihre Kontingente erhöht werden, wenn Sie Google Cloud mit der Zeit stärker nutzen. Wenn Sie Ihr Testkontingent erreicht haben, warten Sie bis zum nächsten Tag oder wechseln Sie zum Blaze-Tarif, 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 Console überwachen.

• Kontingent für die Cloud Testing API

  Die Cloud Testing API hat zwei Kontingentlimits: Anfragen pro Tag und pro Projekt sowie Anfragen pro 100 Sekunden und pro Projekt. Sie können Ihre Nutzung in der Google Cloud-Konsole im Blick behalten.

• Kontingent 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 im Blick behalten.

  Weitere Informationen zu API-Limits finden Sie unter Cloud API-Kontingente für Test Lab. Wenn Sie ein API-Kontingent erreicht haben:

  • Sie können ein höheres Kontingent beantragen, indem Sie Ihre Kontingente direkt in der Google Cloud Console bearbeiten. Die meisten Limits sind standardmäßig auf den Maximalwert festgelegt.

  • Wenn Sie ein höheres API-Kontingent benötigen, füllen Sie ein Antragsformular in der Google Cloud Console aus oder wenden Sie sich an den Firebase-Support.

Wie finde ich heraus, ob die Zugriffe auf mein Backend von Test Lab stammen?

Anhand der Quell-IP-Adresse können Sie in Ihrem Back-End feststellen, ob der Traffic von Firebase-gehosteten Testgeräten stammt. Vergleichen Sie dazu die IP-Adresse mit unseren IP-Bereichen.

Funktioniert Test Lab mit VPC-SC?

Test Lab funktioniert nicht mit VPC-SC, was das Kopieren von Apps und anderen Testartefakten zwischen dem internen Speicher von Test Lab und den Ergebnis-Buckets der Nutzer blockiert.

Wie erkenne ich fehlerhafte Tests in Test Lab?

Um in Ihren Tests fehlerhaftes Verhalten zu erkennen, empfehlen wir die Option --num-flaky-test-attempts . Wiederholungen von Defragmentierungsvorgängen werden wie normale Testausführungen in Rechnung gestellt oder auf Ihr Tageskontingent angerechnet.

Beachten Sie Folgendes:

• Die gesamte Testausführung wird noch einmal ausgeführt, wenn ein Fehler erkannt wird. Es wird nicht unterstützt, nur fehlgeschlagene Testfälle noch einmal auszuführen.
• Die Wiederholungsläufe der Defragmentierung werden zur gleichen Zeit geplant, laufen aber nicht garantiert parallel, z. B. wenn der Traffic die Anzahl der verfügbaren Geräte übersteigt.

Hinweis: Infrastrukturfehler sind unabhängig von der Deflate-Funktion und lösen keine Deflate-Wiederholungen aus.

Unterstützt Test Lab Wearables?

Sehr gut. Test Lab unterstützt Google Pixel Watch. Sie können jetzt Tests für Ihre eigenständige Wear OS-App auf Google Pixel Watches ausführen. Weitere Informationen zu Test Lab-Geräten finden Sie unter Auf verfügbaren Geräten testen.

Unterstützt Test Lab die neuesten Google-Geräte?

Sehr gut. Test Lab unterstützt Google Pixel Tablet und Google Pixel Fold. Sie können Ihre Tests auf Ihren eigenständigen physischen Geräten ausführen. Weitere Informationen zu Test Lab-Geräten finden Sie unter Auf verfügbaren Geräten testen.

Wie erkenne ich in Test Lab, dass ein Test ausgeführt wird?

Wenn Sie Ihre App in Firebase testen oder Tests für einen Pre-Launch-Bericht in der Play Console ausführen, können Sie feststellen, ob ein Test auf einem von Firebase gehosteten Gerät ausgeführt wird. Suchen Sie dazu in der Datei MainActivity nach der Systemeigenschaft firebase.test.lab. Sie können dann zusätzliche Anweisungen basierend auf dem booleschen Wert für testLabSetting ausführen. Weitere Informationen finden Sie unter Änderungen am Testverhalten.

Unterstützt Test Lab Appium, Flutter/FlutterDriver, ReactNative/Jest oder Cucumber?

Einige dieser Elemente sind zwar auf unserer Roadmap, wir können derzeit jedoch keine Zusicherungen zur Unterstützung dieser Plattformen für Tests und App-Entwicklung 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 dann in Test Lab ausführen.

Unterstützt Test Lab den Test verschleierter Apps, z. B. mit ProGuard oder R8?

Test Lab unterstützt weder Obfuscation noch Deobfuscation explizit. Die App wird wahrscheinlich ausgeführt, aber alle verschleierten App-Daten wie Stack-Traces werden in den Protokollen ebenfalls verschleiert angezeigt.

Kann ich mein faltbares Gerät in verschiedenen Falt- und Positionen verwenden, während ich auf Test Lab teste?

Sehr gut. Sie können Ihr faltbares Gerät in verschiedenen Zuständen und Positionen testen.

Faltbare Geräte können sich in verschiedenen Zuständen befinden, 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 bestimmten Faltstatus. Beispielsweise die Position „Auf dem Tisch“, ein HALF_OPENED-Status in horizontaler Ausrichtung, oder die Position „Buch“, ein HALF_OPENED-Status in vertikaler Ausrichtung.

Wenn Sie Instrumentierungstests ausführen, können Sie die Jetpack WindowManager-Bibliothek verwenden und der Dokumentation zum Testen Ihrer App auf faltbaren Geräten folgen, um verschiedene Status und Positionen zu testen.

Alternativ sind die verfügbaren Status gerätespezifisch und können über die adb shell command cmd device_state gesteuert werden.

• Führen Sie adb shell cmd device_state state aus, um den aktuellen Status aufzulisten.
• Wenn Sie den aktuellen Status festlegen oder überschreiben möchten, führen Sie adb shell cmd device_state state <IDENTIFIER> aus.
• Führen Sie adb shell cmd device_state state reset aus, um den Status zurückzusetzen.
• Führen Sie den Befehl adb shell cmd device_state print-states auf dem faltbaren Gerät aus, um die verfügbaren Status zu prüfen.

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},
]

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 Samples im AndroidX-GitHub-Repository erstellen. Für einen Robo-Test benötigen Sie nur die APK-Datei Ihrer App. Für einen Instrumentierungstest sind dagegen sowohl eine App als auch ein Test-APK erforderlich, die aus dem Quellcode erstellt werden. Weitere Informationen finden Sie unter Instrumentierte Tests.

Weitere Informationen zu den Funktionen von Test Lab finden Sie unter Erste Schritte mit Firebase Test Lab.

Welche Geräte eignen sich am besten für Screenshot-Diff-Tests?

Bei Screenshot-Diff-Tests basieren Testaussagen auf dem Vergleich von Screenshots, die während eines Tests erfasst wurden, mit Gold-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. Arm-Emulatoren verwenden Images, die den generischen Emulatoren von Android Studio sehr ähnlich oder identisch sind.

Wir empfehlen Ihnen außerdem, Testbibliotheken zu verwenden, mit denen sich Screenshot-Tests bei erwarteten Änderungen robuster gestalten lassen.

Aktualisiert Test Lab virtuelle Geräte?

Sehr gut. Virtuelle Geräte werden aktualisiert, wenn folgende Änderungen vorgenommen werden:

1. Aktualisierungen vorhandener Bilder
2. Einstellung früherer API-Ebenen
3. Es werden neue Android-API-Level hinzugefügt.

Wie aktiviere ich Abdeckungsberichte?

Wenn Sie Abdeckungsberichte aktivieren möchten, fügen Sie dem Feld environmentVariables das Zeichen coverage=true hinzu. Wenn Sie Android Test Orchestrator verwenden, müssen Sie ein Verzeichnis angeben, in dem die Abdeckungsergebnisse gespeichert werden sollen:

--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

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“ abgerufen werden:

gcloud firebase test android models describe MODEL

Bekannte Probleme

Captchas bei der Anmeldung

Robotests können keine Anmeldebildschirme umgehen, für die neben der Eingabe von Anmeldedaten noch eine zusätzliche Nutzeraktion erforderlich ist, z. B. das Ausfüllen eines CAPTCHAs.

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-Objekte). Wenn Sie Robo Test zum Testen von Apps verwenden, die andere UI-Frameworks verwenden, einschließlich Apps, die die Unity-Game-Engine verwenden, wird der Test möglicherweise beendet, ohne dass der erste Bildschirm geprüft wurde.