Bild 1: Die Hardware von DIOLINE20.

Bild 1: Die Hardware von DIOLINE20.Friedrich Lütze

Die Norm DIN EN 50128 enthält Vorschriften zur Software-Entwicklung für Schienenfahrzeuge. Bei einer Entwicklung nach dieser Norm muss der Softwaretest nicht nur im Gesamtsystem sondern auch auf Modulbasis erfolgen. Die Module sind hier die in der Aufrufhierarchie am weitesten unten liegenden Software-Komponenten. Sie müssen gegen die Spezifikation (Module Test Specification) getestet werden, um zu zeigen, dass die Module ihre beabsichtige Funktion erfüllen. Zudem gilt es, die Testüberdeckung (Test Coverage) zu ermitteln. Im vorliegenden Fall nahm nicht die Herstellerfirma selbst den Modultest vor sondern ein externes Unternehmen, das für die Unabhängigkeit des Tests sorgte.

Bild 2: Auszug aus einer Testfallspezifikation nach der Klassifikationsbaummethode für die Software von DIOLINE20

Bild 2: Auszug aus einer Testfallspezifikation nach der Klassifikationsbaummethode für die Software von DIOLINE20Hitex

Die Friedrich Lütze GmbH beauftragte die Firma Hitex als Dienstleister, die Software für ein I/O-System zu testen, das in Schienenfahrzeugen zum Einsatz kommt. Das Dioline20 genannte System (Bild 1) ist mit einem Mikrocontroller des Typs netX 100 ausgestattet, der auf einer ARM-CPU basiert. Ein Gnu-Compiler für ARM übersetzt die in C geschriebene Software. Um die Software auf der tatsächlichen Hardware testen zu können, kommt der JTAG-Debugger TantinoARM von Hitex zum Einsatz, wobei die Bedienung dieses JTAG-Debuggers mit Hilfe der Software HiTOP erfolgt. Die zu testenden Softwareteile umfassen 24 Quellcode-Module (nicht zu verwechseln mit den Testobjekten), in denen sich jeweils ungefähr zehn Funktionen im Sinne von C befinden.

Den eigentlichen Modultest führte nicht der Hersteller selbst sondern die Firma Hitex durch. Dies entlastet den Hersteller nicht nur von der eigentlichen Testarbeit, sondern sorgt auch für die Unabhängigkeit des Testens. Falls nämlich ein Entwickler einen Modultest selbst durchführt, dann erkennt er wahrscheinlich Fehlinterpretationen oder (unbewusste) Ergänzungen der Modulspezifikation während der Entwicklung nicht als Fehler. Oft ergänzt ein Entwickler während der Implementierung ein nicht-spezifiziertes Detail so wie es seiner Meinung nach eigentlich nur sein kann, wie es jedoch nicht zwingend sein muss. Selbst durchgeführte Tests decken derartige Fehler nicht auf, weil die Tests natürlich nur die vermeintlich korrekte Implementierung prüfen. Dieser Effekt ist auch als „Blindness against own faults“ bekannt.

Klassifikationsbaummethode

Sowie ein entwickelndes Unternehmen den Test an eine externe Firma vergibt, bedeutet die Erstellung von Testfällen anhand der Modulspezifikation automatisch ein Review der Spezifikation. Dies ist insbesondere der Fall, wenn zum Erstellen der Testfallspezifikationen eine systematische Methode zum Einsatz kommt. Konkret nutzten die Testexperten von Hitex hier die Klassifikationsbaummethode (Classification Tree Method, CTM), die dazu dient, aus einer Modulspezifikation eine Menge von Testfällen abzuleiten.

Bild 3: Darstellung der Zweigüberdeckung in Tessy. Die Flussdiagrammdarstellung korreliert mit dem Quellcode. Rot dargestellte Zweige wurden nicht durchlaufen.

Bild 3: Darstellung der Zweigüberdeckung in Tessy. Die Flussdiagrammdarstellung korreliert mit dem Quellcode. Rot dargestellte Zweige wurden nicht durchlaufen.Hitex

Ein Kernstück dieser Methode ist die Äquivalenzklassenmethode (Equivalence Partitioning). Diese ist beispielsweise in der Tabelle A.13 des Standards DIN EN 50128 aufgeführt, wo Techniken für die dynamische Analyse und Test gelistet sind. Die Äquivalenzklassenmethode dient zur Reduzierung von sehr großen Mengen möglicher Werte für einen testrelevanten Aspekt, beispielsweise einen Eingabeparameter. Dazu werden Klassen gebildet, denen die möglichen Werte zugeordnet werden. Die Bildung der Klassen erfolgt so, dass alle Werte in einer Klasse als äquivalent für den Test betrachtet werden können; dann muss in den Testdaten lediglich ein Stellvertreter aus jeder Klasse enthalten sein, was die Anzahl der Testfälle signifikant reduziert und möglicherweise überhaupt erst handhabbar macht. Die Krux bei dieser Methode besteht natürlich darin, dass immer dann, wenn die Einteilung der Klassen nicht korrekt vorgenommen wurde, unter Umständen Testdaten, die einen Fehler im Testobjekt aufdecken würden, bei der Erstellung der Testfälle nicht berücksichtigt werden.

Eine weitere Technik, die in der Klassifikationsbaummethode zum Einsatz kommen kann, sind Grenzwertbetrachtungen (Boundary Value Analysis). Dieser Technik liegt die Überlegung zu Grunde, dass Extremwerte und Werte an den Grenzen von Bereichen bessere Testdaten ergeben als Werte aus dem Normalbereich. Grenzwertbetrachtungen sind ebenfalls in der Tabelle A.13 des Standards aufgeführt, und sie sind für die Software-Sicherheits-Anforderungs-Stufen (SSAS beziehungsweise „Software Safety Integrity Level“ SWSIL) von 1 bis 4 „highly recommended“ (besonders empfohlen). Alles in allem ergibt die Klassifikationsbaummethode eine graphische Darstellung der geplanten Testfälle. Diese Visualisierung der Testideen ist sehr gut als Grundlage eines Reviews geeignet (Bild 2).

Tessy im Einsatz

Die eigentliche Testdurchführung der Modultests führte Hitex mit dem Werkzeug Tessy durch. Tessy enthält den Klassifikationsbaumeditor CTE (Classification Tree Editor), mit dem die Spezifizierung der Testfälle nach der Klassifikationsbaummethode und der anschließende Export nach Tessy möglich ist. Die Testdurchführung erfolgt völlig automatisiert, was der Forderung aus Abschnitt 10.4.14 der Norm nach der Möglichkeit zur automatisierten Wiederholung der Tests nachkommt (Abschnitt iv). Tessy erzeugt auch einen Testbericht, der ebenfalls den Forderungen aus Abschnitt 10.4.14 entspricht. Insbesondere kann Tessy einen ausführlichen und verständlichen Testreport in druckbarem Format erzeugen, wodurch er prüfbar (auditable) ist.

Weiterhin fordert die Norm die Bestimmung der „Test Coverage“ (Testabdeckung, ebenfalls in Abschnitt 10.4.14), die im Wesentlichen zeigen soll, dass die Tests alle Quellcode-Anweisungen zumindest einmal ausgeführt haben. Tessy kann ohne zusätzlichen Aufwand höherwertige Überdeckungsmaße wie zum Beispiel Zweigüberdeckung (Branch Coverage) messen, was eher der Forderung nach „Structure-based Testing“ aus Tabelle A.13 der Norm entspricht. Hierbei geht es um den Nachweis, dass – über Anweisungen hinausgehend – weitere Teilmengen der Programmstruktur, beispielsweise Programmzweige, während der Tests ausgeführt wurden. Im vorliegenden Projekt führten die Verantwortlichen eine Messung der Zweigüberdeckung durch, wobei sie insgesamt (mit ungefähr 1500 Testfällen) eine Überdeckung von 98,8 Prozent verzeichneten. Die restlichen 1,2 Prozent überprüften sie manuell.

Ausgelagertes Testen

Die Norm DIN EN 50128 enthält Vorschriften zur Software-Entwicklung für Schienenfahrzeuge. Der Softwaretest muss hierbei auch auf Modulbasis erfolgen. Friedrich Lütze beauftragte die Firma Hitex als Dienstleister, die Software für ein I/O-System zu testen, das in Schienenfahrzeugen zum Einsatz kommt. Ausgelagertes Testen erfordert besondere organisatorische Maßnahmen und Prozesse. Diese Prozesse definierten und lebten Lütze und Hitex gemeinsam. Wichtig ist hierbei eine gute Kommunikation mit definierten Ansprechpartnern und klaren Zuständigkeiten auf beiden Seiten. Die Auslagerung der Modultestdurchführung hat mit zum Projekterfolg beigetragen, und Hitex arbeitet bereits an einem weiteren Testprojekt von Lütze.