introductory talk on model-based testing in German

1. Modellbasiertes Testen
Reifes MBT -
Erfolgsfaktoren für modellbasiertes Testen
Thomas Roßner
CTO imbus AG
Gastvortrag an der Hochschule Coburg
01.12.2011
Version 1.0

2. imbus
! Spezialisierter Lösungsanbieter für
Software-Qualitätssicherung und
Software-Test
! Innovativ seit 1992
! Erfahrung und Know-how aus über
3.000 erfolgreichen Projekten
! 180 Mitarbeiter an vier Standorten
imbus AG Hauptquartier in Möhrendorf in Deutschland
! Joint Venture in Shanghai

3. Lösungen
! Beratung
! Test-Services
! Training
! Tools
! Datenqualität

4. Agenda
! Motivation für MBT – mal wieder die Kosten ...
! Auf der Suche nach dem geeigneten Modell
! Hauptnutzen und Hauptrisiko
! Vermeidungsstrategie I – Lawinenreiten
! Vermeidungsstrategie II – Schneefangzäune
! Zusammenfassung, Raum für Fragen und Diskussionen

5. Testen ist teuer –
nicht testen aber noch teurer
! Kosten/Schaden durch nicht gefundene Softwarefehler
(The Economic Impacts of Inadequate Infrastructure for Software Testing, NIST 2003)
! Typische Verteilung des Aufwands in Entwicklungsprojekten
(Handbook for Software cost estimation, JPL 2003)
⇒ Kosten reduzieren, aber nicht die (Test-) Qualität?

6. Testen ist teuer – aber warum?
Beginn
Testkonzept
Planung & (engl. test plan), 6%
Steuerung Testpläne
Analyse & Testspezifikationen 54%
Design
Konkrete Testdaten,
Realisierung & Testrahmen, ...
Durchführung
38%
Auswertung & Testprotokolle,
Fehlermeldungen &
Bericht Testbericht
Abschluss 2%
Zahlen für einen typischen Systemtest
Ende („TMAP Next“, Kap. 11.2)

7. Kostensenkung durch Automation – der
Anfang eines Schemas
Beginn
Testkonzept
Planung & (engl. test plan),
Steuerung Testpläne
Analyse & Testspezifikationen
Design
Testroboter
Konkrete Testdaten,
Realisierung & Testrahmen, ...
Durchführung
Testmanagementsystem
Auswertung & Testprotokolle,
Fehlermeldungen &
Bericht Testbericht
manuelle Arbeit
Abschluss
Ende

8. MBT – die Erweiterung des Schemas der
Automatisierung
Beginn
Testkonzept Modellierung
Planung & (engl. test plan),
Steuerung Testpläne MBT-Werkzeug
Analyse & Testspezifikationen
Design
Testroboter
Konkrete Testdaten,
Realisierung & Testrahmen, ...
Durchführung
Testmanagementsystem
Auswertung & Testprotokolle,
Fehlermeldungen &
Bericht Testbericht
Abschluss
Ende

9. Agenda
! Motivation für MBT – mal wieder die Kosten ...
! Auf der Suche nach dem geeigneten Modell
! Hauptnutzen und Hauptrisiko
! Vermeidungsstrategie I – Lawinenreiten
! Vermeidungsstrategie II – Schneefangzäune
! Zusammenfassung, Raum für Fragen und Diskussionen

10. Was ist denn ein Modell?
Herbert Stachowiak (1921–2004), 1973:
1. Ein Modell ist die Abbildung eines Ausschnitts der realen
Welt (des Originals) oder eines anderen Modells.
2. Ein Modell verkürzt die Darstellung des Originals, d. h., es
bildet nicht alle Eigenschaften ab, sondern nur die vom
Modellersteller als notwendig betrachteten; verschiedene
Modelle bilden dasselbe Original aus verschiedenen Sichten
ab.
3. Ein Modell ist pragmatisch. Ein einziges Original kann
durch eine Vielzahl von Modellen ersetzt werden; welches
dem Original tatsächlich zugeordnet wird, orientiert sich
daran, von wem und wozu es benutzt werden soll.

11. Was heißt das für das modellbasierte
Testen?
! Abbildung: Eigenschaften von System oder Tests darstellen
! Verkürzung: nur für Test relevante Informationen darstellen
! Pragmatik: Testkosten senken, mehr/früher Fehler finden
oder kurz
! Tests modellieren Tests
! Tests aus Modellen automatisch modellieren
generieren
generieren
! Diese beiden Ausprägungen
ergänzen sich
Tests

12. Begeben wir uns auf die Suche nach
Modellen ...
! Systemmodelle
! Wiederverwendung von Entwicklungsartefakten
für den Test

13. Ist MBT auf der Basis von Systemmodellen
eine gute Idee?
Pro Contra
Modell steht (aus Sicht des Tests) Enthält (für den Test) unnötige
„sofort“ zur Verfügung und ist immer Informationen
aktuell Ggf. inadäquate
Modellierungssprache
Modellfehler führen zu fehlerhaften
Testfällen – QS des Modells
notwendig
Im Extremfall: wir testen Generator
gegen Generator
Wiederverwendung des Tester sind oftmals keine Informatiker
Modellierungswerkzeugs möglich – Hemmschwelle beim Einsatz eines
„Full Feature“ UML-Werkzeugs für
sog. „Fachtester“

14. Begeben wir uns auf die Suche nach
Modellen ...
! Testmodelle
! Von Testern (ausschließlich) für den Test erstellte Modelle

15. Vom Modell zum Testfall
Testfall 1 2
Testfall
Prüfe dass Tür geschlossen
Prüfe dass Tür geschlossen
Trete vor Tür
Trete vor Tür
prüfe dass Tür sich öffnet
prüfe dass Tür sich öffnet
gehe durch Tür stehen
bleibe vor Tür
Warte 2020 Sekunden
Warte Sekunden
prüfe dass Tür geöffnet
prüfe dass Tür sich schließt
Warte bis Tür Tür
gehe durch geschlossen
warte 20 Sekunden
prüfe dass Tür sich schließt
warte bis Tür geschlossen

16. Fahren wir mit dedizierten Testmodellen
besser?
Pro Contra
„schlankes“ Modell, reduziert auf die Zusätzlicher Aufwand für Erstellung
für den Test notwendigen und Pflege eines zweiten Modells
Informationen Ggf. zusätzliches
Modellierungssprache kann ggf. Modellierungswerkzeug
unabhängig von der des
Systemmodells gewählt werden
Erstellung des Testmodells wirkt als Konsistenz zwischen System- und
QS-Maßnahme gegen das Testmodell muss sichergestellt
Systemmodell bzw. die werden (Traceability)
Systemanforderungen

17. Zwischen-Zusammenfassung – MBT-
Szenarien, Nutzen und Nachteile
Testmodellgetriebenes Modellorientiertes Testen
Testen ü Modell dient lediglich als Anhaltspunkt für
Testdesign – kein Generator notwendig
ü Kostensenkung durch automatische
- Begrenzter Nutzen (Transparenz)
Generierung von Testfällen
- Zusatzkosten durch zweites Modell
Tests
modellieren
generieren
Tests
Systemmodellgetriebenes
Testen
ü Kostensenkung durch automatische
Generierung von Testfällen
- Risiko durch Wiederverwendung eines
fehlerhaften Modells

18. Agenda
! Motivation für MBT – mal wieder die Kosten ...
! Auf der Suche nach dem geeigneten Modell
! Hauptnutzen und Hauptrisiko
! Vermeidungsstrategie I – Lawinenreiten
! Vermeidungsstrategie II – Schneefangzäune
! Zusammenfassung, Raum für Fragen und Diskussionen

19. Nutzen veranschaulicht – ein
Einsatzbeispiel
! KFZ-Verkaufssystem „VirtualShowRoom“, Teilsystem
„CarConfigurator“

20. Preisberechnung - Ablauf
2 Testfälle

21. Preisberechnung - Daten
5 gültige
Fahrzeugtypen
3 gültige
Sondermodelle
+ „kein
Sondermodell“
8 gültige
Zubehörteile + „kein
Zubehör“
100 gültige
Rabattwerte, davon
5 ausgewählte

22. Gesamtzahl der Testfälle
! Mögliche$ Zubehörkombinationen:
!8
z= = 1 + 8 + 28 + 56 + 70 + 56 = 219
5
1+ ∑ # &
n=1
"n%
! * 5 (Anzahl der Fahrzeugtypen)
! * 4 (Anzahl der Sondermodelle + „kein Sondermodell“)
! * 6 (5 ausgesuchte Rabattwerte + keine Rabatteingabe)
= 26.280 Testfälle
Würde man diese manuell spezifizieren wollen, bräuchte man
sicherlich deutlich mehr als 1 Arbeitstag (= 28.800 Sekunden)
Das Konstruieren des Modells hat ca. 1 - 2 Stunden gedauert

23. Der Fluch des Erfolgs
! „Früher hatten wir 500 Testfälle und 5
Testdesigner – heute sind es 5000
Testfälle und 2 Testdesigner“
! .. und wieviele Tester?
Ø Unmenge an Testfällen kann nicht
durchgeführt werden
Ø Enormer Management-Aufwand
zur Selektion
! .. und wieviele Entwickler?
Ø Viele Testfälle bedeuten auch viele Fehlermeldungen
Ø Weiterentwicklung wird durch Fehlerbehebungen
verlangsamt

24. Tame the beast
! MBT-Ziel 1: Testabdeckung
erhöhen
! mehr Testfälle mit dem gleichen (oder
weniger) Aufwand als bisher erzeugen
Ø Viele Testfälle müssen durchgeführt
werden
Ø Automatisierung!
! MBT-Ziel 2: Testentwurfsaufwand
senken
http://www.rifty.de/
images/bonus/
entscheidung.jpg ! Mindestens gleich viele (gute) Testfälle
wie bisher mit weniger Aufwand erzeugen
Ø Überschaubares, wartbares Modell
Ø Testfallmenge muss sinnvoll
eingeschränkt werden!

25. Agenda
! Motivation für MBT – mal wieder die Kosten ...
! Auf der Suche nach dem geeigneten Modell
! Hauptnutzen und Hauptrisiko
! Vermeidungsstrategie I – Lawinenreiten
! Vermeidungsstrategie II – Schneefangzäune
! Zusammenfassung, Raum für Fragen und Diskussionen

26. Tame the beast – 2: modellbasierte Tests
automatisieren
! Schlüsselwortbasierte Testfallspezifikation
! Testfälle werden durch Aneinanderreihung (fachlich motivierter) Schlüsselwörter beschrieben
! Testdaten werden zu Parametern der Schlüsselwort-Aufrufe
! Schlüsselwortbasierte Testautomatisierung
! Schlüsselwörter werden separat als Skript-Bausteine implementiert
! Framework übernimmt das Parsen der Schlüsselwortsequenzen und Datentabellen
„Suche Buch nach Titel“
UI-Bedienung
Testdatum
UI-Element
UI-Prüfung

27. Tame the beast – 2: modellbasierte Tests
automatisieren
„Suche Buch nach Titel“
Testdatum

28. Zusammenspiel über Schlüsselwörter
Modellierung Testfälle (=Schlüsselwortsequenzen + Datentabellen)
Parser-Framework
Schlüsselwort-
Bibliothek
Testdurchführungswerkzeug
Generierung

29. Automatisiertes MBT - Wann lohnt sich
das?
! Wenn sich Anforderungen und Code häufig ändern und daher
Tests häufig überarbeitet und wiederholt werden müssen
! .. z.B. bei agiler Entwicklung nach Scrum
Erstellung der Skript-
Bausteine parallel zur
Implementierung
Test Model First –
Modellierung vor
Coding
Generierung und
Grobes Modell parallel automatisierte Durchführung im
zum Product Backlog „nightly build“

30. Agenda
! Motivation für MBT – mal wieder die Kosten ...
! Auf der Suche nach dem geeigneten Modell
! Hauptnutzen und Hauptrisiko
! Vermeidungsstrategie I – Lawinenreiten
! Vermeidungsstrategie II – Schneefangzäune
! Zusammenfassung, Raum für Fragen und Diskussionen

31. Ziel: sinnvolle Reduktion der Testfallmenge
! Kritische Frage: Erst mühevoll den Generator
zum Laufen bringen – und jetzt schränken wir
ihn wieder ein?
! Haupt-Erfolgsfaktor von Testautomatisierung
sind i.a. NICHT die Kosten für die erstmalige
Erstellung, sondern für die Wartung bei
Anpassungen des zu testenden Systems
! MBT macht also durchaus Sinn, wenn zwar
keine größere Menge an Testfällen generiert
wird, aber der Anpassungsaufwand für deren
Wartung deutlich gesenkt werden kann

32. Mittel zur Reduktion der Testfallmenge
! .. hängen stark von den verwendeten
Algorithmen und Werkzeugen ab
Justierung
Über das
Über den Über das Testmana-
Generator Modell
gement
Modell- Daten- Delta- Guard Diagram Global
über- kombi- Generie- Con- Con- Con- Filtern Feedback
deckung nation rung straints straints straints

33. Justierung über den Generator -
Modellüberdeckungskriterien
“Graph Coverage Criterion”
! All paths criterion (AP)
! Round trip criterion (RT)
A
! All activities (AA)
B
! Happy Paths (HP)
AA
• A ; B ; C ; D ; E C
RT
• A ; C;D;E HP
D
• A ; B ; C ; D ; A ; B ; C ; D ; E
AP
• A ; B ; C ; D ; A ; C;D;E
• A ; C;D;A ;B;C;D;E E
• A ; C;D;A ; C;D;E

34. Justierung über den Generator -
Datenkombinationen
Data Coverage Criterion
! Sampling
! Choice-per-suite
! Choice-per-variable
! Choice-per-path
! Exhaustive
48 Testfälle

35. Justierung über den Generator – Delta-
Generierung
Model Version 1.0
4 Model Version 1.1 9

36. Justierung über den Generator – Delta-
Generierung
Die Testfälle mit den
meisten Änderungen
stehen am Anfang!

37. Justierung über das Modell – Guard
Constraints
! Datenkombinationen, für die nicht alle Constraints auf
einem Pfad wahr sind, werden für diesen Pfad nicht
generiert
! Dies ist KEINE Auswertung zur Laufzeit, sondern zur
Generierzeit

38. Justierung über das Modell – Diagram
Constraints
! Einschränkung der Zuweisungsmöglichkeiten für eine
Diagrammvariable
! Dies ist KEINE Zuweisung zur Laufzeit, sondern zur
Generierzeit

39. Justierung über das Modell – Global
Constraints
! Globale Einschränkung von Datenkonstellationen im
gesamten Modell
! Dies ist KEINE Einschränkung zur Laufzeit, sondern zur
Generierzeit

40. Justierung über das Testmanagement -
Filtern
! Generierte Testfälle tragen Management-Information, z.B.
Requirement-Keys aus RM-Tool, Prioritäten etc.
! Filter im Testmanagementtool NACH der Generierung:
„gib mir alle Testfälle mit Eigenschaft X“

41. Justierung über das Testmanagement –
Model-Based Feedback
Testmodellierung und -generierung
Testmanagement
Zuordnung von
Anforderungen,
Testfällen, Ergebnissen
Versionierung
Visualisierung der Testergebnisse im Modell
Entscheidungsgrundlage für Freigabe Übergang zur
Testautomatisierung
Verknüpfung der Modellelemente mit
Fehlermeldungen Filterung
Planung
Testdurchführung, -protokollierung und
Ergebnisanalyse

42. Justierung über das Testmanagement –
Model-Based Feedback
Model Entry
Defect Search
Defect Entry
Model Search

43. Agenda
! Motivation für MBT – mal wieder die Kosten ...
! Auf der Suche nach dem geeigneten Modell
! Hauptnutzen und Hauptrisiko
! Vermeidungsstrategie I – Lawinenreiten
! Vermeidungsstrategie II – Schneefangzäune
! Zusammenfassung, Raum für Fragen und Diskussionen

44. imbus AG
Kleinseebacher Str. 9
91096 Möhrendorf
DEUTSCHLAND
Tel. +49 9131 7518-0
Fax +49 9131 7518-50
Weitere Standorte:
imbus AG
Balanstr. 73 // Gbd. 21a
81541 München
DEUTSCHLAND
Tel. +49 89 3219909-0
Fax +49 89 3219909-50
imbus Rhein-Main GmbH
Kirschgartenstr. 15
65719 Hofheim
DEUTSCHLAND
Tel. +49 6192 92192-0
Fax +49 6192 92192-50
imbus Rheinland GmbH
Volksgartenstr. 36
50677 Köln
DEUTSCHLAND
Tel. +49 221 998788-0
Fax +49 221 998788-50
info@imbus.de
www.imbus.de