Die Bedeutung der Qualitätssicherung insbesondere in den frühen Projektphasen ist bekannt. Je eher ein Fehler entdeckt wird, desto einfacher ist seine Behebung. Der letztmögliche Zeitpunkt, zu dem die Notbremse gezogen werden kann, ist die Testphase.

Methodisches Vorgehen und die Beherrschung der verfügbaren Tools, so meint Heinrich Braun*, sind bei der Fehlerkorrektur unabdingbar.

Das Testen von Programmen gilt als uninteressante Aufgabe und wird in der Regel lustlos betrieben. Dabei kann es faszinierend und hochproduktiv sein, vorausgesetzt, man beherrscht die Methodik und kann mit den entsprechenden Tools umgehen. Jedoch genügt der Einsatz von Werkzeugen nicht, um das Testproblem in den Griff zu bekommen. Nötig ist vielmehr, eine klare Methodik Zu erarbeiten und anzuwenden.

Erst auf dieser Basis können Werkzeuge ausgewählt und eingesetzt werden. Die Unterstützung der langweiligen Tätigkeiten durch geeignete Tools kann allerdings die praktische Umsetzung einer solchen Testkonzeption erleichtern. Folgende Tätigkeiten kehren beim festen immer wieder:

- Kritische Systemteile müssen gefunden werden, denen man beim Test gesonderte Aufmerksamkeit widmet.

- Testfälle sind zu beschreiben, Testdaten zu erstellen.

- Testfälle und -daten müssen verwaltet und bei Bedarf bereitgestellt werden.

- Der Tester hat Code-Inspektionen vorzunehmen und Programme symbolisch auszuführen.

- Die Testumgebung ist vor jedem Test zu initialisieren.

- Tests müssen durchgeführt und wiederholt werden.

- Der Verantwortliche hat zu überprüfen, wie vollständig bisher getestet wurde.

- Die Ergebnisse, die der Programmtest erzeugt, sind mit den Resultaten des letzten Tests zu vergleichen.

- Fehler müssen geortet und korrigiert werden.

- Der Tester muß die anfallenden Daten speichern, verwalten und auswerten.

Sämtliche genannten Tätigkeiten lassen sich durch die DV unterstützen. Je fader die Tätigkeit ist (zum Beispiel der Vergleich der Testergebnisse), desto umfangreicher ist eine Tool-Unterstützung. Umgekehrt gilt: Je interessanter die Tätigkeit (zum Beispiel der Vergleich der Testergebnisse), desto umfangreicher ist eine Tool-Unterstützung. Umgekehrt gilt: Je interessanter die Tätigkeit (zum Beispiel das Ausarbeiten der Testfälle), desto geringer ist die Auswahl in verfügbaren Tools.

Bei der Testvorbereitung geht es darum, Testschwerpunkte zu finden, Code-Inspektionen durchzuführen sowie Testfälle und Testdaten zu erarbeiten.

Die Qualitätsanforderungen an DV-Systeme oder Systemteile sind nicht immer gleich hoch. Sie müssen individuell festgelegt werden - dabei kann kein Tool helfen. Es gibt ,jedoch weitere Anforderungen an die Testvollständigkeit. Diese ergeben sich unter anderem aus der Komplexität des Codes, der zur automatisierenden Funktionen des zugrundeliegenden Datenmodells etc. Komplexe Funktionen müssen ausführlicher überprüft werden als weniger komplexe.

Testschwerpunkte mit Upper-CASE-Tools finden

Beim Finden der Testschwerpunkte helfen sowohl Softwaremetriken als auch grafische Darstellung. Auf der konzeptionellen Seite lassen sich Upper-CASE-Tools einsetzen. Was den Sourcecode betrifft, gibt es mittlerweile gute Werkzeuge, die eine große Anzahl von Metriken und teilweise auch grafische Darstellungen und Programmpfade sowie der Daten- und Informationswege liefern.

Code-Inspektionen und symbolische Programmausführungen sind eine sehr effektive und preisgünstige Art, Fehler zu finden. Bei Code-Inspektionen wird das Programm Art, Fehler zu finden. Bei Code-Inspektionen wird das Programm daraufhin untersucht, ob bestimmte Fehlerquellen vorhanden sind und vorgeschriebene Standards eingehalten werden. Es gibt umfangreiche und Praxisnahe Checklisten zu diesem Thema. Viele Punkte darin können automatisch überprüft werden. Dies bietet zwei Vorteile: Zum einen ist die Prüfung vollständig und korrekt (Menschen können vorhandene Ungereimtheiten übersehen), zum anderen kann der Programmierer die Prüfung selbst veranlassen und muß sich nicht der Kontrolle seiner Kollegen unterwerfen.

Der Fingertest ist ein bewährtes Verfahren

Die symbolische Programmausführung ist allgemein als Fingertest bekannt. Auch hier gibt es Tools zur Unterstützung. Der Sourcecode erscheint am Bildschirm, wobei Befehl für Befehl hell angezeigt wird. Bei Programmverzweigungen wird ein Weg ausgewählt und weiter verfolgt. Man kann dies als Spielerei ansehen, wer aber damit gearbeitet hat, wird darauf nicht mehr verzichten wollen.

Bei der Erarbeitung der Testfälle und -daten ist zu unterscheiden, für welche Art von Tests die Daten benötigt werden. Dazu gehört selbstverständlich auch das Vorausberechnen der Testergebnisse. Testfälle und -daten für White-box-Tests werden aus dem Sourcecode entwickelt. Der vorhandene Code soll ja einer möglichst vollständigen Prüfung unterzogen werden. Eine maschinelle Erzeugung von Testdaten aus dem Sourcecode - es gibt solche Tools - empfiehlt sich jedoch nicht, da fehlerhaft programmierte Entscheidungen zu genau den gleichen Fehlern im Testdatenbestand führen und damit nicht auffallen.

Sinnvoller ist es, auch hier Tools einzusetzen, die den Sourcecode analysieren. Die grafische Darstellung von Programmzweigen sowie Daten- und Informationswegen hilft, Testdaten zu entwickeln, die von Beginn an eine gute Code-Abdeckung gewährleisten. Ist diese Abdeckung noch immer nicht ausreichend, so kann sie nach den Tests überprüft und weiter verbessert werden.

Testfälle und Testdaten für Black-Box-Tests werden aus dem Fachkonzept entwickelt (Geschäftsvorfälle). Die Umsetzung geschieht manuell. Es gibt Anforderungen, diese Beschreibungen von Testfällen zum Beispiel aus der strukturierten Analyse oder einer anders formalisierten Vorgehensweise mit Hilfe von Werkzeugen abzuleiten. Hier gibt es jedoch noch Möglichkeiten zur Verbesserung.

Vor der naheliegenden Möglichkeit, Testdaten für Black-box-Tests aus Produktionsdaten abzuleiten, möchte ich nachdrücklich warnen. Auf diese Weise werden nämlich nur die Standardfälle getestet - und zwar immer wieder.

Für Volumentests können Ausschnitte aus Produktionsdaten zum Einsatz kommen, denn hier geht es hier lediglich darum zu testen, was passiert, wenn bestehende Systemgrenzen, zum Beispiel Dateigrößen, verletzt werden. Tools dazu sind ausreichend vorhanden und finden in der Regel auch Anwendung.

Streßtests dienen dazu herauszufinden, wie das System auf Belastungsspitzen reagiert. Dabei geht es um Online-Eingaben. Es gibt Werkzeuge, die die Zahl der logischen Terminals und der Transaktionen simulieren können. Diese Verfahren läßt sich bis an die Grenzen der Systembelastung treiben.

Vorausberechnen von Testaufgaben ist nötig

Im Mittelpunkt von Regressionstests steht die Zuordnung von Daten, die bereits aus den anderen Testarten vorhanden sind. Unterstützung bieten diverse Arten von Softwarewerkzeugen auf sehr unterschiedlicher Weise, jedoch muß dieses Problem organisatorisch gelöst werden.

Das Vorausberechnen von Testaufgaben ist eine der essentiellen Tätigkeiten bei der Testvorbereitung. Unterstützung durch allgemein verwendbare Tools ist hier nicht möglich - es sei denn, es handelt sich um einfache DV-technische Funktionen wie das Duplizieren von Daten. Wenn Altsysteme abgelöst werden sollen, können diese zum Einsatz kommen, wobei die so entstehenden Testaufgaben natürlich noch zu überprüfen und gegebenfalls zu modifizieren sind. Auch lassen sich einfache PC-Lösungen denken (deren Ergebnis muß ebenfalls überprüft werden und bei Bedarf modifiziert werden), wenn die zu testende Software auf Mainframes laufen soll.

Kommen wir zur Testdurchführung. Als erster Schritt ist die Datenumgebung zu initialisieren, die Ausführungs- und Nachbearbeitungsphase schließen sich an. Zur Datenumgebung gehört der Tastatur-Input, gegenfalls sequentielle Eingaben sowie Daten in einer Datenbank oder in sonstigen Direktzugriffs-Dateien. Tastatureingaben lassen sich DV-technisch festhalten. Ihre Aufzeichnung erfolgt in einem "Script", das anschließend geändert werden kann, um weitere Testdaten aufzunehmen. Solche Scripts werden dann - mit oder ohne Modifikation - abgespielt. Eine Wiederholung von Online-Tests ist in der Praxis ohne die automatische Aufzeichnung von Tastatureingaben nicht möglich. Die Wiederholbarkeit von Tests gilt jedoch als deren Grundvoraussetzung.

Sequentielle Eingaben müssen lediglich aufgehoben und für weitere Tests zur Verfügung gestellt werden. Natürlich sind auch Daten in der Datenbank oder in Direktzugriffs-Dateien für den Test zu initialisieren. Dafür gibt es zwei Möglichkeiten: entweder wird der benötigte Stand der Daten unmittelbar vor dem Test geladen, oder die durchgeführten Änderungen werden unmittelbar nach jedem Test zurückgenommen.

Für beide Möglichkeiten reichen oft die Utilities aus, die zum entsprechenden Datenbanksystem gehören. Das Problem ist, daß diese DB-Tools für Testzwecke häufig nicht genutzt werden, weil die Handhabung sehr umständlich ist - und das, obwohl sich hier ebenfalls eine Grundvoraussetzung für die Wiederholbarkeit von Tests schaffen ließe. Es gibt Test-DB-Tools, die das nötige Handling erleichtern, und oft noch weitere Vorteile bieten.

Tests sollen asynchron, also im Batch-Betrieb, ablaufen und dabei die verwendeten Dateien, die Datenbanken etc. exklusiv nutzen.

Die Initialisierung der Umgebung sowie maschinell zu bewerkstelligende Anteile der Auswertung gehören als fester Bestandteil zu den Tests. Planung unbeaufsichtigt ablaufen, und parallel angestoßene Daten verwenden, zerstören nicht gegenseitig das Datenumfeld.

Beim dritten Schritt, der Testnachbereitung, müssen zum einen Abweichungen gegenüber den Ergebnissen des letzten Tests (oder eine sonstige Referenz) festgestellt und bewertet werden, zum anderen ist die bisher erreichte Testabdeckung zu überprüfen. Konsequenz aus dieser Überprüfung könnte sein, daß weitere Testfälle definiert werden müssen.

Um Änderungen bei den Ergebnissen zu erkennen - die durchaus beabsichtigt sein können, werden die Auswirkungen, die das zu testende Programm auf seine Datenumgebung hat, mit einem Referenzstand verglichen. Anschließend erfolgt dann eine Bewertung der Unterschiede, die nicht maschinell unterstützt werden kann. Zu der Datenumgebung gehören Bildschirmausgaben, unter Umständen sequentiellen Ausgaben sowie Daten in der Datenbank oder in Direktzugriffs-Dateien.

Die erfolgten Bildschirmein- und -ausgaben können durch Einsatz entsprechender Werkzeuge während der Tests aufgezeichnet werden (im IBM-Umfeld meist auf VTAM-Basis). So entstehen Datenbestände, die sich maschinell vergleichen lassen. Um diese

Vergleiche handhabbar zu machen, bieten Tools zur Aufzeichnung der Tastatureingaben in der Regel auch eine Vergleichsfunktion für die Bildschirmein- und -ausgaben. Damit kann der lästige und fehleranfällige manuelle Vergleich entfallen. Gekennzeichnet werden nur die Unterschiede im Vergleich zum Referenzbestand.

Tools müssen "Intelligenz" besitzen

Zum Vergleich sequentieller Ausgaben gibt es Werkzeuge, die, ähnlich wie im vorherigen Absatz dargestellt, nur die Unterschiede zum Referenzbestand anzeigen. Wichtig ist, daß diese Tools Intelligenz besitzen. So muß es zum Beispiel möglich sein, bestimmte Felder aus dem Vergleich auszuschließen, etwa die Laufzeit, und Synchronisatioskriterien zu definieren für den Fall, daß Zeilen entfalten oder hinzukommen.

Um diese Auswirkungen zu überprüfen, die das zu testende Programm auf eine Datenbank oder sonstige Direktzugriffs-Dateien hat, gibt es zwei Möglichkeiten: entweder wird der Stand der Datenbank nach dem Test mit einer Referenz verglichen, oder man schreibt die Änderungen mit, die das Programm ausführt, und vergleicht den Logbestand mit einer Referenz.

Diese zweite Möglichkeit erlaubt eine detailliertere Analyse und läßt sich durch Tools unterstützen. Dennoch ist diese Verfahren eher die Ausnahme. Es reicht auch, den Stand der Daten nach erfolgtem Test mit einer Referenz abzugleichen. Auch hierfür gibt es Vergleichswerkzeuge.

Zur Testnachbereitung gehört auch die Überprüfung, ob mit dem vorliegendem Test alle definierten Testfälle mindestens einmal erfolgreich durchgespielt wurden. Bei Black-Box-Tests gibt es Werkzeuge, die zumindest Teilunterstützung liefern. Eine vollständige Unterstützung durch Tools wäre durchaus denkbar und wünschenswert. Dann müßte das Problem nur noch auf der Organisationsseite gelöst werden.

Eine gute Werkzeugunterstützung gibt es für White-box-Tests: So sind Tools zur Testabdeckungs-Überprüfung verfügbar, die aufzeigen, welche Programmteile bisher wie oft getestet wurde. Zu diesem Zweck wird üblicherweise der zu testende Code von diesem Tool verändert Je nach Qualität des Werkzeugs erfolgt diese Überprüfung nach unterschiedlichen Kriterien.

Testbewertung nicht werkzeugunterstützt

Eine reine Statement-Abdeckung reicht nicht aus. Wie bereits ausgeführt, gibt es Tools, die helfen, Testschwerpunkte zu finden und damit Vorgaben zu der Vollständigkeit von Tests zu machen . Werkzeuge zur Testabdeckungs-Überprüfung können eingesetzt werden, um die Einhaltung dieser Vorgaben zu überprüfen.

Um zu entscheiden, welche Abweichung bei den Testergebnissen Fehler sind, ob sie behoben werden müssen und ob neue Testdaten zu erstellen sind, ist eine anschließende Testbewertung erforderlich. Diese Tätigkeit kann nicht durch Tools unterstützt werden.

Bei der Behebung helfen die bereits mehrfach genannten Tools, die den Code statisch analysieren. Grafische Darstellungen der Programmpfade sowie der Daten- und Informationswege sind wertvolle Grundlagen, die den Überblick über das zu korrigierende Programm erleichtern. Es gibt darüber hinaus eine Reihe von Debug-Tools, die bei der Fehlersuche wertvolle Dienste leisten.

Bei allen genannten Tätigkeiten fallen Daten an, die aussagekräftig für den laufenden Test sind. Wäre es möglich, solche Test-Metadaten zu speichern und im semantischen Zusammenhang abzufragen, könnten viele Probleme besser angegangen werden. Es ließen sich etwa folgende Fragen beantworten:

- Wie hat sich die Zahl der notwendigen Änderungen in einem Programm entwickelt?

- Wurden alle Änderungen im Programm durchgeführt, so daß ein neuer Test gestartet werden kann?

- Wurde die geforderte Testabdeckung bei einem bestimmten Programm erreicht?

- Welche Fachfunktionen haben sich als besonders fehleranfällig erwiesen?

- Wie war die Testabdeckung beim letzten Regressionstest in einem bestimmten Programm?

Voraussetzung ist natürlich zunächst der Entwurf eines konzeptionellen Datenmodells für diese Test-Metadaten. Damit wäre es auch möglich, sinnvolle testende Kriterien zu definieren - und deren Einhaltung überprüfen. So etwas ist bisher leider nicht käuflich zu erwerben.

Es gibt keine Test-Tools, die uns bei allen vorher genannten Tätigkeiten unterstützen. Einige Werkzeuge arbeiten sinnvollerweise in einer anderen Umgebung als in dem zu testenden Programm und beobachten quasi von außen, was beim Test geschieht. Andere Tools müssen gemäß ihrer Aufgabe in derselben Umgebung arbeiten wie das Programm. Die Werkzeuge arbeiten also in verschiedenen Betriebssystem-Umgebungen, und das Problem liegt dementsprechend in der Integration der verschiedenen Tools.

Abhilfe ist hier nur in Eigenleistung möglich. Nötig wäre es, die Daten, die durch den Einsatz der verschiedenen Tools entstehen, mit eigenen Programmen zu sammeln und in einer eigenen Test-Metadatenbank zusammenzufassen. Von dort aus könnten sie dann beliebig abgefragt werden. Wohl erst dann ist ein Überblick über Testaktivitäten und deren Erfolge möglich.

* Heinrich Braun ist Unternehmensberater für Software Engineering in Idstein/Taunus