Modelle & MBT
DRY durch Zustandsmodelle – Szenarien systematisch ableiten statt Testfälle duplizieren.
Eine weitere DRY-Methode ist der Einsatz von Modellen (Model-Based Testing). Statt jeden Testfall einzeln zu schreiben, wird das Systemverhalten abstrakt beschrieben – z. B. durch ein Zustandsmodell. Aus dem Modell lassen sich Testfälle automatisch generieren.
Beispiel: Checkout-Zustandsmodell
Ablage:
inhalt/assets/diagrams/dry-modelle/checkout-flow.puml
@startuml
skinparam shadowing false
skinparam defaultTextAlignment left
title Checkout – Zustandsmodell (Abstrakt → Konkret via OKW)
[*] --> LoggedOut
LoggedOut --> LoggedIn : Log In(user, pass) [valid]
LoggedOut --> LoginError : Log In(user, pass) [invalid]
LoginError --> LoggedOut : Dismiss Error
state LoggedIn {
[*] --> Browsing
Browsing --> Cart : Add Item(itemId)
Cart --> Browsing : Remove Item(itemId)
Cart --> Checkout : Proceed To Checkout
}
Checkout --> Paid : Pay Order(method) [payment ok]
Checkout --> PaymentError : Pay Order(method) [payment failed]
PaymentError --> Checkout : Retry Payment
Paid --> [*]
@enduml
Abgeleiteter Testfall (Beispiel)
*** Test Cases ***
Checkout_Success_Path
Log In Alice Secret123
Add Item To Cart BOOK-1
Proceed To Checkout
Pay Order CreditCard
VerifyValue OrderStatus SUCCESS
Vorteile
Redundanzarm – Szenarien sind nicht mehrfach niedergeschrieben.
Systematisch – auch „unpopuläre“ Pfade (Fehlerfälle) werden generiert.
Erweiterbar – neue Zustände/Übergänge werden einmalig im Modell ergänzt.
Fallstricke
Over-Engineering – für einfache Systeme lohnt MBT nicht immer.
Generierungskomplexität – zu viele Zustände/Übergänge → Testexplosion.
Pfad-Auswahl – man muss bewusst entscheiden, welche Pfade getestet werden sollen.
Zuletzt aktualisiert