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

imbus

imbus AG Hauptquartier in Möhrendorf

! 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 in Deutschland

! Joint Venture in Shanghai

Lösungen

! Beratung

! Test-Services

! Training

! Tools

! Datenqualität

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

Testen ist teuer – nicht testen aber noch teurer

! Kosten/Schaden durch nicht gefundene Softwarefehler

! Typische Verteilung des Aufwands in Entwicklungsprojekten

⇒ Kosten reduzieren, aber nicht die (Test-) Qualität?

(The Economic Impacts of Inadequate Infrastructure for Software Testing, NIST 2003)

(Handbook for Software cost estimation, JPL 2003)

Auswertung & Bericht

Beginn

Ende

Analyse & Design

Realisierung & Durchführung

Abschluss

Testkonzept (engl. test plan),

Testpläne

Testspezifikationen

Konkrete Testdaten, Testrahmen, ...

Testprotokolle, Fehlermeldungen &

Testbericht

Planung & Steuerung

Testen ist teuer – aber warum?

6%

54%

38%

Zahlen für einen typischen Systemtest („TMAP Next“, Kap. 11.2)

2%

manuelle Arbeit

Kostensenkung durch Automation – der Anfang eines Schemas

Auswertung & Bericht

Beginn

Ende

Analyse & Design

Realisierung & Durchführung

Abschluss

Testkonzept (engl. test plan),

Testpläne

Testspezifikationen

Konkrete Testdaten, Testrahmen, ...

Testprotokolle, Fehlermeldungen &

Testbericht

Planung & Steuerung

Testmanagementsystem

Testroboter

Modellierung

MBT – die Erweiterung des Schemas der Automatisierung

Auswertung & Bericht

Beginn

Ende

Analyse & Design

Realisierung & Durchführung

Abschluss

Testkonzept (engl. test plan),

Testpläne

Testspezifikationen

Konkrete Testdaten, Testrahmen, ...

Testprotokolle, Fehlermeldungen &

Testbericht

Planung & Steuerung

Testmanagementsystem

Testroboter

MBT-Werkzeug

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

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.

Was ist denn ein Modell?

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 aus Modellen automatisch generieren ! Diese beiden Ausprägungen ergänzen sich

Tests modellieren

Tests generieren

Begeben wir uns auf die Suche nach Modellen ...

! Systemmodelle ! Wiederverwendung von Entwicklungsartefakten

für den Test

Ist MBT auf der Basis von Systemmodellen eine gute Idee?

Pro Contra

Modell steht (aus Sicht des Tests) „sofort“ zur Verfügung und ist immer aktuell

Enthält (für den Test) unnötige Informationen Ggf. inadäquate Modellierungssprache Modellfehler führen zu fehlerhaften Testfällen – QS des Modells notwendig Im Extremfall: wir testen Generator gegen Generator

Wiederverwendung des Modellierungswerkzeugs möglich

Tester sind oftmals keine Informatiker – Hemmschwelle beim Einsatz eines „Full Feature“ UML-Werkzeugs für sog. „Fachtester“

Begeben wir uns auf die Suche nach Modellen ...

! Testmodelle ! Von Testern (ausschließlich) für den Test erstellte Modelle

Vom Modell zum Testfall

Testfall 1

Prüfe dass Tür geschlossen

Trete vor Tür

prüfe dass Tür sich öffnet

gehe durch Tür

Warte 20 Sekunden

prüfe dass Tür sich schließt

Warte bis Tür geschlossen

Testfall 2

Prüfe dass Tür geschlossen

Trete vor Tür

prüfe dass Tür sich öffnet

bleibe vor Tür stehen

Warte 20 Sekunden

prüfe dass Tür geöffnet

gehe durch Tür

warte 20 Sekunden

prüfe dass Tür sich schließt

warte bis Tür geschlossen

Fahren wir mit dedizierten Testmodellen besser?

Pro Contra

„schlankes“ Modell, reduziert auf die für den Test notwendigen Informationen Modellierungssprache kann ggf. unabhängig von der des Systemmodells gewählt werden

Zusätzlicher Aufwand für Erstellung und Pflege eines zweiten Modells Ggf. zusätzliches Modellierungswerkzeug

Erstellung des Testmodells wirkt als QS-Maßnahme gegen das Systemmodell bzw. die Systemanforderungen

Konsistenz zwischen System- und Testmodell muss sichergestellt werden (Traceability)

Zwischen-Zusammenfassung – MBT-Szenarien, Nutzen und Nachteile

Tests modellieren

Tests generieren

Systemmodellgetriebenes Testen ü  Kostensenkung durch automatische

Generierung von Testfällen -  Risiko durch Wiederverwendung eines

fehlerhaften Modells

Testmodellgetriebenes Testen ü  Kostensenkung durch automatische

Generierung von Testfällen -  Zusatzkosten durch zweites Modell

Modellorientiertes Testen ü  Modell dient lediglich als Anhaltspunkt für

Testdesign – kein Generator notwendig -  Begrenzter Nutzen (Transparenz)

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

Nutzen veranschaulicht – ein Einsatzbeispiel

! KFZ-Verkaufssystem „VirtualShowRoom“, Teilsystem „CarConfigurator“

Preisberechnung - Ablauf

2 Testfälle

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

Gesamtzahl der Testfälle

! Mögliche Zubehörkombinationen: z= = 1 + 8 + 28 + 56 + 70 + 56 = 219

! * 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

1+8n!

"#$

%&

n=1

5∑

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

Tame the beast

http://www.rifty.de/images/bonus/entscheidung.jpg

! 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 ! Mindestens gleich viele (gute) Testfälle

wie bisher mit weniger Aufwand erzeugen

Ø  Überschaubares, wartbares Modell Ø  Testfallmenge muss sinnvoll

eingeschränkt werden!

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

Tame the beast – 2: modellbasierte Tests automatisieren

UI-Bedienung

UI-Prüfung

UI-Element Testdatum

„Suche Buch nach Titel“

! 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

Tame the beast – 2: modellbasierte Tests automatisieren

Testdatum

„Suche Buch nach Titel“

Parser-Framework

Zusammenspiel über Schlüsselwörter

Modellierung

Generierung

Testfälle (=Schlüsselwortsequenzen + Datentabellen)

Schlüsselwort- Bibliothek

Testdurchführungswerkzeug

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

Generierung und automatisierte Durchführung im „nightly build“

Erstellung der Skript-Bausteine parallel zur Implementierung

Grobes Modell parallel zum Product Backlog

Test Model First – Modellierung vor Coding

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

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

Mittel zur Reduktion der Testfallmenge

Justierung

Über den Generator

Modell-über-

deckung

Daten-kombi-nation

Delta-Generie-

rung

Über das Modell

Guard Con-

straints

Diagram Con-

straints

Global Con-

straints

Über das Testmana-

gement

Filtern Feedback

! .. hängen stark von den verwendeten Algorithmen und Werkzeugen ab

Justierung über den Generator - Modellüberdeckungskriterien

“Graph Coverage Criterion” ! All paths criterion (AP) ! Round trip criterion (RT) ! All activities (AA) ! Happy Paths (HP)

A

C

D

E

B

•  A ; B ; C ; D ; E •  A ; C ; D ; E •  A ; B ; C ; D ; A ; B ; C ; D ; E •  A ; B ; C ; D ; A ; C ; D ; E •  A ; C ; D ; A ; B ; C ; D ; E •  A ; C ; D ; A ; C ; D ; E

AP

RT

AA

HP

Justierung über den Generator - Datenkombinationen

48 Testfälle

Data Coverage Criterion ! Sampling ! Choice-per-suite ! Choice-per-variable ! Choice-per-path ! Exhaustive

Justierung über den Generator – Delta-Generierung

4 9

Mod

el V

ersi

on 1

.0

Mod

el V

ersi

on 1

.1

Justierung über den Generator – Delta-Generierung

Die Testfälle mit den meisten Änderungen stehen am Anfang!

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

Justierung über das Modell – Diagram Constraints

! Einschränkung der Zuweisungsmöglichkeiten für eine Diagrammvariable

! Dies ist KEINE Zuweisung zur Laufzeit, sondern zur Generierzeit

Justierung über das Modell – Global Constraints

! Globale Einschränkung von Datenkonstellationen im gesamten Modell

! Dies ist KEINE Einschränkung zur Laufzeit, sondern zur Generierzeit

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“

Justierung über das Testmanagement – Model-Based Feedback

Testdurchführung, -protokollierung und Ergebnisanalyse

Testmodellierung und -generierung

Visualisierung der Testergebnisse im Modell Entscheidungsgrundlage für Freigabe Verknüpfung der Modellelemente mit Fehlermeldungen

Testmanagement Zuordnung von Anforderungen, Testfällen, Ergebnissen Versionierung Übergang zur Testautomatisierung Filterung Planung

Justierung über das Testmanagement – Model-Based Feedback

Model Entry Defect Search

Defect Entry Model Search

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

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