DE4416704A1

DE4416704A1 - Integrationstestverfahren für ein objektorientiertes Programm

Info

Publication number: DE4416704A1
Application number: DE4416704A
Authority: DE
Inventors: Peter Dr Juettner; Sebald Kolb; Peter Zimmerer; Udo Naumann
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 1994-05-11
Filing date: 1994-05-11
Publication date: 1995-11-16
Also published as: US5615333A

Description

Die Erfindung bezieht sich auf ein automatisch ablaufendes Verfahren zum Integrationstesten eines objektorientierten Programmes.

Im Gegensatz zu prozeduraler Software mit einer Modul- bzw. Funktionsstruktur und gemeinsamen globalen Daten, verbunden über Funktionsaufrufe und Datenflüsse, besteht objektorien tierte Software aus Objekten und Klassen, verbunden über Nachrichtenaustausch, Vererbung und Aufruf-/Benutztbeziehung. insgesamt gibt es in objektorientierten Programmen viel mehr gegenseitige "Abhängigkeiten" (Aufruf, Benutzt, Daten attribute, etc.) als in prozeduraler Software. Durch die Kap selung von Daten und Funktionen in den Klassen besteht eine enge Kopplung zwischen den Daten- und den Aufrufbeziehungen.

Die Funktionalität eines objektorientierten Programms ist nicht in einer top-down organisierten Hierarchie von Funktio nen realisiert, sondern sie ist vielmehr in einem Netzwerk von miteinander kommunizierenden Objekten verteilt. Dadurch verschiebt sich die Komplexität und die Ablauflogik in einem objektorientierten Programm von den einzelnen Funktionen bzw. Methoden zu dem korrekten Zusammenspiel zwischen den Me thoden. Dies wird durch die speziellen objektorientierten Merkmale wie etwa Vererbung, Polymorphismus, dynamisches Binden, Overloading und Reimplementierung noch verstärkt.

Ein "Stub" einer Methode ist eine Ersatzimplementierung zu Testzwecken, die nicht die vollständige Funktionalität der Methode bietet, aber einen Testablauf ermöglicht. Der Prozeß des "Stubbing" beim Testen objektorientierter Software ist komplizierter als in der prozeduralen Programmierung. Die Gründe liegen in der andersartigen Architektur und Struktur der objektorientierten Software, in der Datenkapselung und in den vielen gegenseitigen Abhängigkeiten zwischen den ein zelnen Objekten bzw. Klassen.

Eine Beschreibung der grundlegenden Fachbegriffe der objekt orientierten Programmierung findet sich in: Steve Cook "Introduction to Object Technologie," OOP 1992, Conference Proceedings, SIGS Publications, New York, 1992.

Für die Integration von objektorientierten Programmen und den zugehörigen Integrationstest gibt es bisher keine expliziten Verfahren, und es sind demzufolge auch keine entsprechenden Testwerkzeuge auf dem Markt vorhanden.

Die der Erfindung zugrundeliegende Aufgabe besteht darin, ein automatisiertes Verfahren zum Integrationstest eines objekt orientierten Programmes anzugeben, das Stubs weitestgehend vermeidet.

Diese Aufgabe wird gemäß den Merkmalen des Patentanspruches 1 gelöst.

Weiterbildungen der Erfindung ergeben sich aus den Unteran sprüchen.

Ein besonderer Vorteil des erfindungsgemäßen Verfahrens be steht darin, daß durch eine Quellcode-Analyse des objektori entierten Programms die Abhängigkeiten der einzelnen Klassen und Objekte zueinander gefunden werden und daß diese Abhän gigkeiten genutzt werden, um solche Objekte zu testen, welche nur von bereits getesteten Objekten bzw. Klassen abhängen. Günstigerweise sieht es das erfindungsgemäße Verfahren wei terhin vor, falls keine solchen Objekte gefunden werden, Ob jekte zu testen, welche lediglich von einem ungetesteten Ob jekt und weiteren bereits getesteten Objekten abhängen kön nen. So wird sichergestellt, daß immer möglichst wenig Stubs zum Testen separat programmiert werden müssen.

Vorteilhaft sieht es das erfindungsgemäße Verfahren vor, zum automatisierten Testen mittels des Quellcodes und der Bezie hungsstruktur den richtigen Konstruktor für ein Objekt auto matisch zu ermitteln und dieses Objekt daraus zu erzeugen.

Günstigerweise wird das Objekt durch das erfindungsgemäße Verfahren automatisiert durch Kopieren von Datenkomponenten in den Zustand versetzt, welcher aktuell für den Integrati onstest benötigt wird.

Vorteilhaft sieht es das erfindungsgemäße Verfahren vor, ein Objekt durch einen Methodenaufruf zu testen, welcher aus der Beziehungsstruktur abgeleitet wurde. Die verwendeten Parame ter für den Objektaufruf ergeben sich aus dem Quellcode-Pro gramm und dem aktuellen Zustand des Objektes.

Besonders günstig ist es, solche Objekte, die miteinander ei nen Zyklus bilden, d. h. welche nur voneinander abhängig sind und sich gegenseitig aufrufen, aus der Beziehungsstruktur zu ermitteln und von diesen Objekten mindestens eines durch ei nen Objektstub zu ersetzen, um das andere testen zu können. Fallweise kann es sich auch ergeben, daß ein solches Objekt an einem weiteren ungetesteten Objekt nur einen Methoden aufruf, sozusagen im Durchgriff durch dieses Objekt bewirkt, welcher sich auf ein bereits getestetes Objekt bezieht. Damit kann dieses zunächst als ungetestet gekennzeichnete Objekt direkt als getestet markiert werden und der Testabsolventen menge zugeführt wird.

Vorteilhaft ist es auch im erfindungsgemäßen Verfahren vorge sehen, Objekte, die nicht getestet sind und auf welche zuge griffen wird, durch einen Objektstub zu ersetzen. Stubs stellen eine gängige Methode zum Simulieren eines Objektver haltens dar und sind daher ohne übermäßigen Einsatz zu pro grammieren.

Vorteilhaft ist es im erfindungsgemäßen Verfahren vorgesehen, die Vorgehensweise mehrfach durchzuführen, um so schließlich für das objektorientierte Programm einen vollständigen Inte grationstest durchzuführen. Am Ende eines solchen Tests sind keine ungetesteten Objekte mehr vorhanden.

Mit der Erfindung wird erstmals ein Verfahren zur rechnerge stützten Integration von objektorientierten Programmen und zum zugehörigen Integrationstest bereitgestellt.

Das erfindungsgemäße Verfahren besteht hier zum Beispiel aus zwei Komponenten:

1. Analyseteil und
2. Ablaufteil.

Das erfindungsgemäße Verfahren führt zunächst eine genaue statische Quellcode-Analyse des zu integrierenden objektori entierten Programmes durch und ermittelt alle Abhängigkeiten und Beziehungen zwischen den einzelnen Objekten bzw. Klassen (Analyseteil). Diese so erhaltenen Informationen werden für die schrittweise Integration der einzelnen Objekte und den dabei durchzuführenden Integrationstest (Durchführung von Me thodenaufrufen, etc.) benötigt (Ablaufteil). Das Vorgehen zur Integration wird im folgenden beschrieben.

Als Ausgangspunkt für die Integration dienen alle Klassen, die als getestet vorausgesetzt werden können (z. B. aus Stan dardbibliotheken). Alle im Programm vorkommenden Objekte solcher getesteter Klassen werden als "Menge getesteter Ob jekte" definiert.

(Dies beinhaltet auch anonyme Objekte, d. h. Objekte, die nur über einen Pointer zugänglich sind und Objekte, die implizit, bzw. temporär vom Compiler erzeugt werden.)

Das Integrationsverfahren beginnt mit dieser Menge, die evtl. leer sein kann. Das Ziel ist die schrittweise Vergrößerung dieser Menge um getestete Objekte bis alle Objekte des Pro gramms erfaßt sind.

Im ersten Schritt werden nun vom erfindungsgemäßen Verfahren alle die Objekte automatisch ermittelt, die
entweder noch nicht getestet sind und nur Standarddatentypen
oder bereits getestete Objekte benutzen (siehe 1. Fall a))
oder aber deren Benutzungen/Verwendungen nur gemeinsam in einem Testschritt getestet werden können (z. B. muß bei o1.m(o2) sicherlich o1 und o2 auch gemeinsam in einem Testschritt getestet werden) (siehe 1. Fall b)).

"Benutzt" bedeutet in diesem Zusammenhang als Datenattribut, als lokale Variable in einer Methode oder als Parameter eines Methodenaufrufs an diesem Objekt.

Ausgehend von diesem ersten Schritt sind beispielsweise drei Fälle zu unterscheiden:

1. Fall: es gibt solche Objekte

Dieser Fall entsprechend der obigen Fallunterscheidung wird in a) und b) aufgeteilt.

a) Vorgehen nach Objekten

Zunächst werden beispielsweise für jedes dieser Objekte alle möglichen Benutzungen (unter Berücksichtigung von Polymor phismus, Pointer, etc.) bestimmt. (Benutzung heißt hier Auf ruf einer Methode dieses Objekts.) Die dazu benötigten In formationen wurden bei der Quellcode-Analyse des objektorien tierten Programmes vom erfindungsgemäßen Verfahren ermittelt. Anschließend werden alle diese Benutzungen getestet, d. h. es werden Methoden aufgerufen und die Ergebniswerte und Zustände überprüft. Der Vorteil bei dieser Vorgehensweise ist, daß keine Programmteile "gestubbt" werden müssen. Die Objekte werden dabei sukzessive "bottom-up" getestet.

Ein einzelner Testschritt besteht dabei beispielsweise in ei nem Methodenaufruf an einem Objekt des Anwendungsprogrammes. Dazu erzeugt das erfindungsgemäße Verfahren zum Beispiel ein neues Objekt und bringt dieses, soweit es möglich ist, in denselben Zustand wie das Objekt des Anwendungsprogrammes (z. B. über einen Konstruktoraufruf und durch Kopieren der Datenkomponenten). Anschließend wird der entsprechende Metho denaufruf in der von dem erfindungsgemäßen Verfahren gene rierten Testumgebung (Ablaufteil) durchgeführt.

Benutzungen, die theoretisch möglich sind, in der speziellen Anwendung aber aufgrund der statischen Analyse nicht auftre ten können, werden in diesem Zusammenhang beispielsweise nicht getestet, da es in diesem Kontext nur um den Test eines konkreten Anwendungsprogrammes geht. Die Intention des Verfahrens ist es, genau das (und nicht mehr und nicht weni ger) zu testen, was für das konkrete Anwendungsprogramm not wendig ist und dabei eine vorteilhafte Reihenfolge bzgl. der Objektintegration anzugeben, die die Verwendung der "Stubs" minimiert bzw. vermeidet.

Nach dem erfolgreichen Testen wird jedes solche Objekt zur Menge aller getesteten Objekte hinzugefügt. Das Verfahren wird im Anschluß beispielsweise mit dem ersten Schritt fort gesetzt.

b) Vorgehen nach durchführbaren Testschritten (die beispiels weise jeweils einer Objekt-Benutzung entsprechen)

Dieses Vorgehen ist präziser als bei a) an den durchführbaren Testschritten orientiert.

Zunächst werden alle möglichen Testschritte (entsprechend zu a)) sukzessive ausgeführt, bis keine weiteren mehr möglich sind. Dabei vergrößert sich die Menge der ausgeführten und ausführbaren Testschritte mit jedem der ausgeführten Test schritte (oder bleibt gleich groß), da jeder ausgeführter Test schritt eventuell wiederum weitere Testschritte ermög licht.

Am Ende, d. h. wenn keine weiteren Testschritte mehr möglich sind, wird geprüft, ob ein, oder eventuell mehrere Objekte ganz getestet wurden.

Falls "ja", dann wird jedes solche Objekt zur Menge aller ge testeten Objekte hinzugefügt. Das Verfahren wird mit dem er sten Schritt fortgesetzt.

Falls "nein", d. h. es wurde kein Objekt ganz getestet und es sind keine Testschritte mehr möglich, dann wird das Verfahren mit dem 2. Fall fortgesetzt.

Als Alternative zu b) muß man nicht unbedingt solange testen bis kein Testschritt mehr möglich ist, sondern kann bereits, wenn ein Objekt ganz getestet wurde, mit dem ersten Schritt fortfahren.

2. Fall: es gibt keine solchen Objekte, aber es gibt noch un getestete Objekte

In diesem Fall ist ein Zyklus aufgetreten, d. h. es besteht eine gegenseitige Abhängigkeit zwischen noch ungetesteten Ob jekten.

Der Zyklus wird beispielsweise durch Stubben einer Objektbe nutzung aufgelöst, um wenigstens ein weiteres Objekt testen zu können. Dieses Objekt wird dann getestet, d. h. zum Bei spiel es werden Methoden aufgerufen und Ergebniswerte und Zu stände überprüft.

Hier zeigt sich ein Vorteil des Verfahrens: es wird nur dann gestubbt, wenn es unbedingt erforderlich ist, ansonsten wird es vermieden.

Nach dem erfolgreichen Testen wird dieses Objekt zur Menge aller getesteten Objekte hinzugefügt. Das Verfahren wird mit dem ersten Schritt fortgesetzt.

3. Fall: es gibt keine ungetesteten Objekte mehr

Damit ist der Integrationstest vollständig und beendet.

1. Analyseteil und
2. Ablaufteil.

Im Analyseteil ermittelt das erfindungsgemäße Verfahren alle Abhängigkeiten und Beziehungen zwischen den einzelnen Objek ten bzw. Klassen anhand des Quellcodes des konkreten Anwen dungsprogrammes. Diese so erhaltenen Informationen werden im Ablaufteil benötigt. Der Ablaufteil ist für die eigentliche Integration und den dabei durchzuführenden Integrationstest (Durchführung der Methodenaufrufe, etc.) verantwortlich.

Zusammenfassend besteht das Verfahren für die Integration und den Integrationstest von Objekten in objektorientierten Pro grammen beispielsweise aus folgenden Teilen und Abläufen:

1. Analyseteil: analysiere den Quellcode des konkreten Anwen dungsprogrammes, und ermittle alle Abhängigkeiten und Beziehungen zwischen den einzelnen Objekten bzw. Klassen;
2. Ablaufteil:

Definitionen:

Standardtypen: = int, float, char, etc.;
getestete Klassen: = alle Klassen aus (bereits erfolgreich getesteten oder Standard-) Klassenbiblio theken, alle bereits erfolgreich getesteten Klassen;
definiere eine Menge getesteter Objekte; sie kann leer sein oder Objekte getesteter Klassen enthalten:

getestete Objekte := alle Objekte von bereits getesteten Klassen, alle Variablen von Standard typen;
Start: bestimme alle Objekte, die entweder noch nicht getestet sind und die nur Stan dardtypen, getestete Objekte oder nichts benutzen ("benutzen" bedeutet hier: benutzen als Datenattribut, als lokale Variable in einer Methode, als Parameter bei einem Metho denaufruf bei diesem Objekt) (siehe 1. Fall a))
oder aber deren Benutzungen/Verwendungen nur gemeinsam in einem Testschritt getestet werden können (z. B. muß bei o1.m(o2) sicherlich o1 und o2 auch gemeinsam in einem Test schritt getestet werden) (siehe 1. Fall b)).

1. Fall: es gibt solche Objekte

Dieser Fall wird in a) und b) aufgeteilt, entsprechend zur obigen Fallunterscheidung.

a) Vorgehen nach Objekten

Bestimme für jedes dieser Objekte alle möglichen Benutzungen (unter Berücksichtigung von Polymorphis mus, Pointer, etc.) und teste diese (rufe Methode auf, überprüfe Ergebniswerte und Zustände); Benutzungen, die theoretisch möglich sind, in der speziellen Anwendung aber nicht auftreten, werden in diesem Zusammenhang nicht getestet; nach erfolgreichem Testen füge jedes solche Objekt zur Menge der getesteten Objekte hinzu; goto Start.

b) Vorgehen nach durchführbaren Testschritten (die je weils einer Objekt-Benutzung entsprechen)

Führe sukzessive alle möglichen Testschritte (entspre chend zu a)) aus;
wenn keine weiteren Testschritte mehr möglich sind, dann prüfe, ob ein (oder eventuell mehrere) Objekt(e) ganz ge testet wurde(n);
falls "ja": füge jedes solche Objekt zur Menge der getes teten Objekte hinzu; goto Start;
falls "nein": goto 2. Fall;
Alternative zu b): Man muß natürlich nicht unbedingt so lange testen bis kein Testschritt mehr möglich ist, son dern kann bereits, wenn ein Objekt ganz getestet wurde, wieder zu Start gehen.

2. Fall: es gibt keine solchen Objekte, aber es gibt noch ungetestete Objekte

In diesem Fall ist ein Zyklus aufgetreten (gegenseitige Abhängigkeit zwischen ungetesteten Objekten); löse den Zyklus auf durch Stubben eines Objektes/Methode, um wenigstens ein weiteres Objekt testen zu können, und teste dieses Objekt (rufe Methode auf, überprüfe Ergeb niswerte und Zustände);
nach erfolgreichem Testen füge dieses Objekt zur Menge der getesteten Objekte hinzu; goto Start.

3. Fall: es gibt keine ungetesteten Objekte mehr

Der Integrationstest in vollständig und beendet;
Die folgende Tabelle 1 zeigt ein C++-Beispiel, mit dem die Arbeitsweise des erfindungsgemäßen Verfahrens verdeutlicht werden soll:

Tabelle 1:

1 class c3
2 { private:
3   float r;
4 public:
5  int c3_m1()
6  { if (r < 0)
7   return (0);
8   else return (1);
9  }
10   c3()
11   { r = 17;
12   c3(float z)
13   { r = z * z; };
14  };
15
16  class c2
17  { private:
18   int i;
19   public:
20   void c2_m1(c3 p)
21   { if (p.c3_m1())
22    i = 10;
23    else i = 7;
24   };
25   void c2_m2(int k)
26   { i = k;
27   }
28   c2()
29   { i = 100;
30   };
31  };
32
33  class c1
34  { private: c2 a;
35   public:
36   void cl_m1(c3 p)
37   { a.c2_m1(p);
38   a.c2_m2(5);
39   }
40  }
41
42  main()
43  { c1 o1;
44   c3 o2;
45   c3 03(5);
46   o1.c1_m1(o2);
47   o1.c1_m1(10.0);
48  }

MGT := Menge der getesteten Objekte
MGT := { }

Als Beispiel werden folgende Iterationsschritte angegeben (die Aufteilung in die einzelnen Schritte ist teilweise fle xibel)

1.) Ermittlung aller noch nicht getesteten Objekte, die nur Objekte aus MGT oder Standardtypen benutzen:

Programmiererdefinierte Objekte

o2, o3 in main() (o1 von c1 ist noch nicht testbar!)

Benutzung von o2

- Aufruf des parameterlosen Konstruktors von c3 in Zeile 44
- Benutzung als "rechte Seite" im vom Compiler generierten Copy-Konstruktor in Zeile 46 (über tol, siehe Schritt 2.); muß nicht getestet werden, da compilergeneriert)

Benutzung von o3

- Aufruf des parameterisierten Konstruktors von c3 in Zeile 45
=< generierte Testfälle:
- Test des parameterlosen Konstruktors von c3
- Test des parameterisierten Konstruktors von c3 mit Parameter 5 (incl. cast von int auf float)

Damit sind o2 und o3 getestet.

MGT := MGT + {o2, o3i}

2.) Ermittlung von noch nicht getesteten Objekten, die nur die Objekte aus MGT oder Standardtypen benutzen; Testfortset zung mit den Objekten, die in Zeile 46 benötigt werden wird angestrebt.

Programmiererdefinierte Objekte

Privates Objekt a von c2 in c1 mit parameterlosem Konstruktor (o1 von c1 noch nicht testbar!)

Compilergenerierte Objekte

Temporäres Objekt to1 der Klasse c3 an Parameterposition in Zeile 46 durch compilergenerierten Copy-Konstruktor erzeugt

Benutzung von to1

- Aufruf des compilergenerierten Copy-Konstruktors mit o2 als rechter Seite (muß nicht getestet werden, da compi lergeneriert)
- weitere Benutzung nur zusammen mit a (in Strategie 1. Fall b))

Benutzung von a

- Aufruf des parameterlosen Konstruktors von c2 in Zeile 34
- weitere Benutzung nur zusammen mit to1 (in Strategie 1. Fall b))

Benutzung von to1 und a (in Strategie 1. Fall b)):

- a.c2_m1(to1) in Zeile 37

Weitere Benutzung von a

- a.c2_m2(5) in Zeile 38
=< generierte Testfälle:
- Test des parameterlosen Konstruktors von c2 für a
- Test von a.c2_m1(to1) mit schon getestetem to1
- Test von a.c1_m1(5)

MGT := MGT + {to1 inklusive a}

3.) Ermittlung von noch nicht getesteten Objekten, die nur die Objekte aus MGT oder Standardtypen benutzen

Programmiererdefinierte Objekte

Privates Objekt a von c2 in c1 mit parameterlosem Kon struktor

Compilergenerierte Objekte

Temporäres Objekt to2 der Klasse c3 an Parameterposition in Zeile 47 mit parameterisiertem Konstruktor c3(float z) erzeugt

Benutzung von to2

- Aufruf des parameterisiertem Konstruktors c3(float z) mit 10.0 als konstantem Parameterwert
- weitere Benutzung nur zusammen mit a (in Strategie 1. Fall b))

Benutzung von a

- a aus Schritt 2.) übernehmen!
- weitere Benutzung nur zusammen mit to2 (in Strategie 1. Fall b))

Benutzung von to2 und a (in Strategie 1. Fall b))

- a.c2_m1(to2) in Zeile 37

Weitere Benutzung von a

- a.c2_m2(5) in Zeile 38
=< generierte Testfälle:
- Test des parameterisierten Konstruktors c3(float z) mit z = 10.0
- Test von a.c2_m1(to2) mit schon getestetem to2 und "altem" a
- Test von a.c1_m1(5)

MGT := MGT + {to2 inklusive a}

4.) Ermittlung von noch nicht getesteten Objekten, die nur die Objekte aus MGT oder Standardtypen benutzen

Programmiererdefinierte Objekte

o1

Compilergenerierte Objekte

Keine mehr (alle bereits getestet)

Benutzung von o1

- Aufruf des parameterlosen, compilergenerierten Konstruk tors von c1 in Zeile 43
- Aufruf der Methode c1_m1(o2) in Zeile 46
- Aufruf der Methode c1_m1(10.0) in Zeile 47

Bemerkung: Die dabei auftretenden weiteren Objekte wurden schon für ihre jeweiligen Verwendungen getestet
=< generierte Testfälle:

- Test der Methode c1_m1(o2)
- Test der Methode c1_m1(10.0)

MGT := MGT + {o1}

Damit sind alle Objekte aus main() getestet.

Im folgenden wird die Erfindung anhand einer Figur weiter er läutert

Fig. 1 zeigt ein Beispiel des erfindungsgemäßen Verfahrens ohne das Verfahren auf diesen Anwendungsfall beschränken zu wollen. Es stellt sich folgende Situation dar:

Die Objekte O₁, O₂ und O₃ sind bereits getestet, die Objekte O₄ und O₅ nicht. O₄ benutzt O₁, O₂ und O₃. O₄ und O₅ benutzen sich gegenseitig, also wäre nach dem reinem Integrieren nach Objekten ein Stub notwendig.

Bei genauerer automatischer Analyse der Abhängigkeit durch das erfindungsmäßige Verfahren ergibt sich, daß der Aufruf von m₅ an O₄ lediglich einen Aufruf von m₁ an O₁ zur Folge hat (dieser kann als getestet angesehen werden.) Somit ergibt sich eine Integrationsreihenfolge ohne Stub: Teste den Aufruf von m₅ an O₄. Anschließend ist O₅ testbar, da keine weiteren, nicht getesteten Aufrufe von O₅ ausgehen. Nach dem Test von O₅ kann dieses zur Menge der getesteten Objekte hinzugefügt werden.

Danach ist auch O₄ testbar.

Claims

1. Integrationstestverfahren für ein objektorientiertes Pro gramm, welches bereits getestete Objekte, bzw. Klassen ent hält

a) bei dem durch eine Quellcode-Analyse des objektorientier ten Programmes gegenseitige Abhängigkeiten zwischen minde stens zwei Objekten und/oder Klassen als Beziehungsstruktur ermittelt werden,
b) bei dem ein getestetes Objekt und/oder ein aus einer ge testeten Klasse abgeleitetes Objekt einer Testabsolventen menge zugeordnet wird,
c) und bei dem mit Hilfe der Beziehungsstruktur mindestens ein Objekt ermittelt wird, welches lediglich von Objekten der Testabsolventenmenge abhängt und getestet wird.

2. Verfahren nach Anspruch 1, bei dem zum Testen eines Objek tes mittels des Quellcodes und der Beziehungsstruktur ein richtiger Konstruktor automatisch ermittelt wird, welcher der Erzeugung des Objektes für den Integrationstest dient.

3. Verfahren nach Anspruch 2, bei dem das zu testende Objekt unter Verwendung des Quellcodes durch einen Konstruktoraufruf und kopieren von Datenkomponenten automatisch in einen Zu stand gebracht wird, wie er für den Integrationstest benötigt wird.

4. Verfahren nach einem der obigen Ansprüche, bei dem zum Testen eines Objektes aus der Beziehungsstruktur ein Metho denaufruf abgeleitet wird, mit dem das Objekt getestet wird.

5. Verfahren nach einem der voranstehenden Ansprüche, bei dem falls kein Objekt ermittelt wird, welches lediglich von Ob jekten der Testabsolventenmenge abhängt, dasjenige Objekt ermittelt wird, welches zusätzlich von möglichst wenigen un getesteten Objekten abhängt und getestet wird.

6. Verfahren nach Anspruch 5, bei dem ein ungetestetes Objekt durch ein Objekt-Stub ersetzt wird.

7. Verfahren nach einem der voranstehenden Ansprüche, bei dem von solchen Objekten, welche aufgrund der Beziehungsstruktur nur voneinander und nicht von Objekten der Testabsolventen menge abhängen mindestens eines durch einen Objekt-Stub er setzt wird, um ein anderes zu testen.

8. Verfahren nach einem der voranstehenden Ansprüche, das mehrfach ausgeführt wird.

9. Verfahren nach Anspruch 5, das so oft ausgeführt wird bis kein ungetestetes Objekt mehr vorhanden ist.