DE60010420T2

DE60010420T2 - Automatisches Regressionstesten von Arbeitsplatz-Software

Info

Publication number: DE60010420T2
Application number: DE60010420T
Authority: DE
Inventors: III William Murray Menomonee Falls Stoval; David P. Highland Edwards
Original assignee: GE Medical Systems Global Technology Co LLC
Current assignee: GE Medical Systems Global Technology Co LLC
Priority date: 1999-12-28
Filing date: 2000-12-21
Publication date: 2005-05-19
Anticipated expiration: 2020-12-22
Also published as: DE60010420D1; EP1113367B1; JP2001236246A; EP1113367A1; IL140456A; US6694509B1; IL140456A0

Description

Die Erfindung bezieht sich auf das Testen von Workstation-Hardware und -Software unter Verwendung von Rückfall- bzw. Regressions-Testtechniken.
Es existieren Computer-Programme, die zum Testen von Software-Anwendungen verwendet werden und die Eingangsdaten empfangen können, wie beispielsweise Tastenanschläge, die durch die Software-Anwendung erkannt werden können. Bei Empfang der Eingangsdaten haben diese Computer-Programme die Fähigkeit, die Eingangsdaten zu speichern (in Dateien, die Testscripts genannt werden) und diese dann erneut abzuspielen, so dass die Software-Anwendung funktioniert, als ob ein Benutzer tatsächlich die Eingangsdaten in die Software-Anwendung tippen würde. Auf diese Weise können Eingangsdaten wiederholt in die Software-Anwendung eingegeben werden, wobei ein Benutzer ein Testscript erzeugt, indem er die Eingangsdaten nur einmal eingibt.
Durch Verwendung eines derartigen Computer-Programms kann eine Software-Anwendung ausgeführt werden, indem ein vorbereitetes Testscript verwendet wird, um so zu verifizieren, dass die Software-Anwendung wie erwartet arbeitet. Dies kann erreicht werden, indem zuvor gespeicherte Ergebnisse mit Ergebnissen verglichen werden, die anschließend gewonnen wurden, indem das Testscript durch die Software-Anwendung erneut abgespielt wird. Die Tatsache, dass die Software-Anwendung wie erwartet arbeitet, kann auch als eine Anzeige verwendet werden, dass die Hardware, auf der die Software-Anwendung läuft, wie erwartet arbeitet.
Regressions- bzw. Rückfall-Testen beinhaltet, dass ein Programm mit vielen unterschiedlichen Tests bereitgestellt wird. Die Tests versorgen das Programm mit unterschiedlichen Eingaben. Diese Tests üben die speziellen Funktionen, Datenstrukturen und Merkmale des Programms. Um Regressionstesten auszuführen, führt ein Computer das Programm mehrere Male aus. Jede Ausführung verwendet einen anderen der Regressionstests in dem Script als Eingabe. Die Resultate der Regressionstests zeigen an, welcher der Tests bestanden wurde und welcher versagte.
Unterschiedliche Programmierer modifizieren unterschiedliche Teile von dem Source- bzw. Quellcode während der Entwicklung des Anwendungsprogramms. Üblicherweise kompiliert der Programmierer das Programm mit eben seinen/ihren Änderungen. Bevor der Programmierer die Änderungen freigibt, führt der Programmierer eine Anzahl von Tests mit den Änderungen aus. (Der Programmierer „gibt frei bzw. releases" Änderungen, indem er anderen in dem Entwicklungsteam gestattet, den geänderten Sourcecode zu benutzen.) Idealerweise enthält das Testen, dass die Regressionstests auf dem neu kompilierten Programm laufen. Das Regressionstesten zeigt, ob die Programmänderungen bewirken, dass einige der Regressionstests versagen.
Ein Problem mit dem Erfordernis, dass ein Programmierer die Regressionstests laufen lässt, wenn eine Änderung gemacht ist, besteht darin, dass das Regressionstesten Stunden oder sogar Tage beanspruchen kann. Regressionstest-Scriptbibliotheken können über Monate oder Jahre aufgebaut werden. Die Information über das, was von ihnen getestet worden ist, kann verloren gehen oder wird möglicherweise nicht aktualisiert. Zusätzlich macht das Volumen von Tests die Kenntnis, welche Tests gemacht worden sind, Anweisungen sehr schwierig. Die Tests können unsortiert oder unklassifiziert sein, welchen Teil des Programms sie testen. Selbst Tests, die verstanden sind, testen üblicherweise andere Teil von dem Programm als den Zielbereich. Deshalb ist es für einen Programmierer sehr schwierig zu wissen, welcher der Regressionstests einen bestimmten Teil des Programms testet.
Während der Entwicklung von einem Computersystem werden viele Anwendungsprogramme durch einen oder mehrere Programmierer über eine längere Zeitperiode üblicherweise erzeugt und modifiziert. Nachdem das Produkt freigegeben ist, werden Wartungsaktivitäten ein wichtiger Faktor während der Lebensdauer des Produktes. Studien haben herausgefunden, dass mehr als 50% der Entwicklungsbemühungen in dem Lebenszyklus von einem Softwaresystem in Wartung verbraucht wird und davon ein großer Prozentsatz aufgrund von Testen. Abgesehen von dem seltenen Ereignis einer größeren Umschreibung sind Änderungen an einem System in der Wartungsphase gewöhnlich klein und werden gemacht, um Probleme zu korrigieren oder die Funktionsfähigkeit schrittweise zu verbessern. Deshalb können Techniken für ein selektives Software-Neutesten helfen, die Entwicklungszeit und Wartungszeit zu verkürzen.
Eine Testscriptbibliothek, die verwendet wird, um ein Softwaresystem zu testen, besteht üblicherweise aus vielen Testscripts, die jeweils einen gewissen Untersatz von den Einheiten des unter Prüfung befindlichen Systems üben oder überdecken. Ein Testscript muss erneut taufen gelassen werden, wenn und nur wenn irgendeine der Programmeinheiten, die es überdeckt, geändert worden ist. Information über die Testscripts für die verschiedenen Softwareeinheiten in dem Computersystem erleichtert stark das Regressionstesten. Diese Information während der aktiven Entwicklungsperiode und der ausgedehnten Wartungsperiode des Produktes aktualisiert zu halten, ist sehr schwierig.
Das Dokument US-A-5,694,540 beschreibt eine Anordnung zum Ausführen von Regressionstesten auf einem rekompilierten Hauptsoftwareprogramm durch einen begrenzten Regressionstest, der auf Modifikationsanforderungen basiert, die mit einer früheren Modifikation verbunden sind, die an einem Software-Modul gemacht ist.
Das Dokument US-A-5,778,169 beschreibt ein Verfahren zum Testen einer modifizierten Version von einem Computer-Programm unter Verwendung von Regressionstesten, indem ein Überdeckungspunkt in den Sourcecode eingeführt wird, damit er einer Anweisung in dem Sourcecode entspricht, wodurch mehrere Tests an dem Sourcecode ausgeführt werden, um ein Ergebnis zu erzeugen, wobei das Ergebnis verwendet wird, um einen Untersatz von den mehreren Tests zu erzeugen, die den Überdeckungspunkt ausführten und die Anweisung getestet haben.
Die vorliegende Erfindung, die in den beigefügten unabhängigen Ansprüchen 1 und 10 im Detail definiert ist, ist ein Verfahren und eine Einrichtung zur Wartung einer Bibliothek von Testscripts zur Verwendung beim Regressionstesten von Anwendungsprogrammen. Genauer gesagt, es wird ein Testverzeichnisbaum gewartet, der ein Spiegelbild von einem Sourceverzeichnisbaum ist, der verwendet wird, um den ausführbaren Code für das Anwendungsprogramm zu kompilieren. Der Testverzeichnisbaum zeigt die Testscripts an, welche beim Regressionstesten eines ausführbaren Codes zu verwenden sind, der aus entsprechenden Einheiten in den glei chen Verzeichnisbäumen kompiliert ist. Wenn kein Spiegeleintrag in dem Testverzeichnisbaum existiert, wird einer automatisch erzeugt und es wird ein entsprechendes Standardtestscript erzeugt und in der Bibliothek gespeichert.
Es wird nun ein Ausführungsbeispiel der Erfindung als Beispiel unter Bezugnahme auf die beigefügten Zeichnungen beschrieben, in denen:
1 eine perspektivische Ansicht von einer Workstation ist, die modifiziert worden ist, um das bevorzugte Ausführungsbeispiel der Erfindung zu praktizieren;
2 ein elektrisches Blockdiagramm von der Workstation gemäß 1 ist;
3 ein Blockdiagramm ist, das die Software- und Datenstrukturen in der Workstation gemäß 1 darstellt, die verwendet werden, um Anwendungsprogramme zur Verwendung auf der Workstation zu erzeugen und zu testen;
4 ein Fließbild von den Schritten ist, die gemäß dem bevorzugten Ausführungsbeispiel der Erfindung ausgeführt werden, um ein Anwendungsprogramm zur Verwendung auf der Workstation zu kompilieren und zu testen;
5 ein Fließbild von den Schritten zum Kompilieren eines Sourcecodes mit zwei verbundenen Sourcecodedateien ist und
6 ein Fließbild von einem Baum zum Verbinden des Sourcecodes mit einer Kopfdatei ist.
Das bevorzugte Ausführungsbeispiel der Erfindung wird in einer Workstation (Arbeitsplatz) verwendet. Wie in 1 gezeigt ist, enthält die Workstation einen Minitower 10, der einen Prozessor und zugeordnete Schaltungsanordnungen, Speicher und periphere Interfaceschaltungen unterbringt. Eine der peripheren Vorrichtungen ist ein kommerziell verfügbarer CRT Monitor 12, der mit einer Grafikschaltung verbunden ist, die in dem Minitower 10 untergebracht ist, und eine weitere periphere Vorrichtung ist eine Tastatur und eine Maus 14, die einen PCI-basierten Controller in dem Minitower 10 verbindet. Eine Bedienungsperson kann Eingangsdaten durch die Tastatur eingeben und die Position von einem Cursor auf dem Monitor-Display 12 steuern, wobei die Maus verwendet wird. Die Workstation kann als ein allein stehendes Grafik-Displaysystem arbeiten oder sie kann verbunden sein, um digitalisierte Bilddaten direkt von einem medizinischen Bildgebungssystem zu empfangen, wie beispielsweise einem Röntgensystem, einem Röntgen-CT-System, einem MRI-System, einem PET-Scannersystem oder einem nuklearen Medizinsystem. Die Work station enthält üblicherweise Anwendungsprogramme, die Bildverarbeitungsfunktionen ausführen, wie beispielsweise Filtern der medizinischen Bilder, Transformieren der Größe und Orientierung der medizinischen Bilder und Hinzufügen von Texturinformation zu den medizinischen Bildern.
Es wird nun insbesondere auf 2 Bezug genommen, wonach die Workstation einen Prozessor 20 enthält, der in einem Speicher 22 gespeicherte Befehle ausführt. Der Prozessor 20 ist eine im Handel erhältliche Vorrichtung, die von Sun Microsystems, Inc. unter der Marke UItraSPARC-IIi verkauft wird. Er enthält einen auf dem Chip befindlichen Speicher und eine I/O Steuerung, um die Systemintegration zu erleichtern. Er ist ein superskalarer Prozessor, der die SPARC-V9 64-bit RISC Architektur implementiert und den Befehlssatz ausführt, der im Handel unter Marke „VIS" vertrieben wird. Er enthält auch einen integralen PCI Bus-Treiber, der ein direktes Interface mit einem 32-bit PCI Bus 24 bildet. Er enthält auch eine integrale Speichermanagementschaltung zum Handhaben aller externer Speicher 22.
Der PCI Bus 24 ist ein Industriestandard-Bus, der 32-Datenbits bei 33 MHz zwischen dem Prozessor 20 und einer Anzahl peripherer Steuerkarten überträgt. Diese umfassen eine PCI EIDE Steuerung 26, die für eine Hochgeschwindigkeits-Datenübertragung zu und von einem CD ROM-Treiber 28 und einen Scheibentreiber 30 sorgt. Eine Ethernet-Steuerung 32 unterstützt eine Datenübertragung mit einer Anzahl peripherer Vorrichtungen, einschließlich der Eingabe von der Tastatur und der Maus 14 und die Kommunikation mit Ehternet-Ports auf einem medizinischen Bildgebungsgerät. Und schließlich verbindet eine Grafik-Steuerung 34 den PCI Bus 24 mit dem CRT Monitor 12 über eine Standard VGA Verbindung 36.
Es wird nun insbesondere auf 3 Bezug genommen, wonach eine Anzahl von Programmen und Datenstrukturen in dem Scheibentreiber 30 gespeichert sind und verwendet werden, um Anwendungsprogramme zur Verwendung auf der Workstation zu erzeugen, zu modifizieren und zu testen. Ein derartiges Anwendungsprogramm könnte beispielsweise ein Programm zum Laden eines medizinischen Bildes und zum Filtern des medizinischen Bildes sein, um Artefakte zu beseitigen, die durch Patientenbewegung oder ähnliches hervorgerufen werden. Es wird deutlich, dass zwar nur ein einziger Benutzer 50 in 3 gezeigt ist, dass aber viele Benutzer, die jeweils eine getrennte Programmeditor-Software 52 bearbeiten, Anwendungsprogramme für die Workstation entwickeln können.
Der Source- bzw. Quellcode für Anwendungsprogramme, die mit dem Editor 52 entwickelt werden, werden in einem Speicher als Teil von einer Quellcode-Bibliothek 54 gespeichert. Weiterhin wird in dem Speicher ein Quellcode-Verzeichnisbaum 56 gespeichert, der Information über jede Quellcode-Programmdatei in der Bibliothek 54 enthält. Der Quellcode-Verzeichnisbaum 56 identifiziert, welche Quellcodedateien in der Bibliothek 54 ein bestimmtes Programm bilden, und zeigt an, wie diese Programmdateien miteinander verbunden sind. Diese Information wird von einem Compiler-Programm 58 benutzt, um die richtigen Quellcodedateien aus der Bibliothek 54 zu laden, sie in ausführbaren Programmcode zu kompilieren und den Programmcode richtig miteinander zu verbinden, um ausführbaren Code 60 zu bilden.
Der Benutzer 50 kann anweisen, dass ein Satz von Regressionstests mit dem ausführbaren Code 60 ausgeführt wird. um zu ermitteln, ob er richtig arbeitet. Dies wird durch ein Programm erreicht, das eine Regressionstestengine 62 genannt wird und das immer dann laufen gelassen wird, wenn ein neuer Quellcode kompiliert ist. In dem bevorzugten Ausführungsbeispiel wird die Regressionstestengine 62 jeden Abend laufen gelassen, und die Ergebnisse werden als ein Report 64 erzeugt, der am nächsten Morgen zur Verfügung steht.
Die Regressionstestengine 62 greift auf gespeicherte Regressionstestscripts 66 zu und verwendet diese Testscripts 66 um zu verifizieren, dass der ausführbare Code 60 wie erwartet arbeitet. Bekanntlich weisen die Regressionstestscripts 66 die Regressionstestengine 62 an, mit dem ausführbaren Code 60 zu arbeiten und Eingangsdaten zu liefern, um den Betrieb zu testen. Die Ergebnisse, die von dem ausführbaren Code 60 erzeugt werden, werden mit den Ergebnissen verglichen, die von dem Regressionstestscript 66 erwartet werden, und auf dem Report 64 wird eine Durchlauf- oder Fehler-Anzeige erzeugt. Der Report 64 ist somit eine Liste der Tests, die mit dem ausführbaren Code 60 ausgeführt wurden, und ein Anzeige, ob jeder Test durchgelaufen oder fehlerhaft war.
Das Management von dem Regressions- bzw. Rückfall-Testscript-Verzeichnis 66 und die richtige Auswahl der Rückfall-Testscripts darin zur Verwendung mit der Rückfall-Testengine 62 ist das Problem, auf das die vorliegende Erfindung gerichtet ist. Wie nachfolgend mit weiteren Einzelheiten beschrieben wird, verwendet die Lösung für dieses Problem einen Testverzeichnisbaum 68, der eine Datenstruktur ist, die während des Kompilierungsverfahrens des Programmes gewartet wird. Sie „spiegelt" den Quellcode-Verzeichnisbaum 56 und sie zeigt der Rückfall-Testengine 62 an, welche Testscripts in der Bibliothek 66 verwendet werden sollen, um den ausführbaren Code 60 zu testen.
Es wird nun auf 4 Bezug genommen; wenn ein Quell- bzw. Sourcecode in dem Verzeichnis 54 kompiliert werden soll, wird ein Programm laufen gelassen, wie es an dem Prozessblock 100 angegeben ist. Der Quellcode-Verzeichnisbaum 56 wird verwendet, um jede der Quellcodedateien zu identifizieren, die kompiliert und verbunden werden müssen. Wie in 5 dargestellt ist, wird beispielsweise eine Quellcodedatei „gvtk" zusammen mit zwei verbundenen Quellcodedateien „display" und „graphic" kompiliert. Wie oben erläutert ist, erzeugt dieser Kompilierungs- und Verbindungsprozess ausführbaren Code 60.
Der Testverzeichnisbaum 68 wird dann geprüft, wie es an dem Entscheidungsblock 102 angegeben ist. Dies wird dadurch erreicht, dass der Testverzeichnisbaum 68 nach „test"-Kopfdateien durchsucht wird, die denjenigen in dem kompilierten Quellverzeichnisbaum entsprechen. Wie in 6 dargestellt ist, hat beispielsweise ein vollständiger Testbaum die Kopfdateien „gvtktest", „displaytest" und "graphictest". Wenn irgendeine der entsprechenden Testkopfdateien nicht gefunden wird, wird eine neue Testkopfdatei erzeugt, wie es an dem Prozessblock 104 angegeben ist. Dieser Testkopfdatei wird der gleiche Name gegeben wie ihre entsprechende Sourcecodedatei mit dem angehängten Textstring „test". Ein Standard-Testscript für diesen neuen Testkopf wird dann, wie es bei 106 angegeben ist, zu dem Rückfall-Testscript-Verzeichnis 66 hinzugefügt. Der Standard-Script wird von einem „Testlauf"-Abschnitt, der ein standardisiertes Script für alle Programme ist, und einen „Testreport"-Abschnitt gebildet, der angibt, ob der Test implementiert worden ist oder nicht und, wenn dies der Fall ist, ob der Test durchlaufen wurde oder fehlerhaft war.
Für automatisch generierte Testdateien werden diese Tests nicht ausgeführt und zeigen „nicht implementiert" auf dem Testergebnisreport 64 an.
Um den Testverzeichnisbaum 68 zu warten, wird eine Prüfung am Entscheidungsblock 108 gemacht um zu ermitteln, ob irgendeine der Testkopfdateien darin verwaist ist. Eine „verwaiste" Datei ist eine Testdatei, deren entsprechende Quellcodedatei entfernt worden ist. Dies geschieht dadurch, dass jede Testkopfdatei in dem Testverzeichnisbaum 68 gelesen wird und nach ihrer entsprechenden Datei in dem Sourceverzeichnisbaum 56 gesucht wird. Wenn eine Waise gefunden wird, wird eine Fehlernachricht erzeugt, wie es an dem Prozessblock 110 angegeben ist, und der Benutzer 50 kann entweder die Waisen-Testkopfdatei weglassen oder sie umbenennen, wie es am Prozessblock 112 angegeben ist. In jedem Fall ist das Ergebnis ein Testverzeichnisbaum 68, der als ein Spiegelbild von dem Sourceverzeichnisbaum 56 beibehalten wird.
Der letzte Schritt in dem Kompilierungsprozess ist die Erzeugung einer „TESTE-ALLE"-Datei, wie es durch einen Prozessblock 114 angegeben ist. Diese Teste-alle-Datei wird von der Regressionstestengine 62 verwendet um zu ermitteln, welche Regressionstestscripts in der Bibliothek 66 beim Testen des neu kompilierten ausführbaren Codes 60 verwendet werden sollen. Sie wird dadurch gebildet, dass die Testkopfdateien aus dem Testverzeichnisbaum 68 gelistet werden, die den Sourcedateien aus dem Sourcecode-Verzeichnisbaum 56 entsprechen, der zum Kompilieren des Programms verwendet wird. In dem in den 5 und 6 gezeigten Beispiel ist die Teste-alle-Datei eine Liste der Dateinamen „gvtktest; displaytest und graphictest".
Die automatische Wartung bzw. Aufrechterhaltung des Testbaumverzeichnisses stellt sicher, dass die Testscripts für alle Sourcecodedateien erzeugt werden, die in dem Sourcecode-Verzeichnisbaum 56 gelistet sind. Unbenutzte oder verwaiste Testscripts werden identifiziert, und der Benutzer kann sie weglassen oder umbenennen. Wenn ein Regressions- bzw. Rückfalltesten auf einer periodischen Basis ausgeführt wird und eine Anzahl von Kompilierungen zwischen den Tests ausgeführt wird, sammelt die Teste-alle-Datei die Testscripts, die für alle Kompilierungen ausgeführt werden müssen. Doppelte Einträge in der Teste-alle-Datei werden weggelassen um zu vermeiden, dass Testscripts mehr als einmal laufen.

Claims

Workstation, die zum Entwickeln von Anwendungs-Programmen verwendet ist, enthaltend: einen Programm-Editor (52), der einem Benutzer ermöglicht, ein Anwendungs-Programm zu erstellen, eine Quellcode-Bibliothek (54) zum Speichern des Anwendungs-Programms, einen Quellcode-Verzeichnisbaum (56) zum Speichern von Namen von Dateien, die den Quellcode speichern, die gemeinsam das Anwendungs-Programm bilden, ein Testbaum-Verzeichnis (68), das die Namen von Testdateien speichert, die den Quellcode-Dateien entsprechen, die in dem Quellcode-Verzeichnisbaum (56) mit Namen genannt sind, ein Regressions- bzw. Rückfall-Testscript-Verzeichnis (66) zum Speichern von Testscripts, die den in dem Testbaum-Verzeichnis (68) genannten Testdateien entsprechen, und ein Regressions- bzw. Rückfall-Testprogramm (62), das auf Testscripts anspricht, die unter Verwendung des Testbaum-Verzeichnis ausgewählt sind, um ein Rückfall-Prüfen eines ausführbaren Codes (60) auszuführen, der aus Quellcode erzeugt ist, der unter Verwendung des Quellcode-Verzeichnisbaums (56) ausgewählt ist.
Workstation nach Anspruch 1, die ferner enthält: Mittel zum Prüfen der Dateinamen in dem Quellcode-Verzeichnisbaum (56) und der Testdateinamen in dem Testbaum-Verzeichnis (68) um zu ermitteln, ob es eine Testdatei gibt, die in dem Testbaumverzeichnis (68) entsprechend jeder Datei benannt ist, die in dem Quellcode-Verzeichnisbaum (56) genannt ist.
Workstation nach Anspruch 2, die ferner enthält: Mittel zum Erstellen eines neuen Rückfall-Testscript zum Speichern in dem Rückfall-Testscript-Verzeichnis (66) für jede Datei in dem Quellcode-Verzeichnisbaum (56), der keine entsprechende Testdatei hat, die in dem Testverzeichnisbaum (68) benannt ist, und Mittel (104, 20) zum Erstellen eines neuen Testdateinamens in dem Testverzeichnisbaum (68), der dem neuen Rückfall-Testscript entspricht.
Workstation nach Anspruch 3, wobei das neue Rückfall-Testscript ein Standard-Testscript ist.
Workstation nach Anspruch 3, wobei der neue Testdateiname eine Textzeichenfolge aufweist, die dem Dateinamen in dem Quellcode-Verzeichnisbaum (56) entspricht.
Workstation nach Anspruch 1, die ferner enthält: Mittel (108, 20) zum Prüfen von Testdateinamen in dem Testverzeichnisbaum (68), um Waisen-Testdateien zu identifizieren, die keine entsprechenden Dateinamen in dem Quellcode-Verzeichnisbaum (56) haben.
Workstation nach Anspruch 6, die ferner Mittel (110) enthält zum Anzeigen für einen Benutzer, daß eine Waisen-Testdatei in dem Testverzeichnisbaum (68) gefunden worden ist.
Workstation nach Anspruch 7, die ferner Mittel (112) enthält zum Löschen von Waisen-Testdateien aus dem Testverzeichnisbaum (68) und der entsprechenden Testscripts aus der Rückfall-Testscript-Bibliothek (66).
Workstation nach Anspruch 7, die ferner Mittel (112) enthält zum Ändern des Namens von verwaisten Testdateien in dem Testbaumverzeichnis (68).
Verfahren zum Erzeugen und Testen von Programmen auf einem programmierbaren System, wobei das Verfahren die folgenden Schritte enthält: a) Erstellen von Quellcode-Programmen unter Verwendung eines Editors (52), b) Speichern der Quellcode-Programme in einer Quellcode-Bibliothek, c) Speichern von Quellcode-Dateinamen in einem Quellcode-Verzeichnisbaum (56), die Quellcode-Programmen in der Quellcode-Bibliothek (54) entsprechen,