Stefan Schmerler - Softwaretest in der Praxis

Abb. 1-10: Hierarchisches Funktionsmodell in Simulink

Grafische Notationen machen Funktionen

besser verständlich als lange Listings.

Die Simulation ist eines der am weitesten verbreiteten Analyseverfahren. Sie ist vergleichsweise kostengünstig, intuitiv anwendbar und bietet viele Möglichkeiten. Durch die automatische Codegenerierung aus dem Modell (zielgerichtet optimiert für spezifische Ziel-Controller) muss die Funktion nur einmal modelliert werden, die klassische und fehleranfällige manuelle Codeerstellung kann entfallen. Wer allerdings glaubt, automatisch generierter Code sei fehlerfrei, der sei hier eines Besseren belehrt, wie Codeanalysewerkzeuge uns Tag für Tag aufzeigen. Doch auch dazu später mehr.

Simulation prüft nicht das SUT,

sondern nur dessen Abstraktion.

Eines sollte man bei der Simulation im Auge behalten. Simulation ist immer eine Abstraktion von der Realität. Je realitätsnäher das Modell ist, desto geringer ist dieser Unterschied. Er ist aber immer existent.

Simulation ist immer eine Abstraktion von der Realität. Es hängt vom Testziel ab, ob der Unterschied zwischen Modell und Realität tolerierbar ist. Keine Simulation kann den finalen Test des realen Systems ersetzen.

Modellbildung kann für komplexe Systeme extrem aufwendig sein. Diesen Aufwand muss man treiben, wenn aus Simulationsergebnissen belastbare Erkenntnisse gezogen werden soll. So kann es sein, dass aufgrund zu großer Abstraktion des Modells oder schlichtweg aufgrund von Modellfehlern das Modell sich so weit vom eigentlichen SUT unterscheidet, dass eine fehlerfreie Simulation nicht automatisch ein fehlerfreies SUT bedeutet. Und umgekehrt spiegeln sich womöglich simulativ gefundene Fehler gar nicht im realen SUT. Wir dürfen nicht vergessen: Testziel ist die Fehlerfreiheit des Codes auf dem Steuergerät und nicht nur die des Modells!

industrielle Nutzung

Im industriellen Kontext werden daher erhebliche Aufwände getrieben, um mit qualitativ höchstwertigen Modellen arbeiten zu können. Nur so kann man aufgrund der Verlässlichkeit der Ergebnisse durch die simulative Erprobung die teurere Erprobung auf der Zielhardware bzw. in der Zielumgebung reduzieren. In der Automobilindustrie kommen nicht selten bei HiL-Simulatoren Fahrzeugmodelle zum Einsatz, für die Dutzende von Personenjahren angesetzt werden können.

Wie komplex sollte ein Modell sein?

Und ein weiterer Aspekt ist nicht zu vernachlässigen: Je komplexer und »besser« ein Modell ist, desto rechenaufwendiger ist die Simulation. Wenn die Ausführung eines Codes bis auf die Simulation der Prozessorhardware reicht, liegt ggf. ein Vielfaches zwischen Simulationszeit und Echtzeit, d. h. es könnte Minuten dauern, um eine Sekunde eines Funktionscodes zu simulieren. Andererseits ist es oftmals das Ziel, dass die Simulation so performant ist, dass Echtzeit erreicht werden kann. Hintergrund ist der Wunsch, bei der Absicherung eines Systems reale und simulierte Komponenten zu mischen, d. h., beide Welten benötigen dieselbe Zeitbasis, um miteinander kommunizieren zu können. Es werden also sehr leistungsfähige Hardwareplattformen zum Einsatz gebracht.

Ziel ist es, die Echtzeit zu schlagen.

Bei der Wahl der Modelltiefe sollte man allerdings aus wirtschaftlichen Gründen auch nicht über das Ziel hinausschießen. Es gilt der Grundsatz: So viel wie nötig, so wenig wie möglich. Die Systeme werden also so dimensioniert, dass noch genügend Rechenreserven vorhanden sind, um in jeder Situation noch Performance in Echtzeit erreichen zu können. Und ist die Simulation schneller als die Realität, ist das kein Problem: Die Realität kann zwar nicht auf die Simulation warten (die Dauer einer Sekunde lässt sich leider nicht ändern, auch wenn man das Gefühl hat, dass die Zeit manchmal viel zu schnell vergeht …), umgekehrt ist das aber sehr wohl möglich: Rechner sind sehr geduldige Wesen.

1.3.6 Testmethoden

Intuition und Bauchgefühl sind

keine guten Berater beim Test.

Wie bereits ausgeführt, liegt der Schlüssel zur Effizienz beim Testen in der Automatisierung und Methodik der Tests. Ein ziel- und planloses Ausprobieren verschiedener Stimuli »nach Intuition« und das Beenden des Testprozesses »nach Bauchgefühl« sind der beste Garant für eine kostenintensive und dennoch in puncto Reifegrad schlechte Absicherung.

Die Kunst des Testens besteht darin, mit möglichst wenigen Tests die wesentlichen Fehler zu finden.

Worauf kommt es beim Testen an?

Das Testergebnis ist immer auch im wirtschaftlichen Kontext zu sehen. Niemand kann es sich leisten, für einfache Steuerungen Monate an Testaufwand zu investieren. In kurzer Zeit ein akzeptables Ergebnis zu erreichen, ist oftmals besser, als sich über einen langen Zeitraum an das perfekte Ergebnis anzunähern. Zeit ist im industriellen Kontext ein rares Gut, und wenn die verbleibenden Fehler tolerierbar sind, ist dies der optimale Weg. Es lohnt sich für viele Systeme nicht, die letzten 5 % vorhandener Fehler aus dem Code zu eliminieren, wenn man dafür 50 % der bislang investierten Ressourcen bräuchte! Man sollte sich allerdings Gedanken über die kritischsten Fehler gemacht haben und diese absichern. Mit den dann noch verbleibenden Auffälligkeiten kann man ggf. leben und diese erst bei Auftreten beseitigen.

A fool with a tool is still a fool.

Testmethodik kann als das Know-how des Testens bezeichnet werden. Die zum Einsatz kommende Testtechnologie ist nur eine notwendige, aber keine hinreichende Bedingung für den effizienten Testerfolg – ich erinnere an den Wahlspruch der 1990er Jahre: »A fool with a tool is still a fool.«, als man in tiefer Toolgläubigkeit in Werkzeuge investierte, ohne sie richtig verstanden zu haben oder anwenden zu können. Merke: Die beste Technologie nutzt nichts, wenn sie nicht richtig angewandt wird!

Testen muss planvoll erfolgen mit

klar definiertem Ziel und Ende.

In diesem Kontext ist der Einsatz von Testmethodik zu sehen. Wenn ein Testingenieur nicht sofort auf die Frage antworten kann, warum gerade jetzt genau dieser Test ausgeführt wird, verfolgt er höchstwahrscheinlich keinen Plan und seinen Tests liegt womöglich keinerlei Methodik zugrunde.

Im Folgenden soll ein Überblick über die verbreitetsten Testmethoden gegeben werden. Diese werden in Form von Steckbriefen mit den wichtigsten Charakteristika und einer Bewertung vorgestellt, um in diesem Kapitel einen schnellen Überblick zu vermitteln. Eine Vertiefung erfolgt dann noch in den folgenden Kapiteln, insbesondere in Kap. 5 (Dynamischer Test).

1.3.6.1 Funktionaler Test

Funktionstest erfolgt

gegen die Spezifikation.

Der wichtigste Vertreter im Bereich Testmethodik ist der funktionale Test oder auch Funktionstest mit einer Reihe von Untermethoden. Allen gemein ist das Prinzip, dass ein Funktionstest immer gegen die Spezifikation erfolgt. Man liest die Spezifikation des SUT und leitet daraus die durchzuführenden Testinhalte ab.

Eigenschaften von Lastenheften

Technische Spezifikationen z. B. für elektronische Steuergeräte umfassen eine Vielzahl von Anforderungen, Diagrammen und Beschreibungen technischer Abläufe des Sollverhaltens. Für die Erfassung haben sich in den letzten Jahren Werkzeuge wie z. B. DOORS als Standard etabliert. Sie bringen Struktur in die große Menge an funktionalen Teilbeschreibungen, indem sie Anforderungen (Requirements) vereinzeln, d. h. einzeln referenzierbar machen. Jede Anforderung erhält eine ID und kann im Übrigen auch zu Testdaten oder anderen Dokumenten verlinkt werden.

Unter Testabdeckung versteht man den Anteil aller Anforderungen, die bereits in einem Test überprüft wurden. Man könnte z. B. für jede Anforderung einen Test erstellen, der den in der Anforderung dokumentierten technischen Sachverhalt prüft.