Dr. Christian Brandes 15. November 2016

Modellbasiertes Testen – revisited

Modellbasierte Testansätze unterscheiden sich in vielfältiger Weise. © crevis / Fotolia.com — © crevis / Fotolia.com

Im Oktober 2015 veröffentlichte das "International Software Testing Qualifications Board" (ISTQB, [1]) den Lehrplan zum "Certified Model Based Tester". Das bedeutet, dass man sich nach Bestehen der zugehörigen Prüfung nun auf Konferenzen als "zertifizierter modellbasierter Softwaretester" vorstellen kann. Was durchaus bemerkenswert ist, denn: Bei dem neuen Lehrplan handelt es sich um eine so genannte "Extension" zur etablierten "Foundation Level"-Testausbildung [2], und weitere solche Extensions sind "Agile Tester" (erschienen), "Usability Tester" (in Beta) und "Automotive Tester" (in Development).

Modellbasiertes Testen (MBT) in dieser illustren Themenrunde dürfte die eine oder andere Augenbraue nach oben wandern lassen: Während agile Themen in der IT-Branche weit verbreitet sind, haftet dem Einsatz von grafischen Modellen im Test nach wie vor ein Exoten- oder Nischen-Image an (von einigen speziellen Branchen abgesehen). Warum ist also genau dieses Thema dem weltweit agierenden Dachverband eine "Extension" im Ausbildungsschema wert? Vielleicht lohnt sich ein genauerer Blick darauf.

MBT – Vorgehen und Spielarten

Die Grundidee beim modellbasierten Test lautet, aus Modellen Tests zu generieren. Daraus ergeben sich unmittelbar zwei Folgefragen: Welche Modelle? Und was für Tests? Genauer: Eignet sich jedes Modell? Welche Inhalte werden darin wie formal modelliert, und von wem? Werden aus ihnen wirklich ausführbare Tests generiert? Sind andere Testartefakte als Generat denkbar? Was testen die generierten Testfälle, auf welcher Teststufe sind sie angesiedelt? Und wo liegt jeweils der Nutzen im Vergleich zum nicht-modellbasierten Vorgehen?

Modellbasierte Testansätze unterscheiden sich in vielfältiger Weise – in den eingesetzten Modellen, im Umfang der Generierung, im Automatisierungsgrad. Schieferdecker [3] nennt verschiedene Varianten, um Anforderungen, Modelle und Tests zueinander in Beziehung zu bringen. Im deutschsprachigen Begleitbuch zum Lehrplan [4] wird insbesondere eine Kategorisierung nach der Rolle des zu Grunde liegenden Modells vorgenommen. Dort wird unterschieden zwischen

modellorientiertem Testen (Nutzung von Modellen als Input für manuelles Testdesign),
modellgetriebenem Testen (Forward-Generierung von Testartefakten aus Modellen) und
modellzentrischem Testen (Roundtrip-Generierung, d. h. Rückführung dedizierter Testinformationen ins Modell).

Es gibt also nicht "das" MBT und auch kein MBT "von der Stange". Der Grund ist einfach: MBT ist eine Testdesign-Methode unter vielen und in jedem Projekt muss aufs Neue der geeignete "Mix" aus Testmethoden definiert werden, der zu Projektauftrag, -zielen und -randbedingungen passt. Diese so genannte "Teststrategie" ist massiv kontextabhängig und muss zu den Risiken, den Randbedingungen, dem Entwicklungsprozess und den Skills im Team passen. Folglich steht vor jedem MBT-Einsatz die grundsätzliche Frage, ob der vorhandene oder geplante Testprozess von einem Einsatz von Modellen überhaupt profitieren würde. Andernfalls würde das Verhältnis von Aufwand und Nutzen aus dem Ruder zu laufen drohen. Ein Vorgehensmodell zur Evaluation und zur Einführung von MBT ist beispielsweise zu finden in [5] und [6].

Ein Beispiel

Betrachten wir ein einfaches System zur elektronischen Türsteuerung genauer: zur Steuerung einer Schiebetür an öffentlich zugänglichen Gebäuden wie z. B. Krankenhäusern. Das System muss eine Reihe funktionaler Anforderungen erfüllen:

Bei Annäherung von Personen öffnet der Antrieb die Tür automatisch. Der Antrieb ist dazu mit Annäherungssensoren auf der Innen- und Außenseite der Tür verbunden.
Anschlagssensoren teilen dem Antrieb mit, ob die Tür vollständig offen oder geschlossen ist.
Einklemmsensoren sollen erkennen, wenn sich Personen während des Schließvorgangs im Türrahmen befinden.
Ist die Tür geöffnet und nähern sich keine Personen, soll sich die Tür nach 10 Sekunden Wartezeit automatisch wieder schließen. Falls während dieser 10 Sekunden eine Person die Tür durchschreitet, beginnt die Wartezeit von vorne.
Über eine Netzwerkleitung kann die Tür verriegelt werden, wenn sich die Tür im geschlossenen Zustand befindet.

Neben diesen funktionalen stellen sich auch nichtfunktionale Anforderungen, insbesondere solche zur Sicherheit. Ein Beispiel:

Im Gefahrenfall muss die Tür manuell von innen entriegelt und dauerhaft geöffnet werden können.

Eine solche Aufgabenstellung lässt sich gut als Zustandsmodell beschreiben. Eine erste funktionale Modellierung (d. h. noch ohne die Berücksichtigung von Sicherheitsanforderungen) könnte aussehen wie in Abb.1.

Abb.1: Erste Modellierung des Türsteuerungs-Beispiels. © <a href="index.php?id=2968#c19004" target="_self">[4]</a> — Abb.1: Erste Modellierung des Türsteuerungs-Beispiels. © [4]

Ziel soll sein, aus diesem formalen Modell systematisch Testfälle abzuleiten. Dazu sind vorbereitend zwei Aufgaben zu erledigen:

Das Modell muss qualitätsgesichert sein, sei es manuell durch Reviews und/oder werkzeuggestützt durch entsprechende Checks des Modellierungstools.
Eine Generierungsstrategie für Testfälle ist zu definieren und zu implementieren.

Abb.2: Generierte Testfälle. © <a href="index.php?id=2968#c19004" target="_self">[4]</a> — Abb.2: Generierte Testfälle. © [4]

Die Generierungsstrategie arbeitet typischerweise mit Fragestellungen wie: Welche Abdeckung sollen die generierten Tests erreichen? (Alle Zustandsknoten, alle Zustandsübergänge, alle "Pfade" o. ä.) Je nach Entscheidung können kombinatorische Effekte schnell dazu führen, dass sehr viele Testfälle entstehen! Dieses Phänomen ist als "Testfallexplosion" bekannt und in vielen MBT-Projekten ein Thema.

In diesem einfachen Beispiel entscheiden wir uns für folgendes Generierungsvorgehen: Wir betrachten den Zustand Tür geschlossen als Start- und Endzustand. Jeder Testfall soll beim Startzustand beginnen und beim Endzustand enden. Für jeden neu zu generierenden Testfall sucht der Generator vom Startknoten aus nach der ersten noch nicht überdeckten Kante und wählt diese aus; von ihr aus wird dann der kürzeste mögliche Pfad zum Endzustand ausgewählt und weitere berührte Kanten als überdeckt markiert. Zyklen sollen genau einmal durchlaufen werden.

Als Ergebnis würde ein solcher Generator Testfälle wie in Abb.2 liefern (darin sind jeweils erstmals vom Test überdeckte Knoten und Kanten fett markiert).

Diese vier funktionalen Testfälle sind in Entstehung und Ablauf komplett nachvollziehbar und erreichen eine definierte Testüberdeckung. Will man nun auch die spezifizierten Sicherheitsanforderungen im Test berücksichtigen, ist einer Erweiterung des ursprünglichen Modells nötig. Das kann im Ergebnis aussehen wie in Abb.3.

Abb.3: Erweitertes Modell zum Türsteuerungs-Beispiel. © <a href="index.php?id=2968#c19004" target="_self">[4]</a> — Abb.3: Erweitertes Modell zum Türsteuerungs-Beispiel. © [4]

Stößt man nun nach erfolgter Modell-Qualitätsprüfung erneut den Testfallgenerator an, stellt man fest, dass Testfall 1 und 2 aus dem ursprünglichen Modell unverändert Bestand haben. Testfall 3 und 4 sind aber nicht mehr im Modell enthalten; stattdessen entstehen neue Tests, sodass wir am Ende 10 Testfälle erhalten, die nun auch die Notentriegelung berücksichtigen. Details zu diesem Beispiel und den Testfällen sind zu finden in [4].

Man kann schon an diesem bewusst simplen Beispiel erkennen, dass ein alternatives manuelles Vorgehen möglicherweise rasch an Grenzen stößt und außerdem ungleich aufwändiger geraten könnte. Gerade in kombinatorischer "Fleißarbeit" steckt ja eine Stärke eines IT-gestützten Vorgehens.

Zur MBT-Historie

Modellbasiertes Testen nahm als Thema in Büchern und Publikationen in den 2000er Jahren Fahrt auf. Vorher fand man es z. B. in Robert Binders klassischem Testbuch [7], in dem explizit von "modeling for test design" die Rede ist und ein Abschnitt sogar den provokanten Titel "Why Testing Must Be Model-Based" trägt. Zwei Standards sollten in diesem Zusammenhang genannt werden: Das "UML Testing Profile" der OMG aus dem Jahr 2004 [8], das ein UML-Profil für die Modellierung von Tests bereitstellt, und die "Testing and Control Notation" TTCN-3, deren Spezifikation 2002 erschien [9]. Das Zusammenspiel der beiden wird anschaulich illustriert in [10].

Parallel dazu versuchten sich verschiedene Werkzeuglösungen am Markt zu etablieren, wobei die Schnittstelle zwischen Modellierung auf der einen Seite und Testmanagement bzw. Testdurchführung auf der anderen Seite auf unterschiedliche Arten realisiert wurde. Ein Überblick über die unterschiedlichen Ansätze und Werkzeugeigenschaften ist zu finden in [11].

Seit 2010 scheint eine gewisse Ernüchterung rund um MBT eingetreten zu sein, wobei man aber nicht so weit gehen sollte, Parallelen zum Schicksal der CASE-Werkzeuge aus den 90er Jahren zu ziehen. Woran es liegen könnte, dass sich Skepsis oder gar Ablehnung breitgemacht haben, wurde in [12] versucht zu ermitteln. So lehnen etwa agile Teams den Einsatz von Modellen häufig kategorisch als "überflüssige Dokumentation" ab und bezeichnen modellbasierte und generative Ansätze – sicher nicht ganz zu Unrecht – als "zu schwergewichtig". Handlungsfelder sind also offenbar die Modellierungswerkzeuge (Bedienbarkeit, Anpassbarkeit an den MBT-Prozess, Schnittstellen und Generatoren) sowie das Fehlen von Modellierungs-Skills bei vielen Testerinnen und Testern. Vor allem aber ist die zielgenaue Definition eines modellbasierten Testprozesses keine kleine Aufgabe und der initiale Aufwand wirkt häufig abschreckend.

Chancen und Risiken des MBT-Einsatzes

Die beiden wichtigsten Chancen, die modellbasiertes Testen bieten kann, heißen "Automatisierung" und "Komplexitätsbeherrschung". Automatisiert werden können mit MBT Schritte nicht in der Testdurchführung, sondern im Testdesign, d. h. dem Entwurf und der Spezifikation von Testfällen. Es steht außer Frage, dass dies eine kreative und deshalb meistens manuell durchgeführte Tätigkeit ist. Aber es besteht definitiv die Möglichkeit, diesen Teil des Testprozesses durch geeignete Werkzeuge zu unterstützen und die Entstehung von Testfällen mitsamt ihrem Tracing zu den zugehörigen Anforderungen zu (teil-)automatisieren. Einige Beispiele hierfür:

Aus Geschäftsprozessmodellen (man denke an BPMN-Modelle) lassen sich zu testende Szenarien systematisch und toolgestützt ableiten. Die sich daraus ergebenden End-To-End-Tests können je nach Spezifikation als Integrations-, System- oder Abnahmetests verwendet werden.
Aus Architekturdokumenten lassen sich Informationen für benötigte Testumgebungen extrahieren (Systeme, Komponenten, Schnittstellen).
Aus Datenbankmodellen und Schemata lassen sich relevante Informationen zur Generierung von Testdaten ableiten.
Und aus formal dokumentierten Requirements – etwa Use-Case-Szenarien, Entscheidungstabellen, Zustandsautomaten oder UI-Spezifikationen – können je nach Art der Spezifikation Testbedingungen, Testschritte oder ganze Testfälle abgeleitet werden.

Bei all dem gilt es den Nutzen im Vergleich zur manuellen Durchführung dieser Testaktivitäten zu untersuchen! Und es sollten damit keine überzogenen und unrealistischen Erwartungen geweckt werden. Fakt ist aber, dass die meisten Testartefakte nicht aus dem Nichts entstehen, sondern sich aus verschiedenen "work products" eines IT-Projekts ergeben. MBT stellt die Frage, ob es in einem Projekt solche Übergänge gibt, die es sich zu automatisieren lohnt. Und damit sollte der Ansatz auch für agile Teams nicht mehr unattraktiv erscheinen, denn es ist allgemein bekannt, dass agile Projekte in sinnvoller Automatisierung einen hohen Wert sehen.

Fakt ist außerdem, dass das größte Einsparpotenzial im Testprozess eben gerade in der Phase "Analyse und Design" liegt (über 50 Prozent des Testaufwands können dort angesiedelt sein [5]). Sich in diesem Bereich nach Automatisierungsansätzen umzusehen, macht also in jedem Fall Sinn.

MBT ist keine reine Werkzeugfrage, sondern eine Frage von Testzielen, Teststrategie und Testprozess.

Das andere Thema lautet "Komplexitätsbeherrschung" und besagt, dass in Anbetracht zunehmend komplexer und damit risikobehafteter Anforderungen und Lösungen auch im Test Hilfsmittel gesucht sind, die es Projektteams erlauben, der entstehenden Komplexität Herr zu werden. Gerade Tests, die sich durch eine große Zahl an Ablauf- und/oder Datenvarianten unterscheiden, können vom Modelleinsatz profitieren. Wie man im Beispiel der Türsteuerung schon erahnen konnte, lassen sich aus einem übersichtlichen Modell viele Tests sinnvoll und nachvollziehbar ableiten. Nicht nur, dass dies aus einer rein textuellen Spezifikation des Systems ungleich problematischer wäre: Gerade mit Blick auf den gesamten Produktlebenszyklus sollte darauf hingewiesen werden, dass MBT bei Wartung und Pflege von Testfallbeständen gute Dienste leisten kann. Wenn etwa Änderungen am Modell vorgenommen werden, ist in einem MBT-Prozess sofort klar, wie die "impact analysis" in Richtung Test aussieht: Welche Tests müssen geändert werden? Welche können entfallen? Welche fehlen noch? Das automatisierte Tracing unterstützt also sowohl bei der Pflege des Testfallbestands als auch bei der Abdeckungsmessung.

So attraktiv diese Chancen klingen mögen, ihnen stehen natürlich ernst zu nehmende Risiken gegenüber. Die wichtigsten lauten:

Fehlende oder unrealistische Zielsetzung des MBT-Einsatzes,
Unterschätzung des Einführungsaufwands (Definition und Implementierung von Schnittstellen, Generatoren, Traces etc.) und
Schwächen im Entwicklungs-, Modellierungs- oder Testvorgehen, die den Erfolg von MBT gefährden – etwa mangelhafte Qualität der verwendeten Modelle oder eine unangemessene (insbesondere nicht risikobasierte) Teststrategie.

Bei all dem muss außerdem berücksichtigt werden, dass – wie bei jedem "change" in Organisationen oder Prozessen – ein Misserfolg dazu führen kann, dass ein Thema auf Jahre hinaus als "verbrannt" gilt. Man fragt dann nicht mehr nach den Ursachen des Misserfolgs, sondern belässt es bei einem pauschalen "Haben wir probiert – geht nicht!". Darum sind gerade bei einem Thema wie MBT klare, nachweisbare und realistische Ziele unverzichtbar. MBT ist also beileibe keine reine Werkzeugfrage, sondern vor allem eine Frage von Testzielen, Teststrategie und Testprozess.

MBT: Was der Lehrplan bringt

Der MBT-Lehrplan besagt: "A person with the CTFL-MBT Certificate has extended the broad understanding (...) required for the MBT process, methodology and techniques" [13]. Um dies zu erreichen, behandelt er in der aktuellen Version folgende Themen:

Mögliche MBT-Ziele und "Stolpersteine"
MBT-Aktivitäten und -Artefakte im Testprozess
Integration von MBT in den Entwicklungsprozess
Erstellung von MBT-Modellen mit Blick auf definierte Testziele
Modellierungs-Richtlinien und Wiederverwendung vorhandener Modelle
Generierungs-Strategien für Testfälle und Testartefakte
Verzahnung von MBT und Testautomatisierung
Auswahl und Einführung von MBT und geeigneter Werkzeugunterstützung.

Damit werden die hier geschilderten MBT-Risiken ausdrücklich adressiert. Es entstehen derzeit Schulungsangebote zur Umsetzung des Lehrplans, die sich natürlich um konkrete MBT-Beispiele werden bemühen müssen. Auf diese Weise wird aus dem MBT-Versprechen ein handfestes "MBT erleben", anhand dessen man natürlich auch konkrete Fragen und Diskussionen rund um MBT führen kann.

Ausblick

Proprietät ist definitiv eine MBT-Herausforderung: Modelle (genauer: Inhalte, Granularität, Abstraktionslevel, Metamodell, Notation) unterscheiden sich von Projekt zu Projekt, und für Testspezifikationen und Testmanagement gilt das gleiche. In beiden Disziplinen gibt es allerdings Standards, auf denen man aufsetzen kann: Modellierungs-Startpunkte wie UML/U2TP oder BPMN erleichtern das "Andocken" und Customizing existierender Generatoren. Auf Testseite können bewährte Praktiken wie "keyword-driven testing" die Verbindung sowohl zu Modellen als auch zur Testautomatisierung schneller zum Erfolg führen. Der Standard 29119-5 [14] beschäftigt sich genau damit und es ist zu hoffen, dass die Werkzeughersteller sich in Zukunft ebenso daran orientieren werden, wie es etwa die Modellierungswerkzeuge mit der UML getan haben. Um den modellbasierten Übergang in den Test mit Standards zu unterstützen, gibt es sowohl fertiggestellte Resultate wie den ETSI-Standard [15] als auch laufende Bestrebungen, etwa eine ISO-Norm zum Thema zu entwickeln.

Es bleibt zu hoffen, dass das Vorliegen des Lehrplans auf das an sich schon spannende Thema MBT in nächster Zeit eine Schubwirkung wird ausüben können. Der Lehrplan lenkt die Aufmerksamkeit auf wichtige Fragestellungen und kann damit dazu beitragen, MBT-Experimente in IT-Projekten zum Erfolg zu führen.

Quellen

International Software Testing Qualifications Board (ISTQB)
Foundation Level-Testausbildung
Schieferdecker, I.: Modellbasiertes Testen, in: OBJEKTspektrum 03/2007?
Begleitbuch zum Lehrplan
Brandes, C.: Testkosten senken, Qualität steigern, in: it-management Juli/August 2015
Güldali, B. et al.: Starthilfe für modellbasiertes Testen: Entscheidungsunterstützung für Projekt- und Testmanager, in: OBJEKTspektrum 3/2010
Binder, R.: Testing Object-Oriented Systems, Addison Wesley 1999
UML Testing Profile der OMG
Testing and Control Notation (TTCN-3)
Baker, P. et al: Model-Driven Testing, Springer 2008
Götz, H. et al: iX-Studie Modellbasiertes Testen, Heise 2009
Brandes, C.: Warum hebt modellbasiertes Testen – noch – nicht ab?, in: OBJEKTspektrum 6/2014
MBT-Lehrplan
Standard 29119-5
ETSI-Standard