Maskenorientiertes Testdesign zur GUI-Automatisierung

Die GUI-Automatisierung hat den Ruf, unverhältnismäßig teuer und gleichzeitig oftmals frustrierend zu sein. Dabei bietet eine konsequent an den Masken und Bedienelementen von GUI-Anwendungen ausgerichtete Strukturierung der Testautomatisierung einen erfolgversprechenden Weg aus den üblichen Problemen der GUI-Automatisierung.

Folgende Herausforderungen tauchen bei der GUI-Automatisierung mit Testscripten regelmäßig auf:

• Die Erstellung der Testscripte bindet teure Ressourcen. Neben den eigentlichen Programmierern werden während der Umsetzung noch zusätzlich Fachleute für die zu testende Anwendung zur Programmierung der Automatisierungen benötigt. Die optimale Kombination von Fachspezialist und Testautomatisierer ist nur in den seltensten Fällen zu finden.
• Es vergeht viel Zeit, bis eine brauchbare Menge an Abläufen erstellt ist. Da i.d.R. jeder Testfall manuell in ein Testscript umgesetzt wird, steigt die Menge der durchführbaren Tests nur sehr langsam an.
• Die Automatisierung ist „Unendlich“. Da es prinzipiell unendlich viele Testfälle geben kann, sind auch immer wieder neue Abläufe zu programmieren.
• Die Automatisierungen sind aufwendig in der Pflege. Werden Bedienelemente oder Masken geändert, müssen alle Abläufe angepasst werden, in denen die geänderten Objekte auftauchen. Die angepassten Abläufe sind in der Folge zumeist nicht abwärtskompatibel, sodass die Anzahl der Scripte zwar ansteigt, die Testabdeckung aber trotzdem unverändert bleibt.
• Die Erstellung und Prüfung der Automatisierungen erfolgt zumeist anhand der zu testenden Anwendung. Zum Nachweis der korrekten Funktion der Automatisierungen muss also eine bereits überprüfte Version der Anwendung vorliegen. Die Testscripte können also nur zur Durchführung von Regressionstests dienen.

Aufgrund dieser Probleme steht einer hohen Investition oft nur eine relativ kleine Ausbeute an fertigen Testscripten gegenüber, die darüber hinaus ständig überarbeitet werden müssen. Auch der Einsatz von „modernen“ Methoden hilft an dieser Stelle nicht immer weiter, da auch dort enge Einschränkungen für einen erfolgreichen Einsatz gelten.

• Data Driven Testing: Dieser Ansatz eignet sich in Reinform nur dann gut, wenn die Eingabeabläufe selbst statisch sind und sich die automatisierte GUI möglichst niemals ändert. Bei modernen Oberflächen ist das allerdings nur selten der Fall, da je nach Datenkonstellation andere Masken oder Elemente angezeigt werden. In der Regel reagieren solche Automatisierungen sehr empfindlich auf Änderungen in den Oberflächen oder Abläufen.

• Keyword Driven Testing: Dies geht schon eher in die richtige Richtung. Allerdings ist auch dieser Ansatz prozesszentriert. Es werden Schlüsselworte für wiederholte Aktionsmuster angelegt. Ändern sich Teile der GUI, muss die Programmierung jedes betroffenen Schlüsselwortes geändert werden. Da die Schlüsselworte in der Regel mehrere unterschiedliche Anwendungsspezifische Aktionen abbilden, sind sie zusätzlich auch noch von Änderungen in den Prozessabläufen betroffen. Dieser Ansatz lohnt sich nur für Anwendungen, die sowohl im äußeren Erscheinungsbild als auch in den internen Abläufen bereits sehr stabil sind.

Diesen beiden Ansätzen ist gemeinsam, dass bei der Automatisierung die Logik der zu automatisierenden Anwendung im Vordergrund steht. Der Testablauf als Ganzes wird in ein Programm umgewandelt, wenn auch, wie beim schlüsselwortgetriebenen Testen, in mehrere miteinander kombinierbare Teilprogramme.

Die Maske als Automatisierungskomponente (AK)

Ein möglicher Ausweg aus dieser Problematik ist eine konsequent maskenorientierte Methode. Bei diesem Ansatz steht bei der technischen Umsetzung nicht mehr die Funktion der zu testenden Anwendung, sondern ausschließlich das äußere Erscheinungsbild im Vordergrund. Dabei wird die Programmierung der Automatisierungskomponenten (AKs) und die Erstellung von Testfällen vollständig voneinander getrennt.

Jede AK bildet eine Maske der Anwendung ab. Es wird konsequent jedes sichtbare Element einer Maske von der AK erfasst und adressierbar gemacht. Die Funktionalität der darunterliegenden Software wird dabei grundsätzlich nicht beachtet. Dadurch wird die Programmlogik der zu automatisierenden Anwendung und die AKs vollständig voneinander getrennt. Die einzelnen AKs werden als eigenständige, unabhängige Programme betrachtet.

Die korrekte Funktion einer AK ist dann nachgewiesen, wenn alle Maskenelemente korrekt adressiert werden können. Der funktionale Zusammenhang zwischen den einzelnen Elementen einer Maske spielt für die Erstellung der AKs keine Rolle. Es ist daher ausreichend, nur das implementierte Frontend ohne Funktion vorliegen zu haben. Für die Erstellung ist lediglich die Darstellung sämtlicher Elemente einer Maske notwendig. Dadurch wird die Umsetzung der Automatisierung unabhängig von den dargestellten Testfällen überprüfbar.

Framework zur Erstellung von Testfällen

Für das Framework zur Erstellung von Testfällen aus den AKs werden nun zwei Ebenen benötigt: Makro- und Mikrosteuerung.

Makrosteuerung: In dieser Ebene werden die AKs in die durch den Testfall vorgegebene Reihenfolge gebracht. Um logische Abhängigkeiten, die nicht aus der Anwendung resultieren, zwischen den AKs zu vermeiden, besitzen alle AKs folgende zwei Eigenschaften:

1. Eine AK prüft nicht am Ende einer Ausführung ob sie korrekt durchgelaufen ist, sondern am Anfang ob die Voraussetzungen für ein Start überhaupt gegeben sind.
2. Alle AKs haben eine einheitliche Schnittstelle, sodass jede AK mit jeder anderen AK verbunden werden kann. Es werden vom Framework also keine technischen Vorgaben zur Kombination von AKs gemacht. Bei undurchführbaren Kombinationen wird die falsch positionierte AK ermitteln dass sie nicht starten kann und einen entsprechenden Fehler generieren.

Mikrosteuerung: Diese zweite Steuerungsebene wird eine für die Aktionen innerhalb einer Maske benötigt. Für jede AK gibt es eine Schnittstelle zu einer Datei welche die einzelnen Aktionen beschreibt, die von der AK zum Zeitpunkt der Ausführung auf der Maske durchgeführt werden sollen. Diese Aktionen werden wie beim schlüsselwortgetriebenen Design dargestellt.

Im Gegensatz zum traditionellen schlüsselwortgetriebenen Design sind die Schlüsselworte ausschließlich auf Maskenelementtypen bezogen. Dadurch wird erreicht, dass beispielsweise ein Element des Typs „Button“ mit jeder AK einer Anwendung dieselben Aktionen ausführen kann. Das von den Testfallerstellern zu verwendende „Wörterbuch“ kann so entsprechend übersichtlich gehalten und die Elementtypen leicht um zusätzliche Funktionen erweitert werden.

Welche Vorteile ergeben sich aus dem maskenorientierten Testdesign?

Die Programmierer der AKs benötigen keinerlei Fachwissen über die Anwendung:

• Lediglich alle Maskenelemente der jeweiligen Maske müssen erreichbar sein.
• Die Umsetzung kann verhältnismäßig „stumpf“ durchgeführt werden, da in der Regel keine logischen Bestandteile beachtet werden müssen.

Jede Maske wird nur ein einziges Mal implementiert:

• Wenn sich eine Änderung am Maskendesign einer Maske ergibt, betrifft es immer nur eine AK.
• Wird die AK entsprechend angepasst, sind alle Testfälle, die diese AK verwenden, wieder vollständig einsatzfähig.
• Beschränkt sich die Änderung auf eine Erweiterung der ursprünglichen Maske, so sollten die bisherigen Testfälle überhaupt nicht betroffen sein.

Die Testfälle selbst können:

• ohne Programmierkenntnisse allein von den Fachleuten für die Anwendung entworfen werden. Nur das Framework zur Zusammenstellung der Testfälle muss bedient werden können.
• direkt aus der Anforderungsbeschreibung eines Ablaufs abgeleitet werden, die eigentliche Anwendung muss zu diesem Zeitpunkt noch nicht vorliegen. So wird ein Testfirstansatz auch für Blackbox-Tests auf GUI Ebene realisierbar.

Die mit den Testfällen dargestellte Testabdeckung wird berechenbar:

• Da bei einem Testfall jede AK als Knoten in einem Ausführungsgraphen und die Befehle der Mikrosteuerung als Bedingungen der Knoten aufgefasst werden können, ergibt sich ein klassischer Kontrollflussgraph mit allen Berechnungsmöglichkeiten wie er aus Whitebox-Tests bekannt ist.

Die Implementierung der Automatisierung ist begrenzt. Sind alle Masken durch AKs erfasst, so ist die technische Umsetzung der Automatisierung vollständig und abgeschlossen. Die Menge der darstellbaren hingegen Testfälle ist unbegrenzt, da die AKs immer wieder anders zusammengesetzt und mit anderen Daten sowie unterschiedlichen Aktionen aufgerufen werden können.

Aus meiner Sicht bietet eine konsequent an den Masken und Bedienelementen von GUI-Anwendungen ausgerichtete Strukturierung der Testautomatisierung erfolgversprechende Lösungen zu den üblichen Problemen der GUI-Automatisierung an.