Stefan Schmerler - Softwaretest in der Praxis

Bei Reviews wird der Wissensaustausch zwischen den Beteiligten gefördert, und zwar sowohl im Hinblick auf das Projekt (einheitliches Verständnis) als auch im Sinne der fachlichen Qualifikation.

Reviews weisen eine Fehlerfin-

dungsrate von bis zu 70% auf!

Untersuchungen zeigen, dass durch gut geführte Reviews bis zu 70 % der in Dokumenten enthaltenen Fehler gefunden werden können – dies ist einer der höchsten Werte in der analytischen Qualitätssicherung überhaupt.

Abb. 1-9: Reviews gemäß Vorgehensweise IEEE 1028

1.3.2 Statische Analysen

Prüfung des Programmcodes

auf Erfüllung von Kriterien,

ohne ihn auszuführen

Statische Analyse ist die Untersuchung des statischen Aufbaus eines Programmcodes auf die Erfüllung vorgegebener Kriterien hin. Die Prüfung ist statisch, d. h., das Testobjekt wird nicht ausgeführt. Statische Analysen grenzen sich damit vom dynamischen Test ab. Sie sind formal durchführbar und damit automatisierbar, womit sie sich vom Review abgrenzen. Als wichtigste Ziele der statischen Analyseverfahren sind zu nennen:

▶Bewertung von Qualitätsmerkmalen, z. B. Pflegbarkeit, Testbarkeit aufgrund struktureller Eigenschaften des Prüflings (z. B. Komplexität, Anomalien),

▶Erkennen von Fehlern und Anomalien in neu erstellter Software,

▶Erkennen und Analyse von Programmstrukturen bei der Pflege und beim Reengineering von Altsystemen,

▶Prüfung, ob ein Programm formale Vorgaben (z. B. Codierrichtlinien, Namenskonventionen, etc.) einhält.

Statischen Analysen ist aufgrund ihrer großen Bedeutung bei der Qualitätssicherung von Software in diesem Buch ein eigenes Kapitel gewidmet.

In der Regel werden für die Durchführung statischer Analysen leistungsfähige Werkzeuge benötigt. Auch auf diese wird im weiteren Verlauf dieses Buchs eingegangen.

1.3.3 Symbolische Ausführung

Bei der symbolischen Ausführung wird die Programmausführung mit symbolischen Werten für Eingaben und Zustände simuliert. Das Programm wird Zeile für Zeile abgearbeitet, ohne Werte für die Eingangsvariablen anzugeben.

Analyseverfahren sollten ohne

Expertenwissen anwendbar sein,

sonst sinkt die Akzeptanz.

Auf jedem Programmpfad wird also für jede Zeile ein symbolischer Ausdruck für Ausgaben und (neue) Zustände berechnet. Die Überprüfung der Ergebnisse ist dadurch schwieriger als beim konventionellen Test, da symbolische Ausdrücke und keine Zahlenwerte mit der Spezifikation verglichen werden müssen. Dies ist automatisiert kaum darstellbar. Es wird zudem ein Theorembeweiser benötigt, der alle erforderlichen Umformungen berechnen kann, z. B. a + 2 . b – a = 2 . b.

Diese Einschränkungen führen dazu, dass die symbolische Ausführung außerhalb des wissenschaftlichen Umfelds im betrachteten industriellen Kontext keine wesentliche Rolle spielt.

1.3.4 Model Checking

Model Checking analysiert das Verhalten des SUT nicht auf Ebene des Sourcecodes, sondern des äquivalenten Funktionsmodells (z. B. einem Matlab Simulink-Modell). Oft wird eine Funktion nicht mehr von Hand programmiert, sondern in Form eines Modells beschrieben.

Modelle bieten als formale Be-

schreibungsmittel einige Vorteile.

Es handelt sich hier aber nur um eine andere Art der Darstellung. Dies ist vorteilhaft, weil Menschen komplexe Zusammenhänge oder Funktionsbeschreibungen in grafischen Notationen besser erfassen und verstehen können als durch das Studium langer Texte. Zudem können Modelle simulativ analysiert werden – eine Analyseebene, die bei reinem Quellcode nicht zur Verfügung steht. Ausgehend von diesem Funktionsmodell erfolgt dann nach Analyse durch Simulation über eine automatische Codegenerierung die Erstellung eines entsprechenden, funktionsäquivalenten Quellcodes.

Model Checking nutzt die Modellebene aber noch über die reine Simulation hinaus. Es ermöglicht, das Systemmodell auf die Erfüllung spezifischer Eigenschaften abzuprüfen.

Beispiel: »Feindliches Grün«

Bei einer Ampelsteuerung, die als Funktionsmodell vorliegt, wäre z. B. die Eigenschaft von besonderem Interesse, ob es im Betrieb – auf welche Weise auch immer – möglich ist, dass Ampeln kreuzender Fahrspuren gleichzeitig Grün anzeigen. Dies bezeichnet man auch als »feindliches Grün«. Auch wenn dies in der Spezifikation sicher nicht vorgesehen ist, wäre ja denkbar, dass ein Implementierungsfehler im Modell dies dennoch zulassen könnte.

Wir fragen nach konkreten

Eigenschaften des Systems.

Model Checking ermöglicht die Überprüfung spezifischer Eigenschaften, z. B. ob es grundsätzlich möglich ist, dass dieses Modell ein »feindliches Grün« zulässt. Ist diese Eigenschaft erfüllt? Nun laufen komplexe Algorithmen ab und das Verfahren liefert entweder die Antwort »Nein« oder es liefert ein konkretes Beispiel, in dem diese Eigenschaft erfüllt ist.

Dies ist eine besondere Art der funktionalen Analyse. Im Gegensatz zum klassischen Funktionstest, der im Prinzip nur auf vielfachem Probieren basiert, könnte man nun sicher sein, dass auch bei beliebig vielen Tests das abgefragte Fehlverhalten nie auftreten würde. Beim Testen allein könnte man nie sicher sein, dass nach vielen fehlerfreien Tests und erreichtem Testende nicht doch der nächste Test ein »feindliches Grün« aufgezeigt hätte. Im weiteren Verlauf dieses Buch werden uns noch weitere Vertreter dieser Art von geschlossenen Fragestellungen begegnen.

Die Möglichkeit, Eigenschaften eines SUT abzufragen (»Ist es prinzipiell möglich, dass …?«), bietet als wertvolle Ergänzung erhebliche Vorteile gegenüber dem klassischen Funktionstest.

Allerdings hat diese Vorgehensweise auch ihren Preis. Zum einen wird in der Tat auch nur exakt diese eine Frage beantwortet – alle anderen Funktionsaspekte bleiben ungetestet –, andererseits kann Model Checking mit erheblichen Rechenzeiten einhergehen. Letztlich laufen komplexe Algorithmen über den Modellgraphen, und um Rechenperformance zu optimieren, können Einschränkungen an den Beschreibungsmerkmalen im Funktionsmodell vorgenommen werden. Ob diese Einschränkungen vertretbar sind, muss von Fall zu Fall entschieden werden.

Besonders sicherheitskritische Modellteile werden oft durch Model Checking analysiert. Fest steht, dass lange Analysezeiten oft zu Lasten der industriellen Akzeptanz gehen. In der automobilen Serienentwicklung wird Model Checking in der Regel nur bei spezifischen Fragestellungen im sicherheitskritischen Bereich eingesetzt, wo der Nachweis der Erfüllung konkreter Modell- und Systemeigenschaften einen entscheidenden Vorteil gegenüber dem stichprobenhaften Vorgehen beim Testen darstellt. Die zu analysierende Modell- und Systemeigenschaft wird verifiziert oder falsifiziert.

1.3.5 Simulation

Software nicht von Hand

schreiben, sondern aus einem

Modell heraus generieren

Bei simulativen Analyseverfahren erfolgt eine dynamische Ausführung des SUT als Modell auf emulierter Komponentenhardware, wenn z. B. die Zielhardware noch nicht verfügbar ist. Wie bereits aufgezeigt, bietet das verhaltensäquivalente Funktionsmodell bessere analytische Möglichkeiten als der klassische Test des Quellcodes. Eine solche analytische Möglichkeit ist die Simulation und es steht eine Vielzahl kommerzieller wie nichtkommerzieller Werkzeuge zur Verfügung mit einer Fülle an Analysemöglichkeiten.

In der Automobilindustrie kommt oftmals Matlab Simulink zum Einsatz. Vor dem Test des Codes direkt auf der Zielhardware, dem finalen Steuergerät, kann man hier bereits frühzeitig mit einem handelsüblichen PC Funktions- bzw. algorithmische Fehler durch Simulation eliminieren.