Success Story: Modellhafte Verbesserung in einer Testabteilung

Durch Nut­zung der Model­lie­rung in der Model­lie­rungs­no­ta­ti­on UML kön­nen kom­ple­xe Zusam­men­hän­ge struk­tu­riert dar­ge­stellt wer­den. Die sonst umständ­lich in Spra­che zu fas­sen­den Bedin­gun­gen und Vor­aus­set­zun­gen kön­nen in der visua­li­sier­ten Logik, z. B. in beschrei­ben­den Kno­ten und die Kno­ten ver­bin­den­den Kan­ten hin­ter­legt werden.

Die­se Logik kann durch geeig­ne­te Algo­rith­men durch­lau­fen und abge­prüft wer­den, sodass dar­aus auto­ma­tisch Test­fäl­le erzeugt wer­den kön­nen. Aus der gro­ßen Anzahl von Werk­zeu­gen, die eine Model­lie­rung in UML2 erlau­ben, wur­de „Enter­pri­se Archi­tect“ von Sparx­Sys­tems aus­ge­wählt. In Enter­pri­se Archi­tect kön­nen Requi­re­ments eben­so wie das dyna­mi­sche Ver­hal­ten eines zu tes­ten­den Sys­tems model­liert und ver­knüpft wer­den. Die­se Model­le wer­den für die Gene­rie­rung der Test­fäl­le und Test­da­ten verwendet.

Zum Ein­satz kommt bei Siemens ein Algo­rith­mus (sie­he [OSS07] und [PSO08]), der in Zusam­men­ar­beit mit der Uni­ver­si­tät Erlan­gen-Nürn­berg als For­schungs­pro­jekt der High­tech-Offen­si­ve Zukunft Bay­ern für den Ein­satz zur Test­fall- und Test­da­ten­ge­ne­rie­rung aus UML-Model­len ent­wi­ckelt wur­de. Die­ser soge­nann­te „gene­ti­sche“ Algo­rith­mus basiert auf Erkennt­nis­sen der bio­lo­gi­schen Ver­er­bungs­leh­re, nach der sich für vor­ge­ge­be­ne Umwelt­be­din­gun­gen beson­ders gut geeig­ne­te gene­ti­sche Eigen­schaf­ten wei­ter ver­er­ben und durch­set­zen. Die Über­tra­gung die­ses Mecha­nis­mus führt dazu, dass aus­ge­hend von einem ers­ten Satz von Test­fäl­len mit Test­da­ten wei­te­re Inkre­men­te erzeugt wer­den, die jeweils die „Gut“-Kriterien für Test­fäl­le mit in die nächs­te Ite­ra­ti­on wei­ter „ver­er­ben“ und damit die gewünsch­ten Kri­te­ri­en erreicht wer­den. Als Haupt­kri­te­ri­en die­nen hier die Maxi­mie­rung der Test­ab­de­ckung bei Mini­mie­rung des Testaufwands.

Mit die­ser auto­ma­ti­sier­ten Opti­mie­rungs­stra­te­gie hebt sich der „gene­ti­sche Algo­rith­mus“ von den bis­her ver­wen­de­ten Metho­den in ande­ren am Markt erhält­li­chen Sys­te­men zur Test­ge­ne­rie­rung ab: In jenen muss der Anwen­der aus einer Aus­wahl mög­li­cher Stra­te­gien (z. B. gewünsch­ter Abde­ckungs­grad aller Test­fäl­le oder aber Aus­wahl von mög­li­chen Pfa­den über Kno­ten und Kan­ten) selbst über die Opti­mie­rungs­mög­lich­kei­ten ent­schei­den und die­se ggfs. in meh­re­ren Inkre­men­ten vor­neh­men. Mit dem „gene­ti­schen Algo­rith­mus“ wird dage­gen sehr effek­tiv ein mög­lichst opti­ma­ler Satz an Test­fäl­len erzeugt.

Die­se Test­fäl­le kön­nen in belie­bi­gen For­ma­ten expor­tiert wer­den, sowohl in Text­form für eine manu­el­le Durch­füh­rung als auch für die auto­ma­ti­sche Durch­füh­rung als Skript. Im kon­kre­ten Anwen­dungs­fall wer­den die Test­fäl­le direkt in das Test­ma­nage­ment-Werk­zeug „Qua­li­ty Cen­ter“ von Hew­lett Packard geschrie­ben, da die­ses in die­ser Abtei­lung bei Siemens ver­wen­det wird. Am Ende der Ein­füh­rung der Model­lie­rung arbei­te­ten 5 der 13 Team­mit­glie­der an der Model­lie­rung und hat­ten erkannt und akzep­tiert, dass für alle die neue Metho­de einen Vor­teil bringt.

Das ist eine wesent­li­che Vor­aus­set­zung für die erfolg­rei­che Ein­füh­rung: Alle müs­sen die­se von sich aus ein­set­zen wol­len, es muss ein „Selbst­läu­fer“ wer­den. Wur­den in einem ers­ten Pro­jekt in der betrach­te­ten Siemens-Abtei­lung zunächst 10 Pro­zent der zu tes­ten­den Anfor­de­run­gen in 25 Model­len erstellt, so wur­den die­se für das dann erfolg­reich durch­ge­führ­te Pro­jekt auf 40 Pro­zent oder 29 Model­le aus­ge­wei­tet und damit 50 Pro­zent aller Test­fäl­le (in Sum­me 151) auto­ma­tisch erzeugt.

1. In Requi­si­te Pro gesam­mel­te und ver­wal­te­te Requi­re­ments wer­den auto­ma­tisch mit dem HP Qua­li­ty Cen­ter abgeglichen.
2. Die Requi­re­ments wer­den für ein aus­ge­wähl­tes The­ma auto­ma­tisch in das UML-Modell impor­tiert und kön­nen dann vom Model­lie­rer im Modell ver­linkt werden.
3. Die erstell­ten Model­le wer­den aus Enter­pri­se Archi­tect expor­tiert und von MBT­suite ein­ge­le­sen. Dar­aus wer­den nach vor­ge­ge­be­nen Abde­ckungs­kri­te­ri­en auto­ma­tisch Test­fäl­le mit zuge­hö­ri­gen Test­da­ten erzeugt.
4. Die­se Test­fäl­le wer­den eben­so auto­ma­tisch ins HP Qua­li­ty Cen­ter geschrie­ben und ste­hen mit Ver­lin­kung zu den Anfor­de­run­gen für die Test­pla­nung und ‑durch­füh­rung zur Verfügung.
5. Die Ver­bin­dung zwi­schen Requi­si­te Pro und dem HP Qua­li­ty Cen­ter macht es mög­lich, Test­fäl­le und deren Durch­füh­rung mit den Test­ergeb­nis­sen den ursprüng­li­chen Anfor­de­run­gen zuzuordnen.

1. In Requi­si­te Pro gesam­mel­te und ver­wal­te­te Requi­re­ments wer­den auto­ma­tisch mit dem HP Qua­li­ty Cen­ter abgeglichen.
2. Die Requi­re­ments wer­den für ein aus­ge­wähl­tes The­ma auto­ma­tisch in das UML-Modell impor­tiert und kön­nen dann vom Model­lie­rer im Modell ver­linkt werden.
3. Die erstell­ten Model­le wer­den aus Enter­pri­se Archi­tect expor­tiert und von MBT­suite ein­ge­le­sen. Dar­aus wer­den nach vor­ge­ge­be­nen Abde­ckungs­kri­te­ri­en auto­ma­tisch Test­fäl­le mit zuge­hö­ri­gen Test­da­ten erzeugt.
4. Die­se Test­fäl­le wer­den eben­so auto­ma­tisch ins HP Qua­li­ty Cen­ter geschrie­ben und ste­hen mit Ver­lin­kung zu den Anfor­de­run­gen für die Test­pla­nung und ‑durch­füh­rung zur Verfügung.
5. Die Ver­bin­dung zwi­schen Requi­si­te Pro und dem HP Qua­li­ty Cen­ter macht es mög­lich, Test­fäl­le und deren Durch­füh­rung mit den Test­ergeb­nis­sen den ursprüng­li­chen Anfor­de­run­gen zuzuordnen.

Dadurch ent­stand eine geschlos­se­ne Werkzeugkette:

Für den Test von syngo.via wur­den 50 Pro­zent aller Test­fäl­le mit­hil­fe der neu­en Metho­de .mzT und Nut­zung des Werk­zeu­ges MBT­suite erzeugt. Es konn­te die­sel­be Rate gefun­de­ner Feh­ler wie beim her­kömm­li­chen Vor­ge­hen ermit­telt wer­den. Die Kos­ten dafür waren für den betrach­te­ten Ein­füh­rungs­zeit­raum nahe­zu gleich. Damit ergibt sich jetzt, da sich der Pro­zess eta­bliert, die Erwar­tung, dass sich der Auf­wand auf der Grund­la­ge zuneh­men­der Erfah­rung signi­fi­kant redu­zie­ren wird. Wich­ti­ge, bereits jetzt mehr­fach gemach­te posi­ti­ve Erfah­run­gen, sind klar erkennbar.

Die visu­el­le Dar­stel­lung des zu tes­ten­den Sys­tems in einem über­sicht­li­chen und struk­tu­rier­ten Modell ermög­licht es schon lan­ge vor der Aus­füh­rung der Tests, Feh­ler in der Spe­zi­fi­ka­ti­on zu erken­nen und sich weit­aus bes­ser inner­halb eines welt­weit koope­rie­ren­den Teams zu verständigen.

Die Kom­mu­ni­ka­ti­on mit den Ent­wick­lern wird ein­fa­cher, da sich bei­de Sei­ten auf der Ebe­ne der logi­schen Abbil­dung schnel­ler ver­ste­hen kön­nen, als dies durch eine unüber­sicht­li­che Pro­sa mög­lich wäre. Die erzeug­ten Model­le sind bes­ser anpass­bar und dadurch nach einer Ände­rung schnel­ler wie­der­zu­ver­wen­den. Reviews der erstell­ten Test­sze­na­ri­en müs­sen nicht durch ermü­den­des Durch­le­sen dut­zen­der Sei­ten oder unüber­sicht­li­cher Tabel­len durch­ge­führt wer­den, son­dern durch gemein­sa­mes Durch­ge­hen einer model­lier­ten und auf einem Bild ersicht­li­chen Logik.

Eine gefor­der­te Test-Abde­ckung kann auf Modell­ebe­ne durch den Ein­satz der MBT­suite selbst­ver­ständ­lich nach­ge­wie­sen werden.

Der oben beschrie­be­ne Infor­ma­ti­ons­aus­tausch über die Anwen­dung der neu­en Metho­de in dafür spe­zi­ell ein­ge­rich­te­ten Bespre­chun­gen wird über die Ein­rich­tung eines „Wiki’s“ insti­tu­tio­na­li­siert. Tipps, Tricks, Erfah­run­gen und wich­ti­ge Neu­ig­kei­ten rund um das The­ma Modell­ba­sier­ter Test@MR kön­nen ins Intra­net ein­ge­stellt und auch dort gele­sen wer­den. In einem nächs­ten Schritt soll auch der Key­word-dri­ven Test über MBT ermög­licht werden.

Eine span­nen­de Erwei­te­rung ist durch die Anwen­dung des MBT in der agi­len Ent­wick­lung vor­ge­se­hen. Dabei kön­nen nach einem gemein­sa­men Start von Ent­wick­lung und Test­mo­del­lie­rung für ein­zel­ne Sprints letz­te­re leicht für den nächs­ten Sprint ange­passt und erwei­tert wer­den. Test­fäl­le wer­den schnell für jedes Inkre­ment und jeden Sprint erzeugt.

Im Pro­jekt wur­de erfolg­reich der „gene­ti­sche Algo­rith­mus“ ein­ge­setzt, um 100% Abde­ckung bei mini­ma­lem Test­auf­wand zu errei­chen. Mit der aktu­ells­ten Ver­si­on der MBT­suite ste­hen vie­le wei­te­re Stra­te­gien zur Test­fall­ge­nerie­rung zur Ver­fü-gung. Mit „Full­path“ wer­den bei­spiels­wei­se zunächst alle mög­li­chen Test­fäl­le erzeugt und kön­nen anschlie­ßend unter zu Hil­fe nah­me von Fit­ler­me­cha­nis­men auf das opti­ma­le Maß redu­ziert wer­den. Es wer­den ver­schie­dens­te Mög­lich­kei­ten zur Ver­fü­gung gestellt , das opti­ma­le Test-Set für den jewei­li­gen Bedarf zu erstel­len. Zusätz­lich wer­den erfor­der­li­che Test­da­ten auto­ma­tisch gene­riert und eine Requi­re­ments-Abde­ckungs­ma­trix angeboten.