Im folgenden Kapitel sollen die Möglichkeiten verschiedenen Testautomatisierungswerkzeuge in Bezug auf die Netzwerkintegrationssoftware ServiceOn Integrator untersucht werden.
Im Vordergrund der Tests steht die grafische Oberfläche des ServiceOn Integrators (SOI), das sogenannte Portal, welches als Java WebStartanwendung sowohl unter Windows als auch unter Linux/Unix ausführbar ist. Der größte Teil der verfügbaren Funktionalitäten, die SOI bietet, ist über diese Oberfläche verfügbar. Der Schwerpunkt liegt daher auf dem Vergleich der beiden GUI-Automatisierungswerkzeuge QF-Test und Marathon.
Die Abbildung zeigt das SOI Portal ohne eine geöffnete Komponente. Der Ressourcenbaum links dient dazu, die einzelnen Komponenten (z.B. die Fehlerverwaltung) zu öffnen.
Nachfolgend soll untersucht werden, ob die GUI-Automatisierungswerkzeuge Marathon und QF-Test zur Automatisierung von Interaktionen mit dem SOI-Portal geeignet sind, und welches gegebenenfalls in der Situation des Projekts den größeren Mehrwert bietet.
Da Marathon keine speziellen Funktionen zum Starten von Webstartanwendungen mitbringt, müssen alle jar-Archive lokal auf dem Testrechner gespeichert werden, bevor das Portal mit Marathon gestartet werden kann. Dies kann z.B. durch manuelles Starten des SOP-Loaders (der SOI-spezifischen Java Webstart-Implementierung) geschehen.
Anschließend müssen alle heruntergeladenen jar-Dateien im Klassenpfad des Marathontestprojektes verfügbar gemacht werden, was sich auch mit Hilfe eines Skriptes automatisieren lässt. Schwieriger wird es, dann sämtliche jnlp Dateien (Java Network Launching Protocol) definierten Java-Properties zu setzen; allerdings ist auch dies aufgrund der XML-Struktur der jnlp-Dateien mit Hilfe eines Parsers möglich.
Eine weitere Schwierigkeit, die sich im Laufe der Tests der Software herausgestellt hat, ist die Art mit der Marathon die Komponentenerkennung handhabt, da gerade die Titel der einzelnen Programmfenster dynamisch erzeugt werden und es mitunter auch vorkommt, dass Texte innerhalb eines Fensters mehrfach verwendet werden.
Die Handhabung des Marathon GUI Testing Tools ist sehr stark entwicklerorientiert, insbesondere durch das komplett in Jython gehaltene Aufnahmeformat. Dieses erfordert ausführliche Kenntnisse der Skriptsprache, insbesondere wenn die Aufnahmen modularisiert und wiederverwendet werden sollen.
Das Starten des SOI-Portals kann bei QF-Test direkt mit Hilfe des SOPLoaders erfolgen, vorausgesetzt das im SOPLoader verwendete jdk ist instrumentiert.
Auch die Komponentenerkennung in QF-Test ist stark abhängig von der verwendeten Sprachversion, da im Quelltext des Projekts in der Regel keine Namen für die Komponenten vergeben werden. Durch die Möglichkeiten, manuell in die Komponentenerkennung einzugreifen, konnten in ersten Tests bereits gute Ergebnisse erzielt werden. Allerdings wurde auch sehr schnell absehbar, dass sich durch die Pflege der Komponentenerkennung ein großer Entwicklungsaufwand in die Tests verlagert, der dort klassisch direkt in die Entwicklung des Systems einfließen sollte.
Große Vorteile bringt die Möglichkeit, auf die Komponenten komplexer Strukturelemente wie beispielsweise Baumstrukturen oder Tabellen je nach Situation entweder durch einen absoluten Pfad oder die relative Position zuzugreifen. Dadurch ist es möglich, sowohl gezielt ein Element auszuwählen als auch das Vorhandensein eines Elements mit bestimmten Eigenschaften, allerdings ohne genau bekannten Namen zu überprüfen.
Die Handhabung der QF-Testsuite unterscheidet sich durch die Knotenstruktur radikal von anderen Java-GUI-Automatisierungswerkzeugen. Dieser Aufbau ermöglicht einen einfachen Überblick über die aufgenommenen oder manuell konfigurierten Abläufe. Trotz dieser einfachen Struktur erfordern manche Testszenarien einen Eingriff in Form von Skripten.
Ein Beispiel hierfür ist die Überprüfung von Tabelleninhalten, die nur aus Bildern bestehen. QF-Test bietet hierfür die Möglichkeit, das Abbild einer einzelnen Zelle zu testen, doch dieser Test ist dann von der Breite der Zelle abhängig. Das Listing liest mit Hilfe des von QF-Test zur Verfügung gestellten Runcontextes rc die Breite einer Zelle aus, um diese dann in einer nachgestellten „Drag-And-Dropsequenz“ auf eine definierte Breite zu setzen.
Zusätzlich benötigen auch viele Tests mehr als nur eine einfache Textabfrage und den Vergleich mit einem regulären Ausdruck oder einem Textabschnitt. In diesem Fall muss ebenso auf die Funktionalitäten eines Jythonskriptes zurückgegriffen werden.
Eine weitere für die Automatisierung von SOI interessante Möglichkeit bietet der Knoten zum Ausführen eines Shellkommandos. Dadurch kann auch auf einem nicht lokal verfügbaren Kernsystem Funktionen aufgerufen werden.
Die beiden Werkzeuge verfolgen einen sehr unterschiedlichen Ansatz bei der Verwaltung der Tests. Marathon richtet sich mit seiner reinen Quelltextform an Entwickler und Tester mit Entwicklungserfahrung. QF-Test dagegen versucht, Tester nur dann mit Quelltext in Berührung kommen zu lassen, wenn dies zwingend notwendig ist. Durchdiese Entkopplung sollte es auch möglich sein, dass Tester mit wenig Programmiererfahrung Tests aufnehmen und modularisieren können. Für die trotzdem anfallenden Skiptanteile würde es dann genügen einzelne Tester mit Jythonkenntnissen zu haben.
Die Komponentenerkennung wird in der aktuellen Situation von keinem der beiden Tools ausreichend standardmäßig gelöst. QF-Test liefert mit der Möglichkeit der eigenen Nameresolver eine Möglichkeit zu einem schnellen Workaround, der punktuell in der Lage ist gute Ergebnisse zu liefern. Langfristig wird man auch hier aber nicht an einer Änderung der Anwendung vorbeikommen. Ich denke, es ist akzeptable, während der Entwicklung Aufwand zu betreiben, um die Anwendung einfacher testen zu können, also das Design der Anwendung im Hinblick auf eine bessere Testbarkeit zu erweitern.
Insgesamt lässt sich zusammenfassen, dass sich die QF-Testuite den erfolgversprechenderen Ansatz zum Testen des ServiceOn Integrators bietet.
Diplomarbeit: Testautomatisierung von Netzmanagementsystemen (Auszug zu QF-Test) - März 2008, Michael Werner, Hochschule Esslingen.
