View
223
Download
3
Category
Preview:
Citation preview
Methodisches und automatisiertes Testen
von Kfz-Steuergerate-Software
Von der Fakultat Konstruktions-, Produktions- und Fahrzeugtechnik
der Universitat Stuttgart
zur Erlangung der Wurde eines Doktor-Ingenieurs (Dr.-Ing.)
genehmigte Abhandlung
vorgelegt von
Carsten Paulus
aus Stuttgart/Bad Cannstatt
Hauptberichter: Prof. Dr.-Ing. Hans-Christian Reuss
Mitberichter: Prof. Dr. Dr. h.c. Manfred Broy
Tag der mundlichen Prufung: 14.10.2011
Institut fur Verbrennungsmotoren und Kraftfahrwesen
Universitat Stuttgart
2011
Vorwort
Die vorliegende Arbeit entstand wahrend meiner Tatigkeit als wissenschaft-
licher Mitarbeiter am Forschungsinstitut fur Kraftfahrwesen und Fahrzeug-
motoren Stuttgart in Zusammenarbeit mit der ZF Friedrichshafen AG.
Mein besonderer Dank gilt Herrn Prof. Dr.-Ing. Hans-Christian Reuss fur
die Betreuung der Arbeit. Bei Herrn Prof. Dr. Dr. h.c. Manfred Broy moch-
te ich mich fur die freundliche Ubernahme des Mitberichts bedanken.
Dank gebuhrt an dieser Stelle auch Herrn Peter Feulner, Herrn Michael
Wolff und Herrn Udo Gillich, welche das der Arbeit zugrundeliegende Pro-
jekt seitens der ZF Friedrichshafen AG erst moglich gemacht haben. Ferner
mochte ich mich bei Herrn Dr.-Ing. Gerd Baumann bedanken, welcher mei-
ne Arbeit seitens des FKFS unterstutzt und gefordert hat.
Ein weiterer Dank gilt meinen Kollegen am FKFS und bei der ZF Fried-
richshafen AG, welche mich im Laufe der Arbeit immer wieder motiviert
und auf neue Gedanken gebracht haben.
Danken mochte ich auch meinen Diplomanden und Praktikanten Tobias
Bollmann, Ricard Lou, Ping Zheng und Nico Gau.
Ferner mochte ich meinen Korrekturlesern danken, insbesondere Frau Ste-
fanie Korte.
Zu guter Letzt mochte ich meiner Familie danken, meinen Eltern Edith
und Gerd Paulus, die mich immer begleiten. Ein herzlicher Dank gebuhrt
meiner Frau Jana fur die Unterstutzung und das Verstandnis, welches sie
mir wahrend dieser Arbeit entgegengebracht hat.
Friedrichshafen, Oktober 2011 Carsten Paulus
3
Inhaltsverzeichnis
Abkurzungsverzeichnis 8
Kurzfassung 11
Abstract 12
1. Einleitung 13
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2. Methoden und Werkzeuge zum Testen . . . . . . . . . . . . 14
1.3. Beitrag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3.1. Beitrag durch das Framework . . . . . . . . . . . . . 18
1.3.2. Beitrag durch die methodische Testsequenzerstellung 19
1.3.3. Beitrag durch die formale Testbeschreibung . . . . . 20
1.3.4. Beitrag durch die Adaption an die Plattformen . . . 20
1.3.5. Erwarteter Nutzen . . . . . . . . . . . . . . . . . . . 21
1.4. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . 21
2. Prozesse, Methoden und Werkzeuge 22
2.1. Aufgaben und Aufbau der Software . . . . . . . . . . . . . . 22
2.2. Softwareentwicklungs- und Testprozess . . . . . . . . . . . . 23
2.3. Entwicklungsparadigmen . . . . . . . . . . . . . . . . . . . . 27
2.3.1. Steuerungs- und regelungstechnische Aspekte . . . . 27
2.3.2. Kommunikation . . . . . . . . . . . . . . . . . . . . . 28
2.3.3. Berucksichtigung der Hardware . . . . . . . . . . . . 28
2.3.4. Programmierung . . . . . . . . . . . . . . . . . . . . 29
2.4. Modelle in der Softwareentwicklung . . . . . . . . . . . . . . 30
2.4.1. Unified Modeling Language . . . . . . . . . . . . . . 31
2.4.1.1. Klassendiagramm . . . . . . . . . . . . . . . 31
2.4.1.2. Zustandsdiagramm . . . . . . . . . . . . . . 32
2.4.2. Extensible Markup Language . . . . . . . . . . . . . 33
2.4.3. Generative Programmierung . . . . . . . . . . . . . . 34
2.4.3.1. Model Driven Architecture . . . . . . . . . 34
4
2.4.3.2. Model Driven Software Development . . . . 35
2.4.3.3. Nutzen der Vorgehensweise . . . . . . . . . 37
2.4.4. Relevanz fur den Test . . . . . . . . . . . . . . . . . 38
2.5. Potenzielle Softwarefehler . . . . . . . . . . . . . . . . . . . 39
2.6. Testentwurfsmethoden . . . . . . . . . . . . . . . . . . . . . 40
2.6.1. Statische Testentwurfsmethoden . . . . . . . . . . . . 41
2.6.2. Dynamische Testentwurfsmethoden . . . . . . . . . . 42
2.6.3. White-box Testentwurfsmethoden . . . . . . . . . . . 43
2.6.3.1. Kontrollflussbezogene Kriterien . . . . . . . 43
2.6.3.2. Datenflussbezogene Kriterien . . . . . . . . 46
2.6.3.3. Bewertung . . . . . . . . . . . . . . . . . . 46
2.6.4. Black-box Testentwurfsmethoden . . . . . . . . . . . 48
2.6.4.1. Aquivalenzklassenbildung . . . . . . . . . . 49
2.6.4.2. Auswahlstrategien . . . . . . . . . . . . . . 50
2.6.4.3. Zustandsbasierter Test . . . . . . . . . . . . 58
2.6.4.4. Erfahrungsbasiertes Testen . . . . . . . . . 58
2.7. Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . 58
3. Testframework 61
3.1. Artefakte aus dem Entwicklungsprozess . . . . . . . . . . . . 61
3.1.1. Strukturartefakte . . . . . . . . . . . . . . . . . . . . 61
3.1.2. Verhalten . . . . . . . . . . . . . . . . . . . . . . . . 62
3.1.3. Daten . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.2. Technologische Realisierung . . . . . . . . . . . . . . . . . . 63
3.2.1. Das Testspezifikations-Meta-Modell . . . . . . . . . . 65
3.2.2. Das Testbericht Meta-Modell . . . . . . . . . . . . . 68
3.2.3. Codegenerierung . . . . . . . . . . . . . . . . . . . . 70
3.2.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . 71
4. Leitanwendung 73
4.1. Physikalische Grundlagen . . . . . . . . . . . . . . . . . . . 73
4.2. Software-Design und Implementierung . . . . . . . . . . . . 76
4.2.1. Klassendiagramm . . . . . . . . . . . . . . . . . . . . 76
4.2.2. Zustandsdiagramm . . . . . . . . . . . . . . . . . . . 78
4.3. Testausfuhrungsplattform . . . . . . . . . . . . . . . . . . . 79
4.4. Aufgaben fur die Testimplementierung . . . . . . . . . . . . 80
5
5. Heuristik zur modellbasierten Testsequenzgenerierung 81
5.1. Prinzip der Testsequenzgenerierung aus Zustandsmaschinen . 82
5.1.1. Generierungsstrategien . . . . . . . . . . . . . . . . . 83
5.1.2. Auffindbare Fehler . . . . . . . . . . . . . . . . . . . 83
5.1.3. Auswahl einer Strategie zur Testsequenzgenerierung . 84
5.1.4. Umgang mit erweiterten endlichen Zustandsmaschinen 85
5.1.4.1. Auflosen von Hierarchie . . . . . . . . . . . 86
5.1.4.2. Auflosen von Orthogonalitat . . . . . . . . . 86
5.2. Integration in das Framework . . . . . . . . . . . . . . . . . 88
5.2.1. Allgemeine Schnittstelle der Heuristik . . . . . . . . . 88
5.2.2. Verfugbare Artefakte der Leitanwendung . . . . . . . 92
5.2.3. Konzeption des Exchange-Meta-Modells . . . . . . . 93
5.2.4. Instanziierung der Leitanwendung . . . . . . . . . . . 94
5.3. Heuristik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.3.1. Bedatung . . . . . . . . . . . . . . . . . . . . . . . . 97
5.3.2. Berechnung der Initialisierungs-Testsequenz . . . . . 100
5.3.3. Berechnung der Transitionsuberdeckung . . . . . . . 102
5.3.4. Vervollstandigung der Transitionsfolgen . . . . . . . . 105
5.3.4.1. Umgang mit Superzustanden . . . . . . . . 106
5.3.4.2. Umgang mit orthogonalen Zustanden . . . . 109
5.3.5. Zusammenfassung der strukturellen Aspekte . . . . . 114
5.3.6. Synthese von Bedatung und Struktur . . . . . . . . . 114
5.4. Uberfuhren der Testspezifikation in ausfuhrbaren Code . . . 119
5.5. Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6. Einsatz des Testframeworks 124
6.1. Methoden und deren Einbindung . . . . . . . . . . . . . . . 125
6.2. Formale Testspezifikation und Transformation . . . . . . . . 128
6.3. Nutzen und Potenziale . . . . . . . . . . . . . . . . . . . . . 130
7. Zusammenfassung und Ausblick 131
A. Algorithmen zur Testsequenzinitialisierung 134
A.1. Dijkstra-Algorithmus . . . . . . . . . . . . . . . . . . . . . . 136
B. Entwicklung des Algorithmus zur Transitionsuberdeckung138
6
Abbildungsverzeichnis 141
Tabellenverzeichnis 142
Literaturverzeichnis 144
7
Abkurzungsverzeichnis
Abkurzungen
ATML Automatic Test Markup Language
CASE Computer-Aided Software Engineering
COM Component Object Model
DSL Domain Specific Language
EGS Elektronische Getriebesteuerung
EMF Eclipse Modeling Framework
FUT Function Under Test
HIL Hardware-In-The-Loop
IDE Integrated Development Environment
MDA Model Driven Architecture
MDSD Model Driven Software Development
MIL Model-In-The-Loop
MISRA The Motor Industry Software Reliablity Association
MM Meta-Modell
MOF Meta Object Facility
oAW open Architecture Ware
OMG Object Management Group
RCP Rapid Control Prototyping
SIL Software-In-The-Loop
SMUT State-Machine Under Test
SUT System Under Test
TS-MM Testspezifikations-Meta-Modell
UML Unified Modeling Language
8
UML Unified Modeling Language
XML Extensible Markup Language
Formelzeichen
F Menge der Faktoren Fi, welche den Eingangsgroßen des
SUT entsprechen
Li Menge der Level l, welche einem Faktor Fi zugeordnet
sind
O Auswahlmatrix
EM Testmodell EM = 〈SM,S, T,R,W 〉SM Wurzelelement der Zustandsmaschine
S Menge der Zustande s der Zustandsmaschine
T Menge der Transitionen t der Zustandsmaschine
R Menge der Regionen r der Zustandsmaschine
W Menge der WerteBereich-Elemente w des Testmodells
E Menge von Ereignissen e. Die Ereignisse ES sind einem
Zustand zugeordnet, die Ereignisse ET einer Transition
G Menge von Guard-Bedingungen g. Die Guard-Bedin-
gungen GS sind einem Zustand zugeordnet, die Guard-
Bedingungen GT einer Transition
A Menge von Aktionen a. Die Aktionen AS sind einem Zu-
stand zugeordnet, die Aktionen AT einer Transition
VS Verhaltensspezifikation eines Zustandes
VT Verhaltensspezifikation einer Transition
B Menge von Bedatungskombinationen b
9
Mengenoperationen
A ⊆ B A ist Teilmenge von B
card (A) oder
|A|Kardinalzahl der Menge A, sie bezeichnet die Anzahl der
Elemente einer endlichen Menge
A ∪B Vereinigung der Mengen A und B. A ∪B = {x|x ∈ A ∨x ∈ B}. Es werden keine doppelten Elemente zugelassen
A ∩B Durchschnitt der Mengen A und B. A ∩ B = {x|x ∈A∧x ∈ B}, entspricht den gemeinsamen Elementen der
beiden Mengen
A ∩B = ∅ Die Mengen A und B sind disjunkt, sie haben kein ge-
meinsames Element
A \B Differenz der Mengen A und B. A \B = {x|x ∈ A∧ x /∈B}. Beispiel {1, 2, 3, 4} \ {3, 4, 5} = {1, 2}
A×B Kartesisches Produkt zweier Mengen. A × B =
{(a, b)|a ∈ A ∧ b ∈ B}A1 × · · · × An n-faches Kartesisches Produkt. A1 × · · · × An =
{(a1, · · · , an)|ai ∈ Ai (i = 1, · · · , n)}
Sonstige
bxc Gaußklammer: maxk∈Z,k≤x(k). Dabei ist k die großte
ganze Zahl, welche kleiner oder gleich x ist
x mod y Ganzzahliger Rest der Divisison. x mod y = x−⌊xy
⌋· y
10
Kurzfassung
Moderne Fahrzeuge beinhalten eine stetig wachsende Vielzahl von mecha-
tronischen Systemen, deren Verhalten durch Steuergerate bestimmt wird.
Die Innovationen in der Fahrzeugtechnik werden also in immer großerem
Maße durch die Software dieser Steuergerate gepragt.
Der wachsende Innovationsdruck, einhergehend mit immer kurzer werden-
den Entwicklungszeiten, fordert die Hersteller auf, qualitativ hochwerti-
ge Software immer effektiver zu erstellen. Zur Beherrschung der Kom-
plexitat werden formale Entwicklungsprozesse definiert, um den Software-
Entwicklern und Testern das Zusammenspiel der Arbeitsschritte vorgeben
zu konnen.
Der Fokus der vorliegenden Arbeit liegt auf dem Testen von Kfz-Steuer-
gerate-Software im Rahmen der Software-Entwicklung eines Automobilzu-
lieferers.
In der Praxis gibt es verschiedene Moglichkeiten, die formalen Entwick-
lungsprozesse umzusetzen. Haufig werden fur die Erfullung gleicher Ar-
beitsschritte unterschiedliche, nicht notwendigerweise kompatible Software-
werkzeuge verwendet.
Es hat sich gezeigt, dass Testentwurfsmethoden implizit und intuitiv ange-
wendet werden. Der Einsatz von Werkzeugen zur Unterstutzung der Tester
scheitert entweder an einer fehlenden Implementierung oder daran, dass ein
gegebenes Werkzeug nicht in die vorgegebene Entwicklungslandschaft in-
tegriert werden kann.
Um diesem Umstand entgegenzuwirken, wird im Rahmen der vorliegen-
den Arbeit ein Testframework konzipiert, welches die nahtlose Integration
unterschiedlicher Testfallerstellungswerkzeuge in den Entwicklungsprozess
ermoglicht. Ferner wird eine Heuristik entwickelt, welche die automatisierte
Erstellung von Testfallen fur zustandsbasiertes Verhalten erleichtert.
11
Abstract
Modern vehicles contain an increasing multitude of mechatronic systems,
whose behavior is determined by electronic control units. Hence innova-
tions in cars are more and more influenced by the software within these
control units.
The increasing pressure to innovate in combination with decreasing prod-
uct life-cycles and development times, requires manufacturers to produce
high-quality software more effectively. To handle the ensuing complexity,
software development-processes have been established to define the inter-
action of tasks for software developers and testers.
The focus of this thesis is the testing of electronic-control-unit software at
an automotive supplier.
In practice there are various possibilities to fulfill the development-process.
In most cases, there can be found different, but not necessarily compatible
software-tools to handle the same tasks.
It showed out, that test design methods are applied implicitly and intu-
itively. The use of test-tools to assist the tester fails due to either the lack
of implementation of a required method or due to the fact that an available
tool cannot be integrated into an established development-environment.
To handle these problems, this thesis develops a framework, which en-
ables the seamless integration of different test-tools into the development-
environment. Furthermore a heuristic method is developed, which fa-
cilitates the automated generation of test-cases for state-based software-
behavior.
12
1. Einleitung
Das Ziel der vorliegenden Arbeit ist es einen Ansatz aufzuzeigen, um die
Qualitat und Effizienz in der Softwareentwicklung zu steigern. Dazu wird
die methodische Testsequenzerstellung in den Softwareentwicklungsprozess
eines Automobilzulieferers integriert.
1.1. Motivation
Heutzutage sind bis zu 90 % der Innovationen eines modernen Fahrzeuges
durch Elektronik gepragt [47]. Die eigentlichen Funktionen der Elektronik
sind dabei durch Software implementiert. Dadurch wird diese zunehmend
zum bestimmenden Faktor fur die Qualitat und Sicherheit des gesamten
Fahrzeuges.
Der zunehmende Innovations- und Kostendruck bedingt, dass neue, kom-
plexere Funktionen in immer kurzerer Zeit zur Serienreife gebracht werden
mussen. Um die Qualitats- und Sicherheitsanforderungen, wie sie beispiels-
weise durch die IEC 61508 gefordert werden, zu erfullen und die Komplexi-
tat der Softwareentwicklung beherrschen zu konnen, werden Referenzmo-
delle, wie Automotive-Spice [37], und Vorgehensmodelle, wie das allgemeine
V-Modell [14], eingefuhrt.
Im Rahmen der Entwicklung mussen bis zu 50 % des Gesamtaufwandes fur
den Test der Software eingesetzt werden [52]. Eine Optimierung des Test-
prozesses hat daher ein hohes Einsparpotenzial. Der Testprozess besteht
nach [52] aus den funf Phasen Testmanagement, Testspezifikation, Testaus-
fuhrung, Testprotokollierung und Testauswertung. In der Praxis zeigt sich
oft, dass der Aufbau und die Wartung der Testinfrastruktur einen großen
Teil der Entwicklungs- und Test-Kapazitiat beanspruchen. Basierend auf
einer lauffahigen Testinfrastruktur beziehen sich die meisten Ansatze zur
Minimierung des Testaufwandes bis jetzt auf die Automatisierung der Test-
ausfuhrung. Dabei werden fur die jeweils verwendeten Testausfuhrungs-
plattformen Automatisierungsskripte geschrieben. Die Testinhalte sind da-
13
bei in plattformspezifischen Codeartefakten verborgen und konnen haufig
nur von Experten verstanden werden. Eine Modifikation oder der Wech-
sel der Ausfuhrungsplattform fuhrt dazu, dass die Testskripte angepasst
werden mussen. Durch die Automatisierung der Bereitstellung der Testin-
frastruktur und der Testausfuhrung lasst sich eine Effizienzsteigerung im
Test erzielen.
Der Testinhalt und damit die Fahigkeit einer Testsequenz, bestimmte Feh-
ler aufzudecken, wird jedoch in der Testspezifikation festgelegt. In der Theo-
rie existieren verschiedene Methoden zum Testentwurf, welche die Soft-
waretester in dieser Phase unterstutzen. Ein Einsatz dieser Methoden in
der Praxis scheitert oft daran, dass sie entweder den Entwicklern unzurei-
chend bekannt sind, nicht als Software-Werkzeug realisiert sind, oder das
implementierte Software-Werkzeuge nicht in die vorhandene Entwicklungs-
landschaft integriert sind. Die Steigerung der Test-Qualitat kann also durch
die Integration von Testentwurfsmethoden in den Entwicklungsprozess er-
zielt werden.
Aus dieser Betrachtung ergeben sich die Eingriffsmoglichkeiten, um eine
Qualitats- und Effizienzsteigerung im Test und damit in der Softwareent-
wicklung zu erzielen:
1. Die Einbindung von Testentwurfsmethoden in den Entwicklungspro-
zess.
2. Die Unterstutzung bei der Bereitstellung der Testinfrastruktur.
3. Die plattformunabhangige Abstraktion der Testinhalte, und die Un-
terstutzung diese auf verschiedenen Testausfuhrungsplattformen au-
tomatisiert ausfuhren zu konnen.
1.2. Methoden und Werkzeuge zum Testen
Im Rahmen der Einbindung von Testentwurfsmethoden in den Entwick-
lungsprozess sind bereits Software-Werkzeuge entstanden, eine Auswahl
dieser wird im Folgenden vorgestellt. Um die Werkzeuge klassifizieren zu
konnen, wird im Vorgriff auf den Abschnitt 2.6 eine kurze Einfuhrung der
Testentwurfsmethoden gegeben.
14
Das Testen von Software kann statisch oder dynamisch erfolgen. Im stati-
schen Fall wird die Software ohne eine Ausfuhrung gepruft, beispielsweise
durch formale Reviews. Beim dynamischen Test wird die Software aktiv
stimuliert. Die Art und Weise, wie die Stimuli ausgewahlt werden, also wie
die Testfalle aufgebaut sind, kann basierend auf der Kenntnis der Imple-
mentierung erfolgen: Es handelt sich dann um white-box oder strukturelle
Testentwurfsmethoden. Wenn die Testfalle aus der Kenntnis der Spezifika-
tion der Software ausgewahlt werden, handelt es sich um black-box oder
funktionale Testentwurfsmethoden.
Die white-box Testentwurfsmethoden werden anhand des Testziels der Test-
falle untergliedert. So wird, ohne Anspruch auf Vollstandigkeit, zwischen
einer Anweisungs-, Zweig-, Bedingungs- und Pfaduberdeckung unterschie-
den. Beispielsweise werden bei dem Ziel der Erreichung einer Anweisungs-
uberdeckung die Stimuli so gewahlt, dass alle Anweisungen mindestens
einmal ausgefuhrt werden.
In der Praxis wird in der Prozess-Phase Testmanagement ein fur das zu
testende Artefakt zu erreichender Uberdeckungsprozentsatz und das Uber-
deckungskriterium formuliert. Wahrend die Stimuli großteils manuell durch
Testskripte erzeugt werden, kann die erreichte Uberdeckung der Implemen-
tierung durch Softwarewerkzeuge gemessen werden.
Ein Ansatz zur automatisierten Generierung von white-box Tests wird
durch [39] vorgestellt. Dabei werden basierend auf der Kenntnis des Quell-
codes automatisch Teststimuli generiert, welche zu einer vorgegebenen Co-
deuberdeckung fuhren.
Wichtige Vertreter der black-box Testentwurfsmethoden sind die Aquiva-
lenzklassenbildung und die Grenzwertanalyse. Davon ausgehend, dass die
Uniformitatshyphotese gilt und sich das System fur eine bestimmte Aqui-
valenzklasse von Eingabewerten gleich verhalt, werden die Eingabepara-
meter eines Systems diesen Klassen zugeordnet. Die Ubergange zwischen
den Aquivalenzklassen sind Grenzwerte, welche haufige Fehlerquellen sind.
Die 1993 vorgestellte Klassifikationsbaummethode [29] stellt einen Ansatz
zur Systematisierung der Findung von Aquivalenzklassen und Grenzwer-
ten dar, durch deren Kombination verschiedene Testfalle bestimmt werden
konnen. Die theoretischen Grundlagen werden durch das Werkzeug CTE-
XL [24] implementiert.
15
Ferner sind im Rahmen der black-box Testentwurfsmethoden unter dem
Schlagwort modellbasiertes Testen eine Vielzahl von Ansatzen entstanden.
Diese ziehen analog zu den white-box Testentwurfsmethoden die Struktur
des zugrunde gelegten Verhaltensmodells der Software als Basis fur die
Testsequenzauswahl heran. Dieser Vorgang lasst sich algorithmisch auto-
matisieren.
Ein wesentliches Unterscheidungsmerkmal der Ansatze zum modellbasier-
ten Testen ist das zugrunde liegende Modell. Eine Klasse von Ansatzen
basiert z. B. auf einer Modellierung durch Endliche Zustandsmaschinen
(Finite State Machines - FSM). Im Rahmen der Forschung der Firma Mi-
crosoft ist dabei das Werkzeug specExplorer [21] entstanden, welches mitt-
lerweile in einigen Teilen des Konzerns eingesetzt wird. Das Modell der zu
testenden Software wird dabei durch die dafur entwickelte Sprache Spec#
beschrieben. Andere Ansatze setzen Beschriftete Ubergangssysteme (Labe-
led Transition Systems - LTS) voraus. Eine kommerzielle Implementierung
dieser Vorgehensweise stellt die Firma Conformiq zur Verfugung [22]. Eine
weitere Modellierungsform beruht auf Erweiterten endlichen Zustandsma-
schinen (Extended Finite State Machines - EFSM) nach Harel [31], welche
in modernen Modellierungssprachen Verwendung finden, wie UML oder
MATLAB/SIMULINK.
Die grundsatzlich zu beachtenden Aspekte beim modellbasierten Testen
werden in [44] aufgefuhrt. Wenn eine automatische Verdiktbildung statt-
finden soll, darf das Modell, aus welchem die Testfalle abgeleitet werden,
nicht das Gleiche sein, wie das Modell, aus welchem die Implementierung
abgeleitet wird. Andernfalls wurde nur der Codegenerator gepruft. Es ent-
stunden also keine Testfalle, welche einen großeren als den im Modell defi-
nierten Einblick in die Funktion bieten.
In [36] wird ein systematischer Ansatz erarbeitet, welcher das in der Spra-
che Auto Focus beschriebene Modell der Implementierung in ein Analy-
semodell uberfuhrt. Die Informationen aus dem Analysemodell werden in
ein Constraint-Logik Programm uberfuhrt. Basierend auf dieser Darstel-
lung werden Testsequenzen berechnet. Die innerhalb der Zustandsmaschi-
nen auftretenden Transitionen sind an Parameter gebunden, welche durch
Aquivalenzklassen und Grenzwerte aufgeteilt werden konnen. Um dies zu
16
systematisieren, wird der Klassfikationsbaumeditor CTE-XL in den Ansatz
eingebunden.
Im Rahmen der Arbeit [20] wird vorgeschlagen, als Modellierungs-
sprache die UML zu verwenden, insbesondere UML-Protokollzustands-
automaten. Auch nebenlaufige Funktionen, welche durch die Protokoll-
zustandsautomaten beschrieben werden konnen, werden in die Testse-
quenzerstellung mit einbezogen. Dazu wird ein mehrstufiger Prozess durch-
laufen. Zunachst wird das UML-Modell in eine Datenstruktur eingelesen.
Orthogonale Zustande werden in einen Produktautomaten uberfuhrt, wel-
cher das Verhalten in einer flachen Struktur beschreibt. Die Testsequenz-
erstellung erfolgt durch Graphentraversierungsalgorithmen (Tiefen- und
Breitensuche).
Haufig scheitert der effiziente Einsatz vorhandener Software-Werkzeuge
daran, dass Informationen aus dem Entwicklungsprozess erneut eingegeben
werden mussen und methodisch erstellte Testfalle im Rahmen der vorge-
gebenen Entwicklungslandschaft nicht maschinell weiterbearbeitet werden
konnen. Zudem zeigt die vorliegende Aufzahlung verschiedener Software-
Werkzeuge, dass insbesondere Werkzeuge zum modellbasierten Testen eige-
ne Modellierungssprachen voraussetzen, welche fur den Einsatz unter den
Anwendern etabliert werden mussen.
1.3. Beitrag
Um die in Abschnitt 1.1 beschriebenen Eingriffsmoglichkeiten fur die
Effizienz- und Qualitatssteigerung im Softwareentwicklungsprozess zu nut-
zen, wird im Rahmen der vorliegenden Arbeit ein Framework erarbei-
tet, welches konzeptionell und technologisch die Integration verschiedener
black-box Testentwurfsmethoden in den Entwicklungsprozess ermoglicht.
Dabei wird sowohl die Bereitstellung der Testinfrastuktur als auch die Ab-
straktion und automatische Ausfuhrung der Testinhalte unterstutzt. Ferner
wird eine Heuristik zum modellbasierten Testen eingefuhrt, welche durch
das Framework an die in der Entwicklungslandschaft verwendeten Model-
lierungssprachen angepasst werden kann.
17
Das Framework besteht dabei aus drei Schichten:
Methodenschicht: Methoden zum Testentwurf werden integriert. Durch
Transformationsregeln konnen entweder kommerzielle oder im Rah-
men der Arbeit entstandene Testsequenzerstellungswerkzeuge initia-
lisiert werden. Ausgabe dieser Schicht sind abstrakte, formalisierte
Testbeschreibungen.
Formale Testbeschreibung: Durch Transformationsregeln werden die
Testbeschreibungen unterschiedlicher Herkunft in eine einheitliche
formale Testbeschreibung uberfuhrt. Diese dient zur Kommunikation
der eigentlichen Testinhalte und kann beispielsweise durch Bedatung
weiter konkretisiert werden.
Adaption an Ausfuhrungsplattformen: Die formal beschriebenen
Testfalle werden mit Hilfe einer weiteren Transformation an die
jeweils vorgesehene Testausfuhrungsplattform angepasst.
1.3.1. Stand der Technik und Beitrag
durch das Framework
Die generelle Struktur einer solchen Integration zeichnet sich in ahnli-
cher Form in verschiedenen Veroffentlichungen ab. So zeigt [30] einen An-
satz auf, welcher aus den Werkzeugen CTE und TPT (Time-Partition-
Testing [34]) erstellte Testfalle entgegennimmt und diese in die Sprache
TTCN-3 transformiert, um diese dann zur Ausfuhrung zu bringen. Das von
der Firma Leirios erarbeitete Werkzeug Leirios Testgenerator, dessen Me-
thode neben anderen Ansatzen in [54] ausfuhrlich beschrieben ist, beruht
auf UML-Modellen und generiert die Testfalle in einem speziellen XML-
Schema. In [48] wird ein kaskadiertes, MDA (Model Driven Architecture)
basiertes Vorgehen beschrieben. Dabei wird fur die Domane GUI-Testen
(Graphical User Interface) eine domanenspezifische Sprache zur Formu-
lierung der Testinhalte erarbeitet, welche durch Transformation auf einer
spezifischen Plattform zur Ausfuhrung gebracht wird. Fur die Implemen-
tierung wird openArchitectureWare (oAW) [1], eine Open Soruce Imple-
mentierung der MDA, verwendet.
18
Das im Rahmen der Arbeit entstandene Framework geht konzeptionell uber
diese Ansatze hinaus, indem es zur Initialisierung der Testsequenzerstel-
lungswerkzeuge Informationen aus dem Entwicklungsprozess verwendet.
Es basiert ebenfalls auf der MDA und verwendet fur die Implementierung
oAW. Ein Beitrag besteht darin, die Konzepte fur das Einsatzgebiet der
automobilen Software-Entwicklung zu adaptieren.
1.3.2. Stand der Technik und Beitrag
durch die methodische Testsequenzerstellung
Um den Einsatz des modellbasierten Testens zu ermoglichen, wird inner-
halb des Frameworks eine Heuristik entwickelt, welche es dem Testinge-
nieur ermoglicht, die Testsequenzgenerierung intuitiv zu steuern. Die Ziel-
setzung ist hierbei ein Migrationsszenario, welches einen iterativen Aufbau
der automatisch generierten Testspezifikation ermoglicht, um den Einblick
und das Vertrauen in die zugrundeliegenden Algorithmen zu starken. Wah-
rend bei den bekannten Ansatzen, basierend auf UML-Zustandsmaschinen,
die Strukturierungselemente Hierarchie und Parallelitat zunachst aufgelost
werden, wird im Rahmen der vorliegenden Arbeit ein expliziter Erhalt die-
ser Strukturierung angestrebt. Diesem Vorgehen liegt die Annahme zu-
grunde, dass die Entwicklungsingenieure mit dem Einsatz der Strukturie-
rung spezifische Aufgabenaspekte der Implementierung im Fokus haben.
Wenn diese durch die Testsequenzgenerierung verloren gehen, ist es nur mit
großem Aufwand moglich aufzuzeigen, welchen Bezug die Testsequenzen zu
dem Testmodell haben.
Mit Hierarchie wird folgendermaßen umgegangen: Die Heuristik identifi-
ziert den Initialknoten der hierarchisch untergeordneten Zustandsmaschi-
ne und behandelt diese als unabhangiges Modell fur die Testsequenzgene-
rierung. Ferner identifiziert die Heuristik die strukturellen Verknupfungen
des hierarchischen Unterzustandes und ermoglicht somit die Erstellung der
Testsequenzen fur das Gesamtsystem. Die aus dem ursprunglichen Modell
vorgegebene Hierarchie wird dadurch in den generierten Testfallen beibe-
halten, wodurch dem Testingenieur die gezielte Zuordnung von Testsequenz
zu Testmodell ermoglicht wird.
19
Wahrend ein gebrauchlicher Ansatz zum Umgang mit Orthogonalitat in-
nerhalb eines UML-Zustandsmaschinen fur die Testsequenzgenerierung
darin besteht, alle moglichen Zustandskombinationen (Konfigurationen) zu
bestimmen, wird dieses Kombinationsproblem im Rahmen der Arbeit neu-
artig gelost.
1.3.3. Stand der Technik und Beitrag
durch die formale Testbeschreibung
Durch die plattformunabhangige Beschreibung der Testspezifikation ergibt
sich die Moglichkeit, diese auf unterschiedlichen Teststufen zur Ausfuhrung
zu bringen. Die Testentwurfsmethoden konnen also bedarfsgerecht in ver-
schiedenen Entwicklungsphasen eingesetzt werden. Im Rahmen der Arbeit
wird ein proprietares XML-Schema fur die Beschreibung der Testspezifi-
kation verwendet. Derzeit sind aber verschiedene Standardisierungsvorha-
ben in Arbeit. So wird im Rahmen der Herstellerinitiative Software [8] ein
XML-basiertes Testaustauschformat erarbeitet. Innerhalb der IEEE wird
unter der Abkurzung ATML (Automatic Test Markup Language) [3] an
dem Standard IEEE 1671 gearbeitet.
Durch den Einsatz eines solchen Testaustauschformates konnen Testbiblio-
theken aufgebaut werden und ein gezieltes wiederverwenden von Testse-
quenzen wird moglich. Erfahrungswissen der Tester kann in diesen Biblio-
theken ebenfalls abgelegt werden. Der Einsatz einer formalen Beschreibung
ermoglicht es, die im Laufe der Zeit erarbeiteten Best-Practices beim Tes-
ten zu formalisieren und zu konservieren.
Es bleibt zu berucksichtigen, dass die Testbibliotheken vor dem Einsatz
in einem geanderten Kontext, ahnlich wie bei der komponentenbasierten
Softwareentwicklung, auf ihre Eignung hin zu prufen sind.
1.3.4. Stand der Technik und Beitrag durch die
Adaption an die Ausfuhrungsplattformen
Abhangig von der Teststufe kommen unterschiedliche Testausfuhrungs-
plattformen zum Einsatz. Nicht selten werden die Automatisierungsskripte
20
einer spezifischen Ausfuhrungsplattform auch noch projektspezifisch vari-
iert. Ein Standard-Codegenerator ist damit in der Praxis kaum realisierbar.
Im Rahmen des Frameworks wird die Plattformadaption durch ei-
ne Modell-zu-Code Transformation realisiert. Dabei ist es moglich,
ausfuhrungsplattform- und projektspezifische Testskriptvorlagen anzule-
gen, welche durch Transformationsregeln mit den in der formalen Test-
beschreibung erfassten Informationen erganzt werden.
1.3.5. Erwarteter Nutzen
Durch den Einsatz des Testframeworks wird die werkzeuggestutzte metho-
dische Testsequenzerstellung im Rahmen der vorgegebenen Entwicklungs-
prozesse ermoglicht. Durch das methodische Vorgehen wird eine Qualitats-
steigerung der Testprozesse ermoglicht. Diese wird vor allem durch den
dokumentierten Einsatz von Methoden beim Testentwurf erzielt. Es kann
verhindert werden, dass Testsequenzkombinationen vergessen werden. Fer-
ner bedingt das Framework als durchgangig geschlossene Werkzeugkette
eine Effizienzsteigerung bei der Erstellung und Ausfuhrung von Testfallen.
1.4. Aufbau der Arbeit
Die Arbeit ist folgendermaßen gegliedert. Das Kapitel 1 erfasst den Stand
der Technik in dem der Arbeit zugrundeliegenden Gebiet der Entwicklung
von Kfz-Steuergerate-Software. In Kapitel 2, werden die Prozesse, Metho-
den und Werkzeuge in diesem Umfeld beschrieben. Daraus resultiert die
Aufgabenstellung der Arbeit Testentwurfsmethoden moglichst generisch in
den Software-Entwicklungsprozess integrieren zu konnen. In Kapitel 3 wird
das zur Losung der Aufgabenstellung konzeptionierte Testframework und
dessen Bestandteile vorgestellt. Aufgrund der Vielfaltigkeit des Arbeitsge-
bietes wird eine Leitanwendung in Kapitel 4 beschrieben, anhand derer die
Konzepte des Testframeworks konkretisiert werden. Das Kapitel 5 stellt die
Entwicklung einer neuartigen Heuristik zur modellbasierten Testsequenz-
generierung im Rahmen des Testframeworks anhand der Leitanwendung
vor. Nach der Diskussion des Einsatzes des Testframeworks in Kapitel 6
wird in Kapitel 7 eine Zusammenfassung der Arbeit gegeben.
21
2. Prozesse, Methoden und
Werkzeuge
Im Rahmen dieses Kapitels werden die Randbedingungen der Software-
entwicklung in der Automobilindustrie dargestellt, um den Beitrag dieser
Arbeit einordnen zu konnen. Zunachst werden in Abschnitt 2.1 die Aufga-
ben und der prinzipielle Aufbau von Software in der Domane Automobil
eingefuhrt. In Abschnitt 2.2 wird der Softwareentwicklungs- und Testpro-
zess vorgestellt. Fur die Erstellung der Steuergeratesoftware kommen ver-
schiedene Entwicklungsparadigmen zum Einsatz, welche in Abschnitt 2.3
erortert werden. Die Betrachtung der potenziellen Softwarefehler in Ab-
schnitt 2.5 erleichtert die Auswahl von Testfallerstellungsmethoden, welche
in Abschnitt 2.6 aufgefuhrt werden. Vor diesem Hintergrund konnen An-
forderungen an das effizientere Testen von Software gestellt werden, welche
in Abschnitt 2.7 zusammengefasst werden.
2.1. Aufgaben und Aufbau der Software
Ein modernes Fahrzeug besteht aus einer Vielzahl mechatronischer Sys-
teme. Diese sind dadurch gekennzeichnet, dass sie Mechanik, Elektronik
und ein elektronisches Steuergerat vereinen. Das Steuergerat enthalt in der
Regel einen Mikrocontroller, der durch Software gesteuert wird. Ein sol-
ches System ist exemplarisch am Beispiel eines Automatikgetriebes [23] in
Bild 2.1 dargestellt. Das mechanische Automatikgetriebe ist durch Aktoren
und Sensoren mit dem elektronischen Steuergerat verbunden. Der Test der
Software dieser Steuergerate ist Gegenstand der vorliegenden Arbeit. Diese
Software ist modular aufgebaut und besteht aus folgenden Bestandteilen:
Modul: Kleinste ausfuhrbare Einheit (Meist eine Klasse. Bsp.: Einstellung
des Hydraulikdrucks).
22
Komponente: Zusammenstellung mehrerer Module zur Ausfuhrung ei-
ner bestimmten Aufgabe (Bsp.: Fehlerbehandlung, Hydraulikansteue-
rung).
Gesamtsoftware: Zusammenstellung aller Komponenten zu der im Steu-
ergerat verwendeten Gesamtsoftware (Bsp.: Getriebesteuerung).
Komponente 2Komponente 1
cX2 cRegler
Einschalten()
cRegler
Einschalten()
Ausschalten()
p_Ist
cX1cX2
cXn Aus
Ausschalten()/
Einschalten()/
MATLAB®
UML
Ein
Steuergeräte Software
CAN-Bus
Abtriebsdrehzahl
Turbinendrehzahl
Wählhebel
Magnet-
Ventile,
Druckregler
Motordrehzahl
Motormoment
Drosselklappenstelung
Anzeige
Motoreingriff Diagnose-
anschlussGesamtsoftware
SW-Komponente
SW-Modul
Programm-
schalter Kick-Down-
SchalterE S
Elektronisches Steuergerät
1
Out1
Product
2
In2
1
In1
Bild 2.1.: Aufbau von Steuergeratesoftware.
2.2. Softwareentwicklungs- und Testprozess
Die Einfuhrung von Vorgehensmodellen, wie dem allgemeinen V-Modell,
hilft dabei, die Softwareentwicklung ubersichtlich zu gestalten und die
23
Komplexitat beherrschbar zu machen. Parallel zu der Entwicklung des ers-
ten V-Modells in Deutschland 1986, wurde in den Vereinigten Staaten auf
Initiative des US-Verteidigungsministeriums ein System zur Bewertung der
Reife von Softwareentwicklungsprozessen erarbeitet, welches den Namen
Capability Maturity Model tragt [10]. Daraus hat sich bis heute eine Fa-
milie von Referenzmodellen mit dem Namen Capability Maturity Model
Integration (CMMI) entwickelt. Konkurrierend dazu ist seit 1998 das Re-
ferenzmodell Software Process Improvement and Capability Determination
(SPICE) entstanden [37]. Seit 2001 wird die domanenspezifische Variante
Automotive-Spice unter Federfuhrung von VW entwickelt, welche in der
Automobilindustrie eingesetzt wird. Innerhalb von Automotive-Spice sind
verschiedene Prozessgruppen definiert. Aus der Gruppe der Engineering-
Prozesse wird die strukturierte Softwareentwicklung nach dem V-Modell
abgeleitet. Die im Rahmen der Arbeit zugrundegelegte Konfiguration des
Software-Design
Software-
Anforderungsanalyse
Software-
Erstellung
Softwareintegration und
Integrationstest
Softwaretest
Modultest
System-
Architekturdesign
UML Zustandsdia
gramme ...
C/
C++MA
TL
AB
/
SIM
UL
INK
Testplanung Testmanagement
Warum, Was, Wo und Wann?
System-
Anforderungsanalyse
Gesamt-
Anforderungsanalyse
3) 4) 5)2)
2) 3) 4) 5)
2) 3) 4) 5)
Systemtest
Systemabnahme
Systemintegration- und Integrationstest
Wie, Wie viel?
Wie, Wie viel?
Wie, Wie viel?
Appli-
kation
Parallele
Ent-
wicklungs-
prozesse
Hydraulik,
Mechanik,
Elektronik
Projekt-
management
Lieferanten-
management
Konfigurations
management
Änderungs-
management
Qualitäts-
sicherung
Problem-
management
Organisatorische und unterstützende Prozesse
1) Testplanung
2) Testspezifikation
3) Testdurchführung
4) Testprotokollierung
5) Testauswertung
Legende:
1)
Bild 2.2.: Integration des Softwaretestprozesses in den Softwareentwick-lungsprozess.
V-Modells ist in Bild 2.2 dargestellt. Der aufgespannte Rahmen geht uber
die eigentliche Softwareentwicklung hinaus, der Fokus der Arbeit liegt al-
lerdings auf der Softwareentwicklung. In der Software-Anforderungsanalyse
24
werden die Anforderungen an die zu erstellende Software erfasst. Sie stel-
len die Grundlage fur das Software-Design dar. Das Grobdesign wird dabei
in UML erstellt. Es wird entschieden, welche Funktionsblocke vorhanden
sein mussen und in welche Komponenten und Module sich die Software un-
tergliedert. Das Feindesign, welches die eigentliche Funktion der einzelnen
Module beschreibt, wird teilweise mit MATLAB/SIMULINK oder eben-
falls in UML erstellt. Der Großteil des Programmcodes wird manuell in C
und C++ programmiert. Das Software-Design ist eng mit der Software-
Erstellung verwoben. Neben der eigentlichen Erstellung ist in dieser Pha-
se fur jedes Modul ein Modultest aufzusetzen. In der Softwareintegration
und dem Integrationstest geht es darum, die einzelnen Module zu funk-
tionsfahigen Komponenten zu integrieren und sicherzustellen, dass deren
Zusammenspiel funktioniert. Die zur Gesamtsoftware integrierten Kompo-
nenten werden schließlich im Softwaretest gegen die Softwareanforderungen
getestet.
Wie Bild 2.2 veranschaulicht ist der Softwaretestprozess, nach [52], in den
Entwicklungsprozess integriert. In der Testplanung (1), werden die organi-
satorischen Aspekte des Testens berucksichtigt. Typische Tatigkeiten sind
die Planung und Verteilung des Resourceneinsatzes (Wer soll wann auf
welcher Umgebung welche Tests ausfuhren?). Weitere Aspekte sind die
Auswahl der Teststrategie sowie die Festlegung der Testendekriterien. In
der Testspezifikation (2) werden die Testinhalte abstrakt erstellt. In die-
ser Phase unterstutzen Testentwurfsmethoden den Tester dabei, systema-
tisch vorzugehen. Dies ist die fur die Qualitat der Tests wichtigste Phase,
da der Inhalt der Testsequenzen festgelegt wird. In der Testausfuhrung
(3) werden die spezifizierten Tests zur Ausfuhrung gebracht. Dazu ist es
notig, entsprechende Testumgebungen bereitzustellen und entweder Test-
skripte zu erstellen, um die Tests automatisch ausfuhren zu konnen, oder
die Tests gemaß der Testspezifikation manuell auszufuhren. Wahrend der
Testausfuhrung muss eine ausfuhrliche Protokollierung (4) stattfinden, um
die Tests bei erweiterten Fragestellungen nicht wiederholen zu mussen und
die Testauswertung (5) unterstutzen zu konnen. Bei der Auswertung wird
entschieden, ob es sich bei gefundenen Fehlern um Fehler in der Testse-
quenz, der Testumgebung oder wirklich um einen Softwarefehler handelt.
Aus der Summe der Testergebnisse lasst sich ein Momentanbild ableiten,
wie es um den Entwicklungszustand der Software bestellt ist.
25
Die vertikale Gliederung des V-Modells fuhrt zu den Teststufen Modul-
test, Integrationstest und Softwaretest. Die Phasen des Softwaretestpro-
zesses, ausgenommen die Phase Testplanung, wiederholen sich in diesen
Stufen immer wieder aufs Neue. Auf den verschiedenen Teststufen sind ge-
maß der Teststrategie vorgegebene Testziele zu erreichen. Dabei kommen
unterschiedliche Testausfuhrungsplattformen zum Einsatz. Im Folgenden
wird eine fur das zugrundeliegende Forschungsprojekt gultige Auspragung
der Teststufen beschrieben.
Modultest: Die Entwicklung der Software beginnt mit den kleinsten Ein-
heiten, den Modulen. Der Modultest ermoglicht es, diese elementa-
ren Bausteine von Anfang an auf ihre Funktionalitat zu uberprufen
und die Funktion von neuen Code-Konstrukten in einem uberschau-
baren Rahmen zu testen. Ein weiteres Ziel des Modultestes ist es,
sicherzustellen, dass der Code lesbar und so strukturiert ist, dass
er der entworfenen Architektur genugt und wiederverwendet werden
kann. Ferner mussen die MISRA C Programmierrichtlinien1 [12] ein-
gehalten werden. Dies wird mit Hilfe eines statischen Code-Analyse-
Werkzeuges und Reviews erreicht. Auf dieser Stufe ist zudem si-
cherzustellen, dass der Code technisch funktioniert und kein unbe-
nutzbarer oder unerreichbarer Code programmiert wurde. Dazu wird
der Code dynamisch stimuliert und die Kontrollflussuberdeckung be-
stimmt. In der Testplanung wird dafur projektspezifisch ein zu er-
reichender Uberdeckungsprozentsatz festgelegt. Zur Durchfuhrung,
Protokollierung und Auswertung der Tests wird ein CppUnit [5] ahn-
liches Testframework eingesetzt. Durch die Wahl der Stimuli lassen
sich schon hier funktionale Aspekte des Softwaremoduls testen.
Integrationstest: Der Integrationstest soll sicherstellen, dass sich die Mo-
dule reibungslos integrieren lassen und dass das Zusammenspiel wie
geplant funktioniert. Im Integrationstest wird eine Software-in-the-
Loop (SiL) Testumgebung eingesetzt. Diese ist in Analogie zu einer
Hardware-in-the-Loop (HiL) Testumgebung dadurch gekennzeichnet,
dass der Steuergerate-Code und ein Umgebungsmodell auf dem PC
gegeneinander simuliert werden. Prinzipiell ist das funktionale Zu-
sammenspiel der Gesamtsoftware mit der Umgebung hier erstmals
1Bei der Generierung von C-Code aus MATLAB/SIMULINK Modellen mussen Modellierungsrichtlinieneingehalten werden, um zu gewahrleisten, dass der erzeugte Code den MISRA Regeln entspricht.
26
testbar, wenngleich die Aussagekraft der Tests im Wesentlichen von
der Gute der verwendeten Umgebungsmodelle abhangt.
Softwaretest: Ziel des Softwaretests ist es sicherzustellen, dass die Soft-
ware die gewunschte Funktionalitat im Fahrzeug realisiert. Dabei ist
es notwendig, dass die Software auf dem Steuergerat ausgefuhrt wird.
So wird gewahrleistet, dass die Software fehlerfrei auf die Hardware
ubertragen wird und das korrekte Zusammenspiel von Hard- und
Software gegeben ist. Dazu werden HiL- und Fahrzeugversuche durch-
gefuhrt. Das Testende fur den Softwaretest wird dadurch nachgewie-
sen, dass zu jeder Anforderung der spezifizierte Test mit positivem
Ergebnis durchgefuhrt wurde.
2.3. Entwicklungsparadigmen
Die Software fur ein mechatronisches System muss verschiedenen Anfor-
derungen genugen. Es sind physikalische, mechanische und elektronische
Zusammenhange zu berucksichtigen. Als Ergebnis muss ein Programm in
Maschinensprache zur Verfugung stehen, welches die Anforderungen auf
der Hardware realisiert.
2.3.1. Steuerungs- und regelungstechnische Aspekte
Ziel der Software in mechatronischen Systemen ist die Steuerung bzw. die
Regelung2 des Systemverhaltens. Es kann sich bei einem Automatikgetriebe
beispielsweise um die Regelung einer Aktuatorik handeln. Die Auslegung
dieser Regelungen erfolgt in einer Simulation gegen ein physikalisch/ma-
thematisches Modell des Verhaltens des zu beeinflussenden Systems. Bei
dem Modell handelt es sich um Differenzialgleichungen, welche durch al-
gebraische Beziehungen in Zusammenhang gebracht werden. Fur die Mo-
dellierung hat sich das Programmsystem MATLAB/SIMULINK etabliert.
Dieses enthalt bereits eine große Anzahl von Funktionen fur die Modeller-
stellung, z. B. Modellbibliotheken sowie Funktionen fur die Auslegung der
Regelungsalgorithmen. Durch die Simulation kann das Verhalten der Rege-
2Im Folgenden wird nur noch von Regelung gesprochen.
27
lung bereits vor der eigentlichen Produktion des Systems getestet werden.
In den letzten Jahren wurden verschiedene Werkzeuge aufgebaut, welche
es ermoglichen, diese Simulationsmodelle direkt in steuergeratekonformen
C-Code zu transformieren3.
2.3.2. Kommunikation
Aufgrund der Realisierung von immer mehr Funktionalitat durch elektro-
nische Steuergerate ist die Anzahl der benotigten Kabelverbindungen so
weit angestiegen, dass sie durch Verwendung einer herkommlichen Ver-
drahtung nicht mehr in ein Fahrzeug passen wurde. Zur Beseitigung dieser
Problemematik sind Bus-Systeme eingefuhrt worden, welche die effektivere
Verdrahtung der Steuergerate ermoglichen. Der wohl bekannteste Vertreter
ist der CAN (Controller Area Network) Bus, welcher 1983 unter Federfuh-
rung der Firma Bosch entwickelt wurde [33]. Mittlerweile sind weitere Bus-
systeme hinzugekommen, exemplarisch seien FlexRay und MOST genannt.
Fur die Software auf einem Steuergerat bedeutet dies, dass eine Signalauf-
bereitungsschicht zur Verfugung stehen muss, welche die am Bus ankom-
menden Signale auf interne Großen der Software abbildet und zu versen-
dende Großen auf Bus Signale ubertragt.
In diesem Zusammenhang ist bei der Auslegung der Regelungsalgorithmen
darauf zu achten, dass diese mit eventuell durch die Kommunikation auf-
tretenden Totzeiten zurecht kommen mussen.
2.3.3. Berucksichtigung der Hardware
Die Abbildung der Schnittstellen des Mikrocontrollers auf die Sensorik bzw.
Aktuatorik muss erfasst und dokumentiert werden, um zu berucksichtigen
wie die Software die Sensorik und Aktuatorik ansteuern kann. Zum einen
handelt es sich dabei um physikalische Schnittstellen des Controllers, wie
Digital/Analog-Wandler oder PWM-Ausgange. Zum anderen handelt es
sich um Bus-Kommunikation, wie beispielsweise die CAN-Schnittstelle.
3Hauptsachlich handelt es sich dabei um den Real-Time Workshop Embedded Coder von The Ma-thWorks oder Target Link der Firma dSPACE.
28
2.3.4. Programmierung
Um die gewunschte Funktionalitat zu realisieren, muss ein Programm in
Maschinensprache zur Verfugung stehen. Wahrend bis in die neunziger Jah-
re eingebettete Systeme noch hauptsachlich in Assembler programmiert
wurden, um den geringen Ressourcen gerecht zu werden, hat im Verlauf der
Zeit ein Wechsel hin zu komfortableren Hochsprachen stattgefunden, deren
Einsatz von dem verwendeten Zielsystem unabhangig ist. Dabei kommt die
funktionsorientierte Sprache C und deren objektorientierte Weiterentwick-
lung C++ zum Einsatz [15]. Da die Assemblersprache fur jeden Mikro-
controller individuell ist, stellen die Herstellerfirmen Cross-Compiler zur
Verfugung, welche es ermoglichen, die Hochsprachen in die jeweilige Ziel-
Assemblersprache zu ubersetzen.
Funktionsorientierte Programmierung Die Sprache C ist eine funk-
tionsorientierte oder auch prozedurale Programmiersprache. Zentraler Be-
standteil eines C-Programms ist die Funktion main(), welche weitere Funk-
tionen aufrufen kann. Die Kapselung von Daten ist durch Strukturen mog-
lich. Gegenuber einer objektorientierten Sprache besteht der Nachteil, dass
ahnliche, zusammenhangende Funktionalitat nicht so effektiv gekapselt
werden kann.
Objektorientierte Programmierung Um die Nachteile der funktions-
orientierten Programmierung zu beheben und den Code effektiver gestalten
zu konnen, wurde das Paradigma der objektorientierten Programmierung
schon Ende der sechziger Jahre entwickelt. Eine praktisch relevante An-
wendung erfahrt das Paradigma aber erst seit den neunziger Jahren. Es
bietet die Moglichkeit Attribute (Variablen) und Methoden (Funktionen)
in einer Klasse zu kapseln, deren Instanzen Objekte genannt werden.
Anhand des bereits erwahnten Automatikgetriebes soll dieser Zusammen-
hang verdeutlicht werden. Zur Bedienung der mehrfach vorhandenen Kupp-
lungen innerhalb des Getriebes werden baugleiche bzw. ahnliche hydrau-
lische Aktuatoren verwendet. Der Druck, den die Aktuatoren stellen, ist
proportional zu einem Strom, den das Steuergerat vorgeben kann. Fur ei-
ne solche Anwendung bietet es sich an die Aktuatoren als Objekte einer
29
Klasse aufzufassen. Die Daten und Funktionen, welche zu der Ansteue-
rung eines Aktuators benotigt werden, konnen dadurch in dieser Klasse
gekapselt werden.
2.4. Modelle in der Softwareentwicklung
Bei der Einfuhrung der Entwicklungsparadigmen sind schon die wesentli-
chen Modelltypen vorgestellt worden.
Die fruhen Modelle in der Softwareentwicklung sind in der Abstraktion
der Assemblersprache in die Hochsprachen C und spater C++ verborgen.
Auch diese Hochsprachen wurden weiter in Programmsysteme wie MAT-
LAB/SIMULINK und UML abstrahiert. Allen Modellen ist gemein, dass
sie versuchen, die komplexen, zugrundeliegenden Zusammenhange auf das
Wesentliche zu abstrahieren, um fokussiert entwickeln zu konnen.
In der Informatik bedeutet dies, dass die zu verarbeitenden Informationen
bzw. die von der Software umzusetzende Funktionalitat in irgendeiner Form
in den PC eingegeben und dort in Maschinensprache verstandlich aufberei-
tet werden muss. Aus diesem Abbild der Informationen im Speicher konnen
weitere Transformationen angestoßen werden.
Im Kontext der Abstraktion der Assemblersprache auf die Hochsprache
C sei hier die Backus-Naur-Form erwahnt. Dieser Formalismus wird dazu
verwendet, die Syntax der Programmiersprache C so zu beschreiben, dass
daraus ein Parser erzeugt werden kann. Der Parser ist dann in der Lage,
den C-Programmcode einzulesen. Der Compiler vermag aus diesem Spei-
cherabbild des Codes die notwendigen Assembler-Befehle abzuleiten. Eine
exaktere Beschreibung der Thematik ist in [51] zu finden.
Im Bereich der automobilen Softwareentwicklung und damit auch in der
vorliegenden Arbeit sind derzeit die Abstraktionen der Sprachen C und
C++ im Fokus. Dazu bietet sich zum einen das bereits erwahnte Pro-
grammsystem MATLAB/SIMULINK an, welches gut fur die funktionalen
und regelungstechnischen Aspekte der Software geeignet ist. Sowohl der
Hersteller The MathWorks als auch die Firma dSPACE bieten als Ergan-
zung zu den SIMULINK Signalfluss-Diagrammen spezielle Erweiterungen
30
an, damit das Funktionsmodell mit den fur die Transformation in die Spra-
che C notwendigen Informationen angereichert werden kann.
Bei der Softwareentwicklung mit der objektorientierten Programmierspra-
che C++ bieten sich UML-Werkzeuge an.
2.4.1. Unified Modeling Language
Die Unified Modeling Language (UML) ist eine von der OMG standardisier-
te Sprache, welche zur Modellierung von Software und Software-Systemen
verwendet wird [13, 38]. Ihre Anfange liegen in den neunziger Jahren. In
diesem Zusammenhang wurde die UML dazu verwendet, die gerade auf-
kommenden objektorientierten Softwaresysteme zu beschreiben. Die UML
definiert derzeit dreizehn Diagrammtypen. Im Rahmen der vorliegenden
Arbeit werden das Klassendiagramm und das Zustandsdiagramm verwen-
det, weswegen nur diese beiden Diagrammtypen im Folgenden erlautert
werden.
2.4.1.1. Klassendiagramm
Das Klassendiagramm ermoglicht es, Klassen im Sinne der objektorientier-
ten Programmierung und deren Beziehungen untereinander darzustellen.
Eine Klasse wird dabei als Rechteck dargestellt, welches durch horizontale
Linien geteilt wird. Im ersten Abteil steht der Name der Klasse, im zweiten
die Attribute und schließlich die Methoden. Zwischen den Klassen konnen
folgende Beziehungen bestehen:
• Vererbung bzw. Generalisierung
• Assoziation
– Gerichtete Referenz
– Aggregation
– Komposition
Mit Ausnahme der Komposition sind diese Beziehungen in Bild 2.3 dar-
gestellt. Die Klasse CommonMetaData ist eine Generalisierung der Klasse
Testfallgruppe. Dadurch erbt die Klasse Testfallgruppe die Attribute (Sta-
31
tus, AusfuhrungsArt, ...) der Klasse CommonMetaData. Die Klasse Test-
spezifikation verweist durch eine gerichtete Referenz auf die Klasse Testbi-
bliothek. Es handelt sich um eine 0 zu * Beziehung (0..*). Eine Instanz der
Klasse Testspezifikation kann also auf null bis beliebig viele Instanzen der
Klasse Testbibliothek verweisen. Ferner beinhaltet die Klasse Testspezifika-
tion durch die Aggregation der Klasse Testfallgruppe eine interne Menge
mit Instanzen dieser Klasse. Bei einer Aggregation konnen die instanzi-
Bild 2.3.: Beispiel fur ein Klassendiagramm.
ierten Elemente nicht ohne das beinhaltende Element existieren. In dem
dargestellten Beispiel konnen also keine Elemente der Klasse Testfallgrup-
pe angelegt werden, ohne dass eine Instanz der Klasse Testspezifikation
vorhanden ist. Bei einer Komposition ist dies hingegen moglich. Sie wird
grafisch durch eine nicht ausgefullte Raute dargestellt.
2.4.1.2. Zustandsdiagramm
Innerhalb der UML wird ein Zustandsdiagramm zu der Klasse der Verhal-
tensdiagramme gezahlt. Das Zustandsdiagramm orientiert sich an der Defi-
nition nach Harel [31]. Es erweitert das Verhalten einer Zustandsmaschine
im Wesentlichen um die Konzepte der Hierarchie und Orthogonalitat, wel-
che in Unterabschnitt 5.1.4 beschrieben werden.
32
2.4.2. Extensible Markup Language
Die Extensible Markup Language (XML) ist eine Auszeichnungssprache.
Sie wird eingesetzt, um Informationen zu strukturieren und sowohl fur
den Menschen als auch fur Maschinen les- und austauschbar zu machen.
Die XML ist ein offener Standard, ein Allzwecksystem zum Speichern von
Informationen und ein Werkzeugkasten fur Auszeichnungssprachen [45].
Innerhalb der XML ist es moglich, Informationen in Elemente zu verpa-
cken. Diese Elemente konnen wiederum zueinander in Beziehung stehen
und Attribute fur die weitere Unterstrukturierung aufweisen.
Eine vollstandigere Definition der XML wurde den Rahmen dieser Arbeit
ubersteigen. Fur die weiteren Ausfuhrungen ist es jedoch wichtig, zumin-
dest die wesentlichen Elemente und deren Beziehung zu anderen Abstrak-
tionsmechanismen, wie dem bereits eingefuhrten Klassendiagramm, aufzu-
zeigen.
Die Grundbegriffe werden anhand der in XML serialisierten Instanz des
Klassendiagramms aus Bild 2.3 erlautert.
1 <?xml version=”1 .0 ” encoding=”UTF−8”?>
2 <t e s t : T e s t b i b l i o t h e k
3 xmi :ve r s i on=”2 .0 ” xmlns:xmi=”h t tp : //www. omg . org /XMI”
4 xmln s : t e s t=” t e s t s p e z i f i k a t i o n ” Name=”Funkt ions te s t ”>
5 <T e s t s p e z i f i k a t i o n Name=”cDruckRegler ” Vers ion=”1 .0 ”
6 B i b l i o t h e k s S p e z i f i k a t i o n=”/ ”>
7 <T e s t f a l l g r u p pe Status=” s p e z i f i z i e r t ”
8 T e s t z i e l=”Nachweis der Funkt i ona l i t a t ”
9 P r i o r i t a t=” g e n e r i e r t ”
10 Name=”Regeln ”/>
11 </ T e s t s p e z i f i k a t i o n>
12 </ t e s t : T e s t b i b l i o t h e k>
Listing 2.1: Serialisierung einer Instanz eines Klassendiagramms.
Die Klasse Testbibliothek stellt das Wurzelelement des Klassendiagramms
dar und wird daher auch als Wurzelelement der XML-Serialisierung ab-
gebildet. Dies ist dadurch gekennzeichnet, dass der Name der Klas-
se in spitzen Klammern (<test:Testbibliothek ...>) zu Beginn des
Dokuments steht. Am Ende des Dokuments steht der Name ebenfalls
in spitzen Klammern, allerdings mit einem vorangestellten Schragstrich
(</test:Testbibliothek>). Die Testbibliothek aggregiert das Element
Testspezifikation, dessen Attribut Name dabei mit dem Wert cDruckReg-
33
ler instanziiert ist. Die Testspezifikation wiederum aggregiert das Element
Testfallgruppe. In der Serialisierung ist die Generalisierungsbeziehung zu
der Klasse CommonMetaData daran zu erkennen, dass das Element Test-
fallgruppe die Attribute der Vater-Klasse CommonMetaData besitzt. Ein
Beispiel dafur ist das Attribut Status, welches mit dem Wert spezifiziert
instanziiert ist. Wie an dem Element Testfallgruppe ersichtlich wird, kann
ein Element auch direkt mit der Zeichenfolge (.../>) abgeschlossen wer-
den, siehe Zeile 10 des Listings 2.1. Die durch die Aggregationsbeziehungen
vorgegebene Hierarchie des Klassendiagramms spiegelt sich in der XML-
Serialisierung durch die Schachtelung der Elemente wieder.
2.4.3. Generative Programmierung
Unter dem Oberbegriff Generative Programmierung konnen alle Ansatze
zusammengefasst werden, welche es ermoglichen, aus Modellen Code zu
generieren [53].
2.4.3.1. Model Driven Architecture
Unter dem Stichwort Model Driven Architecture (MDA) entwickelt die Ob-
ject Management Group (OMG) einen Standard, welcher eine offene und
interoperable Losung der generativen Programmierung zum Ziel hat. Der
Standard sieht eine klare Trennung zwischen der funktionalen Sicht auf
die Software und der technischen Realisierung in Form eines ausfuhrbaren
Implementierungscodes vor. Die Funktionalitat der Software wird in dem
Platform Independent Model (PIM) beschrieben, welches durch Transfor-
mation in das Platform Specific Model (PSM) uberfuhrt werden kann. In-
nerhalb der MDA werden zwei wesentliche Transformationsarten definiert:
1. Modell-zu-Modell Transformation (M2M)
2. Modell-zu-Code Transformation (M2Code)
In der Meta-Object-Facility (MOF) wird eine Metadatenarchitektur defi-
niert, welche die technologische Grundlage fur Transformationen darstellt.
Innerhalb der MOF existieren vier Ebenen, welche in Bild 2.4 visualisiert
sind.
34
M3: Meta-Meta-Modell
M2: Meta-Modell
M1: Modell
M0: Objekte der Realität
ist Instanz von
beschreibt
ist Instanz von
beschreibt
ist Instanz von
beschreibt
beschreibtist Instanz von
Dokument:
Testbibliothek
1 <?xml version="1.0" encoding="UTF-8"?>2 <test:Testbibliothek 3 xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" 4 xmlns:test="testspezifikation" Name="Funktionstest">5 <Testspezifikation Name="cDruckRegler" Version="1.0"...
Bild 2.5
Bild 2.3
Listing 2.1
Bild 2.4.: Die vier Ebenen der MOF werden anhand des bereits eingefuhr-ten Beispiels des Klassendiagramms und des im folgenden be-schriebenen EMF-Meta-Modells dargestellt.
Die Ebene M3 ist das Meta-Meta-Modell. Dieses stellt die Konstruktions-
elemente fur die Ebene M2, das Meta-Modell, dar. Basierend auf dem Meta-
Modell werden in der Ebene M1 Modellelemente aufgebaut. Diese repra-
sentieren Objekte aus der realen Welt, welche in der Ebene M0 dargestellt
sind.
2.4.3.2. Model Driven Software Development
Die Bausteine der MDA befinden sich noch in der Standardisierungsphase.
Unter dem Begriff Model Driven Software Development (MDSD) werden
bereits verfugbare Adaptionen dieser Konzepte zusammengefasst. So stellt
das Eclipse Modeling Framework (EMF) [50] in Zusammenhang mit open
Architecture Ware (oAW) [26] eine solche Adaption dar. Die Modellierung
35
erfolgt dabei basierend auf dem EMF, die Transformationen werden durch
oAW realisiert.
Basierend auf dieser Technologie wird das bereits eingefuhrte Konzept der
MOF erlautert.
M3: Das Meta-Meta-Modell In Bild 2.5 ist das dem EMF zugrunde
liegende vereinfachte Meta-Meta-Modell dargestellt.
Bild 2.5.: Vereinfachtes Meta-Meta Modell des EMF.
Im EMF tragt es den Namen ecore. Es ist selbst aus ecore-Bausteinen auf-
gebaut. Innerhalb des Modells wird die Klasse EClass definiert, welche die
Klassen EAttribute und EReference aggregiert. Die Klasse EReference kann
wiederum auf eine EClass referenzieren. Attribute, welche durch die Klas-
se EAttribute abgebildet werden konnen, verweisen auf einen Datentyp,
welcher durch die Klasse EDataType dargestellt wird. Durch die Referenz
eSuperTypes kann die Klasse EClass auf Instanzen dieser Klasse verweisen,
wodurch die Generalisierungsbeziehung dargestellt werden kann.
M2: Das Meta-Modell Aus diesen grundlegenden Strukturelementen
kann das Klassendiagramm in Bild 2.3 aufgebaut werden. Im Sinne der
MOF handelt es sich dabei um die Ebene M2, das Meta-Modell. Alle
in dem Diagramm vorhandenen Klassen sind Instanzen des Meta-Meta-
Modell-Elements EClass. Das Meta-Meta-Modell stellt also die Konstruk-
tionselemente fur das Meta-Modell zur Verfugung.
36
M1: Das Modell Durch die Elemente des Meta-Modells steht eine Infor-
mationsstrukturierungsvorlage zur Verfugung, wie die Serialisierung einer
Instanz des Klassendiagramms in Listing 2.1 zeigt.
M0: Objekte der Realitat Das Modell beschreibt ein Objekt aus der
Realitat, in Bild 2.4 ein formales Dokument, welches eine Testbibliothek
beinhaltet.
2.4.3.3. Nutzen der Vorgehensweise
Der Nutzen dieser Metadaten-Architektur besteht in der Gewahrleistung
der Interoperabilitat zwischen verschiedenen Werkzeugen, welche dieser Ar-
chitektur genugen. Dies erfolgt dadurch, dass die zu integrierenden Werk-
zeuge auf den gleichen Konstruktionselementen aufsetzen, wie die durch
das Meta-Meta-Modell vorgegebenen.
Wenn verschiedene UML Werkzeuge das der Sprache zugrundeliegende
Meta-Modell mit den gleichen Konstruktionselementen aufbauen, wird es
moglich, durch die Modell-zu-Modell Transformation Informationen aus
der Realisierung A in die Realisierung B zu uberfuhren.
Durch das Konzept der MOF entsteht ein großes Standardisierungs- und
Automatisierungspotenzial. Nach der Vermutung des Autors wird den
meisten kommenden Software-Werkzeugen die MOF zugrunde liegen. Diese
Annahme beruht zum einen auf der Tatsache, dass die Konzepte von der
OMG definiert werden, welche auch die UML und damit indirekt UML-
Werkzeuge definiert. Ferner zeigen die Adaptionen der MOF im EMF und
oAW eine verfugbare und hilfreiche praktische Anwendbarkeit auf, wodurch
die Verwendung in Software-Werkzeugen nahe liegend ist.
Das EMF wird damit beworben, UML, XML und Java miteinander zu ver-
einigen. Dies gelingt in der Entwicklungsumgebung Eclipse [6] durch die
Moglichkeit, aus *.ecore-Bausteinen ein UML-Klassendiagramm aufzubau-
en. Daraus kann dann eine Java-Implementierung des Objektmodells ge-
neriert werden, welche in XML serialisierbar ist. Ferner sind Moglichkeiten
vorgesehen, annotiertes Java zur Generierung der Implementierungsklassen
eines Objektmodells heranzuziehen oder anstelle des Klassendiagramms ein
XML-Schema zu verwenden.
37
Noch nicht alle Software-Werkzeuge verwenden die gleichen Meta-Meta-
Modelle. Trotzdem ergibt sich durch das EMF die Moglichkeit, die Mecha-
nismen der MDA zu verwenden. Dazu mussen aber Informationen aus den
zu integrierenden Software-Werkzeugen in ein EMF-Meta-Modell uberfuhrt
werden. Dazu konnen auch Technologien wie COM verwendet werden.
2.4.4. Relevanz fur den Test
Unter Berucksichtigung der bereits eingefuhrten Begriffe zeichnet sich fur
die Entwicklungslandschaft von Software fur eingebettete Systeme im Au-
tomobil folgendes Bild 2.6 ab. Um das grobe Design der Software beschrei-
UML Zustandsdiagramme
...
man.
codieren
C/C++
Assembler
MATLAB/
SIMULINK
generieren generieren
Bild 2.6.: Entwicklungslandschaft fur Steuergeratesoftware.
ben zu konnen, eignet sich die UML. Das Verhalten einzelner, fur die Rege-
lung zustandiger Komponenten lasst sich durch das fur die Domane besser
geeignete Programmsystem MATLAB/SIMULINK beschreiben. Als Resul-
tat muss in jedem Fall zunachst C bzw. C++ Code zur Verfugung stehen,
welcher durch die geeigneten Compiler in Maschinensprache ubersetzt wird.
Der C bzw. C++ Code kann dabei auf drei verschiedenen Wegen entstehen:
1. Unter Zuhilfenahme eines MATLAB/SIMULINK-basierten Codege-
nerators (TargetLink bzw. Embedded Coder) wird C-Code generiert.
2. Unter Zuhilfenahme eines geeigneten UML-Werkzeugs kann aus
UML-Diagrammen ein Teil des Codes generiert werden.
3. Das in UML vorgegebene Design wird manuell in C bzw. C++ Code
uberfuhrt.
Dabei zeigt sich der Trend zu der Verwendung einer hoheren Abstraktion
im Zusammenhang mit der generativen Softwareentwicklung. Mit der UML
38
konnen objektorientierte Programme durch verschiedene Diagrammtypen
beschrieben werden. Parallel zu der reinen physikalischen Betrachtungswei-
se durch MATLAB/SIMULINIK steht damit eine informationstechnisch
motivierte Sichtweise auf die Software zur Verfugung, welche insbesondere
die ubergeordneten Strukturen und die Architektur der Software, geeigne-
ter zu beschreiben vermag.
Im Rahmen der Entwicklung mechatronischer Systeme haben beide Sicht-
weisen ihre Daseinsberechtigung und Notwendigkeit.
Die Beschreibung dieser Entwicklungsparadigmen stellt die Basis fur die
Abstraktion der zu testenden Software dar. Fur die in dieser Arbeit ange-
strebte effizientere Testsequenzerstellung ist es relevant, die Beschreibungs-
und Entwicklungsparadigmen zu kennen, um bereits formalisierte Informa-
tionen fur den Test wieder heranzuziehen, bzw. um die Testfallerstellung
in die Entwicklungskette zu integrieren.
2.5. Potenzielle Softwarefehler
Ziel des Testens von Steuergerate-Software ist das Sicherstellen einer feh-
lerfreien Funktionalitat. Die folgende Aufzahlung soll einen Uberblick uber
typisch zu erwartende Fehlerklassen in der Software geben.
Funktionale Fehler: Da die Softwareentwickler in der Regel einen Mo-
dultest durchfuhren, kann unplausible Funktionalitat gleich gefunden
werden. Besonderes Augenmerk ist darauf zu legen, wenn die Funk-
tionalitat uber mehrere Module oder Komponenten verteilt ist. Funk-
tionale Fehler konnen aber auch bei großer Komplexitat entstehen.
Bei manueller Implementierung zustandsbasierten Verhaltens ist es
leicht moglich, den Test einer Ubergangsbedingung zu vergessen.
Berechnungs- und Genauigkeitsfehler: Diese entstehen durch die Ty-
pisierung und Skalierung von Variablen in eingebetteter Software,
welche aufgrund der Festkomma-Arithmetik notwendig ist. Die Ge-
nauigkeit von Berechnungen wird durch die definierte Auflosung der
Großen vorgegeben. Ein Beispiel hierfur ist die Definition einer Va-
riable Masse mit dem Datentyp unsigned integer 8 bit und einer
Skalierung von 256 kg/bit. Durch diese Festlegung konnen nur Mas-
39
senanderungen von 256 kg detektiert werden. Die Definition an sich
muss nicht fehlerhaft sein, im Zusammenspiel der gesamten Software
kann die Festlegung jedoch zu unerwunschtem Verhalten fuhren.
Uberlauf von Datenstrukturen: Diese Fehler entstehen, wenn die Ty-
pisierung und Skalierung von Variablen an Ubergabepunkten inner-
halb eines Moduls und uber Modul- und Komponentengrenzen hin-
weg nicht ubereinstimmen.
Typfehler beim Zugriff auf Datenstrukturen: Bei diesen sieht die
Zugriffsfunktion einen anderen Datentyp vor.
Verletzung von Echtzeitanforderungen: Diese konnen vielfaltige Ur-
sachen haben und sowohl in fehlerhafter Programmierung als auch in
der Uberlastung des Steuergerates ihre Ursache haben.
Abweichungen von spezifizierten Anforderungen: Solche Abweich-
ungen treten auf, wenn sich die Software nicht so verhalt, wie es
die Anforderungen fordern. Dabei kann das Verhalten der Software
trotzdem in sich konsistent sein und damit funktional korrekt.
2.6. Testentwurfsmethoden
us der in Abschnitt 2.2 eingefuhrten Beschreibung des Softwaretestprozes-
ses geht hervor, dass die Prozessphase Testspezifikation die entscheidende
Rolle in Bezug auf die Sicherung der Qualitat der Software spielt. Durch
den Einsatz von Testentwurfsmethoden wird festgelegt, welche Fehler prin-
zipiell gefunden werden konnen und welche Aspekte der Software getestet
werden. In der Praxis zeigt sich, dass den Softwaretestern zwar prinzipi-
ell die verschiedenen Verfahren bekannt sind, ein expliziter, systematischer
Einsatz jedoch eher die Ausnahme als die Regel darstellt.
Im Folgenden wird eine fur die Arbeit relevante Auswahl von bekannten
Testentwurfsmethoden aufgefuhrt und in statische und dynamische Me-
thoden eingeteilt. Einen Uberblick uber die Klassifizierung gibt Abbildung
2.7.
40
Kontrollflussanalyse
Testen
Strukturierte
Gruppenprüfung
Statische
Analyse White-box Testen
Code-Reviews Codierungs-
richtlinien
Metriken
Datenflussanalyse
Black-box Testen
Anweisungs-
überdeckung
Zweigüberdeckung
Pfadüberdeckung
Äquivalenz-
klassenbildung
Grenzwertanalyse
Zustandsbezogener Test
Statisches Testen Dynamisches Testen
Bild 2.7.: Klassfizierung der Testfallerstellungsmethoden.
2.6.1. Statische Testentwurfsmethoden
Bei den statischen Testentwurfsmethoden wird das Testobjekt, in diesem
Fall der Quellcode des Programms, nicht ausgefuhrt. Es werden zwei Ka-
tegorien unterschieden: Die Strukturierte Gruppenprufung und die Stati-
sche Analyse. Zu der Kategorie der Strukturierten Gruppenprufung geho-
ren die Code-Reviews. Diese vermogen unter Zuhilfenahme von Review-
Fragestellungen, die haufig aus dem Erfahrungswissen der Tester und Ent-
wickler schriftlich gesammelt werden, schon einige Fehler aufzudecken. Ins-
besondere sind dies Fehler in Funktionalitat, die uber die gesamte Software
verteilt ist. Ein Beispiel fur eine Fragestellung ist:”Was passiert wenn in
der Situation X ein Reset des Steuergerates ausgefuhrt wird?“
In der Kategorie der Statischen Analyse wird der Quellcode formalen Fra-
gestellungen unterzogen:
Codierungsrichtlinien: Sie stellen eine Sammlung von Regeln dar, ge-
gen welche der Quellcode gepruft werden kann. So gibt es fur die
Erstellung von C-Code die MISRA-C Richtlinien [12]. Diese Samm-
lung von Gestaltungsrichtlinien fur den Quellcode wurden aus Er-
41
fahrungen gewonnen. Neben offiziellen Standards sind haufig auch
firmenspezifische Richtlinien zu finden.
Metriken: Durch Software-Metriken werden eine Reihe von Maßen defi-
niert. Es gibt Metriken, welche die Dichte der Kommentare beschrei-
ben bis hin zu Komplexitatsmaßen, wie sie durch die Zyklomati-
sche Zahl definiert werden. Einen guten Uberblick zu dem Thema
liefert [25].
Kontroll- und Datenflussanalyse: Durch das statische Nachvollziehen
der Kontroll- und Datenflusse innerhalb der Software konnen bereits
einige Fehler aufgedeckt werden. Fur diese Analysen stehen mittler-
weile Werkzeuge zur Verfugung, wie Polyspace der Firma The Ma-
thWorks oder Coverity Prevent der Firma Coverity.
2.6.2. Dynamische Testentwurfsmethoden
Die Klassifizierung der dynamischen Testverfahren erfolgt anhand der fur
die Testfallauswahl zugrundegelegten Sicht auf das Testobjekt. Dies soll
Abbildung 2.8 verdeutlichen. Bei den white-box Verfahren kann der Tester
IF
IF
DO
ENDI
F
ENDIF
WHILEBlack-Box
Grey-Box
White-BoxTestobjekt
Testrahmen
Bild 2.8.: Verschiedene Sichten auf das Testobjekt, als Grundlage fur dieTestfallerstellung.
den Quellcode der zu testenden Software einsehen. Es wird damit moglich,
anhand der Struktur der Software Testfalle zu bestimmen, welche gezielt
verschiedene Aspekte der Software stimulieren. Im Rahmen der black-box
Verfahren sind dem Tester nur die Anforderungen an die Software bekannt.
Dies ist die einzige Referenz gegen welche das Verhalten der Software be-
wertet werden kann und welches als Grundlage fur die Testfallerstellung
dient. Der Begriff grey-box Testverfahren stammt aus der testgetriebenen
42
Entwicklung, wie sie beispielsweise in [55] publiziert wird. Der grey-box
Test hat mit dem white-box Test gemeinsam, dass er von dem Entwickler
geschrieben wird. Mit dem black-box Test besteht die Gemeinsamkeit, dass
die Interna der Software zum Zeitpunkt der Testerstellung nicht bekannt
sind, da der Test vor der Software erstellt wird.
Die white-box Testverfahren werden haufig im Modultest eingesetzt. Je
komplexer das Testobjekt wird, desto weniger ubersichtlich werden die Ver-
fahren. In der Praxis hat es sich bewahrt, mit Hilfe der black-box Testver-
fahren Stimuli fur das Testobjekt zu bestimmen und durch den werkzeug-
gestutzten Einsatz von white-box Testverfahren nachzuweisen, zu welcher
Code-Uberdeckung diese Stimuli fuhren. Dieses Vorgehen stellt einen guten
Kompromiss dar. Bei einer reinen black-box Betrachtung des Testobjekts
lasst sich zwar nachweisen, dass das Testobjekt seinen Anforderungen ge-
nugt, es kann jedoch nicht festgestellt werden, ob es unbenutzten Imple-
mentierungscode gibt, oder warum es bei der Eingabe bestimmter Werte
zu einem Absturz bzw. Verklemmen des Testobjekts kommt. Auf der an-
deren Seite besteht bei der reinen Erstellung der Testfalle mit white-box
Verfahren die Gefahr, Anforderungen nicht implementiert zu haben und
dies aufgrund der rein codezentrierten Betrachtungsweise nicht zu bemer-
ken. Die white-box Testverfahren haben den großen Vorteil, dass durch die
Messung der Codeuberdeckung nach den jeweiligen Kriterien ein quantifi-
zierbares Testergebnis erzielt wird.
2.6.3. White-box Testentwurfsmethoden
Den white-box Testentwurfsmethoden liegt die Kenntnis der Struktur der
Software zugrunde. Aus dieser Kenntnis leiten sich Kriterien fur die Uber-
deckungsmessung ab.
2.6.3.1. Kontrollflussbezogene Kriterien
Anhand des in Bild 2.9 dargestellten Kontrollflussgraphen einer Software
werden die kontrollflussbezogenen Kriterien erlautert [46,52]. Der Kontroll-
flussgraph ist dabei folgendermaßen definiert:
43
Definition 2.1 (Kontrollflussgraph) Der Kontrollflussgraph eines
Programms ist ein gerichteter Graph.
Knoten: Den Knoten des Graphen sind Anweisungen zugeordnet. Es kon-
nen einem Knoten ganze Anweisungsfolgen, die keine bedingten An-
weisungen enthalten, zugeordnet sein. Das komplette Entscheidungs-
pradikat einer bedingten Anweisung ist dagegen einem sogenannten
Entscheidungsknoten zugeordnet, wobei fur jeden Ausgang der
Entscheidung eine Kante zu einem Nachfolgerknoten existiert, die
mit true bzw. false markiert ist. Um Initialisierungsvorgange model-
lieren zu konnen (z.B. Parameterubergabe bei Prozeduren), enthalt
ein Kontrollflussgraph nur einen Knoten (genannt: Anfangsknoten),
der keinen Vorgangerknoten hat und auch nur eine ausgehende Kan-
te, genannt Anfangskante, besitzt. Außerdem soll ein Kontrollfluss-
graph nur einen Knoten, genannt Endknoten, enthalten, der keinen
Nachfolger hat.
Kanten: Die Kanten stellen die Verbindungen zwischen Anweisungen und
Anweisungsnachfolgern dar.
IF
IF
DO
ENDIF
ENDIF
WHILE
a
b
c
d
e
f
g
h
i
Legende
Knoten, Anweisung
Kante, Kontrollfluss
Benennung der Kantenn
Bild 2.9.: Kontrollflussgraph zur Verdeutlichung der Uberdeckungskrite-rien.
Anweisungsuberdeckung (C0): Eine vollstandige Uberdeckung aller
Anweisungen kann in dem in Bild 2.9 dargestellten Beispiel schon
mit einem Testfall { a, b, f, g, h, d, e } erreicht werden. Konnen
Anweisungen nicht ausgefuhrt werden, so kann dies ein Hinweis auf
nicht erreichbaren Programmtext sein.
44
Zweiguberdeckung (C1): Ziel dieses Kriteriums ist es, die Uberdeckung
aller Kanten des Kontrollflussgraphen zu erzielen. Anweisungsfreie
Zweige einer Bedingung mussen zur Erreichung der vollstandigen
Zweiguberdeckung durchlaufen werden. Die Zweiguberdeckung stellt
damit ein starkeres Kriterium als die Anweisungsuberdeckung dar.
Einfache Bedingungsuberdeckung (C2) : Setzt sich eine Bedingung
aus mehreren logisch verknupften Teilbedingungen zusammen, so ist
das Ziel der einfachen Bedingungsuberdeckung, dass jede atomare
Teilbedingung sowohl den Wert wahr als auch falsch annimmt. Ei-
ne atomare Teilbedingung ist dabei dadurch definiert, dass sie keine
Operatoren, wie AND, OR oder NOT, sondern hochstens Relatio-
nen wie ≤ oder = enthalt. Besteht eine Bedingung aus mehreren
atomaren Teilbedingungen, kann es bei der einfachen Bedingungs-
uberdeckung dazu kommen, dass die Gesamtbedingung immer den
gleichen Wert annimmt, damit ist sie ein schwacheres Kriterium als
die Zweigabdeckung.
Mehrfache Bedingungsuberdeckung (C3): Bei der Mehrfachbedin-
gungsuberdeckung wird gefordert, dass alle Kombinationen der
Wahrheitswerte der atomaren Teilbedingungen berucksichtigt wer-
den. Damit wird die Gesamtbedingung mindestens einmal wahr und
falsch.
Minimale Mehrfachbedingungsuberdeckung: Da alle Kombinatio-
nen in der Praxis oft nicht immer erreicht werden konnen und die
Anzahl der Kombinationen 2n bei n Teilbedingungen betragt, wur-
de die minimale Mehrfachbedingungsuberdeckung eingefuhrt, welche
nur noch die Kombinationen fordert, welche die Gesamtbedingung
mindestens einmal zu wahr und einmal zu falsch werden lassen kon-
nen.
Pfaduberdeckung (C4): Die Pfaduberdeckung fordert die Ausfuhrung
aller unterschiedlichen Pfade durch ein Testobjekt, dies bedeutet,
dass auch Schleifen vollstandig durchlaufen werden mussen.
45
2.6.3.2. Datenflussbezogene Kriterien
Dem datenflussbezogenen Testentwurf liegt der Gedanke zugrunde, dass
eine Anweisung auch deshalb falsch sein kann, weil die innerhalb der Be-
rechnung verwendeten Variablen falsch initialisiert wurden oder weil sie
falsche Werte referenzieren. Zur Erlauterung der Kriterien wird der Daten-
flussgraph definiert [46]:
Definition 2.2 (Datenflussgraph) Ein Datenflussgraph ist ein Kon-
trollflussgraph, bei dem jedem Knoten k die Mengen DEF(k), UN-
DEF(k) und REF(k) zugeordnet sind.
DEF(k) ist die Menge der Variablen x, fur welche die Anweisungsfolge
f , die zum Knoten k gehort 4, der Variablen x einen Wert zuweist,
der nicht anschließend in f in einen undefinierten Zustand uberfuhrt
wird.
UNDEF(k) ist die Menge der Variablen x, fur welche die Anweisungsfol-
ge f , die zum Knoten k gehort, die Variable x in einen undefinierten
Zustand uberfuhrt, ohne x anschließend in f neu zu definieren.
REF(k) ist die Menge der Variablen x, fur welche die Anweisungsfolge
f , die zum Knoten k gehort, die Variable x referenziert, ohne dass
x vorher in f in einen undefinierten Zustand uberfuhrt wird. (Da-
bei wird generell vorausgesetzt, dass innerhalb eines Knotens k kein
lokaler Datenfluss vorkommt. Andernfalls ist die Anweisungsfolge so
auf zwei oder mehrere Knoten aufzuteilen, dass dieser Datenfluss in-
nerhalb eines Knotens eliminiert wird.)
Basierend auf dem Datenflussgraphen werden wiederum verschiedene Uber-
deckungskriterien definiert: Beispiele dafur sind Testsuiten, welche den Kri-
terien Alle Definitionen oder Alle Referenzen genugen.
2.6.3.3. Bewertung der white-box Testentwurfsmethoden
Die Effektivitat der white-box Testentwurfsmethoden lasst sich nach [28]
grob quantifizieren: Kontrollflussorientiertes Testen erkennt 85% der Feh-
4Es kann sich - je nach Abstraktionsgrad des Kontrollflussgraphen - um eine oder mehrere sequenziellauszufuhrende Anweisungen handeln, die zum Knoten k gehoren.
46
ler, datenflussbezogenes Testen deckt 70% der Fehler auf, ausdrucks- und
anweisungsbezogenes Testen5 erkennt 41% der Fehler. In den zugrunde lie-
genden Untersuchungen werden jedoch nicht alle Kriterien einer Testklasse
(bspw. Kontrollfluss) verwendet, so dass das Ergebnis mit Vorsicht zu be-
handeln ist.
Dennoch stellen solche Aussagen die Grundlage dafur dar, dass in der Re-
gel die kontrollflussorientierten Kriterien verwendet und gelehrt werden.
Im Zusammenhang mit objektorientiert programmierter Software gewin-
nen die datenflussorientierten Kriterien jedoch wieder an Relevanz. Bei
objektorientierter Software ist eine Kontrollflussuberdeckung fur die ein-
zelnen Methoden oft mit wenig Aufwand zu erreichen, da die Methoden in
der Regel nicht komplex verfasst werden. Der vorrangig zu testende Aspekt
ist hier das Zusammenspiel der Methoden [52], welche um die gemeinsam
genutzen Daten, die Attribute, aufgebaut sind. Es wird angenommen, dass
ein datenflussorientiert durchgefuhrter Test von Klassen erheblich bessere
Aussagen liefert als ein kontrollflussorientierter Klassentest. Derzeit gibt es
jedoch kaum Werkzeuge auf dem Markt, welche den datenflussorientierten
Klassentest unterstutzen [35]. Es ist daher naheliegend, den Datenfluss der
Software mit einem statischen Datenflussanalysewerkzeug zu untersuchen.
Partielle Ordnung der Kriterien Um die Auswahl eines Uberde-
ckungskriteriums zu ermoglichen, gibt es Untersuchungen, welches der an-
gegebenen Kriterien welche anderen inkludiert. Fur die kontrollflussorien-
tierten Kriterien ist diese Ordnung in Form eines gerichteten Graphen in
Bild 2.10 dargestellt. Der gerichtete Verweis von einem Kriterium auf ein
anderes ist so zu deuten, dass das Kriterium, von welchem die gerichtete
Kante ausgeht, das folgende beinhaltet.
Zusammenfassung Eine Testsuite, welche basierend auf dem Kontroll-
fluss eines Programms erstellt wird, hat eine hohere Fehlerfindungswahr-
scheinlichkeit als eine auf dem Datenfluss basierende. Innerhalb der kon-
trollflussbezogenen Testentwurfsmethoden hat das Kriterium der Pfad-
uberdeckung das hochste Fehlerfindungspotenzial, bedingt aber gleichzeitig
den großten Aufwand fur die Generierung und Ausfuhrung einer solchen
5Dieses Kriterium wird an dieser Stelle nicht weiter erlautert, naheres siehe [46]
47
Anweisungs-
überdeckung (C0)
Zweig-
überdeckung (C1)
Einfache
Bedingungs-
überdeckung (C2)
Mehrfache
Bedingungs-
überdeckung (C3)
Pfad-
überdeckung (C4)
Minimale Mehrfach-
Bedingungs-
überdeckung
Anweisungsüberdeckung: 18% - 41%
Zweigüberdeckung: 16% - 92%
Pfadüberdeckung: das dreifache der Zweigüberdeckung (62% - 64% statt 21% [How 76,
How78b]
Prozentzahlen der gefundenen Fehler – Von Riedemann mit
Literaturstellen belegt
Bild 2.10.: Ordnungsgraph der kontrollflussbasierten white-box Testent-wurfsverfahren.
Testsuite. Einen guten Kompromiss stellt die Zweiguberdeckung dar, da
sie ein großes Fehleraufdeckungspotenzial bei einem vertretbaren Aufwand
hat.
Die Fehler der Klasse Abweichungen von spezifizierten Anforderungen kon-
nen prinzipiell nicht mit den white-box Testentwurfsmethoden gefunden
werden. Im Folgenden werden einige dieser Fehler aufgezahlt:
• Abweichungen von der Spezifikation.
• Fehler bei extremen oder speziellen Werten, die fur die Funktion wich-
tig sind.
• Fehlende Pfade bzw. Funktionen.
• Schnittstellenfehler. Diese Fehler bedurfen der Referenz durch die
Anforderungen oder das Design der Nachbarkomponenten.
• Initialisierungsfehler.
2.6.4. Black-box Testentwurfsmethoden
Testentwurfsmethoden, bei denen die Kenntnis der Implementierung nicht
zugrunde gelegt wird, werden black-box Testentwurfsmethoden genannt.
48
Im Folgenden werden die in der Ubersicht aus Bild 2.7 aufgefuhrten Test-
entwurfsmethoden naher erlautert.
2.6.4.1. Aquivalenzklassenbildung und Grenzwertanalyse
Mit Hilfe der Aquivalenzklassenbildung und Grenzwertanalyse wird der
Eingabedatenraum fur das System Under Test (SUT) strukturiert. Eine
Aquivalenzklasse ist dadurch gekennzeichnet, dass das Systemverhalten fur
diesen Eingabebereich gleich bleibt. Grenzwerte kennzeichnen den Uber-
gang zwischen Aquivalenzklassen. Als Uberbegriff fur Aquivalenzklassen
und Grenzwerte wird im Folgenden die Bezeichnung Klassifikation ver-
wendet. Im Kontext funktionaler Aquivalenzklassen kann dabei ein im
Softwaretest vorgegebener zeitlicher Stimulationsverlauf beispielsweise in
die Klassen konstant und dynamisch aufgeteilt werden. Bezogen auf den
Test einer Funktion r = f(x, y) im Modultest kann der Datenraum der
Ubergabeparameter mit Klassifikationen strukturiert werden, wie das Bild
2.11 darstellt. Konkrete Datenpunkte (x, y) fur den Test sind somit entwe-
r = f(x,y)
x
y
r = f(x,y)
y
[Äquivalenzklasse x1]
[Äquivalenzklasse y1]
[Grenzwert yn]
[Grenzwert xm]
[Datenpunkte]
Bild 2.11.: Aquivalenzklassen und Grenzwerte.
der Reprasentanten einer Aquivalenzklasse, die Auswahl eines Grenzwer-
tes oder beides. Es ist zu beachten, dass fur jeden gewahlten Datenpunkt
(x, y) auch ein erwarteter Ruckgabewert r′ angegeben werden muss, damit
ein Test der Form r′ == f(x, y)6 moglich ist.
6Der Operator == ist der Sprache C entnommen und pruft, ob der Wert auf der linken Seite desOperators dem auf der rechten Seite entspricht.
49
2.6.4.2. Auswahlstrategien
Die Auswahl konkreter Eingabe-Datenpunkte ist eine im Rahmen des Tes-
tens zentrale Fragestellung. Im Zusammenhang mit Kombinatorik wird die-
se Frage auch in anderen Zusammenhangen gestellt, beispielsweise in der
statistischen Versuchsplanung [43]. Um bei der allgemeinen Kombinatorik
zu bleiben, wird die folgende Nomenklatur verwendet. Die Eingangsgroßen
des SUT werden als Faktoren F bezeichnet.
F = {F1, . . . , Fk} card(F) = k (2.1)
Die verschiedenen Klassifikationen der Faktoren werden als Level l bezeich-
net. Jedem Faktor ist ein Menge von Leveln L zugeordnet,
F ⊆ F× L ⇒ {F1, L1}, {F2, L2}, . . . {Fk, Lk}, (2.2)
fur welche gilt:
Li = {li,1, . . . , li,ni} card(Li) = ni (2.3)
In Bild 2.12 ist ein SUT mit k = 3 Faktoren dargestellt, welche jeweils
in drei Level unterteilt sind (n1 = n2 = n3 = 3). Der Eingabedatenraum
des SUT wird dadurch in 27 Datenpunkte unterteilt. Es stellt sich nun die
Fehlerregion Einfacher Fehler
C
Level A2 Level A3
Level B2
Level A1
Level C2
Level C3
Datenraum
des SUT
A
BLegende:
Orthogonales Feld
Minimale Auswahl
Punkte liegen
übereinander
Bild 2.12.: Visualisierung der Kombinatorik im Datenraum [43].
Frage, wie die Datenpunkte fur den Test ausgewahlt werden sollen. Um die
Relevanz dieser Auswahl zu veranschaulichen, stellt das Bild eine Fehler-
region dar, welche eine Fehlerklasse visualisiert, die prinzipiell durch die
50
Auswahl verschiedener Datenpunkte gefunden werden kann. Zudem ist ein
einfacher Fehler dargestellt, dass heißt er kann nur mit einer einzigen Ein-
gabedatenkombination gefunden werden. Es wird deutlich, dass die Menge
der ausgewahlten Datenpunkte daruber entscheidet, wie wahrscheinlich es
wird, Fehler zu finden. Schon eine Untermenge der moglichen Datenpunkte
vermag eine Fehlerregion aufzudecken. Das Auffinden des einfachen Fehlers
kann jedoch entweder durch Gluck oder Erfahrung erfolgen oder durch die
vollstandige Auswahl aller moglichen Datenpunkte fur den Test7. Ferner
wird die Relevanz der Auswahl der Klassifikationen ersichtlich. Wenn der
Datenraum zu grob strukturiert wird, so ist der einfache Fehler ebenfalls
nicht zu finden.
Im Folgenden werden verschiedene Auswahlstrategien vorgestellt:
1. Orthogonale Felder
2. Minimale Auswahl
3. Maximale Auswahl
4. Weitere Losungen
Orthogonale Felder Ein orthogonales Feld ist eine spezielle Matrix, de-
ren Auswahl konkreter Eingabe-Datenpunkte dazu fuhrt, dass immer zwei
Eingangsgroßen paarweise voneinander unabhangig sind. Dies fuhrt also
dazu, dass immer der Einfluss zweier Faktoren auf das SUT getestet wird.
Im Rahmen des Testens ist diese Annahme relevant, da davon ausgegangen
wird, dass die meisten Fehler in Software in einer paarweisen Interaktion
auftreten [32].
Bestimmung orthogonaler Felder In Anlehnung an die Ausfuhrungen
in [56] wird ein allgemeines orthogonales Feld folgendermaßen definiert:
O(c, k, n, t) (2.4)
Dabei haben die Ubergabeparameter folgende Bedeutung:
7Da die Datenraume in der Praxis haufig nicht so uberschaubar sind, ist es aus zeitlichen Grunden nichtimmer moglich, vollstandig zu testen.
51
c: Anzahl der Eingabe-Datenpunkte. Dies entspricht der Anzahl der Zei-
len.
k: Anzahl der Faktoren. Dies entspricht der Anzahl der Spalten.
n: Anzahl der Level, es gilt: n = max(ni).
t: Starke der Matrix. Alle t-fachen Kombinationen kommen gleich oft vor.
In jeder c× t Untermatrix kommen alle moglichen nt t-Tupel gleich oft
vor.
Ein orthogonales Feld der Starke t = 2, welches der Auswahl paarweiser
Kombinationen entspricht, lasst sich nach dem Algorithmus von Bose [18]
berechnen:
O(n2, n + 1, n, t = 2) kurz: O(n2, n + 1, n) (2.5)
Die Anzahl der Level n muss dabei eine ganzzahlige (m) Potenz einer
Primzahl (p) sein.
n = pm (2.6)
Die einzelnen Elemente Oij(n2, n + 1, n) der Matrix mit i = 1, . . . , n2 und
j = 1, . . . , n + 1 werden dabei folgendermaßen bestimmt. Sei
u =
⌊(i− 1)
n
⌋+ 1 und w = ((i− 1) mod n) + 1 (2.7)
dann gilt:
Oi1 = u und Oi2 = w (2.8)
Die ubrigen Elemente der Matrix berechnen sich zu:
Oij(n2, n + 1, n) = q (2.9)
Fur j > 2 ist q so zu bestimmen, dass unter Verwendung der Arithmetik
des Galois-Feldes (GF) der Ordnung n
GF (n) = {x0, x1, . . . , xn} mit x0 = 0 und x1 = 1 (2.10)
52
und der Galois-Feld Arithmetik
xq = xj−2 · xu + xw (2.11)
gilt.
Die Berechnung des benotigten Galois-Feldes ist in [27] beschrieben. Durch
diesen Algorithmus werden orthogonale Felder mit folgenden Eigenschaften
erzeugt:
• Die erste Zeile besteht aus lauter Einsen.
• Die ersten n Zeileneintrage gleichen den Zeilenindizes, mit Ausnahme
der ersten Spalte.
• Die erste Spalte besteht aus n Einsen, n Zweien usw.
• Jede Spalte der Matrix, mit Ausnahme der ersten, besteht aus Per-
mutationen von (1, . . . , n).
Voraussetzungen fur den Einsatz orthogonaler Felder Aus der Be-
rechnungsvorschrift fur ein orthogonales Feld mit paarweiser Uberdeckung,
wie es in Gleichung (2.5) beschrieben ist, zusammen mit der Vorgabe in
Gleichung (2.6), dass die Anzahl der diskreten Auspragungen eines Faktors
(Level) einer ganzzahligen Potenz einer Primzahl entsprechen muss, wird
ersichtlich, dass nicht fur jeden Anwendungsfall ein passendes orthogona-
les Feld bestimmt werden kann. Um diesem Umstand Rechnung zu tragen,
gibt es verschiedene Ansatze.
In [42] werden Techniken beschrieben, wie ein orthogonales Feld an einen
konkreten Anwendungsfall mit einer vorgegebenen Anzahl von Parametern
und diskreten Auspragungen angepasst werden kann. Dabei wird auf eine
Tabelle von bereits vorbestimmten orthogonalen Feldern zuruckgegriffen.
Wenn sich Faktoren gegenseitig beeinflussen, kann es sein, dass der Effekt
der Interaktion zweier Faktoren den Effekt eines anderen Faktors uber-
deckt. Dazu ist fur jedes orthogonale Feld eine Interaktionstabelle spezifi-
ziert, welche angibt, welche Spalte von welchen Faktorkombinationen uber-
deckt wird. Auszuge aus dieser Interaktionstabelle konnen durch lineare
Graphen dargestellt werden. Der Einsatz orthogonaler Felder zur Auswahl
von Eingabe-Datenpunkten fur den Test verspricht einen methodischen
53
Vorteil durch die mathematische Eigenschaft, paarweise Kombinationen
von Datenpunkten zu untersuchen. Praktisch zeigen die vorangegangenen
Ausfuhrungen jedoch, dass ein orthogonales Feld nicht ohne Fachwissen fur
eine Problemstellung adaptiert werden kann. Verschiedene Ansatze einer
Realisierung dieser Testvorgehensweise sind unter [2] publiziert. Ein mog-
licher Ansatz wird von [56] durch die Implementierung des Werkzeuges
T-Config bereitgestellt. Die von Williams vorgeschlagene Vorgehenswei-
se ermoglicht es, die Auffindung eines geeigneten orthogonalen Feldes auf
zwei Eingabeparameter zu reduzieren: Die Anzahl der Faktoren (k) und
ihrer diskreten Auspragungen (n). Weist das wirkliche Problem eine unter-
schiedliche Anzahl von Auspragungen ni auf, muss die großte Auspragung
i = max(ni) als Grundlage fur die Auswahl eines passenden orthogona-
len Feldes herangezogen werden. Die damit uberbestimmten Auspragun-
gen konnen beliebig vergeben werden, durfen aber nicht geloscht werden,
da sonst die Orthogonalitatseigenschaft des Feldes verloren geht.
Fur den Fall, dass die Anzahl der Faktoren und Auspragungen nicht den
Anforderungen aus den Gleichungen (2.5) und (2.6) genugen, wird eine
Uberdeckungsmatrix O′ berechnet, welche annahernd die mathematischen
Eigenschaften eines orthogonalen Feldes erfullt.
Faktor A Faktor B Faktor C
Level A1 Level A2 Level A3 Level B1 Level B2 Level B3 Level C1 Level C2 Level C3
SUT
Datenpunkt 1
Datenpunkt 2
Datenpunkt 3
Datenpunkt 4
Datenpunkt 5
Datenpunkt 6
Datenpunkt 7
Datenpunkt 8
Datenpunkt 9
123
312
231
213
132
321
333
222
111
3
3
3
2
2
2
1
1
1
O’(9,3,3,2)
O(9,4,3,2)
Bild 2.13.: Darstellung der Auswahl von Eingabe-Datenpunkten durch einreduziertes orthogonales Feld O′ nach [56].
54
In Bild 2.13 wird dies anhand des mit Bild 2.12 eingefuhrten Beispiels
verdeutlicht, in welchem jeder der drei Faktoren (k=3) drei Level (n=3)
besitzt. Aus Gleichung (2.5) resultiert, dass sich fur das Problem nur
das orthogonale Feld O(9, 4, 3, 2) bestimmen lasst. Das Werkzeug T-
Config berechnet fur diese Konfiguration das reduzierte orthogonale Feld
O′(9, 3, 3, 2). Die durch das reduzierte orthogonale Feld O′ vorgegebene
Auswahlmatrix ist dabei in einer Klassifikationsbaumdarstellung visuali-
siert. Die Zahlen in der Matrix geben den Level an, die Spalte steht fur
den Faktor. Die Orthogonalitatseigenschaft der Matrix ist dadurch gekenn-
zeichnet, dass jeder Level in jedem Spaltenpaar vorkommt und zwar gleich
oft. Diese Ausgleichseigenschaft ist mathematisch dafur hinreichend, dass
jeweils zwei Spaltenvektoren im kombinatorischen Sinne voneinander linear
unabhangig sind, wodurch der Einfluss dieser beiden Faktoren voneinan-
der unabhangig untersucht wird. Um den durch das reduzierte orthogonale
Feld O′ untersuchten Datenraum zu kennzeichnen, sind die Datenpunkte
der Matrix in das Bild 2.12 eingetragen.
Minimale Auswahl: Bei der minimalen Auswahl wird jeder Level aus
jedem Faktor mindestens einmal ausgewahlt. Unter Berucksichtigung der
Gleichungen (2.1) und (2.3), sowie der Beziehung n = max(ni) wird die
Auswahlmatrix durch die Gleichung (2.12) bestimmt.
Oi,j =
{lj,i i = 1(1)n, j = 1(1)k
lj,1 Wenn nj < i(2.12)
In der Gleichung (2.12) symbolisiert die Notation i = 1(1)n, j = 1(1)k eine
geschachtelte Schleife der Tiefe zwei. In Bild 2.14 ist die minimale Aus-
wahlmatrix fur das aufgefuhrte Beispiel mit den drei Faktoren dargestellt.
Die drei ausgewahlten Datenpunkte sind schraffiert in den Datenraum des
SUT in Bild 2.12 eingetragen. Alle Datenpunkte wurden auch durch das
reduzierte orthogonale Feld ausgewahlt.
Vollstandige Auswahl: Bei der vollstandigen Auswahl werden alle
Punkte des Datenraums ausgewahlt. Die Auswahlmatrix wird zeilenwei-
se nach der Gleichung (2.13) aufgebaut, wobei die Anzahl der Zeilen c dem
55
Faktor A Faktor B Faktor C
Level A1 Level A2 Level A3 Level B1 Level B2 Level B3 Level C1 Level C2 Level C3
SUT
Datenpunkt 1
Datenpunkt 2
Datenpunkt 3
Bild 2.14.: Visualisierung der minimalen Auswahlstrategie.
Produkt der Level-Anzahlen ni der Faktoren entspricht.
O(c,:) = [l1,h, . . . , lk,j] mit
c = 1(1)∏k
i=1 ni
h = 1(1) ni, · · · , j = 1(1) nk
(2.13)
In der Darstellung gilt, dass die Indizes der Matrix den Index der Zeile
und der Spalte eines Matrix-Elements reprasentieren. Der Operator : steht
fur alle Elemente einer Dimension. Die Notation (c,:) beschreibt damit alle
Elemente in der c-ten Zeile der Matrix. Die Syntax h = 1(1) ni, · · · , j =
1(1) nk in Gleichung (2.13) symbolisiert eine geschachtelte Schleife mit der
Tiefe k. Bezogen auf das Beispiel wird die Auswahlmatrix O durch die
Gleichung (2.14) bestimmt. Die Matrix hat c = 27 Zeilen, was der Anzahl
der Datenpunkte in dem Datenraum des SUT entspricht.
O(c,:) = [lA,h, lB,i, lC,j] mit
c = 1(1) (nA · nB · nC)
h = 1(1) nA
i = 1(1) nB
j = 1(1) nC
(2.14)
Zusammenfassung Die Tabelle 2.1 fasst die vorgestellten Auswahlstra-
tegien in einem Uberblick zusammen. Von weiterem Interesse sind die ver-
schiedenen Anzahlen der durch die Strategie gewahlten Datenpunkte.
Abhangig von der Kritikalitat des SUT ist zu entscheiden, welche Aus-
wahlstrategie verwendet werden soll. Mit der maximalen Auswahl wird der
56
Orthogonales Feld O(c = n2, k = n + 1, n = max(ni))
Anzahl Datenpunkte: n2
Minimale Auswahl O(c = n = max(ni), k, n)
Anzahl Datenpunkte: n
Maximale Auswahl O(c =∏k
i=1 ni, k, n)
Anzahl Datenpunkte:∏k
i=1 ni
Tabelle 2.1.: Uberblick zu den Auswahlstrategien.
gesamte Datenraum getestet; wurden die Klassifikationen richtig gewahlt,
besteht die großte Wahrscheinlichkeit Fehler aufzudecken. Phadke, Wil-
liams und Andere berichten von guten Erfahrungen mit orthogonalen Fel-
dern. Fur die Anwendung besteht das großte Problem in der zuverlassigen
Bestimmung eines geeigneten orthogonalen Feldes. Die minimale Auswahl
kann schnell abgetestet werden, untersucht jedoch nur einen kleinen Teil
des Datenraums.
In diesem Kontext soll auf das Werkzeug CTE-XL hingewiesen werden,
welches aus den grundlegenden Arbeiten zu der Klassifikationsbaumme-
thode [29] hervorging. Die Faktoren und Level konnen hierbei manuell
in einen Klassifikationsbaum eingetragen werden. Innerhalb des Werkzeu-
ges sind ebenfalls verschiedene Auswahlstrategien implementiert, welche
im Folgenden, in Anlehnung an die beigefugte Dokumentation, aufgezahlt
werden:
Ein Element aus jedem Faktor: Von den diskreten Auspragungen der
Faktoren wird jeweils eine gewahlt.
Paarweise Kombination: Aus einer Menge von Faktoren K = {a, b, c},mit den jeweiligen diskreten Auspragungen na,b,c, werden paarweise
Kombinationen der Form k1 = (a ·b), k2 = (a ·c), k3 = (b ·c) gebildet.
Dreifache Kombination: Es wird ein der paarweisen Kombination ent-
sprechendes Prinzip angewendet. Aus einer Menge von Faktoren
K = {a, b, c, d} werden Kombinationen der Form k1 = (a · b · c),... gebildet.
n-fache Kombination: Das Prinzip wird auf das n-Fache erweitert.
Die Kombinationsregeln konnen beliebig miteinander kombiniert werden.
57
2.6.4.3. Zustandsbasierter Test
Ein großer Teil der Steuergerate-Software ist durch zustandsbasiertes Ver-
halten gekennzeichnet. Selbst kontinuierliche Regelfunktionen sind haufig
in ein ubergeordnetes diskretes Zustandsverhalten eingebunden. Aus der
Struktur dieses Zustandsdiagramms konnen Testsequenzen generiert wer-
den. In diesem Kontext wird auch haufig von modellbasiertem Testen ge-
sprochen. Die im Rahmen der vorliegenden Arbeit entwickelte Heuristik
basiert ebenfalls auf diesem Verfahren.
2.6.4.4. Erfahrungsbasierte und intuitive Testsequenzermittlung
Trotz der methodischen Testsequenzerstellung wird es immer wieder Test-
sequenzen geben, welche sich nur aus der Systemkenntnis und Erfahrung
eines Testingenieurs ableiten lassen. Um diesem Umstand Rechnung zu
tragen, wird die erfahrungsbasierte und intuitive Testsequenzermittlung
als Testentwurfsmethode aufgefuhrt.
2.7. Aufgabenstellung - Methodisches und
automatisiertes Testen
Den bisherigen Ausfuhrungen ist zu entnehmen, dass Kfz-Steuergerate-
Software hierarchisch entwickelt wird. Zunachst werden einzelne Software-
Module zu Komponenten und spater zur gesamten Software integriert, wie
es Bild 2.1 zeigt.
Der Testprozess wiederholt sich wahrend dieser Integrations- bzw. Teststu-
fen (Bild 2.2).
Die Phase der Testspezifikation ist dabei entscheidend fur die Fahigkeit
der Tests, potenzielle Fehler aufzudecken. Der Einsatz von Testentwurfs-
methoden hilft dabei, die Testspezifikation systematisch aufzubauen.
Es ist anschaulich klar, dass die Tests fur ein Modul der Software auch mit
der gesamten Software zusammenhangen. Es ist jedoch ein technologischer
Unterschied zwischen den Tests auf den verschiedenen Abstraktionsgra-
den gegeben. Inhaltlich werden ebenfalls unterschiedliche Aspekte gepruft,
58
da die Teststufen von unterschiedlichen Entwicklern mit unterschiedlichem
Hintergrundwissen durchgefuhrt werden.
Der Modultest erfolgt in der Regel in der gleichen Entwicklungsumgebung,
in der das Modul erstellt wird. Fur manuell erstellten C bzw. C++ Code ist
dies eine IDE, wie Visual Studio, fur andere Module entsprechend MAT-
LAB/SIMULINK.
Zu einer Komponente integrierte Module weisen haufig schon eine so große
Anzahl von Schnittstellen auf, dass es sich anbietet, den Test wenn moglich
im integrierten Zustand der Software durchzufuhren. Im Automobil-Umfeld
werden dazu haufig Closed-Loop-Verfahren, wie SiL oder HiL, angewendet.
Diese zeichnen sich dadurch aus, dass die zu testende Software gegen ein
Umgebungsmodell ausgefuhrt wird, wie es Bild 2.15 zeigt.
Modul 1
Modul 2Komponente 1
Komponente 2
Steuergerätesoftware
Umgebungsmodell
Modultest
Komponententest
Softwaretest
Bild 2.15.: Unterschiedliche Testabstraktionsschichten.
Das Testziel, eine korrekte Funktion der Software, bleibt dabei zwar unver-
andert, jedoch wechselt der technologische Fokus; dass heißt die Methode
der Softwarestimulation und der Zugriff auf Ein- und Ausgangsgroßen ist
heterogen.
Vor diesem Hintergrund zeigt sich, dass in der Praxis ein großer Teil der
Zeit, welche fur das Testen aufgebracht wird, in die Erstellung der Testin-
frastruktur fließen muss. Ferner konnte festgestellt werden, dass den meis-
ten Entwicklern zwar die Testentwurfsmethoden prinzipiell bekannt sind,
diese aber selten belegbar angewendet werden, da vorhandene Werkzeug-
unterstutzungen nicht immer in das Entwicklungsumfeld passen.
59
Damit ergeben sich fur die Arbeit die folgenden Ziele:
1. Es soll eine Moglichkeit gefunden werden, Testentwurfsmethoden auf
allen Teststufen technologisch wiederverwenden zu konnen.
2. Der Aufwand, die Testinfrastruktur bereitzustellen, soll reduziert
werden.
3. Die black-box Testentwurfsmethoden Zustandsbasierter Test und
Aquivalenzklassenbildung/Grenzwertanalyse sollen praktisch einge-
setzt werden.
60
3. Testframework
Um den Anforderungen aus Kapitel 2 zu genugen, wird das vorgestellte
Testframework konzipiert und implementiert [40]. Die Architektur dieses
Frameworks stellt Schnittstellen zu den im Rahmen der Entwicklung ver-
wendeten Werkzeugen bereit, um Grundinformationen fur die einzubin-
denden Testentwurfsmethoden zu erhalten. Dabei wird in Abschnitt 3.1
diskutiert, welche Informationen aus dem Entwicklungsprozess verwendet
werden konnen. Die methodisch erstellten Testfalle werden zunachst platt-
formunabhangig beschrieben. Diese Beschreibung stellt zugleich ein Kom-
munikationsmittel dar, um den Testinhalt diskutieren und austauschen zu
konnen, ohne die plattformspezifische Implementierungssprache zu verste-
hen. Ausgehend von dieser formalen Basis kann die plattformspezifische
Implementierung durch eine geeignete Transformation erfolgen. Die tech-
nologische Realisierung des Frameworks wird in Abschnitt 3.2 beschrieben.
3.1. Verwendung von Artefakten
aus dem Entwicklungsprozess
Die verwendbaren Artefakte konnen in drei Kategorien eingeteilt wer-
den: Strukturartefakte, Verhalten und Daten. In Anlehnung an die Bilder
2.2 und 2.6 konnen diese Daten hauptsachlich aus dem UML-Design und
MATLAB/SIMULINK-Modellen entnommen werden, wobei aufgrund der
Gegebenheit in dem zugrundeliegenden Projekt zunachst auf UML-Modelle
eingegangen wird.
3.1.1. Strukturartefakte
Strukturartefakte der Software sind im Software-Design bereits formal hin-
terlegt. Dabei handelt es sich um fur den Test wichtige Angaben, wie den
Aufbau einzelner Softwarekomponenten, die Angabe, welche Module vor-
handen sind und welche Ein- und Ausgabeschnittstellen diese zur Verfu-
61
gung stellen, sowie Informationen uber die Datentypen und Werteberei-
che der Schnittstellenparameter. Die Schnittstellen der Software mussen
wahrend des gesamten Entwicklungs- und Testprozesses konsistent sein,
weswegen diese durchgangig wiederverwendet werden mussen. Insbesonde-
re fur die Testfallerstellung konnen diese Schnittstelleninformationen her-
angezogen werden, um einzelne Komponenten uber die Schnittstellen zu
stimulieren. Auf diese Weise kann zwar nicht ausgeschlossen werden, dass
eine notwendige Schnittstelle nicht vorhanden ist; dies zeigt sich jedoch bei
einer durchgangigen Entwicklungskette spatestens bei der Integration.
3.1.2. Verhalten
Verhalten ist in Form von Zustandsmaschinen haufig in den Software-
Anforderungsdokumenten oder spatestens im Software-Design zu finden.
Dabei ist das Verhalten auf unterschiedlichen Detaillierungsstufen des Ent-
wicklungsprozesses beschrieben. So kann sowohl das Verhalten der Gesamt-
software durch eine Zustandsmaschine abgebildet sein, wie auch das Ver-
halten eines einzelnen Software-Moduls. In allen Fallen stellt diese formale
Beschreibung eine wertvolle Basis fur die zustandsbasierte Testsequenzer-
stellung dar. Die Verwendung der Verhaltensinformationen fur die Testfall-
erstellung wird haufig unter dem Stichwort modellbasiertes Testen publi-
ziert. In der Arbeit [44] werden verschiedene Szenarien des modellbasierten
Testens identifiziert:
1. Aus einem Modell werden sowohl der Implementierungscode, als auch
die Testfalle abgeleitet. In diesem Fall ist ein manuelles Verdict not-
wendig. Da die Testfalle auf der gleichen Basis wie der Code beruhen,
konnen automatisiert keine Fehler gefunden werden, es sei denn, der
Codegenerator arbeitet fehlerhaft.
2. Das Modell, aus welchem die Testfalle abgeleitet werden, wird durch
Reverse-Engineering aus der Implementierung der Software abgelei-
tet. Auch in diesem Fall ist ein manuelles Verdict notwendig.
3. Unabhangig von der Implementierung der Software wird ein spezi-
elles Testmodell nur als Basis fur den Test der Software aus den
Anforderungen abgeleitet. In diesem Fall ist die Unabhangigkeit der
62
generierten Testfalle gewahrt und es kann ein automatisches Ver-
dict gebildet werden.
4. Im Unterschied zum vorangegangenen Punkt wird die Software nicht
manuell erstellt, sondern ebenfalls aus einem Modell abgeleitet. Es
ist jedoch nach wie vor ein unabhangiges Testmodell vorhanden, wo-
durch das automatische Verdict weiterhin gerechtfertigt ist.
Unter Berucksichtigung der notwendigen Unabhangigkeit zwischen dem
Testmodell (Basis fur die Testfallableitung) und dem Implementierungsmo-
dell (Basis fur die Generierung der Implementierung) zeigt sich, dass ein
automatisches Verdict nur gultig ist, wenn Test- und Implementierungs-
modell voneinander unabhangig sind. Daraus folgt, dass das Verhalten in
Form einer Zustandsmaschine aus dem Entwicklungsprozess fur die Test-
fallerstellung nur verwendet werden kann, wenn sichergestellt ist, dass die
Implementierung unabhangig von dem Modell erstellt wird oder wenn ein
manuelles Verdict gebildet wird. Da das oberste Ziel die Automatisierung
ist, sollten manuelle Arbeiten jedoch vermieden werden.
3.1.3. Daten
Eingebettete Software fur ein Automobil-Steuergerat enthalt eine Vielzahl
von Daten und Parametern, welche im Entwicklungsprozess in einer for-
malen Form abgelegt werden. Die Wiederverwendung dieser Daten fur den
Test spart den erneuten Eingabeaufwand und stellt eine Grundlage fur die
Testbedatung dar.
3.2. Technologische Realisierung
In Bild 3.1 ist die architektonische und technologische Sicht auf das Fra-
mework dargestellt. Architektonisch hat das Framework drei Aufgaben zu
erfullen:
1. Bereitstellung verschiedener werkzeuggestutzter Verfahren zum Test-
entwurf.
2. Speicherung der generierten Testfalle in einer formalen Testbeschrei-
bungs-Datenstruktur.
63
Artefakte aus dem Entwicklungsprozess /
Testmodell
Werkzeuggestützte Testentwurfsmethoden
Ausführungsplattformen
Exchange.ecore
M2M
M2M
M2M
M2Text
Artefakte aus dem Entwicklungsprozess /
Testmodell
Ausführungsplattformen
Tes
tfra
mew
ork
Testentwurfsmethoden
Formale Testbeschreibung
Codegenerator
Architektonische Sicht Technologische Sicht
Tes
tfra
mew
ork
Testspezifikation.ecore Testbericht.ecore
Bild 3.1.: Technologische Realisierung des Testframeworks.
3. Bereitstellung verschiedener Codegeneratoren, um die Testinhalte
auf den verwendeten Testausfuhrungsplattformen implementieren zu
konnen.
Die technologische Realisierung des Frameworks erfolgt unter Zuhilfenah-
me der in Unterabschnitt 2.4.3 beschriebenen Konzepte der Model Driven
Architecture (MDA). Dadurch ist von vornherein eine Unabhangigkeit der
Implementierung von konkreten Werkzeugen und die Interoperabilitat zwi-
schen verschiedenen Implementierungen vorgesehen. Fur die konkrete Im-
plementierung wird das Eclipse Modeling Framework (EMF) und openAr-
chitectureWare (oAW) verwendet. Die im Rahmen der Arbeit erarbeiteten
Meta-Modelle basieren dadurch auf dem Ecore-Meta-Meta-Modell.
Um die Unabhangigkeit der Testentwurfswerkzeuge von den im Rahmen
der Entwicklung eingesetzen Werkzeuge zu erhalten, wird das Exchange-
Meta-Modell vorgesehen. Diesem kommt die Aufgabe zu, die Informationen
aus dem Entwicklungsprozess aufzunehmen und fur Testentwurfswerkzeuge
zur Verfugung zu stellen. Fur die Integration von Testentwurfswerkzeugen
stehen damit Informationen aus dem Entwicklungsprozess formal zur Ver-
fugung. Das Exchange-Meta-Modell kann nicht generisch angegeben wer-
den, aber im Zusammenhang mit der in Kapitel 5 vorgestellten Heuristik
zum Testentwurf wird eine konkrete Auspragung vorgestellt.
Die generierten Testfalle werden erneut durch M2M in eine formale Test-
beschreibung uberfuhrt. Dieses Format hat die zentrale Aufgabe, die Test-
64
inhalte von den Testausfuhrungsplattformen zu abstrahieren. Ausgehend
von dieser formalen Basis kann durch Modell-zu-Text (M2Text) Transfor-
mation plattformspezifischer Implementierungscode generiert werden. Die
M2Text hat den Vorteil, dass es sich um ein Schablonen (Template) basier-
tes Verfahren handelt. Der Großteil des zu implementierenden Codes wird
dabei in einer durch Schlusselworter angereicherten Vorlage gespeichert.
Die Transformation erganzt diese Schlusselworter mit den Daten aus der
formalen Testbeschreibung. Auf diese Weise kann der Codegenerator sehr
flexibel an verschiedene Anforderungen angepasst werden.
Ein Meta-Modell in Verbindung mit einer Transformations- und ggf. Va-
lidierungsvorschrift kann im Kontext der modellgetriebenen Softwareent-
wicklung als Domanenspezifische Sprache aufgefasst werden.
Definition 3.1 (Domanenspezifische Sprache) Eine Domain Specific
Language (DSL) nach [49] besteht aus einem Meta-Modell, welches die Syn-
tax bzw. die statische Semantik vorgibt, und einer dynamischen Semantik,
um den Konstrukten des Meta-Modells eine Bedeutung zu geben.
Innerhalb des gesamten Konzeptes kommt dem Testspezifikations-Meta-
Modell eine zentrale Bedeutung zu, auf welche im Folgenden eingegangen
wird.
3.2.1. Das Testspezifikations-Meta-Modell
Das Meta-Modell der Testspezifikation hat folgende Aufgaben:
• Die Abstraktion der Testinhalte von den Ausfuhrungsplattformen.
• Die Formalisierung der im Unternehmen verwendeten Nomenklatur
in der Domane Test.
• Die Kommunikation der Testinhalte uber Abteilungsgrenzen hinweg.
• Die Formalisierung der Testerfahrung durch wiederverwendbare Bi-
bliotheken.
Als Wurzelelement des Testspezifikations-Meta-Modells (TS-MM) dient
das Element Testbibliothek. Dieses beinhaltet die Elemente Ordner und
Testspezifikation.
65
Bild 3.2.: Das Meta-Modell der Testspezifikation.
66
Das Meta-Modell sieht vor, dass eine Testspezifikation Elemente vom Typ
Testfallgruppe oder Kombinationsgruppe aggregiert, deren gemeinsamer
abstrakter Basistyp das Element TestfallGruppeAbstrakt ist. Die Testfall-
GruppeAbstrakt beinhaltet Testfall -Elemente. Um im Kontext der in Kapi-
tel 5 entwickelten Heuristik die hierarchischen Beziehungen einer Zustands-
maschine in der Testspezifikation abbilden zu konnen, vermag ein Testfall -
Element wiederum TestfallGruppeAbstrakt-Elemente zu aggregieren. Fur
die Abbildung der orthogonalen Beziehungen der Zustandsmaschine sind
die Elemente Kombinationsgruppe und Tetallkombination vorgesehen. Ein
Testfall -Element beinhaltet das Element Testsequenzaufruf, welches auf
Testsequenz - und Bedatungskombinations-Elemente verweist.
Die Testsequenz wird in den Ordner -Elementen der Testbibliothek verwal-
tet. Die Testsequenz aggregiert Testschritt-Elemente.
Ein Testschritt ist die kleinste mogliche Einheit; ihm werden konkrete Ak-
tionen zugewiesen, wie Methodenaufrufe oder Berechnungsschritte.
Jeder Testschritt kann Testdatum-Elemente aggregieren, welche im Kon-
text des Testschritts entweder Methoden-Parameter oder einzelne Varia-
blen darstellen.
Im Kontext der Aquivalenzklassenbildung und Grenzwertanalyse aus Un-
terabschnitt 2.6.4.1 aggregiert das Element Testdatum WerteBereich-
Elemente, um diese darstellen zu konnen. Einer Aquivalenzklasse Wer-
teBereich ist mindestens ein Repraesentant-Element zuzuordnen.
Das Element Testsequenz ist im Kontext der Testausfuhrung als ausfuhr-
bare Funktion bzw. Methode konzipiert, weshalb diesem mit dem Element
Testdatensatz die Summe der Testdatum-Elemente der zugeordneten Test-
schritt-Elemente zugewiesen wird.
Bezugnehmend auf die in Unterabschnitt 2.6.4.2 eingefuhrten Auswahlstra-
tegien entspricht das Element Testsequenz dem SUT, die Elemente Testda-
tum den Faktoren und die Elemente Wertebereich den diesen zugeordneten
Leveln. Das Element Bedatungskombination entspricht einem ausgewahlten
Datenpunkt und das Element Testdatensatz der Summe der kombinierten
Datenpunkte.
67
Anwendungsmoglichkeiten im Framework ergeben sich durch die
Technologie des EMF derart, dass ein grafischer Editor aus dem TS-MM
erzeugt werden kann, welcher auch die manuelle Instanziierung des Meta-
Modells ermoglicht. In diesem Editor ist zur Beschrankung der Komplexitat
zunachst die minimale Auswahlstrategie implementiert, so dass nach Anga-
be von Testschritt, Testdatum und Wertebereich die minimale Anzahl an
Bedatungskombinations-Elementen fur eine Testsequenz erzeugt wird. In
Bild 3.3 ist dies anhand eines Beispiels illustriert. Es ist eine Testsequenz
mit zwei Testschritten und insgesamt vier Testdaten dargestellt. Die ma-
ximale Anzahl von WerteBereich-Elementen ist drei. Daraus ergeben sich
die dargestellten drei Bedatungskombinationen.
Bild 3.3.: Anwendung von Auswahlstrategien in dem TS-MM.
3.2.2. Das Testbericht Meta-Modell
Im Kontext des funfphasigen Testprozesses, welcher in Abschnitt 2.2 ein-
gefuhrt worden ist, ermoglicht das TS-MM die Formalisierung der Testin-
halte.
68
Das Framework sieht vor, durch die Implementierung unterschiedlicher
Codegeneratoren als M2Text-Transformation, die Inhalte des TS-MM in
Code zu uberfuhren, welcher gegen das SUT ausgefuhrt werden kann.
Wahrend der Ausfuhrung hat prozessgemaß eine Protokollierung und Be-
wertung stattzufinden. Zu diesem Zweck ist das Testbericht-Meta-Modell
vorgesehen, welches in Bild 3.4 dargestellt ist.
Bild 3.4.: Der Testbericht als Teilaspekt der Testbeschreibung.
Die Elemente des Meta-Modells referenzieren auf die Elemente des TS-MM.
Innerhalb der EMF-Technologie ist es moglich, eine in XML-serialisierte
Instanz des Modells wieder in das Java-Objektmodell einzulesen und dy-
namisch zu verwalten.
69
Dieses Konzept wird fur den Testbericht wie folgt angewandt: Die Code-
generatoren werden so geschrieben, dass wahrend der Testausfuhrung eine
XML-Report-Datei geschrieben wird, welche eine Instanz des Testbericht-
Meta-Modells ist, wie es Listing 3.1 darstellt. Durch den Report-Befehl
findet wahrend der Testausfuhrung eine Dateiausgabe statt.
1 i f ( Bedingung in einem T e s t s c h r i t t ){2 Report (<T e s t s c h r i t t Name=”fahren ”
3 IDTes t s ch r i t t=”032984 ” Verdict=”bestanden ”> , Bedingung )
4 } e l s e {5 Report (<T e s t s c h r i t t Name=”fahren ”
6 IDTes t s ch r i t t=”032984 ” Verdict=”nichtbestanden ”> , Bedingung )
7 }
Listing 3.1: Exemplarische Implementierung von Report-Code.
Dadurch entsteht mit jeder Testausfuhrung eine Bericht-Datei, welche zu-
nachst uber die Struktur- und Namensgleichheit der Testbericht-Elemente
mit der Testspezifikation in Verbindung gebracht werden kann. Technolo-
gisch ist es uber die Referenzbeziehung zu den TS-MM-Elementen auch
moglich, die Beziehung automatisiert herzustellen.
3.2.3. Codegenerierung
Die als M2Text-Transformation mit den Mitteln von oAW realisierte Code-
generierung soll an dieser Stelle exemplarisch aufgezeigt werden. Die The-
matik ist ausfuhrlich in [26] beschrieben. Die M2Text-Transformation be-
dient sich der XPAND Sprache, deren wesentliches Element das Template
ist, welches mit dem Schlusselwort «DEFINE» eingeleitet wird. Das in Lis-
ting 3.2 dargestellte Template ist fur das Element Testspezifikation des
TS-MM definiert. Das Template erzeugt die Implementierung der Metho-
de run der aus dem Ubergabewert «className» ubergebenen Klasse. Darin
wird fur jedes enthaltene Testfallgruppen-Element der in den Zeilen 5 bis
10 dargestellte Code des Listings erzeugt. Die Arbeitsweise der Transfor-
mation wird an dem Beispiel des Methodenaufrufs in Zeile 7 erlautert.
Fur die Eingabe einer Testfallgruppe, deren Attribut Name mit dem Wert
Zustand_AUS_EIN belegt ist, wird der Code TF_Zustand_AUS_EIN(); ge-
neriert.
70
1 «DEFINE RunBody( St r ing className , S t r ing sutClassName )
2 FOR t e s t : : T e s t s p e z i f i k a t i o n »3 void «className» : : run ( )
4 { «FOREACH t h i s . T e s t f a l l g r up p e AS t fg»5 th i s−>r e s e t ( ) ;
6 t ry {7 TF «tfg . Name» ( ) ;
8 } catch ( except ion &e ) {9 f p r i n t f ( s tde r r , ”\ n t e s t c a s e TF «cppIdent i f i e r ( t f g .Name)» . . . ) ;
10 }11 «ENDFOREACH»12
13 «PROTECT CSTART ’/∗ ’ CEND ’∗/ ’ ID t h i s .Name + ” u s e r t c c a l l s ”»14 // Protected Region f u r e i g ene Tes t f a l l g ruppen
15 «ENDPROTECT»16 }17 «ENDDEFINE»
Listing 3.2: Exemplarische Darstellung der M2Text-Transformation.
Das in Zeile 13 dargestellte Schlusselwort leitet einen geschutzten Bereich
ein, dessen Inhalt bei erneuter Codegenerierung nicht mehr uberschrieben
wird. Auf diese Weise bleiben manuelle Anpassungen unangetastet.
Es wird deutlich, dass es mit Hilfe der XPAND Sprache komfortabel mog-
lich ist, einen Codegenerator fur verschiedene Zielsprachen zu schreiben.
Der großte Aufwand in der Erstellung des Codegenerators liegt darin, dass
der Implementierer sowohl die Generatorsprache als auch die Zielsprache
beherrschen muss.
3.2.4. Zusammenfassung
Durch die Konzeption des Testframeworks und die Definition der beiden
Meta-Modelle fur die Testspezifikation und den Testbericht ist eine Basis
geschaffen, welche es ermoglicht, verschiedene werkzeuggestutzte Testent-
wurfsmethoden in den Entwicklungsprozess zu integrieren.
Im Rahmen der verwendeten Implementierungstechnologie lassen sich, ba-
sierend auf den Meta-Modellen, grafische Editoren generieren, welche die
Eingabe der Testspezifikation auch manuell ermoglichen. Im Rahmen eines
Migrationsszenarios ist es in der Praxis damit denkbar, zunachst manuell
die Testfalle in das Testspezifikationsformat einzugeben, die Codegenera-
71
toren zu erarbeiten und zu verfeinern. Danach kann die automatisierte
Erstellung des TS-MM aus Testentwurfsmethoden eingefuhrt werden.
Es ist zu beachten, dass die Testspezifikations-Datenstruktur den Daten
nur eine formale Struktur gibt, sie definiert aber keine eindeutige Seman-
tik. So besteht die Gefahr, dass Anwender aus unterschiedlichen Bereichen
Inhalte unterschiedlich in diese Struktur einsortieren. Dieser Gefahr kann
durch die automatische Befullung des Formates durch werkzeuggestutzte
Testentwurfsmethoden und das Bereitstellen ausfuhrlicher Beispiele vorge-
beugt werden.
72
4. Leitanwendung
Die Integration der methodischen Testfallerstellung und der automatisier-
ten Testausfuhrung in den Entwicklungsprozess einer Kfz-Steuergerate-
Software ist eine vielschichtige Aufgabenstellung. Daher sollen die Grund-
konzepte zunachst an einer Leitanwendung entwickelt werden, welche im
Folgenden vorgestellt wird.
Im Kontext von Bild 2.15 liegt der Fokus zunachst auf dem Modultest.
Diesem Ansatz liegt das Motto der Konstruktionslehre”von innen nach
außen“ zugrunde.
Als Leitanwendung wird das Softwaremodul Druckregler aus der Steue-
rungssoftware eines Automatik-Getriebes ausgewahlt.
4.1. Physikalische Grundlagen
Die Schaltvorgange innerhalb eines automatischen Getriebes werden hy-
draulisch ausgelost. Die Steuerung dieser Vorgange erfolgt uber Regel- und
Schaltmagnetventile, welche das Bindeglied zwischen der physikalischen
Realisierung und der elektronischen Steuerung sind. Die Magnetventile sind
in dem in Bild 4.1 dargestellten hydraulischen Schaltgerat integriert. In
diesem Bild wird auch der vereinfachte hydraulische Schaltplan aufgezeigt.
Aus dem Schaltplan wird ersichtlich, dass mehrere Magnetventile innerhalb
des Systems zum Einsatz kommen. Der Haupt-Druckregler (HD), welcher
den Arbeitsdruck des Systems einregelt, ist der Olpumpe nachgeschaltet.
Da der an den anderen Ventilen anliegende Druck von diesem Arbeitsdruck
abhangt, kann im Gesamtsystem kein hoherer Druck als der Arbeitsdruck
herrschen.
Durch die Vorgabe eines Stroms an die Magnetventile ist es der Elektroni-
schen Getriebesteuerung (EGS) moglich, die Stellglieder des Systems mit
einem Druck zu beaufschlagen und somit die Gangwechsel des Getriebes zu
steuern. Da die innerhalb des Steuergerates implementierten Algorithmen
die Große Druck verwenden, wird innerhalb der Gesamtsoftware ein Modul
73
[ZF-Schulung: Grundlagen Automatikgetriebe]
Ölpumpe
25 bar
Schaltglieder
Regelmagnetventile
6 - 7 bar
Schaltmagnetventile
HD
Schaltmagnetventile
Bild 4.1.: Hydraulisches Schaltgerat und vereinfachter hydraulischerSchaltplan [7].
benotigt, welches diesen Druck in einen auszugebenden Strom umrechnet.
Dieses Modul ist Teil eines Regelkreises und wird im Folgenden Druckregler
bezeichnet.
Die Umrechnung wird durch eine Kennlinie implementiert, welche in Bild
4.2 dargestellt ist. Die Kennlinie wird nicht interpoliert. Sie wird durch
einen maximal und einen minimal moglichen Druck begrenzt, pmax respek-
tive pmin. Es wird kein kleinerer Strom als der applizierbare Ruhestrom
I0 ausgegeben. Beim Einschalten des Magnetventils muss ein applizierba-ZF FRIEDRICHSHAFEN Aktiengesellschaft Beschreibung: Zusatzbenennun
Funktionsspezifikation Druckregler
Nr.: DIN A4
Seite 6 von 13
D:\Projekte\3_Zusammenstellung einer Werkzeugkette\eb1\druckregler.doc
3.5 Druck in Strom umrechnen
Die Druck-Strom-Charakteristik liegt als Kennlinie mit sechs Punkten DR1_x.P_I vor. Die x-Achse ist dabei der Druck, die y-Achse ist der Strom. Im Regelbereich wird die Kennlinie interpoliert. Im ausgeschalteten Zustand wird der Strom I_null ausgegeben. Die Kennlinie wird nicht extrapoliert.
3.6 Status des Druckreglers Beim Aufruf der Methoden Einschalten(), DruckAusgeben() etc. wird der Status des Druckreglers zurückgegeben. Er gibt an, ob der Regler ein- oder ausgeschaltet ist und ob der Arbeitspunkt außerhalb des Regelbereichs liegt.
Wert Status Beschreibung 0 ausgeschaltet Druckregler ausgeschaltet, keine
Druckausgabe möglich! 1 regelt P_Min ≤ p_soll ≤ p_Max 2 regelt, Filter wirksam Druckfilterung verhindert p_Soll-
Umsetzung im Regelbetrieb 3 KL begrenzt oben P_soll > p_Max 4 KL begrenzt unten P_soll < p_Min 5 Begrenzt durch
Hauptdruck P_Max > p_soll > p_HD
6 Begrenzt durch max. zulässigen Druck
P_soll > p_max_zul
7 durchgesteuert Druckregler durchgesteuert P = p_HD + p_HD_Offset
8 Störung Stromreglerstörung/Fehler
p1 pMax
IMax
I1I0
I2
p2pMin
ZF FRIEDRICHSHAFEN Aktiengesellschaft Beschreibung: Zusatzbenennun
Funktionsspezifikation Druckregler
Nr.: DIN A4
Seite 7 von 13
D:\Projekte\3_Zusammenstellung einer Werkzeugkette\eb1\druckregler.doc
3.7 Einschalten Beim Einschalten wird ein applizierbarer Strompuls I_Einsprung für eine Zeit t_Einsprung ausgegeben, um den Druckregler sicher in die Regelstellung zu bewegen. t_Einsprung ist eine Kennlinie über T_Sumpf. Nach dem Strompuls wird der einzustellende Druck in einen Strom umgerechnet und dieser ausgegeben. Beim Einschalten wird der Status zurückgeliefert.
t
t
psoll
Isoll
DR_[x].t_Einsprung
DR_[x].I_Einsprung
3.8 Druck vorgeben Dem Druckregler werden zwei Drücke übergeben: p_Steuer_Soll, p_Regel_Soll. p_Steuer_Soll ist immer positiv, p_Regel_Soll kann auch negative Werte annehmen. Der tatsächliche Solldruck für den Druckregler wird durch Addition der beiden Drücke ermittelt: p_Soll = p_Steuer_Soll + p_Regel_Soll Eine Druckvorgabe ist nur möglich, wenn der Druckregler eingeschaltet und nicht durchgesteuert ist. Die Druckvorgabe wird nicht sofort in einen Strom umgesetzt, sondern nur zwischengespeichert. Die eigentliche Ausgabe erfolgt in der Run-Methode.
3.8.1 Garantierter Mindestdruck Ein Aufruf der Funktion MinDruckGarantieEin() schaltet den Druckregler auf Mindestdruck-Garantie. Unabhängig von der Druckvorgabe wird ein Mindestdruck vom Druckregler nicht unterschritten. Dieser Mindestdruck kann vorgegeben werden MinDruckGarantieEin(p_min_zul) oder es wirkt der applizierbare Mindestdruck DR_x.p_min_garantiert. Eingestellt wird das Maximum aus beiden Mindestdrücken Die Mindestdruck-Garantie kann nur aktiviert werden, wenn der Druckregler eingeschaltet und nicht durchgesteuert ist. Liegt der aktuelle Istdruck unter dem garantierten Mindestdruck, hebt der Druckregler den Istdruck beim Einschalten der Garantie auf Mindestdruck an. Die Mindestdruck-Garantie kann durch Aufruf der Funktion MinDruckGarantieAus() abgeschaltet werden.
Bild 4.2.: Druck-Strom-Kennlinie des Moduls Druckregler (DR).
74
rer Stromimpuls IEinsprung ausgegeben werden, um zu gewahrleisten, dass
das Ventil sich nicht verklemmt. Dieser Zusammenhang wird ebenfalls in
Bild 4.2 dargestellt. Die Zeitdauer tEinsprung, fur welche IEinsprung anliegt,
hangt von der Temperatur des Getriebeols im Olsumpf TSumpf ab und ist
wiederum durch eine Kennlinie beschrieben.
Durch eine ubergeordnete Regelung, wie sie in Bild 4.3 dargestellt ist, wird
der Solldruck pSoll berechnet.
pSoll = pSteuer Soll + pRegel Soll (4.1)
Der Solldruck wird in einen korrespondierenden Strom umgerechnet. Dabei
ist die Sollwertvorgabe immer positiv, pSteuer Soll ∈ R+. Fur die Ruckfuh-
rung des zu regelnden Wertes gilt: pRegel Soll ∈ R.
Regler StreckepSteuer_Soll
pRegel_Soll
pSoll
Bild 4.3.: Ubergeordnete Regelung, in welche das Softwaremodul eingebun-den ist.
Durch das Durchsteuern eines Ventils wird dieses hydraulisch geoffnet. Der
sich dabei einstellende Druck pIst hangt von dem Druck pmax und von dem
durch den Hauptdruckregler eingestellten Arbeitsdruck im Gesamtsystem
pHD ab. Damit berechnet sich der anliegende Druck zu:
pIst = min(pHD, pmax) (4.2)
Wenn das Softwaremodul in eine ubergeordnete Regelung eingebunden ist,
kann ein Gradientenfilter fur den ausgegebenen Strom aktiviert werden,
welches die Regelung komfortabler und numerisch stabiler macht.
Ferner bietet das Softwaremodul die Moglichkeit, einen Mindestdruck an
dem jeweiligen Ventil zu gewahrleisten. Durch den Mechanismus automati-
sches Deaktivieren kann die Steuerung die Bestromung des Ventils auf das
Minimum herunterfahren.
75
4.2. Software-Design und Implementierung
Aus den physikalischen Anforderungen wird das Design des Moduls abge-
leitet. Da die Magnetventile in dem hydraulischen Schaltgerat mehrfach
in ahnlicher Form vorkommen, bietet sich eine objektorientierte Imple-
mentierung der Software an, welche im Folgenden durch UML-Diagramme
erlautert wird.
4.2.1. Klassendiagramm
Die Klasse cDruckregler wird fur die mehrfach vorkommenden physikali-
schen Objekte jeweils neu instanziiert und bedatet. Die physikalische Ab-
hangigkeit aller Drucke in den Ventilen von dem eingeregelten Hauptdruck
wird im Design dadurch berucksichtigt, dass es eine Instanz fur den Haupt-
druckregler gibt, welche den Hauptdruck an alle ubrigen Instanzen bindend
vorgibt. Dieser Sachverhalt ist in dem Klassendiagramm des Softwaremo-
duls, welches in Bild 4.4 dargestellt ist, durch die Kompositionsbeziehung
HD realisiert. Die Abhangigkeit der Impulszeit tEinsprung von der Sumpf-
temperatur des Getriebes ist durch eine Referenz zu der Klasse cTempSen-
sor realisiert, die im Klassendiagramm nicht dargestellt ist. Der innerhalb
des Moduls berechnete Strom wird in einer Instanz der Klasse cOCG ab-
gelegt, welche die Implementierung des Stromreglers realisiert. Zu diesem
Zweck besteht zwischen den beiden Klassen wiederum eine Kompositions-
beziehung. Die Bedatung der unterschiedlichen Instanzen erfolgt uber ein
Datenfeld. Um dessen Parameter in unterschiedlichen Speicherbereichen
des in der EGS eingesetzten Mikrocontrollers ablegen zu konnen, imple-
mentiert die Klasse cDruckreglerDF die Zugriffsmethoden auf die Daten,
welche wiederum durch Referenzbeziehungen in unterschiedlichen Struk-
turen abgelegt sind. Diese Strukturen konnen gezielt auf Speicherbereiche
abgebildet werden. Die Klasse cDruckregler aggregiert die Zugriffsklasse
cDruckreglerDF.
76
Stromregler
cOCG
SetCurrent
GetCurrent
AcceptDiagnosis
Reset
Load
Flush
ComputeDAC
GetTrexDiagnosis
SetMode
SetDiagnosticCurrent
Enable
Disable
cOCG
SetCurrent
GetCurrent
AcceptDiagnosis
Reset
Load
Flush
ComputeDAC
GetTrexDiagnosis
SetMode
SetDiagnosticCurrent
Enable
Disable
sDF{Structure}
t_Einsprung
I_Einsprung
I_null
p_EW_DR_ina ...
Attribute1
cDruckreglerDF
p_I_KL (in Druck) : Strom
t_Einsprung () : Zeit
I_Einsprung () : Strom
I_null () : Strom
p_HD_Offset ()
SetzeVariante ()
pg_max_bei_Filt_aktiv ()
...
cDruckRegler
Init
Run
DruckVorgeben
HoleIstdruck
HoleIndexAIM
cDruckRegler
SteuerdruckVorgeben
RegeldruckVorgeben
Einschalten
Ausschalten
Durchsteuern
Regeln
MinDruckGarantieEin
MinDruckGarantieAus
MinDruckGarantieIstEin
MaxDruckVorgeben
SetzeVariante
Run_200ms
DruckBerechnen
DruckFilterungEin
DruckFilterungAus
sDF_EEP{Structure}
p_I_KL
cDruckReglerCalDF
I_Cal_Offset ()
sFixDF_EEP{Structure}
I_ANLE_A
I_ANLE_B
I_ANLE_D
I_ANLE_E
I_ANLE_F
I_ANLE_WK
1
1
ptr_DF
0..1
HD
1
1 Stromregler
11
Datenfeld
1
1
ptr_DF_EERAM
1
1 ptr_DF_EEROM
11
DF_RAM_EEP
1
1
«byName»
EeCalData
Bild 4.4.: Klassendiagramm des Softwaremoduls Druckregler.
77
4.2.2. Zustandsdiagramm
Das Verhalten der Klasse cDruckregler wird durch ein UML-
Zustandsdiagramm beschrieben, welches in Bild 4.5 dargestellt ist. Dieses
AUSGESCHALTET
Entry/Stromregler.SetCurrent(Datenfeld.I_null())...
EINGESCHALTET
DRUCK_REGELN
EINSPRUNG
Entry/Stromregler.SetCurrent(Datenfeld.I_Einsprung())
REGELND
Entry/ I_Soll = DruckInStromUmrechnen(p_Soll)
Stromregler.SetCurrent(I_Soll)
DruckVorgeben/
I_Soll = DruckInStromUmrechnen(p_Soll)
Stromregler.SetCurrent(I_Soll)
DURCHGESTEUERT
Entry/ p_Soll = HD.HoleIstdruck()+Datenfeld.p_HD_Offset()
I_Soll = DruckInStromUmrechnen(p_Soll)
Stromregler.SetCurrent(I_Soll) ...
DRUCK_ABSENKEN
Entry/ I_Soll = DruckInStromUmrechnen(p_Soll - Datenfeld.delta_p)
Stromregler.SetCurrent(I_Soll)
REGELN
Entry/ I_Soll = DruckInStromUmrechnen(p_max_zul)
Stromregler.SetCurrent(I_Soll)
DRUCK_BEGRENZEN
AUTODEAKTIVIEREN
AKTIV INAKTIV
MINDESTDRUCK_GARANTIEREN
GARANTIE_AUS
GARANTIE_EIN
DRUCK_REGELN
EINSPRUNG
Entry/Stromregler.SetCurrent(Datenfeld.I_Einsprung())
REGELND
Entry/ I_Soll = DruckInStromUmrechnen(p_Soll)
Stromregler.SetCurrent(I_Soll)
DruckVorgeben/
I_Soll = DruckInStromUmrechnen(p_Soll)
Stromregler.SetCurrent(I_Soll)
DURCHGESTEUERT
Entry/ p_Soll = HD.HoleIstdruck()+Datenfeld.p_HD_Offset()
I_Soll = DruckInStromUmrechnen(p_Soll)
Stromregler.SetCurrent(I_Soll) ...
DRUCK_ABSENKEN
Entry/ I_Soll = DruckInStromUmrechnen(p_Soll - Datenfeld.delta_p)
Stromregler.SetCurrent(I_Soll)
REGELN
Entry/ I_Soll = DruckInStromUmrechnen(p_max_zul)
Stromregler.SetCurrent(I_Soll)
DRUCK_BEGRENZEN
EINSPRUNG
Entry/Stromregler.SetCurrent(Datenfeld.I_Einsprung())
REGELND
Entry/ I_Soll = DruckInStromUmrechnen(p_Soll)
Stromregler.SetCurrent(I_Soll)
DruckVorgeben/
I_Soll = DruckInStromUmrechnen(p_Soll)
Stromregler.SetCurrent(I_Soll)
DURCHGESTEUERT
Entry/ p_Soll = HD.HoleIstdruck()+Datenfeld.p_HD_Offset()
I_Soll = DruckInStromUmrechnen(p_Soll)
Stromregler.SetCurrent(I_Soll) ...
DRUCK_ABSENKEN
Entry/ I_Soll = DruckInStromUmrechnen(p_Soll - Datenfeld.delta_p)
Stromregler.SetCurrent(I_Soll)
REGELN
Entry/ I_Soll = DruckInStromUmrechnen(p_max_zul)
Stromregler.SetCurrent(I_Soll)
DRUCK_BEGRENZEN
DRUCK_ABSENKEN
Entry/ I_Soll = DruckInStromUmrechnen(p_Soll - Datenfeld.delta_p)
Stromregler.SetCurrent(I_Soll)
REGELN
Entry/ I_Soll = DruckInStromUmrechnen(p_max_zul)
Stromregler.SetCurrent(I_Soll)
AUTODEAKTIVIEREN
AKTIV INAKTIVAKTIV INAKTIV
MINDESTDRUCK_GARANTIEREN
GARANTIE_AUS
GARANTIE_EIN
GARANTIE_AUS
GARANTIE_EIN
FEHLER
after( Datenfeld.t_Einsprung() )/
Durchs teuern/ R ege ln /
A ussc halten/
when( p_Soll <= Datenfeld.p_EW _DR_inaktiv() )/
/
E ins c halten/
when( p_Soll > Datenfeld.p_EW _DR_inaktiv() )/
when( HD.HoleIstdruck()
> p_max_zul )/
when( HD.HoleIstdruck()
+ Datenfeld.p_HD_Offset()
< p_max_zul )/after( Datenfeld.t_Absenken )/
R ege ln /
after( Datenfeld.t_inaktiv )/Ausschalten
S trom regler_Fehler/
S trom regler_Fehler/
Stromregler_OK/Stromregler.Reset
MinDruckGarantieE in/
MinDruckGarantieAus/
Superzustand
Orthogonaler Bereich
Orthogonaler Bereich
Orthogonaler Bereich
Superzustand
Bild 4.5.: Verhaltensbeschreibung des Softwaremoduls Druckregler durchein UML-Zustandsdiagramm.
weist die im Rahmen der UML moglichen Strukturierungselemente Hier-
archie und Parallelitat auf, um das Verhalten besser darstellen zu kon-
nen. Der Zustand Eingeschaltet ist ein Superzustand, welcher drei parallele
Regionen {DRUCK REGELN, AUTODEAKTIVIEREN und MINDEST-
DRUCK GARANTIEREN } enthalt. Damit wird ermoglicht, die Methoden
fur die Festlegung eines Mindestdrucks und die Steuerung der Funktiona-
litat automatisches Deaktivieren bereitzustellen, wahrend sich das System
in der Region DRUCK REGELN befindet.
78
Die Region DRUCK REGELN enthalt ferner den hierarchischen Superzu-
stand DRUCK BEGRENZEN, welcher die Teilfunktionalitat fur die Akti-
vierung des Gradientenfilters beinhaltet.
Das bereits aufgezeigte Design wird innerhalb des zugrundeliegenden Ent-
wicklungsprozesses manuell in die Implementierungssprache C++ ubertra-
gen.
4.3. Testausfuhrungsplattform
Fur den Test der Implementierung wird ein Unit-Test-Framework verwen-
det, welches sich an den Artikel [11] anlehnt. Der Aufbau ist in Bild 4.6 dar-
gestellt. Das Framework besteht aus den beiden Klassen cTest und cSuite.
Bild 4.6.: Aufbau des verwendeten Unit-Test-Frameworks.
Die Klasse cTest verwaltet die beiden Variablen n pass und n fail und stellt
die Methode do test zur Verfugung. Dieser Methode konnen boolesche Be-
dingungen ubergeben werden, welche nach einer erfolgreichen Ausfuhrung
die Variable n pass inkrementieren, andernfalls die Variable n fail.
Fur jede zu testende Klasse cSUTi wird eine Instanz der Klasse cTest an-
gelegt, welche die zu testende Klasse referenziert. Um einen Testschritt
innerhalb des Unit-Test-Frameworks bewerten zu konnen, muss dieser als
Assertion vom Typ bool formuliert werden. Diese Assertion wird der Me-
thode do test() ubergeben, welche die Klassenvariablen n pass und n fail
entsprechend inkrementiert.
79
Die Klasse cSuite ermoglicht es, die innerhalb eines Projektes entstande-
nen Instanzen der Klasse cTest gemeinsam auszufuhren, indem sie diese
referenziert.
4.4. Aufgaben fur die Testimplementierung
Der Entwickler muss fur die Testimplementierung die folgenden Aufgaben
abarbeiten.
1. Erstellen eines neuen C++ Projektes, welches die Implementierung
des SUT, der Klasse cDruckRegler, referenziert und das Unit-Test-
Framework implementiert.
2. Erstellen von Stubs, um die Schnittstellen des SUT so zu bedienen,
dass ein fur den Test lauffahiges Programm erstellbar ist.
3. Implementierung der Testinhalte in der Klasse cDruckReglerTest.
Die Arbeitspunkte 1. und 2. sind haufig so arbeitsintensiv, dass fur den
Arbeitspunkt 3., welcher fur die Aussagekraft des Tests am Wichtigsten
ist, am wenigsten Zeit bleibt.
An dieser Stelle soll das erarbeitete Testframework den Entwickler unter-
stutzen, sowohl die Infrastruktur fur den Test aufzubauen, als auch werk-
zeuggestutzte Methoden einzubringen.
80
5. Heuristik zur modellbasierten
Testsequenzgenerierung
Das folgende Kapitel widmet sich dem Aufgabenschwerpunkt, die black-
box Testentwurfsmethoden Zustandsbasierter Test und Aquivalenzklassen-
bildung/Grenzwertanalyse im Rahmen des in Kapitel 3 beschriebenen Test-
frameworks zur Anwendung zu bringen. Dazu wird eine Heuristik zur Test-
sequenzgenerierung erarbeitet, basierend auf Artefakten aus dem Entwick-
lungsprozess. Das Vorgehen wird anhand der Leitanwendung erklart, wel-
che in Kapitel 4 eingefuhrt worden ist.
Artefakte aus dem Entwicklungsprozess /
Testmodell
Testspezifikation.ecore
Ausführungsplattformen
Exchange.ecore
M2M
M2Text
Tes
tfra
mew
ork
Heuristik
M2M
M2M
(Abschnitt 5.2)
(Abschnitt 5.3)
Bild 5.1.: Integration der Heuristik zum Testentwurf in das Testframework.
Grundlage der Heuristik sind die Prinzipien des Zustandsbasierten Testens,
welche in Abschnitt 5.1 eingefuhrt werden. Die Heuristik soll im Rahmen
des Testframeworks generisch weiterverwendet werden konnen. Im Kon-
text der Leitanwendung bedarf es daher einer spezifischen Auspragung des
Exchange-Meta-Modells, um die gegebenen Artefakte aus dem Entwick-
lungsprozess fur die Heuristik aufzubereiten. Dieser Sachverhalt wird in
Abschnitt 5.2 erlautert. Die Heuristik selbst wird in Abschnitt 5.3 vorge-
stellt.
81
5.1. Prinzip der Testsequenzgenerierung aus
Zustandsmaschinen
Der folgende Abschnitt zeigt das allgemeine Prinzip der Testsequenzgene-
rierung aus Zustandsmaschinen auf, welches haufig auch unter dem Schlag-
wort modellbasiertes Testen [54] eingefuhrt wird. Die Vorgehensweise, aus
einer endlichen Zustandsmaschine der Form M = 〈S, T 〉 Testsequenzen
zu deren Verifikation zu generieren, ist in Bild 5.2 dargestellt. Durch die
ZFF TE-NL/FKFS 8 ©Z
F F
riedr
ichs
hafe
n A
G, 2
008
Strategien zur Testfallgenerierung aus UML-Zustandsautomaten
Testprinzip
Regler - System Under Test
Testimplementierung
Stimulation Prüfung
Strategie
Regler – Modell des SUT
Aus
Ein
Ausschalten/Einschalten/
Testsequenzen
Testschritt 1:System im erwarteten Ausgangszustand?
Testschritt 2:Stimulation einesÜbergangs. Testschritt 3:
System im erwartetenZielzustand?
Bild 5.2.: Prinzip der automatischen Testsequenzgenerierung.
Anwendung einer Generierungsstrategie, naher erlautert in Unterabschnitt
5.1.1, wird zunachst ein Ubergangsbaum abgeleitet. Die Pfade durch die-
sen Ubergangsbaum stellen den Testinhalt dar. Im Rahmen des Frame-
works wird dieser Testinhalt in eine Instanz des Testspezifikations-Meta-
Modells uberfuhrt, wodurch die plattformunabhangige Testspezifikation er-
stellt wird. Der eigentliche Test erfolgt nach folgendem Schema:
1. Prufen, ob sich das System in dem jeweiligen Ausgangszustand be-
findet und stimulieren der Verhaltensspezifikation des Zustandes.
2. Stimulieren der Verhaltensspezifikation der Transition, um diese zu
durchlaufen.
3. Prufen, ob das System den Zustandswechsel vollzogen hat und sti-
mulieren der Verhaltensspezifikation des Zielzustandes.
82
5.1.1. Generierungsstrategien
Das Ziel der in der Literatur definierten und beschriebenen Generierungs-
strategien ahnelt den in Unterabschnitt 2.6.3.1 beschriebenen Kontrollfluss-
kriterien. Es ist eine Testspezifikation zu berechnen, welche zu einer ent-
sprechenden Uberdeckung des SUT (M) fuhrt. Die gebrauchlichsten Stra-
tegien in Anlehnung an [16,20] sind:
Zustandsuberdeckung: Eine Testspezifikation, welche der Zustands-
uberdeckung genugt, erreicht jeden Zustand mindestens einmal.
Transitionsuberdeckung: Eine Testspezifikation, welche der Transiti-
onsuberdeckung genugt, stimuliert jede Transition mindestens ein-
mal.
N+ Strategie: Ausgehend von jedem Zustand werden alle Ubergangs-
Bedingungen aktiviert.
Pfaduberdeckung: Eine Testspezifikation, welche der Pfaduberdeckung
genugt, stimuliert alle moglichen Pfade durch die Zustandsmaschine.
Dies bringt den Vorteil, dass Zustande auf allen moglichen Pfaden
erreicht werden. Dadurch konnen Fehler aufgedeckt werden, welche
von der Art abhangen, wie der Zustand erreicht wurde.
5.1.2. Auffindbare Fehler
Im Rahmen der Implementierung zustandsbasierten Verhaltens konnen die
folgenden Fehler auftreten. Bezugnehmend auf die in Abschnitt 2.5 vorge-
stellten potenziellen Softwarefehler handelt es sich um Funktionale Fehler.
Falscher Ubergang: Die Implementierung durchlauft einen nicht aus der
Spezifikation stimulierten Ubergang.
Falsche Aktion: Die an einen Ubergang geknupfte Aktion ist fehlerhaft.
Nicht spezifizierter Ubergang: Bei dem Aufruf eines Events wird in
der Implementierung ein Ubergang stimuliert, welcher in dem Modell
nicht vorgesehen ist.
83
Nicht spezifizierter Zustand: Bei dem Aufruf eines Events wird in der
Implementierung ein Zustand erreicht, welcher in dem Modell nicht
vorgesehen ist.
5.1.3. Auswahl einer Strategie zur
Testsequenzgenerierung
Ziel der folgenden Betrachtungen ist es, zu entscheiden, welche Generie-
rungsstrategie eingesetzt werden soll. Dazu zeigt Tabelle 5.1 auf, welche
Strategie welche Fehler aufdecken kann [41]. Eine Testspezifikation, welche
der Zustandsuberdeckung genugt, vermag keinen der betrachteten Fehler-
typen zu finden. Dieses liegt darin begrundet, dass ein Zustand ggf. uber
mehr als eine Transition erreicht werden kann und so die Testspezifikation
nicht mit Sicherheit falsche Transitionen bzw. Aktionen aufdecken kann.
Eine Testsuite, welche der Transitionsuberdeckung genugt, vermag diese
Fehler aber aufzudecken.
Ein nicht spezifizierter Zustand bzw. Ubergang tritt auf, wenn das System
aus einem Zustand auf ein Ereignis reagieren muss, welches laut Spezifi-
kation nicht auftreten durfte. Solche nicht spezifizierten Ereignisse werden
durch eine Testspezifikation ausgelost, welche der N+ Strategie genugt.
Zustands-uberdeckung
Transitions-uberdeckung
N+
Falsche Transition Nein Ja Ja
Falsche Aktion Nein Ja Ja
Nicht spezifizierteTransition
Nein Nein Ja
Nicht spezifizierterZustand
Nein Nein Ja
Abschatzung derTestschrittanzahl
2 · n m · n m2 · n2
Tabelle 5.1.: Welche Strategie kann welche Fehler aufdecken?n Anzahl der Zustande, m Anzahl der Transitionen.
84
Wie aus der Tabelle 5.1 ersichtlich wird, steigt durch den Einsatz der N+
Strategie die Anzahl der generierten Testschritte (prufen, stimulieren, . . .)
gegenuber der Transitionsuberdeckungsstrategie an. Unter Berucksichti-
gung der Pramisse, die Testspezifikation so ubersichtlich wie moglich zu
gestalten, stellt sich die Frage, welchen Mehrwert der Einsatz der N+
Strategie bringen wurde. Die Antwort kann zwar nicht generisch, aber im
Kontext der Leitanwendung gegeben werden. Wie bereits erwahnt, liegt
der Quellcode der zu testenden Implementierung vor und eine werkzeugge-
stutzte Kontrollflussmessung wird auf diesem ausgefuhrt. Da ein im Test-
modell nicht spezifizierter Zustand in der Implementierung auch nicht sti-
muliert wird, entsteht in diesem Bereich eine mangelnde Uberdeckung. Eine
Testspezifikation, welche mit der Generierungsstrategie Transitionsuberde-
ckung erzeugt wurde, zeigt die mangelnde Code-Uberdeckung an der Stelle
des nicht spezifizierten Zustandes damit genauso auf. Ahnliches gilt fur
nicht spezifizierte Transitionen. Somit kann die Strategie Transitionsuber-
deckung fur die Leitanwendung eingesetzt werden, ohne die Vorteile der
N+ Strategie zu verlieren.
5.1.4. Umgang mit erweiterten endlichen
Zustandsmaschinen
Die beschriebenen Generierungsstrategien setzen eine endliche Zustands-
maschine voraus. Im Rahmen der vorliegenden Arbeit sollen jedoch
ebenfalls erweiterte endliche Zustandsmaschinen [31], wie sie in UML-
Werkzeugen umgesetzt sind, als Testmodell dienen. Erweiterte endliche Zu-
standsmaschinen fuhren im Wesentlichen die Konzepte der Hierarchie und
der Orthogonalitat von Zustanden ein. Um die gangigen Generierungsstra-
tegien dennoch anwenden zu konnen, werden in der Literatur [16, 17, 19]
verschiedene Ansatze vorgeschlagen, wie die erweiterte Zustandsmaschi-
ne in eine aquivalente, endliche Zustandsmaschine uberfuhrt werden kann.
History-Zustande, welche sich einen Zustand uber mehrere Ausfuhrungs-
schritte merken konnen, sollen im Rahmen der Arbeit ausgeschlossen wer-
den.
85
5.1.4.1. Auflosen von Hierarchie
Durch das Konzept der Hierarchie wird eine Strukturierungsmoglichkeit
eingefuhrt. Diese gestattet es dem Modellentwickler, eine Teilzustands-
maschine einer anderen unterzuordnen. Die Gruppierung zu einem hierar-
chischen Zustand hat dabei folgende Bedeutung:
• Alle in den hierarchischen Zustand fuhrenden Transitionen fuhren zu
dem untergeordneten Initialzustand. Wenn die Transition von dem
Initialzustand zu dem ersten Zustand innerhalb des hierarchisch un-
tergeordneten Zustands ohne Auswirkung auf das Systemverhalten
ist, kann die von außen eingehende Transition auch direkt mit dem
Folgezustand des Initialzustandes verbunden werden.
• Alle den hierarchischen Zustand verlassenden Transitionen haben ih-
ren Ursprung in jedem der untergeordneten Zustande, wie es Bild 5.3
darstellt.
Im Vorgriff auf die Ziele der Heuristik sei an dieser Stelle angemerkt, dass
im Kontext der Generierung von Testsequenzen das Auflosen der hierar-
chischen Strukturierung keinen großen Einfluss auf die resultierende Kom-
plexitat hat. Schwerwiegender ist, dass das eingefuhrte Strukturierungsele-
ment in den generierten Testsequenzen nicht mehr zur Verfugung steht.
DURCHGESTEUERT (2)
REGELND (3)
DRUCK_BEGRENZEN (4)
DRUCK_ABSENKEN (4.1)
REGELN (4.2)
(4.0)
DURCHGESTEUERT (2)
REGELND (3)
DRUCK_BEGRENZEN (4)
DRUCK_ABSENKEN (4.1)
REGELN (4.2)
i) vorher ii) nachher
(4.0)
Bild 5.3.: Interpretation eines hierarchischen Zustandes.
5.1.4.2. Auflosen von Orthogonalitat
Ein orthogonaler Zustand wird in der Literatur auch als”And-Zustand“
bzw. als nebenlaufiger Zustand bezeichnet. Durch das Konzept der Ortho-
gonalitat werden parallel ausfuhrbare Zustandsmaschinen beschrieben. In
Bild 5.4 wird dies anhand des Anwendungsbeispiels zweier unabhangig an-
steuerbarer Elektromotoren dargestellt. Diese sind so angeordnet, dass der
86
eine eine Bewegung nach rechts oder links und der andere eine Bewegung
nach oben oder unten verursacht. Im ersten Teil des Bildes ist die aqui-
valente Zustandsmaschine dargestellt, welche die kombinierten Zustande
beinhaltet. Im zweiten Teil ist das Verhalten mit Hilfe zweier orthogonaler
Zustandsmaschinen dargestellt. Die Darstellung macht deutlich, dass die
Moving
Up-Left
Moving
Up
Moving
Up-Right
Moving
Left
Moving
RightStopped
Moving
Down-Left
Moving
Down
Moving
Down-Right
a) Button1_P1 / E1_RotateCW()
b) Button1_P2 / E1_Stop()
c) Button1_P3 / E1_RotateAntiCW()
d) Button2_P1 / E2_RotateCW()
e) Button2_P2 / E2_Stop()
f) Button2_P3 / E2_RotateAntiCW()
a) b)
c)
d) e)
d)
e) f)
b)e)
e)
d)
a) b)
b) c) b)
f)
e)
e)
f)
a) b)
c)
Moving Up StoppedMoving
Down
Moving Left StoppedMoving
Right
a) b)
b) c)
d)
e)
e)
f)
a) Button1_P1 / E1_RotateCW()
b) Button1_P2 / E1_Stop()
c) Button1_P3 / E1_RotateAntiCW()
d) Button2_P1 / E2_RotateCW()
e) Button2_P2 / E2_Stop()
f) Button2_P3 / E2_RotateAntiCW()
Bild 5.4.: Orthogonalitat.
Erfassung des Verhaltens der beiden Motoren unter Zuhilfenahme der or-
thogonalen Darstellung einfacher ist, da die verknupfende Kombination der
beiden Bereiche implizit modelliert wird und nicht explizit erfasst werden
muss.
Die in der Literatur beschriebenen Ansatze [20] zur Ableitung einer aquiva-
lenten Zustandsmaschine aus orthogonalen Zustandsmaschinen gehen nach
dem folgenden Schema vor:
• Bilden der moglichen Zustands-Konfigurationen. Eine Konfiguration
ist eine Menge von Zustanden, welche die Zustande zusammenfasst,
die gleichzeitig aktiv sein konnen (Bsp. Rechts-Oben).
• Zusammenfassung der Konfigurations-Transitionen, welche sich
durch sequenzielle Verknupfung der Transitionen der Zustande aus
den jeweiligen Konfigurationen ergeben.
87
Dieses Vorgehen setzt voraus, dass die Verhaltensspezifikationen der Tran-
sitionen und Zustande der orthogonalen Zustandsmaschinen disjunkt sind.
Im konkreten Fall bedeutet dies: Wenn der Steuerbefehl fur den einen Elek-
tromotor auch eine Auswirkung auf den anderen Elektromotor hat, so kann
das Gesamtverhalten nicht mehr einfach dargestellt werden.
Fur die im Rahmen der Arbeit entwickelte Heuristik ergibt sich das Ziel,
die durch die Orthogonalitat eingefuhrte, kompakte Darstellung auch in
den generierten Testsequenzen beizubehalten.
5.2. Integration in das Framework
Im Rahmen der Arbeit wird eine neuartige Heuristik zur Testsequenzge-
nerierung entworfen, welche basierend auf erweiterten Zustandsmaschinen
eine Testspezifikation erstellt. Um die Heuristik generisch einsetzen zu kon-
nen, baut diese auf der in Unterabschnitt 5.2.1 beschriebenen allgemeinen
Schnittstelle auf.
Die Funktionsweise und die Konzepte werden anhand der in Kapitel 4 vor-
gestellten Leitanwendung entwickelt. In diesem Kontext wird zunachst auf
die verfugbaren Artefakte aus dem Entwicklungsprozess in Unterabschnitt
5.2.2 eingegangen. Darauf aufbauend wird eine konkrete Auspragung des
Exchange-Meta-Modells in Unterabschnitt 5.2.3 vorgestellt, welche die Ad-
aption der Heuristik fur die Leitanwendung ermoglicht. In Unterabschnitt
5.2.4 wird schließlich darauf eingegangen, wie die Instanziierung des Ex-
change-Meta-Modells erfolgt.
5.2.1. Allgemeine Schnittstelle der Heuristik
Die Heuristik soll die Konzepte des Zustandsbasierten Testens basierend
auf endlichen Zustandsmaschinen unterstutzen, sowie die Aquivalenzklas-
senbildung und Grenzwertanalyse. Vor diesem Hintergrund wird die allge-
meine Schnittstelle, welche im Folgenden auch als Testmodell bezeichnet
wird, durch das 5-Tupel aus Gleichung (5.1) definiert.
EM = 〈SM,S, T,R,W 〉 (5.1)
88
SM Das Element SM stellt das Wurzelelement der
Zustandsmaschine dar und speichert die Informa-
tion, welcher Zustand als Ausgangspunkt fur die
Testsequenzgenerierung gekennzeichnet ist.
S = {s1, s2, . . . , sn} Die Menge S reprasentiert die n Zustande s der
Maschine.
T = {t1, t2, . . . , tm} Die Menge T reprasentiert die m Transitionen t
der Maschine.
R = {r1, r2, . . . , rl} Die Menge R, bestehend aus l Regionen r, repra-
sentiert das Strukturierungselement fur hierarchi-
sche und orthogonale Bereiche, es kann wiederum
Zustande und Transitionen aggregieren.
W = {w1, w2, . . . , wk} Die Menge W entspricht den k Werte Bereich-
Elementen w. Diese reprasentieren die Aquiva-
lenzklassen und Grenzwerte der Attribute und
Parameter, die im Testmodell verwendet werden.
Diese Mengen stellen die fur die Beschreibung des Testmodells notwendigen
Modellelemente dar. Die Elemente Zustand s und Transition t beinhalten
zudem Untermengen, mit denen die Verhaltensspezifikation der Elemente
transportiert wird, dargestellt in Tabelle 5.3.
E
ET = {eT1 , eT2 , . . . eT�}ES = {eS1 , eS2 , . . . eS�}
E ist die Menge von Ereignissen e. Ereig-
nisse, welche eine Transition auslosen kon-
nen, werden eT bezeichnet. Ereignisse, wel-
che beim Betreten eines Zustandes ausgelost
werden, werden eS bezeichnet.
G
GT = {gT1 , gT2 , . . . gT�}GS = {gS1 , gS2 , . . . gS�}
G ist die Menge von Guard-Bedingungen g.
Guard-Bedingungen, welche zu einer Transi-
tion gehoren, werden gT bezeichnet. Die Zu-
gehorigkeit zu einem Zustand wird durch gS
gekennzeichnet.
89
A
AT = {aT1 , aT2 , . . . aT�}AS = {aS1 , aS2 , . . . aS�}
A ist die Menge von Aktionen a. AT kenn-
zeichnet den Bezug zu einer Transition, AS
den Bezug zu einem Zustand.
W : W S ⊆ W ∧W T ⊆ W
W T = {wS1 , w
T2 , . . . w
T�}
W S = {wT1 , w
S2 , . . . w
S�}
Den im Kontext der Mengen E, G und A ver-
wendeten Attributen und Parametern sind
durch die Menge W Aquivalenzklassen und
Grenzwerte zugewiesen. Die Menge W S be-
zieht sich dabei auf die Verhaltensspezifikati-
on der Zustande, die Menge W T auf die der
Transitionen.
VS = ES ×GS × AS ×W S VS ist die Menge der Verhaltensspezifikatio-
nen eines Zustandes. Beim Betreten des Zu-
standes kann ein Event (eSx) aufgerufen wer-
den, welches nach der Erfullung einer Guard-
Bedingung (gSx ) zu dem Aufruf einer Aktion
(aSx) fuhrt. Dies erfolgt gemaß der Syntax:
eSx [gSx ]/aSx . Den dabei verwendeten Attribu-
ten und Parametern sind durch die Menge
W S Aquivalenzklassen und Grenzwerte zu-
gewiesen.
VT = ET ×GT × AT ×W T VT ist die Menge der Verhaltensspezifikatio-
nen einer Transition. Durch den Aufruf eines
Events (eTx ) und die Erfullung einer Guard-
Bedingung (gTx ) wird die Transition von ei-
nem Zustand in den darauffolgenden Zustand
unter Aufruf der Aktion (aTx ) durchgefuhrt.
Dies erfolgt gemaß der Syntax: eTx [gTx ]/aTx .
Dabei sind die WerteBereich-Elemente in der
Menge W T zusammengefasst.
Tabelle 5.3.: Erlauterung der Verhaltensspezifikation.
Ferner ist im Kontext des Testmodells EM definiert, welche Relationen
zwischen den Mengen bestehen. Diese sind in Tabelle 5.4 zusammengefasst.
90
T ⊆ S × VT × S Eine Transition t ist eine Relation zwischen
Zustanden, wobei der Ubergang von einem
Ausgangs-Zustand (source) in einen Zielzustand
(target) gemaß einem Element der Verhaltensspe-
zifikation VT beschrieben wird.
R ⊆ T × S Eine Region r stellt uber die Aggregation von Ele-
menten t ∈ T und s ∈ S eine Relation zwischen
diesen dar. Durch die Regionen wird die Informa-
tion uber die Strukturierung des Modells in hier-
archische und orthogonale Bereiche transportiert.
S ⊆ S ×R Ein Zustand s kann uber die Aggregationsbezie-
hung zu einer Region r keine, eine oder mehrere
Regionen beinhalten.
Tabelle 5.4.: Relationen zwischen den Modellelementen.
Der Einfachheit halber soll es im Folgenden moglich sein, auf die Attri-
bute und Relationen der Modellelemente mit dem Punkt-Operator (.) zu-
greifen zu konnen. Bsp.: t1.source = {Name des Ausgangszustands der
Transition}. Ferner soll es moglich sein, die Attribute und Relationen ei-
nes Elements in runden Klammern anzugeben, um deren Zusammenhang
darstellen zu konnen. Transitionen werden durch den Index des Ausgangs-
und des Endzustandes indiziert.
Die Menge der Zustande S beinhaltet auch die Pseudozustande Start ( )-
und Endzustand ( ). Der Zugriff auf den Startzustand einer Region er-
folgt durch die Operation r.ss. Der Zugriff auf den Endzustand durch die
Operation r.se.
Mit dem Testmodell werden folgende Definitionen eingefuhrt:
Definition 5.1 (Region) Eine Region ri ∈ R beinhaltet Zustande und
Transitionen. Die Region r0 beinhaltet das gesamte Zustandsdiagramm.
Weitere Regionen kommen in Superzustanden oder orthogonalen Zustanden
vor.
91
Definition 5.2 (Einfacher Zustand) Ein einfacher Zustand beinhaltet
keine weiteren Regionen. Es gilt: card {s.R} = 0.
Definition 5.3 (Superzustand) Ein Superzustand ist ein Zustand, wel-
cher eine Hierarchieebene beinhaltet. Es gilt: card {s.R} = 1.
Definition 5.4 (Orthogonaler Zustand) Ein orthogonaler Zustand
beinhaltet parallele Hierarchieebenen. Es gilt: card {s.R} > 1.
5.2.2. Verfugbare Artefakte der Leitanwendung
Das zu testende Verhalten der Leitanwendung ist in Form eines Klassen-
diagramms mit einem zugeordneten Zustandsdiagramm in einem UML-
Werkzeug1 beschrieben. Da die Implementierung des Verhaltens im Rah-
men der Leitanwendung manuell erfolgt ist, ist es zulassig, diese Design-
Artefakte fur die Testgenerierung zu verwenden.
Um die Aquivalenzklassen- und Grenzwerte bereits im Design spezifizieren
zu konnen und die Generierung von Testsequenzen aus dem Zustandsdia-
gramm steuern zu konnen, wird ein UML-Profil definiert, welches in Tabelle
5.5 aufgelistet ist.
Stereotyp Tag-Definition Modell-Element-Zuweisung
«Value» Setter, Getter, Wertebereich Parameter, Attribut, Operation
«SMUT» - State
Tabelle 5.5.: UML-Profil zur Steuerung der Testsequenzerstellung.
Das Stereotyp «Value» ist den Modell-Elementen Parameter, Attribut und
Operation zugewiesen und dient dazu, den Definitionsbereich dieser Ele-
mente in Form von Aquivalenzklassen und Grenzwerten zu spezifizieren.
Dafur ist dessen Tagged-Value Wertebereich vorgesehen. Durch die Zuwei-
sung des Stereotyps an eine Operation wird deren Ruckgabewert klassifi-
ziert. Durch die Tagged-Values Setter 2 und Getter konnen die Methoden
1Artisan-Studio2In der objektorientierten Programmierung werden die Methoden zum Setzen und Lesen von Eigen-schaften einer Klasse haufig als Set- und Get-Methoden bezeichnet.
92
spezifiziert werden, welche fur den Zugriff auf den jeweiligen Parameter
oder das jeweilige Attribut vorgesehen sind.
Das Stereotyp State Machine Under Test («SMUT») kann innerhalb eines
Zustandsdiagramms einem Zustand (State) zugewiesen werden. Durch die
Platzierung dieses Stereotyps kann der Testingenieur definieren, welcher
Teil des Diagramms in die Testsequenzgenerierung mit einbezogen wird.
5.2.3. Konzeption des Exchange-Meta-Modells
Um das in dem machtigen UML-Meta-Modell beschriebe Klassen- und Zu-
standsdiagramm der Leitanwendung in das fur das Framework und die
Heuristik benotigte Testmodell EM zu uberfuhren, wird im Folgenden das
Bild 5.5.: Aufbau des Exchange-Meta-Modells.
93
Exchange-Meta-Modell fur diese Anwendung konzipiert. Sein Aufbau ist in
Bild 5.5 dargestellt.
Im Kontext des fur die Leitanwendung verwendeten UML-Werkzeuges ist
das Zustandsdiagramm einer Klasse zugeordnet. Dieser Zusammenhang
wird in dem Exchange-Meta-Modell durch die Aggregationsbeziehung der
Elemente Root, Package, Class zu StateMachineType abgebildet. Das At-
tribut SMUT des Elements StateMachineType ist dafur vorgesehen, den
im UML-Zustandsdiagramm mit dem Stereotyp «SMUT» gekennzeichne-
ten Zustand aufzunehmen.
Die Elemente StateType und PseudoState sollen die Zustande des UML-
Zustandsdiagramms aufnehmen, beide Elemente werden im Testmodell auf
die Menge S abgebildet. Desgleichen ist das Element TransitionType zur
Aufnahme der Transitionen T und das Element Region zur Aufnahme der
Regionen R konzipiert.
Im UML-Zustandsdiagramm werden die Verhaltensspezifikationen event,
guard und action fur Zustande und Transitionen spezifiziert. Sie bedienen
sich aus den der ubergeordneten Klasse zugeordneten Operationen und
Attributen bzw. aus den assoziierten Klassen. Dieser Zusammenhang ist
durch die Modellelemente Class, Operation und Attribute berucksichtigt.
Insbesondere ist vorgesehen, dass Attributen und Parametern von Opera-
tionen Aquivalenzklassen und Grenzwerte zugewiesen werden konnen. Die
Kennzeichnung der Aquivalenzklassen erfolgt im UML-Klassendiagramm
durch das Stereotyp «Value». In dem Exchange-Meta-Modell sind die Ele-
mente Attribute und Parameter definiert, um diese Information aufzuneh-
men.
Zu diesem Zweck aggregieren die Elemente Parameter und Attribute das
Element Value mit dem Attribut range zur Aufnahme der Wertebereiche.
5.2.4. Instanziierung der Leitanwendung
Im Kontext des Frameworks wird die Leitanwendung zunachst in eine In-
stanz des Exchange Meta-Modells uberfuhrt, welche wiederum in das der
Heuristik zugrundeliegende Testmodell EM uberfuhrt wird.
94
In Bild 5.6 wird dargestellt, wie das in Bild 4.5 eingefuhrte UML-
Zustandsdiagramm der Leitanwendung in eine Instanz des Exchange-Meta-
Modells uberfuhrt wird. Der mit dem Stereotyp «SMUT» gekennzeichnete
EINSPRUNG (1)
DURCHGESTEUERT (2)
REGELND (3)
DRUCK_REGELN EM1 Initial1 (0)
INAKTIV (7)AKTIV (6)
AUTODEAKTIVIEREN EM2
Initial2 (5) Final2 (8)
GARANTIE_EIN (11)GARANTIE_AUS (10)
MINDESTDRUCK_GARANTIEREN EM3
Initial3 (9)
EINGESCHALTET (0.3)
AUSGESCHALTET (0.1)
Initial (0.0)
FEHLER (0.2)
DRUCK_BEGRENZEN (4)
DRUCK_ABSENKEN (4.1)
REGELN (4.2)
(4.0)
cDruckRegler
«SMUT»
Bild 5.6.: Abbildung eines UML-Zustandsdiagramms in das Exchange-Meta-Modell.
Zustand wird innerhalb des Exchange-Meta-Modells als Attribut des Ele-
ments StateMachineType vermerkt. Innerhalb des Beispiels ist der Initial-
zustand der Region DRUCK REGELN markiert.
Die folgenden Ausfuhrungen stellen den Bezug zu dem Testmodell
EM = 〈SM,S, T,R,W 〉
her. Das in dem Diagramm beschriebene Verhalten ist der Klasse cDruck-
Regler zugeordnet, weshalb das gesamte Diagramm auf die Region
r0.name = cDruckRegler abgebildet wird.
Die Region r0 beinhaltet die Zustande:
S = {s0.name = Initial, s1.name = AUSGESCHALTET, s2.name = EIN-
GESCHALTET, s3.name = FEHLER}.
95
Ferner beinhaltet r0 die Transitionen:
T = {t0→1, t1→2, t2→1, t2→3, t3→1, t1→3}.
Der Zustand s2 beinhaltet parallele Regionen. Es gilt damit s2.R =
{r1.name = DRUCK REGELN, r2.name = AUTODEAKTIVIEREN,
r3.name = MINDESTDRUCK GARANTIEREN}.
Die verbleibenden Inhalte des UML-Zustandsdiagramms werden in analo-
ger Weise abgebildet.
5.3. Heuristik
Der vorliegende Abschnitt stellt die im Rahmen der Arbeit entwickelte
Heuristik zur Testsequenzgenerierung, basierend auf erweiterten endlichen
Zustandsmaschinen, vor. Die Heuristik berechnet eine Testspezifikation ge-
maß der Transitionsuberdeckungsstrategie. Das Neue an der Vorgehens-
weise ist, dass die Strukturierungselemente Hierarchie und Orthogonalitat
explizit erhalten bleiben. Diesem Vorgehen liegt die Annahme zugrunde,
dass die Entwicklungsingenieure mit dem Einsatz der Strukturierung ihren
Fokus auf spezifische Aufgabenaspekte der Implementierung legen. Wenn
diese Strukturierungselemente durch die Generierung der Testspezifikation
verloren gehen, kann nur mit großem Aufwand aufgezeigt werden, welchen
Bezug die Testfalle zu dem Testmodell haben. Der Erhalt der Struktur
gelingt, indem die Heuristik die Transitionsuberdeckungsstrategie separat
auf Superzustande und orthogonale Zustande anwendet. Das in Unterab-
schnitt 3.2.1 eingefuhrte Testspezifikations-Meta-Modell beinhaltet ahnli-
che Strukturierungselemente und vermag diese deshalb aufzunehmen.
Die Heuristik arbeitet nach dem im Folgenden beschriebenen Schema.
Bedatungsaspekt Die im Design zugewiesenen Aquivalenzklassen und
Grenzwerte, welche zunachst in dem Exchange-Meta-Modell erfasst wer-
den, werden durch die in Unterabschnitt 2.6.4.2 eingefuhrten Auswahlstra-
tegien aufbereitet. Die Beschreibung erfolgt im Unterabschnitt 5.3.1.
96
Struktureller Aspekt Durch strukturelle Umformung des Testmodells
wird eine Testspezifikation errechnet, um testen zu konnen, ob die Imple-
mentierung des SUT dem Design entspricht. Dazu werden folgende Schritte
durchlaufen:
1. Grundlage ist das Testmodell EM = 〈SM,S, T,R,W 〉.
2. Durch die Platzierung des Stereotyps «SMUT» wird festgelegt, von
welchem Zustand ausgehend Testfalle generiert werden. Die Heuristik
identifiziert zunachst, wo das Stereotyp platziert ist und berechnet
fur den Fall, dass es sich nicht um den Initialzustand des Testmodells
handelt, eine Initialisierungs-Testsequenz, welche das System in den
markierten Testausgangszustand versetzt.
3. Auf der relativ zu dem markierten Ausgangszustand obersten Hier-
archieebene wird eine Testspezifikation gemaß der Transitionsuber-
deckung errechnet.
4. Die generierte Menge von Transitionsfolgen wird derart erweitert,
dass alle Zustande auf weitere Regionen hin untersucht werden.
Die Beschreibung erfolgt in den Unterabschnitten 5.3.2 bis 5.3.5.
Synthese der Bedatungsaspekte und der strukturellen Aspekte
Die aus strukturellen Gesichtspunkten abgeleitete Testspezifikation wird
zusammen mit den aufbereiteten Bedatungskombinationen dem TS-MM
zugeordnet. Die Beschreibung erfolgt in Unterabschnitt 5.3.6.
5.3.1. Bedatung
Als Ausgangspunkt fur die Bestimmung der Test-Bedatung werden die
Transitionen der Zustandsmaschine herangezogen. Im Kontext des UML-
Designs und des Testmodells EM aggregiert das Element Transition T
sowohl seine eigene Verhaltensspezifikation VT als auch indirekt uber die
Referenz zu dem Start- und Zielzustand deren Verhaltensspezifikationen
VS. Um eine Testspezifikation ausfuhren zu konnen, mussen alle im Kon-
text der Verhaltensspezifikationen verwendeten Attribute und Parameter
mit einem Zahlenwert versehen werden. In Verbindung mit der Aquiva-
lenzklassenbildung und Grenzwertanalyse werden diesen Wertebereiche W
97
zugeordnet, vgl. Unterabschnitt 5.2.2. Unter Berucksichtigung der in Un-
terabschnitt 2.6.4.2 eingefuhrten Auswahlstrategien ergeben sich damit je
nach eingesetzter Strategie unterschiedliche Anzahlen von konkreten Be-
datungskombinationen.
Fur die Bestimmung der Auswahlmatrizen wird im Folgenden die minimale
Auswahlstrategie aus Gleichung (2.12) herangezogen, um die Auswahlma-
trix Omin zu bestimmen. Ferner wird die maximale Auswahlstrategie aus
Gleichung (2.13) zur Bestimmung der Matrix Omax herangezogen.
Die zur Initialisierung der Algorithmen notwendigen Mengen der Faktoren
F und Level L ergeben sich dabei wie folgt:
F: Die Menge der Faktoren F setzt sich aus der Summe der Para-
meter und Attribute zusammen, welche der Verhaltensspezifikation
VT einer Transition und der Verhaltensspezifikationen VS der zuge-
ordneten Start- und Zielzustande zugewiesen sind. Dabei ist jedem
Faktor F eine Menge von Wertebereichen W ′ zugeordnet, welche
als Level L bezeichnet werden: F ⊆ F×L, wobei gilt card(F) = k.
L: Die Menge L entspricht der Summe der den Faktoren zugeordneten
Level: Li = {li,1, . . . , li,ni} mit card(Li) = ni.
In Anlehnung an Tabelle 2.1 ergeben sich damit die beiden Matrizen
Omin(c = n = max(ni), k, n) und
Omax(c =∏k
i=1 ni, k, n)
mit c Zeilen, k Spalten fur jeweils n Level. Jede Zeile entspricht dabei einer
Bedatungskombination b. Fur die Menge der minimalen Bedatungskom-
binationen Bmin und der maximalen Bedatungskombinationen Bmax gilt:
Bmin ⊆ Bmax (5.2)
Die Differenz der beiden Mengen wird B∆ = Bmax \Bmin genannt.
Fur die Bedatung der Testspezifikation werden fur jedes Transitions-
Element ti→j ∈ T im Testmodell EM die Matrizen Omax und Omin be-
98
stimmt. Jeder Transition werden die Mengen Bmax, BminundB∆ zugeord-
net, wie es Gleichung (5.3) ausdruckt.
ti→j : {ti→j, {Bmax, Bmin, B∆}} = {ti→j,B} (5.3)
Der Zugriff auf die einzelnen Mengen soll im Folgenden uber den Punkt-
Operator in der Form ti→j.B� moglich sein. Das Vorgehen soll fur die Tran-
sition von dem Zustand Ausgeschaltet in den Zustand Eingeschaltet
aus Bild 5.6 veranschaulicht werden. Dem Start- und Endzustand sind kei-
ne Verhaltensspezifikationen zugewiesen. Der Transition ist die Operation
Einschalten(p Steuer Soll, p Regel Soll) mit ihren beiden Parametern als
Event zugewiesen.
Fur die Parameter sind jeweils drei Aquivalenzklassen definiert:
p Steuer Soll : [0, 5000], [5001, 10001], [10001, 15000] [mbar]
p Regel Soll : [0, 3000], [3001, 7001], [7001, 15000] [mbar]
Die Auswahlmatrix Omin wird damit fur zwei Faktoren mit jeweils drei
Leveln berechnet, ihre Auspragung ist in Bild 5.7 in Klassifikationsbaum-
darstellung visualisiert. Auf die Darstellung der korrespondierenden Matrix
Omax, welche fur die gegebene Konfiguration card(Bmax) = 3 ·3 Zeilen auf-
weist, wird verzichtet.
[0, 5000] [5001, 10001] [10001, 15000] [0, 3000] [3001, 7001] [7001, 15000]
p_Steuer_Soll p_Regel_Soll
1.
2.
3.
Bild 5.7.: Darstellung der Bedatunskombinationen Bmin.
Fur die Transition ergibt sich damit:
tEingeschaltet→Ausgeschaltet.Bmin = {b1, b2, b3} (5.4)
99
5.3.2. Berechnung der Initialisierungs-Testsequenz
Im Kontext der strukturellen Umformung des Testmodells dient die
Initialisierungs-Testsequenz dem Zweck, das System in den fur den Test
gewahlten Ausgangszustand zu versetzen. Sie steht damit nicht im Fokus
der Testspezifikation und kann so kurz wie moglich ausfallen. Um dies zu
erreichen, wird der Dijkstra-Algorithmus zur Berechnung des Initialisie-
rungspfades verwendet, welcher die wenigsten Faktoren enthalt. Als Kan-
tengewicht wird dazu die Anzahl der Faktoren ubergeben.
Da der Dijkstra-Algorithmus auf einfachen, gerichteten Graphen arbeitet,
ist es zunachst notwendig, das hierarchische Testmodell in einfache Teilgra-
phen aufzuteilen. Konkret bedeutet dies, dass wenn auf dem Weg von dem
Initialzustand des Testmodells zu dem Testausgangszustand («SMUT»)
Regionengrenzen uberschritten werden, die Regionen einzeln zu betrachten
sind. Die Aufteilung erfolgt durch die Funktion splitGraph(), welche im
Anhang A.1 beschrieben wird. Die Funktion gibt einen Vektor von Instan-
zen der Klasse subGraph zuruck. Das Objekt subGraph hat die Attribute
region, start und end. Das Attribut region beinhaltet dabei die jeweilige
Region. Die Attribute start und end beschreiben den Anfangs- und End-
zustand innerhalb der Region.
EINSPRUNG (1)
DURCHGESTEUERT (2)
REGELND (3)
DRUCK_BEGRENZEN (4)
DRUCK_REGELN EM1 Initial1 (0)
EINGESCHALTET (0.3)
AUSGESCHALTET (0.1)
Initial (0.0)
FEHLER (0.2)
«SMUT»
...
DRUCK_ABSENKEN (4.1)
REGELN (4.2)
(4.0)
Bild 5.8.: Visualisierung der Initialpfadsuche.
100
Die Funktionsweise wird an der in Bild 5.6 dargestellten Konfiguration der
Leitanwendung illustriert, in welcher der Initialzustand der ersten Region
des orthogonalen Zustandes s3.name = Eingeschaltet mit dem Stereo-
typ «SMUT» gekennzeichnet ist. Der Testausgangszustand (Initial1 ) liegt
in der Region DRUCK REGELN. Auf dem Weg von dem Initialzustand
des Testmodells (Initial) zu diesem Zustand wird damit eine Regionengren-
ze uberschritten. Um die Teilgraphen zu berechnen, wird der Funktion der
Initialzustand des Testmodells und der Testausgangszustand ubergeben,
der Aufruf lautet: splitGraph(start = Initial, end = Initial1).
ret =
region: cDruckRegler
start: Initial
end: EINGESCHALTET
;
region: DRUCK REGELN
start: Initial1
end: Initial1
(5.5)
Der Ruckgabewert der Funktion ist ein Vektor mit zwei subGraph-Objekten
(Gleichung (5.5)), deren Bedeutung in Bild 5.8 veranschaulicht wird. Das
erste subGraph-Objekt beschreibt innerhalb der Region cDruckRegler den
Startzustand Initial und den Endzustand Eingeschaltet, welcher die zu
testende Region enthalt. Das zweite subGraph-Objekt beinhaltet die Regi-
on DRUCK REGELN und als Start- und Endzustand den Initialzustand
Initial1, welcher gleichzeitig der Testausgangszustand ist.
Nun ist es die Aufgabe des Dijkstra-Algorithmus, welcher im Anhang A.1
beschrieben ist, innerhalb der Teilgraphen den Weg mit den wenigsten Fak-
toren zu finden. Der Algorithmus ist in der Funktion findLocalPath()
implementiert und wird auf jedes subGraph-Objekt angewendet. Die je-
weils zuruckgegebenen Transitionsfolgen werden zusammengefugt und der
Menge PInit hinzugefugt, welche zur Initialisierung der Testspezifikation
benotigt wird. Fur das erste subGraph-Objekt wird die Transitionsfolge
p0 = {tInitial→AUSGESCHALTET, tAUSGESCHALTET→EINGESCHALTET}
zuruckgegeben. Fur das zweite subGraph-Objekt wird eine leere Transiti-
onsfolge p1 = {∅} zuruckgegeben, da Start- und Endzustand ubereinstim-
men. Die Menge von Transitionsfolgen zur Initialisierung ergibt sich damit
zu:
PInit = {pInit = p0 ∪ p1}. (5.6)
101
5.3.3. Berechnung der Transitionsuberdeckung
Der nachste Schritt in der Heuristik ist die Berechnung von Pfaden durch
das Testmodell, welche alle Transitionen mindestens einmal durchlaufen,
siehe Unterabschnitt 5.1.1. Dazu wird der Algorithmus 5.1 verwendet. Neu
ist, dass die Transitionsuberdeckung zunachst nur in der Region berechnet
wird, welcher der Testausgangszustand angehort. Zustande, welche wei-
tere Regionen beinhalten, werden zuerst als einfache Zustande aufgefasst
und erst in einem zweiten Schritt weiter aufgelost. Der Algorithmus wird
anhand der bereits eingefuhrten Konfiguration der Leitanwendung vorge-
stellt.
Ausgehend von dem markierten Testausgangszustand Initial1 geht in die
Transitionsuberdeckungsberechnung der in Bild 5.9 dargestellte Teilgraph
EM1 des Testmodells EM ein.
REGELND
EINSPRUNG
DURCHGESTEUERT
REGELND DRUCK_BEGRENZEN
DURCHGESTEUERT REGELND
Initial1
DRUCK_REGELN
EINSPRUNG
Entry/Stromregler.SetCurrent(Datenfeld.I_Einsprung())
REGELND
Entry/ I_Soll = DruckInStromUmrechnen(p_Soll)Stromregler.SetCurrent(I_Soll)
DruckVorgeben/I_Soll = DruckInStromUmrechnen(p_Soll)Stromregler.SetCurrent(I_Soll)
DURCHGESTEUERT
Entry/ p_Soll = HD.HoleIstdruck()+Datenfeld.p_HD_Offset()I_Soll = DruckInStromUmrechnen(p_Soll)Stromregler.SetCurrent(I_Soll) ...
DRUCK_ABSENKEN
Entry/ I_Soll = DruckInStromUmrechnen(p_Soll - Datenfeld.delta_p)Stromregler.SetCurrent(I_Soll)
REGELN
Entry/ I_Soll = DruckInStromUmrechnen(p_max_zul)Stromregler.SetCurrent(I_Soll)
DRUCK_BEGRENZEN
DRUCK_REGELN
EINSPRUNG
Entry/Stromregler.SetCurrent(Datenfeld.I_Einsprung())
REGELND
Entry/ I_Soll = DruckInStromUmrechnen(p_Soll)Stromregler.SetCurrent(I_Soll)
DruckVorgeben/I_Soll = DruckInStromUmrechnen(p_Soll)Stromregler.SetCurrent(I_Soll)
DURCHGESTEUERT
Entry/ p_Soll = HD.HoleIstdruck()+Datenfeld.p_HD_Offset()I_Soll = DruckInStromUmrechnen(p_Soll)Stromregler.SetCurrent(I_Soll) ...
DRUCK_ABSENKEN
Entry/ I_Soll = DruckInStromUmrechnen(p_Soll - Datenfeld.delta_p)Stromregler.SetCurrent(I_Soll)
REGELN
Entry/ I_Soll = DruckInStromUmrechnen(p_max_zul)Stromregler.SetCurrent(I_Soll)
DRUCK_BEGRENZEN
EINSPRUNG
Entry/Stromregler.SetCurrent(Datenfeld.I_Einsprung())
REGELND
Entry/ I_Soll = DruckInStromUmrechnen(p_Soll)Stromregler.SetCurrent(I_Soll)
DruckVorgeben/I_Soll = DruckInStromUmrechnen(p_Soll)Stromregler.SetCurrent(I_Soll)
DURCHGESTEUERT
Entry/ p_Soll = HD.HoleIstdruck()+Datenfeld.p_HD_Offset()I_Soll = DruckInStromUmrechnen(p_Soll)Stromregler.SetCurrent(I_Soll) ...
DRUCK_ABSENKEN
Entry/ I_Soll = DruckInStromUmrechnen(p_Soll - Datenfeld.delta_p)Stromregler.SetCurrent(I_Soll)
REGELN
Entry/ I_Soll = DruckInStromUmrechnen(p_max_zul)Stromregler.SetCurrent(I_Soll)
DRUCK_BEGRENZEN
DRUCK_ABSENKEN
Entry/ I_Soll = DruckInStromUmrechnen(p_Soll - Datenfeld.delta_p)Stromregler.SetCurrent(I_Soll)
REGELN
Entry/ I_Soll = DruckInStromUmrechnen(p_max_zul)Stromregler.SetCurrent(I_Soll)
after( Datenfeld.t_Einsprung() )/
Durchsteuern/ Regeln/
when( HD.HoleIstdruck() > p_max_zul )/
when( HD.HoleIstdruck() + Datenfeld.p_HD_Offset() < p_max_zul )/
after( Datenfeld.t_Absenken )/
Regeln/
«SMUT»
EINSPRUNG
REGELND
DURCHGESTEUERT
DRUCK_BEGRENZEN
DRUCK_ABSENKEN
REGELN
Initial1DRUCK_REGELN
EINSPRUNG (1)
DURCHGESTEUERT (2)
REGELND (3)
DRUCK_BEGRENZEN
DRUCK_REGELN Initial1 (0)«SMUT»
REGELND
EINSPRUNG
DURCHGESTEUERT
REGELND
Initial1
DRUCK_BEGRENZEN
REGELND
EINSPRUNG
DURCHGESTEUERT
Initial1
DURCHGESTEUERT
DRUCK_BEGRENZEN
REGELND
EINSPRUNG
DURCHGESTEUERT
Initial1
REGELND
Übergangsbaum Pfad1Pfad2
Pfad3
(4)
Bild 5.9.: Ausgangspunkt fur die Transitionsuberdeckung.
Die Elemente des Teilgraphen lauten:
SM1 = {Initial1}S1 = {Initial1 (0), EINSPRUNG (1), DURCHGESTEUERT (2),
REGELND (3), DRUCK BEGRENZEN (4)}T1 = {t0→1, t1→2, t2→3, t3→2, t3→4, t4→3, t4→2}R1 = {r1 = DRUCK REGELN }W1 ⊆ W
Der Algorithmus gibt einen Ubergangsbaum B = {ki} aus, welcher eine
Instanz des in Bild 5.10 dargestellten Meta-Modells ist.
102
Bild 5.10.: Meta-Modell des Ubergangsbaumes.
Durch die Struktur des Testmodells3 ist a-priori nicht zu unterscheiden,
ob der Zustand Druck Begrenzen (4) ein einfacher Zustand oder ein
Superzustand ist. Dadurch ist es moglich, die Transitionsfolgen stufenweise,
unabhangig von den weiteren hierarchischen Strukturen des Testmodells zu
generieren.
Algorithmus 5.1: Algorithmus zur Berechnung der Transitionsuber-deckung.
Eingabe : EM1 = 〈SM1, S1, T1, R1,W1〉Ausgabe : B = {ki}
1 Initialisierung:
2 k0 = s0 // s0 = Initial13 visited: {∅} // Leerer Vektor4 queue ⊆ S ×B = {(s0, k0)} // Vektor mit Paaren5 solange queue 6= ∅ tue6 pair ← Element aus der queue nehmen (s�, k�)7 Zustand s ← pair.first // Zu Beginn: (s0)8 Knoten k ← pair.second // Zu Beginn: (k0)9 wenn Zustand /∈ visited dann
10 visited = visited ∪ Zustand// T1 = r1.T : Alle Transitionen, welche zu der Region
Druck Regeln gehoren und damit auf der gleichenHierarchieebene stehen, wie der Testausgangszustand.
11 fur ti ∈ T1[ti.source == Zustand] tue12 Knoten.child = ti.target13 ki = Knoten.child14 ni = (ti.target, ki) // Ein neues queue-Element anlegen15 queue = queue ∪ ni // Das Element der queue hinzufugen16 Ende fur17 Ende wenn18 Ende solange
3Instanz des Exchange-Meta-Modells
103
Nach der Initialisierung des Algorithmus und der Uberprufung, ob ein Zu-
stand bereits in den Ubergangsbaum aufgenommen wurde (Zeile 9), wird
die Schleife in Zeile 11 betreten. Es wird nach allen Trasitionen gesucht,
welche den gerade zu untersuchenden Zustand (ti.source == Zustand) ver-
lassen und welche Teil der aktiven Region (im Beispiel DRUCK REGELN)
sind. Die Entwicklung des Algorithmus ist im Anhang B fur eine alternative
Konfiguration des Testmodells dargestellt.
Der ausgegebene Ubergangsbaum hat die in Bild 5.11 dargestellte Form.
Er beschreibt durch einen gerichteten Graphen Wege durch den zugrunde
liegenden Teilgraphen EM1, welche alle Transitionen mindestens einmal
durchlaufen. Aus dem Ubergangsbaum werden die einzelnen Transitionsfol-
DURCHGESTEUERT
REGELND
DURCHGESTEUERT
EINSPRUNG
DURCHGESTEUERT
EINSPRUNG
REGELND
DURCHGESTEUERT DRUCK_BEGRENZEN
DURCHGESTEUERT REGELND
DRUCK_BEGRENZEN
DURCHGESTEUERT
EINSPRUNG
REGELND
DURCHGESTEUERT
DRUCK_BEGRENZEN
DURCHGESTEUERT
EINSPRUNG
REGELND
REGELND
Übergangsbaum Pfad1
Pfad2Pfad3
(0)
(1)
(2)
(3)
(2)(4)
(3)(2)
Initial1
Bild 5.11.: Fur den Teilgraphen EM1 berechneter Ubergangsbaum.
gen abgeleitet, indem der Weg von den Blattzustanden4 zu dem Wurzelzu-
stand beschritten wird. Daraus resultiert der Vektor von Transitionsfolgen
in Gleichung (5.7), welche den abstrakten Testinhalt beschreiben.
P ′EM1=
p1,0 = {t0→1, t1→2, t2→3, t3→2}p1,1 = {t0→1, t1→2, t2→3, t3→4, t4→2}p1,2 = {t0→1, t1→2, t2→3, t3→4, t4→3}
(5.7)
Definition der Nomenklatur Der Index EM1 der Menge von Transi-
tionsfolgen PEM1stellt den Bezug zu der Region des Testmodells her. Die
4Zustande innerhalb des Ubergangsbaums, welche auf keine nachfolgenden Zustande mehr verweisen.
104
Indizes der Transitionsfolgen px,y beziehen sich mit dem ersten Index x auf
die Region des Testmodells. Der zweite Index y ist eine Laufvariable.
5.3.4. Vervollstandigung der Transitionsfolgen
Die Transitionsfolgen in Gleichung (5.7) bedingen fur die daraus abgeleite-
ten Testsequenzen das Aktivieren der Zustande in den Reihenfolgen, wie sie
in den Pfaden in Bild 5.11 visualisiert sind. Dabei ist noch keine Unterschei-
dung getroffen worden, ob es sich um einfache Zustande (Definition 5.2),
Superzustande (Definition 5.3) oder orthogonale Zustande (Definition 5.4)
handelt. Die beiden zuletzt genannten Zustandsklassen beinhalten weitere
Regionen und mussen fur die Generierung eines vollstandig ausfuhrbaren
Tests weiter aufgelost werden.
Zu diesem Zweck werden die einzelnen Transitionsfolgen p1,i ∈ PEM1in
dem Algorithmus 5.2 elementweise darauf hin untersucht, ob sie weitere
Regionen beinhalten (card(tj.target.R 6= 0)5).
Algorithmus 5.2: Vervollstandigung der Transitionsfolgen.
Eingabe : P ′EM1
Ausgabe : PEM1
1 fur jedes p1,i ∈ P ′EM1tue
2 fur jedes tj ∈ p1,i tue
3 Fall card(tj.target.R) = 0
// Einfacher Zustand - Es ist nichts weiter zu tun.
4 Fall card(tj.target.R) = 1
5 Umgang mit Superzustanden (Unterabschnitt
5.3.4.1)
6 Fall card(tj.target.R) > 1
7 Umgang mit orthogonalen Zustanden
(Unterabschnitt 5.3.4.2)
8
9 Ende fur
10 Ende fur
5Anzahl der Regionen, welche der Zielzustand einer Transition aus der Transitionsfolge enthalt.
105
5.3.4.1. Umgang mit Superzustanden
Wenn die Bedingung in Zeile 4 des Algorithmus 5.2 erfullt ist, beinhal-
tet die Transitionsfolge an der entsprechenden Stelle einen Superzustand
(Bsp. Druck Begrenzen in Bild 5.11). Die Auflosung erfolgt nach dem
folgenden Schema:
1. Anwendung des Algorithmus 5.1 auf die zuruckgegebene Region
r(4,1)6. Dabei werden die Elemente der Region folgendermaßen auf
das von dem Algorithmus erwartete Testmodell EM2 abgebildet:
SM2 = {r(4,1).ss}S2 = {r(4,1).ss (4,0), Druck Absenken (4,1), Regeln (4,2)}T2 = {t4,0→4,1, t4,1→4,2}R2 = ∅W2 ⊆ W
Das Ergebnis der Berechnung ist die Transitionsfolgenmenge7:
PEM2={
p2,0 = {t(4,0)→(4,1), t(4,1)→(4,2)}}
(5.8)
2. Aus der Semantik eines Superzustandes folgt, dass jede den Super-
zustand verlassende Transition ihren Ursprung in einem Subzustand
hat (Unterabschnitt 5.1.4.1). Um diesem Umstand Rechnung zu tra-
gen, werden folgende Unterschritte benotigt:
a) Die Menge der Subzustande innerhalb eines Superzustandes,
ausschließlich der Pseudozustande ss und se, wird identifiziert:
r(4,1).S = {DRUCK ABSENKEN (4,1), REGELN (4,2) }
b) Aus der ubergeordneten Transitionsfolge, siehe Zeile 2 des Algo-
rithmus 5.2, folgt ein Zielzustand des Superzustandes. Es mus-
sen nun alle Transitionsfolgen gebildet werden, welche ihren Ur-
sprung in der Subzustandsmenge haben und in dem Zielzustand
enden. Der erste Zielzustand Durchgesteuert (2) ergibt sich
aus der Transition t4→2 in der Transitionsfolge p1,1 der Gleichung
6Nomenklatur: (Index des Vaterzustandes, Index der Region): Erste Region des ZustandesDruck Begrenzen (4).
7Welche in dem betrachteten Fall nur ein Element beinhaltet.
106
5.7. Daraus resultiert die zu integrierende Transitionsmenge:
TEM4= {t(4,1)→2, t(4,2)→2}. (5.9)
Algorithmus 5.3: Superzustand: Hinzufugen von Transitionen.Eingabe : PEM2
Ausgabe : P ′EM2
// i: Prufen, ob es moglich ist, die Transitionen den Blattzustandenhinzuzufugen.
1 fur jedes p2,i ∈ PEM2tue
2 t = p2,i.get(LetztesElement) // Die letzte Transition in p2,i
ermitteln.3 fur jedes tj ∈ TEM4
tue4 wenn t.target == tj.source dann5 TEM4
.remove(tj)6 p2,i.add(tj)7 Ende wenn
// Wenn TEM4== ∅, Algorithmus beenden
8 Ende fur9 Ende fur
// ii: Hinzufugen neuer Transitionsfolgen minimaler Lange.10 fur jedes p2,i ∈ PEM2
tue11 fur jedes tj ∈ TEM4
tue12 fur jedes tk ∈ p2,i tue13 wenn tk.target == tj.source dann14 p = p2,i.get(0 : k) // Kopieren der
Teiltransitionsmenge p2,i.get(0 : k)15 TEM4
.remove(tj)16 p.add(tj)17 P ′EM2
= PEM2.add(p)
18 Ende wenn19 Ende fur
// Wenn TEM4== ∅, Algorithmus beenden
20 Ende fur21 Ende fur
c) Die Transitionsfolge PEM2muss um die berechneten Transitio-
nen TEM4erweitert werden. Dazu wird der Algorithmus 5.3 ein-
gesetzt, welcher aus zwei Teilen besteht:
107
i. Prufen, ob die in TEM4enthaltenen Transitionen einem
Blattzustand der Transitionsfolge PEM2hinzugefugt werden
konnen; falls moglich, diese hinzufugen.
ii. Wenn Transitionen der Menge TEM4nicht auf diese Weise
eingefugt werden konnen, mussen sie den bestehenden Tran-
sitionsfolgen p2,i ∈ PEM2hinzugefugt werden. Dazu wird
das erste Auftreten einer Transition gesucht, welches die
Bedingung erfullt, dass der Zielzustand der Transition der
Transitionsfolge dem Ausgangszustand der Transition der
Menge TEM4entspricht (Zeile 13 in Algorithmus 5.3). An
dieser Stelle wird der zugrunde liegende Ubergangsbaum
verzweigt und der Menge PEM2die entsprechende Transiti-
onsfolge hinzugefugt.
Der Algorithmus 5.3 gibt fur den vorliegenden Fall die Teiltran-
sitionsfolgenmenge P ′EM2zuruck.
P ′EM2=
{p2,0 = {t(4,0)→(4,1), t(4,1)→(4,2), t(4,2)→2}p2,1 = {t(4,0)→(4,1), t(4,1)→2}
}(5.10)
Die errechnete Teiltransitionsfolgenmenge wird in die ubergeordne-
te Transitionsfolge an der Stelle eingefugt, an der der Ubergang von
einem Zustand in einen Superzustand stattfindet, welcher innerhalb
des Algorithmus 5.2 identifiziert wird. In der Transitionsfolge p1,1
werden die abstrakten Transitionen t3→4 und t4→2 durch die Transi-
tion t3→P ′EM2
ersetzt. Der Index von P ′EM2verweist darauf, dass die
beinhalteten Transitionsfolgen in dem Zustand (2) enden.
3. Die Teile 2b) und 2c) (Seite 106) werden fur die weiteren Transitions-
folgen der Menge PEM1aus Gleichung 5.7 wiederholt. Im vorliegenden
Fall ist nur noch die Transitionsfolge p1,2 zu untersuchen, welche er-
neut den Superzustand DRUCK BEGRENZEN (4) beinhaltet, dies-
mal mit Zielzustand (3). Die Anwendung der Teile 2b) und 2c) ergibt
dann die Teiltransitionsfolgenmenge P ′EM3.
P ′EM3=
{p3,0 = {t(4,0)→(4,1), t(4,1)→(4,2), t(4,2)→3}p3,1 = {t(4,0)→(4,1), t(4,1)→3}
}(5.11)
108
Das Ergebnis der Auflosung von Superzustanden in der Menge von Tran-
sitionsfolgen PEM1ist durch Gleichung (5.12) gegeben.
PEM1=
p1,0 = {t0→1, t1→2, t2→3, t3→2}p1,1 = {t0→1, t1→2, t2→3, t3→P ′
EM2}
p1,2 = {t0→1, t1→2, t2→3, t3→P ′EM3}
(5.12)
5.3.4.2. Umgang mit orthogonalen Zustanden
Wenn die Bedingung in Zeile 6 des Algorithmus 5.2 erfullt ist, enthalt der
entsprechende Zustand orthogonale Bereiche, wie es Bild 5.12 darstellt. Die
bereits errechnete Menge von Transitionsfolgen PEM1aus Gleichung (5.12)
ist aus dem Bereich Druck Regeln des orthogonalen Zustandes Ein-
geschaltet bestimmt worden. Wie im Unterabschnitt 5.1.4.2 aufgezeigt,
EINSPRUNG (1)
DURCHGESTEUERT (2)
REGELND (3)
DRUCK_BEGRENZEN
DRUCK_REGELN EM1 Initial1 (0)
(4)
INAKTIV (7)AKTIV (6)
AUTODEAKTIVIEREN EM2
Initial2 (5) Final2 (8)
GARANTIE_EIN (11)GARANTIE_AUS (10)
MINDESTDRUCK_GARANTIEREN EM3
Initial3 (9)
EINGESCHALTET (0.3)
Bild 5.12.: Orthogonale Bereiche des Zustandes Eingeschaltet.
wird durch orthogonale Bereiche parallel ausfuhrbare Funktionalitat be-
schrieben. In dem vorliegenden Beispiel kann somit folgende Konfiguration
gelten: Wahrend die Region Druck Regeln im Zustand Einsprung ist,
ist die Region Autodeaktivieren im Zustand Aktiv und die Region
Mindestdruck Garantieren im Zustand Garantie Aus.
109
Da die Algorithmen zur Testsequenzgenerierung eine einfache Zustands-
maschine voraussetzen, formen bekannte Ansatze [17,19] die orthogonalen
Zustande in den zugrundeliegenden Produktautomaten um und berechnen
die Testspezifikation basierend auf diesem. Der Vorteil dieser Vorgehens-
weise liegt darin, dass durch die Umformung alle moglichen Zustandskonfi-
gurationen bestimmt werden, die durch die Semantik verborgen sind. Der
Nachteil liegt im Verlust dieser hoheren Abstraktion.
Um dem Ziel der vorliegenden Heuristik gerecht zu werden und die durch
die Orthogonalitat eingefuhrte Semantik bei der Testsequenzgenerierung
beizubehalten, werden zunachst die Folgen der Umformung orthogonaler
Bereiche in einen Produktautomaten betrachtet.
DRUCK_REGELN EM1
(7)(6)
AUTODEAKTIVIEREN EM2
(11)(10)
MINDESTDRUCK_GARANTIEREN EM3
EINGESCHALTET
(6) (10) (6) (11)
(7) (10) (7) (11)
s(6)
t6→7
s(7)
s(10)
t10→11
s(11)
a
bc
a b c
... ...
...
i) ii) iii)
... ...
Bild 5.13.: Bedeutung orthogonaler Zustande fur den Test.
Dazu zeigt Bild 5.13 i) einen reduzierten Ausschnitt des Zustandes Ein-
geschaltet aus Bild 5.12. Die moglichen Zustandskonfigurationen und
deren Transitionsbeziehungen der reduzierten letzten beiden Regionen sind
in Bild 5.13 ii) dargestellt. Die Zustandsnamen werden durch die Nummern
in runden Klammern abgekurzt. Die Darstellung zeigt fur die Konfigurati-
onstransition b: Wahrend sich die Zustandsmaschine in der Konfiguration
{(6) (10)} befindet, fuhrt die Stimulation der Verhaltensspezifikationen
der Transitionen t6→7 und t10→11 zum Ubergang in die Konfiguration {(10)
(11)}. Entscheidend fur den Ubergang von einer Konfiguration in die an-
dere sind die Transitionen der einzelnen Regionen. Gemaß der Definition
des Testmodells EM in Unterabschnitt 5.2.1 sind aus den Transitionen
fur den Test einzelne Testschritte nach folgendem Schema ableitbar: Pru-
fen der Verhaltensspezifikation des Startzustandes; Stimulieren der Ver-
110
haltensspezifikation der Transition; Prufen der Verhaltensspezifikation des
Zielzustandes.
Dieser Zusammenhang ist in Bild 5.13 iii) ersichtlich. Dabei sind die gemaß
der beiden Transitionen t6→7 und t10→11 in der Zustandsmaschine vorgege-
benen Testschritte in einer Tabelle dargestellt. Die Testspezifikation eines
Konfigurationsubergangs wird als Punkt-Markierung ( ) symbolisiert. Die
Tabelle stellt die drei Konfigurationstransitionen a, b und c dar.
Basierend auf dieser Betrachtung wird folgendes neues Vorgehen gewahlt.
Die Heuristik erachtet die orthogonalen Regionen als separate Zustands-
maschinen. Auf jede Region wird der Algorithmus 5.1 angewendet. Daraus
resultieren fur den betrachteten Zustand Eingeschaltet die Mengen von
Transitionsfolgen in den Gleichungen (5.12), (5.13) und (5.14).
PEM2=
{p2,0 = {t5→6, t6→7, t7→8}p2,1 = {t5→6, t6→7, t7→6}
}(5.13)
PEM3={
p3,0 = {t9→10, t10→11, t11→10}}
(5.14)
Die Testspezifikation des Zusammenspiels der Regionen ergibt sich aus der
Kombination der einzelnen Transitionen, wie es die Tabelle in Bild 5.13 iii)
darstellt. Um eine gultige Testspezifikation zu erhalten, ist die Reihenfolge
der Transitionen einzuhalten, wie sie in den Mengen P abgebildet sind.
Daraus resultieren fur die Kombination die Regeln:
• Aus jeder orthogonalen Menge von Transitionsfolgen P darf nur eine
Transitionsfolge p ausgewahlt werden, die Reihenfolge der Transiti-
onsfolgen innerhalb der Menge P spielt dabei keine Rolle.
• Die Transitionen t ∈ p mussen in der durch Algorithmus 5.1 be-
rechneten Reihenfolge ausgefuhrt werden, da sonst Ubergange gefor-
dert werden, welche die zugrundeliegende erweiterte Zustandsmaschi-
ne gar nicht ausfuhren kann.
• Die Testschritte, welche den gewahlten Transitionen entsprechen,
werden entweder sequenziell aneinandergereiht:
1. Ausfuhren der Testschritte der ersten Transition.
111
2. Ausfuhren der Testschritte der folgenden Transition.
Dieses Vorgehen entspricht der neuen Sequenzierung der bestehen-
den Transitionsfolgen. Alternativ erfolgt die Anordnung nach dem
Schema:
1. Stimulieren und Prufen der Verhaltensspezifikationen der Aus-
gangszustande.
2. Stimulieren und Prufen aller Verhaltensspezifikationen der Tran-
sitionen.
3. Stimulieren und Prufen der Verhaltensspezifikationen der Ziel-
zustande.
Die Testspezifikation orthogonaler Regionen kann damit aus der Menge der
Transitionsfolgen der separaten Regionen aufgebaut werden. Im Kontext
der Heuristik wird fur die Kombination der Transitionsfolgen der orthogo-
nalen Bereiche die minimale Auswahlstrategie angewendet.
Im ersten Schritt wird dabei die Menge der orthogonal auszufuhren-
den Transitionsfolgen KEM0.3mit Gleichung (2.12) bestimmt. In diesem
Kontext stellen die orthogonalen Regionen des Zustandes Eingeschal-
tet die Faktoren dar. Aus der Beziehung PEingeschaltet = PEM0.3=
{PEM1, PEM2
, PEM3} ergibt sich die Große k = card(PEM0.3
) = 3. Die Level
entsprechen den Transitionsfolgen p ∈ Pi. Die Große n = max(ni) hat da-
mit ebenfalls den Wert 3, da die Menge PEM1drei Transitionsfolgen hat.
Es ergibt sich:
KEM0.3=
k0.3,0 = {{p1,0}, {p2,0}, {p3,0}}k0.3,1 = {{p1,1}, {p2,1}, {p3,0}}k0.3,2 = {{p1,2}, {p2,0}, {p3,0}}
(5.15)
Die Transitionen in den orthogonal auszufuhrenden Transitionsfolgen k
mussen sequenziert werden, um eine gultige Testspezifikation zu erhalten.
Die Sequenzierung erfolgt in Algorithmus 5.4.
112
Algorithmus 5.4: Sequenzierung orthogonaler Transitionsfolgen.
Eingabe : KEM0.3
Ausgabe : KEM0.3
1 h= 1 // Laufvariable h fur den Vektor k0.3,o
2 fur o = 1: card(KEM0.3) tue
3 n = max(card(p) ∈ k0.3,o)
4 k = card(k0.3,o)5 fur i=1:n tue6 fur j=1:k tue7 wenn i ≤ card(k0.3,o{j}) dann8 k0.3,o(h) = k0.3,o{j}(i) // i-te Transition t der j-ten
Transitionsfolge p ∈ k0.3,o
9 sonst// tue nichts
10 Ende wenn11 h = h+112 Ende fur13 Ende fur14 Ende fur
Das Ergebnis des Algorithmus wird in Gleichung (5.16) dargestellt:
KEM0.3= {k0.3,0, k0.3,1, k0.3,2}T mit:
k0.3,0 = {t0→1, t5→6, t9→10, t1→2, t6→7, t10→11, t2→3, t7→8, t11→10, t3→2}k0.3,1 =
{t0→1, t5→6, t9→10, t1→2, t6→7, t10→11, t2→3, t7→6, t11→10, t3→EM ′
2
}k0.3,2 =
{t0→1, t5→6, t9→10, t1→2, t6→7, t10→11, t2→3, t7→8, t11→10, t3→EM ′
3
}(5.16)
Die zugrunde gelegte Auswahlstrategie entscheidet, ob die Testspezifikation
der Menge derjenigen entspricht, die aus dem zugrunde liegenden Produk-
tautomaten berechnet wird, oder ob nur eine Teilmenge davon verwendet
wird.
Die Testspezifikation fur orthogonale Bereiche bzw. fur einfache Regionen
setzt sich aus den gleichen Transitionsfolgen in neuer Sequenzierung zu-
sammen. Die gewunschte Ubersichtlichkeit kann nun dadurch gewahrleistet
werden, dass dem Testingenieur die Mengen P in einer separaten Ansicht
dargestellt werden. Genauso kann die Menge K separat dargestellt werden.
113
5.3.5. Zusammenfassung der strukturellen Aspekte
Durch die Heuristik werden fur die unterschiedlichen Regionen der Zu-
standsmaschine cDruckRegler aus der Leitanwendung die Transitionsfolgen
berechnet, welche in Tabelle 5.6 und Bild 5.14 zusammengefasst werden.
PInit: Gleichung (5.6) PEM1: Gleichung (5.12)
P ′EM2: Gleichung (5.10) P ′EM3
: Gleichung (5.11)
PEM2: Gleichung (5.13) PEM3
: Gleichung (5.14)
KEM0.3: Gleichung (5.16)
Tabelle 5.6.: Zusammenfassung der strukturellen Aspekte.
EINSPRUNG (1)
DURCHGESTEUERT (2)
REGELND (3)
DRUCK_BEGRENZEN
DRUCK_REGELN EM1 Initial1 (0)
(4)
INAKTIV (7)AKTIV (6)
AUTODEAKTIVIEREN EM2
Initial2 (5) Final2 (8)
GARANTIE_EIN (11)GARANTIE_AUS (10)
MINDESTDRUCK_GARANTIEREN EM3
Initial3 (9)
EINGESCHALTET (0.3)
AUSGESCHALTET (0.1)
Initial (0.0)
FEHLER (0.2)
Bild 5.14.: Zusammenfassung der errechneten Mengen von Transitions-folgen.
5.3.6. Synthese von Bedatung und Struktur
Mit Hilfe der Heuristik ist in Unterabschnitt 5.3.1 jeder Transition ti→j ∈T ∈ EM eine Menge von Bedatungskombinationen zugeordnet wor-
114
den {ti→j,B}. Basierend auf der Transitionsuberdeckungsstrategie wurden
Mengen von Transitionsfolgen P =⋃
i Pi und K aus dem Testmodell unter
Beibehaltung seiner hierarchischen und orthogonalen Struktur abgeleitet.
Diese Artefakte stellen im Kontext des Frameworks die Grundlage der Test-
spezifikation dar und werden in das TS-MM aus Bild 3.2 uberfuhrt.
Prinzipiell gilt die in Tabelle 5.7 dargestellte Zuordnungsvorschrift:
1: Mengen von Transitionsfolgen P 7−→ Testspezifikation
2: Mengen von Transitionsfolgen P 7−→ Testfallgruppe
2: Orthogonale Transitionsfolgen K 7−→ Kombinationsgruppe
3: Transitionsfolge p 7−→ Testfall
4: Transition ti→j 7−→ Testsequenz
5: Stimulieren und Prufen von VS und VT 7−→ Testschritt
6: Bedatung einer Transition B ∈ B 7−→ Testdatensatz
7: Eine Bedatungskombination b ∈ B 7−→ Bedatungskombination
Tabelle 5.7.: Zuordnung von Struktur und Bedatung zu dem TS-MM.
Zunachst wird mit der Zuordnung der Transitionen ti→j ∈ T in das TS-MM
begonnen. Dazu wird in der Testbibliothek ein Ordner -Element angelegt,
welches die Testsequenzen aufnehmen kann. Fur jede Transition wird ei-
ne Testsequenz und fur deren Verhaltensspezifikation VT ein Testschritt
angelegt. Fur jeden Zustand und dessen Verhaltensspezifikation VS wird
gepruft, ob dieser schon im TS-MM vorhanden ist. Wenn fur den Zustand
noch kein Testschritt-Element existiert, wird aus der Testsequenz ein neues
Element uber die Aggregationsbeziehung angelegt. Wenn fur den Zustand
schon ein Testschritt-Element existiert, wird die Referenzbeziehung aus der
Testsequenz gesetzt.
Zu jedem erstellten Testschritt werden die Elemente Testdatum, WerteBe-
reich und Reprasentant anglegt. Das Attribut Wert des Elements Repra-
sentant wird dabei zunachst zufallig initialisiert, unter Berucksichtigung
des ubergeordneten Attributs Bereich des Elements WerteBereich.
Die der Transition zugeordnete Menge B wird folgendermaßen abgebildet:
Zu jeder Testsequenz wird ein Testdatensatz -Element angelegt, dessen zu-
geordnete Bedatungskombinations-Elemente den Bedatungskombinationen
115
b ∈ B entsprechen. Dazu werden die Referenzbeziehungen auf die Elemente
Testdatum und WerteBereich verwendet.
Als nachstes werden die Mengen von Transitionsfolgen in das Element Test-
spezifikation uberfuhrt. Die dafur vorgesehenen Elemente Testfallgruppe,
Kombinationsgruppe und Testfall sind uber Aggregationsbeziehungen ver-
bunden, damit sie die hierarchische Struktur des Testmodells EM wider-
spiegeln konnen. Zunachst wird eine Testfallgruppe fur die Menge PInit
angelegt, welche ein Testfall -Element fur die Transitionsfolge pInit enthalt.
Der Testfall enthalt die beiden Testsequenzaufruf -Elemente, welche den
Transitionen der Transitionsfolge pInit entsprechen. Ferner enthalt er die
Testfallgruppe PEM0.3, welche den komplexen Zustand Eingeschaltet
(0.3) reprasentiert. Die Testfallgruppe enthalt, analog zu dem Zustand
Eingeschaltet (0.3) drei parallele Testfallgruppen, welche die Mengen
von Transitionsfolgen PEM1bis PEM3
aufnehmen. Auf der gleichen Ebene
der Testfallgruppe PEM0.3wird die Kombinationsgruppe KEM0.3
angelegt,
welche die Transitionsfolgen aus Gleichung (5.16) beinhaltet.
Genauso wie die aus den orthogonalen Regionen resultierenden Transiti-
onsfolgen auf gleicher Ebene im TS-MM abgebildet werden, ist es auch
moglich, die aus dem hierarchischen Zustand Druck Begrenzen (4) re-
sultierenden Transitionsfolgen unterzuordnen. Dies erfolgt beispielsweise
bei der Abbildung der Transitionsfolge p1,1 ∈ PEM1aus Gleichung (5.12).
Zuordnung der Bedatungskombinationen Prinzipbedingt enthalten
die Transitionsfolgen immer wieder die gleichen Transitionen, da die dem
Testmodell zugrundeliegende Zustandsmaschine immer nur ausgehend vom
Initialzustand stimuliert werden kann8. Um aus dieser Wiederholung einen
Nutzen zu ziehen, wird bei der Erstellung der Testsequenzaufruf -Elemente
darauf geachtet, dass die zugeordnete Bedatungskombination b variiert
wird. Dafur wird der Algorithmus 5.5 eingesetzt.
Fur die notwendige Zuordnung
{ti→j, b ∈ B} 7−→ Testsequenzaufruf.Bedatung
8Es ist denkbar, hier Meta-Strategien einzusetzen, um nicht immer bei dem Initialzustand anfangen zumussen.
116
werden dabei bei jedem Aufruf zunachst die Bedatungskombinationen der
Menge Bmin verwendet. Nach jeder Zuordnung wird das Element b der Men-
ge entnommen. Wenn die Menge Bmin leer ist, werden in gleicher Weise die
Bedatungskombinationen der Menge B∆ zugeordnet. Sind beide Mengen
leer, wird auf das erste Element der Menge Bmax verwiesen.
Algorithmus 5.5: Bedatung von Testsequenzen.
1 wenn ti→j.Bmin 6= ∅ dann2 Testsequenzaufruf.Bedatung = ti→j.Bmin.first() // Dem Element
Bedatung das erste Element Bmin.first() zuordnen.3 ti→j.Bmin = ti→j.Bmin \ ti→j.Bmin.first() // Die Menge Bmin um
das erste Element reduzieren.4 sonst wenn ti→j.B∆ 6= ∅ dann5 Testsequenzaufruf.Bedatung = ti→j.B∆.first()6 ti→j.B∆ = ti→j.B∆ \ ti→jB∆.first() // Die Menge B∆ um das
erste Element reduzieren.7 sonst
// (ti→j.Bmin ∧ ti→j.B∆) = ∅8 Testsequenzaufruf.Bedatung = ti→j.Bmax.first()9
Durch die Bestimmung des Bedatungskoeffizienten Qb
Qb =card(Bmin ∪B∆)
card(Bmax)(5.17)
wird dabei fur jede Transition respektive Testsequenz bestimmt, wie viel
Prozent der maximal moglichen Bedatungskombinationen in der Testspe-
zifikation verwendet werden.
Fur die Kombinationsgruppe erfolgt die analoge Zuordnung zu Testse-
quenzaufrufen.
In Bild 5.15 ist die im Vorhergehenden beschriebene Abbildung der Re-
sultate der Heuristik in das TS-MM dargestellt. Die hierarchischen und
orthogonalen Beziehungen sind in der Baumstruktur des TS-MM darge-
stellt.
117
Bild 5.15.: Auszug des resultierenden TS-MM.
118
5.4. Uberfuhren der Testspezifikation in
ausfuhrbaren Code
Im Rahmen des Testframeworks besteht der nachste Schritt darin, die
formale Testspezifikation in ausfuhrbaren Code zu transformieren. Als
Ausfuhrungsplattform wird das in Abschnitt 4.3 vorgestellte Unit-Test-
Framework verwendet.
Die Transformation der Testspezifikation in die Sprache C++ erfolgt als
Modell-zu-Code Transformation unter Verwendung der openArchitecture-
Ware Xpand-Language [26].
Die generierte Testspezifikation wird in der Klasse cDruckRegler Test im-
plementiert, welche von der Klasse cTest des Unit-Test-Frameworks erbt,
siehe Bild 5.16.
Bild 5.16.: Design des Unit-Tests fur die Klasse cDruckRegler mit der Test-implementierung cDruckRegler Test.
Die Elemente der Testspezifikation werden durch folgende Abbildungsre-
geln in Code uberfuhrt; die Aufzahlung erfolgt ausgehend von dem unters-
ten Element in der Hierarchie, dem Testschritt.
Testschritt Fur jede Uberprufung, ob das System in einem definierten
Ausgangs-Zustand ist, wird ein separates Testschritt-Element ange-
legt. Analog werden fur die Stimulation und Uberprufung der Ver-
haltensspezifikation der Transition und die Uberprufung des Ziel-
Zustandes separate Testschritt-Elemente angelegt. Innerhalb der Zu-
standsprufungen sind auch die jeweiligen Verhaltensspezifikationen
des Zustandes zu prufen. Die Zustandsprufung wird durch die Me-
thode testState() implementiert, deren Grundprinzip in Listing 5.1
dargestellt ist. Die Umsetzung ist so angelegt, dass eine Abstraktion
der Implementierung von dem Testmodell moglich ist. Dies kann an-
hand des orthogonalen Zustandes Eingeschaltet veranschaulicht
119
werden. Der Code der Klasse cDruckRegler weist keinen explizit ab-
fragbaren Zustand mit dem Namen Eingeschaltet auf. Dass sich
die Implementierung in diesem Zustand befindet, kann jedoch durch
die Abfrage uberpruft werden, ob der Druckregler und der zugeord-
nete Stromregler den Status OK aufweisen.
1 bool cDruckRegler Test : : t e s t S t a t e ( const char ∗ stateName ) {2
3 /∗ PROTECTED REGION ID( t e s t S t a t e ) ENABLED START ∗/4 i f ( ! strcmp ( stateName , ”E i n g e s c h a l t e t ” ) ) {5 i f (DR−>IstOK ( ) && DR−>StromreglerIstOK ( ) ){6 return true ;
7 } else {8 return fa l se ;
9 }10 }11 /∗ PROTECTED REGION END ∗/12 . . .
13 }
Listing 5.1: Auszug aus der Implementierung der Methode
testState().
Testsequenz Die Testsequenz implementiert die einer Transitionsfolge
entsprechenden Testschritte in einer bedatbaren Methode. Die Argu-
mentenliste der Methode entspricht den Faktoren der Transitionsfol-
ge. Listing 5.2 zeigt die Implementierung des Tests fur den Zustands-
ubergang von dem Zustand Ausgeschaltet nach Eingeschaltet.
Fur die Uberprufung der Zustande wird die beschriebene Methode
testState() eingesetzt.
1 void cDruckRegler Test : : SEQ cDruckReg ler Ausgescha l tet Eingescha l tet
2 ( const int &i n p S t e u e r S o l l , const int &i n p R e g e l S o l l ) {3
4 t e s t ( this−>t e s t S t a t e ( ”Ausgescha l t e t ” ) ) ;
5 i f ( ! ( this−>t e s t S t a t e ( ”Ausgescha l t e t ” ) ) ) {6 throw std : : runt ime er ro r ( ”th i s−>t e s t S t a t e (\”Ausgescha l t e t \”) f a i l e d ” ) ; }7
8 DR−>Einscha l t en ( i n p S t e u e r S o l l , i n p R e g e l S o l l ) ;
9
10 t e s t ( this−>t e s t S t a t e ( ”E i n g e s c h a l t e t ” ) ) ;
11 i f ( ! ( this−>t e s t S t a t e ( ”E i n g e s c h a l t e t ” ) ) ) {12 throw std : : runt ime er ro r ( ”th i s−>t e s t S t a t e ( ”E i n g e s c h a l t e t ”) f a i l e d ” ) ; }13 }
Listing 5.2: Implementierung des Elements Testsequenz.
120
Testfall Das Element Testfall implementiert die Ausfuhrung einer Tran-
sitionsfolge. Dazu werden die Testsequenzaufruf -Elemente des TS-
MM in einen Methodenaufruf transformiert. Das Listing 5.3 zeigt
das Ergebnis der Transformation fur das Testsequenzaufruf -Element
von der Transitionsfolge tEingeschaltet→Ausgeschaltet. Der Methodenauf-
ruf SEQ_cDruckRegler_Ausgeschaltet_Eingeschaltet(...) er-
folgt mit der in Bild 5.7 dargestellten Bedatungskombination b1.
1 void cDruckRegler Test : : T F I n i t i a l A u s g e s c h a l t e t ( ) {2
3 SEQ cDruckRegler Initial ZUSTAND AUS ( ) ;
4
5 SEQ cDruckReg ler Ausgescha l tet Eingescha l tet
6 ( int (2500) /∗ p S t e u e r So l l [ 0 , 5000 ] ∗/ ,
7 int (2000) /∗ p Reg e l S o l l [ 0 , 3000 ] ∗/ ) ;
8 . . .
9 }
Listing 5.3: Implementierung des Elements Testfall.
Testfallgruppe Das Element Testfallgruppe wird durch eine Methode im-
plementiert, welche die zugeordneten Testfall -Elemente sequenziell
aufruft. Um zu gewahrleisten, dass die Zustandsmaschine vor je-
dem Testfallaufruf wieder in dem Initial-Zustand ist, wird die Me-
thode reset() generiert, welche die Instanz der zu testenden Klasse
cDruckRegler aus dem Speicher loscht und neu anlegt.
Kombinationsgruppe Das Element Kombinationsgruppe wird analog zu
dem Element Testfallgruppe angelegt.
Testspezifikation Das Element Testspezifikation wird in der Implemen-
tierung der zentralen run()-Methode des Unit-Test Frameworks rea-
lisiert. Alle aggregierten Testfallgruppen werden dadurch sequenziell
aufgerufen.
5.5. Anwendung
Im Folgenden soll die generierte Testspezifikation bewertet werden. Da-
zu wird der erzeugte Testcode gegen die Implementierung der in Kapitel
4 beschriebenen Leitanwendung ausgefuhrt. Parallel wird die durch das
121
Framework mogliche Vorgehensweise der Testcodeerstellung mit der kon-
ventionellen Herangehensweise verglichen.
Um den Code ausfuhren zu konnen, sind zunachst die in Abschnitt 4.4
beschriebenen Vorarbeiten zu leisten. Ein Visual-Studio-Projekt (*.vcproj)
muss angelegt werden, welches die zu testenden C++-Quellen referenziert
und die notwendigen Stub-Objekte9 bereitstellt, damit das SUT uberhaupt
lauffahig ist.
Zur Erleichterung dieser zeitaufwendigen Arbeitsschritte ist der Code-
generator so erweitert worden, dass er einen Großteil der notwendigen
Test-Infrastruktur generieren kann. Zum einen wird das benotigte Visual-
Studio-Projekt (*.vcproj) generiert. Die Generierung ist moglich, da es sich
um eine XML-Datei handelt. Sie muss die Verweise auf die zu inkludie-
renden Quellcode-Dateien, Bibliotheksverweise (*.lib) und Praprozessor-
Anweisungen enthalten. Die fur die Generierung notwendigen Informatio-
nen werden dabei folgendermaßen gewonnen: Der Ablageort der Quellcode-
Dateien ist standardisiert und der Dateiname der benotigten Quellcode-
Dateien kann durch eine Nomenklatur-Festlegung aus dem Design abgelei-
tet werden. Fur die Leitanwendung bedeutet dies: Aus dem Klassennamen
cDruckRegler im Design kann geschlossen werden, dass die Implementie-
rung in den Dateien druckregler.cpp/hpp abgelegt wird.
Zum anderen werden die Code-Rahmen der Stub-Objekte generiert. Da-
zu werden die aus dem UML-Klassendiagramm bekannten und im Ex-
change-Meta-Modell gespeicherten Informationen uber die Klassenbezie-
hungen und Operationen herangezogen.
Zusatzlich enthalt der aus der Testspezifikation generierte Quellcode ne-
ben der eigentlichen Testspezifikation die Instanziierung des Unit-Test-
Frameworks.
In dieser Vorgehensweise zeigt sich ein erster Vorteil der Einbindung der
Heuristik in das Testframework. Die Infrastruktur fur den Test steht deut-
lich schneller bereit. Wahrend die konventionelle Erstellung der Tests und
der Test-Infrastruktur Tage und Wochen in Anspruch nimmt, ist dies mit
dem Testframework in Stunden machbar.
9Ein Stub-Objekt ersetzt die Funktionalitat eines Objektes fur den Test. Dabei wird die Funktionalitatauf das Minimum reduziert.
122
Ein weiterer Vorteil ist in der klaren Struktur des Testcodes zu sehen.
In der manuellen Implementierung, welche uber einen langeren Zeitraum
entstanden ist, sind unterschiedliche Umsetzungen, Strukturierungen und
Bezeichnungen zu finden. Der generierte Code hingegen enthalt die Inhalte
der in Bild 5.15 dargestellten Testspezifikation in genau der Struktur, wie
sie durch die Transformationsvorschriften aus Abschnitt 5.4 vorgegeben
sind.
Wahrend der eigentlichen Erstellung der Testspezifikation aus dem Design
hat sich die sukzessive Vorgehensmoglichkeit der Heuristik als sehr hilfreich
erwiesen. Durch die Platzierung des Stereotyps «SMUT» ist zunachst fur
den Zustand Eingeschaltet eine Testspezifikation erstellt und in Test-
code uberfuhrt worden. Nachdem die Stub-Objekte implementiert waren
und die Test-Infrastruktur lauffahig war, wurde die Testspezifikation durch
die Umplatzierung des Stereotyps sukzessive erweitert.
Da das SUT manuell aus dem Design abgeleitet wurde, war die Implemen-
tierung haufig komplexer oder anders, als es das Design vorgab. Nach der
Plausibilisierung der korrekten Funktionalitat des SUT musste also ent-
weder das Design oder der Testcode angepasst werden. Als hilfreich und
notwendig hat sich dafur das Konzept der Protected Regions erwiesen, wel-
ches eine manuelle Erganzung des generierten Codes ermoglicht.
Der inhaltliche Vergleich der generierten Testspezifikation mit der manuel-
len Testspezifikation ergab, dass das zustandsbasierte Verhalten des SUT
mit der generierten Testspezifikation vollstandig getestet werden kann.
Aus dem Vergleich der erreichten Zweiguberdeckung (C1), vgl. Unterab-
schnitt 2.6.3.1, der Klasse cDruckRegler bei der Stimulation mit den bei-
den Testspezifikationen ergibt sich, dass die generierte Testspezifikation
50% C1-Abdeckung erzielt. Die manuell erstellte Testspezifikation erzielt
70% C1-Abdeckung. Der Unterschied ist damit zu erklaren, dass die Imple-
mentierung des SUT uber zusatzliches, nicht zustandsbasiertes Verhalten
verfugt. Dabei handelt es sich um triviale Setter- und Getter-Methoden
oder um domanenspezifische Besonderheiten, wie sie durch die Kennlinien-
Abhangigkeit aus Bild 4.2 beschrieben sind.
123
6. Einsatz des Testframeworks
Das vorliegende Kapitel zeigt die im Rahmen der Arbeit entstandenen Aus-
pragungen des in Kapitel 3 konzipierten Testframeworks auf. Die Erlaute-
rungen erfolgen anhand der in Bild 6.1 dargestellten grafischen Benutzer-
oberflache des Testframeworks. Die Implementierung realisiert dabei ver-
schiedene Auspragungen der in dem Testframework vorgesehenen Schich-
ten, vgl. Bild 3.1. In Abschnitt 6.1 werden die parallel zu der Heuristik
integrierten Testentwurfsmethoden und deren Initialisierung mit Informa-
tionen aus dem Entwicklungsprozess beschrieben. Der Abschnitt 6.2 zeigt
den Nutzen der formalen Testspezifikation und die Potenziale durch die
M2Text-Transformation auf. Abschnitt 6.3 fasst schließlich den Nutzen und
die Potenziale des Testframeworks zusammen.
Bild 6.1.: Benutzeroberflache des Testframeworks.
124
6.1. Methoden und deren Einbindung
Die in Kapitel 5 beschriebene Heuristik ist in die grafische Benutzeroberfla-
che aus Bild 6.1 folgendermaßen integriert: Der Knopf Load Statemachine
transformiert die UML-Zustandsmaschine, welche das Verhalten der Leit-
anwendung beschreibt, in eine Instanz des Exchange-Meta-Modells, wie es
in Unterabschnitt 5.2.4 beschrieben ist. Der Knopf Statebased Test fuhrt die
Berechnungen der Heuristik aus und erzeugt mit dem Ergebnis eine Instanz
des Testspezifikations-Meta-Modells, wie es in Abschnitt 5.3 erlautert wird.
Mit dem Knopf Edit Testspezifikation wird ein Editor fur die Testspezifi-
kation geoffnet, wie er in Bild 5.15 dargestellt ist. Schließlich kann durch
den Knopf Generate C++ Code die in Unterabschnitt 3.2.3 beschriebene
Transformation in den C++ Testcode durchgefuhrt werden.
Der Grundgedanke des Testframeworks ist es, verschiedene Testentwurfs-
methoden einbinden zu konnen. Diese Moglichkeit ist notwendig, da eine
zu testende Implementierung mehr als nur zustandsbasiertes Verhalten auf-
weisen kann,wie sich in der Anwendung der berechneten Testspezifikation
auf den Quellcode der Leitanwendung gezeigt hat (vgl. Abschnitt 5.5).
Insbesondere komplexere Berechnungsmethoden wie die Kennlinienzugrif-
fe, lassen sich unter Zuhilfenahme der Klassifikationsbaummethode testen.
Zu diesem Zweck wurde der Klassifikationsbaumeditor CTE-XL [24] in das
Framework integriert. Dies ist technologisch moglich, da der CTE-XL mit
XML-Dateien arbeitet. Darin sind der Klassifikationsbaum und das Ergeb-
nis der Testauswahlstrategien formal gespeichert.
Fur die Einbindung des CTE-XL in das Testframework wurde in das UML-
Design ein weiterer Stereotyp mit Namen «FUT» (Function Under Test)
eingefuhrt, um gezielt Methoden fur den Test kennzeichnen zu konnen. Fur
den spezifischen Fall der Leitanwendung ist das Exchange-Meta-Modell
schon so angelegt, dass es die mit «FUT» gekennzeichneten Methoden
speichern kann. Die Einbindung des CTE-XL erfolgt dann als Modell-zu-
Modell-Transformation in der Methodenschicht. Dazu ist es zunachst notig
ein EMF-Modell des CTE-XML-Schemas zu erstellen, welches als CTE-
Meta-Modell (CTE-MM) bezeichnet wird. Im Kontext des Frameworks ist
es damit moglich, Dateien zu erzeugen, welche der CTE-XL weiterverar-
beiten kann. Die Informationen aus dem Exchange-Meta-Modell, welche
125
Methode getestet werden soll und welche Parameter und Wertebereiche
diese aufweist, werden in der M2M-Transformation in das CTE-MM trans-
formiert.
Das Einlesen des modifizierten UML-Designs und die Transformation des
Exchange-MM in das CTE-MM wird durch den Knopf Load Class-Diagram
angestoßen. Das Ergebnis der Transformation ist eine XML-Datei mit der
Endung *.cte, welche die mit «FUT» gekennzeichnete Klassen-Methode
als Klassifikationsbaum-Wurzel, deren Parameter als Klassifikationen und
deren Wertebereiche als Klassen aufweist. Durch den Knopf Testcases via
CTE wird der CTE-XL geoffnet. Der Benutzer kann nun die erzeugte *.cte-
Datei offnen und Bedatungskombinationen erzeugen, wie es Bild 6.2 zeigt.
Dazu stehen die in Unterabschnitt 2.6.4.2 beschriebenen Auswahlstrategi-
en zur Verfugung. Durch das Speichern der Datei in dem CTE-XL wird die
zugrundeliegende *.cte-Datei um die gewahlten Bedatungskombinationen
erweitert. Die daraus folgende *.cte-Datei wird durch das Testframework
Bild 6.2.: Beispiel fur das Einbinden des CTE-XL in das Testframework.
weiterverarbeitet. Dazu wird die *.cte-Datei wieder in das CTE-MM ein-
gelesen, um eine M2M-Transformation in das Testspezifikations-MM zu er-
moglichen. Der auf diese Weise fur eine Methode spezifizierte Test wird auf
ein Testsequenz -Element abgebildet. Die ursprunglich im CTE-XL gewahl-
ten Bedatungskombinationen werden nun in das Testdatensatz -Element
und dessen untergeordnete Bedatungskombinations-Elemente uberfuhrt.
Das beschriebene Vorgehen ermoglicht es, die mit der Heuristik erstell-
te Testspezifikation fur die Leitanwendung zu erweitern. Daraus wird das
Potenzial des Testframeworks ersichtlich, Testentwurfsmethoden einzubin-
den, die schon als Software-Werkzeug zur Verfugung stehen. Alternativ ist
es auch moglich, die im Kontext der Heuristik eingesetzten Auswahlstrate-
126
gien zu verwenden, um fur eine mit «FUT» gekennzeichnete Methode eine
Testspezifikation zu bestimmen.
Eine weitere Moglichkeit, die Testspezifikation zu erweitern, wird durch
das Werkzeug T-Config [56] ermoglicht. Das Werkzeug bestimmt nach der
Bekanntgabe der Faktoren und Level einer mit «FUT» gekennzeichneten
Methode eine Auswahlmatrix, welche wenn moglich einem orthogonalen
Feld entspricht, wie es in Unterabschnitt 2.6.4.2 beschrieben ist. Der Aufruf
dieser Vorgehensweise ist in der grafischen Benutzeroberflache durch den
Knopf Orthogonal Array realisiert.
Diskussion: In dieser Arbeit wurden die beschriebenen Testentwurfs-
methoden in das Testframework integriert. Die Konzeption des Testframe-
works sieht dabei jedoch vor, zukunftig weitere Testentwurfsmethoden in-
tegrieren zu konnen. Die Integration von Werkzeugen zum modellbasierten
Test soll dabei nach folgenden Szenarien moglich sein: Wenn die einzubin-
dende Losung eine offene Schnittstelle fur das verwendete Testmodell hat,
kann eine Initialisierung des Testmodells mit Informationen aus dem Ent-
wicklungsprozess erfolgen, wie es die im Rahmen der Arbeit entstandene
Heuristik aufzeigt. Kommerzielle Werkzeuge zum modellbasierten Test er-
rechnen eine Testspezifikation, welche in einer formalen Form, meistens in
XML, abgelegt wird. Die Integration in das Testframework besteht dann
nur aus einer M2M-Transformation der fremden Testspezifikation in das
Testspezifikations-Meta-Modell. Auf diese Weise konnen die bereits erar-
beiteten Modell-zu-Text-Transformationen fur die firmenspezifischen Test-
ausfuhrungsplattformen weiterverwendet werden. Kommerzielle Losungen
sind beispielsweise von den Firmen Conformiq [4] oder Leirios [9] verfugbar.
Die im Rahmen der Arbeit entstandene Heuristik zur modellbasierten Test-
sequenzgenerierung verspricht durch die klare Struktur der errechneten
Testspezifikation und die Moglichkeit der schrittweisen Erweiterung der
Testspezifikation Akzeptanz fur das modellbasierte Testen zu schaffen.
Einsatz der Heuristik auf anderen Teststufen Um die Heuristik
des Testframeworks auf anderen Teststufen einsetzen zu konnen, ist die
jeweilige Anwendung zu betrachten. Dies soll am Beispiel der Teststufe
Integrationstest erlautert werden, welche auf Seite 26 beschrieben ist. Die
127
Software wird dabei in einer Software-in-the-Loop (SiL) Simulation betrie-
ben. Das bedeutet, dass das zustandsbasierte Verhalten einzelner Kom-
ponenten nicht mehr ohne die Wechselwirkung der Gesamtsoftware und
des Umgebungsmodells getestet werden kann, vgl. Bild 2.15. Bezogen auf
die Leitanwendung, die Implementierung der Klasse cDruckRegler, steht
damit nicht mehr die Teilfunktionalitat im Blickwinkel, sondern die Funk-
tionalitat in der Gesamtsoftware. Diese besteht darin, die Schaltelemente
des Getriebes zu betatigen, damit ein Gang eingelegt werden kann. Die
Testspezifikation kann dafur exemplarisch folgende Testschritte beinhal-
ten: Motor einschalten → D-einlegen → Triebstrang geschlossen? → Gang
eingelegt? → Beschleunigen → .... Eine solche Testspezifikation lasst sich
Triebstrang_geschlossen Fahrend
Fahrend_Fehlersituation
Beschleunigen/
FehlerAusloesen/
D_einlegen/cSteuerungSiL
D_einlegen ()
Beschleunigen (in v_ziel)
FehlerAusloesen(in FehlerNummer)
Klassendiagramm Zustandsdiagramm
Bild 6.3.: Anwendung der Heuristik am SiL.
auch als UML-Klassendiagramm und UML-Zustandsdiagramm formulie-
ren, wie es das Testmodell in Bild 6.3 veranschaulicht. Die zur Stimulati-
on von Zustandsubergangen notwendigen Methoden werden dabei in einer
Klasse zusammengefasst. Die erwartete Funktionalitat der Software wird
als Zustandsmaschine formuliert.
Unter Verwendung des Frameworks resultiert aus dem Testmodell eine for-
male Testspezifikation als Instanz des TS-MM. Die Transformation der
Testspezifikation muss nun allerdings neu geschrieben werden, um die neue
Testausfuhrungsplattform (SiL) stimulieren zu konnen.
6.2. Formale Testspezifikation und
Transformation
Neben der automatischen Instanziierung des Testspezifikations-Meta-Mo-
dells kann es auch manuell mit Hilfe des Editors erstellt werden, vgl. Bild
3.3. Ein wichtiger Aspekt ist dabei die Moglichkeit, die Nomenklatur in
128
der Domane Test firmenspezifisch durch die Elemente des Meta-Modells
pragen zu konnen. Bei der Erstellung einer Testspezifikation mit dem
Editor entsteht ein hierarchisch strukturiertes und ubersichtliches Doku-
ment, welches durch die M2Text-Transformation des Testframeworks wei-
ter in ausfuhrbaren Testcode uberfuhrt werden kann. Die Testinhalte wer-
den dabei von der konkreten Implementierung getrennt. Dies verbessert
auch die Kommunikation der Testinhalte zwischen den beteiligten Ent-
wicklungsteams, da in der Regel nicht jeder Mitarbeiter alle verwendeten
Test-Implementierungssprachen versteht. Die Transformation ermoglicht
es, aus einer Instanz des TS-MM die gleichen Testinhalte auf verschiedenen
Testausfuhrungsplattformen zum Einsatz zu bringen. Diese Vorgehensweise
hilft das Verhalten des SUT auf unterschiedlichen Testplattformen verglei-
chen zu konnen.
Aufgrund der haufig unterschiedlichen Testausfuhrungsplattformen und
der Moglichkeit, eine Testautomatisierung unterschiedlich zu strukturie-
ren, weisen die Testautomatisierungen einzelner Projekte haufig Unter-
schiede auf. Der Ansatz, die Testimplementierung durch eine M2Text-
Transformation zu realisieren, birgt dabei den Vorteil, dass die Transforma-
tionsvorschrift leicht an die Projektgegebenheiten angepasst werden kann,
da die Transformation zum Großteil auf einem Template basiert, wie es
das Listing 3.2 aufzeigt.
Die Arbeitsschritte zur Erstellung der Test-Infrastruktur machen ca. zwei
Drittel des notwendigen Arbeitsaufwandes fur den Test aus, die Umset-
zung der Testinhalte ca. ein Drittel. Damit liegt in der Erstellung der
Test-Infrastruktur ebenfalls großes Automatisierungspotenzial, wie es im
Kontext der Leitanwendung in Abschnitt 5.5 beschrieben worden ist. Eine
generische Losung fur die Generierung der Test-Infrastruktur kann im Rah-
men der Arbeit nicht gegeben werden. Die Verwendung der dem Testfra-
mework zugrunde liegenden Technologie der generativen Programmierung
und des Grundgedankens der MDA, Softwarewerkzeuge auf den gleichen
Konstruktionselementen aufzubauen, zeigt jedoch ein Verbesserungspoten-
zial auf. Wenn projektspezifische Automatisierungslosungen ebenfalls die
verwendeten Konzepte des Frameworks verwenden, so bauen diese auf den
gleichen Konstruktionselementen, konkret dem *.ecore-Meta-Meta Modell,
auf. Dadurch wird es moglich, punktuell entstandene Teil-Losungen lang-
fristig zu großeren zusammenhangenden Losungen zu integrieren.
129
6.3. Nutzen und Potenziale
Die Anwendung des Testframeworks ermoglicht den Einsatz werkzeug-
gestutzter Testentwurfsmethoden in bestehenden Entwicklungsprozessen.
Durch das methodische Vorgehen wird eine Qualitatssteigerung der Test-
prozesse herbeigefuhrt. Ferner bedingt das Testramework als durchgangig
geschlossene Werkzeugkette eine Effizienzsteigerung bei der Erstellung und
Ausfuhrung von Testspezifikationen. Durch die formale Beschreibung der
Testinhalte wird es moglich, die methodisch erstellten Testspezifikationen
auf unterschiedlichen Ausfuhrungsplattformen zu implementieren und die
Testinhalte effektiv uber verschiedene Teststufen zu verteilen. Ferner wird
ein bedarfsgerechter Einsatz der Testentwurfsmethoden in verschiedenen
Entwicklungsphasen ermoglicht.
130
7. Zusammenfassung und Ausblick
In der vorliegenden Arbeit wurde ein Testframework konzipiert und im-
plementiert, welches die Integration von Testentwurfsmethoden in einen
bestehenden Software-Entwicklungsprozess ermoglicht. Die Aufgabenstel-
lung resultiert aus der Beobachtung, dass Testentwurfsmethoden haufig
nur implizit angewendet werden, da entweder keine Unterstutzung durch
ein Software-Werkzeug gegeben ist oder bestehende Software-Werkzeuge
nicht in die vorgegebene Entwicklungslandschaft integriert werden konnen.
Das erarbeitete Testframework besteht aus drei Schichten: Eine Schicht,
um Artefakte aus dem Software-Entwicklungsprozess fur die Initialisierung
von Testentwurfsmethoden heranziehen zu konnen, eine weitere Schicht,
um die Testentwurfsmethoden zu verwenden und eine dritte Schicht, um
die methodisch erstellte Testspezifikation auf formale Art und Weise zu
erfassen. Basierend auf der formalen Testspezifikation werden Codegene-
ratoren vorgesehen, um die Transformation auf die jeweils anzubindende
Testausfuhrungsplattform zu realisieren.
Zur Umsetzung des Frameworks werden die Konzepte des OMG Stan-
dards Model Driven Architecture (MDA) verwendet. Dabei wird eine ad-
aptierte Implementierung durch das Eclipse Projekt open-Architecture-
Ware (oAW) benutzt. In diesem Kontext wird die Anbindung der Test-
entwurfsmethoden an den Software-Entwicklungsprozess als Modell-zu-
Modell-Transformation (M2M) realisiert. Die Anbindung der Testspezifika-
tion an die verschiedenen Testausfuhrungsplattformen werden als Modell-
zu-Text-Transformation (M2Text) umgesetzt.
Zentrales Element des Testframeworks ist das Testspezifikations-Meta-
Modell. Es hat zur Aufgabe, die methodisch erstellten Testinhalte von
einer plattformspezifischen Implementierung zu trennen. Dadurch ergibt
sich die Moglichkeit, die Testinhalte einfacher in Entwicklungsteams zu
kommunizieren und die Nomenklatur in der Domane Test firmenspezifisch
zu pragen.
131
In der Methodenschicht des Testframeworks wurde mit der Einbindung des
Klassifikationsbaum-Editors CTE-XL die Fahigkeit aufgezeigt, bestehende
Software-Werkzeuge integrieren zu konnen.
Zudem wurde eine neuartige Heuristik zum modellbasierten Testen, basie-
rend auf UML-Zustandsdiagrammen, erarbeitet und integriert. Die Merk-
male der Heuristik sind, dass die in UML-Zustandsdiagrammen mogli-
chen Strukturierungselemente Hierarchie und Orthogonalitat explizit bei
der Testerstellung beibehalten werden. Zudem ist es moglich, eine Test-
spezifikation, basierend auf einem komplexen Zustandsmodell, schrittweise
abzuleiten.
Im Gegensatz zu herkommlichen Ansatzen, die dem UML-Zustands-
diagramm zugrunde liegende erweiterte endliche Zustandsmaschine in eine
einfache Zustandsmaschine umzuformen, verzichtet die Heuristik auf die
Umformung. Stattdessen werden bekannte Algorithmen zur Ableitung einer
Testspezifikation aus endlichen Zustandsmaschinen auf die einzelnen Regio-
nen des UML-Zustandsdiagramms angewendet. Es resultiert eine Testspe-
zifikationen mit einer hierarchischen Struktur, wie sie durch die erweiterte
Zustandsmaschine vorgegeben ist. Diese Vorgehensweise ermoglicht es dem
Testingenieur, den Bezug der Testspezifikation zu der zugrundeliegenden
Zustandsmaschine einfach herzustellen.
Aus der Heuristik resultiert eine Testspezifikation, welche aus der Struk-
tur des Testmodells gewonnen wird. Dabei sind die einzelnen Transitio-
nen und Zustandsubergange auch an bedatbare Verhaltensspezifikationen
gebunden. Im Rahmen der Heuristik werden fur die Auswahl konkreter
Bedatungskombinationen Auswahlstrategien, wie die minimale Kombina-
torik, herangezogen.
Die Funktionsweise der Heuristik und eine Auspragung des Testframeworks
werden anhand einer Leitanwendung aus dem Modultest einer Getriebe-
Steuerungs-Software veranschaulicht.
Das Testframework schafft durch seine Konzeption eine Moglichkeit, Test-
entwurfsmethoden auf allen Teststufen technologisch wiederzuverwenden.
Zunachst wird eine formale Testspezifikation als Instanz des Testspezifika-
tions-Meta-Modells erstellt, welche erst durch eine konkrete Transformati-
on die Testinhalte in den auf der Teststufe verwendeten Testautomatisie-
rungscode uberfuhrt. Durch die Generierung der Test-Infrastruktur kann
132
der teilweise betrachtliche Aufwand zu deren Bereitstellung reduziert wer-
den, wodurch eine weitere Effizienzsteigerung im Testprozess erzielt werden
kann.
Die im Verlauf der Arbeit gesammelten ersten Erfahrungen mit dem Ein-
satz des Testframeworks und der Heuristik zum modellbasierten Testen ha-
ben Vorteile erkennen lassen. So ist zum einen hervorzuheben, dass durch
den Einsatz einer Methode zum Testentwurf konkret nachgewiesen werden
kann, wie die Testinhalte entstanden sind. Durch die Formalisierung der
Testinhalte und den Einsatz einer Transformation, um ausfuhrbaren Test-
code zu erzeugen, konnten zeitaufwendige manuelle Arbeitsschritte einge-
spart werden.
Zukunftig sollte daran gearbeitet werden, weitere Transformationen und
Methoden im Rahmen des Testframeworks anzubinden. Es ist zu erwarten,
dass mit der wachsenden Funktionalitat eine Evolution der verwendeten
Meta-Modelle stattfindet.
133
A. Entwicklung der Algorithmen zur
Testsequenzinitialisierung
Funktion splitGraph(start,end)
Eingabe : start, endAusgabe : ret = {subGraph}
1 Initialisierung:
2 ret =
region: = ∅start: = ∅end: = ∅
3 wenn r(start) == r(end) // Beide Zustande sind Element dergleichen Region
4 dann
5 ret = ret ∪
region: = r(start)
start: = start
end: = end
6 sonst7 current = r(end)8 target = end9 wahrend current 6= r(start) tue
10 subRegion = current
11 ret = ret ∪
region: = subRegion
start: = subRegion.ss
end: = target
12 target = s(subRegion) // Der Zustand, welcher die Regionbeinhaltet.
13 current = r(target) // Die Region, welche den Zustand targetbeinhaltet.
14 Ende-wahrend
15 ret = ret ∪
region: = current
start: = start
end: = target
16 Ende wenn
134
Beschreibung der Funktion splitGraph Bezug nehmend auf den Unterab-
schnitt 5.3.2.
1. Durchlauf
Aufruf der Funktion splitGraph(start = Initial, end = Initial1)
Zeile 3 false
Zeile 7 current = r(end) = DRUCK REGELN
Zeile 8 target = Initial1
Zeile 10 subRegion = DRUCK REGELN
Zeile 11 ret =
region: = DRUCK REGELN
start: = Initial1
end: = Initial1
Zeile 12 target = s(DRUCK REGELN) = EINGESCHALTET
Zeile 13 current = r(EINGESCHALTET) = cDruckRegler
2. Durchlauf
Zeile 9 false, da current == r(start) (hier: cDruckRegler)
Zeile 15 ret =
region: cDruckRegler
start: Initial
end: EINGESCHALTET
region: DRUCK REGELN
start: Initial1
end: Initial1
T
135
A.1. Dijkstra-Algorithmus
Beschreibung des Dijkstra-Algorithmus, wie er im Kontext der Ausfuhrun-
gen aus Unterabschnitt 5.3.2 verwendet wird. Der Algorithmus ist auf die
beiden Funktionen findLocalPath() und relaxe() aufgeteilt. Die Dar-
stellung ist in Pseudo-Code aufgefuhrt, verwendet jedoch die im Rahmen
der Implementierung eingesetzten Java-Klassen.
Funktion findLocalPath(EM , path,start,end)
Eingabe :EM : // Testmodell EM = 〈SM,S, T,R,W 〉
1 path: Vector<Transition>2 start: Zustand3 end: Zustand
Ausgabe : Die Funktion beschreibt die Variable path mit derTransitionsfolge, welche die wenigsten Faktoren enthalt
4 Initialisierung:5 queue: PriorityQueue<Transition> // Prioritatsorientierte
Schlange, welche so initialisiert ist, dass sie die Transition mitden meisten Faktoren (t.factors) zuruckgibt
6 visited: HashSet<Zustand>7 distance: HashMap<Zustand, Integer>8 distance.put(start,0) // Distanz des Startknotens auf Null setzen9 previous: HashSet<Transition>
10 relaxe(EM , start, queue, distance, previous, visited)11 solange queue nicht leer ist tue12 t = queue.poll() // Abfragen und entfernen des vordersten
Elements der Schlange13 u = t.target14 wenn u == end dann15 found = true;16 Ende wenn17 visited.add(u)18 relaxe(EM , u, queue, distance, previous, visited)19 Ende solange20 path = previous
136
Funktion relaxe(EM , start, queue, distance, previous, visited)
Eingabe :EM : // Testmodellstart: Zustandqueue: PriorityQueue<Transition>distance: HashMap<Zustand, Integer>previous: HashSet<Transition>visited: HashSet<Zustand> // vAusgabe : In dem Vektor previous wird die Transitionsfolge mit
den wenigsten Faktoren abgelegt1 fur alle t ∈ EM mit [t.source == start] // Alle Transitionen,
welche den Zustand start verlassen2 tue3 v = t.target // Zielzustand der Transition4 wenn v /∈ visited dann5 Initialisierung:6 d1 =∞, d2 =∞7 d1 = distance.get(start) // Enfernungswert aus distance
auslesen, welcher start zugeordnet ist8 d2 = distance.get(v) // Enfernungswert aus distance auslesen,
welcher dem aktuellen Zielzustand v zugeordnet ist9 factors = t.factors // Anzahl der zu bedatenden Faktoren der
aktuellen Transition bestimmen10 wenn d2 > d1 + factors.size() dann11 distance.put(v,d1+factors.size())12 previous.add(t)13 queue.add(t)14 Ende wenn15 Ende wenn16 Ende fur
137
B. Entwicklung des Algorithmus zur
Transitionsuberdeckung
Im Folgenden wird die Entwicklung des Algorithmus 5.1 fur den Fall dar-
gestellt, dass der Zustand Initial (0.0) mit dem Stereotyp «SMUT» ge-
kennzeichnet ist.
Eingabe fur den Algorithmus 5.1
EM = 〈SM,S, T,R,W 〉: Eine Instanz des Exchange-Meta-Modells, welche
das in Bild B.1 dargestellte Verhalten reprasentiert.
FEHLER (0.2)AUSGESCHALTET (0.1)
[Stromregler_Fehler]/Einschalten()/Ausschalten()/
EINGESCHALTET (0.3)
cDruckRegler
INITIAL
(0.0)
SM = {Initial}S = {Initial (0.0), Ausgeschaltet (0.1), Eingeschaltet (0.3),
Fehler (0.2) }T = {t0.0→0.1, t0.1→0.3, t0.3→0.2, t0.3→0.1}R = {cDruckRegler}W
Bild B.1.: Anwendungsbeispiel zur Erlauterung des Algorithmus.
138
Entwicklung des Algorithmus 5.1
1. Durchlauf
Zeile 7 s0 = Initial
Zeile 8 k0 = s0
Zeile 9 false
Zeile 10 visited = {s0}Zeile 13 k1 = t.target = Ausgeschaltet
Zeile 15 queue = {(Initial, k0), (Ausgeschaltet, k1)}2. Durchlauf
Zeile 7 s1 = Ausgeschaltet
Zeile 8 k1 = s1
Zeile 9 false
Zeile 10 visited = {s0, s1}Zeile 13 k2 = t.target = Eingeschaltet
Zeile 15 queue = {(Initial, k0),(Ausgeschaltet, k1),
(Eingeschaltet, k2)}3. Durchlauf
Zeile 7 s2 = Eingeschaltet
Zeile 8 k2 = s2
Zeile 9 false
Zeile 10 visited = {s0, s1, s2}Zeile 11 T = {t0.3→0.1, t0.3→0.2}Zeile 13.1 k3 = t.target = Ausgeschaltet
Zeile 15.1 queue = {(Initial, k0),(Ausgeschaltet, k1),
(Eingeschaltet, k2), (Ausgeschaltet, k3)}Zeile 13.2 k4 = t.target = Fehler
Zeile 15.2 queue = {(Initial, k0),(Ausgeschaltet, k1),
(Eingeschaltet, k2), (Ausgeschaltet, k3), (Fehler, k4)}
139
Abbildungsverzeichnis
2.1. Aufbau von Steuergeratesoftware. . . . . . . . . . . . . . . . 23
2.2. Softwaretestprozesses im Softwareentwicklungsprozess. . . . 24
2.3. Beispiel fur ein Klassendiagramm. . . . . . . . . . . . . . . . 32
2.4. Die vier Ebenen der MOF. . . . . . . . . . . . . . . . . . . . 35
2.5. Vereinfachtes Meta-Meta Modell des EMF. . . . . . . . . . . 36
2.6. Entwicklungslandschaft fur Steuergeratesoftware. . . . . . . 38
2.7. Klassfizierung der Testfallerstellungsmethoden. . . . . . . . . 41
2.8. Sichten auf das Testobjekt . . . . . . . . . . . . . . . . . . . 42
2.9. Kontrollflussgraph . . . . . . . . . . . . . . . . . . . . . . . 44
2.10. Ordnungsgraph . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.11. Aquivalenzklassen und Grenzwerte. . . . . . . . . . . . . . . 49
2.12. Visualisierung der Kombinatorik im Datenraum. . . . . . . . 50
2.13. Eingabe-Datenpunkte durch ein orthogonales Feld. . . . . . 54
2.14. Visualisierung der minimalen Auswahlstrategie. . . . . . . . 56
2.15. Unterschiedliche Testabstraktionsschichten. . . . . . . . . . . 59
3.1. Technologische Realisierung des Testframeworks. . . . . . . . 64
3.2. Das Meta-Modell der Testspezifikation. . . . . . . . . . . . . 66
3.3. Anwendung von Auswahlstrategien in dem TS-MM. . . . . . 68
3.4. Der Testbericht als Teilaspekt der Testbeschreibung. . . . . 69
4.1. Hydraulisches Schaltgerat. . . . . . . . . . . . . . . . . . . . 74
4.2. Druck-Strom-Kennlinie des Moduls Druckregler (DR). . . . . 74
4.3. Ubergeordnete Regelung . . . . . . . . . . . . . . . . . . . . 75
4.4. Klassendiagramm des Softwaremoduls Druckregler. . . . . . 77
4.5. Verhaltensbeschreibung des Softwaremoduls Druckregler . . 78
4.6. Aufbau des verwendeten Unit-Test-Frameworks. . . . . . . . 79
5.1. Integration der Heuristik zum Testentwurf . . . . . . . . . . 81
5.2. Prinzip der automatischen Testsequenzgenerierung. . . . . . 82
5.3. Interpretation eines hierarchischen Zustandes. . . . . . . . . 86
5.4. Orthogonalitat. . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.5. Aufbau des Exchange-Meta-Modells. . . . . . . . . . . . . . 93
140
5.6. Instanziierung des Exchange-Meta-Modells. . . . . . . . . . . 95
5.7. Darstellung der Bedatunskombinationen Bmin. . . . . . . . . 99
5.8. Visualisierung der Initialpfadsuche. . . . . . . . . . . . . . . 100
5.9. Ausgangspunkt fur die Transitionsuberdeckung. . . . . . . . 102
5.10. Meta-Modell des Ubergangsbaumes. . . . . . . . . . . . . . . 103
5.11. Fur den Teilgraphen EM1 berechneter Ubergangsbaum. . . . 104
5.12. Orthogonale Bereiche des Zustandes Eingeschaltet. . . . 109
5.13. Bedeutung orthogonaler Zustande fur den Test. . . . . . . . 110
5.14. Zusammenfassung der Transitionsfolgen. . . . . . . . . . . . 114
5.15. Superzustande in der Testspezifikation. . . . . . . . . . . . . 118
5.16. Design des Unit-Tests fur die Klasse cDruckRegler. . . . . . 119
6.1. Benutzeroberflache des Testframeworks. . . . . . . . . . . . . 124
6.2. Beispiel fur das Einbinden des CTE-XL in das Testframework.126
6.3. Anwendung der Heuristik am SiL. . . . . . . . . . . . . . . . 128
B.1. Anwendungsbeispiel zur Erlauterung des Algorithmus. . . . 138
141
Tabellenverzeichnis
2.1. Uberblick zu den Auswahlstrategien. . . . . . . . . . . . . . 57
5.1. Auswahl einer Testsequenzgenerierungsstrategie. . . . . . . . 84
5.3. Erlauterung der Verhaltensspezifikation. . . . . . . . . . . . 90
5.4. Relationen zwischen den Modellelementen. . . . . . . . . . . 91
5.5. UML-Profil zur Steuerung der Testsequenzerstellung. . . . . 92
5.6. Zusammenfassung der strukturellen Aspekte. . . . . . . . . . 114
5.7. Zuordnung von Struktur und Bedatung zu dem TS-MM. . . 115
142
Liste der Algorithmen
5.1. Algorithmus zur Berechnung der Transitionsuberdeckung. . . 103
5.2. Vervollstandigung der Transitionsfolgen. . . . . . . . . . . . . 105
5.3. Superzustand: Hinzufugen von Transitionen. . . . . . . . . . . 107
5.4. Sequenzierung orthogonaler Transitionsfolgen. . . . . . . . . . 113
5.5. Bedatung von Testsequenzen. . . . . . . . . . . . . . . . . . . 117
-. Funktion splitGraph(start,end) . . . . . . . . . . . . . . . . . 134
-. Funktion findLocalPath(EM , path,start,end) . . . . . . . . . 136
-. Funktion relaxe(EM , start, queue, distance, previous, visited) 137
143
Literaturverzeichnis
[1] www.openarchitectureware.com.
[2] www.pairwise.org.
[3] ATML. http://grouper.ieee.org/groups/scc20/tii/index.htm.
[4] Conformiq. http://www.conformiq.com/.
[5] CppUnit. http://sourceforge.net/projects/cppunit/.
[6] Eclipse. http://www.eclipse.org/.
[7] Grundlagen der Automatikgetriebe - Ein interaktives Lernprogramm.
http://www.rolandschule.de/mit6.htm.
[8] Herstellerinitiative Software. www.automovie-his.de.
[9] Leirios - Smarttesting. http://www.smartesting.com.
[10] Alain Abran und James W. Moore, (Hrsg.). SWEBOOK - Guide to
Software Engineering Body of Knowledge. IEEE Computer Society,
2004.
[11] Chuck Allison. The simplest automated unit-test framework that
could possibly work. Dr. Dobb’s Portal, 2003.
[12] MISRA The Motor Industry Software Reliability Association. Gui-
delines for the use of the C language in vehicle based software.
www.misra.org.uk, 1998.
[13] Heide Balzert. UML 2 in 5 Tagen. w3L, 2005.
[14] Helmut Balzert. Lehrbuch der Software-Technik. Spektrum Akademi-
scher Verlag, 1998.
[15] Michael Barr. Programming Embedded Systems in C and C++.
O’Reilly, 1999.
[16] Robert V. Binder. Testing Object-Oriented Systems Models, Patterns,
and Tools. Addison Wesley, 1999.
144
[17] Kirill Bogdanov. Automated Testing of Harels Statecharts. Doktorar-
beit, University of Sheffield, 2000.
[18] R. C. Bose. On the application of the properties of galois fields to the
construction of hyper graeco-latin squares. Sankhya, 3:323–338, 1938.
[19] Michael Brost. Automatisierte Testfallerzeugung auf Grundlage einer
zustandsbasierten Funktionsbeschreibung fur Kraftfahrzeugsteuergera-
te. Doktorarbeit, Universitat Stuttgart, 2008.
[20] Michael Brost, Gerd Baumann und Hans-Christian Reuss. UML-
basierte Testfallerzeugung fur Karosseriesteuergerate. In Clemens
Guhmann, (Hrsg.), Simulation und Test in der Funktions- und Soft-
wareentwicklung fur die Automobilelektronik II. Expert-Verlag, 2008.
[21] Colin Campbell, Wolfgang Grieskamp, Lev Nachmanson, Wolfram
Schulte, Nikolai Tillmann und Margus Veanes. Model-Based Testing
of Object-Oriented Reactive Systems with Spec Explorer. Microsoft
Research, 2005.
[22] Conformiq. Conformiq Qtronic SG - Semantics and Algorithms for
Test Generation. Conformiq Software Ltd., 2008.
[23] Hansjorg Dach, Wolf-Dieter Gruhle und Peter Kopf. Pkw-
Automatgetriebe. In Bibliothek der Technik, Band 88. Verlag Moderne
Industrie, 2001.
[24] Daimler. CTE-XL. www.systematic-testing.com.
[25] Christof Ebert und Reiner Dumke. Software-Metriken in der Praxis.
Springer Verlag, 1996.
[26] Sven Efftinge, Peter Friese, Arno Haase, Dennis Hubner, Clemens Ka-
dura, Bernd Kolb, Jan Kohnlein, Dieter Moroff, Karsten Thoms, Mar-
kus Volter, Patrick Schonbach, Moritz Eysholdt, Dennis Hubner und
Steven Reinisch. openarchitectureware user guide version 4.3.1, 2008.
[27] William J. Gilbert. Modern Algebra with Applications. John Wiley &
Sons, 1976.
[28] M. R. Girgis und M. R. Woodward. An experimental comparison of
the error exposing ability of program testing criteria. In Workshop
Software Testing, 1986.
145
[29] Matthias Grochtmann, Klaus Grimm und Joachim Wegener. Tool-
supported test case design for black-box testing by means of the
classification-tree editor. European Int. Conf. on Software Testing,
Analysis and Review (EuroStar ’93), 1:169–176, 1993.
[30] Jurgen Großmann. Integration von Testsprachen und Werkzeugen.
In 1. AutoTest Fachkonferenz: Test von Hard- und Software in der
Automobilentwicklung. FKFS, 25. - 26. Oktober 2006.
[31] David Harel. A visual formalism for complex systems. Science of
Computer Programming, 8(3):231–274, June 1987.
[32] Dirk W. Hoffmann. Software-Qualitat. Springer Verlag, 2008.
[33] Wolfhard Lawrenz. CAN Controller Area Network - Grundlagen und
Praxis, volume 5. Huthig, 2007.
[34] Eckard Lehmann. Time Partition Testing - Systematischer Test des
kontinuierlichen Verhaltens von eingebetteten Systemen. Doktorar-
beit, Universitat Berlin, 2003.
[35] Peter Liggesmeyer. Software-Qualitat. Spektrum Akademischer Verlag
Heidelberg Berlin, 2002.
[36] Heiko Lotzbeyer. Modellbasierte Testfallermittlung fur eingebettete
Systeme in sicherheitskritischen Anwendungen. Doktorarbeit, Uni-
versitat Munchen, 2003.
[37] Markus Muller, Klaus Hormann, Lars Dittmann und Jorg Zimmer.
Automotive SPICE in der Praxis. dpunkt.verlag, 2007.
[38] Bernd Oestereich. Analyse und Design mit UML 2.1. Objektorientierte
Softwareentwicklung. Oldenbourg, 2006.
[39] Norbert Oster. Automatische Generierung optimaler struktureller
Testdaten fur objekt-orientierte Software mittels multi-objektiver Me-
taheuristiken. Doktorarbeit, Friedrich-Alexander-Universitat Erlan-
gen-Nurnberg, Erlangen, 2007.
[40] Carsten Paulus, Michael Wolff, Peter Feulner und Hans-Christian
Reuss. Ein neues Framework zum Testen von Kfz-Steuergerate-
Software. In 2. AutoTest Fachkonferenz: Test von Hard- und Software
in der Automobilentwicklung, 22. - 23. Oktober 2008.
146
[41] Carsten Paulus, Michael Wolff und Hans-Christian Reuss. Strategien
zur Testfallgenerierung aus UML-Zustandsautomaten. In Haus der
Technik: Tagung Hardware-in-the-Loop-Simulation, September 2008.
[42] Madhav S. Phadke. Quality Engineering Using Robust Design. Pren-
tice Hall, 1989.
[43] Madhav S. Phadke. Planning Efficient Software Tests. www.phadke-
associates.com, 2010.
[44] Alexander Pretschner. Zum modellbasierten funktionalen Test reakti-
ver Systeme. Doktorarbeit, Universitat Munchen, 2003.
[45] Eric T. Ray. Einfuhrung in XML. O’Reilly, 2004.
[46] Eike Hagen Riedemann. Testmethoden fur sequentielle und nebenlau-
fige Software- Systeme. Vieweg + Teubner, 1998.
[47] Jorg Schauffele und Thomas Zurawka. Automotive Software Enginee-
ring. Vieweg Verlag, 2003.
[48] Carsten Sensler, Michael Kunz und Peter Schnell. Testautomatisie-
rung mit modellgetriebener Testskript-Entwicklung. Objektspektrum,
03, 2006.
[49] Thomas Stahl und Markus Volter. Modellgetriebene Softwareentwick-
lung. dpunkt.verlag, 2005.
[50] Dave Steinberg, Frank Budinsky, Marcelo Paternostro und Ed Merks.
EMF Eclipse Modeling Framework. Addison Wesley, 2008.
[51] Manfred Broy und Ralf Steinbruggen. Modellbildung in der Informa-
tik. Springer Verlag, 2004.
[52] Andreas Spillner und Thilo Linz. Basiswissen Softwaretest. dpunkt.-
verlag, 2007.
[53] Krzysztof Czarnecki und Ulrich W. Eisenecker. Generative Program-
ming: Methods, Tools, and Applications. Addison Wesley, 2000.
[54] Mark Utting und Bruno Legeard. Practical Model-Based Testing. Mor-
gan Kaufmann, 2007.
[55] Frank Westphal. Testgetriebene Entwicklung mit JUnit und FIT: Wie
Software anderbar bleibt. dpunkt.verlag, 2005.
147
[56] Alan W. Williams. Determination of test configurations for pair-wise
interaction coverage. In IFIP TC6/WG6.1 13th International Confe-
rence on Testing Communicating Systems (Test-Com 2000), pp. 59-
74, 2000.
148
Lebenslauf
Personliche Daten
Name Carsten Paulus
Geburtsdatum 24.11.1978
Geburtsort Stuttgart
Familienstand verheiratet
Schulbildung
1985 - 1989 Altenburg Grundschule, Stuttgart-Bad Cannstatt
1989 - 1998 Johannes Kepler Gymnasium, Stuttgart-Bad Cann-
statt
1998 Abitur
Zivildienst
1998 - 1999 Zivildienst im Rettungsdienst des Deutschen Roten
Kreuzes Stuttgart
Studium
1999 - 2005 Studium des Maschinenwesens an der Universitat
Stuttgart
21.12.2005 Abschluss als Diplom-Ingenieur
Berufstatigkeit
seit 2006 Wissenschaftlicher Mitabeiter am Forschungs-
institut fur Kraftfahrwesen und Fahrzeugmotoren
Stuttgart (FKFS)
seit 2009 Entwicklungsingenieur bei der ZF Friedrichshafen
AG
149
Recommended