Suchen

Seminar Der Weg zur umfassenden Teststrategie

Autor / Redakteur: Stuart Cording * / Franz Graser

Wie soll eine integrierte Teststrategie für eingebettete Software aussehen, die eine hohe Testabdeckung gewährleistet, aber auch Aspekte wie die Benutzerführung berücksichtigt?

Firmen zum Thema

Modellbasiertes Testen: Die MBTsuite erzeugt Testreihen, mit denen der jeweils im Projekt gefordere Testabdeckungsgrad erreicht werden kann.
Modellbasiertes Testen: Die MBTsuite erzeugt Testreihen, mit denen der jeweils im Projekt gefordere Testabdeckungsgrad erreicht werden kann.
(Bild: sepp.med)

Würden Sie Ihr Leben in die Hand einer von Ihnen selbst entwickelten Software für eingebettete Systeme legen? Sind Sie zu 100 Prozent sicher, dass sie sich bei jeder Ausführung akkurat und wie vorgesehen verhält? Das mag wie ein unerreichbares Ziel erscheinen, entspricht aber der Erwartung an Software, die in den mit Elektronik vollgestopften Fahrzeugen von heute zu finden ist.

Wir verlassen uns darauf, dass diese Software in scheinbar trivialen Geräten wie elektrischen Fensterhebern bis hin zu komplexeren Systemen wie der elektrischen Feststellbremse und dem Airbag von Anfang an jedes Mal fehlerfrei arbeitet. Ganz davon zu schweigen, dass sie das über zehn bis zwanzig Jahre tun muss.

Testwerkzeuge für den Quelltext werden oft als teuer und kompliziert angesehen. Damit sich solche Investitionen trotzdem lohnen, ist die Ausbildung von bestimmten Personen im Team zu Test-Experten notwendig. In kleinen bis mittleren Unternehmen werden die Test-Tools oft schon von vornherein ad acta gelegt, weil die Mitglieder des Engineering-Teams bereits bis an ihre Grenzen mit Entwicklungs- und Unterstützungsaufgaben ausgelastet sind.

Dass hier am falschen Ende gespart wird, ist dennoch allen Beteiligten bewusst. Glücklicherweise findet auf dem Gebiet der Mikrocontrollerentwicklung eine Art Standardisierung in Richtung von ARMs Cortex-M-Konzepten als Herzstück eines Mikrocontrollers (MCU) statt. Einher geht damit auch die Angleichung des Zugangs zum Mikrocontroller (Debugging-Interface wie JTAG oder ETM bei ARM-MCUs) und eröffnet neue Möglichkeiten das Testen auf einfache Weise in den Entwicklungsablauf von eingebetteter Software zu integrieren.

Mit dieser Standardisierung kommt ARMs Debugging-Technik mit dem Namen CoreSight ins Spiel. CoreSight definiert die notwendigen Eigenschaften einen Prozessor zu debuggen, den Flash-Speicher des Gerätes zu programmieren sowie auf die Register und Speicher der MCU zuzugreifen.

Zusätzlich kann, in Abhängigkeit von dem tatsächlich implementierten Debug-Interface (in Bezug auf die Anzahl von nach außen geführten Pins und interner Logik), auch die Nachverfolgung der Ausführung des Programmcodes und die Zugriffe auf den Datenspeicher unterstützt werden. Folgende Tabelle bietet eine Liste der angebotenen Optionen, Vorteile und Nachteile.

Nachverfolgungs-Technik Typischer ARM-Kern
Vorteile Nachteile
MTB - Micro Trace Buffer
Cortex M0+
- Leicht zu konfigurieren
- Kommuniziert über existierendes Debud-Interface (SWO)
- Keine Echtzeit
- Erfordert Teile des SRAM der MCU
- Auf kurze Code-Sektionen begrenzt
ITM - Instrument Trace Macrocell
Cortex M3/M4
- Kommuniziert über existierendes Debug-Interface (SWO)
- Trace-Granularität beschränkt auf Instrumentierungs-Punkte
ETM - Embedded Trace Macrocell
Cortex M3/M4
- Volle Echtzeit-Programmverfolgung
- Erfordert I/O-Pins von der MCU (typ. 4)
ETM - Embedded Trace Macrocell
Cortex M7
- Volle Echtzeit-Programmverfolgung
plus Datenverfolgung
- Erfordert I/O-Pins von der MCU (typ. 4)

Je nachdem wie gut ein Entwicklungswerkzeug die im Silizium umgesetzte CoreSight-Technologie unterstützt, kann ein Entwickler den Applikationscode debuggen und gleichzeitig dessen Funktionalität systematisch testen.

Das Integrationswerkzeug Jenkins hilft dabei, die Testreihen zu automatisieren.
Das Integrationswerkzeug Jenkins hilft dabei, die Testreihen zu automatisieren.
(Bild: Jenkins-Screenshot/iSYSTEM)

Auf der einfachsten Ebene wird z.B. ein Unit-Test geschrieben, der sicherstellt, dass eine einzelne Funktion wie spezifiziert abläuft. Ein Funktionsaufruf, der zum Beispiel das Puls-Pausenverhältnis der Pulsweitenmodulation für die Kontrolle eines industriellen Ofens berechnen soll, kann über Unit-Tests, die eine Liste mit Eingabewerten bereitstellen und die zurückgegebenen Ergebnisse mit den erwarteten Werten vergleichen, getestet werde. Im Entwicklungsablauf werden solche Tests geschrieben , sobald der entsprechende Programmcode fertiggestellt und im zentralen Code-Repository gespeichert ist (zum Beispiel Git, SVN und dergleichen).

Wenn später der Code für ein anderes Projekt wiederverwendet wird oder Änderungen am Quellcode nötig sein sollten, können die Unit-Tests wieder ausgeführt werden, um sicherzustellen, dass die ursprünglich notwendige Funktionalität nicht verändert wurde. Die BlueBox-On-Chip-Analyzer von iSYSTEM machen es zusammen mit der Software testIDEA einfach, solche Tests zu definieren und auszuführen. Zusätzlich werden diese Tests mithilfe der OBC-Methode (Original Binary Code) auf der Ziel-MCU ausgeführt, was sicherstellt, dass der Code nicht nur funktioniert, sondern auch auf der von Ihnen ausgewählten MCU-Plattform korrekt abläuft.

Selbst die Ausführung der Tests muss nicht bedeuten, dass wertvolle Engineering-Zeit verbraucht wird. Mit den aktuellen Änderungen und Fehlerbehebungen, die in ein Code-Repository eingespielt wurden, kann ein Werkzeug für kontinuierliche Integration wie Jenkins den neuesten Code auschecken, die Projekte kompilieren und die testIDEA-Prüfungen über Nacht ausführen. Alles, was für Sie zu tun bleibt, ist, am nächsten Morgen ins Büro zu kommen und die Jenkins-Anzeige auf Builds und eventuell fehlgeschlagene Tests zu prüfen.

Der Pfad zur bestmöglichen Testabdeckung

Codeumfang und Komplexität steigen zunehmend. Es wird dadurch immer schwieriger, die „richtigen“ Tests zu definieren, die die höchstmögliche Testabdeckung liefern. Wann ist man mit dem Testen fertig und haben wir auch jeden denkbare Anwendungsfall berücksichtigt?

Stellen Sie sich beispielsweise das Menüsystem einer Industriesteuerung vor. Tests zu entwickeln, die nacheinander alle möglichen Menüoptionen durchgehen und gewährleisten, ist noch vergleichsweise einfach.

Aber was ist mit realistischen Anwendungsbedingungen, wenn man etwa aus den Menüeinstellungen zurückkommt, um eine vorher festgelegte Einstellung zu ändern oder zu korrigieren? In diesem Fall wächst die Zahl der möglichen Permutationen von Testpfaden exponentiell an. Anstelle all die möglichen Tests manuell herauszufinden, ist es aus unserer Sicht sinnvoller, eine Methodologie zu verwenden, die das für uns erledigt. Ein Konzept ist das modellbasierte Testen, das die Grundlage des Testdesign-Werkzeuges MBTsuite von sepp.med bildet.

Die Rolle des modellbasierten Testens

Der Grundgedanke ist einfach: Beginne mit den definierten Anforderungen an das Produkt, modelliere die Funktionalität mit Hilfe eines UML-Werkzeugs wie zum Beispiel Enterprise Architect von Sparx Systems. Bei der Modellierung Ihres Systems können Prüfpunkte hinzugefügt werden. Das kann der Status einer LED oder eines LCD-Displays sein, könnten aber auch den Inhalt einer Variablen oder eines Arrays im Code ihrer Applikation einschließen, wenn Sie den BlueBox-Test-Analyzer zusammen mit testIDEA nutzen.

Sobald das Modell annähernd vollständig ist, kann die MBTsuite benutzt werden, um einen Testplan zu generieren, der auf dem Modell basiert, entweder als dokumentierter Prozess, der von einem Tester ausgedruckt und Schritt für Schritt abgehakt, oder als Python-Skript, das als Teil eines automatisierten Testsystems wie Jenkins ausgeführt wird. MBTsuite kann zudem Tests erzeugen, die unterschiedliche Grade von Testabdeckung erreichen, so etwa:

  • Smoke-Test: Einfache und kurze Testreihen, die genutzt werden können, um zu gewährleisten, dass das Ziel- und das Testsystem wie erwartet arbeiten
  • Regressionstest: Umfassende Testreihen mit einem hohen Testabdeckungsgrad, die benutzt werden, um den Erfolg von neu hinzugefügten Features oder Bugfixes zu bestätigen
  • Langzeittest: Höchstwahrscheinlich eine zyklische Testart oder Tests, die darauf ausgelegt sind, viele Stunden, Tage oder Wochen zu laufen, um die langfristige Zuverlässigkeit des Systems zu bestimmen.

Ein MBTsuite-Modell kann so konfiguriert werden, dass die Skriptfähigkeit von testIDEA dazu verwendet werden kann, Python-Aufrufe in geeignete Teile der Tests oder Prüfpunkte einzusetzen. Indem man zudem die Nachverfolgung über die Trace-Module MTB oder ETM der ARM-Mikrocontroller aktiviert, kann die Codeabdeckung für die Tests ebenfalls gemessen werden. Zuletzt können die BlueBox-On-Chip-Analyzer von iSYSTEM mit einem analog/digitalen Input/Output-Modul namens IOM ausgestattet werden, das ihnen erlaubt, Stimuli in einer eng begrenzten Hardware-in-the-Loop-Umgebung zu erzeugen und zu messen.

Alle diese Konzepte werden in dem Seminar „Erst der Test beendet die Entwicklung“ zusammengebracht, das in den kommenden Monaten in ganz Europa angeboten wird. In diesem Seminar werden zuerst die Erwartungen verschiedener internationaler Standards (so wie ISO 26262) im Hinblick auf Tests berücksichtigt, bevor demonstriert wird, wie Enterprise Architect, MBTsuite, Jenkins und testIDEA zusammen mit einem BlueBox-On-Chip-Analyzer und einem ARM-Mikrocontroller gemeinsam genutzt werden können, um zu gewährleisten, dass Ihre eingebetteten Systeme sicherer und zuverlässiger sind und weiterhin den hohen Qualitätsstandards genügen, den Ihre Kunden mit Recht erwarten.

* Stuart Cording ... ist Technical Marketing Manager der iSYSTEM AG mit Sitz in Schwabhausen in der Nähe von München.

(ID:44250993)