27.02.2014 Aufrufe

4 Unit Tests

4 Unit Tests

4 Unit Tests

MEHR ANZEIGEN
WENIGER ANZEIGEN

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

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!