Software-Test

  1. Vorwort

    • Zur Begriffsklärung siehe auch SW-Test, Test-Nomenklatur.
    • Tests von eingebetteter Software in der Automotivindustrie greifen auf den Speicherbereich des Steuergeräts zu. Im AGS-Projekt z.B. erfolgt dieser Zugriff über Tools wie INCA, Diagnose-Tools. Auf jeden Fall ist es dem Tester jederzeit möglich, die Software als White-Box zu betrachten, auch wenn ein Black-Box-Verfahren in der Regel die Grundlage der Testdefinition bildet.

  2. Funktionaler Test

    Ein Schwerpunkt der Tätigkeit seit dem Anfang der 2000er Jahre ist die Definition, Dokumentation, Implementierung und Pflege von funktionalen Tests.
    (Anm.: Ich erwarb 2005 das ISTQB-Zertifikat Certified Tester Foundation Level und 2006 das ISTQB-Zertifikat Certified Tester Advanced Level, Functional Tester).

    Wenn ein Lastenheft, Pflichtenheft, oder andere gut dokumentierte Unterlagen zur Software-Spezifikation - in welcher Form auch immer - dem Testerteam vorliegt, kommen Black-Box-Verfahren zur Erstellung einer Testspezifikation in Frage.

    1. Integrationstest im AGS-Projekt:
      Das AGS-Softwaremodul ist eingebettet in einem Steuergerät. Es liest am Anfang eines jeden Berechnungszyklus u.a. den aktuellen Wert von CAN-Bus-Signalen auf der sogenannten Layer-In-Schnittstelle. Die Handhabung der Signale an der Schnittstelle wird genau spezifiziert:

      • Die Layer-In-Spezifikationen liegen in etlichen Formaten (PDF, DOC, XLS, XML, usw.) bereit - je nach beabsichtigter Auswertung.
      • Auch die Bordnetzdatenbank - zur Beschreibung aller Nachrichten und zugehöriger Signale auf CAN-Bussen - wird in etlichen Formaten exportiert.

      Aus den Datenquellen generiert ein Perl-Programm pro Schnittstelle ein Testskript (Testpaket), das vom ECUTT am HiL-Prüfstand durchgeführt wird. Die Testfälle werden auf der Basis von Black Box -Verfahren generiert: Äquivalenzklassenbildung, Grenzwertanalyse.

      Weitere Infos zum AGS-Projekt sind folgenden Links zu entnehmen: Eckdaten, Kurzbeschreibung.

    2. GUI-Test des Multiplate© Analyzer:
      In diesem Projekt wurden in kleinem Kreis Lastenheft, Pflichtenheft und eine dazugehörige Testspezifikation nacheinander erarbeitet. Die in diesem Rahmen entwickelten GUI-Tests sind Anwendungsfallbasierte Tests.

      Weitere Infos zum Projekt 'Definition von Tests fürs Multiplate© Analyzer' sind folgenden Links zu entnehmen: Eckdaten, Kurzbeschreibung.

    3. Test von Chip Karten:
      In diesem Anwendungsbereich sorgen maßgebliche Software-Spezifikationen - z.B. GlobalPlatform, Java Card, ETSI - dafür, dass die Implementierung aller Kartenhersteller weltweit interoperabel sind.

      1. Systemtest

        • Die Tests gegen die GlobalPlatform-Spezifikation sind APDU-Tests.
          Um manchen Funktionen zu testen - z.B. den Datenaustausch zwischen Applets - mussten z.T. komplexe (realitätsnahe) Testapplets geschrieben werden.

          Im Rahmen von zwei Pilotprojekten in den Jahren 2005, 2006 wurden kritische Teile von GlobalPlatform - u.a. der Command Dispatcher - mit Hilfe der B-Methode, einer Formalsprache zur Beschreibung von Softwarespezifikationen, modelliert.
          Diese Vorhaben wurden in enger Zusammenarbeit mit der Firma LEIRIOS (u.a. mit Eddie Jaffuel) durchgeführt, die ein Tool, den LEIRIOS Test Generator (LTG), vermarkt, das B-Modelle lesen kann und daraus, Funktionstests definiert. Über Konfigurations-Parameter wird der Umfang der definierten Testsfälle gesteuert.
          Im Vergleich dazu sah der Standardprozess vor, dass der Testentwickler seine Tests manuell definiert und im Anschluss dazu sie gegenüber der zugeordneten Anforderung in DOORS einträgt. Um sicherzustellen, dass keine Lücke (nicht getestete Anforderung) entsteht, schreibt der Prozess aufwendige Maßnahmen - insbesondere Reviews - vor.

        • Um die Datenverschlüsselungsmechanismen nach ETSI zu testen wurde in C++ eine realitätsnahe Testapplikation auf der Terminalseite entwickelt.

        Zur Definition der Tests werden folgende Black-Box-Verfahren herangezogen: Zustandsbezogener Test, Ursache-Wirkungs-Graph-Analyse, Anwendungsfallbasierter Test.

        Weitere Infos sind den Links in folgender Tabelle zu entnehmen:

        Projekt- Nr. Titel Zeitraum
        Projekt [19] Verschlüsselter Datenaustausch nach ETSI (2007)
        Projekt [18] Formale Modellierung von GlobalPlatform (2005-2006)
        Projekt [17] APDU-Tests für GlobalPlatform (2004-2005)
        Projekt [15] APDU-Tests für Globalplatform (2002-2003)
        Projekt [14] APDU-Tests für OpenPlatform (2001-2002)
        Tab. Eckdaten von Projekten

      2. Modultest

        Die Tests gegen die Java Card-Spezifikation sind API-Tests. Zur Definition der Tests werden folgende Black-Box-Verfahren herangezogen: Äquivalenzklassenbildung, Grenzwertanalyse.

        Weitere Infos sind folgenden Links zu entnehmen: Eckdaten von Projekt 'API-Tests für JavaCard' (2003-2004).

  3. White Box Test

    Der White Box Test wird oft dem Entwicklertest zugeordnet, da seine Definition Zugang zum Quelltext voraussetzt - siehe auch Test-Nomenklatur.

    1. Modultest im AGS-Projekt:

      • Ein Teil der Module liegt nur als C-Quelltext vor.
      • Ein Teil der Module wird mit MATLAB und Simulink modelliert. Wenn vorhanden, gelten diese Modelle als perfekte Abbildung der Softwarelogik.

      Aus diesen Quellen wird - manuell - eine Menge von Testfällen bzw. Testszenarien definiert. D.h. Testschritte werden in einem zugeordneten Testskript zusammengefasst, das vom ECU-Testtool am HiL-Prüfstand durchgeführt wird. Ist ein Modul komplex, wird es in Untermodule aufgeteilt. D.h. ihm werden mehrere Testskripte zugeordnet.

      Das Verfahren zur Definition der Testfälle verwendet übliche Kriterien der Überdeckung der Ablauflogik - wobei die Fälle - hinsichtlich Zeitplanung, Aufwand, Beurteilung - priorisiert werden, wie es z.B. in anwendungsorientierten-Verfahren üblich ist: Es geht also nicht darum, die Module systematisch zu verifizieren, sondern sie in Standardsituationen zu validieren.

      Weitere Infos zum AGS-Projekt sind folgenden Links zu entnehmen: Eckdaten, Kurzbeschreibung.

  4. Referenzen zum Thema 'Softwaretests'

    Vgl. Seite Khelil: Referenzen zu SW-Test.