iOS-Geräte beanspruchen immer noch einen bedeutenden Teil des Mobilfunkmarktes und machen weltweit bis zu 22 Prozent des Umsatzes aus. Da viele treue Kunden immer wieder neue Apple-Produkte kaufen, gibt es auch eine große Nachfrage nach iOS-Anwendungen. In diesem Artikel befassen wir uns mit der Sicherstellung der Qualität von iOS-Apps durch die Verwendung von Best Practices mit den Tools Appium, Cucumber und Serenity.

Struktur

Das Page Object Model ist einer der besten Testansätze, die QA-Ingenieure für ein Testautomatisierungsprojekt anwenden können. Es ist ein Weg, den Code in einem Automatisierungsprojekt zu strukturieren, der die Codequalität und -lesbarkeit sowie die Testwartung verbessert und darüber hinaus ein großartiges Mittel zur Vermeidung von Chaos ist. Die Grundidee besteht darin, alle Verweise auf mobile Elemente und Methoden, die Operationen auf ihnen ausführen, in einer Klassendatei für jede Seite oder jeden Bildschirm der App (oder Webseite für nicht-native Webanwendungen) zu speichern.

Was sind die Vorteile dieses Ansatzes, werden Sie sich fragen? Erstens macht es die Automatisierung wirklich einfach. Im Grunde geht es darum, Elemente in unserer iOS-App über den Inspektor zu finden und dann Operationen mit ihnen durchzuführen. Ein weiterer Hauptvorteil ist die kohärente Struktur des Projekts, die es jedem ermöglicht, schnell durch das Projekt zu navigieren.

Lassen Sie uns ein Beispiel für eine App nehmen, die Rezepte enthält. Sie zeigt beim Start das Standard-Kochbuch mit den Grundrezepten an, was unsere erste Seite sein wird. Von dort aus kann der Benutzer zu jedem verfügbaren Rezept navigieren, wodurch eine zweite Seite markiert wird. Darüber hinaus bietet die App die Möglichkeit, in anderen Kochbüchern zu stöbern oder Premium-Kochbücher zu kaufen, was sie zur dritten Seite und damit zu einer Seitenobjektdatei macht.

Auch wir sollten entsprechende Schrittdefinitionsdateien erstellen. Dies ist nicht zwingend erforderlich, aber alle Schrittdefinitionen an einem Ort zu halten, verursacht unnötiges Chaos.

Während Sie Ihre Seiten und Schrittdefinitions-Klassendateien erstellen, ist es ratsam, Namen zu wählen, die sich auf die Seite (App-Bildschirm) beziehen, an deren Inhalt Sie arbeiten werden. Die Benennung dieser Dateien nach einer Funktion oder einem Szenario kann auf den ersten Blick richtig erscheinen, aber mit zunehmender Größe des Projekts werden Sie feststellen, dass die Struktur immer unübersichtlicher wird. Durch die Übernahme der Seitennamenskonvention wird sichergestellt, dass alle am Projekt Beteiligten sich sofort damit vertraut machen und in kürzester Zeit mit der Zusammenarbeit beginnen können. Eine solche Praxis trägt auch zur Wiederverwendbarkeit von Code bei – entweder Schrittdefinitionen oder Methoden/Funktionen.
Im Gegensatz zu den erwähnten Schritt- und Schrittdefinitionsdateien sollten die Cucumber-Feature-Dateien nach einem Feature benannt werden, das sie verifizieren. Clever, nicht wahr? Die Strukturierung in Verzeichnisse, die nach einem bestimmten Bereich der zu testenden Anwendung benannt sind, macht die Struktur aussagekräftiger.
Das Grundkonzept von Serenity ist es, eine „lebende Dokumentation“ zu sein. Daher hilft die Benennung von Testszenarien und Funktionsdateien dem Team und den Beteiligten, Berichte und das gesamte Projekt besser zu verstehen.

Ein weiterer Bestandteil, der die Vorteile des Seitenobjektmodells im Testautomatisierungsprojekt erweitert, ist PageFactory. Es ist ein Tool, das Ihnen hilft, den Codierungsaufwand zu reduzieren und MobileElements-Locators mithilfe der @FindBy-Notation einfach in den Code einzufügen. Von dort aus ist es viel einfacher, Elemente zu finden, mit denen Appium in Tests interagieren kann.

Assertion

Die Ausführung von Tests über Appium kann sehr ressourcenintensiv sein. Um es Ihrem MacOS-Rechner, der Tests auf Ihrem iOS-Gerät ausführt, leichter zu machen, stellen Sie sicher, dass Sie nicht ständig die Sichtbarkeit aller Objekte auf einer Seite überprüfen. Diese Praxis erhöht die Testausführungszeit erheblich, was in der Regel nicht wünschenswert ist.

Wenn Sie prüfen müssen, ob ein Element sichtbar, aktiviert, anklickbar oder irgendetwas dazwischen ist, versuchen Sie, die Lokalisierung mobiler Elemente mit Xpath zu vermeiden. Der Tipp des Appium-Inspektors hat einen guten Punkt! Sie sollten alles in Ihrer Macht stehende tun, um das Entwicklungsteam davon zu überzeugen, sich mehr Mühe zu geben und den Elementen in der App eindeutige IDs und Namen zuzuweisen. Dies wird nicht nur die Automatisierungstests einfacher und schneller machen, sondern auch Ihre Arbeit als Tester effektiver gestalten, was letztendlich zu einer Steigerung der Gesamtqualität des Produkts führt. Und genau dafür sind wir da. Ganz zu schweigen davon, dass die Wartung der Tests (z.B. das Umschalten auf andere Locators, wenn nötig) viel angenehmer wird.

Die Schritte verstehen

Ein weiterer Aspekt beim Einrichten eines solchen Projekts besteht darin, die Vorteile von Cucumber zu nutzen und die Sprache Gherkin zu verwenden.

Gherkin implementiert einen einfachen Ansatz mit der Notation Given, When, Then mit Hilfe der zusätzlichen And und But, die recht einfach zu verwenden sind. Sie können so ziemlich alles, was Sie wollen, in die Testschritte Ihrer Feature-Dateien schreiben. Letztendlich werden die aufgerufenen Methoden Aktionen ausführen.

Der Grund für die Verwendung des Behavior Driven Development-Ansatzes und von Cucumber selbst ist, dass die am Projekt beteiligten Nicht-Techniker verstehen können, was im Testbereich vor sich geht. Nicht nur das, auch das Schreiben von Testszenarien in der Given/When/Then-Methode kann zu Ihrem Vorteil sein. Solche vom Kunden oder Business-Analysten gelieferten High-Level-Testbeschreibungen werden Sie in kürzester Zeit zum Kodieren bringen, vorausgesetzt, sie sind richtig geschrieben. Hier einige hilfreiche Tipps:
Testszenarien, die in Gherkin geschrieben sind, sollten sich auf das Verhalten der Anwendung konzentrieren (daher Behavior Driven Development).
Hier ist ein Beispiel dafür, wie man NICHT in Gherkin Test-Szenarien schreiben sollte, um das Thema Kochbuch-Anwendung zu vertiefen:

Das obige Beispiel illustriert zwei schlechte Praktiken, die wir vermeiden sollten: Es konzentriert sich auf die Implementierung statt auf das Verhalten und es verwendet fest kodierte Werte, anstatt Testschritte so zu schreiben, dass eine Wiederverwendbarkeit durch Ändern von Werten innerhalb eines Schrittes möglich ist.

Ein richtiges Szenario für den Kauf eines Kochbuchs in unserer Beispiel-App sollte daher wie folgt aussehen:

Ein anderes Beispiel:

Wenn man diesen Ansatz wählt, bedeutet dies weniger Arbeit bei der Erstellung und Kodierung von Testschritten, wenn sich die Implementierung einer bestimmten Funktion ändert.

Abgesehen von der Hauptnotation Given/When/Then unterstützt Cucumber die Verwendung von Konjunktionsschritten. Die Verwendung von Und- und Aber-Schritt-Notationen macht die Testschritte allgemeiner und wiederverwendbar, was dazu führt, dass weniger Code geschrieben wird und die Ordnung im Projekt erhalten bleibt. Hier ein einfaches Beispiel:

Wenn Sie also den obigen ‚Given‘-Schritt codieren, um unser Rezeptelement durch Suchen seines Namens zu finden, können Sie ihn viele Male wiederverwenden, indem Sie einfach den Stringwert im Schritt ändern (vorausgesetzt, Sie codieren die Schrittdefinition später richtig). Darüber hinaus kann der Schritt „And“ Teil eines jeden Testszenarios sein, das eine solche Aktion beinhaltet.

Alles zusammenfassen

Nach der Einrichtung eines Projekts unter Verwendung der oben beschriebenen Praktiken sind die am meisten sichtbaren Teile der Verwendung von Serenity die generierten Testberichte. Nach der Übernahme des @RunWith(CucumberWithSerenity.class)-Tags in Ihre TestRunner-Klassendatei führt die Ausführung der Testsuite dazu, dass Serenity einen aggregierten Bericht über die Testergebnisse generiert, der bei der Bewertung der Qualität der zu testenden Anwendung und der Präsentation des Produktstatus für die Stakeholder oder das Entwicklungsteam nützlich sein kann.

Appium, Cucumber, Serenity – Zusammenfassung

Wie Sie sehen, lässt sich das Konzept der Best Practices beim Automatisierungstest in drei Worten zusammenfassen: Wiederverwendbarkeit, Lesbarkeit und Leistung. Wiederverwendbarkeit bedeutet weniger Kodierung und damit weniger Zeitaufwand für die Fertigstellung der Aufgabe. Die Lesbarkeit verbessert das Verständnis, was entscheidend ist, um sicherzustellen, dass das Produkt das tut, was es tun soll. Und schließlich spart die Leistung Ausführungszeit und verbessert die Stabilität. Alle drei tragen nicht nur zur Qualität des Testautomatisierungsprojekts bei, sondern spielen auch eine wichtige Rolle bei der Verbesserung der Gesamtqualität der gelieferten Anwendung.