Toolmentor: Automatisierten Komponententest mit Rational QualityArchitect implementieren
Dieser Toolmentor liefert einen Überblick über die Einheitentestaufgaben, die mit Rational QualityArchitect ausgeführt werden.
Tool: Rational QualityArchitect
Beziehungen
Hauptbeschreibung

Überblick

Dieser Toolmentor liefert einen Überblick über die vier primären Einheitentestaufgaben, die mit Rational QualityArchitect ausgeführt werden:

  • Einheitentest
  • Szenariotest
  • Stub-Generierung
  • Aufzeichnen von EJB-Sitzungen

Ein Entwicklungsprozess, der das Testen so lange hinauszögert, bis alle Komponenten zu einem kompletten System assembliert werden können, birgt viele Risiken. Mängel, die zu einem so späten Zeitpunkt im Lebenszyklus festgestellt werden, lassen sich schwerer beheben und können einen erheblichen Verzug im Zeitplan verursachen, insbesondere wenn es sich um architekturbezogene Probleme handelt, die eine umfassende Überarbeitung des Designs erfordern.

Selbst wenn ein Team ein begründet hohes Vertrauen in die Qualität seiner Systemkomponenten hat, kann das Vertrauen in das Gesamtsystem trotzdem inakzeptabel gering sein. Stellen Sie sich ein einfaches System vor, das sich aus fünf Komponenten zusammensetzt, deren Zuverlässigkeit (durch Testmetriken oder weniger quantitative Methoden) mit jeweils 95 % bewertet wird. Da die Systemzuverlässigkeit kumulativ ist, ist die Gesamtbewertung 95 x 95 x 95 x 95 x 95 bzw. knapp über 77 %. Während die Fehlerrate in jeder einzelnen Komponente lediglich 1:20 beträgt, erreicht sie für das Gesamtsystem 1:4, und das bei einem System mit nur wenigen Komponenten.

Im Gegensatz dazu hat ein Entwicklungsprozess, der Komponententests während des gesamten iterativen Entwicklungsprozesses einsetzt, mehrere signifikante Vorteile:

  • Probleme können in einem isolierten Kontext ermittelt und behoben werden, was sie zwar nicht leichter zu korrigieren, wohl aber leichter erkennbar und diagnostizierbar macht.
  • Da Tests und Entwicklung während des Lebenszyklus eng miteinander gekoppelt sind, sind die Fortschrittsmessungen glaubwürdiger. Der Fortschritt kann jetzt daran gemessen werden, wie viel des Projekts codiert ist und funktioniert, und nicht nur daran, wie viel codiert ist.
  • Durch unvorhersehbare Probleme verursachte Unterbrechungen des Zeitplans werden minimiert, was den Gesamtzeitplan realistischer macht und das Projektrisiko reduziert.

Obwohl frühe Tests unzählige Vorteile haben, sind sie in der Praxis weit davon entfernt, die Regel zu sein, insbesondere wenn Komponenten der mittleren Schicht ohne Benutzerschnittstelle betroffen sind.

Warum? Weil sie zeitaufwändig und mühsam sind und ihre Umsetzung in der Vergangenheit häufig mehr Kosten verursacht als Vorteile eingebracht hat. Da die meisten Tests für eine bestimmte Komponente angepasst werden, besteht außerdem wenig Gelegenheit zur Wiederverwendung. Viele Organisationen halten es für Verschwendung, Fehlersimulationen und Stubs ganz neu zu erstellen, sie zu verwenden und dann Projekt für Projekt einfach wegzuwerfen. Sie bevorzugen, ihre begrenzten Ressourcen auf andere Bereiche zu konzentrieren.

Mit QualityArchitect werden frühe Tests praktikabel, weil Fehlersimulationen und Stubs automatisch generiert werden, nicht nur einmal, sondern im Einklang mit dem Modell, das iterativ entwickelt wird. Der gesamte Entwicklungsprozess wird strukturierter, kontrollierter und sichtbarer, da sich aufgrund der Ergebnisse der Komponententests strengere Einstiegskriterien definieren lassen, um einen verfrühten Systemtest zu verhindern. QualityArchitect ermöglicht Entwicklern, sich auf die kreativen Aspekte der Testdefinition zu konzentrieren, so dass sie sich Gedanken über die beste Methode zum Testen einer Komponente machen können, anstatt Testtreiber und Stubs zu schreiben und im Debugger zu testen. Entwickler und Architekten arbeiten eng zusammen mit gemeinsamen visuellen Modellen, so dass sie ganz natürlich eine produktivere Beziehung zueinander entwickeln.

Dieser Toolmentor gilt für Windows 98/2000/NT 4.0.

Toolschritte

Dieser Toolmentor beschreibt die folgenden Hauptaufgaben für die Implementierung eines automatisierten Komponententests mit QualityArchitect:

  1. Vorausgesetzte Schritte für Einheitentests
  2. Einheitentest implementieren
  3. Szenariotest implementieren
  4. Stub-Komponente erstellen
  5. EJB Session Recorder verwenden

1.   Vorausgesetzte Schritte für Einheitentests

Wenn Sie mit QualityArchitect Tests für COM- oder EJB-Komponenten erstellen möchten, müssen Sie mit Rational Administrator ein Rational-Projekt erstellen und konfigurieren. Dieses Projekt muss einen Testdatenspeicher für alle Test-Assets wie Testergebnisse und Datenpools enthalten. Informationen hierzu finden Sie in Projekte mit Rational Administrator konfigurieren.

2.   Einheitentest implementieren

Die Zielsetzung eines Einheitentests ist zu prüfen, ob eine bestimmte Operation in einer bestimmten Komponente den korrekten Rückgabewert für bestimmte Eingaben liefert. Einheitentests werden auf der Basis der Klassenspezifikation in der logischen Sicht erstellt. Das Erstellen und Ausführen eines Einheitentests setzt sich aus den folgenden drei Schritten zusammen:

  • Code für Einheitentest generieren
  • Daten für Einheitentest generieren
  • Test ausführen und Ergebnisse untersuchen

Code für Einheitentest generieren

Der Code für den Einheitentest enthält alle Anweisungen, die erforderlich sind, um die Komponente zu instanzieren, die zu testende Operation aufzurufen und die zurückgegebenen Ergebnisse anhand einer Referenzversion zu untersuchen.

Für COM-Komponenten
  1. Wählen Sie in der logischen Sicht die zu testende Operation unterhalb der Komponentenschnittstelle aus.
  2. Klicken Sie mit der rechten Maustaste auf die unterhalb der Komponentenschnittstelle aufgelistete Operation und wählen Sie Rational Test > Generate Unit Test aus. Möglicherweise werden Sie während des Prozesses aufgefordert, sich an einem Rational-Projekt anzumelden.

QualityArchitect generiert in diesem Prozess Code, der mit Visual Basic 6 kompatibel ist.

In Visual Basic müssen Sie zunächst versuchen, den Code zu kompilieren. Alle Kompilierungsfehler müssen untersucht werden. Manchmal ist QualityArchitect nicht in der Lage, Code für Testoperationen zu generieren, die sehr viele komplexe Datentypen verwenden. In diesem Fall fügt QualityArchitect ungültigen Code ein. Zur Kompilierungszeit werden die Codesegmente hervorgehoben, die eine manuelle Codierung erfordern. Nach der Kompilierung des Codes können Sie mit dem nächsten Schritt Daten für Einheitentest generieren fortfahren.

Für EJB-Komponenten
  1. Wählen Sie in der logischen Sicht unter der fernen Schnittstelle die zu testende Operation aus.
  2. Klicken Sie mit der rechten Maustaste auf die Operation und wählen Sie Rational Test > Select Unit Test Template aus.
  3. Navigieren Sie zur entsprechenden Vorlage für Ihren EJB-Server. für WebSphere wählen Sie die Vorlage websphere_remote.template im Ordner "EJBWebSphereBusiness Methods" aus. Für Web Logic wählen Sie die Vorlage weblogic_remote.template im Ordner "EJBWeb LogicBusiness Methods" aus.
  4. Wählen Sie Rational Test > Generate Unit Test aus. Möglicherweise werden Sie während des Prozesses aufgefordert, sich an einem Rational-Projekt anzumelden.  

QualityArchitect generiert Java-Code als Ausgabe dieses Prozesses.

Sie können die IDE oder einen Editor Ihrer Wahl verwenden, um den Java-Code zu untersuchen. Rational Rose stellt den Editor R2 bereit, den Sie für diesen Zweck verwenden können.

In Ihrem Editor können Sie versuchen, den Code zu kompilieren. Alle Kompilierungsfehler müssen untersucht werden. Manchmal ist QualityArchitect nicht in der Lage, Code zu generieren, der sehr viele komplexe Datentypen verwendet. In diesem Fall fügt QualityArchitect ungültigen Code ein, der nicht kompiliert wird, um die Codezeilen zu markieren, die eine manuelle Codierung erfordern. Nach der Kompilierung des Codes können Sie mit dem nächsten Schritt, Daten für Einheitentests generieren fortfahren.

Daten für Einheitentests generieren

Der eigentliche Maßstab eines erfolgreichen Einheitentests sind die Testdaten. Der Testcode selbst ist vollständig austauschbar, da QualityArchitect den Code jederzeit neu generieren kann. Obwohl QualityArchitect den Testcode erstellen kann, kann er keine aussagefähigen Testdaten erstellen. Dies liegt in der Zuständigkeit des Analytikers oder Implementierers. Achten Sie sorgfältig darauf, dass Testdaten erstellt werden, die repräsentative Positiv- und Negativtests auswerten. Testdaten, die sich auf die Grenzbedingungen der Komponentenlogik konzentrieren, sind exzellente Kandidaten für Einheitentests.

Für COM-Komponenten
  1. Wählen Sie in der logischen Sicht unter der Schnittstelle der Komponente die zu testende Operation aus.
  2. Klicken Sie mit der rechten Maustaste auf die Operation und wählen Sie Rational Test > Create Datapool aus.
  3. Nachdem Sie Create Datapool ausgewählt haben, erscheint der Dialog "Datapool Properties". Jetzt können Sie Edit Datapool Data auswählen, um die Daten einzugeben, oder Define Datapool Fields auswählen, wenn QualityArchitect Testdaten für Sie generieren soll.
Für EJB-Komponenten
  1. Wählen Sie in der logischen Sicht unter der fernen Schnittstelle die zu testende Operation aus.
  2. Klicken Sie mit der rechten Maustaste auf die Operation und wählen Sie "Rational Test > Create Datapool" aus.
  3. Nachdem Sie Create Datapool ausgewählt haben, erscheint der Dialog "Datapool Properties". Jetzt können Sie Edit Datapool Data auswählen, um die Daten einzugeben, oder Define Datapool Fields auswählen, wenn QualityArchitect Testdaten für Sie generieren soll.
Mit Datapools arbeiten

Wenn Sie Define Datapool Fields auswählen, können Sie die QualityArchitect-Funktionen für die Generierung von Testdaten verwenden. QualityArchitect kann verschiedene Typen generischer Daten generieren, die in der Dropdown-Liste der Datentypen im Feld Type aufgelistet sind.  

Wenn Sie die entsprechenden Typen ausgewählt haben, wählen Sie die Anzahl der zu generierenden Zeilen aus und klicken Sie dann auf Generate Data. Es ist wahrscheinlich, dass QualityArchitect nicht alle Daten für Sie erstellen kann. Beispielsweise kann QualityArchitect zwar eine generische Liste mit deutschen Städten generieren, hat aber nicht die Möglichkeit, eine Liste aller gültigen, systemspezifischen Rechnungsnummern für dein Auftragssystem zu generieren. Diese Daten müssen manuell als Datentyp oder direkt in einen Datenpool eingegeben werden. Das Erstellen eines Datentyps mit benutzerdefinierten Daten hat den Vorteil, dass QualityArchitect von diesem Zeitpunkt an in der Lage ist, diesen Typ von Daten in der Schnittstelle "Define Datapool Fields" zu generieren. Wenn Sie die Daten direkt in den Datenpool eingeben, stehen sie nur in diesem spezifischen Datenpool zur Verfügung.

Wenn Sie Edit Datapool Data auswählen, geben Sie sofort aussagefähige Testdaten ein. Es gibt ein Feld für jedes Argument, ein Feld für einen erwarteten Rückgabewert und ein Feld für einen erwarteten Fehler. Wenn Sie einen Fehler angeben, sind Fehlernummer und Fehlernachrichten gültige Einträge. Wenn Ihre Operation ein komplexes Objekt als Argument erfordert oder wenn sie ein komplexes Objekt zurückgeben soll, können Sie eine solche Objektreferenz nicht in den Datenpool eingeben. Gliedern Sie das Objekt stattdessen in einfache Argumenttypen, die erforderlich sind, um eine Instanz des Objekts zu erstellen. Verwenden Sie die Schaltflächen Insert Before und Insert After, um dem Datenpool Felder für diesen Zweck hinzuzufügen. Sie müssen den Testcode modifizieren, um mit den bereitgestellten Daten eine Instanz des Objekts zu erstellen.

Test ausführen und Ergebnisse untersuchen

Nachdem Sie den Testcode und die Testdaten erstellt haben, können Sie den Test ausführen. Sie können Ihren Test in der IDE ausführen oder die Ausführung des Tests in einer TestManager-Suite planen. Weitere Informationen zu diesem Thema finden Sie in Toolmentor: Testsuite mit Rational TestManager ausführen.

  1. Zu Beginn der Testausführung werden Sie aufgefordert, eine Position für die Testprotokollergebnisse anzugeben. Wenn Sie eine Position angegeben haben, speichert der TestManager die Ergebnisse dort.
  2. Am Ende der Testausführung zeigt TestManager das Testprotokoll an. Zum Anzeigen der Testergebnisse wählen Sie im Fenster "Log Viewer" das Register Detailed View aus. Erweitern Sie die Baumstrukturanzeige mit den Ergebnissen, um die Details zur Testausführung anzuzeigen. Wenn Sie weitere Informationen sehen möchten, klicken Sie mit der rechten Maustaste auf eine Zeile und wählen Sie Properties aus.

3.   Szenariotest implementieren

Die Zielsetzung eines Szenariotests ist zu prüfen, dass eine bestimmte Reihe von Operationen in einer bestimmten Reihe von Komponenten eine kollektive Aufgabe gemeinsam korrekt ausführen. Szenariotests werden aus Interaktionsdiagrammen, insbesondere Ablauf- und Kollaborationsdiagrammen erstellt. Das Erstellen und Ausführen eines Einheitentests setzt sich aus den folgenden drei Schritten zusammen:

  • Code für Szenariotest generieren
  • Daten für Szenariotest generieren
  • Test ausführen und Ergebnisse untersuchen

Code für Szenariotest generieren

Der Code für den Szenariotest umfasst den gesamten Testtreibercode, der erforderlich ist, um die Komponenten zu instanzieren, die testenden Operationen aufzurufen und die Ergebnisse dieser Operationen an Prüfpunkten auszuwerten. Prüfpunkte sind ein Mechanismus, mit dem der Testcode SQL-Anforderungen an eine Datenbank absetzen kann, um sicherzustellen, dass die zugrunde liegenden Daten korrekt geändert werden.

Für EJB-Komponenten
  1. Wählen Sie im Browser das Kollaborationsdiagramm aus.
  2. Klicken Sie mit der rechten Maustaste auf das Diagramm und wählen Sie Rational Test > Select ScenarioTest Template aus.
  3. Navigieren Sie zur entsprechenden Vorlage für Ihren EJB-Server. Für WebSphere wählen Sie die Vorlage websphere_scenario.template im Ordner EJBWebSphereScenario aus. Für Web Logic wählen Sie die Vorlage weblogic_scenario.template im Ordner EJBWeb LogicScenario aus.
  4. Öffnen Sie das Ablauf- oder Kollaborationsdiagramm, das das Testszenario modelliert. Es ist wichtig, dass im Diagramm die Nachrichten an die Komponenten angegeben werden, die getestet werden. Nachrichten werden angegeben, indem Sie doppelt auf die Nachrichtenlinie klicken und in der Dropdown-Liste auf der Registerkarte General einen Namen angeben. Der Name muss der zu testenden Operation entsprechen. Diese Spezifikationen können geändert werden, um die Daten für den Testfall anzugeben.

    Rose zeigt beispielsweise die Nachrichtenspezifikation standardmäßig wie folgt an:
    getTransactions(customerID : String)

    Diese Spezifikation kann wie folgt an einen einzelnen Datenfall angepasst werden:
    getTransactions(customerID : String="BBryson")

    Für jeden Szenariotest generiert QualityArchitect automatisch einen Datenpool für die Testfalldaten. Die Daten im Diagramm werden in die erste Zeile geschrieben. Danach können Sie weitere Zeilen angeben.
  5. Um mit dem Test zu beginnen, klicken Sie im Browser mit der rechten Maustaste auf das Diagramm und wählen Sie dann Rational Test > Generate Scenario Test aus. Wenn Sie aufgefordert werden, sich an Ihrem Projekt anzumelden, tun Sie dies.  
  6. Es erscheint ein Dialog, in dem Sie aufgefordert werden, die Ziele für den Szenariotest auszuwählen. Wählen Sie alle Komponenten im Diagramm aus, die an dem Test teilnehmen. Für jede ausgewählte Komponente wird Operation aufgerufen, die in der Nachricht der jeweiligen Komponente angegeben ist.  
Für COM-Komponenten
  1. Öffnen Sie das Ablauf- oder Kollaborationsdiagramm, das das Testszenario modelliert. Es ist wichtig, dass im Diagramm die Nachrichten an die Komponenten angegeben werden, die getestet werden. Nachrichten werden angegeben, indem Sie doppelt auf die Nachrichtenlinie klicken und in der Dropdown-Liste auf der Registerkarte General einen Namen angeben. Der Name muss der zu testenden Operation entsprechen. Diese Spezifikationen können geändert werden, um die Daten für den Testfall anzugeben.

    Rose zeigt beispielsweise die Nachrichtenspezifikation standardmäßig wie folgt an:
    getTransactions(customerID : String)

    Diese Spezifikation kann wie folgt an einen einzelnen Datenfall angepasst werden:
    getTransactions(customerID : String="BBryson")

    Für jeden Szenariotest generiert QualityArchitect automatisch einen Datenpool für die Testfalldaten. Die Daten im Diagramm werden in die erste Zeile geschrieben. Danach können Sie weitere Zeilen angeben.
  2. Um mit dem Test zu beginnen, klicken Sie im Browser mit der rechten Maustaste auf das Diagramm und wählen Sie dann Rational Test > Generate Scenario Test aus. Wenn Sie aufgefordert werden, sich an Ihrem Projekt anzumelden, tun Sie dies.  
  3. Es erscheint ein Dialog, in dem Sie aufgefordert werden, die Ziele für den Szenariotest auszuwählen. Wählen Sie alle Komponenten im Diagramm aus, die an dem Test teilnehmen. Für jede ausgewählte Komponente wird Operation aufgerufen, die in der Nachricht der jeweiligen Komponente angegeben ist.  
Prüfpunkte

Für jede Operation, die aufgerufen wird (und am Ende des Tests erneut), werden Sie aufgefordert, einen Prüfpunkt anzugeben. Prüfpunkte werden von QualityArchitect verwendet, um sicherzustellen, dass die Operationen korrekt ausgeführt wurden. Obwohl die Prüfpunktarchitektur offen und erweiterbar ist, ist derzeit nur der Datenbankprüfpunkt implementiert. Am Datenbankprüfpunkt können Sie SQL-Anweisungen angeben, um eine Abfrage abzusetzen. Die erstellte Abfrage wird zur Testzeit ausgeführt, um zu prüfen, ob die Datenbank von der Komponente korrekt geändert wird. 

Symbol für Onlinehilfe Sie können Ihre eigenen Prüfpunkte implementieren, indem Sie die in der Onlinehilfe von QualityArchitect beschriebenen Schritte ausführen.

  1. Wählen Sie Yes aus, um einen Prüfpunkt einzufügen.
  2. Wählen Sie den Typ für den Prüfpunkt aus, den Sie einfügen möchten. Sofern Sie keine eigenen Prüfpunkte implementiert haben, müssen Sie Database VP auswählen.
  3. Daraufhin wird ein Abfragenerstellungsprogramm (Query Builder) geöffnet, in dem Sie die Verbindungsparameter für Ihre Datenbank angeben und die Abfrage erstellen können, die anschließend ausgeführt wird, um die korrekte Funktionsweise der aufgerufenen Operation zu überprüfen. Es sind grundlegende Kenntnisse in der zugrunde liegenden Datenbank und SQL-Syntax erforderlich, um die Verbindung einzurichten und die Abfrage zu erstellen.

An dieser Stelle wird der Code, der erforderlich ist, um alle Komponenten zu instanzieren, alle Operationen aufzurufen und die eingefügten Prüfpunkte auszuführen, generiert.

Daten für Szenariotest generieren

Für jeden generierten Szenariotest erstellt QualityArchitect automatisch einen Datenpool, der die Testdaten enthält. Wenn im Diagramm Daten angegeben wurden, wird die erste Zeile dieses Datenpools automatisch mit diesen Daten und den Informationen für alle eingefügten Prüfpunkte gefüllt. Enthält das Diagramm keine Daten, enthält der Datenpool lediglich Informationen zu den Prüfpunkten.

Gehen Sie wie folgt vor, um diese Informationen anzuzeigen und zu editieren:

  1. Wählen Sie in Rose die Optionen "Tools > Rational Test > Toolbar" aus.
  2. Wählen Sie in der Funktionsleiste den zweiten Eintrag aus, um Ihren Datenpool zu bearbeiten. QualityArchitect erstellt einen Datenpool, der den Namen des Szenariodiagramms enthält, der mit _D endet. Der Algorithmus für die Benennung des Datenpools ist so komplex, dass es zu schwierig ist, den Namen jedes Datenpools in dieser Dokumentation vorherzusagen.

Wenn Sie diese Daten ändern möchten, folgen Sie den Basisschritten, die in Mit Datenpools arbeiten beschrieben sind.

Test ausführen und Ergebnisse untersuchen

Nachdem Sie den Testcode und die Testdaten erstellt haben, können Sie den Test ausführen. Sie können Ihren Test in der IDE ausführen oder die Ausführung des Tests in einer TestManager-Suite planen. Weitere Informationen zu diesem Thema finden Sie in Testsuite mit Rational TestManager ausführen.

  1. Zu Beginn der Testausführung werden Sie aufgefordert, eine Position für die Testprotokollergebnisse anzugeben. Wenn Sie eine Position angegeben haben, speichert der TestManager die Ergebnisse dort.
  2. Am Ende der Testausführung zeigt TestManager das Testprotokoll an. Zum Anzeigen der Testergebnisse wählen Sie im Fenster "Log Viewer" das Register Detailed View aus. Erweitern Sie die Baumstrukturanzeige mit den Ergebnissen, um die Details zur Testausführung anzuzeigen. Wenn Sie weitere Informationen sehen möchten, klicken Sie mit der rechten Maustaste auf eine Zeile und wählen Sie Properties aus.

Für Prüfpunkte wird beim ersten Durchlauf kein Hinweis auf Bestanden oder Gescheitert gegeben. Der erste Durchlauf dient nur zur Erfassung einer Momentaufnahme der Abfrageergebnisse, die als Referenzdaten für künftige Testdurchläufe verwendet werden.

Klicken Sie doppelt auf die Prüfpunkte, um eine Vergleichsanzeige mit den Ergebnissen der Abfrage anzuzeigen. Diese Ergebnisse können bearbeitet werden, so dass die Daten geändert werden können, falls die Abfrage nicht die korrekten Ergebnisse zurückgegeben hat. Alle nachfolgenden Durchläufe des Tests vergleichen ihre Abfrageergebnisse mit den im ersten Durchlauf erfassten.

4.   Stub-Komponente erstellen

Häufig sind die Komponenten in einem Einheiten- oder Szenariotest von anderen Komponenten abhängig. Es können Probleme auftreten, wenn diese sekundären Komponenten nicht betriebsbereit sind. Manchmal befinden sich diese Komponenten noch in der Entwicklung, und manchmal sind sie einfach fehlerhaft. Die Tests der primären Komponente müssen jedoch trotzdem nicht aufgeschoben werden, bis die sekundären Komponenten verfügbar sind. Alle Komponenten, die noch nicht für Testzwecke betriebsbereit sind, können durch einen Stub oder eine vorläufige Komponente ersetzt werden. Der Stub implementiert nicht die Funktionalität der echten Komponente, er reagiert lediglich auf Eingaben. Stubs geben eine programmierte Antwort für eine bestimmte Gruppe von Werten zurück, ohne jegliche Logik zu implementieren. Es ist eine einfache Stimulus-Antwort-Beziehung.

QualityArchitect kann Stubs für COM- und EJB-Komponenten erstellen. Diese Stubs stützen sich auf Referenztabellen, um die Geschäftslogik der Komponenten zu replizieren, die sie ersetzen. Die Tabelle, die als Datenpool implementiert wird, bestimmt, welcher Wert für eine bestimmte Gruppe von Eingaben zurückgegeben wird.

Das Erstellen eines Stub setzt sich aus den folgenden drei Schritten zusammen:

  • Stub-Komponente generieren
  • Referenztabelle für Stub generieren
  • Stub einsetzen

Stub-Komponente generieren

Wenn Sie einen Stub generieren, müssen Sie eine vollständige Komponente generieren. Für die Operationen, die im Stub erfasst werden sollen, müssen Sie eine Referenztabelle erstellen. Eine Stub-Komponente, die Stub-Code für alle Operationen dieser Komponente enthält, ist die Ausgabe des Stub-Generierungsprozesses. Es kann kein Stub für eine einzelne Operation generiert werden.

Für COM-Komponenten
  1. Wählen Sie in der logischen Sicht die Komponentenschnittstelle aus.
  2. Klicken Sie mit der rechten Maustaste auf die Schnittstelle und wählen Sie Rational Test > Generate Stub aus. Sie werden aufgefordert, die Position anzugeben, an der Sie den generierten Stub-Code speichern möchten. Nachdem Sie die Position ausgewählt haben, wird der Code generiert.
Für EJB-Komponenten
  1. Wählen Sie in der logischen Sicht die Bean-Implementierungsklasse aus.  
  2. Klicken Sie mit der rechten Maustaste auf die Klasse und wählen Sie Rational Test > Generate Stub aus. Sie werden aufgefordert, die Position anzugeben, an der Sie den generierten Stub-Code speichern möchten. Nachdem Sie die Position ausgewählt haben, wird der Code generiert.

Referenztabelle für Stub generieren

Zum Replizieren der Logik der echten Komponente muss der Stub wissen, wie die echte Komponente auf eine bestimmte Gruppe von Argumenten reagieren würde. Diese Logik wird in einer Referenztabelle verwaltet, die angibt, welcher Wert oder Fehler für bestimmte Argumente zurückgegeben werden soll. Sie können eine Referenztabelle für jede Operation in der Komponente erstellen, für die der Stub generiert wird.

Für COM-Komponenten
  1. Wählen Sie in der logischen Sicht die Operation unterhalb der Komponentenschnittstelle us.
  2. Klicken Sie mit der rechten Maustaste auf die Schnittstelle und wählen Sie Rational Test > Create Lookup Table aus. Daraufhin wird der Dialog "Datapool Properties" angezeigt.
  3. Führen Sie zum Erstellen dieser Referenztabelle die Basisschritte aus, die unter Mit Datenpools arbeiten beschrieben sind. Sie verwenden diese Tabelle, um die Werte oder Ausnahmen anzugeben, die für bestimmte Argumente zurückgegeben werden sollen.
Für EJB-Komponenten
  1. Wählen Sie in der logischen Sicht die Operation unterhalb der Bean-Implementierungsklasse aus.  
  2. Klicken Sie mit der rechten Maustaste auf die Klasse.
  3. Wählen Sie Rational Test > Create Lookup Table aus. Daraufhin wird der Dialog "Datapool Properties" angezeigt.
  4. Führen Sie zum Erstellen dieser Referenztabelle die Basisschritte aus, die unter Mit Datenpools arbeiten beschrieben sind. Sie verwenden diese Tabelle, um die Werte oder Ausnahmen anzugeben, die für bestimmte Argumente zurückgegeben werden sollen.

Stub einsetzen

Nachdem Sie den Stub und die Referenztabelle generiert haben, muss der Stub anstelle der vorhandenen Komponenten eingesetzt werden. Dieser Prozess ist umgebungsspezifisch. Anleitung zu dieser Aufgabe finden Sie in der Onlinehilfe zu QualityArchitect.

5.   EJB Session Recorder verwenden

EJB Session Recorder ist eine Java-Anwendung, die Ihnen die Interaktion mit eingesetzten Live-EJB-Komponenten ermöglicht. Dieser Funktionalität ist nur für Enterprise JavaBeans, nicht für COM-Komponenten verfügbar.

Die Verwendung des EJB Session Recorder beinhaltet die folgenden Schritte:

  • XML-Aufzeichnungssitzung starten
  • Verbindung zum EJB-Server herstellen
  • Instanz der zu testenden Bean erstellen
  • Operation in der Bean aufrufen
  • Prüfpunkte und Java-Code einfügen
  • Testcode aus EJB-Sitzungsaufzeichnung generieren

Der EJB Session Recorder kann in zwei Modi ausgeführt werden - mit Aufzeichnung und ohne Aufzeichnung. Im Aufzeichnungsmodus werden alle ausgeführten Aktionen in einem XML-Protokoll aufgezeichnet, das der EJB Session Recorder in ausführbaren Java-Code konvertiert. Der Code enthält alle Methodenaufrufe, den gesamten eingefügten Java-Code und die Prüfpunkte. Im Modus ohne Aufzeichnung erstellt das Tool lediglich Instanzen der EJBs und ruft ihre Operationen auf.

  1. Wenn Sie eine Verbindung zum EJB-Server herstellen möchten, müssen Sie den Provider-URL und die Ausgangskontext-Factory angeben. Diese Informationen sind dieselben, die Ihr Clientcode verwendet, um eine Verbindung zum Server herzustellen. Standardverbindungsinformationen für WebSphere und Web Logic finden Sie in der Onlinedokumentation zum Produkt.  
  2. Nachdem Sie die Verbindungsinformationen eingegeben haben, wählen Sie Connect aus. Daraufhin erscheint eine Liste mit Beans, die in diesem Server eingesetzt werden. Sie können in einer Sitzung mit beliebig vielen Beans interagieren. An dieser Stelle müssen Sie die erste Bean auswählen, mit der Sie interagieren möchten.
  3. Hier erstellen Sie eine Instanz der ersten zu testenden Bean. Wählen Sie im oberen Teil des Fensters "Methods" die gewünschte Erstellungsmethode aus. Wenn die Erstellungsmethode bestimmte Parameter erfordert, geben Sie diese im Abschnitt Parameters an. Anschließend wählen Sie Invoke aus, um eine Instanz der Bean zu stellen.
  4. Nachdem die Instanz der Bean erstellt wurde, zeigt der EJB Session Recorder die verschiedenen Operationen an, die in dieser Bean verfügbar sind. Die eigenen Operationen der Bean werden in der oberen Hälfte des Fensters "Methods" angezeigt, die geerbten Operationen in der unteren Hälfte. Im Allgemeinen werden die geerbten Operationen nicht getestet. Nachdem Sie die zu testende Operation ausgewählt haben, können Sie die erforderlichen Parameter für diese Operation im Fenster "Parameters" angeben.
  5. Wenn der Parameter ein komplexes Objekt ist, wird eine Schaltfläche "New" angezeigt. Wenn Sie auf diese Schaltfläche klicken, erscheint ein weiteres Fenster mit einem Dialog, in dem Sie eine Instanz des erforderlichen Objekts erstellen können. In dem Fenster werden alle Konstruktoren und die erforderlichen Argumente für das Erstellen einer Instanz des Objekts angezeigt. Nachdem Sie die Konstruktorinformationen angegeben haben, müssen Sie das Objekt benennen, damit es später während der Aufzeichnung bei Bedarf referenziert werden kann.  
  6. Den Parametern Namen zuzuordnen ist sinnvoll, wenn diese Werte später während der Sitzungsaufzeichnung erneut verwendet werden. Wenn Sie einen Namen angeben, kann QualityArchitect den Wert in alle Parameterfelder eintragen, wenn Sie mit der rechten Maustaste auf das jeweilige Feld klicken.
  7. Wenn Sie auf Invoke klicken, wird die Operation mit dem angegebenen Parameter aufgerufen. Der Rückgabewert wird im Feld Last Return Value angezeigt. Wenn dieser Wert als Eingabe für einen nachfolgenden Aufruf benötigt wird, können Sie ihn in das erforderliche Feld ziehen und übergeben. Sie können den Wert auch über die rechte Maustaste einfügen, wenn Sie den Cursor auf dem Parameterfeld positionieren, in das der Wert eingefügt werden soll. Um zu bestimmen, welche Werte im Kontextmenü angezeigt werden, gleicht der EJB Session Recorder den Typ des Parameters mit den vorherigen Typen ab, die während des Tests bereits verwendet wurden.  
  8. Sie können zu jedem Zeitpunkt während der Sitzung Java-Code oder Prüfpunkte aus dem Menü Insert einfügen. Die Prüfpunkte sind dieselben, die auch bei der Generierung von Code für Szenariotests verwendet werden. Auch Java-Code kann eingefügt werden, um zusätzliche Verarbeitung durchzuführen.
  9. Im Aufzeichnungsmodus können Sie nach Abschluss aller Testschritte die XML-basierte Aufzeichnung in Java-Code konvertieren. Klicken Sie auf Stop, um diese Aktion auszuführen. Sie werden aufgefordert, den XML-Code in Java-Code zu konvertieren und einen Sitzungsnamen und einen Scriptnamen einzugeben. Die Ausgabe dieses Prozesses ist Java-Code, den Sie ausführen können, um die während der Aufzeichnung ausgeführten Schritte zu replizieren.