Code Coverage leicht gemacht
Sichere Softwareentwicklung im Automotive-Segment
Sicherheit ist bei der Softwareentwicklung im Automotive-Segment eine der wichtigsten Herausforderungen. Softwaretests sind daher unverzichtbarer Bestandteil der Qualitätssicherung. Ohne ausreichende, dokumentierte Tests ist nicht feststellbar, ob eine Software sicher und funktional korrekt ist.
Die Norm ISO 26262 beschreibt in Teil 6 konkrete Anforderungen für Entwurf, Implementierung, Verifizierung und Validierung von Software, um die funktionale Sicherheit zu gewährleisten. Bezüglich der strukturellen Code-Abdeckungsanalyse (Code Coverage) beinhaltet die Norm klare Vorgaben, um die Vollständigkeit der Tests für sicherheitsrelevante Software in Fahrzeugen nachzuweisen. Mithilfe der Code Coverage kann festgestellt werden, wie umfassend eine Software bereits getestet wurde und welche Codeteile noch getestet werden müssen, um die geforderte Abdeckung zu erreichen.
Unterschiedliche Automotive Safety Integrity Level
In welchem Umfang und auf welchem Niveau die Code Coverage verlangt wird, hängt davon ab, wie kritisch das korrekte Verhalten dieser Komponente für die Sicherheit des Fahrzeugs ist. Entsprechend dem Risiko schwerer Unfälle muss jeder Komponente ein sogenanntes Automotive Safety Integrity Level (ASIL) zugeordnet werden.
Haben potenzielle Fehlfunktionen weniger schwere Konsequenzen oder können vom Fahrer leicht kontrolliert werden, werden die Systeme in niedrigere ASIL-Stufen eingeordnet. Die niedrigste ASIL-Stufe ist A. Für diese ist lediglich Statement Coverage vorgeschrieben. Nur für Systeme mit noch geringerem Risiko muss keinerlei Code Coverage nachgewiesen werden.
Ein fehlerhaftes Verhalten einer Komponente mit dem höchsten ASIL D hingegen kann mit hoher Wahrscheinlichkeit zu lebensbedrohlichen oder sogar tödlichen Verletzungen führen, ohne dass der Fahrer die Situation kontrollieren kann. Es verwundert daher nicht, dass die ISO 26262 für diese Sicherheitsstufe mit der Modified Condition/Decision Coverage eine sehr detaillierte und damit herausfordernde Coverage-Stufe verlangt.
Beim Test von sicherheitskritischer Software erscheint die Messung der Codeabdeckung zunächst oft komplex und zeitaufwändig. Bei Embedded-Software kommen weitere Herausforderungen wie begrenzter Speicherplatz hinzu. Werden jedoch einige grundlegende Aspekte beachtet, wird die Code-Coverage-Messung schnell einfacher und bei Nutzung eines geeigneten Tools fast zum Kinderspiel.
Zu beachten ist, dass sich die am Markt befindlichen Code-Coverage-Analyser im Handling und in der Qualität teils deutlich unterscheiden. Die folgenden Kriterien unterstützen bei der Auswahl eines geeigneten Code-Coverage-Tools.
Anforderungen an Code-Coverage-Tools
Auch für Code-Coverage-Analyser gilt: selbst die beste Software wird ungern (und damit selten) genutzt, wenn die Bedienung unnötig kompliziert oder nicht durchdacht ist. Ein einfaches Handling hingegen kann die Akzeptanz für den Einsatz eines Tools zur Messung der Testabdeckung beim Anwender deutlich erhöhen und dabei helfen, Zeit und Kosten zu sparen. Idealerweise läuft das Tool im Hintergrund, ist gegebenenfalls in einen Continuous-Integration-Prozess eingebaut und erzeugt für den Nutzer beim Test keine zusätzliche Arbeit.
Nachvollziehbarkeit der Coverage-Berichte
Die Code-Coverage-Analyse erzeugt meist große Datenmengen, die durch das Coverage-Tool in einer sinnvollen und interpretierbaren Weise aufgearbeitet werden sollten. Die bereitgestellten Informationen müssen dabei sowohl in maschinenlesbarer Form für die weitere automatische Verarbeitung (zum Beispiel XML) als auch in menschenlesbarer Form (beispielsweise HTML) für einen schnellen und guten Überblick zur Verfügung stehen (Bild 1).
Für den Tester oder Qualitätsverantwortlichen sollte beim Betrachten der Coverage-Berichte möglichst auf einen Blick klar werden, welche Teile des Codes bereits getestet sind und wo es noch an Tests fehlt. Bei guten Coverage-Tools kann der Tester auf Quellcodeebene sehr einfach erkennen, welche Testfälle noch ausstehen. Durch das Ausführen dieser fehlenden Tests kann die Code Coverage dann zielgerichtet erhöht werden. Dies vermeidet gleichzeitig unnötige Arbeit, die durch redundante Tests entstehen würde (Bild 2).
Möglichkeit von Justifications
Oft können bestimmte Codeteile – beispielsweise aufgrund defensiver Programmierung – nicht durch Testfälle erreicht werden. Für diesen Fall sollte der Code-Coverage-Analyser die Möglichkeit bieten, fehlende Coverage über sogenannte Justifications zu erklären und zu dokumentieren. Das Tool Testwell CTC++ etwa bietet die Möglichkeit, Justifications über Kommentare direkt im Quellcode zu hinterlegen oder diese alternativ in Dateien außerhalb des Quellcodes zu dokumentieren. In den Coverage-Berichten ist transparent sichtbar, welche Codeteile tatsächlich getestet und welche über Justifications »erklärt« wurden (Bild 3 und Bild 4).
Unterstützung bei »kreativer« Programmierung
Nicht jeder zu untersuchende Code folgt schulbuchmäßig gängigen Standards. Manche Coverage-Tools bekommen Probleme bei der Analyse von Sprachkonstrukten, die von üblichen Standards abweichen oder eine hohe Schachtelungstiefe haben. Ein gutes Tool für die Messung der Testabdeckung sollte jedoch auch mit einem »kreativen« Programmierstil zurechtkommen.
Unabhängigkeit vom eingesetzten Compiler
Selbstverständlich muss ein Code-Coverage-Tool als Grundvoraussetzung mit dem im Projekt eingesetzten Compiler funktionieren. In der Praxis ist es allerdings sehr sinnvoll, bereits von Beginn an auf ein Tool zu setzen, das unabhängig vom Compiler eingesetzt werden kann. Solche Werkzeuge können dann in allen Projekten genutzt werden. Und auch im laufenden Projekt ist bei Bedarf ein – heute vielleicht noch nicht absehbarer – Wechsel des Compilers möglich. Ein Coverage-Tool, das compilerunabhängig nutzbar ist, kann wesentlich vielfältiger und zukunftssicherer verwendet werden und ist daher eine lohnende Investition.
Flexible Integration
Auch innerhalb eines Unternehmens sind Entwicklungsumgebungen und Toolketten oft sehr heterogen. Zudem werden mehr und mehr Tests automatisiert, um Kosten zu senken und Fehlerquellen durch manuelle Aktionen zu vermeiden.
Gerade in großen Entwicklungsprojekten kann auf automatisierte Tests und die automatische Erfassung der Codeabdeckung kaum verzichtet werden. Die Automatisierung des Tests auf dem Build-System ist vor allem in der agilen Entwicklung mit Continuous Integration/Continuous Deployment (CI/CD) erforderlich. Daher muss die Integration des Coverage-Analysers in den jeweiligen Build-Vorgang und in die Durchführung der Tests nahtlos und ohne großen Aufwand möglich sein. Tools wie Testwell CTC++, die auch über die Kommandozeile genutzt werden können, vereinfachen diese Integration und bieten Vorteile bei der Erstellung automatisierter Builds.
Support von höheren Coverage-Maßen / Eignung für sicherheitskritische Entwicklung
Für den Test von sicherheitskritischer Software schreibt die Norm ISO 26262 hohe Coverage-Maße vor, die je nach Sicherheitslevel bis hin zur MC/DC-Coverage reichen. Es ist deshalb zwingend darauf zu achten, dass das auszuwählende Coverage-Tool die jeweils geforderte Coverage-Stufe auch tatsächlich unterstützt.
Um eine Lösung langfristig einsetzen zu können, sollten hierbei nicht nur aktuelle, sondern auch zukünftige, bereits absehbare Anforderungen berücksichtigt werden. Hier ist wichtig zu wissen, dass viele gängige Coverage-Tools maximal Decision- oder Branch-Coverage messen. Für die sicherheitskritische Softwareentwicklung sind sie daher unzureichend.
Im Automotive-Bereich ist je nach ASIL-Stufe Anweisungsüberdeckung (Statement Coverage), Zweigüberdeckung (Branch Coverage) oder MC/DC (Modified Condition/Decision Coverage) erforderlich. Dies geht aus der Tabelle der Norm ISO 26262 hervor (Tabelle 1).
Wie bereits erwähnt, erfordert die höchste Sicherheitsstufe ASIL D mit der MC/DC-Coverage einen sehr hohen Abdeckungsgrad. In der Tabelle steht ++ für »sehr empfehlenswert« und + für »empfohlen«. Eine vollständige MC/DC Coverage impliziert automatisch eine vollständige Branch Coverage. Eine vollständige Branch Coverage wiederum impliziert automatisch eine vollständige Statement Coverage.
Zertifizierung und Qualifizierung
Analog zu den meisten Sicherheitsnormen fordert die ISO 26262, dass die gesamte Werkzeugkette qualifiziert wird. Hier geht es darum, nachzuweisen, dass sowohl der Coverage-Analyser als auch die anderen genutzten Tools innerhalb der gesamten Toolchain zuverlässig funktionieren.
Wenn das Tool zertifiziert ist (beispielsweise durch den TÜV), kann es in der Regel ohne weitere Qualifizierungsmaßnahmen für die sicherheitskritische Software-Entwicklung für alle ASIL-Stufen genutzt werden.
Spezielle Anforderungen für die Entwicklung von Embedded-Software
Für Software eingebetteter Geräte steht in der Regel nur wenig Speicherplatz zur Verfügung. Auch haben die Prozessoren aus Kostengründen oft Einschränkungen. Hierdurch ergeben sich bezüglich der Code-Coverage-Messung besondere Herausforderungen, die bei der Auswahl eines Coverage-Analysers zu berücksichtigen sind.
Geringer Instrumentation-Overhead
Die meisten Coverage-Tools messen die Code Coverage über die Instrumentierung des Quellcodes. Der Quellcode wird dabei durch das Coverage-Tool mit »Zählern« angereichert, die mitzählen, wo und wie oft die betreffenden Codeteile beim Testen ausgeführt wurden.
Zudem muss auf dem zu testendem Target eine Bibliothek implementiert werden, die unter anderem den Datentransfer zu einem Host übernimmt. Auch hierdurch wird der originale Code vergrößert. Da embedded Targets nur über beschränkten Speicherplatz verfügen, ist darauf zu achten, dass der durch den Coverage-Analyser benötigte Overhead möglichst gering bleibt.
Die Unterschiede bezüglich des Speicherbedarfs sind bei den einzelnen Code-Coverage-Tools teilweise beträchtlich. Der Code-Coverage-Analyser Testwell CTC++ ist in dieser Hinsicht sehr ressourcenschonend und bietet zudem die Möglichkeit, durch kleinere Zähler den Speicherplatz nochmals spürbar zu reduzieren. Das sogenannte Bit-Coverage-Feature reduziert die Zählergröße von 32 Bit auf 16 oder 8 Bit, misst dann allerdings nicht mehr, wie oft ein Codeteil getestet wurde, sondern nur noch, ob es überhaupt getestet wurde. Dies ist zur Erfüllung der Anforderungen der Normen ausreichend. Sollte der Instrumentierungs-Overhead dennoch zu hoch sein, kann die Codeabdeckung separat für einzelne Codeteile analysiert werden (partielle Instrumentierung).
Mögliche Auswirkungen auf den Prozessor prüfen
Um Kosten zu sparen, sind nicht nur die Speicher vieler eingebetteter Geräte klein – auch die Prozessoren haben oft Einschränkungen. Leider wirkt sich die Instrumentierung auch auf den Prozessor aus. So kann es in einigen Fällen vorkommen, dass das definierte Timing überschritten wird, was unter Umständen zu fehlerhaften Programmabläufen führen kann.
Aus diesem Grund sollten Code-Coverage-Analyser auch im Hinblick auf ihre Auswirkungen auf das Timing evaluiert werden. Das oben genannte Bit-Coverage-Feature kann auch hier Abhilfe schaffen. Ebenfalls ist es sinnvoll, die Tests einmal mit und einmal ohne Abdeckungsanalyse durchzuführen, um sicherzustellen, dass die Messung der Coverage nicht zu Änderungen des Programmverhaltens geführt hat.
Fazit
Für die sicherheitskritische Softwareentwicklung ist Code Coverage aus gutem Grund vorgeschrieben. Aber auch für alle, die ihre Softwarequalität generell verbessern wollen, ist die Messung der Testabdeckung eine gute Methode, um die Qualität und Aussagekraft von Softwaretests zu messen und zu erhöhen.
Bei der Auswahl eines Code-Coverage-Analysers muss darauf geachtet werden, dass das Werkzeug den gestellten Anforderungen entspricht. Zudem spielen Faktoren wie einfache Benutzung und professionelle Unterstützung bei Rückfragen und im Supportfall eine wichtige Rolle.
Die Eignung eines Coverage-Tools für die eigenen Projekte sollte auf jeden Fall im Rahmen einer Tool-Evaluation überprüft werden. Bereits hier wird man auch einen Eindruck von der Leistungsfähigkeit des technischen Supports bekommen. Nicht zuletzt empfiehlt sich auch ein Blick auf die Kundenreferenzen des Herstellers. Richtig eingesetzt, hilft ein gutes Testabdeckungstool dabei, die Qualität deutlich zu verbessern, die Motivation von Entwicklern und Testern zu erhöhen und Tests kostensparend durchzuführen.
Zusatzinfos: Die von der ISO 26262 geforderte Coverage-Stufen im Überblick
Es gibt zahlreiche unterschiedliche Testabdeckungsgrade. Allgemein gilt dabei: Je strenger und detaillierter ein Testabdeckungsgrad ist, desto größer ist der erforderliche Aufwand. Entsprechend steigen damit auch die Kosten. Auf Unit-Test-Level gibt die Norm je nach ASIL Statement-, Branch- oder MC/DC (Modified Condition/Decision Coverage) vor. Für Integrations-Tests verlangt die Norm, dass auf Software-Architektur-Level Function Coverage oder Call Coverage nachgewiesen werden. In der Praxis wird diese Anforderung oft durch Nutzung der für den Unit-Test vorgeschriebenen Coveragestufen abgedeckt.
Function Coverage
Die Funktionsabdeckung (Function Coverage) zeigt den prozentualen Anteil der Anzahl der Funktionen (Unterprogramme), die aufgerufen bzw. getestet wurden. Trotz der phonetischen Ähnlichkeit ist die Function Coverage von der funktionalen Coverage zu unterscheiden, bei der mit Black-Box-Tests nachgewiesen werden soll, dass jedes Merkmal der Software wie vorgesehen funktioniert.
Call Coverage
Während die Function Coverage zeigt, ob jede Funktion in einem Programm während des Tests überhaupt aufgerufen wurde, werden bei der Aufrufabdeckung (Call Coverage) alle möglichen Funktionsaufrufe berücksichtigt.
Statement Coverage
Die Anweisungsabdeckung zeigt, welche Anweisungen von den Tests ausgeführt wurden. Bei diesem Coverage-Level kann auch »toter Code« erkannt werden.
Decision Coverage / Branch Coverage
Bei diesem Abdeckungsgrad muss jede Entscheidung mindestens einmal als wahr und einmal als falsch getestet werden. Bei normalen if-Anweisungen heißt das, dass jede Verzweigung ausgeführt worden sein muss.
Multicondition Coverage und Modified Condition/Decision Coverage (MC/DC)
Bei der Multicondition Coverage müssen alle möglichen Wahr-Falsch-Kombinationen für zusammengesetzte Entscheidungen geprüft werden. Im Falle mehrerer Bedingungen innerhalb einer Entscheidung erfordert dies meist eine unpraktikabel hohe Anzahl von Testfällen. Daher ist in der Praxis und in den Normen die Modifizierte Bedingungs-/Entscheidungsabdeckung (MC/DC, Modified Condition/Decision Coverage) relevant, bei der die Anzahl der Testfälle reduziert wird und die Aussagekraft der Testabdeckung ausreichend hoch bleibt. Für MC/DC werden alle atomaren Bedingungen einer zusammengesetzten Bedingung verwendet. Für jede atomare Bedingung wird ein Testfallpaar getestet, das zur Änderung des Gesamtergebnisses der zusammengesetzten Bedingung führt, wobei sich aber nur der Wahrheitswert der betrachteten atomaren Bedingung ändert, während der Wahrheitswert der anderen atomaren Bedingungen konstant bleiben muss. In der Praxis wird hiermit der gleiche Zweck wie bei der Multicondition Coverage erzielt – allerdings mit weniger Testfällen.
Der Autor
Klaus Lambertz
ist Gründer und Geschäftsführer von Verifysoft Technology, einer in Offenburg ansässigen Entwicklungsfirma für Softwaretesttools. Hauptprodukt ist der Code-Coverage-Analyser Testwell CTC++, der erfolgreich in zahlreichen sicherheitskritischen Softwareprojekten in 45 Ländern weltweit eingesetzt wird. Zusätzlich bietet Verifysoft Tools für die statische Codeanalyse und für Security an.
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Sicherer dank Rust, effizienter dank KI
Perforce zeigt Embedded-Zukunftstechnologien
dSpace auf der embedded world 2026
Automatisierte Testlösungen beschleunigen die Entwicklung
Robuste Verifikation und Validierung
Tasking-Toolchain unterstützt agentenbasierte KI-Workflows
Bridgestone
Virtuelle Reifenentwicklung mit Driver-in-the-Loop-Simulator
