Hard- und Softwaretest Grenzen der Testbarkeit von Embedded-Software

Autor / Redakteur: Dr. Richard Kölbl, Erwin Pschernig und Wolfram Gettert * / Dipl.-Ing. (FH) Hendrik Härter

Sachgerechtes und systematisches Testen ist die Voraussetzung für eine belastbare Qualitätsaussage über Hard- und Software. Wir stellen fünf Grenzen des Testens vor.

Firmen zum Thema

Grenzen der Testbarkeit: Ein nicht vollständiger Test tritt bei Grenzsituationen auf, wie sie im Timing oder im Interruptverhalten von Systemen auftreten
Grenzen der Testbarkeit: Ein nicht vollständiger Test tritt bei Grenzsituationen auf, wie sie im Timing oder im Interruptverhalten von Systemen auftreten
(Andreus, clipdealer.de)

Vor einiger Zeit wurde das Ergebnis europaweiter Stresstests für Kernkraftwerke bekanntgegeben. Eines der Prüfkriterien war die Resistenz der jeweiligen Anlage gegen einen Flugzeugabsturz. Es dürfte unmittelbar einsichtig sein, dass ein solches Prüfkriterium vernünftigerweise nicht im praktischen Versuch getestet werden kann. Stattdessen werden Näherungsmethoden eingesetzt, deren Gesamtergebnis einen Rückschluss auf das ursprüngliche Prüfkriterium zulassen, wenngleich mit einer methodisch bedingten Unschärfe bzw. Aussagewahrscheinlichkeit behaftet.

Ebenfalls an die Grenzen kann der Systemtester aus verschiedenen Gründen stoßen. Setzt man als ideales Ziel des Systemtests zunächst den mathematisch vollständigen Nachweis der Fehlerfreiheit des getesteten Systems, so ist beweisbar, dass dies schon aus Zeitgründen nicht möglich ist: Gegeben sei ein Modul zum Vergleich zweier Zeichenketten der Länge 4 Byte. Für den mathematisch vollständigen Beweis muss jeder Vergleichsschritt bitweise in beide Richtungen durchgeführt werden. Daraus ergeben sich 264 Testfälle, deren Ausführung bei einer Frequenz von beispielsweise 1000 Testfällen pro Sekunde 585 Millionen Jahre dauern würde. Auch eine Steigerung auf einige Millionen Testcases pro Sekunde würde die Sache nicht grundlegend beschleunigen.

Ein mathematisch vollständiger Beweise ist unmöglich

Ein mathematisch vollständiger Nachweis der Fehlerfreiheit ist bei einfachsten Szenarien unmöglich. Ist ein vollständiger Test in der Praxis überhaupt notwendig? Also wird der Systemtester eine vernünftige Auswahl treffen müssen: der Tester definiert eine Teilmenge von auszuführenden Tests mit dem Wissen, dass unter den ausgesonderten Testfällen sich solche befinden, die den Nachweis eines noch unentdeckten Systemfehlers erbringen würden.

Ganz so aussichtslos ist die Lage des Testers auch wieder nicht, wie ein Blick in unsere komplex digitalisierte und vernetzte Welt zeigt. Die Kunst des Testens hat in den letzten Jahren und Jahrzehnten ebenso an Methodik und Erfahrung gewonnen wie auch andere Bestandteile des Produktionsprozesses, etwa das Anforderungs- oder Fehlermanagement. Professionelles Testen orientiert sich an Risikoabschätzungen und Fehlerpriorisierungen - und trifft auf Testendekriterien. Sie legen fest, wann ein Testzyklus vertretbar als abgeschlossen angesehen werden kann. Diese Kriterien sollten idealerweise aus den technischen Gegebenheiten des Systems stammen. In der Praxis begrenzen häufig Budgetvorgaben den Testumfang, womit der zweite Typ von Grenze für das Testen beschrieben ist.

Wenn die komplexe Außenwelt betrachtet werden muss

Der dritte Typ von Begrenzung kann als schnittstellenbedingt bezeichnet werden. Beim ersten Typ ließ die interne Kompliziertheit des Prüflings die Menge aller möglichen Testfälle über das durchführbare Ausmaß anwachsen. Jetzt kommt die Komplexität der externen Welt dazu, mit der der Prüfling in Kontakt tritt. Das betrifft Software mit einer oder mehreren Schnittstellen, über die sie mit anderer Hardware und der darauf befindlichen Logik in Verbindung tritt.

Teilnehmer A möchte mit seinem Endgerät eine Verbindung zum Endgerät des Teilnehmers B aufbauen. Auf der einen Seite stehen die Endgeräten und die Domäne der Übermittler. Auf der anderen Seite die Endgeräte mit ihrer enormen Anzahl möglicher, noch im Gebrauch befindlicher Geräte. Jeder Teilnehmer sollte transparent erscheinen. Es muss möglich sein, von einem Wählscheibentelefon aus ein mobiles Endgerät anzurufen.

Die enorme Anzahl von möglichen Testfällen ergibt sich hier scheinbar schon allein durch die Kombination möglicher Endgeräte oder Modems. Tatsächlich sind es aber weitaus mehr technische Details, die in die Domäne der Übermittler fallen, die für die Multiplikation der Testfälle sorgen.

Dazu zählen statische Parameter wie Leitungstypen und -längen oder der dynamische Parameter Datenlast. Auch wenn die Menge von Testfällen durch die Kombination von den zwanzig wichtigsten Endgeräten, häufigen Leitungstypen und der schrittweisen Abtestung von Leitungslängen umgrenzt erscheint, wird sie überlagert durch den dynamisch wechselnden Zustand des Netzes in der Übermittlerdomäne, wodurch sich die Anzahl der Testfälle wiederum potenziert. Wenn wir den Blick von den großen Netzwelten in die vermeintlich überschaubarere Welt der Embedded-System richten, finden wir dort mit der technisch bedingten Grenze der Testbarkeit den vierten Typ.

(ID:36418840)