Testsuite für die grafische Benutzeroberfläche
Die Editoroberfläche soll mittels eines Capture-Replay-Tools einem Regressionstest unterworfen werden. Zentraler Punkt des Oberflächentests ist die Prüfung, ob das Programm korrekt auf Nutzereingaben reagiert und ob der Editor korrekt in Eclipse integriert ist. Zu diesem Zweck wird im Folgenden zuerst ein Überblick über die verfügbaren Werkzeuge für den Java-Oberflächentest gegeben. Zwei dieser Tools werden ausgewählt und näher evaluiert. Abschließend erfolgt eine Beschreibung der mit dem ausgewählten Werkzeug erstellten Testsuite
Fazit und Auswahl
Insgesamt wirkt das kommerzielle Werkzeug deutlich komfortabler und robuster. Nicht zu vernachlässigen ist auch der ausgesprochen schnelle und kompetente Support per E-Mail. Das ist etwas, was man bei einem Tool aus der Kategorie Open Source Software ganz einfach nicht erwarten kann und in der Regel auch nicht findet. Die Ausnahme bilden hier vielleicht die Foren von großen Open-Source-Produkten wie OpenOffice oder Eclipse, doch SWTBot kann mit diesen bei der Größe der Community einfach nicht mithalten. In Tabelle 3.2 werden die relevanten Unterschiede zwischen den beiden Tools abschließend zusammengefasst.
Im Ergebnis der Evaluation und unter Beachtung der Schwerpunkte, die die Aufgabenstellung setzt, wurde in Abstimmung mit ubigrate entschieden, dass aufgrund der gefundenen Unterschiede zwischen den Tools – besonders im Hinblick auf die Linearität der Testerstellung – im Rahmen der Arbeit QF-Test als Werkzeug für den Oberflächentest verwendet werden soll.
Direkter Vergleich zwischen SWTBot und QF-Test
| Kriterium | SWTBot | QF-Test |
|---|---|---|
| Capture-Replay | Keine Capture-Komponente | Ja |
| Notwendige API-Kenntnisse | Umfangreich (SWTBot.*, Hamcrest) | Begrenzt (Resolver) |
| Injektionsmethode | Eigenes Target Platform Plug-In | Instrumentiertes JDK, modifiziertes SWT |
| Aufwand Testerstellung | Sehr hoch (Zeile-für-Zeile mit Wechsel zwischen Testrealisierung und SUT | Niedrig (Capture, schlimmstenfalls mit nicht wiedererkennbaren Komponenten) |
| Schwächen in der Testerstellung | Zeilenweises Scripten, nichtlinearer Workflow | Weniger Kontrolle über die SUT-Interna |
| Ausführungsgeschwindigkeit | Schnell (In-situ auf SUT-Ebene) | Schnell (Direkte Instrumentierung des JDK) |
| Stärke in der Testdurchführung | Introspektion | Deploy-Neutralität |
| Setup/Teardown | Nur auf SUT-Ebene oder via ant etc. | Prozeduren, SUT kann auch zwischen Testläufen neu gestartet werden |
| Anpassbarkeit | eigene Hamcrest-Matcher verwendbar | Eigene Resolver verwendbar |
| GEF-Unterstützung | Schlecht [Mer09] | Ausgereift, per Import aktivierbar |
| SWTBot für Eclipse/RCP (SWT) | QF-Test für Eclipse/RCP (SWT) |
Tabelle 3.2: Direkter Vergleich zwischen SWTBot und QF-Test
Den kompletten Auszug des Evaluationsberichts zu QF-Test können Sie hier (PDF) lesen.
Diplomarbeit: Entwurf und Realisierung eines Protokollmodelleditors, Kapitel 3: Testsuite für die grafische Benutzeroberfläche - Vergleich von QF-Test und SWTBot – Januar 2010, Christoph Schmidt, TU Dresden, Deutschland.
