Software-Optimierung/"A fool with a tool is still a fool"

Worauf es bei Testwerkzeugen eigentlich ankommt

23.01.1997

Das Testen einer Anwendung läßt sich üblicherweise in verschiedene Teststufen unterteilen. Jede soll helfen, ein bestimmtes Qualitätsziel zu erreichen. Das führt zu je unterschiedlichen Fragen auf Basis je speziellen Fachwissens:

Der Entwicklertest soll die vollständige Umsetzung der DV-technischen und fachlichen Vorgaben sowie die grobe fachliche Richtigkeit aller Programmteile prüfen (Modultest, Integrationstest). Der Funktionstest fragt, ob alle fachlichen Vorgaben erfüllt sind und jede fachliche Funktion fehlerfrei ist. Der Verbundtest hat das Qualitätsziel, die Korrektheit der Anwendung im Verbund mit anderen Anwendungen zu belegen. Und im Systemtest werden Leistungsfähigkeit, Ergonomie, Stabilität etc. überprüft.

Immer wieder werden Tools ohne klare vorherige Analyse angeschafft, wie und wozu sie Verwendung finden sollen. Aber: "A fool with a tool is still a fool." Der naive Kauf ohne Planung führt fast immer dazu, daß Anwender dem intuitiven Vorgehen der Tools folgen, ohne die notwendigen Prozesse zu durchdenken und zu planen. Die Folge ist, daß das Tool den Testablauf bestimmt und nicht umgekehrt. Durch die fehlende Anbindung der Tools an das Gesamtvorgehen landen die meisten im binären Nirwana und spielen im Test keine Rolle mehr. Was sind nun die typischen Prozesse im Entwicklertest? Um die vollständige Umsetzung aller DV-technischen und fachlichen Vorgaben zu kontrollieren, müssen alle Module (Prozeduren oder Objekte) einzeln und in der Integration Tests durchlaufen. Jedes Modul besteht von außen betrachtet aus Ein- und Ausgabe-Schnittstellen und von innen betrachtet aus Anweisungen unterschiedlichen Typs.

Dies führt zu zwei grundsätzlichen Testansätzen: Im Black-box-Test werden Fälle anhand der fachlichen und DV-technischen Vorgaben konstruiert, die dem Entwickler beziehungsweise Tester zeigen, ob alle externen Anforderungen an das Modul erfüllt sind. Dieses wird nur anhand seines Ein- und Ausgabeverhaltens getestet. Im White-box-Test werden dagegen Szenarien anhand des Innenlebens des Moduls durchgespielt, die die spezielle Sicht des Entwicklers widerspiegeln.

Der Black-box-Test spielt unter Entwickleraspekten eine untergeordnete Rolle. Der Schwerpunkt liegt mehr auf dem White-box-Test mit Blick auf externe Anforderungen - man spricht deshalb auch vom Grey-box-Test. Der Entwickler beziehungsweise Tester verwendet Informationen über Aufbau, Schwachpunkte und Entscheidungswege des Moduls zur Konstruktion entsprechender Testfälle.

Nach der Testfallermittlung erfolgt die Testdatendefinition und anschließend die Testausführung. Diesen Prozeß sollten nun entsprechende Tools unterstützen (siehe Kasten).

Die bisher angesprochenen Testaufgaben betreffen den sogenannten dynamischen Test. Dies ist ein Verfahren, bei dem das Modul mit seinen Testdaten in Gang gesetzt wird. Daneben gibt es den statischen Test. Er umfaßt die Überprüfung des Sourcecodes bezüglich bestimmter Punkte wie Namenskonventionen (für Konstanten, Variablen etc.), Programmiersprachenbedingte Stolpersteine (wie "=" anstelle von "==" in C) und Hitlisten "beliebter" Programmierfehler (etwa im Speicher-Management).

Für diese Testaufgaben hat sich die sogenannte Sourcecode-Inspektion als Verfahren etabliert. Dabei unterstützen eine ganze Reihe von Tools diverse Programmierregeln, zum Beispiel Namenskonventionen wie "kein CASE ohne Default" etc.

Neben den Modulen muß ein zeitgemäßer Entwicklertest die Graphical-User-Interface-(GUI-) und Client-Server-Funktionen berücksichtigen. Capture/Replay-Tools lassen sich vielfach durch den konsequenten Ausbau der "Kontextsensivität" oder auch "Objektorientierung" als GUI-Formaltester einsetzen. Auch hier sollte zuerst die Frage stehen: "Was will ich erreichen?" Der Aufbau einer Benutzer-Schnittstelle kann infolge der Mächtigkeit der meisten GUI-Entwicklungsumgebungen noch während des Tests starken Veränderungen unterworfen sein. Für den Formaltest wird nun angestrebt, möglichst automatisch alle Veränderungen der Objektspezifikationen der GUI zu entdecken und zu dokumentieren.

Das Testen von Client-Server-Anwendungen gestaltet sich wegen ihrer Komplexität ungleich schwieriger. Grund ist die intensive Nutzung von Fremdsoftware, die häufig instabil oder fachlich fehlerhaft ist. Bis heute ist keine etablierte Testmethode im Bereich des Entwickler- und Funktionstests zu erkennen.

Nur im Bereich des Systemtests sind Performance-Meßverfahren verfügbar. Dies sind Black-box-Messungen nach DIN 66273, Teil 1, oder sie basieren auf TPC, einer US-amerikanischen Industrienorm. Die Überprüfung von Client-Server-Komponenten im Entwicklertest erfolgt derzeit häufig durch extensives Protokollieren mit anschließender intensiver Analyse. Von einer systematischen Vorgehensweise einschließlich Tool-Verwendung in Client-Server-Tests kann aber derzeit keine Rede sein.

Daß Test-Tools derzeit so populär sind, hat mehrere Gründe. Der wichtigste ist, daß die Bedeutung von qualitätssichernden Maßnahmen in den letzten zwei Jahren langsam, aber sicher gestiegen ist. Dieser Wandel ist auf Auftraggeber- und Auftragnehmerseite deutlich zu erkennen. Dies belegt auch die hohe Besucherzahl der letzten europäischen Konferenz zum Softwaretesten, "Euro-Star". Von 350 Teilnehmern im Jahr 1995 stieg deren Anzahl - trotz Rezession - im letzten Jahr auf weit über 500. Über das allgemein gestiegene Interesse hinaus wächst auch die Zahl konkreter Projekte.

Ebenso verlangen Auftraggeber immer häufiger Nachweise über eine strukturierte Entwicklung und einen strukturierten Entwicklertest. Nicht zuletzt deshalb etablieren sich qualitätssichernde Normen wie ISO-9000-Derivate und "Bootstrap" in den Softwarehäusern und Entwicklungsabteilungen. Diese Nachweise lassen sich um so leichter erbringen, je mehr Tools Verwendung finden. Dies hängt damit zusammen, daß die meisten Werkzeuge eine Art Aktivitäten- oder Ergebnisverwaltung besitzen, die zur Dokumentation und damit zum Nachweis geeignet sind.

Eine weitere Ursache ist ein allgemeiner Innovationsdruck zur Kostenreduzierung. Selbstverständlich verringert eine sinnvoll und systematisch verwendete Tool-Sammlung die Testkosten - und damit auch die Entwicklungsausgaben insgesamt. Messungen in Projekten zeigen, daß teilweise 40 bis 60 Prozent des Gesamtentwicklungsaufwands in die Tests gehen. Softwarehäuser und Entwicklungsabteilungen können hier viel sparen.

Die Test-Tools selbst haben sich bezüglich Stabilität, Ergonomie und Funktionalität erheblich verbessert. Stabilität und Funktionsumfang sind in MVS-Host- und Unix-Server-Umgebungen seit Jahren gegeben. Die schlagartige Umstellung auf grafische Benutzeroberflächen und Client-Server-Architekturen - nicht selten in Verbindung mit einem Wechsel zu objektorientierten Entwicklungsparadigmen - hat auch eine neue Generation von Test-Tools nötig gemacht. Diese waren, besonders im Bereich Capture/Re- play-Tools, oft erschreckend instabil. Erst seit etwa einem Jahr ist bei fast allen Tools eine deutliche Verbesserung zu spüren. Ausnahmen bestätigen die Regel.

Die Einführung neuer Technologien hat dazu geführt, daß die zu erstellenden Anwendungen und die dazu verwendeten Entwicklungsumgebungen merklich komplexer wurden. Auch diese Entwicklung führt zu einer verstärkten Nutzung von Test-Tools. Allein der Wechsel von monolithischen zu verteilten Anwendungen - sei es durch Client-Server-Computing oder Objektorientierung - macht viel mehr Tests notwendig. Es gilt ungleich mehr Schnittstellen und Schichtenwechsel mit den damit verbundenen Nebeneffekten zu beachten.

Nach dem Test der einzelnen Module müssen im sogenannten technischen Integrationstest Testtechniken und -verfahren definiert werden, die möglichst früh Fehler aufdecken. Es braucht Monitoring-Konzepte, um Kommunikationspfade mit den dazugehörigen Daten verfolgen und analysieren zu können. Ohne Tool-Unterstützung wäre schon die Verfolgung eines einfachen SQL-Auftrags an den Server nicht zu analysieren.

Abschließend sei noch das "Problem 2000" genannt, weil die vielfach notwendige Umstellung der Software besondere Herausforderungen an den Test stellt. Große Anwender haben gegebenenfalls 10000 bis 20000 Programme anzupassen. Diese müssen bearbeitet, geprüft und wieder in produktiven Ablauf gebracht werden. In den Jahren 1998/99 werden dann im Schnitt zehn bis 15 Programme am Tag freizugeben sein. Danach obliegt es dem Tester, nachzuweisen, ob die modifizierten Programme praxistauglich sind.

Einen solchen Nachweis kann entweder nur ein vollständiger Regressionstest oder eine Stichprobe erbringen. Um den gewaltigen Testdurchsatz bewältigen zu können, bedarf es einer unterstützenden "Testmaschine". So ist es notwendig, schon heute Tools einzuführen und als Teile in die Testmaschine zu integrieren, damit ab dem Startschuß ein Test wie am Fließband möglich ist. Während des Tests wird es kaum verantwortlich oder möglich sein, Vorgehen oder Tools zu verändern.

Angeklickt

Bis zu zwei Drittel der Kosten eines Softwareprojekts fallen in Testverfahren an. Es ist daher nicht überraschend, daß sich Softwarehäuser und Entwicklungsabteilungen bei den Anwendern unter dem steigenden Druck zu kostengünstigeren Produkten immer häufiger entsprechender Tools bedienen. Deren Auswahl erfolgt allerdings oft nach wenig schlüssigen Grundsätzen. Dieser Überblick über die Abschnitte und Prozesse der Software-Analyse soll fundiertere Entscheidungen erleichtern.

Test-Tools

Softwaretests bestehen aus verschiedenen Teilbereichen, für die es entsprechende Tools gibt.

Die wichtigsten Aufgaben von Tools, die das Test-Management unterstützen sollen:

- Verwalten von Testaufträgen und Testaktivitäten: Der Testplan gibt vor, wer wann welche Testaufgaben übernehmen soll. Die entsprechende Auftragsvergabe und der Status der Aktivität müssen verwaltet werden und auswertbar sein.- Verwalten von Tests: Jeder einzelne Test (Testlauf, Testdurchgang oder ähnliches) muß mit seinem Status verwaltet werden und auswertbar sein. Der Teststand sollte sich von einer Stelle der internen DV aus abfragen lassen.

Die wichtigsten Aufgaben von Tools, die die Testfallermittlung unterstützen sollen:

- Identifizierung von fehlerträchtigen Modulen und Modulteilen: Es existieren mehrere Verfahren, um die Komplexität und somit die Fehlerträchtigkeit eines Moduls zu messen. Am bekanntesten sind Maße wie zyklomatische Komplexität nach McCabe und für objektorientierte Systeme die Maßzahlen nach Chidamber/Kemerer ("Towards a metrics suite for object-oriented design") sowie Li/Kafura/Schulman ("Measuring object- oriented design").- Nicht ausgeführte Codezeilen identifizieren: Während der Testausführung soll gemessen werden, ob jeder Teil des Source- codes zur Ausführung gekommen ist. Dazu werden Testabdeckungsmaße (c0, c1...) eingeführt. Teile des Sourcecodes, welche nicht zur Ausführung gekommen sind, müssen dann mittels Debugger oder durch Erweiterung der Testfälle beziehungsweise Testdaten berücksichtigt werden.- Hilfen, um bestimmte Bereiche im Code zu erreichen: Mit symbolischen Debuggern können Module in schwer erreichbare Zustände versetzt werden. So lassen sich beispielsweise Werte von statischen Variablen in C so setzen, daß bestimmte Teile des Moduls zur Ausführung kommen.

Die wichtisten Aufgaben von Tools, die die Testdatenerstellung unterstützen sollen:

- Ermittlung der Ein- und Ausgabe-Schnittstellen der Module: Analyse des Sourcecodes beispielsweise bezüglich Aufrufparametern einer Funktion. Bei der Umsetzung der Testfälle in Testdaten (oder auch Testdatenkombinationen) werden dann die Parameter zur Dateneingabe angezeigt.- Verwaltung der Primärdaten (Eingabedaten): Durch Namenskonventionen oder mitgelieferte Verwaltungsfunktionalitäten sollte eine gute Wartbarkeit der Testdaten unterstützt werden.- Erstellen und Bearbeiten von Sekundärdaten (Datenbanken, Dateien oder ähnliches): Sekundärdaten müssen erstellt und gewartet werden.- Verwaltung von Sekundärdaten: Die Testdaten, die in Datenbanken, Parameterdateien etc. vorliegen müssen, sind zu verwalten.

Die wichtigsten Aufgaben von Tools, die die Testausführung unterstützen sollen (Unit-Tester):

- Isoliertes Modultesten: Um einzelne Module der Anwendung zu testen, müssen Treiber und Platzhalter generiert werden, die ein Modul einschalen und lauffähig beziehungsweise testfähig machen.- Speicher-Management: Speicherlöcher, illegale Speicheroperationen etc. müssen aufgespürt werden.- Testauswertung: Das Ausgabeverhalten (Dateien, Benutzeroberfläche etc.) und ge- gebenenfalls Variablenwerte müssen in ein auswertbares respektive vergleichbares Format abgelegt und verwaltet werden.

*Ralf Schroers ist Diplominformatiker im Kompetenzcenter Testprojekte und Heinz Bons Geschäftsführer der SQS Gesellschaft für Software-Qualitätssicherung mbH in Köln.