7. DEZ 2016

Erfahrungen mit der Einführung von modellbasierter Testspezifikation, Implementierung und Generierung bei einem deutschen Automotive OEM

MATHIAS HELMINGER

Vorstellung

• Seit 1979

• 450 Mitarbeiter

• Hauptsitz München

• Engineering, Beratung, Softwareentwicklung, Testlösungen

• Haupt-Branchen: Automotive, Transportation, Machinery

• Seit 2011 Teil der ASSYSTEM Gruppe (weltweit 11.000 Mitarbeiter)

TABLE OF

CONTENTS Vorstellung

Einsatzumfeld MBT

Kurzintro MBT

Herausforderung für den MBT Einsatz

Erfahrungen

Gewählte Lösungsansätze

Projektumfeld (am Beispiel Automobil OEM)

Prüflinge: • Integrationstests (auch: Komponententests)

• Komponenten verschiedener Hersteller, black-box Sicht

• Zahlreiche mögliche Aktionen, teilweise komplexe Abhängigkeiten

• Teure Prüfstand-Zeit

Zahlreiche Werkzeuge vorhanden (Kollaboration, Versionierung, Spezifikation, Ausführung, Ausführungsplanung, Auswertung, …)

Testfälle mit langen Lebenszyklen und externen Referenzen (z.B. Tracing von Anforderungen, Testergebnissen)

Herausforderung

• Viele heterogene Komponenten / Schnittstellen -> Starke Zunahme durch IoT-Trend

•Oft Black-Box Sicht auf viele Komponenten (häufig mehrere Hersteller)

• Test-Raum sehr groß oder unendlich

• Tests (inklusive Sollverhalten) aufwändig zu entwickeln und zu warten

Schnellüberblick: Model Based Testing

-> Modellbasiertes Design im Testprozess

Testfälle

Testergebnisse

MB

T P

roze

ss

Ausführung

Systembeschreibung

Modell eines Systems (UML-Diagramme, formale Beschreibung, …)

automatische Ableitung

aus Modell

Gewünschte Test-

Abdeckung

Modellierung

Trad

itio

nel

ler

Test

pro

zess

Systembeschreibung

Testfälle

Testergebnisse

Ausführung

manueller Design-Prozess

Eige

ne

Dar

stel

lun

g n

ach

Utt

ing

/ K

amga

, Her

rman

n u

nd

Jo

shi

Woher kommt das Modell für MBT?

Das Modell wird…

• bereits als Spezifikation erstellt

• nach Vorbild von Spezifikation entwickelt

• aus Entwicklungsprozess übernommen (z.B. Modell für Code-Generierung)

Klingt attraktiv, aber

potentiell sehr

problematisch

Diverse

Einflussfaktoren (Projektphase, Komplexität,

Testbarkeit, …)

Ist-Situation (Projektstart)

Vorheriger Ansatz:

• einfache, aber große Modelle (~ DFA)

• zufallsbasierte Generierung (Markov-Ketten)

Probleme:

•Manuell: Soll-Werte, nötige Prüfungen

• Aufwändige Konfiguration des Generators • Manuelle Intervention vor und nach der Generierung

• Geringe Reproduzierbarkeit durch Zufall

•De-facto: Modellierung einzelner Testfälle -> Aufwendig bei Änderungen -> Testabdeckung unklar

• Rudimentäre Anbindung an Tool-Landschaft

Typisches Modell:

X 50

Qu

elle

: al

l4te

c

Anforderungen/Wünsche an ein MBT-Modell

Grundsätzlich: ähnlich zu Model Based Design

Vollständig -> Erlaubt test-relevante Sequenzen (nicht zwingend alle!)

Wartbar/verstehbar -> Für Zusammenarbeit und Übergabe an andere -> Als Diskussionsgrundlage mit anderen Stakeholdern

Maschinenlesbar -> formale Modellierungsart

Generierbar -> Berücksichtigung von Generator-Limits (vgl. Halteproblem) -> Vielzahl von Explorations-Algorithmen existiert

Beeinflussung der Generierung - Motivation

häufige Kritik an MBT:

„Zu viele Testfälle“ „Falsche Testfälle“ „Uninteressante Testfälle“

Ursachen:

• Kritische Logik des Prüflings im Test-Modell nicht modelliert (unbekannt, schwer modellierbar, …)

=> Aufwand

• Kritische Logik des Testmodells zu komplex für Generator => Tool-Problem

• Tester haben spezifische Vorstellungen für relevante Sequenzen (-> Tester Erfahrung/Bauchgefühl, frühere Bugs, must-have Tests, …)

=> Wiederspruch zu MBT-Ansatz?

Entstandenes Tool: MODICA

• Modellierung von Benutzungsmodellen

• Annotation der Modelle (Prüfling Interaktion, Requirements, …)

• Generierung von Testfällen

• Konfiguration und Auswertung der Testabdeckung

• Export ausführbarer Testskripte

Technische Daten

• hierarchische UML-Statecharts

• graphische Modellierung

• Grundlage: Engine von

• Eclipse-basiert

Workflow mit MODICA

C

A

D B

Testfälle

C A B

A A B C

Prüfling

Tester Benutzungsmodell Test Spezifikation

Testergebnisse

Beeinflussung der Generierung - Umsetzung

1. Umsetzung

• Annotation von Stellen im Model

• Regel: Stelle + erlaubte Folge-Stelle(n)

• Beispiel: „Nach X erzwinge Y“

2. Umsetzung

• Angelehnt an reguläre Ausdrücke (RE)

• Beispiel: „Erst Aktionen X,Y,Z dann beliebig bis Stelle A, danach Aktionen U,V,X“

2.A Verbessert

• graphisches Erzeugen und Verfolgen der Regeln (im Statechart)

• Mächtig

• Wenig intuitiv

• RE prinzipiell bekannt

• Trotzdem fehleranfällig

(2 Modelle!)

• Durchbruch aus

Anwendersicht

Eigenschaften typischer Modelle*

• 10-300 States in 1-30 hierarchischen Statecharts

• Einzelne Teil-Diagramme komplex, viele simpel

• Requirements, Prüfling-Interaktion, … als Modellannotation

• Teils umfangreiches Testorakel

• Häufige, kleine Modeländerungen („Vor X muss ab jetzt immer Y passieren“)

-> Testfälle bleiben häufig trotzdem die „gleichen“

* Erfahrungswerte teils auch aus anderen Sektoren wie IoT-Weißware, Geräte für Forstwirtschaft, weiterer Automobil OEM, …

Erfahrungen

• Modellierung ist Arbeit – amortisiert sich aber -> Vollständigkeit, Systematik, komplexe Abhängigkeiten, späte Spez.-Änderungen, …

• Gute Modellierung ist nicht trivial -> sinnvoll: Leitlinien, Muster, Reviews, usw. (Stichwort Wartbarkeit)

• Modellierung kann Spezifikationsfehler aufdecken und Systemverständnis erhöhen (mehrfaches User-Feedback)

• MBT-Ansatz muss zu Prüfling und Testzielen passen -> kontinuierlich/eventbasiert, Zustandsautomaten, Komplexität, Art der Exploration, …

• Vorhandene Automatisierung (z.B. via keyword-based-testing) oft einfach integrierbar -> Aber: enge Integration kann trotzdem sehr wertvoll sein

• Semiautomatische Generierung: Das Beste aus beiden Ansätzen -> nützlich aber nicht ohne Risiken

• Werkzeug-Funktionen für Modell-Verständnis/Debugging sehr wichtig -> leicht zu unterschätzen

Zusammenfassung und Ausblick

MBT steht und fällt mit: (Liste nicht abschließend)

• Auswahl von passendem MBT-Ansatz

•Modellqualität

•Werkzeugfunktionen - Modellwartung - Integration in Umfeld

Für uns offene Frage: Markov-Ketten bieten großes Potential, aber wie kann ein sinnvoller Hybrid aus deterministischer und probabilistischer Generierung aussehen?