Eine(r) für alle Fälle Gibt es die ideale Testbeschreibung? Abstract Eine Vielzahl unterschiedlichster Testmethoden und Testbeschreibungssprachen ist am Markt verfügbar. Die Methoden und Sprachen sind oft für spezielle Entwicklungsphasen, Domänen, Anwender-Skills und Testarten konzipiert und damit in ihrem Bereich effizient einsetzbar. In dieser Arbeit werden Bewertungs-Kriterien für Testbeschreibungen, mit ihren jeweiligen Polen dargestellt. Eine Analyse zeigt, dass es keine Testbeschreibung gibt, die alle Anforderungen optimal erfüllt. Eine Lösung stellt die flexible Synthese verschiedener Notationen und Testwerkzeuge dar, mit der [dann] ein Gesamtoptimum erzielt wird. Wenn gleichzeitig ein einheitliches Testdatenmanagement eingesetzt wird, kann die Produktivität maßgeblich gesteigert werden. Im Vortrag wird weiterhin gezeigt, wie die aktuellen Entwicklungen der Vector Test Solution diesen effizienten Ansatz aufnehmen und so einen Pfad zur Reduktion der Produkt-Entwicklungskosten eröffnen. 1) Testen das notwendige Übel? Die Erstellung und Durchführung von Tests verursacht erst einmal unerwünschte Effekte: Sie sind umfangreich und teuer in der Erstellung und Ausführung. Testaktivitäten gehen folglich zu Lasten anderer Aktivitäten beziehungsweise des Budgets. Für die Erstellung und Ausführung der Tests ist vielfach eine intensive Kommunikation zum meist ohnehin voll ausgelasteten Entwicklungs-Bereich notwendig, belastet diesen also zusätzlich. Tests sind teilweise sehr komplex und darum schwierig zu erstellen und zu prüfen. Tests sind spezifisch für Varianten, für Auftraggeber, für Testwerkzeuge und damit nicht so gut wiederverwendbar wie sie eigentlich sein könnten. Tests münden nicht unmittelbar in Produktfeatures, bedeuten also scheinbar keinen Mehrwert für den Anwender. Veränderungen an Tests treten mindestens genauso häufig auf wie Veränderungen an Anforderungen. Unumstritten ist allerdings die Tatsache, dass nicht ausgereifte Testprozesse sehr hohe Risiken sowohl für den Anwender also auch die Hersteller von Produkten darstellen. Eine(r) für alle Fälle Gibt es die ideale Testbeschreibung? 1/9
2) Anforderungen an eine Testbeschreibung Die Beteiligten einer Produktentwicklung haben verschiedene und teilweise wenig überlappende Anforderungen an zu nutzende Testbeschreibungen, insbesondere an die formale ausführbare Testsprache, in der die Tests notiert sind. Wichtige Anforderungen eines Domänenexperten sind beispielweise: Lesbare, verständliche und prüfbare Notation Ad-hoc Erstellung und Modifikation von Tests ist möglich Gemeinsames Verständnis der Abläufe mit den Entwicklern und Testingenieuren, insbesondere auch bei Abweichungen vom Sollverhalten Wichtige Anforderungen der Steuergeräteentwickler und Testingenieure sind: Die Komplexität der Testsprache ist an die Aufgaben angepasst. Definiertes Zeitverhalten, insbesondere wenn Echtzeitfähigkeit erforderlich ist; performante Ausführung Komfortable und effiziente Anwendung der Testsprache und der passenden Entwicklungsumgebung Mit der Testsprache kann sehr leicht mit dem System unter Test interagiert werden, dies umfasst Hardware-, Software- und Protokollzugänge. Genauso leicht sollte die Steuerung der angebundenen Testumgebung möglich sein. Die Testsprache bietet eine sehr einfache und gut lesbare Notation, kann aber bei Bedarf auch für komplexe Abläufe eingesetzt und erweitert werden. Erstellte Testabläufe sind leicht wartbar Testabläufe können in Configuration Management Systemen verwaltet werden; Weiterentwicklungen (Unterschiede durch Weiterentwicklungen) sind darstellbar und nachvollziehbar. Die Kompatibilität von bereits erstellten Tests hin zu neueren Versionen der Testsprache und Testumgebung ist selbstverständlich. Ein Manager wird eher folgende Punkte als wichtig erachten: Die Testsprache ist schnell erlernbar und effizient einsetzbar Investitionen in bereits erstellte Testabläufe sind gesichert und mehrfach nutzbar Testabläufe sind wiederverwendbar auf unterschiedlichen oder/und unterschiedlich ausgeprägten Testsystemen Die Testsprache ist geeignet für mehrere (möglichst viele) Produktentwicklungsphasen und passt zu den unterschiedlichen Skills der Mitarbeiter Die Testsprache lässt sich an Artefakte vorheriger Phasen des Entwicklungsprozesses koppeln und erlaubt somit eine Traceability bis hin zu Anforderungen Eine(r) für alle Fälle Gibt es die ideale Testbeschreibung? 2/9
Viele dieser Anforderung sind widersprüchlich oder können nur schwer gleichzeitig erfüllt werden, wie zum Beispiel einfache Notation versus für komplexe Testabläufe geeignet. 3) Ein Testansatz für alle Fälle? Neben den oben aufgelisteten Anforderungen erfordern die unterschiedlichen Produktentwicklungsphasen oft ganz spezielle Testansätze. Deren Abbildung in eine einzige Testsprache oder gar in ein einziges Testwerkzeug stellt durchaus eine Herausforderung sowohl für die Technologie als auch für den Anwender dar. Folgende erweiterbare Liste von Test-Aktivitäten illustriert die Anforderungen recht deutlich: Frühe Absicherungen wie Model-in-the-Loop (MIL) Tests, Software-in-the-Loop (SIL) Tests, Fahrdynamiktests Entwicklungstests wie Modultests, Performancetests Systemtests, Dauerlauftests, Funktionstests Späte Absicherungen wie Hardware-in-the-Loop (HIL) Tests, Vehicle-in-the-Loop (VIL) Tests, Erprobungsfahrten EMV-Tests MMI-Tests, als White-Box-Test oder kamerabasiert als Black-Box-Test Können diese Aktivitäten tatsächlich mit einer einzigen Testbeschreibung abgehandelt werden? Können diese Aktivitäten mit einem einzigen Testsystem durchgeführt werden? Ein Blick in den Markt zeigt mehrere Anbieter, Standards und Vorgehensweisen. Dabei lässt sich beobachten, dass jeweils bestimmte Aspekte sehr gut, andere dafür weniger gut umgesetzt sind. Beispielsweise hinsichtlich des Echtzeitanspruchs, der Möglichkeit einer direkten HIL- Anbindung, der Austauschbarkeit usw. 4) Kriterien zur Analyse der Testsprachen Testsprachen werden nach verschiedenen Gesichtspunkten konzipiert und können dementsprechend klassifiziert werden. Im Folgenden werden verschiedene Kriterien mit ihren jeweiligen Ausprägungen dargestellt, die in den meisten Fällen nicht gleichermaßen gut zu erreichen sind, quasi Pole sind. Zeitverhalten: a) Definiertes und gutes Echtzeitverhalten mit vorhersagbaren Antwortzeiten. Einbindbarkeit von fremd-implementierten Code-Teilen, sofern diese bestimmten grundlegenden architektonischen und technischen Kriterien genügen. Eine(r) für alle Fälle Gibt es die ideale Testbeschreibung? 3/9
b) Offenheit zur Integration beliebiger Funktionen von extrem kurzen Laufzeiten bis hin zu lange laufenden Berechnungen oder Abfragen von externen Quellen unter Nutzung eines langsamen Übertragungsweges, beispielsweise eines Internet- Dienstes. Notation: a) Vollständige Programmiersprache, mit den üblichen Sprachmitteln wie sie in gängigen Programmiersprachen zu finden sind. b) Klar definierter Satz an Sprach- und/oder Modellierungselementen. Neue Verhaltensmuster erfordern Erweiterungen der Sprache / des Satzes der Modellierungselemente. Solche Sprachen sind meist schnell und gut verständlich, allerdings weniger flexibel. Um beispielsweise in graphischen Modellierungssprachen sowohl die Einfachheit zu behalten als auch ein gewisses Maß an Programmierfähigkeit zu erreichen, könnten einige Modellierungselemente programmierbar gestaltet werden. Weiterhin sind je nach Notation die erforderlichen Anwender-Skills unter Umständen sehr unterschiedlich. Lokalität / Wartbarkeit: a) Auswirkungen von Änderungen sind klar erkennbar, dies erfordert eine gewisse Lokalität. Damit können Testabläufe sehr schnell und spontan angepasst werden. b) Werden die für den Testablauf notwendigen Funktionen ungünstig geordnet, beispielsweise durch eine Durchmischung von HIL-Ansteuerfunktionen mit Funktionen für die Test-Semantik, so geht Übersichtlichkeit verloren. Die eigentlichen Testabläufe können im Extremfall nur noch schwer erkennbar sein. Dies hat zur Folge, dass Auswirkungen von Änderungen nicht mehr leicht abschätzbar sind. Zweckbindung: a) Sprache soll zur gegebenen Testaufgabe optimal passen. Beispielsweise sollen Symbole der Domäne wie Signale, Ein- und Ausgänge, Modellparameter direkte Bestandteile der Test-Sprache sein, und durch Compiler vor der Laufzeit des Tests geprüft und aufgelöst werden. Einen wertvollen Beitrag hinsichtlich Anwendbarkeit ist das Anbieten geeignete Editier-Unterstützungen und graphischer Explorer zur Auswahl der Domänen-Symbole. b) Sprache soll für viele Zwecke und Anwendungen gewappnet sein. Dies hat wiederum Nachteile in einzelnen Bereichen zur Folge. Beispielsweise sind Symbole der Domäne generisch eingebunden, beispielsweise über Strings. Weniger gut lesbare Qualifizierer und entsprechend lange Zeichenketten sind das Resultat. Eine eindeutige Auflösung und Prüfung ist hier oft erst zur Laufzeit des Tests möglich. Eine(r) für alle Fälle Gibt es die ideale Testbeschreibung? 4/9
Portabilität / Austauschbarkeit: a) Portabilität hat mindestens 2 Aspekte: Teilweise sind Tests mit unterschiedlichen Test-Design-Werkzeugen bearbeitbar. Weiterhin sollen einmal formulierte Tests auf anderen Testsystemen ebenso lauffähig sein. Dabei dürfen sich die Semantik und das Zeitverhalten spezifizierter Stimulationen und Prüfungen nicht ändern. b) Es werden bequeme und leicht anwendbare auf die Domäne zugeschnittene Testfunktionen benutzt; diese müssen für andere Testsysteme erst (nach-) implementiert werden. Entwicklungsumgebung a) Es ist eine hoch integrierte Entwicklungsumgebung für die Testentwicklung vorhanden. b) Die Entwicklungsumgebung ist sehr einfach und stellt nur die in einem Kontext benötigten Funktionen bereit. Je nach Schwerpunkt sind nur einige der hier dargestellten oder auch weitere, darüber hinausgehende, Kriterien relevant. Bild 1: Beispielhafte Analyse und Bewertung fiktiver Testsprachen Eine Analyse tatsächlich vorhandener und populärer Testsprachen hinsichtlich dieser und weiterer Kriterien ist eine separate Aufgabe die den Rahmen dieses Vortrags sprengen würde und darum hier nicht weiter fortgeführt wird. Eine(r) für alle Fälle Gibt es die ideale Testbeschreibung? 5/9
5) Fazit Für den geplanten Einsatzzweck einer Testbeschreibung sind jeweils Kriterien aufzustellen, zu gewichten und anschließend die dafür beste Lösung auszuwählen. Das Diagramm oben zeigt sehr gut, dass die fiktiven Testsprachen eine volle Bewertung jeweils nur in einigen Kategorien verdienen, und in anderen etwas oder sogar deutlich schlechter abschneiden. Sinnvoll erscheint hier darum ein abgestuftes Vorgehen, das sich an die jeweilige Notwendigkeit anpasst: Innerhalb eines Testsystems, eine sehr einfache Notation die für das Gros der Testfälle ausreichend ist, und eine flexible und freie(re) Notation für kompliziertere Aufgaben hierbei sollte es sich nicht um einen entweder, oder -Ansatz handeln sondern um eine Synthese, möglichst innerhalb weniger Testbeschreibungssprachen. Die verschiedenen Testbeschreibungsmethoden sollten in einem Gesamtprojekt organisiert werden, so dass nahtlos zur jeweils optimalen Methode gewechselt werden kann. Über verschiedene Entwicklungsphasen hinweg werden auch mittelfristig mehrere Testsysteme benötigt werden. Hier bietet es sich an, die nutzbaren Systeme zu klassifizieren, und Empfehlungen für den Einsatz der Testsysteme und deren Notationen auszusprechen. Durch ein geeignetes Datenmanagement kann eine organisierte Vielfalt trotzdem gut verwaltet und geführt werden. Siehe Vector Test Solution. Eine(r) für alle Fälle Gibt es die ideale Testbeschreibung? 6/9
6) Vector Test Solution Folgende Übersicht stellt die Vector Testlösung im aktuell verfügbaren und im geplanten Stand dar: Bild 2: Überblick über die Vector Testlösung Die Vector Testlösung besteht aus 3 wesentlichen Komponenten: a) HIL Test Bench Als Produkt steht CANoe mit dem VT System und den unterschiedlichen Netzwerkinterfaces zur Verfügung. CANoe mit der Ausführungsplattform selbst ist skalierbar in Leistung und Platzbedarf. Vielfältige Zugänge zum System-Unter-Test sind unterstützt, über konkrete Netzwerkschnittstellen, IOs, Debug-Interfaces, höhere Protokolle wie Diagnose und XCP, usw. b) Test Design und Test Erstellung Von der tabellenartigen (einfachen) Testbeschreibung, über full-featured Programmiersprachen, bis hin zu graphischen Notation werden Lösungen angeboten. Auch eine sehr stark auf Diagnose-Tests fokussierte Lösung ist als Produkt verfügbar. Weiterhin arbeitet Vector derzeit an einer Integrierten Test Design Umgebung, welche mehrere Testbeschreibungen in einem einzigen Werkzeug integriert. c) Test Daten Management Vector konzipiert und entwickelt derzeit ein Werkzeug basierend auf PREEvision, mit dem Eine(r) für alle Fälle Gibt es die ideale Testbeschreibung? 7/9
sämtliche am Testprozess beteiligten Daten versioniert und verwaltet werden können, insbesondere die Eingangsdaten und Ausgangsdaten von Test- Design-Werkzeugen und Test-Ausführungs-Werkzeugen; die Testplanung durchgeführt werden kann die Testdurchführung beauftragt und überwacht werden kann, die Traceability zwischen den Arbeitsprodukten (=Artefakten) hergestellt werden kann, und ein einheitliches Reporting über die verschiedenen Testsysteme hinweg geschaffen wird. Im Rahmen des Vortrags wird insbesondere auf die Komponente Test Design und Test Erstellung näher eingegangen und einige Editoren der neuen Integrierten Test Design Umgebung kurz vorgestellt. 7) Zusammenfassung und Ausblick Die Funktionen im Automobil werden eher u- als abnehmen. Folglich werden die Tests eher umfangreicher und komplexer. Eine einzige allumfassende Testsprache für alle Domänen, Ziele oder Produktphasen ist nicht absehbar, und wie die Analyse zeigt auch nicht erreichbar. Um bei steigenden Anforderungen und Testumfängen weiterhin effizient und schnell Ergebnisse zu erzielen, ist eine flexible Kombination der jeweils optimalen Testbeschreibungsmethode in einer integrierten Entwicklungsumgebung nötig. Einen weiteren Beitrag zur Effizienzsteigerung der Testprozesse bringt das vereinheitlichte Testdatenmanagement in Verbindung mit einem harmonisierten Reporting. Vector investiert strategisch in die Vector Testlösung und stellt damit wesentliche Key-Faktoren für eine noch effizientere Produktentwicklung bereit. Eine(r) für alle Fälle Gibt es die ideale Testbeschreibung? 8/9
Kongress: 4. AutoTest Stuttgart (18.Oct.2012), www.fkfs.de Stand: 10/2012 Autor: Siegfried Beeh, Dipl.-Ing., Product Manager Testing Tools, Gruppenleiter Tel. 0711/80670-0, Fax 0711/80670-111, Vector Informatik GmbH Ingersheimer Str. 24 D-70499 Stuttgart www.vector.com Eine(r) für alle Fälle Gibt es die ideale Testbeschreibung? 9/9