© DrHitch/Shutterstock.com
Automatisiertes Testen

1 Automatisiertes Testen: ein Erfahrungsbericht


Insbesondere im agilen Umfeld mit kurzen Releasezyklen oder Continuous Delivery ist ein automatisierter Test fast unabdingbar. Hier ist es ohne immensen Testaufwand unmöglich, für jedes Release einen kompletten manuellen Regressionstest zu realisieren. JUnit-Tests haben für die Komponententests bereits vielfach Einzug gehalten. Geplante automatisierte Oberflächen- und Behaviour-Tests sind dagegen eher die Ausnahme.

Das strategische automatisierte Testen fristet in der Softwareentwicklung vielfach noch ein Schattendasein. Dabei ist es für wiederholbare Smoke- und Regressionstests sehr sinnvoll. Außerdem eignen sich nicht alle Tests und Prüfungen für menschliche Wahrnehmung und menschliches Verhalten, also für die manuelle Ausführung. Ungeeignet sind z. B. Prüfungen, bei denen Texte verglichen werden müssen, insbesondere wenn diese nicht in der Muttersprache sind oder darüber hinaus noch über ein anderes Alphabet verfügen. Auch wenn innerhalb eines großen Menüs ein Punkt fehlt oder Überschriften zwar vorhanden sind, aber den falschen Text haben, sind dies Punkte, die einem menschlichen Betrachter vermutlich nicht auffallen – wenn er nicht ausgerechnet danach sucht. Bei Anbietern automatisierter Testtools kommt das automatisierte Testen gerne wie eine Lichtgestalt daher. Entsprechend hochgeschraubte Erwartungen bauen sich auf.

Unsere Anwendung läuft aktuell auf verschiedenen Plattformen (Multiplattform, Android/iOS, Desktop/Mobile) in zehn Übersetzungen (Multi Language) und auf vier unterschiedlichen Domänen (Multi Domain, COM Host, türkischer Host, brasilianischer Host, russischer Host). Anvisierte Wunschvorstellung war, für jeden Test bei dessen Aufruf festzulegen, auf welchen Plattform-Browser-Kombinationen (1 – x), für welche Sprachen (Angabe der zu prüfenden Sprachen, 1 – y) und für welche Domänen (1 – z) dieser laufen soll. In der vollen Ausprägung muss jeder Test x*y*z-mal laufen.

Wie alles begann

Folgende Ausgangssituation liegt vor: Für die vielen Workflows im Backend gibt es Unit-Tests. Improvements werden mit Features abgesichert, sodass sie leicht abgeschaltet werden können. Die Überprüfung der Anforderungen des Kunden bezüglich Aussehen und Verhalten der Anwendung wird manuell durchgeführt. Hierfür werden vom Kunden in den Implementierungs­tickets zusammen mit dem Entwickler Anforderungen und Abnahmekriterien definiert. Diese lassen sich von den Testern mit einem eigenen Schema in einen Testplan überführen, der manuell ausgeführt wird. Dieses Schema gibt Richtlinien für den manuellen Test vor, die neben explorativen Anteilen abgedeckt werden müssen. Beurteilt wird dabei neben der Spezifikation der Test für verschiedene Äquivalenzklassen, die Usability, das Design der Oberfläche und die Integration in das Gesamtsystem. Es gibt zurzeit keine automatisierten Tests, keine Last- und Performancetests und keine Penetrationstests.

image

Abbildung 1.1: Wie ein Test ablaufen kann

Abbildung 1.1 zeigt den Testablauf. Die Komponenten P1 bis Pn haben eigene Unit-Tests, JUnit-Test 1 bis JUnit-Test n, die deren Korrektheit prüfen. Bei Testfehlschlag geht es zurück in die Implementierung, bei Erfolg ins Testsystem. Dort werden Tests von der QA durchgeführt. Bei Testfehlschlag oder Fehlerfund geht es zurück zur Implementierung, bei Erfolg ins Produktivsystem. Hier werden erneut Tests von der QA und den POs gemacht. Bei Fehlschlägen im Produktivsystem werden Bugtickets eröffnet, Features wieder abgeschaltet und Rollbacks durchgeführt.

Als Mindestanforderung für die Automatisierung ergab sich: Auf der technischen Seite müssen die Tests parametrisierbar sein, in das CI-Tool Bamboo integriert werden, sie sollen mit dem Ticketmanagement von Jira zusammenarbeiten und später mit einem Test­management­werkzeug verwaltet werden. Aufwändig ist in unserem Fall die Bereitstellung von repräsentativen Testdaten in einem eigenen Testsystem. Zum Teil ist dies nur schwer möglich – wenn überhaupt –, da mit Daten und Schnittstellen von Drittanbietern getestet werden muss. Für die manuellen Tests existiert eine eigene Testumgebung, die der Einfachheit halber auch für die automatisierten Tests genutzt werden soll. Manuelle und automatisierte Tests wurden zeitlich getrennt, sodass sie sich gegenseitig nicht beeinflussen konnten.

Vorgehen und Toolsuche

Bei der Suche nach dem richtigen Automatisierungs­framework gingen wir nach dem Pyramid Approach vor [1]. Nach Zusammenstellung der Anforderungen an das Tool/Framework wurde die Menge potenzieller Kandidaten zusammengestellt. Sie wurden bewertet und der Prozess so lange iteriert, bis nur noch ein Kandidat übrig war, mit dem der erste Versuch gewagt werden sollte. Wir kamen zu folgendem Ergebnis:

  • Testframework Geb
  • Organisation der Testfälle mit TestNG
  • Verwendung des PageObject-Patterns
  • Tests für Englisch als Basissprache, Deutsch als zweite Sprache; eine Möglichkeit, weitere Sprachen hinzuzufügen, sollte der Entwurf sofort vorsehen
  • Test zunächst nur auf der Hauptdomäne, wobei die Möglichkeit zur Erweiterung direkt gegeben sein sollte
  • Test auf der Webseite über Desktopbrowser sowie auf der mobilen Seite über einen entsprechenden Device-Cloud-Anbieter
  • Automatisierte Ausführung der Tests mit Bamboo-Anbindung

Geb ist ein Framework für die Webautomation (Abb. 1.2). Kurz gesagt, handelt es sich um einen Wrapper um Selenium, der die Umsetzung einer Automatisierung einfach und schnell macht. Geb bietet außerdem einen jQuery-ähnlichen Zugriff auf Webelemente und die Robustheit des vorimplementierten PageObject-Patterns. Eine ausführliche Dokumentation [2] rundet das Paket ab und macht es für einen ersten Einstieg attraktiv.

image

Abbildung 1.2: Integration der automatisierten Tests mit Geb in die Applikations­landschaft

Als erstes Testobjekt wählten wir die Registrierung eines neuen Kunden, ein relativ eigenständiger Bereich, der jedoch genügend Raum für diverse Ausprägungen, Vorbedingungen und Möglichkeiten zur Fehleingabe bietet.

Gebs Konzepte

Konzeptionell verfolgt Geb den Ansatz, lieber Programmier­paradigmen und Sprachkonstrukte statt Beschränkungen in der Testumgebung zu verwenden, um damit Tests zu erstellen. Damit bietet es den Entwicklern die Freiheit einer Programmiersprache. Explizit wird zu Beginn des Manuals erwähnt, dass es sich um ein Entwicklertool handelt [2].

Geb implementiert das PageObject-Pattern [3], dessen zentrales Konzept es ist, dass es im gesamten Code je...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang