<< zurück

MBSE Home

weiter >>

7.1 Testdaten und Sollergebnis mit Objektdiagrammen

Abbildung 7.1 zeigt den sich aus der in Abbildung 6.7 ergebenden Einsatz von zwei Objektdiagrammen zur Darstellung der Testdaten und des Sollergebnisses. Damit ein Objektdiagramm für mehrere Testfälle verwendet werden kann, sind gegebenenfalls kleinere Anpassungen für einen spezifischen Testfall notwendig. Deshalb ist es möglich, nach Aufbau der entsprechenden Objektstruktur zusätzlich Java-Code einzubauen.

Nach Ausführung des Testlings steht die Istdatenstruktur zur Verfügung und kann mit der durch das zweite Objektdiagramm vorgegebenen Solldatenstruktur verglichen werden. Zusätzliche Eigenschaften können durch OCL-Bedingungen geprüft werden. Dies können allgemein gültige OCL-Invarianten sein, die immer geprüft werden sollten, aber auch für den Test spezifische Bedingungen.

Einer der typischen im Auktionssystem verwendeten Testdatensätze besteht aus einem Objekt der Klasse AllData, mehreren Auktionen mit allen davon abhängigen Objekten, mehreren Personen, die in unterschiedlichen Situationen angemeldet sind, und einer Reihe von Nachrichten, die einigen offenen und abgelaufenen Auktionen zugeordnet sind. Von diesen Grundstrukturen sind nur relativ wenige Datensätze notwendig, denn durch Anpassung mit zusätzlichem Java-Code lassen sich diese für viele Testfälle wiederverwenden.

Auf dem in Abbildung 7.2 dargestellten Testdatensatz wird der Effekt der Methode zum Eröffnen einer Auktion start() durch das Sollergebnis (ausschnittsweise) in Abbildung 7.3 beschrieben.

Neben der als NoBidYet angegebenen OCL-Bedingung, die besagt, dass nach der Eröffnung noch kein Gebot abgegeben ist, existieren auch einzuhaltende Invarianten. Beispielsweise ist Bidders1 für Auktionen allgemeingültig:

OCL       context Auction a inv Bidders1:

a.activeParticipants <= a.bidder.size

und muss natürlich auch nach der Eröffnung einer Auktion gelten. Wird eine Codegenerierung für die beschriebenen Diagramme nach Kapitel 5 zugrunde gelegt, so kann ein Test mit der in Anhang B, Band 1 beschriebenen Java/P-Erweiterung wie folgt formuliert werden:

Java/P        testStart() {

Auktion a1213 = setupYetClosed();      // Testdaten erzeugen

a1213.start();                         // Test ausführen

ocl isStructuredAsRunning(a1213);      // Sollergebnis erfüllt?

ocl checkNoBidYet(a1213);              // Eigenschaft NoBidYet

ocl checkBidders1(a1213);              // Invariante Bidders1

ocl checkTime1(a1213);                 // weitere Invariante Time1

}

Die UML/P bietet eine eigenständige Dokumentart an, mit der diese Tests kompakter formuliert werden können:

Test       test Auction.start() {

testdata: OD YetClosed;

driver:   a1213.start();

assert:   OD Running; inv NoBidYet; inv Bidders1; inv Time1;

}

Um die Fähigkeiten der beiden oben beschriebenen Frameworks JUnit und VUnit richtig zu nutzen, ist allerdings eine angepasste Codegenerierung für die prädikative Abfrage isStructuredAs auf Basis von Objektdiagrammen und check für OCL-Bedingungen sinnvoll. Dabei entsteht nicht nur eine boolesche Aussage, sondern im Fehlerfall eine bei JUnit übliche Beschreibung des Istergebnisses, die idealerweise den Namen der verletzten OCL-Bedingung beziehungsweise Namen und Inhalt des vom Sollergebnis abweichenden Objekts und Attributs beschreibt.

In Abbildung 7.3 wurde das Sollergebnis ebenso detailliert dargestellt wie die Testdaten. Dies muss im Allgemeinen nicht der Fall sein. Während das Objektdiagramm zur Bereitstellung der Testdaten eine gewisse Vollständigkeit benötigt, um damit konstruktiv Objektstrukturen bilden zu können, muss das Sollergebnis nur den Teil der Objektstruktur darstellen, der für den behandelten Testfall von Interesse ist. Dabei können einzelne Attribute ausgelassen aber auch abgeleitete Attribute eingesetzt werden. Fehlt im Sollergebnis eine Teilstruktur der Objekte, so bedeutet das entsprechend der Semantik eines Objektdiagramms nicht, dass diese im Istergebnis zu löschen war, sondern dass ihre tatsächliche Form nicht von Interesse ist.

Durch ein Hinzufügen des Stereotyps ≪complete≫ aus Tabelle 5.15 kann gefordert werden, dass das Objektdiagramm als vollständige Beschreibung einer Objektstruktur inklusive aller Links verstanden wird. Der Vergleich ist dann, wie in Abschnitt 5.2 beschrieben, wesentlich restriktiver. Allerdings müssen in diesem Objektdiagramm auch alle Attributwerte angegeben werden.

Die in Abschnitt 4.3, Band 1 diskutierte Kombinierbarkeit von Objektdiagrammen, die durch OCL-Logikoperatoren gesteuert wird, kann bei der Modellierung von Testdaten und von Sollergebnissen hilfreich zur Modularisierung eingesetzt werden. Nach dem in Abschnitt 5.2 diskutierten Verfahren können Objektdiagramme kombiniert und damit die Gesamtstruktur der Testdaten aus mehreren Einzeldiagrammen zusammengesetzt werden. Bei der Definition des Sollergebnisses kann die in Kapitel 4, Band 1 diskutierte, sehr flexible Kombinierbarkeit von Objektdiagrammen mithilfe der OCL-Operatoren genutzt werden. Dabei kann zum Beispiel mit negierten Objektdiagrammen geprüft werden, dass eine bestimmte Situation nicht auftritt.

Der hier vorgeschlagene Weg zur Modellierung von Testfällen mit der UML findet sich in Ansätzen auch in [CCD02] wieder, wo ebenfalls Objektdiagramme zur Modellierung von Testdaten eingesetzt werden. Dort werden mehrere Stereotypen vergeben, um im Objektdiagramm direkt zu markieren, wofür es eingesetzt werden soll, wodurch jedoch die Wiederverwendbarkeit für verschiedene Zwecke sinkt.

Die Verwendung von Objektdiagrammen wird in Kapitel 8 anhand von Testmustern detailliert demonstriert.

Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012

<< zurück

MBSE Home

weiter >>