Methodisches und automatisiertes Testen von Kfz-Steuergeräte-Software

Größe: px
Ab Seite anzeigen:

Download "Methodisches und automatisiertes Testen von Kfz-Steuergeräte-Software"

Transkript

1 Methodisches und automatisiertes Testen von Kfz-Steuergeräte-Software Von der Fakultät Konstruktions-, Produktions- und Fahrzeugtechnik der Universität Stuttgart zur Erlangung der Würde eines Doktor-Ingenieurs (Dr.-Ing.) genehmigte Abhandlung vorgelegt von Carsten Paulus aus Stuttgart/Bad Cannstatt Hauptberichter: Mitberichter: Prof. Dr.-Ing. Hans-Christian Reuss Prof. Dr. Dr. h.c. Manfred Broy Tag der mündlichen Prüfung: Institut für Verbrennungsmotoren und Kraftfahrwesen Universität Stuttgart 2011

2

3 Vorwort Die vorliegende Arbeit entstand während meiner Tätigkeit als wissenschaftlicher Mitarbeiter am Forschungsinstitut für Kraftfahrwesen und Fahrzeugmotoren Stuttgart in Zusammenarbeit mit der ZF Friedrichshafen AG. Mein besonderer Dank gilt Herrn Prof. Dr.-Ing. Hans-Christian Reuss für die Betreuung der Arbeit. Bei Herrn Prof. Dr. Dr. h.c. Manfred Broy möchte ich mich für die freundliche Übernahme des Mitberichts bedanken. Dank gebührt an dieser Stelle auch Herrn Peter Feulner, Herrn Michael Wolff und Herrn Udo Gillich, welche das der Arbeit zugrundeliegende Projekt seitens der ZF Friedrichshafen AG erst möglich gemacht haben. Ferner möchte ich mich bei Herrn Dr.-Ing. Gerd Baumann bedanken, welcher meine Arbeit seitens des FKFS unterstützt und gefördert hat. Ein weiterer Dank gilt meinen Kollegen am FKFS und bei der ZF Friedrichshafen AG, welche mich im Laufe der Arbeit immer wieder motiviert und auf neue Gedanken gebracht haben. Danken möchte ich auch meinen Diplomanden und Praktikanten Tobias Bollmann, Ricard Lou, Ping Zheng und Nico Gau. Ferner möchte ich meinen Korrekturlesern danken, insbesondere Frau Stefanie Korte. Zu guter Letzt möchte ich meiner Familie danken, meinen Eltern Edith und Gerd Paulus, die mich immer begleiten. Ein herzlicher Dank gebührt meiner Frau Jana für die Unterstützung und das Verständnis, welches sie mir während dieser Arbeit entgegengebracht hat. Friedrichshafen, Oktober 2011 Carsten Paulus 3

4 Inhaltsverzeichnis Abkürzungsverzeichnis 8 Kurzfassung 11 Abstract Einleitung Motivation Methoden und Werkzeuge zum Testen Beitrag Beitrag durch das Framework Beitrag durch die methodische Testsequenzerstellung Beitrag durch die formale Testbeschreibung Beitrag durch die Adaption an die Plattformen Erwarteter Nutzen Aufbau der Arbeit Prozesse, Methoden und Werkzeuge Aufgaben und Aufbau der Software Softwareentwicklungs- und Testprozess Entwicklungsparadigmen Steuerungs- und regelungstechnische Aspekte Kommunikation Berücksichtigung der Hardware Programmierung Modelle in der Softwareentwicklung Unified Modeling Language Klassendiagramm Zustandsdiagramm Extensible Markup Language Generative Programmierung Model Driven Architecture

5 Model Driven Software Development Nutzen der Vorgehensweise Relevanz für den Test Potenzielle Softwarefehler Testentwurfsmethoden Statische Testentwurfsmethoden Dynamische Testentwurfsmethoden White-box Testentwurfsmethoden Kontrollflussbezogene Kriterien Datenflussbezogene Kriterien Bewertung Black-box Testentwurfsmethoden Äquivalenzklassenbildung Auswahlstrategien Zustandsbasierter Test Erfahrungsbasiertes Testen Aufgabenstellung Testframework Artefakte aus dem Entwicklungsprozess Strukturartefakte Verhalten Daten Technologische Realisierung Das Testspezifikations-Meta-Modell Das Testbericht Meta-Modell Codegenerierung Zusammenfassung Leitanwendung Physikalische Grundlagen Software-Design und Implementierung Klassendiagramm Zustandsdiagramm Testausführungsplattform Aufgaben für die Testimplementierung

6 5. Heuristik zur modellbasierten Testsequenzgenerierung Prinzip der Testsequenzgenerierung aus Zustandsmaschinen Generierungsstrategien Auffindbare Fehler Auswahl einer Strategie zur Testsequenzgenerierung Umgang mit erweiterten endlichen Zustandsmaschinen Auflösen von Hierarchie Auflösen von Orthogonalität Integration in das Framework Allgemeine Schnittstelle der Heuristik Verfügbare Artefakte der Leitanwendung Konzeption des Exchange-Meta-Modells Instanziierung der Leitanwendung Heuristik Bedatung Berechnung der Initialisierungs-Testsequenz Berechnung der Transitionsüberdeckung Vervollständigung der Transitionsfolgen Umgang mit Superzuständen Umgang mit orthogonalen Zuständen Zusammenfassung der strukturellen Aspekte Synthese von Bedatung und Struktur Überführen der Testspezifikation in ausführbaren Code Anwendung Einsatz des Testframeworks Methoden und deren Einbindung Formale Testspezifikation und Transformation Nutzen und Potenziale Zusammenfassung und Ausblick 131 A. Algorithmen zur Testsequenzinitialisierung 134 A.1. Dijkstra-Algorithmus B. Entwicklung des Algorithmus zur Transitionsüberdeckung138 6

7 Abbildungsverzeichnis 141 Tabellenverzeichnis 142 Literaturverzeichnis 144 7

8 Abkürzungsverzeichnis Abkürzungen ATML CASE COM DSL EGS EMF FUT HIL IDE MDA MDSD MIL MISRA MM MOF oaw OMG RCP SIL SMUT SUT TS-MM UML Automatic Test Markup Language Computer-Aided Software Engineering Component Object Model Domain Specific Language Elektronische Getriebesteuerung Eclipse Modeling Framework Function Under Test Hardware-In-The-Loop Integrated Development Environment Model Driven Architecture Model Driven Software Development Model-In-The-Loop The Motor Industry Software Reliablity Association Meta-Modell Meta Object Facility open Architecture Ware Object Management Group Rapid Control Prototyping Software-In-The-Loop State-Machine Under Test System Under Test Testspezifikations-Meta-Modell Unified Modeling Language 8

9 UML XML Unified Modeling Language Extensible Markup Language Formelzeichen F L i O Menge der Faktoren F i, welche den Eingangsgrößen des SUT entsprechen Menge der Level l, welche einem Faktor F i zugeordnet sind Auswahlmatrix EM Testmodell EM = SM, S, T, R, W SM S T R W E G A V S V T B Wurzelelement der Zustandsmaschine Menge der Zustände s der Zustandsmaschine Menge der Transitionen t der Zustandsmaschine Menge der Regionen r der Zustandsmaschine Menge der WerteBereich-Elemente w des Testmodells Menge von Ereignissen e. Die Ereignisse E S sind einem Zustand zugeordnet, die Ereignisse E T einer Transition Menge von Guard-Bedingungen g. Die Guard-Bedingungen G S sind einem Zustand zugeordnet, die Guard- Bedingungen G T einer Transition Menge von Aktionen a. Die Aktionen A S sind einem Zustand zugeordnet, die Aktionen A T einer Transition Verhaltensspezifikation eines Zustandes Verhaltensspezifikation einer Transition Menge von Bedatungskombinationen b 9

10 Mengenoperationen A B card (A) oder A A B A B A B = A ist Teilmenge von B Kardinalzahl der Menge A, sie bezeichnet die Anzahl der Elemente einer endlichen Menge Vereinigung der Mengen A und B. A B = {x x A x B}. Es werden keine doppelten Elemente zugelassen Durchschnitt der Mengen A und B. A B = {x x A x B}, entspricht den gemeinsamen Elementen der beiden Mengen Die Mengen A und B sind disjunkt, sie haben kein gemeinsames 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} A 1 A n n-faches Kartesisches Produkt. A 1 A n = {(a 1,, a n ) a i A i (i = 1,, n)} Sonstige x x mod y Gaußklammer: max k Z,k x (k). Dabei ist k die größte ganze Zahl, welche kleiner oder gleich x ist Ganzzahliger Rest der Divisison. x mod y = x y x y 10

11 Kurzfassung Moderne Fahrzeuge beinhalten eine stetig wachsende Vielzahl von mechatronischen Systemen, deren Verhalten durch Steuergeräte bestimmt wird. Die Innovationen in der Fahrzeugtechnik werden also in immer größerem Maße durch die Software dieser Steuergeräte geprägt. Der wachsende Innovationsdruck, einhergehend mit immer kürzer werdenden Entwicklungszeiten, fordert die Hersteller auf, qualitativ hochwertige Software immer effektiver zu erstellen. Zur Beherrschung der Komplexität werden formale Entwicklungsprozesse definiert, um den Software- Entwicklern und Testern das Zusammenspiel der Arbeitsschritte vorgeben zu können. Der Fokus der vorliegenden Arbeit liegt auf dem Testen von Kfz-Steuergeräte-Software im Rahmen der Software-Entwicklung eines Automobilzulieferers. In der Praxis gibt es verschiedene Möglichkeiten, die formalen Entwicklungsprozesse umzusetzen. Häufig werden für die Erfüllung gleicher Arbeitsschritte unterschiedliche, nicht notwendigerweise kompatible Softwarewerkzeuge verwendet. Es hat sich gezeigt, dass Testentwurfsmethoden implizit und intuitiv angewendet werden. Der Einsatz von Werkzeugen zur Unterstützung der Tester scheitert entweder an einer fehlenden Implementierung oder daran, dass ein gegebenes Werkzeug nicht in die vorgegebene Entwicklungslandschaft integriert werden kann. Um diesem Umstand entgegenzuwirken, wird im Rahmen der vorliegenden Arbeit ein Testframework konzipiert, welches die nahtlose Integration unterschiedlicher Testfallerstellungswerkzeuge in den Entwicklungsprozess ermöglicht. Ferner wird eine Heuristik entwickelt, welche die automatisierte Erstellung von Testfällen für zustandsbasiertes Verhalten erleichtert. 11

12 Abstract Modern vehicles contain an increasing multitude of mechatronic systems, whose behavior is determined by electronic control units. Hence innovations in cars are more and more influenced by the software within these control units. The increasing pressure to innovate in combination with decreasing product 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 interaction 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 intuitively. 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 enables the seamless integration of different test-tools into the developmentenvironment. Furthermore a heuristic method is developed, which facilitates the automated generation of test-cases for state-based softwarebehavior. 12

13 1. Einleitung Das Ziel der vorliegenden Arbeit ist es einen Ansatz aufzuzeigen, um die Qualität und Effizienz in der Softwareentwicklung zu steigern. Dazu wird die methodische Testsequenzerstellung in den Softwareentwicklungsprozess eines Automobilzulieferers integriert Motivation Heutzutage sind bis zu 90 % der Innovationen eines modernen Fahrzeuges durch Elektronik geprägt [47]. Die eigentlichen Funktionen der Elektronik sind dabei durch Software implementiert. Dadurch wird diese zunehmend zum bestimmenden Faktor für die Qualität und Sicherheit des gesamten Fahrzeuges. Der zunehmende Innovations- und Kostendruck bedingt, dass neue, komplexere Funktionen in immer kürzerer Zeit zur Serienreife gebracht werden müssen. Um die Qualitäts- und Sicherheitsanforderungen, wie sie beispielsweise durch die IEC gefordert werden, zu erfüllen und die Komplexität der Softwareentwicklung beherrschen zu können, werden Referenzmodelle, wie Automotive-Spice [37], und Vorgehensmodelle, wie das allgemeine V-Modell [14], eingeführt. Im Rahmen der Entwicklung müssen bis zu 50 % des Gesamtaufwandes für den Test der Software eingesetzt werden [52]. Eine Optimierung des Testprozesses hat daher ein hohes Einsparpotenzial. Der Testprozess besteht nach [52] aus den fünf Phasen Testmanagement, Testspezifikation, Testausführung, 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-Kapazitiät beanspruchen. Basierend auf einer lauffähigen Testinfrastruktur beziehen sich die meisten Ansätze zur Minimierung des Testaufwandes bis jetzt auf die Automatisierung der Testausführung. Dabei werden für die jeweils verwendeten Testausführungsplattformen Automatisierungsskripte geschrieben. Die Testinhalte sind da- 13

14 bei in plattformspezifischen Codeartefakten verborgen und können häufig nur von Experten verstanden werden. Eine Modifikation oder der Wechsel der Ausführungsplattform führt dazu, dass die Testskripte angepasst werden müssen. Durch die Automatisierung der Bereitstellung der Testinfrastruktur und der Testausführung lässt sich eine Effizienzsteigerung im Test erzielen. Der Testinhalt und damit die Fähigkeit einer Testsequenz, bestimmte Fehler aufzudecken, wird jedoch in der Testspezifikation festgelegt. In der Theorie existieren verschiedene Methoden zum Testentwurf, welche die Softwaretester in dieser Phase unterstützen. Ein Einsatz dieser Methoden in der Praxis scheitert oft daran, dass sie entweder den Entwicklern unzureichend bekannt sind, nicht als Software-Werkzeug realisiert sind, oder das implementierte Software-Werkzeuge nicht in die vorhandene Entwicklungslandschaft integriert sind. Die Steigerung der Test-Qualität kann also durch die Integration von Testentwurfsmethoden in den Entwicklungsprozess erzielt werden. Aus dieser Betrachtung ergeben sich die Eingriffsmöglichkeiten, um eine Qualitäts- und Effizienzsteigerung im Test und damit in der Softwareentwicklung zu erzielen: 1. Die Einbindung von Testentwurfsmethoden in den Entwicklungsprozess. 2. Die Unterstützung bei der Bereitstellung der Testinfrastruktur. 3. Die plattformunabhängige Abstraktion der Testinhalte, und die Unterstützung diese auf verschiedenen Testausführungsplattformen automatisiert ausführen zu können Methoden und Werkzeuge zum Testen Im Rahmen der Einbindung von Testentwurfsmethoden in den Entwicklungsprozess sind bereits Software-Werkzeuge entstanden, eine Auswahl dieser wird im Folgenden vorgestellt. Um die Werkzeuge klassifizieren zu können, wird im Vorgriff auf den Abschnitt 2.6 eine kurze Einführung der Testentwurfsmethoden gegeben. 14

15 Das Testen von Software kann statisch oder dynamisch erfolgen. Im statischen Fall wird die Software ohne eine Ausführung geprüft, beispielsweise durch formale Reviews. Beim dynamischen Test wird die Software aktiv stimuliert. Die Art und Weise, wie die Stimuli ausgewählt werden, also wie die Testfälle aufgebaut sind, kann basierend auf der Kenntnis der Implementierung erfolgen: Es handelt sich dann um white-box oder strukturelle Testentwurfsmethoden. Wenn die Testfälle aus der Kenntnis der Spezifikation der Software ausgewählt werden, handelt es sich um black-box oder funktionale Testentwurfsmethoden. Die white-box Testentwurfsmethoden werden anhand des Testziels der Testfälle untergliedert. So wird, ohne Anspruch auf Vollständigkeit, zwischen einer Anweisungs-, Zweig-, Bedingungs- und Pfadüberdeckung unterschieden. Beispielsweise werden bei dem Ziel der Erreichung einer Anweisungsüberdeckung die Stimuli so gewählt, dass alle Anweisungen mindestens einmal ausgeführt werden. In der Praxis wird in der Prozess-Phase Testmanagement ein für das zu testende Artefakt zu erreichender Überdeckungsprozentsatz und das Überdeckungskriterium formuliert. Während die Stimuli großteils manuell durch Testskripte erzeugt werden, kann die erreichte Überdeckung der Implementierung durch Softwarewerkzeuge gemessen werden. Ein Ansatz zur automatisierten Generierung von white-box Tests wird durch [39] vorgestellt. Dabei werden basierend auf der Kenntnis des Quellcodes automatisch Teststimuli generiert, welche zu einer vorgegebenen Codeüberdeckung führen. Wichtige Vertreter der black-box Testentwurfsmethoden sind die Äquivalenzklassenbildung und die Grenzwertanalyse. Davon ausgehend, dass die Uniformitätshyphotese gilt und sich das System für eine bestimmte Äquivalenzklasse von Eingabewerten gleich verhält, werden die Eingabeparameter eines Systems diesen Klassen zugeordnet. Die Übergänge zwischen den Äquivalenzklassen sind Grenzwerte, welche häufige Fehlerquellen sind. Die 1993 vorgestellte Klassifikationsbaummethode [29] stellt einen Ansatz zur Systematisierung der Findung von Äquivalenzklassen und Grenzwerten dar, durch deren Kombination verschiedene Testfälle bestimmt werden können. Die theoretischen Grundlagen werden durch das Werkzeug CTE- XL [24] implementiert. 15

16 Ferner sind im Rahmen der black-box Testentwurfsmethoden unter dem Schlagwort modellbasiertes Testen eine Vielzahl von Ansätzen entstanden. Diese ziehen analog zu den white-box Testentwurfsmethoden die Struktur des zugrunde gelegten Verhaltensmodells der Software als Basis für die Testsequenzauswahl heran. Dieser Vorgang lässt sich algorithmisch automatisieren. Ein wesentliches Unterscheidungsmerkmal der Ansätze zum modellbasierten Testen ist das zugrunde liegende Modell. Eine Klasse von Ansätzen basiert z. B. auf einer Modellierung durch Endliche Zustandsmaschinen (Finite State Machines - FSM). Im Rahmen der Forschung der Firma Microsoft ist dabei das Werkzeug specexplorer [21] entstanden, welches mittlerweile in einigen Teilen des Konzerns eingesetzt wird. Das Modell der zu testenden Software wird dabei durch die dafür entwickelte Sprache Spec# beschrieben. Andere Ansätze setzen Beschriftete Übergangssysteme (Labeled Transition Systems - LTS) voraus. Eine kommerzielle Implementierung dieser Vorgehensweise stellt die Firma Conformiq zur Verfügung [22]. Eine weitere Modellierungsform beruht auf Erweiterten endlichen Zustandsmaschinen (Extended Finite State Machines - EFSM) nach Harel [31], welche in modernen Modellierungssprachen Verwendung finden, wie UML oder MATLAB/SIMULINK. Die grundsätzlich zu beachtenden Aspekte beim modellbasierten Testen werden in [44] aufgeführt. Wenn eine automatische Verdiktbildung stattfinden soll, darf das Modell, aus welchem die Testfälle abgeleitet werden, nicht das Gleiche sein, wie das Modell, aus welchem die Implementierung abgeleitet wird. Andernfalls würde nur der Codegenerator geprüft. Es entstünden also keine Testfälle, welche einen größeren als den im Modell definierten Einblick in die Funktion bieten. In [36] wird ein systematischer Ansatz erarbeitet, welcher das in der Sprache Auto Focus beschriebene Modell der Implementierung in ein Analysemodell überführt. Die Informationen aus dem Analysemodell werden in ein Constraint-Logik Programm überführt. Basierend auf dieser Darstellung werden Testsequenzen berechnet. Die innerhalb der Zustandsmaschinen auftretenden Transitionen sind an Parameter gebunden, welche durch Äquivalenzklassen und Grenzwerte aufgeteilt werden können. Um dies zu 16

17 systematisieren, wird der Klassfikationsbaumeditor CTE-XL in den Ansatz eingebunden. Im Rahmen der Arbeit [20] wird vorgeschlagen, als Modellierungssprache die UML zu verwenden, insbesondere UML-Protokollzustandsautomaten. Auch nebenläufige Funktionen, welche durch die Protokollzustandsautomaten beschrieben werden können, werden in die Testsequenzerstellung mit einbezogen. Dazu wird ein mehrstufiger Prozess durchlaufen. Zunächst wird das UML-Modell in eine Datenstruktur eingelesen. Orthogonale Zustände werden in einen Produktautomaten überführt, welcher das Verhalten in einer flachen Struktur beschreibt. Die Testsequenzerstellung erfolgt durch Graphentraversierungsalgorithmen (Tiefen- und Breitensuche). Häufig scheitert der effiziente Einsatz vorhandener Software-Werkzeuge daran, dass Informationen aus dem Entwicklungsprozess erneut eingegeben werden müssen und methodisch erstellte Testfälle im Rahmen der vorgegebenen Entwicklungslandschaft nicht maschinell weiterbearbeitet werden können. Zudem zeigt die vorliegende Aufzählung verschiedener Software- Werkzeuge, dass insbesondere Werkzeuge zum modellbasierten Testen eigene Modellierungssprachen voraussetzen, welche für den Einsatz unter den Anwendern etabliert werden müssen Beitrag Um die in Abschnitt 1.1 beschriebenen Eingriffsmöglichkeiten für die Effizienz- und Qualitätssteigerung im Softwareentwicklungsprozess zu nutzen, wird im Rahmen der vorliegenden Arbeit ein Framework erarbeitet, welches konzeptionell und technologisch die Integration verschiedener black-box Testentwurfsmethoden in den Entwicklungsprozess ermöglicht. Dabei wird sowohl die Bereitstellung der Testinfrastuktur als auch die Abstraktion und automatische Ausführung der Testinhalte unterstützt. Ferner wird eine Heuristik zum modellbasierten Testen eingeführt, welche durch das Framework an die in der Entwicklungslandschaft verwendeten Modellierungssprachen angepasst werden kann. 17

18 Das Framework besteht dabei aus drei Schichten: Methodenschicht: Methoden zum Testentwurf werden integriert. Durch Transformationsregeln können entweder kommerzielle oder im Rahmen der Arbeit entstandene Testsequenzerstellungswerkzeuge initialisiert werden. Ausgabe dieser Schicht sind abstrakte, formalisierte Testbeschreibungen. Formale Testbeschreibung: Durch Transformationsregeln werden die Testbeschreibungen unterschiedlicher Herkunft in eine einheitliche formale Testbeschreibung überführt. Diese dient zur Kommunikation der eigentlichen Testinhalte und kann beispielsweise durch Bedatung weiter konkretisiert werden. Adaption an Ausführungsplattformen: Die formal beschriebenen Testfälle werden mit Hilfe einer weiteren Transformation an die jeweils vorgesehene Testausführungsplattform angepasst Stand der Technik und Beitrag durch das Framework Die generelle Struktur einer solchen Integration zeichnet sich in ähnlicher Form in verschiedenen Veröffentlichungen ab. So zeigt [30] einen Ansatz auf, welcher aus den Werkzeugen CTE und TPT (Time-Partition- Testing [34]) erstellte Testfälle entgegennimmt und diese in die Sprache TTCN-3 transformiert, um diese dann zur Ausführung zu bringen. Das von der Firma Leirios erarbeitete Werkzeug Leirios Testgenerator, dessen Methode neben anderen Ansätzen in [54] ausführlich beschrieben ist, beruht auf UML-Modellen und generiert die Testfälle in einem speziellen XML- Schema. In [48] wird ein kaskadiertes, MDA (Model Driven Architecture) basiertes Vorgehen beschrieben. Dabei wird für die Domäne GUI-Testen (Graphical User Interface) eine domänenspezifische Sprache zur Formulierung der Testinhalte erarbeitet, welche durch Transformation auf einer spezifischen Plattform zur Ausführung gebracht wird. Für die Implementierung wird openarchitectureware (oaw) [1], eine Open Soruce Implementierung der MDA, verwendet. 18

19 Das im Rahmen der Arbeit entstandene Framework geht konzeptionell über diese Ansätze hinaus, indem es zur Initialisierung der Testsequenzerstellungswerkzeuge Informationen aus dem Entwicklungsprozess verwendet. Es basiert ebenfalls auf der MDA und verwendet für die Implementierung oaw. Ein Beitrag besteht darin, die Konzepte für das Einsatzgebiet der automobilen Software-Entwicklung zu adaptieren Stand der Technik und Beitrag durch die methodische Testsequenzerstellung Um den Einsatz des modellbasierten Testens zu ermöglichen, wird innerhalb des Frameworks eine Heuristik entwickelt, welche es dem Testingenieur ermöglicht, die Testsequenzgenerierung intuitiv zu steuern. Die Zielsetzung ist hierbei ein Migrationsszenario, welches einen iterativen Aufbau der automatisch generierten Testspezifikation ermöglicht, um den Einblick und das Vertrauen in die zugrundeliegenden Algorithmen zu stärken. Während bei den bekannten Ansätzen, basierend auf UML-Zustandsmaschinen, die Strukturierungselemente Hierarchie und Parallelität zunächst aufgelöst werden, wird im Rahmen der vorliegenden Arbeit ein expliziter Erhalt dieser Strukturierung angestrebt. Diesem Vorgehen liegt die Annahme zugrunde, dass die Entwicklungsingenieure mit dem Einsatz der Strukturierung spezifische Aufgabenaspekte der Implementierung im Fokus haben. Wenn diese durch die Testsequenzgenerierung verloren gehen, ist es nur mit großem Aufwand möglich aufzuzeigen, welchen Bezug die Testsequenzen zu dem Testmodell haben. Mit Hierarchie wird folgendermaßen umgegangen: Die Heuristik identifiziert den Initialknoten der hierarchisch untergeordneten Zustandsmaschine und behandelt diese als unabhängiges Modell für die Testsequenzgenerierung. Ferner identifiziert die Heuristik die strukturellen Verknüpfungen des hierarchischen Unterzustandes und ermöglicht somit die Erstellung der Testsequenzen für das Gesamtsystem. Die aus dem ursprünglichen Modell vorgegebene Hierarchie wird dadurch in den generierten Testfällen beibehalten, wodurch dem Testingenieur die gezielte Zuordnung von Testsequenz zu Testmodell ermöglicht wird. 19

20 Während ein gebräuchlicher Ansatz zum Umgang mit Orthogonalität innerhalb eines UML-Zustandsmaschinen für die Testsequenzgenerierung darin besteht, alle möglichen Zustandskombinationen (Konfigurationen) zu bestimmen, wird dieses Kombinationsproblem im Rahmen der Arbeit neuartig gelöst Stand der Technik und Beitrag durch die formale Testbeschreibung Durch die plattformunabhängige Beschreibung der Testspezifikation ergibt sich die Möglichkeit, diese auf unterschiedlichen Teststufen zur Ausführung zu bringen. Die Testentwurfsmethoden können also bedarfsgerecht in verschiedenen Entwicklungsphasen eingesetzt werden. Im Rahmen der Arbeit wird ein proprietäres XML-Schema für die Beschreibung der Testspezifikation verwendet. Derzeit sind aber verschiedene Standardisierungsvorhaben in Arbeit. So wird im Rahmen der Herstellerinitiative Software [8] ein XML-basiertes Testaustauschformat erarbeitet. Innerhalb der IEEE wird unter der Abkürzung ATML (Automatic Test Markup Language) [3] an dem Standard IEEE 1671 gearbeitet. Durch den Einsatz eines solchen Testaustauschformates können Testbibliotheken aufgebaut werden und ein gezieltes wiederverwenden von Testsequenzen wird möglich. Erfahrungswissen der Tester kann in diesen Bibliotheken ebenfalls abgelegt werden. Der Einsatz einer formalen Beschreibung ermöglicht es, die im Laufe der Zeit erarbeiteten Best-Practices beim Testen zu formalisieren und zu konservieren. Es bleibt zu berücksichtigen, dass die Testbibliotheken vor dem Einsatz in einem geänderten Kontext, ähnlich wie bei der komponentenbasierten Softwareentwicklung, auf ihre Eignung hin zu prüfen sind Stand der Technik und Beitrag durch die Adaption an die Ausführungsplattformen Abhängig von der Teststufe kommen unterschiedliche Testausführungsplattformen zum Einsatz. Nicht selten werden die Automatisierungsskripte 20

21 einer spezifischen Ausführungsplattform auch noch projektspezifisch variiert. Ein Standard-Codegenerator ist damit in der Praxis kaum realisierbar. Im Rahmen des Frameworks wird die Plattformadaption durch eine Modell-zu-Code Transformation realisiert. Dabei ist es möglich, ausführungsplattform- und projektspezifische Testskriptvorlagen anzulegen, welche durch Transformationsregeln mit den in der formalen Testbeschreibung erfassten Informationen ergänzt werden Erwarteter Nutzen Durch den Einsatz des Testframeworks wird die werkzeuggestützte methodische Testsequenzerstellung im Rahmen der vorgegebenen Entwicklungsprozesse ermöglicht. Durch das methodische Vorgehen wird eine Qualitätssteigerung der Testprozesse ermöglicht. Diese wird vor allem durch den dokumentierten Einsatz von Methoden beim Testentwurf erzielt. Es kann verhindert werden, dass Testsequenzkombinationen vergessen werden. Ferner bedingt das Framework als durchgängig geschlossene Werkzeugkette eine Effizienzsteigerung bei der Erstellung und Ausführung von Testfällen 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-Steuergeräte-Software. In Kapitel 2, werden die Prozesse, Methoden und Werkzeuge in diesem Umfeld beschrieben. Daraus resultiert die Aufgabenstellung der Arbeit Testentwurfsmethoden möglichst generisch in den Software-Entwicklungsprozess integrieren zu können. In Kapitel 3 wird das zur Lösung der Aufgabenstellung konzeptionierte Testframework und dessen Bestandteile vorgestellt. Aufgrund der Vielfältigkeit des Arbeitsgebietes 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 Testsequenzgenerierung 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

22 2. Prozesse, Methoden und Werkzeuge Im Rahmen dieses Kapitels werden die Randbedingungen der Softwareentwicklung in der Automobilindustrie dargestellt, um den Beitrag dieser Arbeit einordnen zu können. Zunächst werden in Abschnitt 2.1 die Aufgaben und der prinzipielle Aufbau von Software in der Domäne Automobil eingeführt. In Abschnitt 2.2 wird der Softwareentwicklungs- und Testprozess vorgestellt. Für die Erstellung der Steuergerätesoftware kommen verschiedene Entwicklungsparadigmen zum Einsatz, welche in Abschnitt 2.3 erörtert werden. Die Betrachtung der potenziellen Softwarefehler in Abschnitt 2.5 erleichtert die Auswahl von Testfallerstellungsmethoden, welche in Abschnitt 2.6 aufgeführt werden. Vor diesem Hintergrund können Anforderungen an das effizientere Testen von Software gestellt werden, welche in Abschnitt 2.7 zusammengefasst werden Aufgaben und Aufbau der Software Ein modernes Fahrzeug besteht aus einer Vielzahl mechatronischer Systeme. Diese sind dadurch gekennzeichnet, dass sie Mechanik, Elektronik und ein elektronisches Steuergerät vereinen. Das Steuergerät enthält in der Regel einen Mikrocontroller, der durch Software gesteuert wird. Ein solches System ist exemplarisch am Beispiel eines Automatikgetriebes [23] in Bild 2.1 dargestellt. Das mechanische Automatikgetriebe ist durch Aktoren und Sensoren mit dem elektronischen Steuergerät verbunden. Der Test der Software dieser Steuergeräte ist Gegenstand der vorliegenden Arbeit. Diese Software ist modular aufgebaut und besteht aus folgenden Bestandteilen: Modul: Kleinste ausführbare Einheit (Meist eine Klasse. Bsp.: Einstellung des Hydraulikdrucks). 22

23 Komponente: Zusammenstellung mehrerer Module zur Ausführung einer bestimmten Aufgabe (Bsp.: Fehlerbehandlung, Hydraulikansteuerung). Gesamtsoftware: Zusammenstellung aller Komponenten zu der im Steuergerät verwendeten Gesamtsoftware (Bsp.: Getriebesteuerung). Wählhebel Motordrehzahl Motormoment Anzeige Motoreingriff Diagnoseanschluss Drosselklappenstelung Programmschalter E S Kick-Down- Schalter Gesamtsoftware CAN-Bus Elektronisches Steuergerät Magnet- Ventile, Druckregler Abtriebsdrehzahl Turbinendrehzahl SW-Komponente Komponente 2 Komponente 1 Steuergeräte Software cx2 cx2 cregler Einschalten() cx1 MATLAB 1 In1 1 2 Out1 In2 Product UML SW-Modul cxn cregler p_ist Einschalten() Ausschalten() Aus Einschalten()/ Ausschalten()/ Ein Bild 2.1.: Aufbau von Steuergerätesoftware Softwareentwicklungs- und Testprozess Die Einführung von Vorgehensmodellen, wie dem allgemeinen V-Modell, hilft dabei, die Softwareentwicklung übersichtlich zu gestalten und die 23

24 Komplexität beherrschbar zu machen. Parallel zu der Entwicklung des ersten 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 trägt [10]. Daraus hat sich bis heute eine Familie von Referenzmodellen mit dem Namen Capability Maturity Model Integration (CMMI) entwickelt. Konkurrierend dazu ist seit 1998 das Referenzmodell Software Process Improvement and Capability Determination (SPICE) entstanden [37]. Seit 2001 wird die domänenspezifische Variante Automotive-Spice unter Federführung 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 Gesamt- Anforderungsanalyse Systemabnahme System- Anforderungsanalyse System- Architekturdesign Parallele Entwicklungsprozesse Hydraulik, Mechanik, Elektronik Software- Anforderungsanalyse Software-Design UML Zustandsdia gramme... MATLAB/ SIMULINK C/ C++ Software- Erstellung Testplanung Testmanagement 1) Warum, Was, Wo und Wann? Softwaretest 2) 3) 4) 5) Wie, Wie viel? Softwareintegration und Integrationstest 2) 3) 4) 5) Wie, Wie viel? Modultest 2) 3) 4) 5) Wie, Wie viel? Systemtest Systemintegration- und Integrationstest Applikation Legende: 1) Testplanung 2) Testspezifikation 3) Testdurchführung 4) Testprotokollierung 5) Testauswertung Projektmanagement Organisatorische und unterstützende Prozesse Lieferantenmanagement Konfigurations management Änderungsmanagement Qualitätssicherung Problemmanagement Bild 2.2.: Integration des Softwaretestprozesses in den Softwareentwicklungsprozess. V-Modells ist in Bild 2.2 dargestellt. Der aufgespannte Rahmen geht über die eigentliche Softwareentwicklung hinaus, der Fokus der Arbeit liegt allerdings auf der Softwareentwicklung. In der Software-Anforderungsanalyse 24

25 werden die Anforderungen an die zu erstellende Software erfasst. Sie stellen die Grundlage für das Software-Design dar. Das Grobdesign wird dabei in UML erstellt. Es wird entschieden, welche Funktionsblöcke vorhanden sein müssen und in welche Komponenten und Module sich die Software untergliedert. Das Feindesign, welches die eigentliche Funktion der einzelnen Module beschreibt, wird teilweise mit MATLAB/SIMULINK oder ebenfalls 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 Phase für jedes Modul ein Modultest aufzusetzen. In der Softwareintegration und dem Integrationstest geht es darum, die einzelnen Module zu funktionsfähigen Komponenten zu integrieren und sicherzustellen, dass deren Zusammenspiel funktioniert. Die zur Gesamtsoftware integrierten Komponenten 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 organisatorischen Aspekte des Testens berücksichtigt. Typische Tätigkeiten sind die Planung und Verteilung des Resourceneinsatzes (Wer soll wann auf welcher Umgebung welche Tests ausführen?). Weitere Aspekte sind die Auswahl der Teststrategie sowie die Festlegung der Testendekriterien. In der Testspezifikation (2) werden die Testinhalte abstrakt erstellt. In dieser Phase unterstützen Testentwurfsmethoden den Tester dabei, systematisch vorzugehen. Dies ist die für die Qualität der Tests wichtigste Phase, da der Inhalt der Testsequenzen festgelegt wird. In der Testausführung (3) werden die spezifizierten Tests zur Ausführung gebracht. Dazu ist es nötig, entsprechende Testumgebungen bereitzustellen und entweder Testskripte zu erstellen, um die Tests automatisch ausführen zu können, oder die Tests gemäß der Testspezifikation manuell auszuführen. Während der Testausführung muss eine ausführliche Protokollierung (4) stattfinden, um die Tests bei erweiterten Fragestellungen nicht wiederholen zu müssen und die Testauswertung (5) unterstützen zu können. Bei der Auswertung wird entschieden, ob es sich bei gefundenen Fehlern um Fehler in der Testsequenz, der Testumgebung oder wirklich um einen Softwarefehler handelt. Aus der Summe der Testergebnisse lässt sich ein Momentanbild ableiten, wie es um den Entwicklungszustand der Software bestellt ist. 25

26 Die vertikale Gliederung des V-Modells führt zu den Teststufen Modultest, Integrationstest und Softwaretest. Die Phasen des Softwaretestprozesses, ausgenommen die Phase Testplanung, wiederholen sich in diesen Stufen immer wieder aufs Neue. Auf den verschiedenen Teststufen sind gemäß der Teststrategie vorgegebene Testziele zu erreichen. Dabei kommen unterschiedliche Testausführungsplattformen zum Einsatz. Im Folgenden wird eine für das zugrundeliegende Forschungsprojekt gültige Ausprägung der Teststufen beschrieben. Modultest: Die Entwicklung der Software beginnt mit den kleinsten Einheiten, den Modulen. Der Modultest ermöglicht es, diese elementaren Bausteine von Anfang an auf ihre Funktionalität zu überprüfen und die Funktion von neuen Code-Konstrukten in einem überschaubaren Rahmen zu testen. Ein weiteres Ziel des Modultestes ist es, sicherzustellen, dass der Code lesbar und so strukturiert ist, dass er der entworfenen Architektur genügt und wiederverwendet werden kann. Ferner müssen die MISRA C Programmierrichtlinien 1 [12] eingehalten werden. Dies wird mit Hilfe eines statischen Code-Analyse- Werkzeuges und Reviews erreicht. Auf dieser Stufe ist zudem sicherzustellen, dass der Code technisch funktioniert und kein unbenutzbarer oder unerreichbarer Code programmiert wurde. Dazu wird der Code dynamisch stimuliert und die Kontrollflussüberdeckung bestimmt. In der Testplanung wird dafür projektspezifisch ein zu erreichender Überdeckungsprozentsatz festgelegt. Zur Durchführung, Protokollierung und Auswertung der Tests wird ein CppUnit [5] ähnliches Testframework eingesetzt. Durch die Wahl der Stimuli lassen sich schon hier funktionale Aspekte des Softwaremoduls testen. Integrationstest: Der Integrationstest soll sicherstellen, dass sich die Module 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 Steuergeräte-Code und ein Umgebungsmodell auf dem PC gegeneinander simuliert werden. Prinzipiell ist das funktionale Zusammenspiel der Gesamtsoftware mit der Umgebung hier erstmals 1 Bei der Generierung von C-Code aus MATLAB/SIMULINK Modellen müssen Modellierungsrichtlinien eingehalten werden, um zu gewährleisten, dass der erzeugte Code den MISRA Regeln entspricht. 26

27 testbar, wenngleich die Aussagekraft der Tests im Wesentlichen von der Güte der verwendeten Umgebungsmodelle abhängt. Softwaretest: Ziel des Softwaretests ist es sicherzustellen, dass die Software die gewünschte Funktionalität im Fahrzeug realisiert. Dabei ist es notwendig, dass die Software auf dem Steuergerät ausgeführt wird. So wird gewährleistet, dass die Software fehlerfrei auf die Hardware übertragen wird und das korrekte Zusammenspiel von Hard- und Software gegeben ist. Dazu werden HiL- und Fahrzeugversuche durchgeführt. Das Testende für den Softwaretest wird dadurch nachgewiesen, dass zu jeder Anforderung der spezifizierte Test mit positivem Ergebnis durchgeführt wurde Entwicklungsparadigmen Die Software für ein mechatronisches System muss verschiedenen Anforderungen genügen. Es sind physikalische, mechanische und elektronische Zusammenhänge zu berücksichtigen. Als Ergebnis muss ein Programm in Maschinensprache zur Verfügung stehen, welches die Anforderungen auf der Hardware realisiert Steuerungs- und regelungstechnische Aspekte Ziel der Software in mechatronischen Systemen ist die Steuerung bzw. die Regelung 2 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/mathematisches Modell des Verhaltens des zu beeinflussenden Systems. Bei dem Modell handelt es sich um Differenzialgleichungen, welche durch algebraische Beziehungen in Zusammenhang gebracht werden. Für die Modellierung hat sich das Programmsystem MATLAB/SIMULINK etabliert. Dieses enthält bereits eine große Anzahl von Funktionen für die Modellerstellung, z. B. Modellbibliotheken sowie Funktionen für die Auslegung der Regelungsalgorithmen. Durch die Simulation kann das Verhalten der Rege- 2 Im Folgenden wird nur noch von Regelung gesprochen. 27

28 lung bereits vor der eigentlichen Produktion des Systems getestet werden. In den letzten Jahren wurden verschiedene Werkzeuge aufgebaut, welche es ermöglichen, diese Simulationsmodelle direkt in steuergerätekonformen C-Code zu transformieren Kommunikation Aufgrund der Realisierung von immer mehr Funktionalität durch elektronische Steuergeräte ist die Anzahl der benötigten Kabelverbindungen so weit angestiegen, dass sie durch Verwendung einer herkömmlichen Verdrahtung nicht mehr in ein Fahrzeug passen würde. Zur Beseitigung dieser Problemematik sind Bus-Systeme eingeführt worden, welche die effektivere Verdrahtung der Steuergeräte ermöglichen. Der wohl bekannteste Vertreter ist der CAN (Controller Area Network) Bus, welcher 1983 unter Federführung der Firma Bosch entwickelt wurde [33]. Mittlerweile sind weitere Bussysteme hinzugekommen, exemplarisch seien FlexRay und MOST genannt. Für die Software auf einem Steuergerät bedeutet dies, dass eine Signalaufbereitungsschicht zur Verfügung stehen muss, welche die am Bus ankommenden Signale auf interne Größen der Software abbildet und zu versendende Größen auf Bus Signale überträgt. In diesem Zusammenhang ist bei der Auslegung der Regelungsalgorithmen darauf zu achten, dass diese mit eventuell durch die Kommunikation auftretenden Totzeiten zurecht kommen müssen Berücksichtigung der Hardware Die Abbildung der Schnittstellen des Mikrocontrollers auf die Sensorik bzw. Aktuatorik muss erfasst und dokumentiert werden, um zu berücksichtigen 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-Ausgänge. Zum anderen handelt es sich um Bus-Kommunikation, wie beispielsweise die CAN-Schnittstelle. 3 Hauptsächlich handelt es sich dabei um den Real-Time Workshop Embedded Coder von The MathWorks oder Target Link der Firma dspace. 28

29 Programmierung Um die gewünschte Funktionalität zu realisieren, muss ein Programm in Maschinensprache zur Verfügung stehen. Während bis in die neunziger Jahre eingebettete Systeme noch hauptsächlich 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 unabhängig ist. Dabei kommt die funktionsorientierte Sprache C und deren objektorientierte Weiterentwicklung C++ zum Einsatz [15]. Da die Assemblersprache für jeden Mikrocontroller individuell ist, stellen die Herstellerfirmen Cross-Compiler zur Verfügung, welche es ermöglichen, die Hochsprachen in die jeweilige Ziel- Assemblersprache zu übersetzen. Funktionsorientierte Programmierung Die Sprache C ist eine funktionsorientierte oder auch prozedurale Programmiersprache. Zentraler Bestandteil eines C-Programms ist die Funktion main(), welche weitere Funktionen aufrufen kann. Die Kapselung von Daten ist durch Strukturen möglich. Gegenüber einer objektorientierten Sprache besteht der Nachteil, dass ähnliche, zusammenhängende Funktionalität nicht so effektiv gekapselt werden kann. Objektorientierte Programmierung Um die Nachteile der funktionsorientierten Programmierung zu beheben und den Code effektiver gestalten zu können, wurde das Paradigma der objektorientierten Programmierung schon Ende der sechziger Jahre entwickelt. Eine praktisch relevante Anwendung erfährt das Paradigma aber erst seit den neunziger Jahren. Es bietet die Möglichkeit Attribute (Variablen) und Methoden (Funktionen) in einer Klasse zu kapseln, deren Instanzen Objekte genannt werden. Anhand des bereits erwähnten Automatikgetriebes soll dieser Zusammenhang verdeutlicht werden. Zur Bedienung der mehrfach vorhandenen Kupplungen innerhalb des Getriebes werden baugleiche bzw. ähnliche hydraulische Aktuatoren verwendet. Der Druck, den die Aktuatoren stellen, ist proportional zu einem Strom, den das Steuergerät vorgeben kann. Für eine solche Anwendung bietet es sich an die Aktuatoren als Objekte einer 29

30 Klasse aufzufassen. Die Daten und Funktionen, welche zu der Ansteuerung eines Aktuators benötigt werden, können dadurch in dieser Klasse gekapselt werden Modelle in der Softwareentwicklung Bei der Einführung der Entwicklungsparadigmen sind schon die wesentlichen Modelltypen vorgestellt worden. Die frühen Modelle in der Softwareentwicklung sind in der Abstraktion der Assemblersprache in die Hochsprachen C und später 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 Zusammenhänge auf das Wesentliche zu abstrahieren, um fokussiert entwickeln zu können. In der Informatik bedeutet dies, dass die zu verarbeitenden Informationen bzw. die von der Software umzusetzende Funktionalität in irgendeiner Form in den PC eingegeben und dort in Maschinensprache verständlich aufbereitet werden muss. Aus diesem Abbild der Informationen im Speicher können weitere Transformationen angestoßen werden. Im Kontext der Abstraktion der Assemblersprache auf die Hochsprache C sei hier die Backus-Naur-Form erwähnt. 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 Speicherabbild 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 erwähnte Programmsystem MATLAB/SIMULINK an, welches gut für die funktionalen und regelungstechnischen Aspekte der Software geeignet ist. Sowohl der Hersteller The MathWorks als auch die Firma dspace bieten als Ergänzung zu den SIMULINK Signalfluss-Diagrammen spezielle Erweiterungen 30

31 an, damit das Funktionsmodell mit den für die Transformation in die Sprache C notwendigen Informationen angereichert werden kann. Bei der Softwareentwicklung mit der objektorientierten Programmiersprache C++ bieten sich UML-Werkzeuge an Unified Modeling Language Die Unified Modeling Language (UML) ist eine von der OMG standardisierte Sprache, welche zur Modellierung von Software und Software-Systemen verwendet wird [13, 38]. Ihre Anfänge liegen in den neunziger Jahren. In diesem Zusammenhang wurde die UML dazu verwendet, die gerade aufkommenden objektorientierten Softwaresysteme zu beschreiben. Die UML definiert derzeit dreizehn Diagrammtypen. Im Rahmen der vorliegenden Arbeit werden das Klassendiagramm und das Zustandsdiagramm verwendet, weswegen nur diese beiden Diagrammtypen im Folgenden erläutert werden Klassendiagramm Das Klassendiagramm ermöglicht es, Klassen im Sinne der objektorientierten 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 können folgende Beziehungen bestehen: Vererbung bzw. Generalisierung Assoziation Gerichtete Referenz Aggregation Komposition Mit Ausnahme der Komposition sind diese Beziehungen in Bild 2.3 dargestellt. Die Klasse CommonMetaData ist eine Generalisierung der Klasse Testfallgruppe. Dadurch erbt die Klasse Testfallgruppe die Attribute (Sta- 31

32 tus, AusführungsArt,...) der Klasse CommonMetaData. Die Klasse Testspezifikation verweist durch eine gerichtete Referenz auf die Klasse Testbibliothek. 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 Testspezifikation durch die Aggregation der Klasse Testfallgruppe eine interne Menge mit Instanzen dieser Klasse. Bei einer Aggregation können die instanzi- Bild 2.3.: Beispiel für ein Klassendiagramm. ierten Elemente nicht ohne das beinhaltende Element existieren. In dem dargestellten Beispiel können also keine Elemente der Klasse Testfallgruppe angelegt werden, ohne dass eine Instanz der Klasse Testspezifikation vorhanden ist. Bei einer Komposition ist dies hingegen möglich. Sie wird grafisch durch eine nicht ausgefüllte Raute dargestellt Zustandsdiagramm Innerhalb der UML wird ein Zustandsdiagramm zu der Klasse der Verhaltensdiagramme gezählt. Das Zustandsdiagramm orientiert sich an der Definition nach Harel [31]. Es erweitert das Verhalten einer Zustandsmaschine im Wesentlichen um die Konzepte der Hierarchie und Orthogonalität, welche in Unterabschnitt beschrieben werden. 32

33 Extensible Markup Language Die Extensible Markup Language (XML) ist eine Auszeichnungssprache. Sie wird eingesetzt, um Informationen zu strukturieren und sowohl für den Menschen als auch für Maschinen les- und austauschbar zu machen. Die XML ist ein offener Standard, ein Allzwecksystem zum Speichern von Informationen und ein Werkzeugkasten für Auszeichnungssprachen [45]. Innerhalb der XML ist es möglich, Informationen in Elemente zu verpacken. Diese Elemente können wiederum zueinander in Beziehung stehen und Attribute für die weitere Unterstrukturierung aufweisen. Eine vollständigere Definition der XML würde den Rahmen dieser Arbeit übersteigen. Für die weiteren Ausführungen ist es jedoch wichtig, zumindest die wesentlichen Elemente und deren Beziehung zu anderen Abstraktionsmechanismen, wie dem bereits eingeführten Klassendiagramm, aufzuzeigen. Die Grundbegriffe werden anhand der in XML serialisierten Instanz des Klassendiagramms aus Bild 2.3 erläutert. 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 x m i : v e r s i o n= 2.0 xmlns:xmi= h t t p : //www. omg. org /XMI 4 x m l n s : t e s t= t e s t s p e z i f i k a t i o n Name= F u n k t i o n s t e s t > 5 <T e s t s p e z i f i k a t i o n Name= cdruckregler Version= 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 p e Status= s p e z i f i z i e r t 8 T e s t z i e l= Nachweis der F u n k t i o n a l i t ä t 9 P r i o r i t ä 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 abgebildet. Dies ist dadurch gekennzeichnet, dass der Name der Klasse 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 Schrägstrich (</test:testbibliothek>). Die Testbibliothek aggregiert das Element Testspezifikation, dessen Attribut Name dabei mit dem Wert cdruckreg- 33

34 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 Testfallgruppe die Attribute der Vater-Klasse CommonMetaData besitzt. Ein Beispiel dafür 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 werden, 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 Generative Programmierung Unter dem Oberbegriff Generative Programmierung können alle Ansätze zusammengefasst werden, welche es ermöglichen, aus Modellen Code zu generieren [53] Model Driven Architecture Unter dem Stichwort Model Driven Architecture (MDA) entwickelt die Object Management Group (OMG) einen Standard, welcher eine offene und interoperable Lösung 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 ausführbaren Implementierungscodes vor. Die Funktionalität der Software wird in dem Platform Independent Model (PIM) beschrieben, welches durch Transformation in das Platform Specific Model (PSM) überführt werden kann. Innerhalb 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 definiert, welche die technologische Grundlage für Transformationen darstellt. Innerhalb der MOF existieren vier Ebenen, welche in Bild 2.4 visualisiert sind. 34

35 beschreibt ist Instanz von M3: Meta-Meta-Modell ist Instanz von Bild 2.5 beschreibt M2: Meta-Modell ist Instanz von beschreibt M1: Modell ist Instanz von beschreibt M0: Objekte der Realität 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"... Dokument: Testbibliothek Bild 2.3 Listing 2.1 Bild 2.4.: Die vier Ebenen der MOF werden anhand des bereits eingeführten Beispiels des Klassendiagramms und des im folgenden beschriebenen EMF-Meta-Modells dargestellt. Die Ebene M3 ist das Meta-Meta-Modell. Dieses stellt die Konstruktionselemente für die Ebene M2, das Meta-Modell, dar. Basierend auf dem Meta- Modell werden in der Ebene M1 Modellelemente aufgebaut. Diese repräsentieren Objekte aus der realen Welt, welche in der Ebene M0 dargestellt sind Model Driven Software Development Die Bausteine der MDA befinden sich noch in der Standardisierungsphase. Unter dem Begriff Model Driven Software Development (MDSD) werden bereits verfügbare 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

36 erfolgt dabei basierend auf dem EMF, die Transformationen werden durch oaw realisiert. Basierend auf dieser Technologie wird das bereits eingeführte Konzept der MOF erläutert. 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 trägt es den Namen ecore. Es ist selbst aus ecore-bausteinen aufgebaut. 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 Klasse EAttribute abgebildet werden können, 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 Konstruktionselemente für das Meta-Modell zur Verfügung. 36

37 M1: Das Modell Durch die Elemente des Meta-Modells steht eine Informationsstrukturierungsvorlage zur Verfügung, wie die Serialisierung einer Instanz des Klassendiagramms in Listing 2.1 zeigt. M0: Objekte der Realität Das Modell beschreibt ein Objekt aus der Realität, in Bild 2.4 ein formales Dokument, welches eine Testbibliothek beinhaltet Nutzen der Vorgehensweise Der Nutzen dieser Metadaten-Architektur besteht in der Gewährleistung der Interoperabilität zwischen verschiedenen Werkzeugen, welche dieser Architektur genügen. Dies erfolgt dadurch, dass die zu integrierenden Werkzeuge 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 möglich, durch die Modell-zu-Modell Transformation Informationen aus der Realisierung A in die Realisierung B zu überführen. 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 verfügbare 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 vereinigen. Dies gelingt in der Entwicklungsumgebung Eclipse [6] durch die Möglichkeit, aus *.ecore-bausteinen ein UML-Klassendiagramm aufzubauen. Daraus kann dann eine Java-Implementierung des Objektmodells generiert werden, welche in XML serialisierbar ist. Ferner sind Möglichkeiten vorgesehen, annotiertes Java zur Generierung der Implementierungsklassen eines Objektmodells heranzuziehen oder anstelle des Klassendiagramms ein XML-Schema zu verwenden. 37

38 Noch nicht alle Software-Werkzeuge verwenden die gleichen Meta-Meta- Modelle. Trotzdem ergibt sich durch das EMF die Möglichkeit, die Mechanismen der MDA zu verwenden. Dazu müssen aber Informationen aus den zu integrierenden Software-Werkzeugen in ein EMF-Meta-Modell überführt werden. Dazu können auch Technologien wie COM verwendet werden Relevanz für den Test Unter Berücksichtigung der bereits eingeführten Begriffe zeichnet sich für die Entwicklungslandschaft von Software für eingebettete Systeme im Automobil folgendes Bild 2.6 ab. Um das grobe Design der Software beschrei- UML Zustandsdiagramme... MATLAB/ SIMULINK generieren man. codieren C/C++ Assembler generieren Bild 2.6.: Entwicklungslandschaft für Steuergerätesoftware. ben zu können, eignet sich die UML. Das Verhalten einzelner, für die Regelung zuständiger Komponenten lässt sich durch das für die Domäne besser geeignete Programmsystem MATLAB/SIMULINK beschreiben. Als Resultat muss in jedem Fall zunächst C bzw. C++ Code zur Verfügung stehen, welcher durch die geeigneten Compiler in Maschinensprache übersetzt wird. Der C bzw. C++ Code kann dabei auf drei verschiedenen Wegen entstehen: 1. Unter Zuhilfenahme eines MATLAB/SIMULINK-basierten Codegenerators (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 überführt. Dabei zeigt sich der Trend zu der Verwendung einer höheren Abstraktion im Zusammenhang mit der generativen Softwareentwicklung. Mit der UML 38

39 können objektorientierte Programme durch verschiedene Diagrammtypen beschrieben werden. Parallel zu der reinen physikalischen Betrachtungsweise durch MATLAB/SIMULINIK steht damit eine informationstechnisch motivierte Sichtweise auf die Software zur Verfügung, welche insbesondere die übergeordneten Strukturen und die Architektur der Software, geeigneter zu beschreiben vermag. Im Rahmen der Entwicklung mechatronischer Systeme haben beide Sichtweisen ihre Daseinsberechtigung und Notwendigkeit. Die Beschreibung dieser Entwicklungsparadigmen stellt die Basis für die Abstraktion der zu testenden Software dar. Für die in dieser Arbeit angestrebte effizientere Testsequenzerstellung ist es relevant, die Beschreibungsund Entwicklungsparadigmen zu kennen, um bereits formalisierte Informationen für den Test wieder heranzuziehen, bzw. um die Testfallerstellung in die Entwicklungskette zu integrieren Potenzielle Softwarefehler Ziel des Testens von Steuergeräte-Software ist das Sicherstellen einer fehlerfreien Funktionalität. Die folgende Aufzählung soll einen Überblick über typisch zu erwartende Fehlerklassen in der Software geben. Funktionale Fehler: Da die Softwareentwickler in der Regel einen Modultest durchführen, kann unplausible Funktionalität gleich gefunden werden. Besonderes Augenmerk ist darauf zu legen, wenn die Funktionalität über mehrere Module oder Komponenten verteilt ist. Funktionale Fehler können aber auch bei großer Komplexität entstehen. Bei manueller Implementierung zustandsbasierten Verhaltens ist es leicht möglich, den Test einer Übergangsbedingung zu vergessen. Berechnungs- und Genauigkeitsfehler: Diese entstehen durch die Typisierung und Skalierung von Variablen in eingebetteter Software, welche aufgrund der Festkomma-Arithmetik notwendig ist. Die Genauigkeit von Berechnungen wird durch die definierte Auflösung der Größen vorgegeben. Ein Beispiel hierfür ist die Definition einer Variable Masse mit dem Datentyp unsigned integer 8 bit und einer Skalierung von 256 kg/bit. Durch diese Festlegung können nur Mas- 39

40 senänderungen von 256 kg detektiert werden. Die Definition an sich muss nicht fehlerhaft sein, im Zusammenspiel der gesamten Software kann die Festlegung jedoch zu unerwünschtem Verhalten führen. Überlauf von Datenstrukturen: Diese Fehler entstehen, wenn die Typisierung und Skalierung von Variablen an Übergabepunkten innerhalb eines Moduls und über Modul- und Komponentengrenzen hinweg nicht übereinstimmen. Typfehler beim Zugriff auf Datenstrukturen: Bei diesen sieht die Zugriffsfunktion einen anderen Datentyp vor. Verletzung von Echtzeitanforderungen: Diese können vielfältige Ursachen haben und sowohl in fehlerhafter Programmierung als auch in der Überlastung des Steuergerätes ihre Ursache haben. Abweichungen von spezifizierten Anforderungen: Solche Abweichungen treten auf, wenn sich die Software nicht so verhält, wie es die Anforderungen fordern. Dabei kann das Verhalten der Software trotzdem in sich konsistent sein und damit funktional korrekt Testentwurfsmethoden us der in Abschnitt 2.2 eingeführten Beschreibung des Softwaretestprozesses geht hervor, dass die Prozessphase Testspezifikation die entscheidende Rolle in Bezug auf die Sicherung der Qualität der Software spielt. Durch den Einsatz von Testentwurfsmethoden wird festgelegt, welche Fehler prinzipiell gefunden werden können und welche Aspekte der Software getestet werden. In der Praxis zeigt sich, dass den Softwaretestern zwar prinzipiell die verschiedenen Verfahren bekannt sind, ein expliziter, systematischer Einsatz jedoch eher die Ausnahme als die Regel darstellt. Im Folgenden wird eine für die Arbeit relevante Auswahl von bekannten Testentwurfsmethoden aufgeführt und in statische und dynamische Methoden eingeteilt. Einen Überblick über die Klassifizierung gibt Abbildung

41 Testen Statisches Testen Dynamisches Testen Strukturierte Gruppenprüfung Statische Analyse White-box Testen Black-box Testen Code-Reviews Codierungsrichtlinien Anweisungsüberdeckung Äquivalenzklassenbildung Metriken Zweigüberdeckung Grenzwertanalyse Kontrollflussanalyse Pfadüberdeckung Zustandsbezogener Test Datenflussanalyse Bild 2.7.: Klassfizierung der Testfallerstellungsmethoden Statische Testentwurfsmethoden Bei den statischen Testentwurfsmethoden wird das Testobjekt, in diesem Fall der Quellcode des Programms, nicht ausgeführt. Es werden zwei Kategorien unterschieden: Die Strukturierte Gruppenprüfung und die Statische Analyse. Zu der Kategorie der Strukturierten Gruppenprüfung gehören die Code-Reviews. Diese vermögen unter Zuhilfenahme von Review- Fragestellungen, die häufig aus dem Erfahrungswissen der Tester und Entwickler schriftlich gesammelt werden, schon einige Fehler aufzudecken. Insbesondere sind dies Fehler in Funktionalität, die über die gesamte Software verteilt ist. Ein Beispiel für eine Fragestellung ist: Was passiert wenn in der Situation X ein Reset des Steuergerätes ausgeführt wird? In der Kategorie der Statischen Analyse wird der Quellcode formalen Fragestellungen unterzogen: Codierungsrichtlinien: Sie stellen eine Sammlung von Regeln dar, gegen welche der Quellcode geprüft werden kann. So gibt es für die Erstellung von C-Code die MISRA-C Richtlinien [12]. Diese Sammlung von Gestaltungsrichtlinien für den Quellcode wurden aus Er- 41

42 fahrungen gewonnen. Neben offiziellen Standards sind häufig auch firmenspezifische Richtlinien zu finden. Metriken: Durch Software-Metriken werden eine Reihe von Maßen definiert. Es gibt Metriken, welche die Dichte der Kommentare beschreiben bis hin zu Komplexitätsmaßen, wie sie durch die Zyklomatische Zahl definiert werden. Einen guten Überblick zu dem Thema liefert [25]. Kontroll- und Datenflussanalyse: Durch das statische Nachvollziehen der Kontroll- und Datenflüsse innerhalb der Software können bereits einige Fehler aufgedeckt werden. Für diese Analysen stehen mittlerweile Werkzeuge zur Verfügung, wie Polyspace der Firma The MathWorks oder Coverity Prevent der Firma Coverity Dynamische Testentwurfsmethoden Die Klassifizierung der dynamischen Testverfahren erfolgt anhand der für die Testfallauswahl zugrundegelegten Sicht auf das Testobjekt. Dies soll Abbildung 2.8 verdeutlichen. Bei den white-box Verfahren kann der Tester Testobjekt White-Box IF Grey-Box Black-Box ENDI F DO IF ENDIF WHILE Testrahmen Bild 2.8.: Verschiedene Sichten auf das Testobjekt, als Grundlage für die Testfallerstellung. den Quellcode der zu testenden Software einsehen. Es wird damit möglich, anhand der Struktur der Software Testfälle 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 bewertet werden kann und welches als Grundlage für die Testfallerstellung dient. Der Begriff grey-box Testverfahren stammt aus der testgetriebenen 42

43 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 häufig im Modultest eingesetzt. Je komplexer das Testobjekt wird, desto weniger übersichtlich werden die Verfahren. In der Praxis hat es sich bewährt, mit Hilfe der black-box Testverfahren Stimuli für das Testobjekt zu bestimmen und durch den werkzeuggestützten Einsatz von white-box Testverfahren nachzuweisen, zu welcher Code-Überdeckung diese Stimuli führen. Dieses Vorgehen stellt einen guten Kompromiss dar. Bei einer reinen black-box Betrachtung des Testobjekts lässt sich zwar nachweisen, dass das Testobjekt seinen Anforderungen genügt, es kann jedoch nicht festgestellt werden, ob es unbenutzten Implementierungscode gibt, oder warum es bei der Eingabe bestimmter Werte zu einem Absturz bzw. Verklemmen des Testobjekts kommt. Auf der anderen Seite besteht bei der reinen Erstellung der Testfälle mit white-box Verfahren die Gefahr, Anforderungen nicht implementiert zu haben und dies aufgrund der rein codezentrierten Betrachtungsweise nicht zu bemerken. Die white-box Testverfahren haben den großen Vorteil, dass durch die Messung der Codeüberdeckung nach den jeweiligen Kriterien ein quantifizierbares Testergebnis erzielt wird White-box Testentwurfsmethoden Den white-box Testentwurfsmethoden liegt die Kenntnis der Struktur der Software zugrunde. Aus dieser Kenntnis leiten sich Kriterien für die Überdeckungsmessung ab Kontrollflussbezogene Kriterien Anhand des in Bild 2.9 dargestellten Kontrollflussgraphen einer Software werden die kontrollflussbezogenen Kriterien erläutert [46,52]. Der Kontrollflussgraph ist dabei folgendermaßen definiert: 43

44 Definition 2.1 (Kontrollflussgraph) Der Kontrollflussgraph eines Programms ist ein gerichteter Graph. Knoten: Den Knoten des Graphen sind Anweisungen zugeordnet. Es können einem Knoten ganze Anweisungsfolgen, die keine bedingten Anweisungen enthalten, zugeordnet sein. Das komplette Entscheidungsprädikat einer bedingten Anweisung ist dagegen einem sogenannten Entscheidungsknoten zugeordnet, wobei für jeden Ausgang der Entscheidung eine Kante zu einem Nachfolgerknoten existiert, die mit true bzw. false markiert ist. Um Initialisierungsvorgänge modellieren zu können (z.b. Parameterübergabe bei Prozeduren), enthält ein Kontrollflussgraph nur einen Knoten (genannt: Anfangsknoten), der keinen Vorgängerknoten hat und auch nur eine ausgehende Kante, genannt Anfangskante, besitzt. Außerdem soll ein Kontrollflussgraph nur einen Knoten, genannt Endknoten, enthalten, der keinen Nachfolger hat. Kanten: Die Kanten stellen die Verbindungen zwischen Anweisungen und Anweisungsnachfolgern dar. IF a c IF ENDIF b f DO i g WHILE h d ENDIF e Legende Knoten, Anweisung Kante, Kontrollfluss n Benennung der Kanten Bild 2.9.: Kontrollflussgraph zur Verdeutlichung der Überdeckungskriterien. Anweisungsüberdeckung (C0): Eine vollständige Überdeckung aller Anweisungen kann in dem in Bild 2.9 dargestellten Beispiel schon mit einem Testfall { a, b, f, g, h, d, e } erreicht werden. Können Anweisungen nicht ausgeführt werden, so kann dies ein Hinweis auf nicht erreichbaren Programmtext sein. 44

45 Zweigüberdeckung (C1): Ziel dieses Kriteriums ist es, die Überdeckung aller Kanten des Kontrollflussgraphen zu erzielen. Anweisungsfreie Zweige einer Bedingung müssen zur Erreichung der vollständigen Zweigüberdeckung durchlaufen werden. Die Zweigüberdeckung stellt damit ein stärkeres Kriterium als die Anweisungsüberdeckung dar. Einfache Bedingungsüberdeckung (C2) : Setzt sich eine Bedingung aus mehreren logisch verknüpften Teilbedingungen zusammen, so ist das Ziel der einfachen Bedingungsüberdeckung, dass jede atomare Teilbedingung sowohl den Wert wahr als auch falsch annimmt. Eine atomare Teilbedingung ist dabei dadurch definiert, dass sie keine Operatoren, wie AND, OR oder NOT, sondern höchstens Relationen wie oder = enthält. Besteht eine Bedingung aus mehreren atomaren Teilbedingungen, kann es bei der einfachen Bedingungsüberdeckung dazu kommen, dass die Gesamtbedingung immer den gleichen Wert annimmt, damit ist sie ein schwächeres Kriterium als die Zweigabdeckung. Mehrfache Bedingungsüberdeckung (C3): Bei der Mehrfachbedingungsüberdeckung wird gefordert, dass alle Kombinationen der Wahrheitswerte der atomaren Teilbedingungen berücksichtigt werden. Damit wird die Gesamtbedingung mindestens einmal wahr und falsch. Minimale Mehrfachbedingungsüberdeckung: Da alle Kombinationen in der Praxis oft nicht immer erreicht werden können und die Anzahl der Kombinationen 2 n bei n Teilbedingungen beträgt, wurde die minimale Mehrfachbedingungsüberdeckung eingeführt, welche nur noch die Kombinationen fordert, welche die Gesamtbedingung mindestens einmal zu wahr und einmal zu falsch werden lassen können. Pfadüberdeckung (C4): Die Pfadüberdeckung fordert die Ausführung aller unterschiedlichen Pfade durch ein Testobjekt, dies bedeutet, dass auch Schleifen vollständig durchlaufen werden müssen. 45

46 Datenflussbezogene Kriterien Dem datenflussbezogenen Testentwurf liegt der Gedanke zugrunde, dass eine Anweisung auch deshalb falsch sein kann, weil die innerhalb der Berechnung verwendeten Variablen falsch initialisiert wurden oder weil sie falsche Werte referenzieren. Zur Erläuterung der Kriterien wird der Datenflussgraph definiert [46]: Definition 2.2 (Datenflussgraph) Ein Datenflussgraph ist ein Kontrollflussgraph, 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, für welche die Anweisungsfolge f, die zum Knoten k gehört 4, der Variablen x einen Wert zuweist, der nicht anschließend in f in einen undefinierten Zustand überführt wird. UNDEF(k) ist die Menge der Variablen x, für welche die Anweisungsfolge f, die zum Knoten k gehört, die Variable x in einen undefinierten Zustand überführt, ohne x anschließend in f neu zu definieren. REF(k) ist die Menge der Variablen x, für welche die Anweisungsfolge f, die zum Knoten k gehört, die Variable x referenziert, ohne dass x vorher in f in einen undefinierten Zustand überführt wird. (Dabei 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 innerhalb eines Knotens eliminiert wird.) Basierend auf dem Datenflussgraphen werden wiederum verschiedene Überdeckungskriterien definiert: Beispiele dafür sind Testsuiten, welche den Kriterien Alle Definitionen oder Alle Referenzen genügen Bewertung der white-box Testentwurfsmethoden Die Effektivität der white-box Testentwurfsmethoden lässt sich nach [28] grob quantifizieren: Kontrollflussorientiertes Testen erkennt 85% der Feh- 4 Es kann sich - je nach Abstraktionsgrad des Kontrollflussgraphen - um eine oder mehrere sequenziell auszuführende Anweisungen handeln, die zum Knoten k gehören. 46

47 ler, datenflussbezogenes Testen deckt 70% der Fehler auf, ausdrucks- und anweisungsbezogenes Testen 5 erkennt 41% der Fehler. In den zugrunde liegenden Untersuchungen werden jedoch nicht alle Kriterien einer Testklasse (bspw. Kontrollfluss) verwendet, so dass das Ergebnis mit Vorsicht zu behandeln ist. Dennoch stellen solche Aussagen die Grundlage dafür dar, dass in der Regel die kontrollflussorientierten Kriterien verwendet und gelehrt werden. Im Zusammenhang mit objektorientiert programmierter Software gewinnen die datenflussorientierten Kriterien jedoch wieder an Relevanz. Bei objektorientierter Software ist eine Kontrollflussüberdeckung für die einzelnen 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 durchgeführter Test von Klassen erheblich bessere Aussagen liefert als ein kontrollflussorientierter Klassentest. Derzeit gibt es jedoch kaum Werkzeuge auf dem Markt, welche den datenflussorientierten Klassentest unterstützen [35]. Es ist daher naheliegend, den Datenfluss der Software mit einem statischen Datenflussanalysewerkzeug zu untersuchen. Partielle Ordnung der Kriterien Um die Auswahl eines Überdeckungskriteriums zu ermöglichen, gibt es Untersuchungen, welches der angegebenen Kriterien welche anderen inkludiert. Für die kontrollflussorientierten 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 Kontrollfluss eines Programms erstellt wird, hat eine höhere Fehlerfindungswahrscheinlichkeit als eine auf dem Datenfluss basierende. Innerhalb der kontrollflussbezogenen Testentwurfsmethoden hat das Kriterium der Pfadüberdeckung das höchste Fehlerfindungspotenzial, bedingt aber gleichzeitig den größten Aufwand für die Generierung und Ausführung einer solchen 5 Dieses Kriterium wird an dieser Stelle nicht weiter erläutert, näheres siehe [46] 47

48 Minimale Mehrfach- Bedingungsüberdeckung Mehrfache Bedingungsüberdeckung (C3) Pfadüberdeckung (C4) Einfache Bedingungsüberdeckung (C2) Zweigüberdeckung (C1) Anweisungsüberdeckung (C0) Bild 2.10.: Ordnungsgraph der kontrollflussbasierten white-box Testentwurfsverfahren. Testsuite. Einen guten Kompromiss stellt die Zweigüberdeckung dar, da sie ein großes Fehleraufdeckungspotenzial bei einem vertretbaren Aufwand hat. Prozentzahlen der gefundenen Fehler Von Riedemann mit Literaturstellen belegt Anweisungsüberdeckung: 18% - 41% Zweigüberdeckung: 16% - 92% Pfadüberdeckung: das dreifache der Zweigüberdeckung (62% - 64% statt 21% [How 76, How78b] Die Fehler der Klasse Abweichungen von spezifizierten Anforderungen können prinzipiell nicht mit den white-box Testentwurfsmethoden gefunden werden. Im Folgenden werden einige dieser Fehler aufgezählt: Abweichungen von der Spezifikation. Fehler bei extremen oder speziellen Werten, die für die Funktion wichtig sind. Fehlende Pfade bzw. Funktionen. Schnittstellenfehler. Diese Fehler bedürfen der Referenz durch die Anforderungen oder das Design der Nachbarkomponenten. Initialisierungsfehler Black-box Testentwurfsmethoden Testentwurfsmethoden, bei denen die Kenntnis der Implementierung nicht zugrunde gelegt wird, werden black-box Testentwurfsmethoden genannt. 48

49 Im Folgenden werden die in der Übersicht aus Bild 2.7 aufgeführten Testentwurfsmethoden näher erläutert Äquivalenzklassenbildung und Grenzwertanalyse Mit Hilfe der Äquivalenzklassenbildung und Grenzwertanalyse wird der Eingabedatenraum für das System Under Test (SUT) strukturiert. Eine Äquivalenzklasse ist dadurch gekennzeichnet, dass das Systemverhalten für diesen Eingabebereich gleich bleibt. Grenzwerte kennzeichnen den Übergang zwischen Äquivalenzklassen. r = f(x,y) Als Überbegriff für Äquivalenzklassen und Grenzwerte wird im Folgenden die Bezeichnung Klassifikation verwendet. Im Kontext funktionaler Äquivalenzklassen kann dabei ein im Softwaretest vorgegebener zeitlicher Stimulationsverlauf beispielsweise in die Klassen konstant und dynamisch aufgeteilt y werden. Bezogen auf den Test einer Funktion r = f(x, y) im Modultest kann der Datenraum der Übergabeparameter mit Klassifikationen strukturiert werden, wie das Bild 2.11 darstellt. Konkrete Datenpunkte (x, y) für den Test sind somit entwe- [Grenzwert y n ] y [Datenpunkte] [Äquivalenzklasse y 1 ] r = f(x,y) x [Äquivalenzklasse x 1 ] [Grenzwert x m ] Bild 2.11.: Äquivalenzklassen und Grenzwerte. der Repräsentanten einer Äquivalenzklasse, die Auswahl eines Grenzwertes oder beides. Es ist zu beachten, dass für jeden gewählten Datenpunkt (x, y) auch ein erwarteter Rückgabewert r angegeben werden muss, damit ein Test der Form r == f(x, y) 6 möglich ist. 6 Der Operator == ist der Sprache C entnommen und prüft, ob der Wert auf der linken Seite des Operators dem auf der rechten Seite entspricht. 49

50 Auswahlstrategien Die Auswahl konkreter Eingabe-Datenpunkte ist eine im Rahmen des Testens zentrale Fragestellung. Im Zusammenhang mit Kombinatorik wird diese Frage auch in anderen Zusammenhängen gestellt, beispielsweise in der statistischen Versuchsplanung [43]. Um bei der allgemeinen Kombinatorik zu bleiben, wird die folgende Nomenklatur verwendet. Die Eingangsgrößen des SUT werden als Faktoren F bezeichnet. F = {F 1,..., F k } card(f) = k (2.1) Die verschiedenen Klassifikationen der Faktoren werden als Level l bezeichnet. Jedem Faktor ist ein Menge von Leveln L zugeordnet, für welche gilt: F F L {F 1, L 1 }, {F 2, L 2 },... {F k, L k }, (2.2) L i = {l i,1,..., l i,ni } card(l i ) = n i (2.3) In Bild 2.12 ist ein SUT mit k = 3 Faktoren dargestellt, welche jeweils in drei Level unterteilt sind (n 1 = n 2 = n 3 = 3). Der Eingabedatenraum des SUT wird dadurch in 27 Datenpunkte unterteilt. Es stellt sich nun die C Fehlerregion Einfacher Fehler Level C3 Level C2 Level A1 B Level B2 Level A2 Level A3 A Datenraum des SUT Legende: Orthogonales Feld Minimale Auswahl Punkte liegen übereinander Bild 2.12.: Visualisierung der Kombinatorik im Datenraum [43]. Frage, wie die Datenpunkte für den Test ausgewählt werden sollen. Um die Relevanz dieser Auswahl zu veranschaulichen, stellt das Bild eine Fehlerregion dar, welche eine Fehlerklasse visualisiert, die prinzipiell durch die 50

51 Auswahl verschiedener Datenpunkte gefunden werden kann. Zudem ist ein einfacher Fehler dargestellt, dass heißt er kann nur mit einer einzigen Eingabedatenkombination gefunden werden. Es wird deutlich, dass die Menge der ausgewählten Datenpunkte darüber entscheidet, wie wahrscheinlich es wird, Fehler zu finden. Schon eine Untermenge der möglichen Datenpunkte vermag eine Fehlerregion aufzudecken. Das Auffinden des einfachen Fehlers kann jedoch entweder durch Glück oder Erfahrung erfolgen oder durch die vollständige Auswahl aller möglichen Datenpunkte für den Test 7. 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 Lösungen Orthogonale Felder Ein orthogonales Feld ist eine spezielle Matrix, deren Auswahl konkreter Eingabe-Datenpunkte dazu führt, dass immer zwei Eingangsgrößen paarweise voneinander unabhängig sind. Dies führt 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 Ausführungen in [56] wird ein allgemeines orthogonales Feld folgendermaßen definiert: O(c, k, n, t) (2.4) Dabei haben die Übergabeparameter folgende Bedeutung: 7 Da die Datenräume in der Praxis häufig nicht so überschaubar sind, ist es aus zeitlichen Gründen nicht immer möglich, vollständig zu testen. 51

52 c: Anzahl der Eingabe-Datenpunkte. Dies entspricht der Anzahl der Zeilen. k: Anzahl der Faktoren. Dies entspricht der Anzahl der Spalten. n: Anzahl der Level, es gilt: n = max(n i ). t: Stärke der Matrix. Alle t-fachen Kombinationen kommen gleich oft vor. In jeder c t Untermatrix kommen alle möglichen n t t-tupel gleich oft vor. Ein orthogonales Feld der Stärke t = 2, welches der Auswahl paarweiser Kombinationen entspricht, lässt sich nach dem Algorithmus von Bose [18] berechnen: O(n 2, n + 1, n, t = 2) kurz: O(n 2, n + 1, n) (2.5) Die Anzahl der Level n muss dabei eine ganzzahlige (m) Potenz einer Primzahl (p) sein. n = p m (2.6) Die einzelnen Elemente O ij (n 2, n + 1, n) der Matrix mit i = 1,..., n 2 und j = 1,..., n + 1 werden dabei folgendermaßen bestimmt. Sei (i 1) u = + 1 und w = ((i 1) mod n) + 1 (2.7) n dann gilt: O i1 = u und O i2 = w (2.8) Die übrigen Elemente der Matrix berechnen sich zu: O ij (n 2, n + 1, n) = q (2.9) Für j > 2 ist q so zu bestimmen, dass unter Verwendung der Arithmetik des Galois-Feldes (GF) der Ordnung n GF (n) = {x 0, x 1,..., x n } mit x 0 = 0 und x 1 = 1 (2.10) 52

53 und der Galois-Feld Arithmetik gilt. x q = x j 2 x u + x w (2.11) Die Berechnung des benötigten 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 Zeileneinträge 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 Permutationen von (1,..., n). Voraussetzungen für den Einsatz orthogonaler Felder Aus der Berechnungsvorschrift für ein orthogonales Feld mit paarweiser Überdeckung, wie es in Gleichung (2.5) beschrieben ist, zusammen mit der Vorgabe in Gleichung (2.6), dass die Anzahl der diskreten Ausprägungen eines Faktors (Level) einer ganzzahligen Potenz einer Primzahl entsprechen muss, wird ersichtlich, dass nicht für jeden Anwendungsfall ein passendes orthogonales Feld bestimmt werden kann. Um diesem Umstand Rechnung zu tragen, gibt es verschiedene Ansätze. In [42] werden Techniken beschrieben, wie ein orthogonales Feld an einen konkreten Anwendungsfall mit einer vorgegebenen Anzahl von Parametern und diskreten Ausprägungen angepasst werden kann. Dabei wird auf eine Tabelle von bereits vorbestimmten orthogonalen Feldern zurückgegriffen. Wenn sich Faktoren gegenseitig beeinflussen, kann es sein, dass der Effekt der Interaktion zweier Faktoren den Effekt eines anderen Faktors überdeckt. Dazu ist für jedes orthogonale Feld eine Interaktionstabelle spezifiziert, welche angibt, welche Spalte von welchen Faktorkombinationen überdeckt wird. Auszüge aus dieser Interaktionstabelle können durch lineare Graphen dargestellt werden. Der Einsatz orthogonaler Felder zur Auswahl von Eingabe-Datenpunkten für den Test verspricht einen methodischen 53

54 Vorteil durch die mathematische Eigenschaft, paarweise Kombinationen von Datenpunkten zu untersuchen. Praktisch zeigen die vorangegangenen Ausführungen jedoch, dass ein orthogonales Feld nicht ohne Fachwissen für eine Problemstellung adaptiert werden kann. Verschiedene Ansätze einer Realisierung dieser Testvorgehensweise sind unter [2] publiziert. Ein möglicher Ansatz wird von [56] durch die Implementierung des Werkzeuges T-Config bereitgestellt. Die von Williams vorgeschlagene Vorgehensweise ermöglicht es, die Auffindung eines geeigneten orthogonalen Feldes auf zwei Eingabeparameter zu reduzieren: Die Anzahl der Faktoren (k) und ihrer diskreten Ausprägungen (n). Weist das wirkliche Problem eine unterschiedliche Anzahl von Ausprägungen n i auf, muss die größte Ausprägung i = max(n i ) als Grundlage für die Auswahl eines passenden orthogonalen Feldes herangezogen werden. Die damit überbestimmten Ausprägungen können beliebig vergeben werden, dürfen aber nicht gelöscht werden, da sonst die Orthogonalitätseigenschaft des Feldes verloren geht. Für den Fall, dass die Anzahl der Faktoren und Ausprägungen nicht den Anforderungen aus den Gleichungen (2.5) und (2.6) genügen, wird eine Überdeckungsmatrix O berechnet, welche annähernd die mathematischen Eigenschaften eines orthogonalen Feldes erfüllt. SUT Faktor A Faktor B Faktor C Level A1 Level A2 Level A3 Level B1 Level B2 Level B3 Level C1 Level C2 Level C3 O(9,4,3,2) O (9,3,3,2) Datenpunkt 1 Datenpunkt 2 Datenpunkt 3 Datenpunkt 4 Datenpunkt 5 Datenpunkt 6 Datenpunkt 7 Datenpunkt 8 Datenpunkt Bild 2.13.: Darstellung der Auswahl von Eingabe-Datenpunkten durch ein reduziertes orthogonales Feld O nach [56]. 54

55 In Bild 2.13 wird dies anhand des mit Bild 2.12 eingeführten Beispiels verdeutlicht, in welchem jeder der drei Faktoren (k=3) drei Level (n=3) besitzt. Aus Gleichung (2.5) resultiert, dass sich für das Problem nur das orthogonale Feld O(9, 4, 3, 2) bestimmen lässt. Das Werkzeug T- Config berechnet für 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 visualisiert. Die Zahlen in der Matrix geben den Level an, die Spalte steht für den Faktor. Die Orthogonalitätseigenschaft der Matrix ist dadurch gekennzeichnet, dass jeder Level in jedem Spaltenpaar vorkommt und zwar gleich oft. Diese Ausgleichseigenschaft ist mathematisch dafür hinreichend, dass jeweils zwei Spaltenvektoren im kombinatorischen Sinne voneinander linear unabhängig sind, wodurch der Einfluss dieser beiden Faktoren voneinander unabhängig 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 ausgewählt. Unter Berücksichtigung der Gleichungen (2.1) und (2.3), sowie der Beziehung n = max(n i ) wird die Auswahlmatrix durch die Gleichung (2.12) bestimmt. O i,j = { lj,i i = 1(1)n, j = 1(1)k l j,1 Wenn n j < 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 Auswahlmatrix für das aufgeführte Beispiel mit den drei Faktoren dargestellt. Die drei ausgewählten Datenpunkte sind schraffiert in den Datenraum des SUT in Bild 2.12 eingetragen. Alle Datenpunkte wurden auch durch das reduzierte orthogonale Feld ausgewählt. Vollständige Auswahl: Bei der vollständigen Auswahl werden alle Punkte des Datenraums ausgewählt. Die Auswahlmatrix wird zeilenweise nach der Gleichung (2.13) aufgebaut, wobei die Anzahl der Zeilen c dem 55

56 SUT Faktor A Faktor B Faktor C Level A1 Level A2 Level A3 Level B1 Level B2 Level B3 Level C1 Level C2 Level C3 Datenpunkt 1 Datenpunkt 2 Datenpunkt 3 Bild 2.14.: Visualisierung der minimalen Auswahlstrategie. Produkt der Level-Anzahlen n i der Faktoren entspricht. O (c,:) = [l 1,h,..., l k,j ] mit c = 1(1) k i=1 n i h = 1(1) n i,, j = 1(1) n k (2.13) In der Darstellung gilt, dass die Indizes der Matrix den Index der Zeile und der Spalte eines Matrix-Elements repräsentieren. Der Operator : steht für alle Elemente einer Dimension. Die Notation (c,:) beschreibt damit alle Elemente in der c-ten Zeile der Matrix. Die Syntax h = 1(1) n i,, j = 1(1) n k 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. c = 1(1) (n A n B n C ) O (c,:) = [l A,h, l B,i, l C,j ] mit h = 1(1) n A i = 1(1) n B (2.14) j = 1(1) n C Zusammenfassung Die Tabelle 2.1 fasst die vorgestellten Auswahlstrategien in einem Überblick zusammen. Von weiterem Interesse sind die verschiedenen Anzahlen der durch die Strategie gewählten Datenpunkte. Abhängig von der Kritikalität des SUT ist zu entscheiden, welche Auswahlstrategie verwendet werden soll. Mit der maximalen Auswahl wird der 56

57 Orthogonales Feld O(c = n 2, k = n + 1, n = max(n i )) Anzahl Datenpunkte: n 2 Minimale Auswahl O(c = n = max(n i ), k, n) Anzahl Datenpunkte: Maximale Auswahl Anzahl Datenpunkte: n O(c = k i=1 n i, k, n) k i=1 n i Tabelle 2.1.: Überblick zu den Auswahlstrategien. gesamte Datenraum getestet; wurden die Klassifikationen richtig gewählt, besteht die größte Wahrscheinlichkeit Fehler aufzudecken. Phadke, Williams und Andere berichten von guten Erfahrungen mit orthogonalen Feldern. Für die Anwendung besteht das größte Problem in der zuverlässigen 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 Klassifikationsbaummethode [29] hervorging. Die Faktoren und Level können hierbei manuell in einen Klassifikationsbaum eingetragen werden. Innerhalb des Werkzeuges sind ebenfalls verschiedene Auswahlstrategien implementiert, welche im Folgenden, in Anlehnung an die beigefügte Dokumentation, aufgezählt werden: Ein Element aus jedem Faktor: Von den diskreten Ausprägungen der Faktoren wird jeweils eine gewählt. Paarweise Kombination: Aus einer Menge von Faktoren K = {a, b, c}, mit den jeweiligen diskreten Ausprägungen n a,b,c, werden paarweise Kombinationen der Form k 1 = (a b), k 2 = (a c), k 3 = (b c) gebildet. Dreifache Kombination: Es wird ein der paarweisen Kombination entsprechendes Prinzip angewendet. Aus einer Menge von Faktoren K = {a, b, c, d} werden Kombinationen der Form k 1 = (a b c),... gebildet. n-fache Kombination: Das Prinzip wird auf das n-fache erweitert. Die Kombinationsregeln können beliebig miteinander kombiniert werden. 57

58 Zustandsbasierter Test Ein großer Teil der Steuergeräte-Software ist durch zustandsbasiertes Verhalten gekennzeichnet. Selbst kontinuierliche Regelfunktionen sind häufig in ein übergeordnetes diskretes Zustandsverhalten eingebunden. Aus der Struktur dieses Zustandsdiagramms können Testsequenzen generiert werden. In diesem Kontext wird auch häufig von modellbasiertem Testen gesprochen. Die im Rahmen der vorliegenden Arbeit entwickelte Heuristik basiert ebenfalls auf diesem Verfahren Erfahrungsbasierte und intuitive Testsequenzermittlung Trotz der methodischen Testsequenzerstellung wird es immer wieder Testsequenzen 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 aufgeführt Aufgabenstellung - Methodisches und automatisiertes Testen Den bisherigen Ausführungen ist zu entnehmen, dass Kfz-Steuergeräte- Software hierarchisch entwickelt wird. Zunächst werden einzelne Software- Module zu Komponenten und später zur gesamten Software integriert, wie es Bild 2.1 zeigt. Der Testprozess wiederholt sich während dieser Integrations- bzw. Teststufen (Bild 2.2). Die Phase der Testspezifikation ist dabei entscheidend für die Fähigkeit der Tests, potenzielle Fehler aufzudecken. Der Einsatz von Testentwurfsmethoden hilft dabei, die Testspezifikation systematisch aufzubauen. Es ist anschaulich klar, dass die Tests für ein Modul der Software auch mit der gesamten Software zusammenhängen. Es ist jedoch ein technologischer Unterschied zwischen den Tests auf den verschiedenen Abstraktionsgraden gegeben. Inhaltlich werden ebenfalls unterschiedliche Aspekte geprüft, 58

59 da die Teststufen von unterschiedlichen Entwicklern mit unterschiedlichem Hintergrundwissen durchgeführt werden. Der Modultest erfolgt in der Regel in der gleichen Entwicklungsumgebung, in der das Modul erstellt wird. Für manuell erstellten C bzw. C++ Code ist dies eine IDE, wie Visual Studio, für andere Module entsprechend MAT- LAB/SIMULINK. Zu einer Komponente integrierte Module weisen häufig schon eine so große Anzahl von Schnittstellen auf, dass es sich anbietet, den Test wenn möglich im integrierten Zustand der Software durchzuführen. Im Automobil-Umfeld werden dazu häufig Closed-Loop-Verfahren, wie SiL oder HiL, angewendet. Diese zeichnen sich dadurch aus, dass die zu testende Software gegen ein Umgebungsmodell ausgeführt wird, wie es Bild 2.15 zeigt. Softwaretest Komponententest Modultest Modul 1 Komponente 1 Modul 2 Komponente 2 Umgebungsmodell Steuergerätesoftware Bild 2.15.: Unterschiedliche Testabstraktionsschichten. Das Testziel, eine korrekte Funktion der Software, bleibt dabei zwar unverändert, jedoch wechselt der technologische Fokus; dass heißt die Methode der Softwarestimulation und der Zugriff auf Ein- und Ausgangsgrößen ist heterogen. Vor diesem Hintergrund zeigt sich, dass in der Praxis ein großer Teil der Zeit, welche für das Testen aufgebracht wird, in die Erstellung der Testinfrastruktur fließen muss. Ferner konnte festgestellt werden, dass den meisten Entwicklern zwar die Testentwurfsmethoden prinzipiell bekannt sind, diese aber selten belegbar angewendet werden, da vorhandene Werkzeugunterstützungen nicht immer in das Entwicklungsumfeld passen. 59

60 Damit ergeben sich für die Arbeit die folgenden Ziele: 1. Es soll eine Möglichkeit gefunden werden, Testentwurfsmethoden auf allen Teststufen technologisch wiederverwenden zu können. 2. Der Aufwand, die Testinfrastruktur bereitzustellen, soll reduziert werden. 3. Die black-box Testentwurfsmethoden Zustandsbasierter Test und Äquivalenzklassenbildung/Grenzwertanalyse sollen praktisch eingesetzt werden. 60

61 3. Testframework Um den Anforderungen aus Kapitel 2 zu genügen, wird das vorgestellte Testframework konzipiert und implementiert [40]. Die Architektur dieses Frameworks stellt Schnittstellen zu den im Rahmen der Entwicklung verwendeten Werkzeugen bereit, um Grundinformationen für die einzubindenden Testentwurfsmethoden zu erhalten. Dabei wird in Abschnitt 3.1 diskutiert, welche Informationen aus dem Entwicklungsprozess verwendet werden können. Die methodisch erstellten Testfälle werden zunächst plattformunabhängig beschrieben. Diese Beschreibung stellt zugleich ein Kommunikationsmittel dar, um den Testinhalt diskutieren und austauschen zu können, ohne die plattformspezifische Implementierungssprache zu verstehen. Ausgehend von dieser formalen Basis kann die plattformspezifische Implementierung durch eine geeignete Transformation erfolgen. Die technologische Realisierung des Frameworks wird in Abschnitt 3.2 beschrieben Verwendung von Artefakten aus dem Entwicklungsprozess Die verwendbaren Artefakte können in drei Kategorien eingeteilt werden: Strukturartefakte, Verhalten und Daten. In Anlehnung an die Bilder 2.2 und 2.6 können diese Daten hauptsächlich aus dem UML-Design und MATLAB/SIMULINK-Modellen entnommen werden, wobei aufgrund der Gegebenheit in dem zugrundeliegenden Projekt zunächst auf UML-Modelle eingegangen wird Strukturartefakte Strukturartefakte der Software sind im Software-Design bereits formal hinterlegt. Dabei handelt es sich um für den Test wichtige Angaben, wie den Aufbau einzelner Softwarekomponenten, die Angabe, welche Module vorhanden sind und welche Ein- und Ausgabeschnittstellen diese zur Verfü- 61

62 gung stellen, sowie Informationen über die Datentypen und Wertebereiche der Schnittstellenparameter. Die Schnittstellen der Software müssen während des gesamten Entwicklungs- und Testprozesses konsistent sein, weswegen diese durchgängig wiederverwendet werden müssen. Insbesondere für die Testfallerstellung können diese Schnittstelleninformationen herangezogen werden, um einzelne Komponenten über 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 durchgängigen Entwicklungskette spätestens bei der Integration Verhalten Verhalten ist in Form von Zustandsmaschinen häufig in den Software- Anforderungsdokumenten oder spätestens im Software-Design zu finden. Dabei ist das Verhalten auf unterschiedlichen Detaillierungsstufen des Entwicklungsprozesses beschrieben. So kann sowohl das Verhalten der Gesamtsoftware durch eine Zustandsmaschine abgebildet sein, wie auch das Verhalten eines einzelnen Software-Moduls. In allen Fällen stellt diese formale Beschreibung eine wertvolle Basis für die zustandsbasierte Testsequenzerstellung dar. Die Verwendung der Verhaltensinformationen für die Testfallerstellung wird häufig unter dem Stichwort modellbasiertes Testen publiziert. In der Arbeit [44] werden verschiedene Szenarien des modellbasierten Testens identifiziert: 1. Aus einem Modell werden sowohl der Implementierungscode, als auch die Testfälle abgeleitet. In diesem Fall ist ein manuelles Verdict notwendig. Da die Testfälle auf der gleichen Basis wie der Code beruhen, können automatisiert keine Fehler gefunden werden, es sei denn, der Codegenerator arbeitet fehlerhaft. 2. Das Modell, aus welchem die Testfälle abgeleitet werden, wird durch Reverse-Engineering aus der Implementierung der Software abgeleitet. Auch in diesem Fall ist ein manuelles Verdict notwendig. 3. Unabhängig von der Implementierung der Software wird ein spezielles Testmodell nur als Basis für den Test der Software aus den Anforderungen abgeleitet. In diesem Fall ist die Unabhängigkeit der 62

63 generierten Testfälle gewährt und es kann ein automatisches Verdict 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 unabhängiges Testmodell vorhanden, wodurch das automatische Verdict weiterhin gerechtfertigt ist. Unter Berücksichtigung der notwendigen Unabhängigkeit zwischen dem Testmodell (Basis für die Testfallableitung) und dem Implementierungsmodell (Basis für die Generierung der Implementierung) zeigt sich, dass ein automatisches Verdict nur gültig ist, wenn Test- und Implementierungsmodell voneinander unabhängig sind. Daraus folgt, dass das Verhalten in Form einer Zustandsmaschine aus dem Entwicklungsprozess für die Testfallerstellung nur verwendet werden kann, wenn sichergestellt ist, dass die Implementierung unabhängig 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 Daten Eingebettete Software für ein Automobil-Steuergerät enthält eine Vielzahl von Daten und Parametern, welche im Entwicklungsprozess in einer formalen Form abgelegt werden. Die Wiederverwendung dieser Daten für den Test spart den erneuten Eingabeaufwand und stellt eine Grundlage für die Testbedatung dar Technologische Realisierung In Bild 3.1 ist die architektonische und technologische Sicht auf das Framework dargestellt. Architektonisch hat das Framework drei Aufgaben zu erfüllen: 1. Bereitstellung verschiedener werkzeuggestützter Verfahren zum Testentwurf. 2. Speicherung der generierten Testfälle in einer formalen Testbeschreibungs-Datenstruktur. 63

64 Architektonische Sicht Technologische Sicht Artefakte aus dem Entwicklungsprozess / Testmodell Artefakte aus dem Entwicklungsprozess / Testmodell Testframework Testentwurfsmethoden Formale Testbeschreibung Codegenerator Testframework M2M Exchange.ecore M2M Werkzeuggestützte Testentwurfsmethoden M2M Testspezifikation.ecore M2Text Testbericht.ecore Ausführungsplattformen Ausführungsplattformen Bild 3.1.: Technologische Realisierung des Testframeworks. 3. Bereitstellung verschiedener Codegeneratoren, um die Testinhalte auf den verwendeten Testausführungsplattformen implementieren zu können. Die technologische Realisierung des Frameworks erfolgt unter Zuhilfenahme der in Unterabschnitt beschriebenen Konzepte der Model Driven Architecture (MDA). Dadurch ist von vornherein eine Unabhängigkeit der Implementierung von konkreten Werkzeugen und die Interoperabilität zwischen verschiedenen Implementierungen vorgesehen. Für die konkrete Implementierung wird das Eclipse Modeling Framework (EMF) und openarchitectureware (oaw) verwendet. Die im Rahmen der Arbeit erarbeiteten Meta-Modelle basieren dadurch auf dem Ecore-Meta-Meta-Modell. Um die Unabhängigkeit 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 für Testentwurfswerkzeuge zur Verfügung zu stellen. Für die Integration von Testentwurfswerkzeugen stehen damit Informationen aus dem Entwicklungsprozess formal zur Verfügung. Das Exchange-Meta-Modell kann nicht generisch angegeben werden, aber im Zusammenhang mit der in Kapitel 5 vorgestellten Heuristik zum Testentwurf wird eine konkrete Ausprägung vorgestellt. Die generierten Testfälle werden erneut durch M2M in eine formale Testbeschreibung überführt. Dieses Format hat die zentrale Aufgabe, die Test- 64

65 inhalte von den Testausführungsplattformen zu abstrahieren. Ausgehend von dieser formalen Basis kann durch Modell-zu-Text (M2Text) Transformation plattformspezifischer Implementierungscode generiert werden. Die M2Text hat den Vorteil, dass es sich um ein Schablonen (Template) basiertes Verfahren handelt. Der Großteil des zu implementierenden Codes wird dabei in einer durch Schlüsselwörter angereicherten Vorlage gespeichert. Die Transformation ergänzt diese Schlüsselwörter 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. Validierungsvorschrift kann im Kontext der modellgetriebenen Softwareentwicklung als Domänenspezifische Sprache aufgefasst werden. Definition 3.1 (Domänenspezifische Sprache) Eine Domain Specific Language (DSL) nach [49] besteht aus einem Meta-Modell, welches die Syntax 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 Das Testspezifikations-Meta-Modell Das Meta-Modell der Testspezifikation hat folgende Aufgaben: Die Abstraktion der Testinhalte von den Ausführungsplattformen. Die Formalisierung der im Unternehmen verwendeten Nomenklatur in der Domäne Test. Die Kommunikation der Testinhalte über Abteilungsgrenzen hinweg. Die Formalisierung der Testerfahrung durch wiederverwendbare Bibliotheken. Als Wurzelelement des Testspezifikations-Meta-Modells (TS-MM) dient das Element Testbibliothek. Dieses beinhaltet die Elemente Ordner und Testspezifikation. 65

66 Bild 3.2.: Das Meta-Modell der Testspezifikation. 66

67 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 Kapitel 5 entwickelten Heuristik die hierarchischen Beziehungen einer Zustandsmaschine in der Testspezifikation abbilden zu können, vermag ein Testfall- Element wiederum TestfallGruppeAbstrakt-Elemente zu aggregieren. Für 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 verwaltet. Die Testsequenz aggregiert Testschritt-Elemente. Ein Testschritt ist die kleinste mögliche Einheit; ihm werden konkrete Aktionen zugewiesen, wie Methodenaufrufe oder Berechnungsschritte. Jeder Testschritt kann Testdatum-Elemente aggregieren, welche im Kontext des Testschritts entweder Methoden-Parameter oder einzelne Variablen darstellen. Im Kontext der Äquivalenzklassenbildung und Grenzwertanalyse aus Unterabschnitt aggregiert das Element Testdatum WerteBereich- Elemente, um diese darstellen zu können. Einer Äquivalenzklasse WerteBereich ist mindestens ein Repraesentant-Element zuzuordnen. Das Element Testsequenz ist im Kontext der Testausführung als ausführbare Funktion bzw. Methode konzipiert, weshalb diesem mit dem Element Testdatensatz die Summe der Testdatum-Elemente der zugeordneten Testschritt-Elemente zugewiesen wird. Bezugnehmend auf die in Unterabschnitt eingeführten Auswahlstrategien entspricht das Element Testsequenz dem SUT, die Elemente Testdatum den Faktoren und die Elemente Wertebereich den diesen zugeordneten Leveln. Das Element Bedatungskombination entspricht einem ausgewählten Datenpunkt und das Element Testdatensatz der Summe der kombinierten Datenpunkte. 67

68 Anwendungsmöglichkeiten 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 ermöglicht. In diesem Editor ist zur Beschränkung der Komplexität zunächst die minimale Auswahlstrategie implementiert, so dass nach Angabe von Testschritt, Testdatum und Wertebereich die minimale Anzahl an Bedatungskombinations-Elementen für 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 maximale Anzahl von WerteBereich-Elementen ist drei. Daraus ergeben sich die dargestellten drei Bedatungskombinationen. Bild 3.3.: Anwendung von Auswahlstrategien in dem TS-MM Das Testbericht Meta-Modell Im Kontext des fünfphasigen Testprozesses, welcher in Abschnitt 2.2 eingeführt worden ist, ermöglicht das TS-MM die Formalisierung der Testinhalte. 68

69 Das Framework sieht vor, durch die Implementierung unterschiedlicher Codegeneratoren als M2Text-Transformation, die Inhalte des TS-MM in Code zu überführen, welcher gegen das SUT ausgeführt werden kann. Während der Ausführung hat prozessgemäß eine Protokollierung und Bewertung 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 möglich, eine in XML-serialisierte Instanz des Modells wieder in das Java-Objektmodell einzulesen und dynamisch zu verwalten. 69

70 Dieses Konzept wird für den Testbericht wie folgt angewandt: Die Codegeneratoren werden so geschrieben, dass während der Testausführung 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 während der Testausführung 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 I D T e s t s c h r i t t= Verdict= bestanden >, Bedingung ) 4 } e l s e { 5 Report (<T e s t s c h r i t t Name= fahren 6 I D T e s t s c h r i t t= Verdict= nichtbestanden >, Bedingung ) 7 } Listing 3.1: Exemplarische Implementierung von Report-Code. Dadurch entsteht mit jeder Testausführung eine Bericht-Datei, welche zunächst über die Struktur- und Namensgleichheit der Testbericht-Elemente mit der Testspezifikation in Verbindung gebracht werden kann. Technologisch ist es über die Referenzbeziehung zu den TS-MM-Elementen auch möglich, die Beziehung automatisiert herzustellen Codegenerierung Die als M2Text-Transformation mit den Mitteln von oaw realisierte Codegenerierung soll an dieser Stelle exemplarisch aufgezeigt werden. Die Thematik ist ausführlich in [26] beschrieben. Die M2Text-Transformation bedient sich der XPAND Sprache, deren wesentliches Element das Template ist, welches mit dem Schlüsselwort «DEFINE» eingeleitet wird. Das in Listing 3.2 dargestellte Template ist für das Element Testspezifikation des TS-MM definiert. Das Template erzeugt die Implementierung der Methode run der aus dem Übergabewert «classname» übergebenen Klasse. Darin wird für jedes enthaltene Testfallgruppen-Element der in den Zeilen 5 bis 10 dargestellte Code des Listings erzeugt. Die Arbeitsweise der Transformation wird an dem Beispiel des Methodenaufrufs in Zeile 7 erläutert. Für die Eingabe einer Testfallgruppe, deren Attribut Name mit dem Wert Zustand_AUS_EIN belegt ist, wird der Code TF_Zustand_AUS_EIN(); generiert. 70

71 1 «DEFINE RunBody( S t r i n g classname, S t r i n g 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 u p p e AS t f g» 5 t h i s >r e s e t ( ) ; 6 try { 7 TF «tfg. Name» ( ) ; 8 } catch ( e x c e p t i o n &e ) { 9 f p r i n t f ( s t d e r r, \ n t e s t c a s e T F «c p p I d e n t i f i e r ( t f g. Name)»... ) ; 10 } 11 «ENDFOREACH» «PROTECT CSTART / CEND / ID t h i s. Name + u s e r t c c a l l s» 14 // Protected Region f ü r e i g e n e T e s t f a l l g r u p p e n 15 «ENDPROTECT» 16 } 17 «ENDDEFINE» Listing 3.2: Exemplarische Darstellung der M2Text-Transformation. Das in Zeile 13 dargestellte Schlüsselwort leitet einen geschützten Bereich ein, dessen Inhalt bei erneuter Codegenerierung nicht mehr überschrieben wird. Auf diese Weise bleiben manuelle Anpassungen unangetastet. Es wird deutlich, dass es mit Hilfe der XPAND Sprache komfortabel möglich ist, einen Codegenerator für verschiedene Zielsprachen zu schreiben. Der größte Aufwand in der Erstellung des Codegenerators liegt darin, dass der Implementierer sowohl die Generatorsprache als auch die Zielsprache beherrschen muss Zusammenfassung Durch die Konzeption des Testframeworks und die Definition der beiden Meta-Modelle für die Testspezifikation und den Testbericht ist eine Basis geschaffen, welche es ermöglicht, verschiedene werkzeuggestützte Testentwurfsmethoden in den Entwicklungsprozess zu integrieren. Im Rahmen der verwendeten Implementierungstechnologie lassen sich, basierend auf den Meta-Modellen, grafische Editoren generieren, welche die Eingabe der Testspezifikation auch manuell ermöglichen. Im Rahmen eines Migrationsszenarios ist es in der Praxis damit denkbar, zunächst manuell die Testfälle in das Testspezifikationsformat einzugeben, die Codegenera- 71

72 toren zu erarbeiten und zu verfeinern. Danach kann die automatisierte Erstellung des TS-MM aus Testentwurfsmethoden eingeführt werden. Es ist zu beachten, dass die Testspezifikations-Datenstruktur den Daten nur eine formale Struktur gibt, sie definiert aber keine eindeutige Semantik. So besteht die Gefahr, dass Anwender aus unterschiedlichen Bereichen Inhalte unterschiedlich in diese Struktur einsortieren. Dieser Gefahr kann durch die automatische Befüllung des Formates durch werkzeuggestützte Testentwurfsmethoden und das Bereitstellen ausführlicher Beispiele vorgebeugt werden. 72

73 4. Leitanwendung Die Integration der methodischen Testfallerstellung und der automatisierten Testausführung in den Entwicklungsprozess einer Kfz-Steuergeräte- Software ist eine vielschichtige Aufgabenstellung. Daher sollen die Grundkonzepte zunächst an einer Leitanwendung entwickelt werden, welche im Folgenden vorgestellt wird. Im Kontext von Bild 2.15 liegt der Fokus zunächst auf dem Modultest. Diesem Ansatz liegt das Motto der Konstruktionslehre von innen nach außen zugrunde. Als Leitanwendung wird das Softwaremodul Druckregler aus der Steuerungssoftware eines Automatik-Getriebes ausgewählt Physikalische Grundlagen Die Schaltvorgänge innerhalb eines automatischen Getriebes werden hydraulisch ausgelöst. Die Steuerung dieser Vorgänge erfolgt über 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 Schaltgerät 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 Ölpumpe nachgeschaltet. Da der an den anderen Ventilen anliegende Druck von diesem Arbeitsdruck abhängt, kann im Gesamtsystem kein höherer Druck als der Arbeitsdruck herrschen. Durch die Vorgabe eines Stroms an die Magnetventile ist es der Elektronischen Getriebesteuerung (EGS) möglich, die Stellglieder des Systems mit einem Druck zu beaufschlagen und somit die Gangwechsel des Getriebes zu steuern. Da die innerhalb des Steuergerätes implementierten Algorithmen die Größe Druck verwenden, wird innerhalb der Gesamtsoftware ein Modul 73

74 Schaltglieder Schaltmagnetventile 6-7 bar 25 bar Ölpumpe HD Regelmagnetventile [ZF-Schulung: Grundlagen Automatikgetriebe] Bild 4.1.: Hydraulisches Schaltgerät und vereinfachter hydraulischer Schaltplan [7]. benötigt, 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 ZF FRIEDRICHSHAFEN Aktiengesellschaft 4.2 dargestellt ist. Die Kennlinie Beschreibung: wird nicht Funktionsspezifikation interpoliert. SieNr.: wird durch Zusatzbenennun Druckregler A4 einen maximal und einen minimal 3.7 Einschalten möglichen Druck begrenzt, p max respektive p min. Es wird kein kleinerer Strom als der applizierbare Ruhestrom I 0 ausgegeben. Beim Einschalten des Magnetventils muss ein applizierba- ZF FRIEDRICHSHAFEN Aktiengesellschaft Beschreibung: Funktionsspezifikation Zusatzbenennun Druckregler 3.5 Druck in Strom umrechnen Nr.: DIN A4 Seite 6 von 13 p soll DIN Seite 7 von 13 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. I Max I 2 t I soll DR_[x].I_Einsprung I 1 I 0 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- p Min p 1 p 2 p Max 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. t DR_[x].t_Einsprung Bild 4.2.: Druck-Strom-Kennlinie 3.8 vorgeben des Moduls Druckregler (DR). Dem Druckregler werden zwei Drücke übergeben: p_steuer_soll, p_regel_soll. p_steuer_soll 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 ermittel 74 p_soll = p_steuer_soll + p_regel_soll Eine Druckvorgabe ist nur möglich, wenn der Druckregler eingeschaltet und nicht durchgesteue

75 rer Stromimpuls I Einsprung ausgegeben werden, um zu gewährleisten, dass das Ventil sich nicht verklemmt. Dieser Zusammenhang wird ebenfalls in Bild 4.2 dargestellt. Die Zeitdauer t Einsprung, für welche I Einsprung anliegt, hängt von der Temperatur des Getriebeöls im Ölsumpf T Sumpf ab und ist wiederum durch eine Kennlinie beschrieben. Durch eine übergeordnete Regelung, wie sie in Bild 4.3 dargestellt ist, wird der Solldruck p Soll berechnet. p Soll = p Steuer Soll + p Regel Soll (4.1) Der Solldruck wird in einen korrespondierenden Strom umgerechnet. Dabei ist die Sollwertvorgabe immer positiv, p Steuer Soll R +. Für die Rückführung des zu regelnden Wertes gilt: p Regel Soll R. p Steuer_Soll p Soll Regler Strecke p Regel_Soll Bild 4.3.: Übergeordnete Regelung, in welche das Softwaremodul eingebunden ist. Durch das Durchsteuern eines Ventils wird dieses hydraulisch geöffnet. Der sich dabei einstellende Druck p Ist hängt von dem Druck p max und von dem durch den Hauptdruckregler eingestellten Arbeitsdruck im Gesamtsystem p HD ab. Damit berechnet sich der anliegende Druck zu: p Ist = min(p HD, p max ) (4.2) Wenn das Softwaremodul in eine übergeordnete Regelung eingebunden ist, kann ein Gradientenfilter für den ausgegebenen Strom aktiviert werden, welches die Regelung komfortabler und numerisch stabiler macht. Ferner bietet das Softwaremodul die Möglichkeit, einen Mindestdruck an dem jeweiligen Ventil zu gewährleisten. Durch den Mechanismus automatisches Deaktivieren kann die Steuerung die Bestromung des Ventils auf das Minimum herunterfahren. 75

76 4.2. Software-Design und Implementierung Aus den physikalischen Anforderungen wird das Design des Moduls abgeleitet. Da die Magnetventile in dem hydraulischen Schaltgerät mehrfach in ähnlicher Form vorkommen, bietet sich eine objektorientierte Implementierung der Software an, welche im Folgenden durch UML-Diagramme erläutert wird Klassendiagramm Die Klasse cdruckregler wird für die mehrfach vorkommenden physikalischen Objekte jeweils neu instanziiert und bedatet. Die physikalische Abhängigkeit aller Drücke in den Ventilen von dem eingeregelten Hauptdruck wird im Design dadurch berücksichtigt, dass es eine Instanz für den Hauptdruckregler gibt, welche den Hauptdruck an alle übrigen Instanzen bindend vorgibt. Dieser Sachverhalt ist in dem Klassendiagramm des Softwaremoduls, welches in Bild 4.4 dargestellt ist, durch die Kompositionsbeziehung HD realisiert. Die Abhängigkeit der Impulszeit t Einsprung von der Sumpftemperatur des Getriebes ist durch eine Referenz zu der Klasse ctempsensor realisiert, die im Klassendiagramm nicht dargestellt ist. Der innerhalb des Moduls berechnete Strom wird in einer Instanz der Klasse cocg abgelegt, welche die Implementierung des Stromreglers realisiert. Zu diesem Zweck besteht zwischen den beiden Klassen wiederum eine Kompositionsbeziehung. Die Bedatung der unterschiedlichen Instanzen erfolgt über ein Datenfeld. Um dessen Parameter in unterschiedlichen Speicherbereichen des in der EGS eingesetzten Mikrocontrollers ablegen zu können, implementiert die Klasse cdruckreglerdf die Zugriffsmethoden auf die Daten, welche wiederum durch Referenzbeziehungen in unterschiedlichen Strukturen abgelegt sind. Diese Strukturen können gezielt auf Speicherbereiche abgebildet werden. Die Klasse cdruckregler aggregiert die Zugriffsklasse cdruckreglerdf. 76

77 cdruckregler Init Run DruckVorgeben HoleIstdruck HoleIndexAIM cdruckregler SteuerdruckVorgeben RegeldruckVorgeben Einschalten Ausschalten Durchsteuern Regeln MinDruckGarantieEin MinDruckGarantieAus MinDruckGarantieIstEin MaxDruckVorgeben SetzeVariante Run_200ms DruckBerechnen Stromregler 1 Stromregler DruckFilterungEin 1 DruckFilterungAus cocg SetCurrent GetCurrent AcceptDiagnosis Reset Load Flush ComputeDAC GetTrexDiagnosis SetMode SetDiagnosticCurrent Enable Disable HD 1 Datenfeld 1 cdruckreglercaldf I_Cal_Offset () 1 1 «byname» EeCalData 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 1 () 1 ptr_df sdf {Structure} t_einsprung I_Einsprung I_null p_ew_dr_ina... Attribute1 1 DF_RAM_EEP 1 ptr_df_eerom 1 1 ptr_df_eeram sdf_eep {Structure} p_i_kl 1 sfixdf_eep {Structure} I_ANLE_A I_ANLE_B I_ANLE_D I_ANLE_E I_ANLE_F I_ANLE_WK Bild 4.4.: Klassendiagramm des Softwaremoduls Druckregler. 1 77

78 Zustandsdiagramm Das Verhalten der Klasse cdruckregler wird durch ein UML- Zustandsdiagramm beschrieben, welches in Bild 4.5 dargestellt ist. Dieses S trom regler_fehler/ / AUSGESCHALTET Entry/Stromregler.SetCurrent(Datenfeld.I_null())... A us s c halten/ Stromregler_OK/Stromregler.Reset E ins c halten/ FEHLER S trom regler_fehler/ DRUCK_REGELN EINGESCHALTET EINSPRUNG Entry/Stromregler.SetCurrent(Datenfeld.I_Einsprung()) Superzustand Orthogonaler Bereich REGELND Entry/ I_Soll = DruckInStromUmrechnen(p_Soll) Stromregler.SetCurrent(I_Soll) DruckVorgeben/ I_Soll = DruckInStromUmrechnen(p_Soll) Stromregler.SetCurrent(I_Soll) Durc hs teuern/ DURCHGESTEUERT Entry/ p_soll = HD.HoleIstdruck()+Datenfeld.p_HD_Offset() I_Soll = DruckInStromUmrechnen(p_Soll) Stromregler.SetCurrent(I_Soll)... after( Datenfeld.t_Einsprung() )/ R egeln/ R egeln/ when( HD.HoleIstdruck() + Datenfeld.p_HD_Offset() < p_max_zul )/ when( HD.HoleIstdruck() > p_max_zul )/ Entry/ Entry/ Superzustand DRUCK_BEGRENZEN DRUCK_ABSENKEN I_Soll = DruckInStromUmrechnen(p_Soll - Datenfeld.delta_p) Stromregler.SetCurrent(I_Soll) after( Datenfeld.t_Absenken )/ REGELN I_Soll = DruckInStromUmrechnen(p_max_zul) Stromregler.SetCurrent(I_Soll) AUTODEAKTIVIEREN when( p_soll <= Datenfeld.p_EW _DR_inaktiv() )/ Orthogonaler Bereich AKTIV when( p_soll > Datenfeld.p_EW _DR_inaktiv() )/ INAKTIV after( Datenfeld.t_inaktiv )/Ausschalten MINDESTDRUCK_GARANTIEREN GARANTIE_AUS M indruckgarantiee in/ Orthogonaler Bereich M indruckgarantiea us/ GARANTIE_EIN Bild 4.5.: Verhaltensbeschreibung des Softwaremoduls Druckregler durch ein UML-Zustandsdiagramm. weist die im Rahmen der UML möglichen Strukturierungselemente Hierarchie und Parallelität auf, um das Verhalten besser darstellen zu können. Der Zustand Eingeschaltet ist ein Superzustand, welcher drei parallele Regionen {DRUCK REGELN, AUTODEAKTIVIEREN und MINDEST- DRUCK GARANTIEREN } enthält. Damit wird ermöglicht, die Methoden für die Festlegung eines Mindestdrucks und die Steuerung der Funktionalität automatisches Deaktivieren bereitzustellen, während sich das System in der Region DRUCK REGELN befindet. 78

79 Die Region DRUCK REGELN enthält ferner den hierarchischen Superzustand DRUCK BEGRENZEN, welcher die Teilfunktionalität für die Aktivierung des Gradientenfilters beinhaltet. Das bereits aufgezeigte Design wird innerhalb des zugrundeliegenden Entwicklungsprozesses manuell in die Implementierungssprache C++ übertragen Testausführungsplattform Für den Test der Implementierung wird ein Unit-Test-Framework verwendet, welches sich an den Artikel [11] anlehnt. Der Aufbau ist in Bild 4.6 dargestellt. 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 Verfügung. Dieser Methode können boolesche Bedingungen übergeben werden, welche nach einer erfolgreichen Ausführung die Variable n pass inkrementieren, andernfalls die Variable n fail. Für jede zu testende Klasse csuti wird eine Instanz der Klasse ctest angelegt, welche die zu testende Klasse referenziert. Um einen Testschritt innerhalb des Unit-Test-Frameworks bewerten zu können, muss dieser als Assertion vom Typ bool formuliert werden. Diese Assertion wird der Methode do test() übergeben, welche die Klassenvariablen n pass und n fail entsprechend inkrementiert. 79

80 Die Klasse csuite ermöglicht es, die innerhalb eines Projektes entstandenen Instanzen der Klasse ctest gemeinsam auszuführen, indem sie diese referenziert Aufgaben für die Testimplementierung Der Entwickler muss für 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 für den Test lauffähiges Programm erstellbar ist. 3. Implementierung der Testinhalte in der Klasse cdruckreglertest. Die Arbeitspunkte 1. und 2. sind häufig so arbeitsintensiv, dass für den Arbeitspunkt 3., welcher für die Aussagekraft des Tests am Wichtigsten ist, am wenigsten Zeit bleibt. An dieser Stelle soll das erarbeitete Testframework den Entwickler unterstützen, sowohl die Infrastruktur für den Test aufzubauen, als auch werkzeuggestützte Methoden einzubringen. 80

81 5. Heuristik zur modellbasierten Testsequenzgenerierung Das folgende Kapitel widmet sich dem Aufgabenschwerpunkt, die blackbox Testentwurfsmethoden Zustandsbasierter Test und Äquivalenzklassenbildung/Grenzwertanalyse im Rahmen des in Kapitel 3 beschriebenen Testframeworks zur Anwendung zu bringen. Dazu wird eine Heuristik zur Testsequenzgenerierung erarbeitet, basierend auf Artefakten aus dem Entwicklungsprozess. Das Vorgehen wird anhand der Leitanwendung erklärt, welche in Kapitel 4 eingeführt worden ist. Testframework Artefakte aus dem Entwicklungsprozess / Testmodell M2M Exchange.ecore M2M Heuristik M2M Testspezifikation.ecore M2Text Ausführungsplattformen (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 eingeführt werden. Die Heuristik soll im Rahmen des Testframeworks generisch weiterverwendet werden können. Im Kontext der Leitanwendung bedarf es daher einer spezifischen Ausprägung des Exchange-Meta-Modells, um die gegebenen Artefakte aus dem Entwicklungsprozess für die Heuristik aufzubereiten. Dieser Sachverhalt wird in Abschnitt 5.2 erläutert. Die Heuristik selbst wird in Abschnitt 5.3 vorgestellt. 81

82 5.1. Prinzip der Testsequenzgenerierung aus Zustandsmaschinen Der folgende Abschnitt zeigt das allgemeine Prinzip der Testsequenzgenerierung aus Zustandsmaschinen auf, welches häufig auch unter dem Schlagwort modellbasiertes Testen [54] eingeführt wird. Die Vorgehensweise, aus einer endlichen Zustandsmaschine der Form M = S, T Testsequenzen Testprinzip zu deren Verifikation zu generieren, ist in Bild 5.2 dargestellt. Durch die Testsequenzen Regler Modell des SUT Strategie Aus Einschalten/ Ausschalten/ Ein Stimulation ZFF TE-NL/FKFS 8 Regler - System Under Test Testimplementierung Strategien zur Testfallgenerierung aus UML-Zustandsautomaten Prüfung Testschritt 1: System im erwarteten Ausgangszustand? Testschritt 2: Stimulation eines Übergangs. Testschritt 3: System im erwarteten Zielzustand? Bild 5.2.: Prinzip der automatischen Testsequenzgenerierung. ZF Friedrichshafen AG, 2008 Anwendung einer Generierungsstrategie, näher erläutert in Unterabschnitt 5.1.1, wird zunächst ein Übergangsbaum abgeleitet. Die Pfade durch diesen Übergangsbaum stellen den Testinhalt dar. Im Rahmen des Frameworks wird dieser Testinhalt in eine Instanz des Testspezifikations-Meta- Modells überführt, wodurch die plattformunabhängige Testspezifikation erstellt wird. Der eigentliche Test erfolgt nach folgendem Schema: 1. Prüfen, ob sich das System in dem jeweiligen Ausgangszustand befindet und stimulieren der Verhaltensspezifikation des Zustandes. 2. Stimulieren der Verhaltensspezifikation der Transition, um diese zu durchlaufen. 3. Prüfen, ob das System den Zustandswechsel vollzogen hat und stimulieren der Verhaltensspezifikation des Zielzustandes. 82

83 Generierungsstrategien Das Ziel der in der Literatur definierten und beschriebenen Generierungsstrategien ähnelt den in Unterabschnitt beschriebenen Kontrollflusskriterien. Es ist eine Testspezifikation zu berechnen, welche zu einer entsprechenden Überdeckung des SUT (M) führt. Die gebräuchlichsten Strategien in Anlehnung an [16, 20] sind: Zustandsüberdeckung: Eine Testspezifikation, welche der Zustandsüberdeckung genügt, erreicht jeden Zustand mindestens einmal. Transitionsüberdeckung: Eine Testspezifikation, welche der Transitionsüberdeckung genügt, stimuliert jede Transition mindestens einmal. N+ Strategie: Ausgehend von jedem Zustand werden alle Übergangs- Bedingungen aktiviert. Pfadüberdeckung: Eine Testspezifikation, welche der Pfadüberdeckung genügt, stimuliert alle möglichen Pfade durch die Zustandsmaschine. Dies bringt den Vorteil, dass Zustände auf allen möglichen Pfaden erreicht werden. Dadurch können Fehler aufgedeckt werden, welche von der Art abhängen, wie der Zustand erreicht wurde Auffindbare Fehler Im Rahmen der Implementierung zustandsbasierten Verhaltens können die folgenden Fehler auftreten. Bezugnehmend auf die in Abschnitt 2.5 vorgestellten potenziellen Softwarefehler handelt es sich um Funktionale Fehler. Falscher Übergang: Die Implementierung durchläuft einen nicht aus der Spezifikation stimulierten Übergang. Falsche Aktion: Die an einen Übergang geknüpfte Aktion ist fehlerhaft. Nicht spezifizierter Übergang: Bei dem Aufruf eines Events wird in der Implementierung ein Übergang stimuliert, welcher in dem Modell nicht vorgesehen ist. 83

84 Nicht spezifizierter Zustand: Bei dem Aufruf eines Events wird in der Implementierung ein Zustand erreicht, welcher in dem Modell nicht vorgesehen ist Auswahl einer Strategie zur Testsequenzgenerierung Ziel der folgenden Betrachtungen ist es, zu entscheiden, welche Generierungsstrategie eingesetzt werden soll. Dazu zeigt Tabelle 5.1 auf, welche Strategie welche Fehler aufdecken kann [41]. Eine Testspezifikation, welche der Zustandsüberdeckung genügt, vermag keinen der betrachteten Fehlertypen zu finden. Dieses liegt darin begründet, dass ein Zustand ggf. über mehr als eine Transition erreicht werden kann und so die Testspezifikation nicht mit Sicherheit falsche Transitionen bzw. Aktionen aufdecken kann. Eine Testsuite, welche der Transitionsüberdeckung genügt, vermag diese Fehler aber aufzudecken. Ein nicht spezifizierter Zustand bzw. Übergang tritt auf, wenn das System aus einem Zustand auf ein Ereignis reagieren muss, welches laut Spezifikation nicht auftreten dürfte. Solche nicht spezifizierten Ereignisse werden durch eine Testspezifikation ausgelöst, welche der N+ Strategie genügt. Zustandsüberdeckung Transitionsüberdeckung Falsche Transition Nein Ja Ja Falsche Aktion Nein Ja Ja Nicht spezifizierte Transition Nicht spezifizierter Zustand Abschätzung der Testschrittanzahl N+ Nein Nein Ja Nein Nein Ja 2 n m n m 2 n 2 Tabelle 5.1.: Welche Strategie kann welche Fehler aufdecken? n Anzahl der Zustände, m Anzahl der Transitionen. 84

85 Wie aus der Tabelle 5.1 ersichtlich wird, steigt durch den Einsatz der N+ Strategie die Anzahl der generierten Testschritte (prüfen, stimulieren,...) gegenüber der Transitionsüberdeckungsstrategie an. Unter Berücksichtigung der Prämisse, die Testspezifikation so übersichtlich wie möglich zu gestalten, stellt sich die Frage, welchen Mehrwert der Einsatz der N+ Strategie bringen würde. Die Antwort kann zwar nicht generisch, aber im Kontext der Leitanwendung gegeben werden. Wie bereits erwähnt, liegt der Quellcode der zu testenden Implementierung vor und eine werkzeuggestützte Kontrollflussmessung wird auf diesem ausgeführt. Da ein im Testmodell nicht spezifizierter Zustand in der Implementierung auch nicht stimuliert wird, entsteht in diesem Bereich eine mangelnde Überdeckung. Eine Testspezifikation, welche mit der Generierungsstrategie Transitionsüberdeckung erzeugt wurde, zeigt die mangelnde Code-Überdeckung an der Stelle des nicht spezifizierten Zustandes damit genauso auf. Ähnliches gilt für nicht spezifizierte Transitionen. Somit kann die Strategie Transitionsüberdeckung für die Leitanwendung eingesetzt werden, ohne die Vorteile der N+ Strategie zu verlieren Umgang mit erweiterten endlichen Zustandsmaschinen Die beschriebenen Generierungsstrategien setzen eine endliche Zustandsmaschine 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 Zustandsmaschinen führen im Wesentlichen die Konzepte der Hierarchie und der Orthogonalität von Zuständen ein. Um die gängigen Generierungsstrategien dennoch anwenden zu können, werden in der Literatur [16, 17, 19] verschiedene Ansätze vorgeschlagen, wie die erweiterte Zustandsmaschine in eine äquivalente, endliche Zustandsmaschine überführt werden kann. History-Zustände, welche sich einen Zustand über mehrere Ausführungsschritte merken können, sollen im Rahmen der Arbeit ausgeschlossen werden. 85

86 Auflösen von Hierarchie Durch das Konzept der Hierarchie wird eine Strukturierungsmöglichkeit eingeführt. Diese gestattet es dem Modellentwickler, eine Teilzustandsmaschine einer anderen unterzuordnen. Die Gruppierung zu einem hierarchischen Zustand hat dabei folgende Bedeutung: Alle in den hierarchischen Zustand führenden Transitionen führen zu dem untergeordneten Initialzustand. Wenn die Transition von dem Initialzustand zu dem ersten Zustand innerhalb des hierarchisch untergeordneten 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 ihren Ursprung in jedem der untergeordneten Zustände, 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 Auflösen der hierarchischen Strukturierung keinen großen Einfluss auf die resultierende Komplexität hat. Schwerwiegender ist, dass das eingeführte Strukturierungselement in den generierten Testsequenzen nicht mehr zur Verfügung steht. i) vorher DURCHGESTEUERT (2) DRUCK_BEGRENZEN (4) (4.0) ii) nachher DURCHGESTEUERT (2) DRUCK_ABSENKEN (4.1) REGELND (3) REGELN (4.2) REGELND (3) DRUCK_BEGRENZEN (4) DRUCK_ABSENKEN (4.1) (4.0) REGELN (4.2) Bild 5.3.: Interpretation eines hierarchischen Zustandes Auflösen von Orthogonalität Ein orthogonaler Zustand wird in der Literatur auch als And-Zustand bzw. als nebenläufiger Zustand bezeichnet. Durch das Konzept der Orthogonalität werden parallel ausführbare Zustandsmaschinen beschrieben. In Bild 5.4 wird dies anhand des Anwendungsbeispiels zweier unabhängig ansteuerbarer Elektromotoren dargestellt. Diese sind so angeordnet, dass der 86

87 eine eine Bewegung nach rechts oder links und der andere eine Bewegung nach oben oder unten verursacht. Im ersten Teil des Bildes ist die äquivalente Zustandsmaschine dargestellt, welche die kombinierten Zustände beinhaltet. Im zweiten Teil ist das Verhalten mit Hilfe zweier orthogonaler Zustandsmaschinen dargestellt. Die Darstellung macht deutlich, dass die Moving Up-Left e) f) d) Moving Up e) Moving Up-Right a) b) b) Moving Left c) Moving Down-Left e) d) e) d) a) b) Stopped b) c) b) f) Moving Down f) e) e) a) b) Moving Right c) 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() Moving Up Moving Left b) c) a) Stopped b) e) f) d) Stopped e) Moving Down Moving 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() Bild 5.4.: Orthogonalität. Erfassung des Verhaltens der beiden Motoren unter Zuhilfenahme der orthogonalen Darstellung einfacher ist, da die verknüpfende Kombination der beiden Bereiche implizit modelliert wird und nicht explizit erfasst werden muss. Die in der Literatur beschriebenen Ansätze [20] zur Ableitung einer äquivalenten Zustandsmaschine aus orthogonalen Zustandsmaschinen gehen nach dem folgenden Schema vor: Bilden der möglichen Zustands-Konfigurationen. Eine Konfiguration ist eine Menge von Zuständen, welche die Zustände zusammenfasst, die gleichzeitig aktiv sein können (Bsp. Rechts-Oben). Zusammenfassung der Konfigurations-Transitionen, welche sich durch sequenzielle Verknüpfung der Transitionen der Zustände aus den jeweiligen Konfigurationen ergeben. 87

88 Dieses Vorgehen setzt voraus, dass die Verhaltensspezifikationen der Transitionen und Zustände der orthogonalen Zustandsmaschinen disjunkt sind. Im konkreten Fall bedeutet dies: Wenn der Steuerbefehl für den einen Elektromotor auch eine Auswirkung auf den anderen Elektromotor hat, so kann das Gesamtverhalten nicht mehr einfach dargestellt werden. Für die im Rahmen der Arbeit entwickelte Heuristik ergibt sich das Ziel, die durch die Orthogonalität eingeführte, kompakte Darstellung auch in den generierten Testsequenzen beizubehalten Integration in das Framework Im Rahmen der Arbeit wird eine neuartige Heuristik zur Testsequenzgenerierung entworfen, welche basierend auf erweiterten Zustandsmaschinen eine Testspezifikation erstellt. Um die Heuristik generisch einsetzen zu können, baut diese auf der in Unterabschnitt beschriebenen allgemeinen Schnittstelle auf. Die Funktionsweise und die Konzepte werden anhand der in Kapitel 4 vorgestellten Leitanwendung entwickelt. In diesem Kontext wird zunächst auf die verfügbaren Artefakte aus dem Entwicklungsprozess in Unterabschnitt eingegangen. Darauf aufbauend wird eine konkrete Ausprägung des Exchange-Meta-Modells in Unterabschnitt vorgestellt, welche die Adaption der Heuristik für die Leitanwendung ermöglicht. In Unterabschnitt wird schließlich darauf eingegangen, wie die Instanziierung des Exchange-Meta-Modells erfolgt Allgemeine Schnittstelle der Heuristik Die Heuristik soll die Konzepte des Zustandsbasierten Testens basierend auf endlichen Zustandsmaschinen unterstützen, sowie die Äquivalenzklassenbildung und Grenzwertanalyse. Vor diesem Hintergrund wird die allgemeine 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

89 SM S = {s 1, s 2,..., s n } T = {t 1, t 2,..., t m } R = {r 1, r 2,..., r l } W = {w 1, w 2,..., w k } Das Element SM stellt das Wurzelelement der Zustandsmaschine dar und speichert die Information, welcher Zustand als Ausgangspunkt für die Testsequenzgenerierung gekennzeichnet ist. Die Menge S repräsentiert die n Zustände s der Maschine. Die Menge T repräsentiert die m Transitionen t der Maschine. Die Menge R, bestehend aus l Regionen r, repräsentiert das Strukturierungselement für hierarchische und orthogonale Bereiche, es kann wiederum Zustände und Transitionen aggregieren. Die Menge W entspricht den k Werte Bereich- Elementen w. Diese repräsentieren die Äquivalenzklassen und Grenzwerte der Attribute und Parameter, die im Testmodell verwendet werden. Diese Mengen stellen die für 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 E T = {e T 1, e T 2,... e T } E S = {e S 1, e S 2,... e S } G G T = {g1 T, g2 T,... g T } G S = {g1 S, g2 S,... g S} E ist die Menge von Ereignissen e. Ereignisse, welche eine Transition auslösen können, werden e T bezeichnet. Ereignisse, welche beim Betreten eines Zustandes ausgelöst werden, werden e S bezeichnet. G ist die Menge von Guard-Bedingungen g. Guard-Bedingungen, welche zu einer Transition gehören, werden g T bezeichnet. Die Zugehörigkeit zu einem Zustand wird durch g S gekennzeichnet. 89

90 A A T = {a T 1, a T 2,... a T } A S = {a S 1, a S 2,... a S } W : W S W W T W W T = {w1 S, w2 T,... w T } W S = {w1 T, w2 S,... w S} V S = E S G S A S W S V T = E T G T A T W T A ist die Menge von Aktionen a. A T kennzeichnet den Bezug zu einer Transition, A S den Bezug zu einem Zustand. Den im Kontext der Mengen E, G und A verwendeten Attributen und Parametern sind durch die Menge W Äquivalenzklassen und Grenzwerte zugewiesen. Die Menge W S bezieht sich dabei auf die Verhaltensspezifikation der Zustände, die Menge W T auf die der Transitionen. V S ist die Menge der Verhaltensspezifikationen eines Zustandes. Beim Betreten des Zustandes kann ein Event (e S x) aufgerufen werden, welches nach der Erfüllung einer Guard- Bedingung (gx S ) zu dem Aufruf einer Aktion (a S x) führt. Dies erfolgt gemäß der Syntax: e S x[gx S ]/a S x. Den dabei verwendeten Attributen und Parametern sind durch die Menge W S Äquivalenzklassen und Grenzwerte zugewiesen. V T ist die Menge der Verhaltensspezifikationen einer Transition. Durch den Aufruf eines Events (e T x ) und die Erfüllung einer Guard- Bedingung (g T x ) wird die Transition von einem Zustand in den darauffolgenden Zustand unter Aufruf der Aktion (a T x ) durchgeführt. Dies erfolgt gemäß der Syntax: e T x [g T x ]/a T x. Dabei sind die WerteBereich-Elemente in der Menge W T zusammengefasst. Tabelle 5.3.: Erläuterung der Verhaltensspezifikation. Ferner ist im Kontext des Testmodells EM definiert, welche Relationen zwischen den Mengen bestehen. Diese sind in Tabelle 5.4 zusammengefasst. 90

91 T S V T S R T S S S R Eine Transition t ist eine Relation zwischen Zuständen, wobei der Übergang von einem Ausgangs-Zustand (source) in einen Zielzustand (target) gemäß einem Element der Verhaltensspezifikation V T beschrieben wird. Eine Region r stellt über die Aggregation von Elementen t T und s S eine Relation zwischen diesen dar. Durch die Regionen wird die Information über die Strukturierung des Modells in hierarchische und orthogonale Bereiche transportiert. Ein Zustand s kann über die Aggregationsbeziehung zu einer Region r keine, eine oder mehrere Regionen beinhalten. Tabelle 5.4.: Relationen zwischen den Modellelementen. Der Einfachheit halber soll es im Folgenden möglich sein, auf die Attribute und Relationen der Modellelemente mit dem Punkt-Operator (.) zugreifen zu können. Bsp.: t 1.source = {Name des Ausgangszustands der Transition}. Ferner soll es möglich sein, die Attribute und Relationen eines Elements in runden Klammern anzugeben, um deren Zusammenhang darstellen zu können. Transitionen werden durch den Index des Ausgangsund des Endzustandes indiziert. Die Menge der Zustände S beinhaltet auch die Pseudozustände Start ( )- und Endzustand ( ). Der Zugriff auf den Startzustand einer Region erfolgt durch die Operation r.s s. Der Zugriff auf den Endzustand durch die Operation r.s e. Mit dem Testmodell werden folgende Definitionen eingeführt: Definition 5.1 (Region) Eine Region r i R beinhaltet Zustände und Transitionen. Die Region r 0 beinhaltet das gesamte Zustandsdiagramm. Weitere Regionen kommen in Superzuständen oder orthogonalen Zuständen vor. 91

92 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, welcher 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} > Verfügbare Artefakte der Leitanwendung Das zu testende Verhalten der Leitanwendung ist in Form eines Klassendiagramms mit einem zugeordneten Zustandsdiagramm in einem UML- Werkzeug 1 beschrieben. Da die Implementierung des Verhaltens im Rahmen der Leitanwendung manuell erfolgt ist, ist es zulässig, diese Design- Artefakte für die Testgenerierung zu verwenden. Um die Äquivalenzklassen- und Grenzwerte bereits im Design spezifizieren zu können und die Generierung von Testsequenzen aus dem Zustandsdiagramm steuern zu können, 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 Elemente in Form von Äquivalenzklassen und Grenzwerten zu spezifizieren. Dafür ist dessen Tagged-Value Wertebereich vorgesehen. Durch die Zuweisung des Stereotyps an eine Operation wird deren Rückgabewert klassifiziert. Durch die Tagged-Values Setter 2 und Getter können die Methoden 1 Artisan-Studio 2 In der objektorientierten Programmierung werden die Methoden zum Setzen und Lesen von Eigenschaften einer Klasse häufig als Set- und Get-Methoden bezeichnet. 92

93 spezifiziert werden, welche für 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 Konzeption des Exchange-Meta-Modells Um das in dem mächtigen UML-Meta-Modell beschriebe Klassen- und Zustandsdiagramm der Leitanwendung in das für das Framework und die Heuristik benötigte Testmodell EM zu überführen, wird im Folgenden das Bild 5.5.: Aufbau des Exchange-Meta-Modells. 93

94 Exchange-Meta-Modell für diese Anwendung konzipiert. Sein Aufbau ist in Bild 5.5 dargestellt. Im Kontext des für 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 Attribut SMUT des Elements StateMachineType ist dafür vorgesehen, den im UML-Zustandsdiagramm mit dem Stereotyp «SMUT» gekennzeichneten Zustand aufzunehmen. Die Elemente StateType und PseudoState sollen die Zustände 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 für Zustände und Transitionen spezifiziert. Sie bedienen sich aus den der übergeordneten Klasse zugeordneten Operationen und Attributen bzw. aus den assoziierten Klassen. Dieser Zusammenhang ist durch die Modellelemente Class, Operation und Attribute berücksichtigt. Insbesondere ist vorgesehen, dass Attributen und Parametern von Operationen Äquivalenzklassen und Grenzwerte zugewiesen werden können. Die Kennzeichnung der Äquivalenzklassen erfolgt im UML-Klassendiagramm durch das Stereotyp «Value». In dem Exchange-Meta-Modell sind die Elemente Attribute und Parameter definiert, um diese Information aufzunehmen. Zu diesem Zweck aggregieren die Elemente Parameter und Attribute das Element Value mit dem Attribut range zur Aufnahme der Wertebereiche Instanziierung der Leitanwendung Im Kontext des Frameworks wird die Leitanwendung zunächst in eine Instanz des Exchange Meta-Modells überführt, welche wiederum in das der Heuristik zugrundeliegende Testmodell EM überführt wird. 94

95 In Bild 5.6 wird dargestellt, wie das in Bild 4.5 eingeführte UML- Zustandsdiagramm der Leitanwendung in eine Instanz des Exchange-Meta- Modells überführt wird. Der mit dem Stereotyp «SMUT» gekennzeichnete Initial (0.0) cdruckregler AUSGESCHALTET (0.1) FEHLER (0.2) EINGESCHALTET (0.3) DRUCK_REGELN EM 1 «SMUT» Initial1 (0) EINSPRUNG (1) DURCHGESTEUERT (2) REGELND (3) DRUCK_BEGRENZEN (4) (4.0) DRUCK_ABSENKEN (4.1) REGELN (4.2) AUTODEAKTIVIEREN EM 2 Initial2 (5) Final2 (8) AKTIV (6) INAKTIV (7) MINDESTDRUCK_GARANTIEREN EM 3 Initial3 (9) GARANTIE_AUS (10) GARANTIE_EIN (11) Bild 5.6.: Abbildung eines UML-Zustandsdiagramms in das Exchange- Meta-Modell. Zustand wird innerhalb des Exchange-Meta-Modells als Attribut des Elements StateMachineType vermerkt. Innerhalb des Beispiels ist der Initialzustand der Region DRUCK REGELN markiert. Die folgenden Ausführungen 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 r 0.name = cdruckregler abgebildet wird. Die Region r 0 beinhaltet die Zustände: S = {s 0.name = Initial, s 1.name = AUSGESCHALTET, s 2.name = EIN- GESCHALTET, s 3.name = FEHLER}. 95

96 Ferner beinhaltet r 0 die Transitionen: T = {t 0 1, t 1 2, t 2 1, t 2 3, t 3 1, t 1 3 }. Der Zustand s 2 beinhaltet parallele Regionen. Es gilt damit s 2.R = {r 1.name = DRUCK REGELN, r 2.name = AUTODEAKTIVIEREN, r 3.name = MINDESTDRUCK GARANTIEREN}. Die verbleibenden Inhalte des UML-Zustandsdiagramms werden in analoger Weise abgebildet 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 gemäß der Transitionsüberdeckungsstrategie. Das Neue an der Vorgehensweise ist, dass die Strukturierungselemente Hierarchie und Orthogonalität 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 Testfälle zu dem Testmodell haben. Der Erhalt der Struktur gelingt, indem die Heuristik die Transitionsüberdeckungsstrategie separat auf Superzustände und orthogonale Zustände anwendet. Das in Unterabschnitt eingeführte Testspezifikations-Meta-Modell beinhaltet ähnliche Strukturierungselemente und vermag diese deshalb aufzunehmen. Die Heuristik arbeitet nach dem im Folgenden beschriebenen Schema. Bedatungsaspekt Die im Design zugewiesenen Äquivalenzklassen und Grenzwerte, welche zunächst in dem Exchange-Meta-Modell erfasst werden, werden durch die in Unterabschnitt eingeführten Auswahlstrategien aufbereitet. Die Beschreibung erfolgt im Unterabschnitt

97 Struktureller Aspekt Durch strukturelle Umformung des Testmodells wird eine Testspezifikation errechnet, um testen zu können, ob die Implementierung 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 Testfälle generiert werden. Die Heuristik identifiziert zunächst, wo das Stereotyp platziert ist und berechnet für 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 Hierarchieebene wird eine Testspezifikation gemäß der Transitionsüberdeckung errechnet. 4. Die generierte Menge von Transitionsfolgen wird derart erweitert, dass alle Zustände auf weitere Regionen hin untersucht werden. Die Beschreibung erfolgt in den Unterabschnitten bis 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 Bedatung Als Ausgangspunkt für 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 V T als auch indirekt über die Referenz zu dem Start- und Zielzustand deren Verhaltensspezifikationen V S. Um eine Testspezifikation ausführen zu können, müssen alle im Kontext der Verhaltensspezifikationen verwendeten Attribute und Parameter mit einem Zahlenwert versehen werden. In Verbindung mit der Äquivalenzklassenbildung und Grenzwertanalyse werden diesen Wertebereiche W 97

98 zugeordnet, vgl. Unterabschnitt Unter Berücksichtigung der in Unterabschnitt eingeführten Auswahlstrategien ergeben sich damit je nach eingesetzter Strategie unterschiedliche Anzahlen von konkreten Bedatungskombinationen. Für die Bestimmung der Auswahlmatrizen wird im Folgenden die minimale Auswahlstrategie aus Gleichung (2.12) herangezogen, um die Auswahlmatrix O min zu bestimmen. Ferner wird die maximale Auswahlstrategie aus Gleichung (2.13) zur Bestimmung der Matrix O max 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 Parameter und Attribute zusammen, welche der Verhaltensspezifikation V T einer Transition und der Verhaltensspezifikationen V S der zugeordneten Start- und Zielzustände 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: L i = {l i,1,..., l i,ni } mit card(l i ) = n i. In Anlehnung an Tabelle 2.1 ergeben sich damit die beiden Matrizen O min (c = n = max(n i ), k, n) und O max (c = k i=1 n i, k, n) mit c Zeilen, k Spalten für jeweils n Level. Jede Zeile entspricht dabei einer Bedatungskombination b. Für die Menge der minimalen Bedatungskombinationen B min und der maximalen Bedatungskombinationen B max gilt: B min B max (5.2) Die Differenz der beiden Mengen wird B = B max \ B min genannt. Für die Bedatung der Testspezifikation werden für jedes Transitions- Element t i j T im Testmodell EM die Matrizen O max und O min be- 98

99 stimmt. Jeder Transition werden die Mengen B max, B min undb zugeordnet, wie es Gleichung (5.3) ausdrückt. t i j : {t i j, {B max, B min, B }} = {t i j, B} (5.3) Der Zugriff auf die einzelnen Mengen soll im Folgenden über den Punkt- Operator in der Form t i j.b möglich sein. Das Vorgehen soll für die Transition von dem Zustand Ausgeschaltet in den Zustand Eingeschaltet aus Bild 5.6 veranschaulicht werden. Dem Start- und Endzustand sind keine Verhaltensspezifikationen zugewiesen. Der Transition ist die Operation Einschalten(p Steuer Soll, p Regel Soll) mit ihren beiden Parametern als Event zugewiesen. Für die Parameter sind jeweils drei Äquivalenzklassen definiert: p Steuer Soll: [0, 5000], [5001, 10001], [10001, 15000] [mbar] p Regel Soll: [0, 3000], [3001, 7001], [7001, 15000] [mbar] Die Auswahlmatrix O min wird damit für zwei Faktoren mit jeweils drei Leveln berechnet, ihre Ausprägung ist in Bild 5.7 in Klassifikationsbaumdarstellung visualisiert. Auf die Darstellung der korrespondierenden Matrix O max, welche für die gegebene Konfiguration card(b max ) = 3 3 Zeilen aufweist, wird verzichtet. p_steuer_soll p_regel_soll [0, 5000] [5001, 10001] [10001, 15000] [0, 3000] [3001, 7001] [7001, 15000] Bild 5.7.: Darstellung der Bedatunskombinationen B min. Für die Transition ergibt sich damit: t Eingeschaltet Ausgeschaltet.B min = {b 1, b 2, b 3 } (5.4) 99

100 Berechnung der Initialisierungs-Testsequenz Im Kontext der strukturellen Umformung des Testmodells dient die Initialisierungs-Testsequenz dem Zweck, das System in den für den Test gewählten Ausgangszustand zu versetzen. Sie steht damit nicht im Fokus der Testspezifikation und kann so kurz wie möglich ausfallen. Um dies zu erreichen, wird der Dijkstra-Algorithmus zur Berechnung des Initialisierungspfades verwendet, welcher die wenigsten Faktoren enthält. Als Kantengewicht wird dazu die Anzahl der Faktoren übergeben. Da der Dijkstra-Algorithmus auf einfachen, gerichteten Graphen arbeitet, ist es zunächst notwendig, das hierarchische Testmodell in einfache Teilgraphen aufzuteilen. Konkret bedeutet dies, dass wenn auf dem Weg von dem Initialzustand des Testmodells zu dem Testausgangszustand («SMUT») Regionengrenzen überschritten 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 Instanzen der Klasse subgraph zurück. 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 Endzustand innerhalb der Region. Initial (0.0) AUSGESCHALTET (0.1) FEHLER (0.2) EINGESCHALTET (0.3) DRUCK_REGELN EM 1 Initial1 (0) «SMUT» EINSPRUNG (1) DURCHGESTEUERT (2) DRUCK_BEGRENZEN (4) (4.0) DRUCK_ABSENKEN (4.1) REGELND (3) REGELN (4.2)... Bild 5.8.: Visualisierung der Initialpfadsuche. 100

101 Die Funktionsweise wird an der in Bild 5.6 dargestellten Konfiguration der Leitanwendung illustriert, in welcher der Initialzustand der ersten Region des orthogonalen Zustandes s 3.name = Eingeschaltet mit dem Stereotyp «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 Regionengrenze überschritten. Um die Teilgraphen zu berechnen, wird der Funktion der Initialzustand des Testmodells und der Testausgangszustand übergeben, der Aufruf lautet: splitgraph(start = Initial, end = Initial1). region: ret = start: end: cdruckregler Initial EINGESCHALTET ; region: start: end: DRUCK REGELN Initial1 Initial1 (5.5) Der Rückgabewert 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 enthält. Das zweite subgraph-objekt beinhaltet die Region 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 Faktoren zu finden. Der Algorithmus ist in der Funktion findlocalpath() implementiert und wird auf jedes subgraph-objekt angewendet. Die jeweils zurückgegebenen Transitionsfolgen werden zusammengefügt und der Menge P Init hinzugefügt, welche zur Initialisierung der Testspezifikation benötigt wird. Für das erste subgraph-objekt wird die Transitionsfolge p 0 = {t Initial AUSGESCHALTET, t AUSGESCHALTET EINGESCHALTET } zurückgegeben. Für das zweite subgraph-objekt wird eine leere Transitionsfolge p 1 = { } zurückgegeben, da Start- und Endzustand übereinstimmen. Die Menge von Transitionsfolgen zur Initialisierung ergibt sich damit zu: P Init = {p Init = p 0 p 1 }. (5.6) 101

102 Berechnung der Transitionsüberdeckung Der nächste Schritt in der Heuristik ist die Berechnung von Pfaden durch das Testmodell, welche alle Transitionen mindestens einmal durchlaufen, siehe Unterabschnitt Dazu wird der Algorithmus 5.1 verwendet. Neu ist, dass die Transitionsüberdeckung zunächst nur in der Region berechnet wird, welcher der Testausgangszustand angehört. Zustände, welche weitere Regionen beinhalten, werden zuerst als einfache Zustände aufgefasst und erst in einem zweiten Schritt weiter aufgelöst. Der Algorithmus wird anhand der bereits eingeführten Konfiguration der Leitanwendung vorgestellt. Ausgehend von dem markierten Testausgangszustand Initial1 geht in die Transitionsüberdeckungsberechnung der in Bild 5.9 dargestellte Teilgraph EM 1 des Testmodells EM ein. DRUCK_REGELN «SMUT» Initial1 (0) DRUCK_REGELN DRUCK_REGELN Initial1«SMUT» EINSPRUNG Entry/Stromregler.SetCurrent(Datenfeld.I_Einsprun DURCHGESTEUERT (2) REGELND (3) EINSPRUNG (1) DRUCK_BEGRENZEN (4) after( Datenfeld.t_Einsprung() )/ REGELND Entry/ I_Soll = DruckInStromUmrechnen(p_Soll) Stromregler.SetCurrent(I_Soll) DruckVorgeben/ I_Soll = DruckInStromUmrechnen(p_Soll) R Stromregler.SetCurrent(I_Soll) when( HD.Hole Durchsteuern/ Regeln/ + Datenfeld.p_H < p_max_zul )/ DURCHGESTEUERT DURCHGESTEUERT Entry/ p_soll = HD.HoleIstdruck()+Datenfeld.p_HD_Offset() I_Soll = DruckInStromUmrechnen(p_Soll) when( HD Stromregler.SetCurrent(I_Soll)... > p_max_ Bild 5.9.: Ausgangspunkt für die Transitionsüberdeckung. Übergangsbaum Die Elemente des Teilgraphen lauten: Initial1 Pfad1 Initial1 Pf SM 1 = {Initial1} EINSPRUNG S 1 = {Initial1 (0), EINSPRUNG REGELND (1), DURCHGESTEUERT (2), REGELND (3), DRUCK BEGRENZEN (4)} DURCHGESTEUERT T 1 = {t 0 1, t 1 2, t 2 3, t 3 2, t 3 4, t 4 3, t 4 2 } R 1 = {r 1 = DRUCKREGELND REGELN } W W 1 DRUCK_BEGRENZEN EINSPRUNG REGELND DURCHGESTEUERT REGELND D DURCHGESTEUERT REGELND Der Algorithmus gibt einen Übergangsbaum B = {k i } aus, welcher eine Instanz des in Bild 5.10 dargestellten Meta-Modells ist. 102

103 Bild 5.10.: Meta-Modell des Übergangsbaumes. Durch die Struktur des Testmodells 3 ist a-priori nicht zu unterscheiden, ob der Zustand Druck Begrenzen (4) ein einfacher Zustand oder ein Superzustand ist. Dadurch ist es möglich, die Transitionsfolgen stufenweise, unabhängig von den weiteren hierarchischen Strukturen des Testmodells zu generieren. Algorithmus 5.1: Algorithmus zur Berechnung der Transitionsüberdeckung. Eingabe : EM 1 = SM 1, S 1, T 1, R 1, W 1 Ausgabe : B = {k i } 1 Initialisierung: 2 k 0 = s 0 // s 0 = Initial1 3 visited: { } // Leerer Vektor 4 queue S B = {(s 0, k 0 )} // Vektor mit Paaren 5 solange queue tue 6 pair Element aus der queue nehmen (s, k ) 7 Zustand s pair.first // Zu Beginn: (s 0 ) 8 Knoten k pair.second // Zu Beginn: (k 0 ) 9 wenn Zustand / visited dann 10 visited = visited Zustand // T 1 = r 1.T : Alle Transitionen, welche zu der Region Druck Regeln gehören und damit auf der gleichen Hierarchieebene stehen, wie der Testausgangszustand. 11 für t i T 1 [t i.source == Zustand] tue 12 Knoten.child = t i.target 13 k i = Knoten.child 14 n i = (t i.target, k i ) // Ein neues queue-element anlegen 15 queue = queue n i // Das Element der queue hinzufügen 16 Ende für 17 Ende wenn 18 Ende solange 3 Instanz des Exchange-Meta-Modells 103

104 Nach der Initialisierung des Algorithmus und der Überprüfung, ob ein Zustand bereits in den Übergangsbaum aufgenommen wurde (Zeile 9), wird die Schleife in Zeile 11 betreten. Es wird nach allen Trasitionen gesucht, welche den gerade zu untersuchenden Zustand (t i.source == Zustand) verlassen und welche Teil der aktiven Region (im Beispiel DRUCK REGELN) sind. Die Entwicklung des Algorithmus ist im Anhang B für eine alternative Konfiguration des Testmodells dargestellt. Der ausgegebene Übergangsbaum hat die in Bild 5.11 dargestellte Form. Er beschreibt durch einen gerichteten Graphen Wege durch den zugrunde liegenden Teilgraphen EM 1, welche alle Transitionen mindestens einmal durchlaufen. Aus dem Übergangsbaum werden die einzelnen Transitionsfol- Übergangsbaum Initial1 (0) EINSPRUNG (1) DURCHGESTEUERT (2) REGELND (3) DURCHGESTEUERT (2) DRUCK_BEGRENZEN (4) Pfad1 EINSPRUNG DURCHGESTEUERT REGELND DURCHGESTEUERT Pfad2 EINSPRUNG DURCHGESTEUERT REGELND DRUCK_BEGRENZEN Pfad3 EINSPRUNG DURCHGESTEUERT REGELND DRUCK_BEGRENZEN DURCHGESTEUERT (2) REGELND (3) DURCHGESTEUERT REGELND Bild 5.11.: Für den Teilgraphen EM 1 berechneter Übergangsbaum. gen abgeleitet, indem der Weg von den Blattzuständen 4 zu dem Wurzelzustand beschritten wird. Daraus resultiert der Vektor von Transitionsfolgen in Gleichung (5.7), welche den abstrakten Testinhalt beschreiben. p 1,0 = {t 0 1, t 1 2, t 2 3, t 3 2 } P EM 1 = p 1,1 = {t 0 1, t 1 2, t 2 3, t 3 4, t 4 2 } p 1,2 = {t 0 1, t 1 2, t 2 3, t 3 4, t 4 3 } (5.7) Definition der Nomenklatur Der Index EM 1 der Menge von Transitionsfolgen P EM1 stellt den Bezug zu der Region des Testmodells her. Die 4 Zustände innerhalb des Übergangsbaums, welche auf keine nachfolgenden Zustände mehr verweisen. 104

105 Indizes der Transitionsfolgen p x,y beziehen sich mit dem ersten Index x auf die Region des Testmodells. Der zweite Index y ist eine Laufvariable Vervollständigung der Transitionsfolgen Die Transitionsfolgen in Gleichung (5.7) bedingen für die daraus abgeleiteten Testsequenzen das Aktivieren der Zustände in den Reihenfolgen, wie sie in den Pfaden in Bild 5.11 visualisiert sind. Dabei ist noch keine Unterscheidung getroffen worden, ob es sich um einfache Zustände (Definition 5.2), Superzustände (Definition 5.3) oder orthogonale Zustände (Definition 5.4) handelt. Die beiden zuletzt genannten Zustandsklassen beinhalten weitere Regionen und müssen für die Generierung eines vollständig ausführbaren Tests weiter aufgelöst werden. Zu diesem Zweck werden die einzelnen Transitionsfolgen p 1,i P EM1 in dem Algorithmus 5.2 elementweise darauf hin untersucht, ob sie weitere Regionen beinhalten (card(t j.target.r 0) 5 ). Algorithmus 5.2: Vervollständigung der Transitionsfolgen. Eingabe : P EM 1 Ausgabe : P EM1 1 für jedes p 1,i P EM 1 tue 2 für jedes t j p 1,i tue 3 Fall card(t j.target.r) = 0 // Einfacher Zustand - Es ist nichts weiter zu tun. 4 Fall card(t j.target.r) = 1 5 Umgang mit Superzuständen (Unterabschnitt ) 6 Fall card(t j.target.r) > 1 7 Umgang mit orthogonalen Zuständen (Unterabschnitt ) 8 9 Ende für 10 Ende für 5 Anzahl der Regionen, welche der Zielzustand einer Transition aus der Transitionsfolge enthält. 105

106 Umgang mit Superzuständen Wenn die Bedingung in Zeile 4 des Algorithmus 5.2 erfüllt ist, beinhaltet die Transitionsfolge an der entsprechenden Stelle einen Superzustand (Bsp. Druck Begrenzen in Bild 5.11). Die Auflösung erfolgt nach dem folgenden Schema: 1. Anwendung des Algorithmus 5.1 auf die zurückgegebene Region r (4,1) 6. Dabei werden die Elemente der Region folgendermaßen auf das von dem Algorithmus erwartete Testmodell EM 2 abgebildet: SM 2 = {r (4,1).s s } S 2 = {r (4,1).s s (4,0), Druck Absenken (4,1), Regeln (4,2)} T 2 = {t 4,0 4,1, t 4,1 4,2 } R 2 = W W 2 Das Ergebnis der Berechnung ist die Transitionsfolgenmenge 7 : { } P EM2 = p 2,0 = {t (4,0) (4,1), t (4,1) (4,2) } (5.8) 2. Aus der Semantik eines Superzustandes folgt, dass jede den Superzustand verlassende Transition ihren Ursprung in einem Subzustand hat (Unterabschnitt ). Um diesem Umstand Rechnung zu tragen, werden folgende Unterschritte benötigt: a) Die Menge der Subzustände innerhalb eines Superzustandes, ausschließlich der Pseudozustände s s und s e, wird identifiziert: r (4,1).S = {DRUCK ABSENKEN (4,1), REGELN (4,2) } b) Aus der übergeordneten Transitionsfolge, siehe Zeile 2 des Algorithmus 5.2, folgt ein Zielzustand des Superzustandes. Es müssen nun alle Transitionsfolgen gebildet werden, welche ihren Ursprung in der Subzustandsmenge haben und in dem Zielzustand enden. Der erste Zielzustand Durchgesteuert (2) ergibt sich aus der Transition t 4 2 in der Transitionsfolge p 1,1 der Gleichung 6 Nomenklatur: (Index des Vaterzustandes, Index der Region): Erste Region des Zustandes Druck Begrenzen (4). 7 Welche in dem betrachteten Fall nur ein Element beinhaltet. 106

107 5.7. Daraus resultiert die zu integrierende Transitionsmenge: T EM4 = {t (4,1) 2, t (4,2) 2 }. (5.9) Algorithmus 5.3: Superzustand: Hinzufügen von Transitionen. Eingabe : P EM2 Ausgabe : P EM 2 // i: Prüfen, ob es möglich ist, die Transitionen den Blattzuständen hinzuzufügen. 1 für jedes p 2,i P EM2 tue 2 t = p 2,i.get(LetztesElement) // Die letzte Transition in p 2,i ermitteln. 3 für jedes t j T EM4 tue 4 wenn t.target == t j.source dann 5 T EM4.remove(t j ) 6 p 2,i.add(t j ) 7 Ende wenn // Wenn T EM4 ==, Algorithmus beenden 8 Ende für 9 Ende für // ii: Hinzufügen neuer Transitionsfolgen minimaler Länge. 10 für jedes p 2,i P EM2 tue 11 für jedes t j T EM4 tue 12 für jedes t k p 2,i tue 13 wenn t k.target == t j.source dann 14 p = p 2,i.get(0 : k) // Kopieren der Teiltransitionsmenge p 2,i.get(0 : k) 15 T EM4.remove(t j ) 16 p.add(t j ) 17 P EM 2 = P EM2.add(p) 18 Ende wenn 19 Ende für // Wenn T EM4 ==, Algorithmus beenden 20 Ende für 21 Ende für c) Die Transitionsfolge P EM2 muss um die berechneten Transitionen T EM4 erweitert werden. Dazu wird der Algorithmus 5.3 eingesetzt, welcher aus zwei Teilen besteht: 107

108 i. Prüfen, ob die in T EM4 enthaltenen Transitionen einem Blattzustand der Transitionsfolge P EM2 hinzugefügt werden können; falls möglich, diese hinzufügen. ii. Wenn Transitionen der Menge T EM4 nicht auf diese Weise eingefügt werden können, müssen sie den bestehenden Transitionsfolgen p 2,i P EM2 hinzugefügt werden. Dazu wird das erste Auftreten einer Transition gesucht, welches die Bedingung erfüllt, dass der Zielzustand der Transition der Transitionsfolge dem Ausgangszustand der Transition der Menge T EM4 entspricht (Zeile 13 in Algorithmus 5.3). An dieser Stelle wird der zugrunde liegende Übergangsbaum verzweigt und der Menge P EM2 die entsprechende Transitionsfolge hinzugefügt. Der Algorithmus 5.3 gibt für den vorliegenden Fall die Teiltransitionsfolgenmenge P EM 2 zurück. P EM 2 = { p2,0 = {t (4,0) (4,1), t (4,1) (4,2), t (4,2) 2 } p 2,1 = {t (4,0) (4,1), t (4,1) 2 } } (5.10) Die errechnete Teiltransitionsfolgenmenge wird in die übergeordnete Transitionsfolge an der Stelle eingefügt, an der der Übergang von einem Zustand in einen Superzustand stattfindet, welcher innerhalb des Algorithmus 5.2 identifiziert wird. In der Transitionsfolge p 1,1 werden die abstrakten Transitionen t 3 4 und t 4 2 durch die Transition t 3 P EM2 ersetzt. Der Index von P EM 2 verweist darauf, dass die beinhalteten Transitionsfolgen in dem Zustand (2) enden. 3. Die Teile 2b) und 2c) (Seite 106) werden für die weiteren Transitionsfolgen der Menge P EM1 aus Gleichung 5.7 wiederholt. Im vorliegenden Fall ist nur noch die Transitionsfolge p 1,2 zu untersuchen, welche erneut den Superzustand DRUCK BEGRENZEN (4) beinhaltet, diesmal mit Zielzustand (3). Die Anwendung der Teile 2b) und 2c) ergibt dann die Teiltransitionsfolgenmenge P EM 3. P EM 3 = { p3,0 = {t (4,0) (4,1), t (4,1) (4,2), t (4,2) 3 } p 3,1 = {t (4,0) (4,1), t (4,1) 3 } 108 } (5.11)

109 Das Ergebnis der Auflösung von Superzuständen in der Menge von Transitionsfolgen P EM1 ist durch Gleichung (5.12) gegeben. p 1,0 = {t 0 1, t 1 2, t 2 3, t 3 2 } P EM1 = p 1,1 = {t 0 1, t 1 2, t 2 3, t 3 P EM2 } p 1,2 = {t 0 1, t 1 2, t 2 3, t 3 P EM3 } (5.12) Umgang mit orthogonalen Zuständen Wenn die Bedingung in Zeile 6 des Algorithmus 5.2 erfüllt ist, enthält der entsprechende Zustand orthogonale Bereiche, wie es Bild 5.12 darstellt. Die bereits errechnete Menge von Transitionsfolgen P EM 1 aus Gleichung (5.12) ist aus dem Bereich Druck Regeln des orthogonalen Zustandes Eingeschaltet bestimmt worden. Wie im Unterabschnitt aufgezeigt, EINGESCHALTET (0.3) DRUCK_REGELN EM 1 Initial1 (0) EINSPRUNG (1) DURCHGESTEUERT (2) REGELND (3) DRUCK_BEGRENZEN (4) AUTODEAKTIVIEREN EM 2 Initial2 (5) Final2 (8) AKTIV (6) INAKTIV (7) MINDESTDRUCK_GARANTIEREN EM 3 Initial3 (9) GARANTIE_AUS (10) GARANTIE_EIN (11) Bild 5.12.: Orthogonale Bereiche des Zustandes Eingeschaltet. wird durch orthogonale Bereiche parallel ausführbare Funktionalität beschrieben. In dem vorliegenden Beispiel kann somit folgende Konfiguration gelten: Während 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

110 Da die Algorithmen zur Testsequenzgenerierung eine einfache Zustandsmaschine voraussetzen, formen bekannte Ansätze [17, 19] die orthogonalen Zustände in den zugrundeliegenden Produktautomaten um und berechnen die Testspezifikation basierend auf diesem. Der Vorteil dieser Vorgehensweise liegt darin, dass durch die Umformung alle möglichen Zustandskonfigurationen bestimmt werden, die durch die Semantik verborgen sind. Der Nachteil liegt im Verlust dieser höheren Abstraktion. Um dem Ziel der vorliegenden Heuristik gerecht zu werden und die durch die Orthogonalität eingeführte Semantik bei der Testsequenzgenerierung beizubehalten, werden zunächst die Folgen der Umformung orthogonaler Bereiche in einen Produktautomaten betrachtet. EINGESCHALTET DRUCK_REGELN EM 1 AUTODEAKTIVIEREN EM 2 (6) (7) MINDESTDRUCK_GARANTIEREN EM 3... (10) (11)... a (6) (10) (6) (11) c b (7) (10) (7) (11) s(6) t 6 7 s(7) s(10) t s(11) a b c i) ii) iii) Bild 5.13.: Bedeutung orthogonaler Zustände für den Test. Dazu zeigt Bild 5.13 i) einen reduzierten Ausschnitt des Zustandes Eingeschaltet aus Bild Die möglichen 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 abgekürzt. Die Darstellung zeigt für die Konfigurationstransition b: Während sich die Zustandsmaschine in der Konfiguration {(6) (10)} befindet, führt die Stimulation der Verhaltensspezifikationen der Transitionen t 6 7 und t zum Übergang in die Konfiguration {(10) (11)}. Entscheidend für den Übergang von einer Konfiguration in die andere sind die Transitionen der einzelnen Regionen. Gemäß der Definition des Testmodells EM in Unterabschnitt sind aus den Transitionen für den Test einzelne Testschritte nach folgendem Schema ableitbar: Prüfen der Verhaltensspezifikation des Startzustandes; Stimulieren der Ver- 110

111 haltensspezifikation der Transition; Prüfen der Verhaltensspezifikation des Zielzustandes. Dieser Zusammenhang ist in Bild 5.13 iii) ersichtlich. Dabei sind die gemäß der beiden Transitionen t 6 7 und t in der Zustandsmaschine vorgegebenen Testschritte in einer Tabelle dargestellt. Die Testspezifikation eines Konfigurationsübergangs wird als Punkt-Markierung ( ) symbolisiert. Die Tabelle stellt die drei Konfigurationstransitionen a, b und c dar. Basierend auf dieser Betrachtung wird folgendes neues Vorgehen gewählt. Die Heuristik erachtet die orthogonalen Regionen als separate Zustandsmaschinen. Auf jede Region wird der Algorithmus 5.1 angewendet. Daraus resultieren für den betrachteten Zustand Eingeschaltet die Mengen von Transitionsfolgen in den Gleichungen (5.12), (5.13) und (5.14). { } p2,0 = {t 5 6, t 6 7, t 7 8 } P EM2 = P EM3 = p 2,1 = {t 5 6, t 6 7, t 7 6 } { p 3,0 = {t 9 10, t 10 11, t } } (5.13) (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 gültige Testspezifikation zu erhalten, ist die Reihenfolge der Transitionen einzuhalten, wie sie in den Mengen P abgebildet sind. Daraus resultieren für die Kombination die Regeln: Aus jeder orthogonalen Menge von Transitionsfolgen P darf nur eine Transitionsfolge p ausgewählt werden, die Reihenfolge der Transitionsfolgen innerhalb der Menge P spielt dabei keine Rolle. Die Transitionen t p müssen in der durch Algorithmus 5.1 berechneten Reihenfolge ausgeführt werden, da sonst Übergänge gefordert werden, welche die zugrundeliegende erweiterte Zustandsmaschine gar nicht ausführen kann. Die Testschritte, welche den gewählten Transitionen entsprechen, werden entweder sequenziell aneinandergereiht: 1. Ausführen der Testschritte der ersten Transition. 111

112 2. Ausführen der Testschritte der folgenden Transition. Dieses Vorgehen entspricht der neuen Sequenzierung der bestehenden Transitionsfolgen. Alternativ erfolgt die Anordnung nach dem Schema: 1. Stimulieren und Prüfen der Verhaltensspezifikationen der Ausgangszustände. 2. Stimulieren und Prüfen aller Verhaltensspezifikationen der Transitionen. 3. Stimulieren und Prüfen der Verhaltensspezifikationen der Zielzustände. Die Testspezifikation orthogonaler Regionen kann damit aus der Menge der Transitionsfolgen der separaten Regionen aufgebaut werden. Im Kontext der Heuristik wird für die Kombination der Transitionsfolgen der orthogonalen Bereiche die minimale Auswahlstrategie angewendet. Im ersten Schritt wird dabei die Menge der orthogonal auszuführenden Transitionsfolgen K EM0.3 mit Gleichung (2.12) bestimmt. In diesem Kontext stellen die orthogonalen Regionen des Zustandes Eingeschaltet die Faktoren dar. Aus der Beziehung P Eingeschaltet = P EM0.3 = {P EM1, P EM2, P EM3 } ergibt sich die Größe k = card(p EM0.3 ) = 3. Die Level entsprechen den Transitionsfolgen p P i. Die Größe n = max(n i ) hat damit ebenfalls den Wert 3, da die Menge P EM1 drei Transitionsfolgen hat. Es ergibt sich: k 0.3,0 = {{p 1,0 }, {p 2,0 }, {p 3,0 }} K EM0.3 = k 0.3,1 = {{p 1,1 }, {p 2,1 }, {p 3,0 }} k 0.3,2 = {{p 1,2 }, {p 2,0 }, {p 3,0 }} (5.15) Die Transitionen in den orthogonal auszuführenden Transitionsfolgen k müssen sequenziert werden, um eine gültige Testspezifikation zu erhalten. Die Sequenzierung erfolgt in Algorithmus

113 Algorithmus 5.4: Sequenzierung orthogonaler Transitionsfolgen. Eingabe : K EM0.3 Ausgabe : K EM0.3 1 h= 1 // Laufvariable h für den Vektor k 0.3,o 2 für o = 1: card(k EM0.3 ) tue 3 n = max(card(p) k 0.3,o ) 4 k = card(k 0.3,o ) 5 für i=1:n tue 6 für j=1:k tue 7 wenn i card(k 0.3,o {j}) dann 8 k 0.3,o (h) = k 0.3,o {j}(i) // i-te Transition t der j-ten Transitionsfolge p k 0.3,o 9 sonst // tue nichts 10 Ende wenn 11 h = h+1 12 Ende für 13 Ende für 14 Ende für Das Ergebnis des Algorithmus wird in Gleichung (5.16) dargestellt: K EM0.3 = {k 0.3,0, k 0.3,1, k 0.3,2 } T mit: k 0.3,0 = {t 0 1, t 5 6, t 9 10, t 1 2, t 6 7, t 10 11, t 2 3, t 7 8, t 11 10, t 3 2 } k 0.3,1 = { t 0 1, t 5 6, t 9 10, t 1 2, t 6 7, t 10 11, t 2 3, t 7 6, t 11 10, t 3 EM 2 } k 0.3,2 = { t 0 1, t 5 6, t 9 10, t 1 2, t 6 7, t 10 11, t 2 3, t 7 8, t 11 10, t 3 EM 3 } (5.16) Die zugrunde gelegte Auswahlstrategie entscheidet, ob die Testspezifikation der Menge derjenigen entspricht, die aus dem zugrunde liegenden Produktautomaten berechnet wird, oder ob nur eine Teilmenge davon verwendet wird. Die Testspezifikation für orthogonale Bereiche bzw. für einfache Regionen setzt sich aus den gleichen Transitionsfolgen in neuer Sequenzierung zusammen. Die gewünschte Übersichtlichkeit kann nun dadurch gewährleistet werden, dass dem Testingenieur die Mengen P in einer separaten Ansicht dargestellt werden. Genauso kann die Menge K separat dargestellt werden. 113

114 Zusammenfassung der strukturellen Aspekte Durch die Heuristik werden für die unterschiedlichen Regionen der Zustandsmaschine cdruckregler aus der Leitanwendung die Transitionsfolgen berechnet, welche in Tabelle 5.6 und Bild 5.14 zusammengefasst werden. P Init : Gleichung (5.6) P EM1 : Gleichung (5.12) P EM 2 : Gleichung (5.10) P EM 3 : Gleichung (5.11) P EM2 : Gleichung (5.13) P EM3 : Gleichung (5.14) K EM0.3 : Gleichung (5.16) Tabelle 5.6.: Zusammenfassung der strukturellen Aspekte. Initial (0.0) AUSGESCHALTET (0.1) FEHLER (0.2) EINGESCHALTET (0.3) DRUCK_REGELN EM 1 Initial1 (0) EINSPRUNG (1) DURCHGESTEUERT (2) REGELND (3) DRUCK_BEGRENZEN (4) AUTODEAKTIVIEREN EM 2 Initial2 (5) Final2 (8) AKTIV (6) INAKTIV (7) MINDESTDRUCK_GARANTIEREN EM 3 Initial3 (9) GARANTIE_AUS (10) GARANTIE_EIN (11) Bild 5.14.: Zusammenfassung der errechneten Mengen von Transitionsfolgen Synthese von Bedatung und Struktur Mit Hilfe der Heuristik ist in Unterabschnitt jeder Transition t i j T EM eine Menge von Bedatungskombinationen zugeordnet wor- 114

115 den {t i j, B}. Basierend auf der Transitionsüberdeckungsstrategie wurden Mengen von Transitionsfolgen P = i P i und K aus dem Testmodell unter Beibehaltung seiner hierarchischen und orthogonalen Struktur abgeleitet. Diese Artefakte stellen im Kontext des Frameworks die Grundlage der Testspezifikation dar und werden in das TS-MM aus Bild 3.2 überführt. Prinzipiell gilt die in Tabelle 5.7 dargestellte Zuordnungsvorschrift: 1: Mengen von Transitionsfolgen P Testspezifikation 2: Mengen von Transitionsfolgen P Testfallgruppe 2: Orthogonale Transitionsfolgen K Kombinationsgruppe 3: Transitionsfolge p Testfall 4: Transition t i j Testsequenz 5: Stimulieren und Prüfen von V S und V T Testschritt 6: Bedatung einer Transition B B Testdatensatz 7: Eine Bedatungskombination b B Bedatungskombination Tabelle 5.7.: Zuordnung von Struktur und Bedatung zu dem TS-MM. Zunächst wird mit der Zuordnung der Transitionen t i j T in das TS-MM begonnen. Dazu wird in der Testbibliothek ein Ordner-Element angelegt, welches die Testsequenzen aufnehmen kann. Für jede Transition wird eine Testsequenz und für deren Verhaltensspezifikation V T ein Testschritt angelegt. Für jeden Zustand und dessen Verhaltensspezifikation V S wird geprüft, ob dieser schon im TS-MM vorhanden ist. Wenn für den Zustand noch kein Testschritt-Element existiert, wird aus der Testsequenz ein neues Element über die Aggregationsbeziehung angelegt. Wenn für den Zustand schon ein Testschritt-Element existiert, wird die Referenzbeziehung aus der Testsequenz gesetzt. Zu jedem erstellten Testschritt werden die Elemente Testdatum, WerteBereich und Repräsentant anglegt. Das Attribut Wert des Elements Repräsentant wird dabei zunächst zufällig initialisiert, unter Berücksichtigung des übergeordneten Attributs Bereich des Elements WerteBereich. Die der Transition zugeordnete Menge B wird folgendermaßen abgebildet: Zu jeder Testsequenz wird ein Testdatensatz-Element angelegt, dessen zugeordnete Bedatungskombinations-Elemente den Bedatungskombinationen 115

116 b B entsprechen. Dazu werden die Referenzbeziehungen auf die Elemente Testdatum und WerteBereich verwendet. Als nächstes werden die Mengen von Transitionsfolgen in das Element Testspezifikation überführt. Die dafür vorgesehenen Elemente Testfallgruppe, Kombinationsgruppe und Testfall sind über Aggregationsbeziehungen verbunden, damit sie die hierarchische Struktur des Testmodells EM widerspiegeln können. Zunächst wird eine Testfallgruppe für die Menge P Init angelegt, welche ein Testfall-Element für die Transitionsfolge p Init enthält. Der Testfall enthält die beiden Testsequenzaufruf -Elemente, welche den Transitionen der Transitionsfolge p Init entsprechen. Ferner enthält er die Testfallgruppe P EM 0.3, welche den komplexen Zustand Eingeschaltet (0.3) repräsentiert. Die Testfallgruppe enthält, analog zu dem Zustand Eingeschaltet (0.3) drei parallele Testfallgruppen, welche die Mengen von Transitionsfolgen P EM 1 bis P EM 3 aufnehmen. Auf der gleichen Ebene der Testfallgruppe P EM 0.3 wird die Kombinationsgruppe K EM0.3 angelegt, welche die Transitionsfolgen aus Gleichung (5.16) beinhaltet. Genauso wie die aus den orthogonalen Regionen resultierenden Transitionsfolgen auf gleicher Ebene im TS-MM abgebildet werden, ist es auch möglich, die aus dem hierarchischen Zustand Druck Begrenzen (4) resultierenden Transitionsfolgen unterzuordnen. Dies erfolgt beispielsweise bei der Abbildung der Transitionsfolge p 1,1 P EM 1 aus 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 kann 8. Um aus dieser Wiederholung einen Nutzen zu ziehen, wird bei der Erstellung der Testsequenzaufruf -Elemente darauf geachtet, dass die zugeordnete Bedatungskombination b variiert wird. Dafür wird der Algorithmus 5.5 eingesetzt. Für die notwendige Zuordnung {t i j, b B} Testsequenzaufruf.Bedatung 8 Es ist denkbar, hier Meta-Strategien einzusetzen, um nicht immer bei dem Initialzustand anfangen zu müssen. 116

117 werden dabei bei jedem Aufruf zunächst die Bedatungskombinationen der Menge B min verwendet. Nach jeder Zuordnung wird das Element b der Menge entnommen. Wenn die Menge B min leer ist, werden in gleicher Weise die Bedatungskombinationen der Menge B zugeordnet. Sind beide Mengen leer, wird auf das erste Element der Menge B max verwiesen. Algorithmus 5.5: Bedatung von Testsequenzen. 1 wenn t i j.b min dann 2 Testsequenzaufruf.Bedatung = t i j.b min.first() // Dem Element Bedatung das erste Element B min.first() zuordnen. 3 t i j.b min = t i j.b min \ t i j.b min.first() // Die Menge B min um das erste Element reduzieren. 4 sonst wenn t i j.b dann 5 Testsequenzaufruf.Bedatung = t i j.b.first() 6 t i j.b = t i j.b \ t i j B.first() // Die Menge B um das erste Element reduzieren. 7 sonst // (t i j.b min t i j.b ) = 8 Testsequenzaufruf.Bedatung = t i j.b max.first() 9 Durch die Bestimmung des Bedatungskoeffizienten Q b Q b = card(b min B ) card(b max ) (5.17) wird dabei für jede Transition respektive Testsequenz bestimmt, wie viel Prozent der maximal möglichen Bedatungskombinationen in der Testspezifikation verwendet werden. Für die Kombinationsgruppe erfolgt die analoge Zuordnung zu Testsequenzaufrufen. In Bild 5.15 ist die im Vorhergehenden beschriebene Abbildung der Resultate der Heuristik in das TS-MM dargestellt. Die hierarchischen und orthogonalen Beziehungen sind in der Baumstruktur des TS-MM dargestellt. 117

118 Bild 5.15.: Auszug des resultierenden TS-MM. 118

119 5.4. Überführen der Testspezifikation in ausführbaren Code Im Rahmen des Testframeworks besteht der nächste Schritt darin, die formale Testspezifikation in ausführbaren Code zu transformieren. Als Ausführungsplattform 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 implementiert, welche von der Klasse ctest des Unit-Test-Frameworks erbt, siehe Bild Bild 5.16.: Design des Unit-Tests für die Klasse cdruckregler mit der Testimplementierung cdruckregler Test. Die Elemente der Testspezifikation werden durch folgende Abbildungsregeln in Code überführt; die Aufzählung erfolgt ausgehend von dem untersten Element in der Hierarchie, dem Testschritt. Testschritt Für jede Überprüfung, ob das System in einem definierten Ausgangs-Zustand ist, wird ein separates Testschritt-Element angelegt. Analog werden für die Stimulation und Überprüfung der Verhaltensspezifikation der Transition und die Überprüfung des Ziel- Zustandes separate Testschritt-Elemente angelegt. Innerhalb der Zustandsprüfungen sind auch die jeweiligen Verhaltensspezifikationen des Zustandes zu prüfen. Die Zustandsprüfung wird durch die Methode teststate() implementiert, deren Grundprinzip in Listing 5.1 dargestellt ist. Die Umsetzung ist so angelegt, dass eine Abstraktion der Implementierung von dem Testmodell möglich ist. Dies kann anhand des orthogonalen Zustandes Eingeschaltet veranschaulicht 119

120 werden. Der Code der Klasse cdruckregler weist keinen explizit abfragbaren Zustand mit dem Namen Eingeschaltet auf. Dass sich die Implementierung in diesem Zustand befindet, kann jedoch durch die Abfrage überprüft werden, ob der Druckregler und der zugeordnete 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 f a l s e ; 9 } 10 } 11 / PROTECTED REGION END / } Listing 5.1: Auszug aus der Implementierung der Methode teststate(). Testsequenz Die Testsequenz implementiert die einer Transitionsfolge entsprechenden Testschritte in einer bedatbaren Methode. Die Argumentenliste der Methode entspricht den Faktoren der Transitionsfolge. Listing 5.2 zeigt die Implementierung des Tests für den Zustandsübergang von dem Zustand Ausgeschaltet nach Eingeschaltet. Für die Überprüfung der Zustände wird die beschriebene Methode teststate() eingesetzt. 1 void cdruckregler Test : : SEQ cdruckregler Ausgeschaltet Eingeschaltet 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 ( A u s g e schaltet ) ) ; 5 i f (! ( this >t e s t S t a t e ( A u s g e schaltet ) ) ) { 6 throw std : : r u n t i m e e r r o r ( this >t e s t S t a t e ( \ A usgeschaltet \ ) f a i l e d ) ; } 7 8 DR >E i n s c h a l t e n ( 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 : : r u n t i m e e r r o r ( this >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

121 Testfall Das Element Testfall implementiert die Ausführung einer Transitionsfolge. Dazu werden die Testsequenzaufruf -Elemente des TS- MM in einen Methodenaufruf transformiert. Das Listing 5.3 zeigt das Ergebnis der Transformation für das Testsequenzaufruf -Element von der Transitionsfolge t Eingeschaltet Ausgeschaltet. Der Methodenaufruf SEQ_cDruckRegler_Ausgeschaltet_Eingeschaltet(...) erfolgt mit der in Bild 5.7 dargestellten Bedatungskombination b 1. 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 cdruckregler Ausgeschaltet Eingeschaltet 6 ( int (2500) / p S t e u e r S o l l [ 0, ] /, 7 int (2000) / p R e g e l S o l l [ 0, ] / ) ; } Listing 5.3: Implementierung des Elements Testfall. Testfallgruppe Das Element Testfallgruppe wird durch eine Methode implementiert, welche die zugeordneten Testfall-Elemente sequenziell aufruft. Um zu gewährleisten, dass die Zustandsmaschine vor jedem Testfallaufruf wieder in dem Initial-Zustand ist, wird die Methode reset() generiert, welche die Instanz der zu testenden Klasse cdruckregler aus dem Speicher löscht und neu anlegt. Kombinationsgruppe Das Element Kombinationsgruppe wird analog zu dem Element Testfallgruppe angelegt. Testspezifikation Das Element Testspezifikation wird in der Implementierung der zentralen run()-methode des Unit-Test Frameworks realisiert. Alle aggregierten Testfallgruppen werden dadurch sequenziell aufgerufen Anwendung Im Folgenden soll die generierte Testspezifikation bewertet werden. Dazu wird der erzeugte Testcode gegen die Implementierung der in Kapitel 4 beschriebenen Leitanwendung ausgeführt. Parallel wird die durch das 121

122 Framework mögliche Vorgehensweise der Testcodeerstellung mit der konventionellen Herangehensweise verglichen. Um den Code ausführen zu können, sind zunächst 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-Objekte 9 bereitstellt, damit das SUT überhaupt lauffähig ist. Zur Erleichterung dieser zeitaufwendigen Arbeitsschritte ist der Codegenerator so erweitert worden, dass er einen Großteil der notwendigen Test-Infrastruktur generieren kann. Zum einen wird das benötigte Visual- Studio-Projekt (*.vcproj) generiert. Die Generierung ist möglich, da es sich um eine XML-Datei handelt. Sie muss die Verweise auf die zu inkludierenden Quellcode-Dateien, Bibliotheksverweise (*.lib) und Präprozessor- Anweisungen enthalten. Die für die Generierung notwendigen Informationen werden dabei folgendermaßen gewonnen: Der Ablageort der Quellcode- Dateien ist standardisiert und der Dateiname der benötigten Quellcode- Dateien kann durch eine Nomenklatur-Festlegung aus dem Design abgeleitet werden. Für die Leitanwendung bedeutet dies: Aus dem Klassennamen cdruckregler im Design kann geschlossen werden, dass die Implementierung in den Dateien druckregler.cpp/hpp abgelegt wird. Zum anderen werden die Code-Rahmen der Stub-Objekte generiert. Dazu werden die aus dem UML-Klassendiagramm bekannten und im Exchange-Meta-Modell gespeicherten Informationen über die Klassenbeziehungen und Operationen herangezogen. Zusätzlich enthält der aus der Testspezifikation generierte Quellcode neben 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 für den Test steht deutlich schneller bereit. Während die konventionelle Erstellung der Tests und der Test-Infrastruktur Tage und Wochen in Anspruch nimmt, ist dies mit dem Testframework in Stunden machbar. 9 Ein Stub-Objekt ersetzt die Funktionalität eines Objektes für den Test. Dabei wird die Funktionalität auf das Minimum reduziert. 122

123 Ein weiterer Vorteil ist in der klaren Struktur des Testcodes zu sehen. In der manuellen Implementierung, welche über einen längeren Zeitraum entstanden ist, sind unterschiedliche Umsetzungen, Strukturierungen und Bezeichnungen zu finden. Der generierte Code hingegen enthält die Inhalte der in Bild 5.15 dargestellten Testspezifikation in genau der Struktur, wie sie durch die Transformationsvorschriften aus Abschnitt 5.4 vorgegeben sind. Während der eigentlichen Erstellung der Testspezifikation aus dem Design hat sich die sukzessive Vorgehensmöglichkeit der Heuristik als sehr hilfreich erwiesen. Durch die Platzierung des Stereotyps «SMUT» ist zunächst für den Zustand Eingeschaltet eine Testspezifikation erstellt und in Testcode überführt worden. Nachdem die Stub-Objekte implementiert waren und die Test-Infrastruktur lauffähig war, wurde die Testspezifikation durch die Umplatzierung des Stereotyps sukzessive erweitert. Da das SUT manuell aus dem Design abgeleitet wurde, war die Implementierung häufig komplexer oder anders, als es das Design vorgab. Nach der Plausibilisierung der korrekten Funktionalität des SUT musste also entweder das Design oder der Testcode angepasst werden. Als hilfreich und notwendig hat sich dafür das Konzept der Protected Regions erwiesen, welches eine manuelle Ergänzung des generierten Codes ermöglicht. Der inhaltliche Vergleich der generierten Testspezifikation mit der manuellen Testspezifikation ergab, dass das zustandsbasierte Verhalten des SUT mit der generierten Testspezifikation vollständig getestet werden kann. Aus dem Vergleich der erreichten Zweigüberdeckung (C1), vgl. Unterabschnitt , der Klasse cdruckregler bei der Stimulation mit den beiden Testspezifikationen ergibt sich, dass die generierte Testspezifikation 50% C1-Abdeckung erzielt. Die manuell erstellte Testspezifikation erzielt 70% C1-Abdeckung. Der Unterschied ist damit zu erklären, dass die Implementierung des SUT über zusätzliches, nicht zustandsbasiertes Verhalten verfügt. Dabei handelt es sich um triviale Setter- und Getter-Methoden oder um domänenspezifische Besonderheiten, wie sie durch die Kennlinien- Abhängigkeit aus Bild 4.2 beschrieben sind. 123

124 6. Einsatz des Testframeworks Das vorliegende Kapitel zeigt die im Rahmen der Arbeit entstandenen Ausprägungen des in Kapitel 3 konzipierten Testframeworks auf. Die Erläuterungen erfolgen anhand der in Bild 6.1 dargestellten grafischen Benutzeroberfläche des Testframeworks. Die Implementierung realisiert dabei verschiedene Ausprägungen der in dem Testframework vorgesehenen Schichten, vgl. Bild 3.1. In Abschnitt 6.1 werden die parallel zu der Heuristik integrierten Testentwurfsmethoden und deren Initialisierung mit Informationen 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.: Benutzeroberfläche des Testframeworks. 124

125 6.1. Methoden und deren Einbindung Die in Kapitel 5 beschriebene Heuristik ist in die grafische Benutzeroberfläche aus Bild 6.1 folgendermaßen integriert: Der Knopf Load Statemachine transformiert die UML-Zustandsmaschine, welche das Verhalten der Leitanwendung beschreibt, in eine Instanz des Exchange-Meta-Modells, wie es in Unterabschnitt beschrieben ist. Der Knopf Statebased Test führt die Berechnungen der Heuristik aus und erzeugt mit dem Ergebnis eine Instanz des Testspezifikations-Meta-Modells, wie es in Abschnitt 5.3 erläutert wird. Mit dem Knopf Edit Testspezifikation wird ein Editor für die Testspezifikation geöffnet, wie er in Bild 5.15 dargestellt ist. Schließlich kann durch den Knopf Generate C++ Code die in Unterabschnitt beschriebene Transformation in den C++ Testcode durchgeführt werden. Der Grundgedanke des Testframeworks ist es, verschiedene Testentwurfsmethoden einbinden zu können. Diese Möglichkeit ist notwendig, da eine zu testende Implementierung mehr als nur zustandsbasiertes Verhalten aufweisen 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 Kennlinienzugriffe, lassen sich unter Zuhilfenahme der Klassifikationsbaummethode testen. Zu diesem Zweck wurde der Klassifikationsbaumeditor CTE-XL [24] in das Framework integriert. Dies ist technologisch möglich, da der CTE-XL mit XML-Dateien arbeitet. Darin sind der Klassifikationsbaum und das Ergebnis der Testauswahlstrategien formal gespeichert. Für die Einbindung des CTE-XL in das Testframework wurde in das UML- Design ein weiterer Stereotyp mit Namen «FUT» (Function Under Test) eingeführt, um gezielt Methoden für den Test kennzeichnen zu können. Für 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 zunächst nötig 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 möglich, Dateien zu erzeugen, welche der CTE-XL weiterverarbeiten kann. Die Informationen aus dem Exchange-Meta-Modell, welche 125

126 Methode getestet werden soll und welche Parameter und Wertebereiche diese aufweist, werden in der M2M-Transformation in das CTE-MM transformiert. 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 geöffnet. Der Benutzer kann nun die erzeugte *.cte- Datei öffnen und Bedatungskombinationen erzeugen, wie es Bild 6.2 zeigt. Dazu stehen die in Unterabschnitt beschriebenen Auswahlstrategien zur Verfügung. Durch das Speichern der Datei in dem CTE-XL wird die zugrundeliegende *.cte-datei um die gewählten Bedatungskombinationen erweitert. Die daraus folgende *.cte-datei wird durch das Testframework Bild 6.2.: Beispiel für das Einbinden des CTE-XL in das Testframework. weiterverarbeitet. Dazu wird die *.cte-datei wieder in das CTE-MM eingelesen, um eine M2M-Transformation in das Testspezifikations-MM zu ermöglichen. Der auf diese Weise für eine Methode spezifizierte Test wird auf ein Testsequenz-Element abgebildet. Die ursprünglich im CTE-XL gewählten Bedatungskombinationen werden nun in das Testdatensatz-Element und dessen untergeordnete Bedatungskombinations-Elemente überführt. Das beschriebene Vorgehen ermöglicht es, die mit der Heuristik erstellte Testspezifikation für die Leitanwendung zu erweitern. Daraus wird das Potenzial des Testframeworks ersichtlich, Testentwurfsmethoden einzubinden, die schon als Software-Werkzeug zur Verfügung stehen. Alternativ ist es auch möglich, die im Kontext der Heuristik eingesetzten Auswahlstrate- 126

Test modellbasiert entwickelter Steuergeräte

Test modellbasiert entwickelter Steuergeräte Seite 1 von 31 26. Treffen der GI-Arbeitsgruppe Test, Analyse und Verifikation von Software Stuttgart, den 06.12.2007 Systematischer Test modellbasiert entwickelter Steuergeräte Dipl.-Ing. Matthias Wiese

Mehr

Absicherung von Automotive Software Funktionen

Absicherung von Automotive Software Funktionen GI Themenabend "Automotive" Absicherung von Automotive Software Funktionen 27.02.2013 Jürgen Schüling Überblick Berner & Mattner Gründung: 1979 Mitarbeiter: 400 Umsatz 2011: Standorte: Angebot: Branchen:

Mehr

Model Driven Architecture

Model Driven Architecture { AKTUELLES SCHLAGWORT* / MODEL DRIVEN ARCHITECTURE Model Driven Architecture Martin Kempa Zoltán Ádám Mann Bei der Model Driven Architecture (MDA) bilden Modelle die zentralen Elemente des Softwareentwicklungsprozesses.

Mehr

Ihr Vorteil durch effizientes Testen

Ihr Vorteil durch effizientes Testen EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM XAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM M EXAM EXAM EXAM EXAM EXAM EXAM EXAM

Mehr

Systematisches Testen von Software

Systematisches Testen von Software Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Model Driven Architecture Praxisbeispiel

Model Driven Architecture Praxisbeispiel 1 EJOSA OpenUSS CampusSource Model Driven Architecture Praxisbeispiel 2 Situation von CampusSource-Plattformen Ähnliche Funktionen (Verwaltung von Studenten und Dozenten, Diskussionsforen,...), jedoch

Mehr

Michael Piechotta - CASE Tools. openarchitecture Ware

Michael Piechotta - CASE Tools. openarchitecture Ware Model Driven Development Michael Piechotta - CASE Tools openarchitecture Ware Gliederung 1.Einleitung - Was ist MDD? - Wozu MDD? 2.Model Driven Development - OMG Konzepte: Modelle,Transformationen Meta-Modellierung

Mehr

Modellgetriebene Softwareentwicklung

Modellgetriebene Softwareentwicklung Modellgetriebene Softwareentwicklung 30.10.2008 Dr. Georg Pietrek, itemis AG Inhalt Wer ist itemis? Modellgetriebene Entwicklung Ein Praxis-Beispiel Fazit 2 Vorstellung IT-Dienstleister Software-Entwicklung

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Beispielhaft MDSD in der Praxis. Dr. Shota Okujava shota.okujava@isento.de www.isento.de

Beispielhaft MDSD in der Praxis. Dr. Shota Okujava shota.okujava@isento.de www.isento.de Beispielhaft MDSD in der Praxis Dr. Shota Okujava shota.okujava@isento.de www.isento.de Agenda Einführung Softwareentwicklungsprozess und MDSD Technologien und Werkzeuge Demo Entwicklung der Metamodelle

Mehr

Durchgängiger Software- und Systemtest einer hochdynamischen Antriebsregelung

Durchgängiger Software- und Systemtest einer hochdynamischen Antriebsregelung Durchgängiger Software- und Systemtest einer hochdynamischen Antriebsregelung mit Hilfe des Testwerkzeuges Time Partition Testing (TPT) Norbert Büttner PikeTec GmbH Übersicht Integration von TPT in den

Mehr

Ein Testprozess für Modellbasiertes Testen

Ein Testprozess für Modellbasiertes Testen Ein Testprozess für Modellbasiertes Testen Seminar: Software-Qualitätssicherung Tobias Eckardt 8. Juli 2008 Testen von Softwaresystemen Fehler in einer adaptiven Geschwindigkeitsregelung (engl. adaptive

Mehr

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

Mehr

PLATTFORMÜBERGREIFENDE ENTWICKLUNG MITHILFE MODELLGETRIEBENER METHODEN UND TECHNOLOGIEN

PLATTFORMÜBERGREIFENDE ENTWICKLUNG MITHILFE MODELLGETRIEBENER METHODEN UND TECHNOLOGIEN PLATTFORMÜBERGREIFENDE ENTWICKLUNG MITHILFE MODELLGETRIEBENER METHODEN UND TECHNOLOGIEN Mathias Slawik, WI (M), 3. FS Aktuelle Themen der Wirtschaftsinformatik, HTW Berlin, WS 10/11 Gliederung 2 Methode

Mehr

Stellenangebote. Multi-Talent, Alleskönner, Teamworker? Entwicklungsingenieur (m/w) Infotainment

Stellenangebote. Multi-Talent, Alleskönner, Teamworker? Entwicklungsingenieur (m/w) Infotainment Entwicklungsingenieur (m/w) Infotainment In Ihrer Funktion als Entwicklungsingenieur im Infotainment-Bereich sind Sie für die Systemintegration dieser Funktionen oder Komponenten ins Fahrzeug verantwortlich.

Mehr

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Die Unified Modeling Language Die UML (hier in der Version 0.9) ist ein Satz von Notationen zur Beschreibung objektorientierter Softwaresysteme.

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Praktikum Software Engineering: Verfahren und Werkzeuge

Praktikum Software Engineering: Verfahren und Werkzeuge Praktikum Software Engineering: Verfahren und Werkzeuge Lehrstuhl für Software Engineering (Informatik 11) Verfahren und Werkzeuge Seite 1 Software Engineering Absichten, Aufgaben Systemnutzung Anforderungsspezifikation

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Skript zum Labor Maschinenkonstruktion. Konzipieren mechatronischer Produkte: Modellbasierte Programmierung eines Mikroroboters

Skript zum Labor Maschinenkonstruktion. Konzipieren mechatronischer Produkte: Modellbasierte Programmierung eines Mikroroboters Skript zum Labor Maschinenkonstruktion Konzipieren mechatronischer Produkte: Modellbasierte Programmierung eines Mikroroboters Sommersemester 2012 1. Einführung 1.1. Modellbasierte Entwicklung mechatronischer

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Testmanagement im agilen Entwicklungsprozess

Testmanagement im agilen Entwicklungsprozess Testmanagement im agilen Entwicklungsprozess Unser Beratungsangebot für die effiziente Abwicklung von Projekten: n Anforderungen erkennen n Software-Qualität steigern n Teams zum Erfolg führen Unser Erfolgskonzept:

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Andreas Lux 16.03.2010 Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Warum unterschiedliche Sprachen? Nicht alle Probleme eignen sich, um mit Standardsprachen beschrieben

Mehr

Vorstellung Diplomarbeit

Vorstellung Diplomarbeit Vorstellung Diplomarbeit Entwurf und Implementierung eines BUS-Moduls für das Automatisierungswerkzeug ECU-TEST engineering software test Gliederung Einleitung Überblick Testautomatisierung Kurzvorstellung

Mehr

Test & Diagnose. Thomas Romanek. thomas.romanek@udo.edu. PG AutoLab Seminarwochenende 21.-23. Oktober 2007. AutoLab

Test & Diagnose. Thomas Romanek. thomas.romanek@udo.edu. PG AutoLab Seminarwochenende 21.-23. Oktober 2007. AutoLab Test & Diagnose Thomas Romanek thomas.romanek@udo.edu PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Einführung Tests zur Qualitätssicherung V-Modell Spezielle Verfahren in Automotive Das Diagnosesystem

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

MDA MDA mit mit Open-Source-Software Eine Eine Bestandsaufnahme

MDA MDA mit mit Open-Source-Software Eine Eine Bestandsaufnahme MDA MDA mit mit Open-Source-Software Eine Eine Bestandsaufnahme Gerhard Wanner (wanner@hft-stuttgart.de) Stefan Stefan Siegl Siegl (s.siegl@novatec-gmbh.de) Agenda Model Driven Architecture (MDA) Einführung/Übersicht/Motivation

Mehr

Key Note und Abstracts Stream 4

Key Note und Abstracts Stream 4 Key Note und Abstracts Stream 4 Key-Note: Future of Google Search Referent: Emmanuel Mogenet, Engineering Director, Google Zurich Agile Embedded Projekte mit Scrum & Kanban Tips & Tricks aus der Praxis

Mehr

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java Willkommen zur Vorlesung Objektorientierte Programmierung Vertiefung - Java Zum Dozenten Mein Name: Andreas Berndt Diplom-Informatiker (TU Darmstadt) Derzeit Software-Entwickler für Web- Applikationen

Mehr

Testmanagement bei SAP-Projekten

Testmanagement bei SAP-Projekten Testmanagement bei SAP-Projekten Erfolgreich Planen Steuern Reporten bei der Einführung von SAP-Banking von Alberto Vivenzio, Domenico Vivenzio 1. Auflage Springer Vieweg Wiesbaden 2012 Verlag C.H. Beck

Mehr

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering,

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Manfred Broy Lehrstuhl für Software & Systems Engineering Technische Universität München Institut für Informatik ISO 26262 Functional

Mehr

Comparing Software Factories and Software Product Lines

Comparing Software Factories and Software Product Lines Comparing Software Factories and Software Product Lines Martin Kleine kleine.martin@gmx.de Betreuer: Andreas Wuebbeke Agenda Motivation Zentrale Konzepte Software Produktlinien Software Factories Vergleich

Mehr

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

Mehr

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Jan Düttmann Archimedon Software + Consulting GmbH & Co. KG Marienstraße 66 32427 Minden Stephan Kleuker Hochschule

Mehr

dspace (1/3) dspace: Gegründet 1988 in Paderborn Mitarbeiter: Über 650 Mitarbeiter weltweit, davon über 70 % Ingenieure Ständiges Mitarbeiterwachstum

dspace (1/3) dspace: Gegründet 1988 in Paderborn Mitarbeiter: Über 650 Mitarbeiter weltweit, davon über 70 % Ingenieure Ständiges Mitarbeiterwachstum Agenda dspace und das V-Modell für Steuergeräte- Entwicklung Wie funktioniert Rapid Control Prototyping TargetLink: Vom Model zum Code Ein Wort zu HIL Praxisbeispiele dspace (1/3) dspace: Gegründet 1988

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Insert picture and click Align Title Graphic. Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Dr. Dieter Lederer, Geschäftsführer Vector Consulting Services GmbH

Mehr

Customer-specific software for autonomous driving and driver assistance (ADAS)

Customer-specific software for autonomous driving and driver assistance (ADAS) This press release is approved for publication. Press Release Chemnitz, February 6 th, 2014 Customer-specific software for autonomous driving and driver assistance (ADAS) With the new product line Baselabs

Mehr

Model Driven Development einige wichtige Grundprinzipien

Model Driven Development einige wichtige Grundprinzipien Model Driven Development einige wichtige Grundprinzipien Johannes Scheier j@scheier software.ch Copyright by Scheier Software Engineering Seite 1 Inhalt Was ist Model Driven Development (MDD)? Was verspricht

Mehr

Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle

Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle Doktoranden-, Diplomandenseminar, Institut für Informatik, TU Clausthal 23. Juni 2009 Motivation: Modelle werden in der

Mehr

Testmanagement in IT-Projekten

Testmanagement in IT-Projekten Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:

Mehr

1. Motivation 2. Begriffsklärung 3. Komponententests 4. Integrationstests 5. Integrationsstrategien 6. Zusammenfassung

1. Motivation 2. Begriffsklärung 3. Komponententests 4. Integrationstests 5. Integrationsstrategien 6. Zusammenfassung Übersicht s s Gregoire Kemgne 1 Motivation Problem: Software wird immer größer und komplexer, dadurch ist diese immer schwerer zu überschauen Ein Projekt benötigt mehr Zeit und/oder Entwickler. Lösung:

Mehr

Systematische Testfallableitung und Tests durchführen

Systematische Testfallableitung und Tests durchführen Systematische Testfallableitung und Tests durchführen Testen Bereich Kontrolle Aktivität Interne Qualitätssicherung durchführen (Verifikation) Ziele Tests werden systematisch und zielgerichtet erstellt

Mehr

Übungsaufgaben zum Software Engineering: Management

Übungsaufgaben zum Software Engineering: Management Übungsaufgaben zum Software Engineering: Management Grundbegriffe: Aufgabe 1: Aus welchen Disziplinen setzt sich das Software Engineering zusammen? a. Informatik b. Physik c. Psychologie d. Chemie e. Geologie

Mehr

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System?

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System? Der Entwicklungsprozess Oder wie entwickle ich ein eingebettetes System? Einleitung Problemstellung erläutern, Eine Entwicklungsprozess ist ein Prozess, der beschreibt, wie man eine Entwicklung anzugehen

Mehr

Traceability-Modell als Erfolgsfaktor für Process Enactment. Paul-Roux Wentzel, SEE 2008

Traceability-Modell als Erfolgsfaktor für Process Enactment. Paul-Roux Wentzel, SEE 2008 Traceability-Modell als Erfolgsfaktor für Process Enactment Einführung Referent Paul-Roux Wentzel Unternehmen method park Software AG 2008 method park Software AG Slide 2 Leistungsportfolio Training &

Mehr

Einführung Arten von Softwaretests Prinzipien Continuous Integration Tests in FLOSS-Projekten Quellen. Softwaretests. Christoph Betschart

Einführung Arten von Softwaretests Prinzipien Continuous Integration Tests in FLOSS-Projekten Quellen. Softwaretests. Christoph Betschart Softwaretests Christoph Betschart 27. Oktober 2014 Inhaltsverzeichnis Einführung Arten von Softwaretests Prinzipien Seven Principles of Software Testing Continuous Integration Tests in FLOSS-Projekten

Mehr

Testautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649

Testautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649 Testautomatisierung Lessons Learned qme Software GmbH Gustav-Meyer-Allee 25 13355 Berlin Telefon 030/46307-230 Telefax 030/46307-649 E-Mail qme Software info@qme-software.de GmbH Testautomatisierung Lessons

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung Software-Qualität im Rahmen modellgetriebener Softwareentwicklung OFFIS Technologiecluster Enterprise Application Integration niels.streekmann@offis.de 09.07.2008 Seite 1 / 13 Software-Qualität: Unterschiedliche

Mehr

.mzt@bpmn: modellbasiertes Testen für die Enterprise-IT. OOP 2011 Florian Prester

.mzt@bpmn: modellbasiertes Testen für die Enterprise-IT. OOP 2011 Florian Prester .mzt@bpmn: modellbasiertes Testen für die Enterprise-IT OOP 2011 Florian Prester Agenda Einführung BPMN/ Innovator MBT/.mzT/.getmore TFS.mzT@BPMN Vergleichsstudie Zusammenfassung 2 sepp.med gmbh IT Service

Mehr

Leitfaden API. Testing und Debugging. Erstellt am 4.9.2014 Autor FG API, Rinaldo Lanza. Dokumentenstatus Freigegeben at work Version 1.

Leitfaden API. Testing und Debugging. Erstellt am 4.9.2014 Autor FG API, Rinaldo Lanza. Dokumentenstatus Freigegeben at work Version 1. Leitfaden API Erstellt am 4.9.2014 Autor FG API, Rinaldo Lanza Dokumentenstatus Freigegeben at work Version 1.0 Verteiler Fachgruppe API Änderungen Datum Version Autor Inhaltsverzeichnis 1 Beschreibung

Mehr

UML 2.0 Quelltextgenerierung

UML 2.0 Quelltextgenerierung UML 2.0 Quelltextgenerierung Seminararbeit im Fach Informatik im Rahmen des Seminars Sicherheitskritische Systeme an der Universität Siegen, Fachgruppe für Praktische Informatik eingereicht bei Dr. Jörg

Mehr

Modellgetriebene Softwareentwicklung bei der IBYKUS AG

Modellgetriebene Softwareentwicklung bei der IBYKUS AG Modellgetriebene Softwareentwicklung bei der IBYKUS AG Theorie Teil 4: Domänenspezifische Sprachen Dr. Steffen Skatulla IBYKUS AG 1 Inhalt Teil 4: Domänenspezifische Sprachen Nutzung vorhandener Sprachen

Mehr

Basiswissen Softwaretest

Basiswissen Softwaretest Andreas Spillner Tilo Linz Basiswissen Softwaretest Aus- und Weiterbildung zum Certified Tester Foundation Level nach ISTQB-Standard 3., überarbeitete und aktualisierte Auflage I Technische l'^vrau«! D~w.-iE*arit

Mehr

Architektur in der Mechatronik. existierender Testwerkzeuge

Architektur in der Mechatronik. existierender Testwerkzeuge Universelle Testsystem Architektur in der Mechatronik Ansatz zur Systematisierung Ansatz zur Systematisierung existierender Testwerkzeuge Gliederung Umfeld und Problemstellung Testsystem Architektur Funktionale

Mehr

Software Engineering II (IB) Testen von Software / Modultests

Software Engineering II (IB) Testen von Software / Modultests Testen von Software / Modultests Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Programm-Tests Tests sollen zeigen, dass ein Programm das tut was es tun soll sowie

Mehr

Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten

Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten

Mehr

www.triton.at White Paper Testfallgewinnung mit dem Portfolio-Manager Gewinnung effizienter Testfälle und -daten

www.triton.at White Paper Testfallgewinnung mit dem Portfolio-Manager Gewinnung effizienter Testfälle und -daten www.triton.at White Paper Testfallgewinnung mit dem Portfolio-Manager Gewinnung effizienter Testfälle und -daten Inhaltsverzeichnis Testfall-Gewinnung bei Triton... 3 Ebenen der Testfall-Definition...

Mehr

Automotive Software Engineering

Automotive Software Engineering Jorg Schauffele Thomas Zurawka Automotive Software Engineering Grundlagen, Prozesse, Methoden und Werkzeuge Mit 278 Abbildungen ATZ-MTZ-Fachbuch vieweg Inhaltsverzeichnis 1 Einfiihrung und Uberblick 1

Mehr

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1 Test Dipl. Wirtsch. Ing. Alexander Werth 9-1 Phasen der Problemdefinition Anforderungsanalyse Spezifikation Entwurf Implementation Erprobung Wartung Methoden der 9-2 Software Test / Erprobung Messen der

Mehr

Massive Automatisierung von Software-Tests. In einem agilen Automotive Projekt

Massive Automatisierung von Software-Tests. In einem agilen Automotive Projekt Massive Automatisierung von Software-Tests In einem agilen Automotive Projekt Inhalt Die Projektziele Die Projektstruktur und die Rahmenbedingungen Automotive SPICE und Scrum Die Automatisierung der SW-Testfälle

Mehr

6 Systematisches Testen von Programmen

6 Systematisches Testen von Programmen 6 Systematisches Testen von Programmen Testen Untersuchung des Source-Codes nach Fehlern und Anomalien Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 6 p.1/24 Untersuchung des Source-Codes

Mehr

Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/)

Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/) Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/) Enterprise Continuum Wiederverwendung von Unternehmensarchitekturen Modul

Mehr

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014 Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung Klaus Kusche, September 2014 Inhalt Ziel & Voraussetzungen Was sind abstrakte Datentypen? Was kann man damit grundsätzlich?

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

Model-based Development of Hybrid-specific ECU Software for a Hybrid Vehicle with Compressed- Natural-Gas Engine

Model-based Development of Hybrid-specific ECU Software for a Hybrid Vehicle with Compressed- Natural-Gas Engine Model-based Development of Hybrid-specific ECU Software for a Hybrid Vehicle with Compressed- Natural-Gas Engine 5. Braunschweiger Symposium 20./21. Februar 2008 Dipl.-Ing. T. Mauk Dr. phil. nat. D. Kraft

Mehr

Prozesskette Funktionsdaten und Funktionsmodelle

Prozesskette Funktionsdaten und Funktionsmodelle Prozesskette Funktionsdaten und Funktionsmodelle Stuttgart, 11. Februar 2015 D. Ruschmeier 2/15 Wesentliche Eingangsparameter für die funktional-basierten Berechnungsverfahren sind: Anforderungs-, Modellbeschreibungen

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

Automatisiertes Testen von Prüfplätzen

Automatisiertes Testen von Prüfplätzen EXCO. The Quality Company Solutions for Industry and R&D Automatisiertes Testen von Prüfplätzen Am Beispiel einer Prüfplatz-Software stellen wir einen toolgestützten Prozess zur Erstellung der erforderlichen

Mehr

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept Testkonzept 1.Einführung Um die Zuverläsigkeit und die Qualität der Software und des gesamten Systems zu verbessern, sind Tests durchzuführen. Die Testreihe läst sich in drei Stufen einteilen, nülich Komponententest,

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Vorlesung Embedded Software-Engineering im Bereich Automotive

Vorlesung Embedded Software-Engineering im Bereich Automotive Vorlesung Embedded Software-Engineering im Bereich Automotive Technische Universität Dresden, Fakultät Informatik, Professur Softwaretechnologie WS 2008/2009 Dr. rer. nat. Bernhard Hohlfeld bernhard.hohlfeld@daad-alumni.de

Mehr

Graphischer Editor für die technologieunabhängige User Interface Modellierung

Graphischer Editor für die technologieunabhängige User Interface Modellierung Universität Augsburg Lehrstuhl für Softwaretechnik und Programmiersprachen Prof. Dr. Bernhard Bauer Praktikum Modellgetriebene Softwareentwicklung SS 2008 Graphischer Editor für die technologieunabhängige

Mehr

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R Vector Software W H I T E P A P E R Test Automation mit VectorCAST während der gesamten Softwareentwicklung VectorCAST Produktfamilie Die VectorCAST Produktfamilie automatisiert Testaktivitäten über den

Mehr

Testen - Konzepte und Techniken

Testen - Konzepte und Techniken Testen - Konzepte und Techniken Magdalena Luniak 21.11.2007 Magdalena Luniak () Testen - Konzepte und Techniken 21.11.2007 1 / 42 Übersicht 1 Motivation 2 Grundbegrie 3 Testen im Softwareentwicklungsprozess

Mehr

Basiswissen Softwaretest

Basiswissen Softwaretest Basiswissen Softwaretest Vergleich der Vorlesung Software-Engineering Wartung und Qualitätssicherung (Stand WS13/14) mit der 4. überarbeiteten und aktualisierten Auflage von Spillner&Linz: Basiswissen

Mehr

Simulation 2.0: Simulationsbaukasten und Team-Modellierung

Simulation 2.0: Simulationsbaukasten und Team-Modellierung Simulation 2.0: Simulationsbaukasten und Team-Modellierung Vortrag an der FH Ostfalia, ASIM 2012 Daniel Frechen TESIS DYNAware GmbH 24. Februar 2012 TESIS DYNAware GmbH, www.tesis-dynaware.com 1 Einleitung

Mehr

Einsatz von UML und C++ am Beispiel einer Satelliten-Lageregelungssoftware

Einsatz von UML und C++ am Beispiel einer Satelliten-Lageregelungssoftware Einsatz von UML und C++ am Beispiel einer Satelliten-Lageregelungssoftware Dipl. Inform. Olaf Maibaum DLR, Abt. Simulations- und Softwaretechnik DLR, Abt. Simulations- und Softwaretechnik 1 Übersicht Bird-Satellit

Mehr

Innovator 2007. Anbindung an openarchitectureware. Connect. Klaus Weber. www.mid.de

Innovator 2007. Anbindung an openarchitectureware. Connect. Klaus Weber. www.mid.de Innovator 2007 Anbindung an openarchitectureware Klaus Weber Connect www.mid.de Anbindung an openarchitectureware (oaw) Wozu dient die Anbindung an openarchitectureware? Für Innovator Object excellence

Mehr

Testmanagement. Q-Day. Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de

Testmanagement. Q-Day. Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de Agenda Warum Testmanagement? Was sind die wichtigsten Schritte beim Testmanagement? Wie funktioniert Testmanagement Toolunterstützung Page 1/15

Mehr

Integrierte modellgestützte Risikoanalyse komplexer Automatisierungssysteme

Integrierte modellgestützte Risikoanalyse komplexer Automatisierungssysteme Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner Integrierte modellgestützte Risikoanalyse komplexer Automatisierungssysteme Dipl.-Ing. Michael

Mehr

Softwareentwicklung mit UML

Softwareentwicklung mit UML Softwareentwicklung mit UML Die Unified Modeling Language im Projekteinsatz 2.12.2003, Seite 1 Übersicht 1 Einleitung 2 Die Unified Modeling Language (UML) 3 Vorgehensmodelle und UML 4 Ausblick 4.1 UML

Mehr

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1 30.01.2011 Seite 1 This flyer is exclusively for the use of client personnel. No part of it may be distributed, quoted or reproduced outside the client organisation without the prior written approval of

Mehr

Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- Architekturentwicklung von Fahrzeugen

Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- Architekturentwicklung von Fahrzeugen Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- entwicklung von Fahrzeugen Martin Jaensch, Dr. Bernd Hedenetz, Markus Conrath Daimler AG Prof. Dr. Klaus D. Müller-Glaser

Mehr

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Modellgetriebene Softwareentwicklung auf Basis von TOPCASED am Beispiel

Mehr

objectif / SOA /.NET Inhalt Technologien ObjectiF Beispiel Vergleich: ObjectiF Rational Rose Quellenverzeichnis 20.01.2008 Christian Reichardt 2 Technologien 20.01.2008 Christian Reichardt 3 Methodenaufruf

Mehr

Komponentenbasierte Softwareentwicklung

Komponentenbasierte Softwareentwicklung Seminar WS04 Komponentenbasierte Softwareentwicklung Karl Pauls Software-Komponente A software component is a unit of composition with contractually specified interfaces and explicit context dependencies

Mehr

Modellbasierte Entwicklung im Kontext von Medizingeräten

Modellbasierte Entwicklung im Kontext von Medizingeräten up FPGA Modellbasierte Entwicklung im Kontext von Medizingeräten Gemeinsamer Ausgangspunkt für Software- und Hardwareentwicklung Osnabrück, 06.02.2014, Wanja Schöpfer Agenda 1 Einleitung 2 Modellbasierte

Mehr

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit IBM Software Group IBM Rational mit RequisitePro Hubert Biskup hubert.biskup@de.ibm.com Agenda Rational in der IBM Software Group Der Rational Unified Process als Basis für die Projektarbeit mit Rational

Mehr

ABSICHERUNG MODELLBASIERTER SICHERHEITSKRITISCHER AVIONIK SOFTWARE Dr. Elke Salecker

ABSICHERUNG MODELLBASIERTER SICHERHEITSKRITISCHER AVIONIK SOFTWARE Dr. Elke Salecker ABSICHERUNG MODELLBASIERTER SICHERHEITSKRITISCHER AVIONIK SOFTWARE Dr. Elke Salecker MOTIVATION Fahrzeug-Software wird modellbasiert mit Simulink/TargetLink entwickelt & DO331/DO-178C ermöglicht modellbasierte

Mehr

Peter Liggesmeyer. Software-Qualität. Testen, Analysieren und Verifizieren von Software. 2. Auflage. Spektrum k-/l AKADEMISCHER VERLAG

Peter Liggesmeyer. Software-Qualität. Testen, Analysieren und Verifizieren von Software. 2. Auflage. Spektrum k-/l AKADEMISCHER VERLAG Peter Liggesmeyer Software-Qualität Testen, Analysieren und Verifizieren von Software 2. Auflage Spektrum k-/l AKADEMISCHER VERLAG 1 Inhaltsverzeichnis 1 Einführung 1 1.1 Motivation 2 1.2 Terminologie

Mehr

Henshin: Modelltransformationen in EMF. Dr. Thorsten Arendt Marburg, 29. Oktober 2015

Henshin: Modelltransformationen in EMF. Dr. Thorsten Arendt Marburg, 29. Oktober 2015 Henshin: Modelltransformationen in EMF Dr. Thorsten Arendt Marburg, 29. Oktober 2015 Überblick Modelltransformationen Einführung in Henshin Modelle im Eclipse Modeling Framework Transformationskonzepte

Mehr

Testen II. (Management, Tools) Daniela Rose. Software Engineering Projekt WS07/08 Fachgebiet Softwaretechnik und Systemgestaltung

Testen II. (Management, Tools) Daniela Rose. Software Engineering Projekt WS07/08 Fachgebiet Softwaretechnik und Systemgestaltung Testen II (Management, Tools) Daniela Rose Fachgebiet Softwaretechnik und Systemgestaltung 12.12.2007 Gliederung 1. Motivation 2. Der grundlegende Testprozess 3. Testen im Softwareentwicklungsprozess 4.

Mehr

Experiences with Model Driven Software Development Creating the Palladio Tool Chain Eclipse Application Developer Day 7.

Experiences with Model Driven Software Development Creating the Palladio Tool Chain Eclipse Application Developer Day 7. Experiences with Model Driven Software Development Creating the Palladio Tool Chain Eclipse Application Developer Day 7. July, 2009 WIR FORSCHEN FÜR SIE Dr.-Ing. Steffen Becker sbecker@fzi.de Abteilungsleiter

Mehr

Soft-SPS - Was ist eine SPS?

Soft-SPS - Was ist eine SPS? Soft-SPS - Was ist eine SPS? SPS = Speicherprogrammierbare Steuerung PLC = Programmable Logic Control Ursprünglich elektronischer Ersatz von Relaissteuerungen (Schützsteuerung) 1 Soft-SPS - Relais-Steuerung

Mehr

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Testprozess und Testwerkzeuge 11

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Testprozess und Testwerkzeuge 11 xi 1 Einleitung 1 1.1 Basiswissen komprimiert.......................... 4 1.2 Praxiswissen Testmanagement Übersicht.............. 8 2 Testprozess und Testwerkzeuge 11 2.1 Fundamentaler Testprozess.........................

Mehr