Success Story der Testautomatisierung bei einem Marktführer der Fashion Shops

Artikel von Peter Lehmann

Für jede Aufgabe gibt es ein geeignetes Werkzeug. So auch für die Automatisierung von Funktionstests bei Shop-Systemen. Dieses Beispiel zeigt, wie Testautomatisierung mit den richtigen Tools erfolgreich für ein eCommerce-System mit Fashion Shops verschiedener Ausprägungen eingesetzt werden kann.

Die Aufgabe

Die Aufgabe besteht darin, verschiedene Fashion Shops zu testen, die auf einer komplexen SaaS-eCommerce-Plattform aufbauen. Die Aufgabe gewinnt an Komplexität, da die Shops unterschiedliche Länderausprägungen mit jeweils verschiedenen fachlichen Anforderungen besitzen. Die Entwicklung dieser Shops erfolgt agil, damit schnell auf Marktveränderungen und daraus resultierenden Anpassungen am Shop reagiert werden kann. Für die Qualitätssicherung der gesamten Lösung bedeutet das eine hohe Zahl an Regressionstestfällen, die immer wiederkehrend in kurzen Abständen durchgeführt werden müssen. Eine automatisierte Lösung ist hierbei unabdingbar.

Die Abbildung 1 (SaaS-Plattform mit Fashion Shops) zeigt eine Grobskizze der Umgebung mit den Eigenschaften der Shop-Variationen.

Ziel ist es, diese Fashion Shops und ihre Ausprägungen mit automatisierten funktionalen Tests auszustatten, um eine hohe Abdeckung zu erreichen. Die wichtigsten Bereiche für eine Automatisierung sind Webseiten und Prozesse mit hoher Business-Relevanz. Darunter fällt primär der Bestellprozess, der gleichzeitig auch den komplexesten und umfangreichsten Teil der funktionalen Tests durch die große Anzahl an Kombinationsmöglichkeiten von Zahlungsarten, Versandarten, Benutzertypen, Gutscheinen usw. darstellt. Weitere shopspezifische Testbereiche sind unter anderem Produktsuche, Kategorienavigation, Produktansichten mit ihren Produktfiltern, Warenkorb, Benutzerkonto-Bereich, die Kontakt- sowie Newsletter-Seiten und natürlich die Login- bzw. Registrierungsseiten. Eine sehr wichtige Funktionalität von Shop-Systemen im Allgemeinen ist das Webanalyse-Tracking. Durch dieses Tracking werden Daten von Benutzerinteraktionen im Shop gesammelt, um das Käuferverhalten zu analysieren und darauf basierend den Shop zu optimieren.

Technische Anforderungen an den Test

Das in diesem Beispiel vorgestellte Fashion-Shop-System ist ein B2C-Onlineshop-System. Damit müssen in erster Linie die verwendeten Webtechnologien bedient werden. Die Webseiten mit HTML, JavaScript und Ajax müssen durch das eingesetzte Automatisierungstool gut automatisierbar sein. Eine Multi-BrowserUnterstützung bei der Testdurchführung ist erforderlich, da die Fashion Shops in verschiedenen Browsern funktionsgetestet werden müssen. Dies muss von dem Automatisierungswerkzeug ebenfalls unterstützt werden. Eine weitere Herausforderung ist die Automatisierung der Schnittstellen. Beispielsweise müssen über eine WebDav-Schnittstelle der eCommerce-Plattform verschiedene Stammdaten wie Kundendaten, Gutscheine und Promotions eingespielt werden, um diese später in den Tests verwenden zu können. Damit auch die Tests für das Webanalyse-Tracking automatisiert werden können, wird eine integrierte Proxy-Lösung benötigt, die die Requests an den Tracking-Dienstleister mitschneidet und auswertet. Damit sind die technischen Anforderungen, die das Shop-System selbst an die Automatisierungslösung stellt, im Groben definiert. Es gibt allerdings noch weitere organisatorische Anforderungen, die im Folgenden beschrieben werden.

Organisatorische Anforderungen an den Test

Eine wichtige Rolle für große Testprojekte spielt die Ausführungssteuerung der automatisierten Regressionstests. Bei einer rein sequenziellen Ausführung von mehreren hundert Tests kommt es sehr schnell zu hohen Durchlaufzeiten. Das spielt bei kleinen Regressionstest-Suiten, die ohne zeitliche Probleme über Nacht laufen können, meist keine große Rolle. Wichtig aber wird die Ausführungszeit bei gezielt kleinen Testsuiten wie Smoketests oder Annahmetests, die die grundlegende Funktion der Testumgebung prüfen und sehr zeitig auf testbehindernde Fehler hinweisen sollen. Oder bei Testsuiten, von denen die Freigabe der zu testenden Software abhängt. In diesen Fällen müssen die Ergebnisse innerhalb von ein bis zwei Stunden vorliegen. Dazu ist eine optimale, an das „System under Test“ angepasste Teststeuerung eine bedeutende Anforderung an die Automatisierungslösung. Ziel ist es hier, durch verschiedene Testumfänge und durch Parallelisierung ein schnelles Feedback geben zu können.

Die Automatisierungslösung muss weiterhin fähig sein, durch manuelle, zeitplanbasierte oder automatische Build Trigger eine Testdurchführung zu starten und nach Beendigung der Tests die Ergebnisse an einer zentralen Stelle abzulegen. Für diesen Zweck bietet sich ein Continuous Integration (CI Tool) an. Optimalerweise bietet die erstellte Lösung eine einfache Integration in das genutzte CI Tool, das heißt, sie nutzt ein entsprechendes Build Tool. Diese Anforderungen erweitern sich in diesem Beispiel dahingehend, dass die Testergebnisse nicht allein als gut auswertbarer Testreport zur Fehlerauswertung zur Verfügung stehen sollen, sondern zusätzlich in das Testmanagement-Tool HP Quality Center geschrieben werden müssen, um die Analyse der Testhistorie und eine Report- und Dokumentenerstellung durch das Testmanagement zu ermöglichen.

Tool-Evaluierung

Basierend auf den Anforderungen lassen sich einige Werkzeuge finden, mit denen eine solche Aufgabe bewältigt werden könnte. Viele dieser Werkzeuge sind proprietäre Software, die nicht kostengünstig ist oder nicht vollumfänglich das bietet, was bei der Umsetzung dieser Aufgabe an Funktionalität von einem Testframework gefordert wird. Einige Werkzeuge zur GUI-Automatisierung arbeiten zum Beispiel mit Bildvergleichsverfahren, um die Elemente auf einer Webseite zu erkennen. Dazu wird oft ein Record-Playback-Mechanismus für die Automatisierung von GUI-Testfällen angeboten. Dieses Vorgehen schafft zwar eine leichte Bedienbarkeit und verlangt keine Programmierkenntnisse, ist aber nur dann effizient einsetzbar, wenn sich das Testobjekt nicht verändert. Denn ändert sich eine markante Stelle im Test-Workflow, ist meist ein komplett neues Recording nötig. Die Wartung und Pflege solcher Testskripte kann sehr aufwendig sein. Für entwicklungsbegleitende Tests, bei denen sich regelmäßig Änderungen an der Weboberfläche ergeben, ist dieses Verfahren ungeeignet.

Effektiver ist es hier, ein Java-basiertes Framework einzusetzen. Für Java gibt es zahlreiche Treiberbibliotheken und eine große Community. So lassen sich recht schnell gute Lösungen für verschiedenste Automatisierungsaufgaben finden. Wiederkehrende Aufgaben in Testprojekten wie Web-GUI-Automatisierung von Standard-Webanwendungen oder die Bedienung immer gleicher Schnittstellentypen legen nahe, ein Testframework zu benutzen, welches geeignete APIs für genau diese oft verwendeten Bibliotheken bereithält.

Unsere Lösung

Wir haben uns daher vor einigen Jahren dazu entschlossen, ein eigenes Projekt mit einem Java-Testframework für Webtests zu entwickeln. Wir haben dieses Projekt „Xeta“ genannt. „Xeta“ ist ein Akronym und steht für „eXtendable Environment for Test Automation“. Die Basis für Tests an Weboberflächen sollte das Open Source Web Automation Tool Selenium darstellen. Selenium bot schon zu dieser Zeit eine hohe Zahl an Features und eine gute Erweiterbarkeit. In das Xeta-Framework wurde von Beginn an eine Schnittstelle zum Testmanagement-Werkzeug HP Quality Center integriert. Einerseits kann damit bei Bedarf die Steuerung der auszuführenden Tests in das Testmanagement verlagert werden. Andererseits – und das ist die Hauptaufgabe dieser Schnittstelle – können die Ergebnisse der Testläufe an das HP Quality Center übertragen werden. Die Testdokumentation findet damit (zusätzlich) im HP Quality Center statt. Weiterhin wurde zur Erleichterung der Auswertung der Testergebnisse ein Reporting integriert, welches die Ergebnisse konsolidiert und nach der Testdurchführung als einen webbasierten Testreport zur Verfügung stellt.

Da Java als Programmiersprache gewählt wurde und die Integrationsfähigkeit in einen CI-Prozess eine allgemeine Anforderung an Testautomatisierungsprojekte war und ist, haben wir uns für das Build-Tool Maven sowohl für das Xeta-Framework selbst als auch für Projekte, die auf Basis von Xeta erstellt werden, entschieden. Maven bietet viele weitere Vorteile, wie z. B. einen Software-Lifecycle und Dependency Management.

Xeta wurde in den letzten Jahren stark weiterentwickelt. Die Basis für Webtests bildet weiterhin Selenium, welches mit Selenium 2/WebDriver sogar einen objektorientierten Ansatz bietet. Zusätzlich verwenden wir den Selenium-Server in Grid-Konfiguration. Damit können wir unterschiedliche Betriebssysteme und Browser in einem Serververbund bereitstellen (siehe Abbildung 2: Selenium Grid).

Die Erweiterungen des Xeta-Frameworks betreffen einige Verbesserungen in der Testauswertung: Liefert ein Test einen Fehlerstatus, wird automatisch ein Screenshot des Webseiteninhalts zum Fehlerzeitpunkt erzeugt und dieser im Testreport dem entsprechenden Testfall zugeordnet. Zusätzlich erstellt Xeta automatisch ein Video für jeden Ablauf eines Web-GUI-Testfalls, das ebenfalls im Report verlinkt wird. Die Reports sind noch detaillierter geworden, beinhalten Statistiken zu dem abgeschlossenen Testlauf, Stacktraces im Fehlerfall, sowie Log-Ausgaben (durch ein Logging-Framework), die der Testentwickler zur besseren Auswertbarkeit implementiert hat. Außerdem enthält jeder Report eine Darstellung der zeitlichen Abarbeitung der einzelnen Testfälle. So kann man dem Testreport, vor allem bei Parallelität, einen Kontroll- bzw. Nachweis-Charakter geben.

Es wurden neue Konnektoren implementiert, die einfache APIs für oft verwendete Schnittstellen bieten: Datenbanken, Dateisysteme und E-Mails. Neben JUnit wird jetzt hauptsächlich TestNG eingesetzt, welches bessere Möglichkeiten der Strukturierung bietet und die Parallelisierung der Tests ins Spiel bringt.

Wie oben beschrieben ist die Parallelisierung der Tests eine zentrale Anforderung. Durch TestNG lassen sich auf einfache Weise Suiten für parallele Testausführungen konfigurieren. Xeta wurde auf die Unterstützung solcher parallelen Abläufe optimiert und bietet jetzt unter anderem ein Session Handling für Selenium- und WebDriver-Sessions. Der Zugriff auf diese Sessions ist sehr einfach gestaltet worden, und ihr Konfigurationsaufwand wurde minimiert. Eine strukturierte Vorgehensweise für die Entwicklung automatisierter Tests von Weboberflächen wird mit der Unterstützung des Page Object Patterns erreicht.

Die Abbildung 3 (Xeta-Systembild) zeigt ein grobes Bild des Xeta-Systems. Zusammen mit den externen Komponenten Selenium Grid und TeamCity, einem Continuous Integration Tool, lassen sich jetzt Tests mit unterschiedlichsten Konfigurationen und Zielplattformen ausführen, steuern und auswerten.

Das aktuelle Xeta-Framework findet nun Anwendung bei unseren Fashion Shops. Welche Xeta-Features werden genutzt und welche Funktionen des Fashion Shops sind damit abgedeckt? Die Hauptkomponente der Fashion Shops ist natürlich die Web-GUI. Xeta ist für die Testautomatisierungsaufgaben dieser Oberflächen bestens vorbereitet. Die Manager- und Utility-Klassen bieten die Möglichkeit, neue Tests mit geringem Konfigurationsaufwand zu automatisieren.

Durch die Verwendung des Page Object Pattern – wobei jede Webseite (Page) eine eigene Klasse im Testtreiber erhält, die zur Laufzeit als Objekt instanziiert wird (Object) – gibt es eine eindeutige Trennung zwischen den „Technical Activities“ (Pages) und den „Workflows“. Ein Workflow beschreibt den logischen Ablauf eines Testfalls und nutzt dafür die relevanten „Technical Activities“. Der Testcode ist damit strukturiert, sehr gut lesbar und bleibt auch bei Erweiterung wartbar.

Zusätzlich zu der Webkomponente werden noch zwei weitere wichtige Schnittstellen durch unsere Tests abgedeckt: Das Webanalyse-Tracking, welches vor allem für Seiten des Bestellprozesses enorm wichtig ist, wird über ein integriertes Proxy-Modul des XetaFrameworks mitgeschnitten und ausgewertet. Ferner werden die von dem Fashion-Shop-System versendeten E-Mails, z. B. bei NewsletterAnmeldung oder Kontaktanfragen, Xeta-Mail-Modul geprüft.

Mit dem als Testrunner eingesetzten TestNG wurden Gruppen und Test-Scopes definiert, mit denen die Ausführung zum einen als kompletter Regressionstest (als Nightly Test) und zum anderen als Smoketest umgesetzt ist. Beide Testsuiten sind durch Parallelität laufzeitoptimiert.
Durch Angabe eines Maven-Profils im Build Task des TeamCity Buildservers werden der Test-Scope und die Fashion-Shop-Ausprägung ausgewählt. Im TeamCity gibt es je einen Build Task pro Fashion-Shop-Ausprägung und jeweils einen „Scheduled Trigger“ für eine Durchführung des kompletten Regressionstests als Nightly Test. Zudem können alle Tests manuell gestartet werden. Nach einer Ausführung wird der Testreport als Artefakt abgelegt, welcher dann mit einem Klick erreichbar ist. Mit der Beendigung der Tests sind die Testergebnisse auch in das HP Quality Center übertragen worden und können hier entsprechend ausgewertet werden.

Der schematische Ablauf anhand des generischen Testprozesses ist in Abbildung 4 (Testprozess mit dem Xeta-Framework) dargestellt. Die Darstellung zeigt die Erstellung der Testfallspezifikationen im HP Quality Center und deren Umsetzung in automatisierten Testcode inklusive Treiberentwicklung mithilfe des Xeta-Frameworks. Die Testdurchführung erfolgt gesteuert durch den TeamCity Buildserver auf der gewählten Zielplattform im Selenium Grid Cluster. Die Ausgaben dieser Durchführung mit dem Xeta-Framework sind zum einen der Testreport mit den Testergebnissen und weiteren nützlichen Informationen wie Screenshots und Screenvideos, zum anderen die in das HP Quality Center synchronisierten Testergebnisse.

Fazit

Alles in allem ist eine Lösung entstanden, die alle businessrelevanten Bereiche der Fashion Shops abdeckt und die Qualität des Produkts regelmäßig überprüft. Die Tests starten automatisch zeitplan- oder eventgesteuert oder können von Entwicklern, aber auch von Nichttechnikern gestartet werden. Durch die Parallelisierung besitzt die gestartete Testsuite eine wesentlich kürzere Laufzeit gegenüber der sequenziellen Abarbeitung der gleichen Tests, was den Entwicklern und dem Testmanager wesentlich schneller Testergebnisse liefert.

Der Buildserver TeamCity benachrichtigt alle Projektbeteiligten über die Beendigung des Testlaufs per E-Mail oder einen WindowsDienst in der Systemleiste. Zu diesem Zeitpunkt sind die Testergebnisse in das HP Quality Center übertragen worden. Über einen Klick auf der TeamCity-Web-GUI lässt sich der von Xeta erzeugte detaillierte Testreport zur Fehleranalyse öffnen. Außerdem können gleichzeitig mehrere Konfigurationen für unterschiedliche Betriebssysteme und Browserversionen getestet werden, was eine hoch priorisierte Anforderung unseres Kunden ist.

Mit dieser Lösung wurde eine hohe Testabdeckung der funktionalen Tests erreicht und zugleich die Feedback-Zeit kurz gehalten. Des Weiteren sind Wartbarkeit und Erweiterbarkeit des Testcodes sehr hoch, womit eine hohe Reaktionsgeschwindigkeit auf Softwareänderungen gewährleistet wird.
Unsere Leistungen sind bei funktionalen automatisierten Tests noch nicht zu Ende. Das akkreditierte Test and Integration Center der T-Systems Multimedia Solutions GmbH führt mit ca. 200 zertifizierten Mitarbeitern für ihre Kunden außerdem automatisierte Performance-, Security- und Schnittstellentests durch.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Kategorien

Recent Posts