Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

DIRLEWANGER-BERICHT

Testhilfen

28.10.1977

Dr. Werner Dirlewanger, Institut für Informatlk Universität Stuttgart

1. Teil

In WC Nr. 33/34 hatte der Autor das Thema Testhilfen bereits kurz angeschnitten, dabei aber gleich im ersten Punkt sich des Verweises auf ein deutsches Rechensystem bedient und ist nicht auf weitere Details eingegangen. Das sei nun hier nachgeholt, wobei aber darauf hingewiesen sei, daß alle anderen damals genannten Punkte weiterhin voll gelten und zu berücksichtigen sind.

Zur Notwendigkeit guter Testhilfen

Gute Testhilfen sind an fast keinem heutigen System zu finden, und es ist sehr eigenartig daß sich die meisten Computerbenutzer sehr leicht damit zufrieden geben, daß Fehlersuche beim Programmieren eine schwierige und trickreiche Angelegenheit sei. Dies kann wohl nur durch eine sehr eigenartige menschliche Verhaltensweise erklärt werden, die etwa wie folgt zu beschreiben ist: Nützliche bequeme und arbeitserleichternde Einrichtungen lehnt man - wenn man nicht damit vertraut ist - ab, es sei denn, man erfährt, gezwungen durch irgendwelche äußeren Umstände hautnah die Vorteile. Dann allerdings empfindet man sie als selbstverständlich.

Beispiele: Die Eisenbahn wurde im letzten Jahrhundert bei Einführung mit viel Mißbehagen betrachtet, ausgenommen diejenigen, die "erfahren" hatten was sie nützt; das Automobil wurde als unsinnig abgelehnt heute ist es der Mehrzahl selbstverständlich; automatische Getriebe in Pkw sind den Schaltgetriebeeignern verhaßt - diejenigen, die eines haben, möchten es nicht wieder hergeben; wer bisher im Assembler programmiert hat, kann sich nicht vorstellen, daß höhere Sprachen Vorteile bieten ( "mit 3 bis 4 Befehlen schreibe ich das genauso schnell hin").

Wenn dieser Assemblierer aber erlebt hat, wie ein Kollege der höhere Sprachen "spricht", schließlich doch ein Programm in viel kürzerer Zeit schreibt austestet und fertig hat, dann wundert er sich. Wenn der andere dann aber gleich noch zu erzählen weiß, daß er im Handumdrehen gleich noch eine vom Benutzer gewünschte Modifikation miteingebaut hat, während der Assemblierer noch immer über seinem ersten Binärdump brütet. dann sollte ihn das wenigstens nachdenklich stimmen. Dem "höheren" Programmierer sind seine Vorteile sicher selbstverständlich. Aber: Da hat sieh nun einer 2 Monate kräftig in FORTRAN oder COBOL abgemüht, seine Programme getestet und bei den täglichen Dumps immer wieder das doch so schöne Erfolgserlebnis gehabt, daß er in den 100seitigen binären oder hexadezimalen Dumps in weniger als einer halben Stunde den Fehler lokalisieren kann, und dann kommt einer und behauptet folgendes: Mir passieren zwar dieselben Programmierfehler wie dir, aber auf meinem System hole ich sie in Sekunden oder Minuten mittels quellbezogener Dumps und interaktiver Testhilfen (ebenfalls quellbezogen) raus.

Dieser Programmierer hat ein Rechensystem mit zeitgemäßen Testhilfen. Solche sind nachfolgend beschrieben, wobei dies als ein Beispielkatalog aufgefaßt werden soll und kein vollständiges Pflichtenheft darstellt. Testhilfen wie nachfolgend beschrieben, sollten heute bei allen Rechnern selbstverständlich sein, und zwar bei den Jumbos genauso wie bei den Minis oder Mikros. Ohne solche Hilfen zu arbeiten - egal auf welchem System -, heißt das Rad wieder zu erfinden. Und wenn nun jemand behauptet, sein Rechner sei zu klein, um "volle" Testhilfen zu haben, dann hat er das falsche System gekauft. Schließlich soll doch die Maschine die Arbeit erleichtern und nicht zur Arbeitsbeschaffung für Programmierer dienen. Auch bei sehr kleinen Rechnern lassen sich prima .Testhilfen realisieren, und wenn jemand eine so winzige Hardware hat, daß ordentliche Testhilfen tatsächlich nicht drin sind, dann ist der Apparat wirklich auch nicht zur Programmerstellung geeignet.

Beispiele wichtiger Testhilfen

- Dynamische Kontrollen: Durch entsprechende Angaben im Compiler und Executekommando soll während des Laufs entweder im ganzen Programm oder nur für einen oder mehrere Zeilenbereiche kontrolliert werden, ob Indexvariable nicht Feldgrenzen überschreiten, ob sieh Unterprogrammaufrufe bezüglich Anzahl und Art der aktuellen Parameter mit den formalen Parametern des Unterprogramms vertragen und ob Schleifenparameter zulässige Werte haben. Alle Fehlerausdrucke erfolgen ausschließlich auf Quellsprachebene,

- Dump: Im Alarmfall oder

auf explizite Anweisung (siehe den später behandelten Punkt "Kontrollereignis") sollen die momentanen Werte von Variablen auf Quellsprachebene ausgegeben werden. Dabei soll - die Hilfe eines sogenannten Rückverfolgers bereitstehen, welcher die aktuelle Aufrufverschachtelung von der Unterbrechungsstelle bis zurück ins Hauptprogramm in Quellsprachenform rekonstruiert. Es soll eine Reihe von Varianten des Dumps möglich sein: Dumpen von bestimmten oder allen Variablen von Hauptprogramm und allen Unterprogrammen; Dumpen von bestimmten oder allen Variablen der an der aktuellen Aufrufverschachtelung beteiligten Programme und Unterprogramme; Dumpen von bestimmten oder allen Variablen von ganz bestimmten Unterprogrammen

und/oder dem Hauptprogramm (etwa: "nur V1, V7 in Subroutine GEX" oder alle Variable außer Feld ARRAY in Subroutine NAM"); Dumpvarianten wie genannt, aber mit Setzen der Werte bestimmter Variabler auf angegebene Zahlen (oder Stringwerte) und Weiterstarten des Programmes an der Unterbrechungsstelle (zum Beispiel mit "13 = 10, V [7] = 2.11").

- In die bisher beschriebenen und später noch zu beschreibenden Testhilfmittel sollen nicht nur einfache Variable, sondern auch ein- und mehrdimensionale Arrays und Stringvariable einbezogen sein.