Modellbasiertes Testen

Transkript

1 Modellbasiertes Testen Ausarbeitung zum Proseminar Präsentation ausgewählter Problemstellungen der Informatik von Christiane Klapdohr betreut durch Prof. Dr. Gregor Engels und Dipl.-Inform. Baris Güldali SS 2005, Universität Paderborn

2 Inhaltsverzeichnis Abstract Einführung Vorgehensweise beim modellbasierten Testen Vor- und Nachteile des modellbasierten Testens Werkzeugunterstützung Fazit Literatur

3 Abstract Um eine gute Qualität entwickelter Software zu erreichen, ist sorgfältiges Testen erforderlich. Dies kann je nach Vorgehensweise sehr hohe Kosten verursachen. Modellbasiertes Testen ist ein Testverfahren, das ein systematisches und effektives Testen von Software bei relativ geringen Kosten ermöglicht. Dabei beruht das Verfahren darauf, dass ausgehend von Modellen der zu testenden Software bzw. des zu testenden Systems automatisch eine Testfallmenge generiert wird und mit Hilfe dieser Testfallmenge das System unter Test automatisch getestet und das Ergebnis des Tests analysiert werden kann. Durch diese Automatisierung ist das modellbasierte Testen besonders für Firmen bzw. Testabteilungen mit begrenzter Zeit und begrenztem Budget von Nutzen. 1 Einführung Jede Software muss vor ihrem endgültigen Einsatz überprüft werden, ob sie sich so verhält, wie sie soll. Dabei sollten zwei verschiedene Blickwinkel berücksichtigt werden, die Korrektheit in Bezug auf die Spezifikation einer Software und die Korrektheit in Bezug auf die Erfüllung der Anforderungen der Kunden an die Software. So ist es durchaus möglich, dass eine Software ihre Spezifikation erfüllt, nicht jedoch die Anforderungen des Kunden, wenn beim Übersetzen der informell formulierten Anforderungen in eine Spezifikation Fehler gemacht wurden. Die Überprüfung der Korrektheit im Sinne der Spezifikation kann mit Hilfe der Verifikation erreicht werden. Hierbei werden meistens mathematische Beweise geführt, die zeigen, dass das Programm sich im Sinne der Spezifikation verhält. Die Überprüfung, ob eine Software die Anforderungen des Kunden erfüllt, nennt man Validation. Eine Validation erfolgt in der Regel durch das Testen der Software. Dies erfordert im Gegensatz zur Verifikation eine reale Umgebung, also ein reales Programm, dass in einer konkreten Einsatzumgebung ausgeführt wird. Da dieses Programm nicht zwangsläufig die komplette Software sein soll, spricht man statt von einer zu testenden Software von einem System unter Test, das in Hinblick auf die Erfüllung der gegebenen Anforderungen getestet wird. Der Tester führt eine solche Überprüfung der Anforderungen mit Hilfe von Testfällen durch. Ein Testfall besteht dabei jeweils aus einer Eingabe und einem erwarteten Systemverhalten, das aus den Anforderungen hergeleitet wird. Hierbei ist die Wahl der Testeingaben aus der Menge der möglichen Eingaben von entscheidender Bedeutung. Die Schwierigkeit beim Testen besteht letztendlich darin, eine Testfallmenge zu erzeugen, die sowohl möglichst viele Fehler findet, indem sie bestenfalls jedes mögliche Verhalten des Systems unter Test mittels entsprechender Eingaben testet, als auch in sinnvollem zeitlichen Rahmen ausgeführt werden kann. Weiterhin sollte bei einer Veränderung des Systems unter Test eine neue bzw. entsprechend an die Veränderungen angepasste Testfallmenge leicht zu erzeugen sein. Nachdem die Testfallmenge erzeugt wurde, sollte das Testen des Systems unter Test in akzeptabler Zeit durchführbar sein. Das Verfahren des modellbasierten Testens bietet ein systematisches und automatisches Erzeugen einer Testfallmenge anhand eines Verhaltensmodells des Systems unter Test und eine Möglichkeit zur Automatisierung der Testdurchführung und Analyse der Testergebnisse. 2

4 Zum weiteren Verständnis der vorliegenden Ausarbeitung werden Grundkenntnisse über Verhaltensmodelle und über das Testen von Software vorausgesetzt. Da diese Ausarbeitung der Nachbereitung des Vortrags Modellbasiertes Testen im Rahmen des Proseminars Präsentation ausgewählter Problemstellungen der Informatik dient und alle Seminarteilnehmer das Grundstudium absolviert haben, sollten diese Kenntnisse vorausgesetzt werden können. Andernfalls können die Grundlagen über Verhaltensmodelle in den entsprechenden Unterlagen der Vorlesungen Modellierung und Softwareentwurf nachgelesen werden. Weiterhin sind zum Verständnis dieser Ausarbeitung grundlegende Kenntnisse über das Testen von Software wünschenswert, welche sich die Seminarteilnehmer im Rahmen des Softwaretechnikpraktikums erworben haben sollten. Im folgenden Kapitel werden diese Grundkenntnisse verknüpft und ich werde darstellen, wie Modelle für das Testen genutzt werden können und mit Hilfe der Modelle das Testen von Software automatisiert werden kann. Dabei werde ich über meinen Vortrag hinausgehend auf die Problematik der automatischen Ergebnisvorhersage eingehen und kurz die Schnittstelle zwischen der Testfallmenge und der Durchführung des Systems unter Test anhand der Testfälle erläutern. Anschließend möchte ich in Kapitel 3 die Vor- und Nachteile bzw. die Grenzen des modellbasierten Testens erläutern, bevor ich kurz in Kapitel 4 auf Möglichkeiten der Werkzeugunterstützung des modellbasierten Testens eingehe. Abschließen werde ich in Kapitel 5 mit einem kurzen Fazit. 2 Vorgehensweise beim modellbasierten Testen 2.1 Abgrenzungen zu anderen Vorgehensweisen Es gibt viele verschiedene Vorgehensweisen um ein System zu testen. Eine Möglichkeit besteht darin, dass ein Tester ohne eine systematische Vorgehensweise das System testet und dadurch nach Fehlern sucht. Abb.1 unsystematisches Testen (Bild nach [ROB]) 3

5 Dies ist eine sehr zeitintensive Methode, bei welcher der Tester mit großer Wahrscheinlichkeit viele Fehler nicht findet. Weiterhin muss damit gerechnet werden, dass auch der Tester selber Fehler macht. Da der Vorgehensweise keine Systematik zugrunde liegt, kann der Tester auch nicht abschätzen, wann er die Testphase beenden kann. Eine andere Vorgehensweise zum Testen ist das Testen mit Hilfe spezieller Skripte. Hierbei entwickelt der Tester für jede Anforderung ein speziell auf das System zugeschnittenes Skript, dass diese Anforderung testet. Das Problem ist, dass die Erzeugung dieser Skripte sehr aufwändig sein kann. Abb.2 Testen mit speziell angepassten Skripten (Bild nach [ROB]) Ebenso problematisch ist die Anpassung an Veränderungen des Systems. Jede Veränderung kann für den Tester ein sehr aufwändiges Anpassen der Skripte bedeuten. Als eine dritte mögliche Vorgehensweise möchte ich noch den so genannten Monkey-Test erwähnen, bei dem der Tester mit zufallsbasierten Eingaben arbeitet. Abb.3 zufallsgesteuertes Testen (Bild nach [ROB]) Da der Tester bei diesem Verfahren keine Erwartungen bezüglich des Systemverhaltens hat, kann er nur Fehler finden, bei denen das System abstürzt. Somit sind weitere Tests nötig, um auch andere Fehler zu finden. 4

6 Die Vorgehensweise des modellbasierten Testens verhindert die Entstehung der aus den anderen Vorgehensweisen bekannten Probleme. Sie bietet ein systematisches Vorgehen, durch das abgeschätzt werden kann, welche Anforderungen bereits getestet wurden und welche noch zu testen sind. Die Testfälle können automatisch aus einem Verhaltensmodell des Systems unter Test erzeugt werden, es ist somit kein aufwändiges Erstellen von Skripten per Hand notwendig. Abb.4 modellbasiertes Testen (Bild abgewandelt von [ROB]) Außerdem braucht der Tester bei einer Veränderung des Systems nur das Modell anzupassen und nicht ein oder mehrere Skripte. Schließlich kann das Verhaltensmodell helfen eine automatische Aussage über das zu erwartende Systemverhaltens zu erzeugen. Dies werde ich in Kapitel 2.4 näher erläutern. Modellbasiertes Testen läuft in folgenden Schritten ab (vgl. Abb. 5), die ich in den folgenden Unterkapiteln näher erläutern möchte: 1. Verstehe das System unter Test. 2. Entwicklung / Anpassung des Verhaltensmodells 3. Generierung der Testfallmenge 4. Testdurchführung 5. Analyse der Testergebnisse 5

7 1. verstehe SUT 2. entwickle passe an Verhaltensmodell 3. generiere Testfallmenge STOP ggf. ändere 4. führe Tests durch entscheide anhand der Testziele System unter Test 5. analysiere Testergebnis erhalte Test Abb.5 Vorgehensweise des modellbasierten Testens (Bild abgewandelt von [EL-F]) 2.2 Verstehe das System unter Test Um ein System zu testen, muss der Tester wissen, wie das System sich den Anforderungen nach verhalten sollte. Dabei sollte der Tester sich darüber im Klaren sein, dass es vielfach besser ist auch einzelne Komponenten eines Systems nicht separat, sondern im Zusammenspiel mit anderen Komponenten des Systems zu testen, da gerade bei der Zusammenarbeit verschiedener Komponenten viele Fehler möglich sind. Andererseits sind viele Systeme einfach zu groß, um ein Zusammenspiel aller Komponenten in überschaubarer Zeit testen zu können. In diesem Fall kann sich der Tester viel Arbeit ersparen, wenn er zu Beginn seiner Analyse des Systemverhaltens die für seinen Test wichtigen Komponenten identifiziert und nur das Verhalten dieser Komponenten betrachtet. Um das Verhalten des Systems zu verstehen, sollte der Tester auf alle verfügbaren Hilfsmittel zurückgreifen. Dazu zählen Dokumente, wie die Anforderungsbeschreibung, UseCases, die Spezifikation der Software, Entwurfsdokumente oder das Benutzerhandbuch. Da sich der Tester in derartige Dokumente aber auch erst einarbeiten muss, ist ein weiteres effektives Hilfsmittel die Kommunikation mit Teams, die an der bisherigen Entwicklung des Systems unter Test beteiligt waren, wie z.b. das Team, welches die Anforderungen dokumentiert hat und das Entwicklungsteam. Durch die Kommunikation mit diesen Teams kann der Tester recht unkompliziert ein Grundverständnis von dem zu testenden System aufbauen. Anschließend kann er die dazugehörigen Dokumente leichter lesen und für ein genaueres Verständnis nutzen. Letztendlich sollte der Tester das Verhalten des Systems soweit verstanden haben, dass er weiß, welche Eingaben unter welchen Bedingungen möglich sind und wie die entsprechende 6

8 Ausgabe bzw. Reaktion des Systems aussehen sollte. Das heißt der Tester sollte wissen, ob eine Eingabe nur unter bestimmten Voraussetzungen möglich ist, wie z.b. dass das System für diese Eingabe in einem bestimmten Modus sein muss, z.b. wenn es um Testen von Benutzungsschnittstellen geht, dass ein bestimmter Eingabedialog geöffnet sein muss. Außerdem sollte der Tester das gewünschte Verhalten in Abhängigkeit von diesen Bedingungen vorhersagen können. Dies ist z.b. relevant, wenn ein und dieselbe Eingabe in verschiedenen Modi des Systems verschiedene Verhaltensweisen erzeugt. Wenn der Tester das System unter Test soweit verstanden hat, kann er ein entsprechendes Verhaltensmodell erzeugen. 2.3 Entwicklung / Anpassung des Verhaltensmodells Mögliche Modelle Um das Verhalten des Systems unter Test zu modellieren eignen sich zahlreiche Arten von Verhaltensmodellen. El Far und Robinson erläutern modellbasiertes Testen anhand eines endlichen Zustandsautomaten (vgl. [EL-F], [ROB]). Dieser eignet sich für ein System mit endlich vielen Zuständen. In den folgenden Kapiteln werde ich zur Veranschaulichung meiner Erläuterungen einen Zustandsautomaten wie in Abb. 6 benutzen. Abb.6 Beispiel- Zustandsautomat (nach [EL-F]) Ein Zustandsautomat zu einem System besteht aus einer endlichen Menge von Zuständen, die das System annehmen kann. Diese sind in Abbildung 6 als Rechtecke dargestellt. Um die Zustände voneinander unterscheiden zu können, sind diese mit start/final, sowie den Ziffern 1 bis 9 bezeichnet. Ein System kann bei einem entsprechenden Ereignis von einem Zustand in Pfeilrichtung in einen anderen Zustand wechseln. Der Buchstabe an einer Kante stellt dabei das Ereignis dar. In folgendem Beispiel (Abb.6) wechselt ein System, das sich in dem Zustand 1 befindet, durch das Ereignis b in den Zustand 2. Ereignisse müssen jedoch keinen Zustandswechsel auslösen. So bleibt das System, wenn es sich in Zustand 5 befindet beim Ereignis h in Zustand 5. Ereignisse sind in der Regel interne Methodenaufrufe des Systems sein. Diese Methodenaufrufe können jedoch durch externe Eingaben ausgelöst werden. 7

9 Jeder Automat muss einen Startzustand haben, also einen Zustand, in dem sich das System zu Beginn befindet. Dies ist in Abbildung 6 der Zustand start/final. Weiterhin besitzt jeder Automat eine endliche Menge von Endzuständen, dies ist in diesem Fall ebenfalls der Zustand start/final. Eine spezielle Form des endlichen Zustandsautomaten ist das UML Zustandsdiagramm. Zustandsdiagramme eignen sich besonders für die Modellierung von parallelem Verhalten. Die Modellierung des Verhaltens kann neben der Modellierung mit endlichen Zustandsautomaten bzw. Zustandsdiagrammen durch weitere UML- Diagramme, wie zum Beispiel Sequenzdiagramme unterstützt werden. Der Vorteil liegt darin, dass aus einem Sequenzdiagramm leicht ein Testfall generiert werden kann. So würde bei einer Vielzahl von Sequenzdiagrammen jeder Testfall einem Sequenzdiagramm entsprechen. Der Nachteil dabei ist, dass mit Hilfe von Sequenzdiagrammen ein komplexes Systemverhalten nur ausschnittsweise dargestellt werden kann. Eine weitere Möglichkeit Verhalten darzustellen bieten formale Grammatiken. Diese eignen sich besonders gut, um Eingaben durch festgelegte Sprachen darzustellen, aber auch für die Beschreibung von zielgerichteten Handlungsabläufen in einer GUI, da durch das System der Ableitungen in einer Grammatik gut eine dynamische Anzahl von Möglichkeiten ein und dasselbe Ziel zu erreichen modelliert werden kann. Dies sind nur einige der möglichen Modelle, um das Verhalten von Software zu beschreiben. Ausahl des Modells Die Aufgabe des Testers besteht nun darin, sich zu entschieden, welches Modell er für seine Testzwecke benutzen möchte. Dabei sollte er folgende Punkte berücksichtigen: In erster Linie muss er evtl. vorhandene Regelungen seiner Firma oder Abteilung beachten. Ist z.b. innerhalb der Testabteilung aus strategischen Gründen ein zu benutzendes Modell festgelegt, sollte er dieses benutzen. Weiterhin kann es sein, dass im weiteren Testverlauf Werkzeuge zur Testautomatisierung benutzt werden, welche bestimmte Modelle fordern. Auch hier bleibt dem Tester dadurch keine oder je nach Testwerkzeug nur eine eingeschränkte Auswahlmöglichkeit. Müssen die beiden vorher genannten Punkte nicht berücksichtigt werden, sollte die erste Frage des Testers sein, ob er bereits vorhandene Verhaltensmodelle für seine Testzwecke nutzen kann. Gibt es bereits solche Modelle, muss er diese eventuell noch anpassen. Wichtig ist, dass mit Hilfe des Modells alle für die Testgenerierung relevanten Aspekte gut darstellbar sind. Ein weiterer Aspekt bei der Wahl des Modells ist die Vertrautheit mit der Theorie des Modells und die Unterstützung durch ein vorhandenes Werkzeug zur Modellierung. Beides hilft dem Tester ein Modell zügig zu entwerfen. Letztendlich sollte der Tester auch den Faktor Zielgruppe berücksichtigen. Ein Modell, das nur von Technikern gelesen und benutzt wird, kann technischer sein, als ein Modell, das auch vom Marketing oder Management gelesen und verstanden werden soll. Nachdem der Tester sich für eine Modellart entschieden hat, entwirft er aufgrund seiner Kenntnisse das Verhaltensmodell des Systems unter Test, bzw. passt ein vorhandenes Modell entsprechend seinen Zielen an. Anschließend kann die Testfallmenge erzeugt werden. 8

10 2.4 Generierung der Testfallmenge Kriterien zur Generierung Ein Testfall ist, wie bereits erwähnt, ein Tupel bestehend aus der Eingabe und dem erwarteten Systemverhalten, das durch die Eingabe hervorgerufen werden soll. Eine Testfallmenge ist eine endliche Menge solcher Testfälle. Die Testfallmenge sollte anhand festgelegter Kriterien generiert werden, um sowohl anhand einer nachvollziehbaren Systematik zu testen, als auch eine Abschätzung machen zu können, was getestet wurde und wo noch Fehlerpotential liegt. Folgende Kriterien beziehen sich die auf zustandsbasierte Verhaltensmodellierung. Für andere Verhaltensmodelle können jedoch ähnliche Kriterien hergeleitet werden. Zur Veranschaulichung der Kriterien dient der Zustandsautomat aus Kapitel 2.3. Zur besseren Lesbarkeit habe ich den Automaten noch einmal in Abb. 7 dargestellt. Abb.7 Beispiel- Zustandsautomat (nach [EL-F]) Ein sehr schlichtes Kriterium ist die Zustandsüberdeckung. Dabei erfolgt die Überdeckung mittels Eingaben. Eine Eingabe ist eine Sequenz von Ereignissen, welche Zustandswechsel hervorrufen. Die Eingaben einer Testfallmenge, die dieses Kriterium erfüllen soll, müssen so gewählt sein, dass jeder Zustand, in dem sich das System unter Test befinden kann, mindestens einmal besucht wird. Für den obigen Automaten könnte eine Testfallmenge, die dieses Kriterium erfüllt, aus folgenden Ereignissen bestehen: a,b,d,e,f,i,j,m,p Der erwartete Systemzustand, in dem sich das System nach diesen Eingaben befinden sollte, wäre dann entsprechend Zustand 7. Ein etwas umfangreicheres Kriterium ist die Ereignisüberdeckung. Hierbei sollte für jeden Zustand, in dem sich das System befindet, jedes in diesem Zustand ausführbare Ereignis mindestens einmal durchgeführt werden. Für einen endlichen Zustandsautomaten entspricht dies einer Kantenüberdeckung, d.h. da jede Kante des Automaten einem Ereignis entspricht, sollte jedes Ereignis mindestens einmal eintreten. Für den gegebenen Beispielautomaten (siehe Abb.7) könnte eine Testfallmenge aus den Eingabesequenzen <a,b,c,d,e,f,g,h,i,j,m,l,j,k> <a,b,d,e,f,i,j,m,p,q,n> und <a,b,d,e,f,i,j,m,p,o> bestehen. Die Eingabesequenzen könnten dabei auch zu einer kombiniert werden. Ebenso sind andere Reihenfolgen innerhalb der Eingabefolgen möglich, wichtig ist dass letztendlich eine Kantenüberdeckung erreicht wird. Eine solche Kantenüberdeckung kann mit Hilfe des Chinese Postman Walk - Algorithmus gewährleistet und optimiert werden. Dieser Algorithmus erzeugt einen kürzesten Pfad in einem Graphen, bei dem jede Kante mindestens einmal durchlaufen wird. 9

11 Das Kriterium der Ereignisüberdeckung gibt es auch in einer abgeschwächten Variante. Dabei wird argumentiert, dass der Tester nur Ereignisse betrachten möchte, durch die ein Zustandswechsel hervorgerufen wird, da dieses meist die Transitionen sind, in denen Fehler auftreten. Somit fordert das Kriterium der zustandswechselnden Ereignisüberdeckung, dass jedes Ereignis, das einen Zustandswechsel verursacht, mindestens einmal ausgelöst wird. Um dieses Kriterium anhand eines Zustandsautomaten ebenfalls effizient erfüllen zu können, sollten alle Transitionen, die nicht einen Zustandswechsel hervorrufen entfernt werden, bevor auf dem so reduzierten Graphen der Chinese Postman Walk - Algorithmus durchgeführt wird. Im Beispielautomaten (Abb.7) würde in diesem Fall lediglich die Kante h entfernt und somit nicht durchlaufen werden. Ein noch mächtigeres Kriterium als die Ereignisüberdeckung ist die Überdeckung der Kombinationen von Ereignissen. Dieses Kriterium ist erfüllt, wenn jede eingehende Kante eines Zustands in Kombination mit jeder ausgehenden Kante ausgeführt wird. Dies bedeutet für einen Zustand z mit x eingehenden Kanten und y ausgehenden Kanten, dass jede mögliche Sequenz (eingehende Kante, ausgehende Kante) mindestens einmal ausgeführt wird, also der Zustand z genau x*y oft innerhalb eines Tests entsprechend einer solchen Testfallmenge durchlaufen wird. Betrachten wir nur Zustand 8 in unserem Beispielautomaten (siehe Abb.8). Dieser hat zwei eingehende Kanten m und q, sowie die drei ausgehenden Kanten l, n und p. Eine Testfallmenge, die das Kriterium erfüllt müsste somit die Eingabefolgen <m,l>, <m,n>, <m,q>, <p,l>, <p,n> und <p,q> enthalten, der Zustand 8 somit sechs mal besucht werden. Abb.8 Ausschnitt aus dem Beispiel-Zustandsautomaten (nach [EL-F]) Das stärkste Überdeckungskriterium ist die Pfadüberdeckung, bei der jede mögliche Abfolge von Ereignissen mindestens einmal durchgeführt wird. Eine derartige Überprüfung ist in der Regel bei etwas komplexeren Systemen nicht mehr durchführbar. Ein System ist für das Kriterium der Pfadüberdeckung schon dann zu komplex, wenn es dynamische Schleifen enthält. Dies ist z.b. auch bei den Kanten b und c in unserem Beispielautomaten (siehe Abb.7) der Fall. Hier müsste bei einer Pfadüberdeckung die Folge <b,c> einmal, zweimal, dreimal schlimmstenfalls undendlich-mal durchlaufen werden. Endlose Schleifen könnte es z.b. bei Systemen geben, die durchgehend laufen. Weitere zu komplexe Systeme sind nebenläufige und nicht-deterministische Systeme. Auch zu viele Zustände und Kanten können eine zu große Testfallmenge erzeugen und so den zeitlichen Rahmen, in dem die Tests durchgeführt werden sollen, sprengen. Deshalb ist das Kriterium der Überdeckung der Ereigniskombinationen das mächtigste realistisch benutzbare Kriterium für den Test eines Systems. 10

12 Orakel- Problematik Die genannten Kriterien sind mögliche systematische Vorgehensweisen, um die Eingaben für eine Testfallmenge zu entwickeln. Zu einer Testfallmenge gehören aber auch die erwarteten Ausgaben bzw. das erwartete Systemverhalten des Systems. In der Literatur wird dabei häufig von einem so genannten Orakel gesprochen, welches eine Aussage über das erwartete Systemverhalten macht. Ein solches Orakel zu erzeugen ist jedoch nicht ganz unproblematisch. Wenn das Orakel ein Programm sein soll, was die zu erwartende Ausgabe des Systems unter Test entsprechend der Eingabe erzeugen soll, stellt sich die Frage, wofür es noch das System gibt, wenn das Orakel-Programm ebenfalls die gewünschte Ausgabe liefern kann. Dieses Problem ist bis jetzt noch nicht zufrieden stellend gelöst worden, deshalb sind die Aussagen über das erwartete Systemverhalten häufig sehr viel vager. So könnte es bereits ein ähnliches Produkt B oder eine Vorgängerversion V des zu testenden Systems geben und eine Orakel- Aussage wäre dann Das System unter Test soll die gleichen Ausgaben / das gleiche Verhalten haben, wie das Produkt B bzw. die Version V (vgl. [SOF]). Falls nicht auf derartige Produkte zurückgegriffen werden kann, müssen andere Orakel- Aussagen gebildet werden. Mit Hilfe des Verhaltensmodells kann die Erzeugung einer Orakel-Aussage beim modellbasierten Testen unterstützt und automatisiert werden. Denn wenn das Verhaltensmodell des Systems unter Test in einer maschinenlesbaren Form gebildet wird, kann mit Hilfe eines entsprechenden Werkzeugs bei der Generierung der Eingaben einer Testfallmenge anhand des Modells gleichzeitig das erwartete Systemverhalten aus dem Modell ausgelesen und in der Testfallmenge gespeichert werden. Wichtig ist, dass in dieser Orakel- Aussage Ausgaben des Systems nur dann enthalten sein können, wenn diese aus dem Modell ausgelesen werden können. Dies könnte bei einer Modellierung mit Mealy- oder Moore- Automaten der Fall sein, da bei diesen Automaten ein erwartetes Ausgabeverhalten in den Zuständen bzw. Zustandsübergängen notiert wird. Ansonsten beinhaltet die automatisch aus dem Modell gewonnene Orakel- Aussage allgemeinere Informationen, z.b. bei einer zustandsbasierten Modellierung in welchem Zustand sich das System nach der Ausführung eines Testfalls befinden soll. Dadurch können jedoch einige Fehler nicht gefunden werden, jene nämlich, bei denen sich das System zwar im erwarteten Zustand befindet, aber trotzdem einen Fehler macht. 2.5 Testdurchführung Um die Eingaben einer Testfallmenge auf einem System unter Test durchführen zu können, muss eine Schnittstelle geschaffen werden, welche die Eingaben der Testfälle mit konkreten Methoden des Systems unter Test verknüpft. Diese Schnittstelle wird in der Regel mit Hilfe von Skripten geschaffen, die für jede Ereignis eine Methode im System unter Test aufrufen oder eine entsprechende Methode implementieren, welche z.b. ein von außen getriggertes Ereignis simuliert. Zur Verdeutlichung wie ein solches Testskript aussehen könnte, möchte ich wieder den Beispielautomaten aus den vorangegangenen Kapiteln benutzen. Bei folgendem Beispiel soll im Test der grüne Pfad durchlaufen werden: 11

13 Abb.9 Beispiel- Zustandsautomat (nach [EL-F]) Ein Test-Skript ruft nacheinander die entsprechenden Prozeduren auf (vgl. [EL-F]): Prozedur Test_Skript() { } //Code um das System in den Startzustand zu bringen a(); b(); d(); e(); f(); i(); j();k(); Dabei sind die Methoden a(), b() etc entweder Methodenaufrufe im System unter Test oder Zwischenmethoden, welche einen Methodenaufruf im System unter Test ermöglichen. Dies kann z.b. dann nötig sein, wenn ein externes Verhalten simuliert wird, durch welches z.b. bestimmte Parameter oder Flags gesetzt werden, die für den Methodenaufruf im System unter Test notwendig sind. Nachdem ein derartiges Test-Skript erstellt wurde, können Test-Skript und System unter Test kompiliert und in der realen Umgebung ausgeführt werden. Dabei wird ein Testergebnis protokolliert. Das Testergebnis sollte die Testfallmenge enthalten, also die Eingabe und das erwartete Systemverhalten, sowie das entsprechende Systemverhalten im Test. Diese drei Aussagen werden zur Analyse benutzt. 2.6 Analyse der Testergebnisse Bei der Analyse der Testergebnisse wird das tatsächliche mit dem erwarteten Systemverhalten verglichen. Weicht das tatsächliche Systemverhalten vom erwarteten ab, muss überprüft werden, ob das Testmodell korrekt ist. Gegebenenfalls muss dies verändert werden. Andernfalls ist das abweichende tatsächliche Verhalten als Fehler des Systems unter Test zu werten. Der Tester entscheidet nun anhand von so genannten Testzielen, ob die Testfallmenge um weitere Testfälle erweitert werden muss oder ob die Testreihe beendet werden kann. Testziele können z.b. die in Kapitel 2.4 erläuterten Überdeckungskriterien sein, demnach ist das Testziel erreicht, wenn ein festgesetztes Überdeckungskriterium erfüllt wurde. Eine andere Möglichkeit wären statistische Kriterien, wie z.b. ein Fehler- pro- festgelegter Zeit- Kriterium, das bei größeren Systemen eingesetzt werden kann. Hierbei ist das Testziel erreicht, wenn z.b. nur noch eine festgelegte Anzahl von Fehlern pro Stunde gefunden wird. 12

14 3 Vor- und Nachteile des modellbasierten Testens 3.1 Vorteile des modellbasierten Testens Die größten Vorteile des modellbasierten Testens entstehen eindeutig durch die Verwendung eines Verhaltensmodells. Durch das Modell können Entwicklung und Test eines Systems miteinander verknüpft werden. Dies heißt nicht nur, dass ein Modell, das in der Entwicklungsphase entstanden ist, in der Testphase wieder verwendet werden kann, wodurch Ressourcen gespart werden können, sondern auch, dass Tester und Entwickler mit Hilfe des Modells miteinander über das System kommunizieren können. So kann einerseits der Tester anhand eines bestehenden Modells das Verhalten des Systems unter Test besser verstehen, andererseits der Entwickler anhand des Modells aufgezeigt bekommen, an welcher Stelle das Verhalten des Systems von dem erwarteten Verhalten abweicht. Durch das Modell kann das Verhalten eines Systems formalisiert werden und somit gewährleistet werden, dass Entwickler und Tester das Gleiche meinen, wenn sie von einem bestimmten Verhalten sprechen. Ein besonderer Vorteil des Modells ist auch, dass anhand des Modells eine Testfallmenge systematisch generiert werden kann, denn nur durch ein systematisches Vorgehen können Fehler effizient gesucht werden. Weiterhin bietet das systematische Vorgehen auch gleichzeitig ein Kriterium, mit dessen Hilfe man das Ende einer Testphase definieren kann. So kann beispielsweise eine Testphase beendet werden, wenn ein festgelegtes Überdeckungskriterium erfüllt wurde. Formale Modelle können Automatisierung unterstützen, in diesem Fall kann anhand des Modells sowohl die Testfallmengengenerierung inklusive einer ungefähren Ergebnisvorhersage als auch die Testdurchführung sowie die Analyse der Testergebnisse automatisiert werden. Falls das System unter Test sich ändert, kann das Modell angepasst und neue Testfälle schnell erzeugt werden. Fallstudien belegen diese Vorteile (vgl. z.b. [AGE]). 3.2 Nachteile und Grenzen des modellbasierten Testens Das größte Problem des modellbasierten Testens ist die Explosion des Umfangs des Modells bei komplexen Systemen, z.b. die Explosion des Zustandsraums bei einer zustandsbasierten Modellierung. Dies heißt, dass bei einem komplexen System unter Test das entsprechende Verhaltensmodell zu groß ist, so dass es nicht mehr handhabbar ist und auch eine Anwendung der Überdeckungskriterien den Testrahmen sprengen. Für dieses Problem gibt es zwei Lösungsansätze, die Abstraktion und den Ausschluss. Bei der Abstraktion werden Teile des Verhaltensmodells zusammengefasst und so die Komplexität des Modells reduziert. Bei einem Zustandsautomaten kann der Tester z.b. mehrere Zustände zu einem Zustand zusammenfassen. Ausschluss meint, dass das Softwareverhalten auf mehrere Modelle aufgeteilt wird. 13

15 Ein weiteres Problem ist das Orakel- Problem, also die automatische Vorhersage über das Systemverhalten. Wenn das Systemverhalten nicht gerade mit Mealy-/Mooreautomaten modelliert wurde, ist es bislang nicht möglich exakte Aussagen über die zu erwartenden Ausgaben des Systems unter Test automatisiert zu treffen (vgl. Kapitel 2.4). Dieses Problem stellt sich jedoch auch bei anderen Testverfahren und stellt somit allgemein eine Grenze der Möglichkeiten beim Testen dar. Das Verfahren des modellbasierten Testens schwächt die Problematik immerhin ab, indem es die Möglichkeit einer allgemeineren aber automatisch erzeugten Aussage über das Verhalten bietet, wie z.b. den erwarteten Zustand in dem sich das System am Ende befinden soll. In der Literatur, die dieser Ausarbeitung zugrunde liegt, wird auch als Nachteil erwähnt, dass für das modellbasierte Testen Ressourcen, wie Fähigkeiten der Tester, Zeit und Geld investiert werden müssen. Dies ist meiner Ansicht jedoch kein Nachteil sondern lediglich eine anfängliche Investition, die sich langfristig gesehen rentiert, da aufgrund dieser Investition modellbasiert getestet werden kann und somit durch das systematische und automatische Testen mit verhältnismäßig wenig Aufwand eine gute Softwarequalität erreicht werden kann. Fallstudien über das modellbasierte Testen bestätigen dies. Fallstudien zeigen aber auch die Grenzen des modellbasierten Testens auf (vgl. [AGE]). So lassen sich mit den herkömmlichen Modelllierungsmethoden kaum Multithreaded-Prozesse sowie zeitliche Abhängigkeiten modellieren. Weiterhin bestätigen die Fallstudien, dass trotz entsprechender Lösungsansätze die Zustandsraumexplosion eines der Hauptprobleme und somit auch Grenze des Verfahrens darstellt. 4 Werkzeugunterstützung Ein besonderer Vorteil des modellbasierten Testens ist die Automatisierbarkeit vieler Phasen des Verfahrens. Hierfür ist eine Unterstützung durch geeignete Werkzeuge notwendig. Es wurden bereits viele geeignete Werkzeuge entwickelt. In diesem Kapitel möchte ich, exemplarisch für die Möglichkeit der Werkzeugunterstützung, das AGEDIS- Projekt erwähnen. Im Rahmen dieses Projektes sind für jede Phase des modellbasierten Testens Werkzeuge entwickelt bzw. vorhandene Werkzeuge angepasst und integriert worden. Ein besonderer Vorteil dieses Projektes ist, dass die Werkzeuge in einem gesamten Tool integriert und aufeinander abgestimmt sind, so dass mit ihrer Hilfe der gesamte Ablauf des modellbasierten Testens automatisiert werden kann. AGEDIS ist ein abgeschlossenes EU Forschungsprojekt, das über drei Jahre lief und von sieben Partnern aus Industrie und akademischen Körperschaften durchgeführt wurde (vgl. [AGE]). Die Ziele des Projektes bestanden darin, für jede Phase des modellbasierten Testens ein Werkzeug zu entwickeln und durch die Zusammenarbeit dieser Werkzeuge eine Testautomatisierung zu erreichen. Durch die Testautomatisierung sollten die Kosten für eine gute Softwarequalität verringert werden. Ferner sollte das bestehende Wissen über Möglichkeiten des Testens von Software weiter entwickelt werden. Die genaue Vorgehensweise des modellbasierten Testens mit AGEDIS wird in der Ausarbeitung Werkzeuge des AGEDIS-Projektes von Dirk Meister beschrieben. 14

16 5 Fazit Es gibt verschiedene Test-Verfahren um ein System unter Test in Hinblick auf seine Anforderungen zu überprüfen. Diese können jedoch sehr aufwändig oder auch fehleranfällig sein, so dass der Tester im Verhältnis zu der Zeit, die er für den Test investiert, wenig Fehler findet. Bei einem Testverfahren wie z.b. dem Testen mit per Hand entwickelten speziellen Skripten hat der Tester weiterhin das Problem, dass diese bei Veränderungen des Systems unter Test aufwändig zu warten sind. Modellbasiertes Testen ist dagegen ein effizientes Verfahren, da das Testen eines Systems dadurch systematisiert, automatisiert und gut wartbar wird. Es beruht darauf, dass der Tester, nachdem er das zu testende System verstanden hat, ein Verhaltensmodell des Systems für seine Testzwecke anpasst, bzw. entwirft. Anhand dieses Verhaltensmodells kann er dann automatisiert nach festzulegenden Generierungskriterien Testfälle erzeugen. Anschließend verknüpft er die Testeingaben über Testskripte mit dem System unter Test und führt diese dann aus. Das resultierende Testergebnis wird analysiert und eine Entscheidung über das weitere Vorgehen gefällt, in der Regel entweder eine Veränderung des Modells, weitere Tests durch Entwicklung einer weiteren Testfallmenge oder die Beendigung der Testphase. Dabei kann der Prozess des modellbasierten Testens durch entsprechende Werkzeuge wie z.b. AGEDIS unterstützt bzw. automatisiert werden. Das größtes Problem, dass sich beim modellbasierten Testen stellt, ist die Explosion des Zustandsraums bei komplexen Systemen unter Test. Dieses Problem kann jedoch mit Hilfe von Abstraktion und Ausschluss gemindert werden. 6 Literatur [AGE] A. Hartmann, AGEDIS. Final Project Report, Feb. 2004, Online resource ( [EL-F] I. K. El-Far and J. A. Whittaker, Model-Based Software Testing. Encyclopedia of Software Engineering (edited by J. J. Marciniak). Wiley, 2001 [ROB] H. Robinson, "Intelligent test automation", Software Testing & Quality Engineering (STQE), Sept./Oct. 2000, pp [SOF] SOFTWARE ACQUISITION GOLD PRACTICE: MODEL-BASED TESTING, The Data and Analysis center for Software (DACS), Online resource ( 15