Software Reliability Engineering im Infotainment - Georg-August ...
Software Reliability Engineering im Infotainment - Georg-August ...
Software Reliability Engineering im Infotainment - Georg-August ...
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
2.2.4.2 Testendekriterien<br />
Besonders schwierig ist somit die Frage zu beantworten, wann das Testen zu beenden<br />
ist (vgl. Thaller 1990, S. 260). Mittels statistischer Methoden kann man beispielsweise<br />
die Fehlermeldungen kumuliert gegen die verstrichene Zeit in ein Diagramm eintragen<br />
(siehe folgende Abb. 2.2-3, ausführlich Kap. 3). Hat man die Grenze der erwarteten<br />
Fehler erreicht bzw. erfolgt eine Sättigung (vgl. Kap. 3), kann man das Testen beenden<br />
(vgl. Thaller 1990, S. 262f.).<br />
Abbildung 2.2-3 Fehlerverfolgung bei <strong>Software</strong><br />
Quelle: Thaller 1990, S. 262<br />
Testendekriterien dienen dazu, eine Balance zwischen Test- und Fehlerkosten zu finden<br />
(Spillner et al. 2006, S. 71f.). Die folgende Abbildung 2.2-4 zeigt dies auf. Betrachtet<br />
man die Kurve der Fehlerfolgekosten zeigt sich, dass je länger man testet, die<br />
Fehlerfolgekosten sinken, da weniger Fehler in der <strong>Software</strong> verbleiben und Kosten<br />
produzieren. Die Kurve der Qualitätssicherungskosten zeigt die Kosten des Testens an.<br />
Sie steigt <strong>im</strong> Verlauf des Testens. Folglich geht es darum, das opt<strong>im</strong>ale und<br />
wirtschaftliche Ziel der beiden zu erreichen, so dass die Gesamtkosten, die sich aus<br />
beiden Kurven bilden, so min<strong>im</strong>al wie möglich sind, also weder zu viel noch zu wenig<br />
Aufwand in die <strong>Software</strong>qualität zu stecken (vgl. Schneider 2007, S. 16).<br />
11