• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Erfolgsfaktoren für modellbasiertes Testen
 

Erfolgsfaktoren für modellbasiertes Testen

on

  • 785 views

introductory talk on model-based testing in German

introductory talk on model-based testing in German

Statistics

Views

Total Views
785
Views on SlideShare
779
Embed Views
6

Actions

Likes
0
Downloads
7
Comments
1

1 Embed 6

http://paper.li 6

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • http://www.sendspace.com/file/8kn03w
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Erfolgsfaktoren für modellbasiertes Testen Erfolgsfaktoren für modellbasiertes Testen Presentation Transcript

    • 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 ! 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 Standortenimbus AG Hauptquartier in Möhrendorf 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 (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?
    • 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)
    • Kostensenkung durch Automation – derAnfang 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
    • MBT – die Erweiterung des Schemas derAutomatisierung 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
    • 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
    • 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.
    • Was heißt das für das modellbasierteTesten?! Abbildung: Eigenschaften von System oder Tests darstellen! Verkürzung: nur für Test relevante Informationen darstellen! Pragmatik: Testkosten senken, mehr/früher Fehler findenoder kurz ! Tests modellieren Tests ! Tests aus Modellen automatisch modellieren generieren generieren ! Diese beiden Ausprägungen ergänzen sich Tests
    • Begeben wir uns auf die Suche nachModellen ... ! Systemmodelle ! Wiederverwendung von Entwicklungsartefakten für den Test
    • Ist MBT auf der Basis von Systemmodelleneine gute Idee?Pro ContraModell steht (aus Sicht des Tests) Enthält (für den Test) unnötige„sofort“ zur Verfügung und ist immer Informationenaktuell Ggf. inadäquate Modellierungssprache Modellfehler führen zu fehlerhaften Testfällen – QS des Modells notwendig Im Extremfall: wir testen Generator gegen GeneratorWiederverwendung des Tester sind oftmals keine InformatikerModellierungswerkzeugs möglich – Hemmschwelle beim Einsatz eines „Full Feature“ UML-Werkzeugs für sog. „Fachtester“
    • Begeben wir uns auf die Suche nachModellen ...! Testmodelle ! Von Testern (ausschließlich) für den Test erstellte Modelle
    • 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
    • Fahren wir mit dedizierten Testmodellenbesser?Pro Contra„schlankes“ Modell, reduziert auf die Zusätzlicher Aufwand für Erstellungfür den Test notwendigen und Pflege eines zweiten ModellsInformationen Ggf. zusätzlichesModellierungssprache kann ggf. Modellierungswerkzeugunabhängig von der desSystemmodells gewählt werdenErstellung des Testmodells wirkt als Konsistenz zwischen System- undQS-Maßnahme gegen das Testmodell muss sichergestelltSystemmodell bzw. die werden (Traceability)Systemanforderungen
    • Zwischen-Zusammenfassung – MBT- Szenarien, Nutzen und NachteileTestmodellgetriebenes Modellorientiertes TestenTesten ü  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
    • 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 – einEinsatzbeispiel! 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: !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älleWürde man diese manuell spezifizieren wollen, bräuchte mansicherlich deutlich mehr als 1 Arbeitstag (= 28.800 Sekunden)Das Konstruieren des Modells hat ca. 1 - 2 Stunden gedauert
    • 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 ! 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 senkenhttp://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!
    • 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! 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
    • Tame the beast – 2: modellbasierte Tests automatisieren„Suche Buch nach Titel“ Testdatum
    • Zusammenspiel über SchlüsselwörterModellierung Testfälle (=Schlüsselwortsequenzen + Datentabellen) Parser-Framework Schlüsselwort- Bibliothek Testdurchführungswerkzeug Generierung
    • 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 undGrobes Modell parallel automatisierte Durchführung imzum Product Backlog „nightly build“
    • 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! .. hängen stark von den verwendeten Algorithmen und Werkzeugen ab Justierung Über das Über den Über das Testmana- Generator Modell gementModell- Daten- Delta- Guard Diagram Global über- kombi- Generie- Con- Con- Con- Filtern Feedbackdeckung nation rung straints straints straints
    • 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 ; EAP •  A ; B ; C ; D ; A ; C;D;E •  A ; C;D;A ;B;C;D;E E •  A ; C;D;A ; C;D;E
    • Justierung über den Generator -DatenkombinationenData Coverage Criterion! Sampling! Choice-per-suite! Choice-per-variable! Choice-per-path! Exhaustive 48 Testfälle
    • Justierung über den Generator – Delta- GenerierungModel Version 1.0 4 Model Version 1.1 9
    • Justierung über den Generator – Delta-Generierung Die Testfälle mit den meisten Änderungen stehen am Anfang!
    • Justierung über das Modell – GuardConstraints ! 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 – DiagramConstraints ! Einschränkung der Zuweisungsmöglichkeiten für eine Diagrammvariable ! Dies ist KEINE Zuweisung zur Laufzeit, sondern zur Generierzeit
    • Justierung über das Modell – GlobalConstraints ! 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 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 PlanungTestdurchführung, -protokollierung und Ergebnisanalyse
    • 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 AGKleinseebacher Str. 991096 MöhrendorfDEUTSCHLANDTel. +49 9131 7518-0Fax +49 9131 7518-50Weitere Standorte:imbus AGBalanstr. 73 // Gbd. 21a81541 MünchenDEUTSCHLANDTel. +49 89 3219909-0Fax +49 89 3219909-50imbus Rhein-Main GmbHKirschgartenstr. 1565719 HofheimDEUTSCHLANDTel. +49 6192 92192-0Fax +49 6192 92192-50imbus Rheinland GmbHVolksgartenstr. 3650677 KölnDEUTSCHLANDTel. +49 221 998788-0Fax +49 221 998788-50info@imbus.dewww.imbus.de