Lösen Standard - Tools die Testproblematik?

09.06.1978

Testhilfe-Pakete sind offenbar nicht sehr beliebt in deutschen Programmier-Stuben. Die Argumente dagegen: Es liegt an der Bockbeinigkeit der Programmierer, die sich nicht ins Test-Handwerk pfuschen lassen wollen, und "die angebotenen Tools taugen nichts". Viele der vorhandenen Testhilfe-Programme sind in der Tat für universellen Einsatz nicht geeignet und als "Wegwerf-Produkte" einfach zu teuer. Daß sie generell das Test Testproblem nicht lösen helfen, hört sich indes wie eine Schutzbehauptung profil-neurotischer Programmierer an. Noch wehrt sich die Gilde allerdings erfolgreich gegen Methoden, die Programm-Erstellung transparent zu machen. Doch verrät Rainer Hartmann, Leiter der Geha-Daterverarbeitung: Standardisierte Testhilfe-Programme sind unnötig, wenn ,strukturiert' programmiert wird."

Peter Acker

Leiter des Referats

"Programmierung Personalwesen", Anstalt für kommunale Datenverarbeitung

(AKDB), München

Allgemeine Aspekte zu Standard-Testsystemen (Anforderungen):

Es muß einfach anzuwenden sein. Auch weniger routinierte Programmierer sollen damit arbeiten können. Andererseits sollen aber auch kompliziertere und komplexere Testprobleme; damit zu lösen sein.

Erfahrungen mit SL/1

Wir setzen seit zirka zwei Jahren das Testsystem SL/1 in der Grundversion Select von der GfS Gesellschaft für Systementwicklung mbH München und Köln bei uns ein. Der größte Nutzeffekt im praktischen Einsatz wird bei der Suche nach Programmierfehlern erreicht.

1. Durch einmaliges Übergeben von beliebig vielen Adressen zu überwachender Bereiche in SL/1 kann man sich vor oder nach jeder Modulschnittstelle eines Programmsystems einschalten und durch einfache SL/1-Statements diese Bereiche ausdrucken oder verändern.

2. Während des Programmlaufs werden Programmfehler die zu abnormalem Programmeinbruch führen würden abgefangen. Der Name des betroffenen Moduls die Fehleradresse die betroffenen Feldinhalte und alle Registerinhalte werden ausgegeben. Der Benutzer kann dann weitere Felder ausgeben lassen verändern und das Programm an beliebiger Stelle fortsetzen.

Weitere Anwendungen

Auch das Durchsuchen von Dateien nach bestimmten Suchkriterien und Dateiauswertungen (Statistiken) werden durch wenige einfache SL/1-

Statements durchgeführt ohne dafür Dateierklärungen angeben zu müssen. Beim Erstellen komplexer Programmsysteme werden noch fehlende Moduln beim Testen sehr einfach durch SL/1-Statements simuliert.

Sämtliche SL/1-Aufrufe im Programm können ohne Laufzeitverluste auch für Produktivläufe erhalten bleiben. Sie werden durch eine Angabe in der Job Control aktiviert beziehungsweise deaktiviert.

(Die laufende SL/1-Version wird Zur Zeit bei der GfS Gesellschaft für Systementwicklung überarbeitet und im Funktionsumfang erweitert.)

Rainer Hartmann

Leiter der Datenverarbeitung Geha-Werke, Hannover

Wir arbeiten seit etwa zwei Jahren mit der Strukturierten Programmierung. Das von uns eingesetzte Paket LSS von Advis stellt uns eine ganze Reihe von sehr schönen Testhilfen zur Verfügung es ist vom Aufbau und der Modularität her sehr testfreudig. Wir können unter anderem Durchlaufstatistiken erzeugen aus denen man ersehen kann in welchen Modulen das Programm gearbeitet hat. Zudem können auch Programmteile isoliert getestet werden - unabhängig vom Gesamtlauf des Programmes - wenn das Programm in der Struktur so aufgebaut ist.

Meiner Meinung nach sind standardisierte Testhilfe-Programme unnötig wenn man Strukturierte Programmierung anwendet. Aber leider sind die Zahlen hier in Deutschland enttäuschend vielleicht deshalb weil hierzulande auf diesem Gebiet noch ein gewaltiges Know-how-Defizit besteht. Viele schrecken vor der großen Arbeits-Investition noch zurück und der damit verbundenen "Nichtumkehrbarkeit" des somit eingeschlagenen Weges. Dennoch bin ich der Meinung, daß jeder, der die Vorteile der Strukturierten Programmierung einmal in der unmittelbaren Praxis erlebt hat, davon begeistert sein wird. Kosten- und zeitaufwendige Testhilfe-Programmerstellung von Anfang bis Ende transparent ist und bleibt. Wenn sich endlich mehrere Anwender dazu entschließen könnten, strukturiert zu programmieren, gäbe es sicher bald keinen Markt mehr für solche Testhilfe-Pakete.

Günter Müller

Leiter der Systemanalyse Holsten Brauerei, Hamburg

Im Jahre 1972 haben wir damit begonnen, uns mit CICS zu beschäftigen und ein Dialog-System aufzubauen. Dabei sind wir darauf gestoßen, daß die Unterstützungsmöglichkeiten zu diesem Zeitpunkt beinahe Null; waren. Deshalb mußten wir speziell für unseren Bedarf in Zusammenarbeit mit einem Software-Haus einige Programme selbst "bauen", die uns bei der Programmentwicklung weiterhalfen. So entstand erst einmal ein Programm, mit dem wir über einen Bildschirm den Hauptspeicher-Inhalt lesen und in der CiCS-Partition selbst auch den Speicher ändern können. Dieses Programm ist recht komfortabel aufgebaut, so daß wir uns bereits in den Startpunkten "das Leben leichtmachen", also Programme, Tables und ähnliches mehr aufrufen können und somit nicht mehr lange nach Adressen suchen müssen.

Über dieses Programm erhalten wir zudem einige Informationen über Devices und Testdaten mit den echten Speicherinhalten, ähnlich wie der Dump. Wir können mit einem entsprechenden Befehl in den Speicher direkt hineinschreiben und somit auch Veränderungen im laufenden System vornehmen.

Als weitere Testhilfe haben wir nach dem erfolgreichen Einsatz des ersten Programms ein weiteres selbst geschrieben, mit dem wir dasselbe auf Plattendateien erreichen. Wir können jetzt formatfrei die Platteninhalte lesen, schreiben und ändern. Hierbei handelt es sich um sehr umfangreiche Programmfunktionen, mit denen man z. B. Testdaten auf der Platte aufbauen kann, indem man sie über den Bildschirm eingibt oder - kopiert aus vorhandenen Sätzen - Veränderungen vornimmt. Zudem können wir in die Plattendateien "hineinsehen und uns Ergebnisse von Testläufen anschauen.

Inzwischen gibt es auf dem Markt zum Kauf angebotene interaktive Testsysteme, die jedoch den Rechner - für unsere Anwendungen - zu sehr belasten. Wir fahren unsere Dialog-Anwendung von morgens 6 Uhr bis abends 20 Uhr. Sie umfaßt den gesamten Versand und wesentliche Teile der Buchhaltung. Die Systembelastung unserer 370/158 mit 2 MB ist durch das TP derart hoch, daß wir uns die Belastung durch die angebotenen Testsysteme nicht leisten können. Wir sind also auf "selbstgestrickte" Testsysteme angewiesen. Derzeit prüfen wir, ob wir nicht eine Art interaktives Testsystem aufbauen können, mit dem wir Programme an bestimmten Punkten starten oder abbrechen können. Wir versuchen so, möglichst viele Testhilfen zu schaffen. Die Basis hierfür ist jedoch, daß man sich den Speicher- oder Platteninhalt ansehen können muß. Es ist viel zu umständlich, zu Testzwecken erst einen Dump zu ziehen oder Platten auszudrücken, um im Batch an die Daten zu kommen. Wenn wir schon am Bildschirm programmieren, müssen die Ergebnisse auch schnell zur Verfügung stehen.

Peter Clotten

Leiter der Systemprogrammierung Wacker Chemie, München

Standard-Software-Pakete als Testhilfen setzen wir in unserem Hause eigentlich nicht ein. Wir haben vor einiger Zeit unsere gesamte Programmierung auf online umgestellt und durch die interaktive Programmierung einige Möglichkeiten zur Verfügung, um unsere Programme bei der Entwicklung laufend zu testen. Datenbanken zum Beispiel können über den Bildschirm formatfrei oder auch unter Format angesehen und geändert werden. Zudem setzen wir Testhilfen für die Erstellung von Bildschirm-Maps.

Die von uns praktizierten Testhilfen werden nicht auf dem Software-Markt angeboten. Dieses Paket wurde ursprünglich von SCS für einen anderen Anwender entwickelt, und wir konnten es durch unser unter CICS eingesetztes Restart-Verfahren übernehmen.

Da wir bei der Online-Programmierung sehr straffe Vorgaben für die Programmentwicklung haben, kommen wir mit den uns zur Verfügung stehenden Testhilfen aus.

Es gibt allerdings ein Problem, mit dem wir uns seit längerer Zeit beschäftigen und nach einer Lösung auf dem Markt umsehen: Wir suchen - und das wird zur Zeit von der Systementwicklung geprüft - ein Datei-Auswertungs-Testprogramm, das auch einmal direkt in der Fachabteilung eingesetzt werden kann. Denn gerade bei Online-Systemen ist die Fachabteilung meist noch zu "unbewandert" um zu wissen, welche Entscheidungen zu treffen sind oder was sie im einzelnen haben will.