Unit-Tests auf Systemen mit eingeschränkten Ressourcen

Sehr geehrte Leserinnen und Leser

aus aktuellem Anlass geht es in diesem Beitrag um das Thema Unit-Test (auch Modultest genannt). Unit-Tests sind bekanntlich ein wesentlicher Bestandteil der Qualitätssicherung in der Softwareentwicklung. Wie der Name schon andeutet werden dabei funktionale Einzelteile (Module) der Software auf korrekte Funktionalität und Robustheit gegenüber z.B. ungültiger Parameter geprüft.

Speziell im Embedded Bereich gibt es zwei grundlegende Ansätze für die Durchführung, nämlich die Ausführung der Tests auf dem Zielsystem/Target (Online) oder auf dem Hostsystem (Offline). Während die am meisten verbreiteten kommerziellen Werkzeuge Cantata und TESSY beide Möglichkeiten anbieten, ermöglichen die etwas preiswerteren bzw. freien Systeme meist nur Offline-Tests.

Dabei gibt es gute Gründe für Tests auf dem Zielsystem:

  • Nur dann kommt für Test- und Normalversion der gleiche Compiler zum Einsatz und Interpretationsfreiheiten der Compilerhersteller haben keinen Einfluss mehr. Zum Beispiel können Datenbreite und Endianess auf dem Host- und Targetsystem unterschiedlich sein.
  • Nur dann ist es möglich auch Fehler der Compiler selbst oder Fehler in deren Standardbibliothek zu finden.
  • Gemischter Code, also zum Beispiel C und Assembler, kann mit vertretbarem Aufwand nur auf dem Target getestet werden.
  • Betriebssystem Funktionsaufrufe müssen ggf. nicht durch Stubs ersetzt werden.
  • Das Laufzeitverhalten entspricht der (meist traurigen) Realität und nicht dem erheblich schnelleren Hostsystem. Sehr wichtig zum Beispiel bei zeit- oder Hardware-getriggerten Funktionen.
  • die relevanten Normen (z.B. ISO 26262) raten dazu.

Gegen Tests auf dem Zielsystem sprechen in der Regel

  • der insgesamt höhere Aufwand.
  • die eingeschränkten Möglichkeiten des Targets bzgl. Anzeigen und Kommunikation mit dem Host. Denn schließlich können auf dem Embedded System die Testergebnisse nicht einfach auf dem Monitor angezeigt werden.
  • die eingeschränkten Ressourcen (Speicher, CPU, Timing usw.) auf dem Zielsystem.

Was den letzten Punkt angeht, stoßen besonders die viel gelobten kommerziellen Tools schnell an Grenzen. Nur die wenigsten, auf minimalen Hardware Einsatz getrimmten Embedded Projekte, bei denen um jedes Byte und jede Mikrosekunde gefeilscht wird, vertragen noch zusätzlich einen aufgeblähten Testcode. Ganz zu schweigen wenn Kommunikationsstandards jenseits von CAN, Flexray und Ethernet zum Einsatz kommen sollen.

Genau hier setzt das von OKN entwickelte Unit-Testsystem an.
Möchten Sie mehr erfahren ?

Bitte rufen Sie uns an …