DE60010011T2

DE60010011T2 - Verfahren und Vorrichtung zur Prüfung eines Rechnersystems durch Software-Fehlerinjektion

Info

Publication number: DE60010011T2
Application number: DE60010011T
Authority: DE
Inventors: Jongki Suwandi; Madhusudhan Talluri
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1999-10-21
Filing date: 2000-10-18
Publication date: 2005-01-20
Anticipated expiration: 2020-10-19
Also published as: EP1094391B1; EP1094391A1; US6701460B1; ATE265064T1; DE60010011D1

Description

Zu Grunde liegende Anmeldung
Diese Anmeldung beansprucht hiermit Priorität gemäss dem Patentgesetz der Vereinigten Staaten von Amerika, § 119, für die vorläufige Patentanmeldung Nr. 60/160,996 mit dem Titel "Fault Injection Method For Multi-Node Clusters", eingereicht am 21. Oktober 1999.
HINTERGRUND Gebiet der Erfindung
Die vorliegende Erfindung betrifft Mechanismen zum Testen von Computersystemen. Genauer betrifft die vorliegende Erfindung ein Verfahren und eine Vorrichtung zum Testen eines Computersystems durch Injizieren von Fehlern in das Computersystem, während es arbeitet.
Verwandte Technik
Der Bedarf an zuverlässigen Computersystemen hat zur Entwicklung von "hochverfügbaren" Computersystemen geführt, die weiterhin funktionieren, wenn eines) oder mehrere der Teilsysteme und/oder der Komponenten in einem Computersystem ausfällt bzw. ausfallen.
Um sicherzustellen, dass hochverfügbare Computersysteme korrekt arbeiten, ist es erforderlich, eine sehr strenge Testung auszuführen. Diese Testung wird dadurch erschwert, dass hochverfügbare Computersysteme typisch eine große Anzahl an Komponenten und Teilsystemen enthalten, die Fehlern unterliegen. Außerdem umfasst ein Betriebssystem für ein hochverfügbares Computersystem eine große Anzahl von Pfaden, um mit Fehlerzuständen umzugehen, die ebenfalls getestet werden müssen.
Einige Arten der Testung können manuell ausgeführt werden, beispielsweise indem eine Computersystemkomponente herausgezogen wird, ein Kabel abgetrennt wird oder indem eine Computersystemkarte herausgezogen wird, während das Computersystem arbeitet. Jedoch ist ein Resultat dieser Art der manuellen Testung typisch nicht wiederholbar und ungenau, da das manuell ausgelöste Ereignis an zufälligen Punkten auf dem Ausführungspfad eines Programms und/oder Betriebssystems auftreten kann, das gerade auf dem hochverfügbaren Computersystem ausgeführt wird.
Es sind ein Verfahren und eine Vorrichtung erforderlich, die das Testen eines Computersystems durch Injizieren von Fehlern an präzise bestimmten Stellen auf dem Ausführungspfad eines Betriebssystems und/oder Programms, das auf einem Computersystem ausgeführt wird, vereinfachen.
Von BLOUGH, D.M. u. a. ist unter dem Titel "Fault-Injection-Based Testing of Fault-Tolerant Algorithms in Message-Passing Parallel Computers" in: Proceedings of the International Symposium on Fault Tolerant Computing (FTCS), Los Alamitos, USA, IEEE Comp. Soc. Press, 24. Juni 1997, S. 256-257 eine Verfahrensweise für eine Fehlerinjektion in Parallelrechner mit verteiltem Speicher, die ein Nachrichten-Weitergabe-Paradigma verwendet, vorgestellt worden. Die Methode beruht auf einer Injektion von Fehlern in die Kommunikation zwischen Prozessoren unter Verwendung eines fehlertoleranten aufspannenden Binomial-Baum-Übertragungsalgorithmus (FTSB-Übertragungsalgorithmus) und erlaubt die Emulation von Fehlermodellen, die gemeinhin bei der Entwicklung von fehlertoleranten parallelen Algorithmen verwendet werden. Die Verfahrensweise bezieht die Verwendung einer auf Software beruhenden Fehlerinjektion ein, wobei eine Fehlerinjektions-Aufrufbibliothek eine Sammlung von Fehlerinjektionsnachrichten übergebenden Funktionsaufrufen liefert.
In den Proceedings of the International Symposium on Fault Tolerant Computing (FTCS), Los Alamitos, USA, IEEE Comp. Soc. Press, Bd. Smp. 23, 22. Juni 1993, S. 208-217, wird von ROSENBERG, H. u. a. unter "Software Fault Injection and its Application in Distributed Systems" ein Software-Fehlerinjektionswerkzeug beschrieben, das ermöglicht, Kombinationen von Fehlerarten in die Knoten eines verteilten Echtzeitsystems zu injizieren, das Mehrprozessorenknoten umfasst, die durch ein Punkt-zu-Punkt-Netzwerk verbunden sind. Das Software-Fehlerinjektionswerkzeug (SFI-Werkzeug) umfasst zwei Hauptkomponenten: einen SFI-Experimentgenerator, der ausführbare Dateien erzeugt, um anwenderdefinierte Fehlerinjektionsexperimente laufen zu lassen, und ein SFI-Steuermodul, das die Routinen umfasst, die für die tatsächliche Fehlerinjektion und die Fähigkeit zur Verhaltensänderung sorgen.
In WEI-LUN KAO u. a.:"DEFINE: a distributed fault Injection and monitoring environment", in: Fault-Tolerant Parallel and Distributed Systems (Kat.-Nr. 94TH0628-8), Proceedings of IEEE Workshop on Fault-Tolerant Parallel and Distributed Systems, College Station, Texas, USA, 12. bis 14. Juni 1994, Los Alamitos, USA, 1995, IEEE Comp. Soc. Press, S. 252-259, ist eine verteilte Fehlerinjektions- und Überwachungsumgebung ("DEFINE") beschrieben, die (i) Hardware-Taktunterbrechungen verwendet, um den Zeitpunkt der Fehlerinjektion und -aktivierung zu steuern, und (ii) Software-Programmunterbrechungen verwendet, um sämtliche Fehler, mit Ausnahme der Kommunikationsfehler und Speicherfehler in dem Daten/Stapelregister-Segment, zu injizieren. Ein Befehl wird an einer ausgewählten Stelle durch eine erste Software-Programmunterbrechung ersetzt. Wenn der Unterbrechungsbefehl abgearbeitet wird, wird eine Nachricht mit der Fehlerzeit, dem Fehlertyp und dem Ort aufgezeichnet. Dann wird der Unterbrechungsbefehl durch den Befehl ersetzt, der den bestimmten Fehler emuliert, und der nächste Befehl wird durch eine zweite Software-Programmunterbrechung ersetzt. Der falsche Befehl wird durch die erste Software-Programmunterbrechung oder den ursprünglichen Befehl ersetzt, wenn die zweite Software-Programmunterbrechung abgearbeitet ist.
In WPI Database, Section EI, Woche 199849, Derwent Publications Ltd., Forschungsmitteilung RD414091, IBM Corporation, ist ein Fehlerinjektionsverfahren zum Testen verteilter Systeme von Servern in vernetzten Computersystemen beschrieben, welche die Verwendung eines Vorprozessors mit sich bringen, wobei das Verfahren jedem Ereignis in dem Quellcode eine eindeutige Kennung zuordnet, die verwendet wird, um ganz bestimmte Punkte zu kennzeichnen, in denen Fehler injiziert werden sollen.
ZUSAMMENFASSUNG
Die vorliegende Erfindung schafft, in Übereinstimmung mit den beigefügten unabhängigen Ansprüchen 1 bzw. 8, ein Verfahren und eine Vorrichtung zum Testen eines Computersystems unter Verwendung von Software, um Fehler in das Computersystem zu injizieren, während es arbeitet. Während dieses System arbeitet, ist es einem Programmierer möglich, einen Fehlerpunkt in einen Quellcode für ein Programm einzufügen. Dieser Fehlerpunkt bewirkt das Auftreten eines Fehlers, falls ein dem Fehlerpunkt zugeordneter Trigger gesetzt ist und falls ein Ausführungspfad des Programms durch den Fehlerpunkt verläuft. Das System ermög licht, diesen Quellcode in ausführbaren Code zu kompilieren. Danach ermöglicht das System, das Computersystem zu testen. Dieses Testen umfasst das Setzen des Triggers für den Fehlerpunkt und dann das Ausführen des ausführbaren Codes, so dass der Fehler auftritt, falls der Ausführungspfad durch den Fehlerpunkt verläuft. Außerdem umfasst dieses Testen das Überprüfen des Ergebnisses der Ausführung.
In einer Ausführungsform der vorliegenden Erfindung führt dann, wenn auf den Fehlerpunkt gestoßen wird, während der ausführbare Code ausgeführt wird, das System den Fehlerpunkt aus, indem ein Trigger, der dem Fehlerpunkt zugeordnet ist, nachgeschlagen wird, bestimmt wird, ob der Trigger gesetzt worden ist und der Code ausgeführt wird, der dem Fehlerpunkt zugeordnet ist, falls der Trigger gesetzt worden ist.
In einer Ausführungsform der vorliegenden Erfindung ruft der Fehlerpunkt eine Fehlerfunktion auf, die das Auftreten des Fehlers bewirkt.
In einer Ausführungsform der vorliegenden Erfindung enthält der Fehlerpunkt Code, der das Auftreten des Fehlers bewirkt.
In einer Ausführungsform der vorliegenden Erfindung besitzt der Trigger globale Geltung und ist in einem Kernadressraum eines Betriebssystems in dem Computersystem gespeichert.
In einer Ausführungsform der vorliegenden Erfindung ist der Trigger in einer Umgebungsvariablen gespeichert, die einem Verfahrensaufrufbefehl zugeordnet ist.
In einer Ausführungsform der vorliegenden Erfindung ist der Trigger in einer Objektreferenz gespeichert. In einer Abwandlung dieser Ausführungsform bewirkt der Trigger, dass der Fehler erzeugt wird, wenn das Objekt, auf das referiert wird, aufgerufen wird.
In einer Ausführungsform der vorliegenden Erfindung kann der Fehler enthalten: eine Computersystem-Reboot-Operation, eine Computersystem-Panikoperation, eine Rückgabe von Fehlercode, eine erzwungene Änderung des Steuerablaufs, einen Betriebsmittelzuweisungsfehler, eine Antwortverzögerung und eine Verklemmung bzw. Systemblockade.
KURZBESCHREIBUNG DER FIGUREN
1 veranschaulicht ein Cluster-Computersystem gemäß einer Ausführungsform der vorliegenden Erfindung;
2 veranschaulicht Software in einem Computersystem gemäß einer Ausführungsform der vorliegenden Erfindung;
3 veranschaulicht das Testverfahren gemäß einer Ausführungsform der vorliegenden Erfindung;
4 veranschaulicht einen Fehlerpunkt gemäß einer Ausführungsform der vorliegenden Erfindung;
5 veranschaulicht einen Trigger gemäß einer Ausführungsform der vorliegenden Erfindung;
6 veranschaulicht den Ort eines Fehlerpunkts gemäß einer Ausführungsform der vorliegenden Erfindung;
7 veranschaulicht die Verwendung eines Umgebungs-Triggers gemäß einer Ausführungsform der vorliegenden Erfindung;
8 veranschaulicht die Verwendung eines Umgebungs-Triggers in einem verschachtelten Aufruf gemäß einer Ausführungsform der vorliegenden Erfindung;
9 veranschaulicht die Verwendung eines Objektreferenz-Triggers gemäß einer Ausführungsform der vorliegenden Erfindung;
10 veranschaulicht die Verwendung eines Objektreferenz-Triggers in einem Szenario verteilter Abarbeitung gemäß einer Ausführungsform der vorliegenden Erfindung;
11 veranschaulicht die Verwendung eines Aufruf-Triggers gemäß einer Ausführungsform der vorliegenden Erfindung;
12 veranschaulicht die Verwendung eines Aufruf-Triggers in einem Proxy-Server-Szenario gemäß einer Ausführungsform der vorliegenden Erfindung;
13 veranschaulicht eine weitere Verwendung eines Aufruf-Triggers in einem Proxy-Server-Szenario gemäß einer Ausführungsform der vorliegenden Erfindung; 14 veranschaulicht eine Technik gemäß einer Ausführungsform der Erfindung, um Trigger weiterzugeben;
15 ist ein Programmablaufplan, der das Testverfahren gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht.
AUSFÜHRLICHE BESCHREIBUNG
Die folgende Beschreibung wird präsentiert, um einen Fachmann auf dem Gebiet in die Lage zu versetzen, die Erfindung nachzuvollziehen und anzuwenden, wobei sie im Kontext einer besonderen Anwendung und ihrer Erfordernisse gegeben wird. Einem Fachmann auf dem Gebiet werden verschiedene Modifikationen der offenbarten Ausführungsformen ohne weiteres offensichtlich sein, und die allgemeinen Prinzipien, die hier definiert sind, können auf andere Ausführungsformen und Anwendungen übertragen werden, ohne vom Geltungsbereich der vorliegenden Erfindung abzukommen. Folglich soll die vorliegende Erfindung nicht auf die gezeigten Ausführungsformen beschränkt sein, sondern ihr soll der weiteste Geltungsbereich, der mit den hier offenbarten Prinzipien und Merkmalen verträglich ist, gewährt werden.
Die in dieser ausführlichen Beschreibung angegebenen Datenstrukturen und Codes sind typisch auf einem computerlesbaren Speichermedium gespeichert, das jede Vorrichtung oder jedes Medium sein kann, die bzw. das Code und/oder Daten für die Verwendung durch ein Computersystem speichern kann. Dies umfasst, ohne jedoch hierauf beschränkt zu sein, magnetische und optische Speichervorrichtungen wie etwa Plattenlaufwerke, Magnetbänder, CDs (Compactdiscs) und DVDs (Digital Versatile Discs oder Digitale Videodiscs) und Computerbefehlssignale, die in einem Übertragungsmedium verkörpert sind (mit oder ohne eine Trägerwelle, auf welche die Signale moduliert sind). Beispielsweise kann das Übertragungsmedium ein Kommunikationsnetz wie etwa das Internet einbeziehen.
Computersystem
1 veranschaulicht ein Cluster-Computersystem 120 gemäß einer Ausführungsform der vorliegenden Erfindung. Das Cluster-Computersystem 120 ist durch das Netz 104 an Client-Computersysteme 102 und 103 gekoppelt.
Das Netz 104 kann einen beliebigen Typ eines drahtgebundenen oder drahtlosen Übertragungskanals enthalten, der in der Lage ist, Verarbeitungsknoten zusammenzuschalten. Dies umfasst, wobei jedoch keine Beschränkung hierauf besteht, ein lokales Netz, ein Weltverkehrsnetz oder eine Kombination von Netzen. In einer Ausführungsform der vorliegenden Erfindung bezieht das Netz 104 das Internet ein.
Die Clients 102-103 können einen beliebigen Knoten des Netzes 104 umfassen, wobei sie Verarbeitungsvermögen und einen Mechanismus, um über das Netz 104 zu kommunizieren, enthalten.
Die Clients 102-103 kommunizieren mit dem Cluster-Computersystem 120, indem sie Pakete an das Cluster-Computersystem 120 senden, um Dienste von dem Cluster-Computersystem 120 anzufordern.
Das Cluster-Computersystem 120 umfasst eine Menge von Knoten, die durch einen (nicht gezeigten) Übertragungskanal miteinander gekoppelt sind. Diese Knoten umfassen Server 106-108.
Die Server 106-108 können Knoten mit einem Mechanismus zur Abarbeitung von Anforderungen von den Clients 102-103 hinsichtlich Verarbeitungs- und/oder Datenspeicherbetriebsmitteln enthalten.
Das Cluster-Computersystem 120 umfasst außerdem Speichervorrichtungen 110-111. Die Speichervorrichtung 110 ist an die Server 106-107 gekoppelt, und die Speichervorrichtung 111 ist an die Server 107-108 gekoppelt. Die Speichervorrichtungen 110-111 sorgen für eine Langzeitspeicherung von Code und/oder Daten, die von den Servern 106-108 beeinflusst werden. Diese Langzeitspeicher können, ohne jedoch hierauf beschränkt zu sein, Magnetspeicher, Flash-Speicher, ROM, EPROM, EEPROM und batteriegeschützten RAM umfassen.
Für die Testung des Cluster-Computersystems 120 enthalten die Server 106-108 Fehlerinjektionscode 116-118, der weiter unten anhand 2-15 ausführlicher beschrieben ist.
2 veranschaulicht Software in dem Server 106 von 1 gemäß einer Ausführungsform der vorliegenden Erfindung. Die Software in dem Server 106 residiert entweder im Anwenderraum 202 oder im Kernraum 204. Der Anwenderraum 202 ist im Allgemeinen Code in Anwenderprogrammen vorbehalten, die von einem Anwender ausgeführt werden. Der Kernraum 204 ist im Allgemeinen Betriebssystemcode vorbehalten.
Der Betriebssystemcode 206 residiert in dem Kernraum 204. In einer Ausfüh rungsform der vorliegenden Erfindung führt der Betriebssystemcode 206 das Betriebssystem Solaris aus, das von Sun Microsystems Inc., Palo Alto (Kalifornien) vertrieben wird. Das Betriebssystem Solaris ist ein Betriebssystem auf UNIX-Grundlage. Daher werden bei der Beschreibung der vorliegenden Technologie häufig UNIX-Fachausdrücke und -Konzepte gebraucht. Jedoch dient dieser Gebrauch der Veranschaulichung und ist nicht als die Erfindung auf dieses besondere Betriebssystem beschränkend aufzufassen.
Der Cluster-Code 208 führt Cluster-Funktionen aus, die den Servern 106-108 ermöglichen, bei der Ausführung von Verarbeitungen zusammenzuarbeiten und die rechnerische Arbeitsbelastung zwischen den Servern 106-108 aufzuteilen. Es ist zu beachten, dass Teile des Cluster-Codes 208 im Kernraum 204 residieren, während andere Teile des Cluster-Codes 208 im Anwenderraum 202 residieren.
Der Fehlerinjektionscode 116 residiert in dem Cluster-Code 208. Es ist zu beachten, dass ein Teil des Fehlerinjektionscodes 118 in dem Kernraum 204 und ein weiterer Teil in dem Anwenderraum 202 residiert.
Testverfahren
3 veranschaulicht das Testverfahren gemäß einer Ausführungsform der vorliegenden Erfindung. Dieses Testverfahren wird durch ein Testprogramm 302 ausgeführt, das Trigger für Fehler und Testbedingungen setzt, bevor ein Programm 306 ausgeführt wird. Es ist zu beachten, dass ein Programm 306 im Allgemeinen jede Art von Anwendungsprogramm enthalten kann. In einer Ausführungsform der vorliegenden Erfindung ist das Programm 306 jedoch ein Betriebssystem, das getestet wird, um die Zuverlässigkeit sicherzustellen.
Wenn während der Ausführung des Programms 308 ein Fehlerpunkt 304 abgearbeitet wird und ein Trigger für den Fehlerpunkt 304 gesetzt worden ist, bewirkt der Fehlerpunkt 304, dass ein Fehler 305 erzeugt wird. Es ist zu beachten, dass der Fehler 305 im Allgemeinen einen beliebigen Fehlertyp oder ein anderes Ereignis, das durch Software getriggert werden kann, umfassen kann. Dies umfasst, ohne jedoch hierauf beschränkt zu sein, eine Computersystem-Reboot-Operation, eine Computersystem-Panikoperation (die das Beenden des Betriebs eines Computersystems bewirkt), eine Rückgabe eines Fehlercodes, eine erzwungene Änderung des Steuerablaufs, einen Betriebsmittel- (Speicher-) Zuweisungsfehler, eine Ant- wortverzögerung, eine fehlerhafte Nachricht oder eine Verklemmung bzw. Systemblockade.
4 veranschaulicht einen Fehlerpunkt 304 gemäß einer Ausführungsform der vorliegenden Erfindung. Der Fehlerpunkt 304 umfasst eine ihn kennzeichnende Fehlerkennung 404. Außerdem umfasst der Fehlerpunkt 304 Fehlercode 406, der das Auftreten des Fehlers 305 bewirkt. Es ist zu beachten, dass im Allgemeinen ein beliebiger Typ von Code, der das Auftreten eines Ereignisses in einem Computersystem bewirkt, für den Fehlercode 406 verwendet werden kann.
Der Fehlercode 406 kann eine Funktion aufrufen, die das Auftreten des Fehlers 305 bewirkt. Als eine andere Möglichkeit kann der Fehlercode 406 Code enthalten, der nicht in einer Funktion ist, um Variablen im lokalen Kontext des Fehlerpunkts 304 abzuändern.
5 veranschaulicht einen Trigger 502 gemäß einer Ausführungsform der vorliegenden Erfindung. Der Trigger 502 umfasst ebenfalls eine Fehlerkennung 404, wobei er außerdem ein Fehlerargument 504 enthält, das ermöglicht, Daten an den Fehlerpunkt 304 zu übertragen. Beispielsweise könnte das Fehlerargument 504 eine Zeitverzögerung oder einen zurückzugebenden Fehlercode spezifizieren. Der Trigger 502 enthält außerdem eine Fehlerargumentgröße 506.
15 ist ein Programmablaufplan, der das Testverfahren gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht. Das System startet, wobei es einem Programmierer ermöglicht, wenigstens einen Fehlerpunkt 304 in den Quellcode für das Programm 306 einzufügen (Schritt 1502). Als Nächstes ermöglicht das System, diesen Quellcode in ausführbaren Code für das Programm 306 zu kompilieren (Schritt 1504).
Während einer anschließenden Testphase setzt das Testprogramm 302 einen Trigger 502 für einen Fehlerpunkt 304 in dem Programm 306 (Schritt 1506). Dies bewirkt, dass der Fehlerpunkt 304 einen Fehler 305 erzeugt, falls der Fehlerpunkt 304 während der Ausführung des Programms 306 abgearbeitet wird.
Als Nächstes ermöglicht das System, den ausführbaren Code für das Programm 306 auszuführen (Schritt 1508). Falls der Fehlerpunkt 304 während dieser Ausführung abgearbeitet wird, schlägt das System den entsprechenden Trigger 502 für den Fehlerpunkt 304 nach und ermittelt dann, ob der Trigger 502 gesetzt ist. Wenn ja, führt das System den Fehlercode 406 aus, der das Auftreten des Fehlers 305 bewirkt (Schritt 1510). Als Nächstes prüft das System das Ergebnis der Ausführung, um das Resultat der Testung zu ermitteln (Schritt 1512).
Fehlerpunkte
In einer Ausführungsform der vorliegenden Erfindung müssen zwei Bedingungen erfüllt sein, bevor ein Fehlerpunktcode ausgeführt wird (und folglich einen Fehler erzeugt): Erliegt auf dem aktuellen Ausführungspfad, und es gibt einen Trigger für seine Fehlerkennzahl. Ein Fehlerpunkt wird als "getriggert" bezeichnet, wenn er zur Ausführung gelangt.
In einer Ausführungsform der vorliegenden Erfindung unterstützt dieses System vier Triggertypen. Es gibt eine Reihe von Gründen, mehrere Typen vorzusehen. Erstens ist es wünschenswert, dass das System unterschiedliche Testanforderungen unterstützt.
Zweitens liefern in einigen Cluster-Computersystemen Objekte Dienste. Clients fordern einen Dienst von einem Objekt an, indem sie zuerst eine Referenz auf das Objekt erhalten und dann das Verfahren des Objekts, das den Dienst ausführt, aufrufen. Verschiedene Objekte, die verschiedene Dienste liefern, können in verschiedenen Knoten des Clusters residieren.
Die meisten Objekte können eine Dienstanforderung selbst ausführen und die Ergebnisse des Dienstes direkt an den anfordernden Client zurückgeben. Einige erfordern jedoch die Dienste von weiteren Objekten, um eine Anforderung vollständig abzuarbeiten. Dies impliziert ein Szenario eines verschachtelten Aufrufverhaltens, d. h. dass ein Aufruf eine Kette weiterer Aufrufe zur Folge hat. Beispielsweise ruft der Client A ein Verfahren des Objekts B auf, das seinerseits Verfahren der Objekte C und D aufrufen muss, um die Anforderung des Clients A vollständig abzuarbeiten.
Dies ist ferner dadurch erschwert, dass Objektreferenzen auf ein Verfahren als Argumente des Aufrufs übergeben werden können (sehr ähnlich der Übergabe von Zeigern als Argumente eines Funktionsaufrufs). Diese Objektreferenzen können wiederum verwendet werden, um Verfahren der Objekte, auf die referiert wird, aufzurufen. Es sei beispielsweise angenommen, dass der Client A ein Verfahren des Objekts B mit Referenzen auf ein Objekt C und ein Objekt D als Aufrufargumente aufruft. Das Objekt B kann nun diese Referenzen verwenden, um die Objekte C und D aufzurufen.
In einer Ausführungsform der vorliegenden Erfindung sind vier Triggertypen vorgesehen, um die oben beschriebenen Aufruf-Szenarien zu unterstützen. In Abhängigkeit von dem Aufrufverhalten der Komponente, die getestet wird, können Testprogramme (Clients) einen oder mehrere der vier Triggertypen verwenden, um Fehler entlang dem Ausführungspfad bzw. der Ausführungspfade eines, einiger oder sämtlicher der Aufrufe in dem Szenario zu erzeugen.
In einer Ausführungsform der vorliegenden Erfindung gibt es zwei Methoden, um Fehlerpunkte unter Verwendung von Fehlerfunktionen sowie lokale Fehlerpunkte zu schreiben. Jede davon ist weiter unten erörtert.
Fehlerfunktionen
Mehrere Fehlerpunkte könnten den gleichen Fehler erzeugen. Statt den gleichen Code für jeden Fehlerpunkt zu schreiben, kann dieser in einer gesonderten Funktion angeordnet werden, die als "Fehlerfunktion" bezeichnet wird. Die Fehlerpunkte können dann so konfiguriert sein, dass sie die Funktion aufrufen, wenn sie getriggert sind.
Tabellarische Aufstellung 1
In einer Ausführungsform der vorliegenden Erfindung stellt ein System eine einfache Methode zur Verfügung, um dies zu leisten. Es sei beispielsweise ange nommen, dass es eine Fehlerfunktion do_delay() gibt, die einen Zeitverzögerungsfehler erzeugt, und angenommen, es soll in foo::bar() ein Fehlerpunkt mit der Fehlerkennzahl 1329 gesetzt werden, der do_delay() aufruft. Dies kann wie in der tabellarischen Aufstellung 1 veranschaulicht erfolgen.
Der Aufruf von FAULT POINT() in der tabellarischen Aufstellung 1 prüft zuerst, ob es einen Trigger für die Fehlerkennzahl 1329 gibt, d. h.: (1) global gesetzt, (2) in der Objektreferenz gesetzt, die den aktuellen Aufruf tätigt, (3) in der Objektreferenz gesetzt, die in seinem zweiten Argument übergeben wird, oder (4) in der Umgebungsvariablen gesetzt, deren Adresse in dem dritten Argument übergeben wird.
Wenn es einen solchen Trigger gibt, ruft FAULT POINT() do_delay() mit zwei Argumenten auf. Das erste ist ein Zeiger auf das Fehlerargument (ein NULL-Zeiger, falls kein Fehlerargument vorhanden ist), das von dem Trigger gehalten wird. Das zweite ist die Größe des Fehlerarguments in Bytes (null, falls kein Fehlerargument vorhanden ist). Andernfalls wird die Ausführung mit der nächsten Anweisung nach FAULT-POINT() fortgesetzt.
Es ist zu beachten, dass das zweite und dritte Argument für FAULT-POINT() optional sind. Wenn eine Objektreferenz für foo::bar() nicht zur Verfügung steht, kann das zweite Argument auf NULL gesetzt sein. Genauso kann, wenn eine Umgebungsvariable nicht zugänglich ist oder wenn der Fehlerpunkt nicht durch eine Umgebungsvariable getriggert werden soll, das dritte Argument auf NULL gesetzt sein.
In einer Ausführungsform der vorliegenden Erfindung müssen Fehlerfunktionen, die an FAULT POINT() übergeben werden, vom Typ

void (*)(void *fault_arg, size_t fault_argsize)

sein.
Fehlerargumente können verwendet werden, um Daten an Fehlerfunktionen zu übergeben. Wenn ein Fehlerargument eine willkürliche Bytesequenz ist, gibt die Fehlerfunktion an, wie sie zu interpretieren ist. Beispielsweise kann mit do_delay() die Verzögerungszeit übergeben werden. Ein weiteres Beispiel ist eine Fehlerfunktion, die einen Fehlercode setzt. Das Fehlerargument könnte der Wert des zu setzenden Fehlers sein. Noch ein weiteres Beispiel ist eine, die eine Nachricht an einen bekannten Dienst sendet. In diesem Fall könnte das Fehlerargument die zu sendende Nachricht sein.
Lokale Fehlerpunkte
Für einige Fehlerpunkte könnte es notwendig sein, Code im Bereich des Codeblocks einzufügen, der sie enthält (z. B. innerhalb einer Funktion oder eines Schleifenkerns), da die Fehlerpunkte sozusagen auf eine lokale Variable Zugriff haben müssen oder ein Beenden des Codeblocks erzwingen müssen (z. B. Rücksprung aus einer Funktion oder Unterbrechung einer Schleife). Beispielsweise zwingt der unten angegebene Fehlerpunkt 137 myfunc() zu einem Rücksprung mit einer Fehlerkennzahl. Der Rückgabewert wird als ein Fehlerargument übergeben.
Tabellarische Aufstellung 2
Die Funktion Fl:triggered() prüft zuerst, ob es einen gesetzten Trigger für die Fehlerkennzahl 137 gibt. Wenn ja, setzt sie fl_argp, um auf das Fehlerargument zu zeigen, das von dem Trigger gehalten wird, setzt argsize entsprechend der Größe des Fehlerarguments in Bytes und gibt "wahr" zurück. Andernfalls setzt sie fl_argp auf NULL, setzt argsize auf null und gibt "falsch" zurück.
Es wird angemerkt, dass ein Aufruf von FAULT POINT() (zuvor erörtert), wie etwa FAULT_POINT(1329, objref, &e, fault_func) unter Verwendung des lokalen Fehlerpunktverfahrens folgendermaßen umgeschrieben werden kann:
Tabellarische Aufstellung 3
In der Tat stellt dies dar, wie eine Ausführungsform von FAULT POINT() tatsächlich ausgeführt wird: FAULT POINT() ruft Fl:triggered() auf, um zu prüfen, ob es einen für sie gesetzten Trigger gibt, und ruft dann die übergebene Fehlerfunktion auf. FAULT POINT() wird einfach als eine geeignete Routine zur Verfügung gestellt, die das Schreiben von Fehlerpunkten unterstützt.
Trigger
Ein Fehlerpunkt gelangt zur Ausführung, wenn es einen Trigger mit einem dazu passenden Fehlerpunkt gibt. Wie oben beschrieben worden ist, umfasst jeder Trigger drei Datenelemente: eine Fehlerkennzahl, ein Fehlerargument und die Fehlerargumentgröße. Diese Datenelemente werden sozusagen von dem Trigger "gehalten".
Bevor ein Trigger genutzt werden kann, muss er gesetzt werden. Typisch setzen Testprogramme einen oder mehrere Trigger, bevor sie ein Verfahren einer Objektimplementierung aufrufen oder einen Systemaufruf ausführen. Wenn ein Fehlerpunkt entlang dem Aufrufpfad (Ausführungspfad) mit einem der Trigger übereinstimmt, gelangt er zur Ausführung (wird getriggert) und erzeugt einen Fehler.
In einer Ausführungsform der vorliegenden Erfindung unterstützt ein Fehlerinjektionssystem vier Triggertypen: globale Trigger, Umgebungs-Trigger, Objektreferenz-Trigger und Aufruf-Trigger. Es gibt eine Reihe von Gründen, um mehrere Typen von Triggern vorzusehen: verschiedene Testanforderungen und verschie dene Aufrufverhaltensszenarien. Die meisten Objekte können Client-Anforderungen selbst ausführen. Das Aufrufen eines Verfahrens an diesen Objekten hat nur einen Aufruf zur Folge (Szenario eines einzigen Aufrufs). Einige Objekte erfordern jedoch die Dienste von weiteren Objekten, bevor eine Anforderung vollständig abgearbeitet ist.
Das Aufrufen eines Verfahrens an diesen Objekten bewirkt eine Reihe weiterer Aufrufe (Szenario verschachtelter Aufrufe). Außerdem können Objektreferenzen als Argumente des Aufrufs an ein Objekt übergeben werden. Diese übergebenen Referenzen können dann verwendet werden, um Verfahren an den Objekten, auf die referiert wird, aufzurufen. In Abhängigkeit von dem Aufrufverhalten der Komponente, die getestet wird, können Testprogramme (Clients) einen oder mehrere der Triggertypen verwenden, um Fehler entlang dem Ausführungspfad bzw. der Ausführungspfade eines, einiger oder sämtlicher der Aufrufe zu erzeugen.
Die folgenden Abschnitte beschreiben diese Triggertypen ausführlicher. Außerdem liefern sie Beispiele, die zeigen, wie diese Triggertypen sowie für jeden Triggertyp geeignete Aufrufszenarien zu setzen sind.
Globale Trigger
Globale Trigger sind Trigger mit globaler Geltung, die im Kernadressraum gespeichert sind. Sie sind für alle Fehlerpunkte in dem System zugänglich. Außerdem können globale Trigger, da sie nicht einem bestimmten Aufruf zugeordnet sind, für Fehlerpunkte abseits des Ausführungspfads des aktuellen Aufrufs gesetzt werden; ein Ereignis mit einem Ausführungspfad, das diese Fehlerpunkte kreuzt, kann sie triggern.
Es ist zu beachten, dass globale Trigger nur innerhalb eines Knotens und nicht innerhalb des gesamten Clusters global sind. "Clusterweite" Trigger können simuliert werden, indem in jedem Knoten des Clusters die gleichen globalen Trigger gesetzt werden.
Globale Trigger sind besonders zweckmäßig, um Merkmale zu testen, die nicht Bestandteil eines Clusters sind, sondern durch dieses beeinflusst sind, d. h. um die Nebenwirkungen eines Clusters zu testen. Beispielsweise können globale Trigger verwendet werden, um das Verhalten der Funktion stat() an einer Datei zu testen, wenn der Inhaberknoten der Datei mitten in dem Aufruf abstürzt. Da stat() nicht Bestandteil des Clusters ist, wird hier nicht das Cluster selbst, sondern seine Wirkung auf den Systemaufruf getestet. In diesem Fall können Trigger für Fehlerpunkte entlang dem Ausführungspfad des Aufrufs global in dem die Datei innehabenden Knoten gesetzt werden, bevor der Systemaufruf getätigt wird (siehe tabellarische Aufstellung 4).
Die Tatsache, dass globale Trigger aufrufunabhängig sind, macht sie für eine "zufällige" Testung nützlich. Diese kann beispielsweise durch Setzen globaler Trigger an einem Knoten während des Boot-Zeitraums für alle Fehlerpunkte erfolgen, die Kern-Paniken erzeugen können. Ein Ereignis, das einen dieser Fehlerpunkte kreuzt, wird den Absturz des Knotens herbeiführen. Es kann ein externes Testprogramm eingerichtet werden, das nach solchen Abstürzen Ausschau hält und, wenn sie auftreten, verifiziert, dass das Cluster als Ganzes noch funktioniert.
Tabellarische Aufstellung 4
Jedoch macht das aufrufunabhängige Wesen der globalen Trigger sie auch für bestimmte Testanforderungen ungeeignet. Es sei beispielsweise angenommen, dass der Codepfad vorliegt, der in 6 gezeigt ist.
Es soll erreicht werden, dass der angegebene Fehlerpunkt einen Fehler erzeugt, wenn der Test – und nur der Test – ausgeführt wird. In diesem Fall sind globale Trigger ungeeignet, da ein anderes Programm dem rechts angegebenen Pfad folgen könnte, bevor der Test startet, was ein vorzeitiges Triggern des Fehlerpunkts zur Folge hätte.
Umgebungs-Trigger
Globale Trigger können ungeeignet sein, um Fehlerpunkte in Codepfaden zu triggern, die gewöhnlich von einer großen Anzahl von Ereignissen oder von Ereignissen, die regelmäßig in kurzen zeitlichen Abständen auftreten, durchlaufen werden. In diesem Fall können Umgebungs-Trigger verwendet werden, da sie ermöglichen, Fehlerpunkte nur während eines bestimmten Aufrufs zu verwenden.
Wie der Name sagt, sind Umgebungs-Trigger in der Umgebung eines Aufrufs gespeichert. Da ein Client jedes Mal, wenn er ein Objekt aufruft, eine Variable vom Umgebungstyp liefern muss, sind Umgebungs-Trigger, die von der Variablen gehalten werden, innerhalb dieses Aufrufs isoliert. Fehlerpunkte entlang dem Weg des Aufrufs werden nicht durch andere Clients getriggert, die dieselben (oder andere) Objekte aufrufen, da jeder Client seine eigene Kopie der Umgebungsvariablen verwendet (es sei denn, zwei Clients setzen Trigger für denselben Fehlerpunkt).
Auf der Client-Seite eines Aufrufs werden die Trigger, die in der Umgebung gespeichert sind, zusammengestellt und an den Server des Objekts gesendet. Auf der Server-Seite werden sie entpackt und in der Umgebung des Servers gespeichert. Dies ermöglicht, dass beide, Client und Server, die gleichen Trigger "sehen". Da auf der Server-Seite jeder Aufruf in einem gesonderten Ausführungsteilprozess ausgeführt wird und jeder Teilprozess eine gesonderte Umgebung besitzt, sind die Umgebungs-Trigger eines Aufrufs von anderen Aufrufen isoliert.
Ein Beispiel für Aufruf-Szenarien, für die Umgebungs-Trigger geeignet sind, ist in 7 gezeigt. Beide, der Client 102 und der Client 103, rufen dasselbe Objekt 702 auf dem Server 106 auf, aber nur der Client 102 setzt Trigger in seiner Umgebung. Auf dem Server 106 werden nur dann Fehlerpunkte getriggert, wenn das Objekt 702 durch den Client 102 aufgerufen wird, obwohl beide Aufrufe dem gleichen Codepfad folgen.
Umgebungs-Trigger sind vor allem für Szenarien verschachtelter Aufrufe nützlich, wobei Fehlerpunkte entlang aller Aufrufe in dem Szenario getriggert werden sollen. Beispielsweise setzt der Client 102 in 8 einige Trigger in seiner Umgebung und ruft dann das Objekt 802 im Server 106 auf, das wiederum das Objekt 803 im Server 107 aufruft. Da über beide Aufrufe Umgebungs-Trigger übermittelt werden, können Fehlerpunkte entlang beider Aufrufpfade getriggert werden.
Es ist zu beachten, dass in einer Ausführungsform der vorliegenden Erfindung, in der die Umgebungen lokale Variablen sind, dies nur möglich ist, wenn das Objekt 802 die gleiche Umgebungsvariable verwendet, wenn es das Objekt 803 aufruft, wie wenn es durch den Client 102 aufgerufen wird.
Es gibt jedoch eine Grenze dafür, was Umgebungs-Trigger in Szenarien verschachtelter Aufrufe leisten können. Bei Verwendung des oben angegebenen Szenarios sei angenommen, dass die Fehlerpunkte nur entlang entweder dem Aufruf vom Client 102 zum Objekt 802 oder entlang dem Aufruf vom Objekt 802 zum Objekt 803, nicht jedoch auf beiden Pfaden, getriggert werden sollen. Umgebungs-Trigger (oder globale Trigger) können in dieser Situation nicht benutzt werden, da beide Aufrufe die gleichen Trigger "sehen".
Für die Lösung dieses Problems können die in den folgenden Absätzen erörterten Triggertypen verwendet werden. Die tabellarische Aufstellung 5 liefert ein Beispiel dafür, wie Umgebungs-Trigger gesetzt und gelöscht werden können.
Objektreferenz-Trigger
Objektreferenz-Trigger sind Umgebungs-Triggern ähnlich. Jedoch werden Objektreferenz-Trigger statt von der Umgebung von Objektreferenzen gehalten. Diese Trigger sind äußerst zweckmäßig für Szenarien, in denen Objektreferenzen als Argumente des Aufrufs oder als Rückgabewerte eines Aufrufs übergeben werden. Ein Beispiel dafür, wie Test-Clients Objektreferenz-Trigger setzen können, ist in der tabellarische Aufstellung 6 gezeigt.
Tabellarische Aufstellung 5
Bei der Server-Implementierung können die Fehlerpunkte wie in der tabellarischen Aufstellung 7 veranschaulicht implementiert werden.
Objektreferenz-Trigger sind zweckmäßig, um Fehler in einer Untermenge von Aufrufen in Szenarien mit verschachtelten Aufrufen zu isolieren. Beispielsweise wird in 9 ein Szenario angenommen, bei dem das Objekt 902 ein Verfahren umfasst, das auf ein weiteres Objekt als Eingangsparameter referiert.
Indem Trigger in der Objektreferenz 901 gesetzt werden, bevor sie an das Objekt 902 übergeben wird, kann der Client 102 Fehlerpunkte nur entlang dem Pfad zwischen dem Client 102 und dem Objekt 902 triggern. Jene entlang dem Pfad zwischen dem Objekt 902 und dem Objekt 903 werden nicht getriggert. Vergleiche dies mit dem Fall, wo der Client 102 die Trigger in der Umgebung setzt.
Tabellarische Aufstellung 6
Ein interessantes Aufruf-Szenario, für welches dieses Verfahren zweckmäßig sein kann, ist das "Verteildienst"-Szenario, bei dem ein Objekt eine Sequenz von Objektreferenzen aufnimmt und jede Referenz in der Sequenz an andere Objekte verteilt (siehe 10).
Tabellarische Aufstellung 7
sIn diesem Beispiel nimmt das Objekt 902 eine Sequenz von zwei Objektreferenzen auf. Das Objekt 902 ruft dann das Objekt 1004 auf, das in der ersten Objektreferenz 1002 in der Sequenz übergeben wird, und das Objekt 1005, das in der zweiten Objektreferenz 1003 in der Sequenz übergeben wird. Um verschiedene Fehlerpunkte entlang dem Pfad zwischen dem Objekt 902 und dem Objekt 1004 und dem Pfad zwischen dem Objekt 902 und dem Objekt 1005 zu triggern, kann der Client 102 verschiedene Trigger in der Objektreferenz 1002 und der Objektreferenz 1003 setzen, bevor sie an das Objekt 802 übergeben werden.
Vergleiche dies mit der Situation, in welcher der Client 102 alle Trigger in der Umgebung setzt. In diesem Fall werden Fehlerpunkte entlang aller drei Aufruf pfade getriggert.
Aufruf-Trigger
Wie im vorhergehenden Absatz beschrieben ist, kann eine Objektreferenz Objektreferenz-Trigger mit sich führen. Diese Trigger werden "Aufruf-Trigger" genannt, wenn sie verwendet werden, um Fehler zu erzeugen, wenn das Objekt, auf das referiert wird, aufgerufen wird. Dies bringt zwei Auswirkungen mit sich. Erstens kann ein Client Trigger an einer Objektreferenz setzen, bevor ein Verfahren an dem Objekt aufgerufen wird. Diese Trigger sind nur innerhalb dieses Aufrufs isoliert. Zweitens kann ein Client eine Objektreferenz, die Objektreferenz-Trigger hält, an ein anderes Objekt übergeben. Es können dann Fehler erzeugt werden, wenn das Empfänger-Objekt das Objekt, auf das referiert wird, aufruft.
In dem einfachsten Szenario, in dem ein Client 102 ein Objekt 1102 eines Servers aufruft und keine verschachtelten Aufrufe erfolgen (Szenario eines einzigen Aufrufs), sind die Aufruf-Trigger den Umgebungs-Triggern sehr ähnlich, obwohl sie vom Konzept her wahrscheinlich einfacher zu verstehen sind (siehe 11).
Das heißt die Trigger sind nur für jenen bestimmten Aufruf spezifisch, es sei denn, die Trigger sind in der Objektreferenz statt in der Umgebung gesetzt. Die tabellarische Aufstellung 8 liefert ein Beispiel dafür, wie dies erfolgen kann.
Da Objektreferenzen als Aufrufargumente weitergegeben werden können, gibt es viele interessante Szenarien, für die Aufruf-Trigger verwendet werden können, um Fehler zu erzeugen. Drei davon sind weiter unten dargestellt.
Das erste wird als das "Proxy-Server-Szenario" bezeichnet, wobei ein Client eine Objektreferenz 1201 an ein Server-Objekt 1205 übergibt, das dann im Auftrag des Clients 102 einen Aufruf des Objekts, auf das referiert wird, ausführt (siehe 12).
Tabellarische Aufstellung 8
Der Client 102 ruft den Objekt-Stellvertreter 1205 auf, wobei er ihm eine Referenz auf das Objekt 1206 übergibt. Der Objekt-Stellvertreter 1205 wiederum ruft im Auftrag des Clients 102 das Objekt 1206 auf. Genauso ruft der Client 103 den Objekt-Stellvertreter 1205 mit einer Referenz auf das Objekt 1207 auf, das von dem Objekt-Stellvertreter 1205 in seinem Namen aufgerufen wird. Um Fehlerpunkte entlang dem Aufrufweg zwischen dem Objekt-Stellvertreter 1205 und dem Objekt 1206 zu triggern, kann der Client 102 Trigger innerhalb der Objektreferenz 1201 setzen, bevor er den Objekt-Stellvertreter 1205 aufruft. Genauso kann der Client 103 Trigger innerhalb der Objektreferenz 1202 setzen, um Fehlerpunkte entlang dem Pfad zwischen dem Objekt-Stellvertreter 1205 und dem Objekt 1207 zu triggern.
Das zweite Szenario ist dem ersten ähnlich, außer, dass der Client 102 in einer Sequenz Objekt-Referenzen an das "Stellvertreter-Objekt" übergibt, das wiederum entweder iterativ oder parallel die Objekte aufruft, auf die durch die übergebenen Referenzen referiert wird (siehe 13).
Um verschiedene Fehler entlang dem Pfad von dem Objekt-Stellvertreter 1305 zu dem Objekt 1207 und dem Pfad von dem Objekt-Stellvertreter 1305 zu dem Objekt 1304 hervorzurufen, kann der Client gesonderte Trigger für die Objektreferenz 1202 und die Objektreferenz 1302 setzen, bevor er den Stellvertreter aufruft.
Das dritte Szenario ist eigentlich kein Aufruf-Szenario, sondern mehr eine Technik, um Trigger weiterzugeben. Sie kann als "Virus-Technik" bezeichnet werden, da sie zu der Möglichkeit verhilft, Trigger über alle Clients eines Objekts zu verteilen.
Normalerweise registrieren sich Objekte, wenn sie erzeugt werden, selbst mit Zeichenkettennamen bei dem Namenserver 1420. Das heißt die Objekte enthalten eine Referenz auf sich selbst und übergeben sie dem Namenserver 1420, der sie in seiner Objektreferenztabelle halten wird. Ein Client 102, der eine Referenz auf das Objekt haben möchte, kann unter Verwendung des registrierten Zeichenkettennamens eine Anforderung an den Namenserver 1420 stellen. Der Namenserver 1420 gibt eine Kopie der angeforderten Referenz an den Client zurück (siehe 14).
Um Trigger auf alle seine Clients zu verteilen kann das Objekt zuerst einige Objektreferenz-Trigger in seiner Objektreferenz setzen, bevor es sie an den Namenserver 1420 übergibt. Wenn die Clients Kopien der Referenz von dem Namenserver 1420 erhalten, erhalten sie außerdem eine Kopie dieser Trigger. Diese Trigger werden Aufruf-Trigger, wenn diese Referenzen benutzt werden, um das Objekt aufzurufen.
Es gibt keinen einzigen Triggertyp, der alle Testanforderungen erfüllt. Die Wahl des zu verwendenden Triggertyps wird davon abhängen, was getestet wird, von seinem Aufrufverhalten, davon, wie der Test implementiert ist und welche Typen und Orte von Fehlerpunkten zu triggern sind. In einigen Fällen könnte es ausreichend sein, genau einen Triggertyp zu verwenden, während es in anderen Fällen erforderlich sein könnte, mehrere Triggertypen gleichzeitig zu verwenden.
Die vorhergehenden Beschreibungen von Ausführungsformen der Erfindung sind nur zum Zweck der Veranschaulichung und der Darstellung gegeben worden. Sie sollen weder erschöpfend sein, noch die vorliegende Erfindung auf die offenbarten Formen beschränken. Dementsprechend werden dem Fachmann auf dem Gebiet zahlreiche Modifikationen und Variationen offensichtlich sein. Außerdem soll die oben gegebene Darstellung die vorliegende Erfindung nicht einschränken. Der Schutzumfang der vorliegenden Erfindung ist durch die beigefügten Ansprüche definiert.

Claims

Verfahren zum Testen eines Computersystems (120) unter Verwendung von Software, um in das Computersystem Fehler zu injizieren, während es arbeitet, umfassend: a) Eingeben (Schritt 1502) eines Fehlerpunkts (305) in den Quellcode für ein Programm (306), wobei der Fehlerpunkt das Auftreten eines Fehlers (305) bewirkt, falls ein dem Fehlerpunkt zugeordneter Trigger (502) gesetzt ist und falls ein Ausführungspfad des Programms (306) durch den Fehlerpunkt (304) verläuft; b) Kompilieren (Schritt 1504) des Quellcodes für das Programm (306) in einen ausführbaren Code; c) Setzen (Schritt 1506) des Triggers für den Fehlerpunkt, so dass der Fehler auftritt, falls der Fehlerausführungspfad (306) durch den Fehlerpunkt verläuft; und d) Ausführen (Schritt 1508) des ausführbaren Codes für das Programm, dadurch gekennzeichnet, dass der Trigger (502) eine Fehlerkennung (404) und ein Fehlerargument (504), das ermöglicht, dass Daten in den Fehlerpunkt (304) geschickt werden, enthält, der Trigger (502) in einer Objektreferenz (901, 1002, 1003, 1101, 1201, 1202, 1302, 1404, 1407, 1408) gespeichert wird und dass der Trigger (502) die Erzeugung des Fehlers bewirkt, wenn das Objekt, auf das referiert wird, aufgerufen wird.
Verfahren nach Anspruch 1, bei dem dann, wenn auf den Fehlerpunkt (304) gestoßen wird, während der ausführbare Code für das Programm ausgeführt wird, die Ausführung des Fehlerpunkts umfasst: a) Nachschlagen eines Triggers (502), der dem Fehlerpunkt (304) zugeordnet ist; b) Bestimmen, ob der Trigger (502) gesetzt worden ist; und c) Ausführen (Schritt 1510) von Code (406), der dem Fehlerpunkt (304) zugeordnet ist, falls der Trigger gesetzt worden ist.
Verfahren nach Anspruch 1, bei dem der Fehlerpunkt (304) eine Fehlerfunktion aufruft, die das Auftreten des Fehlers bewirkt.
Verfahren nach Anspruch 1, bei dem der Fehlerpunkt (304) Code enthält, der
Verfahren nach Anspruch 1, bei dem der Fehler eines der folgenden enthält: a) eine Computersystem-Reboot-Operation; b) eine Computersystem-Panikoperation; c) eine Rückgabe von Fehlercode; d) eine erzwungene Änderung des Steuerablaufs; e) einen Betriebsmittelzuweisungsfehler; f) eine Antwortverzögerung; und g) eine Verklemmung.
Computerlesbares Speichermedium, das Befehle speichert, die, wenn sie von einem Computer ausgeführt werden, den Computer dazu veranlassen, ein Verfahren nach einem der Ansprüche 1 bis 5 auszuführen.
Computerprogramm, das, wenn es auf einem Computersystem läuft, das Computersystem dazu veranlasst, das Verfahren nach einem der Schritte 1 bis 5 auszuführen.
Vorrichtung zum Testen eines Computersystems (120) unter Verwendung von Software, um Fehler in das Computersystem zu injizieren, während es arbeitet, mit: a) einem Fehlerpunkt-Eingabemechanismus, der das Eingeben eines Fehlerpunkts (304) in den Quellcode für ein Programm (306) erleichtert, wobei der Fehlerpunkt (304) das Auftreten eines Fehlers (305) bewirkt, falls ein dem Fehlerpunkt zugeordneter Trigger (502) gesetzt ist und falls ein Ausführungspfad des Programms (306) durch den Fehlerpunkt (304) verläuft; b) einem Kompilierer, der den Quellcode für das Programm (306) in ausführbaren Code kompiliert; und einem Triggersetzmechanismus, der das Setzen des Triggers (502) für den Fehlerpunkt (304) erleichtert, so dass der Fehler auftritt, falls der Ausführungspfad des Programms (306) durch den Fehlerpunkt verläuft; dadurch gekennzeichnet, dass der Trigger (502) eine Fehlerkennung (404) und ein Fehlerargument (504), das ermöglicht, Daten in den Fehlerpunkt (304) zu schicken, enthält, der Trigger (502) in einer Objektreferenz (901, 1002, 1003, 1101, 1201, 1202, 1302, 1404, 1407, 1408) gespeichert wird und dass der Trigger (502) die Erzeugung des Fehlers bewirkt, wenn das Objekt, auf das referiert wird, aufgerufen wird.
Vorrichtung nach Anspruch 8, bei der der Fehlerpunkt (304) so konfiguriert ist, dass die Ausführung des ausführbaren Codes für den Fehler umfasst: a) Nachschlagen eines Triggers (502), der dem Fehlerpunkt (304) zugeordnet ist; b) Bestimmen, ob der Trigger (502) gesetzt worden ist; und c) Ausführen (Schritt 1510) von Code (406), der dem Fehlerpunkt (304) zugeordnet ist, falls der Trigger gesetzt worden ist.
Vorrichtung nach Anspruch 8, bei dem der Fehlerpunkt (304) eine Fehlerfunktion aufruft, die das Auftreten des Fehlers bewirkt.
Verfahren nach Anspruch 8, bei dem der Fehlerpunkt (304) Code enthält, der das Auftreten des Fehlers bewirkt.
Vorrichtung nach Anspruch 8, bei der der Fehler eines der folgenden enthält: a) eine Computersystem-Reboot-Operation; b) eine Computersystem-Panikoperation; c) eine Rückgabe von Fehlercode; d) eine erzwungene Änderung des Steuerablaufs; e) einen Betriebsmittelzuweisungsfehler; f) eine Antwortverzögerung; und g) eine Verklemmung.