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.

22.04.1977 - 

Siemens-Leitfaden Software-Entwicklung:

Systematik mindert Ärger pro Phase

MÜNCHEN (uk) - Überhöhter Aufwand in der Realisierungsphase, ständiges Nachentwickeln und immer wie, der Fehler beheben während der Einsatzperiode: Dieser ganze (typische) Software-Ärger hat logische Wurzeln. Planungsmängel bei Projektbeginn, unsystematisches Vorgehen (weil beispielsweise Entscheidungspunkte fehlen) während des Projektablaufes und ein Mangel an Vorleistungen (bei Techniken, Methoden, Standards), das sind die Ursachen.

Diese Erfahrungen machten Organisations-, Datenverarbeitungs- und Schulungsabteilungen der Siemens AG bei Analysen von bereits realisierten Softwareprojekten. Bestätigt wurde auch, daß Terminpläne, Personal- sowie Rechenzeitkosten besonders bei denjenigen Projekten überschritten wurden, bei denen Instrumentarien zur Projektplanung, -überwachung und -kontrolle nicht vorhanden waren beziehungsweise ungenügend genutzt wurden

Um den Zielen der Kostenminimierung bei Softwareentwicklung und -pflege sowie der Qualitätsverbesserung von Softwareprodukten einen Schritt näherzukommen, hat das Siemens-Autorenkollektiv End/Gotthardt/Winkelmann einen Leitfaden für die Softwareentwicklung gesponnen. An diesem Ariadne-Faden können sich alle Projektbeteiligten systematisch von der Planung zur Realisierung leiten lassen. Danach kann jeder einzelne Arbeitsschritt (von der Idee bis zur Einführung), können Auswahl und Einsatz geeigneter Realisierungshilfen kontrolliert werden. Die in dem Entwicklungs-Hilfsdienst beschriebene Vorgehensweise soll universal anwendbar sein: In Industriebetrieben und Handelsunternehmen genauso wie in der kommunalen Verwaltung, in Behörden und bei Geld- und Kreditinstituten. Eine dieser Resourcen - "Die Minimierung der Testfälle mit Hilfe der Eliminationsmethode" - wird im folgenden von Co-Autor Horst Gotthardt erläutert. Mit "Elimination" läßt sich die minimale Anzahl von Testfällen bei der Verwendung von Struktogrammen herausfinden; außerdem beschreibt Gotthardt, wie die Gesamtzahl von Testfall-Kombinationen ermittelt wird.

Die Unsicherheit des Programmierers, ob seine Programmkomponente

vollständig ausgetestet ist, soll mit dieser Methode vermindert werden Minimale Anzahl von Testfällen gefunden werden, bei denen jeder Weg und damit auch jeder Befehl beziehungsweise jede Anweisung mindestens einmal ausgeführt wird. Wenn man bei den mit dieser Methode ermittelten Testfallen noch berücksichtigt, welche Wege den "Normalfall" repräsentieren und dabei die jeweils oberen und unteren Wertgrenzen (beispielsweise ein Index) mit einschließt, kann man davon ausgehen, daß der Programmteil ausreichend getestet ist.

Im Bild 1 existieren die Wege a, b, c und d. Mit der Auswahl ac und bd werden alle Wege benutzt, aber nicht alle Kombinationen, da die Möglichkeiten ad und bc fehlen. Diese Kombinationen sind nur wichtig, wenn in a oder b die Wahl zwischen den Wegen c und d beeinflußt wird. Die Aktionen, die nach Verzweigungen durchgeführt werden, sind zwar wichtig und müssen auf korrekten Ablauf geprüft werden, sie sind aber unwichtig bei der Bestimmung der minimalen Anzahl der Testfälle.

Jeder Durchlauf ein Testfall

Es werden nur die Verzweigungen der Struktogramme (IF, CASE) betrachtet. Die CYCLE- und WHILE-Konstruktionen werden als einfache Aktionen angesehen. Zur Ermittlung der minimalen Testfälle wird das Struktogramm abgearbeitet, indem die in einem Durchgang durchlaufenen Strukturblöcke mit gleichen Zeichen (beispielsweise Buchstaben) gekennzeichnet werden. Dabei fängt man links oben an und nimmt den jeweils links stehenden (beispielsweise JA-Zweig) noch nicht gekennzeichneten Strukturblock. Es sind so viele Durchlaufe notwendig bis jeder Strukturblock einmal gekennzeichnet ist. Die Durchlaufanzahl (Anzahl der verschiedenen Kennzeichnungen) ist gleichzeitig auch die gesuchte Anzahl der minimalen Testfälle.

Beispiel:

Als erstes wird aus Übersichtsgründen ein Struktogramm gezeichnet, in dem die Entscheidungen durchnumeriert sind und die Aktionen nicht aufgeführt werden.

Im ersten Durchgang werden die links stehenden Strukturblöcke 1Y, 8Y, 9Y mit dem Buchstaben A gekennzeichnet. Im zweiten Durchgang sind die links stehenden Strukturblöcke 1N, 2Y, 6Y, 8Y, 9N - sie werden mit B gekennzeichnet.

Mit den Testfällen A, B und C ist der Strukturblock, der durch die Entscheidung 8 gekennzeichnet ist, mit der minimalen Anzahl von notwendigen Testfällen ausgetestet. Welche Wege in diesem Strukturblock für die noch folgenden Testfälle, die zum Austesten des kantendeckenden Vorgängers notwendig sind, beschritten werden, ist frei wählbar. Diese Vorgehensweise muß so lange wiederholt werden, bis alle Stukturblöcke gekennzeichnet sind.

Das Bild zeigt die Testfälle E und F Mit diesen Testfällen ist die vorliegende Programmkomponente ausgetestet. Es sind demnach Testdaten zu erstellen, die folgende Wege durchlaufen

A: 1Y, 8Y, 9Y.

B: 1N, 2Y, 6Y, 8Y, 9N.

C: 1N, 2N, 3Y, 4Y, 6N, 7Y, 8N.

Ermittlung aller Testfälle

Die Anzahl der Kombinationen ergibt sich durch Multiplikation der Strukturblockausgänge, die gleichen Darstellungsebenen angehören, beginnend von der untersten bis zur obersten. Liegen in einem Verzweigungsstrukturblock nur verschieden tief geschachtelte Entscheidungen, so werden deren Ausgänge zu den größten übergeordneten addiert.

Der Strukturblock der Entscheidung 1 und der Entscheidung 8 liegen auf der gleichen Darstellungsebene. Damit errechnet sich die Gesamtzahl der Kombination als Produkt der Kombinationen aus den Entscheidungen 1 und 8. Die Summe der Kombinationen des Strukturblocks der Entscheidung 1 ergibt sich aus dem Produkt der Ausgänge der auf gleicher Darstellungsebene liegenden Entscheidungen 2 (5 Ausgänge) und 6 (3 Ausgänge) plus dem Ausgang der Entscheidung (YES-Zweig). Der Strukturblock der Entscheidung 8 hat 3 Ausgänge. Das Produkt aus der Entscheidung 1 (16 Kombinationen) und Entscheidung 8 (3 Kombinationen) ergibt die Gesamtzahl der möglichen Testfälle (48).

Mit 48 Kombinationen können alle möglichen Entscheidungen dieser Programmkomponente auf ihre logische Richtigkeit überprüft werden.

*Horst Gotthardt ist Mitautor des Buches "Softwareentwicklung" und beschäftigt im Siemens Unternehmensbereich Nachrichtentechnik.