Testmustergenerierung mit Hilfe von ... - ihmor.de

Testmustergenerierung mit Hilfe von
Wahrscheinlichkeitsverteilungen im
Rahmen des modellbasierten Tests
eingebetteter Systeme
Diplomarbeit
von
Oliver Fick
Fakultät V für Elektrotechnik, Informatik und Mathematik
Institut für Informatik
Universität Paderborn
Juni 2005
Erstbetreuer: Dr. Klaus Lamberg (dSPACE GmbH)
Zweitbetreuer: Stefan Ihmor (Universität Paderborn)
Erstprüfer: Prof. Dr. rer. nat. Franz Josef Rammig
Zweitprüfer: Prof. Dr. rer. nat. habil. Odej Kao

Kurzfassung
Kurzfassung
Im modellbasierten Entwicklungsprozess eingebetteter Systeme kommen vermehrt Techniken
zur automatischen Erstellung von Tests zum Einsatz. Die auf Zufall basierenden
Verfahren haben Nachteile bezüglich der Effizienz während der Generierung von Testdaten
und der Qualität der erzeugten Testmuster. Die vorliegende Arbeit liefert eine
Methodik, welche dem Testentwickler die Möglichkeit zur Steuerung zufallsbasierter
Testmustergenerierung mithilfe von Wahrscheinlichkeitsverteilungen bietet. Dadurch ist es
dem Anwender des Verfahrens möglich, gezielt Testdaten für Systembereiche zu generieren,
welche durch das allgemeine auf Zufall basierte Verfahren nicht abgedeckt werden.
Das entwickelte Verfahren wurde im Rahmen dieser Arbeit prototypisch umgesetzt,
wodurch eine Evaluierung der Methodik ermöglicht wurde. Diese zeigt, dass der Aufwand
der Testerstellung sowie der Testdurchführung durch Anwendung der entwickelten
Methodik stark verringert werden kann. Zusätzlich wurde die Qualität der erzeugbaren
Testmuster derart gesteigert, dass diese nahezu die Qualität manuell erstellter Testmuster
erreichen.
Abstract
Techniques for automatic test pattern generation are increasingly applied in the modelbased
development process of embedded systems. Random-based methods have disadvantages
in respect of efficiency during the generation process of test data and in terms of
quality of generated test patterns. In this diploma thesis, a methodology is presented,
allowing the developer to control the random-based generation process of test patterns by
dint of probability distributions. Using this methodology, test patterns for those system
areas not covered by the generic random-based method can be obtained automatically. The
developed method is prototypically implemented in the context of this thesis, permitting its
evaluation. Evaluation results show that effort for test data creation and test execution can
be significantly reduced by applying the outlined technique. Additionally, it increases the
quality of generated test patterns almost to the level of manually created ones.
i

Danksagung und Eigenständigkeitserklärung
Danksagung
Dieses Dokument entstand im Rahmen einer Diplomarbeit in Kooperation der Arbeitsgruppe
Rammig der Universität Paderborn und der dSPACE GmbH. Für das interessante
Diplomarbeitsthema möchte ich mich im Besonderen bei Prof. Dr. rer. nat. Franz J.
Rammig bedanken. Ebenfalls danke ich Prof. Dr. rer. nat. habil. Odej Kao für die Übernahme
des zweiten Gutachtens. Besonderer Dank gilt meinem Betreuer Dr.-Ing. Klaus
Lamberg bei der dSPACE GmbH, durch dessen Engagement diese Arbeit überhaupt möglich
wurde. Ihm und meinem Betreuer Stefan Ihmor von der Universität Paderborn gilt
besonderer Dank für die über den Zeitraum der Erstellung der Diplomarbeit andauernde
fachliche und persönlich engagierte Betreuung. Meinen ehemaligen Kollegen Holger
Krisp, Jürgen Klahold, Dirk Jegminat, Stefan Heidloff, Ulrich Eisemann und Otto Linnemann
in der Abteilung Produktmanagement der dSPACE GmbH möchte ich für ihre
Unterstützung und die kollegiale Arbeitsatmosphäre danken, die mir bei der Erarbeitung
des Themas sehr geholfen haben. Nicht zuletzt möchte ich Catrin Trautmann für das intensive
Korrekturlesen dieser Arbeit danken.
Paderborn, im Juni 2005
Oliver Fick
Eigenständigkeitserklärung
Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig verfasst und keine
anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich
gemacht habe.
Paderborn, den 28. Juni 2005
Oliver Fick
ii

Inhaltsverzeichnis
Inhaltsverzeichnis
1 EINLEITUNG .............................................................................1
1.1 Motivation ............................................................................................................1
1.2 Aufgabenstellung .................................................................................................1
1.3 Gliederung............................................................................................................2
2 MODELLBASIERTE ENTWICKLUNG EINGEBETTETER
SYSTEME..................................................................................3
2.1 Eingebettete Systeme...........................................................................................3
2.2 Entwicklungsprozess nach dem V-Modell ........................................................3
2.3 Grafische Modellierung in MATLAB................................................................6
2.3.1 Blockdiagramme in Simulink..............................................................................6
2.3.2 Zustandsdiagramme in Stateflow........................................................................7
3 MODELLBASIERTES TESTEN ..............................................11
3.1 Grundlagen.........................................................................................................11
3.1.1 Der Systembegriff .............................................................................................11
3.1.2 Grundbegriffe beim Testen ...............................................................................12
3.1.3 Der Testprozess.................................................................................................18
3.2 Prüfmethoden.....................................................................................................19
3.2.1 Verifikation und Validierung ............................................................................19
3.2.2 Statische Prüfverfahren .....................................................................................21
3.2.3 Dynamische Prüfverfahren................................................................................21
3.2.4 Spezielle Testarten ............................................................................................22
3.3 Abdeckung von Strukturmerkmalen...............................................................23
3.3.1 Bemerkung ........................................................................................................24
3.3.2 Kontrollflussgraph.............................................................................................25
3.3.3 Abdeckungskriterium und Abdeckungsgrad.....................................................26
3.3.4 Codeabdeckung .................................................................................................27
3.3.4.1 Anweisungsabdeckung ...................................................................................27
3.3.4.2 Zweigabdeckung.............................................................................................27
3.3.4.3 Bedingungsabdeckung ....................................................................................28
3.3.4.4 Pfadabdeckung................................................................................................32
3.3.5 Modellabdeckung..............................................................................................32
3.3.5.1 Zustandsabdeckung.........................................................................................32
iii

Inhaltsverzeichnis
3.3.5.2 Zweigabdeckung ............................................................................................ 32
3.3.5.3 Bedingungsabdeckung.................................................................................... 33
3.3.6 Bemerkungen.................................................................................................... 33
3.4 Methoden zur Testfallerstellung...................................................................... 34
3.4.1 Klassifikationsbaummethode............................................................................ 35
3.4.2 Zufallsbasierte Testmustergenerierung zur Strukturabdeckung ....................... 37
3.4.3 Testmustergenerierung mit Evolutionären Algorithmen .................................. 38
3.4.4 Analytische Testmustergenerierung ................................................................. 40
3.4.5 Fehlermodelle im Hardwaretest........................................................................ 41
3.5 Kommerzielle Anwendungen zur Testfallerstellung...................................... 44
3.5.1 Klassifikationsbaumeditor (CTE)..................................................................... 44
3.5.2 Reactis............................................................................................................... 45
3.5.3 MOTCase-X ..................................................................................................... 46
4 TESTMUSTERGENERIERUNG MIT HILFE VON
WAHRSCHEINLICHKEITSVERTEILUNGEN ........................ 47
4.1 Zufallbasierte Testmustergenerierung............................................................ 49
4.1.1 Erweiterung des bearbeiteten Testmusters ....................................................... 50
4.1.2 Evaluierung des Testmusters ............................................................................ 52
4.1.3 Auswertung der Evaluierung ............................................................................ 53
4.1.4 Fortsetzen oder Beenden der Generierung ....................................................... 54
4.2 Steuerung des Zufallprozesses mit Wahrscheinlichkeitsverteilungen ......... 56
4.2.1 Diskrete Eingangssignale.................................................................................. 56
4.2.2 Analoge Modelleingänge.................................................................................. 58
4.2.2.1 Diskretisierung des Wertebereichs................................................................. 59
4.2.2.2 Kontinuierlicher Wertebereich....................................................................... 61
5 IMPLEMENTIERUNG DES TESTFALLGENERATORS ........ 63
iv
5.1 Das Hauptprogramm: TestCaseCommander ................................................ 64
5.2 Die Hauptdialoge............................................................................................... 66
5.2.1 Interface Parameter Editor................................................................................ 66
5.2.2 Input Editor....................................................................................................... 67
5.2.3 Weight Editor.................................................................................................... 69
5.2.4 Probability Density Function Editor................................................................. 69
5.2.5 Generation Status.............................................................................................. 70
5.3 Das Verfahren zur Testmustergenerierung.................................................... 71

Inhaltsverzeichnis
5.4 Weitere Softwarekomponenten ........................................................................72
5.4.1 Reporter.............................................................................................................72
5.4.2 cvsim .................................................................................................................73
5.4.3 cvhtml................................................................................................................73
5.5 Die Testumgebung .............................................................................................73
6 EVALUIERUNG DES TESTMUSTERGENERATORS............75
6.1 Beispielmodell Automat_diskret ...............................................................75
6.2 Beispielmodell Automat_analog ................................................................78
6.3 Beispielmodell Kaffeeautomat..........................................................................81
6.3.1 Modellierung der Funktionalität........................................................................81
6.3.2 Verwendete Wahrscheinlichkeitsverteilungen..................................................84
6.3.3 Ergebnisse der Testmustergenerierung .............................................................86
6.4 Bewertung...........................................................................................................89
7 ZUSAMMENFASSUNG UND AUSBLICK ..............................93
7.1 Zusammenfassung .............................................................................................93
7.2 Ausblick ..............................................................................................................94
8 LITERATURVERZEICHNIS.....................................................95
ANHANG ............................................................................................99
A Grundlagen der Wahrscheinlichkeitsrechnung........................................................99
v

Abbildungsverzeichnis
Abbildungsverzeichnis
Abbildung 2-1: V-Modell...................................................................................................... 4
Abbildung 2-2: Entwicklungsmodelle im V-Modell [Schl et al. 04] .................................... 5
Abbildung 2-3: Grundblöcke in Simulink............................................................................. 7
Abbildung 2-4: Blöcke zur Behandlung des Kontrollflusses in Simulink ............................ 7
Abbildung 2-5: Bestandteile eines Statecharts in Stateflow.................................................. 8
Abbildung 2-6: Parallelität in Zustandsautomaten ................................................................ 9
Abbildung 3-1: Implementierungsmodell als Testobjekt .................................................... 13
Abbildung 3-2: Zusammenhang von Testziel, Testbasis und Testfallerstellung................. 14
Abbildung 3-3: Struktur eines Testmusters......................................................................... 17
Abbildung 3-4: Testfall ....................................................................................................... 17
Abbildung 3-5: Testdurchführung, Monitoring und Testauswertung ................................. 18
Abbildung 3-6: Klassifikationsschema nach Liggesmeyer [Lig02, S. 34].......................... 20
Abbildung 3-7: Strukturtestverfahren (White-Box-Test) .................................................... 21
Abbildung 3-8: Funktionstest (Black-Box-Test)................................................................. 22
Abbildung 3-9: Back-to-Back-Test ..................................................................................... 23
Abbildung 3-10: Programmbeispiel in C............................................................................. 24
Abbildung 3-11: C-Funktion maximum mit zugehörigem Kontrollflussgraphen (rechts) .. 26
Abbildung 3-12: Modifizierte C-Funktion maximum mit Kontrollflussgraphen ................ 28
Abbildung 3-13: Beispiel in Simulink zur Zweigabdeckung .............................................. 33
Abbildung 3-14: Beispiel in Stateflow zur Bedingungsabdeckung..................................... 33
Abbildung 3-15: Modell zur Berechnung des Maximums von drei Werten ....................... 34
Abbildung 3-16: Klassifikationsbaum und Kombinationstabelle ....................................... 36
Abbildung 3-17: Zufallsbasierte Testmustergenerierung .................................................... 37
Abbildung 3-18: Ablauf eines Evolutionären Algorithmus [Sth et al. 01], [Weg02] ......... 39
Abbildung 3-19: Propagierung von Wertebereichen [Her05] ............................................. 40
Abbildung 3-20: Haftfehler-Modell an einem AND-Gatter [VieMis04] ............................ 42
Abbildung 3-21: Fehlerpropagierung [Mol02].................................................................... 43
Abbildung 3-22: Klassifikationsbaumeditor ....................................................................... 45
Abbildung 3-23: Beispielsystem ......................................................................................... 46
Abbildung 4-1: Kombination manueller und automatischer Testmustergenerierung ......... 47
Abbildung 4-2: Testmustergenerierung mithilfe von Wahrscheinlichkeitsverteilungen..... 50
Abbildung 4-3: Erzeugung von Eingabedaten..................................................................... 51
Abbildung 4-4: Erzeugen eines Testmusters (Akzeptieren / Verwerfen)............................ 53
vi

Abbildungsverzeichnis
Abbildung 4-5: Notwendigkeit langer Sequenzen ...............................................................54
Abbildung 4-6: Notwendigkeit mehrerer Testmuster ..........................................................55
Abbildung 4-7: Beispielmodell Automat_diskret .......................................................57
Abbildung 4-8: Beispielmodell Automat_analog .........................................................59
Abbildung 4-9: Diskretisierung............................................................................................60
Abbildung 4-10: Beispiel einer Wahrscheinlichkeitsdichte.................................................62
Abbildung 5-1: Softwarestruktur des TestCaseCommanders ..............................................63
Abbildung 5-2: Hauptfenster des TestCaseCommanders ....................................................64
Abbildung 5-3: Interface Parameter Editor..........................................................................67
Abbildung 5-4: Input Editor.................................................................................................68
Abbildung 5-5: Input Editor (analog) ..................................................................................68
Abbildung 5-6: Weight Editor .............................................................................................69
Abbildung 5-7: Probability Density Function Editor...........................................................70
Abbildung 5-8: Generation Status........................................................................................71
Abbildung 5-9: Abdeckungsreport.......................................................................................72
Abbildung 5-10: Einbetten des Testobjekts in die Testumgebung ......................................74
Abbildung 6-1: Beispielmodell Automat_diskret .......................................................75
Abbildung 6-2: Beispielmodell Automat_analog .........................................................79
Abbildung 6-3: Kontinuierliche Wahrscheinlichkeitsdichte................................................79
Abbildung 6-4: Beispielmodell Kaffeeautomat ...................................................................82
Abbildung 6-5: Subsystem Zentrale_Steuerung ..................................................................84
Abbildung 6-6: Wahrscheinlichkeitsdichten für Spannung .................................................85
Abbildung 6-7: Abdeckungsreport mit der Gleichverteilung ..............................................87
Abbildung 6-8: Modifiziertes Beispielmodell Automat_analog...................................89
Abbildung 6-9: Verbesserungspotenzial des gesteuerten Verfahrens..................................91
vii

Tabellenverzeichnis
Tabellen- und Abkürzungsverzeichnis
Tabelle 3-1: Wahrheitswertekombinationen für (a > b && a > c) ...................................... 29
Tabelle 3-2: Wahrheitswertekombinationen für (b > a && b > c)...................................... 29
Tabelle 4-1: Beispiele für diskrete Wahrscheinlichkeitsverteilungen................................. 57
Tabelle 6-1: Gewählte Wahrscheinlichkeitsverteilungen.................................................... 76
Tabelle 6-2: Ergebnisse mit Beispielmodell Automat_diskret................................... 77
Tabelle 6-3: Ergebnisse mit Beispielmodell Automat_analog ..................................... 81
Tabelle 6-4: Wahrscheinlichkeitsverteilungen für Muenzeinwurf....................................... 85
Tabelle 6-5: Wahrscheinlichkeitsverteilungen für Geldrueckgabe ..................................... 85
Tabelle 6-6: Wahrscheinlichkeitsverteilungen für Auswahl................................................ 85
Tabelle 6-7: Ergebnisse mit Gleichverteilung ..................................................................... 88
Tabelle 6-8: Abhängigkeit der Testmusterlänge von den Übergangsbedingungen............. 90
Abkürzungsverzeichnis
ATG
Automatischer Testmustergenerator
CTE/ES
Klassifikationsbaumeditor für eingebettete Systeme
(Classification Tree Editor for Embedded Systems)
CTM
Klassifikationsbaummethode
(Classification Tree Method)
GUI
Graphische Benutzeroberfläche
(Graphical User Interface)
MC/DC
Modifizierte Mehrfach-Bedingungsabdeckung
MC/DC-Abdeckung
(Modified Condition / Decision Coverage)
UML
Unified Modeling Language
viii

1 Einleitung
1.1 Motivation
In heutigen elektrotechnischen Produkten sind häufig mikroelektronische Steuerungs- und
Überwachungssysteme, so genannte eingebettete Systeme, integriert. Diese bestehen
hauptsächlich aus für ihre Aufgabe spezialisierter Hardware und für diese Hardware optimierter
Software. Ihr Einsatz erfolgt in zunehmendem Maße in den unterschiedlichsten
Bereichen der Technik und reicht von einfachen Systemen wie dem Fensterheber in Autos
bis hin zu komplexen Überwachungssystemen in Flugzeugen. Die stetig steigende Komplexität
dieser hybriden Systeme aus Soft- und Hardware erfordert von Herstellern und
Zulieferern in zunehmendem Maße die Steigerung des Qualitätssicherungsaufwandes, der
zu höheren Entwicklungszeiten und damit verbundenen Kostensteigerungen führt. Da
Produkte aufgrund ihrer Komplexität heutzutage kaum noch ausreichend manuell getestet
werden können, kommen vermehrt automatische Testerstellungsverfahren zum Einsatz.
Die Anwendung automatischer Methoden erfolgt zunehmend auch im modellbasierten
Entwicklungsprozess eingebetteter Systeme, da in diesem bereits in frühen Phasen der Produktentstehung
aus einer Modellrepräsentation des Systems Testmuster zur Überprüfung
des später entwickelten Programmcodes erzeugt werden können. Die in dieser Arbeit
zentral betrachteten Verfahren zur zufallsbasierten Testmustergenerierung haben
Schwächen hinsichtlich ihrer Effizienz bei der Erzeugung und der Qualität der erzeugbaren
Testmuster, da die Generierung von Testdaten eher unstrukturiert erfolgt. Der Schwerpunkt
der Diplomarbeit liegt in der Entwicklung einer Methodik, mit der die automatische
zufallsbasierte Generierung von Testdaten durch einen Anwender gesteuert werden kann.
1.2 Aufgabenstellung
Die in dieser Arbeit zu entwickelnde Methodik soll dem Testentwickler die Möglichkeit
bieten, durch Vorgabe von diskreten und stetigen Wahrscheinlichkeitsverteilungen den
Prozess der Testdatenerzeugung, bezogen auf die zu testenden Systemteile, zu beeinflussen.
Das zu entwerfende Verfahren dient vor allem dazu, alle Bedingungen, die an die
erzeugten Tests gestellt werden, auf effiziente Weise zu erfüllen. Dazu zählt neben einer
möglichst kurzen Testdurchführung auch die Zeit sparende, effiziente Generierung der
Testmuster.
Das Ziel dieser Arbeit ist die Implementierung eines Testmustergenerators, der für den
modellbasierten Test eingebetteter Systeme zufallsbasiert Eingabe- und Referenzdaten aus
MATLAB-Modellen [MATLAB] erzeugt. Der Testmustergenerator soll zur Umsetzung
der entwickelten Methodik zur Testmustergenerierung über eine Schnittstelle verfügen,
über die der Testentwickler mithilfe von Wahrscheinlichkeitsverteilungen Einfluss auf die
Testmustergenerierung nehmen kann.
1

1.3. Gliederung
Es ist durch eine Analyse zu zeigen, wieweit auf Zufall basierende Testmustergeneratoren
bei Anwendung des entwickelten Verfahrens gezielt in Problembereiche geführt werden
können. Die Evaluierung des Verfahrens soll anhand des implementierten Testmustergenerators
erfolgen.
1.3 Gliederung
Einleitend geht die Diplomarbeit in Kapitel 2 auf die modellbasierte Entwicklung eingebetteter
Systeme ein und ordnet sich in den Entwicklungsprozess nach dem V-Modell ein.
Das folgende Kapitel 3 führt die für diese Arbeit relevanten Begriffe im Umfeld des
modellbasierten Testens ein und stellt die wichtigsten Aktivitäten des Testprozesses vor.
An dieser Stelle wird auf verschiedene Testverfahren eingegangen, die sich im Softwareund
Hardwaretest etabliert haben. Nachfolgend bietet die Arbeit eine Übersicht von
Methoden zur modellbasierten Testfallgenerierung. Der Schwerpunkt liegt dabei auf den
Verfahren zur Erstellung strukturbasierter Tests, die im Gegensatz zu funktionalen Tests
anstelle der Funktionalität ausschließlich die Struktur des Systems berücksichtigen.
Kapitel 4 beschreibt die in dieser Arbeit entwickelte Methodik zur Steuerung der Testmustergenerierung
mithilfe von Wahrscheinlichkeitsverteilungen. An dieser Stelle wird
zwischen analogen und digitalen Eingabeschnittstellen und der daraus resultierenden unterschiedlichen
Behandlung im Verfahren differenziert.
Im fünften Kapitel wird die Implementierung der theoretischen Methodik erläutert. Dabei
wird auf die durch graphische Oberflächen erzeugten Möglichkeiten zur Angabe von
Wahrscheinlichkeitsverteilungen durch den Anwender eingegangen.
Die Evaluierung des entwickelten Verfahrens erfolgt anhand von ausgewählten Beispielmodellen
in Kapitel 6, welches die Vorteile des Verfahrens zur Steuerung der Generierung
von Testdaten mithilfe von Wahrscheinlichkeitsverteilungen herausstellt.
Eine Zusammenfassung mit angeschlossenem Ausblick auf mögliche Verbesserungen und
weiterführende Arbeiten schließen die Arbeit ab.
2

2 Modellbasierte Entwicklung eingebetteter Systeme
2.1 Eingebettete Systeme
In den vergangenen Jahren trat die Klasse der reaktiven Systeme in den Vordergrund, deren
Bezeichnung unter anderem von David Harel [HarPol98] geprägt wurde. Traditionelle
Softwaresysteme sind transformationelle Systeme. Dies bedeutet, dass sie Eingabedaten
einlesen, bearbeiten (transformieren), nach Abschluss dieses Prozesses terminieren und
eine Ausgabe liefern. Im Gegensatz dazu stehen reaktive Systeme in ständigem Wechselspiel
mit ihrer Umgebung. Insbesondere die Terminierung ihrer Ausführung ist nicht
gewünscht, was in der Regel zu einer unbeschränkten Laufzeit ohne Neustart führt
[Gol02].
Eine Form von reaktiven Systemen sind eingebettete Systeme. Diese sind durch eine
hybride Realisierung in Hard- und Software charakterisiert. Die Hardware ist dabei in der
Regel auf die Aufgaben des Systems optimiert, während die Software eine gewisse Flexibilität
gegenüber einem reinen Hardwaresystem ermöglicht, aber auf die begrenzten
Möglichkeiten der Hardware zugeschnitten ist. Eingebettete Systeme erfüllen häufig
Aufgaben zur Steuerung, Regelung und Überwachung (Steuergeräte im Automobilbereich),
wodurch eine fortlaufende Interaktion mit ihrer Umwelt mittels Sensoren,
Aktoren und Benutzerschnittstellen vorausgesetzt ist. Durch die im Prinzip unbeschränkte
Laufzeit eingebetteter Systeme müssen diese im Unterschied zu klassischen Daten verarbeitenden
Systemen ein spezielles Qualitätsmerkmal aufweisen: Ihre Korrektheit und
Ausfallsicherheit sind nicht nur abhängig vom Ein- und Ausgabeverhalten zu bestimmten
Zeitpunkten, sondern auch von dem Verhalten des Systems über einen längeren Zeitraum
hinweg [Con04].
2.2 Entwicklungsprozess nach dem V-Modell
Das V-Modell (Vorgehensmodell) ist der Entwicklungsstandard für IT-Systeme des
Bundes. Dieser wurde im Auftrag des Bundesministeriums für Verteidigung erstellt. Das
Bundesministerium des Inneren setzt es seit 1992 für den Bereich der Bundesverwaltung
ein. Das V-Modell wurde mit dem Ziel der Vereinheitlichung von Entwicklungen in der
Informationstechnik entwickelt und steht seit 1992 unter der Aufsicht der Koordinierungsund
Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung
[KBSt].
In Zusammenarbeit mit Verbänden von IT-Herstellern, Softwareentwicklern und Beratungsfirmen
wurde der Standard V-Modell 97 entwickelt und mit internationalen Normen
und Standards abgestimmt [VM97]. Es beschreibt ein Prozessmodell zum Planen und
Durchführen von Entwicklungsprojekten, um diese gemäß der Norm ISO 9001 abwickeln
zu können. Abbildung 2-1 zeigt die für diese Arbeit wichtigen Phasen des V-Modells in
3

2.2. Entwicklungsprozess nach dem V-Modell
Anlehnung an dessen Teilmodell Softwareerstellung [BröDrö93, S. 24], welches die
Aktivitäten während der Softwareerstellung festlegt. Entsprechende Testphasen sind den
einzelnen Entwicklungsphasen gegenübergestellt. In chronologischer Reihenfolge erfolgt
zuerst die Erstellung des Lastenheftes, welches die Kundenanforderungen beinhaltet. Die
damit verbundene Testphase ist die letzte Phase des Entwicklungsprozesses, der Systemtest.
Die aus dem Lastenheft erstellte Spezifikation des Funktionsumfangs (Pflichtenheft)
wird im dritten Entwicklungsschritt in Modulspezifikationen unterteilt, welche dann
während der Softwareerstellungsphase in separaten Einheiten implementiert werden. Im
Anschluss an die Softwareerstellung erfolgt der Modultest, der die Implementierung gegen
die Modulspezifikation testet. Nach einem Integrationsschritt, welcher die einzelnen
Module zusammenführt, erfolgt der Funktionstest als Testphase gegen das Pflichtenheft.
Im abschließenden Systemtest wird das gesamte System gegen die Kundenanforderungen
geprüft.
Kundenanforderungen
(Lastenheft)
Systemtest
Funktionsspezifikation
(Pflichtenheft)
Funktionstest
Modulspezifikation
Modultest
Softwareerstellung
Abbildung 2-1: V-Modell
Im modellbasierten Entwicklungsprozess wird bereits in frühen Phasen in der Beschreibungssprache
des verwendeten Modellierungs- und Simulationswerkzeuges sowohl ein
Modell der zu entwickelnden Software (Funktionsmodell), als auch eines des umgebenden
Systems (Streckenmodell) und dessen Umgebung (Umgebungsmodell) erstellt. Das
Funktionsmodell zeichnet sich dadurch aus, dass bereits zu einem frühen Zeitpunkt im
Entwicklungsprozess ein ausführbares Abbild des Produktes vorliegt, welches eingebettet
in das Modell seiner Umgebung simuliert werden kann. Auf diese Weise können komplexe
Systeme bereits vor der Entwicklung eines Prototypen und vor ihrem Einbau in ein reales
Umgebungssystem funktional und realitätsnah simuliert und getestet werden [Con04].
4

2. Modellbasierte Entwicklung eingebetteter Systeme
Das Funktionsmodell wird aus dem ursprünglichen Lasten- und Pflichtenheft systematisch
erzeugt. In ihm werden die Algorithmen realisiert, mit denen die geforderte Systemfunktionalität
erzielt wird. Es dient zusätzlich als Basis für alle weiteren konstruktiven und
analytischen Entwicklungsschritte. Zu diesen gehören unter anderem die Generierung oder
manuelle Programmierung ausführbaren Codes und die Testfallerstellung. In den einzelnen
Phasen der Entwicklung wird das Funktionsmodell schrittweise verfeinert. Während
anfänglich ein von der Zielplattform unabhängiges, physikalisches Modell erzeugt wird,
erfolgt im nächsten Entwicklungsschritt eine Überführung in ein plattformspezifisches
Implementierungsmodell. Dieses dient in der Softwareerstellungsphase als Spezifikation
zur Erzeugung zielplattformabhängigen Codes.
Kundenanforderungen
(Lastenheft)
Systemtest
Funktionsspezifikation
(Pflichtenheft)
Funktionsmodell
Funktionstest
Umgebungsmodell
Modulspezifikation
Implementierungsmodell
Modultest
Umgebungsmodell
Softwareerstellung
Generierter Code
Abbildung 2-2: Entwicklungsmodelle im V-Modell [Schl et al. 04]
Die Erstellung des Codes kann sowohl vollautomatisch, semi-automatisch oder vollständig
manuell erfolgen. Als ideal wird eine vollautomatische Generierung unter Verwendung
von Codegeneratoren wie beispielsweise TargetLink® [TargetLink] der dSPACE GmbH
[dSPACE] angesehen. Mithilfe von TargetLink kann Seriencode für Steuergeräte vollautomatisch
aus grafischen Simulinkmodellen erzeugt werden. Durch den Einsatz eines Codegenerators
können Änderungen am System – sei es aufgrund veränderter Anforderungen
oder entdeckter Fehler – direkt im Modell vorgenommen werden. Die automatische
Codegenerierung setzt ohne Einwirken des Entwicklers diese Änderungen direkt im Code
um. Eine aufwendige und kostenintensive manuelle Konsistenzhaltung von Modell und
Code in sämtlichen Schritten des Entwicklungsprozesses ist somit nicht notwendig. Ebenso
werden durch die automatische Codegenerierung Fehler in der Implementierungsphase
vermieden, wenn von einem fehlerfreien Codegenerator ausgegangen werden kann.
5

2.3. Grafische Modellierung in MATLAB
Die wesentlichen Vorteile des modellbasierten Entwicklungsprozesses sind Folgende:
Aufgrund der Verfügbarkeit einer simulierbaren Repräsentation des Systems ist eine Überprüfung
desselben auf Fehler bereits vor der Existenz eines realen Prototyps möglich. Die
abstraktere, grafische Beschreibung des Systems vereinfacht die Aktivitäten der Testentwickler,
da die erwähnten Modelle leichter verständlich als der zugehörige Quellcode sind.
Zusätzlich kann die Erstellung von Tests im Entwicklungsprozess zeitlich in frühere
Phasen verlegt werden und parallel zum Systementwurf erfolgen. Der entscheidende
Unterschied zur herkömmlichen Softwareentwicklung ist allerdings die Möglichkeit, aus
grafischen Modellen automatisch sowohl Quellcode als auch Testfälle erzeugen zu können.
Dies ermöglicht eine Zeitersparnis bei der Implementierung und Testfallerstellung und
reduziert zudem die Anzahl der Fehler, die bei manueller Umsetzung dieser Aktivitäten
auftreten würden.
2.3 Grafische Modellierung in MATLAB
Die in dieser Arbeit entwickelte Methodik zur automatischen Testmustergenerierung ist
eng verknüpft mit dem im vorherigen Abschnitt beschriebenen modellbasierten Entwicklungsprozess.
Aus einem Modell wird zur Überprüfung einer im Prozess später erzeugten
Systemrepräsentation eine Menge von Tests erzeugt. Bevor auf den Aspekt des Testens
und die Erstellung von Tests eingegangen wird, werden im Folgenden die hier verwendeten
Modellarten vorgestellt. Dieser Abschnitt diskutiert zwei grundlegende grafische
Modellierungstechniken: Blockdiagramme und Zustandsdiagramme. In dieser Arbeit
werden diese ausschließlich in Gestalt der Softwareprodukte Simulink [Simulink] und
Stateflow [Stateflow] verwendet. Sie sind Bestandteil der technischen Entwicklungsumgebung
MATLAB [MATLAB] von The Mathworks [Mathworks].
2.3.1 Blockdiagramme in Simulink
Mit den Blockdiagrammen der Modellierungssprache Simulink wird der Datenfluss eines
Systems beschrieben. Die Linien eines Blockdiagramms repräsentieren Signalleitungen,
über die Daten übertragen werden. Jede Linie zeigt die Richtung an, in der Daten von
einem Quellblock zu einem oder mehreren Zielblöcken übertragen werden. Einzelne
Blöcke repräsentieren Recheneinheiten, die eingehende Daten verarbeiten und daraus
resultierende Berechnungen bereitstellen. Ein Pfad durch ein Blockdiagramm, der aus
mehreren Recheneinheiten und Signalleitungen besteht, repräsentiert eine Berechnungssequenz.
Das funktionale Verhalten des Modells wird durch die verwendeten Blöcke und den
zwischen ihnen erstellten Verbindungen modelliert. Abbildung 2-3 zeigt eine Auswahl von
Grundblöcken in Simulink. Darunter sind unter anderem die Signalquellen Constant und
Sine Wave aufgeführt, welche ein konstantes Signal bzw. eine Sinuskurve als Signal
liefern. Die mathematischen Grundblöcke Gain und Sum dienen zur Multiplikation mit
einer Konstanten (Gain) und der Addition von zwei Signalen (Sum).
6

2. Modellbasierte Entwicklung eingebetteter Systeme
Abbildung 2-3: Grundblöcke in Simulink
Neben den Grundblöcken stehen auch Blöcke zum Lenken des Kontrollflusses zur Verfügung,
von denen eine Auswahl in Abbildung 2-4 zu sehen ist.
Abbildung 2-4: Blöcke zur Behandlung des Kontrollflusses in Simulink
Um die Übersichtlichkeit in großen Modellen zu gewährleisten, ermöglicht Simulink den
Einsatz von Hierarchieebenen. Dabei können mehrere Grundblöcke zu komplexen
Blöcken, so genannten Subsystemen, zusammengefasst werden. Diese können wiederum
Teilsysteme beinhalten. Auf diese Weise können Blöcke gruppiert werden, die logische
Einheiten bilden.
2.3.2 Zustandsdiagramme in Stateflow
Die in Simulink verwendeten Zustandsdiagramme werden als Statecharts bezeichnet. In
ihnen wird das logische Verhalten eines Systems modelliert. Dabei wird davon ausgegangen,
dass eine Aufteilung in eine Menge von Modi oder Zuständen möglich ist,
zwischen denen Übergänge bestehen. Abbildung 2-5 zeigt die Grundbestandteile eines
7

2.3. Grafische Modellierung in MATLAB
Statecharts in Stateflow, wozu Zustände (engl. states) und Zustandsübergänge (Transitionen,
engl. transitions) gehören.
Abbildung 2-5: Bestandteile eines Statecharts in Stateflow
Die Zustände werden durch Rechtecke mit abgerundeten Ecken, Zustandsübergänge mit
gerichteten Kanten symbolisiert. Häufig sind Bedingungen an die Transitionen geknüpft,
die erfüllt sein müssen, damit der Übergang zum jeweils nächsten Zustand vollzogen
werden kann. Diese Bedingungen (engl. conditions) können auch an Ereignisse (engl.
events) gebunden sein, welche hauptsächlich zur Interaktion mehrerer parallel laufender
Zustandsautomaten verwendet werden.
Stateflow ermöglicht die Modellierung mehrerer Hierarchieebenen. Auf diese Weise
können mehrere parallel laufende Teilsysteme modelliert werden, die jeweils einen
eigenen Zustandsautomaten darstellen. Diese werden innerhalb komplexer Zustände, so
genannten Superstates, beschrieben, welche Zustände repräsentieren, die in eine Menge
von Teilzuständen aufgeteilt wurden.
In Abbildung 2-6 zählen die Zustände System, S1 und S2 zur Klasse der Superstates.
Diesen gegenüber stehen die einfachen Zustände S11, S12, S21 und S22. Die Parallelität im
Statechart System wird durch die gestrichelten Ränder der Zustände S1 und S2 dargestellt.
Diese beinhalten zwei parallel ablaufende Teilsysteme mit den Zuständen S11 und S12 in
S1 sowie S21 und S22 in S2. Im Beispiel sind zwei Ereignisse, Event_1 und Event_2,
eingebaut worden. Ersteres wird ausgelöst, wenn der Zustandsübergang von S11 zu S12
genommen wird. Dies hat zur Folge, dass im Anschluss der Superstate S2 den Zustandsübergang
von S21 zu S22 wechselt.
8

2. Modellbasierte Entwicklung eingebetteter Systeme
Abbildung 2-6: Parallelität in Zustandsautomaten
Die in diesem Abschnitt vorgestellten Modellarten werden in den Beispielen späterer
Kapitel verwendet. Insbesondere in Kapitel 6 werden Simulink/Stateflowmodelle als
Beispiele zur Evaluierung des in dieser Arbeit entwickelten Verfahrens zur Steuerung
automatischer Testmustergenerierung verwendet. Bevor auf dieses Verfahren eingegangen
wird, erfolgt im Folgenden eine Definition der wichtigsten Begriffe im Umfeld des
modellbasierten Testens.
9

3 Modellbasiertes Testen
Die Anwendung systematischer Methoden während der Entwicklung von Hardware- und
Softwaresystemen trägt bereits zur Reduzierung der Anzahl von Fehlern in technischen
Produkten bei. Die Komplexität dieser Systeme nimmt derart zu, dass die Fehlerfreiheit
mit den genannten Methoden allein nicht garantiert werden kann. Der Test ist ein bedeutender
Bestandteil des Soft- und Hardwareentwicklungsprozesses geworden [BroNot03,
Pre03], der dem Ziel gewidmet ist, Fehler in Systemen aufzudecken und somit die Systemqualität
zu erhöhen. Ein Anlass zum Testen kann die Suche nach der Ursache eines
offensichtlichen Fehlverhaltens des Systems oder auch das Bestreben nach einem höheren
Vertrauen auf seine Qualität sein.
In diesem Kapitel erfolgt zunächst die Definition wesentlicher Konzepte und Aktivitäten
des modellbasierten Testens. Dazu werden in Abschnitt 3.1 die in dieser Arbeit verwendeten
Begriffe im Umfeld des Testens definiert. Unterkapitel 3.2 stellt eine Klassifikation
von Prüfverfahrenklassen vor und geht auf die Unterschiede zwischen Verifikation und
Validierung und ihre Abgrenzung zur formalen Verifikation ein. In Abschnitt 3.3 werden
Abdeckungskriterien erläutert, die als Testziele strukturorientierter Testverfahren dienen.
Der darauf folgende Abschnitt 3.4 liefert einen Überblick über ausgewählte Verfahren zur
Testfallerzeugung. Ziel dieses Unterkapitels ist es, Methoden aufzuzeigen, die den Tester
bei der Erzeugung von Testfällen unterstützen. Abschließend werden in Unterkapitel 3.5
kommerzielle Programme zur Erstellung von Testfällen und Testmustern vorgestellt.
3.1 Grundlagen
Im Folgenden werden Begriffe definiert, die im Umfeld des Testens und insbesondere in
dieser Arbeit von Bedeutung sind. An dieser Stelle sei bereits erwähnt, dass in der Literatur
Abweichungen von den hier aufgeführten Definitionen zu finden sind. In späteren
Abschnitten, in denen Begriffe nicht mit referenzierten Literaturquellen in ihrer Definition
übereinstimmen, ist dies gekennzeichnet, um möglichen Missverständnissen vorzubeugen.
3.1.1 Der Systembegriff
Bevor auf die Begriffe im Umfeld des Testens eingegangen wird, erfolgt zum besseren
Verständnis späterer Abschnitte die Definition des Systembegriffs nach Föllinger [Föl94].
Allgemein ist ein System eine Menge von Dingen, die in einer bestimmten Relation
zueinander stehen. Die Relation bildet aus der Menge von Dingen eine Betrachtungseinheit.
Ein System besteht somit aus einer Menge von Dingen und einer Menge von
Relationen. Die Tatsache, dass praktisch jedes System ein Teil eines größeren Systems ist,
erfordert die Definition des folgenden Begriffs.
Abgeschlossenes System. Ein System, das keinen näher definierten Einflüssen aus einer
Umgebung ausgesetzt ist, wird als abgeschlossenes System oder Globalsystem bezeichnet.
11

3.1. Grundlagen
Demnach ist ein Globalsystem zwar in ein größeres Umgebungssystem eingebettet, seine
Interaktion mit diesem kann aber vernachlässigt werden.
Abgegrenztes System. Wird ein System aus seiner Umgebung herausgenommen, mit der
es interagiert, bezeichnet man dieses als abgegrenztes System. Dieses zeichnet sich
dadurch aus, dass es nicht nur allein als separate Komponente betrachtet werden kann, da
die Wechselwirkung mit seiner Umgebung auf das Systemverhalten Einfluss nimmt.
Eingangs- und Ausgangsgrößen. Die Interaktion eines abgegrenzten Systems mit seiner
Umgebung erfolgt über Eingangsgrößen, auf die es reagiert, und Ausgangsgrößen, mit
denen das System seine Umgebung beeinflusst.
Die in dieser Arbeit betrachteten eingebetteten Systeme sind – wie bereits ihr Name sagt –
abgegrenzte Systeme, die in ein Umgebungssystem eingebettet sind, mit welchem sie
interagieren. Im Folgenden bezeichnet der Begriff System, immer ein abgegrenztes
System. Insbesondere der später näher definierte Begriff Testobjekt beschreibt ein
abgegrenztes System, dessen Verhalten mittels Tests überprüft werden soll.
3.1.2 Grundbegriffe beim Testen
Testen. Das Testen ist eine Maßnahme, die im Entwicklungsprozess eines Systems der
Steigerung der Produktqualität dient. Fälschlicherweise wird häufig angenommen, der Sinn
des Testens sei die Überprüfung eines Systems auf korrektes Verhalten während der
Ausführung. Diese Zielsetzung widerspricht im Kern dem Gedanken der Qualitätssteigerung,
da aufgrund eines Nachweises des korrekten Laufzeitverhaltens keine Verbesserung
am System vorgenommen wird. Entgegengesetzt formuliert Myers die Definition des
Testbegriffs:
„Testen ist der Prozeß, ein Programm mit der Absicht auszuführen, Fehler zu finden“
[Mye89, S.4].
Das Überprüfen der Korrektheit eines Systems mit dem Ziel, Fehler zu finden, kann
direkten Einfluss auf die Qualität nehmen. Sollte mit einer Anzahl von Testfällen dieses
Ziel erreicht werden, führt die Behebung der gefundenen Fehler direkt zu einer Qualitätssteigerung.
Testziel. Die Erstellung und Durchführung von Testfällen, wie sie nachfolgend beschrieben
wird, ist immer einem konkreten Ziel gewidmet [Pre03]. Hierbei ist nicht die bereits
erwähnte Motivation des Testens, nämlich das Aufdecken von Fehlern, gemeint. Es
handelt sich vielmehr um eine ausgewählte Eigenschaft des Systems, welche durch die
Anwendung eines Testfalls überprüft werden soll. Das Testziel kann die Überprüfung der
Existenz einer Systemfunktionalität oder auch ihrer korrekten und vollständigen Umsetzung
fordern. Des Weiteren kommt auch die Robustheit eines Systems oder einer
Teilfunktionalität als Testziel in Frage.
Die Testziele können sowohl formal, als auch nicht-formal angegeben werden. Eine nichtformale
Beschreibung kann häufig durch einen Testentwickler leichter angegeben werden.
12

3. Modellbasiertes Testen
Dem gegenüber stehen formal beschriebene Testziele, die in der Regel mit mathematischen
Mitteln angegeben werden. Diese vereinfachen eine automatische Testfallerstellung, da
mathematische und logische Formeln leicht durch Software ausgewertet werden können.
Ein Beispiel für eine formale Testzielbeschreibung wäre die Angabe einer Zeitspanne, die
maximal zwischen dem Aufprall eines Fahrzeugs auf ein Hindernis und dem Zeitpunkt, an
dem der Airbag ausgelöst wird, verstreichen darf.
Testschritt. Die Durchführung von rechnerbasierten Tests erfordert eine Diskretisierung
der Zeitlinie. Hierbei wird der Zeitverlauf eines Tests auf eine Folge von Zeitpunkten
abgebildet, die einen festen zeitlichen Abstand haben [Con04].
Testobjekt. Als Prüfling, Testling, Testgegenstand oder Testobjekt wird die Komponente
des zu untersuchenden Systems bezeichnet [Bal98], welche zentraler Gegenstand der Testdurchführung
ist. Jede Testaktivität steht in Bezug zu dem Testobjekt, auch wenn dieses in
frühen Phasen des Qualitätssicherungsprozesses noch nicht vollständig vorhanden sein
muss. Es sich um jede Teilkomponente des zu entwickelnden Produktes handeln. Wie
bereits in Abschnitt 2.2 beschrieben wurde, durchschreitet dieses im Rahmen des modellbasierten
Entwicklungsprozesses mehrere Phasen, in denen es in unterschiedlichen Formen
vorliegt. Zu diesen gehören unter anderem das Funktionsmodell, das Implementierungsmodell
sowie der daraus generierte Programmcode. Die verschiedenen Entwicklungsstände
oder auch Teilkomponenten davon kommen als Testobjekte in Frage [Con04]. Abbildung
3-1 zeigt ein Beispiel für ein Testobjekt mit Kennzeichnung seiner n Eingabe- und m
Ausgabeschnittstellen.
Auch wenn der eigentliche Gegenstand der Testdurchführung eine Implementierung ist,
werden häufig die während der Testerstellung verwendeten Entwicklungsstufen ebenfalls
als Testobjekte bezeichnet. In dieser Arbeit wird generell das Funktionsmodell zur
Erstellung von Tests verwendet.
e 1
a 1
e n
a m
Abbildung 3-1: Implementierungsmodell als Testobjekt
Testbasis. Bei der Erstellung von Tests spielen die Informationsquellen, auf die zurückgegriffen
wird, eine entscheidende Rolle. Sie bilden die Basis, aufgrund derer Tests erstellt
werden [Con04]. Im modellbasierten Entwicklungsprozess kommen dafür unter anderem
13

3.1. Grundlagen
die Kundenanforderungen, eine daraus erstellte Spezifikation in Form eines Dokuments
oder das Funktionsmodell in Frage. Conrad [Con04] verwendet zusätzlich den Begriff
Testorakel, wenn ein Modell als Testbasis verwendet wird und zusätzlich auch zur
Bestimmung von Referenzdaten dient.
Testfallerstellung
Testziel
Testbasis
Struktureigenschaft
(z.B. Test aller
Verzweigungen)
Funktionseigenschaft
(z.B. Test des
Auslösers eines Airbags)
Kundenanforderungen
.......................
.......................
.......................
.......................
.......................
Funktionsmodell
Abbildung 3-2: Zusammenhang von Testziel, Testbasis und Testfallerstellung
Abbildung 3-2 zeigt den Zusammenhang der drei soeben erläuterten Begriffe. Die Wahl
der Testziele hängt im Wesentlichen von der Wahl der Testbasis ab, welche in dieser
Arbeit das Funktionsmodell ist. Dieses bietet eine gute Voraussetzung dafür, als Testziele
strukturelle Eigenschaften des Systems zu verwenden, da es zum einen direkt aus den
Anforderungen des Benutzers erstellt wurde und zum anderen als Grundlage für spätere
Entwicklungsschritte verwendet wird. Die wichtigsten strukturellen Eigenschaften, die als
Testziele in Frage kommen, werden in Abschnitt 3.3 unter dem Gesichtspunkt der
Abdeckungsmessung näher behandelt.
Teststrategie. Die Komplexität heutiger Systeme macht es unmöglich, mittels Tests einen
Beweis der Korrektheit einer Systemkomponente durchzuführen. Die Anzahl möglicher
Kombinationen der Eingabedaten, die das zu prüfende Objekt verarbeitet und auf die es
reagiert, ist in der Regel so hoch und kann daher durch Tests nicht vollständig abgedeckt
werden. Zur Reduzierung des Zeitaufwandes und den damit verbundenen Kosten ist die
Festlegung einer Teststrategie notwendig. Dabei wird der Umfang einzelner Tests unter
dem Gesichtspunkt einer Prioritätensetzung festgelegt. Sicherheitskritische Aspekte sollten
an dieser Stelle gegenüber weniger wichtigen Funktionen bevorzugt und umfangreicher
überprüft werden. Nach der gewählten Teststrategie werden die Ziele vor der Erstellung
von Tests definiert [Bal98].
Eingabedaten (Testdaten). Ein Eingabedatum e i,s steht für einen Wert aus dem Wertebereich
des i-ten Signaleingangs, den dieser während der Testdurchführung zum Zeitpunkt
des s-ten Testschritts annimmt. Balzert [Bal98] bezeichnet die Eingabedaten als Testdaten,
da sie zum Test des Systems verwendet werden.
14

3. Modellbasiertes Testen
Eingabevektor. Ein Eingabevektor e s beinhaltet exakt ein Eingabedatum für jeden der n
Signaleingänge des Testobjektes zum Testschritt s.
e
s
⎛ e1,
s
⎞
⎜ ⎟
= ⎜ ... ⎟
⎜ ⎟
⎝en,
s ⎠
Ausgabedaten. Entsprechend der Definition der Eingabedaten ist ein Ausgabedatum a i,s
der Wert eines Signalausgangs des zu untersuchenden Systems während des s-ten Testschritts
der Testdurchführung.
Ausgabevektor. Ein Ausgabevektor a s besteht aus jeweils einem Ausgabedatum für jede
der m Ausgangsschnittstellen des Testobjekts:
a
s
⎛ a1,
s
⎞
⎜ ⎟
= ⎜ ... ⎟
⎜ ⎟
⎝am,
s ⎠
Referenzdaten. Die Erwartungswerte der Systemausgabe während der Testdurchführung
werden als Referenzdaten bezeichnet. Dabei repräsentiert ein Referenzdatum r i,s einen
Wert, den der i-te Systemausgang zum Zeitpunkt des s-ten Testschritts annehmen soll. Die
Werte aller Signalausgänge des Systems bilden die Referenzdaten. Diese dienen während
der Testdurchführung und der anschließenden Bewertung des Systemverhaltens dem
Vergleich mit der tatsächlichen Systemausgabe. Häufig werden als Referenzdaten die
während einer Simulation einer ausführbaren Systemspezifikation gemessenen Ausgabedaten
verwendet. Im modellbasierten Entwicklungsprozess dient dazu beispielsweise das
Funktionsmodell. Der hiermit verbundene Begriff des Back-to-Back-Tests wird in
Abschnitt 3.2.4 motiviert und erläutert.
Referenzvektor. Die Vereinigung von jeweils einem Referenzdatum pro Ausgabeschnittstelle
bildet den Referenzvektor r s :
r
s
⎛ r1,
s
⎞
⎜ ⎟
= ⎜ ... ⎟
⎜ ⎟
⎝rm , s ⎠
Toleranzvektor. Der Toleranzvektor τ ist die Beschreibung der Abweichung, um die die
gemessenen Ausgabedaten von den vorgegebenen Referenzdaten abweichen dürfen. Die
Abweichung wird in der Regel für einen gesamten Testfall definiert, sodass sie in jedem
Testschritt Geltung hat.
⎛ τ
1 ⎞
⎜ ⎟
τ = ⎜ ... ⎟ mit τ i ≥ 0
⎜ ⎟
⎝τ m ⎠
1
15

3.1. Grundlagen
Testvektor. Die Vereinigung von Eingabe- und Referenzdaten bildet einen Testvektor.
Dieser beinhaltet jeweils ein Eingabedatum pro Eingabeschnittstelle und ein Referenzdatum
pro Ausgabeschnittstelle zu dem Zeitpunkt der Testdurchführung, dem der Testvektor
zugeordnet ist. Der folgende Testvektor t s beinhaltet n+m Werte, wobei n die
Anzahl der Signaleingänge des Systems und m die Anzahl der Systemausgänge ist. Die
Werte e 1,s , …, e n,s sind die Werte der Systemeingänge und r 1,s , …, r m,s die erwarteten Werte
der Ausgänge im s-ten Testschritt der Testdurchführung.
t
s
⎛ t1,
s ⎞ ⎛ e1,
s ⎞
⎜ ⎟ ⎜ ⎟
⎜ ... ⎟ ⎜ ... ⎟
⎜ t ⎟ ⎜ ⎟
n,
s
en,
s
= ⎜ ⎟ = ⎜ ⎟
⎜ tn+
1, s ⎟ ⎜ r1,
s ⎟
⎜ ⎟ ⎜ ⎟
⎜
...
⎟ ⎜
...
⎟
⎝tn+
m,
s ⎠ ⎝rm , s ⎠
In der Literatur wird alternativ zu der hier gelieferten Definition häufig bereits ein Eingabevektor
als Testvektor bezeichnet. Für diese Arbeit sollen aber die vorherige Definitionen
Geltung haben.
Testmuster. Eine zeitliche Abfolge von Testvektoren, die während der Testdurchführung
auf das Testobjekt in festen Zeitschritten (vgl. Testschritt) angewendet werden, bildet ein
Testmuster. Dieses beinhaltet zum einen eine Menge von Eingabevektoren, mit denen das
Testobjekt stimuliert wird, und zum anderen die zugehörigen Referenzvektoren, die zum
Vergleich der gemessenen Ausgabevektoren benötigt werden.
Das Testmuster T ist eine Matrix, deren i-te Zeile den zeitlichen Verlauf der Werte des
i-ten Signaleingangs beschreibt, wenn i ≤ n gilt. Sollte i > n sein, beinhaltet sie die Werte,
die der (i – n)-te Signalausgang des Systems in den einzelnen Testschritten annimmt. Die
i-te Spalte der Matrix beschreibt hingegen eine Momentaufnahme des Zustands aller Einund
Ausgänge des Testobjektes im Testschritt i.
T
⎛ t
⎜
⎜ .
⎜ tn
= ⎜
⎜ t(
n+
⎜
⎜
.
⎝t(
n+
1,1
,1
1),1
m),1
t
1,2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
t
1, s
( n+
1), s
t
t
.
.
.
n+
m,
s
⎞ ⎛ e
⎟ ⎜
⎟ ⎜ .
⎟ ⎜en
⎟ = ⎜
⎟ ⎜ r
⎟ ⎜
⎟ ⎜
.
⎠ ⎝rm
1,1
,1
1,1
,1
e
1,2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
e1,
s ⎞
⎟
. ⎟
e ⎟
n,
s
⎟
r1,
s ⎟
.
⎟
⎟
r
m,
s ⎠
Das Beispiel in Abbildung 3-3 verdeutlicht die Struktur eines Testmusters und seinen
Zusammenhang zum Zeitverlauf der Testdurchführung. Als Abstand der Zeitschritte
wurden 0,01 Sekunden gewählt.
16

3. Modellbasiertes Testen
Testvektor tv 2 zum Zeitpunkt 0.02
mit Eingabedaten und Referenzdaten
Referenzdatum 7.34 für
den Systemausgang Out2
Eingabedatum 1.04 für
den Systemeingang In2
Namen der
Systemeingänge
In1
In2
5
1.04
tv 2
0
0.04
tv 3
4
1.04
tv 4
1
0.04
tv 5
2
1.04
tv 6
3
0.04
tv 7
7
1.04
tv 8
6
0.04
tv 9
9
1.04
tv 1 3
Namen der
Systemausgänge
Out1
Out2
Out3
0.34
1.35
2.34
0.91
5.23
2.35
1.02
7.34
2.36
0.03
9.34
2.34
4.04
8.2
2.45
2.05
10
2.01
5.06
4.76
2.56
0.37
3.65
2.99
6.48
8.3
Zeit
0.01
0.02
0.03
0.04
0.05
0.06
0.07
0.08
0.09
Abbildung 3-3: Struktur eines Testmusters
Testfall. Die Menge von Testziel und einer endlichen Anzahl von Testmustern bildet einen
Testfall. Dieser beschreibt eine Menge von Szenarien, durch deren Ausführung das
Verhalten des Testobjekts bzgl. eines angegebenen Ziels überprüft wird. Die Verwendung
eines Testfalls in der entsprechenden Phase des Testprozesses wird in Kapitel 3.1.3 näher
beschrieben.
Testfall
Testziel
Testmuster
Abbildung 3-4: Testfall
Testresultat. Die Ergebnisse der Durchführung eines Testfalls werden als Testresultat
bezeichnet. Dieses kann in einfachen Formen wie beispielsweise einer einfachen Statusbeschreibung
oder einem umfassenden Dokument vorliegen. Ersteres kann in Form einer
Aufzählung gefundener Fehler und einer Endbewertung erfolgen, die einen Status „fehlgeschlagen“
oder „erfolgreich“ beinhaltet. Dem gegenüber steht die zweite Variante in Form
eines Dokuments, welches eine detaillierte Beschreibung der Testfälle, ihrer Testziele und
Testmuster und der gefundenen Fehler beinhaltet. Ebenso kann eine Beschreibung der
geprüften Systembereiche in Form einer Abdeckungsmessung (siehe Kapitel 3.3) in das
Testresultat integriert sein. Mit diesem Abdeckungsbericht können beim Kunden aufgetretene
Fehler dahingehend analysiert werden, ob die für den Fehler verantwortlichen
Systembereiche bereits umfangreich oder sogar gar nicht überprüft wurden.
17

3.1. Grundlagen
3.1.3 Der Testprozess
Zu den Testaktivitäten werden alle Tätigkeiten gezählt, die zur Überprüfung des Systems
auf Fehler dienen. Pretschner [Pre03] identifiziert folgende Aktivitäten als Bestandteil des
Testprozesses: Testplanung, Testorganisation, Testfallgenerierung, Testdurchführung und
Monitoring, Testauswertung und Testdokumentation. Das Beheben aufgedeckter Fehler als
Reaktion auf die Überprüfung ist nicht Bestandteil des Prozesses und muss gesondert
betrachtet werden. In dieser Arbeit hat das Beheben von Fehlern jedoch keine Relevanz
und wird nicht näher betrachtet. Die folgenden Beschreibungen dieser Testaktivitäten
folgen den von Pretschner vorgestellten Definitionen [Pre03].
Testplanung. Die Testplanung dient der Festlegung des Testobjekts und einer Anzahl von
Testzielen. Dies geschieht unter Berücksichtigung der Testbasis und einer Teststrategie.
Testorganisation. Durch die Verwaltung von Testobjekten und Testfällen wird die Reproduzierbarkeit
von Testdurchführung und Testresultaten unterstützt. Dies beinhaltet auch
die Wiederverwendung von Testfällen in den verschiedenen Entwicklungsstufen und
neuen Varianten und Revisionen des Systems.
Testfallgenerierung. Diese Tätigkeit beinhaltet mehrere Einzelaktivitäten. Die in der
Planungsphase festgelegten Testziele werden zuerst formal spezifiziert. Aus der entstandenen
Testfallspezifikation werden einzelne Testfälle erstellt, mit denen einzelne Testziele
erreicht werden. Zusätzlich wird ein Toleranzmaß in Form eines Toleranzvektors angeben,
mithilfe dessen eventuell eine geringe Abweichung von gemessenen Ausgabe- und
vorgegebenen Referenzdaten für die spätere Testauswertung vorgesehen wird. Die Testfallgenerierung
kann manuell oder auch automatisiert vollzogen werden.
Testdurchführung und Monitoring. Diese Phase des Testprozesses besteht aus zwei
Teilaktivitäten, die gleichzeitig durchgeführt werden müssen. Auf der einen Seite werden
die erstellten Testfälle zur Überprüfung des betroffenen Testobjekts angewendet, während
gleichzeitig eine Aufzeichnung der Ausgabedaten des Testobjektes erfolgt. Diese werden
für die spätere Testauswertung benötigt. Zum Zeitpunkt des i–ten Testschrittes wird das
Testobjekt mithilfe des i-ten Eingabevektors des verwendeten Testmusters stimuliert.
Gleichzeitig erfolgt die Aufzeichnung des i-ten Ausgabevektors. Zusätzlich kann das
Monitoring auch die Aufzeichnung von Abdeckungsmaßen beinhalten, auf die in Abschnitt
3.3 näher eingegangen wird.
Testdurchführung Monitoring Testauswertung
Testfall
Testziel
Referenzdaten
+
-
Vergleich
Testresultat
Testmuster
Eingabedaten
Testobjekt
Ausgabedaten
Abbildung 3-5: Testdurchführung, Monitoring und Testauswertung
18

3. Modellbasiertes Testen
Testauswertung. Der Vergleich von Ist- und Sollverhalten des Systems ist die eigentliche
Phase, in der Fehler im System festgestellt werden können. Hierzu wird für jeden der
während der vorherigen Phase am Testobjekt gemessenen Ausgabevektoren ein Vergleich
des Ausgabevektors mit dem zugehörigen Referenzvektor durchgeführt. Zu diesem Zweck
wird der Abweichungsvektor Δ s als der Differenz von Ausgabe- und Referenzvektor des
Testschrittes s gebildet. Unter Berücksichtigung des zuvor definierten Toleranzvektors τ
wird entschieden, ob der durchgeführte Testschritt korrekt oder fehlerhaft erfolgte.
Δ
s
=
⎛ Δ1,
⎜
⎜ ...
⎜
⎝Δ
,
s
m s
⎞
⎟
⎟ =
⎟
⎠
⎛ a1,
⎜
⎜ ...
⎜
⎝am,
s
s
⎞ ⎛ r1,
s
⎞
⎟ ⎜ ⎟
⎟ − ⎜ ... ⎟
⎟ ⎜ ⎟
⎠ ⎝rm
, s ⎠
Δ
s
⎛ Δ1,
s
⎞ ⎛ τ1
⎞
? ⎜ ⎟ ? ⎜ ⎟
< τ ⇔ ⎜ ... ⎟ < ⎜ ... ⎟ mit τ i ≥ 0
⎜ ⎟ ⎜ ⎟
⎝Δm,
s ⎠ ⎝τ
m ⎠
Das Ergebnis der Testauswertung ist das Testresultat, welches eine Bewertung des Tests
aufgrund dieser Vergleiche beinhaltet.
Testdokumentation. Durch eine umfangreiche Dokumentation der durchgeführten Tests
werden zum einen die Nachvollziehbarkeit von Tests und deren Resultaten und zum
anderen auch die Akzeptanz des getesteten Produktes unterstützt. Anhand einer Beschreibung,
welche Eigenschaften des Systems erfolgreich überprüft wurden, können Kunden
besser entscheiden, ob sie das gelieferte Produkt akzeptieren, oder weitere Tests fordern.
Eine Gewissheit auf Fehlerfreiheit kann selbstverständlich nicht geliefert werden, da dies
nur mithilfe eines erschöpfenden (vollständigen) Tests möglich ist, welcher in der Regel
aufgrund des extrem hohen Aufwands nicht durchführbar ist.
3.2 Prüfmethoden
3.2.1 Verifikation und Validierung
Die Überprüfung der Korrektheit eines Systems erfolgt in mehreren Stufen und auf unterschiedliche
Arten. Die Verifikation ist die Prüfaktivität am Ende jeder Entwicklungsphase,
in der das System gegen einzelne zu Beginn der Phase aufgestellte Anforderungen, geprüft
wird. Dagegen erfolgt durch die Validierung eine Untersuchung des Systems gegen die
Benutzeranforderungen. Thaller formuliert dies genauer:
„Bei der Verifikation wird überprüft, ob das Produkt richtig ist. Bei Validation prüfen wir
dagegen, ob wir das richtige Produkt erstellt haben.“ [Tha00, S.19].
Verifikation und Validierung dienen somit jeweils der Überprüfung der Richtigkeit des
untersuchten Systems.
19

3.2. Prüfmethoden
Die genannte Definition des Begriffs Verifikation ist nicht zu verwechseln mit der formalen
Verifikation, welche eine spezielle Form der Verifikation ist, die mit formalen, meist
mathematischen Mitteln erfolgt. Mit dieser beschäftigt sich Abschnitt 3.2.2.
Prüfverfahren
statisch
verifizierend
formale Verifikation
…
analysierend
dynamisch
strukturorientiert
Inspektionen und Reviews
…
kontrollflussorientiert
Anweisungsüberdeckungstest
Zweigüberdeckungstest
Bedingungsüberdeckungstest
Einfacher Bedingungsüberdeckungstest
Mehrfach-Bedingungsüberdeckungstest
Minimaler Mehrfach-Bedingungsüberdeckungstest
Modifizierter Mehrfach-Bedingungsüberdeckungstest
…
Pfadüberdeckungstest
…
datenflussorientert
funktionsorientiert
…
Funktionale Äquivalenzklassenbildung
…
diversifizierend
…
Back-to-Back-Test
…
Abbildung 3-6: Klassifikationsschema nach Liggesmeyer [Lig02, S. 34]
Die für diese Arbeit wichtigen Prüfmethoden werden in das Klassifikationsschema von
Softwareprüfverfahren nach Liggesmeyer eingeordnet, welches in Abbildung 3-6 in
Auszügen dargestellt ist. Zur näheren Erläuterung erfolgt in den folgenden Abschnitten
eine Klassifikation der Verfahren, die zur Überprüfung von Soft- und Hardware verwendet
werden. Die zur Validierung und Verifikation verwendeten Techniken und Verfahren
werden in statische und dynamische Testverfahren eingeordnet. Diese bilden die Hauptklassen
der Prüftechniken, die in weitere Unterklassen aufgeteilt und deren Eigenschaften
herausgestellt werden.
20

3. Modellbasiertes Testen
3.2.2 Statische Prüfverfahren
Die statischen Verfahren werden in analysierende und verifizierende Methoden unterteilt.
Inspektionen und Reviews gehören zur Klasse der analysi5erenden Techniken und haben
den Charakter, dass zu ihrer Durchführung keine Testfälle erzeugt werden müssen und
somit keine Ausführung des Systems erforderlich ist. Die hierbei verwendeten Analysetechniken
können allerdings keine vollständigen Aussagen über die Korrektheit eines
Systems treffen.
Dem gegenüber stehen die verifizierenden Verfahren, welche derartige Korrektheitsaussagen
ermöglichen. Zu ihnen zählt die formale Verifikation. Sie besteht aus einem
formalen Beweis, der die Konsistenz zwischen einer Spezifikation und einem
Entwicklungsstand des Systems mit mathematischen Mitteln zeigt. Voraussetzung zur
Durchführung einer formalen Verifikation ist das Vorhandensein einer entsprechend
formalen Spezifikation. Diese besteht nach Balzert [Bal98] aus einer Menge von Vor- und
Nachbedingungen. Der Korrektheitsbeweis einer Implementierung erfolgt, indem Vorbedingungen
unter Verwendung von Verifikationsregeln in Nachbedingungen transformiert
werden. Die Verifikationsregeln sind hierbei formale Beschreibungen von Programmkonstrukten
und deren Effekt auf einen Systemzustand.
3.2.3 Dynamische Prüfverfahren
Die größere und in dieser Arbeit zentral betrachtete Verfahrensklasse bilden die dynamischen
Prüfverfahren (vgl. Abbildung 3-6). Zu ihnen zählen strukturorientierte und
funktionsorientierte Methoden. Ihre zentrale Eigenschaft besteht in der Ausführung des
Systems. Dazu wird dieses mit konkreten Eingabewerten versehen und ausgeführt. Dies
impliziert, dass auf diese Weise eine vollständige Überprüfung des Systems nicht möglich
ist, da diese während der Testdurchführung eine Ausführung des Systems mit allen Werten
der Wertebereiche der Eingabeschnittstellen und aller Kombinationen von Eingabewerten
an den verschiedenen Schnittstellen fordert. Aufgrund der schon bei relativ kleinen
Systemen hohen Anzahl zu erzeugender Tests ist dies extrem aufwendig und meistens
nicht realisierbar.
Die strukturorientierten Testverfahren zielen auf die Struktur des Testobjektes ab. Der
Strukturtest basiert auf der Auswertung des internen Aufbaus, der Struktur des Testobjektes.
Daher stammt auch die verbreitete Bezeichnung White-Box-Test. Dieser betrachtet das
System als „durchsichtige Box“, aus deren Innern für den Test relevante Informationen
während der Testfallerstellung entnommen werden können. Das Ziel ist hierbei der
möglichst vollständige Test durch Ausführung bestimmter Strukturelemente während der
Tests.
Eingabedaten
…
&
&
…
Ausgabedaten
Abbildung 3-7: Strukturtestverfahren (White-Box-Test)
21

3.2. Prüfmethoden
Die Erstellung von Strukturtests erfordert ein Mittel zum Messen der Vollständigkeit von
Tests bezogen auf ausgewählte Strukturmerkmale. Nähere Informationen zu diesem Thema
liefert Kapitel 3.3, in welchem unterschiedliche Strukturmerkmale vorgestellt werden, die
in dieser Arbeit Verwendung finden. Der vornehmliche Nachteil der strukturorientierten
Testverfahren besteht darin, dass sie nicht in der Lage sind, fehlerhaft oder unvollständig
implementierte Funktionen zu erkennen. Sollten bei der Implementierung die Anforderungen
falsch interpretiert worden sein, können fehlerhaft implementierte Komponenten in
einer ansonsten in sich konsistenten und korrekten Umsetzung mittels White-Box-Tests
nicht aufgedeckt werden. Das Gleiche gilt für übersehene und vergessene Funktionen
[Tha00].
Eine Überprüfung fehlerhaft oder unvollständig implementierter Funktionen bieten dagegen
die funktionalen Testverfahren, bei denen die Spezifikation des Testobjektes zur
Erstellung von Tests herangezogen wird. Das System wird bis auf seine Schnittstellen nach
außen nicht näher berücksichtigt. Informationen über den inneren Aufbau und die Art der
Realisierung des Systems werden zur Generierung von Eingabe- und Ausgabedaten nicht
verwendet. Das System oder Modell wird somit als „undurchsichtige schwarze Box“
betrachtet. Daher leitet sich auch der Begriff des Black-Box-Tests ab. Das Ziel eines
Funktionstests ist es, die Spezifikation der Programmfunktionen möglichst vollständig zu
testen.
Eingabedaten
System
Ausgabedaten
Abbildung 3-8: Funktionstest (Black-Box-Test)
Ein wichtiger Aspekt von Funktionstests ist ihr szenarioorientierter Aufbau. Während
Strukturtests häufig aus nicht im realen Einsatz vorkommenden Abfolgen von Eingabewerten
bestehen, handelt es sich beim funktionsorientierten Test um Stimulusdaten, deren
Auftreten im Einsatz des Systems sehr wahrscheinlich ist. Ein wichtiger Vertreter des
funktionalen Tests ist die Testfallerstellung mithilfe der Klassifikationsbaummethode.
Diese ist ein Verfahren zur abstrakten Beschreibung szenarioorientierter Testfälle und wird
in Unterkapitel 3.4.1 näher beschrieben.
3.2.4 Spezielle Testarten
Der Zufallstest (engl. random testing) bezeichnet eine Technik, bei der aus den Wertebereichen
der Eingabedaten des Systems zufällige Testmuster erzeugt werden. Die Schwäche
des Zufalltests ist, dass die erzeugten Daten in keiner Art und Weise voraussehbar sind.
Diesem Nachteil steht gegenüber, dass durch Zufallstests das Testobjekt durch geringen
Aufwand vergleichsweise gut geprüft werden kann [Lig02]. Die Regellosigkeit bei der
Erzeugung der Testdaten ist neben der genannten Schwäche allerdings auch ein Vorteil.
Tester neigen üblicherweise dazu, Testfälle zu erzeugen, die entsprechenden Einsatzszenarien
des Systems ähnlich sind (vgl. Funktionstest 3.2.3). Bereits in der Entwurfsphase wird
22

3. Modellbasiertes Testen
das System von Entwicklern aber häufig genau anhand dieser Szenarien erstellt, sodass es
sich in diesen Prüfsituationen wie erwartet verhält. Durch Zufallstests werden hingegen
auch solche Testfälle erzeugt, die nicht von Testern bedacht werden. Dies soll allerdings
nicht bedeuten, dass funktionale Tests vorgesehener Einsatzszenarien unnötig sind. Der
Zufallstest sollte vielmehr zusätzlich erfolgen, um realitätsnahe Tests um unwahrscheinliche
– aber trotzdem mögliche – Szenarien zu ergänzen [Bal98].
Die Idee des Back-to-Back-Tests (vgl. Abbildung 3-6) besteht darin, mehrere Repräsentationen
des gleichen Systems mit identischen Eingabedaten zu untersuchen. Die Übereinstimmung
der Repräsentationen wird anhand eines Vergleichs ihrer Ausgabedaten
überprüft. Aus dem primären Vergleich der Ausgabedaten stammt auch die Bezeichnung
dieser Testart. Sollten die unterschiedlichen Repräsentationen dieselben Ausgabedaten
liefern, wird eine funktionale Übereinstimmung angenommen.
Testdaten
Testbasis
(Modell)
+_
Vergleich
Testobjekt
(C-Code)
Abbildung 3-9: Back-to-Back-Test
Dieses Testverfahren bietet sich insbesondere im modellbasierten Entwicklungsprozess an.
Da mehrere Repräsentationen des Systems in Form des Funktionsmodells, des Implementierungsmodells
und des erzeugten Programmcodes vorliegen, ist eine Anwendung von
Back-to-Back-Tests in hohem Grade geeignet, deren Übereinstimmung zu überprüfen.
Insbesondere, wenn beispielsweise das Funktionsmodell in validierter Form vorliegt, also
gegen die Benutzeranforderungen geprüft wurde, können Back-to-Back-Tests gut angewendet
werden, weil dadurch sichergestellt wird, dass das Testobjekt auf diese Weise
indirekt auch gegen die Benutzeranforderungen getestet wird.
Zur Erstellung von Testmustern für Back-to-Back-Tests kann sowohl auf strukturorientierte
als auch auf funktionale Testverfahren zurückgegriffen werden. In dieser Arbeit
werden ausschließlich strukturorientierte Verfahren zum Erzeugen von derartigen Testmustern
verwendet.
3.3 Abdeckung von Strukturmerkmalen
Die Frage, ob durch entwickelte Testfälle gründlich genug getestet wird, lässt sich durch
die Messung der Strukturabdeckung (engl. coverage) zum Teil beantworten. Diese liefert
einen Überblick darüber, für welche Bestandteile des Testobjektes – sei es ein verfeinertes
Modell oder auch Programmcode – noch keine Testfälle existieren. Hohe Abdeckung
23

3.3. Abdeckung von Strukturmerkmalen
impliziert, dass das zu prüfende Objekt in seiner Breite getestet wird, also nach Möglichkeit
fast all seine funktionalen Komponenten während der Testdurchführung mindestens
einmal ausgeführt werden.
In erster Linie sind kontrollflussorientierte Strategien zur Messung der Strukturabdeckung
zu nennen. Datenflussorientierte Strategien spielen in dieser Arbeit keine Rolle und werden
daher nicht behandelt. Die Messung der Strukturabdeckung erfolgt anhand des Kontrollflussgraphen,
der in Abschnitt 3.3.2 erklärt wird. In Abschnitt 3.3.3 werden die Begriffe
Abdeckungskriterium und Abdeckungsgrad definiert. Eine nähere Beschreibung der unterschiedlichen
in dieser Arbeit relevanten Abdeckungskriterien erfolgt in den Abschnitten
3.3.4 und 3.3.5 und folgt den Definitionen von Baresel [Bar00] und Chilenski [ChiMil94].
Es werden folgende Abdeckungskriterien behandelt:
• Anweisungsabdeckung (C 0 )
• Zweigabdeckung (C 1 )
• Bedingungsabdeckung
o Einfache (atomare) Bedingungsabdeckung (C 2 )
o Mehrfach-Bedingungsabdeckung (C 3 )
o Minimale Mehrfach-Bedingungsabdeckung
o Modifizierte Mehrfach-Bedingungsabdeckung (MC/DC)
• Pfadabdeckung (C 7 )
3.3.1 Bemerkung
Einleitend ist zu dem Thema Abdeckung zu bemerken, dass die Gründlichkeit von Tests
nicht nur aufgrund eines Abdeckungskriteriums bewertet werden sollte. Dies verdeutlicht
folgende C-Funktion:
int speed (int distance, int time) {
return distance/time;
}
Abbildung 3-10: Programmbeispiel in C
Mithilfe je eines Wertes für distance und time kann diese Funktion mit hundertprozentiger
Abdeckung getestet werden, wenn die Ausführung aller Anweisungen als
Abdeckungsmaß herangezogen wird. Dabei handelt es sich allerdings nur um eine von sehr
vielen Möglichkeiten – bei 16-Bit Integer 2 16 Möglichkeiten – bei der Wahl des Wertes
von time. In nur einem Fall kann ein Fehlverhalten der Funktion aufgedeckt werden,
wenn time den Wert Null annimmt und die Division durch null zu einem Laufzeitfehler
führt. Die Messung der Abdeckung allein kann folglich keine Aussage über die Qualität
von Testfällen treffen. Dem gegenüber steht der Fall, wenn keine hundertprozentige Abdeckung
durch eine Menge von Testmustern erreicht wird. Dies ist ein Indiz dafür, dass
weitere Testmuster erstellt werden sollten, um die bisherigen Testfälle zu vervollständigen.
24

3. Modellbasiertes Testen
Die gewählten Abdeckungskriterien hängen dabei stark vom vorliegenden Testobjekt ab.
Je nach Phase im Entwicklungsprozess kann es sich um ein Modell oder auch um
Programmcode handeln. Daher unterscheidet man in erster Linie Modellabdeckung und
Codeabdeckung.
3.3.2 Kontrollflussgraph
Ein Kontrollflussgraph ist eine Repräsentation eines Systems in Form eines gerichteten
Graphen G = (N, E, n start , n final ). Dieser besteht aus der Menge der Knoten N, einer zweistelligen
Relation E zwischen den Knoten, einem Startknoten n start und einem Endknoten
n final [Lig02].
Jeder Knoten aus der Menge der Knoten N des Kontrollflussgraphen entspricht – je nach
Testobjekt – einer nichtleeren Menge von Anweisungen des Programmcodes oder Grundblöcken
eines Modells. Innerhalb eines Knotens dürfen dabei keine Anweisungen oder
Grundblöcke mit Verzweigungen auftreten. Diese bilden lediglich als letzte Anweisung
bzw. als letzter Block die Abtrennung zum Folgeknoten.
Die Relation E = { (n i , n j ) : n i , n j ∈ N, i ≠ j } beschreibt die Menge der Verbindungen
zwischen den Knoten des Kontrollflussgraphen. Diese werden als Zweige des Kontrollflussgraphen
bezeichnet. Jeder Zweig (n i , n j ) ist eine gerichtete Kante, die vom Knoten n i
zum Knoten n j führt. Sie entspricht einem Kontrollfluss- oder Steuerungsübergang der
letzten Anweisung des Knotens n i zur ersten Anweisung des Folgeknotens n j .
Als Verzweigungspunkte werden Knoten bezeichnet, von denen mehrere Zweige abgehen.
Diese beschreiben bedingte Übergänge, die beispielsweise an Schleifenanweisungen,
bedingten Einzelanweisungen oder Verzweigungsanweisungen auftreten. Während der
Ausführung von Software bzw. eines Modells wird der Kontrollfluss an Verzweigungspunkten
in einen der zur Auswahl stehenden Zweige gelenkt. Hierzu erfolgt eine Auswertung
von Übergangsbedingungen, die zur Entscheidung für eine der Möglichkeiten dienen.
Ein einfaches Beispiel eines Kontrollflussgraphen ist anhand einer C-Funktion zur Berechnung
des Maximums von drei Werten in Abbildung 3-11 gegeben.
25

3.3. Abdeckung von Strukturmerkmalen
1
2
3
4
5
6
7
8
9
int maximum (int a, int b, int c)
{
int max;
if (b > c)
{
if (b > a)
max = b;
else
max = a;
}
else
{
if (c > a)
max = c;
else
max = a;
}
return max;
}
wahr
4
maximum ( 10, 20, 30)
wahr
3
5
1
2
falsch
(20 > 30)
falsch
(30 > 10)
wahr
6
falsch
7
8
9
Abbildung 3-11: C-Funktion maximum mit zugehörigem Kontrollflussgraphen (rechts)
3.3.3 Abdeckungskriterium und Abdeckungsgrad
Abdeckungskriterium. Unter einem Abdeckungskriterium werden Strukturmerkmale
eines Testobjektes verstanden, deren Ausführung während der Testdurchführung gefordert
wird. Bei strukturorientierten Testverfahren werden ein oder mehrere Abdeckungskriterien
als Testziele gewählt.
Abdeckungsgrad. Der Abdeckungsgrad cov criteria ist das Maß für die Vollständigkeit eines
strukturorientierten Testmusters in Bezug auf das Abdeckungskriterium criteria. Zu seiner
Berechnung wird die Anzahl durch Anwendung des Testmusters ausgeführter und durch
das Abdeckungskriterium geforderter Strukturkomponenten in Verhältnis zur Anzahl aller
betroffenen Strukturkomponenten gesetzt:
cov criteria =
_______________________________
ausgeführte betroffene Komponenten
alle betroffenen Komponenten
Testfallabdeckungsgrad. Der Abdeckungsgrad eines vollständigen Testfalls berücksichtigt
die Abdeckungsgrade seiner Testmuster. Da die Testmuster eines Testfalls bezüglich
eines Abdeckungskriteriums in der Regel nicht disjunkt sind, lässt sich der Testfallabdeckungsgrad
nicht als Summe der Abdeckungsgrade aller Testmuster berechnen. Er
errechnet sich aus dem Verhältnis der Strukturkomponenten, die durch mindestens ein
26

3. Modellbasiertes Testen
Testmuster des Testfalls ausgeführt werden, zu allen durch das Kriterium betroffenen
Strukturkomponenten.
mindestens in einem Testmuster ausgeführte betroffene Komponenten
cov __________________________________________________________
criteria =
alle betroffenen Komponenten
Anstelle der Bezeichnung Abdeckung (vgl. Pretschner [Pre03]) wird in der Literatur häufig
von Überdeckung gesprochen (vgl. Baresel [Bar00]). Dementsprechend werden die Synonyme
Überdeckungskriterium, Überdeckungsgrad und Testfallüberdeckungsgrad für die
soeben eingeführten Definitionen verwendet.
3.3.4 Codeabdeckung
Wenn das Testobjekt der Programmcode eines Systems ist, wird die Codeabdeckung
betrachtet. Als Abdeckungskriterien werden Strukturelemente herangezogen, wie z. B. die
Anweisungen, Zweige und Bedingungen der zu untersuchenden Software. Die einzelnen
Kriterien werden im Folgenden unter Angabe des Abdeckungsgrades beschrieben.
3.3.4.1 Anweisungsabdeckung
Das Kriterium der Anweisungsabdeckung (engl. statement coverage) untersucht die ausgeführten
Anweisungen der zu testenden Software. In der Literatur ist dieses Abdeckungskriterium
häufig unter dem Begriff C 0 -Abdeckung zu finden [Tha00]. Das Ziel ist es, eine
Menge von Testmustern zu finden, die zur vollständigen Ausführung der Programmanweisungen
führt. Der erreichte Abdeckungsgrad cov statements ist das Verhältnis der Anzahl
während der Tests ausgeführten Anweisungen zu der Anzahl aller Anweisungen des
Programms:
ausgeführte Anweisungen
cov
______________________
statements =
alle Anweisungen
Ein Test des in Abbildung 3-11 vorgestellten Programms mit dem Eingabevektor
⎛10
⎞
⎜ ⎟
5
e = ⎜20⎟
, der den Testdaten a = 10, b = 20, c = 30 entspricht, hat covstatements = als
⎜ ⎟
9
⎝30⎠
Abdeckungsgrad, da die Anweisungen 1, 2, 6, 7, 9 ausgeführt werden und die Funktion
maximum insgesamt aus neun Anweisungen besteht.
3.3.4.2 Zweigabdeckung
Die Zweigabdeckung (engl. branch coverage) fordert, dass jeder Zweig des Testobjektes
einmal durchlaufen wird. Sie wird häufig als C 1 -Abdeckung bezeichnet [Tha00]. Ein
Zweig wird hierbei durch eine Kante im Kontrollflussgraphen identifiziert. Dieser wird im
Folgenden als Tupel k = (s, t) dargestellt, wobei s und t die Nummern der Knoten sind,
zwischen denen eine Kante k liegt. Es werden Testdaten gesucht, die bei Durchführung des
Programms eine Menge von Pfaden erzeugen, in denen alle Kanten des Kontrollfluss-
27

3.3. Abdeckung von Strukturmerkmalen
graphen mindestens einmal enthalten sind. Der Abdeckungsgrad cov branches errechnet sich
als Verhältnis der Anzahl abgedeckter Kanten zur Anzahl aller Kanten des Kontrollflussgraphen.
ausgeführte Verzweigungen
cov ________________________
branches =
alle Verzweigungen
⎛10
⎞
⎜ ⎟
Der Eingabevektor e = ⎜20⎟
führt im Beispiel von Abbildung 3-11 zur Abdeckung der
⎜ ⎟
⎝30⎠
Zweige (1, 2), (2, 6), (6, 7) und (7, 9). Die übrigen Kanten (2, 3), (3, 4), (3, 5), (4, 9),
(5, 9), (6, 8) und (8, 9) wurden nicht ausgeführt. Der Abdeckungsgrad beträgt demnach
cov branches = 11
4 .
3.3.4.3 Bedingungsabdeckung
Durch das Kriterium der Bedingungsabdeckung wird die Vollständigkeit der Tests in
Bezug auf die Verzweigungs- und Wiederholungsbedingungen des Testobjektes untersucht.
Dieses Kriterium liegt unter anderem in vier verbreiteten Ausprägungen vor:
a) einfache (atomare) Bedingungsabdeckung,
b) Mehrfach-Bedingungsabdeckung,
c) minimale Mehrfach-Bedingungsabdeckung und
d) modifizierte Mehrfach-Bedingungsabdeckung.
1
2
3
4
5
6
7
int maximum (int a, int b, int c)
{
int max;
if (a > b && a > c)
max = a;
else
{
if (b > a && b > c)
max = b;
else
max = c;
}
return max;
}
3
1
2
5
7
4
6
Abbildung 3-12: Modifizierte C-Funktion maximum mit Kontrollflussgraphen
28

3. Modellbasiertes Testen
Die Bedingungen an Verzweigungs- und Wiederholungsanweisungen bestehen häufig aus
mehreren Einzelbedingungen. Einzelbedingungen, welche nicht aus mehreren Teilbedingungen
zusammengesetzt sind, werden als elementare oder atomare Bedingungen
bezeichnet. Diese atomaren Bedingungen werden mithilfe relationaler Terme, also unter
Verwendung von Vergleichsoperationen, beschrieben. Durch logische Verknüpfung bilden
sie den Gesamtausdruck einer Verzweigungs- oder Wiederholungsbedingung. Zur Erläuterung
der verschiedenen Kriterien zur Bedingungsabdeckung wurde die Funktion zur
Maximumberechnung in Abbildung 3-12 modifiziert.
a) Die atomare Bedingungsabdeckung ist das einfachste der vier genannten Bedingungsabdeckungskriterien
und ist in der Literatur unter der Bezeichnung C 2 -Abdeckung zu
finden [Tha00]. Sie fordert, dass sich in den Testdaten für jede atomare Bedingung jeder
Verzweigung mindestens ein Eingabevektor befindet, mit welchem die atomare Bedingung
als wahr (engl. true) bewertet wird; zusätzlich wird mindestens ein Eingabevektor gefordert,
mit dem sie als falsch (engl. false) ausgewertet wird. Das Kriterium stellt keine
Anforderungen an die Abdeckung von Kombinationen der Bewertungen vorkommender
atomarer Bedingungen. Der Abdeckungsgrad der C 2 -Abdeckung ist das Verhältnis der
Anzahl atomarer Bedingungen, die jeweils einmal als wahr und falsch ausgewertet
wurden, zur Anzahl aller atomaren Bedingungen des Testobjektes:
__________________________________________________
Jeweils mit wahr und falsch bewertete atomare Bedingungen
cov C2 =
alle atomaren Bedingungen
Abbildung 3-12 zeigt die modifizierte Funktion maximum, welche die Verzweigungsbedingungen
(a > b && a > c) und (b > a && b > c) beinhaltet. In ihnen sind die
atomaren Bedingungen (a > b), (a > c), (b > a) und (b > c) enthalten, deren Einfluss
auf die Bewertung der zwei zusammengesetzten Bedingungen in den folgenden
Tabellen verdeutlicht wird.
a > b a > c a > b && a > c
*1 falsch falsch falsch
*2 falsch wahr falsch
wahr falsch falsch
wahr wahr wahr
Tabelle 3-1: Wahrheitswertekombinationen für (a > b && a > c)
b > a b > c b > a && b > c
falsch falsch falsch
falsch wahr falsch
*1 wahr falsch falsch
*2 wahr wahr wahr
Tabelle 3-2: Wahrheitswertekombinationen für (b > a && b > c)
29

3.3. Abdeckung von Strukturmerkmalen
⎛10⎞
⎜ ⎟
Der Eingabevektor e 1
= ⎜20⎟
deckt von jeder atomaren Bedingung jeweils nur eine
⎜ ⎟
⎝30⎠
Bewertungsmöglichkeit ab; die atomaren Bedingungen (a > b), (a > c) und
(b > c) werden mit falsch bewertet, während (b > a) mit wahr bewertet wird. Dieser
Fall und seine Bewertung der Verzweigungsbedingungen sind in obigen Tabellen mit *1
gekennzeichnet. Die atomare Bedingungsabdeckung erfordert, dass das Testobjekt mit
mehr als einem Eingabevektor ausgeführt wird. Die zusätzliche in den Tabellen mit *2
⎛20⎞
⎜ ⎟
gekennzeichnete Ausführung mit e 2
= ⎜30⎟
bewertet die Teilbedingungen (a > c),
⎜ ⎟
⎝10
⎠
(b > a) und (b > c) mit wahr und (a > b) mit falsch. Die Hintereinanderausführung
des Programms mit e1 und e 2 führt demnach zu einem atomaren Abdeckungsgrad von
cov C2 = 2
1 . Zwei der vier atomaren Bedingungen der Funktion wurden mit beiden
Bewertungsmöglichkeiten ausgeführt, während in beiden Fällen (a > b) mit falsch und
(b > a) mit wahr bewertet wurden.
b) Die Mehrfach-Bedingungsabdeckung stellt stärkere Anforderungen an die Testdaten.
Sie fordert, dass die Verwendung der Testdaten zur Ausführung sämtlicher Kombinationen
der Wahrheitswerte aller atomaren Bedingungen jeder Verzweigungsbedingung führt, und
wird als C 3 -Abdeckung bezeichnet. Die Auswertung sämtlicher Kombinationen von
Teilbedingungen führt zur Auswertung sämtlicher Wahrheitswerte aller komplexen Bedingungen.
Dadurch ist die Zweigabdeckung C 1 in der C 3 -Abdeckung mit eingeschlossen,
d. h. vollständige C 3 -Abdeckung führt zu hundert Prozent C 1 -Abdeckung. Der Abdeckungsgrad
errechnet sich als Division der Anzahl der Verzweigungsbedingungen, deren
Teilbedingungen in sämtlichen Kombinationen getestet wurden, durch die Anzahl aller
Verzweigungsbedingungen:
cov C3 =
___________________________________________________
Mit allen Kombinationen bewertete Verzweigungsbedingungen
Alle Verzweigungsbedingungen
In diesem Fall muss das Testobjekt in der Regel mit mindestens vier Eingabevektoren
ausgeführt werden, um die vier möglichen Kombinationen zu testen, die an Verzweigungsbedingungen
mit zwei Teilbedingungen möglich sind. Bezogen auf das Beispiel aus
⎛30⎞
⎛20⎞
⎛20⎞
⎜ ⎟ ⎜ ⎟ ⎜ ⎟
Abbildung 3-12 decken die Eingabevektoren e 1
= ⎜20⎟
, e 2
= ⎜10⎟
, e 3
= ⎜30⎟
und
⎜ ⎟
⎝10
⎜ ⎟
⎠ ⎝30
⎜ ⎟
⎠ ⎝10⎠
⎛10⎞
⎜ ⎟
e 4
= ⎜10⎟
sämtliche Kombinationen der Verzweigungsbedingung (a > b && a > c) ab.
⎜ ⎟
⎝10⎠
Die von dieser Verzweigungsbedingung abhängige Bedingung (b > a && b > c) wird
30

3. Modellbasiertes Testen
jedoch nur in drei der vier Fälle ausgeführt, da bei Verwendung von e 1 bereits nach
Auswertung der ersten Verzweigungsbedingung a mit dem Wert 30 als Maximum feststeht.
Dadurch ergibt sich ein Abdeckungsgrad von cov C3 = 2
1 , da nur die erste
Verzweigungsbedingung dem Abdeckungskriterium entsprechend getestet wurde.
c) Die minimale Mehrfach-Bedingungsabdeckung fordert für jede atomare oder zusammengesetzte
Verzweigungsbedingung, dass mithilfe der Eingabedaten für jede in der
Bedingung enthaltene Teilbedingung und auch zusammengesetzte Teilbedingung beide
Wahrheitswerte getestet werden. Dabei ist nicht die Ausführung aller Kombinationen
gefordert.
⎛20⎞
⎛20⎞
⎜ ⎟
⎜ ⎟
Die Eingabedaten e 1
= ⎜10
⎟ und e 2
= ⎜30⎟
genügen bezüglich des Beispiels aus
⎜ ⎟
⎝30
⎜ ⎟
⎠
⎝10⎠
Abbildung 3-12 diesem Abdeckungskriterium. Der Eingabevektor e 1 bewertet die in den
beiden Verzweigungsbedingungen enthaltenen Teilbedingungen wie folgt: a > b mit
wahr, und die übrigen Teilbedingungen mit falsch. Der Eingabevektor e 2 hat den exakt
gegenteiligen Effekt und bewertet die Teilbedingungen wie folgt: a > b mit falsch, und
die übrigen Teilbedingungen mit wahr. Somit ergibt sich eine hundertprozentige Abdeckung
bezüglich des Kriteriums der minimalen Mehrfach-Bedingungsabdeckung.
d) Die modifizierte Mehrfach-Bedingungsabdeckung ist in eine andere Richtung
ausgelegt als die minimale Mehrfach-Bedingungsabdeckung. Sie fordert, dass für jede
Teilbedingung ihr Einfluss auf die Bewertung der Gesamtbedingung überprüft wird. Es
muss für jede Teilbedingung gezeigt werden, dass eine Änderung der Bewertung einer
jeden von ihnen den Wahrheitswert der Gesamtbedingung ändern kann, wenn die Bewertungen
der übrigen Teilbedingungen nicht verändert werden. Der Abdeckungsgrad
errechnet sich wiederum als Division der Anzahl der Verzweigungsbedingungen, die
ausreichend getestet wurden, durch die Anzahl aller Verzweigungsbedingungen:
cov MC/DC =
Mit allen für MC/DC
_____________________________________________________
relevanten Kombinationen bewertete Verzweigungsbedingungen
Alle Verzweigungsbedingungen
In der Literatur ist dieses Kriterium auch als MC/DC-Abdeckung (engl. Modified
Condition / Decision Coverage) zu finden. Für das Beispiel aus Abbildung 3-12 erfüllen
⎛30⎞
⎛20⎞
⎛20⎞
⎜ ⎟ ⎜ ⎟ ⎜ ⎟
die Testdaten e 1
= ⎜20⎟
, e 2
= ⎜10⎟
und e 3
= ⎜30⎟
dieses Kriterium für die Verzweigungsbedingung
(a > b && a > c). Ausgehend von der Bewertung, mit der beide Teilbedin-
⎜ ⎟
⎝10
⎜ ⎟
⎠ ⎝30
⎜ ⎟
⎠ ⎝10⎠
gungen mit wahr bewertet wurden (e1) und somit die Gesamtbedingung (a > b && a > c)
wahr ist, wird mit e 2 die rechte Teilbedingung mit falsch und somit die Gesamtbedingung
mit falsch bewertet. Der dritte Eingabevektor bewertet dementsprechend die linke Teilbedingung
mit falsch und auch die Gesamtbedingung mit falsch. Dieselben drei
31

3.3. Abdeckung von Strukturmerkmalen
Eingabevektoren erfüllen allerdings für (b > a && b > c) nicht das Kriterium. Die drei
vorgestellten Eingabevektoren führen demnach zu einem Abdeckungsgrad von
cov MC/DC = 2
1 .
3.3.4.4 Pfadabdeckung
Die Pfadabdeckung (engl. path coverage) ist das umfangreichste Abdeckungskriterium und
fordert die Ausführung aller möglichen Pfade des Testobjektes. Im Beispiel von Abbildung
3-11 sind vier Pfade möglich. Bei komplexeren Systemen übersteigt die Ausführung sämtlicher
Pfade allerdings die Möglichkeiten der Tester. Zudem können im Testobjekt
Schleifen ohne obere Grenzen der Iterationszahl vorkommen, wodurch eine unendliche
Anzahl von Pfaden zu testen wäre. Aufgrund dessen wird die Pfadabdeckung in der Praxis
nur in einfachen, überschaubaren Systemen verwendet und hat in dieser Arbeit keine
weitere Relevanz. Sie wird in der Literatur als C 7 -Abdeckung bezeichnet [Hart01].
3.3.5 Modellabdeckung
Unter Modellabdeckung wird die Abdeckung von Modellkomponenten verstanden. Je nach
Art des vorliegenden Modells sind seine Bestandteile sehr unterschiedlich. Ebenso
variieren dementsprechend die Abdeckungskriterien, unter deren Berücksichtigung das
Modell getestet werden soll. Die für die Codeabdeckung genannten Kriterien lassen sich
zum Teil auf Modelle übertragen. Im Folgenden werden die Abdeckungskriterien für
Modelle in Simulink und Stateflow beschrieben, da diese vornehmlich in dieser Arbeit
verwendet werden.
3.3.5.1 Zustandsabdeckung
Die Anweisungsabdeckung besitzt keine äquivalente Entsprechung bei der Betrachtung
von Modellen. Ein nahe liegendes Abdeckungskriterium ist die Abdeckung von Grundblöcken,
aus denen ein Modell besteht. Jeder Grundblock entspricht dabei in der Regel
einer Menge von Anweisungen. Eine Ausprägung in Bezug auf Stateflowmodelle ist die
Zustandsabdeckung (engl. state coverage). Das damit verbundene Testziel ist, jeden im
Statechart vorkommenden Zustand (State) mithilfe der Testdaten mindestens einmal zu
durchlaufen. Der Abdeckungsgrad errechnet sich hierbei als Verhältnis der durch die Testdaten
abgedeckten Zustände des Statecharts und der insgesamt vorhandenen Zustände.
3.3.5.2 Zweigabdeckung
Das Kriterium Zweigabdeckung kann auf Modelle übertragen werden. Zur Erfüllung
dieses Kriteriums wird eine Menge von Testdaten benötigt, die für jede Verzweigung im
Simulinkmodell – beispielsweise an Blöcken wie Logical Operator, Relational Operator,
Switch – alle möglichen Werte berechnet. Für das in Abbildung 3-13 gezeigte Modell
werden zwei Eingabevektoren benötigt, um bzgl. der Zweigabdeckung das Modell ausreichend
zu testen: e = ( 0)
und e = ( 2)
1 2
. Im ersten Fall würde der Block Relational Operator
den Vergleich mit falsch bewerten, im zweiten Fall mit wahr. Der Abdeckungsgrad dieses
32

3. Modellbasiertes Testen
Kriteriums ist das Verhältnis der Anzahl der Blöcke, die jeweils einmal mit wahr und
einmal mit falsch bewertet wurden, zu den insgesamt vorhandenen Blöcken, die bzgl. der
Zweigabdeckung relevant sind.
Abbildung 3-13: Beispiel in Simulink zur Zweigabdeckung
3.3.5.3 Bedingungsabdeckung
Die vier Kriterien zur Bedingungsabdeckung lassen sich ebenfalls auf Modelle übertragen.
In Simulink kommen Bedingungen unter anderem in den bereits beim Kriterium Zweigabdeckung
genannten Blöcken vor, in Stateflow in den Zustandsübergängen. Abbildung
3-14 zeigt eine atomare Bedingung für den Zustandsübergang (Transition) vom Zustand S1
zum Zustand S2. Diese wird beispielsweise mit den Testdaten e = 1
() 1 und
e = 2
( 20)
vollständig abgedeckt.
Abbildung 3-14: Beispiel in Stateflow zur Bedingungsabdeckung
3.3.6 Bemerkungen
Wie bereits erwähnt, können Tests, die am Modell durchgeführt wurden, im modellbasierten
Entwicklungsprozess zur Überprüfung des Verhaltens einer Implementierung in
Form von Programmcode herangezogen werden. Dabei werden die während der Modelltests
aufgezeichneten Ausgabedaten als Referenzdaten für die Implementierungstests
verwendet (vgl. Back-to-Back-Test in Kapitel 3.2.4). Eine vollständige Abdeckung des
Modells bzgl. der genannten Kriterien impliziert allerdings nicht die vollständige Abdeckung
der Implementierung.
Ein gutes Beispiel hierfür ist das in Abbildung 3-15 gezeigte Simulinkmodell. Wenn dieses
mithilfe des C-Codes aus Abbildung 3-12 realisiert wird, stimmen die Werte zur Zweigabdeckung
nicht überein. Mit nur einem Testdatum mit a als Maximum wird vom Modell
genau ein Zweig abgedeckt. Dieser am Modell bestimmte Abdeckungsgrad von
cov branches = 3
1 beträgt für das C-Codebeispiel aus Abbildung 3-12 covbranches = 8
3 und für
Abbildung 3-11 cov branches = 11
4 .
33

3.4. Methoden zur Testfallerstellung
Die Übertragung der Abdeckungskriterien von Codeabdeckung zu Modellabdeckung oder
auch umgekehrt ist demzufolge prinzipiell möglich; die Werte der Abdeckungsgrade
können sich dennoch deutlich unterscheiden [ConSad02].
Abbildung 3-15: Modell zur Berechnung des Maximums von drei Werten
Die von Programmen berechneten Abdeckungsgrade hängen zusätzlich auch von deren
Implementierung ab. Die in den vorherigen Kapiteln eingeführten Vorschriften für die
Berechnung der Abdeckungsgrade sind nur beispielhaft und werden in der Literatur unterschiedlich
ausgelegt. Zusätzlich ist der Inhalt eines Kontrollflussgraphen nicht allgemein
festgelegt. Ein Knoten kann beispielsweise aus einer einzelnen Anweisung bestehen oder
gleich aus einer ganzen Abfolge.
Je nach Implementierung des Kontrollflussgraphen wird Abdeckungsgrad unterschiedlich
berechnet. Der in Abbildung 3-11 vorgestellte Kontrollflussgraph kann auf acht Knoten
reduziert werden, da der erste Knoten für den Kontrollfluss nicht wichtig ist und in den
zweiten mit einfließen kann. Der Wert für die Zweigabdeckung aus dem vorherigen Absatz
würde sich somit von 8
3 auf 7
3 erhöhen, da im reduzierten Graphen eine Kante weniger
vorkommt. Wichtig für den Kontrollflussgraphen ist an dieser Stelle, dass nur die letzte
Anweisung eines Knotens, der eine Sequenz von Anweisungen repräsentiert, eine
Verzweigung sein darf.
3.4 Methoden zur Testfallerstellung
In diesem Unterkapitel erfolgt eine Beschreibung verschiedener Methoden zur Testfallerstellung.
An dieser Stelle wird nicht nur auf die Verfahren eingegangen, die im modellbasierten
Entwicklungsprozess Anwendung finden, sondern auch auf verwandte Verfahren
aus dem Hardware- und Softwaretest. Diese können wie auch das in dieser Arbeit entwickelte
Verfahren (siehe Kapitel 4) der Erzeugung von Back-to-Back-Tests aus einer
Systemrepräsentation zur Überprüfung einer daraus erzeugten Repräsentation. In dieser
Arbeit handelt es sich hierbei um ein Modell, aus dem Testfälle zur Überprüfung einer
daraus entwickelten Implementierung. Diese kann entweder in Gestalt eines Implementierungsmodells
oder auch als Programmcode vorliegen.
Die Generierung von Testmustern für Back-to-Back-Tests aus einem Modell erfordert,
dass dieses in einem validierten Zustand vorliegt. Dadurch eignen sich auf diese Weise
erzeugte Referenzdaten zur Überprüfung späterer Systemrepräsentationen. Der Vergleich
34

3. Modellbasiertes Testen
der Ausgabedaten eines derartigen Tests mit den am Modell generierten Referenzdaten
führt dazu, dass dieses dadurch indirekt gegen die Benutzeranforderungen validiert wird.
Kapitel 3.4.1 führt ein manuelles Black-Box-Testverfahren ein. Bei diesem handelt es sich
um die Klassifikationsbaummethode. Die Verfahren zur Testmustergenerierung, die eine
Strukturabdeckung als Testziel haben, erzeugen Testfälle, die ausgewählten, bereits in
Unterkapitel 3.3 eingeführten Abdeckungskriterien genügen. Die Unterkapitel 3.4.2 bis
3.4.4 beschäftigen sich mit ausgewählten Verfahren zur automatischen Erstellung
derartiger Testmuster. In Abschnitt 3.4.5 wird auf das aus dem Hardwarebereich stammende
Konzept der Fehlermodelle eingegangen.
3.4.1 Klassifikationsbaummethode
Die Klassifikationsbaummethode (engl. classification tree method, CTM) ist ein Verfahren
zur methodischen abstrakten Beschreibung von Testfällen, welches Anfang der 1990er
Jahre von der Daimler Benz AG (heute Daimler Chrysler AG) entwickelt wurde. Es dient
der kompakten grafischen Repräsentation von Testfällen [Weg93, Con04].
Das Testziel der Klassifikationsbaummethode ist immer die Überprüfung des Verhaltens
eines Systems während eines speziellen Szenarios. Der erzeugte Testfall zielt dabei auf die
Überprüfung einer ausgewählten Systemfunktionalität ab, zu der ein Testentwickler
anhand der vorliegenden Spezifikation einen zeitlichen Ablauf erstellt, in dem das Testobjekt
mit festgelegten Eingabedaten stimuliert und seine Ausgabe mit Referenzdaten
verglichen wird.
Der CTM liegt die grundsätzliche Idee zugrunde, den Eingabedatenraum des Testobjektes
in logisch zusammengehörige Bereiche zu zerlegen. Dazu werden die Eingabeschnittstellen
des Testobjektes anhand verschiedener Kriterien geordnet, die als Klassifikationen
bezeichnet werden. Eine weitere Unterteilung des Eingabedatenraums einzelner Klassifikationen
in Wertebereiche wird als Klasse oder auch Äquivalenzklasse bezeichnet.
Der zugrunde liegende Gedanke ist die Uniformitätshypothese. Diese nimmt an, dass eine
Menge von Eingabedaten während der Testdurchführung zu einem ähnlichen – im Idealfall
zu einem identischen – Systemverhalten führt. Die einzelnen Werte werden dabei als
untereinander uniform bezeichnet [Bar97]. Die Gesichtspunkte zur Unterteilung der Wertebereiche
in Klassen werden dementsprechend gewählt. Aufgrund der Uniformität der
Werte einer Klasse wird diese als Äquivalenzklasse bezeichnet.
Als Basis für eine Aufteilung in Äquivalenzklassen dient in der Regel die funktionale
Spezifikation, in der das gewünschte Verhalten des Testobjektes beschrieben ist. Anhand
der Spezifikation wählt der Tester die Gesichtspunkte zur Unterteilung der Wertebereiche
einzelner Eingabeschnittstellen aus. Die Unterteilung in Äquivalenzklassen erfolgt vollständig
und disjunkt. Dies bedeutet, dass der gesamte mögliche Wertebereich von
Eingabewerten abgedeckt wird und die jeweiligen Teilbereiche sich untereinander nicht
überschneiden. Die erstellten Klassen können wiederum für sich verfeinert, also in weitere
Unterklassen unterteilt werden.
35

3.4. Methoden zur Testfallerstellung
Das Ergebnis einer vollständigen Klassifizierung ist der Klassifikationsbaum. Dieser bildet
den Kopf einer Kombinationstabelle, deren Zeilen Testschritte definieren 1 . Ein Testschritt
beschreibt abstrakt den Zustand sämtlicher Eingangsschnittstellen zu einem bestimmten
Zeitpunkt, abstrahiert dabei allerdings von konkreten Testmustern. Jede Zeile einer Kombinationstabelle
ist somit die abstrakte Beschreibung eines Testvektors, welcher gemäß der
Definition aus Abschnitt 3.1.2 konkrete Eingabe- und Referenzdaten zu einem Zeitpunkt
der Testdurchführung beinhaltet. Pro Testschritt wird von jeder Klassifikation eine
Äquivalenzklasse ausgewählt. Dadurch werden allen Eingabeschnittstellen abstrakte Werte
in Form der Wertebereiche der gewählten Klassen zugeordnet.
Abbildung 3-16: Klassifikationsbaum und Kombinationstabelle
Ein einfaches Beispiel eines Klassifikationsbaums mit zugehöriger Kombinationstabelle
wird in Abbildung 3-16 in Anlehnung an [Lam04] vorgestellt. Diese zeigt den Überholvorgang
eines Autos, welches anhand der Klassifikationen Gaspedal, Lenkung und Bremse
beschrieben wird. Die vorgestellte Kombinationstabelle beschreibt ein Szenario, welches
nach zehn Sekunden der Testdurchführung die Wahl eines Wertes der Klasse ]75, 100[ für
den Systemeingang Gaspedal vorsieht. Die Interpretation dieser Klasse liefert einen Wert
im Bereich zwischen 75 und 100 Prozent des möglichen Maximalwertes, den der Eingang
Gaspedal annehmen kann. Zeitgleich wird geradeaus gelenkt und die Bremse nicht
betätigt.
1 [Con04] bezeichnet im Gegensatz zu dieser Arbeit jeden Testschritt als Testfall.
36

3. Modellbasiertes Testen
3.4.2 Zufallsbasierte Testmustergenerierung zur Strukturabdeckung
Die einfachste Form der Testmustergenerierung ist die Erzeugung zufälliger Sequenzen
von Eingabedaten, unter deren Verwendung das zu testende System während der Testdurchführung
stimuliert wird (vgl. Kapitel 3.2.4 Zufallstest). In Abbildung 3-17 wird das
diesem Abschnitt zugrunde liegende Verfahren zur Erzeugung von Back-to-Back-Tests als
UML-Aktivitätsdiagramm (Unified Modeling Language [UML]) vorgestellt. Es verwendet
zufällig erzeugte Testmuster und hat eine möglichst hohe Abdeckung ausgewählter
Strukturmerkmale als Testziel.
Erzeugen eines neuen Testmusters
Messen des Abdeckungsgrades
anhand des Modells
[Coverage < 100%]
Berechnen des Testfallabdeckungsgrades
[Coverage == 100%]
Ausgabe des Testfalls
Abbildung 3-17: Zufallsbasierte Testmustergenerierung
Das Vorgehen kann als das allgemeine zufallsbasierte Verfahren zur Erzeugung von
strukturorientierten Testfällen für Back-to-Back-Tests angesehen werden. Dabei wird
versucht mit einem Testfall, der aus mehreren Testmustern besteht, einen Abdeckungsgrad
von hundert Prozent bezüglich eines ausgewählten Abdeckungskriteriums zu erreichen.
Die Wahl des Kriteriums spielt für das Verfahren an sich keine Rolle und wird deshalb
nicht weiter beachtet.
Die Generierung erfolgt in einem zyklischen Ablauf. Pro Zyklus wird ein neues Testmuster
anhand einer ausgewählten Systemrepräsentation in Form eines Modells erzeugt. Im
modellbasierten Entwicklungsprozess kann es sich dabei beispielsweise um das Funktionsmodell
handeln. Zur Generierung eines Testmusters werden nur die Wertebereiche der
Eingabeschnittstellen des Modells berücksichtigt. Für diese wird eine Menge von Eingabe-
37

3.4. Methoden zur Testfallerstellung
daten zufällig erzeugt. Ebenfalls entstehen an dieser Stelle die für die Testdurchführung
der erzeugten Back-to-Back-Tests benötigten Referenzdaten. Daran anschließend erfolgt
die Messung des Abdeckungsgrades des soeben erzeugten Testmusters. Auch dies erfolgt
anhand des vorliegenden Modells. Aus dem ermittelten Abdeckungsgrad des neu erzeugten
Testmusters und den Abdeckungsgraden der in früheren Zyklen generierten Testdaten wird
der Testfallabdeckungsgrad (vgl. Unterkapitel 3.3.3) berechnet.
Das Verfahren beendet die Testmustergenerierung, sobald der Testfallabdeckungsgrad
hundert Prozent erreicht hat. Ebenfalls ist eine Beschränkung der maximal erzeugten
Testmuster sinnvoll, um die Laufzeit zu begrenzen.
3.4.3 Testmustergenerierung mit Evolutionären Algorithmen
Die Erzeugung von Strukturtests mit Evolutionären Algorithmen folgt im Wesentlichen der
zufälligen Erstellung von Testmustersequenzen. Es gibt allerdings auch deutliche Unterschiede.
Evolutionäre Algorithmen folgen dem natürlichen Phänomen der biologischen
Evolution. Nach Darwins Theorie der natürlichen Auslese erfolgt in diesem Verfahren die
Erzeugung neuer Daten aus einer zuvor generierten Menge von Daten. Im Fall der Testmustergenerierung
handelt es sich bei diesen Daten um Sequenzen von Eingabedaten zur
Erzeugung von Testmustern [Bar00].
Evolutionsalgorithmen oder Evolutionäre Algorithmen folgen dem biologischen Vorbild
der Evolution. Sie bilden den Prozess der Entwicklung einer Art nach. Dieser wird als eine
Form von Optimierungsprozess gesehen, dessen Ziel es ist, durch Manipulation von Erbinformationen
eine Lebensform an sich ändernde Umwelt- und Lebensbedingungen in
kurzen Zeiträumen anzupassen. Die Evolution ist hierbei eine Art Suchprozess, welcher in
der Vielzahl von erzeugbaren Erbinformationen diejenigen aussucht, welche eine Lebensform
am besten an seine Umwelt anpassen und dadurch die Arterhaltung sichern [Schö94].
Diesem Prinzip folgend ist das Ziel der Testmustergenerierung, die Erzeugung möglichst
guter Testmuster. Im Folgenden wird der Ablauf der Testmustergenerierung mittels
Evolutionärer Algorithmen vorgestellt.
Der wesentliche Unterschied zum allgemeinen Verfahren zur zufallsbasierten Erzeugung
von Testmustern liegt in der Art ihrer Erzeugung. Während im allgemeinen Verfahren aus
Abschnitt 3.4.2 immer nur ein Testmuster erzeugt wird, werden im Verfahren mit Evolutionären
Algorithmen immer mehrere gleichzeitig betrachtet, welche eine Population von
Testmustern bilden. Aus einer Anfangspopulation (engl. Initial Population) wird nach und
nach eine Population mit besseren Eigenschaften gebildet. Das hierzu notwendige
Verfahren ist zyklisch aufgebaut und in Abbildung 3-18 dargestellt, welche den Grundaufbau
eines Evolutionären Algorithmus zur Testmustergenerierung nach Sthamer [Sth et al.
01] und Wegener [Weg02] zeigt.
Schöneburg identifiziert drei Prinzipien, auf denen die Evolution beruht: die Selektion
(engl. Selection) einzelner Individuen aufgrund ihrer Tauglichkeit, die Rekombination
(engl. Recombination) der Erbinformationen und die Mutation (engl. Mutation) des Erbgutes.
Die Selektion ist für die Steuerung der Evolution zuständig. Sie bestimmt durch
38

3. Modellbasiertes Testen
Auswahl von Individuen aufgrund einer Bewertung, welche Eigenschaften einer Population
in die nächste Generation übergehen und welche wegfallen. Die Rekombination
vereint die Eigenschaften einer Population, indem es die Eigenschaften einzelner
Individuen kombiniert und in neu erzeugte Individuen einfließen lässt. Die Mutation dient
dem alleinigen Zweck, Varianten und Alternativen zu erzeugen. Dies erfolgt, indem
einzelnen Individuen neue Eigenschaften zufällig hinzugefügt werden, die gegebenenfalls
in der Population noch nicht enthalten sind [Schö94].
Reinsertion
Initial population
Mutation
Fitness evaluation
Recombination
Selection
Test results
Abbildung 3-18: Ablauf eines Evolutionären Algorithmus [Sth et al. 01], [Weg02]
Die Übertragung dieser allgemeinen Prinzipien auf die Testmustergenerierung führt zu
folgendem Vorgehen: Es wird eine zufällige Anfangspopulation von Testmustern erzeugt.
Jedes Testmuster wird als Individuum betrachtet und einer Bewertung unterzogen. Unter
der Zielsetzung, Strukturtests zu erzeugen, werden ein oder mehrere Abdeckungskriterien
zur Bewertung herangezogen. Aufgrund eines Fitnesswertes für jedes Individuum werden
die Testmuster einer Population untereinander verglichen. Als Fitnesswert kommt
beispielsweise der Abdeckungsgrad infrage.
Aufgrund des Fitnesswertes erfolgt die Selektion. Diese wählt einen Teil der Population –
beispielsweise die Hälfte mit den höheren Fitnesswerten – aus und bildet daraus eine neue
Generation von Testmustern. Während der Rekombination erfolgt eine Kombination dieser
Testmuster zu neuen Testmustern, welche in die neu erstellte Generation aufgenommen
werden. Die Art der Kombination kann beliebig erfolgen. Es können einzelne Testdaten
oder auch ganze Sequenzen von Testmustern ausgetauscht werden. Im nächsten Schritt
39

3.4. Methoden zur Testfallerstellung
werden der Generation durch Mutation neue Testdaten zufallsbasiert hinzugefügt. Die
durch diese Schritte entstandene Generation geht als Population in den nächsten Zyklus
ein. Pro Zyklus entsteht durch dieses Verfahren eine Population von Testmustern, welche
die besten Eigenschaften der vorherigen Generation beibehält.
Aufgrund eines Abbruchkriteriums erfolgt am Ende des Verfahrens die Ausgabe der besten
Testmuster. Hierzu kann beispielsweise die Menge der insgesamt im Verfahren erzeugten
Testmuster als obere Schranke herangezogen werden. Sollte als Testziel ein Abdeckungskriterium
dienen, kann das Verfahren bereits zwischenzeitlich terminieren, sobald ein
Testmuster erzeugt wurde, welches zu hundertprozentiger Abdeckung führt.
3.4.4 Analytische Testmustergenerierung
Während die drei zuvor behandelten Verfahren vom grundsätzlichen Vorgehen her ohne
Systemwissen Testdaten erzeugen, wird in diesem Abschnitt ein Verfahrensansatz behandelt,
welcher direkt aus dem Aufbau eines Systems durch Analyse und Berechnung
Testdaten bestimmt. Hierbei werden andere Strukturmerkmale als die in Kapitel 3.3
vorgestellten Abdeckungskriterien als Testziele verwendet.
Als Testbasis dient wie in den zuvor beschriebenen Verfahren ebenfalls eine Systemrepräsentation
in Form eines Modells. Für jeden Block wird anhand von festgelegten Regeln
eine Menge von Wertebereichen bestimmt, aus denen der Block mit jeweils mindestens
einem Wert während der Testdurchführung ausgeführt werden muss, um diesen abzudecken
[Her05]. Um dieses Vorgehen zu verdeutlichen, ist in Abbildung 3-19 ein Beispielsystem
gegeben. Dieses berechnet mithilfe eines Blocks Gain das Dreifache des Eingangssignals
In1 und begrenzt durch einen Saturation-Block den errechneten Wert auf minimal
sieben und maximal hundert.
Abbildung 3-19: Propagierung von Wertebereichen [Her05]
Die analytische Testmustergenerierung bestimmt anhand von festen Regeln, die pro
Blocktyp vorgegeben sind, für jeden Block die Wertebereiche, anhand derer die
Abdeckung gemessen wird. Im Beispiel ergeben sich für den Saturation-Block die Wertebereiche
D S1 = {x | x ≤ 7}, D S2 = {x | 7 < x < 100} und D S3 = {x | x ≥ 100}, welche die
Wertebereiche oberhalb der oberen Schranke und unterhalb der unteren Schranke und den
Wertebereich innerhalb der Schranken des Saturation-Blocks beschreiben. Für den Gain-
40

3. Modellbasiertes Testen
Block werden die Wertebereiche D G1 = {x | x ≥ 0} und D G2 = {x | x < 0} gewählt, welche
darauf abzielen, den Block mit einem negativen und einem positiven Wert auszuführen.
Die Testfallgenerierung muss aus diesen Wertebereichen Testdaten wählen. Hierbei ist zu
berücksichtigen, dass für den Saturation-Block diese nicht direkt erzeugt werden, da der
Block nicht unmittelbar von einem Eingangssignal stimuliert wird. Vielmehr müssen für
den Signaleingang In1 derartige Werte generiert werden, dass nach einer Berechnung
durch den Gain-Block passende Werte in die Ausführung des Saturation-Blocks eingehen.
Zu diesem Zweck werden im Verfahren der analytischen Testmustergenerierung die
Wertebereiche im Signalfluss nach vorne propagiert. Aus den Wertebereichen der Einzelblöcke
werden Wertebereiche für die Signaleingänge berechnet. Im Fall des
Beispielsystems aus Abbildung 3-19 entstehen die Wertebereiche D In1_1 = {x | x < 0},
D In1_2 = {x | 0 ≤ x ≤ 7/3}, D In1_3 = {x | 7/3 < x < 100/3} und D In1_4 ={x| x ≥ 100/3}. Der
Wertebereich D In1_1 deckt direkt den Wertebereich D G2 des Gain-Blocks ab, während zur
Abdeckung von D G1 die Wertebereiche D In1_2 , D In1_3 und D In1_3 benötigt werden. Entsprechendes
gilt für die Abdeckung der Wertebereiche des Saturation-Blocks.
Die erzeugten Wertebereiche für die Eingabeschnittstellen des Systems werden zur Erstellung
konkreter Testmuster verwendet. Pro Wertebereich wird ein Testdatum ausgewählt.
Dies kann zufällig oder auch durch die Wahl eines Mittelwertes erfolgen. Die Menge der
auf diese Weise erzeugten Testdaten führt zur Abdeckung der blockspezifischen Wertebereiche.
Für Zyklen in Simulink und auch Statecharts, in denen nicht direkt die Möglichkeit
besteht, durch Rückwärtspropagieren an den Eingabeschnittstellen benötigte Werte zu
berechnen, müssen zeitliche Aspekte berücksichtigt werden. In Simulinkzyklen und
Statecharts spielen die in vorherigen Zeitschritten verwendeten Testdaten eine wichtige
Rolle und haben direkten Einfluss auf den aktuellen Systemzustand. Auf die Behandlung
dieses Problems wird in [Her05] nicht näher eingegangen.
Die analytische Testmustergenerierung für auf Statecharts basierende Systeme wird in
[Cha04] vorgestellt. Es wird einen Verfahrensansatz beschrieben, in dem direkt aus der
Struktur eines Statecharts Testmuster erzeugt werden, welche beispielsweise zur Ausführung
sämtlicher Zustände (vgl. Abschnitt 3.3.5.1) führen. Zu diesem Zweck werden
Statecharts in einem ersten Schritt stark vereinfacht. Dies erfolgt zum einen durch den
Abbau von Parallelität zum anderen auch durch Abbau von Hierarchieebenen. Ebenfalls
dürfen die verwendeten Statecharts nur in den Zustandsübergängen Ausgaben erzeugen,
während Statecharts im Allgemeinen auch Ausgaben in einzelnen Zuständen erlauben.
3.4.5 Fehlermodelle im Hardwaretest
Während die bisher vorgestellten Verfahren zur Testfallerzeugung hauptsächlich im
Softwarebereich ihre Anwendung finden, behandelt dieser Abschnitt den Aspekt der
Fehlermodelle zur Erstellung von strukturorientierten Hardwaretests. Hierbei dient als
Testbasis eine kombinatorische Logikschaltung. Zusätzlich wird ein so genanntes Fehler-
41

3.4. Methoden zur Testfallerstellung
modell herangezogen. Dieses beruht darauf, dass innerhalb einer Schaltung eine bestimmte
Art von Fehlern angenommen wird. Aufgrund dieser angenommenen Fehler werden Testmuster
generiert, die zur Überprüfung der Existenz bzw. Abwesenheit dieser expliziten
Fehler verwendet werden. Bevor auf die eigentliche Testmustergenerierung eingegangen
wird, wird im Folgenden zuerst auf ein ausgewähltes Fehlermodell eingegangen.
Das Fehlermodell für Haftfehler (engl. Stuck-at-Fault) ist das einfachste Fehlermodell und
wurde bereits in den 50er Jahren entwickelt [VieMis04]. Es behandelt einfache Fehler
einzelner Signalleitungen einer digitalen Schaltung, welche permanent entweder auf dem
Wert logisch Eins oder logisch Null liegen. Durch einen derartigen Fehler ist ein Signalwechsel
auf der betroffenen Leitung nicht mehr möglich und das System verhält sich
fehlerhaft. Die Bezeichnung für einen derartigen Fehler ist „Haftfehler bezüglich des
Wertes 0 bzw. 1“. Die für die Eingangs- und Ausgangsleitungen eines AND-Gatters denkbaren
Haftfehler sind in Abbildung 3-20 mit s-a-0 (engl. stuck at 0) bzw. s-a-1 (engl. stuck
at 1) gekennzeichnet.
Abbildung 3-20: Haftfehler-Modell an einem AND-Gatter [VieMis04]
Die Testmustergenerierung bezieht das Fehlermodell wie folgt ein. Für jeden angenommenen
Fehler müssen Testdaten generiert werden, welche bei der Testdurchführung den
angenommenen Haftfehler aufdecken, wenn dieser vorliegen sollte. In diesem Zusammenhang
wird von Fehlerüberdeckung gesprochen. Eine vollständige Abdeckung aller
angenommenen Haftfehler führt dazu, dass jeder vorhandene Haftfehler während der
Testdurchführung gefunden wird. Sollte bei hundertprozentiger Haftfehlerüberdeckung
kein Fehler entdeckt worden sein, ist dies – bei korrekter Testfallerstellung und korrekter
Testdurchführung – ein Beweis dafür, dass derartige Fehler im überprüften System nicht
vorkommen.
Das Haftfehlermodell kann – wie jedes Fehlermodell – in zwei Ausprägungen betrachtet
werden. Der einfachere Fall ist das Einzelfehlermodell. Dieses geht davon aus, dass in
einer Schaltung nur ein einziger Haftfehler vorkommt. Diese Betrachtung berücksichtigt
unter anderem nicht, dass mehrere Fehler gleichzeitig auftreten und sich unter Umständen
während der Testdurchführung gegenseitig aufheben können, wodurch sie nicht gefunden
werden. Das Mehrfachfehlermodell berücksichtigt dies. Es wird stets von mehreren gleich-
42

3. Modellbasiertes Testen
zeitig auftretenden Haftfehlern an verschiedenen Stellen eines Systems ausgegangen. Eine
vollständige Fehlerabdeckung bzgl. eines Mehrfachfehlermodells ist allerdings nur für
kleine Systeme mit wenigen Gattern und Signalleitungen praktikabel, da die Anzahl der
möglichen Mehrfachhaftfehler alle Kombinationen von Einzelfehlern beinhalten muss.
Dies beinhaltet bei n Signalleitungen eine Fehleranzahl von 1 bis n gleichzeitigen Fehlern,
welche zusätzlich einzeln in sämtlichen Positionen angenommen werden müssen. Deren
Zahl wächst mit steigender Systemgröße exponentiell. Daher wird in der Regel bei der
Erstellung von Testfällen die Fehlerüberdeckung von Einzelfehlern betrachtet, um den
Testaufwand gering zu halten.
Abbildung 3-21: Fehlerpropagierung [Mol02]
Die Testmustergenerierung für kombinatorische Schaltungen kann zum Beispiel mit dem
D-Algorithmus von Roth [Rot66] erfolgen. In diesem wird zunächst eine Leitung ausgewählt,
an der ein bestimmter Fehler angenommen wird. In Fall von Abbildung 3-21 ist dies
ein Haftfehler mit dem Wert Null (s-a-0). Der D-Algorithmus basiert auf dem so genannten
D-Kalkül. In diesem wird von einer 5-Werte-Logik ausgegangen, welche die Werte 0, 1,
D, D’ und X als Werte vorsieht, welche eine Signalleitung annehmen kann. Das Prinzip des
D-Algorithmus besteht daraus, dass ausgehend von einem festgelegten Wert einer Signalleitung
die Werte der übrigen Leitungen im D-Kalkül festgelegt werden. Hierbei
beschreiben 0 und 1 die Werte logisch Null und Eins. Der Wert D steht für einen Signalwert,
der den Wert Eins annimmt, wenn die Schaltung fehlerfrei ist, und entsprechend den
Wert Null annimmt, wenn die Schaltung fehlerhaft ist. D’ steht für das exakte Gegenteil
von D. Der Wert X repräsentiert den unbestimmten Fall. Der Wert der betroffenen
Signalleitung ist beliebig.
Der Algorithmus sieht das Propagieren eines angenommenen Haftfehlers zu den Ein- und
Ausgängen des Systems vor. Die zugrunde liegende Idee ist, dass dadurch der Fehler durch
definierte Eingabewerte getestet und durch die Ausgabewerte und vorher bestimmte
Erwartungswerte beobachtet und aufgedeckt werden kann. Im Fall des s-a-0-Fehlers aus
Abbildung 3-21 bedeutet dies, dass der Wert D an der betroffenen Signalleitung die Werte
der übrigen Leitungen im D-Kalkül festlegt. Für den Test des s-a-0-Fehlers muss an den
Signaleingängen des vor dem angenommenen Haftfehler liegenden AND-Gatters jeweils
der Wert logisch Eins anliegen, damit die Existenz des Fehlers überprüft werden kann. Der
erste Signaleingang des nachfolgenden OR-Gatters hat demnach in der 5-Werte-Logik den
Wert D. Die weitere Propagierung der Werte erfolgt nach folgenden Regeln.
43

3.5. Kommerzielle Anwendungen zur Testfallerstellung
Soll der Ausgang eines Gatters von exakt einem Eingangssignal abhängig sein, wie es im
Fall des OR-Gatters der Fall ist, müssen die übrigen Eingangssignale solche Werte
annehmen, die sich „neutral“ bzgl. des Gatters verhalten. Bei einem AND-Gatter ist dies
jeweils der Wert logisch Eins, bei einem OR-Gatter entsprechend der Wert logisch Null
[VieMis04]. Diesen Regeln folgend werden die Werte der übrigen Eingangssignale der
⎛ 1 ⎞
Schaltung bestimmt. Das Ergebnis des Verfahrens ist, dass mithilfe des Testvektors
⎝ 0 ⎠
der angenommene s-a-0-Fehler am einzigen Systemausgang beobachtet werden kann.
Durch die Propagierung hat dieser in der 5-Werte-Logik den Wert D. Dies bedeutet, dass
mit dem erwähnten Testvektor bewiesen wird, dass der angenommene Fehler nicht
vorhanden ist, wenn der Signalausgang den Wert logisch Eins annimmt. Im gegenteiligen
Fall wird der Haftfehler aufgedeckt.
⎜
⎜ 1
⎜ 0
⎜
⎜ X
⎜
Das aus dem Hardwaretest bekannte Vorgehen, mithilfe von Fehlermodellen Testmuster zu
erzeugen, kann in diesem Abschnitt nur in Auszügen vorgestellt werden. Zur detaillierteren
Lektüre wird an dieser Stelle auf Quellen in der Literatur verwiesen: [Mol02], [Rot66],
[VieMis04].
⎟
⎟
⎟
⎟
⎟
⎟
3.5 Kommerzielle Anwendungen zur Testfallerstellung
In diesem Abschnitt werden ausgewählte Anwendungen vorgestellt, die in Verbindung zu
den soeben in Abschnitt 3.4 beschriebenen Verfahren zur Testmustergenerierung stehen.
3.5.1 Klassifikationsbaumeditor (CTE)
Die Erstellung der in Abschnitt 3.4.1 vorgestellten Klassifikationsbäume und das Ausfüllen
der Kombinationstabelle werden durch den Klassifikationsbaumeditor für eingebettete
Systeme (engl. classification tree editor for embedded systems, CTE/ES) unterstützt
[Razorcat]. Der CTE/ES erlaubt die visuelle Darstellung und Bearbeitung von Testsequenzen
in abstrakter Form.
Im CTE/ES wird ein Klassifikationsbaum wie folgt dargestellt. Die Wurzel des Baums
repräsentiert das Testobjekt, welches nur an seinen Eingabe- und Ausgabeschnittstellen
betrachtet wird. Bei den Klassifikationen der ersten Ebene kann es sich um eine Zusammenfassung
sämtlicher Eingabeschnittstellen des Testobjektes oder auch um eine Auswahl
derselben handeln. Zugehörige Klassen werden ohne Rechteck dargestellt. In dem Beispiel
aus Abbildung 3-22 sind als Bezeichner der Klassen die Wertebereiche verwendet worden.
Die Kombinationstabelle wird unter dem Klassifikationsbaum in der Form dargestellt, dass
Klassen und zugehörige Einträge in der Tabelle untereinander stehen. Ein Verschieben der
Klassen oder die Einführung neuer Klassen führt zu einer automatischen Verschiebung der
Einträge der Kombinationstabelle. Zusätzlich bietet der CTE/ES eine Überprüfung der
44

3. Modellbasiertes Testen
Kombinationstabelle an. Einerseits unterbindet er bereits beim Erstellen der Testschritte,
dass Klassen desselben Eingangs gleichzeitig verwendet werden, andererseits können in
den Testschritten nicht verwendete Klassen identifiziert und hervorgehoben werden. Die
Konsistenz und die Vollständigkeit der Kombinationstabelle in Bezug auf den Klassifikationsbaum
werden auf diese Weise sichergestellt.
Abbildung 3-22: Klassifikationsbaumeditor
Den auf die Erstellung von Klassifikationsbaum und Kombinationstabelle folgenden
Schritt der Erzeugung konkreter Testmuster aus den abstrakt beschriebenen Testsequenzen,
unterstützt der Klassifikationsbaumeditor nicht. Daher können mithilfe des CTE/ES keine
konkreten Testfälle erstellt werden. Dies leisten unter den Produkten der dSPACE GmbH
die Testwerkzeuge AutomationDesk [AutomationDesk] und MTest [MTest]. Mit diesen
können aus im CTE/ES erstellten Klassifikationsbäumen konkrete Testmuster erzeugt
werden [Lam04]. Ebenfalls wird durch AutomationDesk die Durchführung derart erzeugter
Testfälle unterstützt.
3.5.2 Reactis
Für die zufallsbasierte Testmustergenerierung ist das Softwareprodukt Reactis® [Reactis]
der Firma Reactive Systems [Reactive Systems] als Beispiel zu nennen. Dieses wird in
diesem Abschnitt vorgestellt. Es besteht aus den drei Teilkomponenten Reactis Tester,
Reactis Simulator und Reactis Validator.
Der Reactis Tester ermöglicht die automatische Erzeugung von Testmustern aus heterogenen
Modellen in MATLAB Simulink und Stateflow. Die Testmustergenerierung kann
durch unterschiedliche Einstellungsmöglichkeiten beeinflusst werden. Hierzu zählen unter
45

3.5. Kommerzielle Anwendungen zur Testfallerstellung
anderem die in Kapitel 3.3 vorgestellten Abdeckungsmaße. Die Testmustergenerierung des
Reactis Testers erfolgt aufgrund eines auf Zufall basierenden Verfahrens. Es werden Testmuster
erzeugt, die aus einer Sequenz von Eingabedaten bestehen, mithilfe derer das
Modell oder eine daraus erstellte Implementierung später im Reactis Simulator oder in
MATLAB Simulink getestet werden können [Rea04].
Der Reactis Simulator unterstützt aus Entwicklungsumgebungen bekannte Verfahren wie
Einzelschritt-Ausführung, Haltepunkte und Visualisierung einzelner Variablen zur Laufzeit.
Er dient hauptsächlich der Simulation einer Testsequenz, mithilfe der das Modell
analysiert werden kann. Auf diese Weise kann untersucht werden, warum beispielsweise
bei der Testmustergenerierung eine gewünschte Abdeckung nicht erreicht wurde [Rea04].
Der Reactis Validator wird zur Überprüfung von Anforderungen an das Modell verwendet.
Durch Analyse des Modells und durch Verwendung generierter Testmuster können
Verstöße gegen einzelne Anforderungen aufgedeckt werden, die vom Entwickler spezifiziert
werden. Vom Reactis Validator wird im Fall eines Verstoßes dem Testentwickler ein
Testmuster zur Verfügung gestellt, dessen Ausführung im Reactis Simulator zu dem
aufgedeckten Verstoß führt [Rea04].
3.5.3 MOTCase-X
Das in Abschnitt 3.4.4 vorgestellte Verfahren der analytischen Testmustergenerierung wird
vom Testmustergenerator der Ingenieurgesellschaft Auto und Verkehr [IAV] verwendet.
Dieser wird unter dem Namen MOTCase-X (engl. Model-based Test Case Extractor)
entwickelt und erzeugt Testmuster für MATLAB Simulink/Stateflowmodelle [IAV04].
Die Generierung erfolgt aufgrund blockspezifischer Regeln, die im Testmustergenerator
für viele Simulink-Standardblöcke hinterlegt sind. Für nicht unterstützte Blöcke ermöglicht
MOTCase-X die manuelle Erstellung von Regeln, die in die Testmustergenerierung
einfließen. Hierzu wurde in den Testmustergenerator eine Komponente integriert, welche
einem Testentwickler bei der Angabe der zu testenden Wertebereiche hilft. Ebenso werden
hier Regeln hinterlegt, welche die Umkehrfunktion eines Blocks beinhalten, sollte diese
existieren.
Abbildung 3-23: Beispielsystem
Am Beispiel des Systems aus Abbildung 3-23 wird für die Testmustergenerierung für den
Saturation-Block die Umkehrfunktion des Gain-Blocks benötigt. Zu diesem Zweck
ermöglicht der Regelassistent aus MOTCase-X die Angabe der Umkehrfunktion für neue
Blocktypen.
46

4 Testmustergenerierung mit Hilfe von Wahrscheinlichkeitsverteilungen
Das Ziel der Arbeit ist es, ein Verfahren zur zufallsbasierten Testmustergenerierung zu
entwickeln, welches durch einen Anwender zielgerichtet eingesetzt werden kann. Der
Grundgedanke hierbei ist, eine Komponente in das automatische zufallsbasierte Verfahren
zu integrieren, welche einem Testentwickler die Möglichkeit zur Steuerung der Testmustergenerierung
bietet. Durch die Kombination von automatischen mit manuellen Methoden
soll ein Synergieeffekt erreicht werden; d. h., die Stärken der beiden Verfahren werden
vereint und ihre Schwächen durch das jeweils andere Verfahren minimiert (Abbildung
4-1). Die Hauptunterschiede der beiden Verfahren liegen in der Qualität und der Quantität
der erzeugbaren Testdaten.
manuell
manuell
(zielgerichtet)
(zielgerichtet)
automatisch
automatisch
(zufallsbasiert)
(zufallsbasiert)
gesteuert
gesteuert
(Wahrscheinlich-
(Wahrscheinlichkeitsverteilungekeitsverteilungen
Abbildung 4-1: Kombination manueller und automatischer Testmustergenerierung
Die wesentliche Stärke automatischer Verfahren liegt in der Anzahl der erzeugbaren
Testfälle. Die automatische Testmustergenerierung ermöglicht dem Anwender die schnelle
Erzeugung viele Testfälle innerhalb kürzester Zeit. Die manuelle Erstellung von Testfällen
erfordert dagegen einen erheblichen zeitlichen Aufwand, mit dem enorme Kosten verbunden
sind. Während manuell erzeugte Testfälle schwer zu warten sind [ArmOchSno04] und
auf neue Systemfunktionalitäten und Modifikationen am System nur mit erheblichen
Verzögerungen reagiert werden kann, ermöglicht es die automatische Testmustergenerierung,
in relativ geringen zeitlichen Abständen auf derartige Änderungen am System zu
reagieren, indem eine erhebliche Menge neuer Testfälle in relativ kurzer Zeit zur Verfügung
gestellt wird. Ein weiterer Vorteil der automatischen Testmustergenerierung ist, dass
die erstellten Testmuster in keiner Art von der Qualität des Testentwicklers abhängen.
Während bei der manuellen Erstellung von Tests der Entwickler abhängig von seinen
47

3.5. Kommerzielle Anwendungen zur Testfallerstellung
eigenen Fähigkeiten je nach Tagesform mal bessere, mal schlechtere Testfälle erzeugt,
generiert ein automatisches Verfahren im Durchschnitt Tests von ähnlicher Qualität.
Dem gegenüber stehen die Stärken der manuellen Testfallerstellung. Durch sie kann ein
Entwickler gezielt Tests erzeugen. Insbesondere sind manuelle Verfahren im Gegensatz
zur zufallsbasierten automatischen Testmustergenerierung in der Lage, Testmuster für ausgewählte
Systemfunktionalitäten oder reale Einsatzszenarien des Systems zu erzeugen.
Unter Verwendung des Testentwicklerwissens über das System und dessen Anwendung
können auf diese Weise Testmuster erzeugt werden, welche gezielt sicherheitskritische
Systemstellen oder selten verwendete Systemfunktionalitäten auf korrektes Verhalten
überprüfen. Das Wissen des Testentwicklers stammt hierbei zum einen aus der ihm vorliegenden
Spezifikation, aufgrund der das System erstellt wurde, zum anderen aus seiner
Erfahrung im Umgang mit dem Testobjekt und ähnlichen Systemen.
Die automatische zufallsbasierte Testmustergenerierung verfügt nicht über dieses Zusatzwissen.
Es besteht lediglich die Möglichkeit, Testdaten in großer Zahl zu erzeugen, so dass
sich darunter auch solche befinden, die zum Test gewünschter Funktionalitäten oder zur
Überprüfung des Systemverhaltens in kritischen Systemzuständen führen. Aufgrund des
Nichtdeterminismus eines zufallsbasierten Vorgehens kann allerdings nicht vorhergesagt
werden, wann und ob jemals Testdaten zur Überprüfung dieser Testziele erzeugt werden.
Der Grund für diese Problematik liegt darin, dass die Generierung derartiger Testdaten
stark von der Wahrscheinlichkeit abhängt, mit der das System bei zufälligen Eingabedaten
in einen kritischen Systemzustand eintritt.
Aufgrund dieser Nachteile der automatischen Methode wird im Allgemeinen der mit der
gezielten manuellen Erstellung von einzelnen Testfällen verbundene Aufwand in Kauf
genommen, um die Qualität der erzeugten Tests zu erhöhen. In dieser Arbeit wird der
Vorteil des Entwicklerwissens in das Verfahren der automatischen zufallsbasierten Testmustergenerierung
einbezogen, wodurch der Aufwand des Anwenders zur Erstellung
konkreter Abfolgen von Testdaten verringert wird. Ziel ist es die zufallsbasierte Erzeugung
von Testdaten derart zu steuern, dass die Wahrscheinlichkeit der Erzeugung gewünschter
Testdaten erhöht wird.
Manuelle Testmustergenerierung erfolgt über die Auswahl und Manipulation von Werten
für die Eingangssignale eines Systems. Die Interaktion des Anwenders mit dem Verfahren
der automatischen Testmustergenerierung beruht in dieser Arbeit auf dem gleichen
Konzept. Sie erfolgt jedoch nicht über die Auswahl konkreter Testmuster, sondern über die
Auswahl von Werten, welche im automatischen Verfahren zur Bildung von Testmustern
als Grundlage dienen. Die Anwendung zufallsbasierter Testmustergenerierung ermöglicht
es, die Auswahl dieser Werte durch die Vorgabe von Wahrscheinlichkeitsverteilungen über
den Wertebereichen der Eingangssignale vorzunehmen.
Der Zufallsprozess der Testmustergenerierung wird auf diese Weise vom Testentwickler
gesteuert. Dabei kann dieser sein Spezialwissen in die Erzeugung von Testdaten einfließen
lassen, um beispielsweise gezielt Testmuster für schwer erreichbare Systembereiche (Testschwerpunkte)
zu erzeugen. Dadurch reduziert sich die Zahl der durch das zufällige
48

4. Testmustergenerierung mit Hilfe von Wahrscheinlichkeitsverteilungen
Verfahren generierten Testdaten, die für einen Testschwerpunkt nicht relevant sind, auf ein
notwendiges Mindestmaß, wodurch die Qualität der automatisch erzeugten Testdaten
erhöht wird.
Die folgenden Unterkapitel gehen detailliert auf das Verfahren ein, welches dem Anwender
die Steuerung der zufallsbasierten Testmustergenerierung ermöglicht. Dabei wird
zuerst in Unterkapitel 4.1 das Verfahren selbst beschrieben. In Abschnitt 4.2 wird auf die
Einbeziehung unterschiedlicher Wahrscheinlichkeitsverteilungen in Abhängigkeit von den
verschiedenen Arten von Signaleingängen eingegangen.
4.1 Zufallbasierte Testmustergenerierung
Das in dieser Arbeit vorgestellte Verfahren zur Testmustergenerierung basiert auf dem
zufallsbasierten Verfahren aus Kapitel 3.4.2. Es handelt sich um ein Verfahren, welches
zur Erstellung von Back-to-Back-Tests (vgl. Kapitel 3.2.4) verwendet wird. D.h., dass eine
Systemrepräsentation als Testbasis zur Erzeugung von Testfällen herangezogen wird, mit
denen in einer späteren Testdurchführung eine zweite Systemrepräsentation überprüft wird.
Da sich diese Arbeit nicht mit dieser Testdurchführung beschäftigt, wird in diesem Kapitel
lediglich auf die Erzeugung derartiger Tests eingegangen.
Als Testbasis wird das Funktionsmodell des Systems verwendet. Ausgehend von diesem
Modell werden Testdaten erzeugt, die zum Test des daraus erstellten Implementierungsmodells
oder des Programmcodes verwendet werden können. Das Testziel ist die
Abdeckung ausgewählter Strukturmerkmale, mit der sich bereits Kapitel 3.3 beschäftigt
hat. Die Art dieser Strukturmerkmale, welche durch die erzeugten Testmuster ausreichend
ausgeführt werden sollen, spielt für das Verfahren der Testmustergenerierung keine Rolle.
Die einzige Voraussetzung für die Anwendung des beschriebenen Verfahrens ist die
Möglichkeit zur Messung des gewählten Abdeckungskriteriums.
Das vorgestellte Verfahren zur Testmustergenerierung erzeugt bei Anwendung einen Testfall,
der in der Regel aus mehreren Testmustern besteht (vgl. Abschnitt 3.1.2). Die
Erzeugung dieser Testmuster wird unter dem Ziel durchgeführt, dass eine – nach
Möglichkeit – vollständige Strukturabdeckung erreicht wird. Das zugrunde liegende
Verfahren wird in Abbildung 4-2 gezeigt und im Folgenden näher beschrieben.
49

4.1. Zufallbasierte Testmustergenerierung
Entwickler
Testmuster
Automatischer
Testmuster-
Generator
Modellabdeckung
Modell
Testumgebung
Abbildung 4-2: Testmustergenerierung mithilfe von Wahrscheinlichkeitsverteilungen
Das Verfahren ist zyklisch aufgebaut und beruht auf der Interaktion von zwei funktionalen
Hauptkomponenten und dem Testentwickler. Am Anfang jedes Zyklus steht der automatische
Testmustergenerator (ATG), welcher die neuen Testdaten erzeugt. Auf diesen
Entstehungsprozess nimmt der Testentwickler mithilfe von Wahrscheinlichkeitsverteilungen
Einfluss. Die Testumgebung, in die das Modell eingebettet ist, führt das Messen
der Strukturabdeckung sämtlicher Testmuster eines Testfalls durch. Die Ergebnisse dieser
Abdeckungsmessung gehen daraufhin in den Entstehungsprozess der Testdaten des nächsten
Zyklus ein. Auf diese Weise wird pro Zyklus ein sich in Bearbeitung befindendes
Testmuster erweitert oder gegebenenfalls mit der Erzeugung eines neuen Testmusters
begonnen. Der konkrete Ablauf des gesamten Verfahrens zur Testmustergenerierung
besteht aus der Wiederholung der folgenden Schritte, die in den folgenden Abschnitten
näher beschrieben werden:
• Erweiterung des bearbeiteten Testmusters im ATG
• Evaluierung des Testmusters in der Testumgebung
• Auswertung der Evaluierung im ATG
• Fortsetzen oder Beenden der Generierung im ATG
4.1.1 Erweiterung des bearbeiteten Testmusters
Der erste Schritt des zyklischen Verfahrens erweitert ein Testmuster, welches aus dem
vorherigen Zyklus übernommen wurde, um weitere Testvektoren, d.h. Eingabe- und Refe-
50

4. Testmustergenerierung mit Hilfe von Wahrscheinlichkeitsverteilungen
renzdaten. Bei dem Testmuster, das erweitert wird, kann es sich insbesondere im ersten
Zyklus der Ausführung des Verfahrens um ein Testmuster der Länge Null handeln,
welches vorerst keine Testdaten beinhaltet.
Zur Erzeugung neuer Testdaten wird eine Beschreibung der Wertebereiche sämtlicher Eingabeschnittstellen
benötigt. Diese beinhaltet pro Eingangssignal In i die Menge der
möglichen Werte, die der Signaleingang annehmen kann. Dieser Wertebereich wird mit
D Ini
bezeichnet. Es werden zwei Arten von Eingangssignalen unterschieden. Im Fall eines
diskreten Eingangssignals Ini beinhaltet der Wertebereich D Ini
eine Menge mit endlich
vielen Werten, die Ini annehmen kann. Ein analoges Eingangssignal zeichnet sich dagegen
dadurch aus, dass es sämtliche Werte aus einem Intervall reeller Zahlen [a, b] annehmen
kann.
In i
Zusätzlich werden zur Generierung über den Wertebereichen definierte Wahrscheinlichkeitsverteilungen
benötigt. Der Testentwickler, welcher das Verfahren anwendet, definiert
aufgrund seines Wissens über das System und dessen Einsatz für jedes Eingangssignal In i
eine Wahrscheinlichkeitsverteilung W , welche auf den Wertebereich des Eingangssignals
beschränkt ist. Auf diese Weise gibt der Testentwickler mithilfe von Wahrscheinlichkeitsverteilungen
vor, welche Eingabedaten während der Generierung neuer Testdaten
häufiger und welche weniger häufig erzeugt werden sollen, wodurch er den Prozess der
Entstehung von Testdaten steuert.
D In i
Wertebereiche
Eingabedaten
Abbildung 4-3: Erzeugung von Eingabedaten
Die Erzeugung neuer Testdaten erfolgt zufallsbasiert auf den Wertebereichen
der Eingangssignale
Ini, wobei die durch den Anwender des Verfahrens angegebenen
Wahrscheinlichkeitsverteilungen W (vgl. Abbildung 4-3) berücksichtigt werden. Auf die
In i
Wahl einzelner Wahrscheinlichkeitsverteilungen wird später in Abschnitt 4.2 näher
eingegangen.
Der ATG erzeugt für alle Eingangssignale In i eine Sequenz von Eingabedaten
e i,s+1 , … , e i,s+k , wobei i ∈ {1, …, n} und n die Anzahl der Eingangssignale des Systems ist.
Diese Sequenz hat die Länge k. Diese wird am Ende des vorherigen Zyklus oder im Fall
D Ini
51

4.1. Zufallbasierte Testmustergenerierung
des ersten Zyklus zu Beginn der gesamten Testmustergenerierung festgelegt. Auf die
Festlegung der konkreten Länge in einem bestimmten Zyklus wird später in Abschnitt
4.1.4 näher eingegangen. Unter Berücksichtigung der Länge s des bereits vorhandenen
Testmusters werden pro Zyklus die Eingabedaten e i,s+1 , … , e i,s+k generiert, wobei
gilt: j ∈{1,...,
k}:
e i
∈ D .
∀
, s+
j
In i
Mithilfe der erzeugten Eingabedaten werden die zugehörigen Referenzdaten ermittelt 2 ,
welche zur späteren Testdurchführung benötigt werden. Die ermittelten Referenzdaten des
Ausgangssignals Out i sind r i,s+1 , … , r i,s+k und es gilt: j ∈{ 1,..., k}:
r i
∈ D mit
∀
, s+
j
ist der Wertebereich des Ausgangssignals Outi, i ∈ {1, …, m} und m ist die Anzahl der
Ausgangssignale des Systems.
Die Vereinigung von Eingabe- mit Referenzdaten bildet die Testvektoren t s+1 , …, t s+k :
⎛ t1,
s+
j ⎞ ⎛ e1,
s+
j ⎞
⎜ ⎟ ⎜ ⎟
⎜ ... ⎟ ⎜ ... ⎟
⎜ t ⎟ ⎜ ⎟
n,
s+
j
en,
s+
j
∀j
∈{ 1,..., k}:
t = ⎜ ⎟ = ⎜ ⎟
s+
j
(vgl. Kapitel 3.1.2).
⎜ tn+
1, s+
j ⎟ ⎜ r1,
s+
j ⎟
⎜ ⎟ ⎜ ⎟
⎜
...
⎟ ⎜
...
⎟
⎝tn+
m,
s+
j ⎠ ⎝rm , s+
j ⎠
Durch Konkatenation dieser neu erzeugten Testvektoren mit dem bestehenden Testmuster
entsteht das folgende Testmuster, dessen erste s Spalten die Testvektoren des alten Testmusters
und die letzten k Spalten die neu erzeugten Testvektoren sind:
Outi
D Outi
T
⎛ e
⎜
⎜ M
⎜en
= ⎜
⎜ r
⎜
⎜
M
⎝rm
1,1
,1
1,1
,1
L
O
L
L
O
L
e
e
r
1, s
n,
s
r
M
1, s
M
m,
s
e
e
r
1, s+
1
n,
s+
1
r
M
1, s+
1
M
m,
s+
1
L
O
L
L
O
L
e
e
r
1, s+
k
n,
s+
k
r
M
1, s+
k
M
m,
s+
k
⎞
⎟
⎟
⎟
⎟ .
⎟
⎟
⎟
⎠
Dieses Testmuster wird zur Evaluierung an die Testumgebung übergeben, was im
folgenden Abschnitt beschrieben ist.
4.1.2 Evaluierung des Testmusters
In der Testumgebung erfolgt eine Simulation sämtlicher Testmuster des aktuellen Testfalls.
Dabei wird die Strukturabdeckung der Eingabedaten der einzelnen Testmuster ermittelt. Zu
diesem Zweck wird das Modell vor der Simulation eines Testmusters in einen Initialzustand
versetzt, um zeitliche Aspekte im Systemverhalten zu berücksichtigen, welche in
2 Da die Referenzdaten für das Verfahren der Generierung von Testmustern in dieser Arbeit keine Relevanz
haben, wird auf die Art ihrer Bestimmung nicht näher eingegangen.
52

4. Testmustergenerierung mit Hilfe von Wahrscheinlichkeitsverteilungen
zustandsbasierten Systemen zu beachten sind. Auf diese Weise wird sichergestellt, dass die
Testmuster während der Testdurchführung dieselben Systembereiche ausführen, welche
am Modell während ihrer Erzeugung gemessen wurden.
Die Informationen zur Strukturabdeckung werden sowohl in Form des Abdeckungsgrades
als auch als Menge der ausgeführten Modellkomponenten ermittelt. Aus der Kombination
der Abdeckung sämtlicher Testmuster des Testfalls bestimmt die Testumgebung die
Strukturabdeckung des gesamten Testfalls und übergibt diese an den ATG.
4.1.3 Auswertung der Evaluierung
Die in der Testumgebung ermittelte Strukturabdeckung des Testfalls wird im ATG ausgewertet.
Insbesondere erfolgt eine Bewertung der im aktuellen Zyklus neu generierten und
an das bearbeitete Testmuster angehängten Testvektoren. Der erreichte Testfallabdeckungsgrad
wird dazu mit dem Testfallabdeckungsgrad des vorherigen Zyklus
verglichen. Auf Basis dieses Vergleichs erfolgt eine Entscheidung darüber, ob die
angehängten Testvektoren in dem bearbeiteten Testmuster verbleiben können oder wieder
aus diesem entfernt werden müssen. Das zugrunde liegende Verfahren des Akzeptierens
und Verwerfens wird im Folgenden näher erläutert und ist in Abbildung 4-4 dargestellt.
Abdeckung
gesteigert?
nein
Abdeckung
gesteigert?
ja
...
Legende:
Akzeptierte Testdaten
Temporär angehängte Testdaten
Abbildung 4-4: Erzeugen eines Testmusters (Akzeptieren / Verwerfen)
Sollte in einem Zyklus der Testfallabdeckungsgrad durch die generierten Testdaten nicht
erhöht werden, ist dies ein Zeichen dafür, dass diese Testdaten solche Systembereiche
testen, die entweder durch die vorangehenden Testdaten des Testmusters oder durch eines
der übrigen Testmuster des Testfalls bereits ausgeführt werden. Dies ermöglicht das
Herausfiltern derjenigen Testdaten, welche unter Berücksichtigung sämtlicher bereits
53

4.1. Zufallbasierte Testmustergenerierung
erzeugter Testdaten nicht zum Erreichen vollständiger Strukturabdeckung beitragen. Zur
Optimierung der erzeugten Testmuster werden diese Testdaten aus dem Testmuster, an
welches sie angehängt wurden, im selben Zyklus wieder entfernt. Auf diese Weise wird ein
Testmuster, welches von einem Zyklus in den nächsten eingeht, nicht in jedem Zyklus
verlängert.
Wenn die in einem Zyklus erzeugten Testdaten zu einer Steigerung des Testfallabdeckungsgrades
geführt haben, werden diese akzeptiert und verbleiben in dem Testmuster,
an welches sie angehängt wurden, wodurch das bearbeitete Testmuster wächst.
Durch die Art dieses Vorgehens kann es vorkommen, dass über mehrere Zyklen hinweg
das bearbeitete Testmuster nicht wächst. Insbesondere kann der Fall auftreten, dass ein
leeres Testmuster nach einem Zyklus weiterhin die Länge Null hat. Dieses Phänomen kann
auftreten, wenn beispielsweise mithilfe von mehreren Testmustern bereits ein hoher
Abdeckungsgrad erzeugt wurde und ein neues Testmuster erzeugt wird, welches zu keiner
Steigerung der Strukturabdeckung führt.
4.1.4 Fortsetzen oder Beenden der Generierung
Der letzte Schritt eines Zyklus besteht entweder aus dem Beenden der Generierung oder
aus der Vorbereitung des nächsten Zyklus.
Die Vorbereitung des nächsten Zyklus erfolgt abhängig von der aktuellen Bewertung der
generierten Testdaten. Wenn diese verworfen wurden, wird für den nächsten Zyklus die
Länge k der zu erzeugenden Sequenz von Testdaten erhöht. Auf diese Weise wird einem
Problem entgegengewirkt, welches in Abbildung 4-5 deutlich wird.
Abbildung 4-5: Notwendigkeit langer Sequenzen
Der abgebildete Zustandsautomat beinhaltet für die Modellabdeckungskriterien aus Kapitel
3.3 lediglich drei relevante Strukturmerkmale. Bezüglich der Zustandsabdeckung sind die
beiden Zustände S1 und S2 relevant, bezüglich eines Bedingungsabdeckungskriteriums
lediglich die Bedingung (A > 100). Das Problem bei Anwendung des Verfahrens der
vorhergegangenen Abschnitte liegt darin, dass aus dem Initialzustand S1 heraus keine
Abdeckungssteigerung möglich ist, wenn die Länge der neu generierten und an das
Testmuster angehängten Sequenz von Testdaten nicht so groß ist, dass der Wert der
Variablen A den Wert 100 überschreitet. Aus diesem Grund wird die Anzahl der zu erzeu-
54

4. Testmustergenerierung mit Hilfe von Wahrscheinlichkeitsverteilungen
genden Testdaten für den nächsten Zyklus erhöht. Dies kann beispielsweise durch eine
Verdopplung geschehen, wodurch bei mehrmaligen „Fehlversuchen“ die Länge der temporär
angehängten Testdaten schnell steigt, bis sie den Schwellwert von 100 überschreitet
und Zustand S2 erreicht wird, wodurch der Abdeckungsgrad bezüglich der Zustandsabdeckung
erhöht wird.
Eine weitere Problematik veranschaulicht Abbildung 4-6. Es ist notwendig nach einer
„gewissen“ Anzahl generierter Testdaten, im nächsten Zyklus mit der Generierung eines
neuen Testmusters zu beginnen. Der abgebildete Zustandsautomat beinhaltet das Problem,
dass zwei Testszenarien benötigt werden, weil die beiden Zustände S2 und S3 in zwei
unabhängigen Zweigen des Systems liegen. Der Zustandsautomat kann deswegen in keiner
Art und Weise von einem der beiden Zustände in den jeweils anderen überführt werden.
Da sie lediglich aus dem Initialzustand S1 erreichbar sind, werden in diesem Fall zwei
Testmuster benötigt. Um diesem Problem entgegen zu wirken, muss zur Anwendung des
beschriebenen Verfahrens der automatischen Testmustergenerierung eine obere Schranke
für die Anzahl der Testdaten angegeben werden, die zur Erzeugung eines Testmusters
generiert und zur Evaluierung temporär an dieses angehängt werden. Mit anderen Worten
wird dadurch die Anzahl der Versuche, mit einer Erweiterung eines Testmusters eine
Abdeckungssteigerung zu erreichen, beschränkt.
Abbildung 4-6: Notwendigkeit mehrerer Testmuster
Das Beenden der Testmustergenerierung erfolgt in zwei Fällen. Der Trivialfall liegt vor,
wenn die erzeugten Testmuster zu einer Testfallabdeckung von hundert Prozent führen. In
diesem Fall werden keine weiteren Testdaten benötigt und das Verfahren terminiert. Der
zweite Fall beruht auf einem Abbruchkriterium, welches vom Anwender des Verfahrens
bestimmt wird. Durch die maximale Anzahl der zu erzeugenden Testmuster wird die Zahl
der Testmuster beschränkt, mit welchen der ATG eine möglichst hohe Strukturabdeckung
erreichen soll. Das Verfahren terminiert, sobald die angegebene Anzahl von Testmustern
generiert wurde. Sollte dieser Fall eintreten, wird ein Testfall ausgegeben, welcher keine
hundertprozentige Abdeckung erreicht. Der Anwender hat nun die Möglichkeit entweder
55

4.2. Steuerung des Zufallprozesses mit Wahrscheinlichkeitsverteilungen
durch Anwendung des Verfahrens weitere Testmuster für diesen Testfall zu erzeugen oder
mit manuellen Methoden (vgl. Kapitel 3.4.1) gezielt Testmuster für die nicht abgedeckten
Strukturmerkmale zu erzeugen.
4.2 Steuerung des Zufallprozesses mit Wahrscheinlichkeitsverteilungen
Im Folgenden wird auf die Wahrscheinlichkeitsverteilungen eingegangen, welche durch
den Anwender des Verfahrens angegeben werden. Diese bilden als Kern des Verfahrens
das Mittel zur Steuerung des Zufallprozesses, der zur Erzeugung von Testdaten führt. Wie
bereits in Abschnitt 4.1.1 erwähnt, erfolgt die Generierung der Eingabedaten aufgrund von
Wahrscheinlichkeitsverteilungen, welche über den Wertebereichen der Eingangssignale
definiert sind.
Die Definition dieser Wahrscheinlichkeitsverteilungen wird dabei durch den Testentwickler
vorgenommen. Es werden zwei Arten von Eingabeschnittstellen unterschieden.
Diskrete Eingangssignale können nur eine begrenzte Anzahl von Werten annehmen.
Beispiele hierfür sind beispielsweise die Schalter zur Einstellung der Geschwindigkeit des
Scheibenwischers und der Lüftung im Automobil, welche die Einstellung mehrerer
Geschwindigkeitsstufen ermöglichen. Die zweite Art von Eingangssignalen sind analoge
Signale, welche sämtliche Werte eines kontinuierlichen Wertebereichs annehmen können.
Hierzu zählen zum Beispiel die Sensorsignale, welche im Automobil dem Antiblockiersystem
die aktuelle Rotationsgeschwindigkeit der Räder mitteilen.
4.2.1 Diskrete Eingangssignale
Bei diskreten Eingangssignalen handelt es sich um Eingangssignale des Systems, welche
Werte eines endlichen Wertebereichs annehmen können. In Abbildung 4-7 ist das
Stateflowmodell Automat_diskret als Beispielsystem gegeben, welches in drei
Zustandsübergängen den Wert des Eingangssignals In1 mit dem Wert 7 vergleicht. Der
Zustandsübergang von S0 nach S1 erfolgt, wenn das Signal In1 einen Wert größer als
sieben annimmt. Entsprechend erfolgt der Zustandsübergang von S1 nach S2 nur bei dem
Wert sieben und der Zustandsübergang von S2 nach S0 bei Werten unterhalb von Sieben.
Sei der Wertebereich D In1 des Eingangssignals In1 auf ganzzahlige Werte aus dem Intervall
[1, 10] beschränkt. Die automatische Testmustergenerierung, wie sie in Abschnitt 4.1
vorgestellt wurde, erzeugt mithilfe eines Zufallszahlengenerators für In1 Werte aus
D In1 = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}. Dies erfolgt unter der Berücksichtigung einer diskreten
Wahrscheinlichkeitsverteilung. Das Eingangssignal In1 wird hierzu aus mathematischer
Sicht als diskrete Zufallsvariable X In1 betrachtet, welche sämtliche Werte aus D In1 annehmen
kann (vgl. Anhang A Grundlagen der Wahrscheinlichkeitsrechnung).
56

4. Testmustergenerierung mit Hilfe von Wahrscheinlichkeitsverteilungen
Abbildung 4-7: Beispielmodell Automat_diskret
Eine diskrete Wahrscheinlichkeitsverteilung ermöglicht die Bevorzugung einzelner Werte,
die eine Zufallsvariable annehmen kann. Der Testentwickler gibt aufgrund der ihm
bekannten Modellstruktur Wahrscheinlichkeiten für jeden der Werte aus D In1 an, wodurch
er gezielt die Generierung bestimmter Testdaten bevorzugen oder benachteiligen kann. Zur
Angabe einer korrekten Wahrscheinlichkeitsverteilung ist zu beachten, dass die Summe
der Einzelwahrscheinlichkeiten den Wert eins ergeben muss. In Tabelle 4-1 sind
beispielhaft zwei Wahrscheinlichkeitsverteilungen der zu In1 zugehörigen Zufallsvariablen
X In1 abgebildet. Die erste Spalte beinhaltet die Werte, welche die Zufallsvariable X In1
annehmen kann, also den Wertebereich D In1 .
x i P 1 (X In1 = x i ) P 2 (X In1 = x i )
1 0,1 0 ,05
2 0,1 0 ,05
3 0,1 0 ,05
4 0,1 0 ,05
5 0,1 0 ,05
6 0,1 0 ,05
7 0,1 0 , 3
8 0,1 0 , 1
9 0,1 0 , 1
10 0,1 0 , 1
Tabelle 4-1: Beispiele für diskrete Wahrscheinlichkeitsverteilungen
Es werden zwei Wahrscheinlichkeitsverteilungen gegenübergestellt. In der zweiten Spalte
ist die Wahrscheinlichkeitsverteilung P 1 abgebildet, in der sämtliche Werte aus D In1 die
gleiche Wahrscheinlichkeit haben. Diese Wahrscheinlichkeitsverteilung (Gleichverteilung)
ist die Grundlage des allgemeinen zufallsbasierten Verfahrens zur Testmustergenerierung
aus Kapitel 3.4.2. Durch Angabe einer Gleichverteilung werden während der Generierung
57

4.2. Steuerung des Zufallprozesses mit Wahrscheinlichkeitsverteilungen
von Testdaten sämtliche möglichen Werte im Durchschnitt gleichhäufig erzeugt. Es findet
folglich keine Bevorzugung einzelner Werte statt.
Im Gegensatz dazu werden durch die Angabe der Wahrscheinlichkeitsverteilung P 2 einzelne
Werte aus D In1 stark bevorzugt. Der Wertebereich ist in drei Teilbereiche unterteilt,
welche jeweils mit einem Drittel Wahrscheinlichkeit versehen sind. Die Werte kleiner
sieben haben jeweils eine Wahrscheinlichkeit von 0 ,05
, wodurch die Summe ihrer Wahrscheinlichkeiten
ein Drittel ergibt. Der zweite Teilbereich beinhaltet lediglich den Wert 7,
welchem die Wahrscheinlichkeit 0 , 3 zugeordnet wird. Die Werte oberhalb von Sieben
wurden jeweils mit der Wahrscheinlichkeit 0 , 1 versehen, wodurch dieser Teilbereich
ebenfalls ein Drittel Wahrscheinlichkeit hat.
Der zugrunde liegende Gedanke bei Angabe dieser Wahrscheinlichkeitsverteilung ist die
Gleichbehandlung der drei Bedingungen an den Zustandsübergängen des Modells.
Während bei der Gleichverteilung P 1 die Wahrscheinlichkeit, dass ausgehend von Zustand
S1 der Zustandsübergang zu S2 erfolgt, bei einem generierten Testdatum bei 0,1 liegt,
wurde mithilfe von P2 diese Übergangswahrscheinlichkeit auf 0 , 3 erhöht. Unter Verwendung
von P1 müssen im Erwartungswert zehn Testdaten generiert werden, bis unter ihnen
einmal der Wert 7 vorkommt. Im Gegensatz dazu liegt der Erwartungswert hierfür bei der
Generierung auf Basis von P2 bei drei Testdaten. Auf diese Weise kann durch eine vom
Testentwickler angegebene Wahrscheinlichkeitsverteilung die Anzahl der zu generierenden
Testdaten reduziert werden. Dies führt zu einer effizienteren Generierung von
Testdaten.
Die beiden vorgestellten Wahrscheinlichkeitsverteilungen wurden anhand des Beispielmodells
aus Abbildung 4-7 (Automat_diskret) zur Testmustergenerierung verwendet.
Dies erfolgte unter der Verwendung des Testmustergenerators TestCaseCommander,
welcher im Verlauf dieser Arbeit implementiert wurde und in Kapitel 5 näher beschrieben
ist. Die Ergebnisse der Testmustergenerierung werden in Kapitel 6.1 vorgestellt.
4.2.2 Analoge Modelleingänge
Insbesondere im Automobilbereich treten häufig analoge Eingangssignale auf. Die mathematische
Betrachtung derartiger Signale erfolgt in dieser Arbeit als kontinuierliche
Zufallsvariable, welche sämtliche reelle Werte eines Wertebereichs annehmen kann. Die
Angabe von Wahrscheinlichkeiten für einzelne Werte kontinuierlicher Zufallsvariablen ist
nicht möglich (vgl. Anhang A Grundlagen der Wahrscheinlichkeitsrechnung). Stattdessen
erfolgt mithilfe der Wahrscheinlichkeitsdichte die Angabe von Wahrscheinlichkeiten für
beliebig kleine Intervalle des Wertebereichs.
Zur Veranschaulichung der Behandlung analoger Modelleingänge in dieser Arbeit wird das
Beispielmodell aus Abbildung 4-8 betrachtet. Es handelt sich um ein Stateflowmodell,
welches in drei Zustandsübergängen auf den Wert des Eingangssignals In1 reagiert. Der
Zustandsübergang von S0 nach S1 erfolgt, wenn das Signal In1 einen Wert größer als 7.5
annimmt. Entsprechend erfolgt der Zustandsübergang von S1 nach S2 nur in dem Werte-
58

4. Testmustergenerierung mit Hilfe von Wahrscheinlichkeitsverteilungen
bereich von 6.5 bis 7.5 und der Zustandsübergang von S2 nach S0 bei Werten unterhalb
von 6.5.
Abbildung 4-8: Beispielmodell Automat_analog
Es sei für die folgenden zwei Abschnitte der Wertebereich D In1 des Eingangssignals In1
auf das Intervall [1, 10] beschränkt. Die automatische Testmustergenerierung erzeugt
mithilfe eines Zufallszahlengenerators für In1 Werte aus D In1 = [1, 10]. Dies erfolgt in den
folgenden zwei Abschnitten auf unterschiedliche Art und Weise. In Abschnitt 4.2.2.1
erfolgt die Anwendung einer diskreten Wahrscheinlichkeitsverteilung auf dem analogen
Signaleingang In1. Der Einsatz einer kontinuierlichen Wahrscheinlichkeitsdichte wird in
Abschnitt 4.2.2.2 beschrieben.
4.2.2.1 Diskretisierung des Wertebereichs
Die Diskretisierung des Wertebereichs eines analogen Eingangssignals ermöglicht die
Anwendung einer diskreten Wahrscheinlichkeitsverteilung gemäß Unterkapitel 4.2.1.
Hierzu wird der Wertebereich des Eingangssignals mithilfe der Klassifikationsbaummethode
aus Kapitel 3.4.1 auf eine oder mehrere Klassen abgebildet. Die Testmustergenerierung
erfolgt dann nicht mehr anhand der ursprünglichen Wertebereiche der
Eingangssignale, sondern aufgrund der Indizes der gebildeten Klassen. Das hierzu
notwendige Vorgehen wird im Folgenden anhand des Beispielsystems aus Abbildung 4-8
näher erläutert.
Aufgrund der Modellstruktur bietet sich die Aufteilung des Wertebereichs D In1 in drei
Teilbereiche während der Testmustergenerierung an. Das Motiv hinter dieser Aufteilung
ist wie bereits in Abschnitt 4.2.1 erwähnt die gewünschte Gleichbehandlung der drei
Bedingungen an den Zustandsübergängen. Deshalb werden die gewählten Wertebereiche
im Folgenden als Äquivalenzklassen bezeichnet. Eine aufgrund der Übergangsbedingungen
des Statecharts gewählte Aufteilung in drei Teilbereiche liefert die Äquivalenzklassen
Klasse 1 = [1, 6.5[, Klasse 2 = [6.5, 7.5] und Klasse 3 = ]7.5, 10].
59

4.2. Steuerung des Zufallprozesses mit Wahrscheinlichkeitsverteilungen
Im zweiten Schritt des Verfahrens werden die gebildeten Äquivalenzklassen jeweils auf
einen Wert abgebildet. Zu diesem Zweck werden die gewählten Äquivalenzklassen mit
einer Nummer versehen. Durch dieses Vorgehen wurde der Wertebereich des Eingangssignals
In1 im Beispielsystem auf die Menge {1, 2, 3} abgebildet. In Abbildung 4-9 ist der
vollständige Vorgang der Diskretisierung dargestellt.
Inputs
In1
[1, 10]
Klasse 1
[1, 6.5[
Klasse 2
[6.5, 7.5]
Klasse 3
]7.5, 10]
1 2 3
Abbildung 4-9: Diskretisierung
Die zufallsbasierte Testmustergenerierung erfolgt nach Anwendung einer Diskretisierung
aufgrund der Nummern der Äquivalenzklassen, also aufgrund des Wertebereichs
D diskretisiert = {1, 2, 3}. Dieses Vorgehen ermöglicht die Anwendung einer diskreten Wahrscheinlichkeitsverteilung
über den Indizes der Äquivalenzklassen. Das dazu notwendige
Vorgehen wurde bereits in Abschnitt 4.2.1 vorgestellt. An dieser Stelle ist anzumerken,
dass die Testmustergenerierung in diesem Fall keine anwendbaren Testmuster erzeugt. Es
werden lediglich die den Klassen zugeordneten Nummern generiert, wodurch abstrakte
Testmuster entstehen (vgl. Kapitel 3.4.1).
Das in dieser Arbeit vorgestellte Verfahren zur Testmustergenerierung erfordert jedoch
konkrete Testmuster, anhand derer die Abdeckungsmessung erfolgen kann. Hierzu müssen
aus den abstrakten Testmustern konkrete Testmuster erzeugt werden. Dies erfolgt in
diesem Abschnitt in der Testumgebung, welche während der Testmustergenerierung die
generierten Nummern der Äquivalenzklassen auf Werte ihrer Wertebereiche abbildet.
Diese Abbildung kann sowohl zufallsbasiert als auch mit der Mittelwertmethode erfolgen,
welche aus dem Wertebereich einer Klasse ihren Mittelwert berechnet und als Repräsentant
der Klasse wählt. Da die Anwendung der Klassifikationsbaummethode aufgrund
der Uniformitätshypothese erfolgt (vgl. Kapitel 3.4.1 und Barbey [Bar97]), können sämtliche
Werte des Wertebereichs einer Äquivalenzklasse als gleichwertig angesehen werden.
Dies bedeutet, dass der Testentwickler den Wertebereich einer Klasse so ausgewählt hat,
dass durch Anwendung seiner Werte ein sehr ähnliches bis identisches Verhalten im
Testobjekt hervorgerufen wird. Die Auswahl eines zufälligen Wertes ist folglich nicht
schlechter als die Mittelwertmethode.
60

4. Testmustergenerierung mit Hilfe von Wahrscheinlichkeitsverteilungen
Die in der Testumgebung erfolgte Abbildung abstrakter Testdaten auf konkrete Eingabewerte
dient lediglich dem Zweck der Abdeckungsmessung. Das Ergebnis der Testmustergenerierung
bleiben jedoch die abstrakten Testmuster, welche lediglich die Nummern der
Äquivalenzklassen des diskretisierten Eingangssignals beinhalten. Während einer späteren
Testdurchführung muss wiederum die Abbildung auf konkrete Testdaten erfolgen. Durch
dieses Vorgehen bleiben die bereits in Kapitel 3.4.1 genannten Vorteile der abstrakten
Testdaten erhalten.
4.2.2.2 Kontinuierlicher Wertebereich
Der Kern des Verfahrens in diesem Unterkapitel liegt darin, dass der Testentwickler eine
kontinuierliche Wahrscheinlichkeitsverteilung vorgibt. Dies erfolgt durch Angabe einer
Funktion, bei der es sich um eine stetige Wahrscheinlichkeitsdichte f(x) handelt (vgl.
Anhang A Grundlagen der Wahrscheinlichkeitsrechnung). Die Angabe einer Wahrscheinlichkeitsdichte
ermöglicht keine Bevorzugung einzelner Werte wie es in Abschnitt
4.2.1 der Fall war, da jedes noch so kleine Teilintervall [a, b] mit a ≠ b unendlich viele
Werte enthält. Mithilfe der Wahrscheinlichkeitsdichte erfolgt vielmehr eine Gewichtung
über Teilintervalle.
Ein wichtiger Aspekt der Wahrscheinlichkeitsdichte ist, dass die Fläche unter dem
Graphen im Wertebereich des Eingangssignals den Wert Eins haben muss. Die Wahrscheinlichkeit,
dass Werte aus einem Teilintervall [a, b] generiert werden, kann mit der
folgenden Formel bestimmt werden und entspricht der Fläche unter dem Graphen der
Wahrscheinlichkeitsdichte in dem jeweiligen Teilintervall:
b
∫
P ( a ≤ X ≤ b)
= f ( x)
dx , wobei a < b gilt.
a
Die Angabe einer konkreten Funktion als mathematische Formel fällt einem Testentwickler
in der Regel sehr schwer, wenn dies überhaupt möglich ist. Deshalb wird entsprechend
dem Vorgehen bei der manuellen Testfallerstellung an dieser Stelle davon ausgegangen,
dass Schwerpunkte modelliert werden, sodass Werte bestimmter Bereiche bevorzugt und
Werte anderer Bereiche vernachlässigt werden.
Zu diesem Zweck wird in dieser Arbeit die Wahrscheinlichkeitsdichte in Form einer
Menge von Stützstellen angegeben. Die Dichtefunktion f(x) wird aus diesen mittels
Interpolation mit kubischen Splines ermittelt, wodurch eine stetig differenzierbare Funktion
entsteht. Da die Interpolation an sich für das Verfahren der Testmustergenerierung in
dieser Arbeit keine Rolle spielt, wird auf diesen Aspekt an dieser Stelle nicht weiter
eingegangen. Die Interpolation wird lediglich dazu verwendet, zwischen den Stützstellen
eine stetig differenzierbare Funktion zu erhalten, wodurch der Graph der Funktion keine
Knicke enthält. Informationen über die mathematischen Hintergründe sind unter anderem
in [Roo99] gegeben. Auf diese Weise kann der Testentwickler durch Verschieben von
Stützstellen oder die Angabe neuer Stützstellen die Dichtefunktion beliebig verändern, bis
die geplanten Schwerpunkte während Testmustergenerierung gesetzt wurden.
61

4.2. Steuerung des Zufallprozesses mit Wahrscheinlichkeitsverteilungen
Abbildung 4-10 zeigt eine solche Wahrscheinlichkeitsdichte. Die fünf zur Erstellung der
Dichtefunktion verwendeten Stützstellen sind darin als Kreuze gekennzeichnet und liegen
an den Stellen 1, 6, 7, 8 und 10.
Abbildung 4-10: Beispiel einer Wahrscheinlichkeitsdichte
Die Erzeugung von Eingabedaten für analoge Eingangssignale des Systems erfolgt während
der Testfallgenerierung aufgrund der als Wahrscheinlichkeitsdichte vorgegebenen
kontinuierlichen Wahrscheinlichkeitsverteilung.
In Abbildung 4-10 ist beispielhaft eine Wahrscheinlichkeitsdichte über dem Intervall
[1, 10] abgebildet. Diese beruht wiederum auf einer Dreiteilung des Wertebereichs. So
wurde eine Gewichtung vorgenommen, mit der das Intervall [1, 6.5[ mit einem Drittel
Wahrscheinlichkeit versehen wurde. Das Gleiche gilt für die beiden Intervalle [6.5, 7.5]
und ]7.5, 10]. Ausgehend vom Beispielsystem aus Abbildung 4-8 sind dadurch während
der Testmustergenerierung die drei Zustandsübergänge derart gewichtet, dass sie jeweils
mit einem Drittel Wahrscheinlichkeit ausgewählt werden, wenn sich das System im
Zustand vor dem Zustandsübergang befindet.
Unter Verwendung der in Abbildung 4-10 vorgestellten Wahrscheinlichkeitsverteilung
wurden Ergebnisse mit dem TestCaseCommander erzeugt, welche in Kapitel 6.2 den
Ergebnissen der Gleichverteilung gegenübergestellt werden.
62

5 Implementierung des Testfallgenerators
Dieses Kapitel beschäftigt sich mit der Implementierung des in dieser Arbeit entwickelten
Testfallgenerators TestCaseCommander, welcher das in Kapitel 4 vorgestellte Verfahren
zur Testmustergenerierung mithilfe von Wahrscheinlichkeitsverteilungen verwendet.
Der Testfallgenerator ist in der in MATLAB integrierten Skriptsprache M implementiert,
welche in der Regel eine Strukturierung der Software in mehrere Teilskripte erfordert. Die
Softwarearchitektur des TestCaseCommanders unterteilt sich in das Hauptprogramm
TestCaseCommander und die Unterprogramme Generator, Reporter,
Evaluator und Simulator.
Test Case
Commander
Generator.m
Simulator.m
Interface
Parameter
Editor
Generation
Status
Evaluator.m
cvsim.m
Input Editor
Reporter.m
Simulink:
Model Coverage Tool
Weight
Editor
Probability Density
Function Editor
Abbildung 5-1: Softwarestruktur des TestCaseCommanders
cvhtml.m
Zur graphischen Benutzeroberfläche (engl. Graphical User Interface, GUI) zählen neben
dem Hauptfenster TestCaseCommander und kleineren Dialogen die Hauptdialoge Interface
Parameter Editor, Input Editor, Weight Editor, Probability Density Function Editor und
Generation Status, welche in Abbildung 5-1 farblich hervorgehoben sind. Die zwei Skripte
cvsim und cvhtml bilden die einzigen externen Komponenten, welche nicht in dieser
Arbeit implementiert wurden. Diese gehören zum Simulink Model Coverage Tools
[SimModCov], welches von The Mathworks [Mathworks] als Zusatzkomponente der Entwicklungsumgebung
MATLAB vertrieben wird. Es dient der Messung verschiedener
Abdeckungskriterien für Modelle aus MATLAB Simulink und Stateflow.
Die nachfolgenden Unterkapitel gehen detailliert auf die genannten Unterprogramme und
GUI-Komponenten ein. Dies erfolgt anhand der in Kapitel 4.2 verwendeten Beispielsysteme.
Zuerst wird in Unterkapitel 5.1 das Hauptprogramm vorgestellt, über das die übrigen
Programmteile durch den Anwender aufgerufen werden. Daran anschließend wird in
63

5.1. Das Hauptprogramm: TestCaseCommander
Unterkapitel 5.2 die Funktionalität der wichtigsten Hauptdialoge beschrieben, welche unter
anderem die Angabe der zu verwendenden Wahrscheinlichkeitsverteilungen ermöglichen.
Die Implementierung des verwendeten Verfahrens zur Testmustergenerierung folgt in
Unterkapitel 5.3. Daran anschließend wird in Abschnitt 5.4 auf die Softwarekomponenten
des TestCaseCommanders eingegangen, die von den bereits erwähnten Komponenten
verwendet werden. Das Unterkapitel 5.5 geht auf die Testumgebung ein, in die das
Testobjekt zur Anwendung des TestCaseCommanders eingebettet werden muss.
5.1 Das Hauptprogramm: TestCaseCommander
Das M-Skript TestCaseCommander.m ist das Hauptprogramm, mit welchem die
grafische Oberfläche des Testfallgenerators gestartet wird. Das zugehörige Hauptfenster
des TestCaseCommanders bietet dem Anwender eine Darstellung des aktuell bearbeiteten
Testfalls (engl. Test Case) in zwei Arbeitsbereichen. In Abbildung 5-2 ist dieses mit den
vorgenommenen Einstellungen für das Beispielmodell Automat_diskret (vgl. Kapitel
4.2.1 dargestellt.
Abbildung 5-2: Hauptfenster des TestCaseCommanders
Der linke Arbeitsbereich zeigt die zur Generierung neuer Testmuster benötigten Konfigurationsmöglichkeiten.
Zusätzlich wird an dieser Stelle die aktuell erreichte
Modellabdeckung des Testfalls angezeigt. Die Unterteilung in vier Teilbereiche folgt der
chronologischen Reihenfolge der Arbeitsschritte zur Erstellung eines neuen Testfalls. Der
Teilbereich General beinhaltet den Namen des Testfalls und einen Benutzerkommentar,
wodurch der bearbeitete Testfall durch den Testentwickler beschrieben werden kann.
64

5. Implementierung des Testfallgenerators
Die Definition des Testobjektes erfolgt im zweiten Teilbereich. In diesem wird das Modell
des Systems angegeben, auf Basis dessen die Erzeugung von Testmustern erfolgen soll.
Zusätzlich wird an dieser Stelle der Parameter Simulation Sample Time definiert, durch den
der zeitliche Abstand der Testschritte (vgl. Kapitel 3.1.2 Testschritt) bestimmt wird, in
denen das Modell stimuliert wird. Die Beschreibung der Eingabeschnittstellen des Modells
(engl. Model Inputs) ist ebenfalls Bestandteil dieses Arbeitsschritts und wird in einer separaten
GUI (siehe Abschnitt 5.2.1) vorgenommen, welche über den Button Edit geöffnet
wird.
Der dritte Arbeitsschritt beinhaltet die Angabe der wichtigsten Einstellungsmöglichkeiten
zur Generierung (Teilbereich Generation). Hierzu zählen unter anderem die bereits in
Kapitel 4.1.4 erwähnten Abbruchkriterien wie die maximale Anzahl an Testmustern und
die maximale Anzahl an Testvektoren pro Testmuster, die während der Testmustergenerierung
erzeugt werden. Ebenfalls werden an dieser Stelle die initiale Länge der Teilsequenz,
welche pro Zyklus an das erstellte Testmuster angehängt wird, und der Wachstumsfaktor
dieser Teilsequenz angegeben (vgl. Kapitel 4.1.4).
Die Angabe der als Testziel verwendeten Abdeckungskriterien erfolgt ebenfalls im Teilbereich
Generation. Dies geschieht durch so genannte Checkboxen, durch die eine Auswahl
unter den vom Simulink Model Coverage Tool [SimModCov] angebotenen Abdeckungskriterien
getroffen wird. Zur Auswahl steht die C2-Abdeckung (Decision Coverage), die
Mehrfach-Bedingungsabdeckung (Condition Coverage) sowie die Modifizierte Mehrfach-
Bedingungsabdeckung (Modified Condition / Decision Coverage) (siehe Kapitel 3.3.4.3).
Zusätzlich bietet das Simulink Model Coverage Tool ein weiteres Abdeckungskriterium
an, welches nicht in Kapitel 3.3 behandelt wurde, da es nicht zu den allgemein üblichen
Abdeckungskriterien zählt. Hierbei handelt es sich um die Table Look-up Coverage,
welche die Abdeckung der im Modell verwendeten Tabellen – unter anderem in dem
Simulinkblock Look-Up Table – misst. Dieses Abdeckungskriterium steht ebenfalls dem
Anwender des TestCaseCommanders zur Verfügung.
Die Aktivierung des Parameters Automatic naming hat den Effekt, dass die während der
Generierung erzeugten Testmuster automatisch mit Namen versehen werden. Mit Prefer
boundary values wird eingestellt, ob der Testmustergenerator die Randwerte der Wertebereiche
analoger Eingangssignale während der Testmustergenerierung bevorzugt generieren
soll. Dadurch wird sichergestellt, dass bei einem Wertebereich [a, b] die Randwerte
a und b während der Testmustergenerierung vorkommen. Da die Wahrscheinlichkeit, dass
einzelne Werte zufällig erzeugt werden, aus mathematischer Sicht Null ist (vgl. Anhang A
Grundlagen der Wahrscheinlichkeitsrechnung), ist dies die einzige Möglichkeit, durch die
der Anwender sicherstellen kann, dass das Testobjekt mit den exakten Werten der
Intervallgrenzen während der Testmustergenerierung stimuliert wird. Mithilfe der Option
Full generation report wird eingestellt, ob während der Testmustergenerierung Zusatzinformationen
angezeigt werden sollen, welche die Entstehung eines neuen Testmusters
protokollieren.
65

5.2. Die Hauptdialoge
Im Teilbereich Results des Hauptfensters werden permanent die aktuell erreichten Testfallabdeckungsgrade
der vier unterstützten Abdeckungskriterien angezeigt. Ebenfalls besteht
hier über den Button Show Test Case Report die Möglichkeit, einen Report zu generieren,
welcher detaillierte Informationen über die durch den Testfall erreichte Modellabdeckung
liefert. Diese Aufgabe übernimmt die Softwarekomponente Reporter, welche in Abschnitt
5.4.1 behandelt wird.
Der rechte Arbeitsbereich ist zweigeteilt. Im oberen Abschnitt wird eine Übersicht über die
Testmuster geboten, aus denen der Testfall bereits besteht. Es besteht die Möglichkeit,
einzelne Testmuster zu entfernen, zu importieren und mittels erneuter Generierung zu
ersetzen, wobei sämtliche im TestCaseCommander vorgenommenen Einstellungen berücksichtigt
werden. Zusätzlich besteht die Möglichkeit, einen Abdeckungsreport für ein
ausgewähltes Testmuster anzeigen zu lassen.
Im unteren Teil des rechten Arbeitsbereichs wird permanent die Modellabdeckung des
selektierten Testmusters angezeigt, wodurch der Anwender die Möglichkeit hat, die
erzeugten Testmuster zu vergleichen und bessere von schlechteren zu trennen, um gegebenenfalls
ausgewählte zu entfernen oder durch neu erzeugte Testmuster zu ersetzen.
5.2 Die Hauptdialoge
Dieses Unterkapitel beschäftigt sich mit den Hauptdialogen der grafischen Oberfläche. Die
Dialoge Interface Parameter Editor und Input Editor werden zur Angabe der Schnittstellenparameter
der Eingabesignale verwendet. Mithilfe der Dialoge Weight Editor und
Probability Density Function Editor können die zu verwendenden diskreten und kontinuierlichen
Wahrscheinlichkeitsverteilungen angegeben werden. Das Fenster Generation
Status dient der Anzeige von Statusinformationen während der Testmustergenerierung.
5.2.1 Interface Parameter Editor
Der Dialog Interface Parameter Editor zeigt die Namen und Typen der durch den
Testentwickler angegebenen Eingangssignale (Abbildung 5-3) und bietet die Möglichkeit,
neue Eingangssignale hinzuzufügen (Add Input), ein bestehendes zu editieren (Edit Input)
oder auch zu entfernen (Remove Input). Bei Betätigung des Buttons Add Input wird ein
neues Eingangssignal erstellt, welches durch den Testentwickler mithilfe des Dialogs Input
Editor beschrieben werden kann. Derselbe Dialog wird geöffnet, wenn über den Button
Edit Input die Beschreibung eines bestehenden Eingangssignals bearbeitet wird.
66

5. Implementierung des Testfallgenerators
Abbildung 5-3: Interface Parameter Editor
5.2.2 Input Editor
Wenn durch den Testentwickler ein neues Signal hinzugefügt oder ein bestehendes Signal
editiert wird, erfolgt dies mithilfe des Dialogs Input Editor (Abbildung 5-4). Dieser dient
zur Beschreibung eines Eingangssignals des Modells. Die dazu benötigten Daten sind der
Name, der Typ und der Wertebereich des Eingangssignals sowie die Wahrscheinlichkeitsverteilungen,
von denen die oberste während der Testmustergenerierung verwendet wird.
Der Name eines neu erstellten Eingangssignals ist standardmäßig NewInput und muss vom
Testentwickler durch den gewünschten Namen ersetzt werden. Im Beispiel aus Abbildung
5-4 hat das bearbeitete Eingangssignal den Namen In1. Die bereits in Kapitel 4.2
behandelten Signaltypen werden durch eine Auswahl zwischen Discrete Input für ein
diskretes Eingangssignal und Analog Input für ein analoges Eingangssignal unterschieden.
Der gewählte Typ beeinflusst die Art der Angabe des Wertebereichs (engl. Codomain)
eines Eingangssignals. Die Angabe des Wertebereichs eines diskreten oder diskretisierten
Eingangssignals erfolgt in der mathematischen Mengenschreibweise mit den geschweiften
Klammern ’{’ und ’}’. In Abbildung 5-4 beinhaltet der Wertebereich von In1 die ganzzahligen
Werte von Eins bis Zehn. Der Wertebereich eines analogen Eingangssignals wird als
Intervall angegeben (Abbildung 5-5).
Im unteren Bereich des Dialogs wird die Liste der angegebenen Wahrscheinlichkeitsverteilungen
angezeigt. Von diesen wird die oberste während der Testmustergenerierung
berücksichtigt. Mithilfe der Buttons Move Up, Move Down können die angegebenen Wahrscheinlichkeitsverteilungen
sortiert werden. Dies ermöglicht dem Testentwickler bei der
Generierung von mehreren Testmustern, einzelne Testmuster aufgrund unterschiedlicher
Wahrscheinlichkeitsverteilungen zu erzeugen.
Die Anzeige der Wahrscheinlichkeitsverteilungen erfolgt als Angabe eines Dateinamens,
wenn es sich um eine kontinuierliche Wahrscheinlichkeitsverteilung handelt. In der referenzierten
Datei befindet sich eine für die Testdatengenerierung optimierte Darstellung der
Wahrscheinlichkeitsdichte.
67

5.2. Die Hauptdialoge
Abbildung 5-4: Input Editor
Abbildung 5-5: Input Editor (analog)
Eine diskrete Wahrscheinlichkeitsverteilung wird durch eine Menge von Gewichten
beschrieben. Dazu wird jedem Wert, den ein Eingangssignal annehmen kann, ein Gewicht
zugeordnet. Eine diskrete Wahrscheinlichkeitsverteilung P j lässt sich aus einer angegebenen
Gewichtung W j berechnen, indem für jeden Wert x i die Wahrscheinlichkeit, dass dieser
während der Testmustergenerierung erzeugt wird, mit der folgenden Formel berechnet
wird.
P(
X
In1
= x ) =
i
∑
x j∈D
x ≠x
j
W ( X
In1
= xi
)
W ( X = x )
In1
i
In1
j
In Abbildung 5-4 sind die bereits in Kapitel 4.2.1 (Beispielmodell Automat_diskret)
behandelten diskreten Wahrscheinlichkeitsverteilungen in Form von zwei Gewichtungen
68

5. Implementierung des Testfallgenerators
abgebildet. Abbildung 5-5 zeigt die entsprechende Darstellung für die kontinuierlichen
Wahrscheinlichkeitsverteilungen anhand des Beispielmodells Automat_analog aus
Kapitel 4.2.2.2. Die verwendeten Wahrscheinlichkeitsverteilungen können durch den
Anwender einzeln mithilfe des Edit-Buttons modifiziert werden, wodurch einer der
Dialoge Weight Editor (diskreter Fall) oder Probability Density Function Editor (analoger
Fall) geöffnet wird. Diese werden in den folgenden Abschnitten behandelt.
5.2.3 Weight Editor
Der Dialog Weight Editor (Abbildung 5-6) dient der Angabe einer diskreten Wahrscheinlichkeitsverteilung,
wie sie bereits im vorherigen Abschnitt erwähnt wurde. Die Angabe
erfolgt mithilfe von Gewichten. Hierzu wird in Form der mathematischen Mengenschreibweise
eine Menge von Gewichten angegeben, welche in gleicher Reihenfolge den Werten
des diskreten Wertebereichs des bearbeiteten Eingangssignals zugeordnet werden.
Abbildung 5-6: Weight Editor
5.2.4 Probability Density Function Editor
Die Angabe einer kontinuierlichen Wahrscheinlichkeitsverteilung erfolgt mithilfe des Dialogs
Probability Density Function Editor (Abbildung 5-7). Mit diesem wird durch eine
Menge von Stützstellen eine Wahrscheinlichkeitsdichtefunktion (engl. Probability Density
Function) angegeben. Zur Angabe der kontinuierlichen Wahrscheinlichkeitsverteilung aus
Kapitel 4.2.2.2 sind beispielsweise fünf Stützstellen notwendig (siehe Abbildung 5-7).
Zwischen den angegebenen Stützstellen erfolgt – wie bereits in Kapitel 4.2.2 beschrieben –
eine Interpolation mit kubischen Splines, wodurch die Dichte als stetige Funktion über
dem Wertebereich des betroffenen Eingangssignals definiert ist.
Mithilfe der Stützstellen und des dadurch definierten Graphen kann eine Wahrscheinlichkeit
für einzelne Intervalle des Wertebereichs angegeben werden. Um diese Angabe
genauer vornehmen zu können, wird mit den unteren beiden Verstellelementen A und B in
der grafischen Oberfläche ein Intervall ausgewählt. Im Beispiel in Abbildung 5-7 wurde
dies für das Intervall [4.9, 5.1] getätigt.
Mit den zwei Verstellelementen für die X- und Y-Koordinaten kann eine ausgewählte
Stützstelle derart verstellt werden, dass die Wahrscheinlichkeit des Intervalls [A, B] einen
gewünschten Wert annimmt. Im Beispiel ist eine Wahrscheinlichkeit von ca. 33 Prozent
(0.33248) für das Intervall [4.9, 5.1] eingestellt, welche im linken Bereich des Dialogs
angezeigt wird.
69

5.2. Die Hauptdialoge
Abbildung 5-7: Probability Density Function Editor
Die angegebene Wahrscheinlichkeitsdichtefunktion wird beim Verlassen des Dialogs über
einen der Buttons Save As…& Exit und Save & Exit in eine Datei gespeichert. Diese wird
während der Testmustergenerierung geladen und als kontinuierliche Wahrscheinlichkeitsverteilung
berücksichtigt.
5.2.5 Generation Status
Während das Unterprogramm Generator (siehe Kapitel 5.3) ausgeführt wird, wird der
Dialog Generation Status angezeigt (Abbildung 5-8). Dieser liefert Statusinformationen
über den Fortschritt der Testmustergenerierung. Zu diesen zählen in erster Linie die
Abdeckungsgrade des aktuell erzeugten Testmusters (Test Pattern Coverage) und des
gesamten Testfalls (Test Case Coverage). Ebenfalls werden der Name und die Länge des
aktuellen Testmusters während der Generierung angezeigt. Zusätzliche Informationen wie
die zur Testmustergenerierung benötigte Zeit (Used Time) sowie der Anzahl der benötigten
Testvektoren (Used test vectors) werden ebenfalls angezeigt. Sowohl die Länge des
aktuellen Testmusters (Actual lenght) als auch die Länge der Teilsequenz (Probe length),
welche an das aktuelle Testmuster angehängt wird, werden ebenfalls angezeigt (vgl.
Kapitel 4). Im unteren Teil des Dialogs wird ein Protokoll angezeigt, welches die
Entstehung der erzeugten Testmuster protokolliert. Dieses kann mithilfe des Buttons Save
Protocol für spätere Analysen gespeichert werden
70

5. Implementierung des Testfallgenerators
Abbildung 5-8: Generation Status
Im Beispiel aus Abbildung 5-8 wurde das Testmuster mit dem Namen TestPattern_01
erzeugt. Es hat eine Länge von zwei Testvektoren, zu dessen Generierung fünf Testvektoren
verwendet wurden.
5.3 Das Verfahren zur Testmustergenerierung
Das im TestCaseCommander verwendete Verfahren zur Testmustergenerierung ist in den
drei Komponenten Generator, Evaluator und Simulator implementiert. In der
Generator-Komponente ist der Algorithmus zur Testmustergenerierung implementiert.
Dieser verwendet die beiden Unterprogramme Evaluator und Simulator. Mit dem
Button Start Generation im Hauptfenster des TestCaseCommanders wird das Unterprogramm
Generator aufgerufen, welches nicht nur die Funktionalität des ATGs aus
Abbildung 4-2 übernimmt, sondern darüber hinaus das zyklische Vorgehen steuert. Dieses
besteht aus der Erzeugung von Testdaten, der Simulation derselben und der Bewertung der
Testdaten.
Das Unterprogramm Simulator dient der Simulation eines Testmusters und verwendet
das M-Skript cvsim des Simulink Model Coverage Tools zur Messung der Modellabdeckung.
Auf den Aspekt der Simulation mit Abdeckungsmessung in der Testumgebung
wird später in Abschnitt 5.5 näher eingegangen.
71

5.4. Weitere Softwarekomponenten
Das M-Skript Evaluator wird zur Berechnung der Testfallabdeckung verwendet. Es
besteht aus technischen Gründen keine Möglichkeit, bereits ermittelte Abdeckungsgrade
einzelner Testmuster zu einem Testfallabdeckungsgrad zu verrechnen. Deshalb muss in
jedem Zyklus unter Verwendung der Komponente Simulator der Testfallabdeckungsgrad
bestimmt werden, indem die Testmuster eines Testfalls erneut evaluiert werden.
Die Aufgabe der Verwaltung vorhandener Testmuster übernimmt während der Testmustergenerierung
ebenfalls das Unterprogramm Generator. Nach Abschluss der Generierung
wird diese Verwaltungsaufgabe allerdings an das Hauptprogramm übergeben. Aus diesem
kann dann eine weitere Testmustergenerierung unter Berücksichtigung der bereits existierenden
Testmuster angestoßen werden.
5.4 Weitere Softwarekomponenten
5.4.1 Reporter
Das Unterprogramm Reporter dient zur Erzeugung eines Abdeckungsreports. Dieser
beinhaltet detaillierte Informationen über abgedeckte Modellbereiche. Hierbei werden bis
auf Blockebene für alle Hierarchiestufen des Modells die Abdeckungsgrade der vier durch
das Simulink Model Coverage Tool unterstützten Abdeckungskriterien angezeigt.
Abbildung 5-9 zeigt beispielhaft einen Ausschnitt eines solchen Abdeckungsreports (engl.
Coverage Report), welcher anhand des Beispielsystems Automat_diskret aus Kapitel
4.2.1 erzeugt wurde.
Abbildung 5-9: Abdeckungsreport
Die Implementierung des TestCaseCommanders ermöglicht die Erzeugung von derartigen
Abdeckungsreporten sowohl für einzelne Testmuster als auch für vollständige Testfälle.
72

5. Implementierung des Testfallgenerators
Die Anzeige eines Abdeckungsreports ermöglicht dem Testentwickler die Analyse der
Testmuster des Testfalls, welchen er gerade bearbeitet. Aufgrund von Informationen über
die Modellabdeckung einzelner Modellbereiche können Modellbereiche identifiziert
werden, für die gezielt Testmuster erzeugt werden müssen, um ihre Abdeckung zu gewährleisten.
5.4.2 cvsim
Das M-Skript cvsim ist Bestandteil des Simulink Model Coverage Tools. Es dient zur
Simulation von Modellen in MATLAB Simulink/Stateflow mit gleichzeitiger Abdeckungsmessung.
Es bietet die Möglichkeit vor der Simulation Testdaten in MATLAB zu laden,
wobei cvsim nicht die Stimulierung des Modells mit diesen übernimmt. Nähere Informationen
zur Art der Stimulierung bietet Unterkapitel 5.5. Das M-Skript cvsim dient
lediglich der Simulation eines Modells in MATLAB Simulink mit gleichzeitiger Messung
der Abdeckungsgrade bzgl. der Abdeckungskriterien C 2 -Abdeckung, Mehrfach-Bedingungsabdeckung,
MC/DC und Table Look-up Coverage (vgl. Abschnitt 5.1). Die während
der Simulation gemessene Modellabdeckung wird in speziellen Datenobjekten (cvdata
objects) gespeichert.
Das Unterprogramm cvsim bietet darüber hinaus die Möglichkeit, die Ausgaben eines
Modells während der Simulation aufzuzeichnen und bereitzustellen. Auf diese Art und
Weise kann eine Erzeugung von Referenzdaten für die spätere Testdurchführung erfolgen.
Dies wurde allerdings im Rahmen dieser Arbeit nicht implementiert, da eine Verwendung
der erzeugten Testdaten in Kombination mit Referenzdaten nicht Bestandteil dieser Arbeit
ist.
5.4.3 cvhtml
Das Unterprogramm cvhtml ist ebenfalls Bestandteil des Simulink Model Coverage Tools
und dient der Erstellung eines Abdeckungsreports aus Informationen über die Modellabdeckung
von Testmustern. Diese benötigt es in speziellen Datenobjekten (cvdata
objects), welche beispielsweise das M-Skript cvsim liefert. Aussehen und Inhalt eines
Abdeckungsreports wurden bereits in Abbildung 5-9 gezeigt und in Abschnitt 5.4.1 erläutert,
weswegen an dieser Stelle nicht näher darauf eingegangen wird.
5.5 Die Testumgebung
Die in dieser Arbeit verwendete Testumgebung (MATLAB Simulink) ermöglicht keine
direkte Stimulierung des Testobjekts mit Testdaten. Zu diesem Zweck muss das Modell in
die Testumgebung eingebettet werden. Dies erfolgt, indem es als Teilsystem in ein Modell
eingefügt wird, welches die notwendigen Komponenten zur Stimulation des Testobjekts
beinhaltet. Anhand von Beispiels Automat_diskret aus Kapitel 4.2.1 wird dieses Vorgehen
im Folgenden verdeutlicht. Der in Abbildung 4-7 dargestellte Statechart ist Teil des
Simulinkmodells Automat_diskret, in welchem der Statechart als Simulinkblock
Chart vorkommt. Das modellierte System hat ein Eingangs- und ein Ausgangssignal.
73

5.5. Die Testumgebung
Abbildung 5-10: Einbetten des Testobjekts in die Testumgebung
Abbildung 5-10 zeigt das in ein umgebendes Modell eingebettete Testobjekt. Zur Stimulation
der Eingabeschnittstelle In1 wird dessen Eingangssignal mit dem Simulinkblock
From Workspace verbunden. Dieser ermöglicht, dass das Testobjekt während einer
Simulation pro Testschritt mit einem Testdatum aus einer in MATLAB geladenen Sequenz
von Testdaten stimuliert wird. Das Laden dieser Testdaten ist mithilfe des M-Skripts
cvsim möglich, welches zum Starten der Simulation mit gleichzeitiger Abdeckungsmessung
verwendet wird (vgl. Abschnitt 5.4.2). Das Ausgangssignal Out1 wird
unverändert nach außen weitergeleitet.
74

6 Evaluierung des Testmustergenerators
Die in diesem Kapitel vorgestellten Ergebnisse wurden durch Anwendung des Testmustergenerators
TestCaseCommander aus Kapitel 5 anhand von ausgewählten Beispielmodellen
ermittelt. In den Unterkapiteln 6.1 und 6.2 wird zu diesem Zweck auf einfache Beispielmodelle
aus den vorherigen Kapiteln zurückgegriffen. Daran anschließend erfolgt in
Abschnitt 6.3 die Evaluierung des Verfahrens anhand eines komplexeren Modells, welches
einen Kaffeeautomaten modelliert. Unterkapitel 6.4 schließt das Kapitel mit einer
Bewertung der vorgestellten Ergebnisse ab.
6.1 Beispielmodell Automat_diskret
Die Ergebnisse dieses Abschnitts wurden durch mehrfache Anwendung des Verfahrens aus
Kapitel 4 mit dem Beispielmodell aus Abbildung 6-1 ermittelt, welches bereits in Kapitel
4.2.1 vorgestellt und in seiner Funktionalität beschrieben wurde. Das System hat ein
Eingangssignal In1 und ein Ausgangssignal Out1. Die zugehörigen Wertebereiche sind
D In1 = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10} und D Out1 = {0, 1, 2}.
Abbildung 6-1: Beispielmodell Automat_diskret 3
Die Anwendung des Verfahrens erfordert die Angabe einer Wahrscheinlichkeitsverteilung
über dem Wertebereich jedes Eingangssignals. Es wurden in jeweils zwanzig Durchläufen
die Wahrscheinlichkeitsverteilungen P 1 und P 2 (Tabelle 6-1) für das Eingangssignal In1
verwendet. P 1 ist eine Gleichverteilung und repräsentiert das allgemeine Verfahren zur
zufallsbasierten Testmustergenerierung aus Kapitel 3.4.2. Durch eine Gleichverteilung
werden während der Generierung von Testdaten sämtliche möglichen Werte aus D In1 im
Durchschnitt gleichhäufig erzeugt, wodurch keine Bevorzugung einzelner Werte erfolgt.
3 Wiederholung von Abbildung 4-7 aus Kapitel 4.2.1 zum Vorstellen der Evaluierungsergebnisse
75

6.1. Beispielmodell Automat_diskret
Im Gegensatz dazu dient die Wahrscheinlichkeitsverteilung P 2 zur Bevorzugung einzelner
Werte aus D In1 . Dabei unterteilt P 2 den Wertebereich D In1 in drei Teile, welche jeweils mit
einem Drittel Wahrscheinlichkeit versehen sind. Die Werte kleiner sieben haben jeweils
eine Wahrscheinlichkeit von 0 ,05
, wodurch die Summe ihrer Wahrscheinlichkeiten ein
Drittel ergibt. Der zweite Teilbereich beinhaltet lediglich den Wert Sieben, welchem die
Wahrscheinlichkeit 0 , 3 zugeordnet wird. Die Werte oberhalb von Sieben wurden jeweils
mit der Wahrscheinlichkeit 0 , 1 versehen, wodurch dieser Teilbereich ebenfalls ein Drittel
Wahrscheinlichkeit hat.
x i P 1 (X In1 = x i ) P 2 (X In1 = x i )
1 0,1 0 ,05
2 0,1 0 ,05
3 0,1 0 ,05
4 0,1 0 ,05
5 0,1 0 ,05
6 0,1 0 ,05
7 0,1 0 , 3
8 0,1 0 , 1
9 0,1 0 , 1
10 0,1 0 , 1
Tabelle 6-1: Gewählte Wahrscheinlichkeitsverteilungen 4
Zur Testmustergenerierung wurde der TestCaseCommander verwendet. Zur Ermittlung
aussagekräftiger Ergebnisse erfolgte dies in zwanzig Durchläufen. Dies geschah mit dem
Testziel, in dem Beispielsystem Automat_diskret die Abdeckung sämtlicher atomarer
Bedingungen (vgl. Kapitel 3.3.4.3) zu erreichen. Dadurch ist das Testziel auf die Abdeckung
von (In1 > 7), (In1 == 7) und (In1 < 7) gerichtet. Diese Bedingungen
müssen durch Testdaten jeweils einmal mit wahr und falsch bewertet werden. Zu berücksichtigen
ist, dass immer nur diejenige Bedingung bewertet wird, welche an einem
Zustandsübergang ausgehend vom aktuellen Zustand des Systems liegt. Dies bedeutet, dass
beispielsweise vom Zustand S0 bei Anwendung eines Testdatums lediglich die Bedingung
(In1 > 7) mit wahr oder falsch bewertet wird. Die anderen Bedingungen sind bei diesem
Testdatum nicht betroffen.
Eine optimale Abfolge von Testdaten, die zu hundertprozentiger Abdeckung des genannten
Kriteriums führt, ist für das vorliegende Modell aus Abbildung 6-1 beispielsweise
folgende: e 1 = 5, e 2 = 8, e 3 = 5, e 4 = 7, e 5 = 8, e 6 = 5. Es ist nicht möglich, mithilfe eines
kürzeren Testmusters ebenfalls hundertprozentige Abdeckung zu erreichen. Mit den
Eingabedaten e 1 und e 2 wird ausgehend vom Initialzustand des Systems S0 zuerst die
4 Wiederholung von Tabelle 4-1 aus Kapitel 4.2.1 zum Vorstellen der Evaluierungsergebnisse
76

6. Evaluierung des Testmustergenerators
Bedingung (In1 > 7) mit falsch dann mit wahr bewertet, wodurch mit e 2 das System in
Zustand S1 übergeht. Damit ist die Übergangsbedingung (In1 > 7) vollständig abgedeckt.
Durch die Eingabedaten e 3 und e 4 erfolgen die gleichen Bewertungen für die
Bedingung (In1 == 7) und analog dazu mit e 5 und e 6 die Bewertungen falsch und wahr
für (In1 < 7). Auf diese Weise wurde mit einem Testmuster der Länge 6 eine
Abdeckung von hundert Prozent bezüglich der atomaren Bedingungsabdeckung erreicht.
Während der Anwendung des TestCaseCommanders wurden unabhängig voneinander
jeweils zwanzig Testmuster pro Wahrscheinlichkeitsverteilung generiert. Unter diesen
waren solche mit der optimalen Länge 6. Die vollständigen Ergebnisse der Testmustergenerierung
sind in Tabelle 6-2 dargestellt. Für jeden Durchlauf des Verfahrens sind die
Länge des erzeugten Testmusters (Ergebnislänge) und die Anzahl der zu dessen Erzeugung
generierten Testdaten (Verbrauch) aufgeführt. Die zweite und dritte Spalte zeigen die mit
der Wahrscheinlichkeitsverteilung P 1 ermittelten Ergebnisse. Die Spalten vier und fünf
beinhalten die entsprechenden Ergebnisse mit der Wahrscheinlichkeitsverteilung P 2 .
Durchlauf
Nr.
P 1 P 2
Ergebnislänge
Verbrauch Ergebnislänge
Verbrauch
1 18 32 7 10
2 67 130 11 17
3 6 7 13 20
4 10 17 15 24
5 7 11 13 20
6 8 11 10 17
7 35 65 6 7
8 25 46 9 12
9 7 9 6 7
10 12 20 21 37
11 14 23 16 27
12 6 9 11 18
13 25 46 10 14
14 69 132 39 72
15 13 23 6 7
16 20 34 14 22
17 12 19 14 23
18 71 136 10 16
19 37 70 18 31
20 14 22 7 8
∅ 23,8 43,1 12,8 20,45
Minimum 6 7 6 7
Maximum 71 136 39 72
Tabelle 6-2: Ergebnisse mit Beispielmodell Automat_diskret
Unter Verwendung der Gleichverteilung P 1 wurde zweimal ein Testmuster mit der optimalen
Anzahl von sechs Testvektoren erzeugt (Durchläufe 3 und 12). Zur Erzeugung dieser
beiden Testmuster wurden im Fall von Durchlauf 3 lediglich 7 Testdaten benötigt,
wodurch nur ein Testdatum durch das Verfahren aus Kapitel 4.1.3 verworfen wurde. In
77

6.2. Beispielmodell Automat_analog
Durchlauf 12 hingegen wurden zur Erzeugung des Testmusters 9 Testdaten benötigt, von
denen 3 verworfen wurden. Durchlauf 3 stellt somit den besten Fall unter den zwanzig
Durchläufen dar, weil das erzeugte Testmuster die optimale Länge hat und zur Erzeugung
dieses Testmusters im Vergleich zu den übrigen Testmustern am wenigsten Testdaten
verworfen wurden.
Dem gegenüber steht Durchlauf 18, in welchem das schlechteste Testmuster unter den
zwanzig Erzeugten gebildet wurde. Es hat im Ergebnis eine Länge von 71 Testvektoren, zu
deren Erzeugung 136 Testdaten generiert wurden. Der Grund für diese im Vergleich zum
Optimalwert extrem hohe Ergebnislänge liegt in dem verwendeten Verfahren aus Kapitel
4.1.3, welches bei jedem Verwerfen von Testdaten die Anzahl der im nächsten Zyklus
generierten Testdaten erhöht.
Die mit der Gleichverteilung P 1 erzeugten Testmuster hatten im Durchschnitt eine Länge
von 23,8 Testvektoren, zu deren Erzeugung im Durchschnitt 43,1 Testvektoren generiert
wurden. Dadurch ergibt sich, dass bei gleich verteilter Testmustergenerierung eine Verschlechterung
um Faktor 4 gegenüber dem optimalen Testmuster mit Länge 6 vorliegt,
welches beispielsweise von einem Testentwickler manuell angegeben werden könnte.
Unter den Testmustern, welche bei Verwendung der Wahrscheinlichkeitsverteilung P 2 in
zwanzig Durchläufen der Testmustergenerierung erzeugt wurden, sind mehrere mit optimaler
Länge (Durchläufe 7, 9 und 15). In diesen drei Fällen wurde jeweils ein Testdatum
verworfen, wodurch wiederum nicht der Fall eingetreten ist, dass direkt ein Testmuster der
Länge 6 ohne Verwerfen erzeugt wurde.
Das längste unter Verwendung von P 2 erzeugte Testmuster wurde in Durchlauf 14 generiert
und hat eine Ergebnislänge von 39 Testvektoren. Zur Erzeugung dieses Testmusters
wurden 72 Testdaten generiert. An dieser Stelle wird der Vorteil des Verfahrens bei Verwendung
einer durch den Testentwickler angegebenen Wahrscheinlichkeitsverteilung
gegenüber der gleich verteilten Testmustergenerierung deutlich. Im schlechtesten Fall sind
die Ergebnisse mit der Wahrscheinlichkeitsverteilung P 2 ungefähr um den Faktor 2 besser
als die Ergebnisse bei Verwendung der Gleichverteilung P 1 .
Auch mit durchschnittlich 20,45 generierten Testvektoren, die zu Testmustern der Länge
12,8 führten, sind die Ergebnisse deutlich besser als bei gleich verteilter Testmustergenerierung.
Damit konnte die Testmustergenerierung mithilfe einer Wahrscheinlichkeitsverteilung
dahingehend gesteuert werden, dass der Aufwand des Generierungsprozesses in
diesem Beispiel halbiert wurde. Zusätzlich wurde die Qualität der gebildeten Testmuster
gesteigert. Diese sind in Verbindung mit P 2 lediglich halb so lang wie bei der Gleichverteilung
P 1 . Dadurch wurde der Prozess der späteren Testdurchführung ebenfalls im
Aufwand reduziert.
6.2 Beispielmodell Automat_analog
Das in Abbildung 6-2 gezeigte Beispielsystem (Automat_analog) wurde bereits in
Kapitel 4.2 behandelt. An dieser Stelle wurde auch die Funktionalität des Systems näher
78

6. Evaluierung des Testmustergenerators
erläutert. Anhand dieses Beispielmodells werden in diesem Kapitel die Ergebnisse der
Testmustergenerierung mithilfe des TestCaseCommanders unter Verwendung stetiger
Wahrscheinlichkeitsverteilungen über dem kontinuierlichen Wertebereich D In1 = [1, 10]
vorgestellt.
Abbildung 6-2: Beispielmodell Automat_analog 5
Zur Anwendung kamen zwei kontinuierliche Wahrscheinlichkeitsverteilungen. P 1 ist die
Gleichverteilung auf dem Intervall [1, 10], welche an dieser Stelle aufgrund ihrer
Einfachheit nicht abgebildet ist. Die zweite gewählte Wahrscheinlichkeitsverteilung P 2
genügt der in Abbildung 6-3 dargestellten Wahrscheinlichkeitsdichte.
Abbildung 6-3: Kontinuierliche Wahrscheinlichkeitsdichte 6
Die Motivation bei Wahl der Wahrscheinlichkeitsverteilung P 2 liegt darin, dass im Durchschnitt
die Bewertungen der drei Übergangsbedingungen mit einem Drittel Wahrscheinlichkeit
mit wahr und zu zwei Drittel mit falsch bewertet werden.
Zur Ermittlung von Durchschnittswerten wurde der TestCaseCommander in jeweils zwanzig
Durchläufen mit den beiden Wahrscheinlichkeitsverteilungen P 1 und P 2 angewendet.
Die Ergebnisse dieses Abschnitts wurden mit dem Testziel erzeugt, in dem Beispielsystem
5 Wiederholung von Abbildung 4-8 aus Kapitel 4.2.2 zum Vorstellen der Evaluierungsergebnisse
6 Wiederholung von Abbildung 4-10 aus Kapitel 4.2.2 zum Vorstellen der Evaluierungsergebnisse
79

6.2. Beispielmodell Automat_analog
sämtliche atomaren Bedingungen (vgl. Kapitel 3.3.4.3) abzudecken. Dies bedeutet, dass
alle Teilbedingungen der Übergangsbedingungen (In1 > 7.5), (In1 < 6.5) und
(In1 >= 6.5 && In1 7.5), (In1 < 6.5),
(In1 >= 6.5) und (In1 7.5) nur in dem Fall mit wahr
oder falsch bewertet werden kann, wenn sich das System in Zustand S0 befindet.
Eine für das Modell aus Abbildung 6-2 optimale Abfolge von Testdaten hat die Länge 7.
Als Beispiel hierfür seien folgende Testdaten genannt: e 1 = 5, e 2 = 8, e 3 = 5, e 4 = 8, e 5 = 7,
e 6 = 8, e 7 = 5. Durch die Eingabedaten e 1 und e 2 wird ausgehend vom Initialzustand des
Systems S0 zuerst die Bedingung (In1 > 7.5) zuerst mit falsch, dann mit wahr bewertet,
wodurch das System in Zustand S1 wechselt. Mithilfe der Eingabedaten e 3 und e 4
werden ausgehend von Zustand S1 die Teilbedingungen (In1 >= 6.5) und
(In1

6. Evaluierung des Testmustergenerators
Durchlauf
Nr.
P 1 P 2
Ergebnislänge
Verbrauch Ergebnislänge
Verbrauch
1 9 12 23 41
2 7 9 19 33
3 51 97 10 14
4 37 69 7 8
5 39 72 9 12
6 10 15 22 39
7 12 20 13 21
8 10 14 9 14
9 19 34 14 24
10 13 20 8 12
11 7 9 7 9
12 15 24 21 39
13 45 84 7 11
14 9 15 11 17
15 74 144 14 24
16 7 10 11 19
17 11 16 9 15
18 73 142 7 9
19 38 70 7 8
20 7 10 7 10
∅ 24,65 44,3 11,75 18,95
Minimum 7 9 7 8
Maximum 74 144 23 41
Tabelle 6-3: Ergebnisse mit Beispielmodell Automat_analog
6.3 Beispielmodell Kaffeeautomat
Das in diesem Abschnitt vorgestellte hybride Simulink/Stateflowmodell repräsentiert einen
vereinfachten Kaffeeautomaten. Dieser dient der Evaluierung des Verfahrens an einem
realistischeren und komplexeren Modell, als es bei den Beispielmodellen der vorherigen
Unterkapitel der Fall ist. In Abschnitt 6.3.1 erfolgt zunächst eine Beschreibung der Grundfunktionalitäten
des modellierten Systems. Daran schließt sich in Abschnitt 6.3.2 die
Beschreibung und Erläuterung der bei der Testmustergenerierung verwendeten Wahrscheinlichkeitsverteilungen
an. Abschnitt 6.3.3 stellt die Ergebnisse der mehrfachen
Testmustergenerierung mit den gewählten Wahrscheinlichkeitsverteilungen vor.
6.3.1 Modellierung der Funktionalität
Das Beispielmodell Kaffeeautomat (Abbildung 6-4) repräsentiert einen Kaffeeautomaten,
welcher dem Benutzer die Möglichkeit zum Kauf verschiedener Getränke bietet.
Über ein Bedienfeld kann der Käufer zwischen den Getränken Kaffee und Cappuccino
wählen. Nachdem über einen Münzeinwurf eine ausreichende Menge Geld eingeworfen
und ein Getränk gewählt wurde, wird dieses in einem Becher ausgegeben. Der Getränkepreis
wird daraufhin vom eingeworfenen Geld abgezogen und ein Becher vom
Bechervorrat des Kaffeeautomaten verbraucht. Über eine Geldrückgabetaste kann das
81

6.3. Beispielmodell Kaffeeautomat
verbliebene Restgeld ausgegeben werden. Zusätzlich hat der modellierte Kaffeeautomat
zwei Warnleuchten, von denen eine dem Benutzer signalisiert, wenn der interne Zwischenspeicher
für Münzen voll ist. Die andere Warnleuchte meldet, wenn der Bechervorrat
aufgebraucht wurde.
Abbildung 6-4: Beispielmodell Kaffeeautomat
Die beschriebenen Funktionalitäten sind in der Modellierung stark vereinfacht. Die Bezahlung
der Getränke ist dahingehend vereinfacht modelliert, dass keine exakten Geldbeträge
sondern lediglich die Anzahl der eingeworfenen Münzen gezählt werden. Die Preise der
Getränke sind auf eine Münze für einen Kaffee und zwei Münzen für einen Cappuccino
festgelegt. Der Münzeinwurf wird durch das boolesche Eingangssignal Muenzeinwurf
modelliert. Es besteht pro Zeiteinheit die Möglichkeit, entweder eine Münze einzuwerfen,
oder dies nicht zu tätigen. Dadurch ist der Wertebereich auf die beiden Werte „0“ für „kein
Münzeinwurf“ und „1“ für „Münzeinwurf“ festgelegt: D Muenzeinwurf = {0, 1}. Das Bedienfeld
zur Auswahl eines Getränkes ist durch das Eingangssignal Auswahl mit dem Wertebereich
D Auswahl = {0, 1, 2} modelliert. Die Werte sind wie folgt zu interpretieren: „0“ steht
für „keine Auswahl getroffen“, „1“ für „Kaffee gewählt“ und „2“ für „Cappuccino
gewählt“.
Das boolesche Eingangssignal Geldrueckgabe repräsentiert die Geldrückgabetaste. Der
Wertebereich D Rueckgabe = {0, 1} ist wie folgt zu interpretieren: entweder wird die Taste zu
einem Zeitpunkt gedrückt (Wert „1“) oder dies wird nicht getan (Wert „0“). Als viertes
Eingangssignal ist eine Spannungsversorgung modelliert. Das Eingangssignal Spannung
hat den Wertebereich D Spannung = [200, 250] und kann sämtliche reelle Werte zwischen 200
und 250 Volt annehmen.
Die Ausgabe eines Kaffees oder Cappuccinos ist durch die Ausgangssignale Kaffee und
Cappuccino modelliert. Diese geben zu jeder Zeiteinheit die Anzahl der gekauften und
82

6. Evaluierung des Testmustergenerators
ausgegebenen Getränke an. Entsprechend zählt das Ausgangssignal Geld_zurueck die
Anzahl der dem Benutzer zurückgegebenen Münzen. Die booleschen Ausgabesignale
Leuchte_Geldspeicher und Leuchte_Becher repräsentieren die Warnleuchten des Kaffeeautomaten
und nehmen entsprechend den Wert „1“ an, wenn der Münzzwischenspeicher
voll bzw. der Bechervorrat verbraucht ist. Ansonsten nehmen sie den Wert „0“ an.
Die Funktionalität des Kaffeeautomaten ist in vier Subsysteme aufgeteilt. Die Kernfunktionalität
ist dabei in dem Subsystem Zentrale_Steuerung modelliert, welches einen
Zustandsautomaten enthält. Bevor auf diesen eingegangen wird, erfolgt eine Beschreibung
der anderen Subsysteme.
Das Subsystem Spannungsüberwachung implementiert die Funktion eines Über- und
Unterspannungsschutzes. Dieser überprüft das Eingangssignal Spannung dahingehend, ob
es über einen festgelegten Zeitraum kritische Werte annimmt. Als kritisch werden Werte
oberhalb von 245 Volt und unterhalb von 205 Volt angesehen. Sollte die Versorgungsspannung
über einen Zeitraum von 6 Zeiteinheiten im kritischen Bereich liegen, wird der
Kaffeeautomat für eine Zeitspanne von 20 Zeiteinheiten abgeschaltet. Das Ausschalten
wird dadurch simuliert, dass sämtliche Eingabesignale nicht weiter beachtet werden.
Das Subsystems Becher_Füllen simuliert den Füllvorgang einer Tasse Kaffee oder
Cappuccino, welcher 5 Zeiteinheiten dauert. Die Modellierung sieht vor, dass es innerhalb
dieser Zeitspanne nicht möglich ist, ein weiteres Getränk zu kaufen.
Im Subsystem Becher_Liefern wurde die Lieferung von neuen Bechern modelliert. Diese
sorgt dafür, dass der interne Bechervorrat in festgelegten zeitlichen Abständen aufgefüllt
wird. Die maximale Anzahl ist auf 15 Becher festgelegt. Von diesen wird bei jedem Kauf
eines Kaffees oder Cappuccinos ein Becher verbraucht. Der zeitliche Abstand zwischen
zwei Becherlieferungen ist auf 200 Zeiteinheiten festgelegt. Dies bedeutet, dass ab dem
Zeitpunkt des Starts des Kaffeeautomaten in einem festen Rhythmus von 200 Zeiteinheiten
der Bechervorrat auf 15 Becher aufgefüllt wird.
Das Subsystem Zentrale_Steuerung modelliert die Hauptfunktionalitäten des Kaffeeautomaten
in einem Zustandsautomaten (Abbildung 6-5). Dieser besteht aus fünf parallelen
Zustandsautomaten, welche im Folgenden kurz erläutert werden.
Die Reaktion auf die Eingangssignale Muenzeinwurf und Geldrueckgabe übernimmt der
Zustandsautomat Kassensystem. Dieser zählt in einem Münzzwischenspeicher die eingeworfenen
Münzen, welche noch nicht durch den Kauf eines Getränkes verbraucht wurden.
Deren Anzahl ist auf maximal 60 Münzen beschränkt. Sollte diese Zahl erreicht werden,
erfolgt die Ausgabe sämtlicher Münzen, die trotz vollem Münzzwischenspeicher eingeworfen
werden. Das Drücken der Geldrückgabetaste hat den Effekt, dass sämtliche Münzen
aus dem Münzzwischenspeicher wieder ausgegeben werden. Dem entsprechend wird das
Ausgangssignal Geld_zurueck um die Anzahl der ausgegebenen Münzen erhöht.
Das Ausgangssignal Leuchte_Geldspeicher repräsentiert die Warnleuchte, welche den
Zustand des vollen Münzzwischenspeichers meldet. Diese wird durch den Zustandsautomaten
Geldspeicher gesteuert und bei vollem Münzspeicher auf den Wert „1“ gesetzt.
83

6.3. Beispielmodell Kaffeeautomat
Entsprechend setzt dieser den Wert von Leuchte_Geldspeicher auf „0“, wenn der Münzzwischenspeicher
noch weitere Münzen aufnehmen kann.
Abbildung 6-5: Subsystem Zentrale_Steuerung
Die Auswahl eines Getränkes ist in dem Zustandsautomat Auswahl modelliert. Dieser hat
keine weitere Funktionalität als sich das gewählte Getränk zu merken.
Der eigentliche Kauf eines Getränkes erfolgt in Kaffeeausgabe. Dieser Zustandsautomat
überprüft, ob ausreichend viele Münzen für das gewählte Getränk eingeworfen wurden.
Sollte dies der Fall sein, werden entsprechend viele Münzen aus dem Münzzwischenspeicher
abgezogen. Ebenfalls wird ein Becher dem Bechervorrat entnommen, wenn noch
ausreichend viele Becher zur Verfügung stehen. Zusätzlich signalisiert Kaffeeausgabe dem
Subsystem Becher_Füllen, dass ein Becher gefüllt werden soll. Auf diesen Vorgang wartet
die Kaffeeausgabe und erwartet danach wieder neue Eingaben.
Der Zustandsautomat BecherKontrolle überwacht den internen Bechervorrat, von dem bei
Kauf eines Getränks ein Becher verbraucht wird. Sollte die Anzahl der Becher auf Null
sinken, signalisiert dies das Ausgangssignal Leuchte_Becher, welches durch den Zustandsautomaten
BecherKontrolle gesteuert wird.
6.3.2 Verwendete Wahrscheinlichkeitsverteilungen
Zur Testmustergenerierung wurden zwei Wahrscheinlichkeitsverteilungen für jedes Eingangssignal
verwendet. Für die diskreten Eingangssignale Muenzeinwurf, Geldrueckgabe
und Auswahl sind die verwendeten diskreten Wahrscheinlichkeitsverteilungen in den
folgenden Tabellen abgebildet. Die Wahrscheinlichkeitsdichten der kontinuierlichen
Wahrscheinlichkeitsverteilungen für das Eingangssignal Spannung sind in Abbildung 6-6
dargestellt.
84

6. Evaluierung des Testmustergenerators
x i P 1 (X Muenzeinwurf = x i ) P 2 (X Muenzeinwurf = x i )
0 0,5 0,1
1 0,5 0,9
Tabelle 6-4: Wahrscheinlichkeitsverteilungen für Muenzeinwurf
x i P 1 (X Geldrueckgabe = x i ) P 2 (X Geldrueckgabe = x i )
0 0,5 0,9
1 0,5 0,1
Tabelle 6-5: Wahrscheinlichkeitsverteilungen für Geldrueckgabe
x i P 1 (X Auswahl = x i ) P 2 (X Auswahl = x i )
0 0 , 3
0,1
1 0 , 3
0,45
2 0 , 3
0,45
Tabelle 6-6: Wahrscheinlichkeitsverteilungen für Auswahl
Abbildung 6-6: Wahrscheinlichkeitsdichten für Spannung
Die Wahrscheinlichkeitsverteilung P1 ist für alle Eingangssignale die Gleichverteilung und
repräsentiert dadurch die allgemeine zufallsbasierte Testmustergenerierung, welche nicht
durch einen Anwender mithilfe von Wahrscheinlichkeitsverteilungen gesteuert werden
kann. Die Motivation bei der Angabe der Wahrscheinlichkeitsverteilung P2 liegt darin,
selten eintretende Ereignisse wie das Überlaufen des Münzzwischenspeichers und das
Verbrauchen sämtlicher Becher mit einer höheren Wahrscheinlichkeit eintreten zu lassen.
So wurde das Verhältnis zwischen Münzeinwurf und Geldrückgabetaste derart gewählt,
dass häufig Münzen eingeworfen werden, und selten die Geldrückgabetaste betätigt wird.
85

6.3. Beispielmodell Kaffeeautomat
Ebenfalls wurde die Auswahl der Getränke so gewichtet, dass die beiden Getränkesorten
gleichhäufig gewählt werden und nur selten kein Getränk ausgewählt wird. Die Wahrscheinlichkeitsdichte
über dem Wertebereich des Eingangssignals Spannung entspricht
einer Dreiteilung des Wertebereichs. Dadurch wird erreicht, dass während der Testmustergenerierung
gleichhäufig aus dem kritischen Bereich der Überspannung (über 245 Volt),
wie aus den Bereichen der Unterspannung (unter 205 Volt) und der Normalspannung
(zwischen 205 und 245 Volt) generiert werden.
6.3.3 Ergebnisse der Testmustergenerierung
Die Testmustergenerierung mithilfe der Wahrscheinlichkeitsverteilungen P1 und P2
erfolgte jeweils in zwanzig unabhängigen Durchläufen mit dem Testziel, möglichst hohe
Modellabdeckung bezüglich des Abdeckungskriteriums der Modifizierten Mehrfach-
Bedingungsabdeckung zu erreichen. Dabei wurde die initiale Länge der anzuhängenden
Teilsequenz auf fünf Testvektoren festgelegt. In jedem Zyklus der Testmustergenerierung,
in dem keine Abdeckungssteigerung erreicht wurde, wurde diese Länge verdoppelt (vgl.
Kapitel 4.1.4). Als Abbruchkriterium für die Dauer der Generierung wurde die maximale
Anzahl an Testdaten, welche während der Testmustergenerierung pro Eingangssignal
erzeugt werden, auf 100000 festgelegt.
Bei Verwendung der Gleichverteilung P1 wurde in keinem der zwanzig Durchläufe eine
hundertprozentige Abdeckung erreicht. Dies verdeutlicht der Abdeckungsreport aus
Abbildung 6-7. So beträgt die Abdeckung der drei Zustandsautomaten BecherKontrolle,
Geldspeicher und Kassensystem keine hundert Prozent. Ein Grund hierfür liegt darin, dass
es in keinem der erzeugten Testmuster geschafft wurde, den Münzzwischenspeicher auf 60
Münzen zu füllen. Dadurch wurden in den Zustandsautomaten Kassensystem und Geldspeicher
einige Übergangsbedingungen nicht mit den erforderlichen Werten getestet.
Zusätzlich lagen die Zeitpunkte, an denen in den generierten Testmustern eine Becherlieferung
stattfindet, so ungünstig, dass sich der Zustandsautomat BecherKontrolle stets
während der Becherlieferung in ein und demselben Zustand befand. Dadurch wurden an
dieser Stelle zwei Übergangsbedingungen nicht ausreichend abgedeckt.
Die vollständigen Ergebnisse der zwanzigmaligen Testmustergenerierung sind in Tabelle
6-7 dargestellt. In dieser werden pro Zeile die Länge des in dem betroffenen Durchlauf
erzeugten Testmusters (Ergebnislänge) sowie die Anzahl der zur Generierung benötigten
Testdaten (Verbrauch) angegeben.
86

6. Evaluierung des Testmustergenerators
Abbildung 6-7: Abdeckungsreport mit der Gleichverteilung
Zu bemerken ist, dass die angegebenen Werte für den Verbrauch unter Verwendung der
Gleichverteilung P1 in Tabelle 6-7 (dritte Spalte) bereinigt wurden. Dies bedeutet, dass für
jedes der Testmuster 100000 Testvektoren generiert wurden, da dieser Wert als Maximum
für die Anzahl der pro Testmuster zu generierenden Testdaten angegeben wurde. Da ab
einem bestimmten Zeitpunkt der Testdatengenerierung eines jeden Testmusters keine
weitere Abdeckungssteigerung erzielt wurde, sind alle ab diesem Zeitpunkt generierten
Testdaten während der Generierung verworfen worden. Dadurch haben diese nicht zum
eigentlichen Testmuster beigetragen, weshalb sie aus dem in Tabelle 6-7 angegebenen
Verbrauch entfernt wurden.
Die maximal erreichte Abdeckung mit der Wahrscheinlichkeitsverteilung P1 betrug bezüglich
des Kriteriums der Modifizierten Mehrfach-Bedingungsabdeckung 79 Prozent. Dieser
Abdeckungsgrad wurde von achtzehn der zwanzig erzeugten Testmuster erreicht. Die in
den Durchläufen 4 und 12 generierten Testmuster erreichten lediglich eine Abdeckung von
87

6.3. Beispielmodell Kaffeeautomat
73 Prozent. Aus diesem Grund sind die Daten dieser Durchläufe aus der Statistik herausgenommen
worden, um aussagekräftigere Durchschnittswerte bestimmen zu können. Die
achtzehn verbliebenen Durchläufe erzeugten im Durchschnitt mit 25699 generierten Testvektoren
Testmuster mit einer Länge von 12874 Testvektoren.
Der schlechteste Durchlauf (Nr. 10) benötigte 82425 Testvektoren zur Generierung eines
Testmusters der Länge 41240. Dem gegenüber steht mit Durchlauf 17 das beste erzeugte
Testmuster. Es erreicht mit einer Länge von 535 Testvektoren denselben Abdeckungsgrad,
wie die übrigen Testmuster. Zu dessen Erzeugung wurden lediglich 1035 Testdaten pro
Eingangssignal generiert.
P1
P2
Durchlauf Ergebnislänglänge
Verbrauch Ergebnis-
Verbrauch
Nr.
1 20720 41390 555 1050
2 10450 20860 695 1340
3 2835 5625 525 1000
4 / / 850 1620
5 2835 5620 525 985
6 41165 82280 525 990
7 5325 10610 530 995
8 845 1640 420 780
9 10445 20835 525 990
10 41240 82425 855 1645
11 20685 41325 225 400
12 / / 525 990
13 1485 2920 210 375
14 10460 20860 410 775
15 20755 41460 560 1060
16 5400 10755 860 1670
17 535 1035 215 375
18 10460 20865 420 795
19 5395 10740 230 410
20 20700 41345 535 1010
∅ 12874 25699 509 962
Minimum 535 1035 210 375
Maximum 41240 82425 860 1670
Tabelle 6-7: Ergebnisse mit Gleichverteilung
Mit der Wahrscheinlichkeitsverteilung P2 wurden durchschnittlich 962 Testvektoren benötigt,
um Testmuster mit einer Länge von 509 Testvektoren zu erzeugen. Die erzeugten
Testmuster erreichten dabei eine hundertprozentige Abdeckung bezüglich der Modifizierten
Mehrfach-Bedingungsabdeckung. Diese im Vergleich zur Gleichverteilung sehr
geringen Werte zeigen die Stärken des Verfahrens zur Testmustergenerierung mithilfe von
Wahrscheinlichkeitsverteilungen. Sowohl die Anzahl der generierten Testdaten, als auch
die Länge der erzeugten Testmuster wurde um den Faktor 25 verringert.
Ebenfalls wurden mit der Wahrscheinlichkeitsverteilung P2 zweimal nahezu optimale
Testmuster generiert. In den Durchläufen 13 und 17 wurde mit den Ergebnislängen von
88

6. Evaluierung des Testmustergenerators
210 bzw. 215 Testvektoren fast die optimale Länge von 200 Testvektoren erreicht. Der
Optimalwert liegt bei 200 Testvektoren, da zu diesem Zeitpunkt die modellierte Becherlieferung
erfolgt, welche zu einem Zustandsübergang in BecherKontrolle führt. Im
Durchschnitt erzeugt die Testmustergenerierung mithilfe der Wahrscheinlichkeitsverteilung
P2 um den Faktor 2.5 schlechtere Testmuster als manuell im Idealfall angegeben
werden können
6.4 Bewertung
In den vorherigen Unterkapiteln wurden die Ergebnisse der Testmustergenerierung
mithilfe von Wahrscheinlichkeitsverteilungen anhand ausgewählter Beispiele vorgestellt.
Dabei wurden die Vorteile des Verfahrens verdeutlicht, zu denen die effizientere
Testmustererzeugung, die Reduzierung der Testmusterlänge sowie die Steigerung des Testumfangs
zählen. In diesem Unterkapitel wird eine qualitative Bewertung der erreichbaren
Verbesserungen gegenüber dem allgemeinen zufallsbasierten Verfahren geliefert.
Abbildung 6-8: Modifiziertes Beispielmodell Automat_analog
Zu diesem Zweck wurden die Wertebereiche der Übergangsbedingungen in dem bereits
mehrfach verwendeten Beispielmodell Automat_analog variiert (Abbildung 6-8).
Durch die Änderung von A und B konnte z.B. die Wahrscheinlichkeit für den Zustandsübergang
von Zustand S1 zu Zustand S2 modifiziert werden. Ziel dabei war es, das
Verbesserungspotenzial bei unterschiedlichen Wahrscheinlichkeiten eines Zustandsübergangs
zu erfassen. Zu diesem Zweck wurden acht Übergangswahrscheinlichkeiten gewählt
und hierfür das allgemeine Verfahren der zufallsbasierten gleichverteilten Testmustergenerierung
jeweils 50-mal angewendet, wobei in jedem Durchlauf hundert Prozent Mehrfachbedingungsabdeckung
erreicht werden mussten. Die durchschnittlichen Längen der
generierten Testmuster sowie die Anzahl der zur Generierung benötigten Testvektoren sind
in Tabelle 6-8 unter Angabe der Übergangswahrscheinlichkeit aufgeführt. Ebenfalls
wurden die gewählten Werte der Variablen A und B aufgeführt.
89

6.4. Bewertung
Nr. A B
Übergangswahrschein
lichkeit
S1=>S2
Testmusterlänge
Verbrauch
1 6,5 7,5 0,11111 24,50 44,1
2 6,625 7,375 0,08333 36,68 68,86
3 6,75 7,25 0.05555 46,20 88,04
4 6,875 7,125 0,02777 86,68 158,92
5 6,9375 7,0625 0,01388 109,92 215,76
6 6,96875 7,03125 0,00694 285,24 566,22
7 6,984375 7,01563 0,00347 473,96 943,9
8 6,992188 7,00781 0,00173 1264,96 2525,9
Tabelle 6-8: Abhängigkeit der Testmusterlänge von den Übergangsbedingungen
Mit der ersten Wahl der Variablen A und B entspricht das modifizierte Beispielmodell
exakt dem bereits bekannten Modell Automat_analog aus Kapitel 6.2. Die Übergangswahrscheinlichkeit
des betrachteten Zustandsübergangs liegt bei ca. 11,1 Prozent.
Die durchschnittliche Länge der generierten Testmuster liegt bei 24,5 Testvektoren. Zur
Erzeugung dieser Testmuster wurden durchschnittlich 44,1 Testvektoren generiert. Wie die
Tabelle zeigt, steigt die Testmusterlänge mit fallender Übergangswahrscheinlichkeit. Bei
einer Übergangswahrscheinlichkeit von 0,173 Prozent werden bereits 2525,9 Testvektoren
zur Generierung von Testmustern der Länge 1264,96 benötigt.
Wie bereits in Kapitel 6.2 gezeigt wurde, können für dieses Beispielmodell die Werte von
Testmusterlänge und Verbrauch durch den Einsatz der Testmustergenerierung mithilfe von
Wahrscheinlichkeitsverteilungen reduziert werden. Das erfordert für jedes gewählte Paar
(A, B) die Angabe einer passenden Wahrscheinlichkeitsverteilung, welche die drei Intervalle
[1, A), [A, B] und (B, 10] bei der Testdatengenerierung jeweils mit einem Drittel
Wahrscheinlichkeit versieht. Die Ergebnisse der gesteuerten Testmustergenerierung sind
daher für alle Übergangswahrscheinlichkeiten im Durchschnitt identisch, wenn eine
entsprechende Wahrscheinlichkeitsverteilung zur Testdatenerzeugung gewählt wurde. Die
in Abschnitt 6.2 ermittelten Ergebnisse ergeben im Durchschnitt eine Testmusterlänge von
11,75 und einen Verbrauch von 18,95 Testvektoren. Folgende Abbildung zeigt das Verbesserungspotenzial,
welches die gesteuerte gegenüber der zufallsbasierten gleichverteilten
Testmustergenerierung bietet.
90

6. Evaluierung des Testmustergenerators
Abbildung 6-9: Verbesserungspotenzial des gesteuerten Verfahrens
Das Verbesserungspotenzial nimmt zu, wenn die Übergangswahrscheinlichkeit einzelner
Transitionen abnimmt. Hier ist das Verfahren lediglich um den Faktor 2 besser, wenn die
Wahrscheinlichkeit des Zustandsübergangs von S1 nach S2 bei 11,1 Prozent liegt. Verringert
man diese Wahrscheinlichkeit, so erhöhen sich im Durchschnitt der Verbrauch und die
Testmusterlänge. Bei einer Übergangswahrscheinlichkeit von 0,173 Prozent ergibt die
Verbesserung bei Einsatz der zuvor erläuterten Wahrscheinlichkeitsverteilung Faktor 100
gegenüber der Generierung auf Basis einer Gleichverteilung.
Die vorgestellten Ergebnisse zeigen, dass ein großes Verbesserungspotenzial im Einsatz
des Verfahrens zur Testmustergenerierung mithilfe von Wahrscheinlichkeitsverteilungen
liegt. Insbesondere bei sehr unwahrscheinlichen Zustandsübergängen kann es zu deutlichen
Verbesserungen sowohl bei der Testdatengenerierung (durch den reduzierten Verbrauch)
als auch bei der späteren Testdurchführung (durch die reduzierte Testmusterlänge) führen.
91

7 Zusammenfassung und Ausblick
7.1 Zusammenfassung
Im Rahmen dieser Arbeit wurde das allgemeine zufallsbasierte Verfahren zur Testmustergenerierung
um eine Komponente erweitert, welche einem Anwender die Möglichkeit zur
Steuerung des Verfahrens bietet. Auf diese Weise kann der Testentwickler sein Wissen
über das System und dessen Einsatzmöglichkeiten in den Erzeugungsprozess der Testdaten
einfließen lassen.
Als Mittel zur Steuerung wurden Wahrscheinlichkeitsverteilungen gewählt, welche durch
den Anwender des Verfahrens über den Wertebereichen der Eingangssignale definiert
werden. Auf diese Weise modelliert der Testentwickler Schwerpunkte, wodurch bei der
Generierung im Fall von diskreten Eingangssignalen Einzelwerte und im Falle analoger
Signale Wertebereiche bevorzugt werden. Damit steuert der Testentwickler den Prozess
der Testdatengenerierung dahingehend, dass Testdaten mit einer höheren Wahrscheinlichkeit
häufiger als andere zur Erzeugung neuer Testmuster verwendet werden.
Das Verfahren wurde in dem Testmustergenerator TestCaseCommander implementiert.
Zur Evaluierung des Verfahrens wurden einfache Beispielsysteme (Abschnitte 6.1 und 6.2)
und das Modell Kaffeeautomat (Abschnitt 6.3) verwendet. Am Beispiel des Kaffeeautomaten
wurde gezeigt, dass die Testmustergenerierung zielgerichtet in Problembereiche
gelenkt werden kann, für die durch gleichverteilte Testmustergenerierung nur mit sehr
großem Aufwand Testdaten erzeugt werden können. Durch die erreichte Steigerung der
Abdeckung konnte an diesem Beispiel der Testumfang erhöht werden, womit in einer
späteren Testdurchführung mehr Systemfunktionalitäten getestet werden würden. Das
Einbeziehen von Wahrscheinlichkeitsverteilungen steigert somit die Qualität des gesamten
Testprozesses, indem die Wahrscheinlichkeit des Auffindens von Fehlern erhöht wird.
Weiterhin kann der Aufwand zur Erzeugung von Testmustern durch benutzerdefinierte
Wahrscheinlichkeitsverteilungen deutlich gegenüber einer gleichverteilten Generierung
verringert werden. Diese Effizienzsteigerung der Testdatengenerierung führt zu einer Zeitersparnis
auf Seiten des Testentwicklers, wodurch die Kosten der Testerzeugung verringert
werden. Dieser Vorteil führt dazu, dass schneller auf Änderungen am System reagiert werden
kann, indem in kürzester Zeit neue Testmuster erzeugt werden können.
Ein weiterer Vorteil liegt in der Länge der erzeugten Testmuster. Die ermittelten Ergebnisse
zeigen, dass die Testmusterlänge bei gleicher Modellabdeckung stark reduziert
werden kann. Durch kurze Testmuster, welche eine hohe Abdeckung erreichen, kann der
Aufwand der Testdurchführung verbessert werden. Dies führt dazu, dass der Kostenfaktor
Zeit reduziert werden kann, wodurch das entwickelte Produkt schneller seine Marktreife
erreicht. Zusätzlich vereinfachen kürzere Tests die Testdurchführung und die daran
93

7.2. Ausblick
anschließende Auswertung der Testergebnisse. Sollten hierbei Fehler gefunden werden,
können diese bei kürzeren Testmustern leichter nachvollzogen werden als bei komplexen
Testmustern.
Abschließend wurde gezeigt, dass das Verbesserungspotential der Methodik zunimmt, je
unwahrscheinlicher einzelne Zustandsübergänge innerhalb des Modells sind.
7.2 Ausblick
Zur Evaluierung des Verfahrens wurde ein Kaffeeautomat als komplexeres Beispielsystem
herangezogen. Das verwendete Modell ist jedoch im Vergleich zu realen Modellen wie
beispielsweise Steuergeräten in der Automobilindustrie nur von geringer Größe. In
weiterführenden Arbeiten ist deswegen zu zeigen, in wiefern das Verfahren auf komplexere
Modelle mit mehreren tausend Zuständen angewendet werden kann. An dieser Stelle
ist insbesondere zu untersuchen, ob ein Anwender des Verfahrens bei derartigen Systemen
in der Lage ist, für sämtliche Eingangssignale des Systems Wahrscheinlichkeitsverteilungen
anzugeben, welche zu deutlich besseren Ergebnissen als bei Verwendung einer
Gleichverteilung führen. Zusätzlich ist eine Analyse vorzunehmen, welche den Aufwand
der vollständig manuellen Testfallerstellung abschätzt und mit dem Aufwand vergleicht,
welcher zur Angabe sämtlicher Wahrscheinlichkeitsverteilungen für die Eingangssignale
komplexer Systeme aufgebracht werden muss.
Ein weiterer zukünftiger Arbeitsschritt liegt in der Untersuchung einer Verfahrenserweiterung.
Deren zugrunde liegende Idee sieht vor, zur Generierung von Testdaten zwischen
verschiedenen Wahrscheinlichkeitsverteilungen zu wechseln. Der Grundgedanke dieser
Erweiterung liegt darin, eine Beobachterkomponente in das bei der Testmustergenerierung
verwendete Modell zu integrieren, welche dem automatischen Testmustergenerator Informationen
über den aktuellen Systemzustand zur Verfügung stellt. Aufgrund dieser erfolgt
ein Wechsel zwischen den Wahrscheinlichkeitsverteilungen. Dies bedeutet, dass der
Anwender des Verfahrens nicht nur eine Wahrscheinlichkeitsverteilung pro Eingangssignal
sondern mehrere angibt, welche abwechselnd zur Erzeugung neuer Testdaten verwendet
werden.
In weiterführenden Arbeiten sollte abschließend eine Analyse darüber erfolgen, welche
Abdeckungskriterien für die modellbasierte Testerstellung mit der vorgestellten Methodik
geeignet sind. Während der Evaluierung erfolgte lediglich eine Anwendung der in
MATLAB verfügbaren Abdeckungsmaße. Eine Untersuchung sollte zeigen, ob die Testmustergenerierung
mithilfe des vorgestellten Verfahrens vollständig unabhängig von den
gewählten Abdeckungskriterien ist, wie es in Kapitel 4 angenommen wurde. Es wäre denkbar,
dass sich bei einzelnen Abdeckungsmaßen herausstellt, dass sich das iterative
Aufbauen der Testmuster als ineffizient herausstellt, da der Anteil der verworfenen Testdaten
zu hoch ist. Ein weiterer Aspekt dieser Untersuchung ist die Ausweitung der
Abdeckungsmaße auf benutzerdefinierte Abdeckungskriterien, wie sie in dem analytischen
Ansatz zur Testmustergenerierung aus Kapitel 3.4.4 angesprochen wurden.
94

8 Literaturverzeichnis
ArmOchSno04
Ove Armbrust, Michael Ochs, Björn Snoek: Stand der Forschung von
Software-Tests und deren Automatisierung, Fraunhofer Institut
Experimentelles Software Engineering, IESE-Report Nr. 068.04/D
Version 1.0, 2004
AutomationDesk dSPACE GmbH: AutomationDesk – The Next Generation of Testing,
http://www.dspace.de/ww/en/pub/products/sw/expsoft/automdesk.htm
(zuletzt besucht: 24.05.2005)
Bal98
Bar00
Bar97
BroNot03
BröDrö93
Cha04
ChiMil94
Con04
Helmut Balzert: Lehrbuch der Software-Technik: Software-Management,
Software-Qualitätssicherung, Unternehmensmodellierung,
Spektrum, Akademischer Verlag, Heidelberg, Berlin, Deutschland,
1998
André Baresel: Automatisierung von Strukturtests mit evolutionären
Algorithmen, Diplomarbeit, Humboldt Universität, Berlin, Deutschland,
2000
Stéphane Barbey: Test Selection for Specification-Based Unit Testing of
Object-Oriented Software based on Formal Specifications, Dissertation
an der École Polytechnique Fédérale de Lausanne, Schweiz, 1997
Bart Broekman, Edwin Notenboom: Testing Embedded Software,
Addison-Wesley, 2003
Adolf-Peter Bröhl, Wolfgang Dröschel: Das V-Modell: Der Standard
für die Softwareentwicklung mit Praxisleitfaden, Oldenbourg Verlag,
1993
Ahmad Chamma: Testfallgenerierung für auf StateCharts basierende
Systeme, Diplomarbeit an der Universität Hannover, 2004
John Joseph Chilenski, Steven P. Miller: Applicability of modified
condition / decision coverage to software testing, Software Engineering
Journal, September 1994, pp. 193 – 200
Mirko Conrad: Auswahl und Beschreibung von Testszenarien für den
Modell-basierten Test eingebetteter Software im Automobil,
Dissertation, Technische Universität Berlin, Deutschland, 2004
95

Literaturverzeichnis
ConSad02
dSPACE
Föl94
Gol02
Hart01
HarPol98
Här87
Her05
Mirko Conrad, Sadegh Sadeghipour: Einsatz von Überdeckungskriterien
auf Modellebene – Erfahrungsbericht und experimentelle
Ergebnisse, Softwaretechnik-Trends 22(2), 2002
dSPACE GmbH, Technologiepark 25, 33100 Paderborn, Deutschland:
dSPACE - Solutions for Control, http://www.dspace.de (zuletzt besucht:
24.05.2005)
Otto Föllinger: Regelungstechnik: Einführung in die Methoden und ihre
Anwendung – 8., überarbeitete Auflage, Hüthig, Heidelberg, 1994
Ursula Goltz, Dennis Maciuszek, Werner Struckmann: Vorlesungsskript
Reaktive Systeme, Institut für Software, Technische Universität
Braunschweig, 2002, http://www.cs.tu-bs.de/ips/struck/report/
skript_rs.ps.gz (zuletzt besucht: 24.05.2005)
Nico Hartmann: Automation des Tests eingebetteter Systeme am
Beispiel der Kraftfahrzeugelektronik, Dissertation an der Universität
Karlsruhe, 2001
David Harel, Michal Politi: Modeling reactive systems with Statecharts:
the statemate approach, McGraw-Hill, 1998
Erich Härtter: Wahrscheinlichkeitsrechnung, Statistik und mathematische
Grundlagen: Begriffe, Definitionen U. Formeln, Vandenhoeck &
Ruprecht, 1987
Dr. Thomas Hermes: Der modellbasierte Testfallgenerator der IAV
(Model-Based Test Case Extractor), Vortrag der IAV GmbH bei
dSPACE, Paderborn, 2005
IAV Ingenieurgesellschaft Auto und Verkehr, Nordhoffstraße 5, 38518
Gifhorn, Deutschland: http://www.iav.de (zuletzt besucht: 06.04.2005)
IAV04
KBSt
Lam04
IAV GmbH: MOTCase-X im Entwicklungsprozess; MOTCase-X:
Effektives Testen mit System in der modellbasierten Softwareentwicklung,
Produktinformation, 2004
Koordinierungs- und Beratungsstelle der Bundesregierung für
Informationstechnik in der Bundesverwaltung:
http://www.kbst.bund.de/-,279/V-Modell.htm (zuletzt besucht:
06.04.2005)
Klaus Lamberg, Michael Beine, Mario Eschmann, Rainer Otterbach,
Mirko Conrad, Ines Fey: Model-based testing of embedded automotive
software using MTest, SAE 2004 World Congress & Exhibition, March
2004, Detroit, MI, USA
96

8. Literaturverzeichnis
Lig02
Peter Liggesmeyer: Software-Qualität, Testen Analysieren und
Verifizieren von Software, Spektrum Akademischer Verlag, Heidelberg-
Berlin, 2002
Mathworks The Mathworks, Inc., 3 Apple Hill Drive, Natick, MA 01760-2098,
USA, http://www.mathworks.com (zuletzt besucht: 24.05.2005)
MATLAB
Mol02
MTest
Mye89
Pre03
Razorcat
Rea04
Reactis
Reactive
Systems
Roo99
Rot66
Schl et al. 04
The Mathworks: MATLAB® 7.0.4 http://www.mathworks.com/
products/matlab/ (zuletzt besucht: 24.05.2005)
Prof. Dr. Paul Molitor: Vorlesungsskript „Synthese, Testen und
Verifikation Digitaler Schaltungen“, http://nirvana.informatik.unihalle.de/~molitor/CDROM1999/skripte/teubner99/
(zuletzt besucht:
24.05.2005)
dSPACE GmbH: MTest – Systematic Model-Based Testing,
http://www.dspace.de/ww/en/pub/products/sw/expsoft/mtest.htm
(zuletzt besucht: 24.05.2005)
Glenford J. Myers: Methodisches testen von Programmen (3. Auflage),
Oldenbourg Verlag, 1989
Alexander Pretschner: Zum modellbasierten funktionalen Test reaktiver
Systeme, Dissertation an der Technischen Universität München, 2003
Razorcat Development GmbH, Witzlebenplatz 5, 14057 Berlin,
Deutschland: http://www.razorcat.com (zuletzt besucht: 24.05.2005)
Reactive Systems: Reactis User’s Guide V2004.2, http://www.reactivesystems.com/reactis/doc/user/index.html
(zuletzt besucht: 06.04.2005)
Reactive Systems: The Reactis Product Line, http://www.reactivesystems.com/products.msp
(zuletzt besucht: 24.05.2005)
Reactive Systems, Inc., 120-B East Broad St., Falls Church, VA 22046,
USA: http://www.reactive-systems.com (zuletzt besucht: 24.05.2005)
Hans-Görg Roos: Numerische Mathematik: das Grundwissen für
jedermann, Teubner, Stuttgart, 1999
J. Paul Roth: Diagnosis of Automata Failures: A Calculus and a
Method, IBM Journal, 1966
H. Schlingloff, C. Sühl, H. Dörr, M. Conrad, J. Stroop, S. Sadeghipour,
M. Kühl, F. Rammig, G. Engels: IMMOS – Eine integrierte Methodik
zur modellbasierten Steuergeräteentwicklung, BMBF-Workshop
“Software Engineering 2006”, Berlin, 2004
97

Literaturverzeichnis
Schö94
SimModCov
Simulink
Stateflow
Sth et al. 01
TargetLink
Tha00
VieMis04
VM97
UML
Weg93
Weg02
Eberhard Schöneburg: Genetische Algorithmen und Evolutionsstrategien:
Eine Einführung in Theorie und Praxis der simulierten
Evolution, Addison-Wesley, 1994
The Mathworks: Model Coverage Tool, http://www.mathworks.com/
access/helpdesk_r13/help/toolbox/simulink/ug/performance_tools13
.html#7314 (zuletzt besucht: 24.05.2005)
The Mathworks: Simulink® 6.2, http://www.mathworks.com/products/
simulink/ (zuletzt besucht: 06.04.2005)
The Mathworks: Simulink® 6.2, http://www.mathworks.com/products/
stateflow/ (zuletzt besucht: 24.05.2005)
Harmen Sthamer, André Baresel, Joachim Wegener: Evolutionary
Testing of Embedded Systems, Proceedings of the 14th International
Software Quality Week (QW '01), San Francisco, USA, 2001.
dSPACE GmbH: TargetLink – Automatisch erzeugter Seriencode für
die Implementierung, http://www.dspace.de/ww/de/pub/systems/
targetimp.htm (zuletzt besucht: 24.05.2005)
Georg Erwin Thaller: Software-Test: Verifikation und Validation,
Heise, 2000
Prof. Dr. Heinrich Theodor Vierhaus, Silvio Misera: Vorlesung „Test
und testfreundlicher Entwurf“, http://www.informatik.tucottbus.de/~wwwteci/student/vl/test/
(zuletzt besucht: 06.04.2005)
IABG: Allgemeiner Umdruck Nr. 250: Vorgehensmodell, http://www.vmodell.iabg.de/vm97.htm
(zuletzt besucht: 24.05.2005)
Object Management Group, Inc.: OMG Unified Modelling Language
Specification (Version 1.5, March 2003), http://www.omg.org/docs/
formal/03-03-01.pdf (zuletzt besucht: 24.05.2005)
Joachim Wegener, Matthias Grochtmann: Werkzeugunterstützte Testfallermittlung
für den funktionalen Test mit dem Klassifikationsbaum-
Editor CTE, Proceedings der GI-Fachtagung Softwaretechnik '93,
Dortmund, Germany, November 1993, pp. 95 - 102
Joachim Wegener, Kerstin Buhr, Hartmut Pohlheim: Automatic Test
Data Generation for Structural Testing of Embedded Software Systems
by Evolutionary Testing, Proceedings of the Genetic and Evolutionary
Computation Conference, GECCO 2002, New York, USA, 2002
98

Anhang
A Grundlagen der Wahrscheinlichkeitsrechnung
In diesem Abschnitt werden die für diese Arbeit benötigten Grundlagen der Wahrscheinlichkeitsrechnung
vorgestellt. Die Begriffsdefinitionen wurden nach den Definitionen von
Härtter [Här87] erstellt.
Zufallsvariable. Als Zufallsgröße oder Zufallsvariable wird eine mathematische Variable
bezeichnet, die abhängig vom Ergebnis einer Funktion oder Prozedur unterschiedliche,
zufällig erzeugte Werte annehmen kann. Die gewürfelte Augenzahl beim Würfeln ist eine
Zufallsvariable mit den möglichen Werten 1, 2, 3, 4, 5 und 6. Es wird zwischen diskreten
und kontinuierlichen Zufallsvariablen unterschieden. Kann die Zufallsvariable nur eine
abzählbare Menge möglicher Werte annehmen, wie es beim Würfeln der Fall ist, wird die
Zufallsvariable als diskret bezeichnet. Eine Zufallsvariable mit überabzählbarem Wertebereich
wird kontinuierlich (oder stetig) genannt.
Wahrscheinlichkeitsverteilung, -funktion. Die Wahrscheinlichkeitsverteilung einer diskreten
Zufallsvariablen X ist durch ihre Wahrscheinlichkeitsfunktion p(x) = P(X = x)
charakterisiert. Diese Funktion gibt für jeden möglichen Wert der Zufallsvariablen die
Wahrscheinlichkeit seines Auftretens an. Bei kontinuierlichen Zufallsvariablen ist eine
Zuordnung von Wahrscheinlichkeiten zu den einzelnen erreichbaren Werten problematisch.
Da in Intervallen reeller Zahlen unendlich viele Werte liegen, ist die Wahrscheinlichkeit,
dass die Zufallsvariable einen bestimmten Wert annimmt, Null. Um eine
kontinuierliche Wahrscheinlichkeitsverteilung anzugeben, wird nicht die Wahrscheinlichkeit,
dass X einen bestimmten Wert annimmt, betrachtet. Vielmehr betrachtet man die
Wahrscheinlichkeit, dass X Werte eines Intervalls annimmt. Hierzu wird die
Verteilungsfunktion benötigt.
Verteilungsfunktion. Die Verteilungsfunktion F(x) gibt für eine Zufallsgröße X und einen
Wert x die Wahrscheinlichkeit an, mit der X Werte kleiner als x oder genau den Wert x
annimmt. Verteilungsfunktionen können sowohl für diskrete als auch für kontinuierliche
Zufallsvariablen angegeben werden. Im Fall einer diskreten Zufallsvariable ist die Verteilungsfunktion
eine Treppenfunktion, die an jeder Stelle x i eine Sprunghöhe p i = P(X = x i )
hat, mit der die Wahrscheinlichkeit angegeben wird, mit der X den Wert x i annimmt. Im
Fall einer kontinuierlichen Zufallsvariable ist die Verteilungsfunktion wie folgt definiert:
x
F( x)
= P(
X ≤ x)
= ∫ f ( x)
dx,
mit f ( x)
= F'(
x)
.
−∞
Wahrscheinlichkeitsdichte. Die Berechnung der Verteilungsfunktion setzt das Vorhandensein
der Dichte der Zufallsvariablen voraus. Die Ableitung f(x) = F’(x) der Verteilungsfunktion
F(x) wird als Wahrscheinlichkeitsdichte, Dichte der Zufallsvariablen, Dichte der
99

Anhang
Verteilung oder kurz als Dichte bezeichnet. Die Dichte f(x) ermöglicht die Berechnung der
Wahrscheinlichkeit, dass eine Zufallsvariable Werte aus einem bestimmten Intervall
annimmt, mit der folgenden Formel:
P ( a ≤ X ≤ b)
= f ( x)
dx . Die Wahrscheinlichkeit,
dass X Werte aus einem Intervall annimmt, ist somit definiert als die Fläche unter dem
Graphen der Wahrscheinlichkeitsdichte in dem gewählten Intervall.
Erwartungswert. Der Erwartungswert einer diskreten Zufallsvariablen X ist der Wert
n
E ( X ) = ∑
i=
1
x p i i
, wobei n die Anzahl der möglichen Werte ist, welche X annehmen kann,
xi der i-te mögliche Wert und p i die Wahrscheinlichkeit von x i . E(X) ist somit der mit der
mit ihren Wahrscheinlichkeiten gewichtete Durchschnitt der Werte, die X annehmen kann.
Für eine kontinuierliche Zufallsvariable errechnet sich der Erwartungswert wie folgt:
+∞
∫
−∞
E(
X ) = x ⋅ f ( x)
dx , wobei f(x) die Wahrscheinlichkeitsdichte der Zufallsvariablen X ist.
b
∫
a
100