Kriterien für das Testen sicherheitskritischer Systeme

Gründliche Softwaretests werden zwar oft gefordert, fallen aber oft Zeit- und Budgetgrenzen zum Opfer. Bei sicherheitskritischen Systemen gelten dagegen definierte Vorschriften, von denen auch andere Entwicklungsbereiche lernen können.

In Pocket speichern vorlesen Druckansicht 7 Kommentare lesen
Lesezeit: 7 Min.
Von
  • Daniel K. Fischer
  • Klaus Lambertz
Inhaltsverzeichnis

Gründliche Softwaretests werden zwar oft gefordert, fallen aber oft Zeit- und Budgetgrenzen zum Opfer. Bei sicherheitskritischen Systemen gelten dagegen definierte Vorschriften, von denen auch andere Entwicklungsbereiche lernen können.

Fehlerhafte Software in der Luftfahrt, in Zügen, Automobilen oder in der Medizintechnik kann zu großen Schäden und sogar zum Verlust von Menschenleben führen. So gab ein Programm zur Berechnung von Bestrahlungen im Medizinbereich im Jahr 2000 inkorrekte Werte aus, was zum Tod von acht Patienten und zu etwa zwanzig Schwerstverletzten führte. Um solche Probleme weitgehend auszuschließen, gibt es für die sicherheitskritische Softwareentwicklung strenge Vorschriften.

Für die Softwareentwicklung in der Luftfahrtindustrie fordern die amerikanische Luftfahrtbehörde FAA (Federal Aviation Administration) und die in Köln ansässige Europäische Agentur für Flugsicherheit (EASA) die Einhaltung der amerikanischen Norm DO-178C beziehungsweise deren quasi identischer europäischen Version ED-12C. Sie teilen die Auswirkungen möglicher Fehlfunktionen in die Stufen A (katastrophal), B (gefährlich/schwerwiegend), C (erheblich), D (geringfügig) und E (keine) ein.

Auch die industrieübergreifende Norm DIN EN 61508 und die bei der Bahn angewendete Norm EN 50128 klassifiziert die Risiken in Sicherheitsanforderungsstufen, den Safety Integrity Level (SIL).

Software in der Automobilindustrie ist nach ISO 26262, einer internationalen Norm zur Absicherung der funktionalen Sicherheit von Straßenfahrzeugen, zu entwickeln und zu testen. Die Sicherheitsanforderungsstufen heißen hier Automotive Safety Integrity Level (ASIL).

Je höher die Sicherheitsanforderungen der Software sind, desto intensiver ist zu testen. Unter anderem werden Unit-Tests (also der Test einzelner Module des Programms) in Kombination mit einem Nachweis der getesteten Programmabschnitte, der sogenannten Code Coverage oder Testabdeckung, verlangt. Diese zeigt, welche Programmabschnitte während des Tests ausgeführt wurden und welche nicht. Durch Eingabe spezifischer Werte zum Test einzelner Funktionen (sogenannter Testvektoren) werden möglichst viele Programmabschnitte durchlaufen, was eine hohe Testabdeckung bedeutet.

Abhängig von Umfang und Genauigkeit der Tests gibt es unterschiedliche Stufen der Testabdeckung. Grundsätzlich unterscheidet man nach Tests auf Funktions-, Anweisungs-, Zweig-, Pfad- und Bedingungsebene. Je höher eine Stufe, desto mehr Aufwand wird benötigt, um eine akzeptable Code Coverage zu erreichen. Die Normen für die Entwicklung sicherheitskritischer Software fordern vor allem Funktions-, Anweisungs- und Zweigüberdeckungstests sowie den modifizierten Bedingungs- und Entscheidungsüberdeckungstest.

Bei der Funktionsüberdeckungs-Coverage (Function Coverage) wird die Anzahl der aufgerufenen Funktionen ins Verhältnis zu der Gesamtanzahl der Funktionen gestellt. Da die inneren Abläufe in der Software hierbei vollständig ignoriert werden, ist der Nutzen solcher Tests relativ gering. Die Anweisungsüberdeckungs-Coverage (Statement Coverage) gibt an, welche Anweisungen durch die Tests ausgeführt wurden. Auf dieser Stufe ist es bereits möglich, unerreichbare Programmteile (Dead Code) zu finden.

Im Gegensatz zur Statement Coverage durchläuft der Zweigüberdeckungstest (Branch Coverage) alle
Zweige. Da mindestens einmal der True- und der False-Zweig zu durchlaufen ist, heißt der Test auch Entscheidungsüberdeckungstest. Diese Coverage-Stufe ist eine realistische Mindestanforderung, die mit einem vertretbaren Aufwand erreichbar ist. Die Anzahl der erforderlichen Testfälle hängt von der
zyklomatischen Komplexität ab und lässt sich auf einfache Weise mit Code-Analysetools messen. Je höher die Komplexität, desto mehr Tests sind erforderlich.

Der modifizierte Bedingungs- und Entscheidungsüberdeckungstest, nach der englischen Bezeichnung Modified Condition/Decision Coverage mit MC/DC abgekürzt, ist die höchste von den Normen geforderte Testabdeckungsstufe. Da die Überprüfung aller Bedingungskombinationen einen enormen Aufwand erfordern würde, versucht MC/DC diesen Testaufwand zu minimieren. Bei dieser Testabdeckungsstufe werden alle atomaren Bedingungen einer zusammengesetzten Bedingung herangezogen. Für jede der atomaren Bedingungen wird ein Testfallpaar implementiert, das zur Veränderung des Gesamtergebnisses der
zusammengesetzten Bedingung führt, wobei sich jedoch nur der Wahrheitswert der betrachteten atomaren Bedingung ändert. Dabei muss der Wahrheitswert der anderen atomaren Bedingungen konstant bleiben.

Die Luftfahrtnorm DO-178C fordert 100 Prozent MC/DC für Software, bei deren Fehlverhalten katastrophale Auswirkungen eintreten können (Level A). Bei gefährlichen beziehungsweise schwerwiegenden Auswirkungen (Level B) wird mindestens Zweigüberdeckung verlangt. In der Automobilindustrie ist bei der höchsten Sicherheitsanforderungsstufe ASIL D ebenfalls die strenge MC/DC vorgeschrieben.