Deutsche BlogsFunktionale Sicherheit

Strukturelle Source Code Überdeckung – Aufwand ohne Nutzen?

Strukturelle Source Code Überdeckung: Sie arbeiten in Software Projekten in denen das Thema Funktionale Sicherheit immer wichtiger wird? Die Anwendung von IEC 61508, ISO 26262 oder einer vergleichbaren Norm steht vor der Tür oder Sie befinden sich bereits mitten in so einem Projekt? In diesen Fällen ist Ihnen vermutlich der Begriff Strukturelle Source Code Coverage auch schon begegnet. Viele setzen die Erreichung der strukturellen Coverage oft gleich mit sehr hohem Testaufwand und sie bezweifeln, ob bei diesem Thema Kosten und Nutzen in einem angemessenen Verhältnis stehen.

Was bedeutet die strukturelle Source Code Überdeckung

Man unterscheidet in der sicherheits relevanten Software Entwicklung grundsätzlich zwischen zwei Arten von Überdeckung (Coverage). Die funktionalen bzw. Requirements Coverage beschreibt wieviele Requirements durch Tests nachgwiesen sind. Aufgrund der meist natürlichsprachlichen Requirements und Testfallbeschreibungen lassen sich hier keine mathematisch exakten Angaben machen.

Dies ist bei der strukturellen Source Code Coverage anders. Hier wird gemessen wieviel des Source Codes durch Tests nachgewiesen ist. Software Tools ermitellen die Source Code Überdeckung eindeutig, da sie auf mathematischen Regeln beruht.

Idealerweise wird die Source Code Coverage immer bei Requirements basierten Tests ermittelt. Dadurch kann dann die Source Code Coverage als Qualitätsmaßzahl für die Requirements und Tests verwendet werden.

Häufige Fehler bei der Ermittlung der Source Code Überdeckung

In der Praxis machen viele oft folgende beide Fehler:

  1. Die Ermittlung der Gesamtüberdeckung wird falsch über die einzelnen Testebenen verteilt.
  2. Die Messung der Source Code Überdeckung ist nicht vollständig automatisiert

Es Bedarf einiges an Erfahrung um die Ermittlung der Coverage richtig auf die Testebenen zu verteilen. Meist wird die Coverage ausschließlich auf Unit Test Ebene ermittelt. Dies hat den großen Nachteil, dass die Verbindung der Tests zu den funktionalen Software Requirements gering ist.

Wenn man dagegen versucht, die Gesamte Source Code Coverage auf Integrations oder Systemebene zu erreichen, steigt der Testaufwand nahezu exponentiell an, für die letzten 20% der Coverage.

Für eine vollständige Automatisierung der Source Code Coverage, fehlt oft die Sorgfalt bei der Erstellung der Testumgebungen. Wenn nicht frühzeitig begonnen wird die Testumgebung sorgfältig zu planen und aufzubauen, leidet meist auch auch die Automatisierung der Coverage Messung. Dies wiederum führt dann in  vielen Projekten dazu, dass die Coverage nur ein einziges mal ganz am Projektende gemessen wird.

Folgendes Bild stellt eine Verbindung her zwischen den Testebenen und der auf eine effiziente Weise erzielbare strukturelle Coverage:

Source Code Überdeckung

Vorteile wenn man die Source Code Coverage zielgerichtet ermittelt

Eine gute Vorgehensweise ist die Coverage zu messen die durch die ohnehin vorhandenen funktionalen Tests auf HW/SW oder SW/SW Integrationsebene erreicht wird. Dies sind erfahrungsgemäß oft 50% bis 80%. Durch gutes Projektmanagement ist es dann oft möglich auf Unit-Testebene nur noch die verbleibenden 20% bis 50% zu testen. Ziel sollte sein das die Erreichung der Coverage zu keinem zusätzlichen Testaufwand führt, bzw. die Coverage Messung soll dazu eingesetz werden um Lücken in den Requirements und den funktionalen Tests zu identifizieren.

Wenn dann die Coverage Messung insbesondere auf der Integrationstestebene vollständig automatisiert ist, entstehen praktisch keine zusätzlichen Kosten. Dadurch kann der Einsatz der Coverage Messung sogar für Projekte interessant sein, die keine Norm der Funktionalen Sicherheit erfüllen müssen.

Weitere HEICON Blog Beiträge zum Thema

Gerne unterstütze ich Sie auch bei individuellen Fragen zu Ihrem Projekt. Senden Sie eine Mail an: info[at]heicon-ulm.de
Einen unverbindlichen Überblick über die Leistungen finden sie auch auf der HEICON Homepage.