Softwaretest Bessere Qualität bei geringeren Kosten

Spätestens seit der zweiten Fassung der IEC 61508 hat modellbasiertes Testen Einzug in die Sicherheitstechnik gehalten. Die automatisierte Testfall-Generierung stellt einen wesentlichen Teil des Verfahrens dar. Dies erhöht die Testqualität deutlich – und das bei zugleich erheblicher Kostensenkung.

von Dr. Tobias Frank,  Head of Safety & Configuration, und Harry Koop, Research & Development, beide bei Phoenix Contact Software.

Sicherheitsgerichtete Funktionsbausteine für IEC-61131-konforme Programmiersysteme werden häufig mit semiformalen Methoden wie dem Zustandsübergangsdiagramm spezifiziert. Auf Basis dieses Diagramms respektive der vorhandenen Systemmodelle lassen sich dann Testdaten und -fälle automatisiert mit dem Ziel erzeugen, die normativ geforderte Testabdeckung zu erreichen. Neben der reinen Testfall-Generierung kann die nachfolgend beschriebene Lösung für das sichere IEC-61131-Programmiersystem Safeprog von Phoenix Contact Software den Test auch automatisiert durchführen und auswerten. Die Tests können sowohl in einer Simulationsumgebung auf dem PC als auch auf einer realen Sicherheitssteuerung erfolgen. Somit ist der Test sicherer Firmware-Funktionen ebenfalls möglich.

Die zentrale Frage bei jedem Software-Test lautet: Wann ist eine Funktion hinreichend geprüft worden? Insbesondere auf der Ebene des Komponententests hat sich die Codeabdeckung (engl. Code Coverage) als Maßzahl etabliert. Darunter ist der Anteil des Quellcodes zu verstehen, der von einem Test durchlaufen wird. Die IEC 61508 empfiehlt hierzu folgende Codeabdeckungsverfahren:

  • Entry Point Coverage

Als einfachste Ausprägung der Codeabdeckung weist diese Methode lediglich die Existenz einer spezifizierten Funktion nach. Aufgrund der daraus resultierenden geringen Aussagekraft eignet sich die Entry-Point-Coverage nicht zur Quantifizierung der funktionalen Testtiefe.

  • Statement Coverage

Bei der prozeduralen Programmierung, zu der auch die klassische SPS-Programmierung mit Funktionsbaustein-Sprache (FBS) oder Strukturiertem Text (ST) zählt, lässt sich ein Programm einfach als Automat darstellen. Die Statement Coverage zeigt den Anteil der im Test abgedeckten Anweisungen respektive der Zustände im Automaten.

  • Branch Coverage

Die Branch Coverage erweitert die Statement Coverage um den Anteil der im Test durchlaufenen Kanten des Automaten (Bild 1).

  • Modified Condition/Decision Coverage

Verzweigen in einem Zustand des Automaten verschiedene Pfade, bietet sich die Modified Condition/Decision Coverage an (MC/DC). Bei dieser Methode werden zusammengesetzte Entscheidungen in ihre atomaren Bedingungen zerlegt. Der Test weist dann nach, dass jede atomare Bedingung unabhängig von den übrigen Bedingungen die Gesamtentscheidung auf »true« und »false« beeinflusst. Das Beispiel »((a OR b) AND c)« soll das Verfahren verdeutlichen. Die Entscheidung »((a OR b) AND c)« setzt sich aus den atomaren Bedingungen »(a OR b)« und »c« zusammen. Für die vollständige Codeabdeckung mittels MC/DC ergeben sich somit die in der Tabelle aufgelisteten möglichen Testfälle.

aba OR bc((a OR b) AND c)
falsefalsefalsetruefalse
truefalsetruetruetrue
falsetruetruefalsefalse

 

Tabelle: Mögliche Testfälle für eine 100-prozentige MC/DC am Beispiel der Entscheidung ((a OR b) AND c).