Vorteile

• siehe C₀
• einfachere technische Implementierung über die von Debuggern gelieferten Zeilennummern

Nachteile

• keine Standardmetrik wie C₀
• liefert bei syntaktisch identischen Programmen je nach Formatierung unterschiedliche Werte

Metrik (Messung)

Der Anweisungsüberdeckungsgrad bestimmt sich wie folgt:

${\displaystyle C_{\text{0}}={\frac {\text{Anzahl der durchlaufenen Anweisungen}}{\text{Gesamtanzahl der Anweisungen}}}\cdot 100\quad \%\,}$

Vorteil

Die Anweisungsüberdeckung bietet folgende Vorteile:

• sie deckt nicht erreichbare Anweisungen im Quellcode auf
• Anweisungsüberdeckung ist im Vergleich zu anderen Überdeckungsmaßen schnell zu erreichen

Nachteil

Die Anweisungsüberdeckung sollte jedoch nicht als alleiniges Testkriterium verwendet werden, denn:

• Anweisungsüberdeckung wertet jede Anweisung im Quellcode gleichgewichtig
• bei Steuerstrukturen (Schleifen, Bedingungen, …) werden die Datenabhängigkeiten nicht beachtet und
• leere Zweige werden nicht entdeckt

Beispiel mit Quellcode

Gegeben sei folgender Quellcode:

 /* z wird das Doppelte des größeren Werts von x oder y zugewiesen */
 int z = x;
 if (y > x)
    z = y;
 z *= 2;

In diesem Fall genügt ein einziger Testfall, um eine vollständige Anweisungsüberdeckung zu erreichen, zum Beispiel x = 0, y = 2. Falls y nicht größer als x ist, wird z = y nicht ausgeführt und die vollständige Anweisungsüberdeckung wird nicht erreicht. Um alle Verzweigungen (if und else) einmal zu testen, sollte die Zweigüberdeckung als Testkriterium verwendet werden.

Beispiel mit Kontrollflussgraphen

Gegeben sei folgender Kontrollflussgraph:

Für diesen Kontrollflussgraphen kann die Anweisungsüberdeckung mit einem Testfall erreicht werden: {(Start, 1, 2, 3, 4, 5, Stopp)}.

Allgemein

Der Zweigüberdeckungstest (C₁–Test; auch Kantenüberdeckung, Entscheidungsüberdeckungstest, Branch- oder Edge Coverage genannt) umfasst den Anweisungsüberdeckungstest vollständig. Für den C₁–Test müssen strengere Kriterien erfüllt werden als beim Anweisungsüberdeckungstest. Im Bereich des kontrollflussorientierten Testens wird der Zweigüberdeckungstest als Minimalkriterium angewendet. Mit Hilfe des Zweigüberdeckungstests lassen sich nicht ausführbare Programmzweige aufspüren. Anhand dessen kann man dann Softwareteile, die oft durchlaufen werden, gezielt optimieren.

Analog zum Anweisungsüberdeckungstest wird, um die Codeabdeckung messbar zu machen, der Code in unten stehender Abbildung durch eine boolesche Hilfsvariable test instrumentiert.

Im Gegensatz zum Anweisungsüberdeckungstest durchläuft der Zweigüberdeckungstest alle Zweige. Der Zweigüberdeckungstest wird auch Entscheidungsüberdeckungstest genannt, da die Hilfsvariable mindestens einmal mit dem Wert true und false durchlaufen werden muss. In diesem Fall muss die While-Schleife mindestens zweimal durchlaufen werden. Mit dem Durchlaufen der Zweige wird auch sichergestellt, dass jeder Knoten (Anweisung) mindestens einmal ausgeführt wird. Somit wird auch das Kriterium für den Anweisungsüberdeckungstest erfüllt. Daher subsumiert der Zweigüberdeckungstest den Anweisungsüberdeckungstest. Schwierig ist es für den Zweigüberdeckungstest Testfälle zu generieren, wo Betriebssystemzustände oder Dateikonstellationen getestet werden müssen. Weiterhin ist diese Technik des Testens zum Testen von ’Schleifen’ und zusammengesetzter Entscheidungen nicht geeignet, da weder Kombinationen von Zweigen, noch kompliziert aufgebaute Entscheidungen in Betracht gezogen werden können. Hierfür müssen Erweiterungen herangezogen werden.

Die Zyklomatische Komplexität gibt an, wie viele Testfälle höchstens nötig sind, um eine Zweigüberdeckung zu erreichen.

Weitaus problematischer erweist sich das Zweigüberdeckungsmaß. In dem Fall, dass alle Knoten gleich bewertet sind, verzichtet man auf die Betrachtung der Abhängigkeiten untereinander. Dadurch entsteht kein linearer Zusammenhang zwischen der erreichten Überdeckungsrate und dem Verhältnis zwischen der Anzahl der dazu benötigten Testfälle und der eigentlichen Anzahl der Testfälle, die für die 100-prozentige Zweigüberdeckung notwendig sind. Um den Zweigüberdeckungstest zu verbessern, wird ein Zweig, der abhängig von einem anderen Zweig ist, nicht weiter berücksichtigt. Die Zweige, die nicht abhängig sind, werden als primitiv bezeichnet.

Metrik

Daher ergibt sich für das Überdeckungsmaß:

${\displaystyle C_{\text{primitiv}}={\frac {\text{Anzahl der ausgefuehrten primitiven Zweige}}{\text{Anzahl aller primitiven Zweige}}}x100\%\,}$.

Vorteile

• Deckt nicht erreichbare Zweige auf
• Fehlerentdeckungsrate bei ca. 33 %. Ein Fünftel davon sind Berechnungsfehler, der Rest sind Steuerflussfehler.

Nachteile

• Abhängigkeiten zwischen Bedingungen werden nicht berücksichtigt
• Schleifen werden nur unzureichend getestet; siehe Pfadüberdeckungstest
• komplexe Verzweigungsbedingungen werden nur schwach getestet

Beispiele

Gegeben sei folgender Quellcode:

 /* z wird das Doppelte des größeren Werts von x oder y zugewiesen */
 int z = x;
 if (y > x)
    z = y;
 z *= 2;

Im Gegensatz zum Anweisungsüberdeckungstest ist nun mehr als ein Testfall notwendig, um eine 100%ige Zweigüberdeckung zu erreichen, da sowohl der Fall für den durchlaufenen If-Zweig, als auch der Fall für den nicht-durchlaufenen If-Zweig überprüft werden muss:

Testfall 1: x = 0, y = 2 Testfall 2: x = 2, y = 0

Wie auch im Anweisungsüberdeckungstest sind verschiedene Testfälle möglich, die das geforderte Kriterium erfüllen. Nach Ausführung stellt sich heraus, dass das Ergebnis bei beiden Testfällen der Spezifikation entspricht und der Test somit bestanden ist.

Ein weiteres Beispiel:

Gegeben sei folgender Kontrollflussgraph:

Eine Zweigüberdeckung ist {(Start, 1, 2, 3, 4, 5 Stopp), (Start, 1, 3, 5, Stopp)}.

Übersicht

• C₂a – vollständiger Pfadüberdeckungstest
• C₂b – Boundary-Interior Pfadüberdeckungstest
• C₂c – Strukturierter Pfadüberdeckungstest

C₂a – vollständiger Pfadüberdeckungstest

Es werden alle möglichen Pfade getestet. Problem: Bei Programmen mit Schleifen kann es extrem viele Pfade geben.

C₂b – Boundary-Interior-Pfadüberdeckungstest

Im Prinzip wie der C₂a-Test, nur dass nun die Schleifendurchläufe auf höchstens zwei reduziert werden.

Für jede Schleife gibt es zwei Gruppen von Pfaden:

C₂c – Strukturierter Pfadüberdeckungstest

Im Prinzip wie der C₂b-Test, nur dass nun die Anzahl der Schleifendurchläufe auf eine vorgegebene natürliche Zahl n reduziert wird.

Vorteil

• Hohe Fehlererkennungsrate

Nachteil

• nicht ansprechbare Pfade auf Grund von Bedingungen

Beispiel

Gegeben sei folgender Kontrollflussgraph:

Eine Pfadüberdeckung ist {(Start, 1, 2, 3, 4, 5 Stopp), (Start, 1, 3, 5, Stopp), (Start, 1, 3, 4, 5, Stopp), (Start, 1, 2, 3, 5, Stopp)}.

C₃a – Einfachbedingungsüberdeckungstest

Jede atomare Bedingung einer Entscheidung muss einmal mit true und einmal mit false getestet werden. Beispiel:

boolean a,b;
if(a || b)
{
    ...
}

Eine minimale Testfallmenge, die die Einfachbedingungsüberdeckung erfüllt, ist {(a=false, b=false), (a=true, b=true)}.

C₃b – Mehrfachbedingungsüberdeckungstest

Dieser Test betrachtet alle atomaren Bedingungen einer Bedingung. Wenn n atomare Bedingungen in der Bedingung stehen, dann werden ${\displaystyle 2^{n}}$ Kombinationen gebildet.

Das heißt für das obige Beispiel, dass 4 Testfälle gebildet werden.

C₃c – minimaler Mehrfachbedingungsüberdeckungstest

Diese Version erstellt mehr Testfälle als C₃a und weniger als C₃b, indem jede Bedingung (atomar und zusammengestellt) zu true und zu false evaluiert wird. Die logische Struktur wird hierbei berücksichtigt und der C₁-Test (Zweigüberdeckungstest) ist vollständig in diesem Test enthalten. Ein weiterer Punkt ist, dass der C₃c-Test berechenbar ist. Im obigen Beispiel wird somit der Testfall {(a=false, b=true)} oder {(a=false, b=false)} gewählt, da andernfalls die logische Struktur bereits bei der ersten Teilbedingung abbricht.

Vorteil

• Hohe Fehlererkennungsrate

Nachteil

• nicht ansprechbare Pfade auf Grund von Bedingungen

Bewertung

• Unvollständige Auswertung einer Bedingung durch eine Programmiersprache mit sog. short circuit evaluation wie zum Beispiel C++, C, Java, C#.

Beispiel:

 if (a && b)
 {
     ...
 }
 else
 {
    // Lies b aus
 }

Wenn a false ist, dann ist die Belegung der Variable b egal. Zum Beispiel a=false und b=null, dann passiert ein Fehler im else-Zweig