Entwicklungs-Tools & Prototyping Wie ein Toolhersteller testet

Dem Vertrauen in den Umgang mit Softwarewerkzeugen (Confidence in the use of software tools) widmet sich Kapitel 8-11 der ISO26262, eine für Automotive speziell „angepasste“ Version der IEC61508. Außer auf die Automobilhersteller und deren Zulieferer, hat diese Norm auch konkrete Auswirkungen auf die Entwicklungs- und Testprozesse der Werkzeughersteller und damit wiederum auf den entsprechenden Entstehungsprozess des Softwarewerkzeugs selbst. Dieser Beitrag beschreibt die organisatorischen und technischen Maßnahmen, die ein Hersteller von Embedded-Entwicklungswerkzeugen im Bereich Debugger und Softwaretest aus aktuellen Normen der funktionalen Sicherheit abgeleitet hat, um die Softwareentwicklungsabteilungen im Vorfeld und insbesondere bei der so genannten Tool-Qualifizierung zu unterstützen. Die diskutierten Maßnahmen haben dabei einen nachhaltigen Effekt auf den Entwicklungs- und Testprozess eines Softwarewerkzeugherstellers dahingehend, dass Prozesse überdacht und optimiert werden und noch mehr Transparenz über diese Prozesse nach außen hin geschaffen wird. Diese Transparenz lässt sich am effizientesten durch den Einsatz von Testautomatisierung erreichen. Interessant sind auch die mit eingeflossenen Aspekte der agilen Softwareentwicklung und der Umsetzung des Prozesses der „Continuous Integration“ im Zusammenspiel mit Testautomation.

Wie wird heute beim Toolhersteller getestet?

Ausgangspunkt für qualitativ hochwertige Soft- und Hardware sind interne Prozessdefinitionen, die genau beschreiben wie diese Produkte entwickelt werden müssen. Im Hardwarebereich werden optische Testsysteme und Boundary Scan Tests bereits seit Jahren eingesetzt und um so genannte dynamische Tests erweitert. In diesen weiterführenden Tests werden Speicher, Speichzugriffszeiten und Peripherie gleichermaßen im Testbetrieb getestet, wobei um bestimmte Geschwindigkeiten zu erreichen, der Mikrocontroller auf dem Testsystem benutzt wird. Das Generieren von neuer Software, Archivieren von alten und Testen von bestimmten Softwareständen, sowie ein funktionierendes Versionskontroll-System stehen beim Testen der Software im Mittelpunkt. Durch die steigende Komplexität der Software, durch immer neue Microcontroller und Erweiterungen der Funktionalitäten ist eine Automatisierung der Tests erforderlich. Eine weitere Motivation für die Testautomatisierung sind Standards der funktionalen Sicherheit, die ein intensives Testen im Allgemeinen und die Qualifizierung von einzusetzenden Softwarewerkzeugen im Speziellen, fordern. iSystem lebt Testautomatisierung im Entwicklungsprozess. Basis ist eine selbstentwickelte Test Tool Suite, die vollautomatisch entsprechend definierte Tests in den Embedded-Systemen durchführt. Embedded-Systeme sind hierbei die Softwareentwicklungs- und testwerkzeuge selbst. iSystem ist unabhängiger Hersteller und Anbieter von Werkzeugen für Embedded-Software-Entwicklung und -Test. Im Prinzip handelt es sich um Debug- und Analysewerkzeuge für Embedded-Software-Entwicklung. Mittels Debug-Technologie wird der schnelle Zugriff auf jegliche Art von Mikrocontroller über die unterschiedlichsten Ausprägungen von Debug-Schnittstellen gewährleistet. Dabei ist es egal, ob Embedded-Software entwickelt oder direkt auf dem Ziel ohne Code-Instrumentierung getestet wird. Solche Werkzeuge werden also sowohl zur Entwicklung als auch zur Fehlersuche eingesetzt. Das akkurate Verhalten dieser Werkzeuge im Entwicklungs- und Testprozess ist deshalb sehr wichtig. Den entsprechenden Nachweis zu erbringen, liegt meist beim Kunden selbst. Eine im Entwicklungsprozess dieser Softwarewerkzeuge eingebaute Testautomatisierung unterstützt die Kunden hierbei. Die Testautomatisierung verwendet direkt das nach außen offene und generische API (Application Programming Interface) der eigentlichen Entwicklungsumgebung. Die Ansteuerung erfolgt über die Skriptsprache Phython. Hierüber werden alle kritischen Aspekte des Embedded-Software-Debuggers und der integrierten Unit Test Tool Suite getestet. Folgende Funktionalitäten werden z. B. überprüft:

Standard-Debugging und IDE-Funktionen wie Download in den Flash-Speicher, Zielsystemspeicherzugriff (lesen, schreiben, Echtzeitzugriff), Breakpoint-Funktionen Spezielle Zeitmessungen zum Test von weiterführendem Debugging wie Trace und Profiler-Funktionalität. Software-Test mit Code-Coverage- und Unit-Test API-Funktionalität

Das Konzept der Test Tool Suite basiert auf dem deterministischen Verhalten der Testumgebung, die aus folgenden Komponenten besteht Referenzsystem (Standard Board vom Halbleiterhersteller, Kundensystem, �?�),Referenzapplikation für solch ein Board/System, iSystem Debugging Hardware (Blue Box), iSystem-Software auf der PC-Seite undCompiler. Das Schlüsselelement ist die Referenzapplikation für das entsprechende Zielsystem, die so geschrieben ist, dass ein deterministisches (definiertes und reproduzierbares) Verhalten aufgezeigt wird. Zum Beispiel: charg_c; void Increment() { g_c++; } Die Ausführung dieser Funktion erhöht offensichtlich die Variable g_c um eins. Die Test Tool Suite führt nun Folgendes aus:

Führe den Code bis zum Aufruf von Increment() aus, lese den Wert der Variablen g_c, führe die Funktion bis zum Ende aus, lese den Wert der Variablen g_c.

Der Test war erfolgreich, wenn das zweite Lesen der variablen g_c einen um eins erhöhten Wert anzeigt. Folgende Funktionalitäten wurden mit diesem Test abgedeckt:

Erkennen von Code- und Datensymbolen aus der Download-Datei (setze Breakpoints auf symbolische Werte, lese Variablenwerte über symbolische Namen), Unterbrechung der Ausführung (ein Breakpoint wurde auf den Funktionseintritt und -austritt gesetzt), Ausführung des Codes und Überprüfung des CPU Status (Run Until, warten bis die CPU stoppt) Speicherlesezugriff (lesen der Variablenwerte), C-Compiler: Code- und Debug-Informationen wurden generiert.

Wenn sich nun eine Komponente der Testumgebung ändert, muss sich die Applikation immer noch gleich verhalten und die Test Tool Suite muss weiterhin dasselbe Resultat ausgeben. Die Phython-Testskripte werden von speziellen Testingenieuren erstellt. Dabei werden in einer Referenzapplikation Referenzkommandos (//rt) benutzt, um erwartete Ergebnisse eines Tests zu speichern. Diese Referenzen werden im Quellcode hinterlegt und sind somit unabhängig vom benutzen Compiler charg_c; void Increment() { g_c++; //rtstep_and_evaluate: value[+1] } Bis jetzt sind über 60 Hardwarekonfigurationen in den Testständen für Testzwecke aktiv und etwa hundert Testfälle pro Konfiguration vorhanden. Und es werden kontinuierlich neue Testfälle hinzugefügt, deren Basis entweder neue Funktionalitäten, Anwendungsfälle von Kunden oder gelöste Supportfälle sind.