Testautomatisierung heuteErfolgsfaktoren bei der automatischen Ausführung von GUI-Tests

Die meisten Firmen stellen im System- und Abnahmetest für das GUI-Testen individuelle Testautomatisierungslösungen zusam-men, und verbrauchen damit sehr viel Kraft und Ressourcen. Sucht man nach Prozessen und Werkzeugen, so wird man zwar fün-dig, aber beim Einsatz ergeben sich vielfältige Probleme, die es zu umschiffen gilt. Dieser Artikel beschreibt den aktuellen Standder Technik zur Lösung dieser Probleme und liefert eine praktische Checkliste (siehe Abbildung 1), um die automatischeAusführung von Testfällen erfolgreich planen und durchführen zu können.

automatisierte Testfälle erstellt. Auto -matisiert der Automatisierungs ingenieurgut verstandene Geschäftsprozesse, werdendabei auch komplexe Testszenarien erstellt.

Vermeidung der WartungsfalleUm die Wartung automatisierter Testfällezu gewährleisten, ist zudem eine tragfähigeund gleichzeitig flexible Testware-Archi -tektur mit verschieden Abstraktions ebenennötig (vgl. [Gra12]). In der oberen Ebene derTestware-Architektur (siehe Abbildung 3)können die Fachexperten durch verständli-che Schlüssel wörter Tests anpassen, aus-führen oder sogar selbst erstellen. DieserAnsatz ist inzwischen weit verbreitet. ImMittelteil befindet sich ein Framework, indem die Testware organisiert ist. In derunteren Ebene befinden sich strukturierteSkripte zur vereinfachten Wartung. Dies

Erhöhung der ProduktivitätAb einer gewissen Anzahl wird die auto-matisierte Ausführung eines Testfallesdurch eine Maschine kostengünstiger alsdessen manuelle Ausführung durch einenMitarbeiter. Ist die genügend häufigeAusführung eines manuellen Testfallesgeplant, rentiert sich die Investition in dieErstellung und Wartung eines automati-schen Testfalles, der ohne Tester „vollauto-matisch“ ausgeführt werden kann. Durchdie Aufhebung der Trennung von manuel-lem und automatisiertem Testfall (sieheAbbildung 2) in einem integrierten Testfall,der sowohl vom Fachbereichsexperten alsauch vom Automatisierungsingenieur aus-geführt und angepasst werden kann, lässtsich die Produktivität bis zum Faktor 5erhöhen. Wenn der Fachbereich Geschäfts -prozesse dokumentiert, werden gleichzeitig

Es ist nicht optimal, wenn die Fach bereichs -experten manuelle Testfälle erstellen und denProgrammierern zur Auto matisierung über-geben. Deshalb ist es inzwischen üblich, dassder Fachbereich in den Testautomati -sierungs prozess einbezogen wird. DieTestautomatisierung wird unter denGesichtspunkten Motivation, Anforderun -gen, Konzepte und Prozesse beleuchtet. Inden letzten zehn Jahren entstand die hier vor-gestellte Checkliste aus der Dokumentationvon Strukturen und Konzepten von zahlrei-chen Testautomati sierungs projekten, unteranderem bei Allianz, Audi, BMW, KDG,Kion, Siemens und Zurich.

Der Begriff Testautomatisierung im Soft -waretest wird sehr oft mit unterschied-lichen Bedeutungen verwendet. DieserArtikel beschränkt sich bei der Definitiondes Begriffs auf die automatisierteAusführung des System- und Abnahme -tests. Es wird im Folgenden auf die zehnwichtigsten Themen eingegangen, die wirk-lich essenziell für den Erfolg im praktischenEinsatz sind. Die Reihenfolge der Themenergibt sich aus der zeitlichen Abfolge derThemen und stellt keine Priorisierung dar.

MotivationManager bemängeln bei der Testauto -matisierung die hohen Kosten und dieHaltbarkeit von Testsuiten und suchennach Wegen zur Erhöhung der Pro -duktivität und zur Vermeidung der War -tungsfalle.

der au tor

Johann Gietl

(johann.gietl@sogeti.de)verfügt als iSQI Quality Assurance Management Professional über tiefeKenntnisse in der Testautomatisierung und dem Testmanagement. Seit2011 ist er für Sogeti Deutschland als Managing Consultant tätig.

1 www.objektspektrum.de

advertorial

Abb. 1: Checkliste Testautomatisierung.

sichert die Langlebigkeit der automatisier-ten Tests.

AnforderungenNach den Motivationsthemen Produkti vitätund Wartungsfalle müssen nun die Anfor -derungen festgelegt werden. Die wesent-lichen Elemente der funktionalen Anfor -derungen werden als Use Cases definiert,während die nichtfunktionalen Anforderun -gen als einfache Liste realisiert werden.

Beschreibung der funktionalenAnforderungen.Im Folgenden sind beispielhaft die UseCases zur automatischen Ausführung einesTests dargestellt (siehe Abbildung 4).

Mit Aktiviere Testausführung initiiertder Fachexperte die Testausführung durchden Start einer Ausführungsliste. Die Testswerden vom Test Management Tool abge-holt. Über <<include>> wird der Use CaseInterpretiere Test eingebunden, der dieTests zeilenweise abarbeitet und ausführba-ren Code erstellt. Wenn Fehler auftauchen,wird Sende Fehlerbenachrichtigung aufge-

2Online-Themenspecial Testing 2013

Online-Themenspecial Testing 2013 advertorial

Abb. 2: Integration von manuellem und automatisiertem Test.

Abb. 3: Testware-Architektur.

Abb. 4: Use Cases Automatische Testfallausführung.

rufen. Des Weiteren initiiert das Test -framework den Use Case Führe Test ausmit dem Actor Test Automation Tool, derden Code ausführt. Schließlich wird im UseCase Erstelle Testlog für jede Testzeile einLogeintrag erstellt. In ähnlicher Weise wer-den die Use Cases für die Testfall -

spezifikation und für den (Fehler-)Reporterstellt.

Beachtung der nichtfunktionalenAnforderungenEiner ausführlichen Betrachtung bedürfenneben den funktionalen auch die nicht-funktionalen Anforderungen. Dabei gilt es,die folgenden Qualitätsmerkmale alsAnforderungen aufzulisten, entsprechendzu gewichten und mit Abnahmekriterien zuversehen. Je wichtiger eine Anforderungbewertet wird, umso genauer müssen dazuMesswerte definiert und überprüft werden.

■ Flexibilität: Ein Testframework mussanpassbar sein. Bei Änderungen in derZielanwendung darf kein übermäßigerAufwand bei der Anpassung desFrameworks entstehen.

■ Wiederverwendbarkeit: Ebenso solltendie Tests, Komponenten und Funktio -nen mehrmals einsetzbar sein.

■ Einfachheit: Die Komplexität sollte fürdie verschiedensten Fachbereiche leichtüberschaubar und intuitiv erfassbarsein.

■ Schnelligkeit: Daneben sollte es schnellmöglich sein, neue Tests, Komponentenund Funktionen zu erstellen sowie An -passungen daran vorzunehmen.

■ Effektivität/Effizienz: Selbst verständ -lich ist es notwendig, effektiv und effi-zient Testfälle erstellen zu können.

■ Robustheit: Des Weiteren muss die sta-bile automatische Ausführung derTestfälle in den heißen Projektphasengewährleistet werden.

■ Wirtschaftlichkeit: Das gesamte Paketmuss rentabel sein.

werden die drei Datenarten statisch, dyna-misch und unmittelbar unterschieden:

■ Die statischen Daten sind bei allenTestfallausführungen konstant undwerden als konkrete Parameterwertespezifiziert.

■ Dynamische Daten werden zu Beginnder Testfallausführung interpretiert undin konkrete Parameterwerte umgewan-delt. Ein Beispiel hierfür ist die DC<Today>, die zu Beginn der Test -ausführung in das aktuelle Tagesdatumumgewandelt wird.

■ Unmittelbare Daten sind erst an einembestimmten Punkt während der Test -fallausführung verfügbar. Dabei han-delt es sich meist um Prüfungen vonErgebniswerten oder um die Ausgabevon z. B. Vertragsnummern.

Alle DCs werden direkt bei den Ge -schäftsprozessschritten (oder BCs) spezifi-ziert. Bei der Erstellung und Strukturierungvon Testfällen, Flows, BCs und DCs ist aufdie Lesbarkeit und Wartbarkeit zu achten.

Definition des TestframeworksNach der fachlichen Architektur geht esjetzt an das Framework zur Verbindung derfachlichen und technischen Ebenen.

In Abbildung 6 ist die dreiteilige Struktureines Testframeworks abgebildet. Auf derlinken Seite befinden sich die Testfall -spezifikationen mit den TabellenblätternInput-Prozess, Input-Daten und In put/Out -put-Daten sowie Log- und Report-Dateien.In der Mitte befindet sich der Kern desTestframeworks. Der Input/Output Managerliest die Testfälle zur Laufzeit ein, bearbeitetdiese und speichert die Ergeb nis se ab. DerBusiness Component Interpreter interpretiertdie Schlüsselwörter und er zeugt lauffähigeBefehle. Der Data Component Interpreterlöst zur Laufzeit die dynamischen undunmittelbaren Test datenwerte auf. Schließ -lich erfolgt noch die Zuordnung der Test -objekte auf die Zielanwendung.

Definition der technischen ArchitekturIn der untersten Abstraktionseben werdennun die technischen Konzepte definiert. DieErstellung der Skripte erfordert strukturierteTechniken und Richtlinien. Für dieKonzeption eines technischen Architektur -elementes sind hier exemplarisch dieBeziehungen der Sheets dargestellt, welchedie Benutzerschnittstelle definieren (sieheAbbildung 7).

die von fast allen Beteiligten ohne großenSchulungsaufwand bereits beherrscht wer-den.

In Abbildung 5 sind fünf Ebenen einerfachlichen Architektur dargestellt. Ganzoben im Test Management Tool befindensich die Ausführungslisten, darunter dieTestfälle. Die weiteren Ebenen sind hier alsExcel-Arbeitsmappen integriert. JedesTabellen blatt entspricht einem Ablauf(oder Flow), jede Zeile entspricht einemProzessschritt, auch Geschäftskomponenteoder Business Component (BC) genannt.Bei besonders komplexen Anwendungenkönnen für die BCs weitere Ebenen defi-niert werden. Zum Beispiel die EbenenNiedrig für einfache Steuerungselemente,Mittel für Dialoge und Hoch fürTeilprozesse. BCs bestehen aus einer Zelle,die das Schlüsselwort enthält und den dazuzugehörigen Datenzellen, die hier DataComponent (DC) genannt werden. Diephysische Trennung von Test schritten undTestdaten machen das Testdesign bzw. diemanuelle Testausfüh rung unnötig kompli-ziert. Um diese Tren nung zu vermeiden,werden hier DCs definiert. Eine DC bestehtaus einem Para meternamen und einemWert. Der Parametername ergibt sichzumeist direkt aus den Feldbezeichnern derzu testenden Anwendung. Bei den Werten

■ Standardisierung: Schließlich solltenstandardisierte Werkzeuge, Methodenund Prozesse für eine nachhaltige Ver -wendung der Ergebnisse sorgen.

Konzepte Nach Dokumentation und Priorisierung derAnforderungen müssen für die drei Ab -straktionsebenen Fachliche Architektur,Testframework und Technische Architekturtragfähige Konzepte definiert werden.

Definition der fachlichen ArchitekturDie fachspezifische Schnittstelle bildet dieKommunikationsbasis zwischen den fach-lichen Testdesignern und den Test inge -nieuren. Die fachspezifische Testsprache wirdin der Literatur oft Domain Specific TestLanguage (DSTL) genannt. Es ist zum einendarauf zu achten, dass die Sprache einfachund intuitiv gehalten wird und zum anderen,dass der Formalismus auf das Notwendigstebeschränkt wird, um Ge schäftsprozesstestsim System- und Abnah me test automatischauszuführen. Das etablierte Grundprinzip isteine Folge von Zeilen der FormSchlüsselwort;Datum;Datum;… (Beispiel:Login;User:=Mustermann;Password:=1234)ohne Schleifen und Sprünge. Als optimaleDarstellung zur einfachen Handhabung derTests haben sich Tabellenblätter bewährt,

advertorial

3 www.objektspektrum.de

Abb. 5: Fachliche Architektur.

Abb. 6: Beispiel eines Testframeworks.

Das Process Sheet (Tabellenblatt) enthältProcess Sheet Entries (BCs). +actionWord“ist die technische Realisierung der Schlüs -selwörter und die +parameter implementie-ren die Data Components (DCs). Danebenexistieren noch einige weitere Datensheets,um die verschiedensten Testanforderungenzu realisieren. Das Test Data Sheet enthältTest Data Sheet Entries (Testdatensätze).Das Runtime Control Sheet enthält techni-sche Informationen zur Verwaltung derTestabläufe, während die Runtime DataSheets die Ausgabewerte zur Laufzeit auf-nehmen. Im Report Sheet werden dieProtokolleinträge und Testergebnisse ge -führt. Für die Programmierung der BCsund DCs empfiehlt sich eine strikt formali-sierte „Inline“-Dokumentation. Aus denstandardisierten Kommentaren lassen sichWertehilfen und Füllfunktionen generieren,die den Testdesigner bei der Erstellung undWartung von Tests mit BCs und DCs opti-mal unterstützen. Für die Programmierungsind natürlich alle sinnvollen und standar-disierten Architekturelemente denkbar (vgl.[Few99]). Nicht vergessen werden solltenauch (Code-)Reviews und Entwicklertests.

ProzesseSind die Konzepte geklärt, ist für die Um -setzung ein gewisses Maß an Change

Management nötig. Hier müssen die Pro -zesse zur Integration der Fachexperten undim Testmanagement angepasst werden.

Integration der FachexpertenZu Beginn eines Testautomatisierungs pro -jektes müssen sich die Fachexperten undTestingenieure auf gemeinsame Schlüssel -wörter einigen. Der Fachbereich muss dabeieinige Formalismen in Kauf nehmen, wäh-rend die IT alle technischen Merkmale vonder obersten Abstraktionsebene fernhaltensollte. Sind die ersten automatisiertenTestfälle am Laufen, kann der Fach bereichbereits zügig neue Varianten dieser Ge -schäfts objekte durch Kopieren und Editierenerstellen (siehe Abbildung 8). Dies ist derPunkt, an dem sich der Hebel für die Maxi -mierung der Produktivität befindet. DieFachexperten werden mit geringem Lern -aufwand in die Lage versetzt, komplizierteSachverhalte in automatisierten Tests ohneProgrammierkenntnisse selbst zu realisieren.

TestmanagementDie rollenbasierte Definition der Arbeits -pakete ist im Testautomatisierungsprozessunerlässlich. Der Fachexperte ist zuständigfür das Testdesign und die Auswahl derTestfälle. Der Testautomatisierer program-miert die BCs, wartet sie und integriert die

Testszenarien in den Regressionstest. DieFreigabe erfolgt durch den Testmanager,während die regelmäßige Ausführung imZuständigkeitsbereich der Fachexpertenliegt. Der Testmanager trägt die Verant -wortung für den Gesamtprozess vomTestdesign bis zur regelmäßigen Ausfüh rung.

Umsetzung der Konzepte und ProzesseWichtiger noch als die vorangegangenenPunkte der Checkliste ist die Realisierungeiner Testautomatisierung: „Just do it!“. Umein besseres Gefühl für die verschiedenen Auf -gaben zu bekommen, sollte man klein begin-nen, um dann die großen Projekte ebenso zubeherrschen. Ein großer Vorteil des Frame -works ist, dass es sich innerhalb kürzesterZeit sehr schnell an ein neues Projekt anpas-sen lässt. So dauert es meist nicht mal einenTag, bis der erste Testfall fertiggestellt ist. Eineflächendeckende Imple men tierung in Groß -unterneh men mit zahlreichen Pro jekten erfor-dert erheblichen Abstim mungs aufwand unddauert natürlich wesentlich länger. Ein bishernoch nicht genannter Fak tor ist die Besetzungder Testdesigner und der Test ingenieure. DerTestdesigner benötigt fach liche Expertise, derTestingenieur Pro am mier kenntnisse. Umoptimale Ergebnisse im Regressionstest erzie-len zu können, müssen beide Rollen auch fun-dierte Kenntnisse des Testprozesses und derTest werkzeuge aufbauen.

FazitJedes vorgestellte Thema für sich ist einwesentlicher Faktor, der sorgfältig berück -sichtigt werden sollte, da ansonsten dasTestautomatisierungsprojekt zur Kosten -falle werden kann. Die Erfolgsfaktorenwurden anhand einer Checkliste für GUI-Testautomatisierung dargestellt. Nach hal -tige Ergebnisse zeigen sich insbesondere beiUnternehmen, die in der Testauto mati -sierung einen langfristigen Horizont habenund erstellte Testartefakte in mehreren Pro -jekten wiederverwenden können. ■

4Online-Themenspecial Testing 2013

Online-Themenspecial Testing 2013 advertorial

Abb. 7: Beziehungen zwischen denEin- und Ausgabesheets.

Abb. 8: Integrationdes Fachbereichs.

Referenzen

[Dor] Website Dorothy Graham, siehe

http://www.dorothygraham.co.uk.

[Few99] M. Fewster, D. Graham, Software

Test Automation, Addison Wesley, 1999.

[Goo] Google Automation, siehe

http://www.googleautomation.com.

[Gra12] D. Graham, M. Fewster, Experiences

in Test Automation, Addison Wesley, 2012.