Fehlerbehebung in Test Lab & Häufig gestellte Fragen
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 sind auch
dokumentiert ist. Wenn Sie nicht finden,
wenn Sie Hilfe suchen oder weitere Hilfe benötigen, können Sie am #test-lab teilnehmen.
Kanal aktiviert
Firebase Slack oder wenden Sie sich an Firebase
support.
Fehlerbehebung
Warum dauert die Ausführung meines Tests so lange?
Wenn du in der Test Lab ein Gerät mit hoher Kapazität auswählst
werden Tests möglicherweise schneller gestartet. Wenn ein
Gerät eine geringe Kapazität hat, kann die Ausführung der Tests länger dauern. Wenn die Anzahl der
aufgerufenen Tests ist viel größer als die Kapazität der ausgewählten Geräte,
kann es länger dauern.
Tests, die auf einer beliebigen Stufe der Gerätekapazität ausgeführt werden, können aufgrund der
folgenden Faktoren:
Traffic, der sich auf die Geräteverfügbarkeit und die Testgeschwindigkeit auswirkt.
Geräte- oder Infrastrukturausfälle, 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 findest du unter „Gerätekapazität“
für Android und iOS.
Warum erhalte ich nicht aussagekräftige Testergebnisse?
Nicht aussagekräftige Testergebnisse treten häufig aufgrund abgebrochener Testläufe auf
oder Infrastrukturfehlern auftreten.
Infrastrukturfehler werden durch interne Test Lab-Probleme verursacht, z. B. das Netzwerk
Fehler oder unerwartetes Geräteverhalten. 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.
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 in der
#test-lab-Version aktiviert
Firebase Slack
Warum wurden meine Tests durch die Fragmentierung ausgeführt?
länger?
Die Fragmentierung kann dazu führen, dass Ihre Tests
länger laufen, wenn die Anzahl der
angegebene Anzahl überschreitet die Anzahl der Geräte, 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, siehe
Gerätekapazität.
Warum dauert es so lange,
Test starten?
Wenn Sie eine Testanfrage einreichen, wird Ihre App zuerst in einem der folgenden Dienste validiert, neu signiert usw.
Vorbereitung auf die Durchführung von Tests auf einem Gerät. Normalerweise wird dieser Prozess
weniger als ein paar Sekunden, kann aber von Faktoren wie der
Nachdem Ihre Anwendung vorbereitet ist, werden Testausführungen geplant und bleiben in einer Warteschlange
bis ein Gerät zur Ausführung bereit ist. Bis alle Testausführungen abgeschlossen sind,
lautet der Matrixstatus „Ausstehend“. (unabhängig davon, ob Testausführungen
in der Warteschlange oder aktiv ausgeführt wird).
Warum dauert es so lange,
um den Test abzuschließen?
Nach Abschluss der Testausführung werden Testartefakte vom Gerät heruntergeladen, verarbeitet und auf Cloud Storage hochgeladen. Die Dauer dieses Schritts kann
von der Menge und Größe der Artefakte beeinflusst.
Die App gibt keine Daten zurück und kann keine Screenshots finden
Artefakte zur Testausführung wie Screenshots und Protokolldateien werden in
Google Cloud Storage und direkt in der Firebase-Konsole gerendert. Wenn
Ihre Testausführung in den letzten 90 Tagen durchgeführt wurde.
zugewiesenen Rollen auf Projektebene (Projektinhaber, -bearbeiter oder -betrachter)
Achten Sie außerdem darauf, dass Cloud-Audit-Logging für Ihr Projekt nicht aktiviert ist
oder Ihrer Organisation.
Wenn die Ausführung vor mehr als 90 Tagen erfolgte,
wahrscheinlich, dass die Testartefakte automatisch gelöscht wurden. Sie können die Konfiguration des Ergebnis-Buckets prüfen, indem Sie im Test Lab-Dashboard auf den Tab Testergebnisse klicken. Das Standardergebnis
Bucket ist so konfiguriert, dass Objekte 90 Tage lang aufbewahrt werden.
Führen Sie den Befehl aus, um die Testartefakte länger aufzubewahren.
gcloud firebase test android run mit dem Flag --results-bucket und übergeben Sie die URL
den Namen des Ergebnis-Buckets. Weitere Informationen finden Sie in der
Referenzdokumentation zu gcloud firebase test android run
Warum erhalte ich unvollständige oder fehlende Ergebnisse eines Instrumentierungstestlaufs?
Wenn Sie Instrumentierungstests ausführen, werden möglicherweise Testfehler angezeigt, die auf unvollständige
Ergebnisse, die Botschaften wie Test run failed to complete. Expected
x tests, received y enthalten (wobei y kleiner als x ist).
Dieser Fehler bedeutet, dass Test Lab den Logcat für den Start des Testlaufs nicht parsen konnte
oder Endmarkierungen, die in der Regel von
AndroidJUnitRunner.
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 ist länger als das von Ihnen angegebene Zeitlimit oder länger als ein
maximales ZeitlimitTest Lab bricht die restlichen Testläufe ab.
Erhöhen Sie das Zeitlimit für die Matrix, um sicherzustellen, dass alle Tests abgeschlossen werden können.
Fragmentieren Sie die Tests, falls Sie dies noch nicht getan haben, sodass jeder Shard eine
Teilmenge der Tests und wird in einem kürzeren Zeitraum durchgeführt.
Wenn Sie die Fragmentierung 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 kann aufgrund einer nicht abgefangenen Ausnahme oder
Assertion-Fehler. Testfälle können in einer Endlosschleife stecken
nicht fortfahren kann, z. B. wenn die App nicht die richtige Ansicht anzeigt und
der Testfall die Aktion nicht auf der Benutzeroberfläche ausführen kann.
Sehen Sie sich das Video und das logcat an, um zu erfahren, an welcher Stelle der Test
angehalten.
Ein benutzerdefinierter Test-Runner (einschließlich Erweiterung von AndroidJUnitRunner) ist abgestürzt.
oder unerwartete Start- oder Endmarkierungen des Testlaufs
logcat
Überprüfen Sie den Test-Runner-Code.
In logcat wurden übermäßig viele Logs geschrieben, wodurch der Zwischenspeicher überlastet wurde
oder den logcat-Prozess zum Absturz bringen.
Schreibvorgänge auf logcat reduzieren.
Die zu testende App ist abgestürzt.
Fehler in der App beheben
Häufig gestellte Fragen
Welche kostenlosen Kontingente gibt es?
für Test Lab? Was kann ich tun, wenn mein Kontingent aufgebraucht ist?
Firebase Test Lab bietet kostenlose Kontingente zum Testen auf Geräten und zur Verwendung
Cloud APIs Für das Testkontingent gilt das Firebase-Standard-Preismodell,
die Cloud API-Kontingente jedoch nicht.
Testkontingent
Testkontingente richten sich nach der Anzahl der Geräte, die zum Ausführen von Tests verwendet werden.
Für den Firebase Spark-Tarif gibt es ein festes Testkontingent, das für Nutzer kostenlos ist. 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 führen Sie ein Upgrade auf den Tarif „Blaze“ durch, wenn Sie derzeit den Tarif „Spark“ nutzen.
Wenn Sie bereits den Tarif „Blaze“ nutzen, können Sie eine Kontingenterhöhung anfordern.
Weitere Informationen finden Sie unter
Testkontingent.
Sie können die Nutzung Ihrer Testkontingente in der Google Cloud-Konsole überwachen.
Cloud Testing API-Kontingent
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.
Kontingent für die Cloud Tool Results API
Für die Cloud Tool Results API gelten zwei Kontingentlimits: Abfragen pro Tag und
und Abfragen alle 100 Sekunden und Projekt. Sie können Ihre
Nutzung in der
Google Cloud-Konsole.
Höhere Kontingente beantragen bis zum
Kontingente bearbeiten
in der Google Cloud-Konsole öffnen. Die meisten Limits sind auf
„Maximum“) oder
Höhere API-Kontingente können Sie anfordern, indem Sie ein Anfrageformular in der
Google Cloud-Konsole oder indem Sie sich an
Firebase-Support.
Wie finde ich heraus, ob das
kommt Traffic, der mein Backend erreicht, von Test Lab?
Über das Backend können Sie feststellen, ob der Traffic von Firebase stammt,
um Geräte zu testen, indem Sie die Quell-IP-Adresse mit der
IP-Bereiche:
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
. Wiederholte Ausführungen werden genauso abgerechnet wie
normale Testausführungen durchführen.
Beachten Sie Folgendes:
Wenn ein Fehler erkannt wird, wird die gesamte Testausführung noch einmal ausgeführt. Es gibt keine
nur die Wiederholung fehlgeschlagener Testläufe.
Deflake-Wiederholungsausführungen werden zur selben Zeit geplant, aber nicht
die garantiert parallel ausgeführt wird, z. B. wenn der Traffic die Anzahl der
verfügbaren Geräten.
Unterstützt Test Lab
Wearables?
Ja! Test Lab unterstützt Google Pixel Watch. Sie können jetzt Tests für
Ihre eigenständige Wear-App auf Google Pixel Watches. Weitere Informationen über
Test Lab Geräte, siehe Testen auf
verfügbaren Geräte.
Unterstützt Test Lab die neuesten Google-Geräte?
Ja! Test Lab unterstützt Google Pixel Tablet und Google Pixel Fold. Sie können
Tests auf eigenständigen physischen Geräten durchführen.
Weitere Informationen über
Test Lab Geräte, siehe Testen auf
verfügbaren Geräten.
Wie erkenne ich einen laufenden Test?
in Test Lab?
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 weitere
Anweisungen auf Grundlage des booleschen Werts für testLabSetting. Weitere Informationen
finden Sie unter
Geändertes Testverhalten:
Hat Test Lab
unterstützen Appium, Flutter/FlutterDriver, ReactNative/Jest oder Gurken?
Obwohl sich einige dieser Punkte in unserer Roadmap befinden, können wir derzeit keine
diese Plattformen für Tests und App-Entwicklung unterstützen. Sie können jedoch
Wenn Sie Ihre App mit einem Framework erstellt haben, das Espresso unterstützt (z. B.
Flutter), können Sie einen Instrumentierungstest mit
Espresso
und führen Sie dann den Test in Test Lab aus.
Hat Test Lab
das Testen verschleierter Apps unterstützen, z. B. mit ProGuard oder R8)?
Test Lab unterstützt die Verschleierung oder Offenlegung nicht explizit. Während
die App ausgeführt wird, verschleierte App-Daten
wie Stacktraces,
werden in den Logs als verschleiert angezeigt.
Kann ich mein faltbares Gerät
verschiedene Status und Einstellungen des faltbaren Geräts beim Testen auf Test Lab?
Faltbare Geräte können sich in einem zusammengeklappten Zustand befinden, z. B. FLAT (vollständig geöffnet) oder HALF_OPENED (vollständig geöffnet oder vollständig geschlossen).
Sicherheitsstatus hingegen sind auf eine bestimmte Geräteausrichtung und faltbare Geräte
Bundesstaat. Zum Beispiel die Haltung „Auf dem Tisch“ im horizontalen Modus „HALF_OPENED“ oder „Buchhaltung“ mit dem Status „HALF_OPENED“ bei vertikaler Ausrichtung.
Kann ich Test Lab ausprobieren, wenn ich keine
eine App?
Im Gegensatz zu anderen Firebase-Produkten ist es hier nicht erforderlich,
SDK, um Test Lab zu verwenden. Wenn Sie noch keine App haben, können Sie
laden Sie online ein APK herunter oder erstellen Sie eine App und ein Test-APK mit einer der
im GitHub-Repository für AndroidX.
Beachten Sie, dass Sie nur die
App-APK-Datei verwenden, um einen Robo-Test durchzuführen, während für einen Instrumentierungstest beides erforderlich ist.
eine App und ein Test-APK,
die aus Quellcode erstellt wurden. Weitere Informationen
Weitere Informationen zu instrumentierten Tests
Welche Geräte sind am besten geeignet?
Screenshot-Differenz-Tests?
Bei Screenshot-Differenz-Tests basieren Testbehauptungen auf einem Bildschirmvergleich.
Bilder erhalten, die während eines Tests mit goldenen Bildern für die erwarteten
verhalten. Solche Tests sind auf einigen Gerätetypen möglicherweise fehleranfälliger als auf anderen. Wir empfehlen die Ausrichtung
Aktivieren Sie (*.arm)-Emulatorgeräte für diese Art von Tests. ARM-Emulator-Geräte verwenden
Images, die den "generischen" Emulatoren von Android Studio sehr ähnlich oder identisch sind.
Wir empfehlen Ihnen außerdem, Testbibliotheken zu untersuchen, die
Screenshot-Tests sind bei erwarteten Änderungen zuverlässiger.
Aktualisiert Test Lab virtuelle Geräte?
Ja! Virtuelle Geräte werden aktualisiert, wenn die folgenden Änderungen vorgenommen werden:
Aktualisierungen vorhandener Images
Einstellung früherer API-Levels
Neue Android API-Level wurden hinzugefügt
Wie aktiviere ich Abdeckungsberichte?
Fügen Sie coverage=true hinzu, um Abdeckungsberichte zu aktivieren
environmentVariables-Feld.
Wenn Sie Android Test Orchestrator verwenden, müssen Sie ein Verzeichnis angeben, in dem die Abdeckungsergebnisse gespeichert werden sollen:
Wo finde ich Gerätedetails wie
Auflösung, unterstützte ABIs usw.?
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
Anmelde-Captchas
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 den Robo-Test zum Trainieren von Apps verwenden, die andere UI verwenden
einschließlich Apps, die die Unity-Spiel-Engine nutzen, wird der Test möglicherweise beendet.
ohne den ersten Bildschirm zu erkunden.