Testen: Lauffähige Software gibt es nicht zum Nulltarif

10.09.1982

Irren ist auch in der Datenverarbeitung menschlich. Unabhängig davon, welche Entwurfsmethoden oder Programmiersprachen benutzt werden: Fehler sind unvermeidlich. Tests helfen, Software-Macken zu lokalisieren und zu beseitigen. Nicht nur die inzwischen en masse angebotenen automatischen Hilfen sind wichtig, sondern viel mehr eine exakte Planung und Organisation. Erfolgreiches Testen verlangt zudem erheblichen Zeitaufwand. Wer hier spart, spart am falschen Platz. Zwar kann die Fehlersuche häufig zu einem recht teuren Unterfangen werden, aber: Vermeintliche Einsparungen führen in der Regel zu höheren Ausgaben für die Wartung. ih

Michael Hagenbach, Geschäftsführer, Menger & Partner EDV- und Wirtschaftsberatung,

Hattersheim

Seit die Software teurer wurde als die Hardware, sind viele Hilfsmittel zur Vereinfachung von Prograrnmiertätigkeiten entwickelt worden. Dazu zählen auch alle Arten von Testhilfen. Es wird beim Einsatz solcher Testhilfen oft vergessen, daß die eigentliche Testphase viel früher beginnen sollte als erst nach Fertigstellung der Programm-Module. Allzuoft wird das Testen von Programmen und Programm-Systemen zum "Anpassen an die Vorgabe" und zum "Anpassen" der Vorgabe an das Programm benutzt. Praxis ist es immer noch, als Testdaten einfach einen Teil der Originaldaten zu kopieren, wobei nicht sichergestellt ist, daß mit diesem Testbestand auch die möglichen Fehlerquellen, wie gewünscht erfaßt werden. Außerdem werden immer noch Testdaten ohne Kontrolle "unterwegs" durch sehr viele Job-Steps gefahren. Meist wird nur der End-Output geprüft.

Die Fachabteilungen sollten beim Testen viel stärker als bisher üblich beteiligt werden. Die Zusammenstellung der Testdaten sollte anhand der Systeskonzeption nur durch die Fachabteilung erfolgen wobei keine Dateikopien verwendet werden sollten. Auf Grund der praktischen Erfahrung im Umgang mit den jeweiligen Arbeitsgebieten sollte es für die Fachabteilung auch Leichter sein, gute Testdaten zu erstellen. Allerdings darf dabei der Aufwand nicht unterschätzt werden. Das Erstellen von guten Testdaten ist keine Sache von einem Tag.

Es zeigt sich auch immer wieder, daß Systemkonzepte absolut testunfreundlich sind. Das muß nicht sein. Bei einem sauberen Konzept ist es möglich alle Anforderungen an das System mit Testfreundlichkeit die auch für die Wartung des Systems sehr wichtig ist, zu verbinden.

Viele Probleme beim Testen entfallen durch eine starke Modularisierung. Daß dabei der Programmier-Aufwand ebenfalls sinkt, muß wohl nicht besonders erwähnt werden.

Durch schlechte Programmvorgaben werden Tests immer wieder behindert. Viele Systemanalytiker und Organisatoren erstellen Programmvorgaben immer noch für sich statt für den Programmierer. Dabei geht dem Programmierer der logische Kontakt zu "seinem" Programm verloren.

Er verliert das Verständnis für seine Testdaten und ist immer weniger in der Lage, seine Tests in den Griff zu bekommen.

Sehr schwierig gestaltet sich der Test bei der Eignungsuntersuchung von Software-Paketen. Die Anbieter dieser oft viel zu komplexen Systeme sind selten in der Lage, gute Dokumentation zu liefern, um die notwendige Einstiegsinformation zu geben.

Oft sind die Unterlagen zwar optisch sehr ansprechend, aber nicht informativ. Das führt dazu, daß der Interessent nicht weiß, ob er seine Ideen und Wünsche alle befriedigen kann. Dazu sind dann langwierige Gespräche mit den Vertriebsbeauftragten notwendig. Auch hierbei kommt die Fachabteilung meist zu kurz.

Obwohl sie später mit diesem System arbeiten soll, ist sie beim Funktionstest meist nur durch einen Abteilungsleiter vertreten, der das Tagesgeschäft kaum noch kennt. Eigentlich ist eine Probeinstallation für eine gewisse Dauer notwendig, um das Standardpaket in der Praxis zu testen. Dazu fehlt es aber meist an Zeit.

Wir versuchen immer wieder unsere Kunden zu überzeugen, für die Tests mehr Zeit einzuplanen. Diese Zeit kann durch gute Planung in der Programmierphase gespart werden. Außerdem sollte dauernd ein Mitarbeiter der Fachabteilung zur Verfügung stehen, der am Projekt von der Konzeptionierung bis zu Übergabe in die Produktion beteiligt ist.

Jürgen Freutel, RZ-Leiter, Hamburg-Münchener Ersatzkasse, Hamburg, (IBM 810014341 )

In unserem Hause werden zwei Systemfamilien mit unterschiedlichem Betriebssystem eingesetzt: IBM 8100 mit DDPX und IBM 4341 mit DSO/VSE. Bei der 8100 ist das Testen problemlos, weil im Dialog mit der DV-Anlage temporäre Testdaten und -dateien aufgebaut werden können. Am System 4341 zu testen, ist mit Schwierigkeiten verbunden.

Schuld daran ist nicht zuletzt unsere Hauptanwendung "Beitragswesen" mit einer täglichen und periodischen Bestandsfortschreibung (Zahlungsüberwachung beziehungsweise Bankabruf). Erst nach gewissen Zeitabläufen wird beispielsweise eine Mahnung erstellt, das heißt, ein zum Soll gestellter Beitrag ist erst einen Monat später nach Fälligkeit anzumahnen. Um diese Arbeiten testen zu können, müssen die Zeitabläufe von drei bis vier Monaten simuliert werden.

Dazu sind 30 Maschinenläufe innerhalb der Testserie durchzuführen, und zwar mit jeweils etwa 20 Testprogrammen. Das Ergebnis dieser Testserien sind viele Listen, die von der Testgruppe/Fachabteilung auf Richtigkeit und Vollständigkeit kontrolliert werden. Je Testserie müssen grundsätzlich die Testvorgaben erbracht werden. Eine weitere Schwierigkeit ergibt sich bei uns auch oder gerade als Sozialversicherungsträger aufgrund der gespeicherten persönlichen Daten der Mitglieder. Mit Originaldaten darf aus Datenschutzgründen nicht getestet werden. Der Aufbau von Testdatenbanken mit er dachten, aber wiederum wirklichkeitsnahen Daten ist sehr zeitaufwendig.

Das Verhältnis Programmier- zu Testaufwand sieht in unserem Unternehmen 40 zu 60 aus. Diese Zahl deutet an, wie schwer es ist, irgendwelche Arbeiten zu komprimieren. Die einzige Chance wäre unseres Erachtens, spezielle Dateien mit dem vorhergehenden Testlauf zu vergleichen und Abweichungen zu dokumentieren. Es wäre dann möglich, zu erkennen, ob eine Änderung gewollt war oder nach der Programmänderung Fehler entstanden sind. Bei dem Vorschlag handelt es sich nur um eine Lösungsidee, denn auch hier haben wir noch nichts gefunden, was uns die Spuldateien von zwei Testläufen miteinander vergleicht und Differenzen aufzeigt.

Harry M. Sneed, Geschäftsführer, Software Engineering Service GmbH, Neubiberg

Der Test von Anwendungsprogrammen ist bisher gegenüber Entwurfsverfahren und Programmiertechniken etwas zu kurz gekommen. Denn unabhängig davon, welche Entwurfsmethodik oder welche Programmiersprache benutzt werden, Fehler sind unvermeidlich. Nach einer Untersuchung der TRW in den USA macht der Mensch 1,5 Fehler pro 100 Zeilen, die er schreibt, oder pro 100 Striche, die er zeichnet. Davon wird er selber rund 50 Prozent merken. Das heißt, es bleiben rund 0,7 Prozent aller Zeilen fehlerhaft. Diese Fehlerrate bleibt konstant, ob man Assembler, Cobol, PDL oder Deutsch schreibt, denn Irren ist menschlich. Um die absolute Anzahl von Fehlern zu reduzieren, kann man allenfalls weniger schreiben beziehungsweise zeichnen.

Wenn dies so ist, und alles scheint dafür zu sprechen, bleibt nichts anderes übrig, als die Fehler zu suchen. Darin liegt die Begründung des Testens, nämlich die unvermeidlichen Fehler zu lokalisieren und zu entfernen.

Es gibt verschiedene Möglichkeiten, die zu tun. Eine der besten und kosteneffektivsten ist, wenn ein Kollege den Code oder die Dokumentation noch einmal sorgfältig liest. Dieses Prüflesen oder Lektorieren ist eine Selbstverständlichkeit für jedes Manuskript. Bei Programmen, in denen es auf die Genauigkeit viel mehr ankommt, scheint keiner daran zu denken.

Eine andere Möglichkeit ist die Ausführung des Programms, ohne zu wissen, was dabei herauskommt. Ist man sich über die Zielsetzung nicht im klaren, kann dies im Chaos enden. Daher empfiehlt es sich, nur gegen eine exakte Spezifikation zu testen. Zwischen diesen beiden extremen Möglichkeiten des Prüflesens und des Probierens gibt es zahlreiche Zwischenlösungen, wie beispielsweise die statische Programmanalyse mit Hilfe eines Werkzeugs, die Interpretation des Codes und die Ausführung der Module in einem sogenannten Testrahmen, in dem das Programmverhalten genau überwacht wird.

Der Umfang des Tests hängt von der erwarteten Zuverlässigkeit ab. Gibt man sich mit einem Zuverlässigkeitsgrad von 95 Prozent zufrieden, kann der Test sehr billig sein. Es kommt nur darauf an, die schlimmsten Macken herauszubekommen. Will man aber 99 Prozent oder mehr Zuverlässigkeit erreichen, muß der Entwickler viel mehr in den Test investieren. Jedes zusätzliche zehntel Prozent schlägt zu Buche. Und ohne adäquate Testwerkzeuge kommt man überhaupt nicht in die höhere Sphäre der Zuverlässigkeit hinein.

In anderen Worten: Testen ist, wie alles andere, eine Frage der Kosten. Wer es sich leisten kann, bekommt eine zuverlässige Software. Wer es sich nicht leisten kann, muß sich eben mit Fehlern abfinden. Es gibt leider keinen Nulltarif.

Hans-Peter Niederhausen, Hauptabteilungsleiter Betriebswirtschaft, Friedr. Krupp GmbH, Krupp Gemeinschaftsbetriebe, Essen

Größere Programmiersysteme werden nach den Methoden des modernen Softwareengineerings in klar abgegrenzten Phasen mit wohldefinierten Phasenergebnissen entwickelt. Syntaxtest, Testvorbereitung, Modultest Integrationstest und Abnahmetest sind dabei eigene Phasen. Die Anzahl dieser unterschiedlichen Phasen dokumentiert die Bedeutung des Testens im Rahmen der gesamten Projektabwicklung.

Den Test betreffende Aktivitäten sind jedoch nicht auf diese Phasen beschränkt. Das Testen ist vielmehr durch alle Phasen hindurch zu planen und vorzubereiten. In der Grobplanung ist unter anderem festzulegen, in welcher Umgebung, mit welchen Testdaten und mit welchem Testdeckungsgrad die Teste durchzuführen sind und welche speziellen Fehler gegebenenfalls durch erhöhten Testaufwand möglichst auszuschließen sind. Bei der auf dem Grobkonzept basierenden Kalkulation der Entwicklungskosten des Projektes darf nicht übersehen werden, daß unterschiedliche Anforderungen an das Testen auch zu sehr unterschiedliche Kosten führen. Die späteren Wartungskosten hängen ebenfalls von dem Testumfang ab Vermeindliche Einsparungen bei den Testkosten führen oft zu vielfach höheren Ausgaben in der Wartungsphase.

Der systematische und effiziente Test eines Programms ist nur dann durchzuführen wenn alle relevanten Daten in der Sequenz visualisiert werden, wie sie im Programmablauf entstanden oder zu Verfügung standen. Zu diesen Daten zählen alle Schnittstellen eines Moduls zu seiner Außenwelt. In den Phasen Feinplanung und Codierung sind zur übersichtlichen Visualisierung der Testausgaben auf Listen oder Bildschirmen die entsprechenden Programmteile zu planen und zu codieren.

Für die Erstellung der Testdaten, die zur Erreichung des geforderten Testdeckungsgrades benötigt werden, ist eine eigene Phase Testvorbereitung vorzusehen. Durch systematischen Testdatenaufbau kann der Testaufwand für ein Programmsystem, der oft bis zu 40 Prozent der Gesamtentwicklungskosten beträgt, sehr positiv beeinflußt werden.

In den Phasen Modultest, Integrationstest und Abnahmetest ist strikt nach der freigelegten Testplanung vorzugehen. Die Ergebnisse dieser Phasen gehören ebenso zur Systemdokumentation wie Programmlisten und Systembeschreibungen.

Sehr vorteilhaft ist es, die Testorganisation einschließlich aller Testdaten über den Entwicklungszeitraum hinweg für Wartungs- und Weiterentwicklungszwecke aufrechtzuerhalten. Hierdurch können Fehlerrisiken minimiert und Wartungs- und Weiterentwicklungskosten gesenkt werden.

Ob in naher Zukunft der erhebliche Aufwand für das Testen durch Werkzeuge für die Programmentwicklung und den Programmtest nachhaltig reduziert werden kann, bleibt abzuwarten.