Modellbasiertes Testen

Aus Winfwiki

Namen der Autoren:	Marco Stark, David Espin
Titel der Arbeit:	Modellbasiertes Testen
Hochschule und Studienort:	FOM Essen

Inhaltsverzeichnis 1 Tabellenverzeichnis 2 Abbildungsverzeichnis 3 Abkürzungsverzeichnis 4 Einleitung / Motivation 5 Grundlagen 5.1 Definitionen 5.1.1 Qualitätsmanagement / Qualitätssicherung 5.1.2 Softwaretests 5.1.3 Softwaremodelle 5.1.4 Modellbasiertes Testen 5.2 Abgrenzungen 5.2.1 Manuelles Testen 5.2.2 Capture & Replay 5.2.3 Stichwortbasiertes Testen 6 Einsatzszenarien 6.1 Modellierung von Testfällen 6.2 Generierung von Testfällen aus Modellen 6.3 Testautomatisierung mit modellbasiertem Testen 7 Allgemeine Methodik 7.1 Voraussetzungen 7.1.1 Modelle 7.1.1.1 Klassendiagramm 7.1.1.2 Objektdiagramm 7.1.1.3 Aktivitätsdiagramm 7.1.1.4 Zustandsdiagramm 7.1.2 Tools und Frameworks 7.1.3 Personelle Voraussetzungen 7.2 Fundamentaler Testprozess 7.2.1 Phasen des fundamentalen Testprozesses 7.2.2 Phasenspezifische Aktivitäten 7.2.2.1 Planung & Steuerung 7.2.2.2 Analyse & Design 7.2.2.3 Realisierung & Durchführung 7.2.2.4 Auswertung & Bericht 7.2.2.5 Abschluss 7.3 Automatisierte Generierung von Testfällen 7.3.1 Modelle nutzen 7.3.2 Modelle erweitern 7.3.3 Testfälle generieren 7.3.4 Testfälle ausführen 8 Bewertung 8.1 Vorteile 8.2 Nachteile 9 Fazit 10 Fußnoten 11 Quellenverzeichnis

1 Tabellenverzeichnis

Tabelle Nr.	Quelle / Inhalt
1	Kontrollelemente im Aktivitätsdiagramm
2	Übersicht der Übernahme der Systemmodelle in Testmodelle
3	Vorteile von modellbasiertem Test
4	Nachteile von modellbasiertem Test

2 Abbildungsverzeichnis

Abb.-Nr.	Abbildung
1	Das V-Modell
2	Die vier Prüfebenen des Software-Tests
3	Taxonomie der UML Struktur- und Verhaltensdiagramme
4	Vergleich textuelle Testfallspezifikation mit modellierung von Testfällen
5	Prinzip der Generierung
6	Testautomatisierung mit Hilfe von Testmodellen
7	Beispieldiagramm Cocktailfeier
8	Fundamentaler Testprozess nach ISTQB
9	Das W-Modell
10	Anbindung mit Hilfe von Adaptern am Beispiel Qtronic

3 Abkürzungsverzeichnis

Abkürzung	Bedeutung
DIN	Deutsches Institut für Normung
EN	Europäische Norm
ISO	International Standardization Organisation
ISTQB	International Software Testing Qualifications Board
OMG	Object Management Group
MDA	Model Driven Architecture
MBT	Modellbasiertes Testen
QM	Qualitätsmanagement
SuT	System under Test
TCL	Tool Command Language
TTCN-3	Testing and Testcontrol Notation Version 3
UML	Unified Modeling Language
UTP	Unified Modeling Language Testing Profile

4 Einleitung / Motivation

"Solange der Mensch Software schreibt, wird die Software mit Fehlern behaftet sein, unabhängig davon, in welcher Sprache bzw. auf welcher semantischen Ebene er seine Gedanken zum Ausdruck bringt."^[1]

Dieses Zitat von Harry M. Sneed führt vor Augen, das Softwareentwicklung vermutlich immer mit Fehlern im Rahmen der Entwicklung umgehen muss. Die Fehler können hierbei in alle Phasen der Softwareentwickling entstehen. Fachliche Fehler entstehen vor allem in der Phase der Analyse und des Designs, in der Programmierung kommt es zu technischen Fehlern. Häufig gibt es vier Gründe, die zu Fehlern führen^[2]:

• Kommunikationsprobleme
• Gedächtnisprobleme
• Fachliches Problemverständnis
• Hohe Komplexität der Softwarelösung

Um die Fehler ausfindig zu machen und zu beheben wird die Softwarelösung getestet, welcher Kunde wird schon fehlerhafte Software abnehmen? Daher hat sich in der Softwareentwicklung das Testen als fester Bestandteil des Softwareentwicklungsprozesses etabliert. Viele Prozessmodelle zur Softwareentwickling kennen eine unterschiedliche Anzahl an Testphasen, wie das in Abbildung 1 gezeigte V-Modell.

Die Ziele von Softwaretests sind^[4]:

• Ausführung des Programmes mit dem Ziel, Fehlerwirkung nachzuweisen.
• Ausführung des Programmes mit dem Ziel, die Qualität zu bestimmen.
• Ausführung des Programmes mit dem Ziel, Vertrauen in das Programm zu erhöhen.
• Analysieren des Programmes oder der Dokumente, um Fehlerwirkungen vorzubeugen.

Um diese Fehler nun zu finden gibt es unterschiedliche Möglichkeiten. In der Vergangenheit wurde die Software durch Ausführung getestet, später wurden gezielt alle Eigenschaften eines Softwaresystems sowie dieses selbst getestet und Jahre danach wurde Testen zu einem Softwareengineering Prozess, welcher den Lebenszyklus des Entwicklungsprozesses abdeckt und nicht nur Fehler finden, sondern die getestete Software qualitativ verbessern sollte. Wurde zu Beginn des Testens ohne Testfälle die Software überprüft, werden heute vielfach Testfälle bereits vor der reinen Programmierung verfasst. Anfangs wurde manuell getestet, heute werden Tests vielfach automatisiert.^[5]

Auch die Softwareentwicklung hat sich geändert, es wurden vermehrt standardisierte Notationssprachen verwendet, um anhand eindeutiger Modelle Anforderungen aufzunehmen und zu beschreiben, Softwaresysteme zu entwerfen und Programmierung vorzubereiten und zu dokumentieren. Eine dieser Notationen, die sich heute durchgesetzt hat, ist die UML. Immer mehr wurde von modellgetriebener Entwicklung gesprochen, Softwaremodelle wurden immer wichtiger bis die Methodik der MDA duch die OMG spezifiziert wurde. Diese hat das Ziel, Softwareentwicklung mithilfe von Modellen zu beschleunigen und zu verbessern, indem aus den Modellen Code generiert wird.^[6]

Schließlich wurde die UML nicht mehr ausschließlich in der Konstruktionsphase (vgl. V-Modell) verwendet, sondern auch in der Phase des Testen. Somit fand das Thema Modellierung Einzug in die Welt des Softwaretests, hier wird erstmals vom modellbasierten Testen gesprochen.

Diese Seminararbeit wird grundlegende Fragestellungen um das Thema modellbasiertes Testen untersuchen. Zum einem wird untersucht, was genau modellbasiertes Testen ist und wie es sich von anderen Testmethodiken abgrenzt. Ferner soll untersucht und dargestellt werden, wie modellbasiertes Testen in der Praxis funktioniert. Es wird jedoch nicht detailliert auf praktische Lösungen eingegangen, sondern vielmehr ein theoretischer Wissenshintergrund erarbeitet werden. Zuletzt soll die Arbeit den Nutzen des modellbasierten Testens darstellen, wobei auch Nachteile nicht außer Acht gelassen werden.

5 Grundlagen

5.1 Definitionen

5.1.1 Qualitätsmanagement / Qualitätssicherung

Qualitätsmanagement ist definiert durch die DIN EN ISO 9000:2005, welche Qualitätsmanagement darstellt als aufeinander abgestimmte Maßnahmen zur Leitung und Lenkung von Organisationen in Bezug auf Qualität, welche im Allgemeinen Qualitätsziele, -planung, -durchführung, -sicherung und -verbesserung umfassen^[7]. QM umfasst also die Aufgaben, die eher durch das Management einer Organisation durchgeführt werden. Die technikbezogen Tätigkeiten, die Qualität sicherstellen sollen, werden unter dem Begriff Qualitätssicherung zusammengefasst^[8].
Qualität selbst wird definiert als "... Leistung im Verhältnis zur Erwartung."^[9] Auf die Softwarebranche bezogen bedeutet das, das die realisierte Software nicht den Anforderungen des Auftraggebers entspricht, sie ist also z.B. fehlerhaft. Um das Ausliefern einer fehlerbehafteten Software an den Auftraggeber zu vermeiden, finden unterschiedlichste Testaktivitäten statt.

5.1.2 Softwaretests

Testen von Software ist beschrieben als stichprobenartiges Ausführen von Testobjekten, die einer Überprüfungen dienen, ob das Istverhalten der Software auch dem Sollverhalten entspricht^[10]. Es dient also dem Erkennen, ob die durch die Softwareentwickler bereitgestellte Software auch den im Vorfeld der Programmierung definierten Anforderungen und Konzepten des Auftraggebers entspricht und fehlerfrei ist. Das Sollverhalten wird immer im Vorfeld festgelegt, es beschreibt, wie sich das System im fehlerfreien Falle verhalten soll. Das Istverhalten ist das Ergebnis des Testes. Es zeigt das tatsächliche Verhalten des Systems. Unterscheiden sich Soll- und Istverhalten, so liegt mit aller Wahrscheinlichkeit ein Fehler vor.

Es gibt viele unterschiedliche Tests, z.B. wird unterschieden nach Black-Box und White-Box Tests, wobei bei Black-Box Tests eine Eingabe in dem zu testenden System durchgeführt wird und das Ergebnis auf Korrektheit überprüft wird, bei den White-Box Tests wird zusätzlich zu dem erwartetem Ergebnis das Verhalten zur Laufzeit überprüft^[11]. Es gibt noch eine Vielzahl an weiteren Tests, die sich jedoch immer White-Box oder Black-Box Tests zuordnen lassen.

Die Testarten lassen sich klassifizieren nach der Entwicklungsphase der Softwareentwicklung oder z.B. nach der Prüfebene, in welcher die Software getestet werden soll.

Diese vier Prüfebenenen, die durch Softwaretests geprüft und auf Korrektheit verifiziert werden, wurden von Hoffmann wie folgt beschrieben^[13]:

• Unittests - Hierbei wird eine einzelnen Softwarekomponente getestet, die eine ausreichende Größe besitzt, um separat getestet zu werden. Dies kann eine einzelne Funktion sein, eine Klasse oder auch eine Komponente, die sich aus mehreren Klassen oder Bibliotheken zusammensetzen kann.
• Integrationstests - Integrationstests sind die nächst größere Teststufe. Hierbei werden mehrere Units, Programmodule oder Biblotheken zusammengefasst und das Ist-Verhalten mit dem Soll-Verhalten verglichen. Die zusammengesetzen Komponenten ergeben ein lauffähiges System, hierbei muss es sich jedoch noch nicht um das Zielsystem handeln, sondern um ein lauffähiges Subsystem.
• Systemtest - Der Systemtest findet nach der Integration aller Softwarekomponenten zu einem lauffähigen Zielsystem statt. Hierbei wird die Gesamtheit der Funktionalitäten nach den Kriterien des Pflichtenheftes auf Korrektheit überprüft. Da hierbei ausschließlich das funktionale Verhalten der fertigen Software überprüft wird, handelt es sich hierbei um einen Black-Box Test.
• Abnahmetest - Abnahmetests finden häufig direkt durch den Auftraggeber statt. Hierbei überprüft dieser, oftmals durch die Anwender der Software, ob alle Anforderungen wunschgemäß durchgeführt worden sind. Dieser Test ist auch für vertragliche Abnahme relevant, da auf Basis des Abnahmetests der Erfüllungsgrad festgelegt wird.

5.1.3 Softwaremodelle

Bereits in den 1970er Jahren wurden Modelle von Stachowiak in seiner allgemeinen Modelltheorie beschrieben und mit den folgenden Merkmalen assoziiert:^[14]

• Abbildungsmerkmal - Modelle bilden etwas ab, und zwar ein Original bzw. einen Ausschnitt davon oder sie sind eine Abbildung anderer Modelle.
• Verkürzungsmerkmal - Modelle beinhalten nur die notwendigen Informationen und Attribute, die ein Modellbenutzer zu dem entsprechenden Zeitpunkt benötigt. Ein einzelnes Modell ist also im allgemeinen nicht eine vollständige Abbildung seines Originals.
• Pragmatisches Merkmal - Modelle dienen einem bestimmten Zweck zu einem definiertem Zeitpunkt für einen spezifischen Betrachter.

Modelle sind also eine zweckbestimmte Abbildung, welche ihr dazugehöriges Original aus einer spezifischen Perspektive wiedergeben. Je nach Sichtweise, sehen unterschiedliche Modelle eines Originals also auch unterschiedlich aus, z.B. weil ein Modellbenutzer mehr oder andere Informationen benötigt als ein anderer Modellbenutzer. Auf Softwareentwicklung (und Testen!) bezogen lässt sich zusammenfassen, das Modelle existierende oder zu entwickelnde Softwaresysteme darstellen wobei sich der Informationsgehalt des Modells immer der notwendigen Sichtweise und dem Zweck des Modells entspricht^[15]. So benötigen Systemanalytiker bei der Konzeption andere Modelle (oder Modellsichten) als z.B. Programmierer während der Entwicklung oder Tester beim Spezifizieren von Testfällen. Modelle haben in der Softwareentwicklung wichtige Aufgaben, welche die Arbeit vereinfachen soll, vor allem bei komplexen Sachverhalten. Modelle helfen vor allem, da sie^[16]:

• Der Projektkommunikation zwischen den Stakeholdern im Projekt dienen, und zwar in dem notwendigen Abstraktionsgrad.
• Auswirkungen von Änderung während der Entwicklung (Design oder Programmierung) visualisieren.
• Verifizieren aller Informationen auf Vollständigkeit, Widerspruchs- und Fehlerfreiheit.

Um Modelle eindeutig zu beschreiben bedient man sich häufig einer Modellierungssprache, wie z.B. der UML, welche von einem herstellerunabhängigem Konsortium, der Object Management Group, entwickelt und gewartet wird. Da im Verlauf der Seminararbeit die Verwendung von UML Modellen für das modellbasierte Testen zum Tragen kommt, seien diese hier erläutert. Die UML bietet dem Modellierer eine Sammlung von Modell- bzw. Diagrammtypen, die er nutzen kann um seine Softwaremodelle in einer einheitlichen Notation zu visualisieren.

Die Abbildung zeigt, welche Diagrammtypen die UML bereitstellt. Sie lassen sich kategorisieren in:

• Strukturdiagramme - Sturkturdiagramme verleihen dem Modell eine statische Struktur.
• Verhaltensdiagramme - Mit Hilfe von Verhaltensdiagrammen lässt sich das spezifisches Verhalten der Software in einem Modell abbilden.
• Interaktionsdiagramme - Bei diesen handelt es sich um eine Unterkategorie der Verhaltensdiagramme, welche die Interaktion zwischen Modellkomponenten oder anderen Modellen grafisch darstellt.

Die notwendigen UML Diagramme, die für das Modellbasiertes Testen genutzt werden können, werden in Kapitel 7.1.1 aufgelistet und beschrieben.

5.1.4 Modellbasiertes Testen

Modellbasiertes Testen wird häufig auch modellgetriebenes Testen genannt. Hierbei sollen Modelle, in unterschiedlicher Abstraktionstiefe, so verwendet werden, dass sich daraus Testfälle ableiten lassen. Dies kann manuell oder automatisiert geschehen oder auch so weit führen, das die Tests völlig automatisiert durchgeführt werden. Dies ist abhängig vom gewählten Einsatzszenario. Der Einsatz von Modellen soll hier helfen, die richtige und eindeutige Sichtweise auf das oder die Testobjekte zu gewinnen und durch eine visuelle Darstellung das Testobjekt für andere sichtbar zu machen. Durch eine sorgfältige Modellierung werden Testobjekte zudem unmissverständlich interpretierbar^[18]. Beim MBT werden also Modelle, wie sie ähnlich in der Konzeption und Programmierung schon lange eingesetzt werden, genutzt um die Effizienz und Qualität des Testes zu erhöhen. Dies kann auch in einer sehr frühen Phase des Softwareentwicklungsprozess geschehen, z.B. in der Designphase um die Qualität der erstellten Modelle bereits zu überprüfen.

Je nach Einsatzszenario für das MBT, siehe hierzu auch Kapitel 6, unterscheidet sich durchaus der Umfang und der Nutzen der Modelle. So reicht der Ansatz vom MBT vom reinen Modellieren von Testfällen hin bis zu einem größtenteils automatisiertem Test.

Jedoch ist MBT keine vollständig neue oder eigenständige Testtechnik, da heute nahezu alle Testtechniken und Methoden mehr oder weniger Modelle verwenden und deshalb als MBT verstanden werden können. Jedoch beinhalten die modellbasierten Testtechniken im engeren Sinne komplexe Modelle mit dem Ziel, Testfälle automatisch zu generieren und diese Tests entsprechend auszuwerten^[19].

5.2 Abgrenzungen

Dieses Kapitel beschreibt kurz andere Arten Software zu testen, die aber nicht Gegenstand dieser Arbeit sind.

5.2.1 Manuelles Testen

Manuelle Testfälle werden komplett von einem menschlichen Tester durchgeführt und protokolliert. Die Testfälle liegen hierbei meist in Form einer Schritt-für-Schritt-Anleitung vor. Dabei werden keine aufwendigen Systeme zur Testdurchführung benötigt, ein identisches erneutes Durchführen der Tests ist allerdings kaum möglich.^[20]

5.2.2 Capture & Replay

Anstatt manuelle Tests zu erstellen werden beim Capture & Replay Verfahren die Eingaben der Tester aufgezeichnet (Capture) und zum späteren wiederholen (Replay) zur Verfügung gestellt. Durch Automatisierung vereinfacht dies die Durchführung von Nach- und Regressionstests sowie die Dokumentation der durchgeführten Tests.^[21]

5.2.3 Stichwortbasiertes Testen

Beim stichwortbasierten Testen werden die Testfälle anhand von Tabellen erstellt. Diese Tabellen enthalten alle nötigen Informationen die ein Parser benötigt um die Anwendung erfolgreich testen zu können.^[22]

6 Einsatzszenarien

6.1 Modellierung von Testfällen

Ein Testfall beinhaltet alle Rahmenbedingungen zur Durchführung eines Testes. Dies beinhaltet die notwendigen Eingabewerte für den Test, die erwarteten Ausgaben das erwartete Verhalten des Testobjektes^[24]. Der Testfall beinhaltet ferner alle notwendigen Schritte in der korrekten Reihenfolge die zur Absolvierung des Testfalls notwendig sind^[25]. Liegen diese Testfälle in einer rein verbalen, textuellen Notation vor, so ist die Beschreibung des Testfalles nicht immer eindeutig interpretierbar. Hierbei hilft der Einsatz eines Testmodelles, denn Modelle helfen, Systeme visualisiert darzustellen, alle notwendigen Zusammenhänge nachvollziehbar aufzuzeigen und Widersprüche besser aufzudecken^[26].

Im von Roßner beschriebenen Szenario der Modellierung von Testfällen "... liegt der Vorteil des Modells "nur" in seiner Eindeutigkeit und Transparenz im Vergleich zur textuellen Spezifikation."^[27].

Das Modellieren von Testfällen beinhaltet also das Erstellen von Testfällen in Testmodellen inkl. aller Testschritte und notwendigen Testdaten. Das Testmodell kann z.B. Aktivtäts- oder Klassendiagramme, Zustandsautomaten oder Sequenzdiagramme enthalten.

6.2 Generierung von Testfällen aus Modellen

Werden aus Modellen, seien es Umgebungs-, System- oder abstrakte Testmodelle, konkrete Testmodelle erzeugt, so spricht man hierbei von der Generierung von Testfällen aus Modellen. Hierbei werden die konkreten Testfälle direkt aus Modellen einer höheren Abstraktionsebene generiert. Damit diese Generierung automatisiert durchgeführt werden kann, müssen die Informationen über das Sollverhalten und die genauen Regeln zum Ableiten der Testfälle in den der Generierung zu Grunde liegenden Modellen enthalten sein. Hierdurch lassen sich in kurzer Zeit viele Testfälle generieren, die sonst hätten manuell erzeugt werden müssen. Voraussetzung ist hierbei eine entsprechende Detailtiefe der Modelle. Durch die automatisierte Generierung der Testfälle werden allerdings keine Testfälle erzeugt, wie sie ein ehrfahrener und entsprechend kreativer Tester beschrieben hätte, es fehlen also ggf. Tests auf Fehler, die sich einem Modell nicht entnehmen lassen^[29].

Die rechts stehende Abbildung 5 zeigt das Prinzip der Generierung. Wird ein Generator, bzw. eine Modelltransformation, verwendet, um ein Zwischenprodukt, in diesem Fall einen oder mehrere Testfälle, zu erzeugen, so ist der hierfür notwendige Aufwand geringer als bei der manuellen Erstellung des Zwischenproduktes durch eine Person. Ein weiterer Vorteil ist, das bei funktionalen Änderungen am System nur das zentrale Modell angepasst werden muss und anschließend die Testfälle neu generiert werden können, anstatt alle Testfälle nach Anpassungsbedarf durch die Änderung zu untersuchen und die Änderung dann in jedem betroffenen Testfall manuell nachziehen zu müssen^[30].

Bei komplexen Modellen kommt es bei der Generierung von Testfällen sehr schnell zu einer sehr großen Menge an Testfällen, daher ist es hilfreich, wenn bei der Generierung von Testfällen die Menge der Generierung eingeschränkt werden können, da sonst das Testen nicht mehr wirtschaflich sein kann^[31].

6.3 Testautomatisierung mit modellbasiertem Testen

Bei der Testautomatisierung werden die Testfälle auch automatisiert durchgeführt. Diese Testfälle sind idealerweise bereits im Vorfeld auch automatisch aus Modellen generiert worden. Allerdings können die automatisierten Tests auch auf Basis manuell erzeugter Testmodelle durchgeführt werden^[33].

Nach Spillner handelt es sich bei der Testautomatisierung um die Verwendung von Softwaretools, um Testfälle zu erstellen oder zu programmieren, damit diese rechnergestützt beliebig oft wiederholt werden können^[34].

Die Tests werden hierbei durch einen sogenannten Testroboter, eine Software, die an das SuT angebunden ist, durchgeführt. Ebenfalls werden die Ergebnisse durch den Testroboter protokolliert und dargestellt. Dabei gibt es hier keinen klassischen Tester, der testet, sondern allenfalls den Testdesigner, der für die Erstellung der Modelle verantwortlich ist, die Generierung sowie die Ausführung durch den Testroboter verantwortet. Die Rollenbeschreibungen lassen sich detailliert Spillner entnehmen, wobei auch der Testdesigner mit entsprechender Kenntniss der verwendeten Tools, einen automatisierten Test durchführen kann^[35].

Bei diesem Szenario ist der Grad der Automatisierung der Höchste von allen.

7 Allgemeine Methodik

7.1 Voraussetzungen

7.1.1 Modelle

Grundsätzlich kann jedes Diagramm als Basis für modellbasiertes Testen dienen. Da sich viele Werkzeuge aus dem Fundus der UML Diagramme bedienen werden hier einige oft verwendete Exemplare erläutert. ^[36]

Wie diese Modelle zum erstellen von Testfällen genutzt werden können wird in Kapitel 7.3 beschrieben. Weiterhin werden die Diagramme in diesem Kapitel nur in ihren Grundzügen erläutert. Für eine detaillierte Beschreibung aller Elemente ist weiterführende Literatur notwendig.

7.1.1.1 Klassendiagramm

In UML 2 wird eine Klasse als eine "Sammlung von Exemplaren, die über gemeinsame Eigenschaften, Einschränkungen und Semantik verfügen"^[38], verstanden. Ein Klassendiagramm ist also eine Abstraktion eines konkreten Objektes. In einem Klassendiagramm werden Attribute, Operationen und Beziehungen dargestellt, die ein Objekt haben kann. Bei Attributen und Operation ist zusätzlich eine Darstellung der Sichtbarkeit gegenüber anderen Klassen vorgesehen.^[39] Ein Beispiel, welches all diese Elemente enthält ist in Abbildung 7 zu sehen.

Ein Attribut ist eine Eigenschaft, die bei einem Objekt mit konkreten Inhaltswerten gefüllt wird. Der Name eines Attributes muss innerhalb einer Klasse eindeutig sein. Zusätzlich zu dem Namen der Eigenschaft wird außerdem oft der Typ und ggf. ein Vorgabewert angegeben. Positioniert werden Attribute in dem Bereich unterhalb des Klassennamens^[40].

Die allgemeine Syntax für ein Attribut sieht wie folgt aus:^[41]

[Sichtbarkeit] [/] Name [: Typ] [[Multiplizität]] [= Vorgabewert] [{Eigenschaftswert [, Eigenschaftswert]*}]

Operationen beschreiben das Verhalten von Objekten und sind zu gleich die Basis zur Interaktion mit diesen. Darüber hinaus ist eine Zustandsänderung nur über Operationen möglich. Operationen werden durch ihren Namen sowie ggf. einer Parameterliste und eines Rückgabewertes dargestellt. Auch hierbei gilt, dass der Name einer Operation innerhalb einer Klasse eindeutig sein muss. Operationen werden im Klassendiagramm im Bereich unter den Attributen aufgelistet.^[42]

Die allgemeine Syntax für eine Operation lautet wie folgt:^[43]

<Operationsname> ::= 
[Sichtbarkeit] name ([Parameterliste]) [: Rückgabetyp] [{Eigenschaftswert [, Eigenschaftswert]*}]

<Parameterliste> ::= 
[Übergabeberechtigung] Name : Typ [[Multiplizität]] [= Vorgabewert] [{Eigenschaftswert [, Eigenschaftswert]*}]

Es gibt unterschiedliche Arten von Beziehungen. Als erstes sei hier die Generalisierung bzw. Spezialisierung genannt. Sie setzt zwei Klassen so in Beziehung zueinander, dass die eine Klasse eine Verallgemeinerung der anderen Klasse darstellt. Im Beispiel ist die Generalisierung zwischen Partyteilnehmer und Gastgeber zu sehen.^[44]

Der zweite Beziehungstyp ist die Assoziation, die sich wiederum in Aggregation und Komposition unterteilen lässt. Allgemein beschreibt eine Assoziation eine Menge gleichartiger Beziehungen zwischen Klassen, wobei auch das gegenseitige Zugreifen auf Attribute und Operationen gewährleistet wird. Dargestellt wird eine einfache Assoziation durch eine verbindende Linie zwischen den Klassen, an die sowohl ein Name als auch eine Multiplizität angefügt werden kann.^[45]

Eine Aggregation als spezielle Assoziation drückt eine "Teile-Ganzes-Beziehung" aus. Dargestellt wird eine Aggregation als verbindende Linie zwischen zwei Klassen, bei der an dem Ende, welches das "Ganze" darstellt, eine nicht ausgefüllte Raute platziert wird.^[46] Im Beispiel zu sehen zwischen Partyteilnehmer und Feier.

Eine Komposition als spezielle Assoziation drückt eine existentielle Beziehung zwischen dem "Teil" und dem "Ganzen" aus. Dies wird in einem Bespiel deutlich: Der Mensch besitzt 10 Finger. Diese Finger können ohne den Menschen allerdings nicht existieren. Wenn ein Ganzes zerstört wird bedeutet dies, dass auch dessen Teile zerstört werden. Anders als bei der Aggregation kann hier deshalb auch ein Teil immer nur einem Ganzen zugeordnet sein. Dargestellt wird die Komposition durch eine verbindende Linie zwischen zwei Klassen an deren Ende, welches das Ganze darstellt, eine ausgefüllte raute positioniert wird.^[47] Im Beispiel zwischen Zutat und Cocktail zu sehen.

7.1.1.2 Objektdiagramm

Das Objektdiagramm stellt ein System in einer Momentaufnahme dar. In ihm werden Objekte modelliert, wie sie zu einem bestimmten Zeitpunkt im System vorhanden sind. Als Grundlage für die Modellierung kann jedes andere Diagramm dienen, in der Regel wird jedoch das Klassendiagramm zu Grunde gelegt. Im Gegensatz zum Klassendiagramm, das alle möglichen Zusammenhänge abstrakt darstellt, kann ein Objektdiagramm nur die zu diesem Zeitpunkt relevanten Elemente (d.h. Attribute) enthalten. Dabei spielen drei Arten von Instanzen eine Rolle:^[48]

• das Objekt - Instanz der Klasse
• der Link - Instanz einer Assoziation
• der Wert - Ausprägung eines Attributs

Dargestellt wird ein Objekt ähnlich wie eine Klasse. Im obersten Bereich Steht der Objektname mit dem Klassennamen durch einen Doppelpunkt getrennt. Darunter stehen die Attribute mit ihren Werten. Die Zuweisung wird als Gleichheitszeichen dargestellt.

7.1.1.3 Aktivitätsdiagramm

Das Aktivitätsdiagramm unterscheidet sich von den bisher betrachteten Diagrammen in so fern, als das es sich hierbei um ein Verhaltensdiagramm und nicht um ein Strukturdiagramm handelt. Es bildet also keine Systemstruktur ab, sondern vielmehr ein Verhalten des Systems unter bestimmten Randbedingungen. Das Verhalten wird dabei als Aktivität bezeichnet und ist laut UML 2 eine Menge von potentiellen Abläufen eines Systems.^[49]

Ein Aktivitätsdiagramm hat dabei folgende wesentlichen Elemente:^[50]

• Aktivitäten
• Aktionen
• Objektknoten
• Kontrollelemente zur Ablaufsteuerung
• verbindende Kanten

Ein Aktivitätsdiagramm besteht aus mindestens einer Aktivität. Eine Aktivität wiederum hat einen Namen und 1 bis n möglicher Abläufe die bestimmte Aktionen durchlaufen. Da jede Aktion selbst auch eine Aktivität darstellen kann, können Aktivitäten auch ineinander verschachtelt sein. Objektknoten am Anfang und am Ende einer Aktivität stellen Ein- und Ausgabeparameter dar.^[51]

Ein Rechteck mit abgerundeten Ecken stellt eine Aktion dar. Im Zentrum des Rechtecks steht der Name der Aktion. Eine Aktion ist zentrales Element eines Aktivitätsdiagrammes. Alle anderen Elemente dienen nur dazu den Ablauf der verschiedenen Aktionen innerhalb einer Aktivität zu steuern bzw. den Datenaustausch zu gewährleisten. Die Aktion selbst beschreibt den Aufruf eines Verhaltens oder das Ausführen einer Datenverarbeitung.^[52]

Ein Objektknoten wird als einfaches Rechteck dargestellt. Er bezeichnet die Ausprägung eines bestimmten Typs, meist einer Klasse und dient zum Transportieren von Daten von einer Aktion zur nächsten. Der Objektknoten ist dabei immer das Ergebnis der direkt vorangegangenen Aktion und Eingabe für die direkt folgende Aktion.^[53]

Es gibt sechs unterschiedliche Kontrollelemente. Sie dienen dazu den Ablauf innerhalb einer Aktivität zu steuern. Diese lauten wie folgt:^[54]

Kontrollelement	Darstellung	Bedeutung
Startknoten	ausgefüllter Kreis	markiert Startpunkt eines Abflaufs
Endknoten	umrandeter ausgefüllter Kreis (gesamte Aktivität) oder ein durch einen Kreis eingefasstes X (einzelner Ablauf)	markiert das Ende eines Ablaufs oder einer Aktivität
Verzweigungs- oder Verbindungsknoten	nicht ausgefüllte Raute	splittet oder verbindet Kanten zwecks eines bedingten Ablaufs
Synchronisation / Parallelisierung	Balken	splittet oder verbindet Kanten zum parallelen Ablauf unterschiedlicher Wege, bzw. vereint zwei unterschiedliche Abläufe zu einem.

Tabelle 1: Kontrollelemente im Aktivitätsdiagramm

Kanten bilden die Übergänge zwischen den Aktionen und Objektknoten. Sie sind immer gerichtet und werden als Pfeil dargestellt. Zur Erläuterung können Kanten auch benannt werden.^[55]

7.1.1.4 Zustandsdiagramm

Zustandsdiagramme oder auch Zustandsautomaten werden ebenfalls dazu genutzt, das Verhalten eines Systems zu spezifizieren. Üblich ist es, mögliche Zustände von Klassen und Use-Cases durch ein Zustandsdiagramm darzustellen.^[56] Da bisher keine Use-Cases betrachtet wurden, wird hier nur die Modellierung von Zustandsdiagrammen für Klassen erklärt.

Um ein Zustandsdiagramm für eine Klasse erstellen zu können, müssen zunächst Zustandsvariablen definiert werden. Zustandsvariablen sind Attribute einer Klasse, die nur eine endliche Menge von gültigen Werten annehmen können. Dies ist zum Beispiel bedingt durch die Zuweisung eines Datentyps. Die Zustände, die eine Klasse annehmen kann definieren sich dann aus allen Kombinationen aller Zustände sämtlicher Zustandsvariablen. Damit dies nicht zu einer übermäßigen Komplexität führt, empfiehlt es sich nur die vermeintlich wichtigen Attribute als Zustandsvariablen zu definieren.^[57]

Als Notationselemente stehen hier, neben dem eigentlichen Zustand und den verbindenden Transitionen, Pseudozustände zur Verfügung. Pseudozustände sind dabei ähnlich den Kontrollelementen des Aktivitätsdiagrammes. Zusätzlich zu den bekannten Elementen gibt es bei Zustandsdiagrammen allerdings noch weitere Elemente wie zum Beispiel Terminatoren.^[58] Diese sind allerdings zum Verständnis einfach gehaltener Diagramme nicht relevant und werden hier deshalb nicht erläutert.

7.1.2 Tools und Frameworks

Nach den Autoren der iX Studie zum modellbasierten Testen lassen sich die Tools, die zur Durchführung eines automatisierenden Ansatzes unerlässlich sind, in drei verschiedene Kategorien einordnen:^[59]

1. Modellbasierte Testdatengeneratoren - generieren aus einem Modell der Ein- oder Ausgangsdaten Testdaten (keine Generierung von Testschrittsequenzen)
2. Modellbasierte Testfalleditoren - generieren von ausführbaren Testfällen (automatisch oder manuell) aus einem abstrakten Testfallmodell
3. Modellbasierte Testfallgeneratoren - generieren von Testfällen oder -skripten aus Verhaltens- oder Umgebungsmodellen des Systems

Mit Bezug auf das Kapitel 7.3 wird hier nur die Kategorie der Testfallgeneratoren näher betrachtet. Tools dieser Kategorie verwenden System- oder Testmodelle zur Generierung von Testfällen, dabei werden sowohl Daten als auch Testschrittsequenzen erstellt. Zusätzlich wird meist eine Anbindung an ein Anforderungsmanagementtool mittels Plugins oder Interfaces unterstützt. Auch geben Tools dieser Kategorie Rückmeldung über den Abdeckungsgrad der Anforderungen. Automatisierte Testdurchführung wird hierbei durch interne Module oder externe Tools realisiert.^[60] Wie dies geschieht hängt aber stark vom verwendeten Tool ab. Grundsätzlich ist dazu eine Anbindung an das System under Test (SuT) notwendig, die entweder im Tool selber konfiguriert oder durch externe Adapter oder Frameworks bereit gestellt wird.

Die Auswahl der Tools soll frühzeitig im Projekt erfolgen, da je nach Art und Weise der Testautomatisierung zusätzlicher Aufwand für die Erstellung von Frameworks oder Adaptern einkalkuliert werden muss.

7.1.3 Personelle Voraussetzungen

Beim modellbasierten Testen ist darauf zu achten, dass das Personal, welches die Tests durchführt (inkl. Vor- und Nachbereitung), auch für die spezifischen Anforderungen, die modellbasiertes Testen an die Tester stellt, geeignet ist. Grundsätzlich soll das Personal Kenntnisse und Fähigkeiten rund um das Testen besitzen. Ideal ist hier eine durch Industriestandards vorgegeben Testausbildung, wie z.B. den ISTQB Certified Tester, welcher nach einem dreistufigem Qualifizierungsschema ausgebildet wird^[61]. Dabei soll der Tester die Aufgaben nach dem fundamentalen Testprozess durchführen können, welcher in Kapitel 7.2 beschrieben ist.

Außerdem müssen die Tester die verwendete Notation der Modellierungssprache, z.B. UML, beherrschen. So sind sie in der Lage, die Modelle, die im Vorfeld während der Design oder Entwicklungsphase entstanden sind, zu verstehen. Außerdem können Sie selbst fehlerfrei eigene UML Modelle erstellen, die für die einzelnen Tests notwendig sind. Je nachdem in welcher Phase die Tests eingesetzt werden und welche spezifische Aufgabe der Tester hat, sind auch Programmierfähigkeiten notwendig. So kann es z.B. sein, das der Tester ein Testskript oder einen Adapter programmieren muss, anhand dessen die verwendeten Tools automatisch die Tests durchführen können. Handelt es sich beim Testen um entwicklungsnahen Test und das Verhalten des Systems soll zur Laufzeit als White-Box Test durchgeführt werden, so sind auch hier Programmierkenntnisse von Vorteil, und sei es ausschließlich um den geschriebenen Quellcode verstehen und analysieren zu können. Kenntnisse der zu testenden Fachlichkeit benötigen die Tester natürlich ebenfalls^[62].

Werden Tools zur Testautomatisierung eingesetzt, so ist es wichtig, das der Tester auch mit diesen Tools arbeiten kann. Da diese sehr komplex sind, sind Schulungen durch den Hersteller des Tools sinnvoll.

7.2 Fundamentaler Testprozess

7.2.1 Phasen des fundamentalen Testprozesses

Die Tätigkeit des Testens ist in Softwareentwicklungsmodellen wie dem Wasserfallmodell zwar vorgesehen, die bloße Eingliederung in den gesamten Prozess reicht aber nicht aus um Tests strukturiert durchführen zu können. Hierzu ist eine detaillierte Aufgabenplanung der Testaktivitäten notwendig. Nach dem ISTQB gliedern sich Softwaretests in insgesamt 5 Phasen:

1. Planung & Steuereung
2. Analyse & Design
3. Realisierung & Durchführung
4. Auswertung & Bericht
5. Abschluss

Abbildung 8 zeigt diese Phasen inklusive möglicher Durchlaufwege. Obwohl die Phasen sequenziell Dargestellt sind, können diese sich auch überschneiden oder parallel Laufen. Alle Phasen zusammen bilden demnach den fundamentalen Testprozess.^[64]

7.2.2 Phasenspezifische Aktivitäten

Im Folgenden werden die Tätigkeiten aus dem zuvor erwähntem fundamentalen Testprozess nach Basiswissen Softwaretest von A. Spillner näher erläutert.

7.2.2.1 Planung & Steuerung

Da Testen von Software eine sehr umfangreiche und stark an die Softwareentwicklung gebundene Aufgabe darstellt, muss dies sorgfältig und frühzeitig geplant werden. Diese Planung beginnt mit dem Anfang des Entwicklungsprozesses. Im weiteren Verlauf muss dann kontrolliert werden ob es Abweichungen von der Planung gibt und ggf. steuernd eingegriffen werden. Voraussetzung um mit der Planung beginnen zu können ist, dass Aufgaben und Ziele des Tests festgelegt sind. Im Anschluss daran kann mit der Ressourcenplanung begonnen werden. Hierbei werden Mitarbeiter den Aufgaben zugeordnet und ermittelt, ob im Vorfeld Schulungen notwendig sind. Es wird bestimmt welche Infrastruktur für die Erfüllung der Aufgaben notwendig ist und wann diese zur Verfügung stehen muss. Diese Tätigkeiten obliegen dem Testmanagement.^[65]

Kernaufgabe der Planung ist das Festlegen einer Teststrategie. Da ein vollständiger Test einer Anwendung in der Regel nicht möglich ist, müssen die zu testenden Einheiten nach Schwere der Fehlerwirkung priorisiert werden. Je gravierender die Fehlerwirkung, desto intensiver muss die Einheit getestet werden. Andere Einheiten werden im Gegenzug weniger stark bzw. unter Umständen gar nicht getestet. Zu der Teststrategie gehört auch das festlegen von Testendekriterien, die dazu dienen ein geeignetes Ende für die Testaktivitäten definieren zu können.^[66]

Eine weitere Aufgabe ist die Auswahl und Beschaffung von Testunterstützungswerkzeugen. Dabei ist zu bestimmen ob diese selbst hergestellt werden müssen oder ob es alternative Bezugsquellen gibt. Im Fall von Testrahmen, in denen Softwareteile zur Ausführung gebracht werden können, ist meist eine eigene Entwicklung notwendig, zur Testautomatisierung kann wiederum ein am Markt verfügbares Produkt in Erwägung gezogen werden.^[67] Hierbei ist die gewünschte Teststrategie zu beachten, da verschiedene Tools unterschiedliche Möglichkeiten bieten. (Vgl. Kapitel 7.1.3)

Testet man modellbasiert, so wird in dieser Phase bestimmt ob nur nach Modellen getestet oder eine modellbasierte Automatisierung durchgeführt werden soll. So soll je nach Prozessreife und gewünschtem Vorgehen auch ein passendes Tool aus den in Kapitel 7.1.2 erwähnten Kategorien ausgewählt werden.

7.2.2.2 Analyse & Design

In dieser Phase wird die Testbasis, also die Dokumente die als Grundlage für die Untersuchung eines Testobjektes genutzt werden, dahingehend analysiert, ob sie ausreichend spezifiziert sind um daraus Testfälle abzuleiten. Sind die Dokumente für ausreichend befunden, wird mit dem erstellen der Testfälle begonnen. Dabei ist die in der Strategie festgelegte Testmethode zu beachten. In dieser Phase werden zunächst nur sehr allgemeine Testfälle spezifiziert. D.h. aus der Anforderung

Ab 5 bestellter Artikel gibt es 20% Rabatt.

folgen mindestens 2 Testfälle:

1. 1 bis 4 Artikel bestellen
2. 5 oder mehr Artikel bestellen

Konkretisiert werden die Testfälle erst in der nächsten Phase. Diese allgemeinen Testfälle werden auch logische Testfälle genannt.^[68]

Zu der Spezifikation eines Testfalls gehören nicht nur die notwendigen Eingaben, sondern auch etwaige Rand- und Vorbedingungen sowie ein erwartetes Ergebnis. Um letzteres bestimmen zu können muss ein so genanntes Testorakel befragt werden. Hierbei handelt es sich um eine Quelle, die auf das Ergebnis schließen lässt.^[69] Im vorherigen Beispiel wäre dies die angegebene Anforderung, aus der sich für den ersten Testfall ein Ergebnis von 0% und für den zweiten eines von 20% Rabatt ergibt.

Geht man modellbasiert vor, so sind in dieser Phase die Modelle als Testbasis zu prüfen und um die notwendigen Informationen für den Test zu erweitern. Dies ist in Kapitel 7.3.2 näher erläutert.

7.2.2.3 Realisierung & Durchführung

Bei der Realisierung und Durchführung werden zunächst aus den logischen konkrete Testfälle abgeleitet. Für obiges Beispiel hieße dies zum Beispiel

1. 2 Artikel bestellen
2. 7 Artikel bestellen

Im Anschluss daran werden die Verschiedenen Testfälle zu Testsequenzen zusammen gefasst. Dies dient dazu viele Testfälle eines komplexen Systems zeiteffizient Testen zu können, da in einer Testsequenz gleich mehrere Testfälle abgehandelt werden.^[70] Ein Beispiel hierzu wäre die Testsequenz "Einfache Bestellung" die sich aus einem Testfall für das Login und einem der zuvor angegebenen Testfälle zusammensetzt.

Sind alle Testfälle konkretisiert und zu Sequenzen zusammengefasst, können sie wie in der Teststrategie festgelegt abgearbeitet werden. Dabei ist besonders auf die Dokumentation zu achten, denn werden Fehlerwirkungen nicht protokolliert, können sie nicht behoben werden. Hierbei werden alle Rahmenbedingungen, ausgeführte Schritte und das tatsächliche Systemverhalten festgehalten. Auch eine Priorisierung der Fehler in Fehlerklassen ist ratsam um die Behebung schwerer Fehler zu forcieren.^[71]

Ist ein modellbasiertes Vorgehen gewählt, so kommt es in dieser Phase stark auf das gewählte Unterstützungstool an, was möglich ist. Wird ein Testdatengenerator eingesetzt, so können einfach konkrete Testfälle abgeleitet werden. Wird ein Tool einer anderen Kategorie eingesetzt kann die Unterstützung bis zum Dokumentieren der Fehler gehen. Dies wird in den Kapiteln 7.3.3 und 7.3.4 genauer beschrieben.

7.2.2.4 Auswertung & Bericht

In dieser Phase werden die festgelegten Testendekriterien auf Erfüllung überprüft. Dabei kann es zu unterschiedlichen Ergebnissen kommen: Wird festgestellt, dass die Kriterien noch nicht erfüllt sind, müssen weitere Tests spezifiziert und durchgeführt werden. Ein weiteres Ergebnis kann sein, dass der Aufwand für weitere Tests nicht verhältnismäßig ist. Dann können die Testaktivitäten auch ohne erreichen der Kriterien abgebrochen werden. Dies soll aber immer mit Blick auf das erwartete Risiko geschehen. Sind die Testendekriterien erreicht, ist ein Abschlussbericht zu verfassen, der Stellen wie das Projektmanagement über die Ergebnisse der Testaktivitäten aufklärt.^[72]

Auch hierbei können Tools aus dem Fundus des MBT helfen, da diese, wenn sie denn Testfälle generieren, auch Aufschluss über z.B. die Testabdeckung geben. Diese ist wiederum eine von viele Kennzahlen, die als Testendekriterium dienen kann.

7.2.2.5 Abschluss

In der letzten Phase des Testprozesses ist ein kritischer Rückblick auf die durchgeführten Tests vorgesehen um die gemachten Erfahrungen auch für zukünftige Projekte nutzen zu können. Dies dient vornehmlich dazu den etablierten Testprozess zu verbessern. Es sollten hier die verwendeten Tools so wie die eingesetzten Testsysteme und -rahmen konserviert werden, um im Zeitraum der Wartung weiter zur Verfügung zu stehen.^[73]

7.3 Automatisierte Generierung von Testfällen

7.3.1 Modelle nutzen

Im Rahmen des Softwareprojektes entstehen nach Roßner Modelle, von denen drei Kategorien bei MBT von besonderer Relevanz sind^[74]:

• Umgebungsmodell - Das Umgebungsmodell stellt das System und seine direkte Umgebung dar und beschreibt Anforderungen an das System als auch Randbedingungen unter denen das System funktionieren muss.
• Systemmodell - Das Systemmodell beschreibt das System sowohl aus seiner statischen als auch aus seiner dynamischen Sicht, also wie ist das System realisiert und wie funktioniert es.
• Testmodell - Das Testmodell entsteht beim MBT als Beschreibung der durchzuführenden Tests. Es ist eine Zusammenfassung der notwendigen Modelle des Umgebungs- und Systemmodell um Tests durchführen zu können, diese werden auch um Tests-pezifische Informationen angereichert.

Das Testmodell, welches durch die Tester entsteht, kann aus folgenden UML Diagrammen bestehen:

• Klassendiagramm - Klassendiagramme beschreiben die notwendigen Daten und strukturieren diese. Mit Klassendiagrammen lassen sich Testdaten erzeugen und außerdem kann getestet werden, ob ein Attribut einer Obejtkinstanz nach einer Operation einen erlaubten Wert hat.
• Aktivitätsdiagramme - Diese beschreiben das gewünschte Verhalten eines meist abgeschlossenen Anwendungsfalles. Hier wird ein funktionaler Test durchgeführt, das interne Verhalten ist nicht relevant. Aktivitätsdiagramme sind also ein adequates Mittel für Black Box Tests. Aktivitätsdiagramme haben immer einen definierten Start- und Endzustand, sie sind also endlich.
• Zustandsautomaten - Beschreiben das Verhalten meist einer spezifischen Komponente, jedoch ohne Start- oder Endzustand, er ist daher unendlich. Hier werden die internen Zustände modelliert, daher handelt es sich hierbei um geeignete Modelle für den White Box Test.

Testmodelle sind notwendig, da die Systemmodelle im Allgemeimen nicht ausreichende Informationen für erfolgreiche Tests enthalten. So kann z.B. das Verhalten des Systems gegen Fehler überprüft werden, Systemmodelle enthalten zumeist nur das Verhalten im Positivfall. Über ein Testmodell können auch konkrete Testdaten erzeugt werden, Systemmodelle beinhalten nur die abstrakten Klassen, selten jedoch konkrete Objekte. Außerdem kann über Testmodelle das eigentliche Systemmodell ebenfalls validiert und auf Korrektheit überprüft werden. Zur Modellierung von Testmodellen wird häufig das UML Testing Profile verwendet, welches erweiterte Elemente enthält, die speziell auf Testmodellierung zugeschnitten sind.^[75].

7.3.2 Modelle erweitern

Zum Erstellen der Modelle kann ein spezifisches UML Profil, das UML Testing Profile (UTP) verwendet werden. Dieses UML Profil ist gedacht, um Artefakte von Testsystemen zu entwerfen, visualisieren und dokumentieren. Das UTP beruht auf den UML 2.0 Spezifikationen, es handelt sich hierbei um eine Erweiterung dieser Spezifikation^[76].

Das UTP ist strukturiert in vier logische Konzeptgruppen, welche das UML Standardardprofile ergänzen und die Einsatzmöglichkeiten der UTP somit festlegt:^[78]:

• Test Architecture - Mithilfe des Konzeptes der Test Achitecture werden die spezifischen Elemente beschrieben, die für die Testfälle benötigt werden. Diese Komponenten können implementierte Schnittstellen (Arbiter oder Scheduler) sein, ein System under Test (SUT) für Black Box Tests oder spezielle Test Elements.
• Test Behavior - Hiermit wird das Verhalten der einzelnen Testfälle spezifiziert, wobei Inhalte dieses Konzeptes u.A. das Verdict (Testaussage, ob der Test bestanden worden ist oder nicht) beinhaltet sowie Test Utilities, notwendige Test Logs und weitere Testverhalten relevante Inhalte.
• Test Data - Mit dem Test Data Konzept können Testdaten beschrieben werden. Es enhält u.A. Wildcards, Data Pools oder Coding Rules für die Spezifikation von Testdatenübertragung.
• Time Concepts - Time Concept erweitern die UML um spezifische Zeitkonzepte wie Timer, Timeouts oder Timezones.

Das W-Modell in Abbildung 9, einer Erweiterung des häufig in der Praxis der Softwareentwicklung verwendeten V-Modell, gibt an, zu welchen Phasen der Entwicklung schon Testaktivitäten durchgeführt werden. Testaktivitäten beginnen hier als paralleler Prozess zur Softwareentwicklung, so werden z.B. bereits bei der Ermittlung von Anforderung und deren Modellierung erste Testfälle beschrieben oder modelliert^[79]. Da hier Testmodelle bereits in der Entwicklungsphase erstellt werden, können über die Testmodelle die Systemmodelle auf ihre Korrektheit überprüft werden, da die Testmodelle von den Systemmodellen abgeleitet sind.

Die in der Entwicklungsphase erstellten Systemmodelle bilden nun die Basis für die Testmodelle. Hierbei können die Systemmodelle einmalig als Testmodelle übernommen werden, wobei bei jeder Änderung der Systemmodelle eine Anpassung der Testmodelle erforderlich ist. Dies kann auch durch einen zyklischen Abgleich der System- und Testmodelle, welcher automatisiert oder halb-automatisiert durchgeführt wird, geschehen. Die möglichen Umsetzungen hierbei sind in der folgenden Tabelle aufgeführt.

	Einmalige Übernahme der Testmodelle	Zyklischer Modellabgleich
Variante 1	Übernahme des Systemmodells in das Testmodell durch einen manuellen Kopiervorgang. Das Testmodell ist hierbei ein Auszug aus den gewünschten Elementen des Systemmodell. Änderungen am Systemmodell müssen später bei Bedarf manuell im Testmodell nachgearbeitet werden.	Hierbei sind System- und Testmodell unterschiedliche Sichten genau eines Modelles. Um dieses zu erreichen, können Notizen oder Stereotypen verwendet werden, um für ein Element die Sicht zu definieren. Viele UML Werkzeuge können dann über Filter lediglich die korrekte Sicht ausgeben, die gerade benötigt werden. Änderungen am Systemmodell müssen auch dann nicht manuell in das Testmodell nachgearbeitet werden.
Variante 2	Durch spezielle Werkzeuge und Transformationssprachen wird ein Systemmodell in ein Testmodell transformiert. Basis der Transformation ist das Metamodell, welches Regeln für alle UML Modelle vorgibt. Bei der Transformation können bereits bestimmte Diagramme um für das Testmodell notwendige Elemente angereichert werden. Kommt es zu Änderungen am Systemmodell, müssen diese ebenfalls im Testmodell angepasst werden.	Die beiden Modelle, das System- und das Testmodell, sind über uni- oder bidirektionale Traces, also Verknüpfungen, verbunden. Kommt es dabei zu Änderungen, können diese direkt in das Testmodell verfolgt werden und dort nachgearbeitet werden. Es können sogar direkt Testfälle automatisiert abgeleitet werden. Bei bidirektionalen Traces können auch die Ergebnisse aus Tests, welche auf dem Testmodell basieren, direkt zu den entsprechenden Änderungen im Systemmodell führen. Jedoch müssen die Modelle anfangs angelegt werden und mit Traces versehen werden.

Tabelle 2^[80] - Übersicht der Übernahme der Systemmodelle in Testmodelle

7.3.3 Testfälle generieren

Werden im Softwareentwicklungsprozess konsequent Modelle eingesetzt, so lassen sich aus diesen Modell Testfälle automatisiert generieren. Der Grad der Automatisierung und die entsprechende Abdeckung ist hier immer Abhängig der verwendeten Tools. Einen hohen Grad an Automatisierung bieten hier Modellbasierte Testfallgeneratoren. Nach Goetz handelt es sich dabei um "[...] Werkzeuge, die basierend auf einem Modell des Systemverhaltens, der Systemumgebung oder der Tests sowie bestimmter Steuerinformationen Testfälle bzw. Testskripte oder sogar ganze Testsuiten automatisch nach konfigurierbaren Abdeckungskriterien erzeugen."^[81].

Die Testfälle können bei solchen Tools per Knopfdruck erzeugt werden, hierbei wird das Sollverhalten des zu testenden Systemes als Testfall erzeugt. Mögliche UML Modelle und ihre Elemente sind hierbei^[82]:

• Klassen
• Objekte
• Kompositionsstruktur
• Aktivitäten
• Zustandsübergänge
• Sequenzen

Dies ist jedoch abhängig des verwendeten Generierungstools, das obige Beispiel stellt die möglichen UML Elemente des Tools Rhapsody Automatic Test Generator der Firma IBM/Telelogic dar. Die UML Modelle finden sich im Testmodell wieder. In den Testmodellen können sowohl das Sollverhalten des zu testeten Systems modelliert werden als auch das Verhalten im Fehlerfalle.

Auch Testdaten für die Testfälle können erzeugt werden. Hierbei können z.B. die Aufrufreihenfolge von Methoden durch Sequenzdiagramme modelliert und daraus entsprechende Testskripe erzeugt werden. Diese Testskripte enthalten auch Sollwerte für die Methodenaufrufe^[83]. Je nach verwendetem Werkzeug können die automatisch erstellten Testfälle / Testskripte nun manuell durch Tester abgearbeitet werden oder sogar zur automatisierten Testdurchführung verwendet werden.

Die generierten Testfälle können auch bereits in für das automatisierten Testen geeigneten Testsprachen als Testskript ausgegeben werden, z.B. in TCL oder TTCN-3.

7.3.4 Testfälle ausführen

Die Testfälle und Testskripte, die bereits automatisiert erzeugt worden sind, können als Grundlage für eine Automatisierung der Testdurchführung herangezogen werden. Um das SuT nun Tests zu unterziehen müssen die Testskripte ggf. noch angepasst werden. Hierbei muss das Testskript mit Informationen angereicht werden, um z.B. die Schnittstellen des zu testenden Systems mit Daten beliefern zu können. Anhand des Beispieles in Abbildung 10 werden hierbei Adapter verwendet. Diese Adapter senden Nachrichten an das SuT und empfangen Nachrichten vom SuT. Die Adapter sind auf der anderen Seite an das Testautomatisierungstool angebunden und werden durch die spezifischen Testfälle angesprochen.

Ein Testfall muss inhaltlich aus Eingabewerte, Sollergebnis sowie definierte Vor- und Nachbedingungen bestehen^[85]. Diese Informationen müssen also in den zur Testautomatisierung vorgesehen Testskripte enthalten sein.

Werden die Tests automatisiert durchgeführt, ist die in Kapitel 6.2 kritisch angemerkte Menge der Testfälle bei automatisierter Testfallgenerierung auch ein geringeres Problem, da die automatisierten Testfälle nachts oder am Wochenende als so genannte "Lights-out-Tests" durchgeführt werden können. Außerdem kann die bei der Automatisierung gewonne Zeit genutzt werden, detailliertere Testfälle durchführen zu können^[86].

Anhand der Informationen über das erwartete Sollergebnis und das tatsächliche beim Test eingetreten Istergenis kann der Test durch das Testautomatierungstool ausgewertet werden und wird, wie in dem Beispiel in Abbildung 10, in einer Datenbank abgelegt. Viele Tools bieten hier auch die Unterstützung, das die Ergebnisse als Report direkt ausgegeben werden.

Auch wenn der Automatisierungsgrad beim MBT recht hoch ist, so darf nicht vergessen werden, das spätestens bei der Testautomatisierung ein wichtiger Anteil innerhalb der Testskripte programmiert werden muss^[87]. Hier müssen die Adapter speziell für das SuT entwickelt werden. Im fundamentalen Testprozess ist hier die Rolle des Testautomatisierers vorgesehen, wenn dies nicht durch den Testdesigner durchgeführt werden kann^[88].

8 Bewertung

Im folgenden Kapitel wird eine Bewertung der zuvor dargelegten Sachverhalte vorgenommen.

8.1 Vorteile

Zeitersparnis durch Automatisierung	Generierung von Testfällen aus bestehenden Modellen und automatisierte Durchführung dieser (Vgl. Kapitel 7.3)
Höhere Produktqualität auf Grund intensiverer Tests	durch automatisierte Generierung und Durchführung der Testfälle können mehr Tests abgearbeitet werden (Vgl. Kapitel 7.3.4)
Kostenersparnis durch frühe Fehlererkennung	Da auf Basis von Modellen getestet wird, können diese schon vor der Erstellung des Quellcodes überprüft werden. Werden Fehler in der Konzeptionsphase gefunden, sind diese Kostengünstiger zu beheben als in späteren Phasen. (Vgl. Kapitel 5.1.4)
Eindeutige Testfälle und Ergebnisse	Da eine genormte Noation (bspw. UML) verwendet wird, ist die Darstellung von Testfällen und Ergebnissen eindeutig (Vgl. Kapitel 6.1)

Tabelle 3 - Vorteile von modellbasiertem Test

8.2 Nachteile

Komplexe Tools	durch den hohen Funktionsumfang und den großen Konfigurationsaufwand um automatisierte Testfallerstellung und -durchführung möglich zu machen, sind modellbasierte Testtools sehr komplex (Vgl. Kapitel 7.1.2 & 7.3)
Erhöhter Programmieraufwand beim Testen	um die Anbindung des Testaufbaus zum SuT zu gewährleisten müssen häufig Adapter erstellt werden. (Vgl. Kapitel 7.3.4)
Abhängigkeit vom Testtool	Durch einen hohen Automatisierungsgrad und den unterschiedlichen Herangehensweisen der verschiedener Tools an diese Automatisierung werden Prozesse unweigerlich auch auf diese abgestimmt. (Vgl. Kapitel 7.1.2)
Stark veränderte Anforderungen an Personal	Statt vornehmlich fachliche Qualifikationen benötigen Tester bei einem modellbasiertem Vorgehen viel mehr Kenntnisse über UML-Modelle und Testautomatisierungssprachen (Vgl. Kapitel 7.1.3)
Gewisse Prozessreife muss gegeben sein	durch intensivere Tests werden auch mehr Fehler gefunden. Der Entwicklungsprozess muss diese auch aufnehmen und verwalten können. (Vgl. Kapitel 6.2)

Tabelle 4 - Nachteile von modellbasiertem Test

9 Fazit

Modellbasiertes Testen bildet keine eigenständige Gruppe innerhalb der Testtechniken. "Praktisch alle systematischen Testtechniken basieren auf mehr oder weniger expliziten Modellen und können deshalb als modellbasierte Ansätze verstanden werden".^[89]

MBT ist viel mehr ein Ansatz, der viele Teile vom fundamentalen Testprozess, mit detaillierten und speziellen Modellen realisiert. Es wird also zunächst nur nach Modellen getestet. Dies bedingt ein neues Anforderungsprofil der Tester, führt aber auch wegen der meist normierten Notation zu einem einheitlichen Verständnis des Softwaresystems bei allen beteiligten. Da Modelle schon in der Konzeptionsphase erstellt werden, können diese auch sehr früh im Entwicklungsprozess getestet und ggf. korrigiert werden. Dies beugt Fehlern in der Realisierungsphase vor, die unter Umständen nur unter hohem Aufwand zu korrigieren sind. Somit wird schon früh im Entwicklungsprozess der Grundstein für eine hohe Softwarequalität gelegt. (Vgl. Kapitel 5.1.4, 6.1 und 7.1.3)

Zusätzlich bietet die normierte Notation eine ideale Grundlage um die Tests zu automatisieren. Die Möglichkeiten, den Test durch Automatisierung zu unterstützen, reichen hierbei vom einfachen Generieren der Testdaten aus den Modellen heraus, bis hin zum komplett autonomen Generieren der Testfälle oder Testsuiten über das Ausführen und anschließende Dokumentieren der erstellten Testfälle. Hierbei ist allerdings zu beachten, dass an dieser Stelle ein automatisiertes Vorgehen auch eine sehr große menge an Testfellen generiert. Auch wenn eine ebenfalls automatisierte Ausführung der Testfälle per "Lights-Out-Tests" im Vergleich zu komplett manuell durchgeführten Testfällen in der selben Zeit mehr Tests schafft, so ist die gesamte Zeit, die für die Tests zur Verfügung steht, sehr begrenzt. Deshalb ist auch hier eine Vorauswahl der durchzuführenden Tests notwendig um die kritischen Systemteile ausreichend intensiv zu testen. Darüber hinaus werden bei mehr durchgeführten Tests auch mehr Fehler gefunden. All diese Fehler müssen auch durch Tester bewertet und durch Entwickler behoben werden. Hier gilt es die Testendekriterien sorgfältig auszuwählen, da zu ehrgeizige Testaktivitäten die Projektzeitpläne gefährden können. Auch sollte im Fehlermanagement sorgfältig ausgewählt und priorisiert werden, welche Fehler wann gefixed werden, um einen stabilen Betrieb gewährleisten zu können.(Vgl. Kapitel 7.3)

Um diese Art des modellbasierten Testens auch erfolgreich praktizieren zu können, muss das passende Testwerkzeug gewählt werden. Hierbei gilt es zu beachten, dass ein Tool ausgewählt wird, welches möglichst gut auf den eigenen Testprozess passt. Gibt es kein Tool, welches dem Testprozess entspricht, kann die Entwicklung einer Individualsoftware in Auftrag gegeben werden. Diese Art von Software ist allerdings sehr kostenintensiv. Eine andere Möglichkeit ist es, den Testprozess auf ein bestimmtes Tool abzustimmen. Das gewählte Tool soll dem aktuellen Prozess dabei schon sehr nahe liegen, um zu große Umstellungen zu vermeiden. Welches Vorgehen auch gewählt wird, ist ein späterer Umstieg auf ein anderes Tool kostspielig, da diese im allgemeinen sehr unterschiedlich arbeiten. Es wird also eine gewisse Abhängigkeit erzeugt. Zusätzlich sind die zur Verfügung stehenden Tools oft komplexe Produkte deren korrekte Bedienung nur durch entsprechend geschultes Personal zu bewerkstelligen ist.(Vgl. Kapitel 7.1.2, 7.1.3 und 7.3)

Wird der automatisierende Ansatz allerdings konsequent umgesetzt, so erhält man ein Testsystem welches in der Lage ist, ein sich veränderndes Softwaresystem auf Knopfdruck durchgängig zu testen. Doch egal wie intensiv ein System auch getestet wird, eines wird immer gelten: "Solange der Mensch Software schreibt, wird die Software mit Fehlern behaftet sein, unabhängig davon, in welcher Sprache bzw. auf welcher semantischen Ebene er seine Gedanken zum Ausdruck bringt."^[90]

10 Fußnoten

1. ↑ Sneed, H. et al. (2002), S. 3
2. ↑ Vgl. Vigenschow, U. (2005), S. 3
3. ↑ Entnommen aus: Baker, P. et al. (2008), S. 8
4. ↑ Vgl. Spillner, A. et al. (2007), S. 9
5. ↑ Vgl. Craig, R. et al. (2002), S. 2ff.
6. ↑ Vgl. Pietrek, G. et al. (2007), S. 17f.
7. ↑ Vgl. DIN EN ISO 9000:2005
8. ↑ Vgl. Balzert, H. (2008), S. 475ff.
9. ↑ Vigenschow, U. (2005), S. 15.
10. ↑ Vgl. Spillner, A. et al. (2007), S. 8ff.
11. ↑ Vgl. Craig, R.D. et al. (2002), S. 159f.
12. ↑ In Anlehnung an: Hoffmann, W. (2008), S. 159
13. ↑ Vgl. Hoffmann, W. (2008), S. 159ff.
14. ↑ Vgl. Stachowiak, H. (1973), S. 131ff.
15. ↑ Vgl. Grässle, P. et al. (2007), S.27ff.
16. ↑ Vgl. Grässle, P. et al. (2007), S.29f.
17. ↑ Entnommen aus: OMG (2009), S. 686
18. ↑ Vgl. Roßner, T. (2009) S. 125
19. ↑ Vgl. Liggesmeyer, P. (2009) S. 215
20. ↑ Vgl. Alt, O. (2009) S. 29
21. ↑ Vgl. Vivenzio, A. (2010) S. 67
22. ↑ Vgl. Fajardo, J. et al. (2007) S. 340f.
23. ↑ Entnommen aus: Roßner, T. (2009), S. 127
24. ↑ Vgl. Spillner, A. et al. (2007) S. 9
25. ↑ Vgl. Vigenschow, U. et al. (2005) S. 23
26. ↑ Vgl. Grässle, P. et al. (2007) S. 26
27. ↑ Roßner, T. (2009) S. 126
28. ↑ In Anlehnung an: Götz, H. et al. (2009), S. 28
29. ↑ Vgl. Roßner, T. (2009) S. 126
30. ↑ Vgl. Roßner, T. (2009) S. 126
31. ↑ Vgl. Götz, H. et al. (2009), S. 31
32. ↑ Entnommen aus: Roßner, T. (2009), S. 127
33. ↑ Vgl. Roßner, T. (2009) S. 126
34. ↑ Vgl. Spillner, A. et al. (2007), S. 253
35. ↑ Vgl. Spillner, A. et al. (2007), S. 170f.
36. ↑ Vgl. Götz, H. et al. 2009 S. 319f.
37. ↑ In Anlehnung an: Rupp, C. et al. 2007 S. 103
38. ↑ Rupp, C. et al. 2007 S. 102
39. ↑ Vgl. Rupp, C. et al. 2007 S. 102
40. ↑ Vgl. Rupp, C. et al. 2007 S. 111f.
41. ↑ Vgl. Rupp, C. et al. 2007 S. 112
42. ↑ Vgl. Rupp, C. et al. 2007 S. 116f.
43. ↑ Vgl. Rupp, C. et al. 2007 S. 117
44. ↑ Vgl. Rupp, C. et al. 2007 S. 128
45. ↑ Vgl. Rupp, C. et al. 2007 S. 136f.
46. ↑ Vgl. Rupp, C. et al. 2007 S. 146
47. ↑ Vgl. Rupp, C. et al. 2007 S. 147
48. ↑ Vgl. Rupp, C. et al. 2007 S. 178
49. ↑ Vgl. Rupp, C. et al. 2007 S. 259f.
50. ↑ Vgl. Rupp, C. et al. 2007 S. 260
51. ↑ Vgl. Rupp, C. et al. 2007 S. 274ff.
52. ↑ Vgl. Rupp, C. et al. 2007 S. 269f.
53. ↑ Vgl. Rupp, C. et al. 2007 S. 276f.
54. ↑ Vgl. Rupp, C. et al. 2007 S. 287ff.
55. ↑ Vgl. Rupp, C. et al. 2007 S. 283
56. ↑ Vgl. Rupp, C. et al. 2007 S. 329
57. ↑ Vgl. Rupp, C. et al. 2007 S. 230
58. ↑ Vgl. Rupp, C. et al. 2007 S. 333ff.
59. ↑ Vgl. Götz, H. et al. (2009) S. 40ff.
60. ↑ Vgl. Götz, H. et al. (2009) S. 45.
61. ↑ Vgl. Spillner, A. et al. (2007) S. 1ff.
62. ↑ Vgl. Götz, H. et al. (2009) S. 336
63. ↑ In Anlehnung an: Spillner, A. et al. (2007) S. 20
64. ↑ Vgl. Spillner, A. et al. (2007) S. 19f.
65. ↑ Vgl. Spillner, A. et al. (2007) S. 20f.
66. ↑ Vgl. Spillner, A. et al. (2007) S. 21f.
67. ↑ Vgl. Spillner, A. et al. (2007) S. 22
68. ↑ Vgl. Spillner, A. et al. (2007) S. 23
69. ↑ Vgl. Spillner, A. et al. (2007) S. 23
70. ↑ Vgl. Spillner, A. et al. (2007) S. 26
71. ↑ Vgl. Spillner, A. et al. (2007) S. 27ff.
72. ↑ Vgl. Spillner, A. et al. (2007) S. 29ff.
73. ↑ Vgl. Spillner, A. et al. (2007) S. 32
74. ↑ Vgl. Roßner, T. (2009) S. 125
75. ↑ Vgl. Götz, H. et al. (2009) S. 24ff.
76. ↑ Vgl. OMG (2005), S. 1
77. ↑ Entnommen aus: Baker, P. et al. (2008), S. 9
78. ↑ OMG (2005), S. 9ff.
79. ↑ Vgl. Roitzsch, P. (2005), S. 463
80. ↑ Vgl. Götz, H. et al. (2009) S. 26
81. ↑ Götz, H. et al. (2009) S. 45
82. ↑ Vgl. Götz, H. et al. (2009) S. 274
83. ↑ Vgl. Spillner, A. et al. (2007) S. 207
84. ↑ In Anlehnung an: Götz, H. et al. (2009), S. 149
85. ↑ Vgl. Spillner A. et al. (2007), S 37
86. ↑ Vgl. Braess, H. et. al. (2005), S. 602
87. ↑ Vgl. Vigenschow, U. (2005), S. 160
88. ↑ Vgl. Spillner A. et al. (2007), S 170
89. ↑ Liggesmeyer, P. (2009) S. 215
90. ↑ Sneed, H. et al. (2002), S. 3

11 Quellenverzeichnis

Alt (2009)	Alt, Oliver: Car Multimedia Systeme Modell-basiert testen mit SysML, 1. Auflage, Vieweg+Teubner GWV Fachverlage GmbH, Wiesbaden 2009
Baker (2008)	Baker, Paul; Dai, Zhen Ru; Grabowski, Jens; Haugen, Øystein; William, Clay: Model-Driven Testing: Using the UML Testing Profile, Springer Verlag, Berlin, Heidelberg 2008
Balzert (2008)	Balzert, Helmut: Lehrbuch der Softwaretechnik: Softwaremanagement, 2. Auflage, Spektrum Akademischer Verlag, Heidelberg 2008
Braess (2005)	Braess, Hermann; Seiffert, Ulrich: Vieweg Handbuch Kraftfahrzeugtechnik, 4. überarbeitete und erweiterte Auflage, Friedr. Vieweg & Sohn Verag / GWV Fachverlage GmbH, Wiesbaden 2005
Craig (2002)	Craig, Rick D.; Jaskiel, Stefan P.: Systematic Software Testing, Artech House Inc, Boston u.A. 2002
Fajardo (2007)	Fajardo, Jose; Dustin, Elfriede: Testing SAP R/3 - A Manager's Step-By-Step Guide, John Wiley & Sons Inc., New Jersey, 2007
Grässle (2007)	Grässle, Patrick; Baumann, Henriette; Baumann, Philippe: UML 2 projektorientiert, 4. aktualisierte Auflage, Galileo Press, Boston 2007
Götz (2009)	Götz, Helmut; Nickolaus Markus; Roßner Thomas; Salomon Knut: iX Studie Modellbasiertes Testen Modellierung und Generierung von Tests- Grundlagen, Kriterien für Werkzeugeinsatz, Werkzeuge in der Übersicht, Heise Zeitschriften Verlag GmbH & Co KG, Hannover 2009
Hoffmann (2008)	Hoffmann, Dirk: Software-Qualität, Springer Verlag, Berlin, Heidelberg 2008
Liggesmeyer (2009)	Liggesmeyer, Peter: Software-Qualität: Testen, analysieren und verifizieren von Software, 2. Auflage, Spektrum Akademischer Verlag, Heidelberg 2009
OMG (2005)	Object Management Group: UML Testing Profile, Version 1.0, o.V., o.O., 2005
OMG (2009)	Object Management Group: OMG Unified Modeling LanguageTM (OMG UML), Superstructure, Version 2.2, o.V., o.O., 2009
Pietrek (2007)	Pietrek, Georg; Trompeter, Jens; Flores Beltran, Juan Carlos; Holzer, Boris; Kamann, Thorsten; Kloss, Michael; Mork, Steffen A.; Niehues, Benedikt; Thoms, Karsten: Modellgetriebene Softwareentwicklung: MDA und MDSD in der Praxis, entwickler.press, o.O. 2007
Roitzsch (2005)	Roitzsch, E.H. Peter: Analytische Softwarequalitätssicherung in Theorie und Praxis, Verlagshaus Monsenstein und Vannerdat OHG, Münster 2005
Roßner (2009)	Roßner, Thomas: Von höherer Ebene - Modellbasiertes Testen - eine Einführung in: iX Magazin für professionelle Informationstechnik, 11/2009, S. 125 - 130
Rupp (2007)	Rupp, Chris; Queins, Stefan; Zengler, Barbara: UML 2 Glasklar, 3. aktualisierte Auflage, Carl Hanser Verlag, München 2007
Sneed H. (2002)	Sneed, Harry M.; Winter, Mario: Testen objektorientierter Software: Das Praxishandbuch für den Test objektorientierter Client/Server-Systeme, Carl Hanser Verlag, München, Wien 2002
Spillner A. (2007)	Spillner, Andreas; Linz, Tilo: Basiswissen Softwaretest, 3. korrigierte Auflage, dpunkt.verlag GmbH, Heidelberg 2007
Stachowiak (1973)	Stachowiak, Herbert: Allgemeine Modelltheorie, Springer Verlag Wien, New York 1973
Vigenschow (2005)	Vigenschow, Uwe: Objektorientiertes Testen und Testautomatisierung in der Praxis: Konzepte, Techniken und Verfahren, 1. Auflage, dpunkt.verlag GmbH, Heidelberg 2005
Vivenzio A. (2010)	Vivenzio, Alberto: Testautomation mit SAP - SAP Banking erfolgreich einführen, 1. Auflage, Vieweg+Teubner GWV Fachverlage GmbH, Wiesbaden 2010