Ralf Bongard ist Geschäftsführer und Trainer der ISARTAL akademie GmbH und seit 1999 in der Automobilindustrie als Entwickler, Berater und Trainer tätig. Seine Themenschwerpunkte liegen im Anforderungs- und Testmanagement im Kontext des Systems Engineering sowie in der Ausbildung von Fachtrainern. Er ist Mitglied des GTB und Leiter der GTB-Arbeitsgruppe »Certified Automotive Software Tester«.
Dr. Klaudia Dussa-Zieger ist leitende Beraterin bei der imbus AG und verfügt über 20 Jahre Berufserfahrung in den Bereichen Softwaretest, Testmanagement sowie Testprozessberatung und -verbesserung. Sie ist ASPICE Principal Assessor. Seit 2008 ist sie die Obfrau des DIN-Normenausschusses 043-01-07 AA »Software und System-Engineering« und seit 2018 die Vorsitzende des GTB.
Prof. Dr. Ralf Reißing ist Professor für Automobilinformatik an der Hochschule Coburg und seit 2002 in der Automobilindustrie mit den Schwerpunkten Testen und Requirements Engineering tätig. Er ist Leiter des Steinbeis-Transferzentrums Automotive Software Engineering, wo er zum Thema Testen im Automobil berät und schult. Er ist Mitglied des GTB und stellvertretender Leiter der GTB-Arbeitsgruppe »Certified Automotive Software Tester«.
Alexander Schulz arbeitet bei der BMW Group in der Fahrzeugentwicklung im Bereich der Funktionssicherheit. Er ist seit 2012 schwerpunktmäßig im Bereich der funktionalen Sicherheit nach IEC 61508 und ISO 26262 tätig.
Alle Autoren dieses Buches sind Mitglieder der GTB-Arbeitsgruppe »Certified Automotive Software Tester« und waren aktiv an der Entwicklung des Lehrplans zum ISTQB Foundation Level Specialist – CTFL® Automotive Software Tester V2.0 beteiligt.
|
Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+: www.dpunkt.plus |
Aus- und Weiterbildung zum ISTQB® Certified Tester
Foundation Level Specialist – Automotive Software Tester
Ralf Bongard · ralf.bongard@isartal-akademie.de
Klaudia Dussa-Zieger · klaudia.dussa-zieger@imbus.de
Ralf Reißing · ralf.reissing@hs-coburg.de
Alexander Schulz · alexander.schulz72@gmx.de
Lektorat: Christa Preisendanz
Copy-Editing: Ursula Zimpfer, Herrenberg
Satz: Birgit Bäuerlein
Herstellung: Stefanie Weidner
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Fachliche Beratung und Herausgabe von dpunkt.büchern zum Thema »ISTQB® Certified Tester«: Prof. Dr. Andreas Spillner · Andreas.Spillner@hs-bremen.de
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN:
Print 978-3-86490-580-3
PDF 978-3-96088-492-7
ePub 978-3-96088-493-4
mobi 978-3-96088-494-1
1. Auflage Copyright © 2020 dpunkt.verlag GmbH
Wieblinger Weg 17
69123 Heidelberg
Hinweis:
Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.
Schreiben Sie uns:
Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: hallo@dpunkt.de.
Dieses Buch basiert auf und enthält Auszüge aus dem Lehrplan Foundation Level Specialist – CTFL® Automotive Software Tester, bereitgestellt durch den Inhaber der ausschließlichen Nutzungsrechte, German Testing Board e.V (GTB).
An der Entwicklung des Lehrplans V1.0 von 2011 beteiligter Autor: Hendrik Dettmering.
An der Aktualisierung des Lehrplans V2.0 von 2017 beteiligte Autoren: Graham Bath, André Baumann, Arne Becher, Ralf Bongard, Kai Borgeest, Tim Burdach, Mirko Conrad, Klaudia Dussa-Zieger, Matthias Friedrich, Dirk Gebrath, Thorsten Geiselhart, Matthias Hamburg, Uwe Hehn, Olaf Janßen, Jacques Kamga, Horst Pohlmann, Ralf Reißing, Karsten Richter, Ina Schieferdecker, Alexander Schulz, Stefan Stefan, Stephanie Ulrich, Jork Warnecke und Stephan Weißleder.
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.
5 4 3 2 1 0
Software im Fahrzeug
Die Automobilindustrie ist im stetigen Wandel. Auch wenn das Testen von Fahrzeugen und ihrer Bestandteile schon immer ein wichtiger Teil der Entwicklung war, so ist das Testen heute noch bedeutender als zuvor. Denn der Umfang der Software im Fahrzeug nimmt stetig zu. So spricht man aktuell von 100 Millionen Codezeilen, aus denen sich die Software eines Fahrzeugs zusammensetzt. Hinzu kommt, dass Software im Vergleich zu Hardware und Mechanik wegen ihrer besonderen Eigenschaften erfahrungsgemäß noch fehleranfälliger ist.
Daher ist mit dem Zuwachs an Software auch mit einem deutlichen Zuwachs an Fehlern in den Fahrzeugsystemen zu rechnen. Diese Fehler muss der Softwaretester im Rahmen der Entwicklung finden, um zu verhindern, dass Endkunden die Fehler im Betrieb aufdecken und dies im schlimmsten Fall nicht überleben. Bücher zum Testen der Software in der Automobilindustrie sind dennoch selten, weshalb dieses Buch eine Lücke schließt.
Lehrplan Automotive Software Tester
Alle vier Autoren dieses Buches sind Mitglieder der Arbeitsgruppe Certified Automotive Software Tester des German Testing Board e.V. (GTB). Die Mitglieder dieser Arbeitsgruppe kommen überwiegend von Automobilherstellern (z.B. BMW, Daimler), von Automobilzulieferern (z.B. Continental, Marquardt, Schaeffler, ZF) sowie deren Dienstleistern (z.B. Werkzeughersteller, Berater, Trainingsanbieter).
Die Arbeitsgruppe entwickelt seit 2014 den (ursprünglich deutschen) Lehrplan zum CTFL Automotive Software Tester (CTFL-AuT) weiter. Gerade aktuell ist die Version 2.0.2 von 2020 [ISTQB 2020]. Die Version 1.0 des Lehrplans, auf der die GTB-Arbeitsgruppe 2014 aufgesetzt hat, erstellte 2011 die Firma Prozesswerk im Auftrag von GASQ.
Seit 2018 gibt es auch den englischen Lehrplan, der die Internationalisierung des CTFL-AuT über Deutschland, Österreich und die Schweiz hinaus angestoßen hat. Chinesische, japanische und koreanische Übersetzungen des Lehrplans sind bereits sehr weit fortgeschritten. Parallel dazu entwickelt die GTB-Arbeitsgruppe den Lehrplan inhaltlich weiter, um neuere Themen aus der Automobilindustrie mit Testbezug wie SOTIF (safety of the intended functionality) und IT-Sicherheit zu integrieren.
Der dpunkt.verlag schlug vor, zu dem in 2017 sehr stark umgestalteten Lehrplan ein Lehrbuch für die Basiswissen-Reihe zu schreiben, das die Inhalte des Lehrplans vertieft und die Vorbereitung auf die Zertifizierungsprüfung unterstützt. Daraufhin haben sich spontan vier Autoren gefunden, die allerdings nicht nur den Lehrplan in Buchform gießen, sondern diesen vertiefen und didaktisch aufbereiten wollten. Deren Lehrbuch halten Sie nun in den Händen.
Rollenbezeichnungen
Aus Gründen der besseren Lesbarkeit verzichtet das Buch auf geschlechtsneutrale Rollenbezeichnungen wie Tester*innen und verwendet stattdessen ausschließlich die männliche Form, also Tester. Sämtliche Rollenbezeichnungen gelten selbstverständlich trotzdem für alle Geschlechter.
Website zum Buch
Zum Buch gibt es die Website www.ctfl-aut.de. Auf dieser Website sind die Lehrpläne, Probeprüfungen und andere hilfreiche Materialien verlinkt. Außerdem kann dort Feedback zum Buch gegeben werden.
Danksagung
Wir danken den Gutachtern Matthias Friedrich, Thorsten Geiselhart, Thomas Hagler, Michael Haimerl, Dennis Herrmann, Peter Raab und Tobias Schmid für ihre wertvollen Rückmeldungen zu den Entwürfen einzelner Kapitel sowie Andreas Spillner für seine umfassenden Anmerkungen zum gesamten Buchmanuskript. Wir danken auch den Autoren der Geleitworte, Gerd Baumann, Thomas Konschak und Horst Pohlmann. Außerdem danken wir dem dpunkt.verlag, insbesondere Christa Preisendanz, für die unendliche Geduld ob der immer größer gewordenen Verspätung bei der Ablieferung des Buchmanuskripts. Und nicht zuletzt möchten wir unseren Familien danken, die uns bei dem umfangreichen Projekt einer Fachbuchveröffentlichung so lange und geduldig unterstützt haben.
Wir wünschen unseren Lesern nun viel Freude und viele Aha-Erlebnisse mit unserem Buch.
Ralf Bongard, Klaudia Dussa-Zieger,
Ralf Reißing und Alexander Schulz
München, Baiersdorf und Coburg,
im Juli 2020
»Wir sollten uns mit großen Problemen beschäftigen, solange sie noch klein sind.« Dieser Satz der polnischen Journalistin Jadwiga Rutkowska entstammt einem anderen Kontext, er benennt aber auch ein Grundprinzip des Testens. Das Auffinden von Elektronik- und Softwarefehlern in frühen Entwicklungsphasen spart Zeit und Kosten. Fehler, die erst im Serienfahrzeug erkannt werden, verärgern Kunden und beschädigen das Markenimage.
Automobilhersteller und Zulieferer haben dies bereits vor vielen Jahren erkannt und erhebliche Investitionen in Verfahren und Anlagen zur Erprobung von vernetzten elektronischen Steuergeräten getätigt. Parallel wurden im Hochschulbereich die theoretischen Grundlagen und Testmethoden für Software im Kraftfahrzeug geschaffen. Dabei konnte man sich auf eine breite Basis von Testprozessen aus der technischen Informatik stützen, die in anderen Branchen wie der Telekommunikation bereits etabliert waren. Heute gehören Hardware-in-the-Loop-Tests von mechatronischen Fahrzeugsystemen und statische Codeanalysen zum Standardrepertoire der Fahrzeugentwicklung.
Allerdings erfolgt das Testen von Automobilelektronik und -software nicht in jedem Fall systematisch. Häufig basieren Tests primär auf Heuristiken, also auf Erfahrungswissen des Entwicklungsteams. Dies ermöglicht eine rasche und effiziente Testfalldefinition, allerdings ist in der Regel nicht bekannt, welche Testabdeckung (Coverage) erreicht wird. Am anderen Ende der Skala stehen Brute-Force-Ansätze. Dabei wird mit hohem Geräte- und Zeitaufwand versucht, alle möglichen Kombinationen von Eingangs- und Zustandsgrößen des zu testenden Moduls zu durchlaufen, was bei umfangreichen Funktionen stets an Kapazitätsgrenzen stößt.
Eine Qualifizierung des Testpersonals anhand des Schemas »Certified Tester« ist die passende Antwort auf diese Herausforderungen. Den Autoren des vorliegenden Buches ist es gelungen, das hierfür notwendige Fachwissen in kompakter und praxisgerechter Form zusammenzufassen.
Die Beherrschung der methodischen Grundlagen ist essenziell, weil der Softwarefunktionsumfang von Kraftfahrzeugen aktuell einen immensen Schub erfährt. Automatisierte, vernetzte Fahrzeuge und deren Absicherung bezüglich Safety und Security erfordern einen Quantensprung beim Testen. Beispielsweise ist heute noch unklar, ob sogenannte Künstliche Intelligenz (KI) zukünftig Bestandteil sicherheitsrelevanter Funktionen zur automatisierten Fahrzeugführung werden kann. Technisch gesehen stellt ein KI-Softwaremodul auf der Basis neuronaler Netze, dessen Parameter sich durch »Lernen« während der Fahrt verändern können, ein zeitvariantes Unikat-System dar. Die etablierten Testansätze für Blackbox- und Whitebox-Prüflinge versagen hierbei. Aufgabe der Forschung ist es, für diesen Anwendungsbereich völlig neue Methoden zu erschließen, die für den praktischen Einsatz in der Automobilindustrie geeignet sind.
Gerd Baumann
Leiter Kraftfahrzeug-Mechatronik/Software,
Forschungsinstitut für Kraftfahrwesen und
Fahrzeugmotoren Stuttgart (FKFS)
Stuttgart, Juli 2020
Die Automobilindustrie steht in der Entwicklung von softwarebestimmten Systemen großen Herausforderungen gegenüber. Um dem Kunden ein umfassendes Fahrerlebnis zu ermöglichen, werden in modernen Automobilen die Funktionen zunehmend komplexer sowie die Wirkketten länger und hochvernetzt. Die Teilstrecken der Funktionen werden dazu in skalierbaren Baukästen organisiert. Dabei liefert eine Vielzahl an Sensoren und Off-Board-Systemen mit unterschiedlichsten Wirkprinzipien massive Datenströme an hochintegrierte Steuergeräte. Diese Steuergeräte müssen dann mit immenser Rechenpower eine Vielzahl an interagierenden Funktionen und Regelkreisen berechnen, um die Aktuatoren anzusteuern.
Um diese Herausforderungen meistern zu können, werden die Systeme arbeitsteilig entwickelt und umgesetzt. Daran sind vor allem die Automobilhersteller (OEMs) und Automobilzulieferer (Tiers) beteiligt, aber immer öfter auch innovative Start-ups und branchenfremde Unternehmen. Will man nun die Systembausteine zu einem stimmigen Gesamtsystem integrieren, so ist u.a. ein aufeinander aufbauendes, methodisches und arbeitsteiliges Testen notwendig. Das beginnt beim Test von Algorithmen und Softwaremodulen in unterschiedlichsten Integrationsstadien. Der Testprozess setzt sich dann fort bei der Zielhardware mit integrierter Software, den Teilsystemen mit den integrierten Steuergeräten bis hin zum Gesamtsystem in seinen unterschiedlichen Varianten.
Um diese Aufgabe professionell, strukturiert und methodisch durchzuführen, ist es notwendig, ein gemeinsames fachlich-methodisches Grundverständnis hinsichtlich der Herangehensweise und Durchführung der Tests zu haben. Auch ein gemeinsamer Nenner bei den Begrifflichkeiten erleichtert die Zusammenarbeit und vermeidet Missverständnisse zwischen den Entwicklungspartnern. Diesen gemeinsamen Nenner bieten die Ausbildung und Zertifizierung der Tester nach dem ISTQB®-Schema. Schon der Foundation Level bietet ein methodisches und begriffliches Grundgerüst, das jeder, der am Test beteiligt ist, haben sollte. Mittlerweile wurde dieses Grundgerüst um das Spezialisierungsmodul zum ISTQB® Automotive Software Tester ergänzt, das die Lücke zwischen klassischem Softwaretest und dem Testen automobiler Systeme schließt.
Mit der spezialisierten Ausbildung zum ISTQB® Foundation Level Specialist – CTFL Automotive Software Tester wird ein solides Fundament gelegt, um den Ansprüchen an einen professionellen Softwaretester in der Automobilindustrie gerecht zu werden. Durch die gut verständliche Aufbereitung und Vermittlung der Inhalte ist dieses Buch der ideale Begleiter für die Ausbildung und die Anwendung des Erlernten.
Thomas Konschak
Leiter E/E-Integration und Variantenabsicherung
für automatisiertes Fahren der BMW AG
München, Juli 2020
In den letzten 15 Jahren hat sich der Anteil der Elektronik und der Software an den Fahrzeugkosten mehr als verdoppelt. Der Trend ist stetig weiter ansteigend bei gleichzeitig wachsender Komplexität. Parallel hat sich in diesem Zeitraum das Testen von Software in der Automobilelektronik als eigene Disziplin etabliert. Dabei nennen die anzuwendenden Normen und Standards lediglich Testverfahren, ohne dem Automotive Softwaretester eine Anleitung zu liefern, welche Testverfahren in welchem Kontext einzusetzen sind. Eine Hilfestellung bieten die Lehrpläne und ergänzenden Materialien des International Software Testing Qualifications Board (ISTQB®).
Die ursprünglich rein branchenunabhängige Ausbildung und Qualifikation von Softwaretestern hat seit der Gründung des ISTQB® im Jahre 2002 einen enormen Zuwachs erfahren. Die Zahlen sprechen für sich: Aktuell gibt es über 700.000 zertifizierte ISTQB®-Tester weltweit, wobei der Anteil in Deutschland mehr als 75.000 Certified Tester beträgt.
Bereits im Jahre 2008 hatte Ralf Bongard die Idee, eine Qualifikation zum Automotive Software Tester zu etablieren. Mit der Gründung der GTB-Arbeitsgruppe »Automotive Software Tester« im Jahre 2013, deren Leiter er heute ist, wurde parallel zur Entwicklung der Inhalte in den Folgejahren die Idee auf vielen Konferenzen im In- und Ausland präsentiert. Auf diesem Wege konnten viele neue Mitstreiter für die aktive Mitarbeit gewonnen werden.
Die Einbettung des Automotive Softwaretesters in das ISTQB®-Produktportfolio schließt eine Lücke: Der Certified Tester Foundation Level (CTFL) vermittelt das notwendige Basiswissen und eine Spezialisierung ergänzt die automobilspezifischen Aspekte. Beide Anteile zusammen bilden die Basis für die Zertifizierung zum CTFL Automotive Software Tester. In den kommenden Jahren wird die Entwicklung des Lehrplans weitergehen, indem weitere Aspekte des Testens von Automotive Software (z.B. Penetrationstesten für IT-Sicherheit) Eingang in den Lehrplan finden.
Das vorliegende Buch »Basiswissen Automotive Softwaretest« vermittelt über den Lehrplan hinaus das erforderliche Fachwissen im Detail und stellt somit eine wertvolle Ergänzung zum ISTQB®- und GTB-Portfolio dar.
Horst Pohlmann
Vorstandsmitglied des German Testing Board e.V. (GTB)
Leiter Prozesse, Methoden und Tools der
Lemförder Electronic GmbH
Bünde, Juli 2020
1Einführung
2Grundlagen
3Normen und Standards
4Virtuelle Testumgebungen
5Testansätze und Testverfahren
Anhang
AISO 26262
BAutomotive SPICE
CGegenüberstellung der Teststufen
DAnforderungsspezifikation Antriebsstrang
EGegenüberstellung Lehrplan
FAbkürzungen
GLiteraturverzeichnis
Index
1Einführung
1.1Lehrpläne
1.2Übersicht über das Buch
1.3Einführung in das Beispielprojekt
1.3.1Projekthintergrund
1.3.2Aufbau des Systems
1.3.3Einzuhaltende Standards
1.3.4Beteiligte Personen
2Grundlagen
2.1Grundsätze des Testens
2.2Der Testprozess
2.2.1Testdurchführung
2.2.2Testvorbereitung
2.2.3Testmanagement
2.3Testen im Systemlebenszyklus
2.4Dimensionen des Testens
2.4.1Teststufen
2.4.2Testarten
2.4.3Testverfahren
3Normen und Standards
3.1Automotive SPICE
3.1.1Aufbau und Struktur
3.1.2Anforderungen an den Test
3.2ISO 26262
3.2.1Funktionale Sicherheit von E/E-Systemen
3.2.2Sicherheitskultur
3.2.3Der Tester im Sicherheitslebenszyklus
3.2.4Gliederung der Norm
3.2.5Kritikalitätsabstufungen des ASIL
3.2.6Auswahl der Testmethoden
3.3AUTOSAR
3.3.1Ziele
3.3.2Entwicklungsmethodik
3.3.3Logische Systemarchitektur
3.3.4Technische Systemarchitektur
3.3.5Steuergeräte-Softwarearchitektur
3.3.6Generierung der Steuergerätesoftware
3.3.7Einfluss auf den Test
3.3.7.1Softwarekomponententest
3.3.7.2Softwareintegrationstest und Softwaretest
3.3.7.3Steuergeräteintegrationstest und Steuergerätetest
3.3.7.4Systemintegrationstest
3.4Gegenüberstellung der Standards
3.4.1Zielsetzung
3.4.2Teststufen
3.4.3Testverfahren und Testansätze
4Virtuelle Testumgebungen
4.1Grundlagen
4.1.1Testobjekt
4.1.2Testrahmen
4.1.3Systemsteuerung
4.2Arten von Testumgebungen
4.2.1Model-in-the-Loop-Testumgebung (MiL)
4.2.2Software-in-the-Loop-Testumgebung (SiL)
4.2.3Hardware-in-the-Loop-Testumgebung (HiL)
4.3Auswahl und Einsatz der Testumgebungen
5Testansätze und Testverfahren
5.1Testansätze
5.1.1Anforderungsbasiertes Testen
5.1.2Erfahrungsbasiertes Testen
5.1.3Risikobasiertes Testen
5.1.4Modellbasiertes Testen
5.2Statische Testverfahren
5.2.1Statische Analyseverfahren
5.2.2Reviewverfahren
5.2.2.1Review der Testbasis
5.2.2.2Qualitätsmerkmale von Anforderungen
5.2.2.3Reviewcheckliste für Anforderungen
5.2.3MISRA-C-Programmierrichtlinien
5.3Dynamische Testverfahren
5.3.1Spezifikationsbasierte Testverfahren
5.3.1.1Äquivalenzklassenbildung
5.3.1.2Grenzwertanalyse
5.3.2Erfahrungsbasierte Testverfahren
5.3.3Strukturbasierte Testverfahren
5.3.3.1Anweisungstest
5.3.3.2Entscheidungstests
5.3.3.3Bedingungstest
5.3.4Testverfahren für die Testdurchführung
5.3.4.1Back-to-Back-Test
5.3.4.2Fehlereinfügungstest
5.4Gegenüberstellung und Auswahl
Anhang
AISO 26262
A.1Zusammenfassung der Bände
A.2Übersicht der testrelevanten Methodentabellen
BAutomotive SPICE
B.1Prozessspezifikation SWE.6
B.2ASPICE-Prozesse und VDA-Scope
B.3Generische Praktiken und Ressourcen
B.4Verfeinerte NPLF-Skala
CGegenüberstellung der Teststufen
DAnforderungsspezifikation Antriebsstrang
D.1Feature Tempomat
D.2Komponentenspezifikation
EGegenüberstellung Lehrplan
FAbkürzungen
GLiteraturverzeichnis
G.1Weiterführende Literatur
G.2Referenzen
Index
Dieses Buch richtet sich an Personen, die in der Automobilindustrie Testaktivitäten für softwarebasierte Systeme planen, vorbereiten, durchführen oder beurteilen. Das Buch soll das Thema Automotive-Softwaretest möglichst allgemein darstellen, weshalb es sich nicht mit allen relevanten Spezialthemen befasst.
Für die vertiefende Behandlung einiger Spezialthemen gibt es eigene ISTQB®-Lehrpläne und zugehörige Bücher im dpunkt.verlag, beispielsweise [Linz 2016] zum Testen in der agilen Softwareentwicklung, [Simon et al. 2019] zum Testen der IT-Sicherheit und [Winter et al. 2016] zum modellbasierten Testen. Zum momentan sehr aktuellen Thema des Testens von Systemen, die auf künstlicher Intelligenz (KI) basieren, wie autonomen Fahrzeugen, ist ein ISTQB®-Lehrplan gerade im Entstehen.
ISTQB® CTFL Automotive Software Tester
Das Buch unterstützt bei der Vorbereitung auf die Zertifizierungsprüfung zum ISTQB® Foundation Level Specialist – CTFL Automotive Software Tester (CTFL-AuT), sowohl im Selbststudium als auch begleitend zu einer Schulung. Es deckt die Inhalte des Lehrplans in der zum Zeitpunkt des Erscheinens aktuellen Version 2.0.2 [ISTQB 2020] vollständig ab. Anhang E enthält eine Tabelle mit Querverweisen, wo im Buch die einzelnen Abschnitte des Lehrplans zum CTFL-AuT behandelt werden. Das Buch geht aber auch über den Lehrplan hinaus, um wichtiges Hintergrundwissen zu vermitteln sowie einzelne Aspekte zu vertiefen.
Vorbereitung Zertifizierungsprüfung
Für die Vorbereitung auf die Zertifizierungsprüfung muss auf jeden Fall neben dem Buch auch der Lehrplan durchgearbeitet werden, da die Prüfungsfragen aus dem Lehrplan abgeleitet sind, und der Lehrplan manche Themen etwas anders behandelt als das Buch. Abweichungen vom Lehrplan sind im Buch aber gekennzeichnet.
ISTQB® Certified Tester Foundation Level
Der CTFL-AuT baut auf dem Lehrplan zum ISTQB® Certified Tester Foundation Level (CTFL) [ISTQB 2018] auf und ergänzt diesen um automobilspezifische Inhalte. Daher erfordert eine Zertifizierung zum CTFL-AuT eine vorhandene Zertifizierung zum CTFL. Das Buch setzt im Wesentlichen die Kenntnisse der Inhalte des CTFL voraus, die beispielsweise im Buch »Basiswissen Softwaretest« [Spillner & Linz 2019] vertieft nachzulesen sind.
ISTQB®-Glossar
Die hier im Buch verwendeten Fachbegriffe des Testens basieren auf dem lehrplanübergreifenden ISTQB®-Glossar [ISTQB & GTB 2020]. Sollte ein testspezifischer Begriff nicht geläufig sein, findet sich dort die zugehörige Definition.
Das Buch orientiert sich im Wesentlichen an der Struktur des Lehrplans zum CTFL-AuT (siehe Anhang E).
Grundlagen
Kapitel 2 geht auf die Grundlagen aus dem CTFL ein. Es skizziert die Grundprinzipien aus dem CTFL, die für das Verständnis des CTFL-AuT notwendig sind. Darüber hinaus beschreibt es den für die Automobilindustrie typischen Produktentstehungsprozess (PEP) und diskutiert die Mitwirkung der Tester im PEP, beispielsweise bei Freigaben.
Normen und Standards
Kapitel 3 umfasst die Normen und Standards, mit denen ein Softwaretester in der Automobilindustrie typischerweise in Kontakt kommt. Der besondere Fokus liegt auf Automotive SPICE, ISO 26262 und AUTOSAR. Dabei werden die Grundstrukturen der Normen und Standards erklärt sowie die Herausforderungen bzw. relevanten Anforderungen an den Tester erläutert. Im Vergleich zum Lehrplan finden sich im Buch mehr Informationen und Hintergründe zu den jeweiligen Normen und Standards. Zielsetzung des Kapitels ist es, dem Tester ausreichend Informationen an die Hand zu geben, sodass er fundiert bei den Diskussionen um die aus den Normen und Standards abgeleiteten Testanforderungen mitsprechen kann. Das Kapitel schließt mit einer Gegenüberstellung der Zielsetzung, der Teststufen und der Testverfahren und Testansätze in den Normen und Standards.
Virtuelle Testumgebungen
Kapitel 4 beschreibt die unterschiedlichen virtuellen Testumgebungen, die in der Automobilindustrie zum Einsatz kommen. Nach einer allgemeinen Einführung in Testumgebungen stellt es die Unterschiede zwischen Closed- und Open-Loop-Systemen dar. Danach vertieft es die Charakteristika virtueller Testumgebungen wie MiL (Model-in-the-Loop), SiL (Software-in-the-Loop) und HiL (Hardware-in-the-Loop). Abschließend erfolgt ein Vergleich der unterschiedlichen virtuellen Testumgebungen und ihrer Einsatzgebiete bei der Produktentwicklung.
Testansätze und Testverfahren
Kapitel 5 erklärt spezielle Testansätze und Testverfahren, die in der Automobilindustrie eingesetzt werden, und zeigt ihre Anwendung anhand von Beispielen auf. Im Softwaretest sind Testansätze von genereller Natur und repräsentieren prinzipielle Vorgehensweisen und Theorien zur Lösung von Testaufgaben. Im Gegensatz dazu sind Testverfahren konkrete Vorgehensweisen und Techniken zur Lösung von Testaufgaben. Hierzu zählen Verfahren sowohl für statische als auch für dynamische Tests. Bei den statischen Testverfahren liegt der Fokus auf der Codeanalyse nach MISRA-C sowie auf den Qualitätsmerkmalen für das Review von Anforderungen. Bei den dynamischen Testverfahren wird insbesondere auf die Testverfahren eingegangen, die die ISO 26262 empfiehlt. Hierzu gehören beispielsweise modifizierte Bedingungs-/Entscheidungstests (MC/DC-Test), Back-to-Back-Tests und Fehlereinfügungstests. Darüber hinaus zeigt Kapitel 5 auf, wie eine Auswahl der Testverfahren in einem konkreten Projektkontext erfolgen kann.
Anhang
Beim Schreiben des Buches hat der eine oder andere Autor Inhalte entwickelt, die die Hauptkapitel des Buches sprengen würden. Da es sich aber um wertvolle Informationen handelt, sind diese Inhalte im Anhang zu finden. Beispielsweise die Zusammenfassung aller Bände der ISO 26262, inkl. einer Aussage zu den Neuerungen in der Version von 2018.
Beispiele
Um dem Leser das Verständnis für die Inhalte zu erleichtern, haben wir das Projekt ULV des Fahrzeugherstellers Bavarian Electric Cars (BEC) als durchgängiges Beispiel eingeführt (siehe Abschnitt 1.3). Wo möglich und sinnvoll, stellen die einzelnen Abschnitte im Buch einen Bezug zu dem Beispielprojekt her. Dies soll dem Leser das Verständnis der Inhalte und den Transfer auf den Projektalltag erleichtern.
Ein durchgängiges Beispiel soll in diesem Buch zum besseren Verständnis der Inhalte beitragen. Alle Beispiele sind im Buch grau hinterlegt:
Bei der zu entwickelnden Tempomatfunktion handelt es sich um einen reinen Geschwindigkeitsregler, nicht um einen Abstandsregeltempomaten.
Systemlieferant Eddison Electronics
Dreh- und Angelpunkt des Beispielprojekts ist die Firma Eddison Electronics. Eddison Electronics ist ein mittelständisches Unternehmen, das sich auf elektrische Antriebe für Kraftfahrzeuge spezialisiert hat. Der Fahrzeughersteller Bavarian Electric Cars (BEC) hat Eddison Electronics beauftragt, den elektrischen Antriebsstrang für ihr neues Stadtfahrzeug Urban Lite Vehicle (ULV) zu entwickeln. Eddison Electronics hat in diesem Projekt die Rolle des Systemlieferanten (Tier-1) und entwickelt für BEC den kompletten elektrischen Antrieb – einschließlich damit verbundener Funktionen, wie Antriebsschlupfkontrolle oder Tempomat. Abbildung 1–1 zeigt, für welche Umfänge des Fahrzeugs Eddison Electronics zuständig ist.
Abb. 1–1Umfänge der Firma Eddison Electronics (EE) am Projekt ULV
Der Antriebsstrang des ULV besteht aus dem E/E-Antriebssystem und den rein mechanischen Umfängen, wie Getriebe und Differenzial. Das E/E-Antriebssystem umfasst den Elektromotor, die Leistungselektronik (Inverter), den Hochvoltspeicher und die Steuergeräte für Leistungselektronik und Elektromotor. Sie sind in das elektrische Bordnetz und die Bussysteme des Fahrzeugs (u.a. CAN) eingebunden. Die Steuergeräte sind moderne Plattformsteuergeräte. Hardware und Software werden von Eddison Electronics selbst entwickelt.
Abbildung 1–2 zeigt die Struktur des Antriebsstrangs bis hin zu den Softwarekomponenten, aus denen die Software der beiden Steuergeräte besteht. Für die Beispiele in diesem Buch sind speziell die Strukturelemente mit Softwareanteil relevant. Sie sind in der Abbildung grau eingefärbt.
Abb. 1–2Struktur des elektrischen Antriebsstrangs
Feature Tempomat
Da der gesamte elektrische Antriebsstrang sehr umfangreich ist, konzentrieren sich die Beispiele im Folgenden auf das Feature Tempomat. BEC hat den Tempomaten zu Projektbeginn grob beschrieben:
Eddison Electronics hat anhand der Beschreibung von BEC eine Systemanforderungsspezifikation verfasst (siehe Anhang D) und auf dieser Basis eine funktionale Systemarchitektur erarbeitet – einschließlich verfeinerter Anforderungen an die Systembestandteile (ebenfalls im gleichen Anhang). Abbildung 1–3 zeigt die funktionale Architektur des Features Tempomat.
Abb. 1–3Funktionale Architektur der Tempomatfunktion
Das Feature Tempomat besteht aus sieben Architekturelementen:
Die kleinen Kästen an den Rändern der Architekturelemente in Abbildung 1–3 stellen die Schnittstellen dar. Das Dreieck im Kästchen zeigt die Signalrichtung an und markiert eine Schnittstelle als Sender bzw. Empfänger von Daten. Die an den Schnittstellen übertragenen Signale sind in Tabelle 1–1 genauer beschrieben.
Signal |
Beschreibung |
IEM |
Stromstärke des Stromflusses zum Elektromotor |
Msoll |
Konsolidiertes Soll-Drehmoment |
Msoll,F |
Soll-Drehmoment auf Basis des Fahrpedals |
Msoll,T |
Soll-Drehmoment auf Basis des Tempomatreglers |
nist |
Werte der vier Raddrehzahlsensoren |
nsoll |
Raddrehzahl nach Elektromotor und Getriebe |
PWMEM |
Pulsweitenmodulationssignale zur Ansteuerung des Elektromotors |
r.sbrems |
Stellung des Bremspedals |
r.sfahr |
Stellung des Fahrpedals |
Taktiv |
Tatsächlicher Aktivitätsstatus des Tempomaten |
Ton/off |
Fahrerwunsch zum Aktivierungsstatus des Tempomaten (an/aus) |
vist |
Aktuelle Geschwindigkeit des Fahrzeugs |
vsoll |
Soll-Geschwindigkeit des Fahrzeugs für den Tempomaten |
vwunsch |
Wunschgeschwindigkeit des Fahrers für den Tempomaten |
Tab. 1–1Signale der Tempomatfunktion
Entwicklung nach Stand der Technik
BEC erwartet, dass Eddison Electronics nach dem Stand der Technik entwickelt, der unter anderem durch Normen und Standards definiert ist. Hier sind drei für die Fahrzeugentwicklung zentrale Standards hervorgehoben, auf die Kapitel 3 ausführlicher eingeht.
Darüber hinaus gibt es noch viele weitere Normen und Standards, die für das Projekt relevant sind. Kapitel 3 führt einige davon auf.
Die folgenden Personen sind bei Eddison Electronics im Projekt tätig:
Auch der Automotive Softwaretester (im Weiteren als Tester bezeichnet) ist ein Softwaretester. Für ihn gelten die gleichen Grundsätze, Prozesse und Verfahren. Er bewegt sich jedoch im automotive-spezifischen Kontext. So sind die Grundlagen des Testens, die im Rahmen der Ausbildung zum ISTQB® Certified Tester – Foundation Level (CTFL) [ISTQB 2018] vermittelt werden, auch hier anwendbar.
Hierzu gehören neben den Grundsätzen des Testens (Abschnitt 2.1) auch der Testprozess (Abschnitt 2.2) im Kontext des Systemlebenszyklus (Abschnitt 2.3). Darüber hinaus gilt es, die drei Dimensionen des Testens (Abschnitt 2.4) mit Teststufen, Testarten und Testverfahren im Kontext der Softwareentwicklung in der Automobilindustrie zu betrachten.
Im CTFL sind die sieben Grundsätze des Testens beschrieben, die jedem Tester als Leitlinien in seiner täglichen Arbeit dienen [ISTQB 2018]:
In der Praxis wird der Tester oft mit der Anforderung konfrontiert, eine Funktionsfreigabe(empfehlung) (siehe Abschnitt 2.3) oder Funktionsbestätigung zu liefern. Dabei muss klar sein: Der Tester kann nur das Risiko unerkannter Fehlerzustä1nde reduzieren und einschätzen. Er kann die Fehlerfreiheit einer Funktion niemals nachweisen!
Um Marktanteile zu gewinnen und Kundenwünsche zu erfüllen, bieten die Fahrzeughersteller eine wachsende Anzahl an Modellvarianten, Konfigurationen und Features an. Im Jahr 2017 hat VW »fast 84.000 Golf in Deutschland verkauft. Davon hatten mehr als 58.000 unterschiedliche Konfigurationen. Gerade einmal 400 Golf waren identisch – von den unterschiedlichen Farben ganz abgesehen. Das heißt: Wir (VW) bauen Unikate« [Doll 2018, S. 15]. Und so wie VW geht es auch anderen Fahrzeugherstellern, die ihren Kunden eine umfangreiche Individualisierung der Fahrzeuge anbieten.
Die große Konfigurationsvielfalt führt unweigerlich zu einer hohen Komplexität, was das Risiko möglicher Fehlerzustände erhöht. Außerdem führt sie zu einer Explosion der Testaufwände, was hohe Kosten mit sich bringt. Selbst wenn ein vollständiger Test möglich wäre, die vollständig getesteten Unikate wären wegen der hohen Testkosten unbezahlbar. Wenn in Konsequenz ein vollständiges Testen weder sinnvoll noch möglich ist, kann Testen nur stichprobenhaft erfolgen. Bei der Auswahl geeigneter Stichproben können dem Tester sowohl Normen und Standards (siehe Kap. 3) als auch Testansätze und Testverfahren (siehe Kap. 5) helfen.
Je später der Tester einen Fehlerzustand aufdeckt, desto teurer ist die Korrektur des Fehlerzustands. Zu den Gestaltungsprinzipen des Lean Development2 gehört auch das Frontloading. Es basiert auf dem Ansatz, hohe Kosten durch spät entdeckte Mängel und Änderungen so weit wie möglich zu vermeiden. Für das frühe Finden von Fehlern spielen der statische Test (siehe Abschnitt 5.2) und der (Software-)Komponententest eine wichtige Rolle.
Darüber hinaus stellt das Testen von eingebetteten Systemen (Embedded Systems) den Tester vor große Herausforderungen. Da eingebettete Fahrzeugsysteme in den technischen Kontext des Fahrzeugs eingebunden sind, lässt sich das Verhalten der Software häufig auch nur im Fahrzeugkontext bewerten. Allerdings ist das Testen unter realen Bedingungen (d.h. auf der Zielhardware und in der realen Umgebung) häufig sehr zeit- und kostenintensiv. Frühes Testen spart auch hier Zeit und Geld, bedingt jedoch den Einsatz virtueller Testumgebungen, die den Kontext simulieren, in den die Systeme eingebettet sind (siehe Kap. 4).
In der Praxis hat sich gezeigt, dass Fehlerzustände nicht gleichmäßig (im Sinne einer gleichen Fehlerdichte) über alle Testobjekte verteilt sind. Die Ursache hierfür liegt darin, dass während der Entwicklung Fehlerzustände durch Fehlhandlungen3 entstehen. Treiber von Fehlhandlungen sind Zeitdruck, hohe Komplexität, hoher Innovationsgrad des Testobjekts und mangelnde Qualifikation der Mitarbeiter.
Eine gleichmäßige Verteilung der Testressourcen hat den Nachteil, dass kritische Bereiche möglicherweise nicht ausreichend und unkritische Bereiche zu ausführlich getestet werden. Beides reduziert die Effizienz des Testens (Mehrwert des Testens bezogen auf den Aufwand für das Testen). Hier ermöglicht ein risikobasierter Testansatz (siehe Abschnitt 5.1.3) ein effizientes Testen. Bei diesem Ansatz ist die Verteilung der Testaufwände abhängig vom Risiko einer Fehlerhäufung (Produktrisiko) oder dem Risiko von Fehlhandlungen (Projektrisiko).
Häufig trifft man in der Softwareentwicklung der Automobilindustrie die Regressionsteststrategie an, dass der Tester alle oder zumindest immer die gleichen Regressionstests durchführt. Dabei kann es zu dem vermeintlich positiven Effekt einer abnehmenden Anzahl von Regressionsfehlern kommen. Vermeintlich positiv, da die daraus abgeleitete Annahme eines zunehmend reiferen Produkts falsch sein kann. Denn auch das Pestizid-Paradoxon
