Testautomatisierung Komponententest für sicherheitsrelevante Software

Autor / Redakteur: Reinhold Schmid * / Franz Graser

Bei Komponententests werden die Einzelteile eines Softwaresystems auf ihre Korrektheit getestet. Zur Zeit erfolgen diese Tests noch überwiegend händisch. Der Artikel stellt einen Automatisierungsansatz vor.

Firmen zum Thema

Bild 1: Beim Testwerkzeug GAIO CoverageMaster wird die zu testende Software auf einem MPU-Simulator ausgeführt. Das Erstellen einer speziellen Testapplikation ist nicht nötig. Die Verwendung des MPU-Simulators erlaubt es, die Ausführung des Programmcodes detailliert zu überwachen.
Bild 1: Beim Testwerkzeug GAIO CoverageMaster wird die zu testende Software auf einem MPU-Simulator ausgeführt. Das Erstellen einer speziellen Testapplikation ist nicht nötig. Die Verwendung des MPU-Simulators erlaubt es, die Ausführung des Programmcodes detailliert zu überwachen.
(Bild: GAIO)

Bei der Entwicklung von Systemen und Komponenten, von deren Funktion die Sicherheit der Benutzer abhängt, verlangt der Gesetzgeber die penible Einhaltung von Vorschriften und Standards. Speziell im Automobilbereich, wo das Versagen sicherheitsrelevanter Systeme (Bremsen, Lenkung, Rückhaltesysteme) katastrophale Folgen haben kann, werden strenge Maßstäbe angelegt.

So schreiben Standards wie IEEE 829, IEEE 61508 oder ISO 26262 zwingend vor, dass jede Software vor ihrem Einsatz in solchen Systemen auf funktionaler Ebene zu testen ist. Um einen solchen Komponententest sachgerecht vornehmen zu können, sind zunächst Testumgebung und Teststrategien zu entwickeln sowie Testziele zu formulieren.

Bei der Ausarbeitung des Vorgehens ist es ratsam, sich an den Richtlinien des Software Testing Qualifications Board (ISTQB) zu orientieren. Demach dient der Komponententest dem Aufspüren von Programmfehlern und der Verifikation von Softwaremodulen, Objekten, Klassen und Ähnlichem, sofern sie getrennt vom Rest des Systems testbar sind. Der Test von Komponenten erfolgt mit einer Entwicklungsumgebung. Dabei sollten die Entwickler beteiligt sein, die den zu testenden Code geschrieben haben.

Programmfehler sollen unmittelbar behoben werden

Wird ein Programmfehler identifiziert, soll er laut ISTQB unmittelbar behoben werden, ohne ein formales Fehlermanagement einzuschalten. Aus dieser Definition wird deutlich, dass der Komponententest als integraler Bestandteil des Entwicklungsprozesses zu verstehen ist und eine geeignete Test- und Debugging-Vorrichtung erfordert.

In der Praxis erfolgen Komponententests nur zu einem geringen Teil automatisiert. Der weitaus größere Teil wird händisch erledigt. Das führt dazu, dass viele Fehler nicht während dieser Phase des Entwicklungsprozesses entdeckt werden, sondern erst später in der Phase der Systemintegration ans Licht kommen.

Grundsätzlich gilt: Je später im Entwicklungsprozess ein Fehler entdeckt wird, desto teurer kommt es, ihn zu beheben. Zudem verschlechtert diese Vorgehensweise die Effizienz des Entwicklungsprozesses, während zugleich die Codequalität sinkt.

Die verpflichtende Anwendung von Standards zur funktionalen Sicherheit wie IEC61508 und ISO 26262 ist ein starkes Motiv, der traditionellen Vorgehensweise den Rücken zu kehren und eine stringente Haltung hinsichtlich der Komponententests einzunehmen. Dazu bietet sich der Einsatz des Komponententest-Simulators CoverageMaster winAMS von GAIO Technology an. Die Software unterstützt Entwicklungsabteilungen bei der Erstellung von Teststrategien und erlaubt weitgehend automatische Tests bei Software, die in C und C++ entwickelt wurde.

Vor allem in der Automobilindustrie erfährt dieser Simulator mittlerweile eine hohe Akzeptanz, was nicht zuletzt auf die Einführung von Standards zur Funktionalen Sicherheit wie ISO 26262 zurückzuführen ist. Dieser Standard enthält viele verpflichtende Vorgaben hinsichtlich der funktionalen Sicherheit bei der Abarbeitung des bekannten V-Modells.

Zu diesen Vorgaben gehören auch die Regeln zum Testen von Komponenten. Unternehmen, die diese Vorgaben bereits umgesetzt haben und die Empfehlungen des Standards IEEE 829 zur strukturierten Dokumentation von Software-Lifecycles befolgen, haben in der Regel wenig Probleme mit der Implementierung von Komponententests. Organisationen, die keine klare Grenze zwischen Komponententests und Debugging ziehen, werden sich dagegen wahrscheinlich mit standardgerechten Tests zu Beginn nicht leicht tun. Typischerweise sind drei Hindernisse zu überwinden:

  • Widerstand auf psychologischer Ebene seitens der Entwickler gegen die Übertragung zusätzlicher Aufgaben.
  • Widerstand der Leitungsebene angesichts zusätzlicher Kosten.
  • Einrichten der für das Testen notwendigen Infrastruktur und Prozesse.

Die Einführung von Softwaretests auf der Komponentenebene ist leichter zu verstehen, wenn man das zu entwickelnde Produkt mit einem mechanischen System vergleicht: Beim Bau mechanischer Systeme ist es selbstverständlich, die Komponenten vor der Montage auf Fehler zu inspizieren. Erst wenn die Fehlerfreiheit aller mechanischen Bauteile festgestellt ist, erfolgt die Montage.

Kann diese Fehlerfreiheit nicht festgestellt werden, kann auch keine Garantie für die Funktion des Gesamtsystems übernommen werden. Diese Betrachtung gilt es auf Softwaresysteme und -komponenten zu übertragen. Es genügt indes nicht, den Entwicklern diese Betrachtungsweise näher zu bringen. Selbst wenn sie im Team akzeptiert ist, sind weitere psychologische Hürden zu überwinden. Die Vorstellung, dass Komponententests eine zusätzliche Belastung darstellen, kann der korrekten Ausführung der Tests entgegenwirken. Als Belastung werden vor allem folgende fünf Aufgaben empfunden:

  • Ausarbeitung des Testkonzepts,
  • Ausführung der Tests,
  • Abdeckungserfassung,
  • Zusammenfassung der Ergebnisse in einem Testbericht,
  • Beheben von im Test entdeckten Fehlern.

Je nach Testgegenstand können manche Aufgaben lediglich Zeit in Anspruch nehmen, während andere die Anwendung testbezogener Techniken erfordern. Der richtige Einsatz der GAIO-Tools spart Zeit und eröffnet zusätzliche Möglichkeiten.

(ID:42473999)