Ein neues Framework zum Testen von Kfz-Steuergeräte-Software

Transkript

1 Ein neues Framework zum Testen von Kfz-Steuergeräte-Software Carsten Paulus, Hans-Christian Reuss FKFS {carsten.paulus, Michael Wolff, Peter Feulner ZF Friedrichshafen AG {m.wolff, Zusammenfassung: Der vorliegende Beitrag beschreibt den Aufbau und die Implementierung eines neuen Frameworks zum Testen von Kfz-Steuergeräte- Software, welches die beiden Ziele Qualitätssteigerung durch methodische Testsequenzgenerierung sowie Effizienzsteigerung durch Automatisierung und Wiederverwendung verfolgt. Abstract: The following article describes the structure and the implementation of a new framework for testing automotive control unit software, which follows the objectives quality enhancement by providing methodical test case generation and efficiency enhancement through automation and reuse. 1 Einführung Das Framework wird im Rahmen eines Forschungsprojektes der ZF Friedrichshafen AG gemeinsam mit dem FKFS entwickelt. Die Motivation für die Vorgehensweise liegt darin begründet, den Testprozess weiter zu optimieren und zu standardisieren. Dazu ist insbesondere die methodische Testsequenzerstellung als ein Ausgangspunkt identifiziert worden. Ein weiterer Punkt ist die Einführung einer einheitlichen Testbeschreibungssprache. Diese ermöglicht zum einen die Wiederverwendung der Testmethoden auf verschiedenen Teststufen, zum anderen wird es möglich, die Testinhalte mit allen am Test beteiligten Personen zu kommunizieren und Tests zwischen verschiedenen Testausführungsplattformen zu migrieren. Gliederung Um die Optimierungspotenziale darzustellen wird in Kapitel 2 zunächst der Softwaretestund Entwicklungsprozess beschrieben, wie er bei der ZF Friedrichshafen AG gelebt wird. Es wird aufgezeigt, welche Artefakte aus dem Entwicklungsprozess für den Testprozess relevant sind. In Kapitel 3 werden die verwendeten Methoden für die Testsequenzerstellung vorgestellt. In Kapitel 4 wird der Aufbau des Frameworks und die zur Implementierung verwendete Technologie beschrieben. Um den Nutzen des dargestellten Vorgehens für die Praxis zu verdeutlichen, wird in Kapitel 5 der Einsatz anhand einer Softwarekomponente aus der Steuerungssoftware für ein Automatik-Getriebe für Stadtbusse vorgestellt.

2 2 Softwareentwicklungs- und Testprozess Der Softwareentwicklungsprozess orientiert sich am allgemeinen V-Modell und an Vorgaben aus Automotive-SPICE. Das in Abbildung 1 dargestellte V-Modell beginnt im linken Ast bei der Gesamtanforderungsermittlung und endet im rechten Ast mit der Systemabnahme. Damit stellt dieses systematische Entwicklungsmodell nicht nur die Softwareaspekte dar, sondern alle Entwicklungsschritte, welche beispielsweise zu einem Getriebesystem führen. Gegenstand der folgenden Betrachtungen sind nur die Arbeitsschritte, welche bei der Softwareerstellung relevant sind. In der Software-Anforderungsanalyse Systemabnahme Systemtest System- Architekturdesign Software- Anforderungsanalyse Systemanforderungsanalyse Gesamtanforderungsanalyse Spezifikation Testplanung Testmanagement Durchführung Systemintegration- und Integrationstest Softwaretest Protokollierung Auswertung Software-Design UML MATLAB/ SIMULINK Zustandsdiagramme... C/C++ Software- Erstellung Spezifikation Spezifikation Softwareintegration und Integrationstest Durchführung Modul-Test Durchführung Protokollierung Protokollierung Auswertung Auswertung Abbildung 1: ZF V-Modell und Testprozess. werden die Anforderungen an die zu erstellende Software erfasst. Sie stellen die Grundlage für das Software-Design dar. Das Grobdesign wird dabei in UML erstellt. Es wird entschieden, welche Funktionsblöcke vorhanden sein müssen und in welche Komponenten und Module sich die Software untergliedert. Das Feindesign, welches die eigentliche Funktion der einzelnen Module beschreibt, wird teilweise mit Matlab/Simulink oder ebenfalls in UML erstellt. Der Großteil des Programmcodes wird manuell in C und C++ programmiert. Das Software-Design ist eng mit der Software-Erstellung verwoben. Neben der eigentlichen Erstellung ist in dieser Phase für jedes Modul ein Modul-Test aufzusetzen. In der Softwareintegration und dem Integrationstest geht es darum, die einzelnen Module zu funktionsfähigen Komponenten zu integrieren und sicherzustellen, dass deren Zusammenspiel funktioniert. Die zur Gesamtsoftware integrierten Komponenten werden schließlich im Softwaretest gegen die Softwareanforderungen getestet. Wie Abbildung 1 ebenfalls veranschaulicht, ist der Softwaretestprozess, nach [SL07] in den Entwicklungsprozess integriert. In der Testplanung, werden die organisatorischen Aspekte des Testens berücksichtigt. Typische Tätigkeiten sind die Planung und Verteilung des Resourceneinsatzes (Wer soll wann auf welcher Umgebung welche Tests ausführen?). Weitere Aspekte sind die Auswahl der Teststrategie sowie die Festlegung der Testendekri-

3 terien. In der Testspezifikation werden die Testsequenzen abstrakt erstellt. In dieser Phase unterstützen Testauswahlmethoden den Tester dabei systematisch vorzugehen. Dies ist die für die Qualität der Tests wichtigste Phase, da der Inhalt der Testsequenzen festgelegt wird. Das vorgestellte Framework unterstützt die Entwickler insbesondere in dieser Phase. In der Testausführung werden die spezifizierten Tests zur Ausführung gebracht. Dazu ist es nötig entsprechende Testumgebungen bereitzustellen und entweder Testskripte zu erstellen, um die Tests automatisch ausführen zu können oder die Tests gemäß der Testspezifikation manuell auszuführen. Während der Testausführung muss eine ausführliche Protokollierung stattfinden, um die Tests bei erweiterten Fragestellungen nicht wiederholen zu müssen und die Testauswertung unterstützen zu können. Bei der Auswertung wird entschieden, ob es sich bei gefundenen Fehlern um Fehler in der Testsequenz, der Testumgebung oder wirklich um einen Softwarefehler handelt. 2.1 Testziele und -plattformen Durch die vertikale Teilung des V-Modells entstehen die Teststufen Modultest, Integrationstest und Softwaretest. Auf diesen wiederholen sich die Phasen des Softwaretestprozesses immer wieder aufs Neue. Lediglich die Phase Testplanung ist aus dieser Wiederholung ausgenommen. Auf den verschiedenen Teststufen sind gemäß der Teststrategie vorgegebene Testziele zu erreichen. Dabei kommen unterschiedliche Testausführungsplattformen zum Einsatz. Modultest: Ziel des Modultests ist es, sicherzustellen, dass der Code lesbar und so strukturiert ist, dass er auch wiederverwendet werden kann. Ferner müssen die MISRA C Programmierrichtlinien eingehalten werden. Dies wird mit Hilfe eines statischen Code Analyse Werkzeuges und Reviews erreicht. Ferner ist auf dieser Stufe sicherzustellen, dass der Code technisch funktioniert und kein unbenutzbarer oder unerreichbarer Code programmiert wurde. Dazu wird der Code dynamisch stimuliert und die Kontrollflussüberdeckung bestimmt. In der Testplanung wird projektspezifisch ein zu erreichender Überdeckungsprozentsatz festgelegt. Zur Durchführung, Protokollierung und Auswertung der Tests wird ein Cpp-Unit ähnliches Testframework eingesetzt. Durch die Wahl der Stimuli lassen sich schon hier funktionale Aspekte des Softwaremoduls testen. Integrationstest: Das Testziel für den Integrationstest ist es, sicherzustellen, dass sich die Module reibungslos integrieren lassen und dass das Zusammenspiel wie geplant funktioniert. Im Integrationstest wird typischerweise eine bei der ZF Friedrichshafen AG entwickelte Software-in-the-Loop (SiL) Testumgebung eingesetzt. Tests werden in der für diese Umgebung entwickelten Skriptsprache oder in Python implementiert. Softwaretest: Ziel des Softwaretests ist es sicherzustellen, dass die Software die gewünschte Funktionalität im Fahrzeug realisiert. Dazu werden Hardware-in-the-Loop (HiL)- und Fahrzeugversuche durchgeführt. Das Testende für den Softwaretest wird dadurch nachgewiesen, dass zu jeder Anforderung mindestens eine Testsequenz durchgeführt wird.

4 3 Methoden zur Testsequenzerstellung Mit Hilfe der methodischen Testsequenzerstellung werden systematisch Testsequenzen gefunden, welche zu den geforderten Testendekriterien führen. Es wird vermieden, dass Testsequenzen vergessen oder wiederholt werden. Die Fragestellung, welche Testsequenzen benötigt werden, wird durch den Einsatz eines methodischen Vorgehens reproduzierbar beantwortet. Derzeit ist eine Vielzahl von Methoden verfügbar und es ist wichtig diese bedarfsgerecht einzusetzen und zu kombinieren. Dieser Ansatz wird durch das Framework, zunächst mit den im Folgenden dargestellten dynamischen Black-Box Testmethoden realisiert, welche die Tester bei der Ermittlung von Stimuli auf die zu testende Software unterstützen. Das Framework ist jedoch so aufgebaut, dass weitere Methoden integriert werden können. Es ist besonders hervorzuheben, dass die vorgestellten Methoden prinzipiell von der Teststufe unabhängig sind, auf welcher sie eingesetzt werden. Es ändert sich lediglich das zu testende System (System-under-Test, SUT). Mit Hilfe der Äquivalenzklassenbildung und Grenzwertanalyse wird der Eingabedatenraum für das SUT reduziert, indem aus dem Datenraum Bereiche ausgewählt werden, für welche das Verhalten äquivalent ist. Auf der Ebene y des Softwaretests können dies funktionale Äquivalenzklassen sein, wie etwa die Reaktion des Getriebesystems auf eine bestimmte Fehlerklasse. Auf der Ebene des Modultests kann es sich um konkrete Wertebereiche handeln, welche in einer Bedingung zu dem gleichen Ergebnis führen (0 < x < 5). Die Wahl der Äquivalenzklassen und Grenzwerte entscheidet wesentlich über die erreichr = f(x,y) 3.1 Äquivalenzklassenbildung und Grenzwertanalyse [Grenzwert y n ] y [Datenpunkte] [Äquivalenzklasse y 1 ] r = f(x,y) x [Äquivalenzklasse x 1 ] [Grenzwert x m ] Abbildung 2: Äquivalenzklassen und Grenzwerte. bare Kontrollflussüberdeckung. Diese Klassifikationen können auf verschiedene Arten kombiniert werden, wodurch das SUT mit einzelnen Datenpunkten aus dem strukturierten Eingabedatenraum stimuliert wird. Dieser Zusammenhang ist in Abbildung 2 dargestellt. Das Beispiel zeigt eine Funktion r = f(x, y). Es ist zu beachten, dass für jeden gewählten Datenpunkt (x, y) auch ein erwarteter Rückgabewert r angegeben werden muss, damit ein Test der Form r == f(x, y) möglich ist.

5 3.2 Kombinatorik C l C3 l C2 Level A1 Level A2 Level A3 Die Kombination verschiedener Eingaben eines SUT ist eine im Rahmen des Testens allgemein zu beantwortende Fragestellung. Wünschenswert wäre natürlich der Einsatz einer vollständigen Kombination aller möglichen Eingabedaten dieser Arbeitsaufwand ist jedoch nur in Ausnahmefällen tragbar. Im Rahmen des Frameworks werden daher verschiedene Ansätze bereitgestellt: Die Kombinatorik durch ein orthogonales Feld, die vollständige Kombinatorik und die Integration des Werkzeuges CTE-XL [CTE], C welches Fehlerregion Einfacher Fehler B bereits verschiedene Kombinationsstrategien beinhaltet Orthogonale Felder Level B3 Datenraum der Software [Äquivalenzklasse B2] Die Level Kombinatorik B2 durch ein orthogonales Feld hat ihren Ursprung in der statistischen Versuchsplanung. Die Art und Weise, wie die einzelnen Testsequenzen aufgebaut sind, wird aus einer speziellen Matrix, dem orthogonalen Feld gewonnen. In der dazugehörigen [M. S. Phadke: Planning Efficient Software Tests] Fachliteratur werden die Eingangsgrößen des SUT als Faktoren bezeichnet. Die verschiedenen Klassifikationen, welche die Faktoren besitzen können, werden als Level bezeichnet. In Abbildung 3 wird dies verdeutlicht. In dem Beispiel besitzt jeder der drei Faktoren [Äquivalenzklasse A1] [Äquivalenzklasse A2] A SUT aktor C Faktor A Faktor B Faktor C evel C2 Level C3 Level A1 Level A2 Level A3 Level B1 Level B2 Level B3 Level C1 Level C2 Level C3 Testfall 1 Testfall 2 Testfall 3 Testfall 4 Testfall 5 Testfall 6 Testfall 7 Testfall 8 Testfall 9 Abbildung 3: Darstellung der Auswahl von Testsequenzen durch ein orthogonales Feld. drei Level. Die durch das orthogonale Feld vorgegebene Kombinatorik, welche durch die Matrix repräsentiert wird, ist dabei in einer Klassifikationsbaumdarstellung visualisiert. Die Zahlen in der Matrix geben den Level an, die Spalte steht für den Faktor. Die Orthogonalitätseigenschaft der Matrix ist dadurch gekennzeichnet, dass jeder Level in jedem Spaltenpaar vorkommt und zwar gleich oft. Diese Ausgleichseigenschaft ist mathematisch dafür hinreichend, dass jeweils zwei Spaltenvektoren im kombinatorischen Sinne voneinander linear unabhängig sind, wodurch der Einfluss dieser beiden Faktoren voneinander unabhängig untersucht wird. Neben dieser vorteilhaften mathematischen Eigenschaft werden durch das Vorgehen wenige, intelligente Testsequenzen gebildet. In Abbildung 4 sind die durch das orthogonale

6 Feld ausgewählten Datenpunkte im Datenraum des Beispiels visualisiert. Es wird deutlich, dass durch diese Auswahl ein großes Datenvolumen untersucht wird, wenngleich auch nicht wie bei der vollständigen Kombinatorik jeder Datenpunkt getestet wird. C C Fehlerregion Einfacher Fehler B Level C3 Datenraum d Software Level B3 Level C2 Level B3 el A1 Level A2 Level A3 Level B2 A Level A1 Level A2 Level A3 Level B2 Abbildung 4: Visualisierung der Kombinatorik im Datenraum. [M. S. Phadke: Planning Efficient Software Die vollständige Kombinatorik ist im Rahmen des Frameworks dennoch implementiert, da es bei Anwendungsfällen mit wenigen Faktoren und Leveln keinen erheblichen Mehraufwand gibt. Dennoch würden für den vollständigen Test an dem angegebenen Beispiel SUT drei Mal so viele Testsequenzen benötigt, wie durch das orthogonale Feld. SU A Faktor B Faktor C Kombinatorik in dem Werkzeug CTE-XL Faktor A Fakt 2 Level A3 Level B1 Level B2 Level B3 Level C1 Level C2 Level C3 Level A1 Level A2 Level A3 Level B1 Leve Ein bekannter Vertreter für die Auswahl von Testsequenzen durch eine Kombinatorik ist das Werkzeug CTE-XL. Die Parameter und Klassifikationen, bzw. die Faktoren und Level Testfall 1 müssen manuell in einen Klassifikationsbaum eingetragen werden. Innerhalb des Werkzeuges sind verschiedene Kombinationsstrategien implementiert, Testfall welche 2 im Folgenden aufgezählt werden. Ein Element aus jeder Klassifikation: Paarweise Kombination: Dreifache Kombination: n-fachen Kombination: Testfall 3 Jede Klassifikation wird mindestens Testfall einmal 4 ausgewählt. Testfall 5 Aus einer Menge von Klassifikationen K = {a, b, c} werden alle paarweisen Kombinationen der Form k 1 = (a b), Testfall 6 Testfall 7 k 2 = (a c), k 3 = (b c) gebildet. Es wird das gleiche Prinzip angewendet, Testfall 8aus einer Menge von Klassifikationen K = {a, b, c, Testfall d} werden 9 alle Kombinationen der Form k 1 = (a b c),... gebildet. Das Prinzip wird auf das n-fache erweitert. Die Kombinationsregeln können beliebig miteinander kombiniert werden. 3.3 Zustandsbasierter Test Ein großer Teil der Steuergeräte-Software ist durch zustandsbasiertes Verhalten gekennzeichnet. Selbst kontinuierliche Regelfunktionen sind häufig in ein übergeordnetes diskretes Zustandsverhalten eingebunden. Aus der Struktur dieses Zustandsdiagramms können

7 Testsequenzen generiert Testprinzip werden. Testsequenzen Regler Modell des SUT Strategie Aus Einschalten/ Ausschalten/ Ein Stimulation ZFF TE-NL/FKFS 8 Regler - System Under Test Strategien zur Testfallgenerierung aus UML-Zustandsautomaten Prüfung Testschritt 1: System im erwarteten Testschritt 2: Ausgangszustand? Stimulation eines Übergangs. Testschritt 3: System im erwarteten Zielzustand? Testimplementierung Abbildung 5: Testprinzip der zustandsbasierten Testsequenzgenerierung. ZF Friedrichshafen AG, 2008 Das Testprinzip, welches dabei zum Einsatz kommt, ist in Abbildung 5 dargestellt. Das Zustandsdiagramm bildet das gewünschte Verhalten der zu testenden Software direkt ab. Die erstellten Testsequenzen repräsentieren verschiedene Pfade durch den Zustandsautomaten. Wie die Abbildung darstellt, werden diese Testsequenzen in einzelnen Testschritten in der Testimplementierung umgesetzt. Im Wesentlichen besteht der Test daraus, zu überprüfen, ob sich das System zu Beginn in dem Ausgangszustand befindet. Ist der Übergang mit einer Übergangsbedingung verknüpft, so wird diese im nächsten Testschritt stimuliert, danach kann überprüft werden, ob sich das System in dem erwarteten Zielzustand befindet. Nach diesem Prinzip werden die Testsequenzen sukzessive abgetestet. Die Modellierung des Zustandsverhaltens kann durch UML-Zustandsautomaten vorgenommen werden. Zur Strukturierung dieser Automaten sind Parallelität und Hierarchie zugelassen Testsequenzerstellungsprozess Es gibt verschiedene Methoden zur Testsequenzerstellung [Bin99], basierend auf der Struktur des Automaten. Für den Einsatz im Rahmen des Testframeworks wurden die Methoden All-States, All-Transitions und N+ auf ihre Eignung hin untersucht. Die Unterschiede liegen im Wesentlichen in der Fähigkeit bestimmte Fehlertypen aufzufinden und der Anzahl der generierten Testschritte. Strategien, welche zusätzlich boolesche Ausdrücke in den Übergangsbedingungen berücksichtigen, führen zu einer weiteren Erhöhung der generierten Testschritte. Ferner gehen die beschriebenen Strategien von einem flachen Zustandsautomaten aus. Es ist daher notwendig einen geeigneten Weg zu wählen, die Hierarchie und Parallelität in den Zustandsautomaten aufzulösen. In der Regel wird die Hierarchie durch eine Substitution des untergeordneten Zustandsautomaten in den Übergeordneten aufgelöst. Die Parallelität kann durch die Bildung eines Produktautomaten behandelt werden [BBR08]. Dabei werden die Strukturierungselemente, welche zur Beherrschung der Modellkomplexität eingefügt wurden, wieder entfernt, wodurch die auf

8 diesem Zustandsautomaten aufbauenden Testsequenzen nicht mehr ohne Weiteres nachvollziehbar sind Metastrategien zur Testsequenzerstellung Um diesem Umstand entgegenzuwirken, wurden im Rahmen des Testframeworks Metastrategien zum Umgang mit Hierarchie und Parallelität erarbeitet, deren Ziel es ist, die Struktur des Modells in den generierten Testsequenzen beizubehalten, gezielt Modellteile testen zu können und die Anzahl der generierten Testschritte zu beeinflussen [PWR08]. Dazu werden in einem ersten Schritt hierarchische und parallele Modellteile identifiziert. Die Struktur wird nicht aufgelöst sondern die Testsequenzerstellungsmethoden werden auf die einzelnen Automaten separat angewendet. Erst in einem nachgelagerten Schritt werden die unabhängig erstellten Testsequenzen zu einer Gesamttestsequenz integriert. 3.4 Erfahrungsbasierte und intuitive Testsequenzermittlung Trotz der methodischen Testsequenzerstellung wird es immer wieder Testsequenzen geben, welche sich nur aus der Systemkenntnis und Erfahrung eines Testingenieurs ableiten lassen. Um diesem Umstand Rechnung zu tragen, wird die erfahrungsbasierte und intuitive Testsequenzermittlung an dieser Stelle aufgeführt. In dem Framework ist die Eingabemöglichkeit solcher Testsequenzen explizit vorgesehen. 4 Das Testframework Um das Optimierungspotenzial, welches sich durch den Einsatz der methodischen Testsequenzerstellung ergibt, in den Entwicklungsprozess einbringen zu können, werden zwei Ansatzpunkte identifiziert. Die Wiederverwendung von Artefakten aus dem Entwicklungsprozess und die Möglichkeit, die erstellten Testsequenzen auf den verschiedenen Ausführungsplattformen ablaufen lassen zu können. 4.1 Verwendung von Artefakten aus dem Entwicklungsprozess Die verwendbaren Artefakte können in drei Kategorien eingeteilt werden. Strukturartefakte der Software sind im Software-Design bereits formal hinterlegt. Dabei handelt es sich um für den Test wichtige Angaben, wie den Aufbau einzelner Softwarekomponenten, die Angabe welche Module vorhanden sind und welche Ein- und Ausgabeschnittstellen diese zur Verfügung stellen, sowie Informationen über die Datentypen und Wertebereiche der Schnittstellenparameter. Verhalten ist in Form von Zustandsautomaten häufig in den Software-Anforderungsdokumenten oder spätestens im Software-Design zu finden. Dabei ist das Verhalten auf unterschiedliche Detaillierungsstufen des Entwicklungsprozesses beschrieben. So kann sowohl das Verhalten der Gesamtsoftware durch einen Zustandsau-

9 tomaten abgebildet sein, wie auch das Verhalten eines einzelnen Software-Moduls. In allen Fällen stellt diese formale Beschreibung eine wertvolle Basis für die zustandsbasierte Testsequenzerstellung dar. Eingebettete Software für ein Automobil-Steuergerät enthält eine Vielzahl von Daten und Parametern, welche im Entwicklungsprozess in einer formalen Form abgelegt werden. Die Wiederverwendung dieser Daten für den Test spart den erneuten Eingabeaufwand und stellt eine Grundlage für die Testbedatung dar. 4.2 Implementierung auf verschiedenen Ausführungsplattformen Das Ergebnis der methodischen Testsequenzerstellung sind abstrakte Testsequenzen, welche die Testlogik und den Testinhalt vorgeben. Ein wesentliches Ziel des Frameworks ist es, diese abstrakten Testsequenzen in die einheitliche, formale Form einer plattformunabhängigen, XML-basierten Testbeschreibungssprache zu überführen. Die Sprache ist dabei so gestaltet, dass sie nicht nur von den Software-Entwicklern, sondern von allen am Test beteiligten Personen verstanden wird. Durch den Einsatz von Code-Generatoren kann aus der formalen Testbeschreibung der plattformspezifische Code generiert werden. Dadurch wird gewährleistet, dass die Testinhalte nicht in ausgefeilten Code-Konstrukten einer plattformspezifischen Programmiersprache versteckt sind. Es ergeben sich die Vorteile, dass gleiche Tests auf unterschiedlichen Plattformen ohne Mehraufwand implementiert werden können; beispielsweise lassen sich Tests, welche auf dem PC erfolgreich waren auf der realen Hardware wiederholen. Dieses Vorgehen ermöglicht langfristig auch die Perspektive die Testinhalte über die Teststufen effektiver zu verteilen. 4.3 Aufbau des Testframeworks Basierend auf diesen Anforderungen ergibt sich der in Abbildung 6 dargestellte Aufbau des Testframeworks. Die oberste Schicht deutet die Artefakte aus dem Entwicklungsprozess an, welche in das Framework eingelesen werden. Die unterste Schicht steht für die verschiedenen eingesetzten Teststufen- und Plattformen, auf welchen die Testsequenzen implementiert werden. Der eigentliche Kern des Testframeworks besteht aus den drei Schichten Methoden zur Testsequenzerstellung, Testbeschreibungssprache und Codegenerator. Um die Artefakte aus dem Entwicklungsprozess einzulesen und den Codegenerator zu implementieren, werden die Konzepte der modellgetriebenen Softwareentwicklung [SV05] in Anlehnung an den OMG 1 -Standard MDA (Model-Driven- Architecture) verwendet. Die Implementierung erfolgt mit der Entwicklungsumgebung Eclipse 3.3 unter Verwendung des Frameworks open Architecture Ware (oaw). Das Einlesen von XML-basierten Daten aus dem Entwicklungsprozess und das Überführen in andere XML-basierte Datenformate wird dabei durch eine Modell-zu-Modell Transformation (M2M) realisiert. Bei der M2M werden Transformationsregeln angegeben, wie Inhalte eines XML-Dokuments, welches auf dem Schema A beruht in ein anderes Dokument zu überführen sind, welches auf dem Schema B beruht. Innerhalb von oaw wird zudem noch ein Parserframework angeboten, welches es ermöglicht, Inhalte aus struk- 1 Object Management Group

10 MUT Methodischer Unit-Test Artefakte aus dem Entwicklungsprozess Strukturinformationen UML Verhalten Daten Testframework Methoden zur Testsequenzerstellung: Äquivalenzklassenbildung, Grenzwertanalyse, Kombinatorik, Zustandsbasierter Test Testbeschreibungssprache XML Codegenerator Ausführbarer Testcode Unit-Test C++ Integrationstest Softwaretest Abbildung 6: Struktur des Testframeworks. RESEARCH IN MOTION Forschungsinstitut für Kraftfahrwesen und Fahrzeugmotoren Stuttgart 2 turierten ASCII-Dateien in ein XML-Dokument zu überführen. Dadurch lassen sich alle gängigen UML-Werkzeuge in das Testframework integrieren. Des Weiteren können auch Inhalte aus Matlab/Simulink Dateien eingelesen werden, welche in strukturierten ASCII- Dateien abgelegt sind. Das Überführen von XML-basierten Daten in plattformspezifischen Implementierungscode wird als Modell-zu-Code Transformation (M2Code) implementiert. Dabei wird ein Codeskelett der plattformspezifischen Implementierungssprache durch Platzhalter ergänzt. Es können Transformationsregeln angegeben werden, welche Informationen aus einem XML-Dokument an diese Platzhalter übergeben werden. Auf diese Weise können mit einfachen mitteln Codegeneratoren für die verschiedenen Ausführungsplattformen erstellt werden, welche ohne großen Aufwand projektspezifisch anpassbar sind Methodische Testsequenzerstellung Für die Unterstützung der Äquivalenzklassenbildung und Grenzwertanalyse durch das Framework wird ein UML-Profil definiert, um in einem UML-Klassendiagramm, zu testende Funktionen, sowie deren Ein- und Ausgänge zu kennzeichnen. Für die Ein- und Ausgangsparameter können Äquivalenzklassen und Grenzwerte definiert werden. Diese Informationen werden durch das Framework aus dem UML-Diagramm in ein Importformat eingelesen. Aus diesen Daten wird eine Datei für den CTE-XL erstellt, welche den Klassifikationsbaum enthält. Testsequenzen, welche durch den CTE-XL in dieser Datei erstellt werden, werden in die Testbeschreibungssprache überführt. Parallel zu dem Einsatz des CTE-XL wird die Kombinatorik durch ein orthogonales Feld ermöglicht. Basierend auf der Anzahl der Funktionsparameter und der Klassifikationen wird ein orthogona-

11 les Feld errechnet. Die daraus resultierenden Testsequenzen werden in der Testbeschreibungssprache abgelegt. Um den zustandsbasierten Test und die beschriebenen Metastrategien (vgl. Unterabschnitt 3.3.2) umzusetzen, können durch das UML-Profil verschiedene Initialzustände in einem UML-Zustandsautomaten gekennzeichnet werden. Innerhalb des Frameworks sind die beschriebenen Algorithmen implementiert, die Ausgabe der generierten Testsequenzen erfolgt direkt in der Testbeschreibungssprache. Eine Kopplung der Äquivalenzklassenbildung mit dem zustandsbasierten Test ist dadurch realisiert, dass durch Äquivalenzklassen und Grenzwerte klassifizierte Parameter, welche gleichzeitig in den Übergangsbedingungen des Zustandsautomaten auftreten, dem Tester bei der konkreten Testdatenauswahl wieder angezeigt werden Testbeschreibungssprache Grundlage für die Testbeschreibungssprache ist die Testnomenklatur der ZF Friedrichshafen AG. Basierend auf dem natürlichen Sprachgebrauch wurde ein XML-Schema erstellt, welches als Wurzelelement die Testspezifikation beinhaltet. Diese besteht im Wesentlichen aus Testsequenzen und Testdaten. Die Testsequenzen beschreiben dabei den parameterunabhängigen Teil des Tests, welcher durch die nachgelagerte Verknüpfung mit konkreten Testdaten einfach wiederverwendet werden kann. Der Bereich des XML- Schemas, welcher die Testdaten widerspiegelt, kann innerhalb des Frameworks durch eine Excel-Tabelle visualisiert werden. Auf diese Weise ist die Bedatung einfach durchführbar. Erwartungswerte, welche sich aus Eingangswerten berechnen lassen, können so mit den Excel Funktionen berechnet werden. Durch einen implementierten Zufallsgenerator lassen sich aus den Äquivalenzklassen konkrete Repräsentanten wählen. Nach dem Speichern werden die Testdaten in der Testbeschreibungssprache aktualisiert. Die Testbeschreibungssprache lässt sich durch einen im Rahmen des Frameworks implementierten Editor manuell bearbeiten, wodurch die erfahrungsbasierte und intuitive Testsequenzermittlung ermöglicht wird. Alle methodisch erstellten Testsequenzen können eingesehen, ergänzt oder bearbeitet werden Codegenerator Der Codegenerator unterstützt zunächst das Cpp-Unit ähnliche Testframework. Dabei handelt es sich um ein schlankes Modultestframework, welches Makros für die Testausführung, -Protokollierung und -Auswertung realisiert. Neben dem eigentlichen Testcode, welcher die Strukturen aus der Testbeschreibungssprache widerspiegelt, wird das gesamte Visual Studio 2003 Projekt generiert. Der Codegenerator unterstützt so genannte Protected-Regions. Dabei handelt es sich um Bereiche im generierten Code, welche bei einem erneuten Generatordurchlauf nicht mehr überschrieben werden. Auf diese Weise können manuelle Anpassungen vorgenommen werden, welche nicht verloren gehen. Dadurch ist eine iterative Testsequenzerstellung möglich. Sobald methodisch auch nur eine Testsequenz erstellt wurde, können durch den Codegenerator das Visual Studio Projekt und der Testcode generiert werden. Manuelle Anpassungen, wie spezielle Konstruktoraufrufe, können eingefügt werden und der erste Test kann zur Ausführung gebracht werden. Jetzt können methodisch weitere Testsequen-

12 zen erstellt werden, welche sukzessive in ausführbaren Testcode überführt werden. Die grafische Oberfläche des Frameworks ist in Abbildung 7 dargestellt. Genauso, wie die Software-Architektur spiegelt auch die Architektur der Oberfläche die Erweiterbarkeit des Frameworks wieder. Neue Methoden oder Codegeneratoren für andere Plattformen können mit der verwendeten Technologie einfach nachgerüstet und in die Oberfläche integriert werden. Abbildung 7: Grafische Oberfläche des Testframeworks. 5 Anwendungsbeispiel Als Leitanwendung für die Entwicklung des Testframeworks wurde ein Softwaremodul aus einer Steuergerätesoftware für das Ecolife Automatikgetriebe eines Stadtbusses ausgewählt, das in Abbildung 8 dargestellt ist. Die Aufgabe des Moduls besteht darin, zu einem aus der übrigen Steuerungssoftware vorgegebenen Solldruck, die richtige Bestromung der Aktoren vorzunehmen. Das Modul zeichnet sich sowohl durch zustandsbasiertes, als auch durch datenflussorientiertes Verhalten aus. Das Modul Druckregler ist durch eine C++ Klasse implementiert. Die Schnittstellen sind in einem UML-Klassendiagramm bereits im Entwicklungsprozess definiert worden. Das zustandsbasierte Verhalten des Druckreglers wird durch ein UML-Zuststandsdiagramm beschrieben, welches der Klasse zugeordnet ist. Die beiden Artefakte sind in Abbildung 9 dargestellt. Die Klasse, aus welcher die zu testende Methode stammt, muss mit dem Stereotyp <<SUT>> belegt werden. Die zu testende Methode selbst wird durch <<FUT>>(Function under Test) gekennzeichnet. Um die Grenzwerte und Äquivalenzklassen der Parameter angeben zu können, ist das Stereotyp <<classification>> vorgesehen. Das Stereotyp <<SMUT>> steht für Statemachine under Test und dient dazu den Initialzustand innerhalb eines UML-Zustandsautomaten zu kennzeichnen, von welchem aus-

13 Profil SUT >> SMUT >> FUT >> classification >> Abbildung 8: ZF Ecolife Getriebe. «SUT» cdruckregler «classification» p_steuer_soll : si16 «classification» p_regle_soll : si16 Ausschalten () «FUT» Einschalten (in p_steuer_soll : si16, in p_regel_soll : si16 = 0) Durchsteuern () Regeln () Run () AutoDeaktivieren () AutoDeaktivierungReset () «SMUT» Run/ Ausschalten/ ZUSTAND_AUS Ausschalten/ Ausschalten/ Einschalten[Datenfeld.t_Einsprung(HoleTemperatur()) > 0]/ Ausschalten/ AutoDeaktivieren/ ZUSTAND_EIN_EINSPRUNG Einschalten[Datenfeld.t_Einsprung(HoleTemperatur()) <= 0]/ AutoDeaktivierungReset/ ZUSTAND_EIN_DRUCK_BEGR_ABSENKEN Run/ Ausschalten/ Regeln/ ZUSTAND_EIN_REGELND Run[ptr_HD->p_Ist > p_max_zul]/ Run/ Durchsteuern[ptr_HD->p_Ist <= p_max_zul]/ Durchsteuern[ptr_HD->p_Ist > p_max_zul]/ Regeln/ Regeln/ ZUSTAND_EIN_DURCHGESTEUERT ZUSTAND_EIN_DRUCK_BEGR_REGELN Run[ptr_HD->p_Ist < p_max_zul + Datenfeld.p_Hyneg_max_zul()]/ Abbildung 9: Artefakte aus dem Entwicklungsprozess. gehend die Testsequenzen generiert werden. Auf diese Weise können gezielt hierarische Unterzustände oder parallele Regionen getestet werden. Diese Informationen werden in das Testframework eingelesen und der Methodenschicht zur Verfügung gestellt. Basierend auf dem Wissen, dass die Methode Einschalten() getestet werden soll, welche die Eingabeparameter p Steuer Soll und p Regel - Soll hat, wird der in Abbildung 10 dargestellte Klassifikationsbaum generiert. Innerhalb Wiederverwendung ZUSTAND_STARTUP Einschalten( ) ZUSTAND_AUS ZUSTAND_EIN_REGELND Abbildung 10: Methodische Testsequenzerstellung. des CTE-XL können Testsequenzen durch Kombinatorik oder manuelle Vorgabe erstellt werden. Aus dem Zustandsdiagramm wird ein Übergangsbaum generiert, welcher ebenfalls in Abbildung 10 angedeutet ist. Dies ist die Basis für Testsequenzen, welche das Zustandsverhalten des Druckreglers systematisch stimulieren. Da die Methode Einschalten() innerhalb dieser Testsequenzen aufgerufen wird, werden die Informationen über den Wertebereich der Übergabeparameter auch für die Bedatung dieser Testse-

14 quenzen herangezogen. Die methodisch erstellten Testsequenzen werden in der Testbeschreibungssprache abgelegt, sowohl die Bedatung durch die Excel Tabelle, als auch der Editor für die Sprache sind in Abbildung 11 dargestellt. Innerhalb der Excel Tabelle hat der Testingenieur die Möglichkeit, konkrete Repräsentanten aus den Äquivalenzklassen auszuwählen und sowohl die Vorgabe als auch die Erwartungswerte der Testsequenzen zu definieren. Erfahrungen und Ergebnisse Abbildung 11: Formale Testbeschreibung und Bedatung. Das SUT wurde bereits manuell getestet. Die Kontrollflussüberdeckung mit den manuell erstellten Testsequenzen wird als Referenz für die Bewertung der Güte der automatisch erstellten Testsequenzen herangezogen. Durch die Kombination der zustandsbasierten Testsequenzerstellung und dem Einsatz der Grenzwertanalyse und Äquivalenzklassenbildung werden methodisch und automatisiert 76 Testsequenzen mit insgesamt 146 Testschritten generiert, welche 7% weniger Kontrollflussüberdeckung erzielen, als die manuelle Referenz. Die Diskrepanz ist vor allem dadurch begründet, dass das Modell noch nicht alle Aspekte der realen Implementierung widerspiegelt. In der Implementierung sind Zustände über mehrere Variablen verteilt. Mit diesem Umstand kann der Generator derzeit nicht automatisiert umgehen. Ein Vergleich der Testsequenzen zeigt, dass es Methoden gibt, welche durch die generierten Testsequenzen intensiver getestet werden. Dies sind Methoden, deren Inhalt stark an das abbildbare Zustandsverhalten des SUT gebunden ist und deren Stimulation manuell zu aufwendig gewesen wäre. Methoden, welche durch die manuellen Testsequenzen intensiver getestet werden, sind von den noch nicht dargestellten Zuständen abhängig. Beachtenswert ist, dass die Testsequenzen aus einem Zustandsautomaten mit 8 Zuständen und 23 Transitionen generiert werden konnten. Basierend auf dieser Grundlage wurde eine plattformunabhängige Beschreibung der Testsequenzen, sowie die notwendige Implementierung generiert. Auch wenn die Kontrollflussüberdeckung zunächst geringer war, zeigt sich, dass mit wenig Aufwand der Großteil der notwendigen Testsequenzen automatisch erstellt werden kann. Während die Erstellung der manuellen Testsequenzen Tage in Anspruch genommen hat, konnten die Testsequenzen automatisiert binnen Stunden erstellt werden, wobei

15 der größte Aufwand in die Erstellung des Modells floss. Damit lässt sich eine deutliche Effizienzsteigerung nachweisen. Eine Qualitätssteigerung wird durch das methodische Vorgehen erzielt. Basis für die Testfälle ist das Modell. Die Testinhalte sind damit in einer einheitlichen, abstrakten Form dargestellt. Bei Änderungen im SUT kann das Modell angepasst werden und die Testsequenzen werden neu generiert. Da sich die Struktur der Testbeschreibungssprache im generierten Testcode widerspiegelt, ist der Code übersichtlich und damit leicht wart- und anpassbar. Durch die automatische Testcodegenerierung werden Fehler in der Testimplementierung vermieden. 6 Zusammenfassung und Ausblick Die beiden Ziele Qualitäts- und Effizienzsteigerung bei dem Testen von Kfz-Steuergeräte- Software werden durch das vorgestellte Framework erreicht. Insbesondere wurden dafür zwei Ansatzpunkte identifiziert. Entscheidend für die Qualität der Tests ist die Art und Weise, wie diese spezifiziert werden. Um den Testingenieur bei dieser Aufgabe systematisch zu unterstützen, wurden Implementierungen verschiedener Methoden in das Framework integriert. Durch die einheitliche Integrationstechnologie können die Methoden gewinnbringend miteinander kombiniert werden. Zudem werden Artefakte aus dem Entwicklungsprozess im Test wiederverwendet. Um die Effizienz zu steigern, werden die abstrakten Testsequenzen in einer XML-basierten, plattformunabhängigen Testbeschreibungssprache abgelegt. Auf diese Weise kann gewährleistet werden, dass die Testinhalte nicht nur den Testingenieuren zugänglich sind, welche die Implementierungssprache einer bestimmten Testausführungsplattform verstehen. Es wird möglich die formal beschriebenen Testsequenzen automatisiert auf den verschiedenen Testausführungsplattformen zu implementieren. Durch die Verwendung von offenen Standards, wie der modellgetriebenen Softwareentwicklung und XML ist eine Implementierung entstanden, welche auch an zukünftige Anforderungen flexibel angepasst werden kann. Neue Methoden oder neue Ausführungsplattformen können einfach integriert werden, wodurch der Grundstein für eine langfristig einsetzbare Standardisierungslösung geschaffen wurde. Zukünftig wird daran gearbeitet weitere Testausführungsplattformen an das Framework anzubinden und die Vorgehensweise in weiteren Pilotprojekten anzuwenden.

16 Literatur [BBR08] Michael Brost, Gerd Baumann und Hans-Christian Reuss. UML-basierte Testfallerzeugung für Karosseriesteuergeräte. In Clemens Gühmann, Hrsg., Simulation und Test in der Funktions- und Softwareentwicklung für die Automobilelektronik II. expert verlag, [Bin99] Robert V. Binder. Testing Object-Oriented Systems Models, Patterns, and Tools. Addison Wesley, [CTE] Homepage Systematic Testing. com/functional_testing/cte_main.php?cte=1. [PWR08] Carsten Paulus, Michael Wolff und Hans-Christian Reuss. Strategien zur Testfallgenerierung aus UML-Zustandsautomaten. In Hardware-in-the-Loop- Simulation. Haus der Technik, [SL07] Andreas Spillner und Thilo Linz. Basiswissen Softwaretest. dpunkt.verlag, [SV05] Thomas Stahl und Markus Völter. Modellgetriebene Softwareentwicklung. d.punkt, 2005.