Sie befin­den sich hier:Start­sei­te/Blog/Dev­Ops und Modell­ba­sier­tes Tes­ten als Effizienz-Turbo

DevOps und Modellbasiertes Testen als Effizienz-Turbo

Lese­zeit: 9 Minu­ten
continious integration 1 socialshare

Testing per Knopfdruck

Die meis­ten Unter­neh­men haben mitt­ler­wei­le erkannt, dass sich durch Ver­ein­fa­chung und Auto­ma­ti­sie­rung der Abläu­fe in Software­entwicklung und Deploy­ment vie­le Vor­tei­le erzie­len las­sen. Die Effi­zi­enz kann deut­lich gestei­gert wer­den, die Time-To-Mar­ket und Release-Zyklen wer­den immer wei­ter ver­kürzt, die Häu­fig­keit von Feh­lern wird stark redu­ziert und nicht zuletzt haben die Mit­ar­bei­ter mehr Spaß bei der Arbeit. Die Lis­te lie­ße sich noch lan­ge fort­set­zen. Zusam­men­ge­fasst wird die­ses Phä­no­men unter dem Namen „Dev­Ops“.

Im Bereich der Qua­li­täts­si­che­rung, ins­be­son­de­re im Test­de­sign, klafft der­zeit aber noch eine Lücke in Bezug auf die Auto­ma­ti­sie­rung. Auch im „DevOps“-Prozess wer­den Test­fäl­le noch von Hand ent­wor­fen und imple­men­tiert. Zwar wer­den sie in der Regel auto­ma­tisch durch­ge­führt, oft sind sie aber nicht aktu­ell, son­dern hin­ken der Ent­wick­lung hinterher.

Die erstell­ten Test­fäl­le fin­den dann übli­cher Wei­se erst in der dar­auf­fol­gen­den Test­pha­se Ver­wen­dung. Dem heu­te eigent­lich obli­ga­to­ri­schen Dev­Ops-Ansatz ent­spricht die­se Vor­ge­hens­wei­se aller­dings bei wei­tem nicht. Mit Dev­Ops soll­te es kei­nen zeit­li­chen Ver­satz zwi­schen aktu­el­lem Ent­wick­lungs­stand und Stand der Test­spe­zi­fi­ka­tio­nen geben. Auch soll­te es kei­ne vom Rhyth­mus der Ent­wick­lung unab­hän­gi­gen Test­pha­sen geben: Alle Vor­gän­ge soll­ten naht­los inein­an­der­grei­fen, am bes­ten per Knopf­druck. Alles ist auf dem glei­chen Stand, alles ist zusam­men­hän­gend gespei­chert, es gibt einen „Sin­gle Point Of Truth“!

Mit dem modell­ba­sier­ten Ansatz steht hier­für schon seit gerau­mer Zeit eine Metho­de zur Ver­fü­gung, auch die Test­fall­erstel­lung zu auto­ma­ti­sie­ren und in einen auto­ma­ti­schen Build-Pro­zess ein­zu­bin­den. Bei die­sem Ansatz wer­den gra­phi­sche Model­le ver­wen­det, um das Test­vor­ge­hen zu unter­stüt­zen. Ähn­lich wie im Beha­viour Dri­ven Deve­lo­p­ment wer­den die Erwar­tun­gen an das zu ent­wi­ckeln­de Sys­tem mit sämt­li­chen rele­van­ten Sze­na­ri­en in einem Ablauf­mo­dell beschrie­ben. Die gra­phi­sche Nota­ti­ons­form der Model­le erlaubt es, bei der Erstel­lung der Anwen­dungs­sze­na­ri­en auch den Pro­duct Owner, Requi­re­ment Engi­neers und Ent­wick­ler mit ein­zu­be­zie­hen und somit einen Mehr­wert nicht nur für den Test zu schaf­fen. Die Model­le die­nen also nicht nur der Defi­ni­ti­on des Test­vor­ge­hens, son­dern auch als Input für die Ent­wick­ler und als Kom­mu­ni­ka­ti­ons­me­di­um im gesam­ten Entwicklungsprozess.

testprozess

Abb. 1: vom Modell zum Testfall

Die auto­ma­ti­sche Gene­rie­rung der Test­fäl­le aus dem Modell kann ent­we­der manu­ell ange­sto­ßen wer­den, oder – eine geeig­ne­te Tool-Ket­te vor­aus­ge­setzt – in den auto­ma­tisch ablau­fen­den CI Pro­zess inte­griert wer­den. Aus Sicht der Qua­li­täts­si­che­rung bie­tet sich damit die Mög­lich­keit, die Tests syn­chron mit der Ent­wick­lung zu hal­ten, da die Test­mo­del­le ohne gro­ßen Auf­wand par­al­lel zum Fort­schritt in der Ent­wick­lung wei­ter­ent­wi­ckelt wer­den können.

Dar­ge­stellt ist die­ses Ver­fah­ren in Abb. 2. Tes­ter und Ent­wick­ler sit­zen im sel­ben Boot – Modell und Code wer­den pas­send zuein­an­der in das Repo­si­to­ry geschrie­ben und auto­ma­tisch vom CI-Ser­ver wei­ter­ver­ar­bei­tet: Der Code wird gebaut, die Test­fäl­le wer­den auto­ma­tisch (aus dem Modell) gene­riert und die Tests wer­den ausgeführt.

automatisierungstoolchain

Abb. 2: Ein­bin­dung des Test­fall­ge­ne­ra­tors in die Automatisierungs-Toolchain

sepp.med hat die­sen Ansatz in sei­ner CI Tool-Ket­te umge­setzt. Begin­nend mit der Über­nah­me der ein­zel­nen Tasks aus dem Back­log wer­den par­al­lel zur Ent­wick­lung Test­mo­del­le erstellt und wei­ter­ge­pflegt, wobei syn­chron zur Ent­wick­lung Test­mo­del­le zu den aktu­el­len neu­en Fea­tures ent­ste­hen bzw. Ände­run­gen Ein­gang in das Test­de­sign fin­den. Damit und mit der auto­ma­ti­schen Test­fall­ge­ne­rie­rung aus den Model­len ist es dann mög­lich, auch im CI-Ablauf die Test­fäl­le auto­ma­tisch zu erstel­len bzw. anzu­pas­sen und aus­zu­füh­ren. Die MBT­sui­te, das modell­ba­sier­te Tes­ting­frame­work der sepp.med gmbh, kann seit eini­ger Zeit in die Dev­Ops Tool­chains inte­griert wer­den und schließt so die Lücken der Test­fall­erstel­lung in der DevOps-Welt.

Die Diens­te wer­den durch ein API zur Ver­fü­gung gestellt. Dies ermög­licht die Ein­bin­dung des Test­fall­ge­ne­ra­tors in Auto­ma­ti­sie­rungs-Tool­chains, zum Bei­spiel in einen Con­ti­nuous Inte­gra­ti­on- bzw. Con­ti­nuous Deploy­ment Pro­zess. Durch die offe­ne XML-RPC-Schnitt­stel­le kön­nen die Diens­te von den unter­schied­lichs­ten Tools aus ange­steu­ert wer­den. Bei sepp.med wird Jenkins ein­ge­setzt. Durch eine klei­ne Anpas­sung in Jenkins (Bei­spiel-Code sie­he unten) wur­de die Ver­bin­dung mit der MBT­sui­te hergestellt.

ciumgebung

Abb. 3: sepp.med CI-Umgebung

In Abb. 3 ist die ver­wen­de­te Werk­zeug­ket­te dar­ge­stellt. Sowohl der Pro­gramm­code also auch die Test­mo­del­le wer­den in ein gemein­sa­mes git-Repo­si­to­ry abge­legt. Im Sin­ne von Con­ti­nuous Inte­gra­ti­on soll­ten dabei Pro­gramm­code und Test­mo­dell immer auf dem glei­chen Stand gehal­ten wer­den. Am Jenkins-Build­ser­ver wird danach nicht nur der Code gebaut, son­dern auch aus dem Test­mo­dell die aktu­el­len Test­fäl­le gene­riert. Im Anschluss wer­den die Test­fäl­le auto­ma­tisch aus­ge­führt. Bei erfolg­rei­cher Test­aus­füh­rung kann ein Deploy­ment der in Nexus abge­leg­ten Build-Arte­fak­te stattfinden.

Die­se Vor­ge­hens­wei­se hat kla­re Vor­tei­le. Wird bei­spiels­wei­se ein neu­es Fea­ture ent­wi­ckelt, so wird nicht nur der geän­der­te Pro­gramm­code in die Inte­gra­ti­ons­pipe­line geschickt, son­dern auch die ange­pass­ten Test­mo­del­le. Die Arbei­ten an den Test­fäl­len und die Ent­wick­lung der Soft­ware fin­den also im glei­chen Rhyth­mus statt. Gleich­zei­tig wird durch das Erstel­len der Test­mo­del­le die Test­bar­keit der Anfor­de­run­gen sicher­ge­stellt und ein ein­heit­li­ches Ver­ständ­nis über die Anfor­de­run­gen hergestellt.

Es müs­sen kei­ne Test­pha­sen mehr koor­di­niert wer­den und der Abgleich ver­schie­de­ner Stän­de von Test­spe­zi­fi­ka­ti­on und Ent­wick­lungs­stand erüb­rigt sich. Die Gene­rie­rung der Test­fäl­le, die Test­aus­füh­rung und das Repor­ting kön­nen kom­plett auto­ma­tisch pas­sie­ren. Dies führt nicht nur zu Effi­zi­enz­stei­ge­run­gen und Ver­ein­fa­chun­gen auf tech­ni­scher, son­dern auch, und viel wich­ti­ger noch, auf der Ebe­ne zwi­schen­mensch­li­cher Kooperation.

Einen wesent­li­chen Bei­trag lie­fern hier­zu die Test­mo­del­le, da sie neue Fea­tures ein­deu­tig und klar beschrei­ben wer­den und Miss­ver­ständ­nis­se zwi­schen den Akteu­ren vermieden.

Dadurch, dass Test­de­si­gner und Ent­wick­ler den glei­chen Rhyth­mus leben, wach­sen sie näher zusam­men, kom­mu­ni­zie­ren bes­ser und koope­rie­ren enger.

Bei sepp.med ver­wen­det das MBT­sui­te-Ent­wick­lungs­team sein eige­nes Pro­dukt, um Test­fäl­le wie oben beschrie­ben auto­ma­tisch zu gene­rie­ren und dann aus­zu­füh­ren. Tes­ter, Deve­lo­per und Pro­duct Owner wir­ken im agi­len Ablauf eng zusam­men. Das Team arbei­tet nach Kan­ban und ver­sucht, mög­lichst häu­fig aus­lie­fer­ba­re Stän­de zu errei­chen. Durch die per­ma­nen­te Syn­chro­ni­sa­ti­on von Pro­dukt­code und Test­mo­dell sowie die auto­ma­ti­sche Gene­rie­rung und Aus­füh­rung der Test­fäl­le wird die­ses Ziel opti­mal unterstützt.

Mit die­sem Vor­ge­hen konn­te sepp.med die Ent­wick­lung deut­lich beschleu­ni­gen und gleich­zei­tig die Qua­li­tät der Pro­duk­te nach­hal­tig ver­bes­sern. Kon­kret wur­de fol­gen­der CI Pro­zess realisiert:

ciprozessmittestfallgenerierung

Abb. 4: sepp.med CI Pro­zess mit Testfallgenerierung

Aus dem Ticket­sys­tem wer­den die Tasks ent­nom­men und zunächst als Test­mo­dell umge­setzt, um die Test­bar­keit sicher zu stel­len und eine ein­heit­li­che Sicht auf das neue Fea­ture bezie­hungs­wei­se des­sen Impli­ka­tio­nen auf das Gesamt­sys­tem her­zu­stel­len. Tri­via­le Tickets kön­ne natür­lich direkt zu einem oder weni­gen Test­fäl­len umge­setzt wer­den. Wird der CI Pro­zess durch einen Com­mit ange­sto­ßen, wer­den zuerst die aktu­el­len Model­le ver­wen­det um ein geeig­ne­tes Test­set zu erzeu­gen. Die­ses wird dann im „nor­ma­len“ CI Pro­zess genutzt.

Abschlie­ßend möch­ten wir anhand eines ein­fa­chen Code-Bei­spiels in der Skript­spra­che groo­vy zei­gen, wie die Test­fall­ge­ne­rie­rung in den CI Pro­zess inte­griert wer­den kann.

Zunächst wird das XML-RPC Libra­ry zur Fern­steue­rung der MBT­sui­te in das groo­vy Skript impor­tiert. Es wird benö­tigt, um auf den Ser­vice der MBT­sui­te zuzu­grei­fen. Danach wird die Klas­se Remo­te­Con­trol­ler defi­niert, die in den wei­te­ren Schrit­ten mit Inhalt gefüllt wird:

In die Zwi­schen­ab­la­ge kopieren

Die Klas­se Remo­te­Con­trol­ler benö­tigt zwei Instanz­va­ria­blen: Die mbt­sui­te spei­chert den MBT­sui­te-Pro­xy für den Remo­te­zu­griff, wäh­rend in mbt­sui­te Pro­cess die Refe­renz auf den eigent­li­chen MBT­sui­te Pro­zess gespei­chert wird. Die MBT­sui­te hört zudem stan­dard­mä­ßig auf Port 8600 auf Requests. Des­halb wird der in den Kon­struk­to­ren erzeug­te XML-RPC Pro­xy mit Port 8600 auf Local­host verbunden.

In die Zwi­schen­ab­la­ge kopieren

Außer­dem soll die MBT­sui­te lokal auf dem Rech­ner gestar­tet wer­den, um dann auf ihre Diens­te zuzu­grei­fen. Die Metho­de star­tet die MBT­sui­te, falls nicht schon eine Instanz der MBT­sui­te läuft. Danach kann durch Auf­ruf der Metho­de wait­ForStart solan­ge gewar­tet wer­den, bis die MBT­sui­te nach dem Start-Auf­ruf auf Anfra­gen reagiert. Erst dann steht der Remo­te-Ser­vice bereit:

In die Zwi­schen­ab­la­ge kopieren

Mit der Metho­de import­Mo­del­From­File kann das Modell in die MBT­sui­te gela­den wer­den. Das API stellt dafür die Funk­ti­on import­Mo­del zur Verfügung:

In die Zwi­schen­ab­la­ge kopieren

Aus dem impor­tier­ten Modell kön­nen dann mit ver­schie­de­nen Stra­te­gien Test­fäl­le erzeugt werden:

In die Zwi­schen­ab­la­ge kopieren

Die erzeug­ten Test­fäl­le kön­nen hier­nach in ver­schie­de­ne Ziel­for­ma­te und zu ver­schie­de­nen Tool expor­tiert wer­den. Wir haben uns hier­für die Metho­de run­Ex­port definiert:

In die Zwi­schen­ab­la­ge kopieren

Die Metho­de stop ver­wen­det die XML-RPC Funk­ti­on clo­se, um die MBT­sui­te sau­ber zu schließen:

In die Zwi­schen­ab­la­ge kopieren

Zum Schluss noch unse­re main-Metho­de, die alle Schrit­te der Rei­he nach auf­ruft. Wir star­ten die MBT­sui­te und impor­tie­ren das Modell aus der Datei Bllinking.xml. Danach füh­ren wir die FPC-Stra­te­gie aus, um die Test­fäl­le zu gene­rie­ren. Die gene­rier­ten Test­fäl­le wer­den in das HTML-For­mat expor­tiert und die MBT­sui­te wird wie­der beendet:

In die Zwi­schen­ab­la­ge kopieren

Mit Ein­füh­rung die­ses CI-Vor­ge­hens konn­ten wir unse­re Ent­wick­lungs­zy­klen deut­lich beschleu­ni­gen. Von vor­mals acht bis zehn Mona­ten pro Release konn­te die Zeit auf zunächst sechs und mitt­ler­wei­le zwei bis drei Mona­te ver­kürzt wer­den. Da der Test syn­chron zur Fea­ture-Ent­wick­lung gehal­ten ist, ent­fal­len län­ge­re Test­pha­sen am Ende der Entwicklungsphase.

Res­u­mée: Die Ent­wick­ler sind glück­lich, weil sie genau­er wis­sen, was sie ent­wi­ckeln sol­len – die Tes­ter sind glück­lich, weil der Test­stress am Ende entfällt.

Kommentare und Feedback gerne via Social Media:

Blei­ben Sie auf dem Lau­fen­den – mit dem monat­li­chen sepp.med Newsletter:

sepp.med News­let­ter abonnieren