Testfälle als regelbasierte Programme Spezifikation der Testfälle
5 Spezifikation objektorientierter Testfälle
5.7 Einfluss der UML auf die Testfallspezifikation
5.6.3 Unterschiede beim funktionsbezogenen Test
Beim funktionsbezogenen Test sind die Unterschiede zwischen konventionellen und objektorientierten Systemen am geringsten – beide liefern die gleichen Ergeb-nisse ab. An der Benutzungsoberfläche in den Listen und in den Exportdaten unter-scheiden sich die Systemarten nicht voneinander. Ein Unterschied besteht nur darin, wie interne Ergebnisse erzeugt werden. Auf der Methodenebene werden Rückga-bewerte erzeugt, auf der Klassenebene werden Objektzustände erstellt und auf der Komponentenebene werden Ausgangsnachrichten gesendet. Hier wird wohl eine ausführliche UML-Objektspezifikation ergänzt durch eine IDL-Schnittstellen-spezifikation erforderlich sein, um die Ergebnisse zu erkennen und auf ihren Ur-sprung zurückzuführen. Je tiefer die Vererbungshierarchien und je länger die Ope-rationsaufrufketten, umso schwieriger ist es, die Entstehung eines bestimmten Er-gebnisses zurückzuverfolgen. Der Hauptunterschied liegt also hier in der Komplexi-tät der Architektur, die es schwer macht, FunktionaliKomplexi-tät zu isolieren und getrennt für sich zu bestätigen.
5.7 Einfluss der UML auf die Testfallspezifikation
Natürlich besteht eine Verbindung zwischen der Spezifikation der Programme und der Spezifikation der Testfälle. Es sind die zwei Seiten derselben Medaille – auf der einen Seite die Hypothese, es sollte so funktionieren, auf der anderen Seite die Beweisführung, dass es wirklich so funktioniert. Die Sprache, in der die Hypothese formuliert wird, hat zwangsläufig Einfluss auf die Formulierung der Beweisfüh-rung. Die eine Semantik bedingt die andere.
Objektorientierte Software wird zunehmend mit Hilfe der „Unified Modelling Lan-guage“ – UML – spezifiziert. Diese Entwurfssprache ist eine graphische Beschrei-bung der eigentlichen Software [OMG99]. Sie setzt sich zusammen aus einer Reihe Diagrammtypen, die verschiedene Sichten auf das geplante oder bereits implemen-tierte System darstellen (Abbildung 5.14). Dazu gehören (vgl. z.B. [Fow98]):
• das Anwendungsfalldiagramm
• das Klassendiagramm
• das Sequenzdiagramm
• das Kollaborationsdiagramm
• das Aktivitätsdiagramm
• das Zustandsdiagramm
• das Komponentendiagramm
• das Verteilungsdiagramm.
Hinzu kommt die Object Constraint Language – OCL –, mit der Zusicherungen bzw. Verarbeitungsregeln ausgedrückt werden können [WaKl99].
Anwendungsfall-diagramm
Komponenten-diagramm
Kollaborations-diagramm
Klassen-diagramm
Zustands-diagramm
Sequenz-diagramm
Aktivitäts-diagramm
Integrationstestfälle Klassentestfälle Systemtestfälle
Abbildung 5.14 Ableitung der Testfälle aus UML
5.7.1 Anwendungsfalldiagramm
Das Anwendungsfalldiagramm (use case diagram) beschreibt die Interaktion zwi-schen den Benutzern des Systems und dem System selbst. Es zeigt, welche Ereig-nisse von wem ausgelöst werden und wie sie miteinander zusammenhängen. Diese Diagramme eignen sich als Basis für die Spezifikation funktionaler Testfälle im Systemtest, aber nur wenn die Vor- und Nachbedingungen der einzelnen Fälle spe-zifiziert sind. Ist dies der Fall, sind sie eine nützliche Basis für die Ermittlung der Systemtestfälle. Außerdem lassen sich die Systemtestszenarien aus ihnen ableiten.
5.7.2 Klassendiagramm
Das Klassendiagramm (class diagram) beschreibt die Generalisierungshierarchien und Assoziation der Klassen sowie die Attribute und Methoden der einzelnen Klas-sen. Es kann als wichtige Unterlage sowohl für den Klassentest als auch für den Klassenintegrationstest dienen. Daraus lässt sich die Information für einen Klassen-testrahmen ableiten, insbesondere die anzustoßenden, in der Klasse selbst definier-ten Operationen und die zu simulierenden, in anderen Klassen definierdefinier-ten Operatio-nen. Für den Integrationstest deuten sie auf Assoziationen zwischen Klassen sowie auf Generalisierungen.
Assoziationen können als Aggregation und Komposition markiert werden. Bei einer Aggregation können Instanzen der „Teileklasse“ auch ohne eine Instanz der „Gan-zesklasse“ existieren, bei einer Komposition erzwingt das Zerstören der Ganzes-Instanz auch das der Teile-Ganzes-Instanzen. Diese Integritätsregeln lassen sich durch
Test-5.7 Einfluss der UML auf die Testfallspezifikation ____________________________151
fälle bestätigen. Die Enden der Assoziationen sind mit Multiplizitäten markiert, die angeben, wie viele Instanzen der dem jeweiligen Assoziationsende zugeordneten Klasse gemäß der Assoziation miteinander verbunden können. Multiplizitäten wer-den in der Form 0:1, 1:N und M:N angegeben, wobei die Multiplizität 0..N bei nicht näher spezifiziertem N auch zu * abgekürzt notiert werden kann. Die Enden der Assoziationen bestimmen somit die Kardinalität der Menge gemäß der Assozia-tion verbindbarer Instanzen. Diese Kardinalität kann bedingt oder unbedingt sein.
Daraus lassen sich etliche Integritätsregeln ableiten, wie z.B. kein Konto ohne Kon-toinhaber und kein KonKon-toinhaber mit nicht mindestens einem Konto. Diese aus den Klassendiagrammen abgeleiteten Integritätsregeln können ohne weiteres in Testfäl-le umgesetzt werden, um die Objektintegrität zu prüfen. Es fehTestfäl-len jedoch die Ver-arbeitungsregeln, die man braucht, um die Methoden zu testen.
5.7.3 Sequenzdiagramm
Das Sequenzdiagramm (sequence diagram) beschreibt die Ausführungsfolge der Operationen über Objektgrenzen hinweg. Damit werden die funktionalen Pfade durch die Objekte aufgezeichnet. Diese funktionalen Pfade entsprechen den Testfäl-len des Integrationstests. Ein Testfall, der mehrere Objekte „durchkreuzt“, müsste 1:1 mit einem Pfad durch das Sequenzdiagramm übereinstimmen. D.h. es sollte möglich sein, die statischen Sequenzdiagramme durch Tabellen, die nach entspre-chender Instrumentierung während des Klassenintegrationstests generiert werden (test traces), nachträglich dynamisch abzubilden. Demnach braucht der Tester nur die beiden Operationsfolgen miteinander abzugleichen. Was fehlt, sind die Bedin-gungen, unter denen die Kontrollübergaben stattfinden. Der Tester muss noch für jeden Pfad durch das Sequenzdiagramm sämtliche Pfadprädikate definieren, die zu erfüllen sind, um diesen Pfad anzusteuern. Aus dem Grund kann das Sequenzdia-gramm nur als Verifikationsmittel verwendet werden, d.h. zu kontrollieren, ob alle darin angezeigten Objektfolgen tatsächlich ausgeführt wurden.
5.7.4 Kollaborationsdiagramm
Das Kollaborationsdiagramm (collaboration diagram) beschreibt die Interaktion zwischen Objekten bzw. die fremden Operationsaufrufe. Diese Darstellung ist für die Planung und Spezifikation der Integrationstestfälle nützlich, denn beim Integra-tionstest kommt es darauf an, sämtliche interne Schnittstellen zwischen verteilten Objekten zu testen. Hier ist jede Schnittstelle zu jeder fremden Operation festgehal-ten. Hinter jeder solchen Schnittstelle stecken eine Menge von Testfällen, und zwar eine für jede Kombination von Parametern bzw. für jede relevante Kombination.
Das Kollaborationsdiagramm ist somit nützlicher als das Sequenzdiagramm, weil es
nicht nur auf eine Kontrollfluss-Übergabe zwischen Klassen verweist, sondern jeden einzelnen Operationsaufruf mit Parameterliste sowie die Art der Verbindung, über die der Operationsaufruf „geleitet“ wird, beschreibt. Trotzdem bietet es nur einen Anhaltspunkt für den Tester. Die Parameterwerte und Rückgabewerte selbst muss der Tester noch ausarbeiten.
5.7.5 Aktivitätsdiagramm
Das Aktivitätsdiagramm (activity diagram) kann benutzt werden, um drei unter-schiedliche Flussarten zu beschreiben:
• Steuerfluss
• Datenfluss und
• Prozessfluss.
Welche Flussart gemeint ist, geht meistens aus der Darstellung hervor. Klar abge-grenzte Bereiche der Aktivitätsdiagramme werden in der Literatur als Schwimm-bahnen bezeichnet. Zu jeder Schwimmbahn gehört mindestens ein Testfall. Da jedoch Schwimmbahnen bekanntlich sehr breit sein können, werden in der Regel mehrere gebraucht, um alle möglichen Verzweigungen abzudecken. Die Mehrdeu-tigkeit dieser Diagrammart macht das Leben der Tester schwer. Man könnte alles und nichts darunter verstehen. Auf der positiven Seite können Aktivitätsdiagramme dazu dienen, den Zusammenhang zwischen nebenläufigen Pfaden durch die Objekte und Komponenten zu spezifizieren. In dieser Hinsicht erfüllen sie den gleichen Zweck wie Petrinetze. Daraus lassen sich technische Testfälle für den Test der Transaktionen im Netz ableiten. Hier lässt sich feststellen, ob und wo „Deadlocks“
und andere Synchronisierungsprobleme auftreten können.
5.7.6 Zustandsdiagramm
Das Zustandsdiagramm (state diagram, state chart) beschreibt die möglichen Ob-jektzustände und deren Übergänge. Es ist das detaillierteste aller UML-Diagramme und am ehesten für die Spezifikation der Klassentestfälle geeignet, denn in ihm kommt die eigentliche Verarbeitungslogik zum Tragen. Sind Zustandsdiagramme formal, vollständig und konsistent, können aus ihnen automatisch Testfälle gene-riert werden (vgl. Abschnitt 6.5.4). Genau dies hat Robert Poston in einem auf ent-sprechend angereicherten Diagrammen basierten Testfallgenerierungswerkzeug gemacht [Pos94].
Für Testtheoretiker erscheint dies als ideale Lösung. Es ist auch viel darüber ge-schrieben wurden. Leider werden in der Projektpraxis die Zustandsdiagramme
sel-5.7 Einfluss der UML auf die Testfallspezifikation ____________________________153
ten vollständig ausgearbeitet, wenn überhaupt. Es bleibt nur der Code als Beschrei-bung der Verarbeitungslogik.
5.7.7 Komponentendiagramm
Das Komponentendiagramm (component diagram) beschreibt die Zuordnung der Klassen bzw. Objekte zu den Komponenten. Außerdem definieren sie die Schnitt-stellen zwischen Komponenten. In dieser Hinsicht sind sie eine unentbehrliche Grundlage für den Komponentenintegrationstest, wo es darum geht, alle Schnittstel-len zwischen Komponenten zu validieren. Es fehlt allerdings eine detaillierte Spezi-fikation der Schnittstelleninhalte. Dazu muss man die IDL-Sprache heranziehen.
Nur auf der Basis der IDL ist es möglich, Schnittstellentestfälle zu spezifizieren.
5.7.8 Verteilungsdiagramm
Das Verteilungsdiagramm (deployment diagram) beschreibt die Verteilung der Komponenten auf dem Rechnernetz, d.h. welche Komponente sich auf welchen Netzknoten befindet. Damit lassen sich zwar keine Testfälle erstellen, aber für den Systemintegrationstest verteilter Komponenten ist die darin enthaltene Information sehr hilfreich. Ansonsten bieten die Verteilungsdiagramme keine Hilfe.
5.7.9 Object Constraint Language
Schließlich gibt es im Zusammenhang mit der UML auch die OCL – Object Constraint Language. Jene Sprache ist die Antwort der OMG auf die Notwendigkeit einer Regelformulierungssyntax. Mit der OCL lassen sich Zusicherungen über Ob-jektzustände sowie über Vor- und Nachbedingungen verfassen. Somit ist OCL die Sprache der Testfallspezifikation, so wie sie hier in diesem Kapitel präsentiert wird.
Sie kann verwendet werden, um gültige und ungültige Zustände sowie Beziehungen zwischen den Attributzuständen festzulegen, z.B.
Programmierer.gehalt < Analytiker.gehalt; Objektptr != null;
Die OCL wird benutzt, um die Zustände der Objekte zuzusichern, die Eingangspa-rameter zu spezifizieren und die AusgangspaEingangspa-rameter zu validieren (Abbildung 5.15). Richtig angewandt, kann sie auch als Testskriptsprache dienen. Durch die Extrahierung und Allokierung der OCL-Anweisungen lassen sich Testprozeduren bilden, die für den Test der Klassen gegen die Klassenspezifikation genutzt werden können. So gesehen ist die UML ergänzt durch OCL ein wichtiger Schritt in Rich-tung selbst-verifizierender Systeme. [WaKl99]
Bank.Überzogene_Konten èSelect ( Bank.Konto.Kontostand
< ( 0 - Bank.Konto.Kreditgrenze ) );
Bank.Schlechte_Kunden è Select ( Bank.Überzogene_Konten ) &&
Select ( Bank.Kunde.Bonität = “niedrig” );
Assert Post Bank.Schlechte_Kunden if ( Bank.Kunde.Bonität = “niedrig” )
& ( Bank.Konto.Kontostand < ( 0 - Bank.Konto.Kreditgrenze ) )
& ( Bank.Kunde.Kontonr = Bank.Konto.Kontonr ) Abbildung 5.15 Objekt Constraint Language
Die Kernfrage ist, ob die UML wirklich dazu dienen kann den Test zu erleichtern bzw. zu verbessern. Die Antwort lautet „jein“. Theoretisch liefern die Dokumente, sofern sie mit dem Code übereinstimmen, eine nützliche Quelle für Testfälle. Mit UML wäre es möglich, den Code gegen das Objektmodell zu testen. In der Praxis sind die UML-Diagramme jedoch selten dazu brauchbar, weil sie zu oberflächlich gehalten werden. Testen hat mit Zuständen und deren Veränderung zu tun und die UML ist schwach, was die Beschreibung dieser Zustände betrifft. Die Zustandsdia-gramme gehen auf die Zustände ein, werden aber in der Praxis nur selten verwen-det.
Der OO-Testexperte Robert Binder nimmt folgende Stellung zum Beitrag der UML zum Test ein. Er schreibt:
“Some OOA/OOD approaches, including those of Embley-Kurtz, Booch and OMT obliterate the distinction between event and action on state transition, static state, and that between event on transition and action on state...They allow both forms in a hy-brid state diagram. UML carries this mutation forward. The resulting hyhy-brid has all of the disadvantages of the Moore model, causes additional testing headaches and does not in any way improve the model’s ability to represent or analyze object behavior....
In short, the UML hybrid solution is error prone and effort intensive.” [Bin99]
Lediglich die OCL [WaKl99] – ein „add on“ zur UML – verspricht wahre Hilfe für die Spezifikation adäquater Testfälle.