JAXenter

GUI gut, alles gut? Sicher kann und muss man auch im Rahmen eines GUI-Tests überprüfen, ob beispielsweise Pflichtfelder bei Fehleingaben rot markiert werden. Das Spannende beim GUI-Testen liegt aber eher darin, für den Endanwender wichtige Bedienungen (z. B. verschiedene mögliche Workflows) in einem Black-Box-Test abzubilden. Sinn und Zweck eines funktionalen GUI-Tests ist daher, die Qualität der entwickelnden Software mit vertretbaren Kosten zu verfolgen. Ein erfolgreicher Test deutet darauf hin, dass die Anwendung sich den Anforderungen entsprechend verhält. Abweichungen (fehlgeschlagene Tests) zeigen in der Regel Fehler in der Software auf. Nach der Behebung eines Fehlers sollte der Test erneut durchgeführt werden. Dieser Regressionstest bringt zwei Vorteile: Erstens wird sichergestellt, dass der Fehler tatsächlich behoben wurde, und zweitens, dass die Beseitigung keine anderen Fehler verursacht hat. Beim Testen grafischer Oberflächen sind Regressionstests also besonders wichtig. Das Schlüsselwort dabei ist "Wartbarkeit", denn die Software erfährt in der Regel bereits während der Entwicklung erste Änderungen. Je weniger Aufwand benötigt wird, um die Regressionstests ablauffähig zu halten, desto höher ist im Endeffekt der Return of Investment (ROI) und desto besser ist die Qualität der Software. Ein zweites Ziel des automatischen GUI-Testens ist, die Zeit zwischen Entwicklung und Test zu verringern. Wird ein Fehler erst Wochen oder Monate nach dem "Einchecken" eines Codestücks gefunden, entstehen deutlich mehr Kosten durch erhöhten Aufwand, den Fehler zu beheben, als wenn dieser früh und damit zeitnah gefunden worden wäre.

Die Anforderungen an einen Test beinhalten also auf der einen Seite das zeitnahe Schreiben und Ausführen von Tests. Tests sollten möglichst während der Implementierung geschrieben und direkt ausgeführt werden können, sobald die zu testende Anwendung (AUT) verfügbar ist. Auf der anderen Seite ist gutes Design und eine wohlüberlegte Struktur unabdingbar für die Wartbarkeit der Tests. Keyword-driven Testing bietet einen möglichen Weg, diesen Anforderungen gerecht zu werden.

Stichwort "Keywords"

Keywords kann man sich als Testbausteine (Module) vorstellen, die mit einem für den Tester griffigen und verständlichen Schlüsselwort versehen werden. GUI-Tests bestehen aus vielen, sich wiederholenden Sequenzen von Aktionen (Text eingeben/prüfen, Schaltfläche klicken, Reiter auswählen usw.). Für solche Aktionen können vorgefertigte Module erstellt werden. Ein Tester muss nur noch die notwendigen Keywords zusammenstellen und gegebenenfalls mit Daten versehen, um seine Testabläufe zu erstellen. Aus einfachen Keywords können wiederum komplexere Keywords zusammengesetzt und wiederverwendet werden (z. B. "Öffne Suchdialog aus dem Menü", "Fülle Suchmaske aus", "Schließe Suchdialog mit O.K.", Abb. 1). Damit bleibt die Arbeit erspart, eine Sequenz von Aktionen mehr als einmal definieren zu müssen.

Keyword-driven Tests haben also den Vorteil, dass sie meist gut strukturiert sind. Wiederverwendbare Module sorgen für ein leichtes Pflegen der Tests, denn Veränderungen an einer zentralen Stelle halten den gesamten Test aktuell. Das Erstellen der Keywords wird häufig von Automation Experts durchgeführt. Keywords werden anhand einer Programmiersprache für eine Anwendung definiert und anschließend an das Testteam zur Verwendung weitergegeben. Eine zeitnahe Testerstellung ist dann möglich, wenn die Implementierung der Keywords rechtzeitig zur Verfügung gestellt wird. Im Folgenden beschreibt dieser Artikel den Ansatz des kommerziellen Tools GUIdancer zur Durchführung von Keyword-driven Testing.

GUIdancer

GUIdancer [1] ist ein Werkzeug zum automatischen Testen von Java-Oberflächen. Das Tool soll es ermöglichen, Tests frühzeitig und ohne Programmierkenntnisse durchzuführen und so den Testprozess synchron mit der Entwicklung zu halten. In der ersten Version wurden nur Swing-Oberflächen unterstützt. Die Erweiterung der Testmöglichkeiten auf SWT/RCP-Oberflächen und HTML war ein wichtiger Meilenstein für das auf Eclipse basierende Tool: Ab Dezember 2007 (Version 2.0) konnte sich GUIdancer endlich selbst testen. Seit Sommer 2008 ist Version 2.2 verfügbar.

Die Testerstellung mit GUIdancer basiert auf zwei elementaren Prinzipien. Erstens kann man aus den Anforderungen, und damit vor der Verfügbarkeit der AUT, Tests erstellen. Somit kann der automatisierte Test quasi zeitgleich mit der Entwicklung aufgebaut werden. Das zweite Prinzip ist die Wiederverwendung von Testfällen, die darauf abzielt, den Wartungsaufwand möglichst gering zu halten. Zu diesem Zweck setzt GUIdancer Keywords ein. Im Unterschied zu anderen Keyword-driven-Ansätzen erfolgt die Test- und Keyword-Erstellung allerdings ohne Programmierung – der Aufwand, Code zu schreiben und zu pflegen, entfällt.

Der Keyword-Ansatz erfordert es, sich schon am Anfang Gedanken über eine gute Struktur und ein gutes Test-design zu machen. Analog zu den Prinzipien vom Softwaredesign gehören solche Gedanken früher oder später ohnehin zu jedem Testprozess. Stellt man erst im Nachhinein fest, dass ein Test eine hohe Modularität benötigt, bietet GUIdancer dem Tester eine Refactor-Funktion.

Erste Schritte

Wie genau die Erstellung von Keywords und Testläufen funktioniert, kann jeder mit einer Demolizenz herausfinden. Nach dem Herunterladen und Installieren der Software muss zunächst eine Demolizenz im GUIdancer Shop angefordert werden. Die dafür notwendige ServerID erhält man im Lizenzadministrator, der automatisch nach der Installation aufgerufen wird. Die Demolizenz wird dann im Lizenzadministrator aktiviert und GUIdancer kann gestartet werden. Für Eclipse-Benutzer sieht die Oberfläche vertraut aus: Perspektiven, Editoren und Views, einschließlich Properties View und Problems View sind vorhanden (Abb. 2). Preferences werden im Workspace gespeichert. Ein großer Unterschied zu Eclipse besteht darin, dass Projekte in einer Datenbank (entweder in der mitgelieferten HSQL-Datenbank oder einer separaten Oracle-Datenbank) gespeichert werden. Durch die Verwendung einer Datenbank können mehrere Benutzer gleichzeitig an einem Projekt arbeiten.

Um den Einstieg in das Tool zu erleichtern, zeigen Cheat Sheets (schrittweise Anleitungen) interaktiv, wie man einen ersten Test zum Laufen bringt. Folgende Schritte werden erklärt:

1. Das Anlegen eines neuen Projekts (Namen und Sprachen definieren).
2. Die Konfiguration einer AUT (sofern diese schon bekannt bzw. vorhanden ist). In einer AUT-Konfiguration wird festgelegt, wo und wie die AUT zu starten ist – wahlweise über ein JAR oder ein Executable (.exe). Für RCP-Anwendungen gibt es weitere Details bei der Konfiguration zu beachten (Kasten: "RCP-GUI-Tests: Was muss man wissen?").
3. Das Erstellen und Wiederverwenden von Testfällen (Keywords).
4. Das Anlegen von Test-Suiten.
5. Die Durchführung des Object Mappings (spätestens hier muss die AUT vorliegen).
6. Die Ausführung des Tests.

Bei der täglichen Arbeit mit GUIdancer hat man es am häufigsten mit dem Design und der Erstellung von Testfällen zu tun. Diese Arbeit wird in den nächsten Abschnitten näher erläutert.