„Gegurke“ für FortgeschritteneTesten während der Entwicklung durch Entwickler gehört spätestens seit dem Aufkommen agiler Softwareentwicklungsprozessewie beispielsweise Extreme Programming (vgl. [Bec04]) zu den festen Bestandteilen zeitgemäßer Softwareentwicklung. Dabeiwerden bevorzugt automatisierte Tests verwendet. Je mehr sich der Testgegenstand von Implementierungsdetails (also klassi-schen Unit-Tests) hin zu Systemtests und dem Prüfen von komplexen Kundenanforderungen entwickelt, desto umständlicher wirddie Umsetzung der Testautomatisierung. Dadurch ist es oft schwierig, den eigentlichen Testfall im Automatisierungscode zuerkennen. Personen, die mit der Automatisierungstechnologie nicht vertraut sind, sind dadurch typischerweise nicht in der Lage,den automatisierten Test nachzuvollziehen.

rischen Maßnahmen zu finden. Die organi-satorischen Maßnahmen werden an eineman Scrum (vgl. [Sch01]) angelehnten Pro -zess erläutert. Eine mögliche technischeUmsetzung stellen wir in diesem Artikelanhand von Cucumber (vgl. [Cuc]) vor.Cucumber ist in der Ruby-on-Rails-Community ein etabliertes Werkzeug zumErstellen automatisierter Testfallbeschrei -bungen. Von Cucumber existiert zudemeine Variante für die Java Virtual Machine(vgl. [Git]) und mit SpecFlow (vgl. [Spe])eine Variante für die .Net-Plattform. DasWerkzeug wird von einer aktivenCommunity entwickelt und gepflegt. DerArtikel beschreibt im Folgenden eineVorgehensweise, die sich an BehaviorDriven Development (vgl. [Nor06]) bzw.Acceptance Test Driven Development (vgl.[Fre10]) orientiert.

Die Vorgehensweise ist in Abbildung 1schematisch dargestellt. Zunächst werdenTestfallbeschreibungen erstellt. Die Test fall -beschreibungen dienen als Aus gangsbasisfür die Ausführungslogik und werden durchdiese interpretiert. Zur automatischenDurchführung des Testfalls interagiert dieAusführungslogik mit der zu testendenAnwendung und vergleicht deren Verhaltenmit dem im Testfall spezifizierten erwartetenVerhalten. Die Ergebnisse des Tests werdenzusammen mit der ursprünglichen

sind die Anforderungen nicht präzisegenug, um aus ihnen Tests ableiten zu kön-nen. Die Folge ist ein gewisser Inter -pretationsspielraum. Dieser Interpreta -tions spielraum sorgt sowohl bei derImplementierung als auch bei der Test -fallentwicklung für unnötige Missverständ -nisse zwischen Fachseite und Entwicklung.

Der Artikel zeigt im Folgenden auf, wie dieeingangs beschriebenen Probleme reduziertwerden können und beschreibt die dazu not-wendigen Vorgehensweisen und möglicheTechnologien. Ziel ist es, automatisierteSystem tests zu erhalten, die von allen Be tei lig -ten verstanden und gepflegt werden können.Dazu sind eine Reihe von Fragen zu klären:

■ Wie können Testfälle verständlichbeschrieben werden?

■ Lassen sich die Beschreibungen so er -stellen, dass diese 1:1 für eine Testaus -führung verwendet werden können?

■ Wie kann die Lesbarkeit und Ver -ständlichkeit der automatisierten Testsverbessert werden?

■ Wie kann man erreichen, dass automa-tisch ausführbare Systemtests nicht erstam Ende einer langen Entwicklungerstellt werden?

Die Antworten auf diese Fragen sindsowohl in technischen als auch organisato-

Die Beschreibung der Testfälle erfolgt beiSystemtests entweder rein textuell oder inautomatisch verwertbarer Form. AlsWerkzeuge für textuelle Beschreibungendienen hier oft noch Office-Anwendungenoder spezielle Testmanagementwerkzeuge,die in gewissem Rahmen auch eine Test -automatisierung zulassen. Da dieAutomatisierung der Tests aber typischer-weise von der Beschreibung getrennt ist,entsteht so die Situation, dass kaum nach-vollzogen werden kann, ob Testfallbe -schreibungen mit den automatisierten Testsübereinstimmen. Änderungen an Testfall -beschreibungen führen damit oft zu hohenAufwänden bei der Anpassung automati-sierter Tests, da einerseits unklar ist, welcheautomatisierten Testfälle überhaupt vonder Änderung betroffen sind und anderer-seits die zu ändernden Stellen im komple-xen Automatisierungscode nur schwer zuidentifizieren sind.

Testfälle für Systemtests werden bei klei-neren Projekten, wenn überhaupt, oft erstgegen Ende des Entwicklungszyklus ent-worfen. Bei größeren Projekten bestehtdagegen oft das Problem, dass die entwor-fenen Systemtests oft nur einfache Fälleabbilden. Details von Prozessen undGeschäftsregeln werden dabei vernachläs-sigt. In den vorhandenen Anforderungenfehlen diese Details ebenfalls häufig. Damit

der au tor

Dr. Ralph Guderlei

(ralph.guderlei@exxcellent.de)ist Project Manager und Software Architect bei der eXXcellent solutions GmbHin Ulm. Dort ist er in unterschiedlichen Kundenprojekten mit der Planung undRealisierung von Enterpriseanwendungen beschäftigt. Neben Technologie -themen interessiert ihn besonders die effiziente Umsetzung von QS-Maßnah -men im Projektalltag.

1 www.objektspektrum.de

advertorial

Testfallbeschreibung für das Repor ting ver-wendet. Beim Reporting können sowohldirekt lesbare HTML-Reports erstellt alsauch Drittsysteme angebunden werden.

Um eine verständliche und gut lesbareTestfallbeschreibung zu erhalten, muss esmöglich sein, Testfälle quasi allgemein-sprachlich zu formulieren. Die allgemein-sprachliche Formulierung erlaubt eine bes-sere Kommunikation von Fachseite undEntwicklung über Testfälle, erleichtertdamit die Erstellung und Priorisierung derTestfälle und auch die Klärung von offenenFragen. Das folgende Beispiel stammt auseinem realen Projekt:

Die einzige Einschränkung der DSL imVergleich zu frei formulierten Texten istnun, dass alle Zeilen mit einem Schlüssel -wort beginnen müssen. Jeder dieser Sätzewird als Step bezeichnet. DieSchlüsselworte zeigen an, ob es sich umeine Vorbedingung (Given), eine Aktion(When) oder eine prüfbare Nachbedingung(Then) handelt. Die Schlüsselworte sindselbstverständlich internationalisierbar,sodass auch bei Testfallbeschreibungen ineiner anderen Sprache als Englisch keineunschöne Vermischung unterschiedlicherSprachen entsteht. Ein Szenario kannzudem jeweils mehrere Vorbedingungen,

schreibung und Automatisierung direktmiteinander verbunden werden können.Basierend auf der Beschreibung muss nach-vollziehbar sein, was bei der Automati -sierung der Tests abläuft, um die Automa -tisierung verifizieren zu können. DieseVerbindung von Testfallbeschreibung undTestautomatisierung ist ein wesentlicherBestandteil von Cucumber. Bei der Ausfüh -rung wird jede Zeile der Testfallbe -schreibung auf eine Ausführungsmethodeabgebildet. Diese enthält dann die eigentli-che Automatisierungslogik. Cucumberunterstützt hierbei Ruby, eine Vielzahl anJVM-Sprachen (u. a. Java, Scala, Clojure)und .Net-Sprachen, um die Automati -sierungslogik zu implementieren. Die Auto -matisierungslogik wiederum greift pro-grammatisch auf die zu testendeAn wendung zu. Die Voraussetzung hierfürist, dass geeignete Werkzeuge für diesenZugriff existieren. Für Webanwendungenhat sich beispielsweise Selenium bewährt.Aber auch für andere Oberflächen -technologien (z. B. Swing oder WPF) gibt esentsprechende Werkzeuge. Im Zweifelsfallkann auch mit Capture&Replay-Werk -zeugen gearbeitet werden. Diese Möglich -keit sollte aber aufgrund des hohen Auf -wands bei Erstellung und Pflege der Testsnur in absoluten Ausnahmefällen genutztwerden.

Bei allen JVM-Sprachen wird JUnit fürdie Testausführung verwendet. Dadurchintegriert sich Cucumber in alle üblichenIDEs, Build-Tools und Continuous-Integra -ion-Systeme. Darüber hinaus gibt es spe-zielle Cucumber-Plugins für IDEs, die nichtnur die Testausführung, sondern auch dasSchreiben von Testfallbeschreibungendurch Syntax-Highlighting und Auto-Vervollständigung unterstützen.

Für den ersten Beschreibungssatz imBeispiel könnte die Umsetzung der Imple -mentierung der Automatisierungslogik mitHilfe von Cucumber wie folgt aussehen:

Der Zusammenhang zwischen Beschrei -bung und Automatisierungslogik wird überreguläre Ausdrücke hergestellt. Dieseermöglichen es, variable Inhalte in den

2Online-Themenspecial Testing 2013

Online-Themenspecial Testing 2013 advertorial

Abb.1: Schematische Darstellung der Vorgehensweise.

Feature: create projectsIn order to enable other users to collaborate, as an administrator,I want to create project.

Scenario: create an empty projectGiven the project 'emptyproject' does not existWhen I create a new project called 'emptyproject'Then the project 'emptyproject' should be listed in the project list

Die Systemtests beschreiben das gewünsch-te Verhalten des Systems in derFachsprache. Um die Beschreibungen spä-ter besser zur Testautomatisierung heran-ziehen zu können, muss die Sprache zurBeschreibung formalisiert werden.Cucumber bietet hierfür eine einfacheDomain Specific Language (DSL) (vgl.[Fow10]) an. Die Beschreibung der Test -fälle erfolgt in einem festgelegten Schema.Ein sogenanntes Feature besteht aus einemoder mehreren Szenarien. Die Szenarienstellen die eigentlichen Testfälle dar. Fea -tures und Szenarien können zusätzlichnoch mit einem Freitext beschrieben wer-den, der nicht Teil der Testausführung ist.

Jedes Szenario besteht aus Vorbedin -gungen, Aktionen und Nachbedingungen.

Aktionen und Nachbedingungen enthalten.Dadurch werden auch komplexe Szenarienwie z. B. komplette Prozessabläufe ermög-licht. Steps können parametrisiert und inunterschiedlichen Szenarien wiederverwen-det werden.

Bei der Formulierung der Testfälle hat essich als vorteilhaft herausgestellt, Beschrei -bungen technischer Abläufe (z. B. Infor -mationen, welche Buttons gedrückt werdenmüssen) zu vermeiden. Technische Abläufestellen immer die Implementierung in denVordergrund, statt sich auf die gewünschtefachliche Funktionalität zu konzentrieren.Im Idealfall ist die Art der technischenRealisierung des Systems nicht aus denTests ableitbar.

Die nächste Frage ist, wie Testfall be -

@Given (“^the project '([\w-.]+)' doesnot exist$”)public voidcheckIfProjectDoesNotExist(StringprojectName){assertFalse(projectList.containsProjectWithName(projectName));}

Laufzeit, dadurch sind Systemtests leiderkaum bei jedem Einchecken in das Versions -managementsystem durchführbar. Vermei -det man Abhängigkeiten von Tests unterein-ander, kann auch die Ausführung vonSystemtests gut parallelisiert werden. EineInitialisierung des Datenbankbestands durchTests ist so allerdings nur schwer möglich.

Um die vorgeschlagene Vorgehensweiseoptimal zu unterstützen, ist es notwendig,die Entwicklung featurebasiert durchzufüh-ren, d. h. Entwickler arbeiten an kleinen,abgegrenzten Arbeitspaketen, die sich aufeinzelne Funktionalitäten beschränken.Diese Features können in Form von UserStories oder Use Cases (vgl. [Coc00])erfasst werden. Wenn man die Szenarien inden Use Cases bereits in der eingeführtenCucumber-DSL beschreibt, können dieSzenarien der Use Cases bzw. die Beschrei -bungen der User Stories direkt als automa-tisierte Testfallbeschreibung herangezogenwerden. Wenn Anforderungen nicht bereitsin dieser Form vorliegen, empfiehlt es sich,die Anforderungen in die entsprechendeForm zu überführen. Bei dieser Überfüh-rung zeigen sich erfahrungsgemäß schnelldie Defizite der bestehenden Anfor -derungen. Um die Defizite auszugleichen,muss eine intensive Kommunikation der

Cucumber bietet keine Unterstützung beiden typischen Problemen bei Systemtests,es bietet ausschließlich einen Rahmen fürdie Organisation und Ausführung derTestfälle. Die technischen Herausfor derun -gen bei Systemtests müssen weiterhin gelöstwerden. Zuerst muss die notwendigeInfrastruktur automatisiert aufgesetzt wer-den bzw. ein automatisches Deployment ineine Testinfrastruktur erfolgen. Hier hatsich eine Mischung aus Deployment -funktionalitäten bestehender Build-Systemeund virtualisierten Infrastrukturen alspraktikabel herausgestellt. Für dieDurchführung der Tests ist zudem eineInitialisierung des Datenbestands (z. B.Datenbank) notwendig. Hier hängt diebeste Lösung oft von den Gegebenheitendes jeweiligen Systems ab. Im einfachstenFall können Systemtests so gestaltet wer-den, dass diese einen initialen Daten -bestand in einer leeren Datenbank erzeu-gen. In komplexeren Fällen könnenImport funktionalitäten oder Datenbank-Snapshots für die initiale Befüllung derDatenbanken genutzt werden.

Eine weitere Herausforderung ist die zurDurchführung der Tests notwendige Zeit.Systemtests haben gegenüber Unit-Teststypischerweise eine deutliche längere

Testfallbeschreibungen unterzubringen.Die variablen Inhalte werden dann alsPara meter der Automatisierungslogik über-geben. Die Automatisierungslogik enthältsowohl die Ansteuerung der zu testendenAnwendung als auch die Prüfung deserwarteten Verhaltens der Anwendung. DieAnsteuerung der zu testenden Anwendungverbirgt sich im Beispiel hinter„projectList.containsProjectWithName()“,die Prüfung des erwarteten Verhaltenserfolgt über JUnit-Assertions(„assertFalse()“).

Es empfiehlt sich, die Zugriffe auf die zutestende Anwendung weiter zu abstrahie-ren. Bei Webanwendungen kann man dazubeispielsweise auf das Page Object Pattern(vgl. [Pag]) zurückgreifen. Ein Page Objectkapselt die Funktionalität für den Zugriffauf einzelne Seiten bzw. Komponenteneiner Webanwendung und stellt der Auto -matisierungslogik Funktionen für diebequeme Ansteuerung der zu testendenAnwendung bereit. Das Page Object ist imBeispiel durch die Variable „project List“angedeutet. Die weitere Abstrak tionerleichtert die Wiederverwen dung derZugriffslogik in unterschiedlichen Ausfüh -rungsmethoden und die Wartbarkeit derZugriffslogik.

advertorial

3 www.objektspektrum.de

Abb. 2: Reportübersicht.

Beteiligten stattfinden. Aus dieser entwi -ckelt sich dann ein gemeinsames Verständ -nis für die Anforderungen.

Findet dieser Abgleich der Anfor derungennicht statt, werden abweichende Interpre ta -tionen von unscharfen Anfor derungen erstspät entdeckt und führen zu teuren Nach -arbeiten. Die Aufarbeitung der Anforderun -gen muss am Anfang der Entwicklung, spä-testens bei der Planung der nächsten Iteration(Sprint) erfolgen. Die Aufarbeitung erfolgtsomit möglichst frühzeitig. Die gewünschteTestbarkeit der Anforderungen ergibt sichdamit direkt bei der gezielten Aufarbeitungder bestehenden Anforderungen.

Der Entwicklungsprozess selbst orien-tiert sich am klassischen Test-DrivenDevelopment. Für jedes Feature werdenzunächst ein oder mehrere (System-)Test -fälle spezifiziert. Eine erste Durchführungdes Tests sollte scheitern, da die zu testendeFunktionalität noch nicht umgesetzt wur-de. Die Entwicklung eines Features istabgeschlossen, sobald die Tests desFeatures erfolgreich durchgeführt wurden.Bei einem an Scrum angelehnten Entwick -lungsprozess sollte die erfolgreiche Durch -führung der Systemtests in die Definitionvon Done für ein Arbeitspaket aufgenom-men werden. Die Tests sichern dabei auchautomatisch eine gewisse Qualität derUmsetzung ab, sodass Folgeaufwände fürIntegration oder Nacharbeiten gering aus-fallen sollten.

Es empfiehlt sich, die Systemtests so oftwie möglich durchzuführen. Bei realenProjekten bedeutet das typischerweise, dassalle Systemtests ein- bis zweimal pro Tagdurchgeführt werden. Das reicht normaler-weise aus, um Regressionen schnell genugzu entdecken, sodass diese noch während

der Entwicklung eines Features behobenwerden können.

Cucumber bietet die Möglichkeit, dieTestergebnisse in unterschiedlichen Forma -ten zu dokumentieren. Eine Möglichkeitbesteht darin, die Ergebnisse in einemHTML-Dokument aufzubereiten. Diesesbietet sowohl eine Übersicht über dieErgebnisse als auch detaillierte Informa -tionen, welche die Testfallbeschreibungenund deren Ergebnisse bis auf die einzelnenSätze der Testfallbeschreibung enthalten.Die HTML-Reports können allen Projekt -beteiligten einfach zugänglich gemachtwerden und ermöglichen so eine schnelleÜbersicht über den Zustand des Projekts.Da es beim vorgeschlagenen Vorgehen einedirekte Verbindung von Features und Testsgibt, zeigt der Report an, welche Featuresmomentan funktionieren und welche nicht.Bei klassischen Unit-Tests ist dieseInterpretation der Testergebnisse nicht soeinfach möglich.

Des Weiteren können die Testergebnisseauch als Json- oder XML-Datei protokol-liert werden. Diese können gut automati-siert weiterverarbeitet werden. Auf diesemWeg können Drittsysteme wie beispiels-weise Testmanagementlösungen oder IssueTracker angebunden werden.

Wenn alle Systemtests zumindest rudi-mentär implementiert sind, ermöglicht dasReporting zudem eine einfache und aussa-gekräftige Bestimmung des Fertigstellungs -grades des Gesamtsystems bzw. der aktuel-len Iteration (Sprint).

Bei einer Entwicklung mit Feature-Branches können Feature-Branches bei erfol-greichen (System-) Tests mit geringem Risikoautomatisiert in einen stabilen Branch über-nommen werden. Dadurch ist es mit vertret-barem Aufwand möglich, Kun den oderTestteams eine aktuelle, hinreichend stabileVersion eines Systems zur Verfügung zu stel-len, um damit neue Fea tures frühzeitig aus-probieren oder weitere manuelle Tests durch-führen zu können. Noch weiter gedacht sinddurchgehend auto matisierte Systemtests eineder Voraus setzungen für automatisierte Pro -duk tiv-Deploy ments (Continous Delivery(vgl. [Hum10])).

Automatisierte Systemtests sind einwichtiger, aber nicht der einzige Bestandteileiner umfassenden Strategie zur Qualitäts -sicherung. Der beschriebene Ansatz für ver-ständliche, automatisierte Systemtests hatsich in mehreren Projekten als überauspraktikabel erwiesen. Dabei ist dieTestautomatisierung nur ein Teil derVorteile des Ansatzes. Mindestens genausowertvoll ist die gemeinsame Testfallent -wicklung und das damit verbundenegemeinsame Verständnis der Anfor derun -gen bei Fachseite und Entwicklung. ■

4Online-Themenspecial Testing 2013

Online-Themenspecial Testing 2013 advertorial

Abb. 3: Reportszenario – Status.

Referenzen

[Bec04] K. Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley, 2004.

[Coc00] A. Cockburn, Writing Effective Use Cases, Addison-Wesley, 2000.

[Cuc] Cucumber, siehe http://cukes.info.

[Fow10] M. Fowler, R. Parsons, Domain Specific Languages,Addison-Wesley, 2010.

[Fre10] S. Freeman,N. Pryce, Growing Object-Oriented Software, Guided By Tests, Addison-

Wesley, 2010.

[Git] Cucumber-JVM, siehe https://github.com/cucumber/cucumber-jvm.

[Hum10] J.Humble, D. Farley, Continuous Delivery: Reliable Software Releases through Build,

Test, and Deployment Automation, Addison-Wesley, 2010.

[Nor06] D. North, Introducing BDD, Better Software Magazin, 2006.

[Pag] Page Object Pattern, siehe https://code.google.com/p/selenium/wiki/PageObjects.

[Sch01] K. Schwaber, M. Beedle, Agile Software Development with Scrum, Prentice Hall, 2001.

[Spe] SpecFlow, siehe http://www.specflow.org/specflownew/.