{"id":1767,"date":"2026-04-08T11:49:39","date_gmt":"2026-04-08T11:49:39","guid":{"rendered":"https:\/\/www.pickplace.de\/?post_type=glossary&#038;p=1767"},"modified":"2026-04-08T14:39:02","modified_gmt":"2026-04-08T14:39:02","slug":"code-coverage","status":"publish","type":"glossary","link":"https:\/\/www.pickplace.de\/en\/glossar\/code-coverage\/","title":{"rendered":"Code Coverage"},"content":{"rendered":"<p><strong>Code Coverage<\/strong> bezeichnet den messbaren Anteil eines Programmcodes, der durch Tests tats&#xE4;chlich ausgef&#xFC;hrt wird. Der Begriff stammt aus der Software-Qualit&#xE4;tssicherung und ist vor allem in der Verifikation und Validierung von Software relevant. In der Embedded-Entwicklung hat Code Coverage jedoch eine deutlich gr&#xF6;&#xDF;ere praktische Bedeutung als in vielen klassischen IT-Anwendungen, weil hier Software direkt mit physischer Hardware, sicherheitsrelevanten Funktionen und oft schwer zug&#xE4;nglichen Fehlerszenarien verbunden ist.<\/p>\n\n\n\n<div class=\"wp-block-rank-math-toc-block\" id=\"rank-math-toc\"><h2>Inhalt<\/h2><nav><ul><li class=\"\"><a href=\"#wozu-braucht-man-code-coverage\">Wozu braucht man Code Coverage?<\/a><\/li><li class=\"\"><a href=\"#code-coverage-fur-embedded-systems\">Code Coverage f&#xFC;r Embedded Systems<\/a><\/li><li class=\"\"><a href=\"#sicherheitskritische-elektronik\">Sicherheitskritische Elektronik<\/a><\/li><li class=\"\"><a href=\"#bedeutung-von-code-coverage\">Bedeutung von Code Coverage<\/a><ul><li class=\"\"><a href=\"#sichtbarkeit-fur-ungetesteten-code\">Sichtbarkeit f&#xFC;r ungetesteten Code<\/a><\/li><li class=\"\"><a href=\"#nachweis-fur-fehlerbehandlung-und-robustheit\">Nachweis f&#xFC;r Fehlerbehandlung und Robustheit<\/a><\/li><li class=\"\"><a href=\"#bessere-testpriorisierung\">Bessere Testpriorisierung<\/a><\/li><li class=\"\"><a href=\"#4-unterstutzung-bei-refactoring-und-portierung\">Unterst&#xFC;tzung bei Refactoring und Portierung<\/a><\/li><li class=\"\"><a href=\"#5-unterstutzung-fur-safety-und-security\">Unterst&#xFC;tzung f&#xFC;r Safety und Security<\/a><\/li><li class=\"\"><a href=\"#reduktion-von-scheinsicherheit\">Reduktion von Scheinsicherheit<\/a><\/li><\/ul><\/li><li class=\"\"><a href=\"#bewertung-und-metriken\">Bewertung und Metriken<\/a><\/li><li class=\"\"><a href=\"#zusammenfassung\">Zusammenfassung<\/a><\/li><\/ul><\/nav><\/div>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"wozu-braucht-man-code-coverage\">Wozu braucht man Code Coverage?<\/h2>\n\n\n\n<p>Code Coverage beantwortet im Kern die Frage: Welche Teile des Codes wurden durch meine Tests wirklich erreicht? Dabei geht es nicht darum, ob der Test &#x201E;bestanden&#x201C; wurde, sondern ob bestimmte Anweisungen, Verzweigungen, Bedingungen oder Pfade &#xFC;berhaupt ausgef&#xFC;hrt wurden.<\/p>\n\n\n\n<p>Typische Arten von Code Coverage sind:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Statement Coverage<\/strong><br>Misst, welche einzelnen Anweisungen mindestens einmal ausgef&#xFC;hrt wurden.<\/li>\n\n\n\n<li><strong>Branch Coverage<\/strong><br>Misst, ob beide Richtungen einer Verzweigung getestet wurden, also beispielsweise <code>if<\/code> und <code>else<\/code>.<\/li>\n\n\n\n<li><strong>Condition Coverage<\/strong><br>Misst, ob einzelne logische Teilbedingungen innerhalb komplexer Ausdr&#xFC;cke jeweils wahr und falsch waren.<\/li>\n\n\n\n<li><strong>Path Coverage<\/strong><br>Betrachtet vollst&#xE4;ndige Ausf&#xFC;hrungspfade durch den Code. Diese Form ist sehr aufwendig, da die Anzahl m&#xF6;glicher Pfade schnell stark ansteigt.<\/li>\n\n\n\n<li><strong>Function Coverage<\/strong><br>Misst, welche Funktionen &#xFC;berhaupt durch Tests aufgerufen wurden.<\/li>\n<\/ul>\n\n\n\n<p>In vielen Projekten wird Code Coverage als Prozentwert angegeben: &#x201E;85 % Statement Coverage&#x201C; oder &#x201E;100 % Branch Coverage&#x201C;. Dieser Wert wirkt auf den ersten Blick eindeutig, ist aber allein noch kein Qualit&#xE4;tsbeweis. Hohe Coverage bedeutet nicht automatisch gute Tests. Sie zeigt nur, dass viel Code ausgef&#xFC;hrt wurde. Ob dieser Code mit sinnvollen Eingaben, realistischen Fehlerf&#xE4;llen und plausiblen Grenzwerten getestet wurde, ist eine andere Frage.<\/p>\n\n\n\n<div class=\"wp-block-stackable-image stk-block-image stk-block stk-fa0bbe9\" data-block-id=\"fa0bbe9\"><style>.stk-fa0bbe9 .stk-img-figcaption{text-align:center !important;font-style:italic !important;}.stk-fa0bbe9 .stk-img-wrapper{width:60% !important;}<\/style><figure><span class=\"stk-img-wrapper stk-image--shape-stretch\"><img loading=\"lazy\" decoding=\"async\" class=\"stk-img wp-image-1768\" src=\"https:\/\/www.pickplace.de\/wp-content\/uploads\/2026\/04\/branch_coverage.jpg\" width=\"60\" height=\"300\" alt=\"Code Coverage und Branch Coverage bei Embedded Systems Projekten\"\/><\/span><figcaption class=\"stk-img-figcaption\">Typisches Beispiel f&#xFC;r Dead Code<\/figcaption><\/figure><\/div>\n\n\n\n<p>Gerade deshalb wird Code Coverage oft missverstanden. Sie ist kein Beweis f&#xFC;r Fehlerfreiheit. Code Coverage ist ein Analysewerkzeug, um blinde Flecken im Testsystem, zum Beispiel in Form von Dead Code sichtbar zu machen. Wenn bestimmte Codeteile nie ausgef&#xFC;hrt werden, dann existiert dort faktisch keine Testaussage. Ohne Coverage-Messung bleibt das in vielen Projekten unbemerkt.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"code-coverage-fur-embedded-systems\">Code Coverage f&#xFC;r Embedded Systems<\/h2>\n\n\n\n<p>F&#xFC;r Embedded-Systeme ist Code Coverage besonders wichtig, weil dort mehrere Randbedingungen zusammenkommen, die Tests erschweren:<\/p>\n\n\n\n<p>Erstens ist Embedded-Software h&#xE4;ufig eng an reale Hardware gekoppelt. Ein Teil des Codes reagiert auf Interrupts, Timer, DMA, Peripherieregister, Kommunikationsframes oder Fehlerzust&#xE4;nde externer Bauteile. Solche Situationen treten im normalen Funktionstest oft nicht vollst&#xE4;ndig oder nur zuf&#xE4;llig auf. Ohne Coverage-Auswertung bleibt unklar, ob diese Abschnitte jemals getestet wurden.<\/p>\n\n\n\n<p>Zweitens enthalten Embedded-Systeme oft viele Ausnahme- und Fallback-Pfade. Dazu geh&#xF6;ren Watchdog-Reaktionen, Fehlerbehandlung bei Kommunikationsabbr&#xFC;chen, Spannungsprobleme, Speicherfehler, Timeouts, ung&#xFC;ltige Sensordaten oder Startprobleme im Bootprozess. Diese Pfade sind im Alltag gerade deshalb selten sichtbar, weil sie nur unter St&#xF6;rbedingungen aktiviert werden. Aus Sicherheits- und Zuverl&#xE4;ssigkeitssicht sind sie aber oft wichtiger als der nominale Hauptpfad. Code Coverage hilft hier zu pr&#xFC;fen, ob solche Fehlerbehandlungsmechanismen &#xFC;berhaupt einmal bewusst ausgel&#xF6;st und getestet wurden.<\/p>\n\n\n\n<p>Drittens sind Embedded-Produkte h&#xE4;ufig langlebig und werden in industriellen, mobilen, sicherheitsbezogenen oder rauen Umgebungen betrieben. Fehler zeigen sich dann nicht nur als Absturz einer Anwendung, sondern m&#xF6;glicherweise als Stillstand eines Ger&#xE4;ts, fehlerhafte Messwerte, Kommunikationsausfall oder gef&#xE4;hrlicher Systemzustand. In solchen Umgebungen reicht ein oberfl&#xE4;chlicher Funktionstest nicht aus. Die Frage, welche Teile des Codes tats&#xE4;chlich verifiziert wurden, wird damit zu einer technischen und oft auch regulatorischen Notwendigkeit.<\/p>\n\n\n\n<p>Viertens ist die Beobachtbarkeit bei Embedded-Systemen oft schlechter als bei PC- oder Cloud-Software. Es gibt meist kein vollst&#xE4;ndiges Logging, keine komfortable Runtime-Inspektion und keine einfache Reproduzierbarkeit aller Zust&#xE4;nde. Coverage-Messung schafft hier eine zus&#xE4;tzliche Ebene von Transparenz. Sie zeigt, was w&#xE4;hrend eines Tests auf dem Target oder in der Testumgebung wirklich passiert ist.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"sicherheitskritische-elektronik\">Sicherheitskritische Elektronik<\/h2>\n\n\n\n<p>Ein weiterer wichtiger Punkt ist die Rolle von Code Coverage in regulierten oder sicherheitskritischen Entwicklungsprozessen. In Bereichen wie Automotive, Railway, Aerospace, Industrial Safety oder Medizintechnik wird Testabdeckung oft nicht nur technisch, sondern auch prozessual bewertet. Dort dient Coverage als Nachweis, dass Anforderungen und Implementierung systematisch &#xFC;berpr&#xFC;ft wurden. Besonders relevant wird das in Verbindung mit Standards und Methoden wie struktureller Coverage, MC\/DC oder anforderungsspezifischer Testfallableitung.<\/p>\n\n\n\n<p>Im Embedded-Kontext wird h&#xE4;ufig zwischen Tests auf verschiedenen Ebenen unterschieden:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Unit Tests auf Host oder Target<\/li>\n\n\n\n<li>Integrationstests mit realen Schnittstellen<\/li>\n\n\n\n<li>Hardware-nahe Tests<\/li>\n\n\n\n<li>Systemtests<\/li>\n\n\n\n<li>Fehlereinbringung oder Robustheitstests<\/li>\n<\/ul>\n\n\n\n<p>Code Coverage kann auf all diesen Ebenen unterschiedlich wertvoll sein. Ein <a class=\"glossaryLink\"  aria-describedby=\"tt\"  data-cmtooltip=\"cmtt_0f328b362ff3e56020704e84828b6729\"  href=\"https:\/\/www.pickplace.de\/glossar\/unit-test\/\"  data-gt-translate-attributes='[{\"attribute\":\"data-cmtooltip\", \"format\":\"html\"}]' tabindex='0' role='link'>Unit Test<\/a> erreicht oft gute Coverage in isolierten Modulen, w&auml;hrend hardwareabh&auml;ngige Zust&auml;nde dort gar nicht abgebildet werden. Ein Systemtest deckt reale Abl&auml;ufe besser ab, erreicht aber oft weniger gezielt bestimmte seltene Zweige. Deshalb ist Coverage besonders n&uuml;tzlich, wenn sie nicht isoliert betrachtet wird, sondern als Kombination aus mehreren Testebenen. <\/p>\n\n\n\n<p>Mehr zur Code Coverage im sicherheitskritischen Kontext <a href=\"https:\/\/www.linkedin.com\/pulse\/das-am-meisten-missverstandene-thema-des-software-code-heininger-iohrf\/\" target=\"_blank\" rel=\"noopener\">in diesem Beitrag von Martin Heininger<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"bedeutung-von-code-coverage\">Bedeutung von Code Coverage<\/h2>\n\n\n\n<p>Warum ist Code Coverage nun konkret wichtig in Embedded-Projekten?<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"sichtbarkeit-fur-ungetesteten-code\">Sichtbarkeit f&#xFC;r ungetesteten Code<\/h3>\n\n\n\n<p>In gewachsenen Embedded-Codebasen gibt es oft alte Funktionen, Legacy-Routinen, Sonderf&#xE4;lle oder defensive Programmteile, die niemand mehr aktiv betrachtet. Coverage macht sichtbar, welche Teile zwar im Build enthalten sind, aber nie getestet werden. Das ist insbesondere bei portierter Software, Plattformwechseln oder langen Produktzyklen relevant.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"nachweis-fur-fehlerbehandlung-und-robustheit\">Nachweis f&#xFC;r Fehlerbehandlung und Robustheit<\/h3>\n\n\n\n<p>Die interessantesten Bugs sitzen oft nicht im nominalen Hauptpfad, sondern in Sonderf&#xE4;llen. Coverage zeigt, ob Recovery-Strategien, Fehlerflags, Retry-Mechanismen, Timeout-Handling oder Safe-State-&#xDC;berg&#xE4;nge &#xFC;berhaupt getestet wurden.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"bessere-testpriorisierung\">Bessere Testpriorisierung<\/h3>\n\n\n\n<p>Wenn Coverage-Daten vorliegen, lassen sich Testl&#xFC;cken gezielt schlie&#xDF;en. Statt weitere beliebige Tests zu schreiben, kann das Team gezielt auf nicht erreichte Verzweigungen, Bedingungen oder Funktionen schauen.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"4-unterstutzung-bei-refactoring-und-portierung\">Unterst&#xFC;tzung bei Refactoring und Portierung<\/h3>\n\n\n\n<p>Gerade bei Embedded-<a href=\"https:\/\/www.pickplace.de\/portierungen-und-refactoring\/\" data-type=\"page\" data-id=\"1313\">Portierungen<\/a> auf neue <a class=\"glossaryLink\"  aria-describedby=\"tt\"  data-cmtooltip=\"cmtt_d983cf127120ee60c83537d13641bc54\"  href=\"https:\/\/www.pickplace.de\/glossar\/mikrocontroller\/\"  data-gt-translate-attributes='[{\"attribute\":\"data-cmtooltip\", \"format\":\"html\"}]' tabindex='0' role='link'>Mikrocontroller<\/a>, RTOS-Versionen, Compiler oder Hardwareplattformen ist Coverage wertvoll. Sie hilft zu beurteilen, ob die bestehende Testbasis den relevanten Code nach der Umstellung weiterhin erreicht oder ob wichtige Pfade verloren gegangen sind.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"5-unterstutzung-fur-safety-und-security\">Unterst&#xFC;tzung f&#xFC;r Safety und Security<\/h3>\n\n\n\n<p>Auch wenn Coverage allein weder Safety noch Security garantiert, ist sie ein wichtiges Fundament. Sicherheitsrelevante Plausibilit&#xE4;tspr&#xFC;fungen, Rechtepr&#xFC;fungen, Secure-Boot-Entscheidungen, Fehlerreaktionen oder Kommunikationsvalidierungen sollten nicht nur vorhanden sein, sondern im Test nachweislich ausgef&#xFC;hrt werden.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"reduktion-von-scheinsicherheit\">Reduktion von Scheinsicherheit<\/h3>\n\n\n\n<p>Viele Projekte haben umfangreiche Testsuiten und trotzdem gro&#xDF;e L&#xFC;cken. Ohne Coverage entsteht leicht der Eindruck, &#x201E;viel getestet&#x201C; zu haben. Coverage zwingt zu einer n&#xFC;chternen Betrachtung: Was wurde tats&#xE4;chlich ausgef&#xFC;hrt und was nicht?<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"bewertung-und-metriken\">Bewertung und Metriken<\/h2>\n\n\n\n<p>Besonders wichtig ist die Unterscheidung zwischen guter und schlechter Nutzung von Coverage. Schlechte Nutzung bedeutet, nur auf eine Zielzahl zu optimieren, etwa &#x201E;wir brauchen 90 %&#x201C;. Das f&#xFC;hrt oft dazu, triviale Tests zu schreiben, die nur Zeilen ber&#xFC;hren, aber kaum Aussagekraft haben. Gute Nutzung bedeutet, Coverage als Diagnoseinstrument zu verwenden: Welche sicherheitsrelevanten, fehlerkritischen oder hardwareabh&#xE4;ngigen Teile sind noch ungetestet? Wo fehlen gezielte Negativtests? Welche Branches wurden nie erreicht?<\/p>\n\n\n\n<p>In Embedded-Systemen treten au&#xDF;erdem technische Herausforderungen bei der Coverage-Messung selbst auf. Anders als bei Desktop-Software l&#xE4;uft der Code oft auf Mikrocontrollern mit begrenztem Speicher, eingeschr&#xE4;nkter Laufzeitbeobachtung oder harter Echtzeitanforderung. Instrumentierung f&#xFC;r Coverage kann Timing ver&#xE4;ndern, Speicher verbrauchen oder bestimmte Effekte verf&#xE4;lschen. Deshalb muss immer bewertet werden, wo und wie Coverage gemessen wird:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>auf dem Host in einer simulierten Umgebung,<\/li>\n\n\n\n<li>auf dem realen Target,<\/li>\n\n\n\n<li>mit Compiler-Instrumentierung,<\/li>\n\n\n\n<li>&#xFC;ber Trace-Hardware,<\/li>\n\n\n\n<li>oder in Kombination verschiedener Methoden.<\/li>\n<\/ul>\n\n\n\n<p>Jede Methode hat Grenzen. Host-basierte Tests sind schneller und leichter automatisierbar, bilden aber Registerzugriffe, Interrupt-Timing oder Hardwarefehler oft nur unvollst&#xE4;ndig ab. Target-basierte Messungen sind realit&#xE4;tsn&#xE4;her, aber aufwendiger und teurer. F&#xFC;r viele Embedded-Projekte ist deshalb ein hybrider Ansatz sinnvoll.<\/p>\n\n\n\n<p>Ein weiterer Aspekt: Nicht jeder Code sollte gleich bewertet werden. In Embedded-Projekten gibt es oft Abschnitte, die schwer oder nur indirekt testbar sind, etwa Start-up-Code, Compiler-Generated Code, Hardware-Abstraction-Layer, Exception-Handler, Bootloader-Teile oder Diagnosepfade unter seltenen Hardwarefehlern. Diese Teile d&#xFC;rfen nicht einfach ignoriert werden, aber sie erfordern oft eine separate Begr&#xFC;ndung. Gute Entwicklungsprozesse dokumentieren deshalb auch, warum bestimmte Bereiche nicht oder nur eingeschr&#xE4;nkt durch Coverage erfasst wurden.<\/p>\n\n\n\n<p>Im sicherheitsbezogenen Umfeld wird h&#xE4;ufig auch von struktureller Coverage gesprochen. Gemeint ist dann die systematische Analyse, welche Strukturen des Programms durch Tests aktiviert wurden. Je nach Standard k&#xF6;nnen unterschiedliche Anforderungen gelten. Besonders bekannt ist in diesem Zusammenhang MC\/DC (Modified Condition\/Decision Coverage), bei der nachgewiesen werden soll, dass einzelne Bedingungen innerhalb einer Entscheidung den Ausgang unabh&#xE4;ngig beeinflussen k&#xF6;nnen. Das ist vor allem bei sicherheitskritischer Logik relevant, etwa in Schutzfunktionen, Zustandsautomaten oder Freigabemechanismen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"zusammenfassung\">Zusammenfassung<\/h2>\n\n\n\n<p>Code Coverage ist kein Selbstzweck und keine Kennzahl f&#xFC;r Management-Folien allein. In der Embedded-Entwicklung ist sie vor allem deshalb wertvoll, weil sie die L&#xFC;cke zwischen vorhandenen Tests und tats&#xE4;chlich ausgef&#xFC;hrtem Code sichtbar macht. Sie zeigt nicht, ob ein Produkt gut ist, aber sie zeigt sehr klar, wo noch keine belastbare Testaussage existiert.<\/p>\n\n\n\n<p><strong>Code Coverage ist ein Werkzeug zur Bewertung der Testabdeckung auf Code-Ebene.<\/strong> Sie hilft, ungetestete Anweisungen, Verzweigungen, Bedingungen und Fehlerpfade sichtbar zu machen. In Embedded-Systemen ist sie besonders wichtig, weil dort hardwareabh&#xE4;ngige Zust&#xE4;nde, Ausnahmef&#xE4;lle, Recovery-Mechanismen und sicherheitsrelevante Funktionen oft nicht automatisch durch Standardtests erreicht werden.<\/p>\n\n\n\n<p>F&#xFC;r die Elektronik- und Embedded-Entwicklung bedeutet das konkret: Wer nur den Normalbetrieb testet, testet oft gerade nicht die Stellen, an denen Systeme im Feld scheitern. Code Coverage macht diese L&#xFC;cken sichtbar und ist deshalb ein zentrales Werkzeug f&#xFC;r robuste Software, nachvollziehbare Verifikation und belastbare Entwicklungsprozesse.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Code Coverage bezeichnet den messbaren Anteil eines Programmcodes, der durch Tests tats\u00e4chlich ausgef\u00fchrt wird. Der Begriff stammt aus der Software-Qualit\u00e4tssicherung und ist vor allem in der Verifikation und Validierung von Software relevant. In der Embedded-Entwicklung hat Code Coverage jedoch eine deutlich gr\u00f6\u00dfere praktische Bedeutung als in vielen klassischen IT-Anwendungen, weil hier Software direkt mit physischer [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"menu_order":0,"template":"","meta":{"footnotes":""},"class_list":["post-1767","glossary","type-glossary","status-publish","hentry"],"blocksy_meta":[],"_links":{"self":[{"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/glossary\/1767","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/glossary"}],"about":[{"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/types\/glossary"}],"author":[{"embeddable":true,"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/users\/1"}],"version-history":[{"count":2,"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/glossary\/1767\/revisions"}],"predecessor-version":[{"id":1770,"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/glossary\/1767\/revisions\/1770"}],"wp:attachment":[{"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/media?parent=1767"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}