Testmanagement im hybriden Umfeld Umgang mit dem Risiko

Transkript

1 Holger Kühl ( arbeitet als Berater für Qualitäts- ud Testmaagemet, Testmethodik ud Testprozessverbesserug für die Firma SySpace GmbH. Da er lage Zeit selbst als aktiver Tester mit diverser Software ud Testprozesse zu tu hatte, ka er auf eie reichhaltige Backgroud a praxisrelevater Erfahrug zurückgreife. Die Erfahruge auf dem Gebiet des Testes/Testmaagemets i Kombiatio mit seiem derzeitige wachsede Aufgabegebiet Prozessverbesserug i Softwareprojekte ach ISO (SPICE), CMMI ud ITIL gewährleiste eie gute Grudlage für Strategieetwickluge i de diverse Brache. Sei Iteresse liegt vor allem bei der Testprozessverbesserug ud dem methodische Teste. Z. B. uterstützt er mehrere Hybrid-Forschugsprojekte im Automotive-Bereich bei de Theme Testmaagemet, Testig ud Prozessverbesserug ach SPICE. Testmaagemet im hybride Umfeld Umgag mit dem Risiko Vo der Kaffeemaschie über de Flachbildferseher bis zum Auto ud zu mediziische Geräte - Software ist heute i alle Lebesbereiche allgegewärtig ud icht mehr wegzudeke. Immer kürzere Produktlebeszykle, die steigede Komplexität der Software ud die techische Neuetwickluge vo Produkte berge jedoch immer höhere Risike ud verlagt ei immer breiteres, fachliches Kow-how icht ur im Softwaretest. Der Softwaretest ud das übergeordete Testmaagemet sid hierbei oft die letzte Istaz, die eie fudierte Qualitätsbeurteilug abgebe ka ud soll. Die relativ juge Etwicklug des Hybridatriebs i der Automobilbrache ist ei Beispiel, das die aufgeführte Pukte als eue Herausforderug defiiert. Ei bewusster Umgag mit de Risike, Testaufwäde, aber auch Chace, ist gefragter de je. Eiführug ud Motivatio Testmaagemet, das heute i diverse IT- Projekte ud Brache agewedet ud umgesetzt wird, erfordert ei breites fachliches Wisse, Erfahrug ud oft geug auch Figerspitzegefühl bei der Umsetzug. Meist reicht jedoch das fachliche (Softwaretest-)Wisse alleie icht mehr aus, um das (Test-)Projekt erfolgreich durchzuführe. Gerade da, we eue Systeme etwickelt, Hard- ud Software als eie Eiheit/ System zusammegeführt ud getestet werde müsse. Der Begriff Hybrid stammt ursprüglich aus dem Griechische ( Hybrida ) ud heißt so viel wie etwas büdel, oder mische. I die Techikwelt übertrage, versteht ma daruter eie Kombiatio vo zwei Techologie, die zusammegeführt, etwas Neues ergebe. Hier soll die Mischtechologie Hybridatrieb beim Auto (Verbreugsmotor ud Stromatrieb kombiiert), am Beispiel der Lithium-Ioe Hybrid Batterie, als ei Vertreter aus diesem Bereich geomme werde. Das Schlagwort Hybrid ud die damit verbudee, eue techische Etwickluge z. B. i der Automobilbrache, gewie immer mehr ud mehr a wirtschaftlicher Bedeutug. Die Auswirkuge dieser eue Techologie, wie sie im Softwaretest ud Testmaagemet wahrgeomme werde, verlage auch ach eiem Blick über de Test-Tellerrad, was im Folgede verdeutlicht werde soll. Dieser Artikel erhebt icht de Aspruch auf Themevollstädigkeit beim Umgag mit diesem Thema. Vielmehr soll dieser eue Aspekte zum Umgag mit der eue hybride Techik ud dem damit verbudee Testmaagemet gebe, um die heutige Vorgehesweise im Softwaretest bzw. Testmaagemetbereich zu überdeke ud ggf. de eue Aforderuge im hybride Umfeld azupasse. Im Folgede solle, am Beispielprojekt eies Batteriesteuergeräts für die Lithium-Ioe Batterie, die Projekt- Erfahruge (Lessos leared) im Bezug auf das Testmaagemet dargestellt werde. Ausgagspukt Batteriesteuergerät, uklare Aforderuge ud eue Etwicklugsmethode Uklare Aforderuge, uklare Testfälle ud Testedekriterie Die Software für das Batteriesteuergerät muss die defiierte Aforderuge erfülle. Der Softwaretest prüft die korrekte Umsetzug dieser Aforderuge ahad vo kokrete Testfälle ud Testedekriterie. Er deckt eierseits Etwicklugsud Programmierfehler, aber ggf. auch fehlede oder falsche Aforderuge auf. Mit fehlede Aforderuge ist icht die kokrete Aforderug gemeit! Vielmehr wird durch die verschiedee Teststufe (z.b. beim Systemtest) ud Testmethode (z.b. Exploratives Teste) häufig die Uvollstädigkeit aufgedeckt. Diese schlägt sich da durch die Hitertür, i Form vo Äderugsafrage (Chage Requests), bis zur Nachdokumetatio i der Spezifikatio durch. Wobei i der Praxis die Abgrezug zwische eiem Chage ud eier fehlede Aforderug oft schwer zu ziehe ist. Die Testfälle sid letztlich die Grudlage für die Validierug der Software etlag der Kudeaforderuge. I der Praxis sid diese Aforderuge jedoch meist uvollstädig, ikosistet oder gar icht vorhade/dokumetiert, was ei fudiertes Testmaagemet ud die zu defiierede Testaktivitäte erschwert. Zum Teil liegt das mit a der och recht juge modellbasierte Etwicklug (siehe ute), die dazu verleitet, relativ schell vorzeigbare Resultate zu etwickel ud diese gleich im ächste Schritt zu teste. Ist 1

2 Olie-Ausgabe Testig 2009 Abb. 1: Beispiel eies Matlab/Simulik/Stateflow Modells das Etwicklugsziel icht klar defiiert, trete frühzeitig techische ud fachliche Probleme ud Frage auf, für die es och keie kokrete Atworte gibt, so sid Aforderuge bzw. ei defiierter Prozess zur Erhebug schell ei Ballast, der gere mal über Bord geworfe wird. Somit liest ma i Spezifikatioe das TBD (to be defied) recht häufig astelle eier kokrete Aforderug. Die Aforderuge ud dere Relevaz, gerade bezoge auf die System- ud Abahmetestkriterie, köe so schell i de Hitergrud trete. Auf eier istabile Aforderugsbasis verlässliche Testedekriterie (d.h. Wa ist der Test beedet? ) zu defiiere, ist gleichfalls schwierig. Modellbasierte Etwicklug ud Teste Die modellbasierte Etwicklug hält immer mehr Eizug i die Softwareetwicklug für Steuergeräte i der Automobilidustrie ud scheit immer mehr die altgediete Programmiersprache, wie z. B. C abzulöse. Die Etwicklugsweise ud Möglichkeite der modellbasierte Etwicklug sid sicherlich mit ei Grud, warum sich icht ur Igeieure i der vo Schaltkreise ud Sigalfluss-Modelle geprägte Etwicklugswelt wohlfühle. Die Möglichkeit, auf Kopfdruck Code zu geeriere ud diese automatisch zu implemetiere ud zu teste, kommt icht ur der Dek-weise ud de igeieursmäßige Lösugsasätze zu Gute. Mithilfe vo etsprechede Werkzeuge, wie z. B. Matlab/Simulik/Stateflow (s. Abbildug 1), ka die Software bzw. die Modelllogik bereits früh simuliert (MIL) ud auf Stimmigkeit geprüft werde. Die Möglichkeit eier iterative Etwicklugsweise erlaubt eie begleitede, dyamische Prüfug der Modelle auf Kopfdruck. Wobei Regressiostests ud Back-to-Back-Tests gezielte Versiosvergleiche ermögliche. Die Frage ach der Dokumetatio lässt sich ebeso durch Tools (ageblich!) sicherstelle, wobei das Modell eimal als Spezifikatio, Testobjekt oder zur Modellverifikatio ud als Validierugsgrudlage diee ka. D. h., die Testfälle ud die beötigte Testdate werde direkt aus dem Modell selbst abgeleitet. Diet das Testobjekt (z. B. eie Fuktio, Applikatio, System etc.) als Referez resp. für de Test ud die Testergebisse ud werde die Testfälle icht vo de Aforderuge, soder vom Testobjekt selbst abgeleitet, da ist der aschließede Soll-Ist-Vergleich ahad der Testergebisse mehr als fragwürdig. Das Risiko, a de Aforderuge vorbei zu etwickel ud zu teste, ist hierbei icht zu uterschätze, vo de ebefalls icht eruierte Risike, wie z. B. Systemrobustheitslücke ud fuktioale Soderlocke ud dere Testabdeckug bzw. Auswirkuge gaz abgesehe. Umfagreiche Parametrisierugsmöglichkeite Eie fuktioelle Eigeschaft des Batteriesteuergeräts bzw. der Steuerugssoftware für eie Lithium-Ioe-Batterie ist die komplexe Parametrisierugsmöglichkeit vo diverse Systemfuktioe ud dere Ei- oder Ausgabe-Sigale. Lade ud Etlade der Batterie, Strom ud Spaug i Abhägigkeit vo uterschiedliche Betriebstemperature, sid beim Betrieb der Batterie u. a. zu berücksichtige ud laufed zu messe. Die gemessee Werte/ Sigale müsse vorab i ihre Greze defiiert, i Beziehug zueiader gesetzt ud aschließed ausgewertet werde. Dadurch ergebe sich eie Fülle vo Kombiatiosmöglichkeite ud abzuleitede Testfälle ierhalb der Steuerugslogik. Das Risiko, die wichtige Testfälle zu übersehe oder icht auszuführe, steigt damit proportioal. Die Abbildug 2 soll diese Komplexität am Beispiel eier Etscheidugstabelle für verschiedee Systemfuktioe ud dere Sigale veraschauliche. Solle die komplexe Fuktioalität, die Risike ud die damit verbudee Mege a Testfälle möglichst umfassed ud wiederholt (Regressiostest) getestet werde, so ist eie automatisierte Testausführug ahe lieged. Aber ohe eie defiierte Testprozess ud ohe eie fudierte Risikoaalyse ist eie effiziete Testautomatisierug oft zum Scheiter verurteilt. Fuktioelle Sicherheit (FuSi) ud die Auswirkuge auf de Test Fuktioelle Sicherheit (kurz FuSi geat) ist eies der wichtige Sicherheitstheme bei der Etwicklug hybrider Systeme, wie z. B. eies Batteriesteuergeräts für die Lithium-Ioe-Batterie ud dere elektrisch/elektroischer Kompoete. Mögliche Fehlfuktioe sid hier besoders grüdlich zu betrachte ud dere Auswirkuge/Risike zu aalysiere. Droht die Batterie zu überhitze oder sogar zu explodiere, greife eigeleitete Gegemaßahme oft zu spät. Eie vorab durchgeführte Risikoaalyse ist hier icht ur otwedig, soder rettet sogar Leib ud Lebe. Aufgrud dieser sesible Techik sid somit auch physikalische ud chemische Ketisse der Batterie für de Testmaager vo Vorteil. Diese helfe ihm, die Testfälle ach Risiko zu priorisiere, Stadards azuwede ud die geeigete Testmethode auszuwähle. Die Hybridbatterie als komplettes System, als Gazes zu verstehe ud die Sicherheitsaforderuge besser eizuorde, ist letztlich auch für de Softwaretest ud die Testplaug etscheided. Der Testmaager muss diese Sicherheitsaspekte kee ud berücksichtige, damit die Softwaretests icht a diese vorbei laufe. Die ISO gibt Hilfestellug bei der Risikoaalyse des Systems ud de kokrete Test-Methode der fuktioale Sicherheit (FuSi). Eie aschließede Testautomatisierug ka somit auf ei festes (Test-)Fudamet gestellt ud risiko- ud fuktiosorietiert geplat ud durchgeführt werde. Olie-Ausgabe Testig

3 Abb. 2: Beispiel der komplexe Parametrisierugsmöglichkeit auf Basis eier Etscheidugstabelle Was ist das System ud was bedeutet Fuktioale Sicherheit? Dabei ist erst eimal vorab zu kläre, was uter FuSi ud eiem System zu verstehe ist. Als Defiitioshilfe für eie eiheitliche Systembegriff et die ISO das Item (z.b. eie Fahrzeugfuktio, Steuergerät, Bauteil etc.). Die ISO 26262, die z. Z. och de Status eies DIS (Draft Iteratioal Stadard) hat ud somit och icht fial verabschiedet ist, et kokrete Vorgabe für die Testmethode je ach ASIL-Level (Sicherheitsaforderugsstufe). Trotz Draft-Versio ka ma das dari gesammelte Kow-how für eie Testpriorisierug utze. Grudsätzlich richtet sich die ISO a ei fuktioal sicheres ud korrekt arbeitedes System letztlich ei Produkt, das aus elektrisch/elektroische Kompoete besteht. Wobei mit System sowohl Hard- als auch Software gemeit ist. FuSi betrachtet letztlich ei mögliches fehlerhaftes Verhalte, eie Ausfall oder ei Versage des Systems oder eizeler Systemkompoete. Ei fehlerhaftes Verhalte oder komplette Systemausfälle köe z. B. durch Etwicklugs- oder Programmierfehler ausgelöst werde. Für de Test ud das Testmaagemet bedeutet dies, de 3 potezielle Schade bzw. die Risike vorab zu lokalisiere ud mit eier defiierte (z. B. risikobasierte)teststrategie gezielt zu reduziere. Mithilfe eier Risikoaalyse ud auf de Ergebisse abgestimmte risikobasierte Teststrategie ist es möglich, de Test ihaltlich mit kokrete Testmethode ud Aktivitäte zu fülle. Systemrisike Uterschiedliche Sichtweise auf ei System berücksichtige Ist der Systembegriff defiiert, das System i seie Systemgreze abgesteckt, gilt es die verschiedee Sichtweise (Auftraggeber, Etwicklug, Zulieferer, Test usw.) auf das System zu defiiere ud abzustimme. Dabei müsse die potezielle (System-) Risike lokalisiert, diskutiert, abgestimmt ud letztlich auch priorisiert werde. Als Beispiel für uterschiedliche Systemsichte stelle Sie sich vor, Sie baue ei Haus. Der Achitekt hat eie adere Sichtweise auf ihr Haus, wie z. B. ei Maurer, Dachdecker, oder der Elektriker. So verhält es sich auch mit de Risike! Am Beispiel der Hybridbatterie ist eie übergeordete Uterteilug/Sicht zwische Hard- ud Software, d. h. dem Batteriesteuergerät ud der Steuergerätesoftware eie erste Eiordugsmöglichkeit. Alle Syste- me oder Kompoete wurde vo uterschiedliche Teams gefertigt. Wichtig für ei eiheitliches Systemverstädis aller ist letzte Edes ei Koses über die Systemgreze, ud somit über die durchzuführede Aktivitäte, Arbeits- ud Testumfäge. Die Schittstelle sid ebefalls geau zu lokalisiere ud i Bezug zu adere ivolvierte Sub-Systeme (z. B. Motorsteuerug, Klimaalage etc.) zu setze. Am Beispiel der Lithium-Ioe-Batterie wurde folgede Software-Systemabgrezug ud dere Schittstelle defiiert: Batteriesteuerugssoftware ud dere Software-Schittstelle (z. B. Motorsteuerug) ud HardwareSchittstelle (z. B. Prozessor). FuSi-Begriffe Hazard, kausaler Faktor ud Ufall Am Beispiel der Fuktio Batteriekühlug solle die Begriffe Hazard, kausaler Faktor ud Ufall erklärt ud dere Verwedug a Beispiele veraschaulicht werde, um aschließed gezielt die (System-)Risike zu idetifiziere ud geeigete Schutzmaßahme zu defiiere: Ei kausaler Faktor ist die Ursache, durch die ei Hazard, also Ufall, etsteht. Beispiel: Die Fahrzeugaußetemperatur beträgt lägere Zeit kostat über 80 C

4 Olie-Ausgabe Testig 2009 (z. B. aufgrud starker Soeeistrahlug, schwarzer Motorhaube etc.). Ei Hazard ist eie Gefahresituatio, die zu eiem Ufall führe ka, aber icht zwagsläufig führe muss! Beispiel: Der Motorraum, i dem die Lithium-Ioe-Batterie verbaut ist, erhitzt sich stärker als im ormale Fahrbetrieb (z. B. abgedichteter Motorraum, hochtouriger Motordauerbetrieb etc.). Amerkug: Ei Hazard befidet sich immer a de Systemgreze, icht im System selbst! Ei Ufall ist ei uerwüschtes Ereigis, das eie Schade für die Umwelt produziert. Beispiel: Die softwaregesteuerte Batteriekühlug im Steuergeräts überhitzt ud versagt, so dass die Batterie bzw. die Zelle icht mehr geüged gekühlt werde, überhitze ud explodiere. Das Beispiel zeigt, wie fuktioale Sicherheit praktisch agewedet ud ausgehed vo eier defiierte Fuktio (hier Batteriekühlug ) auf Ufälle hi utersucht werde ka. Eie Uterscheidug zwische edogee Hazards (z. B. ei Bauteileversage im Systemiere) ud exogee Hazards (z. B. meschliches Versage, Hitze, Kälte etc.) erlaubt eie geauere Defiitio der Risike ud der Gegemaßahme. Auch die Frage ach dem direkte Eitritt eies Ufalls/Risikos oder eier mögliche Ufallvermeidug ist letztlich für eie Priorisierug der Testfälle hilfreich. Der Testmaager muss die Hazards verstehe ud durch geeigete Testfälle (uter Berücksichtigug der Systemgreze) abdecke. Risiko Defiitio ach ISO Grudsätzlich lässt sich das Risiko durch folgede Formel eifach defiiere: Was ausformuliert Risiko = Schadesausmaß x Eitrittswahrscheilichkeit bedeutet. Wird diese Formel durch die Defiitio der ISO erweitert, ergibt sich folgede Defiitio: D. h. Risiko = Schadesausmaß x (Aufethaltswahrscheilichkeit vo Mesche etc. im Hazard-Bereich x Vermeidugswahrscheilichkeit, we dieser Hazard auftritt ). Für jedes Schadesausmaß auf ei Item (Defiitio für Systembegriff i ISO 26262), d. h. ei Steuergerät, Bauteil oder ei aderes elektrisch/elektroisches Bauteil, werde sogeate ASIL-Level (Automotive Safety Itegrity Level) bestimmt. Diese werde i vier Stufe (A, B, C, D) i eier aufsteigede Kategorisierug eier maximale bzw. eher tolerierbare Azahl vo Fehler bzw. Systemausfälle pro Stude zugeordet. Zusätzlich werde de eizele ASIL-Level-Methode zugeordet, die vo uerwüscht bis verbidlich defiiert sid. Damit wird versucht, de Ursprug eies Hazards, also z. B. ei Programmierfehler oder eie schwerwiegede, kostruktive Abweichug eies Bauteils, durch de Gebrauch vo Best Practice - Methode zu vermeide. Priorisierug der Testfälle mit Gegemaßahme teste Das Testmaagemet ka mithilfe dieser Methodik eie Priorisierug der (Risiko-) Testfälle hisichtlich eier Risikomiderug durchführe. Sid die tolerierbare Risike (geriges Hazard-Risiko) ud die icht tolerierbare Risike (hohes Hazard- Risiko) mit obe beschriebeer Methode herausgearbeitet, so köe die relevate Testfälle ahe a eiem hohe Hazard- Risiko höher priorisiert werde als die Testfälle, die tolerierbare Hazards bzw. Gegemaßahme teste. Für das o. g. Beispiel der Batteriekühlug köe z. B. folgede Gegemaßahme defiiert werde: Drohede Überhitzug durch Warlampe/Sigal dem Fahrer sigalisiere ud Motor als zusätzliche Wärmequelle automatisch ausschalte (Sicherheitsfuktio). Automatisches Aschalte der Klimaalage ud Umleitug des Kühlugsstromes i de Motorraum (Sicherheitsfuktio). Sicherheitsuterweisug (z. B. bei der Ausbildug i Fahrschule) zum Umgag mit Lithium-Ioe-Batterie ud dere Arbeitsweise im Auto (extere aktive Maßahme). Sicherheitshiweis i Fahrzeug-Beutzerhadbücher (extere passive Maßahme). Alle diese uterschiedliche Gegemaßahme köe abgeleitet ud die softwarerelevate ud somit softwaretestbare Aforderuge durch Testfälle abgedeckt werde. Der Test begit jedoch mit de Aforderuge. Sid diese icht klar, eideutig ud vollstädig, ist ei stabiler Testprozess oder gar eie fudierte Risikoaalyse schwer durchzuführe. Der Testfallberg wächst jedoch auch trotz uklarer Aforderuge ud Priorisierug uaufhörlich. Somit wird Testautomatisierug meist früher als später zu eiem wichtige Thema. Testautomatisierug vs. Testprozess das Hee-Ei -Problem? Testautomatisierug ohe eie strukturierte Testprozess eizuführe, ist zu 99,9% zum Scheiter verurteilt. We Chaos vorhade ist, wird auch meist ur Chaos automatisiert, was etliche Praxisbeispiele belege. Trotzdem ka eie parallel zum Testprozess eigeführte Testautomatisierug Erfolge brige. Stehe kappe Ressource a Testpersoal trotz Priorisierug eiem Berg a Testfälle gegeüber ud ist zudem die zu testede Software och stark parametrisierbar, da ist eie frühzeitige Testautomatisierug oft der eizige Weg, de Testaufwad i de Griff zu bekomme. Im dargestellte Beispielprojekt wurde die Toolevaluierug u. a. mithilfe der folgede Frage uterstützt. Toolauswahl ud Tooleisatz im Projekt Der Spruch..drum prüfe, wer sich (läger) bidet... spielt auch hier eie erst zu ehmede Rolle! We eie lagfristige Toolstrategie durch ugeügede Support oder sogar ei Marktrückzug durchkreuzt wird, ka dies die Koste achhaltig ud deutlich erhöhe. Im dargestellte Hybrid-Projekt wurde die obe geate Pukte im Detail ausformuliert ud als Richtschur für die Toolevaluierug ud Auswahl geomme. Bei der Frage ach sivolle Test-Tools sid u. a. folgede Aspekte vo etscheideder Bedeutug: Welche auf dem Markt befidliche Test-Tools erfülle die spezielle Test- Aforderuge? Welche Test-Tools spiele miteiader ud welche icht? Wie hoch ist der Eiarbeitugs-Aufwad für die Mitarbeiter? Wie ist der Tool-Support defiiert? Welche Tools komme letztlich i Frage ud was koste diese? Dabei ist icht immer teuer auch mit gut gleichzusetze. Es gibt eie Fülle vo juge ud (och) flexible Uterehme, die auf de Toolmarkt dräge ud dere Koditioe ud Preise weit uter dee Olie-Ausgabe Testig

5 der etablierte Abieter liege. Jedoch ist geau zu prüfe, was diese Tools köe, wie flexibel der Abieter agiere ka ud was dies letztlich a Koste verursacht. Die Frage ach dem Grad der Aforderugserfüllug eies Testtools ist icht eu, aber immer wieder spaed. Bute Produktbroschüre ud Toolpräsetatioe versuche eie heile Welt zu suggeriere, i der alles klappt ud ohe Fehler fuktioiert. Im praktische Eisatz sieht das allerdigs gaz aders aus. Eie vorab erstellte Aforderugsliste uterstützt bei der Toolauswahl. Gerade bei lage Toolkette uterschiedlicher Abieter ist auf ei korrektes Zusammespiel der Tools utereiader Wert zu lege. Dass alle beötigte Tools miteiader problemlos arbeite, ist fast umöglich. Auch sollte auf eie gewisse Marktpräsez des Abieters ud des agebotee Tools geachtet werde. Hadelt es sich z. B. um ei Nischeprodukt, was keie strategische Wichtigkeit ierhalb der Uterehmug hat, ka es schell zu Supportprobleme komme oder das Tool wird vom Abieter gaz vom Markt geomme. Grudsätzlich sollte bei Tooleiführug midestes ei Mitarbeiter der Toolfirma für midestes eie Woche vor Ort sei. Dieses Präsezcoachig sollte ach ca. 1-2 Woche eigestädiger Arbeit wiederholt werde. Aufgrud der defiierte Toolaforderuge im Projekt wurde die folgede Werkzeuge ausgewählt ud i eier Toolkette miteiader verbude: MATLAB ud Simulik für die Etwicklug der eizele Module ud Fuktioe. AutomatioDesk & MTest für die Erstellug vo Modul-Testframes. Classificatio Tree Editor (CTE) zur Erstellug der Testfälle. MTest für die automatische Testausführug ud Protokollierug. Abb. 3 verdeutlicht das Zusammespiel der geutzte Tools über die verschiedee Testsimulatiosstufe hiweg: Software-ithe-Loop (SIL), Model-i-the-Loop (MIL) ud Processor-i-the-Loop (PIL). Ist im MIL-Modus das Verhalte des Modells simuliert ud als Referez für die ächste Simulatiosschritte festgehalte, folgt im SIL-Modus ei Abgleich auf Code-Ebee. D. h. hier werde mithilfe des geerierte Codes die MIL-Simulatios-Ergebisse mit dee der SIL-Ergebisse vergliche. Im letzte Schritt wird i der PIL-Simulatio der geerierte Code mit dem Zielprozessor 5 Abb. 3: Tool-Kette im Überblick im Verbud getestet. Auf diesem (Simulatios-)Weg köe Programmierfehler lokalisiert ud behobe werde. Im geate Beispielprojekt musste die Etscheidug zur Testautomatisierug relativ schell getroffe werde, da durch die komplexe Parametrisierugsmöglichkeit der Steuerugssoftware die Gefahr eier Testfallexplosio bestad, die auch mit eier Priorisierug der Testfälle icht die Hauptrisike abdeckte. Die Möglichkeit, durch Tools Testfallkombiatioe automatisiert zu erstelle, ud diese auch ausführe zu lasse ud somit die Testabdeckug zu erhöhe, sprach für sich. Somit wurde die eizele Module aus Matlab/ Simulik i eie Testbech, i das Tool Automatio Desk, überführt. Dort wurde die eizele Module i eie Testrahme eigespat. Dieser Testrahme, der durch Testtreiber ud Platzhalter das Testobjekt mit de Testdate versorgte, musste für jedes eizele Modul per Had erstellt werde, kote aber durch leichte Modifikatioe immer wieder verwedet werde. Die Testfälle selbst wurde mit Hilfe des CTE-Editors erstellt ud durch das Tool AutomatioDesk automatisiert ausgeführt. Das aschließede Reportig ud die Dokumetatio der Testausführug wurde durch MTest automatisch geeriert. Fazit Die Herausforderuge ud beötigte Ketisse im Bereich des Testmaagemets im hybride Umfeld beziehe sich icht alleie auf die Software, Testmethode ud beötigte Testtools. Fudierte Ketisse der Hardware ud dere Arbeitsweise, über die modellbasierte Etwicklug ud fudierte Ketisse über fuktioale Sicherheit ud die dort existierede Norme sid uumgäglich. Der Testmaager wird immer stärker mit diesem breite Kowhow a Methode, Techike ud Stadards kofrotiert. Spezielle Schuluge, die diese Theme auch durch die Brille des (Software-)Testmaagemets ud der Softwaretester vermittel, sid Pflicht für Uterehme i diesem Umfeld. Die Rolle des Testmaagers ist spätestes hier icht mehr der part time job, de es och i viele Uterehmuge i dieser Form gibt. Testmaagemet ist Projektmaagemet im Testbereich. Es erfüllt vergleichbare Aufgabe, plat Aktivitäte ud geeriert Aufwäde. Testmaagemet ud Teste ist als eie Eiheit zu sehe ud erfüllt zusamme wichtige Aufgabe, die letztlich mit eier risikobasierte Teststrategie ud etsprechede Testaktivitäte verbude sid. Risike (ud uklare Aforderuge) gibt es ud wird es immer gebe. Aforderuge ud Risike sid das Futter für eie erfolgreiche Test ud ei risikogetestetes ud aforderugsbasiertes Produkt. Wird dies vo alle ivolvierte Parteie verstade ud sid die (Test-) Ziele des Projekts alle klar, ist die Gefahr, dass das Projekt scheitert, geriger. Teste ka keie Qualität i ei Produkt hieiteste. Teste ka aber potezielle Risike für ei Produkt gezielt agehe, offe lege ud letztlich dazu beitrage, diese zu mider. Das Testmaagemet ist hier eie Schlüsseldiszipli ud gerade im hybride Umfeld icht zu uterschätze.