DE19960050A1

DE19960050A1 - Grafische Benutzerschnittstelle zur Entwicklung von Anwendungsbeispielen unter Verwendung einer Testobjektbibliothek

Info

Publication number: DE19960050A1
Application number: DE19960050A
Authority: DE
Inventors: Thomas J Pavela
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1998-12-28
Filing date: 1999-12-14
Publication date: 2000-06-29
Also published as: US6421822B1

Abstract

Es werden ein Verfahren, eine Vorrichtung und ein Fertigungsprodukt zur Erzeugung eines Testcodes für ein automatisiertes Verfahren beschrieben. Das Verfahren umfasst die folgenden Schritte: Präsentieren einer visuellen Darstellung einer Bibliothek ausführbarer Codeobjekte für einen Benutzer, die eine Vielzahl von Testobjekten umfasst, Annehmen einer Auswahl eines ersten Testobjektes in der visuellen Darstellung, Darstellen erster Testobjektoptionen, die mindestens einen Testparameter definieren, Annehmen einer Auswahl einer ersten Testoption, Umsetzen der ersten Testoption in mindestens eine Kennzeichnung und einen Kennzeichnungsparameter und Speichern der Kennzeichnung und des Kennzeichnungsparameters in einer Quellendatei. Das Fertigungsprodukt umfasst eine Datenspeichereinheit, die Befehle zum Ausführen der oben beschriebenen Verfahrensschritte eindeutig ausführt. Die Vorrichtung umfasst einen Computer mit geeigneten Programmbefehlen, um einem Benutzer eine visuelle Darstellung einer Bibliothek ausführbarer Codeobjekte zu präsentieren. Die Bibliothek ausführbarer Codeobjekte enthält eine Vielzahl von Testobjektelementen, von denen jedes einen Befehlssatz zum Ausführen eines Teils des Testverfahrens definiert. Der Computer ist außerdem so konfiguriert, dass er eine grafische Benutzerschnittstelle realisiert, um eine Auswahl eines ersten Testobjektes in der visuellen Darstellung anzunehmen, Testoptionen für das ausgewählte Testobjekt darzustellen und eine ...

Description

QUERVERWEIS AUF VERWANDTE ANMELDUNGEN

Diese Anmeldung betrifft die folgende gleichzeitig anhängige und gemeinschaftlich zugewiesene Patentanmeldung, die durch Bezugnahme hierin aufgenommen ist: Anmeldung mit der Seriennr. 221 389, mit dem Titel "SYSTEM AND METHOD FOR DEVELOPING TEST CASES USING A TEST OBJECT LIBRARY", eingereicht am 28. Dezember 1998 von Thomas J. Pavela.

GRUNDLAGEN DER ERFINDUNG 1. Gebiet der Erfindung

Die vorliegende Erfindung betrifft Systeme und Verfahren zur Erzeugung von Anwendungsbeispielen und insbesondere ein Verfahren und System zur Erzeugung von Anwendungsbeispielen unter Verwendung einer Testobjektbibliothek.

2. Beschreibung der technischen Zusammenhänge

In den letzten beiden Jahrzehnten fand eine schnelle Verbreitung von Computeranwendungsprogrammen statt. Um wettbewerbsfähig zu bleiben, müssen Softwareanwendungen auf die sich rasch entwickelnden Bedürfnisse der Kunden reagieren und so fehlerfrei wie möglich sein. Ein Verfahren zur Gewährleistung der Fehlerfreiheit einer Softwareausgabe ist das Testen der Software mit einer großen Auswahl von Anwendungsbeispielen, die sorgfältig ausgewählt werden, um alle kritischen Module im Softwareprodukt zu testen. Solche Testverfahren sind besonders wichtig, wenn die zu testende Software entworfen wird, um mit einer Anzahl parallel betriebener Prozessoren oder anderer Systeme zu arbeiten. In solchen Fällen sollten die die Anwendungsbeispiele schreibenden Personen mit dem Betriebssystem und den Übertragungsprotokollen für alle Elemente im System vertraut sein, leider gibt es jedoch nur wenige Personen, die über alle notwendigen Fachkenntnisse zum Schreiben eines vollständigen Testprogramms verfügen.

Die Entwicklung und Ausführung von Software-Anwendungsbeispielen benötigen außerdem viel Zeit und Betriebsmittel und können die rechtzeitige Einführung eines Softwareproduktes auf dem Markt verzögern. Da Softwareanwendungen unter hohem Konkurrenzdruck geschrieben und verkauft werden, besteht ein dringender Bedarf zur Verringerung des Kosten- und Zeitaufwands beim Testen von Software.

Normalerweise beginnt der Prozess der Entwicklung von Softwaretestverfahren mit dem Erstellen eines Testplans mit Testaufgaben und -verfahren. Dieser Testplan wird veröffentlicht und einer Prüfung unterzogen. Falls der Testplan genehmigt wird, wird ein ausführlicher automatisierter Testcode geschrieben. Ausnahmslos funktioniert der Testcode nicht wunschgemäß, und es müssen Änderungen am Code vorgenommen werden, die oftmals auch größere Änderungen am Testplan mit sich bringen. Da das Softwareprodukt so schnell wie möglich auf den Markt gebracht werden soll, kommt es häufig vor, dass der Testplan nie aktualisiert wird, um die neuen Testverfahren widerzuspiegeln. Auch wenn die Situation eine Aktualisierung des Testplans erfordert, beinhaltet diese Anstrengung üblicherweise einen erheblichen Zeit- und Kostenaufwand.

Benötigt wird ein verbessertes System und Verfahren zur Entwicklung von Anwendungsbeispielen. Die vorliegende Erfindung entspricht diesem Bedarf, indem sie ein System bietet, das es den Systemtestentwicklern erspart, den automatisierten Code von vorne zu schreiben. Statt dessen wird der Testentwickler mit einer Bibliothek von Testobjekten ausgestattet, von denen jedes einen Teil des automatisierten Testverfahrens ausführt. Wenn eines der Objekte in der Bibliothek ausgewählt wird, wird der Benutzer zum Auswählen aus Testobjektoptionen aufgefordert, die benötigte Testparameter definieren, wodurch der Prozess vereinfacht wird. Das System und Verfahren zum Entwickeln von Anwendungsbeispielen befreit den Testentwickler außerdem von der Last, sich mit den Protokollen und dem Interoperabilitätsbedarf für jedes von der Software verwendete Systemelement vertraut zu machen, und ermöglicht es, dass der Testplan mit deutlich weniger Aufwand aktualisiert und dokumentiert werden kann.

ZUSAMMENFASSUNG DER ERFINDUNG

Um die oben beschriebenen Bedürfnisse anzusprechen, stellt die vorliegende Erfindung ein Verfahren, eine Vorrichtung und ein Fertigungsprodukt zum Erzeugen eines Testcodes für eine automatische Prozedur bereit.

Das Verfahren umfasst die folgenden Schritte: Darstellen einer visuellen Darstellung einer Bibliothek ausführbarer Codeobjekte, die eine Vielzahl von Testobjekten enthalten, für einen Benutzer, Aufnehmen einer Auswahl eines ersten Testobjektes in die visuelle Darstellung, Darstellen erster Testobjektoptionen, die mindestens einen Testparameter definieren, Annehmen einer Auswahl einer ersten Testoption, Umsetzen der ersten Testoption in mindestens eine Kennzeichnung und mindestens einen Kennzeichnungsparameter und Speichern der Kennzeichnung und des Kennzeichnungsparameters in einer Quellendatei. Das Fertigungsprodukt umfasst eine Datenspeichereinheit, die Befehle zum Ausführen der oben beschriebenen Verfahrensschritte eindeutig ausführt.

Die Vorrichtung umfasst Mittel, um einem Benutzer eine visuelle Darstellung einer Bibliothek ausführbarer Codeobjekte zu präsentieren. Die Bibliothek ausführbarer Codeobjekte enthält eine Vielzahl von Testobjektelementen, von denen jedes einen Befehlssatz zum Ausführen eines Teils des Testverfahrens definiert. Nominell umfasst das Mittel zum Ausführen dieser Funktion einen Computer, der geeignete Programmbefehle ausführt. Die Vorrichtung umfasst außerdem Mittel, beispielsweise einen eine grafische Benutzerschnittstelle (GUI) realisierenden Computer, um eine Auswahl eines ersten Testobjektes in der visuellen Darstellung anzunehmen, Testoptionen für das ausgewählte Testobjekt darzustellen und eine Testobjektoption anzunehmen. Die Vorrichtung umfasst außerdem Mittel zum Umsetzen der ersten Testoption in mindestens eine Kennzeichnung und mindestens einen Kennzeichnungsparameter, die in einer Quellendatei gespeichert werden.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Nun wird auf die Zeichnungen Bezug genommen, in denen gleiche Bezugsziffern durchweg entsprechende Teile darstellen:

Fig. 1 ist ein Blockschaltbild, das eine beispielhafte Hardwareumgebung zum Umsetzen der vorliegenden Erfindung in die Praxis zeigt;

Fig. 2 ist ein Flussdiagramm, das eine Übersicht über die Prozess-Schritte zeigt, die zum Umsetzen einer Ausführungsform der vorliegenden Erfindung in die Praxis verwendet werden;

Fig. 3 ist ein Flussdiagramm, das zusätzliche Einzelheiten bezüglich der in Fig. 2 beschriebenen Arbeitsgänge bereitstellt;

Fig. 4 ist ein Diagramm, das eine veranschaulichende Ausführungsform einer Schablone für die Skriptdatei zeigt;

Fig. 5 ist ein Beispiel einer Skriptdateischablone, nachdem der Testzweck und das Testszenario vom Benutzer in die Quellendatei eingefügt wurden;

Fig. 6 ist ein Beispiel einer Quellendateischablone, nachdem eine Vielzahl von Testverfahrensbefehlen in die Quellendateischablone eingefügt wurden;

Fig. 7 ist ein Flussdiagramm, das ein veranschaulichendes Beispiel von Prozess-Schritten zeigt, die zum Erstellen des Testplans aus der Quellendatei verwendet werden;

Fig. 8A und 8B sind Diagramme, die einen Testplan zeigen, der aus der in Fig. 6 gezeigten Quellendatei erstellt wurde;

Fig. 9A bis 9F sind Diagramme, die eine Auflistung eines automatisierten Testcodes zeigen, der aus der in Fig. 6 gezeigten Skriptdatei erzeugt wurde;

Fig. 10 ist ein Flussdiagramm, das eine Übersicht über die Arbeitsgänge zeigt, die zum Erzeugen einer Quellendatei unter Verwendung der Anwendungsbeispiel-GUI verwendet werden;

Fig. 11 ist ein Diagramm eines Startfensters für die Anwendungsbeispiel-GUI;

Fig. 12 ist ein Diagramm einer Ausführungsform des Erscheinens der Anwendungsbeispiel-GUI, die den Benutzer auffordert, einen Anwendungsbeispielnamen und eine Anwendungsbeispielbeschreibung bereitzustellen;

Fig. 13 ist ein Diagramm des Erscheinens einer Ausführungsform der Anwendungsbeispiel-GUI, die den Benutzer zum Auswählen einer Konfiguration (Umgebung) auffordert;

Fig. 14 ist ein Diagramm, das ein Beispiel der Anwendungsbeispiel-GUI zeigt, die den Benutzer zum Eingeben einer schrittweisen Szenariobeschreibung auffordert;

Fig. 15 ist ein Diagramm, das ein Beispiel davon zeigt, wie die Anwendungsbeispiel-GUI den Testentwickler zum Eingeben eines Autorennamens auffordert;

Fig. 16 ist ein Diagramm, das eine beispielhafte Anwendungsbeispiel-GUI zeigt, die den Benutzer zum Auswählen einer Testkonfiguration auffordert;

Fig. 17 ist ein Diagramm, das eine beispielhafte Anwendungsbeispiel-GUI zeigt, die den Benutzer zum Auswählen unter RECON-Initialisierungsoptionen auffordert;

Fig. 18 ist ein Diagramm, das eine beispielhafte Anwendungsbeispiel-GUI zeigt, die den Benutzer zum Auswählen von Datenbanktypen für das Anwendungsbeispiel auffordert;

Fig. 19 ist ein Diagramm, das eine beispielhafte Anwendungsbeispiel-GUI zeigt, die den Benutzer auffordert, eine Auswahl zu treffen, welche Datenbanken für das Anwendungsbeispiel geladen werden sollen;

Fig. 20 ist ein Diagramm, das eine beispielhafte Anwendungsbeispiel-GUI zeigt, die den Benutzer zum Auswählen unter IRLM-Optionen auffordert;

Fig. 21 ist ein Diagramm, das eine beispielhafte Anwendungsbeispiel-GUI zeigt, die den Benutzer zum Eingeben von Testverfahrensbefehlen auffordert;

Fig. 22 ist ein Diagramm, das die Anwendungsbeispiel-GUI zeigt, nachdem der Benutzer ein Symbol zum Zeigen der Bibliothekelementobjekte ausgewählt hat, die in die Kuppeleinrichtungskategorie eingeteilt wurden;

Fig. 23 ist ein Diagramm, das die Anwendungsbeispiel-GUI zeigt, nachdem der Benutzer das Bibliothekelementobjekt "CF Link Failure Recovery" in Fig. 22 ausgewählt hat;

Fig. 24 ist ein Diagramm, das zeigt, wie die Anwendungsbeispiel- GUI verwendet werden kann, um mit Befehlen in der Quellendatei ein reverse-parsing auszuführen;

Fig. 25 ist ein Diagramm, das die Anwendungsbeispiel-GUI nach einer Änderung in der Konfiguration von einer Einwegkonfiguration zu einer Sechswegekonfiguration zeigt;

Fig. 26 ist ein Diagramm, das eine andere Ausführungsform der Anwendungsbeispiel-GUI zeigt;

Fig. 27 ist ein Diagramm, das die Anwendungsbeispiel-GUI zeigt, die eine andere Ausführungsform des Fensters "Set up a live terminal" zeigt;

Fig. 28 ist ein Diagramm, das die Anwendungsbeispiel-GUI zeigt, nachdem der Benutzer ein Objekt im Quellencode mit einem Parameterfehler zum reverse-parsing ausgewählt hat;

Fig. 29 ist ein Diagramm, das die Anwendungsbeispiel-GUI zeigt, die ein IRLM-Objektfenster darstellt;

die Fig. 30A und 30B stellen Codebefehle für ein Skriptmakro dar;

Fig. 31 stellt ein Beispiel eines Softwarecodes dar, der zum Umsetzen eines Testobjekts in einen Testcode verwendet wird; und

Fig. 32A bis 32C stellen ein Beispiel einer Unterroutine in der automatisierten, ausführbaren Unterroutinenbibliothek dar, die vom Testcode aufgerufen werden kann.

AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM

In der folgenden Beschreibung wird Bezug auf die begleitenden Zeichnungen genommen, die einen Teil hiervon bilden und durch Veranschaulichung mehrere Ausführungsformen der vorliegenden Erfindung zeigen. Es ist klar, dass andere Ausführungsformen verwendet und strukturelle Änderungen vorgenommen werden können, ohne vom Anwendungsbereich der vorliegenden Erfindung abzuweichen.

Hardwareumgebung

Fig. 1 stellt ein beispielhaftes Computersystem 100 dar, das zum Ausführen der vorliegenden Erfindung verwendet werden könnte. Der Computer 102 umfasst einer Prozessor 104 und einen Speicher 106, beispielsweise einen Arbeitsspeicher (RAM) 106. Der Computer 102 wird mit einer Anzeige 122 funktionsmäßig verbunden, die dem Benutzer auf einer grafischen Benutzerschnittstelle 118B Bilder, zum Beispiel Fenster, präsentiert. Der Computer 102 kann mit anderen Einheiten verbunden werden, beispielsweise mit einer Tastatur 114, einer Mauseinheit 116, einem Drucker, usw. Fachleute werden selbstverständlich erkennen, dass jede Kombination der oben genannten Komponenten oder jede Anzahl von verschiedenen Komponenten, Peripheriegeräten und anderen Einheiten mit dem Computer 102 verwendet werden kann.

Im Allgemeinen arbeitet der Computer 102 unter der Steuerung eines im Speicher 106 gespeicherten Betriebssystems und mit Schnittstellen zum Benutzer zur Aufnahme von Eingaben und Befehlen und zur Darstellung von Ergebnissen durch ein grafisches Schnittstellen-(GUI-)Modul 118A. Obwohl das GUI- Modul 118A als separates Modul dargestellt wird, können sich die die GUI-Funktionen ausführenden Befehle im Betriebssystem 108 oder im Anwendungsprogramm 110 befinden oder in diesem verteilt sein oder mit speziellen Speichern und Prozessoren ausgeführt werden. Der Computer 102 realisiert außerdem einen Compiler 112, der es ermöglicht, dass ein in einer Programmiersprache wie COBOL, C++, FORTRAN oder einer anderen Sprache geschriebenes Anwendungsprogramm in einen vom Prozessor 104 lesbaren Code übersetzt wird. Nach Beendigung greift die Anwendung 110 unter Verwendung der Zusammenhänge und der Logik, die unter Verwendung des Compilers 112 erzeugt wurden, auf im Speicher 106 des Computers 102 gespeicherte Daten zu und bearbeitet diese.

In einer Ausführungsform werden Befehle, die das Betriebssystem 108, das Computerprogramm 110 und den Compiler 112 ausführen, in einem computerlesbaren Datenträger gespeichert, z. B. einer Datenspeichereinheit, die eine oder mehrere feststehende oder austauschbare Datenspeichereinheiten, beispielsweise ein Zip- Laufwerk, Diskettenlaufwerk 124, Festplattenlaufwerk, CD-ROM- Laufwerk, Bandlaufwerk, usw., enthalten kann. Außerdem umfassen das Betriebssystem 108 und das Computerprogramm 110 Befehle, die beim Lesen und Ausführen durch den Computer 102 bewirken, dass der Computer 102 die zum Ausführen und/oder Anwenden der vorliegenden Erfindung benötigten Schritte ausführt. Befehle des Computerprogramms 110 und/oder Betriebsbefehle können außerdem im Speicher 106 und/oder in Datenübertragungseinrichtungen eindeutig ausgeführt werden, wodurch ein Computerprogrammprodukt oder Fertigungsprodukt gemäß der Erfindung erzeugt wird. Wie sie hierin verwendet werden, sind die Begriffe "Fertigungsprodukt" und "Computerprogrammprodukt" als solche vorgesehen, ein Computerprogramm zu beinhalten, auf das von jeder computerlesbaren Einheit oder jedem computerlesbaren Datenträger zugegriffen werden kann.

In einer Ausführungsform ist der Computer 102 mit einem System 130 kommunikationsfähig verbunden, das ein oder mehrere Systemelemente umfasst, darunter beispielsweise ein ferner Computer 132A, ein ferner Server 132B oder eine Testeinheit oder Testschnittstelle 132C (im Folgenden insgesamt als Systemelemente 132 bezeichnet). Teile des Anwendungsprogramms 110 können von den Systemelementen 132 sowie vom Computer 102 ausgeführt werden, wodurch folglich eine parallele Verarbeitungsstruktur realisiert wird. Das Anwendungsprogramm 110 kann außerdem eine Reihe von Befehlen für ein oder mehrere der Systemelemente 132 enthalten.

Fachleute werden erkennen, dass an dieser Konfiguration viele Änderungen vorgenommen werden können, ohne vom Anwendungsbereich der vorliegenden Erfindung abzuweichen. Fachleute werden beispielsweise erkennen, dass jede Kombination der obigen Komponenten oder jede Anzahl von verschiedenen Komponenten, Peripheriegeräten und anderen Einheiten mit der vorliegenden Erfindung verwendet werden kann.

Übersicht

Fig. 2 ist ein Flussdiagramm, das eine Übersicht über die Verfahrensschritte darstellt, die zum Umsetzen einer Ausführungsform der vorliegenden Erfindung verwendet werden. Als erstes beginnt der Prozess mit der Definition einer Quellendatei 318 mit einer Vielzahl von Kennzeichnungen, wie im Block 202 gezeigt wird. Jeder Kennzeichnung wird ein Element einer Bibliothek ausführbarer Codeobjekte zum Ausführen eines Teils eines automatisierten Testverfahrens für das System 130 zugeordnet. Die Quellendatei 318 wird zum Erzeugen 204 eines Testplans 322 verwendet. Der Testplan 322 ist ein Dokument, das die Testaufgaben, -verfahren, -szenario und andere wichtige Informationen über das Anwendungsbeispiel allgemeinsprachlich beschreibt. Der Testplan 322 wird normalerweise zur Überprüfung durch ein Testprüfteam veröffentlicht. Falls der Testplan 322 genehmigt wird, wird ein automatisierter Testcode aus der Quellendatei 318 erzeugt 206.

Fig. 3 ist ein Flussdiagramm, das zusätzliche Einzelheiten bezüglich der in Fig. 2 beschriebenen Arbeitsgänge bereitstellt. Eine Quellendatei 318 kann unter Verwendung einer Anwendungsbeispiel-GUI 312 oder manuell unter Verwendung einer Quellendateischablone 302 mit Hilfe irgendeines Texteditors erzeugt werden. Der Prozess der Erzeugung einer Quellendatei 318 aus der Quellendateischablone 302 wird unten erläutert.

Fig. 4 ist ein Diagramm, das eine veranschaulichende Ausführungsform einer Schablone 302 für die Skriptdatei 318 zeigt. Die Quellendateischablone 302 stellt dem Benutzer eine organisierte Liste der wesentlichen Teile der Quellendatei 318 bereit. Der Benutzer kann die Schablone 302 verwenden, um die Anwendungsbeispielaufgaben, das Testszenario, das Testverfahren, die Systemkonfiguration und die vom Anwendungsbeispiel verwendeten Teile einzugeben. Nach der Fertigstellung wird die Quellendatei 318 zum Erzeugen eines Testplans 322 und eines Testcodes 320 für das Anwendungsbeispiel verwendet.

Die Schablone 400 umfasst eine Vielzahl von Kennzeichnungen 402 bis 450, die zum Kennzeichnen und Beschreiben von in die Quellendatei 318 eingegebenen Informationen verwendet werden. Die Kennzeichnungen 402, 406, 414, 422, 430 und 438 (mit :h4 bezeichnet) sind Vorsatzkennzeichnungen, die anzeigen, dass die auf die Kennzeichnung folgenden Informationen (die Zeichen "Objectives", "Scenario", "Procedure", "Verification", "System Configuration" und "Parts Used by Test Case") einer vierten Vorsatzstufe (header level) zugeordnet werden, die im Testplan 322 in unverschlüsseltem Text ausgegeben werden. Die Kennzeichnung 404 zeigt an, dass die folgenden Informationen im Testplan 322 als Textabschnitt ausgegeben werden. Die Kennzeichnungen 408, 416, und 424 zeigen an, dass die folgenden Elemente Teil einer geordneten Liste sind und nummeriert werden. Die Kennzeichnungen 410, 418, 426 und 434 zeigen an, dass die folgende Information eine Zeilenausgabe ist. Die Kennzeichnungen 412, 420, 428 und 436 sind Anzeigen für das Ende der Kennzeichnung. Der Begleittext der Aufgaben des Tests wird nach der Kennzeichnung 404 eingegeben. Eine oder mehrere Zeileneingaben oder Befehle werden bereitgestellt, die ab der Kennzeichnung 410 in das Testszenario eintreten. Ähnlich werden Informationen, die die Testverfahren, die Überprüfung, die Systemkonfiguration und die vom Anwendungsbeispiel verwendeten Teile betreffen, nach den Kennzeichnungen 416, 424, 432 bzw. 438 eingegeben.

Fig. 5 ist ein Beispiel einer Skriptdateischablone 500, nachdem der Testzweck und das Testszenario vom Benutzer in die Quellendatei 318 eingefügt wurden. Ein Begleittext zum Zweck des Tests wird als 502 dargestellt, und das Testszenario wird von der Vielzahl der als 504 gezeigten Zeilen angegeben.

Außer dem Testzweck und dem Testszenario muss der Benutzer ein Testverfahren eingeben. Dieses Testverfahren hat eine Reihe von Befehlen an die getesteten Systemelemente 132 zur Folge. Der Benutzer kann das Testverfahren eingeben, indem er einfach Zeichen tippt, die die geeigneten Systemelementbefehle in der Skriptdatei beschreiben, oder indem eine grafische Benutzerschnittstelle (GUI) 312 für das Anwendungsbeispiel verwendet wird, die in dieser Beschreibung an späterer Stelle beschrieben wird. Die Anwendungsbeispiel-GUI 312 führt den Benutzer im Grunde genommen schrittweise durch den Prozess der Definition des Testverfahrens, indem der Benutzer zum Auswählen von Testoptionen aufgefordert wird. Die Anwendungsbeispiel-GUI 312 befreit den Benutzer folglich von der Notwendigkeit, sich an die Syntax und die Parameter für eine große Anzahl von Testverfahrensbefehlen zu erinnern.

Fig. 6 ist ein Beispiel einer Quellendateischablone 302, nachdem eine Vielzahl von Testverfahrensbefehlen 606 bis 616 in die Quellendateischablone 500 eingefügt wurden. Jedem der Befehle wird eine Kennzeichnung 602A bis 616A und ein oder mehrere Parameter 602B bis 616B zugeordnet. Jede der Kennzeichnungen 602A bis 616A für die Testverfahrensbefehle wird einem Element einer Bibliothek ausführbarer Codetestobjekte 314 zugeordnet, von denen jedes eine zugewiesene Funktion zur Unterstützung des automatisierten Testverfahrens ausführen kann. Die Kennzeichnung 602A :HPENTRY und der zugeordnete Parameter 602B geben beispielsweise die zu testende Konfiguration an. Die Kennzeichnung 604A :HPLOAD und zugeordnete Parameter geben an, dass die getestete Datenbank die "DJK"-Datenbank ist, die auf einer gemeinsamen Stufe von drei realisiert werden soll. Andere Kennzeichnungen 606A bis 616A und Parameter 606B bis 616B beziehen sich außerdem auf spezifische Testbefehle. Die Quellendatei 318 ist beendet, wenn alle gewünschten Testverfahrensbefehle eingegeben wurden. Wiederum mit Bezugnahme auf Fig. 3 wird die Anwendungsbeispiel-Quellendatei 318 nun verwendet, um über ein QPRINT 321 oder eine ähnliche Funktion einen Testplan 322 zu erzeugen. Der Testplan 322 ist eine allgemeinsprachliche Beschreibung des Anwendungsbeispiels (einschließlich der Aufgaben, des Szenarios, der Verfahren, usw.).

Fig. 7 ist ein Flussdiagramm, das ein veranschaulichendes Beispiel von Verfahrensschritten zeigt, die zur Erzeugung des Testplans 322 aus der Quellendatei 318 verwendet werden. In einigen Fällen geben die Kennzeichnungen in der Quellendatei 318 einfach ein Druckformat an (z. B. Einrückung und ob der auf die Kennzeichnung folgende Text ein Vorsatz ist, wie die Kennzeichnungen 402 bis 405). Andere Kennzeichnungen, beispielsweise die Kennzeichnungen 602A bis 616A, werden stattdessen den Elementen der Bibliothek ausführbarer Testcodeobjekte 314 zugeordnet. Der erste Kennzeichnungstyp kann von einer QPRINT-Funktion 321 ausgewertet und gedruckt werden. Der zweite Kennzeichnungstyp wird jedoch nicht von einer QPRINT- Funktion 321 erkannt und muss auf andere Weise erkannt und bearbeitet werden. Diese Kennzeichnungen werden unter Verwendung von Skriptmakros 325 ausgewertet und übersetzt, und allgemeinsprachliche Anweisungen für den Testplan 322 werden erzeugt, wie in den Blöcken 702 und 704 gezeigt wird. Dies wird über Skriptmakros 325 ausgeführt, beispielsweise das in den Fig. 30A und 30B dargestellte Skriptmakro mit repräsentativen Codebefehlen. Falls Kennzeichnungen vorkommen, die nicht ausgewertet werden können (weil der Benutzer beispielsweise den falschen Kennzeichnungsnamen eingetippt hat, eine Kennzeichnung nicht einem der Skriptmakros 325 zugeordnet ist oder ein Kennzeichnungsparameter nicht unterstützt wird oder außerhalb des Bereichs liegt), wird eine diesen Fehler angebende Fehlermeldung (zum Beispiel "+++") an eine entsprechende Stelle im Testplan 322 gestellt.

Die Kennzeichnungen in der Quellendatei 318 werden abgefragt, um durch das Anwendungsbeispiel getestete Systemelemente 132 zu kennzeichnen und um einen Testindex (der Index wird automatisch erzeugt) aus den gekennzeichneten Systemelementen 132 zu erzeugen. Dies gibt dem Benutzer einen flüchtigen Überblick über den Anwendungsbereich und die Vollständigkeit des Anwendungsbeispiels.

Die Fig. 8A und 8B sind Diagramme, die einen Testplan 322 zeigen, der aus der in Fig. 6 gezeigten Quellendatei erzeugt wurde. Es sei darauf hingewiesen, dass die QPRINT-Funktion 321 die ersten Kennzeichnungen ausgewertet hat, um den Testplan entsprechend zu formatieren, und die Skriptmakros haben die zweiten Kennzeichnungen ausgewertet und stellen eine allgemeinsprachliche Beschreibung der Testverfahren bereit. Da der Testplan 322 eine allgemeinsprachliche Beschreibung dessen darstellt, was der Test ausführen soll, welche Verfahren und welcher Testcode verwendet werden, kann der Testplan 322 zur Überprüfung und Kritik veröffentlicht werden. Falls irgendwelche Änderungen am Test erforderlich sind, nimmt der Benutzer die notwendigen Änderungen an der Quellendatei 318 vor und erzeugt den Testplan 322 von neuem. Außerdem kann der Testplan 322 auch zur Erzeugung anderer spezieller Dateien verwendet werden. Beispielsweise kann der Testplan 322 durch ein HPINFO- Softwaremodul 323 verarbeitet werden, um eine Anwendungsbeispielinformations-(Info-)Datei 324 zu erzeugen, die Hintergrundinformationen und andere Informationen zum Anwendungsbeispiel liefern kann. Bei Bedarf können zusätzliche Softwaremodule die Quellendatei 318 verarbeiten, um Testspezifikationen und ähnliche Dokumentationen zu erzeugen.

Nach der Genehmigung des Testplans 322 ist der nächste Schritt die Erzeugung des Testcodes 320 aus der Quellendatei 318. Dieser Schritt wird von einem HPTC EXEC-Softwaremodul 319 ausgeführt, das die Kennzeichnungen und zugeordnete Kennzeichnungsparameter in der Quellendatei auswertet und einen Testcode mit Verbindungen zum entsprechenden Element in der Bibliothek ausführbarer Codeobjekte 314 erzeugt. In einer Ausführungsform verwendet der erzeugte automatisierte Testcode 320 das Verfahren "screen scraping technique", wobei die Befehle an die Systemelemente über codierte automatisierte Tastenanschlageingaben bereitgestellt werden, die in das entsprechende Systemelement eingegeben werden. In Fig. 31 wird ein Beispiel eines Teils eines HPTC EXEC-Codes dargestellt, der zum Übersetzen eines HPSRLM2-Testobjektes in einen Testcode verwendet wird. Ein Beispiel des erzeugten Testcodes 320, der aus dem HPSRLM2-Testobjekt übersetzt wurde, wird in Fig. 9E bei 910 gezeigt. Ein Beispiel der von der Testcodezeile 910 aufgerufenen Unterroutine wird in den Fig. 32A bis 32C gezeigt. Dieser Code befindet sich in der Bibliothek 327 für automatisierte ausführbare Unterroutinen. Antwortnachrichten vom Systemelement werden abgefangen und zur Feststellung verwendet, ob der Befehl normal ablief oder ob ein Fehler auftrat.

Die Fig. 9A bis 9F sind Diagramme, die eine Auflistung eines automatisierten Testcodes 320 zeigen, der aus der in Fig. 6 gezeigten Skriptdatei erzeugt wird. Die Auflistung beginnt in Fig. 9A mit kommentiertem Code (vorangestellte Zeichen "/*t" kennzeichnen Codekommentare), der die Aufgaben und das Szenario für das Anwendungsbeispiel beschreibt. Die Auflistung wird in Fig. 9B mit zusätzlichen Informationen bezüglich des Anwendungsbeispielnamens, der Quellendatei und mit anderen Informationen fortgesetzt. Der Rest von Fig. 9B sowie die Fig. 9C und 9D beschreiben veränderbare Definitionen für Szenariovariablen und aufgerufene Befehle. Fig. 9E stellt die Testcodebefehle dar.

Wiederum mit Bezugnahme auf Fig. 3 kann der Testcode ausgeführt werden 326, sobald er erzeugt wurde. Unter Verwendung des oben beschriebenen Verfahrens "screen-scraping technique" werden die Befehle zu den Systemelementen 132 gesendet, und Antwortnachrichten von der Systemelementen 132 werden verwendet, um das Testergebnis festzustellen und um festzustellen, ob die Testfehler gemeldet wurden. Falls keine Testfehler gemeldet wurden 328, werden die Testergebnisse dem Benutzer bereitgestellt, und das Anwendungsbeispiel ist beendet. Falls Testfehler gemeldet wurden 328, können sie durch Änderung der Anwendungsbeispiel-Quellendatei 318 und erneute Erzeugung des Testplans 322 und des automatisierten Testcodes 320 korrigiert werden. Einer der von der vorliegenden Erfindung bereitgestellten Vorteile ist die Verwendung der Quellendatei 318 zur automatischen Erzeugung des Testplans 322 und des automatisierten Testcodes 320. Wenn Fehler im Testplan 322 oder im Testcode 320 erkannt werden (durch Ausführen oder Kompilieren des Codes), können diese Fehler korrigiert werden, indem entsprechende Änderungen an der Quellendatei 318 vorgenommen werden. Folglich ist der Testcode 320 selbstdokumentierend, und der Benutzer muss nicht den zeitaufwendigen (und oftmals weggelassenen) Prozess des erneuten Schreibens des Testplans 322 auf sich nehmen, um gegenwärtigen Testverfahren zu entsprechen.

Im Vorhergehenden wird eine Quellendatei mit einer Vielzahl von Kennzeichnungen verwendet, die ausführbaren Codetestobjekten in der Bibliothek 314 für ausführbare Codetestobjekte zugeordnet werden. Obwohl die Verwendung zuvor definierter Testobjekte die Erzeugung des Testcodes 320 vereinfacht, muss der Benutzer noch immer entsprechende Kenntnisse der Syntax und der zugehörigen Parameter der Testverfahrensbefehle 602 bis 606 haben. Außerdem hängt der geeignete Wert für einen bestimmten Testbefehl in vielen Fällen von einer Funktion und einem Wert ab, die in einem anderen Teil des Testcodes ausgewählt werden. Die vorliegende Erfindung verbessert dieses Problem mit einer Anwendungsbeispiel-GUI 312, die mit der Computer-GUI 118B arbeitet. Wiederum mit Bezugnahme auf Fig. 3 unterstützt die Anwendungsbeispiel-GUI 312 den Benutzer bei der Erzeugung der Quellendatei 318, indem sie dem Benutzer die Anwendungsbeispieloptionen 304 präsentiert und eine Benutzereingabe 210 zum Auswählen der entsprechenden Optionen annimmt. Die Benutzeroptionen 304 werden von einem oder mehreren Sätzen von Regeln 306 festgelegt. Benutzeroptionen können außerdem kontextsensitiv sein. Das heißt, die für den Benutzer verfügbaren Optionen zum Ausführen einer bestimmten Testfunktion können entsprechend einer zuvor ausgewählten Benutzereingabe 210 dynamisch festgestellt werden. Wie sie hier beschrieben wird, ermöglicht die Anwendungsbeispiel-GUI 312 dem Benutzer außerdem die Umsetzung manuell eingegebener Anwendungsbeispielbefehle in Anwendungsbeispielobjekte und deren Speicherung in der Bibliothek 314 für ausführbare Codetestobjekte zur künftigen Verwendung.

Fig. 10 ist ein Flussdiagramm, das eine Übersicht über die Arbeitsgänge darstellt, die zum Erzeugen einer Quellendatei 318 unter Verwendung der Anwendungsbeispiel-GUI 312 verwendet werden. Als erstes wird dem Benutzer eine visuelle Darstellung der Elemente der Bibliothek 314 für ausführbare Codetestobjekte präsentiert, wie im Block 1002 gezeigt wird. Anschließend nimmt die Anwendungsbeispiel-GUI 312 eine Auswahl eines ersten Testobjektes in der visuellen Darstellung entgegen 1004. Sodann werden dem Benutzer Testoptionen für das erste Testobjekt zur Auswahl präsentiert 1006. Die Testoptionen definieren Testparameter zum Ausführen eines Teils des automatisierten Testverfahrens. Anschließend nimmt die Anwendungsbeispiel-GUI 312 vom Benutzer ausgewählte erste Testobjektoptionen entgegen, wie im Block 1008 gezeigt wird. Die ersten Testobjektoptionen werden in eine Kennzeichnung und einen zugeordneten Kennzeichnungsparameter umgesetzt, die schließlich in der Quellendatei 318 gespeichert werden 1012.

Fig. 11 ist ein Diagramm eines Startfensters für die Anwendungsbeispiel-GUI 312. Das Startfenster umfasst eine Vielzahl von Registerzungen 1102, 1104, 1106 und 1108 zum Navigieren des Startfensters. Die Registerzunge 1102 "New" ermöglicht dem Benutzer die Erzeugung eines neuen Testplans, die Registerzunge 1104 "Existing" ermöglicht es dem Benutzer, einen vorhandenen Testplan oder ein vorhandenes Anwendungsbeispiel zu bearbeiten und auszuführen, die Registerzunge 1106 "Recent" ermöglicht dem Benutzer die Überprüfung kürzlich erzeugter Testpläne oder Anwendungsbeispiele, und die Registerzunge 1108 "Tutorial" ermöglicht dem Benutzer den Zugang zu einem Lerntext über die Verwendung des Erstellungsprogramms für das Anwendungsbeispiel.

Fig. 12 zeigt für eine Ausführungsform das Aussehen der Anwendungsbeispiel-GUI 312, nachdem der Benutzer die Erzeugung eines neuen Anwendungsbeispiels gewählt hat. Die Anwendungsbeispiel-GUI 312 stellt nun ein Anwendungsbeispiel- Informationsfenster 1202 dar. Der Benutzer wird zur Eingabe des Anwendungsbeispielnamens in ein Anwendungsbeispielnamenfeld 1204, der Aufgabe des Anwendungsbeispiels in ein Testaufgabenfeld 1206 und einer Beschreibung des Anwendungsbeispiels in ein Beschreibungsfeld 1208 mit Zeilenumbruch aufgefordert. Nach der Eingabe der Informationen wählt der Benutzer die Schaltfläche 1210 "Next".

Fig. 13 zeigt für eine Ausführungsform das Aussehen der Anwendungsbeispiel-GUI 312. Hier fordert die Anwendungsbeispiel- GUI 312 den Benutzer zum Eingeben der Anwendungsbeispielkonfiguration mit einem Fenster 1302 "Select configuration" auf. Der Benutzer wählt die gewünschte Prozessorkonfiguration aus den im Fenster 1302 "Select configuration" dargestellten Optionen aus. Im gezeigten Beispiel hat der Benutzer eine Konfiguration mit drei Prozessoren ausgewählt. Wenn der Benutzer mit der Konfigurationsauswahl zufrieden ist, wird die Schaltfläche 1308 "Next" ausgewählt. Falls der Benutzer eine in einem vorhergehenden Fenster gemachte Eingabe ändern möchte, wird die Schaltfläche 1310 "Back" gewählt.

Fig. 14 ist ein Diagramm, das ein Beispiel der Anwendungsbeispiel-GUI 312 zeigt, die den Benutzer zum Eingeben einer schrittweisen Szenariobeschreibung auffordert. Dies wird durch die Darstellung eines Szenariobeschreibungsfensters 1402 "Step-by-step" ausgeführt. Der Benutzer gibt eine allgemeinsprachliche Beschreibung des Szenarios für das Anwendungsbeispiel in das Beschreibungsfeld 1404 ein. Nach Beendigung wählt der Benutzer die Tasten "Next" oder "Back", wie oben beschrieben wird. Die vorhergehenden Arbeitsgänge beenden die erste Phase der Erzeugung der Quellendatei.

Fig. 15 ist ein Diagramm, das ein Beispiel davon zeigt, wie die Anwendungsbeispiel-GUI 312 den Testentwickler zum Eingeben eines Autorennamens auffordert. Ein Autorenfeld 1504 wird in einem Fenster 1502 "Author name" bereitgestellt. Der Testentwickler gibt seinen Namen in das Autorennamenfeld 1502 ein und wählt die Schaltfläche 1506 "Next".

Fig. 16 ist ein Diagramm, das eine beispielhafte Anwendungsbeispiel-GUI 312 zeigt, die den Benutzer zum Auswählen einer Testkonfiguration auffordert. Dem Benutzer wird ein Fenster 1602 "Select configuration" präsentiert. Das Fenster 1602 "Select configuration" umfasst einen oder mehrere Dateneingabe- oder Optionsauswahlbereiche 1604 bis 1610 zum Auswählen aus den verfügbaren Konfigurationsoptionen. Im gezeigten Beispiel hat der Benutzer eine Konfiguration mit sechs Computern ausgewählt.

Fig. 17 ist ein Diagramm, das eine beispielhafte Anwendungsbeispiel-GUI 312 zeigt, die den Benutzer zum Auswählen unter RECON-Initialisierungsoptionen auffordert. Hier umfasst die Anwendungsbeispiel-GUI 312 ein Fenster 1702 "Initialize RECON", das eine Vielzahl von Dateneingabe- oder Optionsauswahlsteuerungen 1704 bis 1718 umfasst. Da der Benutzer zuvor eine Konfiguration mit sechs Computern ausgewählt hat, werden Computer eins bis sechs im Markierfeldbereich 1704 aufgelistet. Der Benutzer kann die Optionen für den Computer wählen, auf dem er das Objekt ausführen möchte, indem er das entsprechenden runde Markierfeld aus dem Bereich 1704 auswählt, anschließend die entsprechenden Daten für die restlichen Dateneingabekomponenten 1706 bis 1718 eingibt oder auswählt.

Fig. 18 ist ein Diagramm, das eine beispielhafte Anwendungsbeispiel-GUI 312 zeigt, die den Benutzer zum Auswählen von Datenbanktypen für das Anwendungsbeispiel auffordert. Hier enthält die GUI 312 ein Fenster 1802 "Select database types" und Eingabesteuerungen, die dem Benutzer die Auswahl des Datenbanktyps für das Anwendungsbeispiel ermöglichen.

Fig. 19 ist ein Diagramm, das eine beispielhafte Anwendungsbeispiel-GUI 312 zeigt, die den Benutzer auffordert, die Datenbanken auszuwählen, die für das Anwendungsbeispiel ausgewählt werden sollen. Dem Benutzer wird ein Fenster 1902 "Load database(s)" präsentiert, das eine Liste 1904 wählbarer Datenbanken, Markierfelder 1906 zur Auswahl einer gemeinsamen Stufe und ein Aktionsfenster-Feld (drop box) 1908 zum Angeben der Anzahl von Partitionen für die ausgewählte Datenbank umfasst. Die in der Datenbankliste 1904 aufgelisteten Datenbanken hängen von der Datenbanktypauswahl ab, die vom Benutzer in die in Fig. 18 dargestellte Anwendungsbeispiel-GUI 132 eingegeben wird.

Fig. 20 ist ein Diagramm, das eine beispielhafte Anwendungsbeispiel-GUI 312 zeigt, die den Benutzer zum Auswählen unter IRLM-Optionen auffordert. Dem Benutzer wird ein Fenster 2002 "Start IRLM" präsentiert. Der Benutzer kann wahlweise die IRLM auf allen Computerkonfigurationen (CEC) oder einer Gruppe von Computern starten, die im Fenster 1602 "Select configuration" angegeben wurden, wobei der Benutzer in letzterem Fall keine Optionen angeben kann, oder der Benutzer kann die IRLM-Optionen bei Bedarf auf eine einzelne CEC anwenden, indem er gewünschte Eingabebereiche auswählt. IRLM-Optionen, wie die Gruppe, der Sperr-Tabulator, die IRLM-ID und der IRLM-Name, werden mit Eingabekomponenten 2006 ausgewählt. Sobald der Benutzer die Eingabe der IRLM-Optionen beendet hat, ist die zweite Phase der Erzeugung des Testplans beendet.

Fig. 21 ist ein Diagramm, das eine beispielhafte Anwendungsbeispiel-GUI 312 zeigt, die den Benutzer zum Eingeben von Testverfahrensbefehlen auffordert. Die Anwendungsbeispiel- GUI 312 umfasst einen ersten Fensterteil (oder Objektfunktionen) 2102, der eine visuelle Darstellung der Elemente der Bibliothek 314 für ausführbare Codetestobjekte umfasst, die zum Erzeugen der Quellendatei 318 verwendet werden kann, und einen zweiten Fensterteil (oder Anwendungsbeispielfenster) 2104, der eine Auflistung der aktuellen Quellendatei 318 bereitstellt. Die Elementobjekte in der Bibliothek für ausführbare Codetests sind in alphabetischen Kategorien organisiert. Der Inhalt jeder Kategorie kann überprüft werden, indem das an die interessierende Kategorie angrenzende "+"-Symbol 2108 ausgewählt wird.

Fig. 22 ist ein Diagramm, das die beispielhafte Anwendungsbeispiel-GUI 312 zeigt, nachdem der Benutzer das "+"- Symbol 2108 ausgewählt hat, um die unter der Verbindungseinrichtungskategorie 2106 kategorisierten Bibliothekelementobjekte 2202 zu zeigen. Der hervorgehobene Bereich zeigt die aktuelle Zeile an, und neue Objekte werden nach der aktuellen Zeile in das Anwendungsbeispiel eingefügt. Wenn der Benutzer irgendeines der Bibliothekelementobjekte 2202 auswählt, wird ein Fenster geöffnet, um Parameteroptionen für dieses Bibliothekelementobjekt zu präsentieren.

Fig. 23 ist ein Diagramm, das die beispielhafte Anwendungsbeispiel-GUI 312 zeigt, nachdem der Benutzer das Bibliothekelementobjekt 2204 "CF Link Failure Recovery" in Fig. 22 ausgewählt hat. Hier wird ein CFLINK-Fenster 2302 angezeigt, das dem Benutzer die Parameteroptionen für "CF Link Failure/Recovery" präsentiert. Das CFLINK-Fenster 2302 enthält einen ON-Rahmen 2310 mit Eingabesteuerungen zum Auswählen der Konfiguration 2304 und einen Aktionsrahmen 2306 mit Eingabesteuerungen zum Auswählen, ob Fehler- oder Wiederherstellungsmaßnahmen vorgenommen werden sollen. Es sei darauf hingewiesen, dass eine Einzelcomputerkonfiguration ausgewählt wurde und nur eine CEC im ON-Rahmen 2310 angezeigt wird, da HPENTRY auf CONFIG = 30 gesetzt ist. Das Objektausgabe- Textfenster 2308 zeigt das syntaktische Objekt und seine(n) Parameter, die nach der hervorgehobenen Zeile 2314 in die Testquelle 2104 eingefügt werden.

Fig. 24 ist ein Diagramm, das zeigt, wie die Anwendungsbeispiel- GUI 312 zum reverse-parsing von Befehlen in der Quellendatei 318 verwendet werden kann. Hier hat der Benutzer die HPENTRY-Zeile 2206 durch Doppelklicken in den zweiten Fensterteil 2104 bei der HPENTRY-Zeile 2206 ausgewählt, wodurch das HPENTRY- Objektdefinitionsfenster 2402 geöffnet wird. Der Benutzer kann nun die HPENTRY-Testobjektparameter unter Verwendung der bereitgestellten Eingabesteuerungen ändern. Im dargestellten Beispiel hat der Benutzer eine Konfiguration mit sechs Prozessoren (HPENTRY = 12) in der Konfigurationsauswahl- Eingabesteuerung 2404 ausgewählt. Diese Einstellungen werden angenommen, wenn der Benutzer die Schaltfläche 2406 "Add object" auswählt, und die HPENTRY-Zeile 2206 wird im zweiten Fensterteil 2104 gemäß der angezeigten Objektausgabe 2408 geändert.

Fig. 25 ist ein Diagramm, das das Ergebnis des reverse-parsing zeigt, dessen Ausführung in Fig. 24 dargestellt wird. Es sei darauf hingewiesen, dass der ON-Rahmen 2310 des CFLINK-Fensters 2302 bei Auswahl des Bibliothekelementobjektes 2204 "CF Link Failure/Recovery" durch den Benutzer nun sechs Prozessoren in der Konfiguration kennzeichnet. Unter Verwendung der oben definierten Fähigkeit zum reverse-parsing kann der Benutzer die Quellendatei 318 direkt editieren. Die Anwendungsbeispiel-GUI 312 führt ein reverse-parsing der ausgewählten Zeilen aus und präsentiert dem Benutzer die verfügbaren Optionen, um eine fehlerhafte Eingabe zu verhindern. Der Benutzer kann die Quellendatei 318 editieren, indem er das Editierobjekt auf der Taskleiste auswählt und den Editiermodus anklickt.

Fig. 26 ist ein Diagramm, das eine andere Ausführungsform der Anwendungsbeispiel-GUI 312 zeigt. Hier hat der Benutzer die Anschlusskategorie 2602, die Bibliothekelementobjekte 2604 einschließlich eines Bibliothekelementobjektes 2606 "Use a live terminal" zeigt, und außerdem das Bibliothekelementobjekt 2606 "Use a live terminal" ausgewählt, wodurch ein Fenster 2606 "Set up a live terminal" geöffnet wird. Das Fenster 2606 "Set up a live terminal" stellt einen ON-Rahmen 2612, einen Anschlussoptionsrahmen 2608, einen Anschlussrahmen (terminal frame) 2614 und einen Anschlussrahmen 2616 dar. Die benötigten Eingabeparameter für das live terminal-Bibliothekelementobjekt 2606 werden hervorgehoben, indem die Farbe des Rahmens oder des den Rahmen bezeichnenden Textes geändert wird. Falls der Benutzer einen Wert in das kombinierte Fenster im Anschlussoptionsrahmen (terminal option frame) 2608 eingibt, wird dieser Wert für die Dauer der Anwendungsbeispiel- Entwicklungssitzung gespeichert. Das QuickInfo-Fenster (tooltip box) 2610 wird im ON-Rahmen 2612 angezeigt, um dem Benutzer kontextsensitive Hilfe bereitzustellen.

Fig. 27 ist ein Diagramm, das die Anwendungsbeispiel-GUI 312 zeigt, die eine andere Ausführungsform des Fensters 2702 "Set up a live terminal" zeigt. Hier hat der Benutzer eine Einzelprozessorkonfiguration ausgewählt, folglich präsentiert der ON-Rahmen 2612 lediglich die Option einer Einzelprozessorkonfiguration. Das Fenster 2702 zeigt außerdem, dass der Benutzer Daten in das kombinierte Fenster im Anschlussrahmen 2614 und in das kombinierte Fenster im Anschlussrahmen 2616 eingegeben hat.

Fig. 28 ist ein Diagramm, das die Anwendungsbeispiel-GUI 312 zeigt, nachdem der Benutzer ein Objekt im Quellencode 318 zum reverse-parsing ausgewählt hat. Hier enthält das durch den Markierungsbalken 2802 hervorgehobene IRLM-Objekt einen ungültigen Parameter (ON = AL), und die Anwendungsbeispiel-GUI 312 antwortet durch die, Darstellung eines Dialogfensters 2804 mit einer Fehlermeldung 2806, die den Fehler beschreibt und Hilfe anbietet.

Fig. 29 ist ein Diagramm, das die Anwendungsbeispiel-GUI 312 zeigt, die ein IRLM-Objektfenster 2902 darstellt. Zum Öffnen dieses Fensters klickte der Benutzer die OK-Schaltfläche im Dialogfenster 2804 an. Das IRLM-Objektfenster 2902 stellt einen ON-Rahmen 2904 dar, der rot hervorgehoben ist, um anzuzeigen, dass der Parameter ON = ausgewählt werden muss. Die Schaltfläche 2906 "Add object" bleibt inaktiviert, bis Werte für alle der benötigten Parameter eingegeben werden.

Schlußfolgerung

Dies schließt die Beschreibung der bevorzugten Ausführungsformen der vorliegenden Erfindung ab. Zusammengefasst beschreibt die vorliegende Erfindung ein Verfahren, eine Vorrichtung und ein Fertigungsprodukt zur Erzeugung eines Testcodes für ein automatisiertes Verfahren.

Das Verfahren umfasst die folgenden Schritte: visuelle Darstellung einer Bibliothek ausführbarer Codeobjekte, die eine Vielzahl von Testobjekten umfasst, für einen Benutzer, Annehmen einer Auswahl eines ersten Testobjektes in der visuellen Darstellung, Darstellen erster Testobjektoptionen, die mindestens einen Testparameter definieren, Annehmen einer Auswahl einer ersten Testoption, Umsetzen der ersten Testoption in mindestens eine Kennzeichnung und einen Kennzeichnungsparameter und Speichern der Kennzeichnung und des Kennzeichnungsparameters in einer Quellendatei. Das Fertigungsprodukt umfasst eine Datenspeichereinheit, die Befehle zum Ausführen der oben beschriebenen Verfahrensschritte eindeutig ausführt.

Die Vorrichtung umfasst Mittel, um einem Benutzer eine visuelle Darstellung einer Bibliothek ausführbarer Codeobjekte zu präsentieren. Die Bibliothek ausführbarer Codeobjekte enthält eine Vielzahl von Testobjektelementen, von denen jedes einen Befehlssatz zum Ausführen eines Teils des Testverfahrens definiert. Nominell umfasst das Mittel zum Ausführen dieser Funktion einen Computer, der geeignete Programmbefehle ausführt. Die Vorrichtung umfasst außerdem Mittel, beispielsweise einen eine grafische Benutzerschnittstelle realisierenden Computer, um eine Auswahl eines ersten Testobjektes in der visuellen Darstellung anzunehmen, Testoptionen für das ausgewählte Testobjekt darzustellen und eine Testobjektoption anzunehmen. Die Vorrichtung umfasst außerdem ein Mittel zum Umsetzen der ersten Testoption in mindestens eine Kennzeichnung und mindestens einen Kennzeichnungsparameter, die in einer Quellendatei gespeichert werden.

Die vorliegende Erfindung ermöglicht Benutzern eine schnelle Erzeugung und Fehlerbehebung von selbstdokumentierenden Anwendungsbeispielen. Dies wird ausgeführt, indem dem Benutzer eine Bibliothek von Testobjekten bereitgestellt wird, von denen jedes einer Kennzeichnung zugeordnet ist. Der Benutzer erzeugt eine Quellendatei unter Verwendung der Kennzeichnungen zur Bezugnahme auf die gewünschten Testobjekte. Zur weiteren Unterstützung des Benutzers wird eine Anwendungsbeispiel-GUI bereitgestellt, die eine visuelle Darstellung der Testobjekte in der Bibliothek und eine Auflistung des Quellencodes präsentiert. Der Benutzer kann den Quellencode erstellen, indem er die geeignete Position in der Quellencodedatei und das entsprechende Testcodeobjekt auswählt. Der Benutzer wird zum Wählen zwischen einer Auswahl von Testcodeobjektparametern aufgefordert, wodurch die Möglichkeit ausgeschlossen wird, dass der Benutzer Testobjektparameter auswählt, die nicht vorkommen oder außerhalb des Bereichs liegen. Außerdem sind die Eingabeaufforderungen der GUI für den Benutzer insofern kontextsensitiv, als die dem Benutzer präsentierten Optionen von den gegenwärtig im Quellencode enthaltenen Testobjekten und Parameterauswahlen abhängig sein können.

Die vorliegende Erfindung stellt außerdem ein vereinheitlichtes Verfahren zur Erzeugung des Testcodes und zur Erzeugung einer allgemeinsprachlichen Dokumentation des Testcodes bereit. Dies vereinfacht das Testdokumentationsverfahren und gewährleistet, dass die eigentlichen Testverfahren mit dem gegenwärtigen Testplan übereinstimmen.

Die vorhergehende Beschreibung der bevorzugten Ausführungsform der Erfindung dient der Erläuterung und Beschreibung. Sie soll weder erschöpfend sein noch die Erfindung auf die genaue beschriebene Form begrenzen. Viele Änderungen und Varianten sind im Hinblick auf die obige Lehre möglich. Es ist vorgesehen, dass der Anwendungsbereich der Erfindung nicht durch diese ausführliche Beschreibung, sondern statt dessen durch die angehängten Ansprüche begrenzt wird. Die obigen Angaben, Beispiele und Daten stellen eine vollständige Beschreibung der Herstellung und Verwendung der Zusammensetzung der Erfindung bereit. Da viele Ausführungsformen der Erfindung realisiert werden können, ohne von Wesensart und Umfang der Erfindung abzuweichen, ist die Erfindung in den im Folgenden angehängten Ansprüchen enthalten.

Claims

1. Verfahren zur Erzeugung eines Testcodes zum Ausführen eines Testverfahrens, das auf ein System mit einer Vielzahl miteinander verbundener Elemente angewandt werden kann, wobei das Verfahren die folgenden Schritte umfasst:
Präsentieren einer visuellen Darstellung einer Bibliothek ausführbarer Codeobjekte, die eine Vielzahl von Testobjektelementen in einem Fenster umfasst, wobei jedes Element einen Befehlssatz zum Ausführen eines Teils eines Testverfahrens umfasst;
Annehmen einer Auswahl eines ersten Testobjektes in der visuellen Darstellung;
Darstellen erster Testobjektoptionen, wobei die ersten Testobjektoptionen mindestens einen Testparameter zum Ausführen von mindestens einem Teil des Testverfahrens definieren;
Annehmen einer Auswahl einer ersten Testoption;
Umsetzen der ersten Testobjektoption in mindestens eine Kennzeichnung und mindestens einen Kennzeichnungsparameter; und
Speichern der Kennzeichnung und des Kennzeichnungsparameters in einer Quellendatei.

2. Verfahren nach Anspruch 1, das außerdem die Schritte des Erzeugens des Testcodes aus der Quellendatei umfasst.

3. Verfahren nach Anspruch 1, das außerdem die Schritte des Erzeugens eines geschriebenen Testplans aus der Quellendatei umfasst.

4. Verfahren nach Anspruch 1, wobei die Bibliothek ausführbarer Codeobjekte ein erstes Testobjektelement umfasst, das einen Befehlssatz zum Ausführen von Verfahrensschritten definiert, die die folgenden Schritte umfassen:
Ausgeben eines Befehls an ein Systemelement; und
Abfangen einer Nachricht, die auf den Befehl vom aufgerufenen Element anspricht.

5. Verfahren nach Anspruch 1, das außerdem die folgenden Schritte umfasst:
Annehmen einer Auswahl eines zweiten Testobjektes in der visuellen Darstellung; und
Darstellen zweiter Testobjektoptionen für den Benutzer, wobei die Testobjektoptionen mindestens einen Testparameter zum Ausführen eines zweiten Teils des Testverfahrens definieren und wobei die zweiten Testobjektoptionen von der Auswahl erster Testobjektoptionen abhängig sind.

6. Verfahren nach Anspruch 1, wobei die visuelle Darstellung der Bibliothek ausführbarer Codeobjekte in einem ersten Teil des Fensters dargestellt wird und das Verfahren außerdem den Schritt des Darstellens der Quellendatei in einem zweiten Teil des Fensters umfasst.

7. Verfahren nach Anspruch 6, das außerdem die folgenden Schritte umfasst:
Annehmen einer Auswahl einer zweiten Kennzeichnung in der Quellendatei vom zweiten Teil des Fensters, wobei die zweite Kennzeichnung einem zweiten Testobjekt zugeordnet ist;
Darstellen zweiter Testoptionen für das zweite Testobjekt;
Annehmen einer Auswahl einer zweiten Testobjektoption;
Umsetzen der zweiten Testobjektoption in mindestens einen zweiten Kennzeichnungsparameter; und
Speichern der zweiten Kennzeichnung und des zweiten Kennzeichnungsparameters in der Quellendatei.

8. Vorrichtung zur Erzeugung eines Testcodes zum Ausführen eines Testverfahrens, das auf ein System mit einer Vielzahl miteinander verbundener Elemente angewandt werden kann, die Folgendes umfasst:
Mittel zum Präsentieren einer visuellen Darstellung einer Bibliothek ausführbarer Codeobjekte, die eine Vielzahl von Testobjektelementen in einem Fenster umfasst, wobei jedes Element einen Befehlssatz zum Ausführen eines Teils eines Testverfahrens definiert;
Mittel zum Annehmen einer Auswahl eines ersten Testobjektes in der visuellen Darstellung;
Mittel zum Darstellen erster Testobjektoptionen, wobei die ersten Testobjektoptionen mindestens einen Testparameter zum Ausführen von mindestens einem Teil des Testverfahrens definieren;
Mittel zum Annehmen einer Auswahl einer ersten Testoption;
Mittel zum Umsetzen der ersten Testobjektoption in mindestens eine Kennzeichnung und mindestens einen Kennzeichnungsparameter; und
Mittel zum Speichern der Kennzeichnung und des Kennzeichnungsparameters in einer Quellendatei.

9. Vorrichtung nach Anspruch 7, die außerdem Mittel zum Erzeugen des Testcodes aus der Quellendatei umfasst.

10. Vorrichtung nach Anspruch 9, die außerdem Mittel zum Erzeugen eines geschriebenen Testplans aus der Quellendatei umfasst.

11. Vorrichtung nach Anspruch 8, wobei die Bibliothek ausführbarer Codeobjekte ein erstes Testobjektelement umfasst, die Folgendes umfasst:
Mittel zum Ausgeben eines Befehls an ein aufgerufenes Systemelement; und
Mittel zum Abfangen einer Nachricht, die auf den Befehl vom aufgerufenen Element anspricht.

12. Vorrichtung nach Anspruch 8, die außerdem Folgendes umfasst:
Mittel zum Annehmen einer Auswahl eines zweiten Testobjektes in der visuellen Darstellung; und
Mittel zum Darstellen zweiter Testobjektoptionen für den Benutzer, wobei die Testobjektoptionen mindestens einen Testparameter zum Ausführen eines zweiten Teils des Testverfahrens definieren und wobei die zweiten Testobjektoptionen von der Auswahl erster Testobjektoptionen abhängig sind.

13. Vorrichtung nach Anspruch 8, wobei die visuelle Darstellung der Bibliothek ausführbarer Codeobjekte in einem ersten Teil des Fensters dargestellt wird und wobei die Vorrichtung außerdem Mittel zum Darstellen der Quellendatei in einem zweiten Teil des Fensters umfasst.

14. Vorrichtung nach Anspruch 13, die außerdem Folgendes umfasst:
Mittel zum Annehmen einer Auswahl einer zweiten Kennzeichnung in der Quellendatei vom zweiten Teil des Fensters, wobei die zweite Kennzeichnung einem zweiten Testobjekt zugeordnet ist;
Mittel zum Darstellen zweiter Testoptionen für das zweite Testobjekt;
Mittel zum Annehmen einer Auswahl einer zweiten Testobjektoption;
Mittel zum Umsetzen der zweiten Testobjektoption in mindestens einen zweiten Kennzeichnungsparameter; und
Mittel zum Speichern der zweiten Kennzeichnung und des zweiten Kennzeichnungsparameters in der Quellendatei.

15. Von einem Computer lesbare Programmspeichereinheit, die mindestens ein Programm von Befehlen beinhaltet, die zum Ausführen von Verfahrensschritten vom Computer ausgeführt werden können, um ein Testverfahren auszuführen, das auf ein System mit einer Vielzahl miteinander verbundener Elemente anwendbar ist, wobei das Verfahren die folgenden Schritte umfasst:
Präsentieren einer visuellen Darstellung einer Bibliothek ausführbarer Codeobjekte, die eine Vielzahl von Testobjektelementen in einem Fenster umfasst, wobei jedes Element einen Satz von Befehlen zum Ausführen eines Teils eines Testverfahrens definiert;
Annehmen einer Auswahl eines ersten Testobjektes in der visuellen Darstellung;
Darstellen erster Testobjektoptionen, wobei die ersten Testobjektoptionen mindestens einen Testparameter zum Ausführen von mindestens einem Teil des Testverfahrens definieren;
Annehmen einer Auswahl einer ersten Testobjektoption;
Übersetzen der ersten Testobjektoption in mindestens eine Kennzeichnung und mindestens einen Kennzeichnungsparameter; und
Speichern der Kennzeichnung und des Kennzeichnungsparameters in einer Quellendatei.

16. Programmspeichereinheit nach Anspruch 15, wobei die Verfahrensschritte außerdem die Verfahrensschritte des Erzeugens des Testcodes aus der Quellendatei umfassen.

17. Programmspeichereinheit nach Anspruch 16, wobei die Verfahrensschritte außerdem die Schritte des Erzeugens eines geschriebenen, allgemeinsprachlichen Testplans aus der Quellendatei umfassen.

18. Programmspeichereinheit nach Anspruch 15, wobei die Bibliothek ausführbarer Codeobjekte ein erstes Testobjektelement umfasst, das einen Satz von Befehlen zum Ausführen von Verfahrensschritten definiert, die die folgenden Schritte umfassen:
Ausgeben eines Befehls an ein aufgerufenes Systemelement; und
Abfangen einer Nachricht, die auf den Befehl vom aufgerufenen Element anspricht.

19. Programmspeichereinheit nach Anspruch 15, wobei die wobei die Verfahrensschritte außerdem die folgenden Schritte umfassen:
Annehmen einer Auswahl eines zweiten Testobjektes in der visuellen Darstellung; und
Darstellen zweiter Testobjektoptionen für den Benutzer, wobei die Testobjektoptionen mindestens einen Testparameter zum Ausführen eines zweiten Teils des Testverfahrens definieren und wobei die zweiten Testobjektoptionen von der Auswahl erster Testobjektoptionen abhängig sind.

20. Programmspeichereinheit nach Anspruch 15, wobei die visuelle Darstellung der Bibliothek ausführbarer Codeobjekte in einem ersten Teil des Fensters dargestellt wird und die Verfahrensschritte außerdem den Verfahrensschritt des Darstellens der Quellendatei in einem zweiten Teil des Fensters umfassen.

21. Programmspeichereinheit nach Anspruch 20, wobei die Verfahrensschritte außerdem die folgenden Schritte umfassen:
Annehmen einer Auswahl einer zweiten Kennzeichnung in der Quellendatei aus dem zweiten Teil des Fensters, wobei die zweite Kennzeichnung einem zweiten Testobjekt zugeordnet ist;
Darstellen zweiter Testobjektoptionen für das zweite Testobjekt;
Annehmen einer Auswahl einer zweiten Testobjektoption;
Übersetzen der zweiten Testobjektoption in mindestens einen zweiten Kennzeichnungsparameter; und
Speichern der zweiten Kennzeichnung und des zweiten Kennzeichnungsparameters in der Quellendatei.