Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

13.11.1987 - 

Engpässe müssen nicht zur Tagesordnung gehören:

Moderne SW-Technik optimiert Testverfahren

13.11.1987

Test-Engpässe sind im Bereich der Software-Qualitätssicherung nach wie vor ein großes Problem. Moderne Methoden der SW-Technik könnten hier indes Abhilfe schaffen. Wolfgang Ohrt* beschreibt ein Testunterstützungssystem, das auf einer Sprache der vierten Generation, einer relationalen Datenbank und einem Data Dictionary aufbaut.

Die Revolution der SW-Entwicklung durch die Programmiersprachen der vierten Generation holt Atem. Trotz unbestreitbarer Erfolge ist die anfängliche Euphorie der Softwarehäuser und der ersten Anwender stark abgekühlt. Zu gewichtig sind die Restriktionen der neuen Sprachen und ihr Leistungsverhalten im RZ-Betrieb. Programmierung bleibt auf absehbare Zeit noch Handarbeit.

Aber es gibt Inseln, auf denen die Vorteile der neuen Sprachen sich ohne lästige Nebenwirkungen entfalten können. In einem zentralen, aber in der bisherigen Diskussion vernachlässigten Bereich der Software-Entwicklung konnten durch den Einsatz einer modernen Programmiersprache beachtliche Fortschritte erzielt werden.

Die Rede ist vom Software-Test im Rahmen der SW-Qualitätssicherung. Durch den Einsatz einer Programmiersprache der vierten Generation (Abfragesprache) im Zusammenwirken mit relationaler Datenbank und Data-Dictionary ist es möglich, die Qualität der entwickelten Software zu steigern. Dabei laßt sich die Dauer der Testphase gegenüber konventionellen Testverfahren reduzieren und dennoch kann die Anzahl der durchgeführten Tests auf ein Vielfaches erhöht werden.

Konzeptioneller Überbau ist zu berücksichtigen

Sinnvoll wird die Entwicklung und Verwendung von Software-Komponenten als Testhilfe erst im Rahmen eines Testverfahrens, das den konzeptionellen Überbau für die gesamte Testphase umfaßt. Das Testverfahren beschreibt die Kriterien für die Testfallüberdeckung, die Testdurchführung, die Anforderungen an die Ergebnisse, um zu einer qualitativen und quantitativen Beschreibung der Testresultate zu gelangen. Das Testverfahren im hier verwendeten Sinne umfaßt drei Komponenten.

- Das Testkonzept

beschreibt die Testlogik. Es legt fest, was zu testen ist, welche Kriterien zum Bestehen eines Tests nachzuweisen sind und welche Teststufen zu durchlaufen sind. An Einzelheiten seien hier lediglich die maßgeblichen Teststufen dargestellt (siehe Kasten).

- Die Testfälle

stellen die Beschreibung der fachlichen Aufgaben (Geschäftsvorfälle) dar, die mit Hilfe des zu entwickelnden SW-Produkts zu lösen sind. Jeder Testfall beschreibt eine genau definierte fachliche Aufgabe, ihre Voraussetzungen, ihre Abwicklung und die geforderten Ergebnisse. Im Idealfall deckt die Menge der Testfälle die möglichen Aufgaben ab.

- Die Testdaten

sind die Umsetzung der Testfälle in verarbeitungsfähige Datensätze. Jedes SW-Produkt (Testling) hat seine eigenen Datensätze zur Eingabe. Diese können entweder in der Form von Bewegungsdaten oder als Datenbanksätze einfließen. Die Summe aller Datensätze zu einem Testfall und einem Testling stellt deren Testumgebung dar.

Ein Testverfahren ist auf einen langfristigen Einsatz in einem Unternehmen angelegt und begleitet daher ein DV-System über seinen gesamten Lebenszyklus: von der Analyse über die Realisierung zur Produktion bis hin zum Ersatz durch ein Nachfolgesystem. Das Testverfahren mit seinen Komponenten muß die spezifischen Anforderungen jeder Phase des Lebenszyklus berücksichtigen Eine zu enge Konzeption macht Testfälle für spätere Wiederholungen unbrauchbar.

Die Archivierung für Testwiederholungen während der Wartung scheitert häufig an der Rekonstruierbarkeit der Testdaten. Die Ordnung der Testfalle, die Zuordnung zu Teststufen und Testlingen wird wegen fehlender Unterstützung durch das Testkonzpet und die Testsoftware oft nicht durchgehalten. Die Folgen sind Mehrfachaufwand zur Wiederherstellung bereits einmal erstellter Testdaten und/oder Testlücken.

Primäre Aufgabe des Testverfahrens ist es, Fehler der entwickelten Software so früh wie möglich zu erkennen, unabhängig davon, ob der Fehler der Konzeption, der Analyse oder der Realisierung entspringt. Die Einbeziehung der Fachabteilung, des späteren Anwenders, ist daher so früh wie möglich geboten. Bereits die ersten testfähigen Programme oder Programmteile sind im Zusammenwirken mit der Fachabteilung zu überprüfen. Der hohe Aufwand, Testresultate für die Fachabteilung verständlich und nachvollziehbar aufzubereiten, verhindert leicht deren frühzeitigen Einsatz.

Das Testsystem bietet dem Programmierer häufig keine Systematik zur Durchführung der Tests. Die Folgen: Testlinge, insbesondere in den ersten beiden Teststufen, werden oft nach Gutdünken als ausgetestet weiterverwendet. Fachliche Tests brechen dann wegen Belanglosigkeiten wie arithmetischer Fehler oder fehlerhafter Eingabedaten ab.

Die Anzahl der möglichen Testfälle ist groß und die Verkettung mit den Testdaten verwickelt. Die Verwaltung der Testdaten wird dadurch kompliziert. Termindruck tut ein übriges und alsbald ist die Menge der Testdaten nicht mehr überschaubar.

Modifikationen der Testdaten bei Änderung der Testumgebung eines Testlings sind meist sehr aufwendig und unterbleiben daher. Bereits durchgeführte Tests stehen dann für Wiederholungen und späteren Nachweis nicht mehr zur Verfügung. Die Erfassung der Testdaten ist meist unkomfortabel. Die Fachabteilungen können daher nicht hinzugezogen werden. Die Testüberdeckung der Testlinge ist tendenziell gefährdet.

Die Analyse von Testergebnissen in Zwischendateien ist oft zeitraubend und fehlerbehaftet, wenn Positionen ausgezählt und gepackte oder binäre Formate geprüft werden müssen. Oft erfordert die Wiederherstellung der Zustände auf einer oder mehreren Datenbanken zur Testwiederholung die Programmierung eigens erstellter Routinen; damit ist sie sehr zeitaufwendig.

Im Ergebnis führen diese Probleme häufig zu einer Engpaß-Situation: Der hohe Aufwand für die Durchführung weiterer Tests ist aufgrund des immer näher rückenden Einführungstermins nicht mehr zu erbringen, die Durchführung eigentlich erforderlicher Tests unterbleibt. Der Test und die Fehlerbehebung werden damit in die Produktion verlagert. Formal aber ist das Projekt abgeschlossen und das Budget eingehalten. Die hohen Kosten zur Fehlerbehebung in produktiven Programmen werden weitergereicht.

Ein möglicher Lösungsansatz besteht in einem Testunterstützungssystem (TUS), durch dessen Einsatz es gelingt, diese Schwierigkeiten in den Griff zu bekommen. Insbesondere geht es darum, Tests, die eine komplexe Testumgebung erfordern, durch die Fachabteilung zu starten und zu analysieren. Die Anzahl der Tests, die Relevanz der Testfälle sowie die Qualität der Testergebnisse können dadurch erheblich gesteigert werden.

Kernstück des Testverfahrens ist das Ordnungssystem. Daher muß an dieser Stelle kurz auf die Nomenklatur eingegangen werden.

Jeder Fall bekommt einen eigenen Ordnungsbegriff

Um die Menge der Testfälle, die sehr schnell nahezu astronomische Größenordnungen erreichen kann, überschaubar zu halten, wird jeder Fall mit einem eindeutigen Ordnungsbegriff belegt. Er umfaßt fünf Bestandteile, die sich aus dem Testverfahren ableiten:

- Teststufe

(Bereich von 1 bis 4)

- Testling

(achtstelliger Name, Modul, Programm, . . .)

- Fallnummer

(dreistellige Nummer)

- Satzart

(Name der Satzstruktur)

- Versionsnummer

(dreistellige Nummer)

Ein solcher Ordnungsbegriff sichert die Verknüpfung zwischen dem fachlichen Testfall und den zugehörigen Testdaten.

Das Testunterstützungssystem ist die Anwendungskomponente des Testverfahrens. Es umfaßt die Datenbasis, Programme, Masken, und Routinen zur Handhabung der Tests und besteht aus Testdatenspeicher (TS) Testfall-Erfassungssystem (TP), Testumgebungsgenerator (TG), Testdriver (TD) sowie Testumgebungs-Sicherungsroutine (TR).

Relationale Datenbank dient als Grundlage

Der Testdatenspeicher ist die Basis des TUS. Es handelt sich um eine relationale Datenbank, in der die Testdaten im Satzformat der jeweiligen Testumgebung gespeichert werden. Jeder Datenbanksatz enthält als Schlüssel den obigen Ordnungsbegriff und im Datenbereich den kompletten, formatgerechten Testdatensatz. Für jede Satzart ist der Datenbereich mit einer User-View überlagert, so daß sich jedes Datenelement in den Erfassungs- und Dienstprogrammen mit seinem Feldnamen ansprechen läßt.

Die verbalen Testfallbeschreibungen werden ebenfalls im TS gespeichert - unter einer eigenen Satzart: TFALL. Damit ist die Darstellung der Verknüpfung zwischen Testfallbeschreibung und Testdaten sowie die Auflistung aller Testfallbeschreibungen oder anderer Auswertungen jederzeit möglich. Das Speichermedium ist unempfindlich gegen Testfehler, da es niemals selbst als Datei in die Tests eingebunden ist, sondern nur als Datenbasis zur Erzeugung der Testumgebungen verwendet wird.

Für das Testfall-Erfassungssystem findet der installierte Maskengenerator Verwendung. Je Satzart wurde eine Maske erstellt, über die die Testdaten erfaßt oder geändert werden. Das zugehörige Programm stellt über die Maske die Erfassung, die Änderung und die Löschung des Datensatzes sicher und fuhrt das Update im, Testdatenspeicher durch.

Der Aufwand zur Erstellung einer Maske mitsamt dem zugehörigen Programm stellt sich im Schnitt auf zirka 20 Minuten. Mit Hilfe der Masken ist es der Fachabteilung ohne

weitere Unterstützung möglich, Testdaten zu erzeugen, zu variieren und zu modifizieren.

Müssen Satzstrukturen während der Entwicklung verändert werden, so stellt sich die Übernahme der bereist erzeugten Testdaten als unkritisch heraus. Mittels einfacher Lade- und Entladeprogramme kann der komplette Datenbestand übernommen werden und steht somit für die weitere Testdurchführung zur Verfügung.

Der Testumgebungsgenerator umfaßt alle Programme, die zur Erzeugung der Testumgebungen notwendig sind. Je Satzart wird ein Programm benötigt. Eine Zusammenfassung zu einem Programm je benötigter Testumgebung ist möglich. Aufgrund der Eingabe von Teststufe und Testfall erzeugt er die erforderlichen Bewegungsdateien und Datenbanksätze. Die Programme sind alle in derselben Abfragesprache geschrieben und haben eine mittlere Lange von 25 Zeilen. Zudem sind sie von gleicher Struktur und können von einem Master abgeleitet werden.

Der Generator wird durch den Testdriver gestartet und läuft unmittelbar vor der Testdurchführung automatisch an. Damit ist nahezu ausgeschlossen, daß aufgebaute Testumgebungen versehentlich zerstört werden. Für eine testende Fachabteilung sind diese Vorbereitungen nicht wahrnehmbar.

Der Testdriver wird über Panels gesteuert. Er sucht aufgrund der einzugebenden Teststufe, des Testfalls und des Testlings die benötigte Job-Prozedur, ersetzt die erforderlichen Parameter und startet den Testlauf. Wie bereits beschrieben, beginnt der Lauf mit der Erstellung der Testumgebung und führt dann zum Start des Testlings. Zwischenergebnisse, insbesondere von temporären Dateien werden im Format der Eingabemasken angelistet. Leicht interpretierbar und von bekannter Struktur kann die Fachabteilung den Testlauf verfolgen und analysieren. Die Laufprozeduren sind im wesentlichen identisch mit den späteren produktiven Prozeduren. Die Modifikationen für den Test fallen aufwandmäßig nicht ins Gewicht.

Durch diese Vorbereitungen wurde die Fachabteilung in die Lage versetzt, selbständig einen Testfall entwerfen, in Testdaten umzusetzen, den Testlauf zu starten und auszuwerten. Selbst die Fehlereingrenzung war durch die leicht lesbare Maskendarstellung möglich. Ab der Teststufe 2 konnte die Fachabteilung in den Test einbezogen werden. Die

letzte Komponente des TUS ist die Testumgebungs-Sicherungsroutine.

In Abhängigkeit vom Testling sichert sie den gesamten Output, sowohl der Bewegungsdateien als auch der Datenbanken. Der Output wird unter dem Testschlüssel auf eine sequentielle Datei fortgeschrieben. Hier steht er für Testauswertungen und Vergleiche zur Verfügung.

Bei Bedarf werden die gespeicherten Daten vom Testumgebungsgenerator zum Aufbau der Testumgebungen herangezogen. Für den Test von simulierten Vertragsverläufen werden historische Datenbankzustände benötigt, die mit diesem Hilfsmittel immer wieder herzustellen sind.

Selbst bei höherem Aufwand rechnet sich dieser normalerweise, denn Testengpässe treten nicht mehr auf Es wird wesentlich mehr und vor allem früher getestet. Die Fachabteilung ist bereits mit den ersten funktionsfähigen Programmteilen eingebunden und vorhandene Fehler lassen sich frühzeitig ausmachen und beheben. Der Fertigstellungstermin kann eingehalten werden.

Die Überdeckung der Programmfunktionen ist in einem hohen Ausmaß erreichbar. Die angelegten Testfälle stehen sauber archiviert zur Verfügung und dienen in der Wartung als Nachweisbestand. Ohne Verwendung einer modernen Programmiersprache wäre ein solches System im Rahmen eines Projektes nicht zu realisieren. Allgemein läßt sich sagen, daß die Produktivitätssteigerung durch eine Programmiersprache der vierten Generation in der hier beschriebenen Verwendung tatsächlich und nachweisbar etwa bei dem Faktor vier liegt.