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.

Trotz Methoden zur konstruktiven Programm-Entwicklung:

Konzept für ein Testprogramm

08.09.1978

Betrachtet man die vielfältigen Hilfen, die heutzutage jedem Sachbearbeiter eines Unternehmens von der EDV zur Verfügung gestellt werden, und vergleicht diese mit der Computerunterstützung, die ein Programmierer erhält, so könnte ein Außenstehender leicht auf den Gedanken kommen, daß Programmieren die am schlechtesten bezahlte Tätigkeit des Computerzeitalters ist. In manchen Firmen wundert man sich, daß die Programmierer nicht noch selbst die Löcher mit dem Handlocher in die Lochkarten machen. Die Werkzeuge der Programmierer (Bleistift, Papier, Compiler) sind Erfindungen spätestens der 50er Jahre. Man wundert sich über die schlechte Software, obwohl doch die Menschheit den Umgang mit Papier und Schreibstift schon vor Tausenden von Jahren gelernt hat. In einigen EDV-Abteilungen wird ja sogar schon mit dem Bildschirm gearbeitet. Da programmiert man in einer sehr hohen, anwendungsfreundlichen Programmiersprache mit komplizierten Datenstrukturen und ausgefeilten Kontrollmechanismen. Nachdem ein Programm syntaktisch fehlerfrei ist, startet man es, schon rattert der Drucker los, und schließlich sitzt man nicht mehr vor dem Bildschirm, sondern vor dem hexadezimalen Speicherauszug. Und wo sind jetzt die komplizierten Datenstrukturen und strukturierten Kontrollmechanismen? Der Programmierer wird zunächst einmal zum Rückwärtscompiler, transformiert hexadezimale Adressen und findet bisweilen sogar seinen Fehler. Programmierer werden schließlich dafür bezahlt, daß sie eine Beziehung zwischen Speicherauszug und Quellprogramm herstellen.

Ein anderer Fall. Maschinen sind heutzutage ja schon recht schnell. Manche besitzen auch Testhilfen. Man startet also sein Programm mit der symbolischen Trace-Option, und schon geht's los. Da flimmern nun endlos Adressen über den Bildschirm, so daß bald auch die Augen flimmern. Oder man gibt den Trace auf den Drucker aus. Dann arbeitet man sich kurze Zeit später durch Berge von immer wiederholten Adressen, die eine 10 000mal durchlaufene Schleife bezeichnen.

Ich versuche hier einen Rahmen für ein Testsystem zu definieren, welches im ganzen Bereich des Testens von Code dem Benutzer umfassende Hilfen zur Verfügung stellt. Es ist mir klar, daß eigentlich primär Methoden der konstruktiven Programmentwicklung vorzuziehen sind, welche bereits in sehr frühen Phasen der Programmentwicklung syntaktische und semantische Fehler erkennen beziehungsweise vermeiden helfen; aber Testen als Vergleich von Soll- und Ist-Prozeß ist auch dann noch notwendig.

Rahmenbedingungen

Alle Tests müssen interaktiv ablaufen. Der Weg vom Test über Fehlererkennung, Ändern, Neucompilieren und Linken bis zum nächsten Test ist in der Batchversion einfach zu lang. Entweder der Programmierer wartet unproduktiv auf die Ergebnisse seiner Änderungen oder er ist gleichzeitig mit mehreren Programmen beschäftigt, was die Konzentration auf die jeweiligen Einzelprobleme vermindert.

Das Testen muß auf der gleichen sprachlichen Ebene stattfinden wie die Programmierung. Das heißt nicht nur daß Variablen symbolisch und ihre Inhalte in lesbarem Format gezeigt werden, sondern auch und vor allem: Das Testsystem muß mindestens die gleichen logischen und prädikativen Möglichkeiten aufweisen wie das zu testende System. Soll zum Beispiel in einem Cobol-Programm ein Ereignis überwacht werden, dann könnte die Eingabe für das Testsystem in etwa lauten: "CUT IF ereignis THEN GO TO USER." Die Sprache des Testsystems ist eine Obermenge der Sprache, in der die zu testenden Programme geschrieben sind.

Das Testsystem muß Selbsterweiterungsfunktionen aufweisen. Es stellt ein Makro- beziehungsweise Prozedurkatalogisierungssystem zur Verfügung, welches erlaubt, Tests auch nach Programmänderungen zu wiederholen ohne daß sämtliche Funktionen neu gesetzt werden müssen. In jeder Phase des schrittweisen Testens kann also auch von der Testseite her "nach dem Fehler wieder aufgesetzt werden".

Das Testsystem muß jederzeit für neue Benutzereingaben bereit, also unterbrechbar sein. Jede Entwicklung in der Programmausführung muß, sobald erkannt, vom Anwender beeinflußbar sein.

Das Testsystem muß sicherstellen, daß minimal sorgfältig getestet wird. Jeder Programmzweig muß mindestens einmal durchlaufen werden.

Welche Einzelfunktionen muß nun ein Testsystem aufweisen?

Regiefunktion

Tests finden statt auf Modul-, Komponenten- und Systemebene. Bei allen Tests muß für den zu testenden Code eine Umgebung bereitgestellt werden: Variable erhalten Initialisierungswerte, ein Return soll zum Anwender zurückführen, ein externes Ereignis soll eine bestimmte Ausführung bewirken. Die Regiefunktion erlaubt insbesondere:

Laden von Moduln, Komponenten und Systemen.

Initialisieren von Variablen, Strukturen und Mengen (Dateien).

Erzeugen externer Ereignisse (Interrupts, Benutzereingriffe).

Zeitraffer/Zeitlupe:

In einer bestimmten Phase des Testens interessieren den Programmierer nur bestimmte Teile eines Programmes; dennoch müssen andere Teile ablaufen. Die Aufnahmefähigkeit des Menschen ist beschränkt. Um den Programmfluß dynamisch beobachten zu können, muß die Geschwindigkeit der Ausführung steuerbar sein. Der Benutzer muß jederzeit in der Lage sein, ihn interessierende Programmteile langsam oder schnell ablaufen zu lassen. Eine Schleife, die l0 000mal durchlaufen wird, ist nur beim ersten Durchgang oder bei Überschreiten irgendwelcher Grenzwerte von Interesse; eine einfache IF-Verzweigung kann demgegenüber in einer bestimmten Situation und Datenkonstellation von größter Bedeutung sein.

Zoom-Funktion:

Mittels der Zoom-Funktion ist der Benutzer in der Lage festzulegen, auf welcher logischen Ebene ihm Informationen über Programmfluß und Zustände darstellen werden. Der Anwender muß in der Lage sein, eine Struktur hexadezimal aufbereitet zu betrachten und gleichzeitig ein Gleitpunktfeld im Displayformat, welches innerhalb der Struktur liegt. Einmal interessiert den Benutzer nur der Programmfluß auf der Ebene der Paragraphen, ein anderes Mal will er Statement für Statement sehen. Die Zoom-Funktion ist nicht ein-, sondern mehrdimensional. Es stehen gleichzeitig für unterschiedliche Programmteile (oder Situationen) unterschiedliche Optiken zur Verfügung. Die Zoom-Funktion bestimmt die logische, Zeitlupe und Zeitraffer die zeitliche Auflösung.

Projektion:

Ähnlich wie beim Film aus statischen Einzelbildern in der Projektion ein dynamischer Ablauf entsteht, wird bei einem Programmablauf das statische, in einer Sprache formulierte "Bild" in einen dynamischen Prozeß umgesetzt. Die Beziehung zwischen statischem Bild und dynamischem Ablauf wird durch die Projektion und Reprojektion transparent gemacht. Das Testsystem stellt die Beziehung dadurch her, daß nicht nur - wie bei einem Trace - Label ausgedruckt werden, sondern Statements direkt verändert werden können. Ein weiterer wesentlicher Punkt ist, daß nicht nur Zugriff auf das statische Programm gewährleitstet sein muß, sondern auch der Durchgriff auf die Dokumentation, welche schließlich beschreibt, was ein Programm eigentlich tun soll. Sehr oft nennt man Programme als ausgetestet wenn sie meistens nicht abstürzen (!); und nicht, wenn sie tun, was sie eigentlich sollen. Testen ist der Vergleich von Soll-Ausführung, -Wirkung und Ist-Ausführung und -Wirkung. Da sich Programmänderungen an verschiedensten Stellen auswirken können, muß auch von daher

der Zugriff auf Informationen über potentielle Nebenwirkungen vorhanden sein.

Replay-Funktion

Sehr oft stellt man beim Testen fest, daß etwas schiefgelaufen ist - und zwar in den letzen zwanzig Statements. Um aber zu wiederholen und genauer nachzuschauen, muß wieder von ganz vorne angefangen werden. Ein umfassendes Testsystem muß also eine Funktion enthalten, die es erlaubt, den Prozeß ein paar Schritte zurückzudrehen und noch mal (vielleicht langsamer) ablaufen zu lassen:

Wiederholung der letzten Statements, ausgehend vom "damaligen" Zustand mit veränderbaren Zeit-, Zoom- und Projektionsparametern.

Schnitt-Funktion:

Ein Break, wie es ihn in herkömmlichen Testsystemen gibt, ist nur Spezialfall eines allgemeinen Event-Monitoring, das Überwachen von Ereignissen. Sorgt die Regiefunktion für den Aufbau einer Programmszenerie, so erlaubt der Schritt das Überwachen von Ereignissen. Beispiele für solche Ereignisse: Variable liegen innerhalb bestimmter Intervalle, eine Bedingt wird wahr, es ereignet sich ein Interrupt, eine bestimmte Programmkomponente wird durchlaufen.

Allgemein erlaubt die Schnittfunktion:

Das Überwachen beliebiger Ereignisse auf der gerade-aktuellen Ebene sowie das Durchführen spezifischer Aktionen. (Rückkehr zum Benutzer, Anzeige des Ereignisses, . . .)

Hiermit sind die interaktiven Einzelfunktionen des Testsystems beschrieben.

*G. Ziegler ist Berater in Hamburg

???DV-Beratung Beck sitzt in der Lindenstraße 18 in 7261 Gechingen und nicht, wie in der Computerwoche-Marktübersicht "Standardprogramme für die Materialwirtschaft" (CW Nr. 32, vom 4.8.78) verdruckt war, in Hechingen.