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.

Leitfaden zur Software-Entwicklung:Gut geplant ist halb getestet

16.06.1978

MÜNCHEN (uk) - Grundfehler bei der Software-Entwicklung: Planungsmängel bei Projektbeginn, unsystematisches Vorgehen, etwa wenn Entscheidungskriterien während des Projektverlaufs fehlen und ein Mangel an Vorleistungen (Techniken, Methoden und Standards) - dies alles führt in den Realisierungsphasen (Test und Probebetrieb) zu überhöhtem Aufwand - und in der Einsatzphase zu Nachentwicklung und Fehlerbereinigung. Dabei beansprucht besonders die Testphase einen überproportional großen Anteil an den Projektgesamtkosten. Zu diesem Schluß kommt die Siemens AG in ihrem Leitfaden "Softwareentwicklung", in dem die Erfahrungen mehrere Organisations-, DV- und Schulungsabteilungen des Hauses verarbeitet sind. Bei umfangreicheren DV-Entwicklungen (etwa ab fünf Mannjahren) sollten deshalb nach Siemens-Empfehlungen Planung und Durchführung der Testschritte von einer eigenen "Testgruppe" wahrgenommen werden, in der unter anderem der Chefprogrammierer, Programmierer, DV-Planer sowie Vertreter der Fachabteilung vertreten sein sollten. Die Aufgaben der Gruppe liegen in der Festlegung der Testorganisation/Teststrategie, im Bereitstellen von Testhilfen und Testdaten, im Ermitteln und Reservieren der benötigten Maschinentestzeiten sowie im Durchführen des Komponenten-, Integrations- und Verfahrenstest. Die Detailaufgaben der Testgruppe sieht Siemens so:

Testorganisation/Teststrategie

Für einen erfolgreichen und termingerechten Testablauf müssen die Aufgaben der einzelnen Testschritte in Form eines Testplans präzisiert werden. Festzulegen sind darin sachlich die Reihenfolge des Komponententests, mögliche Testhilfen, zu bildende Testdateien sowie die Dokumentation der Testergebnisse. Zeitlich müssen außerdem die Dauer und die Termine der Testschritte, wann welche Stelle Testdaten liefert, welche Rechenzeiten wann zur Verfügung stehen müssen sowie wann welche Testhilfen bereitgestellt werden müssen. Bei der Planung der Termine der einzelnen Testschritte ist die vom RZ benötigte "Turn-around-Zeit" zu berücksichtigen.

Testhilfen

Die Testhilfen erleichtern und beschleunigen die Testarbeiten wie Fehleranalyse, Auswerten der Ergebnisse sowie die Formulierung von Testabläufen. Stehen keine geeigneten Testhilfen zur Verfügung, sollte geprüft werden, ob sich eine Eigentwicklung lohnt. Die Fehleranalyse erleichtern beispielsweise Programmspeicherauszüge, die den Zustand eines Programms zum Abbruchzeitpunkt wiedergeben. Vorteilhaft sind außerdem ablaufverfolgende Testhilfen, bei denen erst zur Programmlaufzeit die Testpunkte festgelegt werden können wie die Siemens-Pakete "Ida" und "Debug".

Beim Auswerten der Testergebnisse können dagegen Datenträgerauszüge und Datenträgervergleiche hilfreich sein. Zur Formulierung von Testabläufen bieten neuere Betriebssysteme und Programmiersprachen außerdem Sprachelemente, mit denen unter anderem Quellcode vorbereitet, korrigiert und übersetzt, Programme ausgeführt sowie Testdaten erstellt werden können.

Testdaten, Testdateien

Möglichkeiten der Testdatenerstellung: Synthetische Daten durch Personen, generierte Daten durch Testdatenprogramme, Verwendung echter Daten sowie Erzeugen durch bereits ausgetestete Verfahrensteile. Dabei werden beim Komponententest für

die Bewegungsdaten "fiktive" synthetische" Daten vom Programmierer erstellt, während bei Stammdaten auf echte Daten zurückgegriffen wird. Um den Aufwand zur Testdatenerstellung zu minimieren, sollte beispielsweise nach der Eliminationsmethode die Daten so gewählt werden, daß alle Zweige einer Komponente wenigstens einmal durchlaufen werden. Die für den Verfahrenstest notwendigen Daten sollten vom Anwender zur Verfügung gestellt werden und eine repräsentative Menge der Produktivdaten darstellen.

Testzeitbedarf

Bei der Festlegung des Testzeitbedarfs können folgende Schätzwerte als Richtschnur verwendet werden: Bei stapelorientiertem Testbetrieb zehn Stunden Testzeit je Mannmonat geplanter Programmierzeit; bei den logorientiertem Testbetrieb 50 Stunden Terminalzeit je Mannmonat geplanter Programmierzeit.

Komponenten-, Integrations- und Verfahrenstest

Beim Komponententest testet der einzelne Programmierer die von ihm entwickelte Komponente durch Schreibtischtests und Maschinentests. Beim Schreibtischtest werden unter anderem geprüft: formale Richtigkeit der einzelnen Statements, Übereinstimmung der Codierung mit dem Programablaufplan, Programmlogik, Datenträgerorganisation sowie formaler Aufbau von Ergebnissen. Beim Maschinentest wird jede Komponente geprüft, ob sie die richtigen Wege durchläuft und die gewünschten Ergebnisse bringt. Beim Integrationstest werden die freigegebenen Komponenten ins Gesamtsystem integriert und hauptsächlich die Schnittstellen untereinander getestet. Beim Verfahrenstest wird mit Echtdaten der Nachweis der Funktionstreue aus Anwendersicht gebracht. Außerdem wird auch das Laufzeitverhalten überprüft.

Testverfolgung

Die Abwicklung der Testläufe ist in einem Testtagebuch festzuhalten, das unter anderem Informationen über Identifikation des Testfalls, Datum, Testergebnis, Fehlerursache sowie Korrekturen enthält.

Quelle:"Sofhwarentwicklung" von Wolfgang End, Siemens AG, München.