Upload
trossner
View
824
Download
0
Embed Size (px)
DESCRIPTION
introductory talk on model-based testing in German
Citation preview
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
[email protected] www.imbus.de