https://wiki-de.moshellshocker.dns64.de/index.php?action=history&feed=atom&title=Kontrollflussorientierte_TestverfahrenKontrollflussorientierte Testverfahren - Versionsgeschichte2026-06-26T17:05:36ZVersionsgeschichte dieser Seite in Wikipedia (Deutsch) – Lokale KopieMediaWiki 1.43.8https://wiki-de.moshellshocker.dns64.de/index.php?title=Kontrollflussorientierte_Testverfahren&diff=887444&oldid=previmported>Invisigoth67: typo2026-02-18T06:53:28Z<p>typo</p>
<p><b>Neue Seite</b></p><div>[[Datei:Teststrategien.svg|mini|350px|Zusammenhang verschiedener kontrollflussgraphorientierter Testverfahren.]]<br />
<br />
Die '''kontrollflussorientierten Testverfahren''', auch '''Überdeckungstests''' genannt, gehören zu der Gruppe der [[Dynamisches Software-Testverfahren#Strukturorientierte Verfahren|strukturorientierten Testmethoden]] von Software.<br />
<br />
Die kontrollflussorientierten Testverfahren orientieren sich am [[Kontrollflussgraph]]en des Programms. Es handelt sich bei diesen Tests um [[White Box|White-Box-Testverfahren]], das heißt, die Struktur des Programms muss bekannt sein.<br />
<br />
Die einzelnen Testverfahren werden mit ''Cx'' bezeichnet, wobei das „C“ für „Coverage“ steht, was so viel heißt wie die Abdeckung oder die Gesamtheit der ausgewerteten Informationen.<br />
<br />
== Nomenklaturen ==<br />
Es gibt mehrere zueinander sehr ähnlich aussehende, aber in der Bedeutung unterschiedliche Bezeichnungsarten:<br />
* Beginnt die Bezeichnung mit kleinen c → siehe [[Harry Sneed|Harry M. Sneed]], Mario Winter: ''Testen objektorientierter Software.'' Hanser Verlag, ISBN 3-446-21820-3.<br />
* Beginnt die Bezeichnung mit einem großen C und steht die nun folgende Ziffer auf der Grundlinie wie das C, z.&nbsp;B. C4 → Ernest Wallmüller, „Software - Qualitätssicherung in der Praxis“, Hanser Verlag.<br />
* Beginnt die Bezeichnung mit einem großen C und ist die folgende Ziffer ein Subskript, zum Beispiel C<sub>1</sub>, liegt also unterhalb der Grundlinie → siehe Standard [[DO-178B]].<br />
Die [[IEC 61508]] Teil 7 und die davon abgeleiteten Anhänge der [[EN 50128]] verwenden keine Abkürzungen für diese Metriken.<br />
<br />
== Die unterschiedlichen Testarten ==<br />
=== Zeilenüberdeckungstests ===<br />
Noch vor der Hierarchie der C<sub>x</sub> Testverfahren steht die von vielen Werkzeugen in der Softwareentwicklung bereitgestellte Zeilenüberdeckungskennzahl. Sie ist etwas unschärfer als C<sub>0</sub>, orientiert sich auch nicht direkt am Kontrollflussgraph, kann aber oft direkt aus den Informationen gewonnen werden, die Debugger ohnehin liefern.<br />
<br />
Bei der Zeilenüberdeckung werden nicht die Anweisungen betrachtet, sondern nur die ausführbaren Quellcodezeilen. Beliebig viele Testfälle für<br />
<br />
<syntaxhighlight lang="java"><br />
if(false){print "abgedeckt?";}<br />
</syntaxhighlight><br />
<br />
würden zu einer Zeilenüberdeckung von 100 % führen, während es für das syntaktisch und semantisch identische, aber anders formatierte Programm<br />
<br />
<syntaxhighlight lang="java"><br />
if(false){<br />
print "abgedeckt?";<br />
}<br />
</syntaxhighlight><br />
nur zu einer Zeilenüberdeckung von 50 % führt.<br />
<br />
In der Regel sind die Unterschiede in der praktischen Anwendung allerdings nicht relevant, da durch andere Maßnahmen in der Softwareentwicklung wie Kodierungsrichtlinien (engl.: "style guides") eine weitgehende Homogenisierung der Quellcodeformatierung vorliegt.<br />
<br />
==== Vorteile ====<br />
* siehe C<sub>0</sub><br />
* einfachere technische Implementierung über die von [[Debugger]]n gelieferten Zeilennummern<br />
<br />
==== Nachteile ====<br />
* keine Standardmetrik wie C<sub>0</sub><br />
* liefert bei syntaktisch identischen Programmen je nach Formatierung unterschiedliche Werte<br />
<br />
=== C<sub>0</sub>. Anweisungsüberdeckungstest (Statement Coverage) ===<br />
[[Datei:C0Ueb.png|mini|Zur Anweisungsüberdeckung genügt es, alle Anweisungen(rot) im Kontrollflussgraphen einmal zu testen.]]<br />
<br />
Anweisungsüberdeckungstests, auch C0-Test genannt, testen jede Anweisung mindestens ein Mal. Wurde jede Anweisung in einem Programm mindestens einmal ausgeführt, spricht man von vollständiger Anweisungsüberdeckung. Wurde vollständige Anweisungsüberdeckung erreicht, dann steht fest, dass kein [[toter Code]] (Anweisungen, die niemals durchlaufen werden) im Programm existiert.<br />
<br />
Anweisungsüberdeckungstests werden selten als Haupttestwerkzeug in einem Vollständigkeitstest eingesetzt, denn dafür sind sie in der Regel zu schwach.<br />
<br />
==== Metrik (Messung) ====<br />
Der Anweisungsüberdeckungsgrad bestimmt sich wie folgt:<br />
<br />
:<math>C_{\text{0}} = \frac{\text{Anzahl der durchlaufenen Anweisungen}}{\text{Gesamtanzahl der Anweisungen}} \cdot 100 \quad\%\,</math><br />
<br />
==== Vorteil ====<br />
Die Anweisungsüberdeckung bietet folgende Vorteile:<br />
* sie deckt nicht erreichbare [[Anweisung (Programmierung)|Anweisungen]] im [[Quellcode]] auf<br />
* Anweisungsüberdeckung ist im Vergleich zu anderen Überdeckungsmaßen schnell zu erreichen<br />
<br />
==== Nachteil ====<br />
Die Anweisungsüberdeckung sollte jedoch nicht als alleiniges Testkriterium verwendet werden, denn:<br />
* Anweisungsüberdeckung wertet jede Anweisung im Quellcode gleichgewichtig<br />
* bei Steuerstrukturen (Schleifen, Bedingungen, …) werden die Datenabhängigkeiten nicht beachtet und<br />
* leere Zweige werden nicht entdeckt<br />
<br />
==== Beispiel mit Quellcode ====<br />
Gegeben sei folgender Quellcode:<br />
<syntaxhighlight lang="java"><br />
/* z wird das Doppelte des größeren Werts von x oder y zugewiesen */<br />
int z = x;<br />
if (y > x)<br />
z = y;<br />
z *= 2;<br />
</syntaxhighlight><br />
<br />
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.<br />
<br />
==== Beispiel mit Kontrollflussgraphen ====<br />
Gegeben sei folgender Kontrollflussgraph:<br />
<br />
[[Datei:Control-flow-graph.svg|400px]]<br />
<br />
Für diesen Kontrollflussgraphen kann die Anweisungsüberdeckung mit einem Testfall erreicht werden: {(Start, 1, 2, 3, 4, 5, Stopp)}.<br />
<br />
=== C<sub>1</sub>. Zweigüberdeckungstest (Branch Coverage) ===<br />
[[Datei:C1Ueb.png|mini|Zweigüberdeckungstest]]<br />
<br />
==== Allgemein ====<br />
Der Zweigüberdeckungstest (C<sub>1</sub>–Test; auch Kantenüberdeckung, Entscheidungsüberdeckungstest, Branch- oder Edge Coverage genannt) umfasst den Anweisungsüberdeckungstest vollständig.<br />
Für den C<sub>1</sub>–Test müssen strengere Kriterien erfüllt werden als beim Anweisungsüberdeckungstest.<br />
Im Bereich des kontrollflussorientierten Testens wird der Zweigüberdeckungstest als Minimalkriterium angewendet.<br />
Mit Hilfe des Zweigüberdeckungstests lassen sich nicht ausführbare Programmzweige aufspüren.<br />
Anhand dessen kann man dann Softwareteile, die oft durchlaufen werden, gezielt optimieren.<br />
<br />
Analog zum Anweisungsüberdeckungstest wird, um die Codeabdeckung messbar zu machen, der Code in unten stehender Abbildung durch eine boolesche Hilfsvariable test instrumentiert.<br />
<br />
Im Gegensatz zum Anweisungsüberdeckungstest durchläuft der Zweigüberdeckungstest alle Zweige. Der Zweigüberdeckungstest wird auch<br />
Entscheidungsüberdeckungstest genannt, da die Hilfsvariable mindestens einmal mit dem Wert true und false durchlaufen werden muss.<br />
In diesem Fall muss die While-Schleife mindestens zweimal durchlaufen werden. Mit dem Durchlaufen der Zweige wird auch sichergestellt, dass<br />
jeder Knoten (Anweisung) mindestens einmal ausgeführt wird.<br />
Somit wird auch das Kriterium für den Anweisungsüberdeckungstest erfüllt.<br />
Daher subsumiert der Zweigüberdeckungstest den Anweisungsüberdeckungstest.<br />
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.<br />
<br />
Die [[McCabe-Metrik|Zyklomatische Komplexität]] gibt an, wie viele [[Testfall|Testfälle]] höchstens nötig sind, um eine Zweigüberdeckung zu erreichen.<br />
<br />
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,<br />
nicht weiter berücksichtigt. Die Zweige, die nicht abhängig sind, werden als primitiv bezeichnet.<br />
<br />
==== Metrik ====<br />
Daher ergibt sich für das Überdeckungsmaß:<br />
:<math>C_{\text{primitiv}}=\frac{\text{Anzahl der ausgefuehrten primitiven Zweige}}{\text{Anzahl aller primitiven Zweige}} \cdot 100\%\,</math>.<br />
<br />
==== Vorteile ====<br />
* Deckt nicht erreichbare Zweige auf<br />
* Fehlerentdeckungsrate bei ca. 33 %. Ein Fünftel davon sind Berechnungsfehler, der Rest sind Steuerflussfehler.<br />
<br />
==== Nachteile ====<br />
* Abhängigkeiten zwischen Bedingungen werden nicht berücksichtigt<br />
* Schleifen werden nur unzureichend getestet; siehe [[Pfadüberdeckungstest]]<br />
* komplexe Verzweigungsbedingungen werden nur schwach getestet<br />
<br />
==== Beispiele ====<br />
Gegeben sei folgender Quellcode:<br />
<syntaxhighlight lang="java"><br />
/* z wird das Doppelte des größeren Werts von x oder y zugewiesen */<br />
int z = x;<br />
if (y > x)<br />
z = y;<br />
z *= 2;<br />
</syntaxhighlight><br />
<br />
Im Gegensatz zum Anweisungsüberdeckungstest ist nun mehr als ein Testfall notwendig, um eine 100%ige Zweigüberdeckung zu erreichen,<br />
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:<br />
<br />
Testfall 1: x = 0, y = 2<br />
Testfall 2: x = 2, y = 0<br />
<br />
Wie auch im Anweisungsüberdeckungstest sind verschiedene Testfälle möglich, die das geforderte Kriterium erfüllen.<br />
Nach Ausführung stellt sich heraus, dass das Ergebnis bei beiden Testfällen der Spezifikation entspricht und der Test somit bestanden ist.<br />
<br />
Ein weiteres Beispiel:<br />
<br />
Gegeben sei folgender Kontrollflussgraph:<br />
<br />
[[Datei:Control-flow-graph.svg|400px]]<br />
<br />
Eine Zweigüberdeckung ist {(Start, 1, 2, 3, 4, 5 Stopp), (Start, 1, 3, 5, Stopp)}.<br />
<br />
=== {{Anker|Pfadüberdeckungstest}}C<sub>2</sub>. Pfadüberdeckungstest (Path Coverage) ===<br />
Beim Pfadüberdeckungstest (auch C2-Test bzw. englisch path coverage) werden im Kontrollflussgraphen die möglichen Pfade vom Startknoten bis zum Endknoten betrachtet.<br />
<br />
==== Übersicht ====<br />
* C<sub>2</sub>a – vollständiger Pfadüberdeckungstest<br />
* C<sub>2</sub>b – Boundary-Interior Pfadüberdeckungstest<br />
* C<sub>2</sub>c – Strukturierter Pfadüberdeckungstest<br />
<br />
==== C<sub>2</sub>a – vollständiger Pfadüberdeckungstest ====<br />
Es werden alle möglichen Pfade getestet. Problem: Bei Programmen mit Schleifen kann es extrem viele Pfade geben.<br />
<br />
==== C<sub>2</sub>b – Boundary-Interior-Pfadüberdeckungstest ====<br />
Im Prinzip wie der C<sub>2</sub>a-Test, nur dass nun die Schleifendurchläufe auf höchstens zwei reduziert werden.<br />
<br />
Für jede Schleife gibt es zwei Gruppen von Pfaden:<br />
<br />
===== Boundary-Test =====<br />
* Jede Schleife wird<br />
**keinmal und<br />
**genau einmal betreten und alle Pfade in dem Schleifenkörper werden einmal abgearbeitet.<br />
<br />
===== Interior-Test =====<br />
* Das Schleifeninnere gilt als getestet, wenn alle Pfade, die bei zweimaligem Durchlaufen möglich sind, abgearbeitet wurden.<br />
<br />
==== C<sub>2</sub>c – Strukturierter Pfadüberdeckungstest ====<br />
Im Prinzip wie der C<sub>2</sub>b-Test, nur dass nun die Anzahl der Schleifendurchläufe auf eine vorgegebene natürliche Zahl n reduziert wird.<br />
<br />
'''Vorteil'''<br />
* Hohe Fehlererkennungsrate<br />
<br />
'''Nachteil'''<br />
* nicht ansprechbare Pfade auf Grund von Bedingungen<br />
<br />
==== Beispiel ====<br />
Gegeben sei folgender Kontrollflussgraph:<br />
<br />
[[Datei:Control-flow-graph.svg|400px]]<br />
<br />
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)}.<br />
<br />
=== C<sub>3</sub>. Bedingungsüberdeckungstest (Condition Coverage) ===<br />
[[Datei:C23Ueb.png|mini|Bedingungsüberdeckungstest]]<br />
<br />
Das Problem der bisherigen Überdeckungstests (C<sub>1</sub>-Test, C<sub>2</sub>-Test) ist, dass zusammengesetzte, hierarchische Bedingungen nicht ausreichend getestet werden.<br />
<br />
* [[#Einfachbedingungsüberdeckungstest|C<sub>3</sub>a – Einfachbedingungsüberdeckungstest]]<br />
* [[#Mehrfachbedingungsüberdeckungstest|C<sub>3</sub>b – Mehrfachbedingungsüberdeckungstest]]<br />
* [[#minimaler Mehrfachbedingungsüberdeckungstest|C<sub>3</sub>c – minimaler Mehrfachbedingungsüberdeckungstest]]<br />
* [[#Bewertung|Bewertung]]<br />
<br />
==== {{Anker|Einfachbedingungsüberdeckungstest}} C<sub>3</sub>a – Einfachbedingungsüberdeckungstest ====<br />
Jede atomare Bedingung einer Entscheidung muss einmal mit true und einmal mit false getestet werden. Beispiel:<br />
<br />
<syntaxhighlight lang="java"><br />
boolean a,b;<br />
if(a || b)<br />
{<br />
...<br />
}<br />
</syntaxhighlight><br />
<br />
Eine minimale Testfallmenge, die die Einfachbedingungsüberdeckung erfüllt, ist <code>{(a=false, b=false), (a=true, b=true)}</code>.<br />
<br />
==== {{Anker|Mehrfachbedingungsüberdeckungstest}} C<sub>3</sub>b – Mehrfachbedingungsüberdeckungstest ====<br />
Dieser Test betrachtet alle atomaren Bedingungen einer Bedingung. Wenn n atomare Bedingungen in der Bedingung stehen, dann werden <math>2^n</math> Kombinationen gebildet.<br />
<br />
Das heißt für das obige Beispiel, dass 4 Testfälle gebildet werden.<br />
<br />
==== {{Anker|minimaler Mehrfachbedingungsüberdeckungstest}} C<sub>3</sub>c – minimaler Mehrfachbedingungsüberdeckungstest ====<br />
Diese Version erstellt mehr Testfälle als C<sub>3</sub>a und weniger als C<sub>3</sub>b, indem jede Bedingung (atomar und zusammengestellt) zu true und zu false evaluiert wird. Die logische Struktur wird hierbei berücksichtigt und der C<sub>1</sub>-Test (Zweigüberdeckungstest) ist vollständig in diesem Test enthalten. Ein weiterer Punkt ist, dass der C<sub>3</sub>c-Test berechenbar ist. Im obigen Beispiel wird somit der Testfall <code>{(a=false, b=true)}</code> oder <code>{(a=false, b=false)}</code> gewählt, da andernfalls die logische Struktur bereits bei der ersten Teilbedingung abbricht.<br />
<br />
==== Vorteil ====<br />
* Hohe Fehlererkennungsrate<br />
<br />
==== Nachteil ====<br />
* nicht ansprechbare Pfade auf Grund von Bedingungen<br />
<br />
==== Bewertung ====<br />
* Unvollständige Auswertung einer Bedingung durch eine Programmiersprache mit sog. short circuit evaluation wie zum Beispiel C++, C, Java, C#.<br />
<br />
'''Beispiel:'''<br />
<syntaxhighlight lang="java"><br />
if (a && b)<br />
{<br />
...<br />
}<br />
else<br />
{<br />
// Lies b aus<br />
}<br />
</syntaxhighlight><br />
<br />
Wenn a false ist, dann ist die Belegung der Variable b egal.<br />
Zum Beispiel a=false und b=null, dann passiert ein Fehler im else-Zweig.<br />
<br />
== Zusammenfassung ==<br />
{| style="border:1px solid #000000;"<br />
|-<br />
!<br />
! Kurzname<br />
! erfüllte Bedingung<br />
! Durchführbarkeit<br />
|-<br />
| '''Anweisungsüberdeckungstest'''<br />
| C<sub>0</sub><br />
| jede Anweisung wird mindestens einmal ausgeführt<br />
| relativ einfach<br />
|-<br />
| '''Zweigüberdeckungstest'''<br />
| C<sub>1</sub><br />
| jede Kante im Kontrollflussgraph (KFG) wird mindestens einmal durchlaufen<br />
| realistische Mindestanforderung, vertretbarer Aufwand<br />
|- style="background:#BBBBBB"<br />
| '''Pfadüberdeckungstest'''<br />
| C<sub>2</sub><br />
|<br />
|<br />
|-<br />
| Vollständig<br />
| C<sub>2</sub>a<br />
| Alle möglichen Pfade werden durchlaufen<br />
| unmöglich bei Schleifen<br />
|-<br />
| Boundary-Interior<br />
| C<sub>2</sub>b<br />
| wie C<sub>2</sub>a, Schleifen werden jedoch nach speziellen Regeln durchlaufen<br />
| aufwendig<br />
|-<br />
| Strukturiert<br />
| C<sub>2</sub>c<br />
| wie C<sub>2</sub>b, Schleifen werden jedoch genau n-mal durchlaufen<br />
| aufwendig<br />
|- style="background:#BBBBBB"<br />
| '''Bedingungsüberdeckungstest'''<br />
| C<sub>3</sub><br />
|<br />
|<br />
|-<br />
| Einfachbedingung<br />
| C<sub>3</sub>a<br />
| jede atomare Bedingung wird einmal mit true und false getestet<br />
|<br />
|-<br />
| Mehrfachbedingung<br />
| C<sub>3</sub>b<br />
| jede true/false Kombination der atomaren Bedingungen wird getestet<br />
| sehr hoher Aufwand<br />
|-<br />
| Minimale Mehrfachbedingung<br />
| C<sub>3</sub>c<br />
| jede atomare Bedingung und die Gesamtbedingung wird mit true und false getestet<br />
| hoher Aufwand<br />
|}<br />
<br />
== Bewertung ==<br />
Die Qualität eines Tests hängt entscheidend vom gewählten Test ab: Wurde nur nach C<sub>0</sub> mit Überdeckungsgrad 100 % getestet, so ist dies trotzdem kein verlässlicher Indikator für eine fehlerfreie Software. Wurde hingegen mit C<sub>2</sub> auf 100 % getestet, würde dies ein gutes Kriterium für eine fehlerfreie bzw. -arme Software darstellen. In der Praxis wird dieser Test wegen der [[Kombinatorische Explosion|kombinatorischen Explosion]] nur für [[DO-178B|sicherheitskritische Software]] (zum Beispiel [[Luftfahrt]]) durchgeführt.<br />
<br />
Die zweite wichtige Größe ist 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.<br />
<br />
== Siehe auch ==<br />
* [[Kontrollflussgraph]]<br />
* [[Softwaremetrik]]<br />
* [[Testabdeckung]]<br />
<br />
== Literatur ==<br />
* Helmut Balzert: ''Lehrbuch der Software-Technik.'' Spektrum Verlag 2008, ISBN 978-3-8274-1161-7.<br />
* Andreas Spillner, Tilo Linz: ''Basiswissen Softwaretest.'' dpunkt.Verlag 2005, ISBN 3-89864-358-1.<br />
* Harry M. Sneed, Mario Winter: ''Testen objektorientierter Software.'' Hanser Verlag 2002, ISBN 3-446-21820-3.<br />
* Ernest Wallmüller: ''Software Qualitätssicherung in der Praxis.'' Hanser Verlag 2001, ISBN 3-446-21367-8.<br />
<br />
== Weblinks ==<br />
* [https://christian-grafe.de/wiki/SEII_Kontrollflussorientierte%20Testverfahren.pdf christian-grafe.de] Seminararbeit über die Thematik (Grundlagen dieser Seite; PDF-Datei; 511&nbsp;kB)<br />
* [https://christian-grafe.de/wiki/Vortrag_SE2.ppt christian-grafe.de] PowerPoint-Vortrag über die Verfahren und theoretische Grundlagen<br />
* [https://web.archive.org/web/20160328111201/http://www2.informatik.hu-berlin.de/~hs/Lehre/2004-WS_SWQS/20041124_Ueberdeckung.pdf informatik.hu-berlin.de] Prof. Dr Holger Schlingloff, Fraunhofer Ges., FIRST, "Überdeckungen" (PDF-Datei; 337&nbsp;kB)<br />
* [https://www.bullseye.com/coverage.html bullseye.com] Steve Cornett, "Code Coverage Analysis"<br />
* [http://www.rtca.org/onlinecart/product.cfm?id=202 rtca.org] DO-248B, Final Annual Report For Clarification Of DO-178B “Software Considerations In Airborne Systems And Equipment Certification”<br />
* [https://www.verifysoft.com/Code-Coverage_auf_Embedded-Systemen.pdf verifysoft.com] (PDF; 920&nbsp;kB) Professor Dr. D. Fischer: Code-Coverage auf Embedded Systemen<br />
<br />
[[Kategorie:Testen (Software)]]<br />
[[Kategorie:Software-Metrik]]</div>imported>Invisigoth67