Die Fehlerfreiheit eines Programmes, das wissen wir spätestens seit Dijkstra, läßt sich nicht nachweisen. Aber jede Software sollte irgendwann einmal freigegeben werden. Die Frage ist also, wann die Fehlersuche beendet werden kann oder darf. Georg Erwin Thaller* stellt verschiedene Methoden vor, diesen Zeitpunkt zu ermitteln.
Wenn wir von der noch wenig gebräuchlichen Methode des Richtigkeitsbeweises von Programmen im mathematischen Sinn einmal absehen, ist Testen immer noch die in fast 100 Prozent der Fälle angewendete Technik, um das Funktionieren der Software sicherzustellen. Nun hat das Testen von Software, selbst wenn es unter Beachtung anerkannter Techniken verantwortlich durchgeführt wird, immer auch eine Schattenseite.
Edsger W. Dijkstra behauptete mit vollem Recht: Durch Testen kann die Anwesenheit von Fehlern bewiesen werden, nicht die Fehlerfreiheit von Programmen. Anders ausgedruckt heißt
das: Wir können über die Anzahl der in einem Programm verborgenen Fehler niemals absolut sicher sein. Auch durch intensives Testen läßt sich nicht schlüssig beweisen, daß wir wirklich alle Fehler in der Software gefunden haben.
Nun geschieht Software-Entwicklung in einer durch Zeitpläne und beschränkte Mittel gekennzeichneten Umgebung. Gewiß wird man ein Phasenmodell für die Entwicklung zugrunde legen und auch genügend Zeit für das Testen des Programmcodes und die Integration der Software zulassen. Doch es kommt der Punkt, wo die Freigabe ansteht. Wie kann das Management nun entscheiden, ob die Software ausgereift und stabil genug ist, um an den Kunden ausgeliefert zu werden?
Leider gibt es auf diese Frage keine exakte Antwort. Immerhin sind uns jedoch Anhaltswerte bekannt. Ware Myers nannte Ende 1986 in einem Artikel in "IEEE Software" einige Zahlen: Bei neu geschaffener Software ist mit einer Fehlerrate von 30 bis 85 pro 1000 Programmzeilen (Lines of Code) zu rechnen. Das sind also drei bis 8,5 Prozent fehlerhafte Zeilen.
Selbstverständlich wird die Masse dieser Fehler während der Entwicklung und des Tests der Software gefunden werden. Da jedoch gegen Ende der Testzeit das Aufspüren der Fehler zunehmend schwieriger und langwieriger wird, muß aus wirtschaftlichen Gründen der Test beendet werden, bevor auch wirklich der letzte Fehler gefunden und beseitigt wurde.
Das führt dazu, daß bei Freigabe und Auslieferung der Programme noch Restfehler in der Größenordnung von 0,03 bis 3,0 pro 1000 Lines of Code (LoC) im Programmcode verbleiben. Um uns eine Vorstellung über das Fehlerpotential zu machen, sollten wir uns ein Beispiel ansehen: Bei einem Computerprogramm von 23 000 Lines of Code können wir mit einer anfänglichen Fehlerzahl von 690 bis 1955 und mit bis zu 69 Restfehlern rechnen.
Dies sind Durchschnittswerte der Industrie. Aussagekräftiger sind die Zahlen der eigenen Organisation, die man durch die Auswertung von abgeschlossenen Projekten gewinnen kann. Auch sollte man differenzieren, was den Typ der Software angeht.
Nun mögen 50 Restfehler für ein Spielprogramm tolerierbar sein. Wenn das Programm allerdings dazu dient, ein Verkehrsflugzeug zu steuern, so ist diese Fehlerzahl zu hoch. Folglich sind die entsprechenden Maßnahmen immer projektspezifisch abzustimmen. Besser wäre es, wenn wir die Zahl der Fehler für ein Softwareprojekt anhand spezifischer Bedingungen ermitteln könnten.
Muneo Takahashi und Yuji Kamayachi bieten hierzu eine Gleichung an. Diese Formel beruht auf einer Auswertung der Ergebnisse von 30 abgeschlossenen Projekten.
Die Software-Entwicklung ist ja keine starre Abfolge von Handlungen, sondern ein dynamischer Prozeß. Die Parameter und die Umgebungsbedingungen der Software-Entwicklung haben auch einen Einfluß auf die zu erwartende Anzahl der Fehler.
Dies kommt in der Gleichung deutlich zum Ausdruck:
C3: Konstante 9,69
C4: Konstante 0,08
SCHG: Änderungen des Lastenhefts während der Entwicklung, also Anzahl der Seiten an "Software Trouble Reports" (STR),
ISKL: durchschnittliche Erfahrung des Entwicklungsteams in Jahren,
DOCC: Ausgereiftheit des Entwurfs, also Anzahl der geänderten oder neu erstellten Seiten an Designdokumenten.
Änderungen im Lastenheft während der Entwicklung treiben also die Fehlerrate in die Höhe. Ein ausgereiftes Design hat einen positiven Einfluß, und auch die Auswahl einer erfahrenen Entwicklungsmannschaft
kann dazu beitragen, die Fehlerquote zu senken.
Da erfahrene Programmierer allerdings auch teurer sind, kann man in einem Projekt nicht nur Ingenieure mit langjähriger Erfahrung einsetzen; auch hier gibt es also Grenzen der Wirtschaftlichkeit.
Doch lassen Sie uns mit der Formel einmal ein Beispiel durchrechnen: Wir verwenden dazu wieder unser kleines Projekt mit 23000 LoC. Wir wollen ferner annehmen, daß eine Änderung im Lastenheft der Software einen um den Faktor 1,2 höheren Änderungsaufwand im Entwurf bedingt. Für die durchschnittliche Erfahrung der Programmierer setzen wir vier Jahre an.
Die Abhängigkeit der Fehlerrate vom Entwicklungsprozeß sieht folgendermaßen aus:
Auch die Erfahrung der Programmierer ist nicht zu unterschätzen. Bei 500 Änderungen im Lastenheft und 600 Seiten Änderungen im Entwurf lassen sich für die Beziehung von Fehlern zu Mitarbeitererfahrung folgende Werte vorhersagen:
Dabei ist:
f_r: Anzahl der noch verbleibenden Fehler,
f_v: Gesamtzahl der vorhergesagten Fehler,
f_i: Anzahl der bereits vor der Integration gefundenen Fehler,
M_: Zahl der bereits integrierten Software-Module,
M_t: Gesamtzahl der Module des Software-Pakets.
Auch diese Methode setzt selbstverständlich voraus, daß man die Fehler in der Software von Anfang an erfaßt. Außerdem muß eine strenge Abgrenzung der einzelnen Phasen der Software-Entwicklung erfolgen.
Bestimmte Fehler werden vorher bewußt eingebaut
Eine bereits seit langem bekannte Methode soll hier der Vollständigkeit halber erwähnt werden. Dabei Werden von einer unabhängigen Gruppe vor dem Test durch eine externe Testgruppe bestimmte Fehler in die Software eingebaut. Welche Fehler dies sind, muß natürlich geheim sein.
Die externe Testgruppe wird während ihrer Arbeit eine ganze Reihe von Fehlern finden - die absichtlich eingebauten und auch viele andere, von denen niemand etwas wußte. Aus dem Verhältnis der gefundenen eingebauten und der ebenfalls gefundenen anderen Fehler läßt sich ein Schluß auf die Fehlerfreiheit des getesteten Programms ziehen. Sind alle eingebauten Fehler tatsächlich gefunden worden, sollte die getestete Software fehlerfrei sein.
In der Praxis stößt diese Methode auf eine Reihe von Schwierigkeiten: Die absichtlich eingebauten Fehler müssen das ganze Spektrum der zu erwartenden Fehler abdecken. Gerade schwerwiegende Fehler sind aber oft so knifflig, daß sie sich kaum künstlich erzeugen lassen. Gewiß muß auch eine große Organisation mit entsprechenden Ressourcen vorhanden sein, sonst funktioniert das Verfahren nicht.
Fehler über einer Zeitachse aufgetragen
Schließlich sollten wir nicht vergessen: Ein gutes Bild sagt mehr als tausend Worte. Wenn wir die Obergrenze der erwarteten Fehler in der Software wissen, können wir die tatsächlich gefundenen Fehler über einer Zeitachse auftragen. Eine solche Grafik könnte so aussehen, wie in der Abbildung oben.
In der Praxis ergibt sich manchmal nicht die erwartete Kurve in der Form einer e-Funktion. Die tatsächlich gefundene Kurve hat vielmehr die Funktion eines leicht gekrümmten "S".
Das kann zum einen daran liegen, daß eine Organisation in den frühen Phasen der Software-Entwicklung die Aufzeichnung und Dokumentation der Fehler nicht mit dem notwendigen Nachdruck betreibt. Natürlich zeigen sich diese Fehler später im Entwicklungsprozeß, mit entsprechend höheren Kosten für die Korrektur.
Eine weitere Ursache kann darin liegen, daß sich eine Firma oder Gruppe erst organisieren muß. Am Anfang der Entwicklung ist der Termin für die Auslieferung des Codes ja noch in weiter Ferne, und man könnte glauben, noch viel Zeit zu haben. Tatsächlich ist dies meist nicht der Fall.
Der Wert der gezeigten Gleichung liegt darin, daß die Bedingungen des Software-Entwicklungsprozesses in ihrem Einfluß auf die Fehlerrate erfaßt werden können. Da dieser Prozeß fast immer eine gewisse Eigendynamik besitzt, liefert die Formel bessere Aussagen als andere Methoden.
Die Frage, wann die Tests sinnvollnerweise beendet werden sollen, läßt sich nun einfach beantworten: Wenn die Anzahl der vorhergesagten Fehler gefunden wurde. Dabei sollte man allerdings nicht zu kleinlich sein. Eine gewisse Bandbreite der Fehlerrate können wir schon akzeptieren, etwa 20 Prozent nach oben und unten.
Je länger der Test, desto seltener werden die Fehler
Ralph Brettschneider geht in seinem ebenfalls in "IEEE Software" erschienen Artikel davon aus, daß die Abnahme der Fehler nach einer Exponential-Funktion erfolgt. Abgesehen von den frühen Phasen der Software-Entwicklung ist das wohl eine berechtigte Annahme.
Brettschneiders Verfahren läuft darauf hinaus, daß eine Zeitspanne in Stunden ermittelt wird, in der während des Tests kein weiterer Fehler mehr auftreten darf. Wird während dieser Testzeit kein neuer Fehler gefunden, dann ist die Software freizugeben. Wird andererseits ein weiterer Fehler gefunden, dann ist der Test fortzusetzen, und es erfolgt keine Freigabe.
Die zugehörige Gleichung stellt sich so dar:
Dabei gilt:
t_zf: Teststunden mit Null Fehlern (zero failure time),
f_k: Fehler beim Kunden nach der Auslieferung,
f_z: erwartete Null-Fehler-Rate, wird mit 0,5 angenommen,
f_test: Zahl der im Test gefundenen Fehler,
t_f: Teststunden bis zum letzten gefundenen Fehler.
Es besteht auch die Möglichkeit, die Anzahl der Fehler beim Kunden (f_k) durch das Produkt der Programmlänge in LoC und der erwarteten Restfehlerrate zu ersetzen.
Wenn wir die Formel einmal, für den gesamten Software-Lifecycle anwenden wollen, dann ergibt sich für unser bekanntes Projekt mit 23 000 LoC das folgende Bild:
Dabei nehmen wir für die Zahl der bereits gefundenen Fehler einmal 750 und für die Zeit bis zum letzten entdeckten Fehler in der Software 120 Stunden an.
Wenn es sich bei der Software um ein sehr kritisches Programm, etwa Embedded-Software, handelt, müssen wir also sieben bis zehn Stunden Test hinter uns bringen, in denen kein Fehler auftreten darf.
Die Methode läßt sich auch für die Wiederfreigabe von Software anwenden, bei der nur bestimmte Module geändert werden oder neu hinzukommen. Rechnen wir mit 3600 geänderten Programmzeilen, einer tolerierbaren Fehlerrate beim Kunden von 0,03/KLoC und sechs gefundenen Fehlern während eines Zeitraums von zwölf Stunden bis zum letzten aufgetretenen Fehler, dann ergibt sich als "zero failure time" in diesem Beispiel eine Zeitspanne von neun Stunden.
Nun ist diese Methode keineswegs vollkommen. Gerechnet werden darf immer nur mit der tatsächlichen Testzeit, also ohne li den Aufwand für das Schreiben der Testprogramme und das Vorbereiten der Tests. Es muß vorausgesetzt werden, daß der Test alle Bereiche und Funktionen der Software gleichmäßig abdeckt. Die Ergebnisse bei der
Anwendung der Gleichung in der Praxis liegen jedoch nahe genug bei den vorausgesagten Werten, so daß man diese Technik empfehlen kann.
Eine Voraussage für den Integrationstest
Die letzte Gleichung in dieser Serie geht davon aus, daß sich die Anzahl der gefundenen Fehler bis zum Integrationstest proportional zur Zahl der Fehler während der Integration der Software verhält. Auch dies ist eine Annahme, die durch die Erfahrung bestätigt wird. Die Gleichung sieht so aus:
Eine solche Form der Kurve läßt auch den Schluß zu, daß das Projekt-Management die Zügel schleifen läßt und die Einhaltung der Termine für Software-Teilprodukte nicht mit dem notwendigen Nachdruck verfolgt.
Allerdings kann uns diese grafische Darstellung deutlich machen, wo wir bei der Auffindung der zu erwartenden Fehler in der Software stehen. Gerade wegen ihrer Anschaulichkeit ist dies eine gute Methode.
Der Test von Software als die zur Zeit am häufigsten eingesetzte Methode zur Verifikation und Validation bedarf in jedem Fall eines klaren und objektiven Kriteriums, um den absoulut richtigen Zeitpunkt zum Beenden der Testphase festlegen zu können.
Dazu wurden hier einige quantitative Methoden aufgezeigt. Sie bedürfen der weiteren Erprobung und der Kalibrierung in den Unternehmen bei konkreten Softwareprojekten. Das Management eines Unternehmens ist gut beraten, wenn es sich zunehmend auf quantitative Methoden verläßt, wenn die Entscheidung zur Freigabe von Software ansteht.