Car Multimedia Systeme Modell-basiert testen mit SysML (eBook)

Dr. Oliver Alt promovierte am Fachbereich Elektrotechnik und Informationstechnik der Technischen Universität Darmstadt in Kooperation mit der Robert Bosch/Blaupunkt GmbH. Er ist heute als Systemarchitekt für die Continental Teves AG & Co. oHG tätig.

Geleitwort 6
Danksagung 8
Kurzfassung 9
Abstract 10
Inhaltsverzeichnis 11
Abbildungsverzeichnis 15
Einleitung 19
Elektronische Systeme im Fahrzeug 22
2.1 Architekturüberblick 22
2.2 Telematiksystem im Fahrzeug 24
2.3 Abgrenzung zu anderen Domänen 27
2.4 Bussysteme und Schnittstellen 28
2.5 Anwendungsbeispiel 36
2.6 Fazit 36
Entwicklung und Test im Telematikbereich 38
3.1 Entwicklungsprozesse 38
3.2 Softwaretest 42
3.3 Testverfahren 46
3.4 Testbeschreibungssprachen für automatisierte Tests 46
3.5 Testumgebung 53
3.6 Problematik der heutigen Testpraxis 54
3.7 Anforderungen 56
3.8 Fazit 59
Modellierung und Modell-basiertes Testen 60
4.1 Modell-basierte Entwicklung 60
4.2 Modell-basierter Test 62
4.3 Modellgetriebene Architektur (MDA) 62
4.4 Metamodellierung 64
4.5 Meta Object Facility (MOF) 64
4.6 Modelltransformation 66
4.7 Modellierungssprachen 70
4.8 Auswahl der Modellierungssprache 87
4.9 Werkzeugauswahl 88
4.10 Fazit 89
Konzeption und Lösungsansatz 90
5.1 Rahmenbedingungen 91
5.2 Modelltransformation 91
5.3 Konzeption des Systemmodells 97
5.4 Strukturierung des Modells 100
5.5 Modell-basierter Testprozess 105
5.6 Formale Beschreibung der Modellstruktur 106
5.7 Testdurchführung 112
5.8 Verwandte Arbeiten 112
5.9 Spezifikation der Testeingabedaten 113
5.10 Fazit 116
Generierung funktionaler Testfälle 118
6.1 Überblick 118
6.2 Ansätze zur Testfallgenerierung 118
6.3 Generierung funktionaler Testfälle 122
6.4 Überdeckungskriterien 134
6.5 Diskussion des Verfahrens 134
6.6 Fazit 138
Generierung produktspezifischer Testfälle 140
7.1 Überblick 140
7.2 Verwandte Arbeiten 140
7.3 Produktspezifische Modellierung 141
7.4 Parameteranpassung 146
7.5 Gewinnung MOST-spezifischer Informationen aus dem Strukturmodell 147
7.6 Äquivalentes Verhalten 152
7.7 Transformation zu spezifischen SysML-Testfällen 153
7.8 Erzeugung der CANoe.MOST XML-Testmodule 161
7.9 Fazit 166
Beispiel MOST Audio System 168
8.1 Systemmodellierung 168
8.2 Testfallgenerierung 176
8.3 Fazit 179
Zusammenfassung und Ausblick 180
9.1 Modellierung von zeitlichem Verhalten 183
9.2 Nutzung weiterer SysML-Konzepte 183
9.3 Varianten 183
9.4 Automatisierte Validierung 183
9.5 Linguistische Aspekte bei der Modellerstellung 184
Literaturverzeichnis 188
Index 196

3.3 Testverfahren (S. 29-30)

Ein Testfall, um Software zu testen, kann auf unterschiedliche Weise ausgeführt werden. Man unterscheidet dabei manuelles und automatisiertes Testen.

3.3.1 Manuelle Tests

Manuelle Testfälle werden komplett durch einen menschlichen Tester ausgeführt und protokolliert. Der Testfall liegt dabei meist in Form einer textuellen Beschreibung vor. Dies kann ein Textdokument oder eine Prüf- oder Checkliste in Form einer Tabelle sein. Der Tester führt die im Dokument beschriebenen Schritte zum Test des Systems durch und beobachtet die Systemreaktion. Die Testergebnisse protokolliert der Tester meist handschriftlich in den Testdokumenten. Manuelles Testen hat den Vorteil, dass zur Durchführung der Tests keine aufwändigen Systeme zur Teststeuerung notwendig sind, die zunächst richtig kon.guriert werden müssen.

Deshalb kann mit dem Test schnell begonnen werden. Große Nachteile ergeben sich jedoch daraus, dass durch die manuelle Ausführung und Protokollierung eine Reproduzierbarkeit der Testfälle bei wiederholter Ausführung kaum gegeben ist.Weitere Nachteile sind der hohe personelle und zeitliche Aufwand beim manuellen Testen. Durch die handschriftliche Protokollierung der Testergebnisse entsteht außerdem ein Medienbruch im sonst EDV-gestützten Entwicklungsprozess, da die Testergebnisse dann per Hand in das EDV-System zurück übertragen werden müssen.

3.3.2 Automatisierte Tests

Bei automatisiert ablaufenden Tests werden spezielle Testsysteme eingesetzt, die in der Lage sind, Testfälle automatisiert auszuführen. Damit dies möglich wird, müssen diese Testfälle in einer formalen Form vorliegen, beispielsweise einer speziellen Testbeschreibungssprache (siehe Abschnitt 3.4), die das Testsystem interpretieren und ausführen kann. Man unterscheidet beim automatisierten Test zwischen voll- und halbautomatischen Testfällen.

Ein vollautomatischer Testfall kann vollständig ohne Eingriff eines menschlichen Testers Systemfunktionen überprüfen. Solche Testfälle können dadurch die Produktivität im Testprozess stark erhöhen, weil sie zum Beispiel jede Nacht laufen können und den aktuellen Stand der Software überprüfen. Bei halbautomatischer Testausführung werden nicht alle nötigen Schritte während des Testens vollautomatisch erledigt. So kann beispielsweise die ¨ Uberprüfung der Systemreaktion auf eine automatisch ausgelöste Bedienung durch einen Tester erfolgen, der vom Testsystem gestellte Fragen beantwortet. Dabei werden die Antworten auf die Fragen (Ja oder Nein) automatisch protokolliert und dem Testergebnis hinzugefügt.

Gerade bei Systemen mit Mensch- Maschine-Schnittstelle (HMI) und Audio- und Videoausgaben ist eine automatisierte Bewertung der Testfälle nur mit erheblichem Aufwand, beispielsweise per Mustererkennung zu realisieren. Durch halbautomatisches Testen können Medienbrüche vermieden werden und gleichzeitig lässt sich die Testautomation nach und nach erhöhen. 3.4 Testbeschreibungssprachen fürautomatisierte Tests Formale Beschreibungssprachen für Testfälle ermöglichen eine automatisierte Testausführung. Es existiert heutzutage eine ganze Reihe von solchen Testbeschreibungssprachen. Innerhalb dieses Abschnittes erfolgt eine Betrachtung der standardisierten Testbeschreibungssprachen TTCN-3, dem UML2 Testing Pro.le sowie der speziellen XML-Testbeschreibung für dasWerkzeug CANoe der Fa. Vector Informatik.

Dieses Werkzeug stellt im Bereich der Automobil- und Telematikentwicklung einen Quasi-Standard dar und wird daher hier näher betrachtet. Neben diesen Testbeschreibungssprachen existieren noch diverse weitere, nicht-standardisierte Eigenentwicklungen (z.B. [BBr04]), die für verschiedene spezielle Einsatzzwecke optimiert sind. Natürlich ist es auch denkbar, Testfälle in einer Programmiersprache, wie z.B. Java, C++ oder VisualBasic zu erstellen.

Der Nachteil dabei ist allerdings, dass diese Sprachen von Haus aus keine speziellen Konstrukte für das Testen mitbringen, beispielsweise Vergleich eines Wertes mit einem Toleranzbereich u.ä. Daher müssen beim Einsatz von Programmiersprachen diese Konstrukte selbst als Bibliothek hinzugefügt werden. Ein Beispiel eines solchen Rahmenwerkes für MOST-Systeme ist das Produkt MOST Studio der Firma K2L [K2L07].