Eine Einführung in die Programmiersprache C und ... - C /C++ Ecke

Eine Einführung in die Informatik und die Programmiersprache C
33 Systematisches Testen von Software
Bevor ein Softwaresystem seinem Verwendungszweck übergeben werden kann, muss verifiziert
werden, ob das System seinen Spezifikationen entspricht. Ein System sollte aber nicht erst am Ende
der Entwicklungphase getestet werden, sonst sind viele Fehler nur sehr kostspielig zu beheben.
Es ist also anzustreben, Fehler möglichst frühzeitig zu finden. Konzeptionelle Fehler sollten dabei
schon in der Analyse/Designphase erkannt und behoben werden, da sonst das gesamte Projekt in
Frage gestellt wird. Auch bereits getestete Module sollten wieder überprüft werden, wenn sie in
einem neuen Kontext verwendet werden. Auf jeden Fall müssen die Spezifikationen der Module mit
den jeweiligen Anforderungen verglichen werden.
Der Absturz der ersten ARIANE 5 im Jahre 1996 ist auf ein ungeprüftes Übernehmen von Software
der Ariane 4 zurückzuführen. Es wurde das Trägheitsnavigationssystem der ARIANE 4 übernommen,
dabei wurde auf ausführliche Tests verzichtet, da sich das System in der ARIANE 4 jahrelang
bewährt hatte. Leider hatte die ARIANE 5 aber eine höhere horizontale Geschwindigkeit, was zu
einem Zahlenüberlauf führte, und dies wiederum ziemlich schnell zum Absturz (Resp. kontrollierten
Sprengung) der Rakete. Schadensumme: 1.7 Miliarden DM. Wenn das System nicht einfach
unbesehen übernommen worden wäre, hätte man das Problem mit grosser Sicherheit erkannt. (Weitere
Informationen dazu unter http://www.esa.int/export/esaCP/Pr_33_1996_p_EN.html)
Viele Fehler äussern sich nicht so spektakulär, aber die Gesamtschadenssumme die jährlich durch
nicht sorgfältig durchgeführte Tests entsteht dürfte enorm hoch sein.
Grundsätzlich unterscheidet man zwei Arten von Tests: Statische Tests und Funktionstests.
33.1 Statische Tests (Reviews)
Zu den statischen Tests gehört die Reviewtechnik, dabei werden in jeder Phase alle Dokumente kritisch
auf Fehler und Inkonsistenzen untersucht. Diese Technik kann auf Diagramme, Spezifikationen,
Pflichtenhefte und effektiven Code (Listings) angewendet werden. Dabei wird kein Code ausgeführt,
sondern es findet eine reine visuelle Kontrolle statt.
Ein Review wird dabei nach vorher festgelegten Richtlinien (Checklisten) durchgeführt. Es kann
genauso auf Einhaltung des Codierungstandards (Komentare, Namensgebung, Verschachtelungstiefe,
Funktionsgrösse) wie auf die Codierung selbst geprüft werden.
In einem Review werden gefundene Fehler oder Unstimmigkeiten nicht behoben, sondern nur in
einem Bericht festgehalten. Anschliessend an das Review können zusammen mit dem Autor Lösungsvorschläge
diskutiert werden.
Das Review kann zusammen mit dem Autor, oder auch ohne den Autor des jeweiligen Dokumentes
stattfinden. Wichtig, bei einem Review sind weder Schuldzuweisungen noch Verteidigungen angebracht,
es werden einfach Erkenntnisse sachlich festgehalten.
In einem Projekt sollte jedes Dokument nach seiner Fertigstellung einem Review unterzogen werden.
Ein positiver Seiteneffekt der Reviewtechnik ist zudem die breitere Streuung des Projektwissens
über die Projektmitglieder. Da die Projektmitglieder sich jeweils gegenseitig reviewen, weiss jedes
Mitglied ungefähr was das andere macht, dadurch wird es leichter, Aufgaben umzuverteilen und
neue Mitarbeiter einzubinden. Zudem wird über das ganze Projekt der Programmierstil einheitlicher,
weil man sieht wie andere ihre Arbeit erledigen.
Wichtig, die Ergebnisse der Reviews dürfen nicht zur Qualifikation der Mitarbeiter verwendet werden,
sie dienen nur der Qualitätssicherung innerhalb der Projekte. Sobald sie für Mitarbeiterqualifikation
missbraucht werden, verlieren sie ihr Effizienz ('Gefälligkeitsgutachten').
Gedruckt am 11.09.2008 13:04:00 Letzte Änderung am: 11. September 2008 Version 2.4, I. Oesch 137/147