Die Entwicklung und Wartung von Software-Produkten vollzieht sich in der Regel in mehreren Schritten. Der wirtschaftliche Erfolg wird von einem ingenieurmäßigen Vorgehen bei der Erstellung der einzelnen Teilprodukte entscheidend beeinflußt. Eine lückenhaft entworfene Leistungsbeschreibung, ein fehlerhaft implementiertes Quellprogramm verringern die Wirtschaftlichkeit beim Einsatz ebenso wie eine Verzögerung des Fertigstellungstermins oder eine erhebliche Kostenüberschreitung. Die auszuübenden technischen Funktionen sind: Entwerfen, Implementieren, Testen, Dokumentieren, Verwalten, Konvertieren und Messen,

Die beiden Funktionen Testen und Messen bilden insofern eine eigene Klasse, als sie ausschließlich zur Überprüfung, Kontrolle und Bewertung einzelner Qualitätsmerkmale dienen. Durch das Testen wird das Qualitätsmerkmal Zuverlässigkeit, durch das Messen die Effizienz eines Software-Produkts oder der Teilprodukte überprüft.

Mit dem Begriff Zuverlässigkeit sollen die im allgemeinen Sprachgebrauch verbundenen Assoziationen auf Software-Produkte übertragen werden: Software hat in dem Maße Zuverlässigkeit, wie erwartet werden kann, daß sie die geplanten und vereinbarten Funktionen erfüllt.

Mit dem Qualitätsmerkmal "Effizienz" wird das Ausmaß der Inanspruchnahme der jeweiligen Hardware durch das Software-Produkt bei gegebenem Funktionsumfang ausgedruckt. Effizienz bezieht sich vor allem auf die Ablaufgeschwindigkeit und den Speicherplatzbedarf.

Eng verknüpft mit der Effizienz sind die Leistungsfähigkeit und das Einsatzverhalten eines DV-Systems. Sie werden in der Regel auf die Hardware-Konfiguration, das Betriebssystem und die Organisation im Rechenzentrum bezogen.

Projektbegleitendes Testen

Ziel des Testens ist es, die Zuverlässigkeit der Software-Produkte zu verbessern. Es liegt auf der Hand, daß höhere Zuverlässigkeit zunächst dadurch erreicht werden kann, daß man sich bei der Software-Erstellung leistungsfähiger Entwurfs- und Implementierungstechniken im Verein mit einer geeigneten Organisation und einem straffen Management bedient. Die Erfahrung zeigt jedoch, daß trotzdem Fehler in nicht unbeträchtlichem Ausmaß auftreten. Dies gilt um so mehr, je größer und komplexen das jeweilige Software-Produkt und je länger die erforderliche Entwicklungszeit ist. Aus diesem Grund war und ist es auch weiterhin notwendig, Software zu "testen", das heißt, durch eine Soll-Ist-Analyse Fehler festzustellen.

Die Auffassung des Testens als Soll-Ist-Analyse bedeutet ganz allgemein, daß überprüft wird

- ob geforderte Funktionen und Eigenschaften (das Soll) mit den realisierten Funktionen und Eigenschaften (dem ist) übereinstimmen

- und daß festgestellte Abweichungen zwischen den Soll- und Ist-Ergebnissen (Fehler) lokalisiert und, ihre Ursachen ermittelt werden.

In intensiven Untersuchungen wurde festgestellt, daß Fehler etwa zur Hälfte auf falsches Entwerfen und falsches Implementieren zurückzuführen sind. Während jedoch ein großer Teil der Implementierungsfehler bereits beim Test von Moduln und Komponenten entdeckt wird, werden die Entwurfsfehler meist erst beim System- oder Abnahmetest oder danach im praktischen Einsatz festgestellt. Schließlich handelt es sich bei den Entwurfsfehlern in der Regel um solche, die im Vergleich zu den Codierfehlern schwieriger zu lokalisieren und nur durch größeren Aufwand zu beheben sind.

Aus diesen Gegebenheiten ist unbedingt die Konsequenz zu ziehen: Testen im Sinne einer Soll-Ist-Analyse muß so früh wie irgend möglich einsetzen und während des gesamten Entwicklungsvorhabens auf alle entstehenden Teilprodukte angewendet werden. Testen ist als eine projektbegleitende Tätigkeit aufzufassen und sollte nicht erst nach Implementierung des Software-Produktes einsetzen. Das bedeutet, daß nicht nur Programme, sondern auch Dokumente, zum Beispiel eine Rahmen- oder Detailspezifikation, getestet werden müssen.

Diese Auffassung des Testens erfordert besonders bei größeren Software-Produkten ein äußerst systematisches Vorgehen.

Einzeltests an Programmteilen

Schrittweises Testen bedeutet, daß der Code eines Programmsystems primär nicht als Ganzes, sondern zunächst in kleinen überschaubaren Teilen getestet wird, die schrittweise zu immer größeren Einheiten integriert werden. Automatisiertes Testen heißt, daß der Rechner nicht nur zum Ablauf des zu testenden Codes, sondern auch zur Testplanung, Testauswertung und Testdokumentation soweit als möglich verwendet wird.

Der besondere Vorteil des schrittweisen Testens liegt darin, daß die Fehlersuche spürbar erleichtert wird: Wenn beim Test ein Fehler auftritt, so wird der Fehler mit größerer Wahrscheinlichkeit in den bisher nicht getesteten Befehlsfolgen oder in den Schnittstellen zwischen den jeweils einzeln schon getesteten Programmteilen liegen.

Ferner ermöglicht das schrittweise Testen neben den bekannten Werkzeugen, wie Speicherabzüge, den Einsatz interaktiver Werkzeuge besonders auch für die Fehlerlokalisierung (zum Beispiel IDA im BS2000).

Sehr verbreitet und in der Praxis mit Erfolg angewandt ist folgende, einfache Form des schrittweisen Testens: Einzeln übersetzbare Programmteile werden im Rahmen des sogenannten "Modultests" jedes für sich getestet. Aus jeweils mehreren getesteten Programmteilen werden Komponenten gebildet, die im Rahmen des "Komponententest" geprüft werden. Dieser Integrationsvorgang kann sich insofern wiederholen, als mehrere getestete Komponenten zu einer neuen, größeren Komponente gebunden werden, die wiederum getestet wird. Schließlich wird das vollständige, integrierte Programmsystem, dessen Teile alle einzeln und in Zwischenstufen bereits einmal oder mehrmals getestet worden sind, im Rahmen des "Systemtests" erneut und abschließend getestet.

Beim schrittweisen Testen ist es notwendig, für die Fehlererkennung ein sogenanntes Testrahmenprogramm zu verwenden. Ein Testrahmen dient dazu, die beim Ablauf des integrierten Programms für einen bestimmten Programmteil (zum Beispiel einen Modul) vorhandene "Umgebung" (aufrufender Modul, Tabelleneinträge, Dateien und so weiter) während des Tests für den zu testenden Programmteil bereitzustellen oder zu simulieren.

Wegen der Notwendigkeit, selektiv testen zu müssen, ist es wichtig, die Güte der mit einem Programm oder Programmteil durchgeführten Tests zu beurteilen, das heißt, festzustellen, ob, gemessen an der zu erzielenden Qualität, ausreichend gut getestet worden ist. Ein erstes, einfaches, in der Regel aber nicht ausreichendes Kriterium hierfür ist, ob zum Beispiel alle Befehle eines, Programms beim Test mindestens einmal durchlaufen worden sind. Durch Programme, die sogenannten "Programmanalysatoren" können die entsprechenden Quellprogramme mit Hilfe des Rechners so geändert (instrumentiert) werden, daß diese einfache Kontrolle der Tests rechnergestützt ausgeführt werden kann und nach Beendigung des Tests Ergebnisse auf Quellcode-Ebene sofort zur Verfügung stehen.

Von besonderer Bedeutung ist die Automatisierung des Tests für den Systemtest. Vor allem bei größeren Programmsystemen ist die zu erzeugende Menge an Testdaten so groß, daß hierfür Programme (zum Beispiel Testdatengeneratoren) verwendet werden müssen. Hinzu kommt, daß die große Menge an Testdaten beim Test eine in der Regel vergleichbar große Menge an Testergebnisdaten erzeugt, die meist wiederum nur rechnergestützt ausgewertet werden kann (zum Beispiel durch Einsatz von Programmen zum Vergleich von Dateien).

Ganz allgemein erfordert die große Datenmenge eine rechnergestützte Verwaltung der Testfälle, der zugehörigen Testdaten und Testergebnisse. In diesem Zusammenhang spricht man von Testbibliotheken. Diese sind besonders auch für die Wartung von großer Wichtigkeit. Im Anschluß an eine Fehlerkorrektur müssen Tests durchgeführt werden, um die Richtigkeit der Korrektur nachzuweisen. Da durch eine Korrektur häufig neue Fehler in anderen Programmteilen auftreten (die "Fernwirkung" der Korrektur ist nicht genau genug bekannt), muß eine Reihe zusätzlicher Tests auch für nicht geänderte Funktionen und Programmteile durchgeführt werden (Regressionstest). Zur Vermeidung von Mehrfacharbeit ist es deshalb besonders günstig, aus einer Testbibliothek die entsprechenden Tests leicht abrufen und anschließend durchführen zu können.

Während des Einsatzes eines Software-Produkts kommt es häufig vor, daß seine Laufzeit oder sein Arbeitsspeicherbedarf so hoch sind, daß eine Verbesserung dieser Leistungsparameter, das heißt, eine Erhöhung seiner Effizienz, dringend erforderlich ist; sei es, um mit einer Arbeitsschicht weniger im Rechenzentrum auszukommen, sei es, weil zusätzlich neue Programme auf der DV-Anlage laufen müssen. Es ist deshalb notwendig, zu messen, das heißt, die Werte einzelner Leistungsparameter festzustellen und zu analysieren. Anschließend sind Verbesserungen am Programm oder am gesamten DV-System zunächst probeweise vorzunehmen (Optimieren beziehungsweise "Tuning") und dann sind erneut die Leistungsparameter zu überprüfen, um den Erfolg oder Mißerfolg der Optimierungsmaßnahmen feststellen zu

können.

In manchen Fällen, besonders bei komplexeren Systemen, wie Betriebssystemen oder Realzeitprogrammen, genügt es nicht, solche Messungen erst in der Einsatzphase durchzuführen. Vielmehr ist es notwendig, bereits an dem jeweils vorliegenden Konzept die Effizienz des zu erstellenden Programms zu untersuchen, genauer gesagt, vorherzusagen. Herbei wird mit abstrakten Modellen des späteren Systems gearbeitet, deren Verhalten entweder mathematisch aufgrund von Wahrscheinlichkeitsannahmen berechnet oder mit Hilfe von Simulationsverfahren ermittelt wird.

Betrachtet man die Gründe für ungenügendes Leistungsverhalten eines DV-Systems, so stellt man fest, daß das einzelne Anwendungsprogramm, das Zusammenwirken mehrerer Programme, das Betriebssystem und seine spezielle Generierung, die Hardware-Ausstattung des Rechenzentrums, die Ablauforganisation im Rechenzentrum sowie auch die Art des Einsatzes der Programme in den Fachabteilungen (zum Beispiel der "Buchhaltung") für die Ineffizienz verantwortlich sein können.

Von besonderer Wichtigkeit für Messungen zur Optimierung der Anwenderprogramme oder auch der Betriebssysteme sind sogenannte Monitore, von denen es zwei Grundformen, den "Software-"

und den "Hardware-Monitor", gibt. Die Software-Monitore werden für Messungen an Anwenderprogrammen und an hardware-fernen Teilen des Betriebssystems verwendet, während die Hardware-Monitore vor allem für hardwarenähere Messungen eingesetzt werden können.

Entscheidend für die Funktionsweise der Hardware-Monitore ist, daß sie zum Beispiel an der Rahmenverdrahtung einer Zentraleinheit oder Gerätesteuerung direkt "physikalisch" angeschlossen werden können, um einzelne Impulse registrieren und anschließend in einem eigenen. Spezialrechner verarbeiten zu können.

Die Software-Monitore gibt es in zwei Formen: Software-Monitore (dann auch Programmanalysatoren genannt), die den Code eines Programms (meist den Quellcode) durch Einfügen zusätzlichen "Meßcodes" an ausgewählten Stellen verändern und so eine Messung ermöglichen, und Software-Monitore, die, verglichen mit den zu messenden Programmen, privilegiert sind, so daß sie für die Messung wichtige Informationen aus dem jeweiligen Programm oder zugeordneten Datenbereichen lesen können.

*Pfandler ist bei der Siemens AG, München, beschäftigt. Dieser Beitrag ist ein Auszug aus einer Abhandlung die im Siemens Data Report "Software Engineering" (14. Jahrgang 1979 Sonderheft) veröffentlicht wurde.