Die Kunst der Testautomatisierung über das GUI„Automatisieren Sie so wenige Testfälle wie möglich über die grafische Benutzeroberfläche!“ Im ersten Abschnitt dieses Artikelswerden die Gründe für diese – für viele vielleicht ungewöhnliche – Empfehlung aufgezeigt und im Anschluss daran wird eineStrategie für die Testautomatisierung vorgestellt. Wenn schon das GUI für automatisierte Testfälle verwendet wird, dann solltedies angemessen durchgeführt werden. In diesem Artikel werden verschiedene Testautomatisierungsarchitekturen präsentiertund dargestellt, welche dieser Architekturen diejenige mit dem meisten Potenzial für wartbare und robuste Testfälle ist.

stufen wäre das durch Mocks einfacherumzusetzen.

Strategie für die

Testautomatisierung

Lisa Crispin und Janet Gregory stellen inihrem vielfach verkauften Buch „AgileTesting – A Practical Guide for Testers inAgile Teams“ (vgl. [Cri08]) eine Test -pyramide vor. Daran angelehnt ist dieTestpyramide in Abbildung 1.

■ Komponententests (engl. Unit Tests –Tests von Klassen und Methoden) bil-den die breite Basis aller Tests. Imple -mentiert der Entwickler die Tests wäh-rend oder im besten Fall vor dem Code(testgetriebene Entwicklung), entstehtautomatisch testbarer Code. DieseVorgehensweise verringert den Auf -wand für die Testautomatisierung be -trächtlich. Ein weiterer Vorteil ist dierasche und häufige Rückkopplung zumEntwickler mit Informationen übermögliche Fehler.

■ Integrationstests mit Diensten (z. B.Webservices) und Programmierschnitt -stellen (API) bilden die zweite Schichtin der Testpyramide. Sie sind überwie-gend leicht automatisierbar, da es meistkeinen Medienbruch zwischen geteste-ter Applikation und Testautomati -

sind aber auch selbst entwickelte odervon Drittanbietern erworbene Steuer -elemente im Einsatz. Will man nicht aufunrobuste Workarounds ausweichen,muss man die Steuerelemente durchAnpassung des Quellcodes testbarmachen. Drittanbieter stellen jedochhäufig den Quellcode nicht zur Ver -fügung. Auch die Synchronisation zwi-schen GUI und automatisierten Test -fällen stellt ein Problem dar, dennmanchmal dauert es etwas länger, biseine Tabelle vollständig mit Datengefüllt ist oder das Testwerkzeug zumgewünschten Steuerelement vordringenkann.

(3) Aufwand für robuste TestfälleEin unerwarteter, für die Testdurch -führung aber unwesentlicher Dialog(z. B. ein Updatehinweis des Antiviren -programms) hat schon so manchenTestautomatisierer zur Verzweiflunggebracht. Noch problematischer ist esoft, für jeden Testfall wieder einen defi-nierten Anfangszustand herzustellen.Auch nach einem Fehler muss für denfolgenden Testfall dieser Zustand gar-antiert werden. GUI-Tests sind über-wiegend Systemtests. Folglich ist esmeist nicht so leicht, sich von Fremd -systemen, Sensoren oder Datenbankenzu entkoppeln. In niedrigeren Test -

Herausforderungen

Automatisierte Tests können verschiedeneSchnittstellen verwenden, um mit dem zutestenden System zu interagieren. Die sehroft favorisierte, aber meist auch schwierig-ste Schnittstelle bei System- und Abnah -metests ist das GUI. Die damit verbunde-nen Herausforderungen können in diefolgenden drei Gruppen unterteilt werden:

(1) Informationsverzögerungen beiÄnderungen am zu testenden System Testwerkzeuge verwenden Technikenwie Reflection, Window Messages oderBilderkennung, um mit dem GUI zuinteragieren. Folglich kann das Test -werkzeug bzw. der Compiler Änderun-gen im GUI nicht erkennen. Problemetreten erst während der Test -durchführung auf. Ein weiterer Aspektdabei ist, dass die GUI-Testauto -matisierung oft zeitlich und organisato-risch weit entfernt von der Entwicklungstattfindet. Um diesen Problempunktzu reduzieren, ist ein gut funktionieren-des Change Management erforderlich.Auch moderne Prozessansätze wie dieagile Entwicklung versuchen, dieseDistanz zu mindern.

(2) Technische HerausforderungenTestwerkzeuge funktionieren meist gutmit Standardsteuerelementen. Vielfach

der au tor

Johannes Hochrainer

(johannes.hochrainer@software-quality-lab.com)ist seit 2006 bei Software Quality Lab als Unternehmensberater undTrainer beschäftigt. In jährlich gut 30 Projekten beschäftigt er sichmit Prozessanalysen, Vorgehensmodellen, Testmanagement undTestautomatisierung.

1 www.objektspektrum.de

advertorial

sierung gibt. Die betrachteten System -teile lassen sich zumeist auch leichtervon der Außenwelt isolieren.

■ Das Ganze ist mehr als die Summe sei-ner Teile. Dieser Lehrsatz desAristoteles muss auch bei der Test -strategie berücksichtigt werden.Folglich sind auch System- und Abnah -me tests nötig. Wie die Testpyramidezeigt, sollten die Tests über Be -nutzerschnittstellen aber nur einengeringen Anteil am Gesamtumfang derTests einnehmen.

Auswahl geeigneter Tests

Besonders bei der Testautomatisierungüber das GUI sollte selektiv bei derAuswahl geeigneter Testfälle vorgegangenwerden. Es kann das folgende einfache,aber effektive Modell angewendet werden:Man ermittelt für jeden Testfall den Wertund den Aufwand für die Testauto -matisierung und stellt die beiden Attributeanschließend in einem Diagramm gegen -über.

Unter anderem können Faktoren wieRisiko, Verwendungshäufigkeit und Fehler -häufigkeit in der Vergangenheit verwendetwerden, um den Wert eines Testfalls zuermitteln. Das Risiko ist das Produkt ausder Wahrscheinlichkeit des Auftretens einesEreignisses und der Schwere der Aus -wirkungen. Eine für den Tagesbetrieb not-wendige Funktion ist häufig wichtiger alseine alle paar Monate benötigte Funktion.Fehler treten häufig in Gruppen auf, wobeisich der größte Teil meist unsichtbar „imBoden“ befindet. Testen Sie also Funk -

tionen, die in der Vergangenheit fehler-trächtig waren, intensiver und häufiger. Einebenso wichtiger Faktor ist der Einfluss desgetesteten Prozesses auf den Erfolg derOrganisation.

Der Aufwand für die Testauto -matisierung ist die zweite Messlatte für dieAuswahl geeigneter Tests. Aspekte wie dieBereitstellung der Testumgebung und derTestdaten, die Anzahl der schwer testbarenSteuerelemente, Testautomatisierung undAnalyse der Ergebnisse beeinflussen dievorhin genannten Faktoren.

Sind Wert und Aufwand für einen Testermittelt, kann aufgrund des in Abbildung 2dargestellten Diagramms gesagt werden, ober automatisiert werden soll:

Die Nummern in den Quadraten desDiagramms veranschaulichen die empfoh-lene Reihenfolge der Testautomatisierung.Demnach sollten Tests mit hohem Wertund niedrigem Aufwand zuerst automati-siert werden. Tests mit niedrigem Wert undhohem Aufwand sollten erst zum Schlussbzw. gar nicht automatisiert werden.

Eine nachvollziehbare Auswahl der Test -fälle ist auch aufgrund eines anderenAspekts wichtig: Menschen suchen nachHerausforderungen. Folglich sind heraus-fordernde Testfälle, also jene mit hohemAufwand, für die Testautomatisierer meistinteressanter als einfache 08/15-Testfälle.Den Testautomatisierern sollte also eineklare Reihenfolge vorgegeben werden.

Architekturen

Nachdem dargestellt wurde, dass das GUIdiejenige Schnittstelle mit den größtenHerausforderungen ist und wie geeigneteTestfälle ermittelt werden können, wird indiesem Abschnitt die Testautomatisierungnäher betrachtet. Dazu gibt es verschiedeneArchitekturen. Die Wahl der richtigen Archi -tektur hat beträchtliche Auswir kun gen aufden Erfolg der Testautomati sierung.

Automatisierte Testfälle sollten Quali -täts attribute wie Robustheit, Wartbarkeitund Lesbarkeit erfüllen. Kleine Änderun-gen in Steuerelementen (z. B. ID, Position)dürfen sich nicht auf die automatisiertenTests auswirken. Des Weiteren sollten Teststrotz unerwarteter, aber für den Test unwe-sentlicher Ereignisse weiterlaufen. JederTest muss am Beginn der Durchführung aufeinen definierten Systemzustand vertrauen

2Online-Themenspecial Testing 2013

Online-Themenspecial Testing 2013 advertorial

Abb. 1: Testpyramide.

Abb. 2: Auswahl geeigneter Testfälle.

Arbeit mit Tabellen. Außerdem können siedie Testautomatisierung von mehrsprachi-gen Systemen unterstützen sowie auch dieProtokollierung und die Interaktion mitkomplizierten Steuerelementen. Fortge -schrittene Testautomatisierer generierenPage Objects, was besonders bei größerenSystemen mit Hunderten von Fenstern vielZeit erspart. Der alternative Weg, PageObjects manuell zu programmieren, istaber bei vielen kleineren Systemen vertret-bar.

Wie der Name Specification by Exampleerkennen lässt, dient diese Architekturdazu, gemeinsam mit dem KundenBeispiele zu spezifizieren. Die Beispiele die-nen allen Akteuren zum besserenVerständnis des Problems und demEntwicklungsteam als Testfälle. Der Fokusbei dieser Architektur liegt klar auf derPräsentation. Nichttechniker solltenBeispiele und somit Testfälle schreiben undlesen können. Beispiele für Systeme, diediese Architektur nutzen, sind FitNesse(vgl. [Fit]) und Programme für Behaviour-Driven Development wie z. B. JBehave (vgl.[Jbe]). Es ist jedoch zu empfehlen, dieseArchitektur primär für Abnahme- undAkzeptanztests zu verwenden. Bei System -tests ist oft keine Lesbarkeit für Nicht -techniker erforderlich. Page Objects undWorkflows reichen hier aus und Sie erspa-ren sich die Wartung einer Präsenta -tionsschicht.

Werkzeugauswahl

Neben der Wahl der Testarchitektur spieltdie Wahl des Werkzeugs eine wesentliche

wiederzuverwenden. Die meisten Werk -zeug hersteller kombinieren Scripting miteiner Map (die Classic Combination). Inder Map werden alle Informationen, diezur Identifikation von Steuerelementenbenötigt werden, an einer zentralen Stelleabgelegt. Testfälle und Skripte sollten keinesolchen Informationen mehr enthalten,sondern diese aus der Map beziehen.Ändert sich ein Steuerelement (z. B. derName), ist idealerweise nur eine Änderungin der Map nötig, um mehrere von derÄnderung betroffene Testfälle wieder zumLaufen zu bringen.

Keyword-Driven Testing ermöglichtauch Nichttechnikern, Testfälle zusammen-zustellen. In eigens dafür entwickelten Edi -toren (teilweise wird auch Excel dafür ver-wendet) können Tester die Bausteine(Key words, generische Aktionen) zu neuenTestfällen kombinieren. Die Bausteineselbst werden typischerweise von Personenmit Programmierkenntnissen erstellt undbereitgestellt.

Eine neuere und interessante Architek -tur variante für die Testautomatisierung istdas Page Object Pattern kombiniert mitWorkflows. Page Objects ersetzen die Map,indem sie die Informationen, die zurIdentifikation von Steuerelementen nötigsind, in Einheiten kapseln, die auch derBenutzer wahrnimmt: in Fenstern. Dem -nach existiert für jedes Fenster genau einPage Object. Testfälle und Workflows dür-fen über die Page Objects auf das GUIzugreifen. Die Page Objects bieten den obe-ren Schichten der Testautomatisierungpraktische Methoden an, wie z. B. die

können. Änderungen im GUI dürfen nureinen geringen Wartungsaufwand verursa-chen. Testspezifikation und Testprotokollesollten für die Zielgruppe lesbar sein.

Um diese Qualitätsattribute umsetzen zukönnen, unterscheidet man zwischen dreiAbstraktionsschichten, die zwischen derTestspezifikation und dem getestetenSystem liegen: Die unterste Schicht ist dieTechnik. Sie befasst sich mit der Identi -fikation von grafischen Steuerelementenund wie diese Informationen abgelegt undwiederverwendet werden können. Work -flows bilden die mittlere Schicht. Wieder -kehrende Abläufe sollten in möglichst vie-len Testfällen Anwendung finden. Dieoberste Schicht bildet die Präsentation derTestfälle. Sie wird nur benötigt, wenn auto-matisierte Tests auch von Personen zusam -men gestellt werden sollten, die nicht pro-grammieren können.

Nachfolgend werden mögliche Testauto -matisierungsmodelle basierend auf dieserSchichtenarchitektur beschrieben:

Obwohl die Aussage „Capture & Replayfunktioniert nicht!“ durch viele fehlgeschla-gene Testautomatisierungsprojekte unter -mauert wird, ist es genau diese Methode, diemanche Werkzeughersteller am meistenbewerben. Das Problem ist, dass die Testfällezu eng mit dem GUI verwoben sind.Technische Informationen für die Erken -nung von Steuerelementen werden nicht zen-tral, sondern in jedem Testfall separat abge-speichert. Änderungen im GUI verursachendadurch hohen Wartungs aufwand.

Beim Scripting wird versucht, häufig ver-wendete Abläufe in mehreren Testfällen

advertorial

3 www.objektspektrum.de

Abb. 3: Architekturen.

Rolle. Es gibt zwei Grundsätze, die dabeiberücksichtigt werden sollten: DassCapture & Replay nur eingeschränkt funk-tioniert und Testautomatisierung in vielenBereichen Softwareentwicklung ist. Umeine robuste und wartbare Testauto -matisierung zu erhalten, sollten Capture &Replay-Werkzeuge zumindest die Mög -lichkeit bieten, aufgezeichnete Skriptedurch Programmierung weiterzuentwi -ckeln.

Unabhängig von der Wahl desWerkzeugs können die Fähigkeiten derTester und Fachexperten am effizientestendurch eine Trennung der Testspezifikation(Kundensicht) von der Testautomatisierung(Sicht der Techniker) eingesetzt werden.Keywords, Page Objects etc. sind dafürgeeignete Mittel.

Fazit

In Reflektion verschiedener GUI-Test -automatisierungsprojekte ergeben sich diefolgenden Punkte als Erfolgsrezept für dieTestautomatisierung:

■ Auswahl: Testen Sie so wenig wie mög-lich über das GUI. Wählen Sie die zuautomatisierenden Tests sorgfältig aus.

■ Architektur: Verwenden Sie Page Objectsund Workflows. Program mieren SieTestfälle in einer weit verbreitetenAllzwecksprache, wie Java oder C#.Wenn es für die Kommu nikation mitdem Kunden hilfreich ist, kann einezusätzliche Präsentations schicht füreinen Teil der Tests sinnvoll sein.

■ Identifikation von Steuerelementen:Verwenden Sie eine Programm -

bibliothek, bei der Steuerelemente überXPath identifiziert und das Page ObjectPattern umgesetzt werden kann.

■ Entwicklungsumgebung: Werkzeuge wieEclipse und Visual Studio erhöhen dieEffizienz beim Automatisieren von Tests.

■ Programmieren: Testfälle sollten pri-mär von Personen automatisiert wer-den, die programmieren können.

4Online-Themenspecial Testing 2013

Online-Themenspecial Testing 2013 advertorial

Referenzen

[Cri08] L. Crispin, J. Gregory, Agile Testing: A

Practical Guide for Testers and Agile Teams,

Addison Wesley, 2008.

[Fit] Fitnesse http://fitnesse.org.

[Jbe] JBehave http://jbehave.org.