Startseite > Automation > Steuerungstechnik > Bessere Qualität bei geringeren Kosten

Softwaretest

Bessere Qualität bei geringeren Kosten

3. November 2016, 8:15 Uhr | Ralf Higgelke

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Immense Zahl an Testfällen

Gemäß IEC 61508 sollte Software, die in programmierbaren elektronischen Systemen bis SIL 3 genutzt wird, die Modified Condition/Decision Coverage zu 100 Prozent erreichen. Für SIL 4 wird aus dieser Empfehlung eine Vorgabe. Bei Anwendung des Verfahrens auf Funktionsbausteine zeigt sich schnell, dass schon bei geringer Komplexität mehrere Tausend Testfälle erforderlich sind. Typische Funktionsbausteine, wie sie beispielsweise die PLCopen (Technical Committee 5) spezifiziert, benötigen durchaus mehrere Millionen Testfälle, um die normativ geforderte Codeabdeckung zu erzielen. Diese Zahlen unterstreichen, dass derartige Tests nur mit Unterstützung von Software zu realisieren sind. Das Generieren und Durchführen entsprechender Testfälle sollte also vollständig automatisiert sein. Dieses Ziel lässt sich durch modellbasiertes Testen umsetzen.

Wie schon erwähnt, basiert modellbasiertes Testen auf einem formal beschriebenen Systemmodell. Dieses ergibt sich aus der Spezifikation, die wiederum aus den Anforderungen abgeleitet ist. Die Spezifikation, die das Systemverhalten des Funktionsbausteins darstellt, bildet die Grundlage für seine Programmierung. Zur formalen Spezifikation erweist sich der Einsatz bekannter Notationen wie der UML (Unified Modeling Language) als am besten geeignet. Das aus einem UML-State-Diagramm abgeleitete Testmodell des spezifizierten Funktionsbausteins fungiert als zentraler Bestandteil des modellbasierten Testens. Denn aus Testsicht stellt es den Funktionsbaustein dar (Bild 2). Aus dem Testmodell entwickelt dann ein Generator die konkreten Testfälle für den Funktionsbaustein.

Ein integriertes Testsystem verarbeitet die erzeugten Testfälle entweder auf Basis einer Simulationsumgebung oder einer realen sicheren Steuerung. Darüber hinaus bereitet das Testsystem die Ergebnisse als Bericht auf, der für die Dokumentation und das Functional-Safety-Management verwendet wird (Bild 3).

Frühzeitig Fehler erkennen

Aus den erläuterten Eigenschaften des modellbasierten Testens resultieren folgende Vorteile für den Anwender:

Das Verfahren fokussiert sich auf die Spezifikation. Das bedeutet, dass bereits in der Spezifikationsphase ein Schwerpunkt auf der Prüfbarkeit des spezifizierten Bausteins liegt. Lückenhafte oder nicht eindeutig formulierte Spezifikationen werden also zu einem frühen Zeitpunkt erkannt.
Erfolgt die Erstellung von Spezifikation und Test iterativ und parallel, lassen sich Fehler im Design und in der Spezifikation frühzeitig erkennen.
Mit dem Systemmodell entsteht implizit auch der Testplan.
Durch den analytischen Ansatz bei der Testfall-Generierung wird eine definierte Codeabdeckung erreicht.
Das Nutzen eines integrierten Testsystems führt zu einer eindeutigen Wiederholbarkeit der durchgeführten Prüfungen und einer erheblichen Senkung der Kosten.
Wird das Systemmodell durch Erweiterungen oder die Beseitigung von Spezifikationsfehlern modifiziert, fallen keine oder nur geringe Wartungskosten für die Testfälle an, weil diese sich vollständig und automatisch aus dem aktuellen Systemmodell ableiten.

Das modellbasierte Testen ist in mehreren Projekten erfolgreich bei der Entwicklung sicherer Funktionsbausteine eingesetzt worden. Der vorgestellte Ansatz eignet sich insbesondere für den Bereich der Komponententests (Unit Test). Sind jedoch schon die Anforderungen nicht korrekt, respektive die daraus resultierenden Spezifikationen, enthält das Systemmodell ebenfalls den Fehler, der hier nicht aufgedeckt werden kann. Fehler in den Anforderungen kann der Akzeptanztest detektieren, solche in der Spezifikation der Systemtest.

Toten Code vermeiden

Ist das Systemmodell hingegen fehlerfrei, erfüllt die beschriebene Entwicklung die normativen Anforderungen hinsichtlich Codeabdeckung durch die vollständige Testabdeckung gemäß Modified Condition/Decision Coverage. Geringere Werte der Testabdeckung begründen sich lediglich aus Spezifikations- respektive Designfehlern. Die Überspezifizierung von Übergangsbedingungen (Transitions) oder eine defensive Programmierung führen beispielsweise zu Codepassagen, die nicht erreicht werden. Dieser sogenannte tote Code entzieht sich der Codeabdeckung. Neben der analytischen Untersuchung des entwickelten Algorithmus wurde die erzielte Codeabdeckung zusätzlich experimentell durch entsprechende Werkzeuge belegt.

Testfälle schnell erstellen

Was die Performance der Lösung betrifft, so werden auf einer konventionellen PC-Hardware etwa fünf Millionen Testfälle pro Stunde erzeugt, deren Abarbeitung in einer PC-basierten Simulationsumgebung ungefähr acht Stunden in Anspruch nimmt. Wird der Test auf einer realen Sicherheitssteuerung durchgeführt, hängt die Performance maßgeblich von der Geschwindigkeit des Datenaustauschs zwischen dem Testsystem und der sicheren SPS ab. Die zukünftige Unterstützung von Multicore-Architekturen ermöglicht eine noch schnellere automatische Generierung von Testfällen. Bereits heute lassen sich die Tests parallel auf mehreren sicheren Steuerungen realisieren.