Capture and Replay stellt eine effiziente Möglichkeit dar, automatisiert ablaufende Regressionstests zu erstellen. Die so generierten Tests gelten jedoch als sehr fragil und erfordern meist einen hohen Pflegeaufwand. Ein großes Problem hierbei ist die Wiedererkennung von Komponenten der grafischen Benutzungsoberflache. Häufig wird auf manuell erstellte Testskripte und aufwendige Patterns wie Page Objects zurückgegriffen, um den Einsatz von Assets zu reduzieren. Skripte erfordern allerdings Programmierkenntnisse, was das Testen durch Domänenexperten erschwert. So entstehen auch hier Mehrkosten, u. a. durch den erhöhten Kommunikationsbedarf.
Mit dem Ziel, den Capture-and-Replay-Ansatz auf mögliche Stärken und Schwächen zu untersuchen, werden vier kommerzielle sowie quelloffene Tools für die Java-Oberflächentechnologie Swing evaluiert. Zu diesem Zweck wird ein entsprechendes Testszenario konzipiert, das typische Defizite solcher Tools adressiert und der Simulation alltäglicher Entwicklungsprozesse dient. Diese Arbeit zeigt, dass die Ergebnisse zum Teil stark variieren und welche Vor- sowie Nachteile Capture and Replay gegenüber manuell erstellten Testskripten bietet.
Die Ergebnisse dieser Arbeit haben gezeigt, dass die Effektivität von Capture-and-Replay-Tools zum Teil stark variiert. Im Gegensatz zu einschlägigen Publikationen wie [NB13] wurde nicht nur die Kompatibilität gegenüber GUI-Komponenten bzw. den entsprechenden Events überprüft, sondern auch das Verhalten der Tools in ihrer eigentlich Disziplin evaluiert – dem Regressionstesten. Mit Pounder, Marathon, QF-Test sowie Ranorex wurden vier Tools ausgewählt, die unterschiedliche Hintergründe besitzen: Pounder als quelloffenes und freies Tool, das zwar nicht mehr aktiv gepflegt wird, dennoch eine gute Reputation besitzt. Marathon hingegen ist nicht nur Open Source und kostenfrei verfügbar, sondern wird auch kontinuierlich durch festabgestellte Entwickler gewartet. Mit QF-Test wurde ein proprietäres Tool evaluiert, welches einen hohen Reifegrad besitzt und zahlreiche zusätzliche Features anbietet. Ranorex besitzt ein ähnlich ausgeprägtes Profil, ist jedoch im Rahmen der Evaluation das einzige Tool, das nicht in Java implementiert ist.
Diese Unterschiede sind allerdings auch bei der Bewertung der Ergebnisse zu berücksichtigen. Zwar geht QF-Test als das Tool hervor, welches die meisten Tests erfolgreich abschließen konnte, ist jedoch gegenüber dem Zweiplatzierten Marathon sowohl geschlossen als auch kostenpflichtig. Zumal mit MarathonITE eine erweiterte, vielversprechende Variante von Marathon zur Verfügung steht. Als Kompromiss muss hierbei auf Open Source und kostenlose Verfügbarkeit verzichtet werden. Pounder und Ranorex, auf Platz drei bzw. vier, scheinen gänzlich ungeeignet: Pounder erfordert aufgrund seiner Einschränkungen zu starke Anpassungen zum Start und zur Verwaltung komplexer Anwendungen, Ranorex verlangsamt die Ausführungsgeschwindigkeit enorm und schneidet am schlechtesten bei den eigentlichen Tests ab. So scheint es von Vorteil, wenn SUT und Tool die identische Plattform verwenden, wie im vorliegenden Fall Java bzw. die Java Virtual Machine (JVM).
Somit liegen mit QF-Test und Marathon zwei Tools vor, die eine effizient Möglichkeit darstellen, automatisiert ablaufende Regressionstests zu generieren. Domänenexperten ohne Programmierkenntnisse können dabei eigenhändig fachliche Tests erstellen, ohne entsprechende schriftliche Spezifikationen aufzusetzen, die mühsam von Entwicklern umgesetzt werden müssen. Beide Tools bieten dennoch die Anbindung von Skriptsprachen, wodurch Capture and Replay auch in frühen Stadien der Entwicklung effizient von Programmierern eingesetzt werden kann. Darüber hinaus scheinen Anpassungen, um die zu testende Applikation für Capture-and-Replay-Tools zu optimieren (beispielsweise die Vergabe eindeutiger Namen) weniger aufwendig, wie etwa spezielle Patterns (z. B. Page Objects [Fow13]), die häufig beim Testen mit manuell erstellten Testskripten zum Einsatz kommen.
Diese These erfordert jedoch weitere empirische Studien, um die Effektivität von Capture and Replay unmittelbar mit alternativen Lösungsansätzen vergleichen zu können. Die vorliegenden Ergebnisse können bei der Auswahl eines geeigneten Tools in Betracht gezogen werden. Auch bietet das konzipierte Testszenario einen guten Ausgangspunkt, weitere Vergleiche durchzuführen. An dieser Stelle sind allerdings Verbesserungen notwendig: Die Evaluation hat gezeigt, dass diverse Tests zu stark voneinander abhängig sind. Weitere, unabhängigere Tests ermöglichen eine einfachere Analyse der eigentlichen Fehlerursache. Darüber hinaus können das Testszenario bzw. SwingSet3 dahingehend erweitert werden, typische Eigenschaften von Softwareprojekten zu übernehmen, um die Alltagstauglichkeit eines Tools oder einer alternativen Teststrategie genauer evaluieren zu können. Hier sind beispielsweise die Anbindung externer Datenquellen oder die Integration in Build-Prozesse denkbar.
Den kompletten Auszug des Evaluationsberichts zu QF-Test können Sie hier (PDF) lesen.
Projektarbeit: Evaluation Swing-kompatibler Capture-and-Replay-Tools - März 2016, Daniel Kraus, Hochschule Karlsruhe – Technik und Wirtschaft, Deutschland.
