Der Artikel wird im Auftrag von Andrey Ivanov und Ekaterina Bateeva , neifmetus , veröffentlicht
Die Automatisierung mobiler Anwendungen ist ein relativ junger Bereich: Es gibt viele Frameworks und viele Projekte stehen vor dem Problem, die „schnellsten, stabilsten und benutzerfreundlichsten“ auszuwählen. Vor ungefähr zwei Jahren standen wir auch vor der Wahl eines neuen Automatisierungstools zum Testen von Android-Anwendungen.
Alle gängigen Tools basierten irgendwie auf UIAutomator und Espresso, daher haben wir uns entschlossen, sie in ihrer reinen Form zu testen und sie mit demselben Appium (dem beliebtesten) und
seeTest (zuvor verwendet, dem besten unter den bezahlten zu dieser Zeit) zu vergleichen.
Von den Vorteilen von Appium kann man die übliche WebDriver-API unterscheiden, die Fähigkeit, die gängigsten Sprachen und Bibliotheken zu verwenden. Darüber hinaus ist es in vielen Unternehmen weit verbreitet und ermöglicht es Ihnen, Tests direkt für iOS- und Android-Plattformen zu schreiben. Und schließlich ist dies eine kostenlose Box-Lösung - was könnte besser sein?
Also dachten wir, bis wir folgende Mängel entdeckten:
- geringe Stabilität von Appium Server
- Sie können nicht mit den öffentlichen Methoden der Aktivität interagieren (im Jahr 2018 sprach Nikolai Abalov von Badoo in seinem Artikel über das Erstellen einer Hintertür in Appium, den Sie hier lesen können).
- Die Geschwindigkeit der Espressotests ist deutlich geringer
Für uns waren diese Momente von entscheidender Bedeutung. Daher wurde beschlossen, eigene Tools rund um Espresso zusammenzustellen, um ein Ökosystem zum Testen mobiler Anwendungen aufzubauen.
Also, das Framework wurde ausgewählt, es blieb, um die restlichen Komponenten zu finden:
- Runner - sollte es ermöglichen, Tests parallel auszuführen und Gerätepools zu konfigurieren
- Reporter - muss einen lesbaren Bericht bereitstellen, der von jedem Teammitglied verwendet werden kann
Die Werkzeuge
Mit dem Läufer war alles in Ordnung, ein wenig auf Github graben,
Shazam / Gabel wurde gewählt.
Sie können den Gerätepool bequem konfigurieren, einfach ändern und einen einfachen HTML-Bericht erstellen. Logcat wird im Falle eines Stacktrace-Tests und eines Videoabsturzes auf jeden Bericht angewendet. Die Videoaufnahme funktioniert nicht richtig, alle Videos dauern 1 Minute, manchmal werden mehrere Tests auf dem Video aufgezeichnet.
Die Gabelberichte waren alles andere als ideal, der Endbenutzer verstand nicht, was im Test vor sich ging, nur anhand seines Namens, ohne einen Testfall zur Hand zu haben. Ich wollte Schritte mit Dateianhängen haben, mit denen ich den Bericht strukturieren konnte. Die Suche nach einem Reporter für Instrumentierungstests ergab 2 Varianten von Löffel und Gurke. Beide Optionen wurden verworfen, da eine Reihe von Screenshots im Fall von Löffel und Bdd von Gurke das Problem nicht vollständig gelöst haben ...
Allure schien die optimalste Lösung für das Problem zu sein:
- Verschachtelung von Schritten, mit denen Sie den Bericht strukturieren können
- die Fähigkeit, benutzerdefinierte Testdaten aufzuzeichnen (Screenshots, Video, Aufgabennummer, Testparameter)
- prägnante Ansicht des Berichts
Aber es gab eine Einschränkung: Allure startet einfach nicht auf Android.
Allure-Android
In Verbindung mit dem oben Gesagten wurde beschlossen, eine Bibliothek zu schreiben, die die Einfachheit und Eleganz von Kotlin, die Vorteile des Allure-Frameworks und die Funktion auf Android-Handys kombiniert. Fügen Sie dem Modul, in dem sich Instrumentierungstests befinden, Abhängigkeiten hinzu, um die Bibliothek zu verbinden:
dependencies { androidTestImplementation "ru.tinkoff.allure:allure-android:$allureVersion@aar" androidTestImplementation "ru.tinkoff.allure:allure-common:$allureVersion" androidTestImplementation "ru.tinkoff.allure:allure-model:$allureVersion" }
Nach dem Einrichten der Abhängigkeiten müssen wir
AllureRunListener bei der Klasse registrieren, die für die Ausführung von Android-Tests verantwortlich ist.
Es gibt drei Möglichkeiten, dies zu tun:
- Zu build.gradle hinzufügen
testInstrumentationRunner "ru.tinkoff.allure.android.AllureAndroidRunner"
- Listener zu Argumenten in Runner onCreate hinzufügen (Argumente: Bundle)
arguments.putCharSequence("listener", AllureAndroidListener::class.java.name)
- Direkt von AllureAndroidRunner geerbt
Allure-Berichte basieren auf Schritt - einem Schritt, einer atomaren Aktion, die während eines Tests ausgeführt wird. Anmerkungen zum Allure
Step- und
Parameter- Framework wurden durch einen direkten Aufruf der step () -Funktion ersetzt.
inline fun <T : Any?> step(description: String, vararg params: Parameter, block: () -> T): T
Diese Funktion ersetzt nicht nur zwei Anmerkungen gleichzeitig, sondern akzeptiert auch ein Lambda, in das Sie die Testlogik einschließen sollten. Zum Beispiel:
Nach dem Start des Tests werden Berichte im JSON-Format, die für Allure2 vorbereitet wurden, auf dem Telefon im Ordner / sdcard / allure-results angezeigt. Nachdem das Team das Ergebnis herausgezogen hat
adb pull /sdcard/allure-results
Wir können einen Bericht erstellen
allure generate
Von den zusätzlichen Merkmalen können wir unterscheiden:
- die Fähigkeit, Schritte ineinander zu investieren
- Überall können Sie deviceScreenshot (Tag: String) aufrufen, um einen Screenshot zu erstellen, der im aktuellen Schritt automatisch an den Bericht angehängt wird
- FailshotRule () - junit4 Rule macht kurz vor dem Fall einen Screenshot
Dies ist eine Übersicht über die Verwendung von Allure auf der Android-Plattform. Die Allure-Android-Lösung ist auf
GitHub verfügbar. Sie können sie detailliert anzeigen und an der Entwicklung teilnehmen.