Qualitätssicherung Wie prüft ein Hersteller von Testwerkzeugen seine Produkte?

Autor / Redakteur: Erol Simsek * / Franz Graser

Für sicherheitskritische Anwendungsfelder müssen die Tool-Hersteller ihre Softwarewerkzeuge rigorosen Tests unterziehen. Von dieser Erfahrung können auch die Kunden profitieren.

Anbieter zum Thema

Tool-Teststand für automatisierte Regressionstests, die auf unterschiedlichen Hardware-Plattformen und Zielsystemen ausgeführt werden. Auch Kundensysteme sind Teil der drei Teststände, die jeweils bis zu 24 Komplettsysteme (BlueBox und Zielsystem) beinhalten.
Tool-Teststand für automatisierte Regressionstests, die auf unterschiedlichen Hardware-Plattformen und Zielsystemen ausgeführt werden. Auch Kundensysteme sind Teil der drei Teststände, die jeweils bis zu 24 Komplettsysteme (BlueBox und Zielsystem) beinhalten.
(Bild: iSystem)

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 sogenannte dynamische Tests erweitert. In diesen weiterführenden Tests werden Speicher, Speichzugriffszeiten und Peripherie gleichermaßen geprüft. Hier stellt iSYSTEM sein Know-how auch Partnerfirmen zur Verfügung.

Das Generieren von neuer Software, Archivieren von alten und Testen von bestimmten Softwareständen sowie ein funktionierendes Versionskontrollsystem stehen beim Testen der Software im Mittelpunkt. Durch die steigende Komplexität der Software, immer neue Microcontroller und Erweiterungen des Funktionsumfangs ist eine Automatisierung der Tests erforderlich. Eine weitere Motivation für die Testautomatisierung sind die funktionalen Sicherheitsstandards, die intensive Tests fordern. Damit schafft der Tool-Hersteller eine Vertrauensbasis für seine Produkte.

Ergänzendes zum Thema
Interview mit Erol Simsek
„Testtools müssen einfach in den Prüfprozess integrierbar sein“

Erol Simsek, Vorstandssprecher der iSYSTEM AG.
Erol Simsek, Vorstandssprecher der iSYSTEM AG.
( Bild: iSYSTEM )

Im Gespräch: Erol Simsek, Vorstandssprecher der iSYSTEM AG, über die Notwendigkeit von Tests im Embedded-Umfeld und die Integration von Tests in den Entwicklungsprozess.

Welche Herausforderungen für Entwickler und Tester beantwortet die Toolsuite fitIDEA?

fitIDEA ist zunächst einmal die interne Umsetzung des iSYSTEM Softwareentwicklungs- und Testprozesses. Wir entwickeln in großen Teilen agil und leben den Prozess der Continous Integration. Hierfür sind wir das Thema Testautomatisierung konsequent angegangen. Des weiteren ist fitIDEA eine Umgebung zur Nachweiserbringung der Korrektheit von iSYSTEM-Toolfunktionalitäten gemäß bestimmter Use Cases, meist kundenspezifisch. Im Rahmen von Standards der funktionalen Sicherheit wird dies zum Teil verlangt.

Was macht ein gutes Testwerkzeug aus?

Das ist schwer zu verallgemeinern. Es gibt ja unterschiedlichste Werkzeuge zur Abdeckung verschiedenster Methoden: vom Modellierungstool über statische Codeanalyse, Unit-/Integrationstestwerkzeuge und nicht zu vergessen Systemtesttools. Meist sind es Kombinationen aus Software und Hardware. Am Wichtigsten ist sicherlich die Einfachheit eines Werkzeugs in der Bedienung und der Integration in den Prozess. Dann schafft man Akzeptanz bei Entwicklern und Testern sowie im Management.

Wie kann man die Komplexität heutiger Softwareantwendungen und die Gerätevielfalt testseitig in den Griff bekommen?

Eine Antwort hierfür ist fitIDEA und die gelebte Testautomation im agilen Softwareentwicklungsumfeld. Sprich: Automation und moderne Methodik. Und ab und zu in Richtung Luftfahrt schauen. Hier gibt es viel Erfahrung im Bereich Modellbasiertes/Requirement-basiertes Testen.

Es gibt unterschiedliche Ansätze und Philosophien, was Softwaretests angeht. Welche ist für Sie die interessanteste?

Interessant sind irgendwie alle. Allerdings muss die Methodik auch zum Unternehmen passen und umgekehrt. Agile Softwareentwicklung und die damit verbundene Philosophie des Testens finde ich zur Zeit sehr interessant. Insbesondere deshalb, weil viele eingefahrene Vorgehensweisen und Verhaltensmuster aufgebrochen werden und recht frisch und munter sowie professionell an die Lösung von Softwareherausforderungen jeglicher Art herangegangen wird.

Manche Experten erwarten für die Zukunft, dass die Bedeutung von statischen Analysewerkzeugen steigt. Wird dadurch die Bedeutung von Tests abnehmen?

Stimmt! Die Bedeutung bzw. der Einsatz solcher Tools hat in den letzten 10 Jahren stark zugenommen und nimmt jetzt richtig Fahrt auf. Solche Werkzeuge sind prinzipiell einfach in bestehende Entwicklungs- und Testprozesse einzubauen, ohne den Prozess stark verändern zu müssen. Statische Analyse-Tools decken einen Teil des Testprozesses ab und sind eine sinnvolle Ergänzung zur Erhöhung der Testtiefe.

Testsuite wird mit der Skriptsprache Python angesprochen

iSYSTEM lebt die Testautomatisierung mit fitIDEA, einer Test-Toolsuite, die vollautomatisch die definierten Tests in den Embedded-Systemen ausführt. fitIDEA wurde ursprünglich für interne Zwecke entwickelt. Es benutzt die API (Application Programming Interface) der Entwicklungsumgebung winIDEA (isystem.connect) über die Skriptsprache Python. Hierüber werden alle kritischen Aspekte des Embedded-Debuggers und der integrierten Unit-Test-Toolsuite getestet. Folgende Funktionen werden u. a. geprüft:

  • Standard-Debugging- und IDE-Funktionen wie Download in den Flash-Speicher, Zielsystemspeicherzugriff (Lesen, Schreiben, Echtzeitzugriff), Breakpoint-Funktionen (Ausführung und Zugriff),
  • 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 des Toolsuite basiert auf dem deterministischen Verhalten der Testumgebung, die aus diesen Komponenten besteht:

  • Referenzsystem (Standard-Board vom Halbleiterhersteller, iSYSTEM-Board, Kundensystem),
  • Referenzapplikation für solch ein Board/System,
  • Debugging-Hardware (Blue Box),
  • Software (winIDEA und testIDEA auf der PC-Seite,)
  • Compiler.

Das Schlüsselelement ist die Referenzapplikation für das jeweilige Zielsystem, die so geschrieben ist, dass ein deterministisches (definiertes und reproduzierbares) Verhalten aufgezeigt wird. Zum Beispiel:

char g_c;

void Increment()

{

g_c++;

}

Die Ausführung dieser Funktion erhöht offensichtlich die Variable g_c um eins. fitIDEA macht nun Folgendes:

  • Führe den Code bis zum Aufruf von Increment() aus,
  • Lies den Wert der Variablen g_c,
  • Führe die Funktion bis zum Ende aus,
  • Lies 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 Funktionen wurden mit diesem Test abgedeckt:

  • Erkennen von Code- und Datensymbolen aus der Download-Datei (setze Breakpoints auf symbolische Werte, lies 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 Debuginformationen wurden generiert.

Wenn sich nun eine Komponente der Testumgebung ändert (iSYSTEM-Tool, Compiler, Zielsystem und Ähnliches), muss sich die Applikation immer noch gleich verhalten und das Test-Tool muss weiterhin das gleiche Resultat ausgeben.

Die Python-Testskripte werden von Testingenieuren erstellt. Dabei werden in der iSYSTEM-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:

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

char g_c;

void Increment()

{

g_c++; //rt step_and_evaluate: value[+1]

}

Überblick: Die Software-Architektur für Regressionstests.
Überblick: Die Software-Architektur für Regressionstests.
(Bild: iSYSTEM)

Bis jetzt sind über 60 Hardwarekonfigurationen in den Testständen aktiv, und es sind ca. 100 Testfälle pro Konfiguration vorhanden. Jeder Entwickler hat Zugriff auf alle Konfigurationen und kann auch lokal Tests vornehmen, bevor er seinen geänderten Programmcode übernimmt. Die automatischen Tests werden über Nacht ausgeführt. Die Testergebnisse sind am nächsten Morgen verfügbar. Somit steht einer nahtlosen Integration nichts mehr im Weg. Es werden kontinuierlich neue Testfälle hinzugefügt, deren Basis entweder neue Funktionen, Anwendungsfälle von Kunden oder gelöste Supportfälle sind. Die Benefits liegen auf der Hand:

  • Neue Software kann schneller verifiziert werden,
  • Stabilere Software-Traceability und Dokumentation,
  • CEO und CTO schlafen ruhiger,
  • Transparenter Testprozess für den Kunden.

Kunden können komplette Testumgebung nutzen

Der Kunde kann fitIDEA im eigenen Unternehmen einsetzen. Mit der Ausführungsplattform erhält er zusätzlich ein Referenzboard und eine Referenzapplikation mit den zugehörigen Testskripten für den jeweiligen Microcontroller. Dieses Referenzdesign mit den zugehörigen Testskripten wird Schritt für Schritt auf die Hard- und Software der Kunden übertragen. Die Tests werden entsprechend erweitert und angepasst.

Am Ende besitzt der Kunde eine komplette Testumgebung für seine Hardware und Applikationssoftware, in der er immer wieder alle Komponenten sehr schnell und effizient testen kann. Der Test nach Austausch oder Veränderung einer Komponente wie einer neuen Compiler- oder einer neuen Hardwareversion ist schnell umzusetzen. Abweichungen sind sofort ersichtlich.

Standards der funktionalen Sicherheit verankern interessanterweise mehr und mehr die Qualifizierung von Softwarewerkzeugen. Das bedeutet, dass man sich im Vorfeld einer Entwicklung über das Risiko des Einsatzes von Softwarewerkzeugen auf bestimmte Anforderungen und „Use Cases“ hin Gedanken machen muss.

Der Tool-Hersteller wird hierbei nicht ausgeklammert. Das heißt: Es ist zu erwarten, dass diese Hersteller entsprechende Verbesserungen und Erweiterungen der eigenen Entwicklungs- und Test-Prozesse implementieren. iSYSTEM hat seine Prozesse bereits auf diese Entwicklungen hin ausgerichtet und lebt einen agilen Softwareentwicklungsprozess mit einer transparenten Testautomatisierung. //FG

* * Erol Simsek ist Vorstandssprecher der iSYSTEM AG mit Sitz in Schwabhausen in der Nähe von München.

(ID:37126660)