DE3884034T2

DE3884034T2 - Verfahren zur Überprüfung von Computersoftware.

Info

Publication number: DE3884034T2
Application number: DE88303029T
Authority: DE
Inventors: Eric Phillip Casteel; R Ralph Delucia; Daniel Joseph Wolf
Original assignee: Westinghouse Electric Corp
Current assignee: CBS Corp
Priority date: 1987-04-08
Filing date: 1988-04-05
Publication date: 1994-05-05
Anticipated expiration: 2008-04-06
Also published as: DE3884034D1; EP0286361A3; EP0286361B1; CA1297191C; IN171541B; JPS63271643A; ES2045108T3; EP0286361A2; US4819233A

Description

Hintergrund der Erfindung

Gebiet der Erfindung:

Diese Erfindung bezieht sich auf ein Verfahren zum Testen neuer und überarbeiteter Computerprogramme durch automatisches Erzeugen, Ausführen und Dokumentieren eines kundenorientierten Testprogramms, das nur minimale Eingaben bzw. Interventionen durch den Benutzer erfordert.

Hintergrundinformation:

Viele Anlagenprozesse werden heutzutage überwacht und in unterschiedlichem Maße im Anlagenkontrollraum gesteuert, wobei Signale verwendet werden, die von überall in der Anlage angeordneten Sendeeinheiten und Instrumentierungen übermittelt werden. Ein typisches Beispiel einer solchen Prozeßanlage ist ein Kernkraftwerk. Obwohl zahlreiche Tätigkeiten im Kontrollraum manuell erfolgen, wird die verbleibende Mehrheit automatisch mit Hilfe von Schaltungen durchgeführt, die programmierte Mikroprozessoren oder programmierbare Digitalrechner umfassen. Zahlreiche der in diesen Mikroprozessoren und Rechnern verwendeten Programme sind mit Bezug auf die Anlagensicherheit kritisch und deshalb sind ihre Genauigkeit und Integrität wichtig.
Bei einem typischen Kernkraftwerk können etwa 1200 oder mehr dieser Steuerungs- und Überwachungsprogramme vorhanden sein. Gegenwärtig werden sie durch eine Sichtprüfung des Codes zusammen mit einer unabhängigen physikalischen Prüfung jedes Programmsegments verifiziert und validitiert, um eine richtige Arbeitsweise des Programms sicherzustellen. Obwohl die Sichtprüfung sich als sehr effektiv bei der Validitierung des Programms erwiesen hat, erfordert die von der Nuclear Regulatory Commission der Vereinigten Staaten herausgegebene Richtlinie 1.97, daß Einrichtungen, die Datenerfassungs- und qualifizierte Anzeigefunktionen innerhalb des Kontrollraums erfüllen, in strengerer Weise geprüft werden. Die physikalischen Tests sind bisher unter Verwendung einer Demonstrationseinheit der tatsächlichen Hardware durchgeführt worden, die Zugang zu den Speicherplätzen für die Eingangsparameter und Ausgangsparameter ermöglicht. Um den zu testenden Softwareteil zu isolieren, werden die gewünschten Testwerte der Eingangsparameter direkt in die zugeordneten Speicherplätze in der Demonstrationseinheit eingegeben, und man läßt das Programm ablaufen. Die Ausgangswerte werden von den Ausgangsspeicherplätzen für einen manuellen Vergleich mit den erwarteten Werten herausgezogen.
Ein solches Testen legt dem Verifizierer die ganze Last des Entwerfens eines Testprogramms auf, das alle Instruktionen und alle möglichen Verzweigungen in dem Programm ausführt. Dies erfordert ein großes Maß an Geschick auf Seiten des Verifizierers, und es gibt keine direkte Aufzeichnung sämtlicher ausgeführter Programmpfade. Da jedes Programm eine Vielzahl von Aufgaben erfordern kann, um alle Verzweigungen auszuführen, wird das Verfahren außerdem extrem zeitaufwendig und kompliziert.
Demgemäß ist es das Hauptziel der vorliegenden Erfindung, ein Verfahren zum Testen von Computerprogrammen zu schaffen, das automatisch ein kundenorientiertes Testprogramm unter Verwendung minimaler Benutzereingaben erzeugt, ausführt und dokumentiert.
Hingewiesen wird auf "Angewandte Informatik", Band 25, 8. August 1983, Seiten 321 bis 327, Wiesbaden, wo ein Verfahren zum Verifizieren eines Computerprogrammquellencodes mit bekanntem Format und einer Reihe von Programmanweisungen einschließlich Nichtsteuer- und Steueranweisungen beschrieben ist, durch welche das Programm sich auf alternative Anweisungen des Quellencodes verzweigen kann, und das Verfahren umfaßt das Instrumentieren einer Zieleinheit des Quellencodes durch Betreiben eines Prozessors zum Unterteilen des Quellencodes in Codeblöcke, wobei ein Codeblock durch die Nichtsteueranweisungen zwischen Steueranweisungen markiert wird, und zum Einfügen von ausführbaren Instruktionen in die Codeblöcke zum Schreiben einer Kennung in eine Ausgabedatei für jeden Codeblock, wenn er ausgeführt wird, das Auswählen eines Testdatensatzes für die Zielcodeeinheit, wobei jeder Testdatensatz Eingabewerte für Variable in der Testeinheit und erwartete Ausgabewerte enthält und der Testdatensatz so ausgewählt wird, daß jeder Codeblock in der Testeinheit ausgeführt wird, und das Erzeugen einer Ausgabe, die tatsächliche Ausgabewerte und erwartete Ausgabewerte für den Testdatensatz darstellt, und einer sequentiellen Auflistung der Blockkennungen der Blöcke der Zielcodeeinheit aus der Ausgabedatei in der Reihenfolge, in der sie ausgeführt wurden.
Die Erfindung besteht in einem Verfahren zum Unterstützen der Verifizierung eines Computerprogrammquellencodes mit den Schritten:
a) Neuformatieren des Quellencodes einer Programmquellendatei, wobei der Quellencode ein bekanntes Format und eine Reihe von Programmanweisungen aufweist, die Nichtsteueranweisungen und Steueranweisungen umfassen, mittels welcher das Programm sich auf alternative Programmanweisungen des Quellencodes verzweigen kann,
b) Auswählen einer benutzergewählten Programmeinheit aus der neuformatierten Programmquellendatei,
c) Instrumentieren des benutzergewählten Programms mittels eines Codeinstrumentenprozessors, der den Quellencode in Codeblöcke unterteilt, wobei ein Codeblock durch die Nichtsteueranweisungen zwischen Steueranweisungen markiert wird, und Einsetzen von ausführbaren Instruktionen in die Codeblöcke zum Schreiben einer Kennung in eine Ausgabedatei für jeden Codeblock, wenn er ausgeführt wird,
d) Erzeugen eines Quellentestprogramms mit Eingabewerten für die benutzergewählte Programmeinheit und erwarteten Ausgabewerten, um die Programmeinheit mit einer Mehrzahl von benutzergewählten Testdaten auszuführen,
e) Kompilieren, Verknüpfen und Ausführen des Testprogramms und der benutzergewählten Programmeinheit,
f) wobei die Ausführung eine Ausgabe erzeugt, die aktuelle Ausgabewerte für jede Gruppe von Testdaten und eine sequentielle Auflistung der Blockkennungen der Blöcke der genannten benutzergewählten Programmeinheit aus der Ausgabedatei in der Reihenfolge darstellt, in welche sie ausgeführt wurden.
Es wird hier ein Verfahren zum Instrumentieren eines Quellencodes, der in einem Prozeßprogramm zu verifizieren ist, und zum Erzeugen eines Teststeuerprogramms beschrieben, das kompiliert und mit dem instrumentierten Quellencode verknüpft wird, um den Quellencode durch Verarbeitung einer Reihe von Testdatensätzen auszuführen. Der Quellencode wird durch Prozessoren instrumentiert, um, wenn der Code ausgeführt wird, eine Anzeige für jeden Codeblock zu erzeugen, daß die Anweisungen des Blocks ausgeführt worden sind. Ein Codeblock umfaßt die Programmanweisungen zwischen Steueranweisungen. Deshalb wird, wenn der instrumentierte Code durch das Teststeuerprogramm ausgeführt wird, eine Ausgabe erzeugt, welche die ausgeführten Codeblöcke angibt. Durch eine zweckmäßig unterteilte Testreihe werden alle Codeblöcke ausgeführt. Die Testdatensätze werden durch Wählen von Werten für die Eingabevariablen des Zielcodes erzeugt. Die erwarteten Werte für die Ausgabevariablen des Zielcodes werden ebenfalls bestimmt, so daß die durch Ausführung der Testdatensätze erzeugten aktuellen Programmausgabewerte verifiziert werden können.
Vorzugsweise wird der zu verifizierende Quellencode zuerst entsprechend einer standardisierten Gruppe von Formatierungsregeln neu formatiert, um einen standardisierten neuformatierten Quellencode herzustellen. Dieser neuformatierte Quellencode wird dann instrumentiert und Einheit für Einheit verifiziert, wobei eine Einheit ein Routine oder ein anderer zweckmäßiger Teil des Quellencodes ist.
Beim Instrumentieren des Quellencodes werden nichtausführbare Bemerkungen mit einer eindeutigen Blockkennung am Anfang und Ende jedes Blocks der Zielcodeeinheit eingesetzt. Eine Blockdatentabelle wird erzeugt, welche die Blockkennungen, den Verschachtelungsgrad jedes Blocks, die Blockkennung, durch welche in jeden Block eingetreten wird, und eine Anzeige, ob ein Block ein Rückschleifenblock ist, auflistet. Eine Blockverknüpfungstabelle wird ebenfalls aus den Steueranweisungen erzeugt, welche alle gültigen Übergänge zwischen Blöcken aufzeigt. Sodann wird eine ausführbare Instruktion am Anfang des Blocks eingesetzt, um eine Ausgabedatei im Hinblick auf die Blockkennung zu informieren, wenn der Block ausgeführt wird. Eine weitere ausführbare Instruktion wird am Ende des Blocks eingesetzt, die den Block anzeigt, zu welchem die Steuerung zurückspringt, nachdem alle Anweisungen in dem Block ausgeführt worden sind. Während das Programm durch die Teststeuerung ausgeführt wird, werden die Blockkennungen während der Ausführung jedes Blocks in einer eindimensionalen Anordnung in eine Ausgabedatei eingeschrieben.
Wenn die Zielcodeeinheit ein weiters Routine aufruft, werden ausführbare Schreibinstruktionen durch einen Prozessor vor und nach der Aufrufanweisung eingefügt, um in der Ausgabedokumentation eine Anzeige zu schaffen, daß die Aufrufanweisung erreicht wurde und das Programm nach dem Aufruf an die richtige Stelle zurückgekehrt ist. Gewünschtenfalls können außerdem Instruktionen zum Einschreiben des Wertes gewählter Variabler in die Ausgabedatei vor und nach dem Aufruf durch einen Prozessor in die Zielcodeeinheit eingefügt werden.
Außerdem kann, wie hier beschrieben ist und bevorzugt wird, ein Pseudocode durch einen Pseudocodeprozessor aus der neuformatierten Zielcodeeinheit erzeugt werden. Der Pseudocode enthält nur die Steueranweisungen, wobei Bemerkungen zwischen den Identifizieren der Codeblöcke die gleichen Kennungen wie der instrumentierte Code verwenden. Der Pseudocodeprozessor kann außerdem die Blockdatentabelle und die Verknüpfungstabelle erzeugen, die vom Instrumentenprozessor erzeugt wird.
Der Verifizierer prüft den Quellencode, sämtliche verfügbare Dokumentation und den Pseudocode sowie die von dem Pseudocodeprozessor erzeugten Blockdaten- und Verknüpfungstabellen zum Auswählen von Testdatensätzen, die alle Blöcke der Zielcodeeinheit ausführen werden. Die gewählten Werte von Eingabevariablen und die erwarteten Ausgabewerte für jeden Testdatensatz werden durch eine benutzerfreundliche Schnittstelle eingegeben und durch einen Testgeneratorprozessor in einer Variablendatei angeordnet. Der Testdatenprozessor benutzt dann diese Daten zum Erzeugen eines Teststeuerprogramms zur Verarbeitung der Testdatensätze. Die Variablendatei kann außerdem zur Bestimmung verwendet werden, welche Testdatensätze beeinträchtigt werden, wenn eine Variable verändert wird. Der Teststeuerprozessor erzeugt außerdem eine Testspezifizierung, welche die Eingabewerte, die erwarteten Ausgabewerte und die Blockverknüpfungen für jeden von dem Teststeuerprogramm verarbeiteten Testdatensatz darstellt.
Das Teststeuerprogramm wird kompiliert und mit der instrumentierten Zielcodeeinheit verknüpft, und das sich ergebende Programm wird ausgeführt, um die Zielcodeeinheit für jeden Testdatensatz sukzessiv auszuführen. Die abschließende Dokumentation umfaßt, zusätzlich zum Pseudocode, die Blockdaten- und Verknüpfungstabellen und der Software-Testspezifizierung, Ausgabedaten, welche die Werte die Eingabevariablen, die tatsächlichen Werte der Ausgabevariablen zusammen mit den erwarteten Werten, und die tatsächliche Folge der Blockverknüpfungen auflisten.
Die Erfindung, die sowohl das Verfahren wie auch die Einrichtung zum Verifizieren eines Computerquellencodes umfaßt, vereinfacht den Verifizierungsprozeß so, daß er schneller und mit einem größeren Maß an Standardisierung und Zuverlässigkeit ausgeführt werden kann, als dies bisher möglich ist.

Kurzbeschreibung der Zeichnungen

Ein volles Verständnis der Erfindung ergibt sich aus der folgenden Beschreibung der nur beispielsweise angegebenen bevorzugten Ausführungsformen in Verbindung mit den anliegenden Zeichnungen, in welchen zeigen:
Die Fig. 1a, 1b und 1c, wenn sie entsprechend den jeweils im Kreis angegebenen Zeichen nebeneinander zusammengesetzt sind ein Flußdiagramm des automatisierten Software-Verifizierungssystems nach einer Ausführungsform der Erfindung,
Fig. 2 die Organisation eines Bausteins einer beispielsweisen, nach der Erfindung zu verifizierenden Software,
die Fig. 3 bis 6 Beispiele von Formatierungsregeln, die bei dem Ausführungsbeispiel der Erfindung zur Standardisierung der Formatierung des Zielcodes verwendet sind,
die Fig. 7a und 7b einen Teil des Zielcodes, der gemäß der Standardisierungs- Formatierungsregeln des Ausführungsbeispiels der Erfindung neu formatiert ist,
Fig. 8 einen Teil eines erzeugten Pseudocodes, wie er bei dem Erfindung anwendbar ist,
die Fig. 9a, 9b und 9c zusammengenommen ein Segment eines vollständig instrumentierten Zielcodes gemäß dem Ausführungsbeispiel der Erfindung,
die Fig. 10a, 10b und 10c zusammengenommen eine benutzerspezifische Informationsdarteiliste, die von dem Testgeneratorprozessor gemäß dem Ausführungsbeispiel der Erfindung erzeuge worden ist,
Fig. 11 Teile eines Teststeuerprogramms, das von dem Testdatenprozessor gemäß dem Ausführungsbeispiel der Erfindung erzeugt worden ist,
die Fig. 12 und 13 Teile der Softwaretestprogrammdatei, die von dem Testdatenprozessor gemäß dem Ausführungsbeispiel der Erfindung erzeugt worden ist,
Fig. 14 die Formatierung von Ausgabeergebnissen gemäß dem Ausführungsbeispiel der Erfindung,
Fig. 15 schematisch in Blockdiagrammform ein System zur Ausführung der Erfindung.

Beschreibung der bevorzugten Ausführungsform

Die Erfindung wird in ihrer Anwendung zum automatischen Verifizieren von Software für die Mikroprozessoren in einem digitalen integrierten Schutz- und Kontrollsystem für ein Kernkraftwerk beschrieben. Es ist jedoch ersichtlich, daß die Erfindung in gleicher Weise zur Verifizierung aller Arten von Software einsetzbar ist.

Allgemeine Beschreibung:

Das automatisierte Softwareverifizierungssystem nach der Erfindung weist eine Reihe von Computerprogrammen auf, davon einige Dialogprogramme, die zum Testen von Zielcomputerprogrammen durch automatisches Erzeugen, Ausführen und Dokumentieren eines kundenorientieren Testprogramms unter Verwendung minimaler Benutzereingaben eingesetzt werden. Die Verifizierung wird an einem Allzweckdigitalcomputer ausgeführt, obwohl die Zielprogramme auch für die Verwendung bei Mikroprozessoren ausgelegt sein können. Das Softwaresystem wird in eine Anzahl unabhängiger Prozessoren unterteilt, um Modifikationen des Systems zu erleichtern.
Der anfängliche Schritt des Verifizierungsprozesses ist die Standardisierung der Formatierung des Zielprogrammquellencodes. Die von verschiedenen Programmierern verwendete Formatierung und auch die Formatierung eines individuellen Programmierers innerhalb eines gegebenen Programms kann beträchtlich variieren. Der anfängliche Prozessor formatiert den gesamten Quellencode entsprechend standardisierter Regeln neu. Während diese Formatierung für die Ausführung der Erfindung nicht wesentlich ist, vereinfacht sie die Aufgaben der anderen Prozessoren. Sodann wird ein spezifisches Programm auf dem Zielprogrammsystem zum Testen aus der neuformatierten Datei herausgezogen. Ein Pseudocodegenerator zieht dann aus dem Zielprogramm eine informatorische Auflistung nur der Steueranweisungen des Zielprogramms heraus. Diese Steueranweisungen werden als Blöcke identifiziert und mit einer Blocknummer versehen. Der Pseudocodegenerator erzeugt außerdem eine Blockdatentabelle, die anzeigt, wie in jeden der Blöcke eingetreten wird, und die identifiziert, ob der Block ein Rückschleifenblock ist oder nicht. Zusätzlich wird eine Verknüpfungstabelle erzeugt, die alle gültigen Verzweigungen zwischen Blockpaaren identifiziert. Diese informatorische Blockdatentabelle und die Verknüpfungstabelle werden dem menschlichen Verifizierer verfügbar gemacht, damit er sie beim Aufsetzen des Testprogramms benutzen kann.
In einem Parallelpfad fügt ein Codekommentarprozessor Blockidentifikationsbemerkungen entsprechend den vom Pseudocodegenerator benutzen Bemerkungen in den Zielquellencode ein. Ein Codeinstrumentierungsprozessor fügt dann ausführbare Überwachungsanweisungen in jeden Block des Quellencodes ein. Diese Überwachungsanweisungen werden ausgedruckt, wenn der Test durchgeführt wird, um zu verifizieren, daß jeder der Blöcke tatsächlich ausgeführt worden ist. Dieser instrumentierte Code ist dann zum Testen bereit. Der menschliche Verifizierer prüft den Zielquellencode anhand der Programmsoftwaredesignspezifikation und irgendwelcher weiterer verfügbarer Dokumentation und wählt zusammen mit der informatorischen Blockdatentabelle und der Verknüpfungstabelle Testbedingungen aus, die alle Zweige des Programms ausführen. Bei dieser Tätigkeit wählt der Verifizierer Eingabewerte für die verschiedenen Variablen und legt fest, wie die erwarteten Ausgabewerte aussehen sollten. Für ein komplexes Programm kann dies die Erstellung zahlreicher Testdatensätze erfordern.

Detailbeschreibung:

Ein Flußdiagramm des automatisierten Softwareverifizierungssystems nach der Erfindung ist in den Fig. 1a, b und c dargestellt. Der Verifizierer, also die Person, welche den Zielcode testet, erhält eine Datei 1 von zu testenden Programmen zusammen mit einer vom Programmierer geschriebenen Designspezifikation 2. Der Verifizierer muß den Zielcode und seine Dokumentation analysieren, um sicherzustellen, daß die Dokumentation richtig und genau ist, und muß den tatsächlichen Zielcode durch ein kundenspezifisches Teststeuerprogramm ausführen, das verifiziert, daß der Zielcode richtig arbeitet.
Aus den Fig. 1a, b und c ist ersichtlich, daß zwei gesonderte Parallelzweige A und B im Funktionsdiagramm vorhanden sind. Der Zweig A zeigt eine Reihe von Prozessoren, die den Zielcode durch Einfügen von Anweisungen so konditionieren, daß bei seiner Ausführung Mittel zur Überwachung und Aufzeichnung des Ausführungspfads sowie sämtlicher Eingabe- und Ausgabewerte für jeden Testdatensatz innerhalb des Verifizierungsprozesses verfügbar sind. Dies ist die Hauptfunktion der Blöcke 3 bis 7 in den Fig. 1a und b. Diese Überwachungsanweisungen und Eingabe/Ausgabewerte stellen die notwendige Dokumentation für den Verifizierungsprozeß dar, wenn der Zielcode ausgeführt wird.
Der Zweig B zeigt den Beurteilungs- und Testspezifikationsvorgang. Unter Verwendung der vom Programmierer geschriebenen Designspezifikation 2, die den Zweck des Zielcodes beschreibt, und unter Betrachtung einer Kopie des Originalcodes 1 muß der Verifizierer eine Reihe von Testdatensätzen - Block 9 - mit einem geeigneten Eingabewert zum Testen sämtlicher existierender Zweige innerhalb des instrumentierten Codes auswählen, während er außerdem bestätigen muß, daß die Ausgabewerte vorhersagbar und genau sind. Dieses Verfahren ist mit oder ohne dem automatisierten Softwareverifizierungssystem gleich und genauso anstrengend, aber die Dateneingabe, die Codekonditionierung und die Erzeugung von Steueranweisungen ist bei diesem System stark vereinfacht. Der Verifizierer gibt bei 10 die Eingabewerte und die erwarteten Ausgabewerte für jeden Testdatensatz ein, und der Zweig B verarbeitet die eingegebenen Testdaten - Block 11 - und erzeugt - Block 12 - ein Teststeuerprogramm, das den im Zweig A "konditionierten" Code ausführt.
Alle innerhalb des beispielsweisen automatisierten Softwareverifizierungssystems eingesetzten Prozessoren wurden mit PL/M86, wie von der Intel Corporation in ihren Mikroprozessoren verwendet wird, als Zielsprache entwickelt. Es ist wichtig, zu verstehen, daß die grundsätzlichen Richtlinien, aufgrund derer diese Prozessoren entwickelt wurden, für jede blockstrukturierte Sprache universal sind und deshalb diese Prozessoren so modifiziert werden können, daß sie eine breite Vielfalt von Programmiersprachen wie beispielsweise unter anderem Pascal, PL1, und struktuiertes FORTRAN bearbeiten können. Eine Programmquellendatei für Intel PL/M86 wird als "MODUL" bezeichnet. Um einen gewöhnlichen Mechanismus zu schaffen, so daß jedes Stück der Software innerhalb der Gesamtsoftwarehierarchie schnell und leicht etikettiert werden kann, sind die folgenden Regeln getroffen worden: jeder "MODUL" innerhalb des Gesamtsoftwaresystems wird eindeutig mit einer fünfstelligen alphanumerischen Kennung mit einem daran anschließenden dreistelligen alphanumerischen Zusatz gekennzeichnet.
Beispiel: TA028.PLM, RA039.ASM, FI007.INC, FD020.DEC.
Die ersten beiden Buchstaben (z. B. TA, RA, FI, FD) werden zur Kategorisierung des Software "MODULS" nach Softwaresystem/Untersystem benutzt.
Die nächsten drei Ziffern (d. h. 028, 039, 007, 020) kennzeichnen einen eindeutigen "MODUL" innerhalb eines spezifischen Softwaresystems/Untersystems.
Die letzten drei Buchstaben (der Zusatz) bezeichnet eine spezifikationsfunktionelle Art der PL/M86-Quellenkartei:
PLM - PL4M86-Programmquellendatei
ASM - PL/M86-Assemblerprogrammquellendatei
INC - PL/M86-Inklusivdatei
DEC - PL/M86-Deklarationsdatei
Eine PL/M86-Programmquellendatei (z. B. "MODUL" in PL/M86-Terminologie) kann irgendwo von 1 bis 99 Unterprogramme enthalten, die gewöhnlich als Prozeduren oder Funktionen bezeichnet werden, oder in der PL/M86-Terminologie als "UNITS". Die aktuelle PL/M86-Programmquellendatei selbst besteht aus drei Funktionsteilen :

1. Kopfteil

Der "MODUL"-"Kopfteil" enthält den gesamten Quellencode (einschließlich Bemerkungszeilen) innerhalb eines "MODULS" ausschließlich: (1) der "Ende"-Anweisung des Moduls, und (2) des gesamten zur Ausführung eines öffentlich oder lokal deklarierten Unterprogramms (d. h. Prozedur oder Funktion) innerhalb des "MODULS" erforderlichen Codes.
Beispiel: TA028.HDR ist lediglich der Kopfteil des Software "MODULS" TA028.

2. Programmteil

Das sind die individuellen Unterprogramme, die innerhalb des "MODULS" existieren. Diese Unterprogramme werden sequentiell von 1 bis 99 nummeriert, entsprechend ihrer physikalischen Reihenfolge in dem "MODUL". Jedes dieser Unterprogramme innerhalb des "MODULS" wird "UNIT" genannt.
Beispiel: TA02823.UNT ist die 23. "UNIT" innerhalb des "MODUL" TA028.

3. Endteil

Das ist der Teil des "MODULS", der dem Ende des letzten Unterprogramms folgt.
Beispiel: TA028.ENS ist lediglich der Endteil des Software "MODULS" TA028.
Die physikalische Struktur eines PL/M86-"MODUL" ist in Fig. 2 dargestellt. Wie dort gezeigt ist, weist der Modul 20 einen Kopfteil 21, eine Reihe von bis zu 99 Unterprogrammen oder Units 22 und einen Endteil 23 auf.
Wie in Block 3 der Fig. 1a gezeigt ist, formatiert der Codevorprozessor (CPP) die Datei von zu testenden Computerprogrammen 1 neu. Der CPP erzeugt eine syntaktisch korrekte Programmdatei aus einem erfolgreich kompilierten PL/M86-Programm. Der CPP bewerkstelligt das zeilenweise Vorformatieren und Einziehen der ursprünglichen PL/M86-Quellenprogrammdatei durch Anwendung der folgenden Programmcodierstandards. Der CPP verändert die Ausführung des ursprünglichen Quellencodes nicht, sondern bewirkt lediglich, daß sämtliche PL/M86- Quellencodeprogramme in sehr ähnlichem Format erscheinen, unabhängig von dem ursprünglichen Programmierer. Diese Standardisierung des Programmformats macht es anderen Personen als dem Urheber leichter verständlich. Es erleichtert auch die Ausführung weiterer Vorprozessoren, d. h. PPP 4, CCP 7, PCG 5, CIP 8, usw., da es anderenfalls für diese sehr schwierig wäre, alle diese verschiedenen in von Programmierer zu Programmierer unterschiedlichen Formaten zu bearbeiten.
Die Blockstruktur der PL/M86-Sprache wird bei der Neuformatierung betont, um sicherzustellen, daß das Programm einfach lesbar ist und daß seine Funktion klar ist. Die folgenden Regeln zeigen, wie Blockstrukturen in dem beispielsweisen System formatiert werden. Natürlich sind die jeweils gewählten Regeln nicht kritisch, solang das Ziel des Erhalts eines standardisierten Formats realisiert wird.

A. Einrückungen

Einrückungen betragen zwei Stellen.

B. "DO"-Anweisungen

Die einleitende "DO"-Anweisung und die entsprechende "END"- Anweisung haben die gleiche Linksbündigkeit. Innerhalb des Blocks werden Anweisungen eingerückt. Jeder neue Blockverschachtelungsgrad innerhalb eines Blocks erzeugt eine weitere Einrückung. Komplexe "DO"-Blöcke können mit äußeren "DO"- und "END"-Anweisungen etikettiert sein. Vorsicht ist bei der Etikettierung innerer Blöcke angebracht, weil sie die Einrückungsstruktur und Klarheit stört; statt dessen sollten Bemerkungen verwendet werden.
Alle in "DO CASE" oder "DO WHILE"-Anweisungen verwendeten Ausdrücke werden in Klammern gesetzt. Ein Beispiel eines etikettierten "DO WHILE"-Blocks mit einem verschachtelten inneren "DO-END"-Block ist in Fig. 3 gezeigt. "DO CASE"- Blöcke müssen eine umschließende "DO"- und "END"-Anweisung um Ausdrücke herum haben, um die von solchen Blöcken umrissenen Pfade zu identifizieren helfen. Es können Anweisungsetiketten oder Bemerkungen in der ersten Zeile jedes Datensatzes verwendet werden. Jedem "DO CASE"-Block muß eine Prüfung auf gültigen Indexbereich vorausgehen. Ein "DO CASE"-Block mit "DO"- und "END"-Begrenzungen für jeden individuellen Datensatz ist in Fig. 4 dargestellt. Ein "DO CASE"-Block mit "DO"- und "END"-Begrenzungen für jeden individuellen Datensatz sowie mit Bemerkungen ist in Fig. 5 dargestellt.

C. "IF"-Anweisungen

Der Auswertungsausdruck wird stets in Klammern gesetzt, und ausführbare Anweisungen werden stets eingerückt. "DO"-Blöcke sollten jederzeit angewendet werden. Wenn "DO"-Blöcke verwendet werden, gelten die sie betreffenden Regeln. "THEN" erscheint auf der gleichen Zeile wie die "IF"-Anweisung, wobei die "DO"-Anweisung auf der nächsten Zeile mit richtiger Einrückung beginnt.
"END IF" ist wörtlich als "DO; END" definiert und dient zum Abschließen eines "IF"-Blocks. Er ist linksbündig mit der anfänglichen "IF" -Anweisung.
Wenn "IF"-Anweisungen nach den "THEN", "DO"-Blöcken verschachtelt sind, müssen stets "DO"-Blöcke und das "END IF"- Konstrukt verwendet werden.
Wenn sequentielle "IF"-Anweisungen verwendet werden ("IF"-Anweisungen, die nach der "ELSE"-Anweisung verschachtelt sind), müssen "DO"-Blöcke immer um die "IF"-Anweisungen herum verwendet werden. Ein Beispiel des verschachtelten und sequentiellen Konstrukts ist in Fig. 6 dargestellt.

2. Doppelt belegtes Alphabet

Die Möglichkeit zur Verwendung von Grußbuchstaben und Kleinbuchstaben ermöglicht die Einführung eines weiteren Klarheitsgrades in den Quellencode. Unter dieser Regel werden Großbuchstaben für auf die Blockstruktur bezogene Wörter verwendet, beispielsweise für "DO", "END", "IF" usw., während Kleinbuchstaben für alles übrige verwendet werden.

3. Bemerkungsstruktur

Bemerkungen innerhalb des Codes sollten in der ersten Spalte stehen oder in der gleichen Spaltenposition wie der eingerückte Code auf der vorhergehenden Zeile des kommentierten Codes beginnen. Eine Bemerkung kann vor einem vollständigen Codeblock eingesetzt werden, um seine Funktionalität zu erläutern.
Ein Beispiel eines nach den obigen Regeln neuformatierten Programmsegments ist in den Fig. 7a und b dargestellt.
Der nächste Prozessor ist der Prozedur-Parser-Prozessor (PPP) 4. Der PPP wird zum automatischen Wählen "des" richtigen zu testenden (d. h. zu verifizierenden) Programms aus einer PL/M86-Quellendatei verwendet, die viele Programme enthalten kann. Dies eliminiert mögliche Fehler, die durch individuelle Verifizierer eingeführt werden können, wenn sie die ursprüngliche PL/M86-Programmquellendatei manuell schneiden und kleben, um das gewünschte Programm herauszuziehen. Der PPP erfordert, daß die PL/M86-Quellendatei zuerst den CPP-Vorprozessor durchlaufen haben muß.
Der PPP zieht das folgende aus der vom CPP verarbeiteten PL/M86-Programmquellendatei heraus:
1. Den Kopfteil des "MODULS" (d. h. TA028.HDR).
2. Die bezeichnete "UNIT" (bzw. Unterprogramm) innerhalb des zu verifizierenden "MODULS" (d. h. TA02823).
3. Den Endteil des "MODULS" (d. h. TA002.END).
Sodann erzeugt er eine modifizierte PL/M86-Programmquellendatei, die mit einer Kennung versehen wird, beispielsweise mit (TA02823.PLM), und aus dem folgenden besteht:
1. Dem herausgezogenen Kopfteil des ursprünglichen "MODULS" (d. h. TA028.HDR).
2. Der unmittelbar darauffolgenden Einfügung eines /*MARK*/- Zeichenkette zum Bezeichnen des Zustands der zu verifizierenden "UNITS" (d. h. Unterprogramm).
3. Der herausgezogenen, zu verifizierenden "UNIT" (d. h. TA02823.UNT).
4. Der unmittelbar darauffolgende Einfügung einer /*MARK END*/-Zeichenkette zum Bezeichnen des Endes der zu verifizierenden "UNIT".
5. Dem herausgezogenen Endteil des ursprünglichen "MODULS" (d. h. TA023.END).
Infolgedessen-hat die Ausgabe des PPP (d. h. TA02823.PLM) die folgende Struktur:
TA028.HDR ursprünglicher Kopfteil von TA028.PLM /*MARK*/ kommentierte "MARK" -Anweisung
TA02823.UNT spezifische getestete TA028-"UNIT" /*MARK END*/ kommentierte "MARK END"-Anweisung
TA028.END ursprüngliches Ende von TA028.PLM
Diese modifizierte Quellendatei wird als Arbeitskopie der zu verifizierenden Einheit verwendet.
Der nächste Prozessor ist der Pseudocodegenerator (PCG) 5, der vollständig informatorisch ist, und die Arbeitskopie des Programms nicht beeinflußt. Der PCG nimmt die aus dem Modul von dem PPP herausgezogene Programm-"UNIT" heraus und führt zwei Funktionen durch. Zunächst wird der Code abgefragt und irgendwelche ausführbaren Instruktionen identifiziert, die zu einem Programmübergang über Verzweigungen innerhalb des Programms führen könnten. Diese Methodologie basiert auf dem, was als Code- "BLOCK" definiert ist. Ein Code-"BLOCK" besteht aus einer Reihe von ausführbaren Softwareanweisungen, die stets von Anfang bis Ende in der gleichen genauen Reihenfolge ausgeführt werden. Normalerweise sind diese Code- "BLÖCKE" durch das voneinander getrennt, was als "Steuer"-Anweisungen bekannt ist, die wiederum bestimmen, welcher Code-"BLOCK" als nächster ausgeführt wird. Jeder Code- "BLOCK" wird mit einem mehrstelligen numerischen Code identifiziert, der als seine "Blocknummer" bekannt ist. Jedem Code-"BLOCK" ist außerdem eine "Verschachtelungsnummer" zugeteilt, die den "Block"-Verschachtelungsgrad identifiziert. Der Verschachtelungsgrad eines Code-"BLOCKS" ist ein Maß dafür, wieviele Steueranweisungen ausgeführt werden müssen, um diesen Code-"BLOCK" zu erreichen. Der PCG löscht sämtlichen Text zwischen den Steueranweisungen und setzt an dessen Stelle eine einfache "BLOCK-nn"-Kommentierungsanweisung, wobei "nn" die Blocknummer in ihrer sequentiellen Position vom Beginn des Programms an beschreibt. Der Zweck hiervon liegt darin, die zur Verifizierung zu testenden Codebereiche kenntlich zu machen. Fig. 8 zeigt den vom PCG für die in den Fig. 7a und b gezeigte Einheit erzeugten Pseudocode.
Die zweite Funktion des PCG ist die Bestimmung aller möglichen Verzweigungen innerhalb der Programmeinheit. Bei der Durchführung dieser Funktion erzeugt der PCG zwei Datentabellen. Die erste ist die Blockdatentabelle, von welcher ein Beispiel folgt und die als Tafel 1 bezeichnet ist. Diese Tafel gibt die Blocknummer, die Verschachtelungsnummer und den damit zusammenhängenden Block an, welcher den Pfad darstellt, über welchen in den Block eingetreten wird.
Die Verschachtelungsnummer in der Blockdatentabelle gibt den Verschachtelungsgrad des Blocks an. Ein Zähler, der den Verschachtelungsgrad verfolgt, erhöht jeweils bei "DO"-Anweisungen und vermindert bei "END"-Anweisungen. Schließlich zeigt die Blockdatentabelle an, ob der Block ein Rückschleifenblock ist, wobei ein "T" angibt, daß dies der Fall ist, und ein "F" angibt, daß dies nicht der Fall ist. Tafel 1 Blockdatentabelle Block Nr. Verschachtelungsnr. Blocknummer des zusammenhängenden Blocks Rückschleifenblock
Die zweite von dem PCG erzeugte Tabelle ist die Verknüpfungstabelle, die nachstehend als Tafel 2 bezeichnet ist. Diese Tabelle bezeichnet alle möglichen Verzweigungen, die auftreten können, wenn der Code ausgeführt wird. Tafel 2 Verknüpfungstabelle
Der PCG kombiniert den Pseudocode zusammen mit den beiden Datenquellen zu einer einzigen gemeinsamen Ausgabedatei 6, beispielsweise TA02823.PCG, die für die abschließende Dokumentation verwendet wird.
Der Kommentierte-Code-Prozessor (CCP) 7 verwendet ebenso wie der PCG den Ausgang des PPP als seinen Eingang. Der CCP ist ähnlich dem PCG, und tatsächlich haben die beiden Prozessoren einen gemeinsamen Code, den sie beide benutzen. Während der PCG nur für den informatorischen Gebrauch für den Verifizierer bestimmt war, ist der CCP für die richtige Arbeitsweise des Codeinstrumentenprozessors (CIP) 8 unbedingt wichtig. Ebenso wie der PPP und PCG hilft auch der CCP, Fehler zu minimieren, die von dem individuellen Verifizierer durch Verwendung eines entsprechenden Standards an Regeln unabhängig von dem zu verifizierenden Code eingeführt werden. Der CCP untersucht den Code Zeile für Zeile auf die gleichen Steueranweisungen wie der PCG. Dieses Mal wird jedoch der Code nicht gelöscht, sondern es werden nichtausführbare Kommentarkarten in den Zielcode eingeführt, um Anfang und Ende jedes Codeblocks zu markieren. Folglich identifiziert der CCP jeden "Block" mit der eindeutigen "Blocknummer" die identisch mit der vom PCG dem gleichen Codeblock zugeordneten Nummer ist. Außerdem fügt der CCP eine kommentierte "DO"-Anweisung (d. h. /*DO*/) unmittelbar vor jedem Code "BLOCK" und eine kommentierte "END"-Anweisung (d. h. /*END*/) unmittelbar nach jedem Code- " BLOCK" ein. Er unterscheidet außerdem zwischen der "END"-Anweisung für ein normales "DO"-"END"-"BLOCK"- Konstrukt und der "END"-Anweisung für ein Schleifen-"DO"-"BLOCK"-Konstrukt (d. h. "END FOR", "END WHILE", usw.). Er gibt auch an, welche kommentierten, "DO"- und "END"-Anweisungen er in dem Programm eingefügt hat, in dem er daneben eine "/*ADDED BY CCP*/"-PL/M86-Kommentaranweisung plaziert. Dies dient lediglich Überwachungszwecken und wird nicht von CIP verwendet.
Der CCP schreibt diese kommentierte "DO END"-Version des Programmquellencodes in eine Datei ein (d. h. TA02823.PRE).
Der CCP erzeugt außerdem die gleichen beiden Datentabelle wie der PCG, aber schreibt sie in eine separate Datei ein (d. h. PA02823.TAB). Diese beiden Dateien werden von dem Codeinstrumentenprozessor (CIP) 8 benutzt.
Der Codeinstrumentenprocessor (CIP) 8 verwendet die vom CCP hinzugefügten Bemerkungen als Markierungen zum Einfügen ausführbarer Überwachungsinstruktionen am Anfang und Ende von Codeblöcken zwischen Steueranweisungen und zum Kategorisieren jedes Blocks mit einer Folgenummer. Die Blöcke werden vom CIP in gleicher Weise nummeriert, wie das PCG-Verfahren die Blöcke nummeriert. Die ausführbaren Instruktionen setzen den Wert eines Elements in einer eindimensionalen Anordnung zu der entsprechenden Blocknummer, wenn in dem Block eingetreten wird, und den Block, zu welchem die Steuerung zurückspringt, wenn während der Ausführung aus dem Block ausgetreten wird. Auf diese Weise wird eine Überwachung des Programmausführungspfads leicht hergestellt, indem die Feldwerte ausgedruckt werden, die den Eintritt und den Austritt in einen bzw. aus einem ausgeführten Block in dem Programm zeigen.
Der CIP identifiziert auch, welche ausführbare Anweisung er durch Danebensetzen einer "/*ADDED BY CIP* /"-PL/M86-Kommentaranweisung in das Programm eingefügt hat. Er identifiziert auch die aktuellen "Blocknummern", die er bei der Verarbeitung der vom CCP kommentierten einfachen "DO"- und "END"-Anweisungen durch Setzen einer "/*BLOCK nn*/"-PL/M86- Kommentaranweisung zugeordnet hat, wobei "nn" die aktuelle "Blocknummer" ist, die vom CIP am Anfang und Ende jedes "BLOCKS" zugeordnet worden ist. Ebenso wie beim CCP erfolgt dies lediglich zu Überwachungszwecken.
Die Fig. 9a, b und c zeigen das voll instrumentierte, in den Fig. 7a und b dargestellte Codestück. Wie man sieht, wird jeder der Blöcke sequentiell in gleicher Weise wie im Pseudocode nach Fig. 8 durch die "BLOCK nn"-Bemerkungen identifiziert, beispielsweise durch die Bemerkungen 24 und 25 am Anfang und Ende des Blocks 3.
Die ausführbaren Überwachungsinstruktionen, die in dem instrumentierten Code nach den Fig. 9a, b und c benutzt werden, sind die ACTLINKS-Anweisungen, welche die entsprechende Blocknummer in ein eindimensionales Feld an einer durch TRACEINX bezeichneten Stelle einschreiben. Beispielsweise schreibt die ACTLINKS-Anweisung 26 in dem Feld die Zahl "3" ein, was anzeigt, daß in den Block 3 eingetreten wurde. Die Zahl "3" wird in der Anordnung an der durch den Wert von TRACEINX angegebenen Stelle gespeichert. TRACEINX wird dann zur Vorbereitung für den nächsten Eintritt um 1 erhöht, wie bei 27 angegeben ist. Am Ende des Blocks 3 fügt eine weitere ACTLINKS-Anweisung 28 eine "2" in das eindimensionale Feld ein, was anzeigt, daß die Steuerung zum Block 2 zurückgeführt wurde. Wiederum wird TRACEINX zur Vorbereitung des nächsten Eintritts, beispielsweise bei 29, um 1 erhöht.
Der instrumentierte Code nach den Fig. 9a, b und c zeigt auch ein weiteres Merkmal der Erfindung. Man sieht, daß der Block 3 ein weiteres, als "DEADMAN" identifiziertes Routine aufruft, wie durch die Anweisung "CALL DEADMAN" 30 angegeben ist. Der CIP fügt vor der Aufrufanweisung eine Reihe von Anweisungen ein, welche während der Ausführung des Programms "BEFORE DEADMAN" ("vor Deadman") ausdrucken. Diese Instruktionen umfassen eine Bewegungsbyte-Instruktion 31, eine Ausgabedatei-Schreibinstruktion 32 und eine Zeilenvorschubinstruktion 33. In gleicher Weise fügt der CIP-Prozessor nach der Aufrufinstruktion Instruktionen ein, die in die Ausgabedatei "AFTER DEADMAN" ("Nach Deadman") schreiben, was durch die Instruktionen 34, 35 und 36 verkörpert wird. Diese Sequenz verifiziert, daß das Zielroutine die Instruktion zum Aufrufen des externen Routine erreicht hat, und daß das Programm von dem aufgerufenen Routine an die richtige Stelle im Zielprogramm zurückgekehrt ist. Obwohl dies nicht durch den in den Fig. 9a, b und c gezeigten Code verköpert ist, kann der CIP-Prozessor auch für ein Einschreiben der Werte der Zieleinheitvariablen sowohl vor und nach dem Übergang zu dem aufgerufenen Routine in die Ausgabedatei einschreiben, um irgendeine Beeinträchtigung zu beobachten, die das Routine auf die Variablen haben kann.
An dieser Stelle ist der Zielcode neu formatiert und alle möglichen Verzweigungsbereiche sind mit einer Blocknummer gekennzeichnet. Außerdem ist ein Code in den Zielcode eingesetzt, um den entsprechenden Wert in einem eindimensionalen Blocknummernfeld zu setzen, wenn dieser besondere Codeabschnitt ausgeführt wird. Außerdem ist ein Code eingeführt worden, um zu verifizieren, daß das Programm von einem aufgerufenen Routine zur richtigen Stelle zurückkehrt, und gewünschtenfalls auch die Werte der Variablen vor und nach dem Aufruf. Bis zu dieser Stelle war die einzige vom Verifizierer verlangte Eingabe die sequentielle Position des vom Modul herauszuziehenden Programms.
Der Verifizierer muß sich nun mit der Computerprogrammsoftwaredesignspezifikation 2 vertraut machen, die vom Programmierer geschrieben ist und exakt die Funktion und den Zweck des Programms beschreibt. Außerdem muß sich der Verifizierer mit dem aktuellen Zielcode vertraut machen, der in der Datei 1 enthalten ist. Der Verifizierer muß den Zielcode visuell analysieren und mit der Designspezifikation 9 vergleichen. Mit dieser Information muß der Verifizierer 10 Eingabewerte und erwartete Ausgabewerte bestimmen, die zum Testen des Zielcodes verwendet werden. Der Pseudocode, die Blockdatentabelle und die Blockverknüpfungstabelle, die vom PCG bei 5 erzeugt worden sind, sind nützlich, indem sie den Verifizierer in die Lage versetzen, Eingabewerte vorzugeben, die jeden der Blöcke im Zielcode ausführen. Wenn die Eingabe/ erwartete Ausgabewerte bestimmt sind, müssen diese Daten zusammen mit entsprechender Identifizierung für die verschiedenen Testdatensätze manuell in den Testgeneratorprozessor (TGP) 12 eingegeben werden.
Der Testgeneratorprozessor 12 dient zum Anfordern und Aufnehmen von Daten vom Verifizierer in einem benutzerfreundlichen Format und zum Anordnen derselben in einer mit dem Zielcode kompatiblen formatierten Weise. Der TGP stellt außerdem sicher, daß der Verifizierer einen vollständigen und folgerichtigen Datensatz eingegeben hat. Eine vom TGP erzeugte benutzerspezifizierte Informationsdateiliste, die auch als Variablendatei bezeichnet wird, wird in Abschnitte unterteilt. Ein Beispiel einer solchen Dateiliste ist in den Fig. 10a, b und c gezeigt. Die erste Zeile 37 bzw. Dateiüberschrift gibt die Daten und die Zeit der Erstellung der Datei und der Version des TGP an. Dies schafft einen Prüfpfad für jede Ausführung durch den Prüfstand. Der Abschnitt 0 gibt die aufgerufenen Prozeduren und/oder Funktionen an; in diesem Fall das Routine "Deadman". Die Zeilen mit einem Stern am Anfang sind Bemerkungen, welche die Information durch eine in der Zeile 39 erscheinende Spalte identifizieren. Beispielsweise ist der aufgerufene Prozedur- oder Funktionsname in den Spalten 1 bis 31 angegeben. In diesem Fall nimmt "Deadman" nur die Spalten 1 bis 7 ein. Die Dateikennung TA03801 ist in den Spalten 32 bis 38 aufgezeichnet.
Der Abschnitt 1, der durch das Bezugszeichen 40 bezeichnet ist, enthält allgemeine Informationen über das Zielprogramm einschließlich solcher Dinge wie die Anzahl von Testdatensätzen und der verwendeten Feldgröße.
Der Abschnitt 2, der durch das Bezugszeichen 41 bezeichnet ist, enthält spezifische Informationen über jede der Variablen, wobei 2 Zeilen jeder Variablen zugeordnet sind. Die Bemerkungen geben die in jeder Spalte der Datei aufgezeichneten Daten an einschließlich des Namens der zu überwachenden Variablen, ihrer Datenart (B-Byte, C-Zeichen, D-Doppelwort, H-Sedezimal, I-Ganze Zahl, L-Logisch, P-Zeiger, R-Real, W- Wort, X-Sedezimales Wort, Y-Sedezimales Doppelwort), eine Feldbezeichnung, eine Eingabebezeichnung, eine Ausgabebezeichnung und einen Auswertetyp (A-Argument, G-Global, L-Lokal, M-Modul, -Spezialbereich für "an" einem speziellem Speicherplatz befindliche Variable). Die Spalte 78 ist eine Allverwendungsbezeichnung, die ein Y ist, wenn diese Variable in sämtlichen Testdatensätzen verwendet wird. Die zweite Zeile, beispielsweise 42 für die Variable SEQ, gibt die Testdatensätze an, in welcher diese Variable benutzt wird. Beispielsweise werden alle vier Variablen in dem beispielsweisen Programm in allen drei Testdatensätzen verwendet.
Der Abschnitt 3, der durch das Bezugszeichen 42 bezeichnet ist, enthält die Anfangswerte für jede der Variablen für jeden der Testdatensätze. In diesem Fall sind die Testdatensätze durch die Ziffern 00, 01 und 02 gekennzeichnet.
Der Abschnitt 4 der TGP-Informationsdateiliste, der durch das Bezugszeichen 43 bezeichnet ist, listet die Aufrufe der getesteten Einheit mit der erforderlichen Argumentliste auf.
Der Abschnitt 5, der durch das Bezugszeichen 44 bezeichnet ist, listet den erwarteten Wert für jede Ausgabevariable für jeden Testdatensatz auf und gibt einen Feldindex an, wenn die Variable ein Feld ist.
Ein nichtdargestellter Kommentarabschnitt ist als Abschnitt 6 für den Benutzer vorgesehen, um irgendwelche testspezifischen Informationen hinzuzufügen, die während der Testausführung zu beachten sind.
Die vom TGP erzeugten Daten werden in einer Datei mit einer siebenstelligen Kennung wie der Dateiname sichergestellt, aber mit dem Zusatz .VAR, beispielsweise TA02838.VAR. Das zur Informationseingabe benützte Schnittstellenmanagementsystem, das vom Benutzer bereitgestellt wird, wurde bei dem beispielsweisen System unter Verwendung des Forms Management Systems auf einem VAX 780 und einem VAX 8600-Computer entwickelt. Das Quellenprogramm für den Testgeneratorprozessor wurde unter Verwendung der FORTRAN-Programmiersprache entwickelt und zwar ebenfalls auf einem VAX 780 und einem VAX 8600.
Die formatierte Datei vom TGP wird vom Testdatenprozessor (TDP) 13 zur Erzeugung einer Softwaretestspezifikation 14 sowie eines Teststeuerprogramms verwendet. Ein Beispiel relevanter Teile eines Teststeuerprogramms, das vom TDP erzeugt worden ist, ist in Fig. 11 dargestellt. Nach Erklärung der Variablen (in Fig. 11 nicht dargestellt) wird eine Ausführungsschleifenanweisung 44 eingefügt, welche die Anzahl von Testdatensätzen enthält, die von der Variablendatei abgeleitet ist. Dem Testprogramm wird dann eine Blockkennung "1" durch eine ACTLINKS-Anweisung 45 zugeordnet. Diese Blocknummer wird in die eindimensionale Blockverknüpfungstabelle eingeschrieben, während das Testprogramm ausgeführt wird, um eine Überwachung der Ausgabe zu erzeugen, die angibt, daß das Testprogramm abgelaufen ist. Als nächstes kommen in Fig. 11 die Anweisungen zur Eingabe der zugeordneten Werte für jede Variable in jedem Testdatensatz und zum Schreiben der Testdatensatznummer zusammen mit den Eingabewerten und den erwarteten Werten in die Ausgabedatei, wie bei 46 angedeutet ist.
Das Teststeuerprogramm ruft dann bei 47 den zu verifizierenden Prozedur/Funktions/Zielcode zusammen mit der entsprechenden Argumentliste aus der Variablendatei auf. Danach folgt eine Anweisung 48, die Instruktionen zur Steuerung des Ausgabeformats aufruft, und eine weitere ACTLINKS-Anweisung 49, die angibt, daß das Testprogramm vervollständigt worden ist.
Schließlich weist das Teststeuerprogramm Ausführungsanweisungen 50 auf, die Ausgangsvariablenwerte und Blockverknüpfungen, die in jedem Testdatensatz erzeugt worden sind, in die Ausgabedatei einschreiben.
Die vom Testdatenprozessor erzeugte Softwaretestspezifikation beschreibt das Testprogramm, das die erwarteten Blockverknüpfungen für jeden Testdatensatz identifizieren, sowie eine Wiederholung des Eingabewerts und des geprüften Ausgabewerts herstellen, die früher vom Verifizierer eingegeben worden sind. Die Softwaretestspezifikation (STS)-Datei 14 enthält keine Programmausführungsergebnisse, obwohl sie noch einen sehr wichtigen Teil der Gesamtprogrammdokumentation 19 darstellt. Teile der STS sind in den Fig. 12 und 13 dargestellt.
Fig. 12 zeigt die allgemeinen Eingabe- und Ausgabedaten. Fig. 13 zeigt einen der Testdatensätze, in diesem Fall den Testdatensatz 0. Die Reihenfolge der Blockausführung ist bei 51 angegeben. Die Anführungszeichen "1" jeweils am Anfang und am Ende der Reihenfolge gibt die Ausführung des Testprogramms selbst an. Die STS gibt auch die Werte der Eingabevariablen 52 und die erwarteten Werte der Ausgabevariablen 53 an. Eine ähnliche Aufzeichnung wird für jeden Testdatensatz durch die STS erzeugt.
An dieser Stelle ist der Zielcode bei 8 so konditioniert, daß der Pfad der Programmausführung und die Eingabe/Ausgabevariablenergebnisse in einer Ausgabedatei aufgezeichnet werden. Ein gesondertes Teststeuerprogramm 15 ist ebenfalls erzeugt worden und ruft den im Test befindlichen instrumentierten Zielcode auf, während ebenfalls alle Eingabe/Ausgabevariablen in der gleichen Ausgabedatei aufgezeichnet werden. Ein Programmkompilier-, Verknüpfungs- und Lokalisierprozessor (PCL) 16 verknüpft den instrumentierten Zielcode, der die Ausgabe des CIP 8 darstellt, mit dem Teststeuerprogramm 15.
Die aktuelle Ausführung des Testprogramms 15 und des Zielcodes wird unter Verwendung des SED-Prozessors 17 bewerkstelligt. Bei dem Ausführungsbeispiel der Erfindung in welchem ein VAX-Computer für die Prozessoren eingesetzt wurde, wurde ein Emulator zum Ausführen des PLM 86-Codes des Zielprogramms eingesetzt. Die Ausführung des Teststeuerprogramms/Zielcodes führte zum Schreiben der erzeugten aktuellen Ausgabewerte und der Blockverknüpfungen für jeden Testdatensatz in die Testergebnisse-Ausgabedatei 18. Ein Beispiel der Formatierung der Ausgabeergebnisse ist in Fig. 14 gezeigt. Die abschließende Dokumentation 19 des Programmverifizierungsprozesses schließt zusätzlich zu der Testergebnisdatei 18 die STS-Datei 14 ein, welche die Eingabewerte, die erwarteten Ausgabewerte, die erwarteten Blockverknüpfungen und Rationale für jeden durchzuführenden Testdatensatz definiert, und die PCT-Ausgabedatei 6 ein, welche die Pseudododestruktur und das zu verifizierende Programm zusammen mit seinen Blocknummern und den gültigen Blockverknüpfungen identifiziert. Diese Dokumentation wird analysiert, um für jeden Testdatensatz festzustellen, daß der Programmausführungspfad korrekt war und die aktuellen Ausgabewerte mit den erwarteten in Übereinstimmung stehen. Zusätzlich muß die Feststellung getroffen werden, daß alle Ausführungspfade getestet worden sind. Dies kann automatisch durch Vergleich der Blocknummern in der Blockdatentabelle mit den Blocknummern erfolgen, die während der Testausführung in die Ausgabedatei eingeschrieben wurden, um sicherzustellen, daß jeder Block mindestens einmal ausgeführt worden ist. Wenn die aktuellen Ausgabewerte in Übereinstimmung mit den erwarteten Ausgabewerten stehen, und wenn alle möglichen Verzweigungskombinationen entsprechend berücksichtigt sind, ist das Zielprogramm verifiziert.
Der Verifizierungsprozeß kann unter Verwendung eines Computersystems ausgeführt werden, wie es beispielsweise in Fig. 15 dargestellt ist. Dieses System weist einen Mehrzweck- Digitalcomputer 54 auf, der bei dem beispielsweisen System ein VAX-Computer war. Die Prozessoren sowie das Zielprogramm werden im Diskettenspeicher 55 gespeichert. Ein Anzeigeterminal 56 schafft die Dialogschnittstelle mit dem Verifizierer zum Wählen der Zieleinheit und der Testfalldaten. Dauerhafte Kopien der Ergebnisse der Verifizierung werden von einem Drucker 57 erzeugt.
Das beschriebene System automatisiert die frühere Arbeitsintensive komplexe Aufgabe der Codevorbereitung zum Ausführen einer ausreichenden Anzahl von Testfällen zum ausreichenden Verifizieren des Zielprogramms. Zusätzlich ist das System so ausgelegt, daß jeder Prozessor einen Teil der Gesamtaufgabe übernimmt und folglich Modifikationen des Systems leicht durch Änderungen in den einzelnen Prozessoren vorgenommen werden können. Ein weiterer Vorteil des Systems liegt darin, daß das Softwareverifizierungssystem notwendigerweise einheitlicher durchgeführt wird. Dieser Vorteil existiert unabhängig von dem zu testenden Programm oder dem den Test durchführenden Verifizierer. Des weiteren machen es das benutzerfreundliche Format und die Codifizierung des Verifizierungsprozesses auch für einen weniger Geübten möglich, die notwendige Softwareverifizierung durchzuführen. Schließlich ist das System in der Lage, mit Modifikationen eine Softwareverifizierung von Programmen durchzuführen, die in irgendeiner Computersprache und für irgendeinen Anwendungsfall geschrieben sind.

Claims

1. Verfahren zum Unterstützen der Verifizierung eines Computerprogrammquellencodes mit den Schritten:

a) Neuformatieren (3) des Quellencodes einer Programmquellendatei (1), wobei der Quellencode ein bekanntes Format und eine Reihe von Programmanweisungen aufweist, die Nichtsteueranweisungen und Steueranweisungen umfassen, mittels welcher das Programm sich auf alternative Programmanweisungen des Quellencodes verzweigen kann,

b) Auswählen (4) einer benutzergewählten Programmeinheit aus der neuformartierten Programmquellendatei,

c) Instrumentieren (8) der benutzergewählten Programmeinheit mittels eines Codeinstrumentenprozessors, der den Quellencode in Codeblöcke unterteilt, wobei ein Codeblock durch die Nichtsteueranweisungen zwischen Steueranweisungen markiert wird, und Einsetzen von ausführbaren Instruktionen in die Codeblöcke zum Schreiben einer Kennung in eine Ausgabedatei für jeden Codeblock, wenn er ausgeführt wird,

d) Erzeugen (12, 13) eines Quellentestprogramms mit Eingabewerten für die benutzergewählte Programmeinheit und erwarteten Ausgabewerten, um die Programmeinheit mit einer Mehrzahl von benutzergewählten Testdaten (9, 10) auszuführen,

e) Kompilieren, Verknüpfen und Ausführen (16, 17) des Testprogramms und der benutzergewählten Programmeinheit,

f) wobei die Ausführung eine Ausgabe (18) erzeugt, die aktuelle Ausgabewerte für jede Gruppe von Testdaten und eine sequentielle Auflistung der Blockkennungen der Blöcke der genannten benutzergewählten Programmeinheit aus der Ausgabedatei in der Reihenfolge darstellt, in welcher sie ausgeführt wurden.

2. Verfahren nach Anspruch 1, wobei der Instrumentierungsschritt das Betreiben eines Prozessors umfaßt, um nichtausführbare Anmerkungen mit einer einzigartigen Blockkennung am Anfang und am Ende jedes Codeblocks in die Zieleinheit einzusetzen, indem aus den Steueranweisungen und den Blockanmerkungen eine Blockdatentabelle erzeugt wird, welche den Block, durch welchen jeder Block eingegeben wird, den Verschachtelungsgrad des Blocks, und irgendwelche Rückführungen in einem Block identifiziert werden, und wobei der Schritt des Einsetzens ausführbarer Schreibinstuktionen in jeden Block die Verwendung der Anmerkungen und der Blockdatentabelle umfaßt, um am Anfang jedes Blocks eine Instruktion zum Schreiben der Blockkennung einzusetzen und am Ende jedes Blocks eine Instruktion zum Schreiben der Blockkennung des Blocks einzusetzen, zu welchem die Zieleinheit zurückkehrt.

3. Verfahren nach Anspruch 2, wobei der Schritt des Erzeugens eine Ausgabe das Erzeugen eines Vergleichs der Blockkennungen, die während der Ausführung eines Codeblocks in die Ausgabedatei eingeschrieben worden sind, und der Blockkennungen in der Blockdatentabelle umfaßt.

4. Verfahren nach Anspruch 2, wobei der Instrumentierungsschritt das Erzeugen einer Blockverknüpfungsdatei umfaßt, die alle möglichen Übergänge zwischen Codeblöcken in der Zieleinheit identifiziert.

5. Verfahren nach Anspruch 2, wobei die Zielcodeeinheit eine Rufinstruktion enthält, die einen externen Programmteil aufruft, und wobei der Instrumentierungsschritt umfaßt: Einsetzen einer ausführbaren Instruktion vor der Rufinstruktion zum Schreiben einer Rufkennung in die Ausgabedatei und Einsetzen einer ausführbaren Instruktion nach der Rufinstruktion zum Schreiben einer Kennung in die Ausgabedatei, daß das Programm an der richtigen Stelle in die Zielcodeeinheit zurückgekehrt ist.

6. Verfahren nach Anspruch 5, wobei der Instrumentierungsschritt das Einsetzen von Instruktionen zum Schreiben der Werte mindestens ausgewählter Zielcodevariablen in die Ausgabedatei vor und nach der genannten Rufinstruktion in die Zieleinheit umfaßt, und wobei der Schritt des Erzeugens einer Ausgabe das Erzeugen von Darstellungen der Werte der gewählten Variablen aus der Ausgabedatei vor und nach dem Ruf umfaßt.

7. Verfahren nach Anspruch 2, welches das Erzeugen eines Pseudocodes zur Verwendung beim Auswählen der genannten Testfälle durch Betätigung eines Prozessors umfaßt, um eine gesonderte Datei zu erzeugen, die nur die Steueranweisungen der Zieleinheit mit anstelle der Nichtsteueranweisungen eingesetzten nichtausführbaren Anmerkungen enthält, wobei die Anmerkungen die Blöcke mit den gleichen Kennungen wie die durch den Instrumentierungsschritt in den Zielcode eingesetzten Anmerkungen identifizieren.

8. Verfahren nach Anspruch 1, wobei der Schritt des Erzeugens eines Quellentestprogramms das Erzeugen einer Variablendatei für die Testvorgänge umfaßt, welche Eingabe- und Ausgabevariable für jeden Testvorgang zusammen mit Eingabewert für jede Eingabevariable und dem erwarteten Wert für jede Ausgabevariable auflistet, und wobei das Verfahren, wenn eine Programmrevision eine Änderung einer bezeichneten Variablen abruft, das Suchen dieser Variablendatei zum Identifizieren der Testvorgänge umfaßt, welche die bezeichnete Variable verwenden.

9. Verfahren nach Anspruch 1, wobei der Schritt des Erzeugens eines Quellentestprogramms das Erzeugen einer Software-Testspezifizierung umfaßt, welche die Werte von durch den Testtreiber zum Implementieren der Testvorgänge verwendeten Variablen und die erwarteten Werte von Ausgabeparametern auflistet.