Die Messung der strukturellen Source Code Coverage ist heutzutage in vielen Funktionalen Sicherheitsstandards als ein wichtiges Verfahren definiert. Die Non-intrusive Messung der strukturellen Coverage bietet hier zukünftig ganz neue Möglichkeiten. Lange Zeit war es industrieweiter Konsense dass die strukturelle Coverage nur in sogenannten White-Box-Tests ermittelt werden sollte und konnte. In vielen Lehrbüchern wird die Messung der strukturellen Source Code Coverage sogar als eigenständige Testmethode angepriesen. Im nachfolgenden Blogbeitrag wird aufgezeigt, warum sich hier zukünftig einiges ändern dürfte.

Einführung strukturelle Source Code Coverage:

Zunächst eine kurze Einführung in das Thema strukturelle Source Code Coverage.

Diese ist ein Maß für den Grad der Abdeckung des Source Code durch Tests. Es gibt dabei verschiedene Maße für die Coverage. Meistens beginnt man mit der Abdeckung der ausführbaren Source Code Zeilen. Das bedeutet, wenn jede Zeile Code einmal ausgeführt wurde, dann hat man eine 100% Abdeckung erreicht.

Mit der berühmten MC/DC Coverage weist man nach, dass jeder Parameter innerhalb einer Entscheidung eine Auswirkung auf das Ergebnis der Entscheidung hat. Die minimale Anzahl der dafür notwendigen Testfälle beträgt Anzahl der Variablen in einer Entscheidung + 1.

Nachfolgendes Bild veranschaulicht Testfälle zur Erreichung einer MC/DC Coverage:

Erkenntnisse aus der praktischen Anwendung:

Branchenübergreifend zeigt sich, dass die alleinige Messung der strukturellen Coverage, keine Qualitätsaussage über das Produkt darstellen kann. Dies gilt auch dann wenn 100% strukturelle Coverage gemessen werden kann. Woran liegt das?

Die Rolle der Requirements bei der Messung der strukturellen Coverage:

Tests die nur zum Ziel haben die strukturelle Coverage zu messen, finden kaum Fehler. Zu guten Tests gehört immer auch die Betrachtung des Datenflusses durch eine Software hinzu. Die Praxis zeigt immer deutlicher, dass zum Finden von Fehlern auch Requirements benötigt werden, welche eine funktionale Erwartungshaltung an die Software definieren.

Nur wenn diese beiden Punkte beim Erstellen von Tests berücksichtigt werden, stellt die Messung der strukturellen Coverage eine sinnvolle Qualitätsaussage über die Software dar. Es ist allgemein anerkannt, dass es praktisch unmöglich ist, für ein System vollständige Requirements  und Tests zu erstellen. Die strukturelle Coverage stellt genau für diese methodische Schwachstelle ein sehr effizientes Korrektiv dar. Eine niedrige strukturelle Coverage kann immer nur eine der folgenden 3 Ursachen haben:

1. Die Requirements sind nicht vollständig
2. Die Tests sind nicht vollständig
3. Der nicht abgedeckte Source Code wird gar nicht benötigt

Aus diesem Grund macht es dann aber konsequenter Weise keinen Sinn die strukturelle Source Coverage Messung als eigenständige Testmethode zu behandeln. Die Messung macht immer nur dann Sinn wenn die entsprechenden Tests auf Requirements basieren.

Fazit:

Dies bedeutet für die Zukunft, das reine White-Box-Tests (=Unittestss die nur die strukturelle Source Code Coverage messen) nicht mehr benötigt werden.

D.h. für die meisten Branchen, dass der Druck steigen wird die Coverage auf höheren Testebenen zu messen. In klassischen Embedded Systemen ist dies meist dann die Ebene auf der die Hardware und die Software im Integrationstest geprüft wird. Nur für diese Testebene gibt es meist die notwendigen funktionalen Requirements.

Hier gab es aber bisher meist gar nicht die Technologie um die strukturelle Source Code Coverage mit einem sinnvollen Aufwand auf dieser Ebene zu bestimmen.

Dies wird sich aber in naher Zukunft ändern. Die Technologie und Toolentwicklung zur non-intrusiven Messung der strukturellen Source Code Coverage macht große Fortschritte und wird in den nächsten Jahren nach meiner Prognose die klassische Source Code Instrumentierung ablösen. Damit kann die strukturelle Source Code Coverage eine ganz neue Rolle einnehmen in der sicherheitsrelevanten Software Entwicklung.

Ihre individuellen Fragen zur Funktionalen Sicherheit beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).