SlideShare ist ein Scribd-Unternehmen logo
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 Standorten
imbus 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 – 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
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
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 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
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)     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“
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 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 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
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
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:
            !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
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
                         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!
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örter

Modellierung       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 und
Grobes Modell parallel                       automatisierte Durchführung im
zum 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
                                                                             gement


Modell-    Daten-      Delta-    Guard          Diagram    Global
 über-     kombi-     Generie-    Con-           Con-       Con-      Filtern      Feedback
deckung    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 ; 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
Justierung über den Generator -
Datenkombinationen

Data Coverage Criterion
!   Sampling
!   Choice-per-suite
!   Choice-per-variable
!   Choice-per-path
!   Exhaustive
                                  48 Testfälle
Justierung über den Generator – Delta-
          Generierung
Model 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 – 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

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

Weitere ähnliche Inhalte

Ähnlich wie Erfolgsfaktoren für modellbasiertes Testen

Automatisierter Software-Test unter Java
Automatisierter Software-Test unter JavaAutomatisierter Software-Test unter Java
Automatisierter Software-Test unter Java
GFU Cyrus AG
 
Testmanagement mit Visual Studio 2013
Testmanagement mit Visual Studio 2013Testmanagement mit Visual Studio 2013
Testmanagement mit Visual Studio 2013
Nico Orschel
 
Agiles Testen (German)
Agiles Testen (German)Agiles Testen (German)
Agiles Testen (German)
Christian Hassa
 
Einführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software EntwicklungEinführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software EntwicklungChristian Baranowski
 
Einführung in die Software-Qualitätssicherung
Einführung in die Software-QualitätssicherungEinführung in die Software-Qualitätssicherung
Einführung in die Software-QualitätssicherungChristian Baranowski
 
Crowdsourced Mobile Testing – Alternative oder Ergänzung?
Crowdsourced Mobile Testing – Alternative oder Ergänzung?Crowdsourced Mobile Testing – Alternative oder Ergänzung?
Crowdsourced Mobile Testing – Alternative oder Ergänzung?
Connected-Blog
 
Simulieren, Testen, Verifizieren - Alles oder Nichts? Systematische Funktions...
Simulieren, Testen, Verifizieren - Alles oder Nichts? Systematische Funktions...Simulieren, Testen, Verifizieren - Alles oder Nichts? Systematische Funktions...
Simulieren, Testen, Verifizieren - Alles oder Nichts? Systematische Funktions...Leiter AK Software - Dr. Schönefeld
 
Creasoft - Software QS
Creasoft - Software QSCreasoft - Software QS
Creasoft - Software QSCreasoft AG
 
Test Management mit Visual Studio 2012
Test Management mit Visual Studio 2012Test Management mit Visual Studio 2012
Test Management mit Visual Studio 2012
Nico Orschel
 
Test-Alternativen
Test-AlternativenTest-Alternativen
Test-Alternativen
Sebastian Dietrich
 
Ich will agil testen! was muss ich können iqnite 2014 - verison 2.0
Ich will agil testen! was muss ich können   iqnite 2014 - verison 2.0Ich will agil testen! was muss ich können   iqnite 2014 - verison 2.0
Ich will agil testen! was muss ich können iqnite 2014 - verison 2.0
Michael Fischlein
 
Agiles Testen - Überblick
Agiles Testen - ÜberblickAgiles Testen - Überblick
Agiles Testen - Überblick
Claudia Haußmann 🦋
 
QS von IT-Consulting bis Software Development
QS von IT-Consulting bis Software DevelopmentQS von IT-Consulting bis Software Development
QS von IT-Consulting bis Software Developmentadesso AG
 
Abenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-WartungAbenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-Wartung
Ernest Wallmueller
 
Ausweg aus der Kommunikationskrise oder das Ende von „Bei mir funktioniert’s“?
Ausweg aus der Kommunikationskrise oder das Ende von „Bei mir funktioniert’s“?Ausweg aus der Kommunikationskrise oder das Ende von „Bei mir funktioniert’s“?
Ausweg aus der Kommunikationskrise oder das Ende von „Bei mir funktioniert’s“?Nico Orschel
 
Scrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADEDScrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADED
SwissQ Consulting AG
 
SE2013 ANECON Testen in agilen Projekten
SE2013 ANECON Testen in agilen ProjektenSE2013 ANECON Testen in agilen Projekten
SE2013 ANECON Testen in agilen Projekten
Peter Haberl
 
eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
eCATT & OpenSource - Automatisierter Test in heterogenen SystemlandschafteneCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
Christoph Menke
 
Die nächste Generation des Unit Testing
Die nächste Generation des Unit TestingDie nächste Generation des Unit Testing
Die nächste Generation des Unit Testing
Daniel Lehner
 
Automatisiertes webauftritt testen
Automatisiertes webauftritt testenAutomatisiertes webauftritt testen
Automatisiertes webauftritt testen
mradamlacey
 

Ähnlich wie Erfolgsfaktoren für modellbasiertes Testen (20)

Automatisierter Software-Test unter Java
Automatisierter Software-Test unter JavaAutomatisierter Software-Test unter Java
Automatisierter Software-Test unter Java
 
Testmanagement mit Visual Studio 2013
Testmanagement mit Visual Studio 2013Testmanagement mit Visual Studio 2013
Testmanagement mit Visual Studio 2013
 
Agiles Testen (German)
Agiles Testen (German)Agiles Testen (German)
Agiles Testen (German)
 
Einführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software EntwicklungEinführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software Entwicklung
 
Einführung in die Software-Qualitätssicherung
Einführung in die Software-QualitätssicherungEinführung in die Software-Qualitätssicherung
Einführung in die Software-Qualitätssicherung
 
Crowdsourced Mobile Testing – Alternative oder Ergänzung?
Crowdsourced Mobile Testing – Alternative oder Ergänzung?Crowdsourced Mobile Testing – Alternative oder Ergänzung?
Crowdsourced Mobile Testing – Alternative oder Ergänzung?
 
Simulieren, Testen, Verifizieren - Alles oder Nichts? Systematische Funktions...
Simulieren, Testen, Verifizieren - Alles oder Nichts? Systematische Funktions...Simulieren, Testen, Verifizieren - Alles oder Nichts? Systematische Funktions...
Simulieren, Testen, Verifizieren - Alles oder Nichts? Systematische Funktions...
 
Creasoft - Software QS
Creasoft - Software QSCreasoft - Software QS
Creasoft - Software QS
 
Test Management mit Visual Studio 2012
Test Management mit Visual Studio 2012Test Management mit Visual Studio 2012
Test Management mit Visual Studio 2012
 
Test-Alternativen
Test-AlternativenTest-Alternativen
Test-Alternativen
 
Ich will agil testen! was muss ich können iqnite 2014 - verison 2.0
Ich will agil testen! was muss ich können   iqnite 2014 - verison 2.0Ich will agil testen! was muss ich können   iqnite 2014 - verison 2.0
Ich will agil testen! was muss ich können iqnite 2014 - verison 2.0
 
Agiles Testen - Überblick
Agiles Testen - ÜberblickAgiles Testen - Überblick
Agiles Testen - Überblick
 
QS von IT-Consulting bis Software Development
QS von IT-Consulting bis Software DevelopmentQS von IT-Consulting bis Software Development
QS von IT-Consulting bis Software Development
 
Abenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-WartungAbenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-Wartung
 
Ausweg aus der Kommunikationskrise oder das Ende von „Bei mir funktioniert’s“?
Ausweg aus der Kommunikationskrise oder das Ende von „Bei mir funktioniert’s“?Ausweg aus der Kommunikationskrise oder das Ende von „Bei mir funktioniert’s“?
Ausweg aus der Kommunikationskrise oder das Ende von „Bei mir funktioniert’s“?
 
Scrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADEDScrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADED
 
SE2013 ANECON Testen in agilen Projekten
SE2013 ANECON Testen in agilen ProjektenSE2013 ANECON Testen in agilen Projekten
SE2013 ANECON Testen in agilen Projekten
 
eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
eCATT & OpenSource - Automatisierter Test in heterogenen SystemlandschafteneCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
 
Die nächste Generation des Unit Testing
Die nächste Generation des Unit TestingDie nächste Generation des Unit Testing
Die nächste Generation des Unit Testing
 
Automatisiertes webauftritt testen
Automatisiertes webauftritt testenAutomatisiertes webauftritt testen
Automatisiertes webauftritt testen
 

Erfolgsfaktoren für modellbasiertes Testen

  • 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