Path Coverage

Path Coverage

Die kontrollflussorientierten Testverfahren, auch Überdeckungstests genannt, gehören zu der Gruppe der strukturorientierten Testmethoden.

Die kontrollflussorientierten Testverfahren orientieren sich am Kontrollflussgraphen des Programms. Es handelt sich bei diesen Tests um White-Box-Testverfahren, d.h die Struktur des Programms muss bekannt sein.

Die einzelnen Tests werden mit Cx bezeichnet was für "Coverage" steht, was so viel heißt wie die Abdeckung oder die Gesamtheit der ausgewerteten Informationen.

Inhaltsverzeichnis

Unterschiedliche Arten

Nomenklaturen

Es gibt mehrere zueinander sehr ähnlich aussehende, aber in der Bedeutung unterschiedliche Bezeichnungsarten:

Beginnt die Bezeichnung mit kleinen c → siehe Harry M. Sneed, Mario Winter "Testen objektorientierter Software", 3-446-21820-3, Hanser Verlag

Beginnt die Bezeichnung mit einem großen C und steht die nun folgende Ziffer auf der Grundlinie wie das C, z. B. C4 → Ernest Wallmüller, „Software - Qualitätssicherung in der Praxis“, Hanser Verlag.

Beginnt die Bezeichnung mit einem großen C und ist die folgende Ziffer ein Subskript, z.B. C1, liegt also unterhalb der Grundlinie → siehe Standard DO-178B.

Zeilenüberdeckungstests

Noch vor der Hierarchie der Cx Testverfahren steht die von vielen Werkzeugen in der Softwareentwicklung bereitgestellte Zeilenüberdeckungskennzahl. Sie ist etwas unschärfer als C0, orientiert sich auch nicht direkt am Kontrollflussgraph, kann aber oft direkt aus den Informationen gewonnen werden, die Debugger ohnehin liefern.

Bei der Zeilenüberdeckung werden nicht die Anweisungen betrachtet, sondern nur die ausführbaren Quellcodezeilen.

 if(false){print "abgedeckt?";}

würde zu einer 100% Zeilenabdeckungskennzahl führen. Während das syntaktisch identische, aber anders formatierte Programm

 
 if(false){
   print "abgedeckt?";
 }

nur zu einer 50% Zeilenüberdeckungskennzahl führt.

In der Regel sind die Unterschiede in der praktischen Anwendung allerdings nicht relevant, da durch andere Maßnahmen in der Softwareentwicklung wie Style Guides eine weitgehende Homogenisierung der Quellcodeformatierung vorliegt.

Vorteile

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

Nachteile

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

C0. Anweisungsüberdeckungstest (Statement Coverage)

Anweisungsüberdeckungstest

Allgemein

Anweisungsüberdeckungstests, auch C0-Test genannt, sind die am einfachsten anwendbaren kontrollflussorientierten Testmethoden. Mit den Anweisungsüberdeckungstests wird sichergestellt, dass kein “toter Code“, Anweisungen die niemals durchlaufen werden, im Programm existiert. Dies ist ein notwendiges Kriterium um sicherzugehen, dass jede Anweisung auf Fehler untersucht wird. Der Sinn des Anweisungsüberdeckungstests ist die mindestens einmalige Ausführung aller Anweisungen in einem Programm. Ist dies gewährleistet, spricht man von einer völligen Anweisungsüberdeckung. Wie in der unten stehenden Abbildung zu erkennen ist, werden alle Anweisungen mindestens einmal ausgeführt, wenn die While-Schleife einmal durchlaufen wird. Unser Testpfad enthält zwar alle Knoten, aber nicht alle Kanten. Die Kante (n3,n5) wird im optionalem Else-Teil nicht ausgeführt. Genau dieser Fall wird im Zweigüberdeckungstest betrachtet. Durch die Einführung der Zähler kann beim automatisierten Testen kontrolliert werden, ob jede Anweisung ausgeführt wurde, indem man sich die Werte nachdem Testdurchlauf ausgeben lässt. Anweisungsüberdeckungstests werden selten als Haupttestwerkzeug in einem Vollständigkeitstest eingesetzt, denn dafür sind sie i. d. R. zu schwach.

Metrik

Der Anweisungsüberdeckungsgrad bestimmt sich wie folgt:

               Anzahl der ausgeführten Anweisungen
cAnweisung = ------------------------------------------
                 Gesamtanzahl der Anweisungen

Vorteil

  • Es werden nicht erreichbare Anweisungen im Quellcode aufgedeckt.
  • Fehleridentifikationsquote liegt bei ca. 18 %

Nachteil

  • jede Anweisung im Quellcode wird gleichgewichtig gewertet
  • bei Steuerstrukturen (Schleifen, Bedingungen, …) werden die Datenabhängigkeiten nicht beachtet
  • leere Zweige werden nicht entdeckt

Beispiel

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 100%ige Anweisungsüberdeckung zu erreichen: z. B. x = 0, y = 2 Es sind beliebig viele passende Testfälle denkbar, solange y größer als x ist ansonsten wird z = y nicht ausgeführt, und die Anweisungüberdeckung ist <100%).

C1. Zweigüberdeckungstest (Branch Coverage)

Zweigüberdeckungstest

Allgemein

Der Zweigüberdeckungstest (C1–Test) umfasst den Anweisungsüberdeckungstest vollständig. Für den C1–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, wieviele 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ß:

                Anzahl der ausgeführten primitiven Zweige
Cprimitiv = ---------------------------------------------------
                  Anzahl aller primitiven Zweige

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

Beispiel

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 sind 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.

C2. Pfadüberdeckungstest (Path Coverage)

Beim Pfadüberdeckungstest (auch C2-Test bzw. englisch path coverage) werden im Kontrollflussgraphen die möglichen Pfade vom Startknoten bis zum Endknoten betrachtet.

Übersicht

  • C2a - vollständiger Pfadüberdeckungstest
  • C2b - Boundary-Interior Pfadüberdeckungstest
  • C2c - Strukturierter Pfadüberdeckungstest
  • Vorteil
  • Nachteil

C2a - vollständiger Pfadüberdeckungstest

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

C2b - Boundary-Interior-Pfadüberdeckungstest

Im Prinzip wie der C2a-Test, nur dass nun die Schleifendurchläufe auf <=2 reduziert werden.

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

Boundary-Test
  • Jede Schleife wird keinmal betreten.
  • Jede Schleife wird genau einmal betreten und alle Pfade in dem Schleifenkörper werden einmal abgearbeitet.

Interior-Test
  • Das Schleifeninnere gilt als getestet, wenn alle Pfade, die bei zweimaligem Durchlaufen möglich sind, abgearbeitet wurden.

C2c - Strukturierter Pfadüberdeckungstest

Im Prinzip wie der C2b-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

C3. Bedingungsüberdeckungstest

Bedingungsüberdeckungstest

Der Bedingungsüberdeckungstest (engl. Condition Coverage) gehört zu einer Gruppe von Überdeckungstests, die zum Testen von Software verwendet werden.

Das Problem der bisherigen Überdeckungstests (C1-Test, C2-Test) ist, dass zusammengesetzte, hierarchische Bedingungen nicht ausreichend getestet werden.

C3a - Einfachbedingungsüberdeckungstest

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

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

Testfall 1 wäre a=false und b=false. Testfall 2 wäre a=true und b=true.

C3b - Mehrfachbedingungsüberdeckungstest

Dieser Test betrachtet alle atomaren Bedingungen einer Bedingung. Wenn n atomare Bedingungen in der Bedingung stehen, dann werden 2n Kombinationen gebildet.

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

C3c - minimaler Mehrfachbedingungsüberdeckungstest

Diese Version erstellt mehr Testfälle als C3a und weniger als C3b, indem jede Bedingung (atomar und zusammengestellt) zu true und zu false evaluiert wird. Die logische Struktur wird hierbei berücksichtigt und der C1-Test (Zweigüberdeckungstest) ist vollständig in diesem Test enthalten. Ein weiterer Punkt ist, dass der C3c-Test berechenbar ist.

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 z. B. C/C++, Java, C#.

Beispiel:

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

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

Zusammenfassung

Kurzname erfüllte Bedingung Durchführbarkeit
Anweisungsüberdeckungstest C0 jede Anweisung wird mindestens einmal ausgeführt relativ einfach
Zweigüberdeckungstest C1 jede Kante im KFG wird mindestens einmal durchlaufen realistische Mindestanforderung, vertretbarer Aufwand
Pfadüberdeckungstest C2
Vollständig C2a Alle möglichen Pfade werden durchlaufen unmöglich bei Schleifen
Boundary-Interiour C2b wie C2a, Schleifen werden jedoch nach speziellen Regeln durchlaufen aufwändig
Strukturiert C2c wie C2b, Schleifen werden jedoch genau n-mal durchlaufen aufwändig
Bedingungsüberdeckungstest C3
Einfachbedingung C3a jede atomare Bedingung wird einmal mit true und false getestet
Mehrfachbedingung C3b jede true/false Kombination der atomaren Bedingungen wird getestet sehr hoher Aufwand
Minimale Mehrfachbedinung C3c jede atomare Bedingung und die Gesamtbedingung wird mit true und false getestet hoher Aufwand

Bewertung

Die Qualität eines Tests hängt entscheidend vom gewählten Test ab: Wurde nur nach C0 mit Überdeckungsgrad 100 % getestet, so ist dies trotzdem kein verlässlicher Indikator für eine fehlerfreie Software.

Wurde hingegen mit C2 auf 100 % getestet, würde dies ein gutes Kriterium für eine fehlerfreie bzw. -arme Software darstellen. Leider ist dieser Test wegen der kombinatorischen Explosion in der Praxis für nicht triviale Programme nicht durchzuführen.

Die zweite wichtige Größe ist natürlich der Überdeckungsgrad. Dieser ist aber nur bei Verwendung des gleichen Tests untereinander vergleichbar.

Bei einem hohen Überdeckungsgrad werden mehr Fehler gefunden als bei einem niedrigen.

Siehe auch

Literatur

  • Helmut Balzert: Lehrbuch der Software-Technik, Spektrum Verlag 2008, ISBN 978-3-8274-1161-7
  • Andreas Spillner, Tilo Linz: Basiswissen Softwaretest, dpunkt.Verlag 2005, ISBN 3-89864-358-1
  • Harry M. Sneed, Mario Winter: Testen objektorientierter Software, Hanser Verlag 2002, ISBN 3-446-21820-3
  • Ernest Wallmüller: Software Qualitätssicherung in der Praxis, Hanser Verlag 2001, ISBN 3-446-21367-8

Weblinks

  • [1] Seminararbeit über die Thematik (Grundlagen dieser Seite)
  • [2] PowerPoint-Vortrag über die Verfahren und theoretische Grundlagen
  • [3]Prof. Dr Holger Schlingloff, Fraunhofer Ges., FIRST, "Überdeckungen"
  • [4] Steve Cornett, "Code Coverage Analysis"
  • [5] DO-248B, Final Annual Report For Clarification Of DO-178B “Software Considerations In Airborne Systems And Equipment Certification”

Wikimedia Foundation.

Игры ⚽ Нужно сделать НИР?

Schlagen Sie auch in anderen Wörterbüchern nach:

  • Code coverage — is a measure used in software testing. It describes the degree to which the source code of a program has been tested. It is a form of testing that inspects the code directly and is therefore a form of white box testing.[1] Code coverage was among …   Wikipedia

  • Branch Coverage — Die kontrollflussorientierten Testverfahren, auch Überdeckungstests genannt, gehören zu der Gruppe der strukturorientierten Testmethoden. Die kontrollflussorientierten Testverfahren orientieren sich am Kontrollflussgraphen des Programms. Es… …   Deutsch Wikipedia

  • Code Coverage — Die kontrollflussorientierten Testverfahren, auch Überdeckungstests genannt, gehören zu der Gruppe der strukturorientierten Testmethoden. Die kontrollflussorientierten Testverfahren orientieren sich am Kontrollflussgraphen des Programms. Es… …   Deutsch Wikipedia

  • Decision Coverage — Die kontrollflussorientierten Testverfahren, auch Überdeckungstests genannt, gehören zu der Gruppe der strukturorientierten Testmethoden. Die kontrollflussorientierten Testverfahren orientieren sich am Kontrollflussgraphen des Programms. Es… …   Deutsch Wikipedia

  • Statement Coverage — Die kontrollflussorientierten Testverfahren, auch Überdeckungstests genannt, gehören zu der Gruppe der strukturorientierten Testmethoden. Die kontrollflussorientierten Testverfahren orientieren sich am Kontrollflussgraphen des Programms. Es… …   Deutsch Wikipedia

  • Code Coverage — Couverture de code La couverture de code (en anglais code coverage) est une mesure utilisée en génie logiciel pour décrire le taux de code source testé d un programme. Ceci permet de mesurer la qualité des tests effectués. La mesure de ce taux… …   Wikipédia en Français

  • Media coverage of the Arab–Israeli conflict — This article is part of the Arab Israeli conflict series. History Views on the conflict …   Wikipedia

  • Decision-to-decision path — A decision to decision path, or DD Path, is a path of execution (usually through a graph representing a program, such as a flow chart) that does not include any conditional nodes. That is, it is the path of execution between two decisions. DD… …   Wikipedia

  • Cyclomatic complexity — (or conditional complexity) is a software metric (measurement). It was developed by Thomas J. McCabe, Sr. in 1976 and is used to indicate the complexity of a program. It directly measures the number of linearly independent paths through a program …   Wikipedia

  • Anweisungsüberdeckungstest — Die kontrollflussorientierten Testverfahren, auch Überdeckungstests genannt, gehören zu der Gruppe der strukturorientierten Testmethoden. Die kontrollflussorientierten Testverfahren orientieren sich am Kontrollflussgraphen des Programms. Es… …   Deutsch Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”