: Oliver Alt
: Car Multimedia Systeme Modell-basiert testen mit SysML
: Vieweg+Teubner (GWV)
: 9783834895677
: 1
: CHF 43.90
:
: Informatik
: German
: 184
: Wasserzeichen/DRM
: PC/MAC/eReader/Tablet
: PDF
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.
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].
Geleitwort6
Danksagung8
Kurzfassung9
Abstract10
Inhaltsverzeichnis11
Abbildungsverzeichnis15
Einleitung19
Elektronische Systeme im Fahrzeug22
2.1 Architekturüberblick22
2.2 Telematiksystem im Fahrzeug24
2.3 Abgrenzung zu anderen Domänen27
2.4 Bussysteme und Schnittstellen28
2.5 Anwendungsbeispiel36
2.6 Fazit36
Entwicklung und Test im Telematikbereich38
3.1 Entwicklungsprozesse38
3.2 Softwaretest42
3.3 Testverfahren46
3.4 Testbeschreibungssprachen für automatisierte Tests46
3.5 Testumgebung53
3.6 Problematik der heutigen Testpraxis54
3.7 Anforderungen56
3.8 Fazit59
Modellierung und Modell-basiertes Testen60
4.1 Modell-basierte Entwicklung60
4.2 Modell-basierter Test62
4.3 Modellgetriebene Architektur (MDA)62
4.4 Metamodellierung64
4.5 Meta Object Facility (MOF)64
4.6 Modelltransformation66
4.7 Modellierungssprachen70
4.8 Auswahl der Modellierungssprache87
4.9 Werkzeugauswahl88
4.10 Fazit89
Konzeption und Lösungsansatz90
5.1 Rahmenbedingungen91
5.2 Modelltransformation91
5.3 Konzeption des Systemmodells97
5.4 Strukturierung des Modells100
5.5 Modell-basierter Testprozess105
5.6 Formale Beschreibung der Modellstruktur106
5.7 Testdurchführung112
5.8 Verwandte Arbeiten112
5.9 Spezifikation der Testeingabedaten113
5.10 Fazit116
Generierung funktionaler Testfälle118
6.1 Überblick118
6.2 Ansätze zur Testfallgenerierung118
6.3 Generierung funktionaler Testfälle122
6.4 Überdeckungskriterien134
6.5 Diskussion des Verfahrens134
6.6 Fazit138
Generierung produktspezifischer Testfälle140
7.1 Überblick140
7.2 Verwandte Arbeiten140
7.3 Produktspezifische Modellierung141
7.4 Parameteranpassung146
7.5 Gewinnung MOST-spezifischer Informationen aus dem Strukturmodell147
7.6 Äquivalentes Verhalten152
7.7 Transformation zu spezifischen SysML-Testfällen153
7.8 Erzeugung der CANoe.MOST XML-Testmodule161
7.9 Fazit166
Beispiel MOST Audio System168
8.1 Systemmodellierung168
8.2 Testfallgenerierung176
8.3 Fazit179
Zusammenfassung und Ausblick180
9.1 Modellierung von zeitlichem Verhalten183
9.2 Nutzung weiterer SysML-Konzepte183
9.3 Varianten183
9.4 Automatisierte Validierung183
9.5 Linguistische Aspekte bei der Modellerstellung184
Literaturverzeichnis188
Index196