Die jährlich von der Gartner Group durchgeführte „Hype Studie“ ergab zum wiederholten Mal, dass das viel diskutierte modellbasierte Testen (MBT) noch weit von einem praxisrelevanten Einsatz entfernt sei.
Wir wollen in diesem Beitrag das Ergebnis dieser Studie differenzierter beleuchten, denn wie so oft ist vieles nur eine Frage der Definition.
Wenn Sie wissen möchten, welche Möglichkeiten RapidRep auf diesem Gebiet für Sie bereithält, klicken Sie bitte hier: Modellbasiertes testen mit RapidRep.
Zunächst wollen wir klären, was wir unter modellbasiertes Testen verstehen. Das Thema modellbasiertes Testen hat viele Facetten und ringt noch um eine allseits akzeptierte Definition.
Wikipedia und andere Definitionen legen den Schwerpunkt auf die frühen Phasen im Test:
„Modellbasiertes Testen (MBT) ist ein Oberbegriff für die Nutzung von Modellen zur
- Automatisierung von Testaktivitäten.
- Generierung von Testartefakten im Testprozess.
Darunter fällt insbesondere die Generierung von Testfällen aus Modellen (z.B. unter Verwendung der UML), die das Sollverhalten des zu testenden Systems beschreiben.“
(Quelle: Wikipedia)
Die Generierung von Testartefakten stellt aus unserer Sicht nur einen Teilaspekt von MBT dar. Die maschinelle Erzeugung von Testfällen und/oder Testdaten aus einem fachlichen Modell heraus trägt zu einer effizienteren Automatisierung in der Testvorbereitung bei.
Der größte Nutzen von MBT besteht in der Möglichkeit die sich ständig wiederholende Testdurchführung und die Testauswertung hochgradig automatisieren zu können.
Die folgende Grafik eignet sich sehr gut, die Einbettung von MBT in den Entwicklungsprozess von Software darzustellen und zu erläutern. Es handelt sich dabei um eine für technische Systeme modifizierte Form des sogenannten wissenschaftlichen Erkenntnisprozesses, der sich in den empirischen Wissenschaften seit Jahrhunderten bewährt. Der wissenschaftliche Erkenntnisprozess setzt allerdings ein reales System voraus (z.B. Planetenbahnen, Atomkerne etc.). Daher beschreibt die Abbildung ein analoges Vorgehen für Systeme, die erst noch entwickelt und aufgebaut werden sollen. Solche Systeme können z.B. ein Aufzug in einem Hochhaus oder ein Softwareprogramm sein.
Anforderungen
Alle Eigenschaften, die das technische System am Schluss besitzen soll, müssen zu Beginn möglichst präzise vorliegen. Das Requirements Engineering sammelt und spezifiziert alle funktionalen und nicht funktionalen Anforderungen.
Konstruktionsplan
Der Konstruktionsplan muss so vollständig sein, dass sich aus diesen Angaben das technische System eindeutig aufbauen lässt.
Technisches System
Das aufgebaute System wird üblicherweise in ein umgebendes System integriert. Sobald das aufgebaute System innerhalb einer Systemumgebung lauffähig ist, können an diesem System Experimente durchgeführt werden. Das System wird über Impulse angeregt und reagiert entsprechend.
Systemdaten
Durch Experimente am technischen System lassen sich Input/Output Zusammenhänge gewinnen. Die Systemdaten eines technischen Systems dienen in der Folge dazu, das Systemverhalten mit den gestellten Anforderungen zu vergleichen.
Stimmt das anhand der Systemdaten ermittelte Systemverhalten nicht mit den Anforderungen überein, sind Anpassungen am Konstruktionsplan oder beim Aufbau des technischen Systems vorzunehmen.
Diese iterativen Veränderungen am technischen System und das wiederholte Testen des Systems sind sehr kostenintensiv und verzögern die Freigabe.
Model Based Testing ist eine demgegenüber deutlich vorteilhaftere Vorgehensweise!
Das MBT ist im Diagramm grün hervorgehoben.
Abstraktes Modell
Ausgehend von dem Konstruktionsplan basiert das Vorgehen auf einem abstrakten Modell. Wie alle Modelle entsteht auch dieses durch Abstraktion und Idealisierung. Das abstrakte Modell ist ein vereinfachter Konstruktionsplan.
Simulationsmodell (Referenzimplementierung)
Das abstrakte Modell dient als Vorlage für den Aufbau eines Simulationsmodells. Der Begriff des Simulationsmodells stammt aus dem wissenschaftlichen Erkenntnisprozess und sollte im Kontext von MBT besser Referenzimplementierung heißen. Die Verifikation stellt sicher, ob das Simulationsmodell fehlerfrei aus dem abstrakten Modell entstanden ist.
Modelldaten
Die Referenzimplementierung ist ein lauffähiges Simulationsmodell. Das Verhalten des Modells ergibt sich aus dem durch Experimente gewonnenem Antwortverhalten.
Die Validierung eines Modells kann nur durch einen Abgleich zwischen Systemdaten und Modelldaten erfolgen. Sofern das abstrakte Modell aus mathematischen Formeln oder Gleichungen besteht, ermöglicht die Deduktion direkt eine analytische Ermittlung der Modelldaten (eher selten).
Einsatzmöglichkeiten
Szenario A: das technische System ist noch nicht aufgebaut
Das technische System befindet sich in der Planung existiert aber noch nicht. Daher stehen auch keine Systemdaten zur Verfügung.
Ein Fachmann muss die Modelldaten mit den Anforderungen vergleichen und plausibilisieren. Wenn die Modelldaten zeigen, dass nicht alle Anforderungen erfüllt sind, sind Änderungen am Konstruktionsplan oder am abstrakten Modell durchzuführen.
Sobald ein Fachmann die Korrektheit des Modells bestätigt, kann mit dem Aufbau des technischen Systems begonnen werden.
Sobald das technische System einsatzfähig ist kommt zusätzlich Szenario B für die Testautomatisierung zum Einsatz.
Szenario B: das technische System existiert bereits
Das technische System ist vorhanden und steht für Experimente zur Ermittlung von Systemdatem bereit.
Die Modelldaten aus dem Simulationsmodell stellen das Soll-Verhalten für das technische System dar. Die gleichen Experimente (gleicher Anreiz) können parallel auf dem technischen System und dem Simulationsmodell durchgeführt werden. Für jedes durchgeführte Experiment (=Test) müssen Systemdaten und Modelldaten übereinstimmen, es sei denn das technische System ist falsch oder unvollständig.
Da das abstrakte Modell durch Idealisierung und Abstraktion eine Vereinfachung darstellt, sind tolerierbare Abweichungen zwischen System- und Modelldaten innerhalb eines bestimmten Intervalls zu berücksichtigen.
Schlussfolgerungen
Die im Diagramm dargestellte Modellierung technischer Systeme ist sehr gut auf die IT Branche anwendbar.
Der Auftraggeber einer Software stellt die fachlichen Anforderungen in Form einer Leistungsbeschreibung oder eines Pflichtenhefts zusammen. Daraus leiten Software Ingenieure ein DV-Konzept ab und geben es dann an die Entwickler für die Umsetzung. Der Auftraggeber nimmt das Programm ab, sobald der Test die geforderten Anforderungen erfüllt.
Der Softwareentwicklungsprozess in seiner heutigen Form beschreibt von der Anforderung bis hin zum Abnahmetest das Vorgehen zur Entwicklung von Software. Egal ob agile Softwaremethoden oder V-Modelle zum Einsatz kommen: Fehler kosten Geld, verzögern den Einsatz von Programmen und der Softwaretest ist ohne MBT schwer automatisierbar und aufwendig.
Vorteile durch MBT
- MBT findet Fehler im Konstruktionsplan noch bevor die technische Umsetzung beginnt (Szenario A).
- Die Referenzlösung lässt sich viel einfacher nachjustieren und die Kommunikation mit dem Fachbereich ist mit Modellen einfacher zu bewerkstelligen als das mit dem Zeigen von Programmzeilen in einer Programmiersprache der Fall wäre.
- Die Referenzlösung kann von einem Fachmann sehr effizient validiert werden. Die Testdaten führen schnell und ohne Umwege zu prototypischen Ergebnissen. Testdaten können aus dem Modell generiert werden oder alternativ aus der systematischen Testfallermittlung verwendet werden.
- Die Umsetzung der Software auf Basis eines validierten Konstruktionsplanes führt zwangsläufig zu weniger Fehlern in der zu erstellenden Software.
- Sobald die Software im Einsatz ist, kann diese hochgradig automatisiert getestet werden. Die Referenzimplementierung fungiert dabei als absolut zuverlässiges Testorakel in der Testdurchführung und Testauswertung.
- Eine hohe Softwarequalität wird mit geringem Aufwand dauerhaft sichergestellt.
Fazit
Model Based Testing wird den Softwareentwicklungsprozess maßgeblich beeinflussen, denn die sich daraus ergebenden Vorteile sind unübersehbar.
Die FINARIS hat mit Hilfe der RapidRep Test Suite das MBT bereits in zwei Projekten sehr erfolgreich durchgeführt. Damit hat MBT aus unserer Sicht den „Hype Status“ längst verlassen.