O'Reilly logo

Automotive SPICE in der Praxis: Interpretationshilfe für Anwender und Assessoren by Jörg Zimmer, Lars Dittmann, Klaus Hörmann, Markus Müller

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

91
2.10 ENG.8 Softwaretest
2.10 ENG.8 Softwaretest
2.10.1 Zweck
Zweck des Prozesses ist es zu bestätigen, dass die integrierte Software den defi-
nierten Softwareanforderungen entspricht.
Durch Tests wird sichergestellt, dass die integrierte Software den in ENG.4 ermit-
telten Softwareanforderungen entspricht. Gemeint ist das integrierte Software-
produkt, das nach Abschluss der Integration (ENG.7) zustande gekommen ist. Es
kann durchaus mehrere parallele Softwareprodukte geben, die auf unterschiedli-
chen Prozessoren laufen und die später im Rahmen der Systemintegration
(ENG.9) mit anderen Systemkomponenten (d.h. auch Hardware, Mechanik)
zusammengeführt werden.
2.10.2 Besonderheiten in der Automobilindustrie
In der Regel wird in der Automobilindustrie ein integriertes System entwickelt,
bestehend aus Hardware-, Software- und Mechanikkomponenten.
61
Bei einem
Assessment stellt sich dann die Frage, wie die diversen im Projekt durchgeführten
Tests den in Frage kommenden Prozessen (ENG.7, ENG.8, ENG.9, ENG.10)
zugeordnet werden. Trivial ist die Zuordnung dann, wenn es explizite Software-
anforderungen sowie genau darauf abzielende Tests gibt. Die Realität ist aber oft
anders: Anforderungen beschreiben Funktionalitäten, die durch ein Zusammen-
spiel von Hard- und Software realisiert werden, die dann auch später im inte-
grierten Zustand getestet werden.
61. Es gibt allerdings auch Projekte, die ein reines Softwareprodukt liefern, das dann z. B. erst in
einem anderen Unternehmen (z. B. beim Kunden) in ein Komplettsystem aus Hardware, Soft-
ware und Mechanik integriert wird.
Hinweis für Assessoren
In der Assessmentpraxis hat sich dann häufig folgende Zuordnung der Tests her-
auskristallisiert:
ENG.7: Softwareintegrationsbegleitende Tests
ENG.8: Tests des fertigen Softwareprodukts vor Integration mit der Hard-
ware, wobei die Zielhardware durch Software und/oder Hardware-Laborauf-
bauten emuliert wird. Der Laboraufbau kann z.B. auch das fertige Steuergerät
umfassen.
ENG.9: Systemintegrationsbegleitende Tests von Software- und Hardware-
komponenten
ENG.10: Tests des integrierten Systems auf der Zielhardware
2 Interpretationen zur Prozessdimension
92
Wird ein Prototyp ausgeliefert (z.B. frühe Muster), der nicht die komplette Funk-
tionalität beinhaltet, müssen die Softwaretests sicherstellen, dass die ausgeliefer-
ten (Teil-)Funktionen entsprechend den Anforderungen arbeiten. Eine weitere
Besonderheit ist, dass sich Hardwarenähe und Realzeitverhalten (siehe auch
ENG.5, Abschnitt 2.7.2 »Besonderheiten in der Automobilindustrie«) stark auf
die Art der Tests und die Testumgebung (oft die Zielhardware und Zielumge-
bung) auswirken.
2.10.3 Basispraktiken
BP1: Entwickle eine Softwareteststrategie. Entwickle eine Strategie, um die Soft-
waretests konsistent mit der Releasestrategie durchzuführen.
Vor dem Test der Gesamtsoftware müssen zuerst die Ziele und Rahmenbedingun-
gen für den Softwaretest in einem Testplan
62
(siehe Exkurs »Testdokumentation«
bei ENG.6) dokumentiert werden. In der Releasestrategie ist definiert, wann wel-
che Funktionalität zur Verfügung steht, und damit, wann welche Tests durchge-
führt werden können und müssen.
BP2: Entwickle eine Testspezifikation für den Softwaretest. Entwickle eine Test-
spezifikation inklusive der Testfälle für den Softwaretest, die für integrierte Soft-
ware angewendet werden soll. Die Testfälle sollten die Übereinstimmung mit
den Softwareanforderungen zeigen.
Anmerkung: Der Softwaretestprozess sollte mit dem Beginn des Softwareent-
wicklungsprozesses starten. Beim Entwickeln der Testfälle und von testbaren
Anforderungen besteht eine enge Verbindung zur Softwareanforderungsanalyse
(ENG.4), zum Softwaredesign (ENG.5) oder zur Anforderungserhebung (ENG.1).
Es kommt auch häufig folgende Konstellation vor: Die Zielhardware liegt bereits
fertig vor, und alle Tests werden direkt auf der Zielhardware durchgeführt.
ENG.7/ENG.8 und ENG.9/ENG.10 sind dann größtenteils redundant. In der
Assessmentpraxis wird dann in der Regel auf die doppelte Bewertung verzichtet
und Integration und Test nur bei ENG.9/ENG.10 bewertet, und ENG.7/ENG.8
wird als nicht anwendbar (»not applicable«) deklariert. Zu beachten sind dabei
die unterschiedlichen Aspekte der jeweiligen Integrationsstufen: Es müssen die
Testfälle, die auf ENG.4/ENG.5 basieren, in ENG.9/ENG.10 durchgeführt wer-
den, d.h., die Konformität zu den Softwareanforderungen und zur Softwarearchi-
tektur muss nun auf der Systemebene nachgewiesen werden. Geschieht dies nicht,
hat es negative Folgen bei der Bewertung von ENG.9/ENG.10.
62. Verschiedene Elemente des Testplans nach IEEE werden von Automotive SPICE erst auf
Level 2 durch die generischen Praktiken von PA 2.1 adressiert.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required