Die Bemühungen des Software-Engineering in den letzten zehn Jahren trugen wesentlich dazu bei, daß Software nicht mehr als Kunstobjekt, sondern als industrielles Produkt verstanden wird. Daß Software-Entwicklung als kontrollierter Prozeß abzulaufen hat, ist nicht zuletzt ein Ergebnis dieses Umdenkens, wobei es sich nur im Idealfall um einen zyklenfreien Prozeß ein lineares Fortschreiten handelt. In der Realität bewirken Änderungen in den Anforderungen, unvollständige Informationen, unzureichende Leistungen von Teilprodukten und die menschliche Fehlbarkeit, daß auch in Zukunft mehrere Zyklen im Entwicklungsprozeß durchlaufen werden.

Daran werden auch Systeme zur Software-Entwicklung nichts ändern. Sie werden vielmehr daran gemessen werden, wie gut sie die Eingliederung solcher Zyklen bewerkstelligen. Voraussetzungen für die Eingliederung sind:

a) das frühzeitige Erkennen notwendiger Änderungen,

b) Identifikation betroffener Teile,

c) die konsistente Durchführung der Veränderungen,

d) eine flexible Projektorganisation zur Einplanung der Änderungen.

Vor allem die Punkte a) und b) sind entscheidend für die Reduzierung der entstehenden Kosten. Wie kann man die notwendigen Änderungen erkennen und die betroffenen Teile identifizieren?

- Durch Design Reviews vor der Implementierung,

- durch Test nach der Implementierung.

Während Design Reviews durch die menschliche Intuition zur Fehlererkennung beitragen, ist der Test ein erstes objektivierbares Kriterium zur Identifikation von Design- und Implementierungsfehlern. Darum kommt dem Test in der Entwicklung eine zentrale Bedeutung zu. Das Ziel eines guten Tests ist primär der Nachweis, daß sich das Produkt gemäß seiner Spezifikation verhält.

Darin unterscheidet sich der Test fundamental vom Debugging, das nur die Aufgabe hat, bei festgestellten Fehlfunktionen die Fehlerursache zu lokalisieren. Im Gegensatz zu Debugging ist daher auch ein Test, bei dem kein Fehler gefunden wurde, durchaus sinnvoll, denn das Testergebnis besteht eben aus dem Nachweis der korrekten Funktion. Gerade bei Zyklen im Entwicklungsprozeß kommt derartigen Regressionstests große Bedeutung zu.

Wichtige Kriterien für die Qualität von Tests sind die Testvorbereitung und die Auswertung der erzeugten Ergebnisse, auf die wir in der Folge näher eingehen wollen.

Testvorbereitung

Sinn und Zweck eines Testfalls ist neben der Aufdeckung möglichst vieler der vorhandenen Fehler der Nachweis der korrekten Umsetzung der Spezifikation in die Implementierung. Erfolgreich getestet hat man also dann, wenn diese Kriterien erfüllt sind. Folgende Regeln sind für einen erfolgreichen Test wichtig:

- Die Eingabedaten müssen wohlüberlegt sein. Mit jedem Testfall versucht man einen bestimmten möglichen Fehlertypus bei der Testdurchführung sichtbar werden zu lassen. Zufallsgeneratoren helfen aus diesem Grund wenig bei der Formulierung von Testfällen. So erzeugte Testfälle verschwenden Rechenzeit, ohne die Ergebnisse aussagekräftiger zu machen.

- Die Funktion eines Moduls ist nur durch das Paar "Eingabe/Ausgabe" zu beschreiben. Daher sind Testfälle wertlos, deren erwartete Ergebnisse nicht vor der Testdurchführung spezifiziert sind, denn sie enthalten keine Aussage über die Korrektheit der Ergebnisse.

Toolschwächen

- Das Vorgehen beim Systemtest muß bei geringem Aufwand das schnelle Erkennen grober Designfehler unterstützen. Bewährt hat sich dabei die "Durchstichstrategie". Die Moduln werden mit Hilfe des Bottom-up-Verfahrens getestet. Die Reihenfolge wird so festgelegt, daß möglichst rasch ein Rumpfsystem mit einem eingeschränkten Funktionsumfang und einer kompletten Steuerung entsteht. Danach werden Zug um Zug die fehlenden Funktionen integriert.

Beim Test kann man von zwei verschiedenen Betrachtungsweisen ausgehen:

a) der Testling wird als Funktionseinheit betrachtet, die auf bestimmte Eingaben mit spezifischen Ausgaben reagiert (Black-Box-Test).

Aufgrund der verschiedenen Betrachtungsweisen wird klar, daß mit einem White-Box-Test niemals die korrekte Umsetzung der Spezifikation in die Implementierung überprüft werden kann, während ein Black-Box-Test keine Auskunft über Fälle geben kann, die einen falschen Ablauf im Modul verursachen. Das heißt für einen kompletten Test müssen wir Testfälle aus beiden Teilbereichen finden.

Bisher gibt es für das Design von Testfällen keine empfehlenswerten automatischen Hilfsmittel. Einige Tools generieren Testdaten, die aus einer Analyse der Implementierung gewonnen werden und eine Abdeckung der verschiedenen Pfade des Programms erreichen. Die Ergebnisdaten müssen allerdings manuell erzeugt und nachvollzogen werden. Eine Testdatengenerierung für Black-Box-Tests setzt eine streng formalisierte Spezifikation mit einem hohen Detaillierungsgrad voraus, die im Normalfall nicht vorliegt.

Tools können daher beim Design der Testfälle nur Hilfestellung in folgenden Bereichen geben:

- Kommentierung der Testfälle,

- automatische Aufbereitung der zu besetzenden Schnittstellendaten in einem Formular, das aus der Schnittstellenspezifikation folgt,

- automatische Prüfung der Eingabe- und Ausgabedaten auf semantische und syntaktische Fehler,

- Definition von Aufruffolgen (Moduln mit Gedächtnis),

- Klassifizierung von Testfällen nach ihrem Zweck,

- Instrumentierung des Programms für Ablaufanalysen,

- Anpassung vorhandener Testfälle bei Schnittstellenänderungen.

Die Durchführung der Tests kann im Normalfall ohne Benutzersteuerung erfolgen, wobei durch eine spezielle Testumgebung kontrollierte Bedingungen für Normalfälle und Aufruffolgen sichergestellt werden müssen, um eine Wiederholbarkeit zu gewährleisten. Die Einbettung des Modulaufrufes sollte über einen modulspezifischen Testtreiber erfolgen, der minimalen Aufwand erfordert und speziellen Problemen angepaßt werden kann (Test von Nebeneffekten).

Die Aufgabe der Auswertung besteht in der Ausfilterung der nicht korrekten Ergebnisse eines Tests und der aussagekräftigen Korrelation von Ergebnis- und Eingabedaten. Das Problem ist auf der einen Seite durch die Vielzahl der anfallenden Daten ein Mengenproblem, auf der anderen Seite ein Problem, die wesentlichen Ergebnisse aufzufinden. Aufgrund psychologischer Gegebenheiten vereinfacht sich die Auswertung wesentlich dadurch daß die Ergebnisdaten bereits beim Entwurf der Testfälle spezifiziert werden. Damit kann man die Suche nach Abweichungen von den erwarteten Ergebnissen automatisieren. Ein Tool für die Testauswertung muß folgendes bieten:

- automatisches Ausweisen der Abweichungen von erwarteten Ergebnissen,

- Möglichkeit des gezielten Zugriffs auf einzelne Ergebnisdaten,

- Vergleichsmöglichkeiten mit erwarteten Ergebnisdaten oder Ergebnissen früherer Testläufe,

- Vergleichsmöglichkeiten mit den Ergebnissen anderer Testfälle (Klassen),

- Möglichkeiten, einen Testlauf interaktiv mehrmals mit verschiedenen Kriterien auszuwerten,

- Übersichtliche Aufbereitung der Ergebnisse,

- Möglichkeiten zur Ablaufanalyse (Testdeckung, Pfadverfolgung),

- Hinweise zur Optimierung (Zeitmessungen, Durchlaufhäufigkeiten),

- Aufbewahrung der Ergebnisse für spätere Verwendung.

Nichts am Markt

Diese Forderungen sollen eine oberflächliche Auswertung der vorhandenen Daten verhindern. Insbesondere die Möglichkeiten zur interaktiven Auswertung nach verschiedenen Kriterien, zusammen mit umfangreichen Vergleichsmöglichkeiten, helfen bei der Lokalisierung der gefundenen Fehler.

Ausgehend von den geschilderten Ideen hat die GFS-Midas die genannten Forderungen an ein Testtool weiter konkretisiert. Nach einer Marktübersicht mit unbefriedigendem Ergebnis wurde das Testsystem "Adora" entworfen, das

- die Eingabe und Verwaltung der Testfälle vereinfacht,

- den Aufwand für die Erstellung eines modulspezifischen Testtreibers verringert,

- die Durchführung von Regressionstests ermöglicht,

- die Testauswertung erleichtert und

- durch Dokumentation den Test überprüfbar macht.

Literaturhinweise:

[1] John R. Garman, The "Bug" heard around the world, ACM Software Engineering Notes, Vol: 6, no5, Oct 81

[2] Glenford J. Myers, The Art of Software Testing, Wiley, 1979

*Dipl.-Inf. Reinhard Haller und Dipl.-Math. Ute Pelkmann sind Mitarbeiter der GFS-Midas Gesellschaft für Führungssysteme mbH, Thalkirchner

Str. 2, 8000 München 2, Telefon: 0 89/2 60 90 87.