Eine Einführung in die Programmiersprache C und die Grundlagen ...
Eine Einführung in die Programmiersprache C und die Grundlagen ...
Eine Einführung in die Programmiersprache C und die Grundlagen ...
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
<strong>E<strong>in</strong>e</strong> <strong>E<strong>in</strong>führung</strong> <strong>in</strong> <strong>die</strong> Informatik <strong>und</strong> <strong>die</strong> <strong>Programmiersprache</strong> C<br />
33 Systematisches Testen von Software<br />
Bevor e<strong>in</strong> Softwaresystem se<strong>in</strong>em Verwendungszweck übergeben werden kann, muss verifiziert<br />
werden, ob das System se<strong>in</strong>en Spezifikationen entspricht. E<strong>in</strong> System sollte aber nicht erst am Ende<br />
der Entwicklungphase getestet werden, sonst s<strong>in</strong>d viele Fehler nur sehr kostspielig zu beheben.<br />
Es ist also anzustreben, Fehler möglichst frühzeitig zu f<strong>in</strong>den. Konzeptionelle Fehler sollten dabei<br />
schon <strong>in</strong> der Analyse/Designphase erkannt <strong>und</strong> behoben werden, da sonst das gesamte Projekt <strong>in</strong><br />
Frage gestellt wird. Auch bereits getestete Module sollten wieder überprüft werden, wenn sie <strong>in</strong><br />
e<strong>in</strong>em neuen Kontext verwendet werden. Auf jeden Fall müssen <strong>die</strong> Spezifikationen der Module mit<br />
den jeweiligen Anforderungen verglichen werden.<br />
Der Absturz der ersten ARIANE 5 im Jahre 1996 ist auf e<strong>in</strong> ungeprüftes Übernehmen von Software<br />
der Ariane 4 zurückzuführen. Es wurde das Trägheitsnavigationssystem der ARIANE 4 übernommen,<br />
dabei wurde auf ausführliche Tests verzichtet, da sich das System <strong>in</strong> der ARIANE 4 jahrelang<br />
bewährt hatte. Leider hatte <strong>die</strong> ARIANE 5 aber e<strong>in</strong>e höhere horizontale Geschw<strong>in</strong>digkeit, was zu<br />
e<strong>in</strong>em Zahlenüberlauf führte, <strong>und</strong> <strong>die</strong>s wiederum ziemlich schnell zum Absturz (Resp. kontrollierten<br />
Sprengung) der Rakete. Schadensumme: 1.7 Miliarden DM. Wenn das System nicht e<strong>in</strong>fach<br />
unbesehen übernommen worden wäre, hätte man das Problem mit grosser Sicherheit erkannt. (Weitere<br />
Informationen dazu unter http://www.esa.<strong>in</strong>t/export/esaCP/Pr_33_1996_p_EN.html)<br />
Viele Fehler äussern sich nicht so spektakulär, aber <strong>die</strong> Gesamtschadenssumme <strong>die</strong> jährlich durch<br />
nicht sorgfältig durchgeführte Tests entsteht dürfte enorm hoch se<strong>in</strong>.<br />
Gr<strong>und</strong>sätzlich unterscheidet man zwei Arten von Tests: Statische Tests <strong>und</strong> Funktionstests.<br />
33.1 Statische Tests (Reviews)<br />
Zu den statischen Tests gehört <strong>die</strong> Reviewtechnik, dabei werden <strong>in</strong> jeder Phase alle Dokumente kritisch<br />
auf Fehler <strong>und</strong> Inkonsistenzen untersucht. Diese Technik kann auf Diagramme, Spezifikationen,<br />
Pflichtenhefte <strong>und</strong> effektiven Code (List<strong>in</strong>gs) angewendet werden. Dabei wird ke<strong>in</strong> Code ausgeführt,<br />
sondern es f<strong>in</strong>det e<strong>in</strong>e re<strong>in</strong>e visuelle Kontrolle statt.<br />
E<strong>in</strong> Review wird dabei nach vorher festgelegten Richtl<strong>in</strong>ien (Checklisten) durchgeführt. Es kann<br />
genauso auf E<strong>in</strong>haltung des Co<strong>die</strong>rungstandards (Komentare, Namensgebung, Verschachtelungstiefe,<br />
Funktionsgrösse) wie auf <strong>die</strong> Co<strong>die</strong>rung selbst geprüft werden.<br />
In e<strong>in</strong>em Review werden gef<strong>und</strong>ene Fehler oder Unstimmigkeiten nicht behoben, sondern nur <strong>in</strong><br />
e<strong>in</strong>em Bericht festgehalten. Anschliessend an das Review können zusammen mit dem Autor Lösungsvorschläge<br />
diskutiert werden.<br />
Das Review kann zusammen mit dem Autor, oder auch ohne den Autor des jeweiligen Dokumentes<br />
stattf<strong>in</strong>den. Wichtig, bei e<strong>in</strong>em Review s<strong>in</strong>d weder Schuldzuweisungen noch Verteidigungen angebracht,<br />
es werden e<strong>in</strong>fach Erkenntnisse sachlich festgehalten.<br />
In e<strong>in</strong>em Projekt sollte jedes Dokument nach se<strong>in</strong>er Fertigstellung e<strong>in</strong>em Review unterzogen werden.<br />
E<strong>in</strong> positiver Seiteneffekt der Reviewtechnik ist zudem <strong>die</strong> breitere Streuung des Projektwissens<br />
über <strong>die</strong> Projektmitglieder. Da <strong>die</strong> Projektmitglieder sich jeweils gegenseitig reviewen, weiss jedes<br />
Mitglied ungefähr was das andere macht, dadurch wird es leichter, Aufgaben umzuverteilen <strong>und</strong><br />
neue Mitarbeiter e<strong>in</strong>zub<strong>in</strong>den. Zudem wird über das ganze Projekt der Programmierstil e<strong>in</strong>heitlicher,<br />
weil man sieht wie andere ihre Arbeit erledigen.<br />
Wichtig, <strong>die</strong> Ergebnisse der Reviews dürfen nicht zur Qualifikation der Mitarbeiter verwendet werden,<br />
sie <strong>die</strong>nen nur der Qualitätssicherung <strong>in</strong>nerhalb der Projekte. Sobald sie für Mitarbeiterqualifikation<br />
missbraucht werden, verlieren sie ihr Effizienz ('Gefälligkeitsgutachten').<br />
Gedruckt am 10.09.2009 14:23:00 Letzte Änderung am: 10. September 2009 Version 2.4.1, I. Oesch 137/147