E-Book, Deutsch, 184 Seiten, eBook
Alt Car Multimedia Systeme Modell-basiert testen mit SysML
2009
ISBN: 978-3-8348-9567-7
Verlag: Vieweg & Teubner
Format: PDF
Kopierschutz: 1 - PDF Watermark
E-Book, Deutsch, 184 Seiten, eBook
ISBN: 978-3-8348-9567-7
Verlag: Vieweg & Teubner
Format: PDF
Kopierschutz: 1 - PDF Watermark
Oliver Alt beschreibt sein Verfahren, Testfälle für den Systemtest von Car Multimedia Systemen automatisiert aus einem speziell konzipierten Systemmodell zu generieren. Neue Ansätze sind dabei die durchgängige Modellierung mit Hilfe von Aktivitätsdiagrammen, die Anwendung funktional gleicher Testfälle auf technisch verschiedene Systeme und der Einsatz der Systembeschreibungssprache OMG SysML
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.
Zielgruppe
Research
Autoren/Hrsg.
Weitere Infos & Material
1;Geleitwort;6
2;Danksagung;8
3;Kurzfassung;9
4;Abstract;10
5;Inhaltsverzeichnis;11
6;Abbildungsverzeichnis;15
7;Einleitung;19
8;Elektronische Systeme im Fahrzeug;22
8.1;2.1 Architekturüberblick;22
8.2;2.2 Telematiksystem im Fahrzeug;24
8.3;2.3 Abgrenzung zu anderen Domänen;27
8.4;2.4 Bussysteme und Schnittstellen;28
8.5;2.5 Anwendungsbeispiel;36
8.6;2.6 Fazit;36
9;Entwicklung und Test im Telematikbereich;38
9.1;3.1 Entwicklungsprozesse;38
9.2;3.2 Softwaretest;42
9.3;3.3 Testverfahren;46
9.4;3.4 Testbeschreibungssprachen für automatisierte Tests;46
9.5;3.5 Testumgebung;53
9.6;3.6 Problematik der heutigen Testpraxis;54
9.7;3.7 Anforderungen;56
9.8;3.8 Fazit;59
10;Modellierung und Modell-basiertes Testen;60
10.1;4.1 Modell-basierte Entwicklung;60
10.2;4.2 Modell-basierter Test;62
10.3;4.3 Modellgetriebene Architektur (MDA);62
10.4;4.4 Metamodellierung;64
10.5;4.5 Meta Object Facility (MOF);64
10.6;4.6 Modelltransformation;66
10.7;4.7 Modellierungssprachen;70
10.8;4.8 Auswahl der Modellierungssprache;87
10.9;4.9 Werkzeugauswahl;88
10.10;4.10 Fazit;89
11;Konzeption und Lösungsansatz;90
11.1;5.1 Rahmenbedingungen;91
11.2;5.2 Modelltransformation;91
11.3;5.3 Konzeption des Systemmodells;97
11.4;5.4 Strukturierung des Modells;100
11.5;5.5 Modell-basierter Testprozess;105
11.6;5.6 Formale Beschreibung der Modellstruktur;106
11.7;5.7 Testdurchführung;112
11.8;5.8 Verwandte Arbeiten;112
11.9;5.9 Spezifikation der Testeingabedaten;113
11.10;5.10 Fazit;116
12;Generierung funktionaler Testfälle;118
12.1;6.1 Überblick;118
12.2;6.2 Ansätze zur Testfallgenerierung;118
12.3;6.3 Generierung funktionaler Testfälle;122
12.4;6.4 Überdeckungskriterien;134
12.5;6.5 Diskussion des Verfahrens;134
12.6;6.6 Fazit;138
13;Generierung produktspezifischer Testfälle;140
13.1;7.1 Überblick;140
13.2;7.2 Verwandte Arbeiten;140
13.3;7.3 Produktspezifische Modellierung;141
13.4;7.4 Parameteranpassung;146
13.5;7.5 Gewinnung MOST-spezifischer Informationen aus dem Strukturmodell;147
13.6;7.6 Äquivalentes Verhalten;152
13.7;7.7 Transformation zu spezifischen SysML-Testfällen;153
13.8;7.8 Erzeugung der CANoe.MOST XML-Testmodule;161
13.9;7.9 Fazit;166
14;Beispiel MOST Audio System;168
14.1;8.1 Systemmodellierung;168
14.2;8.2 Testfallgenerierung;176
14.3;8.3 Fazit;179
15;Zusammenfassung und Ausblick;180
15.1;9.1 Modellierung von zeitlichem Verhalten;183
15.2;9.2 Nutzung weiterer SysML-Konzepte;183
15.3;9.3 Varianten;183
15.4;9.4 Automatisierte Validierung;183
15.5;9.5 Linguistische Aspekte bei der Modellerstellung;184
16;Literaturverzeichnis;188
17;Index;196
Elektronische Systeme im Fahrzeug.- Entwicklung und Test im Telematikbereich.- Modellierung und Modell-basiertes Testen.- Konzeption und Lösungsansatz.- Generierung funktionaler Testfälle.- Generierung produktspezifischer Testfälle.- Beispiel MOST Audio System.- Zusammenfassung und Ausblick.
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].
