-
GEBIET DER ERFINDUNG
-
Die vorliegende Erfindung betrifft allgemein die Erzeugung von Testfällen und genauer die Ableitung verallgemeinerter Testfälle zur Verwendung in Regressionstests.
-
HINTERGRUND
-
Regressionstests beinhalten die Wiederholung von Tests, die für ein System entwickelt wurden, um ein korrektes Verhalten des Systems zu gewährleisten und etwaige Softwarefehler oder Regressionen in bestehenden funktionalen und nicht-funktionalen Bereichen des Systems aufzudecken. Typischerweise werden Regressionstests durchgeführt, nachdem Änderungen, beispielsweise Verbesserungen, Patches oder Konfigurationsänderungen, an dem System vorgenommen worden sind. Durch Regressionstests soll gewährleistet werden, dass die am System vorgenommenen Änderungen keine Ausnahme- oder Programmfehler in das System eingeschleust haben. Regressionstests können nicht nur verwendet werden, um zu prüfen, ob ein Programm fehlerfrei ist, sondern auch, um die Qualität seiner Ausgabe nachzuverfolgen.
-
Wenn Regressionstests für Client/Server-Systeme entwickelt werden, stellt das Testen der APIs (Anwendungsprogrammierschnittstellen) einen wichtigen Teil davon dar. Tests-Clients werden programmiert, um mit dem Server zu interagieren und Antworten zu prüfen, die vom Server kommend empfangen werden. Allerdings ist die manuelle Entwicklung von Test-Clients eine aufwändige Sache, die Leute mit profunden Kenntnissen der Server-APIs und bedeutenden Programmierfähigkeiten erfordert.
-
KURZFASSUNG
-
Ausführungsformen der vorliegenden Erfindung geben ein Verfahren, ein System und ein Computerprogrammprodukt zur Erzeugung eines verallgemeinerten Testfalls an. Ein erster Computer empfängt eine oder mehrere vordefinierte Äquivalenzklassen, wobei eine vordefinierte Äquivalenzklasse einen oder mehrere im Wesentlichen äquivalente Werte umfasst. Der erste Computer empfängt mehrere Nachrichten, die zwischen einem zweiten Computer und einem dritten Computer gesendet werden, wobei jede Nachricht von den mehreren Nachrichten mindestens einen Parameter aufweist und jeder Parameter mindestens einen Entsprechungswert aufweist. Der erste Computer bestimmt, ob mindestens einer von den in den mehreren Nachrichten enthaltenen Parametern mindestens einen Entsprechungswert aufweist, der mit einem oder mehreren Werten einer vordefinierten Äquivalenzklasse übereinstimmt. Der erste Computer erzeugt eine oder mehrere wertbestimmte (value driven) Äquivalenzklassen, wobei jede wertbestimmte Äquivalenzklasse einen oder mehrere Parameter umfasst, und wobei der eine bzw. jeder von den mehreren Parametern in jeder wertbestimmten Äquivalenzklasse den gleichen Entsprechungswert aufweist. Der erste Computer erzeugt einen verallgemeinerten Testfall, wobei der verallgemeinerte Testfall die mindestens eine oder die mehreren wertbestimmten Äquivalenzklassen beinhaltet.
-
KURZBESCHREIBUNG DER MEHREREN ZEICHNUNGSDARSTELLUNGEN
-
1 zeigt ein Testfallerzeugungssystem zur Erzeugung eines verallgemeinerten Testfalls gemäß einer Ausführungsform der Erfindung.
-
Die 2 und 3 sind Flussdiagramme, die die Operationen eines Testfallerzeugungsprogramms bei der Erzeugung eines verallgemeinerten Testfalls gemäß einer Ausführungsform der Erfindung zeigen.
-
4 ist ein Blockdiagramm, das die Hardware-Komponenten des Testfallerzeugungsprogramms von 1 gemäß einer Ausführungsform der Erfindung abbildet.
-
AUSFÜHRLICHE BESCHREIBUNG
-
Der Fachmann wird erkennen, dass Aspekte der vorliegenden Erfindung als System, als Verfahren oder als Computerprogrammprodukt verwirklicht werden können. Somit können Aspekte der vorliegenden Erfindung als reine Hardware-Komponenten, reine Software-Komponenten (einschließlich Firmware, systemeigener Software, Mikrocode usw.) oder als Ausführungsform verwirklicht werden, in der Software- und Hardware-Aspekte kombiniert sind, die hierin mit dem Überbegriff „Schaltung”, „Modul” oder „System” bezeichnet werden können. Ferner können Aspekte der vorliegenden Erfindung als Computerprogrammprodukt verwirklicht werden, das in einem oder mehreren computerlesbaren Medien verkörpert ist, auf dem bzw. auf denen computerlesbare(r) Programmcode/-befehle verkörpert sind.
-
Es kann jede Kombination aus einem oder mehreren computerlesbaren Medien verwendet werden. Das computerlesbare Medium kann ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium sein. Beispiele für computerlesbare Speichermedien sind unter anderem elektronische, magnetische, optische, elektromagnetische, Infrarot- oder Halbleitersysteme, -geräte oder -vorrichtungen oder jede geeignete Kombination der genannten. Als konkretere Beispiele (ohne Anspruch auf Vollständigkeit) für das computerlesbare Speichermedium können die folgenden genannt werden: eine elektrische Verbindung über eines oder mehrere Kabel, eine portable Computerdiskette, eine Festplatte, ein RAM (random access memory), ein ROM (read-only memory), ein EPROM (erasable programmable read-only memory oder Flash memory), ein Lichtwellenleiter, eine portable CD-ROM (compact disc read-only memory), eine optische Speichervorrichtung oder jede geeignete Kombination der genannten. Im Kontext dieses Dokuments kann ein computerlesbares Speichermedium jedes physische Medium sein, das ein Programm zur Verwendung in oder in Verbindung mit Befehlsausführungssystemen, -geräten oder vorrichtungen enthält oder speichert.
-
Ein computerlesbares Signalmedium kann ein weitergegebenes Daten- bzw. Ausgabesignal, in dem beispielsweise computerlesbarer Programmcode verkörpert ist, in einem Basisband oder als Teil einer Trägerwelle beinhalten. Solch ein weitergegebenes Signal kann eine beliebige von verschiedenen Formen aufweisen, unter anderem kann es elektromagnetisch, optisch oder irgendeine geeignete Kombination davon sein. Ein computerlesbares Signalmedium kann irgendein computerlesbares Medium sein, bei dem es sich nicht um ein computerlesbares Speichermedium handelt und das ein Programm zur Verwendung in oder in Verbindung mit Befehlsausführungssystemen, -geräten oder -vorrichtungen weitergeben, verbreiten oder transportieren kann.
-
Programmcode, der auf einem computerlesbaren Medium verkörpert ist, kann unter Verwendung jedes geeigneten Mediums versendet werden, unter anderem drahtlos, über Kabel, Lichtwellenleiter, HF usw. oder jede geeignete Kombination der genannten.
-
Computerprogrammcode zur Ausführung von Operationen für Aspekte der vorliegenden Erfindung können in jeder Kombination aus einer oder mehreren Programmiersprachen geschrieben sein, einschließlich einer objektorientierten Programmiersprache wie Java, Smalltalk, C++ oder dergleichen, und herkömmlicher prozeduraler Programmiersprachen, wie der „C”-Programmiersprache oder ähnlicher Programmiersprachen. Der Programmcode kann nur auf dem Computer eines Anwenders, zum Teil auf dem Computer eines Anwenders, als eigenständiges Softwarepaket, zum Teil auf dem Computer eines Anwenders und zum Teil auf einem Remote-Computer oder ganz auf dem Remote-Computer oder Server ausgeführt werden. Im letztgenannten Szenario kann der Remote-Computer über irgendeine Art von Netz, einschließlich eines LAN (local area network) oder eines WAN (wide area network) mit dem Computer eines Anwenders verbunden sein, oder die Verbindung kann mit einem externen Computer (beispielsweise über das Internet mithilfe eines Internetdienstanbieters) hergestellt werden.
-
Aspekte der vorliegenden Erfindung werden nachstehend unter Bezugnahme auf Darstellungen von Flussdiagrammen und/oder Blockdiagrammen von Verfahren, Geräten (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es sei klargestellt, dass jeder Block der dargestellten Flussdiagramme und/oder Blockdiagramme und Kombinationen von Blöcken in den dargestellten Flussdiagramme und/oder Blockdiagramme durch Computerprogrammbefehle implementiert werden kann bzw. können. Diese Computerprogrammbefehle können an einen Prozessor eines nicht zweckgebundenen Computers, eines zweckgebundenen Computers oder eines anderen programmierbaren Datenverarbeitungsgeräts zur Erzeugung einer Maschine ausgegeben werden, so dass die Befehle, die über den Prozessor des Computers oder des anderen programmierbaren Datenverabeitungsgeräts ausgeführt werden, eine Einrichtung schaffen zur Implementierung der Funktionen/Aktionen, die in dem Block oder den Blöcken im Flussdiagramm und/oder Blockdiagramm angegeben sind.
-
Diese Computerprogrammbefehle können auch in einem computerlesbaren Medium gespeichert werden, das einen Computer, ein anderes programmierbares Datenverabeitungsgerät oder andere Vorrichtungen dazu bringen kann, auf bestimmte Weise zu funktionieren, so dass die Befehle, die in dem computerlesbaren Befehl gespeichert sind, ein Erzeugnis bilden, das Befehle enthält, welche die Funktion/Aktion, die im Block oder in den Blöcken des Flussdiagramms und/oder Blockdiagramms angegeben sind, implementieren.
-
Die Computerprogrammbefehle können auch in einen Computer, ein anderes programmierbares Datenverabeitungsgerät oder in andere Vorrichtungen geladen werden, um die Durchführung einer Abfolge von Operationsschritten in dem Computer, dem anderen programmierbaren Datenverabeitungsgerät oder den anderen Vorrichtungen zu bewirken, um einen computerimplementierten Prozess zu erzeugen, so dass die Befehle, die in dem Computer oder dem anderen programmierbaren Datenverabeitungsgerät ausgeführt werden, Prozesse zur Implementierung der Funktionen/Aktionen liefern, die im Block oder in den Blöcken des Flussdiagramms und/oder Blockdiagramms angegeben sind.
-
Nun werden Ausführungsformen der vorliegenden Erfindung ausführlich unter Bezugnahme auf die begleitenden Figuren beschrieben.
-
1 zeigt ein Testfallerzeugungssystem 100 gemäß einer Ausführungsform der Erfindung. In einem Ausführungsbeispiel beinhaltet das Testfallerzeugungssystem 100 einen Server 110, eine Client-Vorrichtung 120 und eine Testfallvorrichtung 140, die alle über ein Netz 130 miteinander verbunden sind,
-
In dem Ausführungsbeispiel ist das Netz 130 das Internet, welches eine weltumspannende Zusammenstellung von Netzen und Zugängen darstellt, die eine Kommunikation zwischen Vorrichtungen unterstützen, die mit dem Internet verbunden sind. Das Netz 130 kann beispielsweise Kabel-, drahtlose oder Lichtwellenleiterverbindungen beinhalten. In anderen Ausführungsformen kann das Netz 130 als Intranet, als LAN (local area network) oder als WAN (wide area network) implementiert sein. Generell kann das Netz 130 jede Kombination aus Verbindungen und Protokollen sein, die eine Kommunikation zwischen dem Server 110, der Client-Vorrichtung 120 und der Testfallvorrichtung 140 unterstützt.
-
Der Server 110 beinhaltet ein Severprogramm 112. In dem Ausführungsbeispiel kann der Server 110 ein Desktop-Computer, ein Notebook, ein Laptop-Computer, ein Tablet-Computer, eine Handheld-Vorrichtung, ein Smartphone, ein Thin Client oder irgendeine andere elektronische Vorrichtung oder irgendein anderes Rechnersystem sein, die bzw. das in der Lage ist, über das Netz 130 Daten von und zu anderen Rechenvorrichtungen, wie der Client-Vorrichtung 120 und der Testfallvorrichtung 140, zu empfangen bzw. zu senden. Auch wenn der Server 110 als einzelne Vorrichtung dargestellt ist, kann der Server 110 in anderen Ausführungsformen aus einem Cluster oder einer Mehrzahl von Rechenvorrichtungen bestehen, die zusammen oder jede für sich arbeiten. Der Server 110 wird unter Bezugnahme auf 4 näher beschrieben.
-
In dem Ausführungsbeispiel ist das Server-Programm 112 eine Software, die in der Lage ist, über das Netz 130 Anfragen einer anderen Rechenvorrichtung, beispielsweise der Client-Vorrichtung 120, zu empfangen und über das Netz 130 Antworten auf die Anfragen zurück zur Rechenvorrichtung zu senden.
-
Die Client-Vorrichtung 120 beinhaltet ein Client-Programm 122. In dem Ausführungsbeispiel kann die Client-Vorrichtung 120 ein Desktop-Computer, ein Notebook, ein Laptop-Computer, ein Tablet-Computer, eine Handheld-Vorrichtung, ein Smartphone, ein Thin Client oder irgendeine andere elektronische Vorrichtung oder irgendein anderes Rechnersystem sein, die bzw. das in der Lage ist, über das Netz 130 Daten von und zu anderen Rechenvorrichtungen, wie dem Server 110 und der Testfallvorrichtung 140, zu empfangen bzw. zu senden. Auch wenn die Testfallvorrichtung 140 als einzelne Vorrichtung dargestellt ist, kann die Testfallvorrichtung 140 in anderen Ausführungsformen aus einem Cluster oder einer Mehrzahl von Rechenvorrichtungen bestehen, die zusammen oder jede für sich arbeiten. Die Testfallvorrichtung 140 wird unter Bezugnahme auf 4 näher beschrieben.
-
In dem Ausführungsbeispiel ist das Client-Programm 122 eine Software, die in der Lage ist, über das Netz 130 Anfragen an andere Rechenvorrichtungen, beispielsweise den Server 110, zu senden und über das Netz 130 Antworten auf die Anfragen von den anderen Rechenvorrichtungen zu empfangen.
-
Die Testfallvorrichtung 140 beinhaltet ein Testfallprogramm 142. In dem Ausführungsbeispiel kann die Testfallvorrichtung 140 ein Desktop-Computer, ein Notebook, ein Laptop-Computer, ein Tablet-Computer, eine Handheld-Vorrichtung, ein Smartphone, ein Thin Client oder irgendeine andere elektronische Vorrichtung oder irgendein anderes Rechnersystem sein, die bzw. das in der Lage ist, über das Netz 130 Daten von und zu anderen Rechenvorrichtungen, wie dem Server 110 und dem Client-Programm 120, zu empfangen bzw. zu senden. Auch wenn die Testfallvorrichtung 140 als einzelne Vorrichtung dargestellt ist, kann die Testfallvorrichtung 140 in anderen Ausführungsformen aus einem Cluster oder einer Mehrzahl von Rechenvorrichtungen bestehen, die zusammen oder jede für sich arbeiten. Die Testfallvorrichtung 140 wird unter Bezugnahme auf 4 näher beschrieben.
-
In dem Ausführungsbeispiel ist das Testfallprogramm 142 Software, die in der Lage ist, Nachrichten, beispielsweise Anfragen und Antworten, die zwischen dem Server 110 und der Client-Vorrichtung 120 über das Netz 130 gesendet werden, zu empfangen oder aufzufangen. Außerdem ist das Testfallprogramm 142 in der Lage, die empfangenen oder aufgefangenen Nachrichten zu analysieren und auf Basis der empfangenen oder aufgefangenen Nachrichten einen verallgemeinerten Testfall zu erzeugen. Ferner ist das Testfallprogramm 142 auch in der Lage, über eine Anwenderschnittstelle Eingaben von einem Anwender zu empfangen und die Eingabe über das Netz 130 an andere Rechenvorrichtungen, beispielsweise den Server 110 und die Client-Vorrichtung 120, zu senden.
-
2 ist ein Flussdiagramm, das die Operationen des Testfallprogramms 142 bei der Analyse von Nachrichten, die zwischen dem Server 110 und der Client-Vorrichtung 120 gesendet werden, und der Erzeugung eines verallgemeinerten Testfalls auf Basis der analysierten Nachrichten gemäß einem Ausführungsbeispiel der Erfindung zeigt. In einem Ausführungsbeispiel empfängt das Testfallprogramm 142 eine oder mehrere vordefinierte Äquivalenzklassen (Schritt 202). In dem Ausführungsbeispiel werden die eine oder werden die mehreren vordefinierten Aquivalenzklassen von einem Administrator oder Programmierer auf Basis von Versions- bzw. Design-Time-Kenntnissen formuliert. Was den assoziierten Wert eines Parameters betrifft, so erzeugen viele serverbasierte Systeme auf das Design bezogene Werte, die Präfixe zur Verfügung stellen, die für in Betracht kommende Ressourcen spezifisch sind. Zum Beispiel werden für einen WebSphere Process Server® (eingetragene Marke von IBM) Werte eines Typs „TKTID” mit sämtlichen Parametern assoziiert, die Prozessaufgabendefinitionskennungen wie „taskDefID” oder der Pluralform „taskDefIDs” entsprechen. Wichtig ist in diesem Zusammenhang, dass Variationen dieses Wertes, wie TKTID.1 oder TKTID.2, in manchen Fällen auf dynamische Weise vom Server 110 erzeugt werden können. Alle Variationen des Wertes, die TKTID als Präfix enthalten, werden für die Zwecke der Erzeugung von verallgemeinerten Testfällen als gleichwertig betrachtet. Eine vordefinierte Äquivalenzklasse wird entworfen, um diese Gleichwertigkeit widerzuspiegeln. In dem Ausführungsbeispiel ist eine vordefinierte Äquivalenzklasse ein Satz von Parametern, die einen Wert zur Verfügung stellen, der Teil eines vordefinierten Wertesatzes ist. Ein vordefinierter Wertesatz kann explizit als einer, der aus einem bestimmten Satz von Werten besteht, oder implizit unter Verwendung von Wertebeschränkungen definiert werden. Was Wertebeschränkungen betrifft, so kann beispielsweise ein vordefinierter Wertesatz als ein beliebiger Wert definiert werden, der mit dem Präfix TKTID anfängt. Unter Verwendung dieses vordefinierten Wertesatzes für ein Testmuster, das assoziierte Werte TKTID.1 und TKTID.2 aufweist, und eines Parameters, der einen assoiierten Wert TKTID.1 aufweist, können in der vorliegenden Ausführungsform beide von diesen Parametern derselben vordefinierten Äquivalenzklasse zugeordnet werden, da sie beide assoziierte Werte aufweisen, die das Präfix TKTID enthalten.
-
In anderen Ausführungsformen kann auf Basis von Design-Time-Kenntnissen von einem Administrator eine vordefinierte Äquivalenzklasse als Satz von Parametern definiert werden, die in bestimmten Rufen vorkommen. Ein Parameter wird eindeutig durch „methodID” und „parameterID” identifiziert. Ein Administrator kann dann Design-Time-Kenntnisse anwenden, um Parameter, die gleiche oder ähnliche Kennungen aufweisen, der gleichen vordefinierten Äquivalenzklasse zuzuteilen. Da beispielsweise „getTaskDefinitions.output.taskDefIDs” und „createTask.input.taskDefID” die gleiche parameterID (taskDefID) enthalten, kann sich ein Administrator mit Design-Time-Kenntnissen dafür entscheiden, beide von diesen Parametern einer vordefinierten Äquivalenzklasse zuzuteilen. Außerdem kann in diesem Ausführungsbeispiel das Testfallprogramm 142 auch eine oder mehrere vordefinierte Testausschlussklassen empfangen; allerdings kann es sein, dass das Testfallprogramm 142 in anderen Ausführungsformen keinerlei vordefinierte Testausschlussklassen empfängt. In dem Ausführungsbeispiel ist eine vordefinierte Ausschlussklasse einer vordefinierten Äquivalenzklasse ähnlich, abgesehen davon, dass eine vordefinierte Ausschlussklasse ein Satz von Parametern ist, die der Administrator nicht testen will. Daher kann ein Administrator mit Design-Time-Kenntnissen vordefinierte Ausschlussklassen erzeugen, so dass bestimmte Parameter von Tests am Testfall ausgeschlossen werden.
-
Das Testfallprogramm 142 empfängt dann eine Nachricht, die zwischen der Client-Vorrichtung 120 und dem Server 110 gesendet wird (Schritt 204). In dem Ausführungsbeispiel ist die empfangene Nachricht Teil eines Testmusters, das eine endliche Anzahl von Nachrichten enthält.
-
Das Testfallprogramm 142 bestimmt dann, ob der Parameter in der Nachricht den Anforderungen einer vordefinierten Äquivalenzklasse genügt (Entscheidung 206). In dem Ausführungsbeispiel enthält die Nachricht nur einen Parameter, jedoch kann die Nachricht in anderen Ausführungsformen mehrere Parameter enthalten, und in solchen Fällen analysiert das Testfallprogramm 142 jeden Parameter, der in der Nachricht enthalten ist, unabhängig, um zu bestimmen, ob der Parameter den Anforderungen einer vordefinierten Äquivalenzklasse genügt. Was das obige Beispiel betrifft, so bestimmt das Testfallprogramm 142 für eine vordefinierte Äquivalenzklasse, die definiert ist in Bezug auf assoziierte Werte mit bestimmten Wertebeschränkungen, beispielsweise Werte, die das Präfix „TKTID” enthalten, ob der Parameter in der empfangenen Nachricht einen assoziierten Wert aufweist, der das Präfix „TKTID” enthält. Falls das Testfallprogramm 142 bestimmt, dass der Parameter in der empfangenen Nachricht Teil einer vordefinierten Äquivalenzklasse ist (Entscheidung 206, „JA”-Zweig), assoziiert das Testfallprogramm 142 den Parameter mit der geeigneten wertbestimmten Äquivalenzklasse (Schritt 208). Wenn das Testfallprogramm 142 beispielsweise bestimmt, dass der Parameter Teil einer vordefinierten Äquivalenzklasse ist, und der Parameter zwei assoziierte Werte aufweist, beispielsweise TKTID.1 und TKTID.2 wie oben angegeben, dann erzeugt das Testfallprogramm 142 zwei wertbestimmte Äquivalenzklassen, eine für jeden assoziierten Wert, der jeweils den Parameter enthält. Eine wertbestimmte Äquivalenzklasse ist ein Satz von Parametern, die den gleichen assoziierten Wert aufweisen. Anders als vordefinierte Werteklassen können sie nicht im Hinblick auf Wertebeschränkungen oder Präfixe definiert werden, sondern stattdessen müssen Parameter in einer wertbestimmten Äquivalenzklasse den gleichen assoziierten Wert aufweisen. Betrachtet man das oben angegebene Beispiel, so kann eine wertbestimmte Äquivalenzklasse definiert sein als Satz von Parametern, in dem jeder Parameter einen assoziierten Wert TKTID.1 aufweist, und eine andere wertbestimmte Äquivalenzklasse kann definiert sein als Satz von Parametern, in dem jeder Parameter einen assoziierten Wert TKTID.2 aufweist.
-
Falls das Testfallprogramm 142 bestimmt, dass der Parameter in der empfangenen Nachricht nicht Teil einer vordefinierten Äquivalenzklasse ist (Entscheidung 206, „NEIN”-Zweig), bestimmt das Testfallprogramm 142, ob der Parameter den Anforderungen einer vordefinierten Ausschlussklasse genügt (Entscheidung 210). Falls das Testfallprogramm 142 bestimmt, dass der Parameter den Anforderungen einer vordefinierten Ausschlussklasse genügt (Entscheidung 210, „JA”-Zweig), assoziiert das Testfallprogramm 142 den Parameter mit einer „no test” (nicht zu testenden) Klasse (Schritt 212). In dem Ausführungsbeispiel beinhaltet eine „no test”-Klasse Parameter, die nicht getestet werden. Sobald das Testfallprogramm 142 einen verallgemeinerten Testfall erzeugt hat, wird dieser Testfall später vom Testfallprogramm 142 verwendet, um zu verifizieren, dass ein Programm ordnungsgemäß funktioniert. Sobald der Testfall erzeugt worden und einsatzbereit ist, nimmt die Testfallvorrichtung 140 zum Beispiel die Stelle einer Client-Vorrichtung 120 ein, und das Testfallprogramm 142 kommuniziert mit dem Server-Programm 112 auf die gleiche Weise wie das Client-Programm 122. In dem Ausführungsbeispiel sendet das Testfallprogramm 142 die Nachrichten, die vom Client-Programm 122 in dem Testmuster gesendet werden, und verifiziert, dass die Antworten des Server-Programms 112 mit den Antworten des Testmusters übereinstimmen. Falls beispielsweise bei einer ersten und einer zweiten Antwort des Server-Programms 112 jede Antwort einen Parameter enthält, wobei beide Parameter zu ein und derselben wertbestimmten Äquivalenzklasse gehören, dann sollten die assoziierten Werte beider Parameter gleich sein. Falls die assoziierten Werte nicht gleich sind, dann kann ein Fehler oder ein Problem mit dem Server-Programm 112 vorliegen. In dem Ausführungsbeispiel werden Werte für Parameter, die zur „no test”-Klasse gehören, vom Testfallprogramm 142 nicht verifiziert.
-
Falls das Testfallprogramm 142 bestimmt, dass der Parameter den Anforderungen einer vordefinierten Ausschlussklasse nicht genügt (Entscheidung 210, „NEIN”-Zweig), assoziiert das Testfallprogramm 142 den Parameter mit einer „value test” (Wertetest-)Klasse (Schritt 214). Parameter, die mit einer „value test”-Klasse assoziiert sind, werden vom Testfallprogramm 142 jeweils einzeln verifiziert. Sobald der verallgemeinerte Testfall erzeugt worden ist, verifiziert das Testfallprogramm 142 zum Beispiel einen Parameter, der mit „value test” assoziiert ist, durch Verifizieren, ob der Wert, der mit dem Parameter assoziiert ist, mit dem Wert übereinstimmt, der während der Erstellung des Testfalls erzeugt worden ist.
-
Das Testfallprogramm 142 bestimmt dann, ob alle Nachrichten im Testmuster zwischen dem Server 110 und der Client-Vorrichtung 120 gesendet worden sind (Entscheidung 216). Wenn das Testprogramm 142 bestimmt, dass nicht alle Nachrichten im Testmuster zwischen dem Server 110 und der Client-Vorrichtung 120 gesendet worden sind (Entscheidung 126, „NEIN”-Zweig), kehrt das Testfallprogramm 142 zurück zu Schritt 204 und analysiert die nächste Nachricht im Testmuster.
-
Wenn das Testprogramm 142 bestimmt, dass alle Nachrichten im Testmuster zwischen dem Server 110 und der Client-Vorrichtung 120 gesendet worden sind (Entscheidung 126, „JA”-Zweig), dann bestimmt das Testfallprogramm 142, ob irgendeine der erstellten wertbestimmten. Äquivalenzklassen nur einen einzigen assoziierten Parameter enthält (Entscheidung 302). Falls das Testfallprogramm 142 bestimmt, dass keine der gebildeten wertbestimmten Äquivalenzklassen nur einen einzigen assoziierten Parameter enthält (Entscheidung 302, „NEIN”-Zweig), erzeugt das Testfallprogramm 142 einen verallgemeinerten Testfall aus den erzeugten wertbestimmten Äquivalenzklassen und „value test”-Klassen (Schritt 306).
-
Falls das Testfallprogramm 142 bestimmt, dass eine oder mehrere wertbestimmte Äquivalenzklassen nur einen einzigen assoziierten Parameter enthält bzw. enthalten (Entscheidung 302, „JA”-Zweig), entfernt das Testfallprogramm 142 die eine oder die mehreren wertbestimmten Äquivalenzklassen und assoziiert die in den entfernten wertbestimmten Äquivalenzklassen. enthaltenen Parameter mit einer „no test”-Klasse (Schritt 304). Das Testfallprogramm 142 erzeugt dann einen verallgemeinerten Testfall aus den verbliebenen wertbestimmten Äquivalenzklassen und „value test”-Klassen (Schritt 306).
-
Sobald der verallgemeinerte Testfall erzeugt worden ist, nimmt die Testfallvorrichtung 140 die Stelle der Client-Vorrichtung 140 ein, und das Testmuster wird erneut ausgeführt. Das Testfallprogramm 142 verifiziert dann durch einen Vergleich mit dem verallgemeinerten Testfall, ob die Server-Antwort richtig ist. Werte für Parameter, die einer „value test”-Klasse zugeteilt sind, werden durch einen Vergleich mit dem für die „value test”-Klasse aufgezeichneten Wert im verallgemeinerten Testfall verifiziert. Falls der Wert mit dem aufgezeichneten Wert übereinstimmt, ist die Server-Antwort verifiziert und richtig. Werte für einen Parameter, der zu einer wertbestimmten Äquivalenzklasse gehört, werden durch einen Vergleich mit Werten anderer Mitglieder der wertbestimmten Äquivalenzklasse verifiziert. Wenn zum Beispiel ein erster Parameter, der zu einer ersten wertbestimmten Äquivalenzklasse gehört, mit einem entsprechenden Wert A empfangen wird und dann ein zweiter Parameter, der auch zur ersten wertbestimmten Äquivalenzklasse gehört, mit einem entsprechenden Wert A empfangen wird, dann werden die beiden Parameter verglichen, um zu bestimmen, ob sie übereinstimmen. Falls sie übereinstimmen, wird die Server-Antwort verifiziert. Außerdem wird zur Verifizierung eines Mitglieds einer wertbestimmten Äquivalenzklasse der Wert, der im verallgemeinerten Testfall aufgezeichnet ist, nicht für Verifizierungszwecke verwendet. Werte von Mitgliedern von wertbestimmten Äquivalenzklassen werden stattdessen mit anderen Werten verglichen, die der wertbestimmten Äquivalenzklasse entsprechen und die während der gleichen Iteration des Testmusters empfangen werden. Anders ausgedrückt wird der Wert A des ersten Parameters mit dem Wert des zweiten Parameters verglichen, um die Richtigkeit zu bestimmen, wenn beide Parameter während der gleichen Iteration des Testmusters empfangen werden. In vorangehenden oder folgenden Iterationen des Testmusters kann der erste Parameter andere assoziierte Werte aufweisen, jedoch sollten die Werte für jede wertbestimmte Äquivalenzklasse in der jeweiligen Iteration übereinstimmen.
-
In anderen Ausführungsformen kann maschinelles Lernen angewendet werden, um einen verallgemeinerten Testfall aus mehreren Testmustern zu erzeugen. In dieser Ausführungsform kann eine Rechenvorrichtung, beispielsweise eine Testfallvorrichtung 140, vordefinierte Äquivalenzklassen empfangen oder kann einen verallgemeinerten Testfall ganz ohne vordefinierte Äquivalenzklassen erzeugen. Falls vordefinierte Äquivalenzklassen verwendet werden, verarbeitet das Testfallprogramm 142 mehrere Testmuster und erzeugt wertbestimmte Äquivalenzklassen, „value test”-Klassen und „no test”-Klassen auf ähnliche Weise wie oben beschrieben. Falls keine wertbestimmten Äquivalenzklassen verwendet werden, verarbeitet das Testfallprogramm 142 mehrere Testmuster, wobei jeder von den unterschiedlichen Parametern jeweils als „value test”-Klasse bezeichnet wird. Daher verarbeitet das Testfallprogramm 142 das erste Testmuster, wobei es zu Anfang jeden Parameter mit einem eindeutigen assoziierten Wert bezeichnet, als „value test”-Klasse.
-
Innerhalb des ersten Testmusters ist jeder Parameter außerdem mit seiner eigenen wertbestimmten Äquivalenzklasse assoziiert, die den Parameter selbst und sämtliche anderen Parameter enthält, die den gleichen Wert zur Verfügung stellen. Für alle folgenden Testmuster werden die Testklassifikation ebenso wie die assoziierte wertbestimmte Äquivalenzklasse für jeden Parameter neu berechnet. Ein Parameter wird in „equiv test” (Äquivalenztest-)Klasse geändert, wenn der Parameter im vorangehenden Testmuster „value test” war und der Parameterwert im aktuellen Testmuster von demjenigen im vorangehenden Testmuster verschieden ist. Andernfalls bleibt die Testklasse die gleiche. Außerdem werden die Parameter, die einen Wert zur Verfügung stellen, der sich vom Wert des Parameters im aktuellen Testmuster unterscheidet, aus der wertbestimmten Klasse, die mit dem Parameter assoziiert ist, gelöscht. Nachdem die Testmuster und zugehörigen Berechnungen abgeschlossen worden sind, wird jeder als „equiv test” klassifizierte Parameter mit einer wertbestimmten Äquivalenzklasse, die nur einen Parameter enthält, in „no test” umklassifiziert.
-
Wenn zum Beispiel Testmuster 1 und Testmuster 2 wie folgt sind: Testmuster 1
Method-ID | Eingabe/Ausgabe | Parameter-ID | Wert |
Methode 1 | Eingabe | P1 | aVal1 |
| Ausgabe | P2 | aVal1 |
Methode 2 | Eingabe | P3 | aVal1 |
| Ausgabe | P4 | aVal1 |
Testmuster 2
Method-ID | Eingabe/Ausgabe | Parameter-ID | Wert |
Verfahren 1 | Eingabe | P1 | aVal1 |
| Ausgabe | P2 | aVal2 |
Verfahren 2 | Eingabe | P3 | aVal2 |
| Ausgabe | P4 | aVal3 |
-
Das Testfallprogramm 142 fuhrt das Testmuster 1 aus und teilt jeden Parameter zu Anfang der „value test”-Klasse zu und erzeugt gleichzeitig eine wertbestimmte Äquivalenzklasse für jeden Parameter im ersten Testmuster. Daher klassifiziert das Testfallprogramm 142 jeden Parameter als „value test” und erzeugt außerdem eine wertbestimmte Äquivalenzklasse, die alle vier Parameter enthält, da sie im ersten Testmuster alle den gleichen Wert zur Verfügung stellen.
-
Dann führt das Testfallprogramm 142 das zweite Testmuster aus. Das Testfallprogramm 142 klassifiziert den ersten Parameter P1 Wertetest, da er im zweiten Testmuster den gleichen Wert zur Verfügung stellt wie im ersten Testmuster, und erzeugt außerdem eine erste wertbestimmte Äquivalenzklasse, die den ersten Parameter enthält. Das Testfallprogramm 142 klassifiziert den zweiten Parameter als „equiv test”, da der Wert, der vom Parameter P2 im zweiten Testmuster zur Verfügung gestellt wird, von dem Wert, der im ersten Testmuster zu Verfügung gestellt wird, verschieden ist. Das Testfallprogramm 142 erzeugt eine zweite wertbestimmte Äquivalenzklasse, die den zweiten Parameter enthält. Das Testfallprogramm 142 klassifiziert außerdem den dritten Parameter P3 als „equiv test” und stellt ihn in die zweite Äquivalenzklasse, da der Wert, der vom dritten Parameter im zweiten Testmuster zur Verfügung gestellt wird, dem Wert gleich ist, der vom zweiten Parameter zur Verfügung gestellt wird. Das Testfallprogramm 142 klassifiziert den vierten Parameter als „equiv test” und erzeugt eine dritte wertbestimmte Äquivalenzklasse, die den vierten Parameter enthält. Nach der Ausführung der Testmuster bestimmt das Testfallprogramm 142, ob eine der wertbestimmten Äquivalenzklassen nur einen einzigen Parameter enthält. In diesem Beispiel enthalten die erste und die vierte wertbestimmte Äquivalenzklasse nur einen einzigen Parameter, so dass sie entfernt werden. Der erste Parameter bleibt ein „value test”, während der vierte Parameter in „no test” umklassifiziert wird.
-
Die obige Beschreibung verschiedener Ausführungsformen der vorliegenden Erfindung wurde nur zur Erläuterung und Beschreibung vorgelegt. Sie erhebt weder Anspruch auf Vollständigkeit, noch soll sie die Erfindung auf genau die offenbarte Form beschränken. Es sind viele Modifikationen und Variationen möglich. Solche Modifikationen und Variationen, die für einen Fachmann naheliegen, sollen im Bereich der Erfindung, wie er in den beigefügten Ansprüchen definiert ist, eingeschlossen sein.
-
4 zeigt ein Blockdiagramm von Komponenten des Servers 110, der Client-Vorrichtung 120 und der Testfallvorrichtung 140 gemäß einer erläuternden Ausführungsform. Man beachte, dass 4 nur ein Beispiel für eine Implementierung zeigt und keinerlei Beschränkungen in Bezug auf die Umgebung impliziert, in der verschiedene Ausführungsformen implementiert werden können. Es können zahlreiche Modifikationen an der abgebildeten Umgebung vorgenommen werden.
-
Der Server 110, die Client-Vorrichtung 120 und die Testfallvorrichtung 140 können eine Kommunikationsmatrix 402 beinhalten, die eine Kommunikation zwischen einem oder mehreren Computerprozessoren 404), einem Memory bzw. Arbeitsspeicher 406, einem persistenten Speicher 408, einer Kommunikationseinheit 412 und einer oder mehreren Eingabe/Ausgabe-(I/O)-Schnittstellen 414 ermöglicht.
-
Der Memory bzw. Arbeitsspeicher 406 und der persistente Speicher 408 sind Beispiele für computerlesbare, physische Speichervorrichtungen und Medien. Bei dem Memory bzw. Arbeitsspeicher 406 kann es sich beispielsweise um einen oder mehrere RAMs (random access memories) 416, einen Cache 418 oder irgendeine andere geeignete flüchtige oder nichtflüchtige Speichervorrichtung handeln.
-
Die Programme Server-Programm 112 im Server 110; Client-Programm 122 in der Client-Vorrichtung 120; und Testfallprogramm 142 in der Testfallvorrichtung 140 sind im persistenten Speicher 408 zur Ausführung durch einen oder mehrere der entsprechenden Computerprozessoren 404 über einen oder mehrere Arbeitsspeicher des Arbeitsspeichers 406 gespeichert. In der in 4 dargestellten Ausführungsform beinhaltet der persistente Speicher 408 einen Flash-Memory. Alternativ oder zusätzlich zum Flash-Memory kann ein persistenter Speicher 408 eine Magnetplattenspeichervorrichtung einer internen Festplatte, ein Solid State Drive, eine Halbleiterspeichervorrichtung, einen ROM (read-only memory), einen EPROM oder irgendeine andere computerlesbare physische Speichervorrichtung beinhalten, die in der Lage ist, Programmbefehle oder digitale Informationen zu speichern.
-
Die vom persistenten Speicher 408 verwendeten Medien können auch abnehmbar bzw. mobil sein. Zum Beispiel kann eine mobile Festplatte als persistenter Speicher 408 verwendet werden. Andere Beispiele beinhalten eine optische oder eine Magnetplatte, die zur Übertragung auf eine andere Speichervorrichtung, die ebenfalls Teil des persistenten Speichers 408 ist, in ein Laufwerk eingeschoben wird, oder andere mobile Speichervorrichtungen, wie einen Speicherstick oder eine Smart Card.
-
Die Kommunikationseinheit 412 in diesen Beispielen ermöglicht eine Kommunikation mit anderen Datenverarbeitungssystemen oder -vorrichtungen. In diesen Beispielen beinhaltet die Kommunikationseinheit 412 eine oder mehrere Netzwerkkarten. Die Kommunikationseinheit 412 kann eine Kommunikation durch die Verwendung von physischen und/oder drahtlosen Kommunikationsverbindungen ermöglichen. Die Programme Server-Programm 112 im Server 110; Client-Programm 122 in der Client-Vorrichtung 120 und Testfallprogramm 142 in der Testfallvorrichtung 140 können über die Kommunikationseinheit 412 in den persistenten Speicher 408 heruntergeladen werden.
-
Die I/O-Schnittstelle(n) 414 ermöglichen die Ein- und Ausgabe von Daten mit anderen Vorrichtungen, die mit dem Server 110, der Client-Vorrichtung 120 und der Testfallvorrichtung 140 verbunden sein können. Zum Beispiel kann die I/O-Schnittstelle 414 eine Verbindung mit externen Vorrichtungen 420 wie einer Tastatur, einem Tastenfeld, einem Touchscreen und/oder einer anderen geeigneten Eingabevorrichtung ermöglichen. Externe Vorrichtungen 420 können auch mobile computerlesbare Speichermedien beinhalten wie beispielsweise Speichersticks, mobile optische oder Magnetplatten und Speicherkarten. Software und Daten, die verwendet werden, um Ausführungsfomen der vorliegenden Erfindung in die Praxis umzusetzen, z. B. die Programme Server-Programm 112 im Server 110; Client-Programm 122 in der Client-Vorrichtung 120; und Testfallprogramm 142 in der Testfallvorrichtung 140, können auf solch einem mobilen computerlesbaren Speichermedium gespeichert werden und können über eine oder mehrere I/O-Schnittstellen 414 in den persistenten Speicher 408 geladen werden. Die mindestens eine I/O-Schnittstelle kann auch mit einer Anzeige 422 verbunden sein.
-
Die Anzeige 422 stellt einen Mechanismus bereit, um einem Anwender Daten anzuzeigen, und kann beispielsweise ein Computermonitor sein.
-
Die hierin beschriebenen Programme werden auf Basis der Anwendung identifiziert, für die sie in einer bestimmten Ausführungsform der Erfindung implementiert werden. Jedoch sei klargestellt, dass jede konkrete Programmbenennung hierin nur aus Gründen der Zweckmäßigkeit verwendet wird und dass die Erfindung nicht auf die Verwendung irgendeiner konkreten Anwendung beschränkt sein soll, die durch eine solche Benennung identifiziert und/oder impliziert wird.
-
Die Ablauf- und Blockdiagramme in den Figuren zeigen die Architektur, die Funktionalität und die Betriebsweise möglicher Implementierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. Was dies betrifft, so kann jeder Block im Flussdiagramm oder in den Blockdiagrammen ein Modul, ein Segment oder einen Abschnitt eines Codes darstellen, das bzw. der einen oder mehrere ausführbare Befehle zur Implementierung der konkreten logischen Funktion(en) umfasst. Man beachte außerdem, dass in manchen alternativen Ausführungsformen die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren angegeben kommen können. Zum Beispiel können zwei nacheinander dargestellte Blöcke eigentlich im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal in umgekehrter Reihenfolge ausgeführt werden, abhängig von der beteiligten Funktionalität. Es sei außerdem klargestellt, dass jeder Block der dargestellten Blockdiagramme und/oder Flussdiagramme und Kombinationen aus Blöcken in den dargestellten Blockdiagrammen und/oder Flussdiagrammen durch auf Hardware basierende zweckgebundene Systeme, die die angegebenen Funktionen oder Aktionen ausführen, oder durch zweckgebundene Hardware und Computerbefehle implementiert werden können.