Was verstehen wir unter Test - FKFS

Erfolgreiche Teststrategien
für komplexe Steuergeräte -
Anforderungen und
Lösungen -
Lothar Beller, ZF Friedrichshafen AG
Michael Wolff, ZF Friedrichshafen AG
Ralph Seefried, ZF Friedrichshafen AG

Erfolgreiche Teststrategien für komplexe Steuergeräte
- Anforderungen und Lösungen -
Successful Test Strategies for Complex Control Systems
- Requirements and Solutions -
Dipl.-Ing. (FH) L. Beller, Dipl.-Ing. M. Wolff, Dipl.-Ing. (FH) R. Seefried
ZF Friedrichshafen AG
Zusammenfassung
Trotz kürzerer Entwicklungszeiten und steigender Anforderungen an die Software
müssen die Softwarequalität und die Kundenzufriedenheit konstant bleiben oder
sogar gesteigert werden. Dazu bedarf es einer guten und effizienten Teststrategie.
Dies wurde bei der ZF früh erkannt und durch die Entwicklung entsprechender Tools
und Methoden sichergestellt.
So setzt die ZF seit Jahren eine Simulationsumgebung ein, die es erlaubt Fehler
schon früh im Entwicklungsprozess zu finden und somit Zeit und Kosten zu sparen.
Tests werden parallel zur Entwicklung der Hardware und unabhängig von knappen
und teuren Ressourcen wie HIL 1 -Prüfständen und Versuchsfahrzeugen entwickelt
und durchgeführt. Durch die Wiederverwendung von einmal erstellten Modellen und
Testfällen in den verschiedenen Entwicklungsphasen, sowie der Automatisierung der
Testdurchführung und Testauswertung wurde eine deutliche Reduktion des
Aufwands erreicht. Klare Absprachen und regelmäßige Prozessreviews stellen die
Softwarequalität auch bei Software-Lieferanten sicher.
Es wird aufgezeigt, wie sich die Tests in der ZF entwickelt haben und wie man sich
auf immer umfangreichere Anforderungen eingestellt hat. Schwerpunkte liegen dabei
auf in-the-Loop-Tests mit Blick auf bewährte Realisierungen bei der
Wiederverwendung und Automatisierung. Die Sicherstellung der Softwarequalität bei
verteilter Entwicklung mit Software-Sharing-Partnern wird aufgezeigt. Aktuelle und
zukünftige Entwicklungen im Bereich der Testmethodik, Testfallgenerierung und
Wiederverwendung werden vorgestellt.
Abstract
Despite shorter development times and growing demands on software, the quality
and customer satisfaction as such has to be maintained or even stepped up,
however, without increasing effort. Therefore a good and efficient strategy for testing
1 HIL – Hardware in the Loop – Software wird im realen Steuergerät in einer simulierten Umgebung ausgeführt.

is necessary. This context has been recognized quite early by ZF and has been
ensured by developing adequate methods and tools.
Thus ZF is using a simulation environment since years. This environment gives the
possibility to find errors and bugs in an early stage of the development process and
by this to save time and money. Tests are developed and performed in parallel to the
hardware and independent from the availability of expensive test equipment like HiLfacilities
and prototype vehicles. An essential reduction of the testing effort has been
reached by reusing the simulation models and test cases during all phases of the
development process and by automation of testing and generating test reports. As
well, precise agreements and regularly process review ensure the software quality of
the software suppliers.
In this article it is shown, how ZF has evolved the testing strategy and tests itself, to
accomplish the growing demands of software development. The article focuses on
the “in the loop” testing with a close look on established implementations at reuse
and automation. But it is also shown, how the software quality at distributed software
development with several sharing partners is ensured. Finally the actual state and
the trend in the domain of development methods, test reuse and test case generating
will be introduced.

1 Einführung
Die ZF Friedrichshafen AG besitzt in der Entwicklung von Antriebs- und
Fahrwerkskomponenten langjährige Erfahrung. Erste Serienanwendungen von
Getriebesteuerungen liegen mehr als 20 Jahre zurück. Die Anwendungen erstrecken
sich von Pkw, Lkw, Bus und Bahn bis hin zu Arbeitsmaschinen.
Sowohl die Anzahl als auch die Komplexität der in Software abgebildeten Funktionen
hat in den letzten Jahren stark zugenommen, parallel steigt der Anspruch an die
Qualität. Dies muss bei immer kürzeren Entwicklungszeiten realisiert werden. In
diesem Spannungsfeld ist es wichtig, Fehler früh zu finden. Ein Fehler, der erst beim
Kunden entdeckt wird, hat einen negativen Einfluss auf die Kosten, die Ressourcen
und nicht zuletzt auf das Image des Unternehmens.
Ein vollständiger Test ist in der Praxis nicht durchführbar. Eine beispielhafte
Steuerung mit 10 Eingängen von 8 Bit Wordlänge hat 1,2 *10 24 statische Zustände.
Wollte man diese Zustände mit einem aktuellen PC durcharbeiten, so ergeben sich
unglaubliche 380 Millionen Jahre an Laufzeit. 2 So wird schnell klar, dass es
unmöglich ist, alle Kombinationen zu testen. Dazu kommt, dass sich die
Entwicklungsprojekte der Automobilzulieferer durch eine Vielzahl an Varianten und
kurze Auslieferungszyklen auszeichnen. So gibt es Getriebe-Softwareprojekte bei
der ZF mit über 40 Projektvarianten und 130 Software-Auslieferungen pro Jahr.
Dadurch vervielfacht sich der Aufwand an Tests nochmals erheblich.
Es ist die Aufgabe der Testverantwortlichen, die richtige Auswahl an Testkonzepten
zu treffen, um die Qualitätsanforderungen zu gewährleisten, ohne die Kosten und
Entwicklungszeit drastisch zu erhöhen. Dazu bedarf es einer guten und effizienten
Teststrategie. Dies wurde bei der ZF früh erkannt und durch den Einsatz
entsprechender Tools und Methoden sichergestellt.
Im Folgenden wird der aktuelle ZF-Testprozess vorgestellt. Danach werden drei für
die ZF spezifische Anforderungen näher erläutert und Lösungsansätze ausgeführt.
Konkret wird auf die komponentenbasierte Entwicklung, auf Varianten und auf die
verteilte Entwicklung eingegangen. Vorgehen, eingesetzte Methoden und der erzielte
Nutzen werden am Beispiel der Softwareentwicklung für Getriebesteuerungen
aufgezeigt.
2 10 Takte pro Zustand und 1 GHz Prozessortakt

2 ZF-Testprozess
2.1 Software-Entwicklungsprozess
Die ZF hat sich in den letzten Jahren intensiv mit der Entwicklung von konzernweit
einheitlichen Prozessen für die Softwareentwicklung beschäftigt. Das hierbei
erarbeitete Wissen über die Vorgehensweisen in den unterschiedlichen Projekten,
über die Anforderungen aus Normen und von Kunden, sowie über Tools und
Methoden, bietet uns heute die Möglichkeit die Tests so zu strukturieren, dass die
Software effizient abgeprüft wird.
Die Prozesse orientieren sich am allgemeinen V-Modell, an den Vorgaben von
AUTOMOTIVE SPICE und beschreiben die Vorgehensweise von der
Anforderungsermittlung bis zur Systemabnahme. Im linken Ast des V-Modells sind
die Konstruktionsphasen beschrieben. Da Fehler am einfachsten auf derselben
Abstraktionsstufe gefunden werden, auf der sie entstanden sind, ordnet der rechte
Ast jedem Konstruktionsschritt eine korrespondierende Teststufe zu [4].
Gesamtanforderungsermittlung
Projektmanagement
Systemanforderungsanalyse
Systemarchitekturdesign
Parallele
Entwicklungsprozesse
z.B. Mechanik,
Hydraulik,
Elektronik
Methoden Organisatorische – Tools und – unterstützende Rollen – Dokumente
Prozesse
Lieferantenmanagement
Abb. 1: ZF-Testprozess
Softwareanforderungsanalyse
Softwaredesign
Softwareerstellung
und Modultest
Konfigurationsmanagement
Änderungsmanagement
Qualitätssicherung
Systemabnahme
Systemtest
Systemintegration
und Integrationstest
SW-Funktionstest
Softwareintegration
und Integrationstest
Abstimmung
Daten
Problemmanagement
Die Teststufen unterscheiden sich durch das Testobjekt, die verwendeten Methoden
und Tools und nicht zuletzt durch die angestrebten Testziele. So bildet jede Teststufe
einen Baustein im Gesamttest. Durch die unterschiedlichen Blickwinkel wird erreicht,
dass alle Qualitätskriterien, die an die Software gestellt werden, abgeprüft werden.

2.2 Modultest
Im Modultest, der ersten Teststufe nach der Implementierung, werden die
Softwarebausteine erstmals einer systematischen Prüfung unterzogen. Auf dieser
Teststufe wird sehr entwicklungsnah gearbeitet. Der Modultest wird typischerweise
als White Box Test durchgeführt, d.h., die Struktur der Software ist bekannt und wird
zum Test hinzugezogen.
Ziele
statische Analyse
Testendekriterien
� Finden von Implementierungsfehlern
� Absichern des Verhaltens bei ungültigen Werten
Unit-Test/
Coverage Software in the Loop
�� Warnungsfreiheit mit der projektspezifischen Standardkonfiguration
�� Die von der Änderung betroffenen Zweige wurden beim Test durchlaufen.
Abb. 2: Modultest
Die wichtigste Aufgabe ist es, sicherzustellen, dass das jeweilige Testobjekt die
Funktionalität korrekt und vollständig realisiert. Typische Fehler, die beim Modultest
aufgedeckt werden, sind Berechungsfehler oder fehlende und falsch gewählte
Programmpfade. Der Test auf Robustheit ist ein weiterer sehr wichtiger Aspekt dieser
Teststufe, denn oft kann die Software nur auf dieser Ebene mit ungültigen Werten
stimuliert werden. Die Software muss auf diese Negativ-Tests mit einer
angemessenen Ausnahmebehandlung reagieren. Neben diesen dynamischen Tests
zählen zum Modultest auch statische Tests wie Reviews und Codeanalysen. Diese
Prüfungen dienen in erster Linie zum Nachweis der nichtfunktionalen Anforderungen
wie Wartbarkeit und Effizienz.
2.2.1 Statische Analyse
Direkt an die Implementierung schließt sich die Phase der statischen Analyse an. Der
Code wird mit Hilfe von Software-Werkzeugen analysiert und auf die Einhaltung von
Programmierstandards überprüft. Die ZF orientiert sich hierbei schon seit vielen
Jahren an den MISRA C Guidelines. Die Regeln aus MISRA wurden in die
Programmierrichtlinien eingearbeitet, die der Programmierung zu Grunde gelegt

werden. Des Weiteren besteht eine Konfiguration für den Rule Checker, der die
automatisch prüfbaren Regeln abprüft.
Da nicht alle Programmierregeln automatisiert prüfbar sind, werden regelmäßig
Codereviews durchgeführt. Dazu werden verschiedene Verfahren angewendet wie
ALP (Autor-Leser-Prinzip), Walkthrough und Inspektion. Die Software wird anhand
ihrer Komplexität und Kritikalität bewertet, um geeignete Review-Kandidaten
auszuwählen.
2.2.2 Unit Test/Codeabdeckung
Ziel im Unit Test ist es, das Verhalten der Software bei gültigen und ungültigen
Werten zu verifizieren. Um dieses Ziel effizient zu erreichen, ist es sinnvoll, kleine
Softwareteile freizuschneiden und in einem so genannten Testbett zu stimulieren. Mit
geeigneten Tools wird die Zweig- und Bedingungsabdeckung gemessen und
protokolliert.
Da in vielen Projekten bei der ZF mit C++ programmiert wird, setzt sich hier ein
CPPUnit Test-Framework durch. Zu jeder Funktionsklasse wird eine Testklasse
programmiert, die die Funktion stimuliert, das Verhalten auswertet und in ein
Protokollfile schreibt. Zur Ableitung der Testfälle gelangen Methoden wie
Äquivalenzklassenbildung und Grenzwertanalyse zum Einsatz.
2.2.3 Funktionaler Modultest (SIL)
Die ZF setzt auf in-the-Loop-Tests, bei denen die Umgebung des Testobjekts
simuliert wird. So gibt es in jedem Projekt auch ein Software-in-the-Loop 3 -System als
Integrations- und Testumgebung. Funktionales Verhalten der Software kann damit
schon beim Software-Entwickler am PC getestet werden.
Die funktionalen Modultests auf der SIL-Umgebung erlauben es, das
Systemverhalten schon in einer sehr frühen Testphase zu bewerten und Fehler zu
erkennen. Die Kopplung mit dem Debugger und einem Codeabdeckungs-Tool
erlaubt effiziente White-Box-Tests.
2.3 Integrationstest
Der Fokus beim Integrationstest (Abb. 3) liegt auf dem Zusammenspiel der
Softwarebausteine und damit deren Schnittstellen. Die Integrationsstrategie legt fest,
in welchen Schritten die Module ins Gesamtsystem integriert werden. Zu jedem
Integrationsschritt gehört auch ein Integrationstest, der das Zusammenspiel der
integrierten Teile überprüft. Die Regressionsstrategie sieht zu jedem Integrationstest
einen automatisierten Regressionstest vor.
3 SIL – Software in the Loop – Die Software wird auf dem PC in einer simulierten Umgebung ausgeführt.

Ziele
Testendekriterien
� Funktionsnachweis, insbesondere das Zusammenspiel der
neuen und geänderten Module
� Nachweis der Rückwirkungsfreiheit
Software in the Loop
Hardware in the Loop
�� Alle übergreifenden Funktions- und Schnittstellenänderungen wurden überprüft
�� Vollständige und fehlerfreie Ausführung des Regressionstests
Abb. 3: Integrationstest
2.3.1 Integration in PC Umgebung (SIL)
Wie schon beim Modultest ausgeführt, gibt es in allen Projekten ein Software-in-the-
Loop-System als Integrations- und Testumgebung. Integrationstests, die nicht direkt
durch die Hardware beeinflusst sind, können auf dieser PC Umgebung getestet
werden. Dies sind vor allem die Steuerungsfunktionen und Regelalgorithmen. Je
nach Detaillierung des Umgebungsmodells können auch Funktionen der
Signalbereitstellung, Diagnose bis hin zu Protokollen getestet werden. Der Vorteil
hierbei liegt vor allem in der hohen Verfügbarkeit, den kurzen Rüstzeiten und dem
einfachen Zugriff auf interne Größen.
2.3.2 Integration in Steuergerät (HIL)
Hardware-in-the-Loop-Systeme simulieren die Umgebung von Getriebe und
Fahrzeug und ermöglichen den Anschluss des Steuergerätes mit den elektrischen
Schnittstellen. Diese Umgebung eignet sich optimal, um das Verhalten der Software
im Zielsystem automatisiert zu testen. Einflüsse des Zielcompilers und der Hardware
sind bei den Tests berücksichtigt. Dies ist vor allem notwendig bei Tests von
Laufzeiteinflüssen, den elektrischen Schnittstellen sowie der hardwarenahen
Diagnose.

2.4 Software-Funktionstest/Systemtest
Nach den Integrationstests erfolgt der Funktionstest. Testobjekt ist die integrierte
Software. Das Ziel ist es zu überprüfen, ob die spezifizierten Anforderungen vom
Produkt erfüllt werden. Der Test gegen die Softwarespezifikation wird als Software-
Funktionstest bezeichnet, der Test gegen die Systemspezifikation als Systemtest.
Die Tester validieren, ob die Anforderungen vollständig und angemessen umgesetzt
wurden.
Ziel Sicherstellen, dass die Software alle Anforderungen erfüllt
Hardware in the Loop
Testendekriterien
Fahrzeug
�� Alle neuen und geänderten Anforderungen sind getestet
�� Vollständige und fehlerfreie Ausführung des Regressionstests
Abb. 4: Software-Funktionstest/Systemtest
Prüfstand
Die geeignete Testumgebung wird je nach Testthema und Verfügbarkeit gewählt.
Hardware-in-the-Loop- und Getriebe-Prüfstände haben den Vorteil der
Automatisierbarkeit und der Reproduzierbarkeit von Testläufen. Das Fahrzeug
dagegen ist die reale Umgebung und wird vor allem dann eingesetzt, wenn die
Auswirkung von Softwareänderungen „erfahrbar“ ist. Änderungen zur Steigerung der
Fahrbarkeit oder Verbrauchsoptimierungen sind nur sehr schwer in simulierten
Umgebungen darzustellen und zu bewerten. Dagegen sind Diagnoseprüfungen und
Protokolltests sehr gut an einem HIL-System automatisierbar.

3 Spezifische Anforderungen an den Test
Die geradlinige sequenzielle Struktur, wie sie das V-Modell beschreibt, findet man im
Umfeld der Automobilzulieferer eher selten. Varianten, schnelle Entwicklungszyklen
und zunehmende Modularisierung stellen zusätzliche Herausforderungen an die
Softwareentwicklung und den Test. Drei für die ZF wichtige Herausforderungen,
werden hier ausführlicher dargestellt und Lösungsansätze aufgezeigt.
3.1 Komponentenbasierte Entwicklung
Um die steigenden Ansprüche an Funktionsumfang und Entwicklungszeit zu
beherrschen, werden Softwareteile in unterschiedlichen Projekten wiederverwendet.
Dazu ist es notwendig, komponentenbasiert zu entwickeln. Das heißt, Software-
Komponenten, die in mehreren Projekten benötigt werden, werden generisch
entwickelt und in verschiedene Projekte integriert. Die komponentenbasierte
Entwicklung stellt besondere Anforderungen an die Test- und Integrationsstrategie.
3.1.1 SIL Umgebung für Komponenten
Für die bei der ZF entwickelten Komponenten kommt eine Software-in-the-Loop-
Umgebung als Testplattform zum Einsatz. Die umgebende Software wird wie das
Getriebe- und Fahrzeugmodell simuliert. Dadurch werden funktionale Prüfungen
ermöglicht, ohne auf die Zielplattform und in die Gesamtsoftware zu integrieren. Die
SIL-Umgebung bietet eine frei konfigurierbare Oberfläche und umfangreiche
Möglichkeiten der Automatisierung. Dadurch sind effiziente manuelle und
automatisierte Tests möglich. Dies ermöglicht die schnelle Umsetzung von
Funktionsänderungen und bietet somit die notwendige Flexibilität bei den
Komponentenentwicklern [2].
if (a == b)
c = d;
else
Skripte, Daten Reports
Abb. 5: SIL Umgebung für Komponenten

3.1.2 Integration der Komponenten
Zur Integration der Komponente ins Projekt gibt es zwei grundsätzliche
Möglichkeiten: Die Integrationsaufgaben erfolgen schwerpunktmäßig bei der
Komponente (Abb. 6) oder im Projekt (Abb. 7).
K1
K2
K3
IT
IT
IT
Projekt
K1
K2
K3
IT
Projekt
Abb. 6: Integration bei Komponente Abb. 7: Integration im Projekt
Wird die Integrationsumgebung dem Komponententeam zur Verfügung gestellt, kann
dort schon integriert und getestet werden. Dazu ist aber Know-How für die
Zielplattform notwendig und weitere beteiligte Komponenten müssen mit einbezogen
werden. Dies erfordert eine erhöhte Kommunikation zwischen den
Komponententeams. Nimmt das Projektteam die Integration vor, dann muss dort
Wissen über die Funktionalität und Schnittstellen vorhanden sein. Dieses
zentralisierte Vorgehen bündelt die Kommunikation und das Integrations-Know-How
an einer Stelle. Je nach Anzahl von Komponenten und Projekten verlagern sich die
Vor- und Nachteile der Vorgehensweisen. Die Funktionskomponenten, die
vollständig bei der ZF entwickelt werden, verlagern den Integrationsaufwand zum
Projekt. Dazu werden Integrations-Arbeitspakete geplant, wenn erkannt wird, dass
Änderungen über Komponentengrenzen hinausgehen. Diese Arbeitspakete werden
bei der Gesamtintegration abgearbeitet [3].
3.2 Varianten in Getriebeanwendungen
Die Getriebe entwickeln sich laufend weiter. War noch vor wenigen Jahren der 5-
Gang-Stufenautomat für Pkw in der Entwicklung, sind es jetzt 6 Gänge und mehr.
Die Erweiterung der Gangstufen und Funktionalität erfordert immer leistungsfähigere
Controller mit zunehmendem Speicherbedarf und steigenden Taktfrequenzen. Nicht
zuletzt kommen die Getriebe bei verschiedenen Kunden in verschiedenen
Fahrzeugplattformen zum Einsatz. Dies alles sind Faktoren, die zu neuen Varianten
einer Getriebefamilie führen. Diese Varianten wirken sich auch auf den Softwaretest
aus. Die Tests müssen sicherstellen, dass Änderungen in die richtigen Varianten
einfließen und die Funktionalität unbeteiligter Varianten nicht beeinflusst wird. Dazu
werden variantenübergreifende automatisierte Vergleichstests bei den
Softwarentwicklern eingesetzt. Für die funktionalen Tests der unterschiedlichen

Varianten müssen spezielle Testumgebungen zur Verfügung stehen und die
Testautomatisierung muss angepasst werden. Dabei kommen Konzepte aus der
objektorientierten Softwareentwicklung zum Einsatz.
Software-Plattform
bedient unterschiedliche:
Getriebe
ECU
Kunden
Fahrzeug
Abb. 8: Varianten in Getriebeanwendungen
Varianten
Die Anzahl zu
bedienender
Varianten steigt
3.2.1 Softwareänderungen variantenübergreifend absichern
Um effizient und flexibel zu bleiben, wird die Software unserer Stufenautomaten aus
einem gemeinsamen Sourcepool bedient. Gleichteile zwischen den Varianten
werden in der Software nur einmal abgebildet, Unterschiede werden durch
Präprozessorschalter variiert. Beim Kompilieren wird dann entschieden, welche
Variante gebildet wird. Softwareänderungen, die für eine Variante notwendig sind,
dürfen sich auf andere Varianten nicht auswirken. Dies sicherzustellen ist Aufgabe
von automatisierten Vergleichstests, die den Einfluss von Änderungen auf die
verschiedenen Varianten erfassen und protokollieren.
Grundlage für den Vergleichstest ist eine Testablaufsteuerung, die verschiedene
Versionen und Varianten aus dem Konfigurationsmanagement auswählen und
Testläufe anstoßen kann.
• Im ersten Schritt des Vergleichstest erfolgt eine umfassende statische
Analyse. Damit wird die formale Korrektheit des Codes aller Varianten
nachgewiesen und die Kompilierbarkeit sichergestellt.
• Im zweiten Schritt werden Codeänderungen durch Vergleich der
Präprozessor-Ausgabe zum Referenz-Softwarestand erfasst. Im Differenzreport
wird ersichtlich, in welchen Varianten eine Codeänderung stattgefunden
hat.
Zeit

• Im dritten Schritt wird die Software-in-the-Loop-Umgebung gestartet und die
im vorhergehenden Schritt ausgewählte Software-Variante sowie die
Referenz-Software mit einem Standardskript stimuliert. Ein nachgeschalteter
Messwertvergleich findet Unterschiede im Laufzeitverhalten. Im Differenzreport
wird ersichtlich, in welchen Varianten eine Funktionsänderung stattgefunden
hat.
Der automatisierte Test über die Varianten gibt Sicherheit, dass keine ungewollten
Änderungen in Varianten vorgenommen wurden [1].
Testablaufsteuerung
Formale Korrektheit
prüfen
Codeänderungen
prüfen
Funktionalität
prüfen
Automatische
Auswertung
Referenz-
Stand
Kompilieren/
statische Analyse
Präprozessorvergleich
Software
in the Loop
Messwertvergleich
Dokumentation Differenzreport
Abb. 9: Ungewollte Seiteneffekte verhindern
Test-
Stand
Grafische Grafische Anzeige
Anzeige
3.2.2 Einfluss von Varianten im Software-Funktionstest
Einflüsse von Varianten sind in allen Entwicklungsstufen relevant. Zum einen gibt es
für unterschiedliche Varianten unterschiedliche Anforderungen, die auch dem Test
zugrunde gelegt werden. Zum anderen ändert sich die Hardwareumgebung, wodurch
auch die Umgebungssimulation und die Ansteuerungsfunktionen der
Testautomatisierung angepasst werden müssen. Die Auswirkung zweier
unterschiedlicher Wählhebelkonzepte soll am Beispiel erläutert werden (siehe Abb.
10).
In der Testautomatisierung sollen Funktionen für das Gangeinlegen zur Verfügung
stehen, die später in Testsequenzen verwendet werden. Da die Hardwareansteuerung
im Testautomatisierungssystem von der Wählhebelvariante abhängt,
sind mehrere Implementierungen für das Gangeinlegen notwendig. Die Testsequenz

soll aber eine einheitliche Zugriffsfunktion verwenden. Ein Lösungsansatz für dieses
Problem ist das „Programmieren gegen Interfaces“.
Abb. 10: Varianten am Beispiel Wählhebel
In einer Kundenvariante werden
verschiedene Wählhebelkonzepte verfolgt.
absoluter Wählhebel
� für jede Position gibt es eine definierte
Wählhebelstellung.
relativer Wählhebel
� ausgehend von der eingelegten Position
wird durch Vor- und Zurücktippen die
Position gewechselt.
Eine Funktion „Position_D_einlegen()“
in der Testautomatisierung hat
verschiedene Ausprägungen.
Eine Interface-Klasse abstrahiert die Schnittstellen von der Implementierung. Bei der
Erstellung der Testsequenzen wird auf die Interface-Klasse zugegriffen, somit bleibt
die Sequenz wiederverwendbar. Vor dem Durchlauf des Tests muss die Auswahl der
geeigneten Implementierung erfolgen. Je nach Variante werden entsprechende
Instanzen gebildet und den Sequenzen übergeben. [5]
class Lever
setPosD()
setPosN()
class AbsoluteLever
setPosD()
setPosN()
class RelativeLever
setPosD()
setPosN()
###Testsequenz
class Sequenz:
def execute (self,
lev = Lever()):
lev.setPosN()
lev setPosD()
Abb. 11: Programmieren gegen Interfaces
Programmieren gegen Interfaces
� Bilden einer „abstrakten Basisklasse“ für
den Wahlschalter, die die Schnittstellen
der Methoden zur Verfügung stellt.
� Für jede Variante wird eine
Implementierung bereitgestellt.
� Die Testsequenzen arbeiten mit der
„abstrakten Basisklasse“.
� Erst beim Erstellen des Testlaufs wird
entschieden, welche Implementierung
verwendet wird.
Die Testsequenzen sind unabhängig
von der Wählhebel-Variante wieder
verwendbar.

Durch das Programmieren gegen Interfaces kann nicht nur Hardware abstrahiert
werden, es können alle Funktionen unabhängig von der zu testenden Variante
bereitgestellt werden. Diese Methode ist grundlegend für den Aufbau von Test-
Bibliotheken.
3.3 Verteilte Entwicklung – Verteilte Tests
Die ZF hat in ihren PKW Getriebeprojekten schon langjährige Erfahrung mit verteilter
Entwicklung. Bis zu sechs verschiede Softwarepartner arbeiten in einem Projekt
zusammen. Bei dieser verteilten Entwicklung wird auch verteilt getestet. Um
sicherstellen zu können, dass die Software vollständig und ausreichend abgeprüft
wird, ist eine Übersicht aller Testaktivitäten im Projekt notwendig.
�Sammlung aller Testthemen für
ein Projekt
�Auflistung aller beteiligter
Entwicklungspartner
�Für jedes Testthema:
� Testumfang
� Häufigkeit des Tests
� Testumgebung
� Testtiefe
� Testverantwortung
�� Überblick über die Testaktivitäten
�� Identifikation von Testlücken
Abb. 12: Übergreifende Testaufteilung
In Projekten der ZF gibt es dazu die „organisationsübergreifende Testaufteilung“ als
zentrales Dokument. Es wird eine Matrix über die Testthemen im Projekt und den
beteiligten Entwicklungspartnern gebildet. Die Testthemen werden aus den
Funktionsanforderungen und dem Design abgeleitet und müssen die notwendigen
Testfelder vollständig erfassen. Jeder Test wird kategorisiert und in die Matrix
eingetragen.
Sind die Tests erfasst, so können den Tests beliebige zusätzliche Informationen
zugeordnet werden. Üblich sind neben Umfang und Häufigkeit - die Anzahl der
Testfälle, die Testumgebung und die Dauer der Durchführung. Was sich auf den
ersten Blick einfach anhört, hat in der Praxis ein paar Tücken. Die Testthemen
müssen so gewählt und abgestimmt sein, dass zwischen den Entwicklungspartnern
ein einheitliches Verständnis besteht. Die Tests müssen sich den Testthemen

zuordnen lassen, um einen direkten Bezug zu den Testfällen zu bekommen. Um dies
in die unterschiedlichen Strukturen der Software-Partner einzugliedern, bedarf es
konkreter Absprachen.
Sind die Hürden überwunden, so hat man mit der Testmatrix ein einfaches, aber
effizientes Mittel, um den Überblick über die Tests zu wahren und steuernd
eingreifen zu können.
4 Nutzen, Ausblick
In den letzten Jahren ist es der ZF gelungen, einen fundierten und effizienten
Testprozess darzustellen. Eindeutige und angepasste Ziele in jeder Teststufe sorgen
dafür, dass die Tests zum optimalen Zeitpunkt durchgeführt werden. Dadurch
werden alle Aspekte des Softwaretests abgedeckt und ohne den Aufwand zu
steigern, wird die Qualität der Software deutlich erhöht.
Varianten, kurze Entwicklungszyklen, der zunehmende Funktionsumfang und die
verteilte Entwicklung sind Anforderungen, die beherrscht werden müssen. Um
effizient zu bleiben, sind realitätsnahe Simulationsumgebungen und ein hoher Automatisierungsgrad
beim Test nicht mehr wegzudenken. Werden Komponenten von
unterschiedlichen Partnern entwickelt, so sind eine abgestimmte Integrationsstrategie
und regelmäßige Durchsprachen der Testaktivitäten zwischen den
Entwicklungspartnern notwendig, um Mehrfachaufwand und Lücken zu vermeiden.
Aktuelle Arbeiten beschäftigen sich mit der Wiederverwendung von Testfällen und
der Erstellung einer geeigneten Testfall-Bibliothek. Ein zweiter Schwerpunkt liegt in
der automatisierten Generierung von Testfällen für die unterschiedlichen Teststufen.
Durch diese Maßnahmen soll der Aufwand für Tests nochmals deutlich gesenkt
werden. Dies ermöglicht eine größere Testtiefe und kurze Entwicklungszyklen.
5 Literatur
[1] DORNSEIFF M.; STAHL M.; SIEGER M.: Durchgängige Testmethoden für
komplexe Steuerungssysteme. Elektronik im Kraftfahrzeug, Baden-Baden, 2001
[2] BAUER G.; HÄBE K.; DORNSEIFF M.: Teststrategien bei der Entwicklung von
Funktionen. Testen im System- und Software-Life-Cycle, Stuttgart, 2005
[3] WOLFF M.; DEISS H.: Beherrschung vernetzter Systeme durch neue
Testmethodik. In: Hanser Automotive Nr.7-8, 2005
[4] SPILLNER A.; LINZ T.: Basiswissen Softwaretest, Dpunkt Verlag, 2004
[5] BATCHELDER N.: A quest for pythonic interfaces, www.nedbatchelder.com,
2004