Android-Test: AWS Device Farm gegen Firebase TestLab

Ein ganzes Jahr ist vergangen, seit ich angefangen habe, an einer Testlösung für Android-Automatisierung für ein großes Unternehmen zu arbeiten. Das Projekt wird jetzt an ein anderes Team übergeben, und es ist Zeit, die wertvollen Erfahrungen zu teilen.

Unsere Aufgabe war es, nur E2E-Tests zu automatisieren. Eine der ersten Entscheidungen, die wir treffen mussten, ist die Auswahl eines seriösen Unternehmens, das alle Arten von physischen Geräten für Testzwecke "mietet". Zunächst dachten wir an eine Self-Hosting-Lösung, die an die Cl-Pipeline angeschlossen werden könnte, aber niemals eine ausreichend granulare Gerätediversität bereitstellen könnte. Aus diesem Grund haben wir uns auf die Suche nach Cloud-Lösungen gemacht.

Da wir eine Lösung brauchten, die sowohl Android- als auch iOS-Plattformen mit einer großen Anzahl verschiedener Geräte unterstützt, zeichnete sich AWS DeviceFarm als eine Lösung aus, von der wir uns sicher sind, dass sie stabil genug ist, mit reaktionsschneller Unterstützung und allgemeiner Benutzerfreundlichkeit.

AWS DeviceFarm

Bei der ersten Verwendung werden Sie den Dienst wahrscheinlich über die Web-Benutzeroberfläche ausprobieren. Es sind nur ein paar obligatorische Schritte erforderlich, um den Testlauf zu starten:

  • Wählen Sie einen Testtyp: Instrumentation
  • Lade test apk hoch
  • App hochladen apk
  • Geräte auswählen (so genannten Gerätepool erstellen)
  • Wenn Sie kein zusätzliches Datenpaket benötigen, klicken Sie auf Ausführen.

Und im Grunde ist es das. Die Tests werden auf ausgewählten Geräten ausgeführt. Wenn alles gut läuft, wird die kumulative Bestanden / Nicht Bestanden-Statistik pro Gerät und eine detaillierte Liste der bestandenen und nicht bestanden Tests angezeigt.

Für jeden Test können Sie standardmäßig das Instrumentierungsprotokoll, das Protokoll und die Videoaufzeichnung abrufen.

Wenn die CI-Pipeline verwendet wird, wird die Web-Benutzeroberfläche jedoch nicht häufig verwendet. Daher müssen Sie entweder die AWS-CLI oder ein Plug-in für den Build-Server verwenden. Wir haben die Jenkins verwendet, die die AWS DeviceFarm-Kommunikation unterstützen (natürlich über das Plugin).

Zumindest bei der Testdurchführung hat es sehr gut geklappt. Ein erstes großes Problem, über das wir gestolpert sind, war die fehlende Berichterstattung. Es gibt keine Option zum Hinzufügen einer E-Mail oder von E-Mails, die den Testbericht erhalten sollen. Tatsächlich gibt es überhaupt keinen Bericht, nicht einmal einen verdauten, der an den Kunden weitergeleitet werden könnte. Wir hatten die Möglichkeit, den Zugriff auf unser AWS-Projekt zuzulassen, damit die Testergebnisse über das Web Ul überprüft werden konnten.

JUnit4-Unterstützung - Deal Breaker

Auf der Android-Seite war das Testverfahren kompliziert genug und wir mussten ein paar Kompromisse eingehen. Eine davon bestand darin, aufgrund des komplexen und langen Anmeldevorgangs in der App eine strikte Reihenfolge der Testausführung zu erzwingen.

Zu diesem Zweck haben wir als ersten Schritt präzise Testsuiten erstellt. Ein praktisches Verhalten der Testsuite-Definition unter Android ist, dass Testklassen in der Reihenfolge ausgeführt werden, in der sie in der @ SuiteClasses-Annotation definiert sind.

Als zweites mussten wir die Tests auch innerhalb der Testklassen bestellen, was wir mit der einzigen verfügbaren Option erledigten: @FixMethodOrder Annotation.

Und das war das Ende der Reise für uns mit AWS DeviceFarm, da JUnit4 nur teilweise implementiert wurde, ohne Unterstützung für die Definition von Testsuiten oder für FixMethodOrder! Da wir keine Optionen hatten, mussten wir den Service einstellen, da wir die Tests nicht wie gewünscht durchführen konnten.

Firebase TestLab

Bevor wir die AWS aufgeben konnten, mussten wir sicherstellen, dass wir einen Dienst finden, der immer noch seriös genug und mit guter Unterstützung ist, der diese JUnit4-Einschränkungen nicht aufweist. Wir haben die Firebase ausprobiert und es hat funktioniert.

Über die Web-Benutzeroberfläche sind die Schritte zur Einrichtung fast identisch mit denen von AWS:

  • Wählen Sie einen Testtyp: (auch Instrumentierung)
  • Lade beide APKs hoch
  • Wähle ein Gerät
  • Lauf.
  • Beobachten Sie die Testergebnisse pro Gerät und pro Test mit Zugriff auf Videoaufzeichnungen und Protokolle.

Natürlich können wir die Web-Benutzeroberfläche nicht verwenden, daher verwenden wir am Ende die CLI-Lösung für Firebase: gcloud.

Mit der gcloud können wir die Art des Tests, die Pfade zu den apk-Dateien, das Ergebnisverzeichnis und den Bucket auf Google Cloud Storage sowie das Testziel definieren, das neben allen Standardoptionen wie Testpaket oder Einzeltest auch das akzeptiert Testsuite als Ziel unter Beachtung der Ausführungsreihenfolge.

Firebase TestLab funktioniert zwar ähnlich wie AWS DeviceFarm, verlässt sich jedoch auf Google Stack und speichert alle Testergebnisse im Eimer von Google Cloud Storage. Das ist großartig, da wir direkt auf die Dateien zugreifen können.

Kleiner Hinweis: Um den benutzerdefinierten Bucket und Pfad pro Testausführung zu definieren, ist ein kostenpflichtiger Zugriff auf Google Cloud Storage erforderlich. Bei Verwendung von freiem Speicher werden die Testergebnisse im Verzeichnis testlab / random-hash gespeichert und nach 90 Tagen entfernt.

Da wir direkt auf die Testergebnisse zugreifen konnten, konnten wir den Testbericht nach unseren Wünschen erstellen, was unseren Kunden sehr gefiel. Dennoch möchte ich erwähnen, dass Firebase auch keine Systemberichtslösung bietet, bei der wir nur die Mailingliste erstellen können, um die Ergebnisse zu liefern. In der Konsolenausgabe werden die Ergebnisse pro Gerät verdaut.

Timeouts:

Die Firebase bietet uns zwar die Möglichkeit, Testsuiten auszuführen, ist jedoch nicht kostenlos. Das maximale Zeitlimit für die Testausführung beträgt 30 Minuten. Dies ist mehr als genug für 90% der Anwendungsfälle. In unserem Fall stellte sich jedoch heraus, dass eine Testsuite mit allen Testklassen eine problematische Lösung darstellt, da unsere E2E-Tests mehr als 60 Minuten dauern.

Der Grund für dieses 30-Minuten-Limit ist laut den Diskussionen in den Google-Foren und bei Slack die Systemstabilität. Daher fanden sie den Kompromiss in 30 Minuten. Wenn Sie etwas länger ausführen, wird dies ohne Ergebnis abgebrochen.

Wir haben dieses Problem gelöst, indem wir viele kleine Testsuiten erstellt haben, die nacheinander mit separaten gcloud-Aufrufen ausgeführt werden. Infolgedessen war die Berichterstellung noch komplexer, aber möglich, sodass wir am Ende die funktionierende Lösung hatten.

Vergleich:

Hier versuchen wir, die Vor- und Nachteile beider Dienste zusammenzufassen:

  1. CLI-Einfachheit: Firebase
  2. Plugin-Zugriff: AWS
  3. Systemberichte (Mailingliste): Keine
  4. Berichte Zugänglichkeit: Firebase
  5. Verdauter Bericht: Firebase
  6. Geräteauswahl: AWS (Firebase hat 15-20 verschiedene Geräte)
  7. Aktuelle Kompatibilität: Firebase
  8. Supportzugänglichkeit: Firebase (fast sofort über Slack)
  9. Gerätefernbedienung: AWS
  10. Systemstabilität: AWS (In Firebase gab es auf bestimmten Geräten viele "Infrastrukturfehler".)
  11. IDE-Integration: Firebase
  12. iOS-Unterstützung: Beide (mit dem geringen Vorteil für AWS, da die Unterstützung für Firebase XCUITest zum Zeitpunkt des Schreibens in der geschlossenen Beta vorliegt)

Diese Liste könnte immer weitergehen, aber es ist nicht das Ziel, Ihnen mitzuteilen, dass Sie niemals Service X verwenden sollten. Ich wollte auf die Probleme und Vorteile des realen Beispiels hinweisen.

Fazit

Ein allgemeines Gefühl, das ich als Benutzer dieser Dienste bekomme, ist, dass es keine große Wahlfreiheit gibt. Da unsere Anforderungen und Erwartungen höher sind, sind auch die Wände, auf die wir treffen, höher, und das passiert sehr oft. Das Schlimmste daran ist, dass Sie sich all dieser kleinen Probleme nicht bewusst sind, wenn Sie eine Entscheidung treffen. Wer würde über JUnit4-Probleme in AWS nachdenken ... aber es passiert.

Hinweis: Diese Dienste werden für unbegrenzt bezahlte Tarife verwendet, einschließlich des in Google Cloud Storage generierten Datenverkehrs. Es gab keine Serviceeinschränkungen aufgrund der kostenlosen oder Testnutzung.

Bleib vorsichtig!