-
Die vorliegende Erfindung bezieht
sich auf Softwareprüfung
und insbesondere auf eine Einheit zur Durchführung der Prüfung von
Software. Die Erfindung ist vorzugsweise, aber nicht ausschließlich für die Verwendung
bei Software gedacht, bei der objektorientierte Programmiersprachen
wie C++, Corba oder Java eingesetzt werden.
-
Das automatische Prüfen von
Software bei ihrer Entwicklung ist bekannt. Die Tests werden als Teil
eines Software-Entwicklungsprozesses entworfen, und sie werden dann
in spezielle Testwerkzeuge als Programme eingebunden und automatisch
ausgeführt.
Viele Werkzeuge (Tools) sind kommerziell erhältlich als Unterstützung für diese
Art der Softwareentwicklung.
-
Software, die sich beim Betrieb selber
prüft, ist
ebenfalls bekannt und wird in großem Umfang entwickelt und angewendet.
Darin enthalten sein kann das Prüfen
von Vor- und Nachbedingungen sowie das Durchsetzen und das Suchen
nach Ausnahmezuständen
an geeigneten Punkten in der Software während ihres normalen Ablaufs
(siehe "Self Testing Systems", M. Aylett und P. Utton, BT Technology Journal
1992).
-
Die bekannten Prüfsysteme ermöglichen End-zu-End-Tests
auf Betriebssystemen, um den Betrieb individueller Einrichtungen
zu testen. Jedoch gibt es gegenwärtig
keine Prüfsysteme,
die ohne weiteres Test auf niedriger Ebene zulassen, die in einem vollständig integrierten
und eingerichteten System laufen. Diese Tests werden oft als "Einheitentest"
bezeichnet und werden direkt auf eine oder mehrere individuelle
Code-Einheiten angewendet (z. B. eine Funktion, ein Verfahren, ein
Modul oder ein Agent). Dies steht im Gegensatz zu den End-zu-End-Tests eines
Systems, die über
ein System oder eine Nutzerschnittstelle laufen. Einheitentests
werden gegenwärtig
bei der Entwicklung vor der Integration manuell oder automatisch
durchgeführt.
-
Von Robert V. Binder wird in "Design
for Testability in Object-Oriented
Systems", Communications of the Association für Computing Machinery, Band
37, Nr. 9, September 1994 (1994–09),
Seite 87–101,
ein Verfahren zum Testen eines objektorientierten Systems beschrieben,
bei dem ein Testtreiber einen Satz von Testkriterien aus einer zu
einem Element von Software gehörenden
Testspezifikation erzeugt. Der Testtreiber prüft das Element der Software in Übereinstimmung
mit den erzeugten Testkriterien und nimmt das Ergebnis auf und evaluiert
es.
-
Die vorliegende Erfindung wird in
den unabhängigen
Ansprüchen
definiert.
-
In Übereinstimmung mit der vorliegenden
Erfindung wird ein Verfahren zum Prüfen eines integrierten Betriebssystems
angegeben, wobei das System mehrere Softwareelemente hat und die Schritte
umfasst:
- a) Automatisches Registrieren jedes aktiven Elements
der Software in einem Register,
- b) Assoziieren eines Satzes von Testkriterien mit jedem Softwareelement,
- c) Auswählen
eines Elements für
die Prüfung
aus denen, die in dem Register registriert sind, und Prüfen des
Elements in Übereinstimmung
mit dem assoziierten Satz von Testkriterien und
- d) Sammeln von Ergebnissen der Prüfung des Elements und Vergleichen
von ihnen mit den assoziierten Testkriterien.
-
Dies hat den Vorteil, dass Einheitentests
in einem integrierten Softwaresystem während des Betriebes ausgeführt werden
können,
so dass eine schnelle Identifizierung latenter oder neu hinzugekommener
Fehler in der Software möglich
wird.
-
1 ist
eine schematische Darstellung eines Computers, auf dem eine Software
läuft,
als Ausführungsform
der vorliegenden Erfindung.
-
2 ist
ein Blockdiagramm der Programmelemente der Software nach 1.
-
3 ist
ein Flussdiagramm, das einen Teil des Ablaufs der Software nach 2 zeigt.
-
4a und 4b sind Tabellen zur Darstellung der Datenstrukturen,
die verwendet werden und erzeugt werden durch Programmelemente nach 2.
-
5 ist
ein Flussdiagramm, das einen weiteren Teil des Ablaufs der Software
nach 2 zeigt.
-
1 zeigt
einen konventionellen Computer 101, wie z. B. einen PC,
auf dem ein konventionelles Betriebssystem 103, wie z.
B. Windows, läuft
und eine Anzahl von Applikationsprogrammen 105 vorhanden
ist, wie z. B. ein Textverarbeitungsprogramm, ein Netz-Browser sowie ein
E-Mail-Programm oder ein Datenbankprogramm. Der Computer 101 hat
außerdem
ein Software-Entwicklungsprogramm 107, das es dem Nutzer
ermöglicht,
neue Programme zu schreiben und zu kompilieren, sowie ein Prüfprogramm 109,
mit dem Programme geprüft
werden können.
Der Computer 101 ist außerdem mit einer konventionellen
Plattenspeichereinheit 111 zum Speichern von Daten und
Programmen, einer Tastatur 113 und einer Maus 115 für Eingaben
des Nutzers sowie einem Drucker 117 und einer Anzeigeeinheit 119 als
Ausgabeeinheiten des Computers 101 verbunden. Der Computer 101 hat über eine
Netzkarte 121 außerdem
Zugriff auf (nicht dargestellte) externe Netze.
-
Bei der konventionellen objektorientierten Programmierung
werden die Programme in konzeptuelle Untereinheiten unterteilt,
die Objekte genannt werden. Jedes Objekt führt vorgegebene Funktionen aus,
im Wesentlichen auf die gleiche Art, wie es eine Subroutine beim
konventionellen Programmieren tut. Objekte sorgen für die Verarbeitung
von Daten und können
mit anderen Objekten zusammenarbeiten, um gewisse Funktionen zu
erfüllen.
Eine solche Zusammenarbeit erfolgt über Schnittstellen zwischen den
Objekten, die Argumente genannt werden und die zum Übermitteln
von Befehlen, Anfragen und Daten zwischen den Objekten dienen.
-
Jedes Objekt gehört zu einer Kategorie von Objektklassen.
In der Tat ist es die Klasse eines Objekts, durch die die Funktionen
und Eigenschaften eines Objekts festgelegt werden. Ein Objekt ist
seinerseits eine Verkörperung
(oder Instanz) der Klasse und kann erzeugt werden, um seine Funktion
zu erfüllen,
und gelöscht
werden, sobald die Funktion erledigt ist. Die Erzeugung eines Objekts
bei einer gegebenen Klasse erfolgt unter Überwachung durch einen Erzeugungsalgorithmus.
Zusätzlich
dient der entsprechende Löschalgorithmus
jeder Klasse dazu, den Eintrag zu entfernen, wenn das entsprechende Objekt
gelöscht
wurde.
-
Jedes Objekt beinhaltet ein oder
mehrere Verfahren. Jedes Verfahren ist eine Subroutine, die mit
anderen Verfahren die Funktionen des Objekts an sich darstellt.
Die Verfahren können
mit andern Objekten zusammenarbeiten, um Funktionen/Verarbeitungen
als Teil des Verfahrens durchzuführen.
Die Verfahren werden ebenfalls durch die Klasse des Objekts definiert,
wie es auch bei den Argumenten des Objekts der Fall ist.
-
Zusammenfassend, Objekte sind Funktionseinheiten
des Softwarecodes, dessen Funktionen definiert werden durch die
Klasse, von der ein gegebenes Objekt eine Instanz darstellt. Objekte
können eine
Anzahl von Zuständen
einnehmen, die sich in Abhängigkeit
von der Interaktion des Objekts mit anderen Objekten oder Daten ändern können. Die
kombinierte Interaktion der Objekte, aus denen ein Computerprogramm
besteht, bilden die Funktionen des Programms an sich.
-
In 2 umfasst
das Prüfprogramm 109 fünf Hauptkomponenten,
eine Testeinrichtung 201, ein Objektregister 203,
einen Berichterstatter 205, einen Testkriterienspeicher 207 und
einen Analysealgorithmus 209. Die Testeinrichtung 201 führt die
Prüfung jedes
Objekts in dem Softwareprogramm, das getestet wird, durch und leitet
die Ergebnisse des Tests an den Berichterstatter 205. Das
Objektregister 203 liefert der Testeinrichtung 201 eine
Liste von Objekten, die zu einem gegebenen Zeitpunkt Teil des Programms
sind (wie oben erwähnt,
können
Objekte im Ablauf eines Programms erzeugt und gelöscht werden).
Der Testkriterienspeicher 207 wird verwendet, um die Daten
und/oder Befehle zu speichern, die notwendig sind, um jedes der
Objekte zu prüfen,
die in dem Objektregister 203 registriert sind. Bei der
vorliegenden Ausführungsform
stehen die Daten und/oder Befehle in dem Testkriterienspeicher 207 der
Testeinrichtung 201 sofort zur Verfügung. Jedoch können in manchen
Fällen
die Daten auch mit einer Script-Sprache codiert werden. In diesem
Fall würde der
Analysealgorithmus 209 verwendet werden, um die Daten/Befehle
in eine Form zu bringen, in der sie von der Testeinrichtung 201 verwendet
werden können.
Die Funktionen und Interaktionen der fünf Hauptkomponenten wird genauer
weiter unten beschrieben.
-
2 zeigt
außerdem
ein Programmobjekt 211, das durch die Testeinrichtung 201 geprüft wird. Das
Objekt 211 ist ein Standardobjekt, hat aber drei zusätzliche
Funktionalitätsbereiche,
die es ihm ermöglichen,
automatisch mit dem Testprogramm 109 zu interagieren. Die
zusätzliche
Funktionalität
ist in der vorliegenden Ausführungsform
durch zwei spezielle Verfahren 213, 215 gegeben,
die zu jeder Klassendefinition in dem zu prüfenden Programm hinzukom men,
und durch Hinzufügungen
zu der Funktionalität
des Erzeugungs- und Löschalgorithmus
für das
Programm.
-
In 3 erfolgt
die Erzeugung in der Art, dass bei Einordnung eines Objektes in
eine gegebene Klasse ein Eintrag in dem Objektregister 203 für das neue
Objekt erfolgt (siehe Schritt 301 in Ablauf C). Dann folgt
bei der Erzeugung im Schritt 303 die Identifizierung als
Objekt in seinem Eintrag im Register 203 (jedes Objekt
erhält
eine eindeutige Identifizierung, wenn es bei der Erzeugung erstellt
wird). Im Schritt 305 wird der Klassentyp des Objektes
in der Liste für
das Objekt eingetragen, und in Schritt 307 ist der entsprechende
Klassenname eingetragen. Nach Schritt 307 wird die Registrierung
abgeschlossen, und der Erzeugungsalgorithmus wird beendet.
-
Wie oben bemerkt, wird ein Objekt
durch einen Löschalgorithmus
gelöscht,
wenn es nicht länger benötigt wird.
Bei der vorliegenden Ausführungsform wird
der Löschalgorithmus
so ausgelegt, dass die Schritte in dem Ablauf D in 3 durchgeführt werden. Im Schritt 309 identifiziert
der Löschalgorithmus den
Eintrag im Register 203, der dem Objekt entspricht, das
gelöscht
wird, und im Schritt 311 wird der Eintrag aus dem Register 203 entfernt.
-
In 4a hat
jede Klasse von Objekten eine Testkriteriendatei, die in dem Testkriterienspeicher 207 gespeichert
wird, wenn das erste Objekt dieser Klasse in das Objektregister 203 eingetragen
wird. Die Kriterien werden bei der Erstellung und Implementierung
des Computerprogramms, das getestet werden soll, erzeugt, und ihr
genauer Aufbau hängt von
den verwendeten Testverfahren ab. Bei der vorliegenden Ausführungsform
wird ein Eintrag im Speicher 207 bei jeder Klasse 401 gemacht.
Bei jeder Klasse wird bei jedem Verfahren ein Eintrag 403 innerhalb
der Klasse gemacht. Bei jedem Verfahren 403 wird eine Definition
der Eingabe 405 für
das Verfahren, des Ausgabewertes 407 des Verfahrens, des Startzustandes 409 des
Objekts, wenn das Verfahren durchgeführt wird, und des Endzustandes 411 des Objekts
bei Beendigung des Verfahrens in dem Speicher 207 eingetragen.
-
Der Betrieb der Testeinrichtung 201 wird
im Folgenden mit Bezug auf 5 beschrieben,
in der bei Schritt 501 die Testeinrichtung 201 einen
Befehl erwartet, um mit der Prüfung
zu beginnen. Bei der vorliegenden Ausführungsform wird der Befehl
von einem Nutzer eingegeben. Sobald der Befehl empfangen wurde,
wählt die
Testeinrichtung 201 in Schritt 503 aus dem Register 203 die
Klasse der Objekte, die getestet werden sollen. Bei der vorliegenden
Ausführungsform
reagiert das System auf einen Befehl eines Nutzer, mit dem Prüfen zu beginnen,
und wählt zufällig ein
Verfahren. Jedoch kann auch der Befehl oder die Wahl des Verfahrens
in Übereinstimmung mit
einem vordefinierten Testplan oder in Abhängigkeit von Anfragen oder
Ereignissen anderer Objekte oder Programme zufällig erfolgen.
-
Im Schritt 505 verwendet
die Testeinrichtung 201 das erste spezielle Verfahren 213 zum
Bestimmen der Anzahl der Verfahren in dem gewählten Objekt. Das Verfahren 213 gibt
wie in 4b gezeigt Daten zurück, die
die Klasse des Objekts 413 beschreiben, sowie Identifikationen 415 jedes
der Verfahren in dem Objekt und eine Beschreibung 417 der Argumente
für jedes
der Verfahren. Im Schritt 507 identifiziert die Testeinrichtung 201 unter
Verwendung der Klassenidentifizierung durch das Verfahren 213 die
geeigneten Test kriterien in dem Testkriterienspeicher 207,
und bei Schritt 509 wird das gewählte Verfahren in Bezug auf
die identifizierten Testkriterien ablaufen gelassen.
-
Im Schritt 511 wird durch
die Testeinrichtung 201 das zweite spezielle Verfahren 215 eingesetzt, und
die Ergebnisse des Testlaufs werden bei dem Verfahren gesammelt.
Die genauen Daten, die gesammelt werden, werden durch die Testkriterien
festgelegt und können
die Ausgangsdaten des getesteten Verfahrens, den Endzustand des
Objekts, von dem das Verfahren ein Teil ist, sowie eine Liste von anderen
Objekten oder Verfahren beinhalten, mit denen das Verfahren als
Folge des Tests interagiert hat. Im Schritt 513 werden
die Testdaten, die in dem vorangehenden Schritt gesammelt wurden,
mit den Testkriterien verglichen, und die Ergebnisse des Vergleichs
werden an den Berichterstatter 205 weitergegeben, um sie
in einen Testbericht einzubauen. Nach Schritt 513 springt
die Testeinrichtung zu Schritt 501 zurück, um weitere Testinstruktionen
abzuwarten.
-
Das Prüfprogramm 201 dient
dazu, Testprozeduren bezüglich
eines Programms durchzuführen, während das
Programm in Betrieb ist. Bei manchen Betriebssystemen kann das Prüfprogramm 201 eingerichtet
werden, um als Hintergrundprozess zu laufen, oder eingerichtet werden,
um zu arbeiten, wenn ein vorgegebener Umfang an restliche Ressourcen des
Prozessors zur Verfügung
steht.
-
Dem Fachmann ist klar, dass es bei
manchen Systemen notwendig sein kann, Mittel vorzusehen, um Änderungen
der Laufzeit eines Softwareelements bei der Prüfung zu vermeiden. Dies kann
in Form von Laufzeittestschaltern erfolgen, die in ihrer Funktion
einem Debug-Kompiler-Schalter ähneln. Bei
manchen Systemen kann es notwendig sein, Mittel vorzusehen, um den
Zustand von irgendwelchen konstanten Variablen (Variablen, die nach
Ausführung
ihren Zustand beibehalten) wiederherzustellen, die durch die Tests
beeinflusst worden sind. Dies kann durch Kopieren der konstanten
Variablen vor einem Test und ihre nachträgliche Wiederherstellung erfolgen.
-
Dem Fachmann ist außerdem klar,
dass das System, das getestet wird, in der Praxis verteilt sein kann.
Beispielsweise kann das Testen in einem Netzwerk erfolgen, und Einheiten
des Codes sind über viele
Computer verteilt. Außerdem
kann das System während
der Konstruktion und Herstellung eines Softwaresystems von Entwicklern
verwendet werden oder als Teil der Funktionalität von Programmen bereitgestellt
werden, die betriebsfertig sind.
-
Das Prüfprogramm ist vorzugsweise
in derselben Sprache geschrieben wie das Programm, das mit ihm geprüft werden
soll. Obgleich die obige Ausführungsform
das Prüfen
einer objektorientierten Programmiersprache beschreibt, ist dem
Fachmann jedoch klar, dass die Prinzipien der Erfindung auch auf
andere Programmiersprachen anwendbar sind. Andere derartige Sprachen
können
modulare Programmiersprachen (wie z. B. Modula-2) oder sequenzielle
Programmiersprachen (wie z. B. Pascal) sein. Außerdem sollte klar sein, dass
der Ausdruck "Objekt" in dieser Beschreibung eine breite Bedeutung
hat und Funktionen, Verfahren, Module oder Agenten abdeckt.
-
Dem Fachmann ist klar, dass das Prüfprogramm 109 auch
auf verschiedenen Übertragungs- und/oder
Speichermedien, wie z. B. einer Diskette, einer CD-ROM oder einem
Magnetband vorliegen kann, so dass das Programm auf einen oder mehrere Standardcomputer
geladen werden kann oder über ein
Computernetz mit einem geeigneten Transmissionsmedium heruntergeladen
werden kann.
-
Soweit aus dem Kontext nichts anderes
eindeutig hervorgeht, sollen in der Beschreibung und den Ansprüchen die
Worte "umfassen", "umfassend" u. dgl. als einschließlich und
nicht ausschließlich
verstanden werden; mit anderen Worten im Sinne von "einschließlich, aber
nicht ausschließlich".