von | | Best Practices , Testautomatisierungseinblicke
E2E-Testen

Einführung

Beim End-to-End-Testen (E2E) werden realistische Nutzungsszenarios in einer Anwendung durchgespielt, wobei so viele Funktionsbereiche und Teile des in der Anwendung verwendeten Technology-Stacks miteinbezogen werden sollen wie möglich. Im Gegensatz zu Unittests, die wesentlich eingeschränkter ablaufen, sind E2E-Tests breit angelegt und werden deshalb oft auch als „Broad-Stack-Tests“ oder „Full-Stack-Tests“ bezeichnet. E2E-Tests sind darauf ausgerichtet, die Workflows einer Anwendung aus der Endnutzerperspektive zu überprüfen, weswegen sie besonders bei Management und Kunden einen hohen Stellenwert genießen. Normalerweise werden E2E-Tests am Ende des Testzyklus durchgeführt, nach Unit-, Integrations- und Systemtests. Der hohe Wert von E2E-Tests steht im Kontrast zu ihrer hohen Komplexität, Fehleranfälligkeit und einem hohen Wartungsaufwand. Aufgrund dessen ist es üblich, weniger E2E-Tests als Unit- und Integrationstests zu implementieren, wie in der Testautomatisierungspyramide dargestellt. E2E-Tests werden gewöhnlich in einer möglichst realitätsnahen Testumgebung durchgeführt, inklusive Backend-Dienste und externer Schnittstellen wie Netzwerk-, Datenbank-, und Drittanbieterdienste. Das ist auch der Grund, warum E2E-Testen Probleme aufzeigen kann, die sonst nur in einer Live-Umgebung ersichtlich sein würden, wie zum Beispiel Wartezeiten durch Kommunikationsprobleme mit einem Zahlungsdienst. In der isolierten Umgebung von Integrationstests bleibt diese Art von Problemen verborgen.

Ein E2E-Beispiel

Nehmen wir an, Sie wollen einen Webshop testen, der auf einen Drittanbieter zur Verifizierung von Zahlungen angewiesen ist. In diesem Fall würde der E2E-Test der Anwendung z.B. folgende Vorgänge beinhalten:

  • Der Nutzer loggt sich ein, sucht nach einem Artikel, gibt ihn in den Warenkorb, wählt Zahlungs- und Versandart aus, schließt die Bestellung ab und loggt sich wieder aus.
  • Der Nutzer loggt sich ein, sucht nach einer bestehenden Bestellung, die bereits unterwegs ist, überprüft die Sendungsverfolgung, erhält eine detaillierte Auskunft über den Auslieferungsstatus der Bestellung und loggt sich wieder aus.
  • Der Nutzer loggt sich ein, sucht nach einer bestehenden Bestellung, die bereits unterwegs ist, beantragt eine Rücksendung, erhält ein Rücksendeetikett und loggt sich wieder aus.
  • Der Nutzer loggt sich ein, geht auf sein Benutzerkonto, fügt eine neue Zahlungsart hinzu, erhält eine Bestätigung über die Gültigkeit der Zahlungsart und loggt sich wieder aus.

Diese Tests greifen auf Drittanbieterdienste wie Verifizierung der Zahlungsart und Sendungsverfolgung zu und beziehen Informationen wie Kundendaten, Artikelbestände, Bestellungen etc. aus einer oder mehrerer Datenbanken.

Best Practices für E2E-Tests

Ein typischer E2E-Test kann komplex ausfallen, mit einer Vielzahl an Schritten, die manuell ausgeführt viel Zeit in Anspruch nehmen. Aufgrund dieser Komplexität können E2E Tests schwierig zu automatisieren und langsam in der Ausführung sein. Die folgenden Tipps können dazu beitragen, die Kosten für E2E-Tests zu verringern und trotzdem von ihren Vorteilen zu profitieren.

Denken Sie wie der Endnutzer

Gestalten Sie E2E-Tests aus der Perspektive des Endnutzers und konzentrieren Sie sich auf die Features der Anwendung statt ihrer Implementierung. Falls möglich, verwenden Sie User-Storys, Akzeptanztests oder BDD-Szenarios, um die Nutzerperspektive zu dokumentieren. 

Ausnahmen sollen Ausnahmen bleiben

Konzentrieren Sie sich auf die meistgenutzten Wege durch die Anwendung, die sogenannten „Happy Paths“ oder „Golden Paths“. Sie sollen die typischen Anwendungsszenarios abdecken, wie z.B. oben in unserem Beispiel beschrieben. Für sogenannte „Bad Paths“ oder „Sad Paths“, also für den Nutzer ungünstige Anwendungsszenarios (z.B Artikel nicht mehr verfügbar, Rücksendedatum überschritten), sollten Sie günstigere Unit- und Integrationstests nutzen.

Risikoanalyse durchführen

E2E-Tests sollten aufgrund Ihrer hohen Kosten optimalerweise nur für Risikofeatures eingesetzt werden. Um zu bestimmen, welchen Features das sind, reicht es meist, die Konsequenzen eines Featureausfalls zu betrachten und wie Endnutzer davon betroffen wären. Ein nützliches Werkzeug hierzu ist eine Risikomatrix. Mehr zum Thema Risikoanalyse finden Sie auch in der Ranorex Testing Wiki.

In der richtigen Reihenfolge testen

Wenn ein Unittest fehlschlägt, ist es relativ einfach, die Fehlerursache ausfindig zu machen. Bei komplexen Tests, die immer mehr Anwendungskomponenten betreffen, steigt auch das Potential für Fehler und die Fehlersuche wird umso anspruchsvoller. Führen Sie daher Ihre Unit- und Integrationstests zuerst durch, um Fehler noch relativ einfach beheben zu können. Beim E2E-Test sollten Sie dann zuerst Ihre essentiellen Smoke-Tests und dann Ihre Sanity-Tests und Testfälle für andere Risikobereiche durchführen.

Nicht die Testumgebung vernachlässigen

Gestalten Sie das Aufsetzen Ihrer Testumgebung so effizient wie möglich und beschränken Sie es auf das Wesentliche. Dokumentieren Sie die Anforderungen an die Testumgebung und geben Sie sie an Systemadministratoren und andere involvierte Personen weiter. Beschreiben Sie in der Dokumentation, wie Aktualisierungen des Betriebssystems, von Browsern und anderen Komponenten der Testumgebung gehandhabt werden, um sie der Produktivumgebung möglichst ähnlich zu gestalten. Eine Lösung hierfür kann die Nutzung eines Backup-Images der Produktumgebung zu Testzwecken sein.

Testlogik von UI-Elementdefinitionen trennen

Trennen Sie Ihre Testlogik von den Definitionen der UI-Elemente Ihrer Anwendung, um E2E-Tests stabiler zu machen. Verwenden Sie ein Repository oder einen Page-Object-Pattern zur Verwaltung von UI-Elementen, damit Ihre Testlogik nicht direkt mit der UI interagieren muss. Dadurch werden Tests robuster gegenüber Änderungen in der UI. Ranorex Studio verwendet diesem Prinzip entsprechend ein Repository zur Verwaltung von UI-Elementen. Bei Web-Tests mit Selenium kann auf einen Page-Object-Pattern zurückgegriffen werden.

UI-Elemente und Wartezeiten

Ein E2E-Test sollte niemals unnötig beim Warten auf eine Seite oder ein UI-Element fehlschlagen. Zu diesem Zweck kann in Ranorex Studio eine Aktion hinzugefügt werden, durch die der Test eine spezifische Zeitspanne abwartet, ob ein UI-Element sichtbar wird. Erscheint das Element nicht innerhalb der Zeitspanne, schlägt der Test fehl. Die Wartezeit sollte so gewählt sein, dass sie mindestens jener Zeitspanne entspricht, die das UI-Element üblicherweise zum Erscheinen benötigt. Sie sollte aber auch nicht zu lang sein. Überlange Wartezeiten in der Anwendung deuten auf ein Problem mit der Anwendung selbst, Schnittstellen oder der Umgebung hin und sind auch für Endnutzer lästig. Außerdem wirken sie sich natürlich auch ungünstig auf die Ausführungsdauer des E2E-Tests aus, und damit auf die Kosten. Als Grundprinzip sollten Sie eine Wartezeit angeben, die ein klein wenig länger ist als die Zeitspanne, die das Element üblicherweise zum Erscheinen benötigt.

Die richtigen Geräte

Bei Tests von Mobilanwendungen sollten Sie E2E-Tests hauptsächlich auf den beliebtesten Geräten mit den meistverwendeten Versionen von iOS und Android beschränken. Für andere Geräte/Versionen können Sie Emulatoren verwenden. Testen Sie aber sowohl im WiFi- als auch im Mobilnetzmodus (verschiedene Anbieter und Geschwindigkeiten von 3G bis LTE).

Setup- und Teardown-Prozesse optimieren

Verwenden Sie Setup- und Teardown-Prozesse, damit Ihre Testumgebung immer bereit für den nächsten Testlauf ist. Erstellen Sie Testdaten mithilfe von automatisierten Scripts und löschen Sie die Daten nach dem Test wieder, um die Testumgebung auf den Ursprungszustand zurückzusetzen.

Fazit

Beim E2E-Testen ist es wichtig, auch manuelles und exploratives Testen miteinzubeziehen, da nicht immer alle Aspekte automatisiert werden können, bspw. Usability und User-Experience. Auch Leistungs- und Lasttests sollten Teil Ihrer Testprozedur sein, um alle Bereiche abzudecken. Dieser Art von Test widmen wir uns im nächsten und letzten Artikel dieser Serie.

Steigen Sie direkt in die Testautomatisierung ein mit unserer kostenlosen 30-tägigen Testversion:
Testversion herunterladen