Strukturelle Source Code Coverage: Wenn Sie neu in dem Bereich der Funktionalen Sicherheit tätig sind, dann werden Ihnen die Begriffe strukturelle Source Code Coverage und Requirements ziemlich schnell begegnen. Die Spezifikation von technischen Systemen mittels Requirements ist natürlich auch im nicht sicherheitskritischen Bereich sehr verbreitet. Dagegen spielt das Thema strukturelle Source Code Coverage außerhalb der Sicherheitstechnik praktisch keine Rolle.
In diesem Blog möchte ich mich mit diesen beiden Begriffen und den dahinter stehenden Prozesse beschäftigen. Insbesondere die Frage nach der gegenseitigen Abhängigkeit ist spannend.

Strukturelle Source Code Coverage:

Die strukturelle Source Code Coverage 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 gibt anhand eines einfachen Beispiels einen Überblick über verschiedene Arten verwendeter Coverages.

Requirements Engineering:

Gute funktionale Requirements beschreiben das Verhalten eines Systems unter definierten Bedingungen. Funktionale Requirements liefern also letztlich die Begründung für die Implementierung. Moment! Im ersten Satz habe ich den Begriff „System“ verwendet und im zweiten Satz steht „Implementierung“. Ist hier nicht ein Widerspruch?
„Ja!“ dies ist ein Widerspruch! Mit Requirements, die das Systemverhalten beschreiben, ist es in vielen Fällen unmöglich eine bestimmte funktionale Umsetzung in der Software direkt nachzuvollziehen. Das ist soweit auch noch kein Problem, da ja nach den System Requirements, in der nächsten Ebene Software Requirements erstellt werden. Alle Standards der Funktionalen Sicherheit fordern mindestens diese beiden Ebenen von Requirements.
Die Requirements für die Software sollten dann aber die Source Code Implementierung in detaillierter Form nachvollziehbar machen? Leider stimmt das in der Praxis meist auch nur sehr bedingt. Die Begründung hierfür liegt in der ständig zunehmenden Komplexität von Software. Die Software Architekturen werden komplexer, um die steigende funktionale Komplexität zu beherrschen.
Das hat dann leider den unangenehmen Nebeneffekt, dass man auch mit Software Requirements inzwischen sehr selten die vollständige Software Implementierung begründen kann.
Da aber andererseits die im ersten Teil beschriebene Source Code Coverage auf Requirements basierten Tests gemessen werden sollte, entsteht in vielen sicherheitskritischen Projekten der Wunsch, mindestens eine weitere Ebene von Requirements zu definieren.
Nun haben wir den Punkt gefunden, an dem sich strukturelle Source Code Coverage und Requirements Engineering treffen. Die Notwendigkeit der Erreichung einer 100% Coverage treibt nach meiner Beobachtung in vielen Projekten die Anzahl der Requirements in die Höhe.

Fazit:

Die Luftfahrt sammelt schon 30 Jahre Erfahrung mit 3 Ebenen von Requirements (System, High-Level SW und Low-Level SW). Diese Ebenen sind dabei in der Norm sogar explizit vorgegeben. Die Erfahrungen hier zeigen, dass es bis heute nur ganz wenige Projekte gibt, die eine gute Balance zwischen den einzelnen Requirements Ebenen gefunden haben. Die Forderungen nach der Erreichung der Source Code Coverage bestehen auch in der Luftfahrt uneingeschränkt.
Trotzdem, die Erstellung von Low-Level Requirements ist sehr aufwendig und teuer. Es gibt viele Projekte in denen der Nutzen aber durchaus sehr zweifelhaft ist (auch zur Erreichung der Code Coverage).
Bevor Sie also in Ihrem Projekt anfangen die Lösung der Herausforderungen in vielen Ebenen von Requirements zu suchen, werfen Sie nochmal einen genaueren Blick auf die wirklichen Herausforderungen. Meist ist eine durchdachte Strategie, sowohl für die Erstellung der Requirements als auch für die Teststrategie zur Erreichung der Source Code Coverage, deutlich zielführender und kostengünstiger als die einfache Erhöhung der Anzahl von Requirements.

Ihre individuellen Fragen zum Test Engineering 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).