Eine kleine Dosis Selen

Aufbau eines Frameworks zur Testautomatisierung von Web-Frontends im E-Commerce-Bereich

Gregor Schrägle
©Shuttertstock/Sebastian Tomus

Oft sind die IT-Landschaften, die sich hinter den E-Commerce-Websites großer Anbieter verbergen, von hoher Komplexität geprägt. Sie bestehen neben dem Shop-Frontend aus zahlreichen Spezialanwendungen, wie z. B. CMS, PIM, Artikelsuche, Recommendation-Engine, Warenwirtschaft, Lagerhaltung, Zahlungsverkehr etc. Das Testen der einzelnen Komponenten sowie übergreifender Geschäftsprozesse stellt bei jedem Deployment eine große Herausforderung dar. Der folgende Beitrag beschreibt den Einsatz eines Frameworks zur Durchführung von automatisierten Frontend-Tests auf der Basis von Selenium.

Was sind die schlimmsten Albträume der Betriebsverantwortlichen von E-Commerce-Websites? Wohl die, in denen die kaufwilligen Kunden eines Unternehmens in dessen Internetshop nicht die Waren des Unternehmens – auf ansprechende Weise präsentiert – zu Gesicht bekommen, sondern lediglich eine einfache Wartungsseite mit dem vagen Hinweis auf ein technisches Problem und der Bitte, den Einkauf doch in Kürze noch einmal zu versuchen.

Das sind die Momente, in denen die verantwortlichen IT-Abteilungen aktiv werden und alle Mitarbeiter mit Hochdruck an der Beseitigung der Probleme arbeiten müssen. Das Ziel ist klar: Der Shop muss so schnell wie möglich wieder in Betrieb gebracht werden. Es dürfen keine Kunden und Bestellungen verloren gehen! Nirgendwo trifft die alte Geschäftsregel mehr zu als beim E-Commerce: Time is money!

Die verantwortlichen IT-Leiter unternehmen heute bereits im Vorfeld eine Reihe von Maßnahmen, um die Anzahl und Dauer der Downtimes ihrer E-Commerce-Plattformen so gering wie möglich zu halten – egal, ob es sich um vorgesehene Downtimes handelt, wie z. B. für regelmäßige Wartungsmaßnahmen, oder um ungeplante, die durch schwere Fehler verursacht werden. Die wohl wichtigste Präventivmaßnahme ist die Durchführung von umfassenden Tests der einzelnen Softwareanwendungen und deren Zusammenspiel innerhalb der IT-Landschaft. Je mehr verschiedene Anwendungen dabei im Spiel sind, desto größer werden die Komplexität, aussagekräftige Testszenarien zu definieren, und der Aufwand, diese Tests durchzuführen.

Im Folgenden werde ich den Aufbau eines Frameworks vorstellen, das es ermöglicht, die webbasierten Frontends der Anwendungen einer E-Commerce-Landschaft automatisiert zu testen. Dieses Framework wurde für einen großen internationalen Kunden im Bereich Handel realisiert und für seine E-Commerce-Anwendungslandschaft eingesetzt, die aus ca. 25 Applikationen besteht.

Die Ziele

Zunächst wurden in Abstimmung mit den verschiedenen Teams für Entwicklung, Integrationstest, Rollout und Betrieb die wichtigsten Ziele vereinbart, die durch den Einsatz des Testautomatisierungsframeworks erreicht werden sollten:

  • Die Reduzierung des Aufwands zur Testdefinition
  • Die Reduzierung des manuellen Aufwands bei der Testdurchführung
  • Die Verkürzung der benötigten Zeit zur Durchführung aller Tests
  • Nutzbarkeit sowohl bei erstmaligen Deployments der Landschaft als auch für Regressionstests

Daraus wurden für das Testframework einige Minimalanforderungen abgeleitet:

  • Eine einheitliche Definition und Durchführung der Tests
  • Eine möglichst große Testabdeckung (im Bezug auf die 25 Einzelanwendungen)
  • Die automatisierte Durchführbarkeit der Tests
  • Eine einfache Wiederholbarkeit von Tests
  • Bereitstellung einer automatischen Auswertung der Testergebnisse und integrierte Eskalationsmöglichkeiten

Nach der Zieldefinition wurden einige Werkzeuge zur Durchführung von GUI-Tests [1] verglichen und das Selenium-Framework [2] für die Umsetzung ausgewählt. Die entscheidenden Gründe für die Wahl von Selenium waren dessen Verfügbarkeit als Open-Source-Software, die breite Abdeckung von Web-Frontend-Technologien und seine aktive Benutzergemeinde.

Die Basiskomponenten des Testframeworks

Das Selenium-Framework besteht im Wesentlichen aus drei Komponenten (Kasten: „Die Selenium Suite“): Als erste kommt das Browser-Plug-in Selenium IDE zum Einsatz, mit dem Benutzerinteraktionen auf einer Website – so genannte „Klick-Strecken“ – aufgezeichnet und später wieder abgespielt werden können. Anschließend kann mit einem Generator aus den aufgezeichneten Klick-Strecken für verschiedene Programmiersprachen Quelltext generiert werden. Wir haben eine Konvertierung in Java vorgenommen. Diese Java-Quelltexte wurden dann als JUnit-Tests mit dem Selenium WebDriver ausgeführt. Eine Ergänzung stellt das Selenium Grid dar, mit dem das Abarbeiten von Testfällen parallelisiert werden kann, indem man sie zur Ausführung auf verschiedene Knoten im Grid verteilt.

Die Selenium Suite

Selenium ist ein Open-Source-Framework zur automatisierten Steuerung von Webbrowsern. Durch seine vielfältigen Funktionen eignet es sich sehr gut zur Umsetzung eines Testframeworks für Webanwendungen. Die bereitgestellten Funktionalitäten sind flexibel und bieten umfangreiche Möglichkeiten, Elemente innerhalb der grafischen Benutzeroberflächen von Webanwendungen zu lokalisieren sowie die erwarteten Ergebnisse für Testfälle mit dem echten Verhalten der Anwendung zu vergleichen. Ein wichtiges Feature von Selenium ist, dass einmal aufgezeichnete Testfälle mit einer Reihe von Webbrowsern abgespielt werden können: Firefox, Internet Explorer, Chrome etc.

Neben den Werkzeugen zum Aufzeichnen und Abspielen von Browserinteraktionen umfasst Selenium auch eine domänenspezifische Sprache, Selenese, die zur Spezifikation von Tests in verschiedenen Programmiersprachen benutzt werden kann, z. B. in Java, C#, Groovy, Perl, PHP, Python und Ruby.

Die wichtigsten Komponenten von Selenium

Die Selenium Suite besteht aus folgenden Hauptkomponenten:

Selenium IDE ist ein Firefox-Plug-in zum Aufzeichnen und Abspielen von Browserinteraktionen (Testfällen). Sie kann auch benutzt werden, um aus aufgezeichneten Testfällen Quellcode zu generieren, der mit Selenium WebDriver abgespielt werden kann.

Selenium WebDriver ist eine Komponente zur Steuerung von Webbrowsern über deren native Schnittstelle. Sie kann entweder lokal auf der eigenen Maschine oder auch remote genutzt werden.

Selenium Grid stellt eine Ergänzung zu Selenium WebDriver dar, um die Ausführung von Testfällen parallel auf mehrere Server verteilen zu können. Das ist besonders für umfangreiche Testsuiten interessant bzw. zum parallelen Testen mit verschiedenen Browsern.

Die Umsetzung des Testframeworks

Die Nutzung eines Testautomatisierungsframeworks beginnt immer mit dem erstmaligen Aufzeichnen von Testfällen. Dazu werden für jede zu testende Webanwendung mit der Selenium IDE einzelne Klick-Strecken aufgezeichnet, in der Regel eine Klick-Strecke pro Testfall.

Ein typischer Testfall „Einkauf“ für ein Shop-Frontend könnte so aussehen: Der Benutzer führt im Webshop eine Produktsuche durch, browst durch den Kategorie-Baum, wählt mehrere Produkte zum Vergleich aus, legt zwei Produkte in den Warenkorb und führt anschließend den Bestellprozess durch, inklusive der Eingabe synthetischer Zahlungsdaten.

Je nachdem, um welche Applikation es sich handelt, gibt es natürlich sehr unterschiedliche Testszenarien, die im Vorfeld funktional genau definiert und zusammen mit den zu erwarteten Ergebnissen spezifiziert werden müssen.

Die technische Basis für die Aufzeichnung von Benutzerinteraktionen mit dem Browser sind dabei immer zwei Dinge: Erstens die Identifizierung von Elementen des GUI bzw. die Lokalisierung der Elemente innerhalb der Elementhierarchie einer Seite. Und zweitens die Aktion, die der Benutzer mit dem Element ausführt, beispielsweise einen Klick, eine Auswahl, eine Texteingabe.

Für die Identifizierung bzw. Lokalisierung von Elementen auf einer Webseite benutzt Selenium die so genannten Element Locators. Dabei handelt es sich um Konfigurationseinstellungen in der Selenium IDE, die spezifizieren, auf welche Weise die Identifizierung bzw. Lokalisierung von GUI-Elementen durchgeführt werden soll. Im Wesentlichen stehen dazu folgende Locators zur Verfügung:

  • ID: Identifikation eines GUI-Elements anhand seiner ID
  • NAME: Identifikation anhand des Namens
  • DOM: Lokalisierung eines GUI-Elements innerhalb des HTML-Objektbaumes, z. B. dom=document.forms[‚myForm‘].myDropdown
  • XPATH: Lokalisierung eines Elements mithilfe eines XPath-Ausdrucks, z. B. xpath=//table[@id=’table1′]//tr[4]/td[2]
  • LINK: Spezifikation des Ankerelements eines Links durch den Linktext, z. B. link=“our specials“
  • CSS: Lokalisierung eines GUI-Elements durch CSS-Selektoren, z. B. css=a[href=“#id3″]

Darüber hinaus besteht die Möglichkeit, eigene Implementierungen für Element Locators zu erstellen. Je nachdem, welche technische Implementierung einer Website zugrunde liegt, sind die einen oder anderen Locators geeigneter. Die Festlegung der Locator-Präferenzen und ihrer Reihenfolge sollte auf jeden Fall frühzeitig erfolgen, bevor mit dem Aufzeichnen der einzelnen Klick-Strecken für die verschiedenen Testfälle begonnen wird. Sonst kann es vorkommen, dass die verwendeten Locators immer wieder einmal angepasst oder ausgetauscht werden müssen.

Werden keine Präferenzen angegeben, verwendet Selenium standardmäßig die drei Element Locators DOM, XPATH und ID.

Nach dem Aufzeichnen und Abspeichern einer Klick-Strecke kann diese über die Selenium IDE jederzeit wieder abgespielt werden. Dabei laufen dann die einzelnen Benutzerinteraktionen mit der Website wie von Geisterhand gesteuert in einem eigenen Browserfenster ab. Zusätzlich können Klick-Strecken aber auch als Quelltext für verschiedene Programmiersprachen exportiert werden. In unserem Fall wurde aus der Selenium IDE heraus pro Klick-Strecke ein JUnit-Testfall erzeugt. Für die Codegenerierung gibt es dabei eine Reihe von Konfigurationsparametern, von denen wir nur einige einfache benutzt haben, z. B. zur Festlegung von Namenskonventionen für die zu generierenden Java-Klassen und -Pakete. Für eine erste Strukturierung der ganzen Testfälle bietet sich an, die Klassennamen der JUnit-Tests aus den Namen der aufgezeichneten Klick-Strecken und die Paketnamen anhand der Namen der getesteten Webanwendungen erzeugen zu lassen. Darüber hinaus bestehen aber noch zusätzliche weitreichende Möglichkeiten zur Anpassung und Erweiterung der Codegenerierung.

Zur Ablaufsteuerung der JUnit-Testfälle wurde ein Ant-Skript [3] verwendet. Dieses Skript definierte dedizierte Ant Targets, die sich an den oben erwähnten Namenskonventionen orientierten und über die sowohl einzelne Testfälle, Gruppen von Testfällen, als auch alle Testfälle sequenziell ausgeführt werden konnten. Innerhalb der Targets wurde auf die Ant Tasks <JUnit> [4] und <JUnitReport> [5] zurückgegriffen. Diese spezifizieren einerseits die Ausführungsparameter der einzelnen JUnit Testfälle, andererseits die Struktur der Ergebnisdarstellung. Die JUnitReports wurden nach jedem Testlauf als HTML-Dateien abgespeichert und lieferten auf oberster Ebene eine Zusammenfassung der Ergebnisse (Anzahl ausgeführter Tests, erfolgreiche Testfälle, fehlgeschlagene Testfälle, Laufzeit der Tests etc.), auf der zweiten Ebene eine Zusammenfassung der Testfälle pro Webanwendung und schließlich auf unterster Ebene eine detaillierte Ansicht jedes einzelnen Testfalls inklusive detaillierter technischer Fehlermeldungen bei fehlgeschlagenen Testfällen.

Für die Ausführung der JUnit-Testfälle mit dem Ant-Skript wurde ein dedizierter Testserver bereitgestellt. Auf ihm wurden unterschiedliche Testläufe so eingeplant, dass bei jedem neuen Deployment der E-Commerce-Umgebung der komplette Testumfang ausgeführt wurde und während des normalen Betriebs zusätzliche Testläufe regelmäßig die Verfügbarkeit der einzelnen Anwendungen überprüften.

Zusammenfassung der Ergebnisse – Fazit

Die Selenium Suite stellt umfangreiche Möglichkeiten zur automatisierten Browsersteuerung zur Verfügung. Mithilfe der Selenium-Hauptkomponenten Selenium IDE, Selenium WebDriver und Selenium Grid lässt sich sehr gut ein Framework zur Testautomatisierung von Webanwendungen aufbauen. Sowohl das Erlernen der Selenium-Konzepte als auch die Handhabung der einzelnen Werkzeuge zum Aufzeichnen und Abspielen von Testfällen oder zur Codegenerierung fallen einem versierten Benutzer erfreulich leicht.

Neben der Basistechnologie zur Browsersteuerung gibt es allerdings noch ein paar wichtige Punkte, die für die vollständige und praxistaugliche Umsetzung eines Frameworks zur Testautomatisierung notwendig sind und von Selenium nicht mitgeliefert werden: Dazu zählen einerseits Vorgaben zur logischen Strukturierung der Testfälle während der Testentwicklung sowie Komponenten zum Scheduling, Reporting und zur Steuerung während der Testdurchführung. Doch das sind eher Kleinigkeiten, um die das Selenium-Framework unter Zuhilfenahme von JUnit und Ant schnell ergänzt werden kann.

Darüber hinaus fehlen aber noch zwei wesentliche Bestandteile, die nicht ohne Weiteres hinzugefügt werden können: Zum einen ist das eine Datenbank zum Parametrieren der ganzen Testautomatisierung, angefangen bei Umgebungsparametern bis hin zur Hinterlegung von fachlichen Daten für erwartete Ergebnisse von Testfällen. Zum anderen fehlt ein durchgängiger Mechanismus, der es auf einfache Weise erlaubt, fachliche Fehler zu definieren und bestimmten Ereignissen während des Ablaufs eines Testfalls zuzuordnen. Das wäre sehr wichtig, um während eines Testlaufs neben technischen Fehlern, welche die Browsersteuerung von Selenium wirft – z. B. ein angegebenes Element kann auf einer Website nicht gefunden werden –, auch fachliche Fehler erkennen zu können, etwa, ob eine angezeigte Bestellnummer sinnvoll ist.

Als Hauptaufwandstreiber für die Umsetzung des Testframeworks haben sich einerseits die technische Bereitstellung der oben beschriebenen Zusatzkomponenten herausgestellt und andererseits das erstmalige Anlegen der ganzen Testfälle. Dabei entfällt der übliche Aufwand auf die ursprüngliche fachliche Spezifikationen von Testfällen; zusätzlicher Aufwand aber entsteht für das technische Aufzeichnen der Tests mit der Selenium IDE. Aus organisatorischer Sicht hat es sich als sehr sinnvoll erwiesen, die Aufzeichnung der Testfälle mit der Selenium IDE jeweils von einem Anwendungsexperten (Rolle: „fachlicher Analyst“) zusammen mit einem IT-Spezialisten durchführen zu lassen, der Selenium und das Testframework genau kennt (Rolle: „technischer Experte“).

Ein wichtiger Aspekt kommt noch hinzu: Nach dem ersten Anlegen von Testfällen muss ein gewisser Aufwand für Wartungsarbeiten einkalkuliert werden. Die getesteten Webseiten können sich sehr oft inhaltlich, manchmal aber auch strukturell ändern. Das bedeutet, unter Umständen müssen die aufgezeichneten Testfälle den Änderungen angepasst werden. Hier wiederum kann sich eine am Anfang gut durchdachte Auswahl der Element Locators positiv auswirken.

Zusammenfassend lässt sich sagen, dass sich die kluge Umsetzung eines Frameworks zur Testautomatisierung auf jeden Fall lohnt, sowohl im Hinblick auf die Einsparung manueller Testaufwände als auch durch die deutliche Verkürzung der Ausführungszeiten für alle Tests. Gerade im E-Commerce-Bereich, wo oft eine große Anzahl von Anwendungen mit webbasierten Benutzeroberflächen innerhalb der IT-Landschaft existiert, wirken sich diese Faktoren sehr positiv aus. Und noch ein kleiner Tipp zum Schluss: Sowohl für das Aufzeichnen von Testfällen mit der Selenium IDE als auch bei der Fehlersuche erweisen sich Firebug [6] und XPath Checker [7] als sehr hilfreiche Werkzeuge!

Aufmacherbild: „Selenium element button“ von Shuttertstock / Urheberrecht: Sebastian Tomus

Geschrieben von
Gregor Schrägle
Gregor Schrägle
Gregor Schrägle ist freiberuflicher IT-Architekt und Berater für Enterprise-Integration. Er unterstützt Unternehmen verschiedenster Branchen bei der Technologieauswahl und der Umsetzung von IT-Transformationsprojekten. Seine Spezialgebiete umfassen Integrationsarchitekturen, SOA, EAI, Datenintegration, BPM und CEP. Mehr finden Sie auf www.schraegle-consulting.de.
Kommentare
  1. Mike2017-01-02 21:50:47

    Na ich hoffe, dass der Dienstleister beim Erstellen der Shops solche Tests ebenfalls mitbringt.
    Mittlerweile ist das echt nicht mehr schwer und kann leicht automatisiert werden.
    Jeder Shop-Betreiber kann das mittels Behat selbst bauen und kontinuierlich Prüfen lassen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.