Methodisches und automatisiertes Testen

von Kfz-Steuergerate-Software

Von der Fakultat Konstruktions-, Produktions- und Fahrzeugtechnik

der Universitat Stuttgart

zur Erlangung der Wurde eines Doktor-Ingenieurs (Dr.-Ing.)

genehmigte Abhandlung

vorgelegt von

Carsten Paulus

aus Stuttgart/Bad Cannstatt

Hauptberichter: Prof. Dr.-Ing. Hans-Christian Reuss

Mitberichter: Prof. Dr. Dr. h.c. Manfred Broy

Tag der mundlichen Prufung: 14.10.2011

Institut fur Verbrennungsmotoren und Kraftfahrwesen

Universitat Stuttgart

2011

Vorwort

Die vorliegende Arbeit entstand wahrend meiner Tatigkeit als wissenschaft-

licher Mitarbeiter am Forschungsinstitut fur Kraftfahrwesen und Fahrzeug-

motoren Stuttgart in Zusammenarbeit mit der ZF Friedrichshafen AG.

Mein besonderer Dank gilt Herrn Prof. Dr.-Ing. Hans-Christian Reuss fur

die Betreuung der Arbeit. Bei Herrn Prof. Dr. Dr. h.c. Manfred Broy moch-

te ich mich fur die freundliche Ubernahme des Mitberichts bedanken.

Dank gebuhrt an dieser Stelle auch Herrn Peter Feulner, Herrn Michael

Wolff und Herrn Udo Gillich, welche das der Arbeit zugrundeliegende Pro-

jekt seitens der ZF Friedrichshafen AG erst moglich gemacht haben. Ferner

mochte ich mich bei Herrn Dr.-Ing. Gerd Baumann bedanken, welcher mei-

ne Arbeit seitens des FKFS unterstutzt und gefordert hat.

Ein weiterer Dank gilt meinen Kollegen am FKFS und bei der ZF Fried-

richshafen AG, welche mich im Laufe der Arbeit immer wieder motiviert

und auf neue Gedanken gebracht haben.

Danken mochte ich auch meinen Diplomanden und Praktikanten Tobias

Bollmann, Ricard Lou, Ping Zheng und Nico Gau.

Ferner mochte ich meinen Korrekturlesern danken, insbesondere Frau Ste-

fanie Korte.

Zu guter Letzt mochte ich meiner Familie danken, meinen Eltern Edith

und Gerd Paulus, die mich immer begleiten. Ein herzlicher Dank gebuhrt

meiner Frau Jana fur die Unterstutzung und das Verstandnis, welches sie

mir wahrend dieser Arbeit entgegengebracht hat.

Friedrichshafen, Oktober 2011 Carsten Paulus

3

Inhaltsverzeichnis

Abkurzungsverzeichnis 8

Kurzfassung 11

Abstract 12

1. Einleitung 13

1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.2. Methoden und Werkzeuge zum Testen . . . . . . . . . . . . 14

1.3. Beitrag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.3.1. Beitrag durch das Framework . . . . . . . . . . . . . 18

1.3.2. Beitrag durch die methodische Testsequenzerstellung 19

1.3.3. Beitrag durch die formale Testbeschreibung . . . . . 20

1.3.4. Beitrag durch die Adaption an die Plattformen . . . 20

1.3.5. Erwarteter Nutzen . . . . . . . . . . . . . . . . . . . 21

1.4. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . 21

2. Prozesse, Methoden und Werkzeuge 22

2.1. Aufgaben und Aufbau der Software . . . . . . . . . . . . . . 22

2.2. Softwareentwicklungs- und Testprozess . . . . . . . . . . . . 23

2.3. Entwicklungsparadigmen . . . . . . . . . . . . . . . . . . . . 27

2.3.1. Steuerungs- und regelungstechnische Aspekte . . . . 27

2.3.2. Kommunikation . . . . . . . . . . . . . . . . . . . . . 28

2.3.3. Berucksichtigung der Hardware . . . . . . . . . . . . 28

2.3.4. Programmierung . . . . . . . . . . . . . . . . . . . . 29

2.4. Modelle in der Softwareentwicklung . . . . . . . . . . . . . . 30

2.4.1. Unified Modeling Language . . . . . . . . . . . . . . 31

2.4.1.1. Klassendiagramm . . . . . . . . . . . . . . . 31

2.4.1.2. Zustandsdiagramm . . . . . . . . . . . . . . 32

2.4.2. Extensible Markup Language . . . . . . . . . . . . . 33

2.4.3. Generative Programmierung . . . . . . . . . . . . . . 34

2.4.3.1. Model Driven Architecture . . . . . . . . . 34

4

2.4.3.2. Model Driven Software Development . . . . 35

2.4.3.3. Nutzen der Vorgehensweise . . . . . . . . . 37

2.4.4. Relevanz fur den Test . . . . . . . . . . . . . . . . . 38

2.5. Potenzielle Softwarefehler . . . . . . . . . . . . . . . . . . . 39

2.6. Testentwurfsmethoden . . . . . . . . . . . . . . . . . . . . . 40

2.6.1. Statische Testentwurfsmethoden . . . . . . . . . . . . 41

2.6.2. Dynamische Testentwurfsmethoden . . . . . . . . . . 42

2.6.3. White-box Testentwurfsmethoden . . . . . . . . . . . 43

2.6.3.1. Kontrollflussbezogene Kriterien . . . . . . . 43

2.6.3.2. Datenflussbezogene Kriterien . . . . . . . . 46

2.6.3.3. Bewertung . . . . . . . . . . . . . . . . . . 46

2.6.4. Black-box Testentwurfsmethoden . . . . . . . . . . . 48

2.6.4.1. Aquivalenzklassenbildung . . . . . . . . . . 49

2.6.4.2. Auswahlstrategien . . . . . . . . . . . . . . 50

2.6.4.3. Zustandsbasierter Test . . . . . . . . . . . . 58

2.6.4.4. Erfahrungsbasiertes Testen . . . . . . . . . 58

2.7. Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . 58

3. Testframework 61

3.1. Artefakte aus dem Entwicklungsprozess . . . . . . . . . . . . 61

3.1.1. Strukturartefakte . . . . . . . . . . . . . . . . . . . . 61

3.1.2. Verhalten . . . . . . . . . . . . . . . . . . . . . . . . 62

3.1.3. Daten . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.2. Technologische Realisierung . . . . . . . . . . . . . . . . . . 63

3.2.1. Das Testspezifikations-Meta-Modell . . . . . . . . . . 65

3.2.2. Das Testbericht Meta-Modell . . . . . . . . . . . . . 68

3.2.3. Codegenerierung . . . . . . . . . . . . . . . . . . . . 70

3.2.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . 71

4. Leitanwendung 73

4.1. Physikalische Grundlagen . . . . . . . . . . . . . . . . . . . 73

4.2. Software-Design und Implementierung . . . . . . . . . . . . 76

4.2.1. Klassendiagramm . . . . . . . . . . . . . . . . . . . . 76

4.2.2. Zustandsdiagramm . . . . . . . . . . . . . . . . . . . 78

4.3. Testausfuhrungsplattform . . . . . . . . . . . . . . . . . . . 79

4.4. Aufgaben fur die Testimplementierung . . . . . . . . . . . . 80

5

5. Heuristik zur modellbasierten Testsequenzgenerierung 81

5.1. Prinzip der Testsequenzgenerierung aus Zustandsmaschinen . 82

5.1.1. Generierungsstrategien . . . . . . . . . . . . . . . . . 83

5.1.2. Auffindbare Fehler . . . . . . . . . . . . . . . . . . . 83

5.1.3. Auswahl einer Strategie zur Testsequenzgenerierung . 84

5.1.4. Umgang mit erweiterten endlichen Zustandsmaschinen 85

5.1.4.1. Auflosen von Hierarchie . . . . . . . . . . . 86

5.1.4.2. Auflosen von Orthogonalitat . . . . . . . . . 86

5.2. Integration in das Framework . . . . . . . . . . . . . . . . . 88

5.2.1. Allgemeine Schnittstelle der Heuristik . . . . . . . . . 88

5.2.2. Verfugbare Artefakte der Leitanwendung . . . . . . . 92

5.2.3. Konzeption des Exchange-Meta-Modells . . . . . . . 93

5.2.4. Instanziierung der Leitanwendung . . . . . . . . . . . 94

5.3. Heuristik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.3.1. Bedatung . . . . . . . . . . . . . . . . . . . . . . . . 97

5.3.2. Berechnung der Initialisierungs-Testsequenz . . . . . 100

5.3.3. Berechnung der Transitionsuberdeckung . . . . . . . 102

5.3.4. Vervollstandigung der Transitionsfolgen . . . . . . . . 105

5.3.4.1. Umgang mit Superzustanden . . . . . . . . 106

5.3.4.2. Umgang mit orthogonalen Zustanden . . . . 109

5.3.5. Zusammenfassung der strukturellen Aspekte . . . . . 114

5.3.6. Synthese von Bedatung und Struktur . . . . . . . . . 114

5.4. Uberfuhren der Testspezifikation in ausfuhrbaren Code . . . 119

5.5. Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

6. Einsatz des Testframeworks 124

6.1. Methoden und deren Einbindung . . . . . . . . . . . . . . . 125

6.2. Formale Testspezifikation und Transformation . . . . . . . . 128

6.3. Nutzen und Potenziale . . . . . . . . . . . . . . . . . . . . . 130

7. Zusammenfassung und Ausblick 131

A. Algorithmen zur Testsequenzinitialisierung 134

A.1. Dijkstra-Algorithmus . . . . . . . . . . . . . . . . . . . . . . 136

B. Entwicklung des Algorithmus zur Transitionsuberdeckung138

6

Abbildungsverzeichnis 141

Tabellenverzeichnis 142

Literaturverzeichnis 144

7

Abkurzungsverzeichnis

Abkurzungen

ATML Automatic Test Markup Language

CASE Computer-Aided Software Engineering

COM Component Object Model

DSL Domain Specific Language

EGS Elektronische Getriebesteuerung

EMF Eclipse Modeling Framework

FUT Function Under Test

HIL Hardware-In-The-Loop

IDE Integrated Development Environment

MDA Model Driven Architecture

MDSD Model Driven Software Development

MIL Model-In-The-Loop

MISRA The Motor Industry Software Reliablity Association

MM Meta-Modell

MOF Meta Object Facility

oAW open Architecture Ware

OMG Object Management Group

RCP Rapid Control Prototyping

SIL Software-In-The-Loop

SMUT State-Machine Under Test

SUT System Under Test

TS-MM Testspezifikations-Meta-Modell

UML Unified Modeling Language

8

UML Unified Modeling Language

XML Extensible Markup Language

Formelzeichen

F Menge der Faktoren Fi, welche den Eingangsgroßen des

SUT entsprechen

Li Menge der Level l, welche einem Faktor Fi zugeordnet

sind

O Auswahlmatrix

EM Testmodell EM = 〈SM,S, T,R,W 〉SM Wurzelelement der Zustandsmaschine

S Menge der Zustande s der Zustandsmaschine

T Menge der Transitionen t der Zustandsmaschine

R Menge der Regionen r der Zustandsmaschine

W Menge der WerteBereich-Elemente w des Testmodells

E Menge von Ereignissen e. Die Ereignisse ES sind einem

Zustand zugeordnet, die Ereignisse ET einer Transition

G Menge von Guard-Bedingungen g. Die Guard-Bedin-

gungen GS sind einem Zustand zugeordnet, die Guard-

Bedingungen GT einer Transition

A Menge von Aktionen a. Die Aktionen AS sind einem Zu-

stand zugeordnet, die Aktionen AT einer Transition

VS Verhaltensspezifikation eines Zustandes

VT Verhaltensspezifikation einer Transition

B Menge von Bedatungskombinationen b

9

Mengenoperationen

A ⊆ B A ist Teilmenge von B

card (A) oder

|A|Kardinalzahl der Menge A, sie bezeichnet die Anzahl der

Elemente einer endlichen Menge

A ∪B Vereinigung der Mengen A und B. A ∪B = {x|x ∈ A ∨x ∈ B}. Es werden keine doppelten Elemente zugelassen

A ∩B Durchschnitt der Mengen A und B. A ∩ B = {x|x ∈A∧x ∈ B}, entspricht den gemeinsamen Elementen der

beiden Mengen

A ∩B = ∅ Die Mengen A und B sind disjunkt, sie haben kein ge-

meinsames Element

A \B Differenz der Mengen A und B. A \B = {x|x ∈ A∧ x /∈B}. Beispiel {1, 2, 3, 4} \ {3, 4, 5} = {1, 2}

A×B Kartesisches Produkt zweier Mengen. A × B =

{(a, b)|a ∈ A ∧ b ∈ B}A1 × · · · × An n-faches Kartesisches Produkt. A1 × · · · × An =

{(a1, · · · , an)|ai ∈ Ai (i = 1, · · · , n)}

Sonstige

bxc Gaußklammer: maxk∈Z,k≤x(k). Dabei ist k die großte

ganze Zahl, welche kleiner oder gleich x ist

x mod y Ganzzahliger Rest der Divisison. x mod y = x−⌊xy

⌋· y

10

Kurzfassung

Moderne Fahrzeuge beinhalten eine stetig wachsende Vielzahl von mecha-

tronischen Systemen, deren Verhalten durch Steuergerate bestimmt wird.

Die Innovationen in der Fahrzeugtechnik werden also in immer großerem

Maße durch die Software dieser Steuergerate gepragt.

Der wachsende Innovationsdruck, einhergehend mit immer kurzer werden-

den Entwicklungszeiten, fordert die Hersteller auf, qualitativ hochwerti-

ge Software immer effektiver zu erstellen. Zur Beherrschung der Kom-

plexitat werden formale Entwicklungsprozesse definiert, um den Software-

Entwicklern und Testern das Zusammenspiel der Arbeitsschritte vorgeben

zu konnen.

Der Fokus der vorliegenden Arbeit liegt auf dem Testen von Kfz-Steuer-

gerate-Software im Rahmen der Software-Entwicklung eines Automobilzu-

lieferers.

In der Praxis gibt es verschiedene Moglichkeiten, die formalen Entwick-

lungsprozesse umzusetzen. Haufig werden fur die Erfullung gleicher Ar-

beitsschritte unterschiedliche, nicht notwendigerweise kompatible Software-

werkzeuge verwendet.

Es hat sich gezeigt, dass Testentwurfsmethoden implizit und intuitiv ange-

wendet werden. Der Einsatz von Werkzeugen zur Unterstutzung der Tester

scheitert entweder an einer fehlenden Implementierung oder daran, dass ein

gegebenes Werkzeug nicht in die vorgegebene Entwicklungslandschaft in-

tegriert werden kann.

Um diesem Umstand entgegenzuwirken, wird im Rahmen der vorliegen-

den Arbeit ein Testframework konzipiert, welches die nahtlose Integration

unterschiedlicher Testfallerstellungswerkzeuge in den Entwicklungsprozess

ermoglicht. Ferner wird eine Heuristik entwickelt, welche die automatisierte

Erstellung von Testfallen fur zustandsbasiertes Verhalten erleichtert.

11

Abstract

Modern vehicles contain an increasing multitude of mechatronic systems,

whose behavior is determined by electronic control units. Hence innova-

tions in cars are more and more influenced by the software within these

control units.

The increasing pressure to innovate in combination with decreasing prod-

uct life-cycles and development times, requires manufacturers to produce

high-quality software more effectively. To handle the ensuing complexity,

software development-processes have been established to define the inter-

action of tasks for software developers and testers.

The focus of this thesis is the testing of electronic-control-unit software at

an automotive supplier.

In practice there are various possibilities to fulfill the development-process.

In most cases, there can be found different, but not necessarily compatible

software-tools to handle the same tasks.

It showed out, that test design methods are applied implicitly and intu-

itively. The use of test-tools to assist the tester fails due to either the lack

of implementation of a required method or due to the fact that an available

tool cannot be integrated into an established development-environment.

To handle these problems, this thesis develops a framework, which en-

ables the seamless integration of different test-tools into the development-

environment. Furthermore a heuristic method is developed, which fa-

cilitates the automated generation of test-cases for state-based software-

behavior.

12

1. Einleitung

Das Ziel der vorliegenden Arbeit ist es einen Ansatz aufzuzeigen, um die

Qualitat und Effizienz in der Softwareentwicklung zu steigern. Dazu wird

die methodische Testsequenzerstellung in den Softwareentwicklungsprozess

eines Automobilzulieferers integriert.

1.1. Motivation

Heutzutage sind bis zu 90 % der Innovationen eines modernen Fahrzeuges

durch Elektronik gepragt [47]. Die eigentlichen Funktionen der Elektronik

sind dabei durch Software implementiert. Dadurch wird diese zunehmend

zum bestimmenden Faktor fur die Qualitat und Sicherheit des gesamten

Fahrzeuges.

Der zunehmende Innovations- und Kostendruck bedingt, dass neue, kom-

plexere Funktionen in immer kurzerer Zeit zur Serienreife gebracht werden

mussen. Um die Qualitats- und Sicherheitsanforderungen, wie sie beispiels-

weise durch die IEC 61508 gefordert werden, zu erfullen und die Komplexi-

tat der Softwareentwicklung beherrschen zu konnen, werden Referenzmo-

delle, wie Automotive-Spice [37], und Vorgehensmodelle, wie das allgemeine

V-Modell [14], eingefuhrt.

Im Rahmen der Entwicklung mussen bis zu 50 % des Gesamtaufwandes fur

den Test der Software eingesetzt werden [52]. Eine Optimierung des Test-

prozesses hat daher ein hohes Einsparpotenzial. Der Testprozess besteht

nach [52] aus den funf Phasen Testmanagement, Testspezifikation, Testaus-

fuhrung, Testprotokollierung und Testauswertung. In der Praxis zeigt sich

oft, dass der Aufbau und die Wartung der Testinfrastruktur einen großen

Teil der Entwicklungs- und Test-Kapazitiat beanspruchen. Basierend auf

einer lauffahigen Testinfrastruktur beziehen sich die meisten Ansatze zur

Minimierung des Testaufwandes bis jetzt auf die Automatisierung der Test-

ausfuhrung. Dabei werden fur die jeweils verwendeten Testausfuhrungs-

plattformen Automatisierungsskripte geschrieben. Die Testinhalte sind da-

13

bei in plattformspezifischen Codeartefakten verborgen und konnen haufig

nur von Experten verstanden werden. Eine Modifikation oder der Wech-

sel der Ausfuhrungsplattform fuhrt dazu, dass die Testskripte angepasst

werden mussen. Durch die Automatisierung der Bereitstellung der Testin-

frastruktur und der Testausfuhrung lasst sich eine Effizienzsteigerung im

Test erzielen.

Der Testinhalt und damit die Fahigkeit einer Testsequenz, bestimmte Feh-

ler aufzudecken, wird jedoch in der Testspezifikation festgelegt. In der Theo-

rie existieren verschiedene Methoden zum Testentwurf, welche die Soft-

waretester in dieser Phase unterstutzen. Ein Einsatz dieser Methoden in

der Praxis scheitert oft daran, dass sie entweder den Entwicklern unzurei-

chend bekannt sind, nicht als Software-Werkzeug realisiert sind, oder das

implementierte Software-Werkzeuge nicht in die vorhandene Entwicklungs-

landschaft integriert sind. Die Steigerung der Test-Qualitat kann also durch

die Integration von Testentwurfsmethoden in den Entwicklungsprozess er-

zielt werden.

Aus dieser Betrachtung ergeben sich die Eingriffsmoglichkeiten, um eine

Qualitats- und Effizienzsteigerung im Test und damit in der Softwareent-

wicklung zu erzielen:

1. Die Einbindung von Testentwurfsmethoden in den Entwicklungspro-

zess.

2. Die Unterstutzung bei der Bereitstellung der Testinfrastruktur.

3. Die plattformunabhangige Abstraktion der Testinhalte, und die Un-

terstutzung diese auf verschiedenen Testausfuhrungsplattformen au-

tomatisiert ausfuhren zu konnen.

1.2. Methoden und Werkzeuge zum Testen

Im Rahmen der Einbindung von Testentwurfsmethoden in den Entwick-

lungsprozess sind bereits Software-Werkzeuge entstanden, eine Auswahl

dieser wird im Folgenden vorgestellt. Um die Werkzeuge klassifizieren zu

konnen, wird im Vorgriff auf den Abschnitt 2.6 eine kurze Einfuhrung der

Testentwurfsmethoden gegeben.

14

Das Testen von Software kann statisch oder dynamisch erfolgen. Im stati-

schen Fall wird die Software ohne eine Ausfuhrung gepruft, beispielsweise

durch formale Reviews. Beim dynamischen Test wird die Software aktiv

stimuliert. Die Art und Weise, wie die Stimuli ausgewahlt werden, also wie

die Testfalle aufgebaut sind, kann basierend auf der Kenntnis der Imple-

mentierung erfolgen: Es handelt sich dann um white-box oder strukturelle

Testentwurfsmethoden. Wenn die Testfalle aus der Kenntnis der Spezifika-

tion der Software ausgewahlt werden, handelt es sich um black-box oder

funktionale Testentwurfsmethoden.

Die white-box Testentwurfsmethoden werden anhand des Testziels der Test-

falle untergliedert. So wird, ohne Anspruch auf Vollstandigkeit, zwischen

einer Anweisungs-, Zweig-, Bedingungs- und Pfaduberdeckung unterschie-

den. Beispielsweise werden bei dem Ziel der Erreichung einer Anweisungs-

uberdeckung die Stimuli so gewahlt, dass alle Anweisungen mindestens

einmal ausgefuhrt werden.

In der Praxis wird in der Prozess-Phase Testmanagement ein fur das zu

testende Artefakt zu erreichender Uberdeckungsprozentsatz und das Uber-

deckungskriterium formuliert. Wahrend die Stimuli großteils manuell durch

Testskripte erzeugt werden, kann die erreichte Uberdeckung der Implemen-

tierung durch Softwarewerkzeuge gemessen werden.

Ein Ansatz zur automatisierten Generierung von white-box Tests wird

durch [39] vorgestellt. Dabei werden basierend auf der Kenntnis des Quell-

codes automatisch Teststimuli generiert, welche zu einer vorgegebenen Co-

deuberdeckung fuhren.

Wichtige Vertreter der black-box Testentwurfsmethoden sind die Aquiva-

lenzklassenbildung und die Grenzwertanalyse. Davon ausgehend, dass die

Uniformitatshyphotese gilt und sich das System fur eine bestimmte Aqui-

valenzklasse von Eingabewerten gleich verhalt, werden die Eingabepara-

meter eines Systems diesen Klassen zugeordnet. Die Ubergange zwischen

den Aquivalenzklassen sind Grenzwerte, welche haufige Fehlerquellen sind.

Die 1993 vorgestellte Klassifikationsbaummethode [29] stellt einen Ansatz

zur Systematisierung der Findung von Aquivalenzklassen und Grenzwer-

ten dar, durch deren Kombination verschiedene Testfalle bestimmt werden

konnen. Die theoretischen Grundlagen werden durch das Werkzeug CTE-

XL [24] implementiert.

15

Ferner sind im Rahmen der black-box Testentwurfsmethoden unter dem

Schlagwort modellbasiertes Testen eine Vielzahl von Ansatzen entstanden.

Diese ziehen analog zu den white-box Testentwurfsmethoden die Struktur

des zugrunde gelegten Verhaltensmodells der Software als Basis fur die

Testsequenzauswahl heran. Dieser Vorgang lasst sich algorithmisch auto-

matisieren.

Ein wesentliches Unterscheidungsmerkmal der Ansatze zum modellbasier-

ten Testen ist das zugrunde liegende Modell. Eine Klasse von Ansatzen

basiert z. B. auf einer Modellierung durch Endliche Zustandsmaschinen

(Finite State Machines - FSM). Im Rahmen der Forschung der Firma Mi-

crosoft ist dabei das Werkzeug specExplorer [21] entstanden, welches mitt-

lerweile in einigen Teilen des Konzerns eingesetzt wird. Das Modell der zu

testenden Software wird dabei durch die dafur entwickelte Sprache Spec#

beschrieben. Andere Ansatze setzen Beschriftete Ubergangssysteme (Labe-

led Transition Systems - LTS) voraus. Eine kommerzielle Implementierung

dieser Vorgehensweise stellt die Firma Conformiq zur Verfugung [22]. Eine

weitere Modellierungsform beruht auf Erweiterten endlichen Zustandsma-

schinen (Extended Finite State Machines - EFSM) nach Harel [31], welche

in modernen Modellierungssprachen Verwendung finden, wie UML oder

MATLAB/SIMULINK.

Die grundsatzlich zu beachtenden Aspekte beim modellbasierten Testen

werden in [44] aufgefuhrt. Wenn eine automatische Verdiktbildung statt-

finden soll, darf das Modell, aus welchem die Testfalle abgeleitet werden,

nicht das Gleiche sein, wie das Modell, aus welchem die Implementierung

abgeleitet wird. Andernfalls wurde nur der Codegenerator gepruft. Es ent-

stunden also keine Testfalle, welche einen großeren als den im Modell defi-

nierten Einblick in die Funktion bieten.

In [36] wird ein systematischer Ansatz erarbeitet, welcher das in der Spra-

che Auto Focus beschriebene Modell der Implementierung in ein Analy-

semodell uberfuhrt. Die Informationen aus dem Analysemodell werden in

ein Constraint-Logik Programm uberfuhrt. Basierend auf dieser Darstel-

lung werden Testsequenzen berechnet. Die innerhalb der Zustandsmaschi-

nen auftretenden Transitionen sind an Parameter gebunden, welche durch

Aquivalenzklassen und Grenzwerte aufgeteilt werden konnen. Um dies zu

16

systematisieren, wird der Klassfikationsbaumeditor CTE-XL in den Ansatz

eingebunden.

Im Rahmen der Arbeit [20] wird vorgeschlagen, als Modellierungs-

sprache die UML zu verwenden, insbesondere UML-Protokollzustands-

automaten. Auch nebenlaufige Funktionen, welche durch die Protokoll-

zustandsautomaten beschrieben werden konnen, werden in die Testse-

quenzerstellung mit einbezogen. Dazu wird ein mehrstufiger Prozess durch-

laufen. Zunachst wird das UML-Modell in eine Datenstruktur eingelesen.

Orthogonale Zustande werden in einen Produktautomaten uberfuhrt, wel-

cher das Verhalten in einer flachen Struktur beschreibt. Die Testsequenz-

erstellung erfolgt durch Graphentraversierungsalgorithmen (Tiefen- und

Breitensuche).

Haufig scheitert der effiziente Einsatz vorhandener Software-Werkzeuge

daran, dass Informationen aus dem Entwicklungsprozess erneut eingegeben

werden mussen und methodisch erstellte Testfalle im Rahmen der vorge-

gebenen Entwicklungslandschaft nicht maschinell weiterbearbeitet werden

konnen. Zudem zeigt die vorliegende Aufzahlung verschiedener Software-

Werkzeuge, dass insbesondere Werkzeuge zum modellbasierten Testen eige-

ne Modellierungssprachen voraussetzen, welche fur den Einsatz unter den

Anwendern etabliert werden mussen.

1.3. Beitrag

Um die in Abschnitt 1.1 beschriebenen Eingriffsmoglichkeiten fur die

Effizienz- und Qualitatssteigerung im Softwareentwicklungsprozess zu nut-

zen, wird im Rahmen der vorliegenden Arbeit ein Framework erarbei-

tet, welches konzeptionell und technologisch die Integration verschiedener

black-box Testentwurfsmethoden in den Entwicklungsprozess ermoglicht.

Dabei wird sowohl die Bereitstellung der Testinfrastuktur als auch die Ab-

straktion und automatische Ausfuhrung der Testinhalte unterstutzt. Ferner

wird eine Heuristik zum modellbasierten Testen eingefuhrt, welche durch

das Framework an die in der Entwicklungslandschaft verwendeten Model-

lierungssprachen angepasst werden kann.

17

Das Framework besteht dabei aus drei Schichten:

Methodenschicht: Methoden zum Testentwurf werden integriert. Durch

Transformationsregeln konnen entweder kommerzielle oder im Rah-

men der Arbeit entstandene Testsequenzerstellungswerkzeuge initia-

lisiert werden. Ausgabe dieser Schicht sind abstrakte, formalisierte

Testbeschreibungen.

Formale Testbeschreibung: Durch Transformationsregeln werden die

Testbeschreibungen unterschiedlicher Herkunft in eine einheitliche

formale Testbeschreibung uberfuhrt. Diese dient zur Kommunikation

der eigentlichen Testinhalte und kann beispielsweise durch Bedatung

weiter konkretisiert werden.

Adaption an Ausfuhrungsplattformen: Die formal beschriebenen

Testfalle werden mit Hilfe einer weiteren Transformation an die

jeweils vorgesehene Testausfuhrungsplattform angepasst.

1.3.1. Stand der Technik und Beitrag

durch das Framework

Die generelle Struktur einer solchen Integration zeichnet sich in ahnli-

cher Form in verschiedenen Veroffentlichungen ab. So zeigt [30] einen An-

satz auf, welcher aus den Werkzeugen CTE und TPT (Time-Partition-

Testing [34]) erstellte Testfalle entgegennimmt und diese in die Sprache

TTCN-3 transformiert, um diese dann zur Ausfuhrung zu bringen. Das von

der Firma Leirios erarbeitete Werkzeug Leirios Testgenerator, dessen Me-

thode neben anderen Ansatzen in [54] ausfuhrlich beschrieben ist, beruht

auf UML-Modellen und generiert die Testfalle in einem speziellen XML-

Schema. In [48] wird ein kaskadiertes, MDA (Model Driven Architecture)

basiertes Vorgehen beschrieben. Dabei wird fur die Domane GUI-Testen

(Graphical User Interface) eine domanenspezifische Sprache zur Formu-

lierung der Testinhalte erarbeitet, welche durch Transformation auf einer

spezifischen Plattform zur Ausfuhrung gebracht wird. Fur die Implemen-

tierung wird openArchitectureWare (oAW) [1], eine Open Soruce Imple-

mentierung der MDA, verwendet.

18

Das im Rahmen der Arbeit entstandene Framework geht konzeptionell uber

diese Ansatze hinaus, indem es zur Initialisierung der Testsequenzerstel-

lungswerkzeuge Informationen aus dem Entwicklungsprozess verwendet.

Es basiert ebenfalls auf der MDA und verwendet fur die Implementierung

oAW. Ein Beitrag besteht darin, die Konzepte fur das Einsatzgebiet der

automobilen Software-Entwicklung zu adaptieren.

1.3.2. Stand der Technik und Beitrag

durch die methodische Testsequenzerstellung

Um den Einsatz des modellbasierten Testens zu ermoglichen, wird inner-

halb des Frameworks eine Heuristik entwickelt, welche es dem Testinge-

nieur ermoglicht, die Testsequenzgenerierung intuitiv zu steuern. Die Ziel-

setzung ist hierbei ein Migrationsszenario, welches einen iterativen Aufbau

der automatisch generierten Testspezifikation ermoglicht, um den Einblick

und das Vertrauen in die zugrundeliegenden Algorithmen zu starken. Wah-

rend bei den bekannten Ansatzen, basierend auf UML-Zustandsmaschinen,

die Strukturierungselemente Hierarchie und Parallelitat zunachst aufgelost

werden, wird im Rahmen der vorliegenden Arbeit ein expliziter Erhalt die-

ser Strukturierung angestrebt. Diesem Vorgehen liegt die Annahme zu-

grunde, dass die Entwicklungsingenieure mit dem Einsatz der Strukturie-

rung spezifische Aufgabenaspekte der Implementierung im Fokus haben.

Wenn diese durch die Testsequenzgenerierung verloren gehen, ist es nur mit

großem Aufwand moglich aufzuzeigen, welchen Bezug die Testsequenzen zu

dem Testmodell haben.

Mit Hierarchie wird folgendermaßen umgegangen: Die Heuristik identifi-

ziert den Initialknoten der hierarchisch untergeordneten Zustandsmaschi-

ne und behandelt diese als unabhangiges Modell fur die Testsequenzgene-

rierung. Ferner identifiziert die Heuristik die strukturellen Verknupfungen

des hierarchischen Unterzustandes und ermoglicht somit die Erstellung der

Testsequenzen fur das Gesamtsystem. Die aus dem ursprunglichen Modell

vorgegebene Hierarchie wird dadurch in den generierten Testfallen beibe-

halten, wodurch dem Testingenieur die gezielte Zuordnung von Testsequenz

zu Testmodell ermoglicht wird.

19

Wahrend ein gebrauchlicher Ansatz zum Umgang mit Orthogonalitat in-

nerhalb eines UML-Zustandsmaschinen fur die Testsequenzgenerierung

darin besteht, alle moglichen Zustandskombinationen (Konfigurationen) zu

bestimmen, wird dieses Kombinationsproblem im Rahmen der Arbeit neu-

artig gelost.

1.3.3. Stand der Technik und Beitrag

durch die formale Testbeschreibung

Durch die plattformunabhangige Beschreibung der Testspezifikation ergibt

sich die Moglichkeit, diese auf unterschiedlichen Teststufen zur Ausfuhrung

zu bringen. Die Testentwurfsmethoden konnen also bedarfsgerecht in ver-

schiedenen Entwicklungsphasen eingesetzt werden. Im Rahmen der Arbeit

wird ein proprietares XML-Schema fur die Beschreibung der Testspezifi-

kation verwendet. Derzeit sind aber verschiedene Standardisierungsvorha-

ben in Arbeit. So wird im Rahmen der Herstellerinitiative Software [8] ein

XML-basiertes Testaustauschformat erarbeitet. Innerhalb der IEEE wird

unter der Abkurzung ATML (Automatic Test Markup Language) [3] an

dem Standard IEEE 1671 gearbeitet.

Durch den Einsatz eines solchen Testaustauschformates konnen Testbiblio-

theken aufgebaut werden und ein gezieltes wiederverwenden von Testse-

quenzen wird moglich. Erfahrungswissen der Tester kann in diesen Biblio-

theken ebenfalls abgelegt werden. Der Einsatz einer formalen Beschreibung

ermoglicht es, die im Laufe der Zeit erarbeiteten Best-Practices beim Tes-

ten zu formalisieren und zu konservieren.

Es bleibt zu berucksichtigen, dass die Testbibliotheken vor dem Einsatz

in einem geanderten Kontext, ahnlich wie bei der komponentenbasierten

Softwareentwicklung, auf ihre Eignung hin zu prufen sind.

1.3.4. Stand der Technik und Beitrag durch die

Adaption an die Ausfuhrungsplattformen

Abhangig von der Teststufe kommen unterschiedliche Testausfuhrungs-

plattformen zum Einsatz. Nicht selten werden die Automatisierungsskripte

20

einer spezifischen Ausfuhrungsplattform auch noch projektspezifisch vari-

iert. Ein Standard-Codegenerator ist damit in der Praxis kaum realisierbar.

Im Rahmen des Frameworks wird die Plattformadaption durch ei-

ne Modell-zu-Code Transformation realisiert. Dabei ist es moglich,

ausfuhrungsplattform- und projektspezifische Testskriptvorlagen anzule-

gen, welche durch Transformationsregeln mit den in der formalen Test-

beschreibung erfassten Informationen erganzt werden.

1.3.5. Erwarteter Nutzen

Durch den Einsatz des Testframeworks wird die werkzeuggestutzte metho-

dische Testsequenzerstellung im Rahmen der vorgegebenen Entwicklungs-

prozesse ermoglicht. Durch das methodische Vorgehen wird eine Qualitats-

steigerung der Testprozesse ermoglicht. Diese wird vor allem durch den

dokumentierten Einsatz von Methoden beim Testentwurf erzielt. Es kann

verhindert werden, dass Testsequenzkombinationen vergessen werden. Fer-

ner bedingt das Framework als durchgangig geschlossene Werkzeugkette

eine Effizienzsteigerung bei der Erstellung und Ausfuhrung von Testfallen.

1.4. Aufbau der Arbeit

Die Arbeit ist folgendermaßen gegliedert. Das Kapitel 1 erfasst den Stand

der Technik in dem der Arbeit zugrundeliegenden Gebiet der Entwicklung

von Kfz-Steuergerate-Software. In Kapitel 2, werden die Prozesse, Metho-

den und Werkzeuge in diesem Umfeld beschrieben. Daraus resultiert die

Aufgabenstellung der Arbeit Testentwurfsmethoden moglichst generisch in

den Software-Entwicklungsprozess integrieren zu konnen. In Kapitel 3 wird

das zur Losung der Aufgabenstellung konzeptionierte Testframework und

dessen Bestandteile vorgestellt. Aufgrund der Vielfaltigkeit des Arbeitsge-

bietes wird eine Leitanwendung in Kapitel 4 beschrieben, anhand derer die

Konzepte des Testframeworks konkretisiert werden. Das Kapitel 5 stellt die

Entwicklung einer neuartigen Heuristik zur modellbasierten Testsequenz-

generierung im Rahmen des Testframeworks anhand der Leitanwendung

vor. Nach der Diskussion des Einsatzes des Testframeworks in Kapitel 6

wird in Kapitel 7 eine Zusammenfassung der Arbeit gegeben.

21

2. Prozesse, Methoden und

Werkzeuge

Im Rahmen dieses Kapitels werden die Randbedingungen der Software-

entwicklung in der Automobilindustrie dargestellt, um den Beitrag dieser

Arbeit einordnen zu konnen. Zunachst werden in Abschnitt 2.1 die Aufga-

ben und der prinzipielle Aufbau von Software in der Domane Automobil

eingefuhrt. In Abschnitt 2.2 wird der Softwareentwicklungs- und Testpro-

zess vorgestellt. Fur die Erstellung der Steuergeratesoftware kommen ver-

schiedene Entwicklungsparadigmen zum Einsatz, welche in Abschnitt 2.3

erortert werden. Die Betrachtung der potenziellen Softwarefehler in Ab-

schnitt 2.5 erleichtert die Auswahl von Testfallerstellungsmethoden, welche

in Abschnitt 2.6 aufgefuhrt werden. Vor diesem Hintergrund konnen An-

forderungen an das effizientere Testen von Software gestellt werden, welche

in Abschnitt 2.7 zusammengefasst werden.

2.1. Aufgaben und Aufbau der Software

Ein modernes Fahrzeug besteht aus einer Vielzahl mechatronischer Sys-

teme. Diese sind dadurch gekennzeichnet, dass sie Mechanik, Elektronik

und ein elektronisches Steuergerat vereinen. Das Steuergerat enthalt in der

Regel einen Mikrocontroller, der durch Software gesteuert wird. Ein sol-

ches System ist exemplarisch am Beispiel eines Automatikgetriebes [23] in

Bild 2.1 dargestellt. Das mechanische Automatikgetriebe ist durch Aktoren

und Sensoren mit dem elektronischen Steuergerat verbunden. Der Test der

Software dieser Steuergerate ist Gegenstand der vorliegenden Arbeit. Diese

Software ist modular aufgebaut und besteht aus folgenden Bestandteilen:

Modul: Kleinste ausfuhrbare Einheit (Meist eine Klasse. Bsp.: Einstellung

des Hydraulikdrucks).

22

Komponente: Zusammenstellung mehrerer Module zur Ausfuhrung ei-

ner bestimmten Aufgabe (Bsp.: Fehlerbehandlung, Hydraulikansteue-

rung).

Gesamtsoftware: Zusammenstellung aller Komponenten zu der im Steu-

ergerat verwendeten Gesamtsoftware (Bsp.: Getriebesteuerung).

Komponente 2Komponente 1

cX2 cRegler

Einschalten()

cRegler

Einschalten()

Ausschalten()

p_Ist

cX1cX2

cXn Aus

Ausschalten()/

Einschalten()/

MATLAB®

UML

Ein

Steuergeräte Software

CAN-Bus

Abtriebsdrehzahl

Turbinendrehzahl

Wählhebel

Magnet-

Ventile,

Druckregler

Motordrehzahl

Motormoment

Drosselklappenstelung

Anzeige

Motoreingriff Diagnose-

anschlussGesamtsoftware

SW-Komponente

SW-Modul

Programm-

schalter Kick-Down-

SchalterE S

Elektronisches Steuergerät

1

Out1

Product

2

In2

1

In1

Bild 2.1.: Aufbau von Steuergeratesoftware.

2.2. Softwareentwicklungs- und Testprozess

Die Einfuhrung von Vorgehensmodellen, wie dem allgemeinen V-Modell,

hilft dabei, die Softwareentwicklung ubersichtlich zu gestalten und die

23

Komplexitat beherrschbar zu machen. Parallel zu der Entwicklung des ers-

ten V-Modells in Deutschland 1986, wurde in den Vereinigten Staaten auf

Initiative des US-Verteidigungsministeriums ein System zur Bewertung der

Reife von Softwareentwicklungsprozessen erarbeitet, welches den Namen

Capability Maturity Model tragt [10]. Daraus hat sich bis heute eine Fa-

milie von Referenzmodellen mit dem Namen Capability Maturity Model

Integration (CMMI) entwickelt. Konkurrierend dazu ist seit 1998 das Re-

ferenzmodell Software Process Improvement and Capability Determination

(SPICE) entstanden [37]. Seit 2001 wird die domanenspezifische Variante

Automotive-Spice unter Federfuhrung von VW entwickelt, welche in der

Automobilindustrie eingesetzt wird. Innerhalb von Automotive-Spice sind

verschiedene Prozessgruppen definiert. Aus der Gruppe der Engineering-

Prozesse wird die strukturierte Softwareentwicklung nach dem V-Modell

abgeleitet. Die im Rahmen der Arbeit zugrundegelegte Konfiguration des

Software-Design

Software-

Anforderungsanalyse

Software-

Erstellung

Softwareintegration und

Integrationstest

Softwaretest

Modultest

System-

Architekturdesign

UML Zustandsdia

gramme ...

C/

C++MA

TL

AB

/

SIM

UL

INK

Testplanung Testmanagement

Warum, Was, Wo und Wann?

System-

Anforderungsanalyse

Gesamt-

Anforderungsanalyse

3) 4) 5)2)

2) 3) 4) 5)

2) 3) 4) 5)

Systemtest

Systemabnahme

Systemintegration- und Integrationstest

Wie, Wie viel?

Wie, Wie viel?

Wie, Wie viel?

Appli-

kation

Parallele

Ent-

wicklungs-

prozesse

Hydraulik,

Mechanik,

Elektronik

Projekt-

management

Lieferanten-

management

Konfigurations

management

Änderungs-

management

Qualitäts-

sicherung

Problem-

management

Organisatorische und unterstützende Prozesse

1) Testplanung

2) Testspezifikation

3) Testdurchführung

4) Testprotokollierung

5) Testauswertung

Legende:

1)

Bild 2.2.: Integration des Softwaretestprozesses in den Softwareentwick-lungsprozess.

V-Modells ist in Bild 2.2 dargestellt. Der aufgespannte Rahmen geht uber

die eigentliche Softwareentwicklung hinaus, der Fokus der Arbeit liegt al-

lerdings auf der Softwareentwicklung. In der Software-Anforderungsanalyse

24

werden die Anforderungen an die zu erstellende Software erfasst. Sie stel-

len die Grundlage fur das Software-Design dar. Das Grobdesign wird dabei

in UML erstellt. Es wird entschieden, welche Funktionsblocke vorhanden

sein mussen und in welche Komponenten und Module sich die Software un-

tergliedert. Das Feindesign, welches die eigentliche Funktion der einzelnen

Module beschreibt, wird teilweise mit MATLAB/SIMULINK oder eben-

falls in UML erstellt. Der Großteil des Programmcodes wird manuell in C

und C++ programmiert. Das Software-Design ist eng mit der Software-

Erstellung verwoben. Neben der eigentlichen Erstellung ist in dieser Pha-

se fur jedes Modul ein Modultest aufzusetzen. In der Softwareintegration

und dem Integrationstest geht es darum, die einzelnen Module zu funk-

tionsfahigen Komponenten zu integrieren und sicherzustellen, dass deren

Zusammenspiel funktioniert. Die zur Gesamtsoftware integrierten Kompo-

nenten werden schließlich im Softwaretest gegen die Softwareanforderungen

getestet.

Wie Bild 2.2 veranschaulicht ist der Softwaretestprozess, nach [52], in den

Entwicklungsprozess integriert. In der Testplanung (1), werden die organi-

satorischen Aspekte des Testens berucksichtigt. Typische Tatigkeiten sind

die Planung und Verteilung des Resourceneinsatzes (Wer soll wann auf

welcher Umgebung welche Tests ausfuhren?). Weitere Aspekte sind die

Auswahl der Teststrategie sowie die Festlegung der Testendekriterien. In

der Testspezifikation (2) werden die Testinhalte abstrakt erstellt. In die-

ser Phase unterstutzen Testentwurfsmethoden den Tester dabei, systema-

tisch vorzugehen. Dies ist die fur die Qualitat der Tests wichtigste Phase,

da der Inhalt der Testsequenzen festgelegt wird. In der Testausfuhrung

(3) werden die spezifizierten Tests zur Ausfuhrung gebracht. Dazu ist es

notig, entsprechende Testumgebungen bereitzustellen und entweder Test-

skripte zu erstellen, um die Tests automatisch ausfuhren zu konnen, oder

die Tests gemaß der Testspezifikation manuell auszufuhren. Wahrend der

Testausfuhrung muss eine ausfuhrliche Protokollierung (4) stattfinden, um

die Tests bei erweiterten Fragestellungen nicht wiederholen zu mussen und

die Testauswertung (5) unterstutzen zu konnen. Bei der Auswertung wird

entschieden, ob es sich bei gefundenen Fehlern um Fehler in der Testse-

quenz, der Testumgebung oder wirklich um einen Softwarefehler handelt.

Aus der Summe der Testergebnisse lasst sich ein Momentanbild ableiten,

wie es um den Entwicklungszustand der Software bestellt ist.

25

Die vertikale Gliederung des V-Modells fuhrt zu den Teststufen Modul-

test, Integrationstest und Softwaretest. Die Phasen des Softwaretestpro-

zesses, ausgenommen die Phase Testplanung, wiederholen sich in diesen

Stufen immer wieder aufs Neue. Auf den verschiedenen Teststufen sind ge-

maß der Teststrategie vorgegebene Testziele zu erreichen. Dabei kommen

unterschiedliche Testausfuhrungsplattformen zum Einsatz. Im Folgenden

wird eine fur das zugrundeliegende Forschungsprojekt gultige Auspragung

der Teststufen beschrieben.

Modultest: Die Entwicklung der Software beginnt mit den kleinsten Ein-

heiten, den Modulen. Der Modultest ermoglicht es, diese elementa-

ren Bausteine von Anfang an auf ihre Funktionalitat zu uberprufen

und die Funktion von neuen Code-Konstrukten in einem uberschau-

baren Rahmen zu testen. Ein weiteres Ziel des Modultestes ist es,

sicherzustellen, dass der Code lesbar und so strukturiert ist, dass

er der entworfenen Architektur genugt und wiederverwendet werden

kann. Ferner mussen die MISRA C Programmierrichtlinien1 [12] ein-

gehalten werden. Dies wird mit Hilfe eines statischen Code-Analyse-

Werkzeuges und Reviews erreicht. Auf dieser Stufe ist zudem si-

cherzustellen, dass der Code technisch funktioniert und kein unbe-

nutzbarer oder unerreichbarer Code programmiert wurde. Dazu wird

der Code dynamisch stimuliert und die Kontrollflussuberdeckung be-

stimmt. In der Testplanung wird dafur projektspezifisch ein zu er-

reichender Uberdeckungsprozentsatz festgelegt. Zur Durchfuhrung,

Protokollierung und Auswertung der Tests wird ein CppUnit [5] ahn-

liches Testframework eingesetzt. Durch die Wahl der Stimuli lassen

sich schon hier funktionale Aspekte des Softwaremoduls testen.

Integrationstest: Der Integrationstest soll sicherstellen, dass sich die Mo-

dule reibungslos integrieren lassen und dass das Zusammenspiel wie

geplant funktioniert. Im Integrationstest wird eine Software-in-the-

Loop (SiL) Testumgebung eingesetzt. Diese ist in Analogie zu einer

Hardware-in-the-Loop (HiL) Testumgebung dadurch gekennzeichnet,

dass der Steuergerate-Code und ein Umgebungsmodell auf dem PC

gegeneinander simuliert werden. Prinzipiell ist das funktionale Zu-

sammenspiel der Gesamtsoftware mit der Umgebung hier erstmals

1Bei der Generierung von C-Code aus MATLAB/SIMULINK Modellen mussen Modellierungsrichtlinieneingehalten werden, um zu gewahrleisten, dass der erzeugte Code den MISRA Regeln entspricht.

26

testbar, wenngleich die Aussagekraft der Tests im Wesentlichen von

der Gute der verwendeten Umgebungsmodelle abhangt.

Softwaretest: Ziel des Softwaretests ist es sicherzustellen, dass die Soft-

ware die gewunschte Funktionalitat im Fahrzeug realisiert. Dabei ist

es notwendig, dass die Software auf dem Steuergerat ausgefuhrt wird.

So wird gewahrleistet, dass die Software fehlerfrei auf die Hardware

ubertragen wird und das korrekte Zusammenspiel von Hard- und

Software gegeben ist. Dazu werden HiL- und Fahrzeugversuche durch-

gefuhrt. Das Testende fur den Softwaretest wird dadurch nachgewie-

sen, dass zu jeder Anforderung der spezifizierte Test mit positivem

Ergebnis durchgefuhrt wurde.

2.3. Entwicklungsparadigmen

Die Software fur ein mechatronisches System muss verschiedenen Anfor-

derungen genugen. Es sind physikalische, mechanische und elektronische

Zusammenhange zu berucksichtigen. Als Ergebnis muss ein Programm in

Maschinensprache zur Verfugung stehen, welches die Anforderungen auf

der Hardware realisiert.

2.3.1. Steuerungs- und regelungstechnische Aspekte

Ziel der Software in mechatronischen Systemen ist die Steuerung bzw. die

Regelung2 des Systemverhaltens. Es kann sich bei einem Automatikgetriebe

beispielsweise um die Regelung einer Aktuatorik handeln. Die Auslegung

dieser Regelungen erfolgt in einer Simulation gegen ein physikalisch/ma-

thematisches Modell des Verhaltens des zu beeinflussenden Systems. Bei

dem Modell handelt es sich um Differenzialgleichungen, welche durch al-

gebraische Beziehungen in Zusammenhang gebracht werden. Fur die Mo-

dellierung hat sich das Programmsystem MATLAB/SIMULINK etabliert.

Dieses enthalt bereits eine große Anzahl von Funktionen fur die Modeller-

stellung, z. B. Modellbibliotheken sowie Funktionen fur die Auslegung der

Regelungsalgorithmen. Durch die Simulation kann das Verhalten der Rege-

2Im Folgenden wird nur noch von Regelung gesprochen.

27

lung bereits vor der eigentlichen Produktion des Systems getestet werden.

In den letzten Jahren wurden verschiedene Werkzeuge aufgebaut, welche

es ermoglichen, diese Simulationsmodelle direkt in steuergeratekonformen

C-Code zu transformieren3.

2.3.2. Kommunikation

Aufgrund der Realisierung von immer mehr Funktionalitat durch elektro-

nische Steuergerate ist die Anzahl der benotigten Kabelverbindungen so

weit angestiegen, dass sie durch Verwendung einer herkommlichen Ver-

drahtung nicht mehr in ein Fahrzeug passen wurde. Zur Beseitigung dieser

Problemematik sind Bus-Systeme eingefuhrt worden, welche die effektivere

Verdrahtung der Steuergerate ermoglichen. Der wohl bekannteste Vertreter

ist der CAN (Controller Area Network) Bus, welcher 1983 unter Federfuh-

rung der Firma Bosch entwickelt wurde [33]. Mittlerweile sind weitere Bus-

systeme hinzugekommen, exemplarisch seien FlexRay und MOST genannt.

Fur die Software auf einem Steuergerat bedeutet dies, dass eine Signalauf-

bereitungsschicht zur Verfugung stehen muss, welche die am Bus ankom-

menden Signale auf interne Großen der Software abbildet und zu versen-

dende Großen auf Bus Signale ubertragt.

In diesem Zusammenhang ist bei der Auslegung der Regelungsalgorithmen

darauf zu achten, dass diese mit eventuell durch die Kommunikation auf-

tretenden Totzeiten zurecht kommen mussen.

2.3.3. Berucksichtigung der Hardware

Die Abbildung der Schnittstellen des Mikrocontrollers auf die Sensorik bzw.

Aktuatorik muss erfasst und dokumentiert werden, um zu berucksichtigen

wie die Software die Sensorik und Aktuatorik ansteuern kann. Zum einen

handelt es sich dabei um physikalische Schnittstellen des Controllers, wie

Digital/Analog-Wandler oder PWM-Ausgange. Zum anderen handelt es

sich um Bus-Kommunikation, wie beispielsweise die CAN-Schnittstelle.

3Hauptsachlich handelt es sich dabei um den Real-Time Workshop Embedded Coder von The Ma-thWorks oder Target Link der Firma dSPACE.

28

2.3.4. Programmierung

Um die gewunschte Funktionalitat zu realisieren, muss ein Programm in

Maschinensprache zur Verfugung stehen. Wahrend bis in die neunziger Jah-

re eingebettete Systeme noch hauptsachlich in Assembler programmiert

wurden, um den geringen Ressourcen gerecht zu werden, hat im Verlauf der

Zeit ein Wechsel hin zu komfortableren Hochsprachen stattgefunden, deren

Einsatz von dem verwendeten Zielsystem unabhangig ist. Dabei kommt die

funktionsorientierte Sprache C und deren objektorientierte Weiterentwick-

lung C++ zum Einsatz [15]. Da die Assemblersprache fur jeden Mikro-

controller individuell ist, stellen die Herstellerfirmen Cross-Compiler zur

Verfugung, welche es ermoglichen, die Hochsprachen in die jeweilige Ziel-

Assemblersprache zu ubersetzen.

Funktionsorientierte Programmierung Die Sprache C ist eine funk-

tionsorientierte oder auch prozedurale Programmiersprache. Zentraler Be-

standteil eines C-Programms ist die Funktion main(), welche weitere Funk-

tionen aufrufen kann. Die Kapselung von Daten ist durch Strukturen mog-

lich. Gegenuber einer objektorientierten Sprache besteht der Nachteil, dass

ahnliche, zusammenhangende Funktionalitat nicht so effektiv gekapselt

werden kann.

Objektorientierte Programmierung Um die Nachteile der funktions-

orientierten Programmierung zu beheben und den Code effektiver gestalten

zu konnen, wurde das Paradigma der objektorientierten Programmierung

schon Ende der sechziger Jahre entwickelt. Eine praktisch relevante An-

wendung erfahrt das Paradigma aber erst seit den neunziger Jahren. Es

bietet die Moglichkeit Attribute (Variablen) und Methoden (Funktionen)

in einer Klasse zu kapseln, deren Instanzen Objekte genannt werden.

Anhand des bereits erwahnten Automatikgetriebes soll dieser Zusammen-

hang verdeutlicht werden. Zur Bedienung der mehrfach vorhandenen Kupp-

lungen innerhalb des Getriebes werden baugleiche bzw. ahnliche hydrau-

lische Aktuatoren verwendet. Der Druck, den die Aktuatoren stellen, ist

proportional zu einem Strom, den das Steuergerat vorgeben kann. Fur ei-

ne solche Anwendung bietet es sich an die Aktuatoren als Objekte einer

29

Klasse aufzufassen. Die Daten und Funktionen, welche zu der Ansteue-

rung eines Aktuators benotigt werden, konnen dadurch in dieser Klasse

gekapselt werden.

2.4. Modelle in der Softwareentwicklung

Bei der Einfuhrung der Entwicklungsparadigmen sind schon die wesentli-

chen Modelltypen vorgestellt worden.

Die fruhen Modelle in der Softwareentwicklung sind in der Abstraktion

der Assemblersprache in die Hochsprachen C und spater C++ verborgen.

Auch diese Hochsprachen wurden weiter in Programmsysteme wie MAT-

LAB/SIMULINK und UML abstrahiert. Allen Modellen ist gemein, dass

sie versuchen, die komplexen, zugrundeliegenden Zusammenhange auf das

Wesentliche zu abstrahieren, um fokussiert entwickeln zu konnen.

In der Informatik bedeutet dies, dass die zu verarbeitenden Informationen

bzw. die von der Software umzusetzende Funktionalitat in irgendeiner Form

in den PC eingegeben und dort in Maschinensprache verstandlich aufberei-

tet werden muss. Aus diesem Abbild der Informationen im Speicher konnen

weitere Transformationen angestoßen werden.

Im Kontext der Abstraktion der Assemblersprache auf die Hochsprache

C sei hier die Backus-Naur-Form erwahnt. Dieser Formalismus wird dazu

verwendet, die Syntax der Programmiersprache C so zu beschreiben, dass

daraus ein Parser erzeugt werden kann. Der Parser ist dann in der Lage,

den C-Programmcode einzulesen. Der Compiler vermag aus diesem Spei-

cherabbild des Codes die notwendigen Assembler-Befehle abzuleiten. Eine

exaktere Beschreibung der Thematik ist in [51] zu finden.

Im Bereich der automobilen Softwareentwicklung und damit auch in der

vorliegenden Arbeit sind derzeit die Abstraktionen der Sprachen C und

C++ im Fokus. Dazu bietet sich zum einen das bereits erwahnte Pro-

grammsystem MATLAB/SIMULINK an, welches gut fur die funktionalen

und regelungstechnischen Aspekte der Software geeignet ist. Sowohl der

Hersteller The MathWorks als auch die Firma dSPACE bieten als Ergan-

zung zu den SIMULINK Signalfluss-Diagrammen spezielle Erweiterungen

30

an, damit das Funktionsmodell mit den fur die Transformation in die Spra-

che C notwendigen Informationen angereichert werden kann.

Bei der Softwareentwicklung mit der objektorientierten Programmierspra-

che C++ bieten sich UML-Werkzeuge an.

2.4.1. Unified Modeling Language

Die Unified Modeling Language (UML) ist eine von der OMG standardisier-

te Sprache, welche zur Modellierung von Software und Software-Systemen

verwendet wird [13, 38]. Ihre Anfange liegen in den neunziger Jahren. In

diesem Zusammenhang wurde die UML dazu verwendet, die gerade auf-

kommenden objektorientierten Softwaresysteme zu beschreiben. Die UML

definiert derzeit dreizehn Diagrammtypen. Im Rahmen der vorliegenden

Arbeit werden das Klassendiagramm und das Zustandsdiagramm verwen-

det, weswegen nur diese beiden Diagrammtypen im Folgenden erlautert

werden.

2.4.1.1. Klassendiagramm

Das Klassendiagramm ermoglicht es, Klassen im Sinne der objektorientier-

ten Programmierung und deren Beziehungen untereinander darzustellen.

Eine Klasse wird dabei als Rechteck dargestellt, welches durch horizontale

Linien geteilt wird. Im ersten Abteil steht der Name der Klasse, im zweiten

die Attribute und schließlich die Methoden. Zwischen den Klassen konnen

folgende Beziehungen bestehen:

• Vererbung bzw. Generalisierung

• Assoziation

– Gerichtete Referenz

– Aggregation

– Komposition

Mit Ausnahme der Komposition sind diese Beziehungen in Bild 2.3 dar-

gestellt. Die Klasse CommonMetaData ist eine Generalisierung der Klasse

Testfallgruppe. Dadurch erbt die Klasse Testfallgruppe die Attribute (Sta-

31

tus, AusfuhrungsArt, ...) der Klasse CommonMetaData. Die Klasse Test-

spezifikation verweist durch eine gerichtete Referenz auf die Klasse Testbi-

bliothek. Es handelt sich um eine 0 zu * Beziehung (0..*). Eine Instanz der

Klasse Testspezifikation kann also auf null bis beliebig viele Instanzen der

Klasse Testbibliothek verweisen. Ferner beinhaltet die Klasse Testspezifika-

tion durch die Aggregation der Klasse Testfallgruppe eine interne Menge

mit Instanzen dieser Klasse. Bei einer Aggregation konnen die instanzi-

Bild 2.3.: Beispiel fur ein Klassendiagramm.

ierten Elemente nicht ohne das beinhaltende Element existieren. In dem

dargestellten Beispiel konnen also keine Elemente der Klasse Testfallgrup-

pe angelegt werden, ohne dass eine Instanz der Klasse Testspezifikation

vorhanden ist. Bei einer Komposition ist dies hingegen moglich. Sie wird

grafisch durch eine nicht ausgefullte Raute dargestellt.

2.4.1.2. Zustandsdiagramm

Innerhalb der UML wird ein Zustandsdiagramm zu der Klasse der Verhal-

tensdiagramme gezahlt. Das Zustandsdiagramm orientiert sich an der Defi-

nition nach Harel [31]. Es erweitert das Verhalten einer Zustandsmaschine

im Wesentlichen um die Konzepte der Hierarchie und Orthogonalitat, wel-

che in Unterabschnitt 5.1.4 beschrieben werden.

32

2.4.2. Extensible Markup Language

Die Extensible Markup Language (XML) ist eine Auszeichnungssprache.

Sie wird eingesetzt, um Informationen zu strukturieren und sowohl fur

den Menschen als auch fur Maschinen les- und austauschbar zu machen.

Die XML ist ein offener Standard, ein Allzwecksystem zum Speichern von

Informationen und ein Werkzeugkasten fur Auszeichnungssprachen [45].

Innerhalb der XML ist es moglich, Informationen in Elemente zu verpa-

cken. Diese Elemente konnen wiederum zueinander in Beziehung stehen

und Attribute fur die weitere Unterstrukturierung aufweisen.

Eine vollstandigere Definition der XML wurde den Rahmen dieser Arbeit

ubersteigen. Fur die weiteren Ausfuhrungen ist es jedoch wichtig, zumin-

dest die wesentlichen Elemente und deren Beziehung zu anderen Abstrak-

tionsmechanismen, wie dem bereits eingefuhrten Klassendiagramm, aufzu-

zeigen.

Die Grundbegriffe werden anhand der in XML serialisierten Instanz des

Klassendiagramms aus Bild 2.3 erlautert.

1 <?xml version=”1 .0 ” encoding=”UTF−8”?>

2 <t e s t : T e s t b i b l i o t h e k

3 xmi :ve r s i on=”2 .0 ” xmlns:xmi=”h t tp : //www. omg . org /XMI”

4 xmln s : t e s t=” t e s t s p e z i f i k a t i o n ” Name=”Funkt ions te s t ”>

5 <T e s t s p e z i f i k a t i o n Name=”cDruckRegler ” Vers ion=”1 .0 ”

6 B i b l i o t h e k s S p e z i f i k a t i o n=”/ ”>

7 <T e s t f a l l g r u p pe Status=” s p e z i f i z i e r t ”

8 T e s t z i e l=”Nachweis der Funkt i ona l i t a t ”

9 P r i o r i t a t=” g e n e r i e r t ”

10 Name=”Regeln ”/>

11 </ T e s t s p e z i f i k a t i o n>

12 </ t e s t : T e s t b i b l i o t h e k>

Listing 2.1: Serialisierung einer Instanz eines Klassendiagramms.

Die Klasse Testbibliothek stellt das Wurzelelement des Klassendiagramms

dar und wird daher auch als Wurzelelement der XML-Serialisierung ab-

gebildet. Dies ist dadurch gekennzeichnet, dass der Name der Klas-

se in spitzen Klammern (<test:Testbibliothek ...>) zu Beginn des

Dokuments steht. Am Ende des Dokuments steht der Name ebenfalls

in spitzen Klammern, allerdings mit einem vorangestellten Schragstrich

(</test:Testbibliothek>). Die Testbibliothek aggregiert das Element

Testspezifikation, dessen Attribut Name dabei mit dem Wert cDruckReg-

33

ler instanziiert ist. Die Testspezifikation wiederum aggregiert das Element

Testfallgruppe. In der Serialisierung ist die Generalisierungsbeziehung zu

der Klasse CommonMetaData daran zu erkennen, dass das Element Test-

fallgruppe die Attribute der Vater-Klasse CommonMetaData besitzt. Ein

Beispiel dafur ist das Attribut Status, welches mit dem Wert spezifiziert

instanziiert ist. Wie an dem Element Testfallgruppe ersichtlich wird, kann

ein Element auch direkt mit der Zeichenfolge (.../>) abgeschlossen wer-

den, siehe Zeile 10 des Listings 2.1. Die durch die Aggregationsbeziehungen

vorgegebene Hierarchie des Klassendiagramms spiegelt sich in der XML-

Serialisierung durch die Schachtelung der Elemente wieder.

2.4.3. Generative Programmierung

Unter dem Oberbegriff Generative Programmierung konnen alle Ansatze

zusammengefasst werden, welche es ermoglichen, aus Modellen Code zu

generieren [53].

2.4.3.1. Model Driven Architecture

Unter dem Stichwort Model Driven Architecture (MDA) entwickelt die Ob-

ject Management Group (OMG) einen Standard, welcher eine offene und

interoperable Losung der generativen Programmierung zum Ziel hat. Der

Standard sieht eine klare Trennung zwischen der funktionalen Sicht auf

die Software und der technischen Realisierung in Form eines ausfuhrbaren

Implementierungscodes vor. Die Funktionalitat der Software wird in dem

Platform Independent Model (PIM) beschrieben, welches durch Transfor-

mation in das Platform Specific Model (PSM) uberfuhrt werden kann. In-

nerhalb der MDA werden zwei wesentliche Transformationsarten definiert:

1. Modell-zu-Modell Transformation (M2M)

2. Modell-zu-Code Transformation (M2Code)

In der Meta-Object-Facility (MOF) wird eine Metadatenarchitektur defi-

niert, welche die technologische Grundlage fur Transformationen darstellt.

Innerhalb der MOF existieren vier Ebenen, welche in Bild 2.4 visualisiert

sind.

34

M3: Meta-Meta-Modell

M2: Meta-Modell

M1: Modell

M0: Objekte der Realität

ist Instanz von

beschreibt

ist Instanz von

beschreibt

ist Instanz von

beschreibt

beschreibtist Instanz von

Dokument:

Testbibliothek

1 <?xml version="1.0" encoding="UTF-8"?>2 <test:Testbibliothek 3 xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" 4 xmlns:test="testspezifikation" Name="Funktionstest">5 <Testspezifikation Name="cDruckRegler" Version="1.0"...

Bild 2.5

Bild 2.3

Listing 2.1

Bild 2.4.: Die vier Ebenen der MOF werden anhand des bereits eingefuhr-ten Beispiels des Klassendiagramms und des im folgenden be-schriebenen EMF-Meta-Modells dargestellt.

Die Ebene M3 ist das Meta-Meta-Modell. Dieses stellt die Konstruktions-

elemente fur die Ebene M2, das Meta-Modell, dar. Basierend auf dem Meta-

Modell werden in der Ebene M1 Modellelemente aufgebaut. Diese repra-

sentieren Objekte aus der realen Welt, welche in der Ebene M0 dargestellt

sind.

2.4.3.2. Model Driven Software Development

Die Bausteine der MDA befinden sich noch in der Standardisierungsphase.

Unter dem Begriff Model Driven Software Development (MDSD) werden

bereits verfugbare Adaptionen dieser Konzepte zusammengefasst. So stellt

das Eclipse Modeling Framework (EMF) [50] in Zusammenhang mit open

Architecture Ware (oAW) [26] eine solche Adaption dar. Die Modellierung

35

erfolgt dabei basierend auf dem EMF, die Transformationen werden durch

oAW realisiert.

Basierend auf dieser Technologie wird das bereits eingefuhrte Konzept der

MOF erlautert.

M3: Das Meta-Meta-Modell In Bild 2.5 ist das dem EMF zugrunde

liegende vereinfachte Meta-Meta-Modell dargestellt.

Bild 2.5.: Vereinfachtes Meta-Meta Modell des EMF.

Im EMF tragt es den Namen ecore. Es ist selbst aus ecore-Bausteinen auf-

gebaut. Innerhalb des Modells wird die Klasse EClass definiert, welche die

Klassen EAttribute und EReference aggregiert. Die Klasse EReference kann

wiederum auf eine EClass referenzieren. Attribute, welche durch die Klas-

se EAttribute abgebildet werden konnen, verweisen auf einen Datentyp,

welcher durch die Klasse EDataType dargestellt wird. Durch die Referenz

eSuperTypes kann die Klasse EClass auf Instanzen dieser Klasse verweisen,

wodurch die Generalisierungsbeziehung dargestellt werden kann.

M2: Das Meta-Modell Aus diesen grundlegenden Strukturelementen

kann das Klassendiagramm in Bild 2.3 aufgebaut werden. Im Sinne der

MOF handelt es sich dabei um die Ebene M2, das Meta-Modell. Alle

in dem Diagramm vorhandenen Klassen sind Instanzen des Meta-Meta-

Modell-Elements EClass. Das Meta-Meta-Modell stellt also die Konstruk-

tionselemente fur das Meta-Modell zur Verfugung.

36

M1: Das Modell Durch die Elemente des Meta-Modells steht eine Infor-

mationsstrukturierungsvorlage zur Verfugung, wie die Serialisierung einer

Instanz des Klassendiagramms in Listing 2.1 zeigt.

M0: Objekte der Realitat Das Modell beschreibt ein Objekt aus der

Realitat, in Bild 2.4 ein formales Dokument, welches eine Testbibliothek

beinhaltet.

2.4.3.3. Nutzen der Vorgehensweise

Der Nutzen dieser Metadaten-Architektur besteht in der Gewahrleistung

der Interoperabilitat zwischen verschiedenen Werkzeugen, welche dieser Ar-

chitektur genugen. Dies erfolgt dadurch, dass die zu integrierenden Werk-

zeuge auf den gleichen Konstruktionselementen aufsetzen, wie die durch

das Meta-Meta-Modell vorgegebenen.

Wenn verschiedene UML Werkzeuge das der Sprache zugrundeliegende

Meta-Modell mit den gleichen Konstruktionselementen aufbauen, wird es

moglich, durch die Modell-zu-Modell Transformation Informationen aus

der Realisierung A in die Realisierung B zu uberfuhren.

Durch das Konzept der MOF entsteht ein großes Standardisierungs- und

Automatisierungspotenzial. Nach der Vermutung des Autors wird den

meisten kommenden Software-Werkzeugen die MOF zugrunde liegen. Diese

Annahme beruht zum einen auf der Tatsache, dass die Konzepte von der

OMG definiert werden, welche auch die UML und damit indirekt UML-

Werkzeuge definiert. Ferner zeigen die Adaptionen der MOF im EMF und

oAW eine verfugbare und hilfreiche praktische Anwendbarkeit auf, wodurch

die Verwendung in Software-Werkzeugen nahe liegend ist.

Das EMF wird damit beworben, UML, XML und Java miteinander zu ver-

einigen. Dies gelingt in der Entwicklungsumgebung Eclipse [6] durch die

Moglichkeit, aus *.ecore-Bausteinen ein UML-Klassendiagramm aufzubau-

en. Daraus kann dann eine Java-Implementierung des Objektmodells ge-

neriert werden, welche in XML serialisierbar ist. Ferner sind Moglichkeiten

vorgesehen, annotiertes Java zur Generierung der Implementierungsklassen

eines Objektmodells heranzuziehen oder anstelle des Klassendiagramms ein

XML-Schema zu verwenden.

37

Noch nicht alle Software-Werkzeuge verwenden die gleichen Meta-Meta-

Modelle. Trotzdem ergibt sich durch das EMF die Moglichkeit, die Mecha-

nismen der MDA zu verwenden. Dazu mussen aber Informationen aus den

zu integrierenden Software-Werkzeugen in ein EMF-Meta-Modell uberfuhrt

werden. Dazu konnen auch Technologien wie COM verwendet werden.

2.4.4. Relevanz fur den Test

Unter Berucksichtigung der bereits eingefuhrten Begriffe zeichnet sich fur

die Entwicklungslandschaft von Software fur eingebettete Systeme im Au-

tomobil folgendes Bild 2.6 ab. Um das grobe Design der Software beschrei-

UML Zustandsdiagramme

...

man.

codieren

C/C++

Assembler

MATLAB/

SIMULINK

generieren generieren

Bild 2.6.: Entwicklungslandschaft fur Steuergeratesoftware.

ben zu konnen, eignet sich die UML. Das Verhalten einzelner, fur die Rege-

lung zustandiger Komponenten lasst sich durch das fur die Domane besser

geeignete Programmsystem MATLAB/SIMULINK beschreiben. Als Resul-

tat muss in jedem Fall zunachst C bzw. C++ Code zur Verfugung stehen,

welcher durch die geeigneten Compiler in Maschinensprache ubersetzt wird.

Der C bzw. C++ Code kann dabei auf drei verschiedenen Wegen entstehen:

1. Unter Zuhilfenahme eines MATLAB/SIMULINK-basierten Codege-

nerators (TargetLink bzw. Embedded Coder) wird C-Code generiert.

2. Unter Zuhilfenahme eines geeigneten UML-Werkzeugs kann aus

UML-Diagrammen ein Teil des Codes generiert werden.

3. Das in UML vorgegebene Design wird manuell in C bzw. C++ Code

uberfuhrt.

Dabei zeigt sich der Trend zu der Verwendung einer hoheren Abstraktion

im Zusammenhang mit der generativen Softwareentwicklung. Mit der UML

38

konnen objektorientierte Programme durch verschiedene Diagrammtypen

beschrieben werden. Parallel zu der reinen physikalischen Betrachtungswei-

se durch MATLAB/SIMULINIK steht damit eine informationstechnisch

motivierte Sichtweise auf die Software zur Verfugung, welche insbesondere

die ubergeordneten Strukturen und die Architektur der Software, geeigne-

ter zu beschreiben vermag.

Im Rahmen der Entwicklung mechatronischer Systeme haben beide Sicht-

weisen ihre Daseinsberechtigung und Notwendigkeit.

Die Beschreibung dieser Entwicklungsparadigmen stellt die Basis fur die

Abstraktion der zu testenden Software dar. Fur die in dieser Arbeit ange-

strebte effizientere Testsequenzerstellung ist es relevant, die Beschreibungs-

und Entwicklungsparadigmen zu kennen, um bereits formalisierte Informa-

tionen fur den Test wieder heranzuziehen, bzw. um die Testfallerstellung

in die Entwicklungskette zu integrieren.

2.5. Potenzielle Softwarefehler

Ziel des Testens von Steuergerate-Software ist das Sicherstellen einer feh-

lerfreien Funktionalitat. Die folgende Aufzahlung soll einen Uberblick uber

typisch zu erwartende Fehlerklassen in der Software geben.

Funktionale Fehler: Da die Softwareentwickler in der Regel einen Mo-

dultest durchfuhren, kann unplausible Funktionalitat gleich gefunden

werden. Besonderes Augenmerk ist darauf zu legen, wenn die Funk-

tionalitat uber mehrere Module oder Komponenten verteilt ist. Funk-

tionale Fehler konnen aber auch bei großer Komplexitat entstehen.

Bei manueller Implementierung zustandsbasierten Verhaltens ist es

leicht moglich, den Test einer Ubergangsbedingung zu vergessen.

Berechnungs- und Genauigkeitsfehler: Diese entstehen durch die Ty-

pisierung und Skalierung von Variablen in eingebetteter Software,

welche aufgrund der Festkomma-Arithmetik notwendig ist. Die Ge-

nauigkeit von Berechnungen wird durch die definierte Auflosung der

Großen vorgegeben. Ein Beispiel hierfur ist die Definition einer Va-

riable Masse mit dem Datentyp unsigned integer 8 bit und einer

Skalierung von 256 kg/bit. Durch diese Festlegung konnen nur Mas-

39

senanderungen von 256 kg detektiert werden. Die Definition an sich

muss nicht fehlerhaft sein, im Zusammenspiel der gesamten Software

kann die Festlegung jedoch zu unerwunschtem Verhalten fuhren.

Uberlauf von Datenstrukturen: Diese Fehler entstehen, wenn die Ty-

pisierung und Skalierung von Variablen an Ubergabepunkten inner-

halb eines Moduls und uber Modul- und Komponentengrenzen hin-

weg nicht ubereinstimmen.

Typfehler beim Zugriff auf Datenstrukturen: Bei diesen sieht die

Zugriffsfunktion einen anderen Datentyp vor.

Verletzung von Echtzeitanforderungen: Diese konnen vielfaltige Ur-

sachen haben und sowohl in fehlerhafter Programmierung als auch in

der Uberlastung des Steuergerates ihre Ursache haben.

Abweichungen von spezifizierten Anforderungen: Solche Abweich-

ungen treten auf, wenn sich die Software nicht so verhalt, wie es

die Anforderungen fordern. Dabei kann das Verhalten der Software

trotzdem in sich konsistent sein und damit funktional korrekt.

2.6. Testentwurfsmethoden

us der in Abschnitt 2.2 eingefuhrten Beschreibung des Softwaretestprozes-

ses geht hervor, dass die Prozessphase Testspezifikation die entscheidende

Rolle in Bezug auf die Sicherung der Qualitat der Software spielt. Durch

den Einsatz von Testentwurfsmethoden wird festgelegt, welche Fehler prin-

zipiell gefunden werden konnen und welche Aspekte der Software getestet

werden. In der Praxis zeigt sich, dass den Softwaretestern zwar prinzipi-

ell die verschiedenen Verfahren bekannt sind, ein expliziter, systematischer

Einsatz jedoch eher die Ausnahme als die Regel darstellt.

Im Folgenden wird eine fur die Arbeit relevante Auswahl von bekannten

Testentwurfsmethoden aufgefuhrt und in statische und dynamische Me-

thoden eingeteilt. Einen Uberblick uber die Klassifizierung gibt Abbildung

2.7.

40

Kontrollflussanalyse

Testen

Strukturierte

Gruppenprüfung

Statische

Analyse White-box Testen

Code-Reviews Codierungs-

richtlinien

Metriken

Datenflussanalyse

Black-box Testen

Anweisungs-

überdeckung

Zweigüberdeckung

Pfadüberdeckung

Äquivalenz-

klassenbildung

Grenzwertanalyse

Zustandsbezogener Test

Statisches Testen Dynamisches Testen

Bild 2.7.: Klassfizierung der Testfallerstellungsmethoden.

2.6.1. Statische Testentwurfsmethoden

Bei den statischen Testentwurfsmethoden wird das Testobjekt, in diesem

Fall der Quellcode des Programms, nicht ausgefuhrt. Es werden zwei Ka-

tegorien unterschieden: Die Strukturierte Gruppenprufung und die Stati-

sche Analyse. Zu der Kategorie der Strukturierten Gruppenprufung geho-

ren die Code-Reviews. Diese vermogen unter Zuhilfenahme von Review-

Fragestellungen, die haufig aus dem Erfahrungswissen der Tester und Ent-

wickler schriftlich gesammelt werden, schon einige Fehler aufzudecken. Ins-

besondere sind dies Fehler in Funktionalitat, die uber die gesamte Software

verteilt ist. Ein Beispiel fur eine Fragestellung ist:”Was passiert wenn in

der Situation X ein Reset des Steuergerates ausgefuhrt wird?“

In der Kategorie der Statischen Analyse wird der Quellcode formalen Fra-

gestellungen unterzogen:

Codierungsrichtlinien: Sie stellen eine Sammlung von Regeln dar, ge-

gen welche der Quellcode gepruft werden kann. So gibt es fur die

Erstellung von C-Code die MISRA-C Richtlinien [12]. Diese Samm-

lung von Gestaltungsrichtlinien fur den Quellcode wurden aus Er-

41

fahrungen gewonnen. Neben offiziellen Standards sind haufig auch

firmenspezifische Richtlinien zu finden.

Metriken: Durch Software-Metriken werden eine Reihe von Maßen defi-

niert. Es gibt Metriken, welche die Dichte der Kommentare beschrei-

ben bis hin zu Komplexitatsmaßen, wie sie durch die Zyklomati-

sche Zahl definiert werden. Einen guten Uberblick zu dem Thema

liefert [25].

Kontroll- und Datenflussanalyse: Durch das statische Nachvollziehen

der Kontroll- und Datenflusse innerhalb der Software konnen bereits

einige Fehler aufgedeckt werden. Fur diese Analysen stehen mittler-

weile Werkzeuge zur Verfugung, wie Polyspace der Firma The Ma-

thWorks oder Coverity Prevent der Firma Coverity.

2.6.2. Dynamische Testentwurfsmethoden

Die Klassifizierung der dynamischen Testverfahren erfolgt anhand der fur

die Testfallauswahl zugrundegelegten Sicht auf das Testobjekt. Dies soll

Abbildung 2.8 verdeutlichen. Bei den white-box Verfahren kann der Tester

IF

IF

DO

ENDI

F

ENDIF

WHILEBlack-Box

Grey-Box

White-BoxTestobjekt

Testrahmen

Bild 2.8.: Verschiedene Sichten auf das Testobjekt, als Grundlage fur dieTestfallerstellung.

den Quellcode der zu testenden Software einsehen. Es wird damit moglich,

anhand der Struktur der Software Testfalle zu bestimmen, welche gezielt

verschiedene Aspekte der Software stimulieren. Im Rahmen der black-box

Verfahren sind dem Tester nur die Anforderungen an die Software bekannt.

Dies ist die einzige Referenz gegen welche das Verhalten der Software be-

wertet werden kann und welches als Grundlage fur die Testfallerstellung

dient. Der Begriff grey-box Testverfahren stammt aus der testgetriebenen

42

Entwicklung, wie sie beispielsweise in [55] publiziert wird. Der grey-box

Test hat mit dem white-box Test gemeinsam, dass er von dem Entwickler

geschrieben wird. Mit dem black-box Test besteht die Gemeinsamkeit, dass

die Interna der Software zum Zeitpunkt der Testerstellung nicht bekannt

sind, da der Test vor der Software erstellt wird.

Die white-box Testverfahren werden haufig im Modultest eingesetzt. Je

komplexer das Testobjekt wird, desto weniger ubersichtlich werden die Ver-

fahren. In der Praxis hat es sich bewahrt, mit Hilfe der black-box Testver-

fahren Stimuli fur das Testobjekt zu bestimmen und durch den werkzeug-

gestutzten Einsatz von white-box Testverfahren nachzuweisen, zu welcher

Code-Uberdeckung diese Stimuli fuhren. Dieses Vorgehen stellt einen guten

Kompromiss dar. Bei einer reinen black-box Betrachtung des Testobjekts

lasst sich zwar nachweisen, dass das Testobjekt seinen Anforderungen ge-

nugt, es kann jedoch nicht festgestellt werden, ob es unbenutzten Imple-

mentierungscode gibt, oder warum es bei der Eingabe bestimmter Werte

zu einem Absturz bzw. Verklemmen des Testobjekts kommt. Auf der an-

deren Seite besteht bei der reinen Erstellung der Testfalle mit white-box

Verfahren die Gefahr, Anforderungen nicht implementiert zu haben und

dies aufgrund der rein codezentrierten Betrachtungsweise nicht zu bemer-

ken. Die white-box Testverfahren haben den großen Vorteil, dass durch die

Messung der Codeuberdeckung nach den jeweiligen Kriterien ein quantifi-

zierbares Testergebnis erzielt wird.

2.6.3. White-box Testentwurfsmethoden

Den white-box Testentwurfsmethoden liegt die Kenntnis der Struktur der

Software zugrunde. Aus dieser Kenntnis leiten sich Kriterien fur die Uber-

deckungsmessung ab.

2.6.3.1. Kontrollflussbezogene Kriterien

Anhand des in Bild 2.9 dargestellten Kontrollflussgraphen einer Software

werden die kontrollflussbezogenen Kriterien erlautert [46,52]. Der Kontroll-

flussgraph ist dabei folgendermaßen definiert:

43

Definition 2.1 (Kontrollflussgraph) Der Kontrollflussgraph eines

Programms ist ein gerichteter Graph.

Knoten: Den Knoten des Graphen sind Anweisungen zugeordnet. Es kon-

nen einem Knoten ganze Anweisungsfolgen, die keine bedingten An-

weisungen enthalten, zugeordnet sein. Das komplette Entscheidungs-

pradikat einer bedingten Anweisung ist dagegen einem sogenannten

Entscheidungsknoten zugeordnet, wobei fur jeden Ausgang der

Entscheidung eine Kante zu einem Nachfolgerknoten existiert, die

mit true bzw. false markiert ist. Um Initialisierungsvorgange model-

lieren zu konnen (z.B. Parameterubergabe bei Prozeduren), enthalt

ein Kontrollflussgraph nur einen Knoten (genannt: Anfangsknoten),

der keinen Vorgangerknoten hat und auch nur eine ausgehende Kan-

te, genannt Anfangskante, besitzt. Außerdem soll ein Kontrollfluss-

graph nur einen Knoten, genannt Endknoten, enthalten, der keinen

Nachfolger hat.

Kanten: Die Kanten stellen die Verbindungen zwischen Anweisungen und

Anweisungsnachfolgern dar.

IF

IF

DO

ENDIF

ENDIF

WHILE

a

b

c

d

e

f

g

h

i

Legende

Knoten, Anweisung

Kante, Kontrollfluss

Benennung der Kantenn

Bild 2.9.: Kontrollflussgraph zur Verdeutlichung der Uberdeckungskrite-rien.

Anweisungsuberdeckung (C0): Eine vollstandige Uberdeckung aller

Anweisungen kann in dem in Bild 2.9 dargestellten Beispiel schon

mit einem Testfall { a, b, f, g, h, d, e } erreicht werden. Konnen

Anweisungen nicht ausgefuhrt werden, so kann dies ein Hinweis auf

nicht erreichbaren Programmtext sein.

44

Zweiguberdeckung (C1): Ziel dieses Kriteriums ist es, die Uberdeckung

aller Kanten des Kontrollflussgraphen zu erzielen. Anweisungsfreie

Zweige einer Bedingung mussen zur Erreichung der vollstandigen

Zweiguberdeckung durchlaufen werden. Die Zweiguberdeckung stellt

damit ein starkeres Kriterium als die Anweisungsuberdeckung dar.

Einfache Bedingungsuberdeckung (C2) : Setzt sich eine Bedingung

aus mehreren logisch verknupften Teilbedingungen zusammen, so ist

das Ziel der einfachen Bedingungsuberdeckung, dass jede atomare

Teilbedingung sowohl den Wert wahr als auch falsch annimmt. Ei-

ne atomare Teilbedingung ist dabei dadurch definiert, dass sie keine

Operatoren, wie AND, OR oder NOT, sondern hochstens Relatio-

nen wie ≤ oder = enthalt. Besteht eine Bedingung aus mehreren

atomaren Teilbedingungen, kann es bei der einfachen Bedingungs-

uberdeckung dazu kommen, dass die Gesamtbedingung immer den

gleichen Wert annimmt, damit ist sie ein schwacheres Kriterium als

die Zweigabdeckung.

Mehrfache Bedingungsuberdeckung (C3): Bei der Mehrfachbedin-

gungsuberdeckung wird gefordert, dass alle Kombinationen der

Wahrheitswerte der atomaren Teilbedingungen berucksichtigt wer-

den. Damit wird die Gesamtbedingung mindestens einmal wahr und

falsch.

Minimale Mehrfachbedingungsuberdeckung: Da alle Kombinatio-

nen in der Praxis oft nicht immer erreicht werden konnen und die

Anzahl der Kombinationen 2n bei n Teilbedingungen betragt, wur-

de die minimale Mehrfachbedingungsuberdeckung eingefuhrt, welche

nur noch die Kombinationen fordert, welche die Gesamtbedingung

mindestens einmal zu wahr und einmal zu falsch werden lassen kon-

nen.

Pfaduberdeckung (C4): Die Pfaduberdeckung fordert die Ausfuhrung

aller unterschiedlichen Pfade durch ein Testobjekt, dies bedeutet,

dass auch Schleifen vollstandig durchlaufen werden mussen.

45

2.6.3.2. Datenflussbezogene Kriterien

Dem datenflussbezogenen Testentwurf liegt der Gedanke zugrunde, dass

eine Anweisung auch deshalb falsch sein kann, weil die innerhalb der Be-

rechnung verwendeten Variablen falsch initialisiert wurden oder weil sie

falsche Werte referenzieren. Zur Erlauterung der Kriterien wird der Daten-

flussgraph definiert [46]:

Definition 2.2 (Datenflussgraph) Ein Datenflussgraph ist ein Kon-

trollflussgraph, bei dem jedem Knoten k die Mengen DEF(k), UN-

DEF(k) und REF(k) zugeordnet sind.

DEF(k) ist die Menge der Variablen x, fur welche die Anweisungsfolge

f , die zum Knoten k gehort 4, der Variablen x einen Wert zuweist,

der nicht anschließend in f in einen undefinierten Zustand uberfuhrt

wird.

UNDEF(k) ist die Menge der Variablen x, fur welche die Anweisungsfol-

ge f , die zum Knoten k gehort, die Variable x in einen undefinierten

Zustand uberfuhrt, ohne x anschließend in f neu zu definieren.

REF(k) ist die Menge der Variablen x, fur welche die Anweisungsfolge

f , die zum Knoten k gehort, die Variable x referenziert, ohne dass

x vorher in f in einen undefinierten Zustand uberfuhrt wird. (Da-

bei wird generell vorausgesetzt, dass innerhalb eines Knotens k kein

lokaler Datenfluss vorkommt. Andernfalls ist die Anweisungsfolge so

auf zwei oder mehrere Knoten aufzuteilen, dass dieser Datenfluss in-

nerhalb eines Knotens eliminiert wird.)

Basierend auf dem Datenflussgraphen werden wiederum verschiedene Uber-

deckungskriterien definiert: Beispiele dafur sind Testsuiten, welche den Kri-

terien Alle Definitionen oder Alle Referenzen genugen.

2.6.3.3. Bewertung der white-box Testentwurfsmethoden

Die Effektivitat der white-box Testentwurfsmethoden lasst sich nach [28]

grob quantifizieren: Kontrollflussorientiertes Testen erkennt 85% der Feh-

4Es kann sich - je nach Abstraktionsgrad des Kontrollflussgraphen - um eine oder mehrere sequenziellauszufuhrende Anweisungen handeln, die zum Knoten k gehoren.

46

ler, datenflussbezogenes Testen deckt 70% der Fehler auf, ausdrucks- und

anweisungsbezogenes Testen5 erkennt 41% der Fehler. In den zugrunde lie-

genden Untersuchungen werden jedoch nicht alle Kriterien einer Testklasse

(bspw. Kontrollfluss) verwendet, so dass das Ergebnis mit Vorsicht zu be-

handeln ist.

Dennoch stellen solche Aussagen die Grundlage dafur dar, dass in der Re-

gel die kontrollflussorientierten Kriterien verwendet und gelehrt werden.

Im Zusammenhang mit objektorientiert programmierter Software gewin-

nen die datenflussorientierten Kriterien jedoch wieder an Relevanz. Bei

objektorientierter Software ist eine Kontrollflussuberdeckung fur die ein-

zelnen Methoden oft mit wenig Aufwand zu erreichen, da die Methoden in

der Regel nicht komplex verfasst werden. Der vorrangig zu testende Aspekt

ist hier das Zusammenspiel der Methoden [52], welche um die gemeinsam

genutzen Daten, die Attribute, aufgebaut sind. Es wird angenommen, dass

ein datenflussorientiert durchgefuhrter Test von Klassen erheblich bessere

Aussagen liefert als ein kontrollflussorientierter Klassentest. Derzeit gibt es

jedoch kaum Werkzeuge auf dem Markt, welche den datenflussorientierten

Klassentest unterstutzen [35]. Es ist daher naheliegend, den Datenfluss der

Software mit einem statischen Datenflussanalysewerkzeug zu untersuchen.

Partielle Ordnung der Kriterien Um die Auswahl eines Uberde-

ckungskriteriums zu ermoglichen, gibt es Untersuchungen, welches der an-

gegebenen Kriterien welche anderen inkludiert. Fur die kontrollflussorien-

tierten Kriterien ist diese Ordnung in Form eines gerichteten Graphen in

Bild 2.10 dargestellt. Der gerichtete Verweis von einem Kriterium auf ein

anderes ist so zu deuten, dass das Kriterium, von welchem die gerichtete

Kante ausgeht, das folgende beinhaltet.

Zusammenfassung Eine Testsuite, welche basierend auf dem Kontroll-

fluss eines Programms erstellt wird, hat eine hohere Fehlerfindungswahr-

scheinlichkeit als eine auf dem Datenfluss basierende. Innerhalb der kon-

trollflussbezogenen Testentwurfsmethoden hat das Kriterium der Pfad-

uberdeckung das hochste Fehlerfindungspotenzial, bedingt aber gleichzeitig

den großten Aufwand fur die Generierung und Ausfuhrung einer solchen

5Dieses Kriterium wird an dieser Stelle nicht weiter erlautert, naheres siehe [46]

47

Anweisungs-

überdeckung (C0)

Zweig-

überdeckung (C1)

Einfache

Bedingungs-

überdeckung (C2)

Mehrfache

Bedingungs-

überdeckung (C3)

Pfad-

überdeckung (C4)

Minimale Mehrfach-

Bedingungs-

überdeckung

Anweisungsüberdeckung: 18% - 41%

Zweigüberdeckung: 16% - 92%

Pfadüberdeckung: das dreifache der Zweigüberdeckung (62% - 64% statt 21% [How 76,

How78b]

Prozentzahlen der gefundenen Fehler – Von Riedemann mit

Literaturstellen belegt

Bild 2.10.: Ordnungsgraph der kontrollflussbasierten white-box Testent-wurfsverfahren.

Testsuite. Einen guten Kompromiss stellt die Zweiguberdeckung dar, da

sie ein großes Fehleraufdeckungspotenzial bei einem vertretbaren Aufwand

hat.

Die Fehler der Klasse Abweichungen von spezifizierten Anforderungen kon-

nen prinzipiell nicht mit den white-box Testentwurfsmethoden gefunden

werden. Im Folgenden werden einige dieser Fehler aufgezahlt:

• Abweichungen von der Spezifikation.

• Fehler bei extremen oder speziellen Werten, die fur die Funktion wich-

tig sind.

• Fehlende Pfade bzw. Funktionen.

• Schnittstellenfehler. Diese Fehler bedurfen der Referenz durch die

Anforderungen oder das Design der Nachbarkomponenten.

• Initialisierungsfehler.

2.6.4. Black-box Testentwurfsmethoden

Testentwurfsmethoden, bei denen die Kenntnis der Implementierung nicht

zugrunde gelegt wird, werden black-box Testentwurfsmethoden genannt.

48

Im Folgenden werden die in der Ubersicht aus Bild 2.7 aufgefuhrten Test-

entwurfsmethoden naher erlautert.

2.6.4.1. Aquivalenzklassenbildung und Grenzwertanalyse

Mit Hilfe der Aquivalenzklassenbildung und Grenzwertanalyse wird der

Eingabedatenraum fur das System Under Test (SUT) strukturiert. Eine

Aquivalenzklasse ist dadurch gekennzeichnet, dass das Systemverhalten fur

diesen Eingabebereich gleich bleibt. Grenzwerte kennzeichnen den Uber-

gang zwischen Aquivalenzklassen. Als Uberbegriff fur Aquivalenzklassen

und Grenzwerte wird im Folgenden die Bezeichnung Klassifikation ver-

wendet. Im Kontext funktionaler Aquivalenzklassen kann dabei ein im

Softwaretest vorgegebener zeitlicher Stimulationsverlauf beispielsweise in

die Klassen konstant und dynamisch aufgeteilt werden. Bezogen auf den

Test einer Funktion r = f(x, y) im Modultest kann der Datenraum der

Ubergabeparameter mit Klassifikationen strukturiert werden, wie das Bild

2.11 darstellt. Konkrete Datenpunkte (x, y) fur den Test sind somit entwe-

r = f(x,y)

x

y

r = f(x,y)

y

[Äquivalenzklasse x1]

[Äquivalenzklasse y1]

[Grenzwert yn]

[Grenzwert xm]

[Datenpunkte]

Bild 2.11.: Aquivalenzklassen und Grenzwerte.

der Reprasentanten einer Aquivalenzklasse, die Auswahl eines Grenzwer-

tes oder beides. Es ist zu beachten, dass fur jeden gewahlten Datenpunkt

(x, y) auch ein erwarteter Ruckgabewert r′ angegeben werden muss, damit

ein Test der Form r′ == f(x, y)6 moglich ist.

6Der Operator == ist der Sprache C entnommen und pruft, ob der Wert auf der linken Seite desOperators dem auf der rechten Seite entspricht.

49

2.6.4.2. Auswahlstrategien

Die Auswahl konkreter Eingabe-Datenpunkte ist eine im Rahmen des Tes-

tens zentrale Fragestellung. Im Zusammenhang mit Kombinatorik wird die-

se Frage auch in anderen Zusammenhangen gestellt, beispielsweise in der

statistischen Versuchsplanung [43]. Um bei der allgemeinen Kombinatorik

zu bleiben, wird die folgende Nomenklatur verwendet. Die Eingangsgroßen

des SUT werden als Faktoren F bezeichnet.

F = {F1, . . . , Fk} card(F) = k (2.1)

Die verschiedenen Klassifikationen der Faktoren werden als Level l bezeich-

net. Jedem Faktor ist ein Menge von Leveln L zugeordnet,

F ⊆ F× L ⇒ {F1, L1}, {F2, L2}, . . . {Fk, Lk}, (2.2)

fur welche gilt:

Li = {li,1, . . . , li,ni} card(Li) = ni (2.3)

In Bild 2.12 ist ein SUT mit k = 3 Faktoren dargestellt, welche jeweils

in drei Level unterteilt sind (n1 = n2 = n3 = 3). Der Eingabedatenraum

des SUT wird dadurch in 27 Datenpunkte unterteilt. Es stellt sich nun die

Fehlerregion Einfacher Fehler

C

Level A2 Level A3

Level B2

Level A1

Level C2

Level C3

Datenraum

des SUT

A

BLegende:

Orthogonales Feld

Minimale Auswahl

Punkte liegen

übereinander

Bild 2.12.: Visualisierung der Kombinatorik im Datenraum [43].

Frage, wie die Datenpunkte fur den Test ausgewahlt werden sollen. Um die

Relevanz dieser Auswahl zu veranschaulichen, stellt das Bild eine Fehler-

region dar, welche eine Fehlerklasse visualisiert, die prinzipiell durch die

50

Auswahl verschiedener Datenpunkte gefunden werden kann. Zudem ist ein

einfacher Fehler dargestellt, dass heißt er kann nur mit einer einzigen Ein-

gabedatenkombination gefunden werden. Es wird deutlich, dass die Menge

der ausgewahlten Datenpunkte daruber entscheidet, wie wahrscheinlich es

wird, Fehler zu finden. Schon eine Untermenge der moglichen Datenpunkte

vermag eine Fehlerregion aufzudecken. Das Auffinden des einfachen Fehlers

kann jedoch entweder durch Gluck oder Erfahrung erfolgen oder durch die

vollstandige Auswahl aller moglichen Datenpunkte fur den Test7. Ferner

wird die Relevanz der Auswahl der Klassifikationen ersichtlich. Wenn der

Datenraum zu grob strukturiert wird, so ist der einfache Fehler ebenfalls

nicht zu finden.

Im Folgenden werden verschiedene Auswahlstrategien vorgestellt:

1. Orthogonale Felder

2. Minimale Auswahl

3. Maximale Auswahl

4. Weitere Losungen

Orthogonale Felder Ein orthogonales Feld ist eine spezielle Matrix, de-

ren Auswahl konkreter Eingabe-Datenpunkte dazu fuhrt, dass immer zwei

Eingangsgroßen paarweise voneinander unabhangig sind. Dies fuhrt also

dazu, dass immer der Einfluss zweier Faktoren auf das SUT getestet wird.

Im Rahmen des Testens ist diese Annahme relevant, da davon ausgegangen

wird, dass die meisten Fehler in Software in einer paarweisen Interaktion

auftreten [32].

Bestimmung orthogonaler Felder In Anlehnung an die Ausfuhrungen

in [56] wird ein allgemeines orthogonales Feld folgendermaßen definiert:

O(c, k, n, t) (2.4)

Dabei haben die Ubergabeparameter folgende Bedeutung:

7Da die Datenraume in der Praxis haufig nicht so uberschaubar sind, ist es aus zeitlichen Grunden nichtimmer moglich, vollstandig zu testen.

51

c: Anzahl der Eingabe-Datenpunkte. Dies entspricht der Anzahl der Zei-

len.

k: Anzahl der Faktoren. Dies entspricht der Anzahl der Spalten.

n: Anzahl der Level, es gilt: n = max(ni).

t: Starke der Matrix. Alle t-fachen Kombinationen kommen gleich oft vor.

In jeder c× t Untermatrix kommen alle moglichen nt t-Tupel gleich oft

vor.

Ein orthogonales Feld der Starke t = 2, welches der Auswahl paarweiser

Kombinationen entspricht, lasst sich nach dem Algorithmus von Bose [18]

berechnen:

O(n2, n + 1, n, t = 2) kurz: O(n2, n + 1, n) (2.5)

Die Anzahl der Level n muss dabei eine ganzzahlige (m) Potenz einer

Primzahl (p) sein.

n = pm (2.6)

Die einzelnen Elemente Oij(n2, n + 1, n) der Matrix mit i = 1, . . . , n2 und

j = 1, . . . , n + 1 werden dabei folgendermaßen bestimmt. Sei

u =

⌊(i− 1)

n

⌋+ 1 und w = ((i− 1) mod n) + 1 (2.7)

dann gilt:

Oi1 = u und Oi2 = w (2.8)

Die ubrigen Elemente der Matrix berechnen sich zu:

Oij(n2, n + 1, n) = q (2.9)

Fur j > 2 ist q so zu bestimmen, dass unter Verwendung der Arithmetik

des Galois-Feldes (GF) der Ordnung n

GF (n) = {x0, x1, . . . , xn} mit x0 = 0 und x1 = 1 (2.10)

52

und der Galois-Feld Arithmetik

xq = xj−2 · xu + xw (2.11)

gilt.

Die Berechnung des benotigten Galois-Feldes ist in [27] beschrieben. Durch

diesen Algorithmus werden orthogonale Felder mit folgenden Eigenschaften

erzeugt:

• Die erste Zeile besteht aus lauter Einsen.

• Die ersten n Zeileneintrage gleichen den Zeilenindizes, mit Ausnahme

der ersten Spalte.

• Die erste Spalte besteht aus n Einsen, n Zweien usw.

• Jede Spalte der Matrix, mit Ausnahme der ersten, besteht aus Per-

mutationen von (1, . . . , n).

Voraussetzungen fur den Einsatz orthogonaler Felder Aus der Be-

rechnungsvorschrift fur ein orthogonales Feld mit paarweiser Uberdeckung,

wie es in Gleichung (2.5) beschrieben ist, zusammen mit der Vorgabe in

Gleichung (2.6), dass die Anzahl der diskreten Auspragungen eines Faktors

(Level) einer ganzzahligen Potenz einer Primzahl entsprechen muss, wird

ersichtlich, dass nicht fur jeden Anwendungsfall ein passendes orthogona-

les Feld bestimmt werden kann. Um diesem Umstand Rechnung zu tragen,

gibt es verschiedene Ansatze.

In [42] werden Techniken beschrieben, wie ein orthogonales Feld an einen

konkreten Anwendungsfall mit einer vorgegebenen Anzahl von Parametern

und diskreten Auspragungen angepasst werden kann. Dabei wird auf eine

Tabelle von bereits vorbestimmten orthogonalen Feldern zuruckgegriffen.

Wenn sich Faktoren gegenseitig beeinflussen, kann es sein, dass der Effekt

der Interaktion zweier Faktoren den Effekt eines anderen Faktors uber-

deckt. Dazu ist fur jedes orthogonale Feld eine Interaktionstabelle spezifi-

ziert, welche angibt, welche Spalte von welchen Faktorkombinationen uber-

deckt wird. Auszuge aus dieser Interaktionstabelle konnen durch lineare

Graphen dargestellt werden. Der Einsatz orthogonaler Felder zur Auswahl

von Eingabe-Datenpunkten fur den Test verspricht einen methodischen

53

Vorteil durch die mathematische Eigenschaft, paarweise Kombinationen

von Datenpunkten zu untersuchen. Praktisch zeigen die vorangegangenen

Ausfuhrungen jedoch, dass ein orthogonales Feld nicht ohne Fachwissen fur

eine Problemstellung adaptiert werden kann. Verschiedene Ansatze einer

Realisierung dieser Testvorgehensweise sind unter [2] publiziert. Ein mog-

licher Ansatz wird von [56] durch die Implementierung des Werkzeuges

T-Config bereitgestellt. Die von Williams vorgeschlagene Vorgehenswei-

se ermoglicht es, die Auffindung eines geeigneten orthogonalen Feldes auf

zwei Eingabeparameter zu reduzieren: Die Anzahl der Faktoren (k) und

ihrer diskreten Auspragungen (n). Weist das wirkliche Problem eine unter-

schiedliche Anzahl von Auspragungen ni auf, muss die großte Auspragung

i = max(ni) als Grundlage fur die Auswahl eines passenden orthogona-

len Feldes herangezogen werden. Die damit uberbestimmten Auspragun-

gen konnen beliebig vergeben werden, durfen aber nicht geloscht werden,

da sonst die Orthogonalitatseigenschaft des Feldes verloren geht.

Fur den Fall, dass die Anzahl der Faktoren und Auspragungen nicht den

Anforderungen aus den Gleichungen (2.5) und (2.6) genugen, wird eine

Uberdeckungsmatrix O′ berechnet, welche annahernd die mathematischen

Eigenschaften eines orthogonalen Feldes erfullt.

Faktor A Faktor B Faktor C

Level A1 Level A2 Level A3 Level B1 Level B2 Level B3 Level C1 Level C2 Level C3

SUT

Datenpunkt 1

Datenpunkt 2

Datenpunkt 3

Datenpunkt 4

Datenpunkt 5

Datenpunkt 6

Datenpunkt 7

Datenpunkt 8

Datenpunkt 9

123

312

231

213

132

321

333

222

111

3

3

3

2

2

2

1

1

1

O’(9,3,3,2)

O(9,4,3,2)

Bild 2.13.: Darstellung der Auswahl von Eingabe-Datenpunkten durch einreduziertes orthogonales Feld O′ nach [56].

54

In Bild 2.13 wird dies anhand des mit Bild 2.12 eingefuhrten Beispiels

verdeutlicht, in welchem jeder der drei Faktoren (k=3) drei Level (n=3)

besitzt. Aus Gleichung (2.5) resultiert, dass sich fur das Problem nur

das orthogonale Feld O(9, 4, 3, 2) bestimmen lasst. Das Werkzeug T-

Config berechnet fur diese Konfiguration das reduzierte orthogonale Feld

O′(9, 3, 3, 2). Die durch das reduzierte orthogonale Feld O′ vorgegebene

Auswahlmatrix ist dabei in einer Klassifikationsbaumdarstellung visuali-

siert. Die Zahlen in der Matrix geben den Level an, die Spalte steht fur

den Faktor. Die Orthogonalitatseigenschaft der Matrix ist dadurch gekenn-

zeichnet, dass jeder Level in jedem Spaltenpaar vorkommt und zwar gleich

oft. Diese Ausgleichseigenschaft ist mathematisch dafur hinreichend, dass

jeweils zwei Spaltenvektoren im kombinatorischen Sinne voneinander linear

unabhangig sind, wodurch der Einfluss dieser beiden Faktoren voneinan-

der unabhangig untersucht wird. Um den durch das reduzierte orthogonale

Feld O′ untersuchten Datenraum zu kennzeichnen, sind die Datenpunkte

der Matrix in das Bild 2.12 eingetragen.

Minimale Auswahl: Bei der minimalen Auswahl wird jeder Level aus

jedem Faktor mindestens einmal ausgewahlt. Unter Berucksichtigung der

Gleichungen (2.1) und (2.3), sowie der Beziehung n = max(ni) wird die

Auswahlmatrix durch die Gleichung (2.12) bestimmt.

Oi,j =

{lj,i i = 1(1)n, j = 1(1)k

lj,1 Wenn nj < i(2.12)

In der Gleichung (2.12) symbolisiert die Notation i = 1(1)n, j = 1(1)k eine

geschachtelte Schleife der Tiefe zwei. In Bild 2.14 ist die minimale Aus-

wahlmatrix fur das aufgefuhrte Beispiel mit den drei Faktoren dargestellt.

Die drei ausgewahlten Datenpunkte sind schraffiert in den Datenraum des

SUT in Bild 2.12 eingetragen. Alle Datenpunkte wurden auch durch das

reduzierte orthogonale Feld ausgewahlt.

Vollstandige Auswahl: Bei der vollstandigen Auswahl werden alle

Punkte des Datenraums ausgewahlt. Die Auswahlmatrix wird zeilenwei-

se nach der Gleichung (2.13) aufgebaut, wobei die Anzahl der Zeilen c dem

55

Faktor A Faktor B Faktor C

Level A1 Level A2 Level A3 Level B1 Level B2 Level B3 Level C1 Level C2 Level C3

SUT

Datenpunkt 1

Datenpunkt 2

Datenpunkt 3

Bild 2.14.: Visualisierung der minimalen Auswahlstrategie.

Produkt der Level-Anzahlen ni der Faktoren entspricht.

O(c,:) = [l1,h, . . . , lk,j] mit

c = 1(1)∏k

i=1 ni

h = 1(1) ni, · · · , j = 1(1) nk

(2.13)

In der Darstellung gilt, dass die Indizes der Matrix den Index der Zeile

und der Spalte eines Matrix-Elements reprasentieren. Der Operator : steht

fur alle Elemente einer Dimension. Die Notation (c,:) beschreibt damit alle

Elemente in der c-ten Zeile der Matrix. Die Syntax h = 1(1) ni, · · · , j =

1(1) nk in Gleichung (2.13) symbolisiert eine geschachtelte Schleife mit der

Tiefe k. Bezogen auf das Beispiel wird die Auswahlmatrix O durch die

Gleichung (2.14) bestimmt. Die Matrix hat c = 27 Zeilen, was der Anzahl

der Datenpunkte in dem Datenraum des SUT entspricht.

O(c,:) = [lA,h, lB,i, lC,j] mit

c = 1(1) (nA · nB · nC)

h = 1(1) nA

i = 1(1) nB

j = 1(1) nC

(2.14)

Zusammenfassung Die Tabelle 2.1 fasst die vorgestellten Auswahlstra-

tegien in einem Uberblick zusammen. Von weiterem Interesse sind die ver-

schiedenen Anzahlen der durch die Strategie gewahlten Datenpunkte.

Abhangig von der Kritikalitat des SUT ist zu entscheiden, welche Aus-

wahlstrategie verwendet werden soll. Mit der maximalen Auswahl wird der

56

Orthogonales Feld O(c = n2, k = n + 1, n = max(ni))

Anzahl Datenpunkte: n2

Minimale Auswahl O(c = n = max(ni), k, n)

Anzahl Datenpunkte: n

Maximale Auswahl O(c =∏k

i=1 ni, k, n)

Anzahl Datenpunkte:∏k

i=1 ni

Tabelle 2.1.: Uberblick zu den Auswahlstrategien.

gesamte Datenraum getestet; wurden die Klassifikationen richtig gewahlt,

besteht die großte Wahrscheinlichkeit Fehler aufzudecken. Phadke, Wil-

liams und Andere berichten von guten Erfahrungen mit orthogonalen Fel-

dern. Fur die Anwendung besteht das großte Problem in der zuverlassigen

Bestimmung eines geeigneten orthogonalen Feldes. Die minimale Auswahl

kann schnell abgetestet werden, untersucht jedoch nur einen kleinen Teil

des Datenraums.

In diesem Kontext soll auf das Werkzeug CTE-XL hingewiesen werden,

welches aus den grundlegenden Arbeiten zu der Klassifikationsbaumme-

thode [29] hervorging. Die Faktoren und Level konnen hierbei manuell

in einen Klassifikationsbaum eingetragen werden. Innerhalb des Werkzeu-

ges sind ebenfalls verschiedene Auswahlstrategien implementiert, welche

im Folgenden, in Anlehnung an die beigefugte Dokumentation, aufgezahlt

werden:

Ein Element aus jedem Faktor: Von den diskreten Auspragungen der

Faktoren wird jeweils eine gewahlt.

Paarweise Kombination: Aus einer Menge von Faktoren K = {a, b, c},mit den jeweiligen diskreten Auspragungen na,b,c, werden paarweise

Kombinationen der Form k1 = (a ·b), k2 = (a ·c), k3 = (b ·c) gebildet.

Dreifache Kombination: Es wird ein der paarweisen Kombination ent-

sprechendes Prinzip angewendet. Aus einer Menge von Faktoren

K = {a, b, c, d} werden Kombinationen der Form k1 = (a · b · c),... gebildet.

n-fache Kombination: Das Prinzip wird auf das n-Fache erweitert.

Die Kombinationsregeln konnen beliebig miteinander kombiniert werden.

57

2.6.4.3. Zustandsbasierter Test

Ein großer Teil der Steuergerate-Software ist durch zustandsbasiertes Ver-

halten gekennzeichnet. Selbst kontinuierliche Regelfunktionen sind haufig

in ein ubergeordnetes diskretes Zustandsverhalten eingebunden. Aus der

Struktur dieses Zustandsdiagramms konnen Testsequenzen generiert wer-

den. In diesem Kontext wird auch haufig von modellbasiertem Testen ge-

sprochen. Die im Rahmen der vorliegenden Arbeit entwickelte Heuristik

basiert ebenfalls auf diesem Verfahren.

2.6.4.4. Erfahrungsbasierte und intuitive Testsequenzermittlung

Trotz der methodischen Testsequenzerstellung wird es immer wieder Test-

sequenzen geben, welche sich nur aus der Systemkenntnis und Erfahrung

eines Testingenieurs ableiten lassen. Um diesem Umstand Rechnung zu

tragen, wird die erfahrungsbasierte und intuitive Testsequenzermittlung

als Testentwurfsmethode aufgefuhrt.

2.7. Aufgabenstellung - Methodisches und

automatisiertes Testen

Den bisherigen Ausfuhrungen ist zu entnehmen, dass Kfz-Steuergerate-

Software hierarchisch entwickelt wird. Zunachst werden einzelne Software-

Module zu Komponenten und spater zur gesamten Software integriert, wie

es Bild 2.1 zeigt.

Der Testprozess wiederholt sich wahrend dieser Integrations- bzw. Teststu-

fen (Bild 2.2).

Die Phase der Testspezifikation ist dabei entscheidend fur die Fahigkeit

der Tests, potenzielle Fehler aufzudecken. Der Einsatz von Testentwurfs-

methoden hilft dabei, die Testspezifikation systematisch aufzubauen.

Es ist anschaulich klar, dass die Tests fur ein Modul der Software auch mit

der gesamten Software zusammenhangen. Es ist jedoch ein technologischer

Unterschied zwischen den Tests auf den verschiedenen Abstraktionsgra-

den gegeben. Inhaltlich werden ebenfalls unterschiedliche Aspekte gepruft,

58

da die Teststufen von unterschiedlichen Entwicklern mit unterschiedlichem

Hintergrundwissen durchgefuhrt werden.

Der Modultest erfolgt in der Regel in der gleichen Entwicklungsumgebung,

in der das Modul erstellt wird. Fur manuell erstellten C bzw. C++ Code ist

dies eine IDE, wie Visual Studio, fur andere Module entsprechend MAT-

LAB/SIMULINK.

Zu einer Komponente integrierte Module weisen haufig schon eine so große

Anzahl von Schnittstellen auf, dass es sich anbietet, den Test wenn moglich

im integrierten Zustand der Software durchzufuhren. Im Automobil-Umfeld

werden dazu haufig Closed-Loop-Verfahren, wie SiL oder HiL, angewendet.

Diese zeichnen sich dadurch aus, dass die zu testende Software gegen ein

Umgebungsmodell ausgefuhrt wird, wie es Bild 2.15 zeigt.

Modul 1

Modul 2Komponente 1

Komponente 2

Steuergerätesoftware

Umgebungsmodell

Modultest

Komponententest

Softwaretest

Bild 2.15.: Unterschiedliche Testabstraktionsschichten.

Das Testziel, eine korrekte Funktion der Software, bleibt dabei zwar unver-

andert, jedoch wechselt der technologische Fokus; dass heißt die Methode

der Softwarestimulation und der Zugriff auf Ein- und Ausgangsgroßen ist

heterogen.

Vor diesem Hintergrund zeigt sich, dass in der Praxis ein großer Teil der

Zeit, welche fur das Testen aufgebracht wird, in die Erstellung der Testin-

frastruktur fließen muss. Ferner konnte festgestellt werden, dass den meis-

ten Entwicklern zwar die Testentwurfsmethoden prinzipiell bekannt sind,

diese aber selten belegbar angewendet werden, da vorhandene Werkzeug-

unterstutzungen nicht immer in das Entwicklungsumfeld passen.

59

Damit ergeben sich fur die Arbeit die folgenden Ziele:

1. Es soll eine Moglichkeit gefunden werden, Testentwurfsmethoden auf

allen Teststufen technologisch wiederverwenden zu konnen.

2. Der Aufwand, die Testinfrastruktur bereitzustellen, soll reduziert

werden.

3. Die black-box Testentwurfsmethoden Zustandsbasierter Test und

Aquivalenzklassenbildung/Grenzwertanalyse sollen praktisch einge-

setzt werden.

60

3. Testframework

Um den Anforderungen aus Kapitel 2 zu genugen, wird das vorgestellte

Testframework konzipiert und implementiert [40]. Die Architektur dieses

Frameworks stellt Schnittstellen zu den im Rahmen der Entwicklung ver-

wendeten Werkzeugen bereit, um Grundinformationen fur die einzubin-

denden Testentwurfsmethoden zu erhalten. Dabei wird in Abschnitt 3.1

diskutiert, welche Informationen aus dem Entwicklungsprozess verwendet

werden konnen. Die methodisch erstellten Testfalle werden zunachst platt-

formunabhangig beschrieben. Diese Beschreibung stellt zugleich ein Kom-

munikationsmittel dar, um den Testinhalt diskutieren und austauschen zu

konnen, ohne die plattformspezifische Implementierungssprache zu verste-

hen. Ausgehend von dieser formalen Basis kann die plattformspezifische

Implementierung durch eine geeignete Transformation erfolgen. Die tech-

nologische Realisierung des Frameworks wird in Abschnitt 3.2 beschrieben.

3.1. Verwendung von Artefakten

aus dem Entwicklungsprozess

Die verwendbaren Artefakte konnen in drei Kategorien eingeteilt wer-

den: Strukturartefakte, Verhalten und Daten. In Anlehnung an die Bilder

2.2 und 2.6 konnen diese Daten hauptsachlich aus dem UML-Design und

MATLAB/SIMULINK-Modellen entnommen werden, wobei aufgrund der

Gegebenheit in dem zugrundeliegenden Projekt zunachst auf UML-Modelle

eingegangen wird.

3.1.1. Strukturartefakte

Strukturartefakte der Software sind im Software-Design bereits formal hin-

terlegt. Dabei handelt es sich um fur den Test wichtige Angaben, wie den

Aufbau einzelner Softwarekomponenten, die Angabe, welche Module vor-

handen sind und welche Ein- und Ausgabeschnittstellen diese zur Verfu-

61

gung stellen, sowie Informationen uber die Datentypen und Werteberei-

che der Schnittstellenparameter. Die Schnittstellen der Software mussen

wahrend des gesamten Entwicklungs- und Testprozesses konsistent sein,

weswegen diese durchgangig wiederverwendet werden mussen. Insbesonde-

re fur die Testfallerstellung konnen diese Schnittstelleninformationen her-

angezogen werden, um einzelne Komponenten uber die Schnittstellen zu

stimulieren. Auf diese Weise kann zwar nicht ausgeschlossen werden, dass

eine notwendige Schnittstelle nicht vorhanden ist; dies zeigt sich jedoch bei

einer durchgangigen Entwicklungskette spatestens bei der Integration.

3.1.2. Verhalten

Verhalten ist in Form von Zustandsmaschinen haufig in den Software-

Anforderungsdokumenten oder spatestens im Software-Design zu finden.

Dabei ist das Verhalten auf unterschiedlichen Detaillierungsstufen des Ent-

wicklungsprozesses beschrieben. So kann sowohl das Verhalten der Gesamt-

software durch eine Zustandsmaschine abgebildet sein, wie auch das Ver-

halten eines einzelnen Software-Moduls. In allen Fallen stellt diese formale

Beschreibung eine wertvolle Basis fur die zustandsbasierte Testsequenzer-

stellung dar. Die Verwendung der Verhaltensinformationen fur die Testfall-

erstellung wird haufig unter dem Stichwort modellbasiertes Testen publi-

ziert. In der Arbeit [44] werden verschiedene Szenarien des modellbasierten

Testens identifiziert:

1. Aus einem Modell werden sowohl der Implementierungscode, als auch

die Testfalle abgeleitet. In diesem Fall ist ein manuelles Verdict not-

wendig. Da die Testfalle auf der gleichen Basis wie der Code beruhen,

konnen automatisiert keine Fehler gefunden werden, es sei denn, der

Codegenerator arbeitet fehlerhaft.

2. Das Modell, aus welchem die Testfalle abgeleitet werden, wird durch

Reverse-Engineering aus der Implementierung der Software abgelei-

tet. Auch in diesem Fall ist ein manuelles Verdict notwendig.

3. Unabhangig von der Implementierung der Software wird ein spezi-

elles Testmodell nur als Basis fur den Test der Software aus den

Anforderungen abgeleitet. In diesem Fall ist die Unabhangigkeit der

62

generierten Testfalle gewahrt und es kann ein automatisches Ver-

dict gebildet werden.

4. Im Unterschied zum vorangegangenen Punkt wird die Software nicht

manuell erstellt, sondern ebenfalls aus einem Modell abgeleitet. Es

ist jedoch nach wie vor ein unabhangiges Testmodell vorhanden, wo-

durch das automatische Verdict weiterhin gerechtfertigt ist.

Unter Berucksichtigung der notwendigen Unabhangigkeit zwischen dem

Testmodell (Basis fur die Testfallableitung) und dem Implementierungsmo-

dell (Basis fur die Generierung der Implementierung) zeigt sich, dass ein

automatisches Verdict nur gultig ist, wenn Test- und Implementierungs-

modell voneinander unabhangig sind. Daraus folgt, dass das Verhalten in

Form einer Zustandsmaschine aus dem Entwicklungsprozess fur die Test-

fallerstellung nur verwendet werden kann, wenn sichergestellt ist, dass die

Implementierung unabhangig von dem Modell erstellt wird oder wenn ein

manuelles Verdict gebildet wird. Da das oberste Ziel die Automatisierung

ist, sollten manuelle Arbeiten jedoch vermieden werden.

3.1.3. Daten

Eingebettete Software fur ein Automobil-Steuergerat enthalt eine Vielzahl

von Daten und Parametern, welche im Entwicklungsprozess in einer for-

malen Form abgelegt werden. Die Wiederverwendung dieser Daten fur den

Test spart den erneuten Eingabeaufwand und stellt eine Grundlage fur die

Testbedatung dar.

3.2. Technologische Realisierung

In Bild 3.1 ist die architektonische und technologische Sicht auf das Fra-

mework dargestellt. Architektonisch hat das Framework drei Aufgaben zu

erfullen:

1. Bereitstellung verschiedener werkzeuggestutzter Verfahren zum Test-

entwurf.

2. Speicherung der generierten Testfalle in einer formalen Testbeschrei-

bungs-Datenstruktur.

63

Artefakte aus dem Entwicklungsprozess /

Testmodell

Werkzeuggestützte Testentwurfsmethoden

Ausführungsplattformen

Exchange.ecore

M2M

M2M

M2M

M2Text

Artefakte aus dem Entwicklungsprozess /

Testmodell

Ausführungsplattformen

Tes

tfra

mew

ork

Testentwurfsmethoden

Formale Testbeschreibung

Codegenerator

Architektonische Sicht Technologische Sicht

Tes

tfra

mew

ork

Testspezifikation.ecore Testbericht.ecore

Bild 3.1.: Technologische Realisierung des Testframeworks.

3. Bereitstellung verschiedener Codegeneratoren, um die Testinhalte

auf den verwendeten Testausfuhrungsplattformen implementieren zu

konnen.

Die technologische Realisierung des Frameworks erfolgt unter Zuhilfenah-

me der in Unterabschnitt 2.4.3 beschriebenen Konzepte der Model Driven

Architecture (MDA). Dadurch ist von vornherein eine Unabhangigkeit der

Implementierung von konkreten Werkzeugen und die Interoperabilitat zwi-

schen verschiedenen Implementierungen vorgesehen. Fur die konkrete Im-

plementierung wird das Eclipse Modeling Framework (EMF) und openAr-

chitectureWare (oAW) verwendet. Die im Rahmen der Arbeit erarbeiteten

Meta-Modelle basieren dadurch auf dem Ecore-Meta-Meta-Modell.

Um die Unabhangigkeit der Testentwurfswerkzeuge von den im Rahmen

der Entwicklung eingesetzen Werkzeuge zu erhalten, wird das Exchange-

Meta-Modell vorgesehen. Diesem kommt die Aufgabe zu, die Informationen

aus dem Entwicklungsprozess aufzunehmen und fur Testentwurfswerkzeuge

zur Verfugung zu stellen. Fur die Integration von Testentwurfswerkzeugen

stehen damit Informationen aus dem Entwicklungsprozess formal zur Ver-

fugung. Das Exchange-Meta-Modell kann nicht generisch angegeben wer-

den, aber im Zusammenhang mit der in Kapitel 5 vorgestellten Heuristik

zum Testentwurf wird eine konkrete Auspragung vorgestellt.

Die generierten Testfalle werden erneut durch M2M in eine formale Test-

beschreibung uberfuhrt. Dieses Format hat die zentrale Aufgabe, die Test-

64

inhalte von den Testausfuhrungsplattformen zu abstrahieren. Ausgehend

von dieser formalen Basis kann durch Modell-zu-Text (M2Text) Transfor-

mation plattformspezifischer Implementierungscode generiert werden. Die

M2Text hat den Vorteil, dass es sich um ein Schablonen (Template) basier-

tes Verfahren handelt. Der Großteil des zu implementierenden Codes wird

dabei in einer durch Schlusselworter angereicherten Vorlage gespeichert.

Die Transformation erganzt diese Schlusselworter mit den Daten aus der

formalen Testbeschreibung. Auf diese Weise kann der Codegenerator sehr

flexibel an verschiedene Anforderungen angepasst werden.

Ein Meta-Modell in Verbindung mit einer Transformations- und ggf. Va-

lidierungsvorschrift kann im Kontext der modellgetriebenen Softwareent-

wicklung als Domanenspezifische Sprache aufgefasst werden.

Definition 3.1 (Domanenspezifische Sprache) Eine Domain Specific

Language (DSL) nach [49] besteht aus einem Meta-Modell, welches die Syn-

tax bzw. die statische Semantik vorgibt, und einer dynamischen Semantik,

um den Konstrukten des Meta-Modells eine Bedeutung zu geben.

Innerhalb des gesamten Konzeptes kommt dem Testspezifikations-Meta-

Modell eine zentrale Bedeutung zu, auf welche im Folgenden eingegangen

wird.

3.2.1. Das Testspezifikations-Meta-Modell

Das Meta-Modell der Testspezifikation hat folgende Aufgaben:

• Die Abstraktion der Testinhalte von den Ausfuhrungsplattformen.

• Die Formalisierung der im Unternehmen verwendeten Nomenklatur

in der Domane Test.

• Die Kommunikation der Testinhalte uber Abteilungsgrenzen hinweg.

• Die Formalisierung der Testerfahrung durch wiederverwendbare Bi-

bliotheken.

Als Wurzelelement des Testspezifikations-Meta-Modells (TS-MM) dient

das Element Testbibliothek. Dieses beinhaltet die Elemente Ordner und

Testspezifikation.

65

Bild 3.2.: Das Meta-Modell der Testspezifikation.

66

Das Meta-Modell sieht vor, dass eine Testspezifikation Elemente vom Typ

Testfallgruppe oder Kombinationsgruppe aggregiert, deren gemeinsamer

abstrakter Basistyp das Element TestfallGruppeAbstrakt ist. Die Testfall-

GruppeAbstrakt beinhaltet Testfall -Elemente. Um im Kontext der in Kapi-

tel 5 entwickelten Heuristik die hierarchischen Beziehungen einer Zustands-

maschine in der Testspezifikation abbilden zu konnen, vermag ein Testfall -

Element wiederum TestfallGruppeAbstrakt-Elemente zu aggregieren. Fur

die Abbildung der orthogonalen Beziehungen der Zustandsmaschine sind

die Elemente Kombinationsgruppe und Tetallkombination vorgesehen. Ein

Testfall -Element beinhaltet das Element Testsequenzaufruf, welches auf

Testsequenz - und Bedatungskombinations-Elemente verweist.

Die Testsequenz wird in den Ordner -Elementen der Testbibliothek verwal-

tet. Die Testsequenz aggregiert Testschritt-Elemente.

Ein Testschritt ist die kleinste mogliche Einheit; ihm werden konkrete Ak-

tionen zugewiesen, wie Methodenaufrufe oder Berechnungsschritte.

Jeder Testschritt kann Testdatum-Elemente aggregieren, welche im Kon-

text des Testschritts entweder Methoden-Parameter oder einzelne Varia-

blen darstellen.

Im Kontext der Aquivalenzklassenbildung und Grenzwertanalyse aus Un-

terabschnitt 2.6.4.1 aggregiert das Element Testdatum WerteBereich-

Elemente, um diese darstellen zu konnen. Einer Aquivalenzklasse Wer-

teBereich ist mindestens ein Repraesentant-Element zuzuordnen.

Das Element Testsequenz ist im Kontext der Testausfuhrung als ausfuhr-

bare Funktion bzw. Methode konzipiert, weshalb diesem mit dem Element

Testdatensatz die Summe der Testdatum-Elemente der zugeordneten Test-

schritt-Elemente zugewiesen wird.

Bezugnehmend auf die in Unterabschnitt 2.6.4.2 eingefuhrten Auswahlstra-

tegien entspricht das Element Testsequenz dem SUT, die Elemente Testda-

tum den Faktoren und die Elemente Wertebereich den diesen zugeordneten

Leveln. Das Element Bedatungskombination entspricht einem ausgewahlten

Datenpunkt und das Element Testdatensatz der Summe der kombinierten

Datenpunkte.

67

Anwendungsmoglichkeiten im Framework ergeben sich durch die

Technologie des EMF derart, dass ein grafischer Editor aus dem TS-MM

erzeugt werden kann, welcher auch die manuelle Instanziierung des Meta-

Modells ermoglicht. In diesem Editor ist zur Beschrankung der Komplexitat

zunachst die minimale Auswahlstrategie implementiert, so dass nach Anga-

be von Testschritt, Testdatum und Wertebereich die minimale Anzahl an

Bedatungskombinations-Elementen fur eine Testsequenz erzeugt wird. In

Bild 3.3 ist dies anhand eines Beispiels illustriert. Es ist eine Testsequenz

mit zwei Testschritten und insgesamt vier Testdaten dargestellt. Die ma-

ximale Anzahl von WerteBereich-Elementen ist drei. Daraus ergeben sich

die dargestellten drei Bedatungskombinationen.

Bild 3.3.: Anwendung von Auswahlstrategien in dem TS-MM.

3.2.2. Das Testbericht Meta-Modell

Im Kontext des funfphasigen Testprozesses, welcher in Abschnitt 2.2 ein-

gefuhrt worden ist, ermoglicht das TS-MM die Formalisierung der Testin-

halte.

68

Das Framework sieht vor, durch die Implementierung unterschiedlicher

Codegeneratoren als M2Text-Transformation, die Inhalte des TS-MM in

Code zu uberfuhren, welcher gegen das SUT ausgefuhrt werden kann.

Wahrend der Ausfuhrung hat prozessgemaß eine Protokollierung und Be-

wertung stattzufinden. Zu diesem Zweck ist das Testbericht-Meta-Modell

vorgesehen, welches in Bild 3.4 dargestellt ist.

Bild 3.4.: Der Testbericht als Teilaspekt der Testbeschreibung.

Die Elemente des Meta-Modells referenzieren auf die Elemente des TS-MM.

Innerhalb der EMF-Technologie ist es moglich, eine in XML-serialisierte

Instanz des Modells wieder in das Java-Objektmodell einzulesen und dy-

namisch zu verwalten.

69

Dieses Konzept wird fur den Testbericht wie folgt angewandt: Die Code-

generatoren werden so geschrieben, dass wahrend der Testausfuhrung eine

XML-Report-Datei geschrieben wird, welche eine Instanz des Testbericht-

Meta-Modells ist, wie es Listing 3.1 darstellt. Durch den Report-Befehl

findet wahrend der Testausfuhrung eine Dateiausgabe statt.

1 i f ( Bedingung in einem T e s t s c h r i t t ){2 Report (<T e s t s c h r i t t Name=”fahren ”

3 IDTes t s ch r i t t=”032984 ” Verdict=”bestanden ”> , Bedingung )

4 } e l s e {5 Report (<T e s t s c h r i t t Name=”fahren ”

6 IDTes t s ch r i t t=”032984 ” Verdict=”nichtbestanden ”> , Bedingung )

7 }

Listing 3.1: Exemplarische Implementierung von Report-Code.

Dadurch entsteht mit jeder Testausfuhrung eine Bericht-Datei, welche zu-

nachst uber die Struktur- und Namensgleichheit der Testbericht-Elemente

mit der Testspezifikation in Verbindung gebracht werden kann. Technolo-

gisch ist es uber die Referenzbeziehung zu den TS-MM-Elementen auch

moglich, die Beziehung automatisiert herzustellen.

3.2.3. Codegenerierung

Die als M2Text-Transformation mit den Mitteln von oAW realisierte Code-

generierung soll an dieser Stelle exemplarisch aufgezeigt werden. Die The-

matik ist ausfuhrlich in [26] beschrieben. Die M2Text-Transformation be-

dient sich der XPAND Sprache, deren wesentliches Element das Template

ist, welches mit dem Schlusselwort «DEFINE» eingeleitet wird. Das in Lis-

ting 3.2 dargestellte Template ist fur das Element Testspezifikation des

TS-MM definiert. Das Template erzeugt die Implementierung der Metho-

de run der aus dem Ubergabewert «className» ubergebenen Klasse. Darin

wird fur jedes enthaltene Testfallgruppen-Element der in den Zeilen 5 bis

10 dargestellte Code des Listings erzeugt. Die Arbeitsweise der Transfor-

mation wird an dem Beispiel des Methodenaufrufs in Zeile 7 erlautert.

Fur die Eingabe einer Testfallgruppe, deren Attribut Name mit dem Wert

Zustand_AUS_EIN belegt ist, wird der Code TF_Zustand_AUS_EIN(); ge-

neriert.

70

1 «DEFINE RunBody( St r ing className , S t r ing sutClassName )

2 FOR t e s t : : T e s t s p e z i f i k a t i o n »3 void «className» : : run ( )

4 { «FOREACH t h i s . T e s t f a l l g r up p e AS t fg»5 th i s−>r e s e t ( ) ;

6 t ry {7 TF «tfg . Name» ( ) ;

8 } catch ( except ion &e ) {9 f p r i n t f ( s tde r r , ”\ n t e s t c a s e TF «cppIdent i f i e r ( t f g .Name)» . . . ) ;

10 }11 «ENDFOREACH»12

13 «PROTECT CSTART ’/∗ ’ CEND ’∗/ ’ ID t h i s .Name + ” u s e r t c c a l l s ”»14 // Protected Region f u r e i g ene Tes t f a l l g ruppen

15 «ENDPROTECT»16 }17 «ENDDEFINE»

Listing 3.2: Exemplarische Darstellung der M2Text-Transformation.

Das in Zeile 13 dargestellte Schlusselwort leitet einen geschutzten Bereich

ein, dessen Inhalt bei erneuter Codegenerierung nicht mehr uberschrieben

wird. Auf diese Weise bleiben manuelle Anpassungen unangetastet.

Es wird deutlich, dass es mit Hilfe der XPAND Sprache komfortabel mog-

lich ist, einen Codegenerator fur verschiedene Zielsprachen zu schreiben.

Der großte Aufwand in der Erstellung des Codegenerators liegt darin, dass

der Implementierer sowohl die Generatorsprache als auch die Zielsprache

beherrschen muss.

3.2.4. Zusammenfassung

Durch die Konzeption des Testframeworks und die Definition der beiden

Meta-Modelle fur die Testspezifikation und den Testbericht ist eine Basis

geschaffen, welche es ermoglicht, verschiedene werkzeuggestutzte Testent-

wurfsmethoden in den Entwicklungsprozess zu integrieren.

Im Rahmen der verwendeten Implementierungstechnologie lassen sich, ba-

sierend auf den Meta-Modellen, grafische Editoren generieren, welche die

Eingabe der Testspezifikation auch manuell ermoglichen. Im Rahmen eines

Migrationsszenarios ist es in der Praxis damit denkbar, zunachst manuell

die Testfalle in das Testspezifikationsformat einzugeben, die Codegenera-

71

toren zu erarbeiten und zu verfeinern. Danach kann die automatisierte

Erstellung des TS-MM aus Testentwurfsmethoden eingefuhrt werden.

Es ist zu beachten, dass die Testspezifikations-Datenstruktur den Daten

nur eine formale Struktur gibt, sie definiert aber keine eindeutige Seman-

tik. So besteht die Gefahr, dass Anwender aus unterschiedlichen Bereichen

Inhalte unterschiedlich in diese Struktur einsortieren. Dieser Gefahr kann

durch die automatische Befullung des Formates durch werkzeuggestutzte

Testentwurfsmethoden und das Bereitstellen ausfuhrlicher Beispiele vorge-

beugt werden.

72

4. Leitanwendung

Die Integration der methodischen Testfallerstellung und der automatisier-

ten Testausfuhrung in den Entwicklungsprozess einer Kfz-Steuergerate-

Software ist eine vielschichtige Aufgabenstellung. Daher sollen die Grund-

konzepte zunachst an einer Leitanwendung entwickelt werden, welche im

Folgenden vorgestellt wird.

Im Kontext von Bild 2.15 liegt der Fokus zunachst auf dem Modultest.

Diesem Ansatz liegt das Motto der Konstruktionslehre”von innen nach

außen“ zugrunde.

Als Leitanwendung wird das Softwaremodul Druckregler aus der Steue-

rungssoftware eines Automatik-Getriebes ausgewahlt.

4.1. Physikalische Grundlagen

Die Schaltvorgange innerhalb eines automatischen Getriebes werden hy-

draulisch ausgelost. Die Steuerung dieser Vorgange erfolgt uber Regel- und

Schaltmagnetventile, welche das Bindeglied zwischen der physikalischen

Realisierung und der elektronischen Steuerung sind. Die Magnetventile sind

in dem in Bild 4.1 dargestellten hydraulischen Schaltgerat integriert. In

diesem Bild wird auch der vereinfachte hydraulische Schaltplan aufgezeigt.

Aus dem Schaltplan wird ersichtlich, dass mehrere Magnetventile innerhalb

des Systems zum Einsatz kommen. Der Haupt-Druckregler (HD), welcher

den Arbeitsdruck des Systems einregelt, ist der Olpumpe nachgeschaltet.

Da der an den anderen Ventilen anliegende Druck von diesem Arbeitsdruck

abhangt, kann im Gesamtsystem kein hoherer Druck als der Arbeitsdruck

herrschen.

Durch die Vorgabe eines Stroms an die Magnetventile ist es der Elektroni-

schen Getriebesteuerung (EGS) moglich, die Stellglieder des Systems mit

einem Druck zu beaufschlagen und somit die Gangwechsel des Getriebes zu

steuern. Da die innerhalb des Steuergerates implementierten Algorithmen

die Große Druck verwenden, wird innerhalb der Gesamtsoftware ein Modul

73

[ZF-Schulung: Grundlagen Automatikgetriebe]

Ölpumpe

25 bar

Schaltglieder

Regelmagnetventile

6 - 7 bar

Schaltmagnetventile

HD

Schaltmagnetventile

Bild 4.1.: Hydraulisches Schaltgerat und vereinfachter hydraulischerSchaltplan [7].

benotigt, welches diesen Druck in einen auszugebenden Strom umrechnet.

Dieses Modul ist Teil eines Regelkreises und wird im Folgenden Druckregler

bezeichnet.

Die Umrechnung wird durch eine Kennlinie implementiert, welche in Bild

4.2 dargestellt ist. Die Kennlinie wird nicht interpoliert. Sie wird durch

einen maximal und einen minimal moglichen Druck begrenzt, pmax respek-

tive pmin. Es wird kein kleinerer Strom als der applizierbare Ruhestrom

I0 ausgegeben. Beim Einschalten des Magnetventils muss ein applizierba-ZF FRIEDRICHSHAFEN Aktiengesellschaft Beschreibung: Zusatzbenennun

Funktionsspezifikation Druckregler

Nr.: DIN A4

Seite 6 von 13

D:\Projekte\3_Zusammenstellung einer Werkzeugkette\eb1\druckregler.doc

3.5 Druck in Strom umrechnen

Die Druck-Strom-Charakteristik liegt als Kennlinie mit sechs Punkten DR1_x.P_I vor. Die x-Achse ist dabei der Druck, die y-Achse ist der Strom. Im Regelbereich wird die Kennlinie interpoliert. Im ausgeschalteten Zustand wird der Strom I_null ausgegeben. Die Kennlinie wird nicht extrapoliert.

3.6 Status des Druckreglers Beim Aufruf der Methoden Einschalten(), DruckAusgeben() etc. wird der Status des Druckreglers zurückgegeben. Er gibt an, ob der Regler ein- oder ausgeschaltet ist und ob der Arbeitspunkt außerhalb des Regelbereichs liegt.

Wert Status Beschreibung 0 ausgeschaltet Druckregler ausgeschaltet, keine

Druckausgabe möglich! 1 regelt P_Min ≤ p_soll ≤ p_Max 2 regelt, Filter wirksam Druckfilterung verhindert p_Soll-

Umsetzung im Regelbetrieb 3 KL begrenzt oben P_soll > p_Max 4 KL begrenzt unten P_soll < p_Min 5 Begrenzt durch

Hauptdruck P_Max > p_soll > p_HD

6 Begrenzt durch max. zulässigen Druck

P_soll > p_max_zul

7 durchgesteuert Druckregler durchgesteuert P = p_HD + p_HD_Offset

8 Störung Stromreglerstörung/Fehler

p1 pMax

IMax

I1I0

I2

p2pMin

ZF FRIEDRICHSHAFEN Aktiengesellschaft Beschreibung: Zusatzbenennun

Funktionsspezifikation Druckregler

Nr.: DIN A4

Seite 7 von 13

D:\Projekte\3_Zusammenstellung einer Werkzeugkette\eb1\druckregler.doc

3.7 Einschalten Beim Einschalten wird ein applizierbarer Strompuls I_Einsprung für eine Zeit t_Einsprung ausgegeben, um den Druckregler sicher in die Regelstellung zu bewegen. t_Einsprung ist eine Kennlinie über T_Sumpf. Nach dem Strompuls wird der einzustellende Druck in einen Strom umgerechnet und dieser ausgegeben. Beim Einschalten wird der Status zurückgeliefert.

t

t

psoll

Isoll

DR_[x].t_Einsprung

DR_[x].I_Einsprung

3.8 Druck vorgeben Dem Druckregler werden zwei Drücke übergeben: p_Steuer_Soll, p_Regel_Soll. p_Steuer_Soll ist immer positiv, p_Regel_Soll kann auch negative Werte annehmen. Der tatsächliche Solldruck für den Druckregler wird durch Addition der beiden Drücke ermittelt: p_Soll = p_Steuer_Soll + p_Regel_Soll Eine Druckvorgabe ist nur möglich, wenn der Druckregler eingeschaltet und nicht durchgesteuert ist. Die Druckvorgabe wird nicht sofort in einen Strom umgesetzt, sondern nur zwischengespeichert. Die eigentliche Ausgabe erfolgt in der Run-Methode.

3.8.1 Garantierter Mindestdruck Ein Aufruf der Funktion MinDruckGarantieEin() schaltet den Druckregler auf Mindestdruck-Garantie. Unabhängig von der Druckvorgabe wird ein Mindestdruck vom Druckregler nicht unterschritten. Dieser Mindestdruck kann vorgegeben werden MinDruckGarantieEin(p_min_zul) oder es wirkt der applizierbare Mindestdruck DR_x.p_min_garantiert. Eingestellt wird das Maximum aus beiden Mindestdrücken Die Mindestdruck-Garantie kann nur aktiviert werden, wenn der Druckregler eingeschaltet und nicht durchgesteuert ist. Liegt der aktuelle Istdruck unter dem garantierten Mindestdruck, hebt der Druckregler den Istdruck beim Einschalten der Garantie auf Mindestdruck an. Die Mindestdruck-Garantie kann durch Aufruf der Funktion MinDruckGarantieAus() abgeschaltet werden.

Bild 4.2.: Druck-Strom-Kennlinie des Moduls Druckregler (DR).

74

rer Stromimpuls IEinsprung ausgegeben werden, um zu gewahrleisten, dass

das Ventil sich nicht verklemmt. Dieser Zusammenhang wird ebenfalls in

Bild 4.2 dargestellt. Die Zeitdauer tEinsprung, fur welche IEinsprung anliegt,

hangt von der Temperatur des Getriebeols im Olsumpf TSumpf ab und ist

wiederum durch eine Kennlinie beschrieben.

Durch eine ubergeordnete Regelung, wie sie in Bild 4.3 dargestellt ist, wird

der Solldruck pSoll berechnet.

pSoll = pSteuer Soll + pRegel Soll (4.1)

Der Solldruck wird in einen korrespondierenden Strom umgerechnet. Dabei

ist die Sollwertvorgabe immer positiv, pSteuer Soll ∈ R+. Fur die Ruckfuh-

rung des zu regelnden Wertes gilt: pRegel Soll ∈ R.

Regler StreckepSteuer_Soll

pRegel_Soll

pSoll

Bild 4.3.: Ubergeordnete Regelung, in welche das Softwaremodul eingebun-den ist.

Durch das Durchsteuern eines Ventils wird dieses hydraulisch geoffnet. Der

sich dabei einstellende Druck pIst hangt von dem Druck pmax und von dem

durch den Hauptdruckregler eingestellten Arbeitsdruck im Gesamtsystem

pHD ab. Damit berechnet sich der anliegende Druck zu:

pIst = min(pHD, pmax) (4.2)

Wenn das Softwaremodul in eine ubergeordnete Regelung eingebunden ist,

kann ein Gradientenfilter fur den ausgegebenen Strom aktiviert werden,

welches die Regelung komfortabler und numerisch stabiler macht.

Ferner bietet das Softwaremodul die Moglichkeit, einen Mindestdruck an

dem jeweiligen Ventil zu gewahrleisten. Durch den Mechanismus automati-

sches Deaktivieren kann die Steuerung die Bestromung des Ventils auf das

Minimum herunterfahren.

75

4.2. Software-Design und Implementierung

Aus den physikalischen Anforderungen wird das Design des Moduls abge-

leitet. Da die Magnetventile in dem hydraulischen Schaltgerat mehrfach

in ahnlicher Form vorkommen, bietet sich eine objektorientierte Imple-

mentierung der Software an, welche im Folgenden durch UML-Diagramme

erlautert wird.

4.2.1. Klassendiagramm

Die Klasse cDruckregler wird fur die mehrfach vorkommenden physikali-

schen Objekte jeweils neu instanziiert und bedatet. Die physikalische Ab-

hangigkeit aller Drucke in den Ventilen von dem eingeregelten Hauptdruck

wird im Design dadurch berucksichtigt, dass es eine Instanz fur den Haupt-

druckregler gibt, welche den Hauptdruck an alle ubrigen Instanzen bindend

vorgibt. Dieser Sachverhalt ist in dem Klassendiagramm des Softwaremo-

duls, welches in Bild 4.4 dargestellt ist, durch die Kompositionsbeziehung

HD realisiert. Die Abhangigkeit der Impulszeit tEinsprung von der Sumpf-

temperatur des Getriebes ist durch eine Referenz zu der Klasse cTempSen-

sor realisiert, die im Klassendiagramm nicht dargestellt ist. Der innerhalb

des Moduls berechnete Strom wird in einer Instanz der Klasse cOCG ab-

gelegt, welche die Implementierung des Stromreglers realisiert. Zu diesem

Zweck besteht zwischen den beiden Klassen wiederum eine Kompositions-

beziehung. Die Bedatung der unterschiedlichen Instanzen erfolgt uber ein

Datenfeld. Um dessen Parameter in unterschiedlichen Speicherbereichen

des in der EGS eingesetzten Mikrocontrollers ablegen zu konnen, imple-

mentiert die Klasse cDruckreglerDF die Zugriffsmethoden auf die Daten,

welche wiederum durch Referenzbeziehungen in unterschiedlichen Struk-

turen abgelegt sind. Diese Strukturen konnen gezielt auf Speicherbereiche

abgebildet werden. Die Klasse cDruckregler aggregiert die Zugriffsklasse

cDruckreglerDF.

76

Stromregler

cOCG

SetCurrent

GetCurrent

AcceptDiagnosis

Reset

Load

Flush

ComputeDAC

GetTrexDiagnosis

SetMode

SetDiagnosticCurrent

Enable

Disable

cOCG

SetCurrent

GetCurrent

AcceptDiagnosis

Reset

Load

Flush

ComputeDAC

GetTrexDiagnosis

SetMode

SetDiagnosticCurrent

Enable

Disable

sDF{Structure}

t_Einsprung

I_Einsprung

I_null

p_EW_DR_ina ...

Attribute1

cDruckreglerDF

p_I_KL (in Druck) : Strom

t_Einsprung () : Zeit

I_Einsprung () : Strom

I_null () : Strom

p_HD_Offset ()

SetzeVariante ()

pg_max_bei_Filt_aktiv ()

...

cDruckRegler

Init

Run

DruckVorgeben

HoleIstdruck

HoleIndexAIM

cDruckRegler

SteuerdruckVorgeben

RegeldruckVorgeben

Einschalten

Ausschalten

Durchsteuern

Regeln

MinDruckGarantieEin

MinDruckGarantieAus

MinDruckGarantieIstEin

MaxDruckVorgeben

SetzeVariante

Run_200ms

DruckBerechnen

DruckFilterungEin

DruckFilterungAus

sDF_EEP{Structure}

p_I_KL

cDruckReglerCalDF

I_Cal_Offset ()

sFixDF_EEP{Structure}

I_ANLE_A

I_ANLE_B

I_ANLE_D

I_ANLE_E

I_ANLE_F

I_ANLE_WK

1

1

ptr_DF

0..1

HD

1

1 Stromregler

11

Datenfeld

1

1

ptr_DF_EERAM

1

1 ptr_DF_EEROM

11

DF_RAM_EEP

1

1

«byName»

EeCalData

Bild 4.4.: Klassendiagramm des Softwaremoduls Druckregler.

77

4.2.2. Zustandsdiagramm

Das Verhalten der Klasse cDruckregler wird durch ein UML-

Zustandsdiagramm beschrieben, welches in Bild 4.5 dargestellt ist. Dieses

AUSGESCHALTET

Entry/Stromregler.SetCurrent(Datenfeld.I_null())...

EINGESCHALTET

DRUCK_REGELN

EINSPRUNG

Entry/Stromregler.SetCurrent(Datenfeld.I_Einsprung())

REGELND

Entry/ I_Soll = DruckInStromUmrechnen(p_Soll)

Stromregler.SetCurrent(I_Soll)

DruckVorgeben/

I_Soll = DruckInStromUmrechnen(p_Soll)

Stromregler.SetCurrent(I_Soll)

DURCHGESTEUERT

Entry/ p_Soll = HD.HoleIstdruck()+Datenfeld.p_HD_Offset()

I_Soll = DruckInStromUmrechnen(p_Soll)

Stromregler.SetCurrent(I_Soll) ...

DRUCK_ABSENKEN

Entry/ I_Soll = DruckInStromUmrechnen(p_Soll - Datenfeld.delta_p)

Stromregler.SetCurrent(I_Soll)

REGELN

Entry/ I_Soll = DruckInStromUmrechnen(p_max_zul)

Stromregler.SetCurrent(I_Soll)

DRUCK_BEGRENZEN

AUTODEAKTIVIEREN

AKTIV INAKTIV

MINDESTDRUCK_GARANTIEREN

GARANTIE_AUS

GARANTIE_EIN

DRUCK_REGELN

EINSPRUNG

Entry/Stromregler.SetCurrent(Datenfeld.I_Einsprung())

REGELND

Entry/ I_Soll = DruckInStromUmrechnen(p_Soll)

Stromregler.SetCurrent(I_Soll)

DruckVorgeben/

I_Soll = DruckInStromUmrechnen(p_Soll)

Stromregler.SetCurrent(I_Soll)

DURCHGESTEUERT

Entry/ p_Soll = HD.HoleIstdruck()+Datenfeld.p_HD_Offset()

I_Soll = DruckInStromUmrechnen(p_Soll)

Stromregler.SetCurrent(I_Soll) ...

DRUCK_ABSENKEN

Entry/ I_Soll = DruckInStromUmrechnen(p_Soll - Datenfeld.delta_p)

Stromregler.SetCurrent(I_Soll)

REGELN

Entry/ I_Soll = DruckInStromUmrechnen(p_max_zul)

Stromregler.SetCurrent(I_Soll)

DRUCK_BEGRENZEN

EINSPRUNG

Entry/Stromregler.SetCurrent(Datenfeld.I_Einsprung())

REGELND

Entry/ I_Soll = DruckInStromUmrechnen(p_Soll)

Stromregler.SetCurrent(I_Soll)

DruckVorgeben/

I_Soll = DruckInStromUmrechnen(p_Soll)

Stromregler.SetCurrent(I_Soll)

DURCHGESTEUERT

Entry/ p_Soll = HD.HoleIstdruck()+Datenfeld.p_HD_Offset()

I_Soll = DruckInStromUmrechnen(p_Soll)

Stromregler.SetCurrent(I_Soll) ...

DRUCK_ABSENKEN

Entry/ I_Soll = DruckInStromUmrechnen(p_Soll - Datenfeld.delta_p)

Stromregler.SetCurrent(I_Soll)

REGELN

Entry/ I_Soll = DruckInStromUmrechnen(p_max_zul)

Stromregler.SetCurrent(I_Soll)

DRUCK_BEGRENZEN

DRUCK_ABSENKEN

Entry/ I_Soll = DruckInStromUmrechnen(p_Soll - Datenfeld.delta_p)

Stromregler.SetCurrent(I_Soll)

REGELN

Entry/ I_Soll = DruckInStromUmrechnen(p_max_zul)

Stromregler.SetCurrent(I_Soll)

AUTODEAKTIVIEREN

AKTIV INAKTIVAKTIV INAKTIV

MINDESTDRUCK_GARANTIEREN

GARANTIE_AUS

GARANTIE_EIN

GARANTIE_AUS

GARANTIE_EIN

FEHLER

after( Datenfeld.t_Einsprung() )/

Durchs teuern/ R ege ln /

A ussc halten/

when( p_Soll <= Datenfeld.p_EW _DR_inaktiv() )/

/

E ins c halten/

when( p_Soll > Datenfeld.p_EW _DR_inaktiv() )/

when( HD.HoleIstdruck()

> p_max_zul )/

when( HD.HoleIstdruck()

+ Datenfeld.p_HD_Offset()

< p_max_zul )/after( Datenfeld.t_Absenken )/

R ege ln /

after( Datenfeld.t_inaktiv )/Ausschalten

S trom regler_Fehler/

S trom regler_Fehler/

Stromregler_OK/Stromregler.Reset

MinDruckGarantieE in/

MinDruckGarantieAus/

Superzustand

Orthogonaler Bereich

Orthogonaler Bereich

Orthogonaler Bereich

Superzustand

Bild 4.5.: Verhaltensbeschreibung des Softwaremoduls Druckregler durchein UML-Zustandsdiagramm.

weist die im Rahmen der UML moglichen Strukturierungselemente Hier-

archie und Parallelitat auf, um das Verhalten besser darstellen zu kon-

nen. Der Zustand Eingeschaltet ist ein Superzustand, welcher drei parallele

Regionen {DRUCK REGELN, AUTODEAKTIVIEREN und MINDEST-

DRUCK GARANTIEREN } enthalt. Damit wird ermoglicht, die Methoden

fur die Festlegung eines Mindestdrucks und die Steuerung der Funktiona-

litat automatisches Deaktivieren bereitzustellen, wahrend sich das System

in der Region DRUCK REGELN befindet.

78

Die Region DRUCK REGELN enthalt ferner den hierarchischen Superzu-

stand DRUCK BEGRENZEN, welcher die Teilfunktionalitat fur die Akti-

vierung des Gradientenfilters beinhaltet.

Das bereits aufgezeigte Design wird innerhalb des zugrundeliegenden Ent-

wicklungsprozesses manuell in die Implementierungssprache C++ ubertra-

gen.

4.3. Testausfuhrungsplattform

Fur den Test der Implementierung wird ein Unit-Test-Framework verwen-

det, welches sich an den Artikel [11] anlehnt. Der Aufbau ist in Bild 4.6 dar-

gestellt. Das Framework besteht aus den beiden Klassen cTest und cSuite.

Bild 4.6.: Aufbau des verwendeten Unit-Test-Frameworks.

Die Klasse cTest verwaltet die beiden Variablen n pass und n fail und stellt

die Methode do test zur Verfugung. Dieser Methode konnen boolesche Be-

dingungen ubergeben werden, welche nach einer erfolgreichen Ausfuhrung

die Variable n pass inkrementieren, andernfalls die Variable n fail.

Fur jede zu testende Klasse cSUTi wird eine Instanz der Klasse cTest an-

gelegt, welche die zu testende Klasse referenziert. Um einen Testschritt

innerhalb des Unit-Test-Frameworks bewerten zu konnen, muss dieser als

Assertion vom Typ bool formuliert werden. Diese Assertion wird der Me-

thode do test() ubergeben, welche die Klassenvariablen n pass und n fail

entsprechend inkrementiert.

79

Die Klasse cSuite ermoglicht es, die innerhalb eines Projektes entstande-

nen Instanzen der Klasse cTest gemeinsam auszufuhren, indem sie diese

referenziert.

4.4. Aufgaben fur die Testimplementierung

Der Entwickler muss fur die Testimplementierung die folgenden Aufgaben

abarbeiten.

1. Erstellen eines neuen C++ Projektes, welches die Implementierung

des SUT, der Klasse cDruckRegler, referenziert und das Unit-Test-

Framework implementiert.

2. Erstellen von Stubs, um die Schnittstellen des SUT so zu bedienen,

dass ein fur den Test lauffahiges Programm erstellbar ist.

3. Implementierung der Testinhalte in der Klasse cDruckReglerTest.

Die Arbeitspunkte 1. und 2. sind haufig so arbeitsintensiv, dass fur den

Arbeitspunkt 3., welcher fur die Aussagekraft des Tests am Wichtigsten

ist, am wenigsten Zeit bleibt.

An dieser Stelle soll das erarbeitete Testframework den Entwickler unter-

stutzen, sowohl die Infrastruktur fur den Test aufzubauen, als auch werk-

zeuggestutzte Methoden einzubringen.

80

5. Heuristik zur modellbasierten

Testsequenzgenerierung

Das folgende Kapitel widmet sich dem Aufgabenschwerpunkt, die black-

box Testentwurfsmethoden Zustandsbasierter Test und Aquivalenzklassen-

bildung/Grenzwertanalyse im Rahmen des in Kapitel 3 beschriebenen Test-

frameworks zur Anwendung zu bringen. Dazu wird eine Heuristik zur Test-

sequenzgenerierung erarbeitet, basierend auf Artefakten aus dem Entwick-

lungsprozess. Das Vorgehen wird anhand der Leitanwendung erklart, wel-

che in Kapitel 4 eingefuhrt worden ist.

Artefakte aus dem Entwicklungsprozess /

Testmodell

Testspezifikation.ecore

Ausführungsplattformen

Exchange.ecore

M2M

M2Text

Tes

tfra

mew

ork

Heuristik

M2M

M2M

(Abschnitt 5.2)

(Abschnitt 5.3)

Bild 5.1.: Integration der Heuristik zum Testentwurf in das Testframework.

Grundlage der Heuristik sind die Prinzipien des Zustandsbasierten Testens,

welche in Abschnitt 5.1 eingefuhrt werden. Die Heuristik soll im Rahmen

des Testframeworks generisch weiterverwendet werden konnen. Im Kon-

text der Leitanwendung bedarf es daher einer spezifischen Auspragung des

Exchange-Meta-Modells, um die gegebenen Artefakte aus dem Entwick-

lungsprozess fur die Heuristik aufzubereiten. Dieser Sachverhalt wird in

Abschnitt 5.2 erlautert. Die Heuristik selbst wird in Abschnitt 5.3 vorge-

stellt.

81

5.1. Prinzip der Testsequenzgenerierung aus

Zustandsmaschinen

Der folgende Abschnitt zeigt das allgemeine Prinzip der Testsequenzgene-

rierung aus Zustandsmaschinen auf, welches haufig auch unter dem Schlag-

wort modellbasiertes Testen [54] eingefuhrt wird. Die Vorgehensweise, aus

einer endlichen Zustandsmaschine der Form M = 〈S, T 〉 Testsequenzen

zu deren Verifikation zu generieren, ist in Bild 5.2 dargestellt. Durch die

ZFF TE-NL/FKFS 8 ©Z

F F

riedr

ichs

hafe

n A

G, 2

008

Strategien zur Testfallgenerierung aus UML-Zustandsautomaten

Testprinzip

Regler - System Under Test

Testimplementierung

Stimulation Prüfung

Strategie

Regler – Modell des SUT

Aus

Ein

Ausschalten/Einschalten/

Testsequenzen

Testschritt 1:System im erwarteten Ausgangszustand?

Testschritt 2:Stimulation einesÜbergangs. Testschritt 3:

System im erwartetenZielzustand?

Bild 5.2.: Prinzip der automatischen Testsequenzgenerierung.

Anwendung einer Generierungsstrategie, naher erlautert in Unterabschnitt

5.1.1, wird zunachst ein Ubergangsbaum abgeleitet. Die Pfade durch die-

sen Ubergangsbaum stellen den Testinhalt dar. Im Rahmen des Frame-

works wird dieser Testinhalt in eine Instanz des Testspezifikations-Meta-

Modells uberfuhrt, wodurch die plattformunabhangige Testspezifikation er-

stellt wird. Der eigentliche Test erfolgt nach folgendem Schema:

1. Prufen, ob sich das System in dem jeweiligen Ausgangszustand be-

findet und stimulieren der Verhaltensspezifikation des Zustandes.

2. Stimulieren der Verhaltensspezifikation der Transition, um diese zu

durchlaufen.

3. Prufen, ob das System den Zustandswechsel vollzogen hat und sti-

mulieren der Verhaltensspezifikation des Zielzustandes.

82

5.1.1. Generierungsstrategien

Das Ziel der in der Literatur definierten und beschriebenen Generierungs-

strategien ahnelt den in Unterabschnitt 2.6.3.1 beschriebenen Kontrollfluss-

kriterien. Es ist eine Testspezifikation zu berechnen, welche zu einer ent-

sprechenden Uberdeckung des SUT (M) fuhrt. Die gebrauchlichsten Stra-

tegien in Anlehnung an [16,20] sind:

Zustandsuberdeckung: Eine Testspezifikation, welche der Zustands-

uberdeckung genugt, erreicht jeden Zustand mindestens einmal.

Transitionsuberdeckung: Eine Testspezifikation, welche der Transiti-

onsuberdeckung genugt, stimuliert jede Transition mindestens ein-

mal.

N+ Strategie: Ausgehend von jedem Zustand werden alle Ubergangs-

Bedingungen aktiviert.

Pfaduberdeckung: Eine Testspezifikation, welche der Pfaduberdeckung

genugt, stimuliert alle moglichen Pfade durch die Zustandsmaschine.

Dies bringt den Vorteil, dass Zustande auf allen moglichen Pfaden

erreicht werden. Dadurch konnen Fehler aufgedeckt werden, welche

von der Art abhangen, wie der Zustand erreicht wurde.

5.1.2. Auffindbare Fehler

Im Rahmen der Implementierung zustandsbasierten Verhaltens konnen die

folgenden Fehler auftreten. Bezugnehmend auf die in Abschnitt 2.5 vorge-

stellten potenziellen Softwarefehler handelt es sich um Funktionale Fehler.

Falscher Ubergang: Die Implementierung durchlauft einen nicht aus der

Spezifikation stimulierten Ubergang.

Falsche Aktion: Die an einen Ubergang geknupfte Aktion ist fehlerhaft.

Nicht spezifizierter Ubergang: Bei dem Aufruf eines Events wird in

der Implementierung ein Ubergang stimuliert, welcher in dem Modell

nicht vorgesehen ist.

83

Nicht spezifizierter Zustand: Bei dem Aufruf eines Events wird in der

Implementierung ein Zustand erreicht, welcher in dem Modell nicht

vorgesehen ist.

5.1.3. Auswahl einer Strategie zur

Testsequenzgenerierung

Ziel der folgenden Betrachtungen ist es, zu entscheiden, welche Generie-

rungsstrategie eingesetzt werden soll. Dazu zeigt Tabelle 5.1 auf, welche

Strategie welche Fehler aufdecken kann [41]. Eine Testspezifikation, welche

der Zustandsuberdeckung genugt, vermag keinen der betrachteten Fehler-

typen zu finden. Dieses liegt darin begrundet, dass ein Zustand ggf. uber

mehr als eine Transition erreicht werden kann und so die Testspezifikation

nicht mit Sicherheit falsche Transitionen bzw. Aktionen aufdecken kann.

Eine Testsuite, welche der Transitionsuberdeckung genugt, vermag diese

Fehler aber aufzudecken.

Ein nicht spezifizierter Zustand bzw. Ubergang tritt auf, wenn das System

aus einem Zustand auf ein Ereignis reagieren muss, welches laut Spezifi-

kation nicht auftreten durfte. Solche nicht spezifizierten Ereignisse werden

durch eine Testspezifikation ausgelost, welche der N+ Strategie genugt.

Zustands-uberdeckung

Transitions-uberdeckung

N+

Falsche Transition Nein Ja Ja

Falsche Aktion Nein Ja Ja

Nicht spezifizierteTransition

Nein Nein Ja

Nicht spezifizierterZustand

Nein Nein Ja

Abschatzung derTestschrittanzahl

2 · n m · n m2 · n2

Tabelle 5.1.: Welche Strategie kann welche Fehler aufdecken?n Anzahl der Zustande, m Anzahl der Transitionen.

84

Wie aus der Tabelle 5.1 ersichtlich wird, steigt durch den Einsatz der N+

Strategie die Anzahl der generierten Testschritte (prufen, stimulieren, . . .)

gegenuber der Transitionsuberdeckungsstrategie an. Unter Berucksichti-

gung der Pramisse, die Testspezifikation so ubersichtlich wie moglich zu

gestalten, stellt sich die Frage, welchen Mehrwert der Einsatz der N+

Strategie bringen wurde. Die Antwort kann zwar nicht generisch, aber im

Kontext der Leitanwendung gegeben werden. Wie bereits erwahnt, liegt

der Quellcode der zu testenden Implementierung vor und eine werkzeugge-

stutzte Kontrollflussmessung wird auf diesem ausgefuhrt. Da ein im Test-

modell nicht spezifizierter Zustand in der Implementierung auch nicht sti-

muliert wird, entsteht in diesem Bereich eine mangelnde Uberdeckung. Eine

Testspezifikation, welche mit der Generierungsstrategie Transitionsuberde-

ckung erzeugt wurde, zeigt die mangelnde Code-Uberdeckung an der Stelle

des nicht spezifizierten Zustandes damit genauso auf. Ahnliches gilt fur

nicht spezifizierte Transitionen. Somit kann die Strategie Transitionsuber-

deckung fur die Leitanwendung eingesetzt werden, ohne die Vorteile der

N+ Strategie zu verlieren.

5.1.4. Umgang mit erweiterten endlichen

Zustandsmaschinen

Die beschriebenen Generierungsstrategien setzen eine endliche Zustands-

maschine voraus. Im Rahmen der vorliegenden Arbeit sollen jedoch

ebenfalls erweiterte endliche Zustandsmaschinen [31], wie sie in UML-

Werkzeugen umgesetzt sind, als Testmodell dienen. Erweiterte endliche Zu-

standsmaschinen fuhren im Wesentlichen die Konzepte der Hierarchie und

der Orthogonalitat von Zustanden ein. Um die gangigen Generierungsstra-

tegien dennoch anwenden zu konnen, werden in der Literatur [16, 17, 19]

verschiedene Ansatze vorgeschlagen, wie die erweiterte Zustandsmaschi-

ne in eine aquivalente, endliche Zustandsmaschine uberfuhrt werden kann.

History-Zustande, welche sich einen Zustand uber mehrere Ausfuhrungs-

schritte merken konnen, sollen im Rahmen der Arbeit ausgeschlossen wer-

den.

85

5.1.4.1. Auflosen von Hierarchie

Durch das Konzept der Hierarchie wird eine Strukturierungsmoglichkeit

eingefuhrt. Diese gestattet es dem Modellentwickler, eine Teilzustands-

maschine einer anderen unterzuordnen. Die Gruppierung zu einem hierar-

chischen Zustand hat dabei folgende Bedeutung:

• Alle in den hierarchischen Zustand fuhrenden Transitionen fuhren zu

dem untergeordneten Initialzustand. Wenn die Transition von dem

Initialzustand zu dem ersten Zustand innerhalb des hierarchisch un-

tergeordneten Zustands ohne Auswirkung auf das Systemverhalten

ist, kann die von außen eingehende Transition auch direkt mit dem

Folgezustand des Initialzustandes verbunden werden.

• Alle den hierarchischen Zustand verlassenden Transitionen haben ih-

ren Ursprung in jedem der untergeordneten Zustande, wie es Bild 5.3

darstellt.

Im Vorgriff auf die Ziele der Heuristik sei an dieser Stelle angemerkt, dass

im Kontext der Generierung von Testsequenzen das Auflosen der hierar-

chischen Strukturierung keinen großen Einfluss auf die resultierende Kom-

plexitat hat. Schwerwiegender ist, dass das eingefuhrte Strukturierungsele-

ment in den generierten Testsequenzen nicht mehr zur Verfugung steht.

DURCHGESTEUERT (2)

REGELND (3)

DRUCK_BEGRENZEN (4)

DRUCK_ABSENKEN (4.1)

REGELN (4.2)

(4.0)

DURCHGESTEUERT (2)

REGELND (3)

DRUCK_BEGRENZEN (4)

DRUCK_ABSENKEN (4.1)

REGELN (4.2)

i) vorher ii) nachher

(4.0)

Bild 5.3.: Interpretation eines hierarchischen Zustandes.

5.1.4.2. Auflosen von Orthogonalitat

Ein orthogonaler Zustand wird in der Literatur auch als”And-Zustand“

bzw. als nebenlaufiger Zustand bezeichnet. Durch das Konzept der Ortho-

gonalitat werden parallel ausfuhrbare Zustandsmaschinen beschrieben. In

Bild 5.4 wird dies anhand des Anwendungsbeispiels zweier unabhangig an-

steuerbarer Elektromotoren dargestellt. Diese sind so angeordnet, dass der

86

eine eine Bewegung nach rechts oder links und der andere eine Bewegung

nach oben oder unten verursacht. Im ersten Teil des Bildes ist die aqui-

valente Zustandsmaschine dargestellt, welche die kombinierten Zustande

beinhaltet. Im zweiten Teil ist das Verhalten mit Hilfe zweier orthogonaler

Zustandsmaschinen dargestellt. Die Darstellung macht deutlich, dass die

Moving

Up-Left

Moving

Up

Moving

Up-Right

Moving

Left

Moving

RightStopped

Moving

Down-Left

Moving

Down

Moving

Down-Right

a) Button1_P1 / E1_RotateCW()

b) Button1_P2 / E1_Stop()

c) Button1_P3 / E1_RotateAntiCW()

d) Button2_P1 / E2_RotateCW()

e) Button2_P2 / E2_Stop()

f) Button2_P3 / E2_RotateAntiCW()

a) b)

c)

d) e)

d)

e) f)

b)e)

e)

d)

a) b)

b) c) b)

f)

e)

e)

f)

a) b)

c)

Moving Up StoppedMoving

Down

Moving Left StoppedMoving

Right

a) b)

b) c)

d)

e)

e)

f)

a) Button1_P1 / E1_RotateCW()

b) Button1_P2 / E1_Stop()

c) Button1_P3 / E1_RotateAntiCW()

d) Button2_P1 / E2_RotateCW()

e) Button2_P2 / E2_Stop()

f) Button2_P3 / E2_RotateAntiCW()

Bild 5.4.: Orthogonalitat.

Erfassung des Verhaltens der beiden Motoren unter Zuhilfenahme der or-

thogonalen Darstellung einfacher ist, da die verknupfende Kombination der

beiden Bereiche implizit modelliert wird und nicht explizit erfasst werden

muss.

Die in der Literatur beschriebenen Ansatze [20] zur Ableitung einer aquiva-

lenten Zustandsmaschine aus orthogonalen Zustandsmaschinen gehen nach

dem folgenden Schema vor:

• Bilden der moglichen Zustands-Konfigurationen. Eine Konfiguration

ist eine Menge von Zustanden, welche die Zustande zusammenfasst,

die gleichzeitig aktiv sein konnen (Bsp. Rechts-Oben).

• Zusammenfassung der Konfigurations-Transitionen, welche sich

durch sequenzielle Verknupfung der Transitionen der Zustande aus

den jeweiligen Konfigurationen ergeben.

87

Dieses Vorgehen setzt voraus, dass die Verhaltensspezifikationen der Tran-

sitionen und Zustande der orthogonalen Zustandsmaschinen disjunkt sind.

Im konkreten Fall bedeutet dies: Wenn der Steuerbefehl fur den einen Elek-

tromotor auch eine Auswirkung auf den anderen Elektromotor hat, so kann

das Gesamtverhalten nicht mehr einfach dargestellt werden.

Fur die im Rahmen der Arbeit entwickelte Heuristik ergibt sich das Ziel,

die durch die Orthogonalitat eingefuhrte, kompakte Darstellung auch in

den generierten Testsequenzen beizubehalten.

5.2. Integration in das Framework

Im Rahmen der Arbeit wird eine neuartige Heuristik zur Testsequenzge-

nerierung entworfen, welche basierend auf erweiterten Zustandsmaschinen

eine Testspezifikation erstellt. Um die Heuristik generisch einsetzen zu kon-

nen, baut diese auf der in Unterabschnitt 5.2.1 beschriebenen allgemeinen

Schnittstelle auf.

Die Funktionsweise und die Konzepte werden anhand der in Kapitel 4 vor-

gestellten Leitanwendung entwickelt. In diesem Kontext wird zunachst auf

die verfugbaren Artefakte aus dem Entwicklungsprozess in Unterabschnitt

5.2.2 eingegangen. Darauf aufbauend wird eine konkrete Auspragung des

Exchange-Meta-Modells in Unterabschnitt 5.2.3 vorgestellt, welche die Ad-

aption der Heuristik fur die Leitanwendung ermoglicht. In Unterabschnitt

5.2.4 wird schließlich darauf eingegangen, wie die Instanziierung des Ex-

change-Meta-Modells erfolgt.

5.2.1. Allgemeine Schnittstelle der Heuristik

Die Heuristik soll die Konzepte des Zustandsbasierten Testens basierend

auf endlichen Zustandsmaschinen unterstutzen, sowie die Aquivalenzklas-

senbildung und Grenzwertanalyse. Vor diesem Hintergrund wird die allge-

meine Schnittstelle, welche im Folgenden auch als Testmodell bezeichnet

wird, durch das 5-Tupel aus Gleichung (5.1) definiert.

EM = 〈SM,S, T,R,W 〉 (5.1)

88

SM Das Element SM stellt das Wurzelelement der

Zustandsmaschine dar und speichert die Informa-

tion, welcher Zustand als Ausgangspunkt fur die

Testsequenzgenerierung gekennzeichnet ist.

S = {s1, s2, . . . , sn} Die Menge S reprasentiert die n Zustande s der

Maschine.

T = {t1, t2, . . . , tm} Die Menge T reprasentiert die m Transitionen t

der Maschine.

R = {r1, r2, . . . , rl} Die Menge R, bestehend aus l Regionen r, repra-

sentiert das Strukturierungselement fur hierarchi-

sche und orthogonale Bereiche, es kann wiederum

Zustande und Transitionen aggregieren.

W = {w1, w2, . . . , wk} Die Menge W entspricht den k Werte Bereich-

Elementen w. Diese reprasentieren die Aquiva-

lenzklassen und Grenzwerte der Attribute und

Parameter, die im Testmodell verwendet werden.

Diese Mengen stellen die fur die Beschreibung des Testmodells notwendigen

Modellelemente dar. Die Elemente Zustand s und Transition t beinhalten

zudem Untermengen, mit denen die Verhaltensspezifikation der Elemente

transportiert wird, dargestellt in Tabelle 5.3.

E

ET = {eT1 , eT2 , . . . eT�}ES = {eS1 , eS2 , . . . eS�}

E ist die Menge von Ereignissen e. Ereig-

nisse, welche eine Transition auslosen kon-

nen, werden eT bezeichnet. Ereignisse, wel-

che beim Betreten eines Zustandes ausgelost

werden, werden eS bezeichnet.

G

GT = {gT1 , gT2 , . . . gT�}GS = {gS1 , gS2 , . . . gS�}

G ist die Menge von Guard-Bedingungen g.

Guard-Bedingungen, welche zu einer Transi-

tion gehoren, werden gT bezeichnet. Die Zu-

gehorigkeit zu einem Zustand wird durch gS

gekennzeichnet.

89

A

AT = {aT1 , aT2 , . . . aT�}AS = {aS1 , aS2 , . . . aS�}

A ist die Menge von Aktionen a. AT kenn-

zeichnet den Bezug zu einer Transition, AS

den Bezug zu einem Zustand.

W : W S ⊆ W ∧W T ⊆ W

W T = {wS1 , w

T2 , . . . w

T�}

W S = {wT1 , w

S2 , . . . w

S�}

Den im Kontext der Mengen E, G und A ver-

wendeten Attributen und Parametern sind

durch die Menge W Aquivalenzklassen und

Grenzwerte zugewiesen. Die Menge W S be-

zieht sich dabei auf die Verhaltensspezifikati-

on der Zustande, die Menge W T auf die der

Transitionen.

VS = ES ×GS × AS ×W S VS ist die Menge der Verhaltensspezifikatio-

nen eines Zustandes. Beim Betreten des Zu-

standes kann ein Event (eSx) aufgerufen wer-

den, welches nach der Erfullung einer Guard-

Bedingung (gSx ) zu dem Aufruf einer Aktion

(aSx) fuhrt. Dies erfolgt gemaß der Syntax:

eSx [gSx ]/aSx . Den dabei verwendeten Attribu-

ten und Parametern sind durch die Menge

W S Aquivalenzklassen und Grenzwerte zu-

gewiesen.

VT = ET ×GT × AT ×W T VT ist die Menge der Verhaltensspezifikatio-

nen einer Transition. Durch den Aufruf eines

Events (eTx ) und die Erfullung einer Guard-

Bedingung (gTx ) wird die Transition von ei-

nem Zustand in den darauffolgenden Zustand

unter Aufruf der Aktion (aTx ) durchgefuhrt.

Dies erfolgt gemaß der Syntax: eTx [gTx ]/aTx .

Dabei sind die WerteBereich-Elemente in der

Menge W T zusammengefasst.

Tabelle 5.3.: Erlauterung der Verhaltensspezifikation.

Ferner ist im Kontext des Testmodells EM definiert, welche Relationen

zwischen den Mengen bestehen. Diese sind in Tabelle 5.4 zusammengefasst.

90

T ⊆ S × VT × S Eine Transition t ist eine Relation zwischen

Zustanden, wobei der Ubergang von einem

Ausgangs-Zustand (source) in einen Zielzustand

(target) gemaß einem Element der Verhaltensspe-

zifikation VT beschrieben wird.

R ⊆ T × S Eine Region r stellt uber die Aggregation von Ele-

menten t ∈ T und s ∈ S eine Relation zwischen

diesen dar. Durch die Regionen wird die Informa-

tion uber die Strukturierung des Modells in hier-

archische und orthogonale Bereiche transportiert.

S ⊆ S ×R Ein Zustand s kann uber die Aggregationsbezie-

hung zu einer Region r keine, eine oder mehrere

Regionen beinhalten.

Tabelle 5.4.: Relationen zwischen den Modellelementen.

Der Einfachheit halber soll es im Folgenden moglich sein, auf die Attri-

bute und Relationen der Modellelemente mit dem Punkt-Operator (.) zu-

greifen zu konnen. Bsp.: t1.source = {Name des Ausgangszustands der

Transition}. Ferner soll es moglich sein, die Attribute und Relationen ei-

nes Elements in runden Klammern anzugeben, um deren Zusammenhang

darstellen zu konnen. Transitionen werden durch den Index des Ausgangs-

und des Endzustandes indiziert.

Die Menge der Zustande S beinhaltet auch die Pseudozustande Start ( )-

und Endzustand ( ). Der Zugriff auf den Startzustand einer Region er-

folgt durch die Operation r.ss. Der Zugriff auf den Endzustand durch die

Operation r.se.

Mit dem Testmodell werden folgende Definitionen eingefuhrt:

Definition 5.1 (Region) Eine Region ri ∈ R beinhaltet Zustande und

Transitionen. Die Region r0 beinhaltet das gesamte Zustandsdiagramm.

Weitere Regionen kommen in Superzustanden oder orthogonalen Zustanden

vor.

91

Definition 5.2 (Einfacher Zustand) Ein einfacher Zustand beinhaltet

keine weiteren Regionen. Es gilt: card {s.R} = 0.

Definition 5.3 (Superzustand) Ein Superzustand ist ein Zustand, wel-

cher eine Hierarchieebene beinhaltet. Es gilt: card {s.R} = 1.

Definition 5.4 (Orthogonaler Zustand) Ein orthogonaler Zustand

beinhaltet parallele Hierarchieebenen. Es gilt: card {s.R} > 1.

5.2.2. Verfugbare Artefakte der Leitanwendung

Das zu testende Verhalten der Leitanwendung ist in Form eines Klassen-

diagramms mit einem zugeordneten Zustandsdiagramm in einem UML-

Werkzeug1 beschrieben. Da die Implementierung des Verhaltens im Rah-

men der Leitanwendung manuell erfolgt ist, ist es zulassig, diese Design-

Artefakte fur die Testgenerierung zu verwenden.

Um die Aquivalenzklassen- und Grenzwerte bereits im Design spezifizieren

zu konnen und die Generierung von Testsequenzen aus dem Zustandsdia-

gramm steuern zu konnen, wird ein UML-Profil definiert, welches in Tabelle

5.5 aufgelistet ist.

Stereotyp Tag-Definition Modell-Element-Zuweisung

«Value» Setter, Getter, Wertebereich Parameter, Attribut, Operation

«SMUT» - State

Tabelle 5.5.: UML-Profil zur Steuerung der Testsequenzerstellung.

Das Stereotyp «Value» ist den Modell-Elementen Parameter, Attribut und

Operation zugewiesen und dient dazu, den Definitionsbereich dieser Ele-

mente in Form von Aquivalenzklassen und Grenzwerten zu spezifizieren.

Dafur ist dessen Tagged-Value Wertebereich vorgesehen. Durch die Zuwei-

sung des Stereotyps an eine Operation wird deren Ruckgabewert klassifi-

ziert. Durch die Tagged-Values Setter 2 und Getter konnen die Methoden

1Artisan-Studio2In der objektorientierten Programmierung werden die Methoden zum Setzen und Lesen von Eigen-schaften einer Klasse haufig als Set- und Get-Methoden bezeichnet.

92

spezifiziert werden, welche fur den Zugriff auf den jeweiligen Parameter

oder das jeweilige Attribut vorgesehen sind.

Das Stereotyp State Machine Under Test («SMUT») kann innerhalb eines

Zustandsdiagramms einem Zustand (State) zugewiesen werden. Durch die

Platzierung dieses Stereotyps kann der Testingenieur definieren, welcher

Teil des Diagramms in die Testsequenzgenerierung mit einbezogen wird.

5.2.3. Konzeption des Exchange-Meta-Modells

Um das in dem machtigen UML-Meta-Modell beschriebe Klassen- und Zu-

standsdiagramm der Leitanwendung in das fur das Framework und die

Heuristik benotigte Testmodell EM zu uberfuhren, wird im Folgenden das

Bild 5.5.: Aufbau des Exchange-Meta-Modells.

93

Exchange-Meta-Modell fur diese Anwendung konzipiert. Sein Aufbau ist in

Bild 5.5 dargestellt.

Im Kontext des fur die Leitanwendung verwendeten UML-Werkzeuges ist

das Zustandsdiagramm einer Klasse zugeordnet. Dieser Zusammenhang

wird in dem Exchange-Meta-Modell durch die Aggregationsbeziehung der

Elemente Root, Package, Class zu StateMachineType abgebildet. Das At-

tribut SMUT des Elements StateMachineType ist dafur vorgesehen, den

im UML-Zustandsdiagramm mit dem Stereotyp «SMUT» gekennzeichne-

ten Zustand aufzunehmen.

Die Elemente StateType und PseudoState sollen die Zustande des UML-

Zustandsdiagramms aufnehmen, beide Elemente werden im Testmodell auf

die Menge S abgebildet. Desgleichen ist das Element TransitionType zur

Aufnahme der Transitionen T und das Element Region zur Aufnahme der

Regionen R konzipiert.

Im UML-Zustandsdiagramm werden die Verhaltensspezifikationen event,

guard und action fur Zustande und Transitionen spezifiziert. Sie bedienen

sich aus den der ubergeordneten Klasse zugeordneten Operationen und

Attributen bzw. aus den assoziierten Klassen. Dieser Zusammenhang ist

durch die Modellelemente Class, Operation und Attribute berucksichtigt.

Insbesondere ist vorgesehen, dass Attributen und Parametern von Opera-

tionen Aquivalenzklassen und Grenzwerte zugewiesen werden konnen. Die

Kennzeichnung der Aquivalenzklassen erfolgt im UML-Klassendiagramm

durch das Stereotyp «Value». In dem Exchange-Meta-Modell sind die Ele-

mente Attribute und Parameter definiert, um diese Information aufzuneh-

men.

Zu diesem Zweck aggregieren die Elemente Parameter und Attribute das

Element Value mit dem Attribut range zur Aufnahme der Wertebereiche.

5.2.4. Instanziierung der Leitanwendung

Im Kontext des Frameworks wird die Leitanwendung zunachst in eine In-

stanz des Exchange Meta-Modells uberfuhrt, welche wiederum in das der

Heuristik zugrundeliegende Testmodell EM uberfuhrt wird.

94

In Bild 5.6 wird dargestellt, wie das in Bild 4.5 eingefuhrte UML-

Zustandsdiagramm der Leitanwendung in eine Instanz des Exchange-Meta-

Modells uberfuhrt wird. Der mit dem Stereotyp «SMUT» gekennzeichnete

EINSPRUNG (1)

DURCHGESTEUERT (2)

REGELND (3)

DRUCK_REGELN EM1 Initial1 (0)

INAKTIV (7)AKTIV (6)

AUTODEAKTIVIEREN EM2

Initial2 (5) Final2 (8)

GARANTIE_EIN (11)GARANTIE_AUS (10)

MINDESTDRUCK_GARANTIEREN EM3

Initial3 (9)

EINGESCHALTET (0.3)

AUSGESCHALTET (0.1)

Initial (0.0)

FEHLER (0.2)

DRUCK_BEGRENZEN (4)

DRUCK_ABSENKEN (4.1)

REGELN (4.2)

(4.0)

cDruckRegler

«SMUT»

Bild 5.6.: Abbildung eines UML-Zustandsdiagramms in das Exchange-Meta-Modell.

Zustand wird innerhalb des Exchange-Meta-Modells als Attribut des Ele-

ments StateMachineType vermerkt. Innerhalb des Beispiels ist der Initial-

zustand der Region DRUCK REGELN markiert.

Die folgenden Ausfuhrungen stellen den Bezug zu dem Testmodell

EM = 〈SM,S, T,R,W 〉

her. Das in dem Diagramm beschriebene Verhalten ist der Klasse cDruck-

Regler zugeordnet, weshalb das gesamte Diagramm auf die Region

r0.name = cDruckRegler abgebildet wird.

Die Region r0 beinhaltet die Zustande:

S = {s0.name = Initial, s1.name = AUSGESCHALTET, s2.name = EIN-

GESCHALTET, s3.name = FEHLER}.

95

Ferner beinhaltet r0 die Transitionen:

T = {t0→1, t1→2, t2→1, t2→3, t3→1, t1→3}.

Der Zustand s2 beinhaltet parallele Regionen. Es gilt damit s2.R =

{r1.name = DRUCK REGELN, r2.name = AUTODEAKTIVIEREN,

r3.name = MINDESTDRUCK GARANTIEREN}.

Die verbleibenden Inhalte des UML-Zustandsdiagramms werden in analo-

ger Weise abgebildet.

5.3. Heuristik

Der vorliegende Abschnitt stellt die im Rahmen der Arbeit entwickelte

Heuristik zur Testsequenzgenerierung, basierend auf erweiterten endlichen

Zustandsmaschinen, vor. Die Heuristik berechnet eine Testspezifikation ge-

maß der Transitionsuberdeckungsstrategie. Das Neue an der Vorgehens-

weise ist, dass die Strukturierungselemente Hierarchie und Orthogonalitat

explizit erhalten bleiben. Diesem Vorgehen liegt die Annahme zugrunde,

dass die Entwicklungsingenieure mit dem Einsatz der Strukturierung ihren

Fokus auf spezifische Aufgabenaspekte der Implementierung legen. Wenn

diese Strukturierungselemente durch die Generierung der Testspezifikation

verloren gehen, kann nur mit großem Aufwand aufgezeigt werden, welchen

Bezug die Testfalle zu dem Testmodell haben. Der Erhalt der Struktur

gelingt, indem die Heuristik die Transitionsuberdeckungsstrategie separat

auf Superzustande und orthogonale Zustande anwendet. Das in Unterab-

schnitt 3.2.1 eingefuhrte Testspezifikations-Meta-Modell beinhaltet ahnli-

che Strukturierungselemente und vermag diese deshalb aufzunehmen.

Die Heuristik arbeitet nach dem im Folgenden beschriebenen Schema.

Bedatungsaspekt Die im Design zugewiesenen Aquivalenzklassen und

Grenzwerte, welche zunachst in dem Exchange-Meta-Modell erfasst wer-

den, werden durch die in Unterabschnitt 2.6.4.2 eingefuhrten Auswahlstra-

tegien aufbereitet. Die Beschreibung erfolgt im Unterabschnitt 5.3.1.

96

Struktureller Aspekt Durch strukturelle Umformung des Testmodells

wird eine Testspezifikation errechnet, um testen zu konnen, ob die Imple-

mentierung des SUT dem Design entspricht. Dazu werden folgende Schritte

durchlaufen:

1. Grundlage ist das Testmodell EM = 〈SM,S, T,R,W 〉.

2. Durch die Platzierung des Stereotyps «SMUT» wird festgelegt, von

welchem Zustand ausgehend Testfalle generiert werden. Die Heuristik

identifiziert zunachst, wo das Stereotyp platziert ist und berechnet

fur den Fall, dass es sich nicht um den Initialzustand des Testmodells

handelt, eine Initialisierungs-Testsequenz, welche das System in den

markierten Testausgangszustand versetzt.

3. Auf der relativ zu dem markierten Ausgangszustand obersten Hier-

archieebene wird eine Testspezifikation gemaß der Transitionsuber-

deckung errechnet.

4. Die generierte Menge von Transitionsfolgen wird derart erweitert,

dass alle Zustande auf weitere Regionen hin untersucht werden.

Die Beschreibung erfolgt in den Unterabschnitten 5.3.2 bis 5.3.5.

Synthese der Bedatungsaspekte und der strukturellen Aspekte

Die aus strukturellen Gesichtspunkten abgeleitete Testspezifikation wird

zusammen mit den aufbereiteten Bedatungskombinationen dem TS-MM

zugeordnet. Die Beschreibung erfolgt in Unterabschnitt 5.3.6.

5.3.1. Bedatung

Als Ausgangspunkt fur die Bestimmung der Test-Bedatung werden die

Transitionen der Zustandsmaschine herangezogen. Im Kontext des UML-

Designs und des Testmodells EM aggregiert das Element Transition T

sowohl seine eigene Verhaltensspezifikation VT als auch indirekt uber die

Referenz zu dem Start- und Zielzustand deren Verhaltensspezifikationen

VS. Um eine Testspezifikation ausfuhren zu konnen, mussen alle im Kon-

text der Verhaltensspezifikationen verwendeten Attribute und Parameter

mit einem Zahlenwert versehen werden. In Verbindung mit der Aquiva-

lenzklassenbildung und Grenzwertanalyse werden diesen Wertebereiche W

97

zugeordnet, vgl. Unterabschnitt 5.2.2. Unter Berucksichtigung der in Un-

terabschnitt 2.6.4.2 eingefuhrten Auswahlstrategien ergeben sich damit je

nach eingesetzter Strategie unterschiedliche Anzahlen von konkreten Be-

datungskombinationen.

Fur die Bestimmung der Auswahlmatrizen wird im Folgenden die minimale

Auswahlstrategie aus Gleichung (2.12) herangezogen, um die Auswahlma-

trix Omin zu bestimmen. Ferner wird die maximale Auswahlstrategie aus

Gleichung (2.13) zur Bestimmung der Matrix Omax herangezogen.

Die zur Initialisierung der Algorithmen notwendigen Mengen der Faktoren

F und Level L ergeben sich dabei wie folgt:

F: Die Menge der Faktoren F setzt sich aus der Summe der Para-

meter und Attribute zusammen, welche der Verhaltensspezifikation

VT einer Transition und der Verhaltensspezifikationen VS der zuge-

ordneten Start- und Zielzustande zugewiesen sind. Dabei ist jedem

Faktor F eine Menge von Wertebereichen W ′ zugeordnet, welche

als Level L bezeichnet werden: F ⊆ F×L, wobei gilt card(F) = k.

L: Die Menge L entspricht der Summe der den Faktoren zugeordneten

Level: Li = {li,1, . . . , li,ni} mit card(Li) = ni.

In Anlehnung an Tabelle 2.1 ergeben sich damit die beiden Matrizen

Omin(c = n = max(ni), k, n) und

Omax(c =∏k

i=1 ni, k, n)

mit c Zeilen, k Spalten fur jeweils n Level. Jede Zeile entspricht dabei einer

Bedatungskombination b. Fur die Menge der minimalen Bedatungskom-

binationen Bmin und der maximalen Bedatungskombinationen Bmax gilt:

Bmin ⊆ Bmax (5.2)

Die Differenz der beiden Mengen wird B∆ = Bmax \Bmin genannt.

Fur die Bedatung der Testspezifikation werden fur jedes Transitions-

Element ti→j ∈ T im Testmodell EM die Matrizen Omax und Omin be-

98

stimmt. Jeder Transition werden die Mengen Bmax, BminundB∆ zugeord-

net, wie es Gleichung (5.3) ausdruckt.

ti→j : {ti→j, {Bmax, Bmin, B∆}} = {ti→j,B} (5.3)

Der Zugriff auf die einzelnen Mengen soll im Folgenden uber den Punkt-

Operator in der Form ti→j.B� moglich sein. Das Vorgehen soll fur die Tran-

sition von dem Zustand Ausgeschaltet in den Zustand Eingeschaltet

aus Bild 5.6 veranschaulicht werden. Dem Start- und Endzustand sind kei-

ne Verhaltensspezifikationen zugewiesen. Der Transition ist die Operation

Einschalten(p Steuer Soll, p Regel Soll) mit ihren beiden Parametern als

Event zugewiesen.

Fur die Parameter sind jeweils drei Aquivalenzklassen definiert:

p Steuer Soll : [0, 5000], [5001, 10001], [10001, 15000] [mbar]

p Regel Soll : [0, 3000], [3001, 7001], [7001, 15000] [mbar]

Die Auswahlmatrix Omin wird damit fur zwei Faktoren mit jeweils drei

Leveln berechnet, ihre Auspragung ist in Bild 5.7 in Klassifikationsbaum-

darstellung visualisiert. Auf die Darstellung der korrespondierenden Matrix

Omax, welche fur die gegebene Konfiguration card(Bmax) = 3 ·3 Zeilen auf-

weist, wird verzichtet.

[0, 5000] [5001, 10001] [10001, 15000] [0, 3000] [3001, 7001] [7001, 15000]

p_Steuer_Soll p_Regel_Soll

1.

2.

3.

Bild 5.7.: Darstellung der Bedatunskombinationen Bmin.

Fur die Transition ergibt sich damit:

tEingeschaltet→Ausgeschaltet.Bmin = {b1, b2, b3} (5.4)

99

5.3.2. Berechnung der Initialisierungs-Testsequenz

Im Kontext der strukturellen Umformung des Testmodells dient die

Initialisierungs-Testsequenz dem Zweck, das System in den fur den Test

gewahlten Ausgangszustand zu versetzen. Sie steht damit nicht im Fokus

der Testspezifikation und kann so kurz wie moglich ausfallen. Um dies zu

erreichen, wird der Dijkstra-Algorithmus zur Berechnung des Initialisie-

rungspfades verwendet, welcher die wenigsten Faktoren enthalt. Als Kan-

tengewicht wird dazu die Anzahl der Faktoren ubergeben.

Da der Dijkstra-Algorithmus auf einfachen, gerichteten Graphen arbeitet,

ist es zunachst notwendig, das hierarchische Testmodell in einfache Teilgra-

phen aufzuteilen. Konkret bedeutet dies, dass wenn auf dem Weg von dem

Initialzustand des Testmodells zu dem Testausgangszustand («SMUT»)

Regionengrenzen uberschritten werden, die Regionen einzeln zu betrachten

sind. Die Aufteilung erfolgt durch die Funktion splitGraph(), welche im

Anhang A.1 beschrieben wird. Die Funktion gibt einen Vektor von Instan-

zen der Klasse subGraph zuruck. Das Objekt subGraph hat die Attribute

region, start und end. Das Attribut region beinhaltet dabei die jeweilige

Region. Die Attribute start und end beschreiben den Anfangs- und End-

zustand innerhalb der Region.

EINSPRUNG (1)

DURCHGESTEUERT (2)

REGELND (3)

DRUCK_BEGRENZEN (4)

DRUCK_REGELN EM1 Initial1 (0)

EINGESCHALTET (0.3)

AUSGESCHALTET (0.1)

Initial (0.0)

FEHLER (0.2)

«SMUT»

...

DRUCK_ABSENKEN (4.1)

REGELN (4.2)

(4.0)

Bild 5.8.: Visualisierung der Initialpfadsuche.

100

Die Funktionsweise wird an der in Bild 5.6 dargestellten Konfiguration der

Leitanwendung illustriert, in welcher der Initialzustand der ersten Region

des orthogonalen Zustandes s3.name = Eingeschaltet mit dem Stereo-

typ «SMUT» gekennzeichnet ist. Der Testausgangszustand (Initial1 ) liegt

in der Region DRUCK REGELN. Auf dem Weg von dem Initialzustand

des Testmodells (Initial) zu diesem Zustand wird damit eine Regionengren-

ze uberschritten. Um die Teilgraphen zu berechnen, wird der Funktion der

Initialzustand des Testmodells und der Testausgangszustand ubergeben,

der Aufruf lautet: splitGraph(start = Initial, end = Initial1).

ret =

region: cDruckRegler

start: Initial

end: EINGESCHALTET

;

region: DRUCK REGELN

start: Initial1

end: Initial1

(5.5)

Der Ruckgabewert der Funktion ist ein Vektor mit zwei subGraph-Objekten

(Gleichung (5.5)), deren Bedeutung in Bild 5.8 veranschaulicht wird. Das

erste subGraph-Objekt beschreibt innerhalb der Region cDruckRegler den

Startzustand Initial und den Endzustand Eingeschaltet, welcher die zu

testende Region enthalt. Das zweite subGraph-Objekt beinhaltet die Regi-

on DRUCK REGELN und als Start- und Endzustand den Initialzustand

Initial1, welcher gleichzeitig der Testausgangszustand ist.

Nun ist es die Aufgabe des Dijkstra-Algorithmus, welcher im Anhang A.1

beschrieben ist, innerhalb der Teilgraphen den Weg mit den wenigsten Fak-

toren zu finden. Der Algorithmus ist in der Funktion findLocalPath()

implementiert und wird auf jedes subGraph-Objekt angewendet. Die je-

weils zuruckgegebenen Transitionsfolgen werden zusammengefugt und der

Menge PInit hinzugefugt, welche zur Initialisierung der Testspezifikation

benotigt wird. Fur das erste subGraph-Objekt wird die Transitionsfolge

p0 = {tInitial→AUSGESCHALTET, tAUSGESCHALTET→EINGESCHALTET}

zuruckgegeben. Fur das zweite subGraph-Objekt wird eine leere Transiti-

onsfolge p1 = {∅} zuruckgegeben, da Start- und Endzustand ubereinstim-

men. Die Menge von Transitionsfolgen zur Initialisierung ergibt sich damit

zu:

PInit = {pInit = p0 ∪ p1}. (5.6)

101

5.3.3. Berechnung der Transitionsuberdeckung

Der nachste Schritt in der Heuristik ist die Berechnung von Pfaden durch

das Testmodell, welche alle Transitionen mindestens einmal durchlaufen,

siehe Unterabschnitt 5.1.1. Dazu wird der Algorithmus 5.1 verwendet. Neu

ist, dass die Transitionsuberdeckung zunachst nur in der Region berechnet

wird, welcher der Testausgangszustand angehort. Zustande, welche wei-

tere Regionen beinhalten, werden zuerst als einfache Zustande aufgefasst

und erst in einem zweiten Schritt weiter aufgelost. Der Algorithmus wird

anhand der bereits eingefuhrten Konfiguration der Leitanwendung vorge-

stellt.

Ausgehend von dem markierten Testausgangszustand Initial1 geht in die

Transitionsuberdeckungsberechnung der in Bild 5.9 dargestellte Teilgraph

EM1 des Testmodells EM ein.

REGELND

EINSPRUNG

DURCHGESTEUERT

REGELND DRUCK_BEGRENZEN

DURCHGESTEUERT REGELND

Initial1

DRUCK_REGELN

EINSPRUNG

Entry/Stromregler.SetCurrent(Datenfeld.I_Einsprung())

REGELND

Entry/ I_Soll = DruckInStromUmrechnen(p_Soll)Stromregler.SetCurrent(I_Soll)

DruckVorgeben/I_Soll = DruckInStromUmrechnen(p_Soll)Stromregler.SetCurrent(I_Soll)

DURCHGESTEUERT

Entry/ p_Soll = HD.HoleIstdruck()+Datenfeld.p_HD_Offset()I_Soll = DruckInStromUmrechnen(p_Soll)Stromregler.SetCurrent(I_Soll) ...

DRUCK_ABSENKEN

Entry/ I_Soll = DruckInStromUmrechnen(p_Soll - Datenfeld.delta_p)Stromregler.SetCurrent(I_Soll)

REGELN

Entry/ I_Soll = DruckInStromUmrechnen(p_max_zul)Stromregler.SetCurrent(I_Soll)

DRUCK_BEGRENZEN

DRUCK_REGELN

EINSPRUNG

Entry/Stromregler.SetCurrent(Datenfeld.I_Einsprung())

REGELND

Entry/ I_Soll = DruckInStromUmrechnen(p_Soll)Stromregler.SetCurrent(I_Soll)

DruckVorgeben/I_Soll = DruckInStromUmrechnen(p_Soll)Stromregler.SetCurrent(I_Soll)

DURCHGESTEUERT

Entry/ p_Soll = HD.HoleIstdruck()+Datenfeld.p_HD_Offset()I_Soll = DruckInStromUmrechnen(p_Soll)Stromregler.SetCurrent(I_Soll) ...

DRUCK_ABSENKEN

Entry/ I_Soll = DruckInStromUmrechnen(p_Soll - Datenfeld.delta_p)Stromregler.SetCurrent(I_Soll)

REGELN

Entry/ I_Soll = DruckInStromUmrechnen(p_max_zul)Stromregler.SetCurrent(I_Soll)

DRUCK_BEGRENZEN

EINSPRUNG

Entry/Stromregler.SetCurrent(Datenfeld.I_Einsprung())

REGELND

Entry/ I_Soll = DruckInStromUmrechnen(p_Soll)Stromregler.SetCurrent(I_Soll)

DruckVorgeben/I_Soll = DruckInStromUmrechnen(p_Soll)Stromregler.SetCurrent(I_Soll)

DURCHGESTEUERT

Entry/ p_Soll = HD.HoleIstdruck()+Datenfeld.p_HD_Offset()I_Soll = DruckInStromUmrechnen(p_Soll)Stromregler.SetCurrent(I_Soll) ...

DRUCK_ABSENKEN

Entry/ I_Soll = DruckInStromUmrechnen(p_Soll - Datenfeld.delta_p)Stromregler.SetCurrent(I_Soll)

REGELN

Entry/ I_Soll = DruckInStromUmrechnen(p_max_zul)Stromregler.SetCurrent(I_Soll)

DRUCK_BEGRENZEN

DRUCK_ABSENKEN

Entry/ I_Soll = DruckInStromUmrechnen(p_Soll - Datenfeld.delta_p)Stromregler.SetCurrent(I_Soll)

REGELN

Entry/ I_Soll = DruckInStromUmrechnen(p_max_zul)Stromregler.SetCurrent(I_Soll)

after( Datenfeld.t_Einsprung() )/

Durchsteuern/ Regeln/

when( HD.HoleIstdruck() > p_max_zul )/

when( HD.HoleIstdruck() + Datenfeld.p_HD_Offset() < p_max_zul )/

after( Datenfeld.t_Absenken )/

Regeln/

«SMUT»

EINSPRUNG

REGELND

DURCHGESTEUERT

DRUCK_BEGRENZEN

DRUCK_ABSENKEN

REGELN

Initial1DRUCK_REGELN

EINSPRUNG (1)

DURCHGESTEUERT (2)

REGELND (3)

DRUCK_BEGRENZEN

DRUCK_REGELN Initial1 (0)«SMUT»

REGELND

EINSPRUNG

DURCHGESTEUERT

REGELND

Initial1

DRUCK_BEGRENZEN

REGELND

EINSPRUNG

DURCHGESTEUERT

Initial1

DURCHGESTEUERT

DRUCK_BEGRENZEN

REGELND

EINSPRUNG

DURCHGESTEUERT

Initial1

REGELND

Übergangsbaum Pfad1Pfad2

Pfad3

(4)

Bild 5.9.: Ausgangspunkt fur die Transitionsuberdeckung.

Die Elemente des Teilgraphen lauten:

SM1 = {Initial1}S1 = {Initial1 (0), EINSPRUNG (1), DURCHGESTEUERT (2),

REGELND (3), DRUCK BEGRENZEN (4)}T1 = {t0→1, t1→2, t2→3, t3→2, t3→4, t4→3, t4→2}R1 = {r1 = DRUCK REGELN }W1 ⊆ W

Der Algorithmus gibt einen Ubergangsbaum B = {ki} aus, welcher eine

Instanz des in Bild 5.10 dargestellten Meta-Modells ist.

102

Bild 5.10.: Meta-Modell des Ubergangsbaumes.

Durch die Struktur des Testmodells3 ist a-priori nicht zu unterscheiden,

ob der Zustand Druck Begrenzen (4) ein einfacher Zustand oder ein

Superzustand ist. Dadurch ist es moglich, die Transitionsfolgen stufenweise,

unabhangig von den weiteren hierarchischen Strukturen des Testmodells zu

generieren.

Algorithmus 5.1: Algorithmus zur Berechnung der Transitionsuber-deckung.

Eingabe : EM1 = 〈SM1, S1, T1, R1,W1〉Ausgabe : B = {ki}

1 Initialisierung:

2 k0 = s0 // s0 = Initial13 visited: {∅} // Leerer Vektor4 queue ⊆ S ×B = {(s0, k0)} // Vektor mit Paaren5 solange queue 6= ∅ tue6 pair ← Element aus der queue nehmen (s�, k�)7 Zustand s ← pair.first // Zu Beginn: (s0)8 Knoten k ← pair.second // Zu Beginn: (k0)9 wenn Zustand /∈ visited dann

10 visited = visited ∪ Zustand// T1 = r1.T : Alle Transitionen, welche zu der Region

Druck Regeln gehoren und damit auf der gleichenHierarchieebene stehen, wie der Testausgangszustand.

11 fur ti ∈ T1[ti.source == Zustand] tue12 Knoten.child = ti.target13 ki = Knoten.child14 ni = (ti.target, ki) // Ein neues queue-Element anlegen15 queue = queue ∪ ni // Das Element der queue hinzufugen16 Ende fur17 Ende wenn18 Ende solange

3Instanz des Exchange-Meta-Modells

103

Nach der Initialisierung des Algorithmus und der Uberprufung, ob ein Zu-

stand bereits in den Ubergangsbaum aufgenommen wurde (Zeile 9), wird

die Schleife in Zeile 11 betreten. Es wird nach allen Trasitionen gesucht,

welche den gerade zu untersuchenden Zustand (ti.source == Zustand) ver-

lassen und welche Teil der aktiven Region (im Beispiel DRUCK REGELN)

sind. Die Entwicklung des Algorithmus ist im Anhang B fur eine alternative

Konfiguration des Testmodells dargestellt.

Der ausgegebene Ubergangsbaum hat die in Bild 5.11 dargestellte Form.

Er beschreibt durch einen gerichteten Graphen Wege durch den zugrunde

liegenden Teilgraphen EM1, welche alle Transitionen mindestens einmal

durchlaufen. Aus dem Ubergangsbaum werden die einzelnen Transitionsfol-

DURCHGESTEUERT

REGELND

DURCHGESTEUERT

EINSPRUNG

DURCHGESTEUERT

EINSPRUNG

REGELND

DURCHGESTEUERT DRUCK_BEGRENZEN

DURCHGESTEUERT REGELND

DRUCK_BEGRENZEN

DURCHGESTEUERT

EINSPRUNG

REGELND

DURCHGESTEUERT

DRUCK_BEGRENZEN

DURCHGESTEUERT

EINSPRUNG

REGELND

REGELND

Übergangsbaum Pfad1

Pfad2Pfad3

(0)

(1)

(2)

(3)

(2)(4)

(3)(2)

Initial1

Bild 5.11.: Fur den Teilgraphen EM1 berechneter Ubergangsbaum.

gen abgeleitet, indem der Weg von den Blattzustanden4 zu dem Wurzelzu-

stand beschritten wird. Daraus resultiert der Vektor von Transitionsfolgen

in Gleichung (5.7), welche den abstrakten Testinhalt beschreiben.

P ′EM1=

p1,0 = {t0→1, t1→2, t2→3, t3→2}p1,1 = {t0→1, t1→2, t2→3, t3→4, t4→2}p1,2 = {t0→1, t1→2, t2→3, t3→4, t4→3}

(5.7)

Definition der Nomenklatur Der Index EM1 der Menge von Transi-

tionsfolgen PEM1stellt den Bezug zu der Region des Testmodells her. Die

4Zustande innerhalb des Ubergangsbaums, welche auf keine nachfolgenden Zustande mehr verweisen.

104

Indizes der Transitionsfolgen px,y beziehen sich mit dem ersten Index x auf

die Region des Testmodells. Der zweite Index y ist eine Laufvariable.

5.3.4. Vervollstandigung der Transitionsfolgen

Die Transitionsfolgen in Gleichung (5.7) bedingen fur die daraus abgeleite-

ten Testsequenzen das Aktivieren der Zustande in den Reihenfolgen, wie sie

in den Pfaden in Bild 5.11 visualisiert sind. Dabei ist noch keine Unterschei-

dung getroffen worden, ob es sich um einfache Zustande (Definition 5.2),

Superzustande (Definition 5.3) oder orthogonale Zustande (Definition 5.4)

handelt. Die beiden zuletzt genannten Zustandsklassen beinhalten weitere

Regionen und mussen fur die Generierung eines vollstandig ausfuhrbaren

Tests weiter aufgelost werden.

Zu diesem Zweck werden die einzelnen Transitionsfolgen p1,i ∈ PEM1in

dem Algorithmus 5.2 elementweise darauf hin untersucht, ob sie weitere

Regionen beinhalten (card(tj.target.R 6= 0)5).

Algorithmus 5.2: Vervollstandigung der Transitionsfolgen.

Eingabe : P ′EM1

Ausgabe : PEM1

1 fur jedes p1,i ∈ P ′EM1tue

2 fur jedes tj ∈ p1,i tue

3 Fall card(tj.target.R) = 0

// Einfacher Zustand - Es ist nichts weiter zu tun.

4 Fall card(tj.target.R) = 1

5 Umgang mit Superzustanden (Unterabschnitt

5.3.4.1)

6 Fall card(tj.target.R) > 1

7 Umgang mit orthogonalen Zustanden

(Unterabschnitt 5.3.4.2)

8

9 Ende fur

10 Ende fur

5Anzahl der Regionen, welche der Zielzustand einer Transition aus der Transitionsfolge enthalt.

105

5.3.4.1. Umgang mit Superzustanden

Wenn die Bedingung in Zeile 4 des Algorithmus 5.2 erfullt ist, beinhal-

tet die Transitionsfolge an der entsprechenden Stelle einen Superzustand

(Bsp. Druck Begrenzen in Bild 5.11). Die Auflosung erfolgt nach dem

folgenden Schema:

1. Anwendung des Algorithmus 5.1 auf die zuruckgegebene Region

r(4,1)6. Dabei werden die Elemente der Region folgendermaßen auf

das von dem Algorithmus erwartete Testmodell EM2 abgebildet:

SM2 = {r(4,1).ss}S2 = {r(4,1).ss (4,0), Druck Absenken (4,1), Regeln (4,2)}T2 = {t4,0→4,1, t4,1→4,2}R2 = ∅W2 ⊆ W

Das Ergebnis der Berechnung ist die Transitionsfolgenmenge7:

PEM2={

p2,0 = {t(4,0)→(4,1), t(4,1)→(4,2)}}

(5.8)

2. Aus der Semantik eines Superzustandes folgt, dass jede den Super-

zustand verlassende Transition ihren Ursprung in einem Subzustand

hat (Unterabschnitt 5.1.4.1). Um diesem Umstand Rechnung zu tra-

gen, werden folgende Unterschritte benotigt:

a) Die Menge der Subzustande innerhalb eines Superzustandes,

ausschließlich der Pseudozustande ss und se, wird identifiziert:

r(4,1).S = {DRUCK ABSENKEN (4,1), REGELN (4,2) }

b) Aus der ubergeordneten Transitionsfolge, siehe Zeile 2 des Algo-

rithmus 5.2, folgt ein Zielzustand des Superzustandes. Es mus-

sen nun alle Transitionsfolgen gebildet werden, welche ihren Ur-

sprung in der Subzustandsmenge haben und in dem Zielzustand

enden. Der erste Zielzustand Durchgesteuert (2) ergibt sich

aus der Transition t4→2 in der Transitionsfolge p1,1 der Gleichung

6Nomenklatur: (Index des Vaterzustandes, Index der Region): Erste Region des ZustandesDruck Begrenzen (4).

7Welche in dem betrachteten Fall nur ein Element beinhaltet.

106

5.7. Daraus resultiert die zu integrierende Transitionsmenge:

TEM4= {t(4,1)→2, t(4,2)→2}. (5.9)

Algorithmus 5.3: Superzustand: Hinzufugen von Transitionen.Eingabe : PEM2

Ausgabe : P ′EM2

// i: Prufen, ob es moglich ist, die Transitionen den Blattzustandenhinzuzufugen.

1 fur jedes p2,i ∈ PEM2tue

2 t = p2,i.get(LetztesElement) // Die letzte Transition in p2,i

ermitteln.3 fur jedes tj ∈ TEM4

tue4 wenn t.target == tj.source dann5 TEM4

.remove(tj)6 p2,i.add(tj)7 Ende wenn

// Wenn TEM4== ∅, Algorithmus beenden

8 Ende fur9 Ende fur

// ii: Hinzufugen neuer Transitionsfolgen minimaler Lange.10 fur jedes p2,i ∈ PEM2

tue11 fur jedes tj ∈ TEM4

tue12 fur jedes tk ∈ p2,i tue13 wenn tk.target == tj.source dann14 p = p2,i.get(0 : k) // Kopieren der

Teiltransitionsmenge p2,i.get(0 : k)15 TEM4

.remove(tj)16 p.add(tj)17 P ′EM2

= PEM2.add(p)

18 Ende wenn19 Ende fur

// Wenn TEM4== ∅, Algorithmus beenden

20 Ende fur21 Ende fur

c) Die Transitionsfolge PEM2muss um die berechneten Transitio-

nen TEM4erweitert werden. Dazu wird der Algorithmus 5.3 ein-

gesetzt, welcher aus zwei Teilen besteht:

107

i. Prufen, ob die in TEM4enthaltenen Transitionen einem

Blattzustand der Transitionsfolge PEM2hinzugefugt werden

konnen; falls moglich, diese hinzufugen.

ii. Wenn Transitionen der Menge TEM4nicht auf diese Weise

eingefugt werden konnen, mussen sie den bestehenden Tran-

sitionsfolgen p2,i ∈ PEM2hinzugefugt werden. Dazu wird

das erste Auftreten einer Transition gesucht, welches die

Bedingung erfullt, dass der Zielzustand der Transition der

Transitionsfolge dem Ausgangszustand der Transition der

Menge TEM4entspricht (Zeile 13 in Algorithmus 5.3). An

dieser Stelle wird der zugrunde liegende Ubergangsbaum

verzweigt und der Menge PEM2die entsprechende Transiti-

onsfolge hinzugefugt.

Der Algorithmus 5.3 gibt fur den vorliegenden Fall die Teiltran-

sitionsfolgenmenge P ′EM2zuruck.

P ′EM2=

{p2,0 = {t(4,0)→(4,1), t(4,1)→(4,2), t(4,2)→2}p2,1 = {t(4,0)→(4,1), t(4,1)→2}

}(5.10)

Die errechnete Teiltransitionsfolgenmenge wird in die ubergeordne-

te Transitionsfolge an der Stelle eingefugt, an der der Ubergang von

einem Zustand in einen Superzustand stattfindet, welcher innerhalb

des Algorithmus 5.2 identifiziert wird. In der Transitionsfolge p1,1

werden die abstrakten Transitionen t3→4 und t4→2 durch die Transi-

tion t3→P ′EM2

ersetzt. Der Index von P ′EM2verweist darauf, dass die

beinhalteten Transitionsfolgen in dem Zustand (2) enden.

3. Die Teile 2b) und 2c) (Seite 106) werden fur die weiteren Transitions-

folgen der Menge PEM1aus Gleichung 5.7 wiederholt. Im vorliegenden

Fall ist nur noch die Transitionsfolge p1,2 zu untersuchen, welche er-

neut den Superzustand DRUCK BEGRENZEN (4) beinhaltet, dies-

mal mit Zielzustand (3). Die Anwendung der Teile 2b) und 2c) ergibt

dann die Teiltransitionsfolgenmenge P ′EM3.

P ′EM3=

{p3,0 = {t(4,0)→(4,1), t(4,1)→(4,2), t(4,2)→3}p3,1 = {t(4,0)→(4,1), t(4,1)→3}

}(5.11)

108

Das Ergebnis der Auflosung von Superzustanden in der Menge von Tran-

sitionsfolgen PEM1ist durch Gleichung (5.12) gegeben.

PEM1=

p1,0 = {t0→1, t1→2, t2→3, t3→2}p1,1 = {t0→1, t1→2, t2→3, t3→P ′

EM2}

p1,2 = {t0→1, t1→2, t2→3, t3→P ′EM3}

(5.12)

5.3.4.2. Umgang mit orthogonalen Zustanden

Wenn die Bedingung in Zeile 6 des Algorithmus 5.2 erfullt ist, enthalt der

entsprechende Zustand orthogonale Bereiche, wie es Bild 5.12 darstellt. Die

bereits errechnete Menge von Transitionsfolgen PEM1aus Gleichung (5.12)

ist aus dem Bereich Druck Regeln des orthogonalen Zustandes Ein-

geschaltet bestimmt worden. Wie im Unterabschnitt 5.1.4.2 aufgezeigt,

EINSPRUNG (1)

DURCHGESTEUERT (2)

REGELND (3)

DRUCK_BEGRENZEN

DRUCK_REGELN EM1 Initial1 (0)

(4)

INAKTIV (7)AKTIV (6)

AUTODEAKTIVIEREN EM2

Initial2 (5) Final2 (8)

GARANTIE_EIN (11)GARANTIE_AUS (10)

MINDESTDRUCK_GARANTIEREN EM3

Initial3 (9)

EINGESCHALTET (0.3)

Bild 5.12.: Orthogonale Bereiche des Zustandes Eingeschaltet.

wird durch orthogonale Bereiche parallel ausfuhrbare Funktionalitat be-

schrieben. In dem vorliegenden Beispiel kann somit folgende Konfiguration

gelten: Wahrend die Region Druck Regeln im Zustand Einsprung ist,

ist die Region Autodeaktivieren im Zustand Aktiv und die Region

Mindestdruck Garantieren im Zustand Garantie Aus.

109

Da die Algorithmen zur Testsequenzgenerierung eine einfache Zustands-

maschine voraussetzen, formen bekannte Ansatze [17,19] die orthogonalen

Zustande in den zugrundeliegenden Produktautomaten um und berechnen

die Testspezifikation basierend auf diesem. Der Vorteil dieser Vorgehens-

weise liegt darin, dass durch die Umformung alle moglichen Zustandskonfi-

gurationen bestimmt werden, die durch die Semantik verborgen sind. Der

Nachteil liegt im Verlust dieser hoheren Abstraktion.

Um dem Ziel der vorliegenden Heuristik gerecht zu werden und die durch

die Orthogonalitat eingefuhrte Semantik bei der Testsequenzgenerierung

beizubehalten, werden zunachst die Folgen der Umformung orthogonaler

Bereiche in einen Produktautomaten betrachtet.

DRUCK_REGELN EM1

(7)(6)

AUTODEAKTIVIEREN EM2

(11)(10)

MINDESTDRUCK_GARANTIEREN EM3

EINGESCHALTET

(6) (10) (6) (11)

(7) (10) (7) (11)

s(6)

t6→7

s(7)

s(10)

t10→11

s(11)

a

bc

a b c

... ...

...

i) ii) iii)

... ...

Bild 5.13.: Bedeutung orthogonaler Zustande fur den Test.

Dazu zeigt Bild 5.13 i) einen reduzierten Ausschnitt des Zustandes Ein-

geschaltet aus Bild 5.12. Die moglichen Zustandskonfigurationen und

deren Transitionsbeziehungen der reduzierten letzten beiden Regionen sind

in Bild 5.13 ii) dargestellt. Die Zustandsnamen werden durch die Nummern

in runden Klammern abgekurzt. Die Darstellung zeigt fur die Konfigurati-

onstransition b: Wahrend sich die Zustandsmaschine in der Konfiguration

{(6) (10)} befindet, fuhrt die Stimulation der Verhaltensspezifikationen

der Transitionen t6→7 und t10→11 zum Ubergang in die Konfiguration {(10)

(11)}. Entscheidend fur den Ubergang von einer Konfiguration in die an-

dere sind die Transitionen der einzelnen Regionen. Gemaß der Definition

des Testmodells EM in Unterabschnitt 5.2.1 sind aus den Transitionen

fur den Test einzelne Testschritte nach folgendem Schema ableitbar: Pru-

fen der Verhaltensspezifikation des Startzustandes; Stimulieren der Ver-

110

haltensspezifikation der Transition; Prufen der Verhaltensspezifikation des

Zielzustandes.

Dieser Zusammenhang ist in Bild 5.13 iii) ersichtlich. Dabei sind die gemaß

der beiden Transitionen t6→7 und t10→11 in der Zustandsmaschine vorgege-

benen Testschritte in einer Tabelle dargestellt. Die Testspezifikation eines

Konfigurationsubergangs wird als Punkt-Markierung ( ) symbolisiert. Die

Tabelle stellt die drei Konfigurationstransitionen a, b und c dar.

Basierend auf dieser Betrachtung wird folgendes neues Vorgehen gewahlt.

Die Heuristik erachtet die orthogonalen Regionen als separate Zustands-

maschinen. Auf jede Region wird der Algorithmus 5.1 angewendet. Daraus

resultieren fur den betrachteten Zustand Eingeschaltet die Mengen von

Transitionsfolgen in den Gleichungen (5.12), (5.13) und (5.14).

PEM2=

{p2,0 = {t5→6, t6→7, t7→8}p2,1 = {t5→6, t6→7, t7→6}

}(5.13)

PEM3={

p3,0 = {t9→10, t10→11, t11→10}}

(5.14)

Die Testspezifikation des Zusammenspiels der Regionen ergibt sich aus der

Kombination der einzelnen Transitionen, wie es die Tabelle in Bild 5.13 iii)

darstellt. Um eine gultige Testspezifikation zu erhalten, ist die Reihenfolge

der Transitionen einzuhalten, wie sie in den Mengen P abgebildet sind.

Daraus resultieren fur die Kombination die Regeln:

• Aus jeder orthogonalen Menge von Transitionsfolgen P darf nur eine

Transitionsfolge p ausgewahlt werden, die Reihenfolge der Transiti-

onsfolgen innerhalb der Menge P spielt dabei keine Rolle.

• Die Transitionen t ∈ p mussen in der durch Algorithmus 5.1 be-

rechneten Reihenfolge ausgefuhrt werden, da sonst Ubergange gefor-

dert werden, welche die zugrundeliegende erweiterte Zustandsmaschi-

ne gar nicht ausfuhren kann.

• Die Testschritte, welche den gewahlten Transitionen entsprechen,

werden entweder sequenziell aneinandergereiht:

1. Ausfuhren der Testschritte der ersten Transition.

111

2. Ausfuhren der Testschritte der folgenden Transition.

Dieses Vorgehen entspricht der neuen Sequenzierung der bestehen-

den Transitionsfolgen. Alternativ erfolgt die Anordnung nach dem

Schema:

1. Stimulieren und Prufen der Verhaltensspezifikationen der Aus-

gangszustande.

2. Stimulieren und Prufen aller Verhaltensspezifikationen der Tran-

sitionen.

3. Stimulieren und Prufen der Verhaltensspezifikationen der Ziel-

zustande.

Die Testspezifikation orthogonaler Regionen kann damit aus der Menge der

Transitionsfolgen der separaten Regionen aufgebaut werden. Im Kontext

der Heuristik wird fur die Kombination der Transitionsfolgen der orthogo-

nalen Bereiche die minimale Auswahlstrategie angewendet.

Im ersten Schritt wird dabei die Menge der orthogonal auszufuhren-

den Transitionsfolgen KEM0.3mit Gleichung (2.12) bestimmt. In diesem

Kontext stellen die orthogonalen Regionen des Zustandes Eingeschal-

tet die Faktoren dar. Aus der Beziehung PEingeschaltet = PEM0.3=

{PEM1, PEM2

, PEM3} ergibt sich die Große k = card(PEM0.3

) = 3. Die Level

entsprechen den Transitionsfolgen p ∈ Pi. Die Große n = max(ni) hat da-

mit ebenfalls den Wert 3, da die Menge PEM1drei Transitionsfolgen hat.

Es ergibt sich:

KEM0.3=

k0.3,0 = {{p1,0}, {p2,0}, {p3,0}}k0.3,1 = {{p1,1}, {p2,1}, {p3,0}}k0.3,2 = {{p1,2}, {p2,0}, {p3,0}}

(5.15)

Die Transitionen in den orthogonal auszufuhrenden Transitionsfolgen k

mussen sequenziert werden, um eine gultige Testspezifikation zu erhalten.

Die Sequenzierung erfolgt in Algorithmus 5.4.

112

Algorithmus 5.4: Sequenzierung orthogonaler Transitionsfolgen.

Eingabe : KEM0.3

Ausgabe : KEM0.3

1 h= 1 // Laufvariable h fur den Vektor k0.3,o

2 fur o = 1: card(KEM0.3) tue

3 n = max(card(p) ∈ k0.3,o)

4 k = card(k0.3,o)5 fur i=1:n tue6 fur j=1:k tue7 wenn i ≤ card(k0.3,o{j}) dann8 k0.3,o(h) = k0.3,o{j}(i) // i-te Transition t der j-ten

Transitionsfolge p ∈ k0.3,o

9 sonst// tue nichts

10 Ende wenn11 h = h+112 Ende fur13 Ende fur14 Ende fur

Das Ergebnis des Algorithmus wird in Gleichung (5.16) dargestellt:

KEM0.3= {k0.3,0, k0.3,1, k0.3,2}T mit:

k0.3,0 = {t0→1, t5→6, t9→10, t1→2, t6→7, t10→11, t2→3, t7→8, t11→10, t3→2}k0.3,1 =

{t0→1, t5→6, t9→10, t1→2, t6→7, t10→11, t2→3, t7→6, t11→10, t3→EM ′

2

}k0.3,2 =

{t0→1, t5→6, t9→10, t1→2, t6→7, t10→11, t2→3, t7→8, t11→10, t3→EM ′

3

}(5.16)

Die zugrunde gelegte Auswahlstrategie entscheidet, ob die Testspezifikation

der Menge derjenigen entspricht, die aus dem zugrunde liegenden Produk-

tautomaten berechnet wird, oder ob nur eine Teilmenge davon verwendet

wird.

Die Testspezifikation fur orthogonale Bereiche bzw. fur einfache Regionen

setzt sich aus den gleichen Transitionsfolgen in neuer Sequenzierung zu-

sammen. Die gewunschte Ubersichtlichkeit kann nun dadurch gewahrleistet

werden, dass dem Testingenieur die Mengen P in einer separaten Ansicht

dargestellt werden. Genauso kann die Menge K separat dargestellt werden.

113

5.3.5. Zusammenfassung der strukturellen Aspekte

Durch die Heuristik werden fur die unterschiedlichen Regionen der Zu-

standsmaschine cDruckRegler aus der Leitanwendung die Transitionsfolgen

berechnet, welche in Tabelle 5.6 und Bild 5.14 zusammengefasst werden.

PInit: Gleichung (5.6) PEM1: Gleichung (5.12)

P ′EM2: Gleichung (5.10) P ′EM3

: Gleichung (5.11)

PEM2: Gleichung (5.13) PEM3

: Gleichung (5.14)

KEM0.3: Gleichung (5.16)

Tabelle 5.6.: Zusammenfassung der strukturellen Aspekte.

EINSPRUNG (1)

DURCHGESTEUERT (2)

REGELND (3)

DRUCK_BEGRENZEN

DRUCK_REGELN EM1 Initial1 (0)

(4)

INAKTIV (7)AKTIV (6)

AUTODEAKTIVIEREN EM2

Initial2 (5) Final2 (8)

GARANTIE_EIN (11)GARANTIE_AUS (10)

MINDESTDRUCK_GARANTIEREN EM3

Initial3 (9)

EINGESCHALTET (0.3)

AUSGESCHALTET (0.1)

Initial (0.0)

FEHLER (0.2)

Bild 5.14.: Zusammenfassung der errechneten Mengen von Transitions-folgen.

5.3.6. Synthese von Bedatung und Struktur

Mit Hilfe der Heuristik ist in Unterabschnitt 5.3.1 jeder Transition ti→j ∈T ∈ EM eine Menge von Bedatungskombinationen zugeordnet wor-

114

den {ti→j,B}. Basierend auf der Transitionsuberdeckungsstrategie wurden

Mengen von Transitionsfolgen P =⋃

i Pi und K aus dem Testmodell unter

Beibehaltung seiner hierarchischen und orthogonalen Struktur abgeleitet.

Diese Artefakte stellen im Kontext des Frameworks die Grundlage der Test-

spezifikation dar und werden in das TS-MM aus Bild 3.2 uberfuhrt.

Prinzipiell gilt die in Tabelle 5.7 dargestellte Zuordnungsvorschrift:

1: Mengen von Transitionsfolgen P 7−→ Testspezifikation

2: Mengen von Transitionsfolgen P 7−→ Testfallgruppe

2: Orthogonale Transitionsfolgen K 7−→ Kombinationsgruppe

3: Transitionsfolge p 7−→ Testfall

4: Transition ti→j 7−→ Testsequenz

5: Stimulieren und Prufen von VS und VT 7−→ Testschritt

6: Bedatung einer Transition B ∈ B 7−→ Testdatensatz

7: Eine Bedatungskombination b ∈ B 7−→ Bedatungskombination

Tabelle 5.7.: Zuordnung von Struktur und Bedatung zu dem TS-MM.

Zunachst wird mit der Zuordnung der Transitionen ti→j ∈ T in das TS-MM

begonnen. Dazu wird in der Testbibliothek ein Ordner -Element angelegt,

welches die Testsequenzen aufnehmen kann. Fur jede Transition wird ei-

ne Testsequenz und fur deren Verhaltensspezifikation VT ein Testschritt

angelegt. Fur jeden Zustand und dessen Verhaltensspezifikation VS wird

gepruft, ob dieser schon im TS-MM vorhanden ist. Wenn fur den Zustand

noch kein Testschritt-Element existiert, wird aus der Testsequenz ein neues

Element uber die Aggregationsbeziehung angelegt. Wenn fur den Zustand

schon ein Testschritt-Element existiert, wird die Referenzbeziehung aus der

Testsequenz gesetzt.

Zu jedem erstellten Testschritt werden die Elemente Testdatum, WerteBe-

reich und Reprasentant anglegt. Das Attribut Wert des Elements Repra-

sentant wird dabei zunachst zufallig initialisiert, unter Berucksichtigung

des ubergeordneten Attributs Bereich des Elements WerteBereich.

Die der Transition zugeordnete Menge B wird folgendermaßen abgebildet:

Zu jeder Testsequenz wird ein Testdatensatz -Element angelegt, dessen zu-

geordnete Bedatungskombinations-Elemente den Bedatungskombinationen

115

b ∈ B entsprechen. Dazu werden die Referenzbeziehungen auf die Elemente

Testdatum und WerteBereich verwendet.

Als nachstes werden die Mengen von Transitionsfolgen in das Element Test-

spezifikation uberfuhrt. Die dafur vorgesehenen Elemente Testfallgruppe,

Kombinationsgruppe und Testfall sind uber Aggregationsbeziehungen ver-

bunden, damit sie die hierarchische Struktur des Testmodells EM wider-

spiegeln konnen. Zunachst wird eine Testfallgruppe fur die Menge PInit

angelegt, welche ein Testfall -Element fur die Transitionsfolge pInit enthalt.

Der Testfall enthalt die beiden Testsequenzaufruf -Elemente, welche den

Transitionen der Transitionsfolge pInit entsprechen. Ferner enthalt er die

Testfallgruppe PEM0.3, welche den komplexen Zustand Eingeschaltet

(0.3) reprasentiert. Die Testfallgruppe enthalt, analog zu dem Zustand

Eingeschaltet (0.3) drei parallele Testfallgruppen, welche die Mengen

von Transitionsfolgen PEM1bis PEM3

aufnehmen. Auf der gleichen Ebene

der Testfallgruppe PEM0.3wird die Kombinationsgruppe KEM0.3

angelegt,

welche die Transitionsfolgen aus Gleichung (5.16) beinhaltet.

Genauso wie die aus den orthogonalen Regionen resultierenden Transiti-

onsfolgen auf gleicher Ebene im TS-MM abgebildet werden, ist es auch

moglich, die aus dem hierarchischen Zustand Druck Begrenzen (4) re-

sultierenden Transitionsfolgen unterzuordnen. Dies erfolgt beispielsweise

bei der Abbildung der Transitionsfolge p1,1 ∈ PEM1aus Gleichung (5.12).

Zuordnung der Bedatungskombinationen Prinzipbedingt enthalten

die Transitionsfolgen immer wieder die gleichen Transitionen, da die dem

Testmodell zugrundeliegende Zustandsmaschine immer nur ausgehend vom

Initialzustand stimuliert werden kann8. Um aus dieser Wiederholung einen

Nutzen zu ziehen, wird bei der Erstellung der Testsequenzaufruf -Elemente

darauf geachtet, dass die zugeordnete Bedatungskombination b variiert

wird. Dafur wird der Algorithmus 5.5 eingesetzt.

Fur die notwendige Zuordnung

{ti→j, b ∈ B} 7−→ Testsequenzaufruf.Bedatung

8Es ist denkbar, hier Meta-Strategien einzusetzen, um nicht immer bei dem Initialzustand anfangen zumussen.

116

werden dabei bei jedem Aufruf zunachst die Bedatungskombinationen der

Menge Bmin verwendet. Nach jeder Zuordnung wird das Element b der Men-

ge entnommen. Wenn die Menge Bmin leer ist, werden in gleicher Weise die

Bedatungskombinationen der Menge B∆ zugeordnet. Sind beide Mengen

leer, wird auf das erste Element der Menge Bmax verwiesen.

Algorithmus 5.5: Bedatung von Testsequenzen.

1 wenn ti→j.Bmin 6= ∅ dann2 Testsequenzaufruf.Bedatung = ti→j.Bmin.first() // Dem Element

Bedatung das erste Element Bmin.first() zuordnen.3 ti→j.Bmin = ti→j.Bmin \ ti→j.Bmin.first() // Die Menge Bmin um

das erste Element reduzieren.4 sonst wenn ti→j.B∆ 6= ∅ dann5 Testsequenzaufruf.Bedatung = ti→j.B∆.first()6 ti→j.B∆ = ti→j.B∆ \ ti→jB∆.first() // Die Menge B∆ um das

erste Element reduzieren.7 sonst

// (ti→j.Bmin ∧ ti→j.B∆) = ∅8 Testsequenzaufruf.Bedatung = ti→j.Bmax.first()9

Durch die Bestimmung des Bedatungskoeffizienten Qb

Qb =card(Bmin ∪B∆)

card(Bmax)(5.17)

wird dabei fur jede Transition respektive Testsequenz bestimmt, wie viel

Prozent der maximal moglichen Bedatungskombinationen in der Testspe-

zifikation verwendet werden.

Fur die Kombinationsgruppe erfolgt die analoge Zuordnung zu Testse-

quenzaufrufen.

In Bild 5.15 ist die im Vorhergehenden beschriebene Abbildung der Re-

sultate der Heuristik in das TS-MM dargestellt. Die hierarchischen und

orthogonalen Beziehungen sind in der Baumstruktur des TS-MM darge-

stellt.

117

Bild 5.15.: Auszug des resultierenden TS-MM.

118

5.4. Uberfuhren der Testspezifikation in

ausfuhrbaren Code

Im Rahmen des Testframeworks besteht der nachste Schritt darin, die

formale Testspezifikation in ausfuhrbaren Code zu transformieren. Als

Ausfuhrungsplattform wird das in Abschnitt 4.3 vorgestellte Unit-Test-

Framework verwendet.

Die Transformation der Testspezifikation in die Sprache C++ erfolgt als

Modell-zu-Code Transformation unter Verwendung der openArchitecture-

Ware Xpand-Language [26].

Die generierte Testspezifikation wird in der Klasse cDruckRegler Test im-

plementiert, welche von der Klasse cTest des Unit-Test-Frameworks erbt,

siehe Bild 5.16.

Bild 5.16.: Design des Unit-Tests fur die Klasse cDruckRegler mit der Test-implementierung cDruckRegler Test.

Die Elemente der Testspezifikation werden durch folgende Abbildungsre-

geln in Code uberfuhrt; die Aufzahlung erfolgt ausgehend von dem unters-

ten Element in der Hierarchie, dem Testschritt.

Testschritt Fur jede Uberprufung, ob das System in einem definierten

Ausgangs-Zustand ist, wird ein separates Testschritt-Element ange-

legt. Analog werden fur die Stimulation und Uberprufung der Ver-

haltensspezifikation der Transition und die Uberprufung des Ziel-

Zustandes separate Testschritt-Elemente angelegt. Innerhalb der Zu-

standsprufungen sind auch die jeweiligen Verhaltensspezifikationen

des Zustandes zu prufen. Die Zustandsprufung wird durch die Me-

thode testState() implementiert, deren Grundprinzip in Listing 5.1

dargestellt ist. Die Umsetzung ist so angelegt, dass eine Abstraktion

der Implementierung von dem Testmodell moglich ist. Dies kann an-

hand des orthogonalen Zustandes Eingeschaltet veranschaulicht

119

werden. Der Code der Klasse cDruckRegler weist keinen explizit ab-

fragbaren Zustand mit dem Namen Eingeschaltet auf. Dass sich

die Implementierung in diesem Zustand befindet, kann jedoch durch

die Abfrage uberpruft werden, ob der Druckregler und der zugeord-

nete Stromregler den Status OK aufweisen.

1 bool cDruckRegler Test : : t e s t S t a t e ( const char ∗ stateName ) {2

3 /∗ PROTECTED REGION ID( t e s t S t a t e ) ENABLED START ∗/4 i f ( ! strcmp ( stateName , ”E i n g e s c h a l t e t ” ) ) {5 i f (DR−>IstOK ( ) && DR−>StromreglerIstOK ( ) ){6 return true ;

7 } else {8 return fa l se ;

9 }10 }11 /∗ PROTECTED REGION END ∗/12 . . .

13 }

Listing 5.1: Auszug aus der Implementierung der Methode

testState().

Testsequenz Die Testsequenz implementiert die einer Transitionsfolge

entsprechenden Testschritte in einer bedatbaren Methode. Die Argu-

mentenliste der Methode entspricht den Faktoren der Transitionsfol-

ge. Listing 5.2 zeigt die Implementierung des Tests fur den Zustands-

ubergang von dem Zustand Ausgeschaltet nach Eingeschaltet.

Fur die Uberprufung der Zustande wird die beschriebene Methode

testState() eingesetzt.

1 void cDruckRegler Test : : SEQ cDruckReg ler Ausgescha l tet Eingescha l tet

2 ( const int &i n p S t e u e r S o l l , const int &i n p R e g e l S o l l ) {3

4 t e s t ( this−>t e s t S t a t e ( ”Ausgescha l t e t ” ) ) ;

5 i f ( ! ( this−>t e s t S t a t e ( ”Ausgescha l t e t ” ) ) ) {6 throw std : : runt ime er ro r ( ”th i s−>t e s t S t a t e (\”Ausgescha l t e t \”) f a i l e d ” ) ; }7

8 DR−>Einscha l t en ( i n p S t e u e r S o l l , i n p R e g e l S o l l ) ;

9

10 t e s t ( this−>t e s t S t a t e ( ”E i n g e s c h a l t e t ” ) ) ;

11 i f ( ! ( this−>t e s t S t a t e ( ”E i n g e s c h a l t e t ” ) ) ) {12 throw std : : runt ime er ro r ( ”th i s−>t e s t S t a t e ( ”E i n g e s c h a l t e t ”) f a i l e d ” ) ; }13 }

Listing 5.2: Implementierung des Elements Testsequenz.

120

Testfall Das Element Testfall implementiert die Ausfuhrung einer Tran-

sitionsfolge. Dazu werden die Testsequenzaufruf -Elemente des TS-

MM in einen Methodenaufruf transformiert. Das Listing 5.3 zeigt

das Ergebnis der Transformation fur das Testsequenzaufruf -Element

von der Transitionsfolge tEingeschaltet→Ausgeschaltet. Der Methodenauf-

ruf SEQ_cDruckRegler_Ausgeschaltet_Eingeschaltet(...) er-

folgt mit der in Bild 5.7 dargestellten Bedatungskombination b1.

1 void cDruckRegler Test : : T F I n i t i a l A u s g e s c h a l t e t ( ) {2

3 SEQ cDruckRegler Initial ZUSTAND AUS ( ) ;

4

5 SEQ cDruckReg ler Ausgescha l tet Eingescha l tet

6 ( int (2500) /∗ p S t e u e r So l l [ 0 , 5000 ] ∗/ ,

7 int (2000) /∗ p Reg e l S o l l [ 0 , 3000 ] ∗/ ) ;

8 . . .

9 }

Listing 5.3: Implementierung des Elements Testfall.

Testfallgruppe Das Element Testfallgruppe wird durch eine Methode im-

plementiert, welche die zugeordneten Testfall -Elemente sequenziell

aufruft. Um zu gewahrleisten, dass die Zustandsmaschine vor je-

dem Testfallaufruf wieder in dem Initial-Zustand ist, wird die Me-

thode reset() generiert, welche die Instanz der zu testenden Klasse

cDruckRegler aus dem Speicher loscht und neu anlegt.

Kombinationsgruppe Das Element Kombinationsgruppe wird analog zu

dem Element Testfallgruppe angelegt.

Testspezifikation Das Element Testspezifikation wird in der Implemen-

tierung der zentralen run()-Methode des Unit-Test Frameworks rea-

lisiert. Alle aggregierten Testfallgruppen werden dadurch sequenziell

aufgerufen.

5.5. Anwendung

Im Folgenden soll die generierte Testspezifikation bewertet werden. Da-

zu wird der erzeugte Testcode gegen die Implementierung der in Kapitel

4 beschriebenen Leitanwendung ausgefuhrt. Parallel wird die durch das

121

Framework mogliche Vorgehensweise der Testcodeerstellung mit der kon-

ventionellen Herangehensweise verglichen.

Um den Code ausfuhren zu konnen, sind zunachst die in Abschnitt 4.4

beschriebenen Vorarbeiten zu leisten. Ein Visual-Studio-Projekt (*.vcproj)

muss angelegt werden, welches die zu testenden C++-Quellen referenziert

und die notwendigen Stub-Objekte9 bereitstellt, damit das SUT uberhaupt

lauffahig ist.

Zur Erleichterung dieser zeitaufwendigen Arbeitsschritte ist der Code-

generator so erweitert worden, dass er einen Großteil der notwendigen

Test-Infrastruktur generieren kann. Zum einen wird das benotigte Visual-

Studio-Projekt (*.vcproj) generiert. Die Generierung ist moglich, da es sich

um eine XML-Datei handelt. Sie muss die Verweise auf die zu inkludie-

renden Quellcode-Dateien, Bibliotheksverweise (*.lib) und Praprozessor-

Anweisungen enthalten. Die fur die Generierung notwendigen Informatio-

nen werden dabei folgendermaßen gewonnen: Der Ablageort der Quellcode-

Dateien ist standardisiert und der Dateiname der benotigten Quellcode-

Dateien kann durch eine Nomenklatur-Festlegung aus dem Design abgelei-

tet werden. Fur die Leitanwendung bedeutet dies: Aus dem Klassennamen

cDruckRegler im Design kann geschlossen werden, dass die Implementie-

rung in den Dateien druckregler.cpp/hpp abgelegt wird.

Zum anderen werden die Code-Rahmen der Stub-Objekte generiert. Da-

zu werden die aus dem UML-Klassendiagramm bekannten und im Ex-

change-Meta-Modell gespeicherten Informationen uber die Klassenbezie-

hungen und Operationen herangezogen.

Zusatzlich enthalt der aus der Testspezifikation generierte Quellcode ne-

ben der eigentlichen Testspezifikation die Instanziierung des Unit-Test-

Frameworks.

In dieser Vorgehensweise zeigt sich ein erster Vorteil der Einbindung der

Heuristik in das Testframework. Die Infrastruktur fur den Test steht deut-

lich schneller bereit. Wahrend die konventionelle Erstellung der Tests und

der Test-Infrastruktur Tage und Wochen in Anspruch nimmt, ist dies mit

dem Testframework in Stunden machbar.

9Ein Stub-Objekt ersetzt die Funktionalitat eines Objektes fur den Test. Dabei wird die Funktionalitatauf das Minimum reduziert.

122

Ein weiterer Vorteil ist in der klaren Struktur des Testcodes zu sehen.

In der manuellen Implementierung, welche uber einen langeren Zeitraum

entstanden ist, sind unterschiedliche Umsetzungen, Strukturierungen und

Bezeichnungen zu finden. Der generierte Code hingegen enthalt die Inhalte

der in Bild 5.15 dargestellten Testspezifikation in genau der Struktur, wie

sie durch die Transformationsvorschriften aus Abschnitt 5.4 vorgegeben

sind.

Wahrend der eigentlichen Erstellung der Testspezifikation aus dem Design

hat sich die sukzessive Vorgehensmoglichkeit der Heuristik als sehr hilfreich

erwiesen. Durch die Platzierung des Stereotyps «SMUT» ist zunachst fur

den Zustand Eingeschaltet eine Testspezifikation erstellt und in Test-

code uberfuhrt worden. Nachdem die Stub-Objekte implementiert waren

und die Test-Infrastruktur lauffahig war, wurde die Testspezifikation durch

die Umplatzierung des Stereotyps sukzessive erweitert.

Da das SUT manuell aus dem Design abgeleitet wurde, war die Implemen-

tierung haufig komplexer oder anders, als es das Design vorgab. Nach der

Plausibilisierung der korrekten Funktionalitat des SUT musste also ent-

weder das Design oder der Testcode angepasst werden. Als hilfreich und

notwendig hat sich dafur das Konzept der Protected Regions erwiesen, wel-

ches eine manuelle Erganzung des generierten Codes ermoglicht.

Der inhaltliche Vergleich der generierten Testspezifikation mit der manuel-

len Testspezifikation ergab, dass das zustandsbasierte Verhalten des SUT

mit der generierten Testspezifikation vollstandig getestet werden kann.

Aus dem Vergleich der erreichten Zweiguberdeckung (C1), vgl. Unterab-

schnitt 2.6.3.1, der Klasse cDruckRegler bei der Stimulation mit den bei-

den Testspezifikationen ergibt sich, dass die generierte Testspezifikation

50% C1-Abdeckung erzielt. Die manuell erstellte Testspezifikation erzielt

70% C1-Abdeckung. Der Unterschied ist damit zu erklaren, dass die Imple-

mentierung des SUT uber zusatzliches, nicht zustandsbasiertes Verhalten

verfugt. Dabei handelt es sich um triviale Setter- und Getter-Methoden

oder um domanenspezifische Besonderheiten, wie sie durch die Kennlinien-

Abhangigkeit aus Bild 4.2 beschrieben sind.

123

6. Einsatz des Testframeworks

Das vorliegende Kapitel zeigt die im Rahmen der Arbeit entstandenen Aus-

pragungen des in Kapitel 3 konzipierten Testframeworks auf. Die Erlaute-

rungen erfolgen anhand der in Bild 6.1 dargestellten grafischen Benutzer-

oberflache des Testframeworks. Die Implementierung realisiert dabei ver-

schiedene Auspragungen der in dem Testframework vorgesehenen Schich-

ten, vgl. Bild 3.1. In Abschnitt 6.1 werden die parallel zu der Heuristik

integrierten Testentwurfsmethoden und deren Initialisierung mit Informa-

tionen aus dem Entwicklungsprozess beschrieben. Der Abschnitt 6.2 zeigt

den Nutzen der formalen Testspezifikation und die Potenziale durch die

M2Text-Transformation auf. Abschnitt 6.3 fasst schließlich den Nutzen und

die Potenziale des Testframeworks zusammen.

Bild 6.1.: Benutzeroberflache des Testframeworks.

124

6.1. Methoden und deren Einbindung

Die in Kapitel 5 beschriebene Heuristik ist in die grafische Benutzeroberfla-

che aus Bild 6.1 folgendermaßen integriert: Der Knopf Load Statemachine

transformiert die UML-Zustandsmaschine, welche das Verhalten der Leit-

anwendung beschreibt, in eine Instanz des Exchange-Meta-Modells, wie es

in Unterabschnitt 5.2.4 beschrieben ist. Der Knopf Statebased Test fuhrt die

Berechnungen der Heuristik aus und erzeugt mit dem Ergebnis eine Instanz

des Testspezifikations-Meta-Modells, wie es in Abschnitt 5.3 erlautert wird.

Mit dem Knopf Edit Testspezifikation wird ein Editor fur die Testspezifi-

kation geoffnet, wie er in Bild 5.15 dargestellt ist. Schließlich kann durch

den Knopf Generate C++ Code die in Unterabschnitt 3.2.3 beschriebene

Transformation in den C++ Testcode durchgefuhrt werden.

Der Grundgedanke des Testframeworks ist es, verschiedene Testentwurfs-

methoden einbinden zu konnen. Diese Moglichkeit ist notwendig, da eine

zu testende Implementierung mehr als nur zustandsbasiertes Verhalten auf-

weisen kann,wie sich in der Anwendung der berechneten Testspezifikation

auf den Quellcode der Leitanwendung gezeigt hat (vgl. Abschnitt 5.5).

Insbesondere komplexere Berechnungsmethoden wie die Kennlinienzugrif-

fe, lassen sich unter Zuhilfenahme der Klassifikationsbaummethode testen.

Zu diesem Zweck wurde der Klassifikationsbaumeditor CTE-XL [24] in das

Framework integriert. Dies ist technologisch moglich, da der CTE-XL mit

XML-Dateien arbeitet. Darin sind der Klassifikationsbaum und das Ergeb-

nis der Testauswahlstrategien formal gespeichert.

Fur die Einbindung des CTE-XL in das Testframework wurde in das UML-

Design ein weiterer Stereotyp mit Namen «FUT» (Function Under Test)

eingefuhrt, um gezielt Methoden fur den Test kennzeichnen zu konnen. Fur

den spezifischen Fall der Leitanwendung ist das Exchange-Meta-Modell

schon so angelegt, dass es die mit «FUT» gekennzeichneten Methoden

speichern kann. Die Einbindung des CTE-XL erfolgt dann als Modell-zu-

Modell-Transformation in der Methodenschicht. Dazu ist es zunachst notig

ein EMF-Modell des CTE-XML-Schemas zu erstellen, welches als CTE-

Meta-Modell (CTE-MM) bezeichnet wird. Im Kontext des Frameworks ist

es damit moglich, Dateien zu erzeugen, welche der CTE-XL weiterverar-

beiten kann. Die Informationen aus dem Exchange-Meta-Modell, welche

125

Methode getestet werden soll und welche Parameter und Wertebereiche

diese aufweist, werden in der M2M-Transformation in das CTE-MM trans-

formiert.

Das Einlesen des modifizierten UML-Designs und die Transformation des

Exchange-MM in das CTE-MM wird durch den Knopf Load Class-Diagram

angestoßen. Das Ergebnis der Transformation ist eine XML-Datei mit der

Endung *.cte, welche die mit «FUT» gekennzeichnete Klassen-Methode

als Klassifikationsbaum-Wurzel, deren Parameter als Klassifikationen und

deren Wertebereiche als Klassen aufweist. Durch den Knopf Testcases via

CTE wird der CTE-XL geoffnet. Der Benutzer kann nun die erzeugte *.cte-

Datei offnen und Bedatungskombinationen erzeugen, wie es Bild 6.2 zeigt.

Dazu stehen die in Unterabschnitt 2.6.4.2 beschriebenen Auswahlstrategi-

en zur Verfugung. Durch das Speichern der Datei in dem CTE-XL wird die

zugrundeliegende *.cte-Datei um die gewahlten Bedatungskombinationen

erweitert. Die daraus folgende *.cte-Datei wird durch das Testframework

Bild 6.2.: Beispiel fur das Einbinden des CTE-XL in das Testframework.

weiterverarbeitet. Dazu wird die *.cte-Datei wieder in das CTE-MM ein-

gelesen, um eine M2M-Transformation in das Testspezifikations-MM zu er-

moglichen. Der auf diese Weise fur eine Methode spezifizierte Test wird auf

ein Testsequenz -Element abgebildet. Die ursprunglich im CTE-XL gewahl-

ten Bedatungskombinationen werden nun in das Testdatensatz -Element

und dessen untergeordnete Bedatungskombinations-Elemente uberfuhrt.

Das beschriebene Vorgehen ermoglicht es, die mit der Heuristik erstell-

te Testspezifikation fur die Leitanwendung zu erweitern. Daraus wird das

Potenzial des Testframeworks ersichtlich, Testentwurfsmethoden einzubin-

den, die schon als Software-Werkzeug zur Verfugung stehen. Alternativ ist

es auch moglich, die im Kontext der Heuristik eingesetzten Auswahlstrate-

126

gien zu verwenden, um fur eine mit «FUT» gekennzeichnete Methode eine

Testspezifikation zu bestimmen.

Eine weitere Moglichkeit, die Testspezifikation zu erweitern, wird durch

das Werkzeug T-Config [56] ermoglicht. Das Werkzeug bestimmt nach der

Bekanntgabe der Faktoren und Level einer mit «FUT» gekennzeichneten

Methode eine Auswahlmatrix, welche wenn moglich einem orthogonalen

Feld entspricht, wie es in Unterabschnitt 2.6.4.2 beschrieben ist. Der Aufruf

dieser Vorgehensweise ist in der grafischen Benutzeroberflache durch den

Knopf Orthogonal Array realisiert.

Diskussion: In dieser Arbeit wurden die beschriebenen Testentwurfs-

methoden in das Testframework integriert. Die Konzeption des Testframe-

works sieht dabei jedoch vor, zukunftig weitere Testentwurfsmethoden in-

tegrieren zu konnen. Die Integration von Werkzeugen zum modellbasierten

Test soll dabei nach folgenden Szenarien moglich sein: Wenn die einzubin-

dende Losung eine offene Schnittstelle fur das verwendete Testmodell hat,

kann eine Initialisierung des Testmodells mit Informationen aus dem Ent-

wicklungsprozess erfolgen, wie es die im Rahmen der Arbeit entstandene

Heuristik aufzeigt. Kommerzielle Werkzeuge zum modellbasierten Test er-

rechnen eine Testspezifikation, welche in einer formalen Form, meistens in

XML, abgelegt wird. Die Integration in das Testframework besteht dann

nur aus einer M2M-Transformation der fremden Testspezifikation in das

Testspezifikations-Meta-Modell. Auf diese Weise konnen die bereits erar-

beiteten Modell-zu-Text-Transformationen fur die firmenspezifischen Test-

ausfuhrungsplattformen weiterverwendet werden. Kommerzielle Losungen

sind beispielsweise von den Firmen Conformiq [4] oder Leirios [9] verfugbar.

Die im Rahmen der Arbeit entstandene Heuristik zur modellbasierten Test-

sequenzgenerierung verspricht durch die klare Struktur der errechneten

Testspezifikation und die Moglichkeit der schrittweisen Erweiterung der

Testspezifikation Akzeptanz fur das modellbasierte Testen zu schaffen.

Einsatz der Heuristik auf anderen Teststufen Um die Heuristik

des Testframeworks auf anderen Teststufen einsetzen zu konnen, ist die

jeweilige Anwendung zu betrachten. Dies soll am Beispiel der Teststufe

Integrationstest erlautert werden, welche auf Seite 26 beschrieben ist. Die

127

Software wird dabei in einer Software-in-the-Loop (SiL) Simulation betrie-

ben. Das bedeutet, dass das zustandsbasierte Verhalten einzelner Kom-

ponenten nicht mehr ohne die Wechselwirkung der Gesamtsoftware und

des Umgebungsmodells getestet werden kann, vgl. Bild 2.15. Bezogen auf

die Leitanwendung, die Implementierung der Klasse cDruckRegler, steht

damit nicht mehr die Teilfunktionalitat im Blickwinkel, sondern die Funk-

tionalitat in der Gesamtsoftware. Diese besteht darin, die Schaltelemente

des Getriebes zu betatigen, damit ein Gang eingelegt werden kann. Die

Testspezifikation kann dafur exemplarisch folgende Testschritte beinhal-

ten: Motor einschalten → D-einlegen → Triebstrang geschlossen? → Gang

eingelegt? → Beschleunigen → .... Eine solche Testspezifikation lasst sich

Triebstrang_geschlossen Fahrend

Fahrend_Fehlersituation

Beschleunigen/

FehlerAusloesen/

D_einlegen/cSteuerungSiL

D_einlegen ()

Beschleunigen (in v_ziel)

FehlerAusloesen(in FehlerNummer)

Klassendiagramm Zustandsdiagramm

Bild 6.3.: Anwendung der Heuristik am SiL.

auch als UML-Klassendiagramm und UML-Zustandsdiagramm formulie-

ren, wie es das Testmodell in Bild 6.3 veranschaulicht. Die zur Stimulati-

on von Zustandsubergangen notwendigen Methoden werden dabei in einer

Klasse zusammengefasst. Die erwartete Funktionalitat der Software wird

als Zustandsmaschine formuliert.

Unter Verwendung des Frameworks resultiert aus dem Testmodell eine for-

male Testspezifikation als Instanz des TS-MM. Die Transformation der

Testspezifikation muss nun allerdings neu geschrieben werden, um die neue

Testausfuhrungsplattform (SiL) stimulieren zu konnen.

6.2. Formale Testspezifikation und

Transformation

Neben der automatischen Instanziierung des Testspezifikations-Meta-Mo-

dells kann es auch manuell mit Hilfe des Editors erstellt werden, vgl. Bild

3.3. Ein wichtiger Aspekt ist dabei die Moglichkeit, die Nomenklatur in

128

der Domane Test firmenspezifisch durch die Elemente des Meta-Modells

pragen zu konnen. Bei der Erstellung einer Testspezifikation mit dem

Editor entsteht ein hierarchisch strukturiertes und ubersichtliches Doku-

ment, welches durch die M2Text-Transformation des Testframeworks wei-

ter in ausfuhrbaren Testcode uberfuhrt werden kann. Die Testinhalte wer-

den dabei von der konkreten Implementierung getrennt. Dies verbessert

auch die Kommunikation der Testinhalte zwischen den beteiligten Ent-

wicklungsteams, da in der Regel nicht jeder Mitarbeiter alle verwendeten

Test-Implementierungssprachen versteht. Die Transformation ermoglicht

es, aus einer Instanz des TS-MM die gleichen Testinhalte auf verschiedenen

Testausfuhrungsplattformen zum Einsatz zu bringen. Diese Vorgehensweise

hilft das Verhalten des SUT auf unterschiedlichen Testplattformen verglei-

chen zu konnen.

Aufgrund der haufig unterschiedlichen Testausfuhrungsplattformen und

der Moglichkeit, eine Testautomatisierung unterschiedlich zu strukturie-

ren, weisen die Testautomatisierungen einzelner Projekte haufig Unter-

schiede auf. Der Ansatz, die Testimplementierung durch eine M2Text-

Transformation zu realisieren, birgt dabei den Vorteil, dass die Transforma-

tionsvorschrift leicht an die Projektgegebenheiten angepasst werden kann,

da die Transformation zum Großteil auf einem Template basiert, wie es

das Listing 3.2 aufzeigt.

Die Arbeitsschritte zur Erstellung der Test-Infrastruktur machen ca. zwei

Drittel des notwendigen Arbeitsaufwandes fur den Test aus, die Umset-

zung der Testinhalte ca. ein Drittel. Damit liegt in der Erstellung der

Test-Infrastruktur ebenfalls großes Automatisierungspotenzial, wie es im

Kontext der Leitanwendung in Abschnitt 5.5 beschrieben worden ist. Eine

generische Losung fur die Generierung der Test-Infrastruktur kann im Rah-

men der Arbeit nicht gegeben werden. Die Verwendung der dem Testfra-

mework zugrunde liegenden Technologie der generativen Programmierung

und des Grundgedankens der MDA, Softwarewerkzeuge auf den gleichen

Konstruktionselementen aufzubauen, zeigt jedoch ein Verbesserungspoten-

zial auf. Wenn projektspezifische Automatisierungslosungen ebenfalls die

verwendeten Konzepte des Frameworks verwenden, so bauen diese auf den

gleichen Konstruktionselementen, konkret dem *.ecore-Meta-Meta Modell,

auf. Dadurch wird es moglich, punktuell entstandene Teil-Losungen lang-

fristig zu großeren zusammenhangenden Losungen zu integrieren.

129

6.3. Nutzen und Potenziale

Die Anwendung des Testframeworks ermoglicht den Einsatz werkzeug-

gestutzter Testentwurfsmethoden in bestehenden Entwicklungsprozessen.

Durch das methodische Vorgehen wird eine Qualitatssteigerung der Test-

prozesse herbeigefuhrt. Ferner bedingt das Testramework als durchgangig

geschlossene Werkzeugkette eine Effizienzsteigerung bei der Erstellung und

Ausfuhrung von Testspezifikationen. Durch die formale Beschreibung der

Testinhalte wird es moglich, die methodisch erstellten Testspezifikationen

auf unterschiedlichen Ausfuhrungsplattformen zu implementieren und die

Testinhalte effektiv uber verschiedene Teststufen zu verteilen. Ferner wird

ein bedarfsgerechter Einsatz der Testentwurfsmethoden in verschiedenen

Entwicklungsphasen ermoglicht.

130

7. Zusammenfassung und Ausblick

In der vorliegenden Arbeit wurde ein Testframework konzipiert und im-

plementiert, welches die Integration von Testentwurfsmethoden in einen

bestehenden Software-Entwicklungsprozess ermoglicht. Die Aufgabenstel-

lung resultiert aus der Beobachtung, dass Testentwurfsmethoden haufig

nur implizit angewendet werden, da entweder keine Unterstutzung durch

ein Software-Werkzeug gegeben ist oder bestehende Software-Werkzeuge

nicht in die vorgegebene Entwicklungslandschaft integriert werden konnen.

Das erarbeitete Testframework besteht aus drei Schichten: Eine Schicht,

um Artefakte aus dem Software-Entwicklungsprozess fur die Initialisierung

von Testentwurfsmethoden heranziehen zu konnen, eine weitere Schicht,

um die Testentwurfsmethoden zu verwenden und eine dritte Schicht, um

die methodisch erstellte Testspezifikation auf formale Art und Weise zu

erfassen. Basierend auf der formalen Testspezifikation werden Codegene-

ratoren vorgesehen, um die Transformation auf die jeweils anzubindende

Testausfuhrungsplattform zu realisieren.

Zur Umsetzung des Frameworks werden die Konzepte des OMG Stan-

dards Model Driven Architecture (MDA) verwendet. Dabei wird eine ad-

aptierte Implementierung durch das Eclipse Projekt open-Architecture-

Ware (oAW) benutzt. In diesem Kontext wird die Anbindung der Test-

entwurfsmethoden an den Software-Entwicklungsprozess als Modell-zu-

Modell-Transformation (M2M) realisiert. Die Anbindung der Testspezifika-

tion an die verschiedenen Testausfuhrungsplattformen werden als Modell-

zu-Text-Transformation (M2Text) umgesetzt.

Zentrales Element des Testframeworks ist das Testspezifikations-Meta-

Modell. Es hat zur Aufgabe, die methodisch erstellten Testinhalte von

einer plattformspezifischen Implementierung zu trennen. Dadurch ergibt

sich die Moglichkeit, die Testinhalte einfacher in Entwicklungsteams zu

kommunizieren und die Nomenklatur in der Domane Test firmenspezifisch

zu pragen.

131

In der Methodenschicht des Testframeworks wurde mit der Einbindung des

Klassifikationsbaum-Editors CTE-XL die Fahigkeit aufgezeigt, bestehende

Software-Werkzeuge integrieren zu konnen.

Zudem wurde eine neuartige Heuristik zum modellbasierten Testen, basie-

rend auf UML-Zustandsdiagrammen, erarbeitet und integriert. Die Merk-

male der Heuristik sind, dass die in UML-Zustandsdiagrammen mogli-

chen Strukturierungselemente Hierarchie und Orthogonalitat explizit bei

der Testerstellung beibehalten werden. Zudem ist es moglich, eine Test-

spezifikation, basierend auf einem komplexen Zustandsmodell, schrittweise

abzuleiten.

Im Gegensatz zu herkommlichen Ansatzen, die dem UML-Zustands-

diagramm zugrunde liegende erweiterte endliche Zustandsmaschine in eine

einfache Zustandsmaschine umzuformen, verzichtet die Heuristik auf die

Umformung. Stattdessen werden bekannte Algorithmen zur Ableitung einer

Testspezifikation aus endlichen Zustandsmaschinen auf die einzelnen Regio-

nen des UML-Zustandsdiagramms angewendet. Es resultiert eine Testspe-

zifikationen mit einer hierarchischen Struktur, wie sie durch die erweiterte

Zustandsmaschine vorgegeben ist. Diese Vorgehensweise ermoglicht es dem

Testingenieur, den Bezug der Testspezifikation zu der zugrundeliegenden

Zustandsmaschine einfach herzustellen.

Aus der Heuristik resultiert eine Testspezifikation, welche aus der Struk-

tur des Testmodells gewonnen wird. Dabei sind die einzelnen Transitio-

nen und Zustandsubergange auch an bedatbare Verhaltensspezifikationen

gebunden. Im Rahmen der Heuristik werden fur die Auswahl konkreter

Bedatungskombinationen Auswahlstrategien, wie die minimale Kombina-

torik, herangezogen.

Die Funktionsweise der Heuristik und eine Auspragung des Testframeworks

werden anhand einer Leitanwendung aus dem Modultest einer Getriebe-

Steuerungs-Software veranschaulicht.

Das Testframework schafft durch seine Konzeption eine Moglichkeit, Test-

entwurfsmethoden auf allen Teststufen technologisch wiederzuverwenden.

Zunachst wird eine formale Testspezifikation als Instanz des Testspezifika-

tions-Meta-Modells erstellt, welche erst durch eine konkrete Transformati-

on die Testinhalte in den auf der Teststufe verwendeten Testautomatisie-

rungscode uberfuhrt. Durch die Generierung der Test-Infrastruktur kann

132

der teilweise betrachtliche Aufwand zu deren Bereitstellung reduziert wer-

den, wodurch eine weitere Effizienzsteigerung im Testprozess erzielt werden

kann.

Die im Verlauf der Arbeit gesammelten ersten Erfahrungen mit dem Ein-

satz des Testframeworks und der Heuristik zum modellbasierten Testen ha-

ben Vorteile erkennen lassen. So ist zum einen hervorzuheben, dass durch

den Einsatz einer Methode zum Testentwurf konkret nachgewiesen werden

kann, wie die Testinhalte entstanden sind. Durch die Formalisierung der

Testinhalte und den Einsatz einer Transformation, um ausfuhrbaren Test-

code zu erzeugen, konnten zeitaufwendige manuelle Arbeitsschritte einge-

spart werden.

Zukunftig sollte daran gearbeitet werden, weitere Transformationen und

Methoden im Rahmen des Testframeworks anzubinden. Es ist zu erwarten,

dass mit der wachsenden Funktionalitat eine Evolution der verwendeten

Meta-Modelle stattfindet.

133

A. Entwicklung der Algorithmen zur

Testsequenzinitialisierung

Funktion splitGraph(start,end)

Eingabe : start, endAusgabe : ret = {subGraph}

1 Initialisierung:

2 ret =

region: = ∅start: = ∅end: = ∅

3 wenn r(start) == r(end) // Beide Zustande sind Element dergleichen Region

4 dann

5 ret = ret ∪

region: = r(start)

start: = start

end: = end

6 sonst7 current = r(end)8 target = end9 wahrend current 6= r(start) tue

10 subRegion = current

11 ret = ret ∪

region: = subRegion

start: = subRegion.ss

end: = target

12 target = s(subRegion) // Der Zustand, welcher die Regionbeinhaltet.

13 current = r(target) // Die Region, welche den Zustand targetbeinhaltet.

14 Ende-wahrend

15 ret = ret ∪

region: = current

start: = start

end: = target

16 Ende wenn

134

Beschreibung der Funktion splitGraph Bezug nehmend auf den Unterab-

schnitt 5.3.2.

1. Durchlauf

Aufruf der Funktion splitGraph(start = Initial, end = Initial1)

Zeile 3 false

Zeile 7 current = r(end) = DRUCK REGELN

Zeile 8 target = Initial1

Zeile 10 subRegion = DRUCK REGELN

Zeile 11 ret =

region: = DRUCK REGELN

start: = Initial1

end: = Initial1

Zeile 12 target = s(DRUCK REGELN) = EINGESCHALTET

Zeile 13 current = r(EINGESCHALTET) = cDruckRegler

2. Durchlauf

Zeile 9 false, da current == r(start) (hier: cDruckRegler)

Zeile 15 ret =

region: cDruckRegler

start: Initial

end: EINGESCHALTET

region: DRUCK REGELN

start: Initial1

end: Initial1

T

135

A.1. Dijkstra-Algorithmus

Beschreibung des Dijkstra-Algorithmus, wie er im Kontext der Ausfuhrun-

gen aus Unterabschnitt 5.3.2 verwendet wird. Der Algorithmus ist auf die

beiden Funktionen findLocalPath() und relaxe() aufgeteilt. Die Dar-

stellung ist in Pseudo-Code aufgefuhrt, verwendet jedoch die im Rahmen

der Implementierung eingesetzten Java-Klassen.

Funktion findLocalPath(EM , path,start,end)

Eingabe :EM : // Testmodell EM = 〈SM,S, T,R,W 〉

1 path: Vector<Transition>2 start: Zustand3 end: Zustand

Ausgabe : Die Funktion beschreibt die Variable path mit derTransitionsfolge, welche die wenigsten Faktoren enthalt

4 Initialisierung:5 queue: PriorityQueue<Transition> // Prioritatsorientierte

Schlange, welche so initialisiert ist, dass sie die Transition mitden meisten Faktoren (t.factors) zuruckgibt

6 visited: HashSet<Zustand>7 distance: HashMap<Zustand, Integer>8 distance.put(start,0) // Distanz des Startknotens auf Null setzen9 previous: HashSet<Transition>

10 relaxe(EM , start, queue, distance, previous, visited)11 solange queue nicht leer ist tue12 t = queue.poll() // Abfragen und entfernen des vordersten

Elements der Schlange13 u = t.target14 wenn u == end dann15 found = true;16 Ende wenn17 visited.add(u)18 relaxe(EM , u, queue, distance, previous, visited)19 Ende solange20 path = previous

136

Funktion relaxe(EM , start, queue, distance, previous, visited)

Eingabe :EM : // Testmodellstart: Zustandqueue: PriorityQueue<Transition>distance: HashMap<Zustand, Integer>previous: HashSet<Transition>visited: HashSet<Zustand> // vAusgabe : In dem Vektor previous wird die Transitionsfolge mit

den wenigsten Faktoren abgelegt1 fur alle t ∈ EM mit [t.source == start] // Alle Transitionen,

welche den Zustand start verlassen2 tue3 v = t.target // Zielzustand der Transition4 wenn v /∈ visited dann5 Initialisierung:6 d1 =∞, d2 =∞7 d1 = distance.get(start) // Enfernungswert aus distance

auslesen, welcher start zugeordnet ist8 d2 = distance.get(v) // Enfernungswert aus distance auslesen,

welcher dem aktuellen Zielzustand v zugeordnet ist9 factors = t.factors // Anzahl der zu bedatenden Faktoren der

aktuellen Transition bestimmen10 wenn d2 > d1 + factors.size() dann11 distance.put(v,d1+factors.size())12 previous.add(t)13 queue.add(t)14 Ende wenn15 Ende wenn16 Ende fur

137

B. Entwicklung des Algorithmus zur

Transitionsuberdeckung

Im Folgenden wird die Entwicklung des Algorithmus 5.1 fur den Fall dar-

gestellt, dass der Zustand Initial (0.0) mit dem Stereotyp «SMUT» ge-

kennzeichnet ist.

Eingabe fur den Algorithmus 5.1

EM = 〈SM,S, T,R,W 〉: Eine Instanz des Exchange-Meta-Modells, welche

das in Bild B.1 dargestellte Verhalten reprasentiert.

FEHLER (0.2)AUSGESCHALTET (0.1)

[Stromregler_Fehler]/Einschalten()/Ausschalten()/

EINGESCHALTET (0.3)

cDruckRegler

INITIAL

(0.0)

SM = {Initial}S = {Initial (0.0), Ausgeschaltet (0.1), Eingeschaltet (0.3),

Fehler (0.2) }T = {t0.0→0.1, t0.1→0.3, t0.3→0.2, t0.3→0.1}R = {cDruckRegler}W

Bild B.1.: Anwendungsbeispiel zur Erlauterung des Algorithmus.

138

Entwicklung des Algorithmus 5.1

1. Durchlauf

Zeile 7 s0 = Initial

Zeile 8 k0 = s0

Zeile 9 false

Zeile 10 visited = {s0}Zeile 13 k1 = t.target = Ausgeschaltet

Zeile 15 queue = {(Initial, k0), (Ausgeschaltet, k1)}2. Durchlauf

Zeile 7 s1 = Ausgeschaltet

Zeile 8 k1 = s1

Zeile 9 false

Zeile 10 visited = {s0, s1}Zeile 13 k2 = t.target = Eingeschaltet

Zeile 15 queue = {(Initial, k0),(Ausgeschaltet, k1),

(Eingeschaltet, k2)}3. Durchlauf

Zeile 7 s2 = Eingeschaltet

Zeile 8 k2 = s2

Zeile 9 false

Zeile 10 visited = {s0, s1, s2}Zeile 11 T = {t0.3→0.1, t0.3→0.2}Zeile 13.1 k3 = t.target = Ausgeschaltet

Zeile 15.1 queue = {(Initial, k0),(Ausgeschaltet, k1),

(Eingeschaltet, k2), (Ausgeschaltet, k3)}Zeile 13.2 k4 = t.target = Fehler

Zeile 15.2 queue = {(Initial, k0),(Ausgeschaltet, k1),

(Eingeschaltet, k2), (Ausgeschaltet, k3), (Fehler, k4)}

139

Abbildungsverzeichnis

2.1. Aufbau von Steuergeratesoftware. . . . . . . . . . . . . . . . 23

2.2. Softwaretestprozesses im Softwareentwicklungsprozess. . . . 24

2.3. Beispiel fur ein Klassendiagramm. . . . . . . . . . . . . . . . 32

2.4. Die vier Ebenen der MOF. . . . . . . . . . . . . . . . . . . . 35

2.5. Vereinfachtes Meta-Meta Modell des EMF. . . . . . . . . . . 36

2.6. Entwicklungslandschaft fur Steuergeratesoftware. . . . . . . 38

2.7. Klassfizierung der Testfallerstellungsmethoden. . . . . . . . . 41

2.8. Sichten auf das Testobjekt . . . . . . . . . . . . . . . . . . . 42

2.9. Kontrollflussgraph . . . . . . . . . . . . . . . . . . . . . . . 44

2.10. Ordnungsgraph . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.11. Aquivalenzklassen und Grenzwerte. . . . . . . . . . . . . . . 49

2.12. Visualisierung der Kombinatorik im Datenraum. . . . . . . . 50

2.13. Eingabe-Datenpunkte durch ein orthogonales Feld. . . . . . 54

2.14. Visualisierung der minimalen Auswahlstrategie. . . . . . . . 56

2.15. Unterschiedliche Testabstraktionsschichten. . . . . . . . . . . 59

3.1. Technologische Realisierung des Testframeworks. . . . . . . . 64

3.2. Das Meta-Modell der Testspezifikation. . . . . . . . . . . . . 66

3.3. Anwendung von Auswahlstrategien in dem TS-MM. . . . . . 68

3.4. Der Testbericht als Teilaspekt der Testbeschreibung. . . . . 69

4.1. Hydraulisches Schaltgerat. . . . . . . . . . . . . . . . . . . . 74

4.2. Druck-Strom-Kennlinie des Moduls Druckregler (DR). . . . . 74

4.3. Ubergeordnete Regelung . . . . . . . . . . . . . . . . . . . . 75

4.4. Klassendiagramm des Softwaremoduls Druckregler. . . . . . 77

4.5. Verhaltensbeschreibung des Softwaremoduls Druckregler . . 78

4.6. Aufbau des verwendeten Unit-Test-Frameworks. . . . . . . . 79

5.1. Integration der Heuristik zum Testentwurf . . . . . . . . . . 81

5.2. Prinzip der automatischen Testsequenzgenerierung. . . . . . 82

5.3. Interpretation eines hierarchischen Zustandes. . . . . . . . . 86

5.4. Orthogonalitat. . . . . . . . . . . . . . . . . . . . . . . . . . 87

5.5. Aufbau des Exchange-Meta-Modells. . . . . . . . . . . . . . 93

140

5.6. Instanziierung des Exchange-Meta-Modells. . . . . . . . . . . 95

5.7. Darstellung der Bedatunskombinationen Bmin. . . . . . . . . 99

5.8. Visualisierung der Initialpfadsuche. . . . . . . . . . . . . . . 100

5.9. Ausgangspunkt fur die Transitionsuberdeckung. . . . . . . . 102

5.10. Meta-Modell des Ubergangsbaumes. . . . . . . . . . . . . . . 103

5.11. Fur den Teilgraphen EM1 berechneter Ubergangsbaum. . . . 104

5.12. Orthogonale Bereiche des Zustandes Eingeschaltet. . . . 109

5.13. Bedeutung orthogonaler Zustande fur den Test. . . . . . . . 110

5.14. Zusammenfassung der Transitionsfolgen. . . . . . . . . . . . 114

5.15. Superzustande in der Testspezifikation. . . . . . . . . . . . . 118

5.16. Design des Unit-Tests fur die Klasse cDruckRegler. . . . . . 119

6.1. Benutzeroberflache des Testframeworks. . . . . . . . . . . . . 124

6.2. Beispiel fur das Einbinden des CTE-XL in das Testframework.126

6.3. Anwendung der Heuristik am SiL. . . . . . . . . . . . . . . . 128

B.1. Anwendungsbeispiel zur Erlauterung des Algorithmus. . . . 138

141

Tabellenverzeichnis

2.1. Uberblick zu den Auswahlstrategien. . . . . . . . . . . . . . 57

5.1. Auswahl einer Testsequenzgenerierungsstrategie. . . . . . . . 84

5.3. Erlauterung der Verhaltensspezifikation. . . . . . . . . . . . 90

5.4. Relationen zwischen den Modellelementen. . . . . . . . . . . 91

5.5. UML-Profil zur Steuerung der Testsequenzerstellung. . . . . 92

5.6. Zusammenfassung der strukturellen Aspekte. . . . . . . . . . 114

5.7. Zuordnung von Struktur und Bedatung zu dem TS-MM. . . 115

142

Liste der Algorithmen

5.1. Algorithmus zur Berechnung der Transitionsuberdeckung. . . 103

5.2. Vervollstandigung der Transitionsfolgen. . . . . . . . . . . . . 105

5.3. Superzustand: Hinzufugen von Transitionen. . . . . . . . . . . 107

5.4. Sequenzierung orthogonaler Transitionsfolgen. . . . . . . . . . 113

5.5. Bedatung von Testsequenzen. . . . . . . . . . . . . . . . . . . 117

-. Funktion splitGraph(start,end) . . . . . . . . . . . . . . . . . 134

-. Funktion findLocalPath(EM , path,start,end) . . . . . . . . . 136

-. Funktion relaxe(EM , start, queue, distance, previous, visited) 137

143

Literaturverzeichnis

[1] www.openarchitectureware.com.

[2] www.pairwise.org.

[3] ATML. http://grouper.ieee.org/groups/scc20/tii/index.htm.

[4] Conformiq. http://www.conformiq.com/.

[5] CppUnit. http://sourceforge.net/projects/cppunit/.

[6] Eclipse. http://www.eclipse.org/.

[7] Grundlagen der Automatikgetriebe - Ein interaktives Lernprogramm.

http://www.rolandschule.de/mit6.htm.

[8] Herstellerinitiative Software. www.automovie-his.de.

[9] Leirios - Smarttesting. http://www.smartesting.com.

[10] Alain Abran und James W. Moore, (Hrsg.). SWEBOOK - Guide to

Software Engineering Body of Knowledge. IEEE Computer Society,

2004.

[11] Chuck Allison. The simplest automated unit-test framework that

could possibly work. Dr. Dobb’s Portal, 2003.

[12] MISRA The Motor Industry Software Reliability Association. Gui-

delines for the use of the C language in vehicle based software.

www.misra.org.uk, 1998.

[13] Heide Balzert. UML 2 in 5 Tagen. w3L, 2005.

[14] Helmut Balzert. Lehrbuch der Software-Technik. Spektrum Akademi-

scher Verlag, 1998.

[15] Michael Barr. Programming Embedded Systems in C and C++.

O’Reilly, 1999.

[16] Robert V. Binder. Testing Object-Oriented Systems Models, Patterns,

and Tools. Addison Wesley, 1999.

144

[17] Kirill Bogdanov. Automated Testing of Harels Statecharts. Doktorar-

beit, University of Sheffield, 2000.

[18] R. C. Bose. On the application of the properties of galois fields to the

construction of hyper graeco-latin squares. Sankhya, 3:323–338, 1938.

[19] Michael Brost. Automatisierte Testfallerzeugung auf Grundlage einer

zustandsbasierten Funktionsbeschreibung fur Kraftfahrzeugsteuergera-

te. Doktorarbeit, Universitat Stuttgart, 2008.

[20] Michael Brost, Gerd Baumann und Hans-Christian Reuss. UML-

basierte Testfallerzeugung fur Karosseriesteuergerate. In Clemens

Guhmann, (Hrsg.), Simulation und Test in der Funktions- und Soft-

wareentwicklung fur die Automobilelektronik II. Expert-Verlag, 2008.

[21] Colin Campbell, Wolfgang Grieskamp, Lev Nachmanson, Wolfram

Schulte, Nikolai Tillmann und Margus Veanes. Model-Based Testing

of Object-Oriented Reactive Systems with Spec Explorer. Microsoft

Research, 2005.

[22] Conformiq. Conformiq Qtronic SG - Semantics and Algorithms for

Test Generation. Conformiq Software Ltd., 2008.

[23] Hansjorg Dach, Wolf-Dieter Gruhle und Peter Kopf. Pkw-

Automatgetriebe. In Bibliothek der Technik, Band 88. Verlag Moderne

Industrie, 2001.

[24] Daimler. CTE-XL. www.systematic-testing.com.

[25] Christof Ebert und Reiner Dumke. Software-Metriken in der Praxis.

Springer Verlag, 1996.

[26] Sven Efftinge, Peter Friese, Arno Haase, Dennis Hubner, Clemens Ka-

dura, Bernd Kolb, Jan Kohnlein, Dieter Moroff, Karsten Thoms, Mar-

kus Volter, Patrick Schonbach, Moritz Eysholdt, Dennis Hubner und

Steven Reinisch. openarchitectureware user guide version 4.3.1, 2008.

[27] William J. Gilbert. Modern Algebra with Applications. John Wiley &

Sons, 1976.

[28] M. R. Girgis und M. R. Woodward. An experimental comparison of

the error exposing ability of program testing criteria. In Workshop

Software Testing, 1986.

145

[29] Matthias Grochtmann, Klaus Grimm und Joachim Wegener. Tool-

supported test case design for black-box testing by means of the

classification-tree editor. European Int. Conf. on Software Testing,

Analysis and Review (EuroStar ’93), 1:169–176, 1993.

[30] Jurgen Großmann. Integration von Testsprachen und Werkzeugen.

In 1. AutoTest Fachkonferenz: Test von Hard- und Software in der

Automobilentwicklung. FKFS, 25. - 26. Oktober 2006.

[31] David Harel. A visual formalism for complex systems. Science of

Computer Programming, 8(3):231–274, June 1987.

[32] Dirk W. Hoffmann. Software-Qualitat. Springer Verlag, 2008.

[33] Wolfhard Lawrenz. CAN Controller Area Network - Grundlagen und

Praxis, volume 5. Huthig, 2007.

[34] Eckard Lehmann. Time Partition Testing - Systematischer Test des

kontinuierlichen Verhaltens von eingebetteten Systemen. Doktorar-

beit, Universitat Berlin, 2003.

[35] Peter Liggesmeyer. Software-Qualitat. Spektrum Akademischer Verlag

Heidelberg Berlin, 2002.

[36] Heiko Lotzbeyer. Modellbasierte Testfallermittlung fur eingebettete

Systeme in sicherheitskritischen Anwendungen. Doktorarbeit, Uni-

versitat Munchen, 2003.

[37] Markus Muller, Klaus Hormann, Lars Dittmann und Jorg Zimmer.

Automotive SPICE in der Praxis. dpunkt.verlag, 2007.

[38] Bernd Oestereich. Analyse und Design mit UML 2.1. Objektorientierte

Softwareentwicklung. Oldenbourg, 2006.

[39] Norbert Oster. Automatische Generierung optimaler struktureller

Testdaten fur objekt-orientierte Software mittels multi-objektiver Me-

taheuristiken. Doktorarbeit, Friedrich-Alexander-Universitat Erlan-

gen-Nurnberg, Erlangen, 2007.

[40] Carsten Paulus, Michael Wolff, Peter Feulner und Hans-Christian

Reuss. Ein neues Framework zum Testen von Kfz-Steuergerate-

Software. In 2. AutoTest Fachkonferenz: Test von Hard- und Software

in der Automobilentwicklung, 22. - 23. Oktober 2008.

146

[41] Carsten Paulus, Michael Wolff und Hans-Christian Reuss. Strategien

zur Testfallgenerierung aus UML-Zustandsautomaten. In Haus der

Technik: Tagung Hardware-in-the-Loop-Simulation, September 2008.

[42] Madhav S. Phadke. Quality Engineering Using Robust Design. Pren-

tice Hall, 1989.

[43] Madhav S. Phadke. Planning Efficient Software Tests. www.phadke-

associates.com, 2010.

[44] Alexander Pretschner. Zum modellbasierten funktionalen Test reakti-

ver Systeme. Doktorarbeit, Universitat Munchen, 2003.

[45] Eric T. Ray. Einfuhrung in XML. O’Reilly, 2004.

[46] Eike Hagen Riedemann. Testmethoden fur sequentielle und nebenlau-

fige Software- Systeme. Vieweg + Teubner, 1998.

[47] Jorg Schauffele und Thomas Zurawka. Automotive Software Enginee-

ring. Vieweg Verlag, 2003.

[48] Carsten Sensler, Michael Kunz und Peter Schnell. Testautomatisie-

rung mit modellgetriebener Testskript-Entwicklung. Objektspektrum,

03, 2006.

[49] Thomas Stahl und Markus Volter. Modellgetriebene Softwareentwick-

lung. dpunkt.verlag, 2005.

[50] Dave Steinberg, Frank Budinsky, Marcelo Paternostro und Ed Merks.

EMF Eclipse Modeling Framework. Addison Wesley, 2008.

[51] Manfred Broy und Ralf Steinbruggen. Modellbildung in der Informa-

tik. Springer Verlag, 2004.

[52] Andreas Spillner und Thilo Linz. Basiswissen Softwaretest. dpunkt.-

verlag, 2007.

[53] Krzysztof Czarnecki und Ulrich W. Eisenecker. Generative Program-

ming: Methods, Tools, and Applications. Addison Wesley, 2000.

[54] Mark Utting und Bruno Legeard. Practical Model-Based Testing. Mor-

gan Kaufmann, 2007.

[55] Frank Westphal. Testgetriebene Entwicklung mit JUnit und FIT: Wie

Software anderbar bleibt. dpunkt.verlag, 2005.

147

[56] Alan W. Williams. Determination of test configurations for pair-wise

interaction coverage. In IFIP TC6/WG6.1 13th International Confe-

rence on Testing Communicating Systems (Test-Com 2000), pp. 59-

74, 2000.

148

Lebenslauf

Personliche Daten

Name Carsten Paulus

Geburtsdatum 24.11.1978

Geburtsort Stuttgart

Familienstand verheiratet

Schulbildung

1985 - 1989 Altenburg Grundschule, Stuttgart-Bad Cannstatt

1989 - 1998 Johannes Kepler Gymnasium, Stuttgart-Bad Cann-

statt

1998 Abitur

Zivildienst

1998 - 1999 Zivildienst im Rettungsdienst des Deutschen Roten

Kreuzes Stuttgart

Studium

1999 - 2005 Studium des Maschinenwesens an der Universitat

Stuttgart

21.12.2005 Abschluss als Diplom-Ingenieur

Berufstatigkeit

seit 2006 Wissenschaftlicher Mitabeiter am Forschungs-

institut fur Kraftfahrwesen und Fahrzeugmotoren

Stuttgart (FKFS)

seit 2009 Entwicklungsingenieur bei der ZF Friedrichshafen

AG

149