Maskenorientiertes Testdesign zur GUI-Automatisierung

Inhaltsübersicht:

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.