Hard- und Softwaretest Grenzen der Testbarkeit von Embedded-Software

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Mixed Mode GmbH

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.

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.

In der Embedded-Welt kann Hardware zum Teil, aber nie vollständig simuliert werden. Nicht vollständige Testbarkeit tritt bei Grenzzuständen auf, im Timing oder im Interruptverhalten. Das integrierte Gesamtsystem ist eine Herausforderung, wenn es um den Test in Grenzsituationen geht. Als Beispiel dient ein Hardware-Watchdog, der bei Unterspannung für einen Reset des Systems zuständig ist. Nicht selten hängt am übergeordneten Controller eine Routine, die in den Millisekunden vor dem Reset noch einen Logeintrag machen soll. Im Gutfall ist die dafür zur Verfügung stehende Zeit ausreichend. Die Zeit wurde statistisch ermittelt und Toleranzen unterworfen.

Das System in der Grenzsituation zu beobachten ist sehr eingeschränkt; eine softwaregestützte Simulation des Hardware-Watchdogs ist zwar möglich, aber letztlich – wie beim eingangs erwähnten Kernkraftwerk – nur von bedingter Aussagekraft. Es kann kaum nachvollzogen werden, ob der Schreibmechanismus in den letzten Millisekunden wirklich noch vollständig ausgeführt wird. Hinzu kommen variable physikalische Parameter, wie sie im gesamten Verkehrswesen von Zug, Flug, Schiff bis zum Auto auftreten, bei Brandschutzeinrichtungen oder Bezahlautomaten.

Auch gewisse fertigungsbedingte Schwankungstoleranzen bei den Ansprechzeiten des Bauelements wirken sich aus. Außerdem müssen bei Standard-Hardwarebauteilen Funktionalitäten in die Software verlegt werden, die besser von der Hardware übernommen würden.

Die fünfte Grenze resultiert aus zu wenig Zeit für eine sachgerechte Entwicklung. Es gab einmal eine Software – Namen werden nicht genannt –, die verschiedene Steuergeräte problemlos unterstützte. Im Lauf der Jahre haben sich in einigen Steuergeräten Protokollfehler angesammelt. Statt sie beim Entstehen zu fixen, wurden in der Software Workarounds eingebaut. Das Ergebnis: der Aufwand für den Freigabetest der Software wuchs stetig an, da tatsächlich jeder Steuergerätetyp einzeln getestet werden musste.

Schnittstellen unbedingt sauber definieren

Wenn vieles reibungslos funktioniert, so ist das das Ergebnis hervorragender und sorgfältiger Arbeit. Trotzdem sollte man sich gelegentlich der ineinandergreifenden Cluster von logischen Komplexitäten bewusst sein, die uns in stetig steigendem Maße umgeben und von denen wir immer abhängiger werden. Es zeigt die enorme Wichtigkeit sauberer Schnittstellendefinitionen und Implementierung der Vorgaben.

Aus Sicht des Testers wird klar: selbst bei knappen Budgets dürfen keine Kürzungen bei Testverfahren angesetzt werden, auch keine indirekten. Denn steigt die Komplexität der zu testenden logischen Systeme, dann bedeutet schon eine nicht damit Schritt haltende Erweiterung des korrespondierenden Testprozesses eine indirekte Kürzung. Nicht nur das jeweilige Produkt muss weiterentwickelt werden, sondern auch die zugehörigen Testverfahren.

* Dr. Richard Kölbl, Erwin Pschernig und Wolfram Gettert arbeiten beim Software-Spezialisten Mixed Mode in Gräfelfing bei München.

(ID:46497587)