Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
116<br />
6 <strong>Unit</strong>-<strong>Tests</strong><br />
6.13 Diskussion<br />
6.13.1 Testabdeckung<br />
Eine durchgängige Implementierung von <strong>Unit</strong>-<strong>Tests</strong> bedeutet hohen Aufwand.<br />
Eine Möglichkeit, den Aufwand in Grenzen zu halten, ist es, Software-Teile mit<br />
Integritätsanspruch sauber von anderen Software-Teilen zu trennen und <strong>Unit</strong>-<br />
<strong>Tests</strong> nur dort durchzuführen, wo der Anspruch an die Integrität der Software<br />
dies erfordert. Einschlägige Normen legen diese Erfordernis nahe, sobald die<br />
Software auch nur einen moderaten Sicherheitsanspruch hat. So empfehlen [ISO<br />
26262, DO-178C] zum Beispiel für das niedrigste Integritätsniveau dringend<br />
<strong>Unit</strong>-<strong>Tests</strong> mit zumindest 100% Statement Coverage und [ISO 26262] empfiehlt<br />
auch hier schon das Erreichen von 100% Branch Coverage. Das Erreichen von<br />
100% Branch Coverage für eingebettete Systeme empfiehlt auch [Liggesmeyer<br />
09] schon lange vor dem Erscheinen der ISO 26262 dringend. Für Software mit<br />
hoher Sicherheitsrelevanz ist in allen modernen Standards die Forderung nach<br />
100% MC/DC üblich. Moderne Werkzeuge können MC/DC auch dann korrekt<br />
berechnen, wenn nicht alle Variablen, die auf die Entscheidung Einfluss nehmen,<br />
direkt in der If-Bedingung aufscheinen:<br />
bool a,b,c,d;<br />
/* ... */<br />
if (a || b || c) KeinProblem();<br />
d = a || b || c;<br />
if (d) AuchKeinProblem();<br />
Die vorgestellten Testabdeckungen sind die in der Praxis am häufigsten gemessenen<br />
dynamischen Testmetriken. Wie erwähnt haben diese strukturellen Testabdeckungen<br />
die Schwäche, nur den Kontrollfluss zu messen, nicht aber den Datenfluss,<br />
was aber wünschenswert wäre, ganz speziell bei OO-Designs. Es gibt weit<br />
mehr Testabdeckungen als die wenigen hier vorgestellten. Wissenschaftliche<br />
Publikationen zum Thema Testabdeckung findet man unter den Stichworten Test<br />
Adequacy Criteria. Eine solche Publikation, [Hutchins 94], schließt aus einer<br />
Reihe von Experimenten, dass es keinen Sinn ergibt, bei Erreichen von 90% oder<br />
95% einer Testabdeckung aus Kostengründen die <strong>Tests</strong> zu beenden, wie man<br />
gelegentlich anderswo liest. Das Erreichen von 100% hat einen vergleichsweise<br />
großen Hebel in der Fehlerfindung.<br />
Werkzeuge zur Unterstützung beim Basis Path Testing findet man in der Tool-<br />
Landschaft lange nicht so häufig, wie Werkzeuge zur Messung von Branch Coverage<br />
und MC/DC. Der strukturierte <strong>Unit</strong>-Test ist dem »unstrukturierten« Test<br />
aber gelegentlich überlegen. In den Übungsaufgaben zu diesem Kapitel findet sich<br />
ein Beispiel dazu. Wenn der strukturierte <strong>Unit</strong>-Test gemacht wird, ohne das<br />
Design (also z. B. die Beschreibung einer Schnittstelle) als Testreferenz zu nehmen,<br />
sich also nur am Quellcode orientiert, dann findet der Test niemals fehlende Teile