Home

Dokument_45.

1. Abbildung B 7 Auswahl TestContext 187 B Werkzeug UnITeD 5 Model s U2TP E TestContext A Tue Oct 04 10 38 58 CEST 2011 3 B P Testsuites Ex Data Generation Age we Elite History Current Population do Hm X E Comment TestSuites TestCases Ci Packagelmport 10 Legend Elite Hi s ee e egend Elite History Testsuite TestCor a Packagelmpo ann nr Range from oldest to latest Elite Testsuite E System 4 Errors in c DS TestSystem E auxiliaryResource DA sProfileApplication D TestContext SUT Behavior of SUT UserControl Coverage criterion Reached coverage 0 0 er D TestSteps 0 5 EAL bi bz 63 ba s der dr 08 E a p Properties W Reached finalization 0 0 bide Legend averne ness Number of Testcase 0 Population Distribution Creation Date 2011 10 04 10 38 58 Zur 24 ProfileApplications DA ProfileApplication ProfileApplication 55 ProfileApplication H m H Generation Progress 5 Abbildung B 8 Anzeige Testfallgenerierungsfortschritt ere eege Ie File Optimization TestScripts Mutation Options Window Help KAA Mod
2. Abbildung B 13 Mutationsanalyse 190 Index Abl sung Abnahmetest Adaptive Maintenance Aktivit tsdiagramm All c uses All c uses some p uses 37 All defs All DU Paths All p uses 36 All p uses some c uses All uses anpassende Wartung Anweisungsiiberdeckung anwendungsgetriebene Integration Arithmetischen Operator ndern 136 Atomare Entit ten aufgerufene Komponente aufgerufene Transition Aufruf Aufruf ndern 136 Aufruf Hinzuf gen 136 Aufruf L schen 136 Aufruf Operatoren 136 aufrufende Komponente aufrufende Transition Bearbeitete Variable ndern 136 Bedingungs berdeckungstests Benutzbarkeitstest Best Fitness Big Bang Integration Black Box Test Boolesche Operatoren ndern Bottom Up Integration Boundary Interior Pfadtest C use 35 Capture Replay Classifier Competent Programmer Hypothesis 123 Constraint Corrective Maintenance Coupling Based Criteria 55 Coupling Effect Hypothesis 123 datenflussannotierter Kontrollflussgraph Def Def clear path definitionsfreie Pfade Dokumentenpr fung Domain Specific Languages 11 Driver dynamische Verfahren 191 INDEX Eclipse Effect Effect Operatoren 135 Effects in on pre states Effects on pre states 62 einfache Bedingungs berdeckung Elitismus endliche Zustandsautomaten Error Erweiterte Endliche Zustandsmaschinen
3. Invoking invoked transitions Tabelle 3 3 Zustandsbasierte Uberdeckungskriterien f r den Integrationstest aus SOPO07 F r zwei interagierende Komponenten C C COMP wurden in SOPO7 folgende zustands basierte Kriterien definiert zusammen mit Formeln f r die Berechnung der Anzahl zu berde ckender Mappings e Pre states and triggers Kriterium dieses Kriterium verlangt dass f r jedes Paar von Pre state und Trigger der aufrufenden Komponente C also f r jedes preC trC wobei preC Sc trC Trc mindestens ein Mapping m t t Map berdeckt wird f r das gilt 61 3 Modellbasierte berdeckungskriterien 62 pre t preC tr t trC Die Anzahl zu berdeckender Mappings wird anhand der folgenden Formel berechnet Pre states and triggers 35 IS Tr E c tr treTrc Pre states triggers and ef fects Kriterium dieses Kriterium verlangt dass f r jedes Tripel von Pre state Trigger und Effect der aufrufenden Komponente C also f r jedes preC trC eC wobei preC Sc trC Trc eC Ec mindestens ein Mapping m t t Map berdeckt wird f r das gilt pre t preC tr t trC e t eC Die Anzahl zu berdeckender Mappings wird anhand der folgenden Formel berechnet Pre states triggers and ef fects S Tr E c tr ell treTrc ecEc Invoking transitions Kriterium dieses Kriterium ver
4. E Invoking transitions on pre states K7C E Triggers and effects in on pre states K6C E Effects in on pre states K5C E Effects on pre states K4C B Invoking transitions K3C E Pre states triggers and effects K2C E Pre states and triggers K1C Abbildung 7 7 Fehlererkennungspotential bzgl einzelner Mutationsklassen von Testfallmen gen die zustandsbasierte Integrationstestkriterien auf dem Modell CabinControl erf llen Die Testfallmenge K8C erreicht bez glich aller vier Mutationsklassen sehr gute Ergebnisse Wie schon vorhin beschrieben erreicht die Testfallmenge K4C einen h heren Mutation score als die Testfallmenge K5C In Abbildung 7 ist zu sehen wo genau der Unterschied zwischen KAC und K5C entsteht und zwar durch die unterschiedliche Erkennbarkeit bez glich der Mutations klasse Effect Mutationen Des Weiteren ist anhand der Graphik zu erkennen dass bez glich Effect Mutationen K3C besser abschneidet als K7C obwohl das Kriterium Invoking transiti ons on pre states das Kriterium Invoking transitions subsumiert Dies l sst sich hnlich erkl ren wie der Unterschied zwischen K4C und KSC Insgesamt erreicht K3C aber einen niedrigeren Mutation score als K7C da durch K3C unter anderem die Pre state und Post state Mutationen zu einem kleineren Anteil erkannt wurden Aufgrund der von Invoking transitions on pre states geforderten berdeckung die auch die Pre states auf der au
5. gt waitingForTalkButton incomngCal 0 1 1 incomingCal incomingMegsage hinzugef gte Transition messageReceived amp ge nderter Zustand Abbildung 5 10 Beispiel f r nderung eines Zustandsautomaten oben Zustandsautomat vor der nderung unten Zustandsautomat nach der nderung Beim Laden des ge nderten InfotainmentGui Zustandsautomaten erscheint ein Dialog sie he Abbildung 5 11 da die vorhin beschriebene Testsuite mit 16 Testf llen aus der initialen Version des Zustandsautomaten generiert wurde Der Dialog fragt ab ob berpr ft werden soll inwiefern die 16 Testf lle auf dem ge nderten Zustandsautomaten ausf hrbar sind Falls diese Analyse nicht durchgef hrt wird wird die Testsuite verworfen Falls im Dialog Yes ausgew hlt 25Diese wird in Abschnitt 6 1 beschrieben 105 5 Werkzeugunterst tzung wird wird die Analyse durchgef hrt und die Ergebnisse der durchgef hrten Analyse angezeigt wiein Abbildung 5 12 dargestellt Da der Testfall TestCase 3 den ge nderten Zustand durch l uft wird er mit markiert Der Testfall TestCase 6 durchl uft auf dem alten Modell die Transition die im neuen Modell gel scht wurde was dazu f hrt dass dieser Testfall auf dem ge nderten Modell nicht mehr ausf hrbar ist und mit X markiert wird Alle anderen Testf lle k nnen unver ndert bernommen werden und werden mit J markiert Un Testsuites out of
6. ii 0 99 Minimize Testcase Cou 041 Ho HS X TestSuites TestCases Name Data Visibility Qualified Name Data Client Dependency Namespace Name Expression Element Import Package Import H Abbildung B 5 Konfiguration Gewichtung der Fitnessfunktion UN UnITeD Testgenerator C Users pinte Desktop Modell Modell uml File Optimization Test Scripts Mutation Options Window Help Get zum A 92 Packagelmport DA Packagelmport Coverage Criterium Optimization Conditions Advanced Stop Criterium None Max Generations Min Coverage Population Size Stagnation Generations Glob 1 Stagnation Generations Local Max Generations Local Lal Qualified Name Client Dependency Namespace Name Expression UN UnlTeD Testgenerator C Users pinte Desktop Modell Modell uml File Optimization Test Scripts Mutation Options Window Help Ge 5 Model 5 U2TP ao Hm X i T TestSuites estCases Please select a TestContext 4 H TestContext TestContext A b SUT sut E Setup setup 4 EJ TestContext TestContex B b SUT tA TestComponent tB Setup setup
7. o o 121 7 Evaluierung des Fehlererkennungspotentials modellbasierter Testfalle Nachdem im vorigen Kapitel die Ergebnisse der automatischen modellbasierten Testfallgenerie rung vorgestellt wurden wird in diesem Kapitel das Fehlererkennungspotential modellbasierter Testf lle evaluiert indem auf die Anzahl und Art der erkannten Fehler eingegangen wird Im Fol genden ist auch vom Fehlererkennungspotential eines berdeckungskriteriums die Rede damit ist immer das Fehlererkennungspotential automatisch generierter Testfallmengen gemeint die zur Erf llung dieses Kriteriums generiert wurden Wie schon im letzten Kapitel erw hnt erf llen mit einer Ausnahme alle generierten Testfallmengen das angestrebte berdeckungskriterium zu 100 Die Ausnahme bezieht sich auf eine Testfallmenge die nicht alle Transitionspaare des Zustandsautomaten Achstest berdeckt Da mit Hilfe modellbasierter Testf lle Modellie rungsfehler oder Implementierungsfehler erkannt werden k nnen wird im weiteren Verlauf das Erkennungspotential hinsichtlich dieser zwei Fehlerkategorien in den Abschnitten und separat behandelt Ein Teil dieser Ergebnisse wurden bereits in ver ffentlicht 7 1 Erkennungspotential hinsichtlich Modellierungsfehler Zur Bewertung des Potentials modellbasierter Testf lle hinsichtlich der Erkennung von Model lierungsfehlern wurde ein Modell Mutationstest durchgef hrt Um dieses Konzept zu erkl
8. 1 2 Zielsetzungen ren das auf genetischen Algorithmen basiert und die vollautomatische Optimierung und Evalu ierung modellbasierter Testf lle erm glicht Dieses Verfahren wurde in ein gleichnamiges Werk zeug umgesetzt Die entwickelte Testprozedur wurde erfolgreich im Bereich Magnetresonanztomographie beim Pilotpartner Siemens Medical Solutions in Erlangen erprobt Hier wurden bis zum Zeitpunkt des Werkzeugeinsatzes Testf lle manuell anhand der Spezifikation erstellt und in Textdateien zusam mengefasst Besonders die manuelle Wartung der Testf lle war dabei sehr aufw ndig nderte sich eine Anforderung so mussten auch m hsam alle Testf lle identifiziert werden die in Folge der nderung angepasst werden mussten Durch den Einsatz des Werkzeugs wurden der Testfallerstellungsprozess und die Wartung der generierten Testfallmengen bedeutend vereinfacht manueller Aufwand entstand nur noch bei der Erstellung und der Anpassung der Modelle nderte sich etwas an dem zugrundeliegenden Modell so wurden die davon betroffenen Testf lle automatisch durch das Werkzeug ermittelt und gegebenenfalls neue Testf lle generiert Am Ende des Piloteinsatzes betrug der Anteil au tomatisch generierter Testf lle 70 der Gesamtanzahl erstellter Testf lle was auf eine hohe Akzeptanz des Werkzeugs seitens des Pilotpartners hindeutet Ein wesentlicher Beitrag der hier vorgestellten Forschungsarbeit besteht also in der Entwick lung eines Verfahre
9. S angepasst werden Der Post state der Transition t wird gleich dem Post state der Transition f gesetzt so dass post t post t Daraufhin wird die Transition t gel scht Zustand Hinzuf gen dieser Operator betrachtet alle Transitionen t Tc 138 7 1 Erkennungspotential hinsichtlich Modellierungsfehler B Ek post t gt l O ein neuer Zustand S wird erzeugt Da f r diesen Zustand mindestens jeweils eine einge hende und eine ausgehende Transition ben tigt werden wird als einzige eingehende Transition die Transition f gesetzt so dass post t S und als einzige ausgehende Transition eine andere Transition 1 aus der Menge ti Telt At A Akprem gt 1 ausgew hlt so dass pre t S Wie an der Beschreibung der einzelnen Modell Mutationsoperatoren zu erkennen ist ist die Granularit t der eingef gten nderungen unterschiedlich So z B weicht ein Mutant der durch den Operator Boolesche Operatoren ndern generiert wurde nur hinsichtlich der booleschen Operatoren z B amp amp statt im Guard einer Transition eines Zustandsautomaten vom initialen Modell ab z B Guard im initialen Modell a gt 0 amp amp b lt 0 Guard im Mutant a gt 0 b lt 0 Andere Operatoren erzeugen dagegen gr ere Abweichungen wie z B der Operator Transition L schen Dieser l scht eine Transition und dabei gleichzeitig auch falls vorhanden den Trig ger den Guard und den Effect diese
10. diese Menge beinhaltet einen Teil der bei der Mutation betrachteten Vergleichsoperatoren MengeArithmetischeO peratoren x diese Menge beinhaltet alle bei der Mutation betrachteten arithmetischen Operatoren Aufbauend auf diesen Konzepten werden im Folgenden die implementierten Modell Mutati onsoperatoren beschrieben Dabei lassen sich die Operatoren in sieben Klassen aufteilen Trig ger Operatoren Guard Operatoren Effect Operatoren Pre state Operatoren Post state Opera toren Transition Operatoren und Zustand Operatoren Die Klasse Effect Operatoren l sst sich weiter auf folgende drei Klassen aufteilen Variablenzuweisung Operatoren Aufruf Operatoren und Generische Effect Operatoren 133 7 Evaluierung des Fehlererkennungspotentials modellbasierter Testf lle Trigger Operatoren Trigger L schen dieser Operator l scht den Trigger einer Transition t Dadurch kann es pas sieren dass der Guard und oder der Effect der Transition ung ltig werden Deshalb wird dieser Operator nur auf Transitionen angewendet die zwar einen Trigger aber weder Guard noch Effect besitzen Dar ber hinaus muss gelten dass der Pre state der Transition t nur eine einzige ausgehende Transition hat und zwar die Transition f Bir AL 8t L e t L Wisel 1 O tr t wird gel scht Trigger Hinzuf gen B tr t 2 pre t Anfangszustandc O der Transition wird ein Trigger zugewiesen der zuf llig aus
11. opA2 opA3 opA2Q opA3Q opA2 opA3 opA1 1770596331 Bn opA5 opA1 1988063922 opB4 opA2 opA3 ona opA3 opA2 opA3Q opA2Q opA3 0pA1 1794321776 opB1 1052368042 opAS opB4 opA5Q 0pB1 620774538 opB4 Population Menge von Testsuites Abbildung 4 2 Kodierungsvorschrift der Individuen Aufrufe opB1 12345 opB3 und opB4 an Komponente B enthalten aber nicht den Aufruf opB2 da opB2 ein interner Aufruf zwischen den Komponenten A und B ist Ein Beispiel f r einen Integrationstestfall f r die Komponenten A und B ist opA1 4 opB1 69171531 opA2 opA3 Im Rahmen dieser Arbeit wird als globale Optimierung das Vorgehen bezeichnet das den in Abbildung A I beschriebenen Algorithmus auf Mengen von Testsuites umsetzt W hrend der globalen Optimierungsphase werden also die zwei Ziele Maximierung der ber deckung und Minimierung der Testfallanzahl gleichzeitig verfolgt Dabei kann es vorkommen dass manche Entit ten der Zustandsautomaten w hrend der globalen Optimierungsphase nicht berdeckt werden Deshalb wurde auch eine lokale Optimierung umgesetzt welche dazu dient Transitionen oder Zust nde eines Zustandsautomaten zu berdecken die w hrend der globalen Optimierungsphase nicht berdeckt wurden Die Suche nach nicht berdeckten Mappings wird allerdings nicht unterst tzt In Rahmen der lokalen Optimierungsphase wird also nur das Ziel der berdeckungsmaximie
12. opB4 opA2 opA3 opa2 opa3 opA2 opa3 opal 70596 0pB1 1627284803 opA5 opB4 opAl 1988063922 opB4 opA2 opA3 Baren opA3 opA2 opA3Q opA2 opA3Q 0pA1 1794321776 opB1 1052368042 opA5 opB4 OpAS opB1 620774538 opB4 Abbildung 4 4 Schemenhafte Darstellung der umgesetzten Rekombinationstypen a auf Testfallebene b auf Aufrufebene c auf Testdatenebene 6Was das genau bedeutet wird im Folgenden beschrieben 85 4 Automatische modellbasierte Testfallgenerierung mittels genetischer Algorithmen F r die Rekombination auf Ebene der Testf lle oder der Aufrufe wurden drei Rekombinati onsoperatoren umgesetzt Diese Operatoren unterscheiden sich in der Art und Weise wie sie Kreuzungspunkte ansetzen Gemeinsam haben sie dass sie auf Folgen oder Mengen von Entit ten angewendet werden k nnen D h diese Operatoren k nnen sowohl auf Individuen Menge von Testf llen als auch auf einzelne Gene Folge von Aufrufen angewendet werden Folgende Operatoren wurden umgesetzt e SinglePoint es wird eine Stelle zuf llig ausgew hlt ab dem die Elemente ausgetauscht werden e TwoPoint es werden zwei Stellen ausgew hlt Zwischen der ersten und der zweiten Stelle werden zwischen den Individuen Elemente ausgetauscht e Uniform es werden alle Elemente durchlaufen und jedes zweite Element zwischen den beiden Entit ten ausgetauscht Welcher dieser drei Auspr gung
13. Deshalb wurde in diesen F llen statt der Uberde ckung aller Transitionspaare die berdeckung aller ausf hrbaren Transitionspaare angestrebt Die Ergebnisse der Testfallgenerierung werden in Tabelle 6 3 dargestellt Ein Teil dieser Ergeb nisse wurde bereits in vorgestellt Mit einer Ausnahme konnten alle generierten Testsuites die 100 ige berdeckung hinsicht lich der angestrebten ausf hrbaren Entit ten erreichen Die Ausnahme bezieht sich auf die Test fallmenge die 97 84 aller ausf hrbaren Transitionspaare des Zustandsautomaten Achstest ber deckt Tabelle 6 3 zeigt dass f r die Erf llung der Zustands berdeckung nur wenige Testf lle be n tigt werden im Schnitt ber die drei Testsuites nur 4 67 Die Anzahl an insgesamt in der Testsuite f r Zustands berdeckung enthaltenen Teststeps Spalte TS ist auch gering im Schnitt nur 38 7 Zur Erf llung des Kriteriums Transitions berdeckung wurden bedeutend mehr Test f lle ben tigt Die Testsuites f r Transitions berdeckung enthalten im Schnitt circa viermal so viele Testf lle und Teststeps wie die Testsuites f r Zustands berdeckung Einen hnlichen Un terschied im Umfang gibt es auch zwischen den Testfallmengen f r Transitionspaar berdeckung 5Siehe Tabelle 6 2 113 6 Evaluierung der vorgestellten Testfallgenerierungsmethode ZM Zustands b Transitions b Transitionspaar b TC TS UE TC TS UE TC TS UE Konto 2 6 8 6 38 19 22 151 58 Infotainment
14. berdecken Ein Kriterium das auf die berdeckung einzelner Messages ausgerichtet ist ist das in DTO7 beschriebene All Message Coverage Kriterium das wie folgt formuliert wurde Testing must cause each message in a sequence diagram to be sent at least once Ein Beispiel f r ein berdeckungskriterium auf Sequenzdiagrammen das Message Sequenzen ber cksichtigt ist das in SM10 eingef hrte Message Sequence Path Kriterium For each sequence diagram there must be at least one test case T such that when the software is executed using T the software that implements the message sequence path of the sequence diagram must be executed Semantisch quivalent zum Sequenzdiagramm ist das Kommunikationsdiagramm Auf die 56 3 3 Modellbasierte berdeckungskriterien f r den Integrationstest Testfallgenerierung aus Kommunikationsdiagrammen konzentrieren sich eine Reihe von Arbei ten wie z B AO00 und AFGCO3 Aufgrund der semantischen quivalenz zu Sequenzdiagrammen sind die f r Kommunikationsdiagramme beschriebenen berdeckungskri terien hnlich wie die vorhin erw hnten Kriterien die f r Sequenzdiagramme definiert wurden Als Beispiel f r ein solches Kriterium sei das in definierte Kriterium Each valid sequence in each collaboration diagram has to be tested at least once 1 Der Tatsache dass in Kommunikationsdiagrammen auch Guards an den Messages modelliert werden k nnen wird in Rechnung getragen
15. e das anvisierte berdeckungskriterium auf Komponenten und auf Integrationsebene e die Parametrisierung des Algorithmus e die Gewichtung der einzelnen Fitnesswerte e die Abbruchbedingung Diese Einstellungen werden abgespeichert und m ssen dann nicht vor jedem Generierungs prozess neu gesetzt werden Vor dem ersten Starten des Werkzeugs sind noch die Standardein stellungen abgespeichert die jederzeit wieder hergestellt werden k nnen Der Men punkt Test Skript erm glicht es die generierten Testf lle in diverse Formate zu ex portieren Unter anderem werden sie in ein Format exportiert das als Eingabe f r das Testmana gement Werkzeug HP TestDirector benutzt werden kann Der Men punkt Mutation erlaubt das Aufrufen des Moduls das die Bewertung der generierten Testsuites hinsichtlich deren Potential Modellierungsfehler zu entdecken erm glicht Unter dem Men punkt Options k nnen diverse Einstellungen vorgenommen werden z B ob Die zul ssige Modellierung von Bedingungen in Guards wurde in Abschnitt 3 1 beschrieben I5Siehe Kapitel 94 5 2 Visualisierung berdeckter sowie zu berdeckender Modellelemente der Men punkt Mutation berhaupt angezeigt werden soll oder ob die Log Informationen im Log Fenster angezeigt werden sollen Schlie lich erm glicht der Men punkt Window das Verwalten der einzelnen Bereiche der GUI Der Men punkt Help erm glicht das Abrufen eines About Dialogs der diverse Informatione
16. myCabindontrol cabinUp currentFloor cabinFloor requestCabin cabinFloor Integer cabinFloor lt currenfFloor myCabinControl cabinDown currentFloor cabinFloor e gt xe requestTravel targetLevel Integer targetLevel lt currentFloor myCabinControl cabinDown requestTravel targetLevel Integer targetLevel gt currentFloor myCabinControl cabinUp done done processing upward TravelRequest processing downward TravelRequest A UML Modelle Modell CabinControl Komponente MainControl Abbildung A 5 178 lt lt ExternalSt gt gt lt lt ExternalSt gt gt closed open closeDoor final Abbildung A 6 Modell CabinControl Komponente CabinDoorControl buttonPushed myMainControl requestCabin 3 final gt lt lt ExternalSt gt gt open Abbildung A 7 Modell CabinControl Komponente TopFloorControl openFloor lt lt ExternalSt gt gt closed closeFloor buttonPushed myMainControl requestCabin mF final lt lt ExternalSt gt gt lt lt ExternalSt gt gt closed open Abbildung A 8 Modell CabinControl Komponente MiddleFloorControl openFloor closeFloor final buttonPushed myMainControl requestCabin 1 lt lt ExternalSt gt gt lt lt ExternalSt gt gt closed open Abbildung A 9 Modell CabinControl Komponente BaseFloorControl openFloor cl
17. 38 2 6 Modellbasierter Test Test Generation und Durchf hrungstechnologie Test Execution Die vertikalen Pfeile mit zwei Spitzen kommen bei den Dimensionen Subject und Redundancy vor deuten auf eine kontinu ierliche Reihe von M glichkeiten hin Das bedeutet dass auch Mischformen der dargestellten Alternativen m glich sind Die geschwungenen Linien zeigen Alternativen die sich nicht un bedingt gegenseitig ausschlie en Dagegen kennzeichnet das Symbol an den Bl ttern dieses Baumes sich gegenseitig ausschlie ende Alternativen nvironment Subject SUT Shared test amp dev model Redundancy Separate test model Moser Ve Non Det Characteristics eg Timed Discrete Continuous Pre Po pe Transition Based Z History Based Functional Operational Structural Model Coverage Data Coverage L T Requirements Coverage Test Selection Criteria Test Case Specifications u Random amp Stochastic Test Fault Based Generation wem a sonora 7 Graph search algorithms Technology Model checking N Symbolic execution nm d Theorem proving Heunistic Methods in Execution On Offline Online Offline Abbildung 2 2 Taxonomie modellbasierter Testans tze aus UPLO6 39 2 Grundlagen Einzelne Begriffe aus der Abbildung 2 2 wurden vom Bearbeiter dieser Arbeit durch Umran dung gekennzeichnet um zu zeigen
18. Der Aufruf opA4 false kann nicht bearbeitet werden da die Komponente A nach dem Aufruf von opA1 1230053765 mit einem Wert kleiner als 0 in den Zustand A3 bergeht in dem der Aufruf opA4 false nicht bearbeitet werden kann Durch Modellsimulation und die darauf folgende Anwendung genetischer Operatoren werden allerdings ausgehend von der Anfangspopulation Testf lle erzeugt die komplett abgearbeitet werden k nnen und eine hohe berdeckung erreichen 4 3 3 Fitnessfunktion der Individuen Ein wichtiges Konzept der genetischen Algorithmen ist die verwendete Fitnessfunktion Sie steu ert den Algorithmus ma geblich indem sie jedem generierten Individuum einen numerischen Wert zuordnet der die G te dieses Individuums hinsichtlich der angestrebten Optimierungsziele angibt Somit wird erm glicht dass einzelne Individuen einer Population miteinander verglichen werden Wie schon in Abschnitt 4 3 1 erw hnt wird zwischen globaler und lokaler Optimierung un terschieden Dementsprechend gibt es auch eine globale und eine lokale Fitnessfunktion Da die lokale Optimierung nur eine Erg nzung zur globalen Optimierung darstellt und dar ber hinaus nur den Komponententest unterst tzt ist sie f r den Zweck dieser Arbeit nicht von so hoher Bedeutung Deshalb wird im Folgenden die globale Fitnessfunktion detailliert dargestellt wo hingegen die Beschreibung der lokalen Fitnessfunktion bewusst kompakt gehalten wird Die globale Fitnessfunkt
19. based Software Systems 2580 2003 Stephan Wei leder and Bernd Holger Schlingloff Automatic Test Generation from Coupled UML Models using Input Partitions In Proc of Int Workshop on Model Driven Engineering Verification and Validation 2007 Stephan Weissleder and Bernd Holger Schlingloff Quality of Automatically Gene rated Test Cases based on OCL Expressions In CST 08 Proceedings of the 2008 International Conference on Software Testing Verification and Validation pages 517 520 Washington DC USA 2008 IEEE Computer Society Abbildungsverzeichnis 2 1 Die Diagramme der UML aus OMG10 s 720 2 2 2222 13 2 2 Taxonomie modellbasierter Testans tze aus UPLO6 39 3 1 Zustandsautomat der das Verhalten einer Komponente A beschreibt aus PSO08 46 3 2 Beispiel f r ein Modell mit zwei interagierenden Komponenten aus PSO08 60 3 3 Subsumptionshierarchie der zustandsbasierten Kriterien aus PS10 65 4 1 Allgemeine Vorgehensweise genetischer Algorithmen aus SP10 71 4 2 Kodierungsvorschrift der Individuen 22s 75 4 3 Ergebnisse eines Experiments zur Veranschaulichung der Funktionsweise des Selektionsoperators EENHEETEN 84 4 4 Schemenhafte Darstellung der umgesetzten Rekombinationstypen a auf Testfallebene b auf Aufrufebene c auf Testdatenebene 85 5 1 Screenshot UnITeD Dialog zur Auswahl eines TestContextes 90 5 2
20. diese Sprache erlaubt es Einschr nkungen Engl Constraints f r bestimmte Elemente der UML festzulegen Beispielsweise erlaubt die Sprache die Angabe von Invarianten f r Attribute von Klassen oder die Formulierung von Vor und Nachbedingungen f r Methoden e Die Standards XML Metadata Interchange Kurz XMI und UML Diagram Interchange Kurz UMLDT unterst tzen den Austausch von Modellen zwischen verschiedenen UML Werkzeugen e Model Driven Architecture Kurz MDA stellt den Standard der OMG zu modellgetrie benen Entwicklung dar Im Rahmen dieses Standards wird eine konkrete Vorgehensweise fiir die modellgetriebene Entwicklung vorgeschlagen die besonders auf die Trennung zwi schen fachlichen und technischen Modellen Wert legt 4Hie in lteren UML Versionen Kollaborationsdiagramm Diese sind alle ber die OMG Seite http www omg org verf gbar 6Kurz f r Extensible Markup Language 15 2 Grundlagen 2 3 Komponentenbasierte Softwareentwicklung Im Rahmen eines komponentenbasierten Entwicklungsprozesses wird die zu erstellende Soft ware nicht als ein monolithisches System von Grund auf neu entwickelt sondern als Menge von interagierenden Komponenten zusammengestellt Die einzelnen Komponenten k nnen da bei entweder neu entwickelt oder von Drittanbietern zugekauft werden wobei es sich im zweiten Fall um so genannte Off the shelf Komponenten handelt Definition 2 1 Komponente laut IEEE Standard 610 1991
21. es ist viel anspruchsvoller als die Anweisungs oder Zweig berdeckung aber meistens nicht sinnvoll einsetzbar da in nicht trivialen Programmen die Anzahl an Pfaden durch den Kontrollflussgraphen sehr hoch ist falls Schleifen im Kontrollussgraphen vorkommen kann die Anzahl an Pfaden sogar unbegrenzt sein Sind Bedingungen die keine untergeordneten Bedingungen enthalten z B die zusammengesetzte Bedingung a gt 0 amp amp b true besteht aus den atomaren Teilbedingungen a gt 0 und b true 34 2 5 Testen Deshalb gibt es abgeschw chte Varianten dieses Kriteriums die die Anzahl der Schleifen durchl ufe begrenzen z B der strukturierte Pfadtest Dabei wird ein maximaler Wert E f r die Anzahl der Schleifendurchl ufe vorgegeben und es wird die berdeckung aller Pfade verlangt die Schleifen h chstens k mal durchlaufen Ein Spezialfall davon mit k 2 ist der Boundary Interior Pfadtest Datenflussorientierter Test Diese Testart geh rt auch zu den Strukturtestverfahren Im Gegensatz zu den kontrollflussorien tierten Verfahren zielen diese Verfahren nicht auf die berdeckung aller Knoten Kanten oder Pfade des Kontrollflussgraphen sondern auf die berdeckung von Variablendefinitionen samt dazugeh riger Variablenverwendungen Um diese Kriterien zu beschreiben m ssen neben dem in Definition 2 5 eingef hrten Kontroll flussgraphen noch weitere Begriffe eingef hrt werden Eine Definition Kurz Def ei
22. glichen k nnte Ein Schritt weiter in Richtung der Betrachtung der Zust nde interagierender Komponenten wird in ABuR 06 gegangen Hier werden in einem ersten Schritt Zustandsautomaten und Kommunikationsdiagramme kombiniert um ein neues Diagramm das so genannte State Col laboration Test Model Kurz SCOTEM zu generieren Auf Basis dieses Diagramms k nnen 0 n der Definition wird der Begriff Collaboration Diagram benutzt Dies kommt daher da das Kommunikations diagramm in fr heren UML Versionen Kollaborationsdiagramm Engl Collaboration Diagram hie 57 3 Modellbasierte Uberdeckungskriterien Testsequenzen f r den Integrationstest automatisiert generiert werden Dazu werden berde ckungskriterien betrachtet die auf die berdeckung von Pfaden im SCOTEM ausgerichtet sind Durch berdeckung solcher Pfade werden die Zust nde der aufgerufenen Komponenten betrach tet d h es wird getestet wie eine Komponente auf einen Aufruf abh ngig von dem Zustand in dem sie sich befindet reagiert Die beschriebene Vorgehensweise betrachtet allerdings nicht die aufrufende Komponente also nicht die Tatsache dass der Aufruf aus unterschiedlichen Zust n den bzw aus unterschiedlichen Transitionen der aufrufenden Komponente erfolgen kann Zusammenfassend werden die aufgez hlten modellbasierten Ans tze in Tabelle darge stellt Einzelne Ans tze betrachten neben den vorhin erw hnten Interaktionsdiagrammen und Zu standsautomaten a
23. hlten Elements des Modellbaums dargestellt Rechts oben werden im Bereich Generierte Testsuites die aus dem Modell generierten Test suites dargestellt Aus dieser Liste kann durch Anklicken eine Testsuite ausw hlt werden was zur Folge hat dass im Bereich Eigenschaften einer ausgew hlten Testsuite die Eigenschaften der ausgew hlten Testsuite dargestellt werden Dieser Bereich enth lt mehrere Informationen Zum einen wird beschrieben f r welchen TestContext diese Testsuite generiert wurde In diesem Fall handelt es sich um den TestContext_B die Testsuite wurde also generiert mit dem Ziel die Map 8Der Zustandsautomat dieser Komponente ist in Abbildung dargestellt Der Zustandsautomat dieser Komponente ist in Abbildung dargestellt 10D h man k nnte genauso gut tA den Stereotyp TestComponent zuordnen und tB den Stereotyp SUT Dieser Screenshot wurde bearbeitet in dem einzelne Bereiche der GUI markiert und benannt wurden Tn diesem Fall handelt es sich um ein Modell das in MagicDraw erstellt wurde und die zwei Komponenten aus Abbildung 3 2 enth lt 9 5 Werkzeugunterst tzung Modellbaum Eigenschaften einer ausgew hlten Testsuite EE No BR X TestSuites TestQpse Ti TestCase 1 ASteps 9 1D 1 Fi TestCase 2 Steps 7 10 2 K Uk 2011 07 06 13 14 49 186 INFO TO COVER Eq Classes 2 2011 07 06 13 14 49 186 INFO tA6 tB4 gt 1 2011 07 06 13 14 49 186 INFO tA6
24. hren dazu dass die Erstellung solcher Systeme zu einer immer gr eren Herausforderung wird Um diese Herausforderung meistern zu k nnen wurde Ende der 60er Jahre die Forderung laut bei der Entwicklung von Software nach ingenieurm igen Prinzipien vorzugehen Es entstand somit eine neue Disziplin mit dem Namen Software Engineering Mit Entstehung dieser Disziplin wurden Grundprinzipien der klassischen Ingenieurwissen schaften f r die Softwareentwicklung bernommen So h lt z B das Prinzip der Abstraktion als Hilfsmittel zur Bew ltigung der Komplexit t mit der modellbasierten Softwareentwicklung auch in der Softwareindustrie Einzug Ebenfalls zum Zweck der Bew ltigung komplexer Pro blemstellungen eignet sich die Teile und Herrsche Strategie auf welcher das weit verbreitete komponentenbasierte Softwareentwicklungsparadigma beruht 1 1 Motivation Die vorhin genannten Entwicklungsparadigmen haben dazu gef hrt dass sich die Art wie Soft ware entwickelt wird bedeutend gewandelt hat Heutzutage wird die zu erstellende Software nicht mehr als ein monolithisches System von Grund auf neu entwickelt Vielmehr wird die gew nschte Systemfunktionalit t in einzelne Teilfunktionalit ten aufgeteilt um daraufhin f r die Umsetzung der Teilfunktionalit ten entweder bestehende Komponenten wiederzuverwenden 1 Einleitung oder neue Komponenten zu entwickeln Ein System ist somit eine Zusammenstellung von ein zelnen ne
25. prSt play o stop cdinput cdinUnit trug que RIl navige ihcomingChll ArSt blay my CDUnit pause incomingPall myCDUnit pquse prSt j play exterhalEndChll navige Abbildung 5 4 Ausschnitt eines Zustandsautomaten der um Uberdeckungsinformationen eines einzelnen Komponententestfalls erg nzt ist 5 2 2 Visualisierung berdeckter und noch zu berdeckender zusammengesetzter Entit ten Zur Visualisierung zusammengesetzter Entit ten reicht allein die F rbung nicht mehr aus da diese Art von Entit ten sich als Kombination einzelner atomarer Entit ten beschreiben lassen die zum Teil verschiedenen Diagrammen angeh ren Deshalb werden zur Beschreibung der zu berdeckenden zusammengesetzten Entit ten Notizen an den Transitionen der Diagramme 207 B Mappings bestehen aus zwei Transitionen aus verschiedenen Automaten 98 5 2 Visualisierung berdeckter sowie zu berdeckender Modellelemente hinzugef gt Diese Notizen enthalten Informationen zu den Mapping Gruppen zu denen diese Transition geh rt Diese Gruppen werden im Notiztext wie folgt dargestellt auf der ersten Zeile wird der Name der Transition beschrieben wonach auf jeder Zeile jeweils eine Mapping Gruppe beschrieben wird In jeder Zeile stehen also zueinander alternativ zu berdeckende Mappings Beispielhaft wird die Darstellung der Mapping Gruppen in Abbildung 5 dargestellt Die No tiz a zei
26. referenzierten Komponenten Ein Beispiel f r so einen TestContext ist der TestContext_B aus Abbildung 5 1 Dieser enth lt durch die Variable tA eine Referenz auf Komponente A und durch die Variable tB eine Referenz auf Komponente B Dabei wird der Variable tA der Stereotyp SUT zugewiesen und der Variable tB der Stereotyp TestComponent Dies beruht auf der im Rahmen des Projekts gew hlten Modellierungskonvention falls nur eine Komponente refe renziert wird bekommt die entsprechende Variable den Stereotyp SUT Falls mehrere Kom ponenten referenziert werden muss eine Variable mit dem Stereotyp SUT belegt werden und alle anderen Variablen mit dem Stereotyp TestComponent F r die Testfallgenerierung ist der Stereotyp der einzelnen Variablen nicht relevant es ist nur wichtig dass alle Variablen mit einem Stereotyp versehen werden Nachdem die vom Werkzeug UnITeD ben tigten Eingaben beschrieben wurden werden im folgenden Teil dieses Abschnittes die Funktionalit ten des Werkzeugs beschrieben Diese werden ber eine GUI zur Verf gung gestellt die in Abbildung gezeigt und im Folgenden kurz beschrieben wird Im Bereich Modellbaum wird in einer Baumdarstellung das geladene UML Modell dar gestellt das sowohl das System als auch die Testsystembeschreibung mit den entsprechenden TestContexten enth lt Links unten werden im Bereich Eigenschaften eines ausgew hlten Mo dellbaumelements die Eigenschaften eines ausgew
27. s Sc 3t Te s pre t tr t 2 x e t y die Menge der Pre states von Transitionen mit einem bestimmten Trigger x und einem Effect y Anhand des Triggers opA3 und des Effects b opB2 wird diese Menge beispielhaft beschrieben Beispiel S Tr E A opA3 b opB2 44 51 3 Modellbasierte Uberdeckungskriterien In den n chsten zwei Abschnitten werden die bei der Testfallgenerierung betrachteten Krite rien vorgestellt F r jedes Kriterium wird mit der Bezeichnung NameKriterium die Anzahl zu berdeckender Entit ten angegeben Hierbei werden auch Entit ten mitgez hlt die u U gar nicht berdeckt werden k nnen Da dar ber hinaus mit einem Testfall mehrere Entit ten berdeckt werden k nnen beschreiben diese Metriken obere Schranken der zur Erf llung entsprechender Kriterien ben tigten Testfallanzahl 3 2 Modellbasierte berdeckungskriterien f r den Komponententest hnlich wie auf Codeebene gibt es auch f r Zustandsautomaten eine ganze Reihe von ber deckungskriterien Da Zustandsautomaten Graphen sind kann ein gro er Teil der in Abschnitt 2 5 2 beschriebenen White Box Testkriterien auf Zustandsautomaten tibertragen werden Die am meisten verbreiteten Kriterien sind die die auf die Uberdeckung der Knoten und Kanten eines Zustandsautomaten ausgerichtet sind e Zustands berdeckung verlangt die berdeckung aller Zust nde S Sc des Zustandsauto maten einer Komponente C Zustands b
28. tB3 gt 2 2011 07 06 13 14 49 186 INFO COVERED 2011 07 06 13 14 49 186 INFO tA6 tB3 2011 07 06 13 14 49 186 INFO tA6 tB4 Abbildung 5 2 Screenshot UnITeD Aufbau der Benutzeroberfl che 92 5 1 Das Werkzeug UnITeD pings zwischen den zwei Komponenten A und B zu berdecken Darunter wird das anvisierte berdeckungskriterium beschrieben zusammen mit der von der Testsuite erreichten berde ckung Des Weiteren wird auch die Anzahl an Teststeps Anzahl an Aufrufen angegeben die als Summe aller Aufrufe ber alle Testf lle der Testsuite berechnet wird Weiter unten wird die mittlere Anzahl an Teststeps pro Testfall angegeben gefolgt von dem Anteil an finalisierten Testf llen Schlie lich wird die Anzahl der Testf lle angegeben die in der Testfallmenge ent halten sind Unter Missing Elements werden die Entit ten angegeben die zu berdecken waren aber mittels der betrachteten Testsuite nicht berdeckt werden konnten Abh ngig vom berde ckungskriterium werden hier also einzelne Zust nde Transitionen Transitionspaare oder Map pings angegeben Durch den ausgew hlten Testfall wurden beide Mappings berdeckt Reached Coverage 100 in Abbildung 5 2 was zur Folge hat dass die Liste der Missing Elements leer ist Durch das Ausw hlen einer Testsuite werden zus tzlich in den zwei Bereichen die von Test f lle einer ausgew hlten Testsuite referenziert werden die
29. 124 Extended Finite State Machine Language 124 externer Pfad externer Zustand Failure Fault Fehler fehlerbehebende Wartung fehlerhafter Zustand formale Modellierungssprachen funktionale quivalenzklassenbildung funktionales Testen Funktionsorientierte Integration funktionsorientierter Test Funktionstest General Purpose Language generische Effects 48 Generische Effect Operatoren 137 Generischen Effect Hinzuf gen 137 Generischen Effect L schen 137 genetische Algorithmen globale Optimierung 75 Graphensuche 192 Grenzwertanalyse Grey Box Test Guard Guard Hinzuf gen 134 Guard L schen 134 Guard Operatoren 134 Guard Variable ndern 135 heuristische Verfahren informale Modellierungssprachen initiales Modell 125 Inside Out Integration Inspections Installationstest Integrationstest Integrationstestfall Interaktions bersichtsdiagramm Interaktionsdiagramm Interface intermodulare Fehler 130 interner Aufruf Interoperabilit tstest intramodulare Fehler 130 Invoking invoked transitions Invoking Transition Invoking transitions Invoking transitions on pre states 63 Irrtum JUnit Klassendiagramm Koh sion Kollaborationsdiagramm Kommunikationsdiagramm Komponente Komponentendiagramm Komponententest Komponententestfall Kompositionsstrukturdiagramm Konfigurationstest konstruktive Qualit tssicherung Kontrollflus
30. 16 02 13 CEST 2011 23 ELI Ex Data EB Comment D7 Packagelmport 95 Packagelmport E System 4 Errors in c E TestSystem E auxiliaryResource ProfileApplication DA ProfileApplication a ProfileApplications DZ ProfileApplication DA sProfileApplications H m A E Properties SS Properties SEE y vee Generation Age x Population Legend Elite History 30 one cce Range from oldest to late TEE ee H Overview Paths and Data Population Distribution Test Test O Testsuites im HO ob XX TestSuites TestCases TestC Test Test TestC Test Test TestC Test TestC TestC Individui Individu Individu Individu Individu Individu Individu Individu r Testsuite TestCor Ti TestCase1 Ti TestCase2 Ti TestCase3 Ti TestCase 4 Ti TestCase 5 EI od H TestContext TestContext_A SUT ui UserControl Behavior of SUT UserControl Coverage criterion Edge Coverage Reached coverage 100 0 TestSteps 101 Average TestSteps 8 42 Reached finalization 54 0 Number of Testcase 12 Creation Date 2011 09 30 16 02 13 Missing Elements Number of elements to cover 54 Number of covered elements 54 1 09 30 16 04 08 510 INFO Total Time 0 hour 1 min 54 sec
31. 20 usw 2000 1800 1600 1400 1200 1000 800 600 400 200 H e e SP o e S S o Y gt P 9 S S f S S S a YT YF LK F S9 d N Y E Abbildung 4 3 Ergebnisse eines Experiments zur Veranschaulichung der Funktionsweise des Selektionsoperators Durch diesen Selektionsoperator werden also haupts chlich Individuen ausgew hlt die auf den ersten Stellen der aktuellen Population stehen Da diese Population der Fitness nach abstei gend sortiert ist handelt es sind dabei um die besten Individuen der aktuellen Population D h diese Strategie ist vergleichbar mit der in Abschnitt 4 2 beschriebene Roulette wheel selection Um einen solchen Wert zu generieren wird als erstes die Funktion nextDouble der Java Math Klasse aufgerufen die eine gleichverteilte Zufallszahl randomValue mit Werten aus dem Intervall 0 0d 1 0d zur ckgibt Falls der Wert in randomValue kleiner als 0 5 ist wird der Wert Math sqrt 2 randomValue 1 generiert anderenfalls der Wert Math sqrt 2 2 randomValue 84 4 3 Einsatz genetischer Algorithmen zur automatischen modellbasierten Testfallgenerierung wobei die Wahrscheinlichkeit nicht proportional zu der Fitness ist Aus diesen zwei ausgew hlten Individuen werden durch den Rekombinationsoperator neue Individuen erstellt 4 3 4 3 Rekombinationsoperatoren Der umgesetzte Rekombinationsoperator erzeugt durch die Kombination zweier
32. Basierend auf diesen nderungsarten erlaubt das Werkzeug die bestehenden und neu generier ten Testf lle wie folgt zu klassifizieren PBSO08 e Klasse Identical beinhaltet Testf lle die ausschlie lich unver nderte Modellbereiche durchlaufen und deshalb unmittelbar bernommen werden k nnen e Klasse X Obsolete beinhaltet Testf lle die im ver nderten Modell nicht mehr lauff hig sind und in ihrer urspr nglichen Form zu verwerfen sind e Klasse Retest Required beinhaltet Testf lle die ver nderte Modellbereiche durchlaufen deren Verhalten deshalb neu berpr ft werden muss e Klasse N New beinhaltet neu hinzugef gte Testf lle Beispielhaft werden diese Konzepte an dem in Abbildung 5 9 dargestellten Zustandsautomaten veranschaulicht Die Transition t3 wurde entfernt daf r eine neue Transition t9 hinzugef gt Der Name des Zustands A5 wurde in A5a umgewandelt Vorausgesetzt es gibt eine Testsuite T T1 T2 T3 die eine vollst ndige Transitionsiiber deckung der urspr nglichen Version dieses Automaten erreicht indem die einzelnen Testf lle folgende Pfade durchlaufen T1 AO AI A2 A3 A3 A6 T2 AO Al A4 A2 A3 A6 22Siehe Abschnitt 23D h dass mindestens ein Aufruf des Testfalls bei der Simulation des Testfalls auf dem Zustandsautomaten nicht abgearbeitet werden kann 103 5 Werkzeugunterst tzung t7 AO tr ae t4 tr4 g4 e4 t1 tr1 g1 e1 t3
33. Design von objektorientierten Programmen akzeptiert Als relativ junge Modellierungssprache wurde die UML immer wieder ge ndert die aktuelle Version der UML ist die 2 3 die im Mai 2010 ver ffentlicht wurde OMG10 Verwaltet wird die UML Spezifikation von der OMG welches ein 1989 gegr ndetes Konsor tium aus ber 800 Unternehmen ist das sich mit der Entwicklung von Standards besch ftigt Neben vielen Softwareherstellern wie Microsoft IBM oder Sun befinden sich darunter auch Un ternehmen deren Kerngesch ft nicht im Softwarebereich liegt wie z B Daimler oder die Nasa Ab der Version 2 0 wurde die UML Spezifikation unterteilt in die e UML Infrastructure Specification stellt das Fundament der Sprache dar und beschreibt die grundlegenden Sprachkonstrukte der UML wie z B Klassen oder Assoziationen Mit Hilfe dieser Konstrukte wird die UML Superstructure erfasst e UML Superstructure Specification diese baut auf die Infrastructure auf und beschreibt Spracheinheiten die sehr UML spezifisch sind wie z B Anwendungsfall oder Aktivit t Die UML enth lt 14 Diagrammarten welche in unter Ber cksichtigung der UML Spezifikation bersichtlich und verst ndlich beschrieben werden Diese Diagramme lassen sich in Struktur Engl Structure Diagrams und Verhaltensdiagramme Engl Behavior Diagrams aufteilen Alle verf gbaren Diagramme werden in Abbildung 2 1 dargestellt Die Strukturdiagramme eignen sich zur Modellierung der statisc
34. Diese geringe Quote ist darauf zur ckzuf hren dass dieses Kriterium zwar die einzelnen Anweisungen betrachtet nicht aber die verschiedenen Kontrollfl sse zwischen ihnen Aufgrund der geringen Leistungsf higkeit der Anweisungs berdeckung gilt die Zweig ber deckung als das minimale Testkriterium f r White Box Verfahren Dieses Kriterium subsu miert die Anweisungs berdeckung da sie die berdeckung aller Kanten des Kontrollfluss graphen fordert was automatisch auch bedeutet dass alle Knoten zu berdecken sind Sie wird auch als Entscheidungs berdeckung bezeichnet da jede Entscheidung im Kontrollflussgraphen 36 Auch CO Test genannt 37 Auch C1 Test genannt 38Ejn Kriterium K subsumiert ein anderes Kriterium L wenn jede beliebige Testfallmenge die K erf llt auch L erf llt 33 2 Grundlagen die Wahrheitswerte wahr und falsch mindestens einmal annehmen muss Ihre Fehleridentifikati onsquote ist besser als die der Anweisungs berdeckung Bal97 Trotzdem bleiben viele Fehler durch Testf lle die Zweig berdeckung erreichen unentdeckt Dies ist darauf zur ckzuf hren dass dieses Kriterium komplexe Pfade die unter anderem auch Schleifen enthalten k nnen nicht ad quat ber cksichtigt Dasselbe trifft auch f r komplexe zu sammenh ngende Bedingungen zu Um besonders komplexe Bedingungen zu berpr fen eignen sich Bedingungs berdeckungs tests Von dieser Testart gibt es mehrere Auspr gungen die zum ei
35. Dieser Ansatz beschreibt berdeckungs kriterien auf Kommunikationsdiagrammen die neben der berdeckung einzelner Messages Kri terium Each message on link oder Message Pfaden Kriterium All message paths explizit auf die berdeckung der Guards an den Messages ausgerichtet sind So z B wird das Kriterium Full predicate coverage wie folgt beschrieben Given a test set T and collaboration diagram CD T must cause each clause in every condition in CD to take the values of TRUE and FALSE while all other clauses in the predicate condition have values such that the value of the predicate will always be the same as the clause being tested Die bisher betrachteten Ans tze definieren Uberdeckungskriterien f r einzelne Interaktions diagramme und fokussieren deshalb die berdeckung einzelner Aufrufe oder Aufrufsequenzen zwischen verschiedenen Komponenten Da die interagierenden Komponenten aus verschiedenen Zust nden heraus die im Sequenz oder Kommunikationsdiagramm beschriebenen Aufrufe trig gern k nnen verlangt der Ansatz von Sok04 dass zus tzlich zu dem Sequenzdiagramm auch Zustandsautomaten benutzt werden sollen um die kommunizierenden Objekte zu initialisieren Durch unterschiedliche Initialisierung der einzelnen Objekte k nnen mehrere Testf lle aus einem einzelnen Sequenzdiagramm generiert werden Dieser Ansatz gibt aber keine expliziten Kriterien an die eine automatische Generierung von entsprechenden Testf llen erm
36. ER a A H 2 H D s UnreportDevistion ReportDevistion PartisiResultEnum TestOK PartisiResultEnum TestNotOK Bas StanMS Im PartielResultEnum TestNotPerformed AcceptDevistion UnecceptDeviation mV PartiaIResultEnum TestDevRep Exitus ImV PartislResultEnum TestDevAoc Exitus Im PartialResultEnum TestNotPerformed if MS 3 MS3Val mV if MS 4 MS4Vsl mV Abbildung A 3 Modell Liegenpr fplatz Komponente PartialResult 176 closeCabin isDoorClosed true myCabinDoorControl closeDoor openCabin myCabinDoorControl openDoor initialising setCabinFloor lt lt ExternalSt gt gt cabinUp isDoorClosed true cabinArrived myMainContro done lt lt ExternalSt gt gt travelingUp lt lt ExternalSt gt gt travelingDown cabinWp isDoorClosed false isDoorClosed true myCabinDoorControl closeDoor Control Komponente CabinControl in Modell Cab Abbildung A 4 177 done if currentFloor 1 myBaseFloorControl openFloor x if currentFloor 2 myMiddleFloorControl openFloor done if currentFloor 1 myBaseFloorControl openFloor if currentFloor 3 myTopFloorControl openFloor 5 ji read cdi Bu essen lau Lc FR processing downward CabinRequest prrocessing upward CabinRequest requestCabin cabinFloor Integer cabinFloor gt currentFloor
37. Eltern Individu en immer zwei Kind Individuen Beide erzeugten Individuen sind dann Teil der neu generierten Population Im Allgemeinen geht es bei der Rekombination darum Eigenschaften zwischen den zwei Eltern Individuen auszutauschen Dabei gibt es mehrere Teile von Individuen die durch Rekombination zwischen diesen ausgetauscht werden k nnen Die Rekombination kann also auf mehreren Ebenen stattfinden e Testf lle ganze Testf llen k nnen zwischen Individuen ausgetauscht werden e Aufrufe einzelne Aufrufe aus den Testf llen k nnen zwischen den Individuen ausgetauscht werden e Testdaten die Daten einzelner Aufrufe die Werte einzelner Parameter von Aufrufen aus dp den Testf llen der Individuen k nnen mittels dieses Operators kombiniert werden Dies funktioniert nat rlich nur f r Parameter die den gleichen Typ haben Auf welcher Ebene die Rekombination tats chlich stattfindet wird bei jeder Anwendung des Rekombinationsoperators aus diesen drei Alternativen zuf llig ausgew hlt Diese drei Alternati ven werden in Abbildung 4 4 bildlich dargestellt opA1 1104924320 ud Ap TIS 964101129423737 Hein Zen COPAS IT 0pA1 1787143425 opB4 opA5 a opasd opB4OQ 0pA1 1500943729 opB1 2050836360 OpAS opB4 opA5 op81 1555817572 opB4 OpA2 opA3Q opA4 true opA5Q opA4 true opas sO opB4 c opA1 1924151534 opB1 2076310642 opa2 opa3
38. Formel 7 1 ohne Ber cksich tigung der funktions quivalenten Mutanten d h unter der Annahme E MO 0 Die von den Testfallmengen erreichten Mutation scores werden in Tabelle Um der Spalte MS beschrieben Dar ber hinaus werden in der Spalte TC die Anzahl der Testf lle und in der Spalte UE die An zahl der durch die Testfallmenge berdeckten Entit ten angegeben Ein Teil dieser Ergebnisse wurde bereits in vorgestellt Zustands b Transitions b Transitionspaar b ZM AM TC UE MS TC UE MS TC UE MS Konto 12 2 8 23 48 6 19 68 8 22 58 7424 InfotainmentGui 429 4 17 33 8 16 54 70 4 48 207 78 09 Achstest 780 8 26 2397 27 83 255 1 580 272 63 97 Mittelwerte 447 4 67 17 27 08 1633 52 64 7 50 179 724 ZM Betrachteter Zustandsautomat AM Anzahl generierter Mutanten TC Anzahl generierter Testf lle UE Anzahl berdeckter Entit ten Zust nde Transitionen oder Transitionspaare MS Erreichter Mutation score in Tabelle 7 1 Ergebnisse der Mutationsanalyse f r Komponententestf lle Um auf die einzelnen Testfallmengen leichter Bezug zu nehmen werden folgende Abk rzun gen eingef hrt bez glich des Zustandsautomaten Konto wird die Testfallmenge die alle Zu st nde berdeckt als ZK Z von Zustands berdeckung und K von Konto bezeichnet TK ist die Testfallmenge die Transitions berdeckung erf llt und 7PK ist die Testfallmenge die Transiti onspaar berdeckung erf llt Ahnliche Abk rzungen werden f r die Tes
39. IEE91 One of the parts that make up a system A component may be hardware or software and may be subdivided into other An components Note The terms module component and unit are often used interchange ably or defined to be subelements of one another in different ways depending upon the context Im weiteren Verlauf dieser Arbeit werden die Begriffe Komponente Software Komponente Modul oder Unit als synonyme Bezeichnung f r ein Softwarebaustein innerhalb eines Softwa resystems benutzt Komponenten kommunizieren miteinander ber ihre Schnittstellen Engl In terfaces welche in wie folgt definiert werden the access points of components through which a client component can request services declared in the interface and provided by another component Neben der Tatsache dass das komponentenbasierte Paradigma die Bew ltigung komplexer Softwareprojekte berhaupt erm glicht bringt es weitere bedeutende Vorteile mit sich Durch Benutzung von Komponenten Off the shelf oder firmenintern entwickelt die sich bereits im Betrieb bew hrt haben wird die Verl sslichkeit des Systems erh ht Ein weiterer Vorteil ist dass die Architektur einer aus mehreren kommunizierenden Komponenten zusammengesetzten Software meist klar und bersichtlich ist Damit die Vorteile dieses Paradigmas voll zum Tragen kommen m ssen die einzelnen Kom ponenten und deren Abh ngigkeiten bestimmte Anforderungen erf llen Diese Anforderungen
40. Ist der Reiter Ein Testfall ist finalisiert wenn er komplette Pfade vom Startzustand zum Endzustand durch Zustandsautomaten beschreibt 93 5 Werkzeugunterst tzung Log ausgew hlt werden w hrend der Testfallgenerierung Informationen zum Generierungsfort schritt beschrieben Diese Informationen beinhalten Angaben zu den bisher generierten Popula tionen und den besten darin enthaltenen Individuen Der Reiter Validation beschreibt Probleme im geladenen Modell Ein Beispiel f r solch ein Problem ist dass im TestContext keine Variable definiert ist die den Stereotyp SUT hat Des Weiteren werden auch Probleme in den einzelnen Automaten aufgezeigt z B wenn sich ein Guard auf Variablen bezieht die nicht definiert sind Die Hauptfunktionalit ten des Werkzeugs werden ber das Men aufgerufen Der Men punkt File stellt Funktionalit ten zum Laden Entladen des Modells und zum Speichern oder L schen der generierten Testsuites zu Verf gung Der Men punkt Optimization erlaubt es einen neuen Generierungsvorgang zu starten Das Starten der Generierung erlaubt zun chst das Ausw hlen eines TestContext siehe Abbildung 5 1 abh ngig von dem ausgew hlten TestContext werden danach Komponenten oder Integrati onstestf lle generiert Vor dem Start der Generierung kann der Konfigurationsdialog aufgerufen werden der es erm glicht diverse f r die Generierung wichtige Einstellungen zu ndern Zu diesen Einstellungen z hlen
41. Mutationen er 4Eine Mutationsklasse beinhaltet alle Mutationen die von Modell Mutationsoperatoren einer bestimmten Klasse erzeugt wurden So z B beinhaltet die Mutationsklasse Trigger Mutationen alle Mutanten die durch Modell Mutationsoperatoren der Klasse Trigger Operatoren erzeugt wurden 143 7 Evaluierung des Fehlererkennungspotentials modellbasierter Testf lle reicht die Testfallmenge ZI gute Ergebnisse da sie 75 51 der Mutanten dieser Klasse erkennt Bez glich Effect Mutationen schneidet ZI auch auf diesem Modell sehr schlecht ab da nur 1 1 der generierten Effect Mutanten erkannt werden Die Testfallmengen TI und TPI schnei den bez glich drei der sieben Klassen gleich gut ab Post state und Zustand Mutationen wer den zu 100 erkannt Pre state Mutationen zu 98 Bez glich der Klasse Trigger und Guard Mutationen schneidet TPI etwas besser ab als TI TPI erkennt 3 63 mehr Trigger und 10 2 mehr Guard Mutanten hnlich wie auf dem Modell Konto werden durch TPI fast doppelt so viele Effect Mutanten im Vergleich zu TI erkannt Bez glich Transition Mutationen schneiden sowohl TPI als auch TI schlecht ab 49 43 E Transitionspaar berdeckung InfotainmentGui TP E Transitions berdeckung InfotainmentGui TI m Zustands berdeckung InfotainmentGui ZI Abbildung 7 4 Fehlererkennungspotential bzgl einzelner Mutationsklassen von Testfallmen gen die Komponententestkriterie
42. Transitionen tB3 und tB4 deren Trigger gleich dem Effect von tA6 ist Zwischen diesen zwei Komponenten gibt es also zwei Mappings ml tA6 tB4 und m2 tA6 tB3 Komponente A Komponente B AO i A4 s TT 1B7 1B5 opA20 x 5 opA3 b opB20 e P810 9pB30 tA3 186 z opB4 A2 tAl tB2 opB1 j int y j tB1 opAS opA4 j bodlean j true e 183 opB20 y lt 0 A3 BO Abbildung 3 2 Beispiel f r ein Modell mit zwei interagierenden Komponenten aus PSO08 Ein Mapping m t t wird durch einen Testfall berdeckt wenn bei der Ausf hrung des Testfalls zu einem bestimmten Zeitpunkt die aufrufende Transition t durchlaufen wird was dazu f hrt dass Komponente k m aufgerufen wird Des Weiteren muss gelten dass der Aufruf der Komponente K m dazu f hrt dass die aufgerufene Transition durchlaufen wird und zwar direkt nach dem durchlaufen wurde Falls solch ein Testfall nicht konstruiert werden kann ist das Mapping nicht ausf hrbar Neben dem Mapping Konzept spielt auch das Konzept der Mapping Gruppe eine wichtige Rolle Diese ist eine Menge von zueinander alternativen Mappings Eine Mapping Gruppe zu berdecken bedeutet zumindest ein Mapping dieser Gruppe zu berdecken Falls eine Mapping Gruppe ausschlieflich aus nicht ausf hrbaren Mappings besteht dann ist sie nicht ausf hrbar PD h dass zwischen dem Durchlaufen von und d keine a
43. V e t EVAc O die im e t referenzierten Variablen werden ge ndert F r jede Variable wird untersucht ob die Komponente deren Verhalten durch den Zustandsautomat be schrieben wird Variablen enth lt die den gleichen Typ wie die zu ndernde Variable haben Falls solche Variablen existieren dann wird eine entsprechende Variable zuf llig ausgew hlt und die zu ndernde Variable gegen die ausgew hlte Variable ausgetauscht Z B Zuweisung im initialen Modell a 0 Zuweisung im Mutant b 0 Somit k nnen durch Anwendung dieses Operators mehrere Mutanten entstehen Die Anzahl der erzeugten Mutanten h ngt davon ab wie viele Variablen im Effect referenziert werden und ob Variablen vorhanden sind die als Ersatz in Frage kommen Aufruf Operatoren 136 Aufruf L schen B e t EAc O e t wird gel scht Aufruf Hinzuf gen B e t O der Transition t wird ein Effect hinzugef gt der zuf llig aus EAc ausgew hlt wird Aufruf ndern B e t EAc V e t EVAc 7 1 Erkennungspotential hinsichtlich Modellierungsfehler O der im Effect vorhandene Aufruf einer Komponente wird durch einen anderen Aufruf derselben Komponente ersetzt Generische Effect Operatoren Generischen Effect L schen B e t EVAc O e t wird gel scht Generischen Effect Hinzuf gen B e t O der Transition wird ein Effect hinzugef gt der zuf llig aus EVAc ausgew hlt wird Pre state Oper
44. Verf gbarkeit vieler UML Modellierungswerkzeuge stellt einen weiteren Grund f r die gro e Verbreitung dieser Sprache dar Diverse Werkzeuge wie z B MagicDraw oder Enterpri se Architect bieten graphische Editoren die die Modellierung sehr gut unterst tzen Zus tzlich stellen diese Werkzeuge Funktionalit ten zur Verf gung die f r die modellgetriebene Entwick lung sehr wichtig sind wie z B automatische Codegenerierung Die geschichtliche Entwicklung der UML wird in BRJ06 beschrieben Durch die Anfang Thttp www magicdraw com http www sparxsystems de 11 2 Grundlagen der 90er Jahre immer st rker aufkommende objektorientierte Softwareentwicklung entstand auch ein Bedarf an geeigneten Modellierungsmethoden und Sprachen Somit entstanden viele Metho denvorschl ge unter anderem Object Oriented Analysis and Design von Grady Booch Object Modeling Technique von Jim Rumbaugh und Object Oriented Software Engineering von Ivar Jacobsen Diese Vorschl ge setzten sich nicht durch was letztendlich dazu f hrte dass sich die genannten Autoren Mitte der 90er Jahre der Definition einer Standardmodellierungssprache wid meten Dabei entstand die UML Version 0 9 die 1996 ver ffentlicht wurde Die darauf folgende Version 1 0 wurde bei der Object Management Group Kurz OMG zur Standardisierung ein gereicht Daraufhin wurde eine berarbeitete Version der UML Version 1 1 von der OMG als Standardnotation f r die Analyse und
45. Zur Er zeugung solcher Mutanten wurden nicht alle Modell Mutationsoperatoren angewendet Zum einen wurden die Transition und Zustand Operatoren ausgelassen Aus der Klasse der Effect Operatoren wurden die Variablenzuweisung Operatoren nicht eingesetzt Die generierten Effect Mutanten die im Folgenden beschrieben werden unterscheiden sich also alle hinsichtlich der Aufrufe in den Effects vom initialen Modell Des Weiteren wurden die Operatoren Trigger Hin zuf gen Aufruf Hinzuf gen Generischen Effect Hinzuf gen und Guard Hinzuf gen nicht an gewendet Diese wurden weggelassen um keine neuen Mappings im Modell zu erzeugen bzw um zu vermeiden dass bestimmte Mappings die im initialen Modell ausf hrbar sind im Mutant nicht ausf hrbar sind Die Modell Mutationsoperatoren wurden nicht auf alle Transitionen der interagierenden Zu standsmaschinen angewendet sondern nur auf die Transitionen die zu Mappings geh ren Da durch entstanden deutlich weniger Mutanten als bei der Mutantengenerierung aus einzelnen Zu standsmaschinen Es wurden 72 Mutanten aus dem Modell CabinControl 94 aus dem Modell Infotainment und 263 Mutanten aus dem Modell Liegenpr fplatz erzeugt Daraufhin wurden die in Tabelle 6 6 beschriebenen Testsuites die zustandsbasierte Uberdeckungskriterien erf llen auf 6Sind Mutanten die durch den Modell Mutationsoperator Transition L schen generiert wurden 147 7 Evaluierung des Fehlererkennungspotentials modellbas
46. aa squsiMsi 5 PressConfirm MSHasStart true ChangeStep ChangeMS HilfsGuard 9 HilfsGuard 9 amp amp actualMS 5 ze actusIMS 5 SetMSPars_4_fail NextMS enge amp amp leaveStep false DevistionAllowed false MSHasContinue tue MSHasinputChis true MSHasStart true sctusIMS nextMS myPar ExitMS NextMS nextMS 2 88 lesveStep false DeviationAllowed false MSHasContinue tue MSHasinpufCtris true MSHasStart true asctuslMS nextMS Lascheda ExternalSte Achstest MS Step Init eise ImyPar InitfactualMS Step_Init Step Init para false StartMS ectusIMS 4 DevistionAllowed tue MSHasContinue true MSHasinputCtis false MSHasStart tue actusIMS 5 myPar MS4Val PartialResultEnum TestOK MS5_Selection_sil tue MS5 Selediion all AutoForward ImyPar MS1Val PartisResultEnum TestNotOK Deselect MSS_Seledi false Peer NexMS nexMS 4 amp amp leaveStep false DeviationAllowed false MSHasContinue false MSHssinputChls true MSHasStart true actualMS nexiMS myPar ExitMS en all Extemai ts ChanpeMS Microstep nicht ausf hrbar ChangeStbe Stans IMSHaslnputCils true db amp amp actualMSi 4 NeaveStep Tute false nexis acuslMS Stans IMSHaslnputCbls false amp amp actualMS 4 JDe
47. achieved with regard to considered coverage criteria and minimizing the number of test cases In addition coverage visualization and model based regression testing are also supported For the purpose of evaluating the fault detection capability both component and integration test cases are considered On the one hand mutation testing is used for evaluating to which extent such test cases allow the detection of modeling faults To do so as a first step several mutants of the model are automatically generated successively the proportion of mutants detected is determined by executing the test cases on the mutants and on the initial model On the other hand the generated test cases were compared to manually created test cases in order to evaluate their potential for detecting implementation faults ii Danksagung Diese Arbeit entstand am Lehrstuhl f r Software Engineering im Rahmen des Forschungs projekts UnITeD das vom Bayrischen Wirtschaftsministerium gef rdert wurde An dieser Stelle m chte ich mich bei Frau Prof Dr Francesca Saglietti f r die fachliche Betreuung und die M g lichkeit bedanken an ihrem Lehrstuhl diese Promotion durchzuf hren Des Weiteren m chte ich mich bei Herrn Prof Dr Fevzi Belli Herrn Prof Dr Klaus Meyer Wegener und Herrn Prof Dr Bernhard Schmauss f r die Beteiligung an meinem Promotionsverfahren bedanken Mein Dank geb hrt ebenfalls meinen Kollegen Marc Matthias Sven Raimar und meinen ehemali
48. berdeckenden En tit ten siehe Abschnitt 5 2 und die modellbasierte Regressionstestgenerierung f r den Kompo nententest siehe Abschnitt 5 3 Beschreibung modellbasierter berdeckungskriterien f r den Integrationstest Existierende Ans tze zur automatischen Generierung von Integrationstestf llen anhand von Mo dellbeschreibungen betrachten Sequenzen von Aufrufen zwischen mehreren Komponenten ohne 1 Einleitung die internen Zust nde der aufrufenden und aufgerufenen Komponenten zu ber cksichtigen Des halb werden zun chst im Rahmen dieser Arbeit in Abschnitt eine Reihe so genannter zustandsbasierter Integrationstest berdeckungskriterien beschrieben welche die internen Zu st nde der interagierenden Komponenten ber cksichtigen Da die unterschiedlichen Kriterien mit unterschiedlichem Testaufwand verbunden sind wird zu jedem einzelnen Kriterium eine Formel angegeben die es erlaubt die Anzahl der zu berdeckenden Entit ten zu bestimmen Schlie lich werden alle Kriterien in eine Subsumptionshierarchie eingeordnet Die betrachteten zustandsbasierten Kriterien wurden in eingef hrt Unterst tzung der automatischen Integrationstestgenerierung und Optimierung Neben der Komponententestgenerierung unterst tzt das vorhin erw hnte Werkzeug auch die Ge nerierung und Optimierung modellbasierter Integrationstestf lle welche zustandsbasierte Inte grationstest berdeckungskriterien erf llen Die Ergebnisse die durch Anwendung
49. bertragung der Terminologie der genetischen Algorithmen auf die Terminologie der automatischen Testfallgenerierung ergibt sich folgende Zuordnung die in Abbildung 4 2 bildlich dargestellt wird Gen Testfall Individuum Testsuite Population Menge von Testsuites Wie schon in Abschnitt 2 5 erw hnt ist ein Testfall eine Folge von Aufrufen an die zu testende Komponente n Ein Komponententestfall beinhaltet Aufrufe an eine einzige Komponente Ein Beispiel f r einen Komponententestfall f r Komponente A aus Abbildung 2 ist opA1 88742965 opA4 true opA5 6 Dagegen beinhaltet ein Integrationstestfall Aufrufe an alle interagierenden Komponenten Da bei sind die internen Aufrufe zwischen den Komponenten nicht im Integrationstestfall mit ent halten So z B kann ein Integrationstestfall f r die Komponenten A und B aus Abbildung B 2 die Die berdeckungsbestimmung dieses Komponententestfalls wird in Abschnitt 4 3 3 1 beschrieben 74 4 3 Einsatz genetischer Algorithmen zur automatischen modellbasierten Testfallgenerierung 1104924320 opB4 opas opA1 1456540800 ER OpA2 OpA3 OpA2 OpA3 opA4 true OpA5 opA1 129423737 opB4 opA2 opA3 opA4 true OpA5 u 1787143425 opB4 opA5Q Gen Testfall opA5 opB4 iG E opB1 2050836360 opAS opB4 Individuum Testsuite op opB4 SM 0pB1 1555817572 opB4 opas OpB1 1329393341 opB4 opA1 1924151534 opB1 2076310642 opA2 D opB4
50. darin enthaltenen Testf lle dargestellt Im rechten Bereich werden die Testf lle nur als Liste bersichtlich dargestellt wohingegen im linken Bereich die genauere Betrachtung einzelner Testf lle erm glicht wird Hier hat die Aus wahl eines spezifischen Testfalls zur Folge dass die einzelnen Aufrufe des Testfalls dargestellt werden W hrend der Generierung wird in diesem Fenster der Generierungsfortschritt angezeigt Durch Rechtsklick mit der Maus auf eine Testsuite im Bereich Generierte Testsuites erscheint ein Kontextmen das mehrere Funktionalit ten zur Verf gung stellt die auf eine Testsuite be zogen sind Zum einen kann der Generierungsprozess ausgehend von der ausgew hlten Testsuite weitergef hrt werden In diesem Fall wird diese Testsuite als Basis f r die Generierung der An fangspopulation genommen Dies kann dann von Interesse sein wenn die generierte Testsuite noch nicht die gew nschte berdeckung erreicht hat oder eine weitere Optimierung bez glich der Anzahl enthaltener Testf lle erw nscht ist Des Weiteren k nnen ber dieses Kontextme n Testsuites gel scht werden Dar ber hinaus bietet dieses Men die M glichkeit Visualisie rungsinformationen abzuspeichern die dann in ein Modellierungswerkzeug eingelesen werden k nnen um die Testfall berdeckung zu veranschaulichen Detailliert wird die Visualisierung in Abschnitt 5 2 beschrieben Im Bereich Log und Validierungsbereich stehen zwei Reiter zur Verf gung
51. date The testsuites belong to an older version of the model Do you want to start the regression analyzer Otherwise the testsuites will not be loaded Abbildung 5 11 Dialog Regressionsanalyse o BBD x TestSuites TestCases Ti Testsuite TestContext_A Data Test TE TestCase 3 Steps 8 ID 3 Ir TestCase 4 Steps 9 ID 4 Ti TestCase 5 Steps 7 ID 5 T TestCase 6 Steps 5 ID 6 Ti TestCase 7 Steps 9 ID 7 Ti TestCase 8 Steps 9 ID 8 Ti TestCase 9 Steps 9 ID 9 Ti TestCase 10 Steps 5 ID 10 Ti TestCase 11 Steps 9 ID 11 Ti TestCase 12 Steps 9 ID 12 Ti TestCase 13 Steps 9 ID 13 Ti TestCase 14 Steps 9 ID 14 m H n p EE psp T TestContext TestContext A SUT ui UserControl Behavior of SUT UserControl Coverage criterion Edge Coverage Reached coverage 94 4 Abbildung 5 12 Ergebnisse Regressionsanalyse Wie auch anhand der Abbildung zu erkennen ist erreicht die alte Testsuite auf dem ge n derten Zustandsautomat keine 100 ige berdeckung da sie nur 94 4 aller Transitionen ber deckt Um die nicht berdeckten Transitionen zu erreichen wurde diese Testsuite als Basis f r 6Die incomplete Testf lle werden mit rot markiert Dies sind Testf lle die keine kompletten Pfade die im An fangszustand starten und im Endzustand enden durch den Zustandsautomaten durchlaufen 106 5 3 Unterst tzung des Regressionstests die Generierung einer neuen Testsuite ben
52. der Beschreibung der umgesetzten Modell Mutationsoperatoren 7 1 2 1 Fehlerarten bei der Modellierung kommunizierender UML Zustandsautomaten Bei der Modellierung des Verhaltens kommunizierender Komponenten mittels Zustandsautoma ten k nnen Fehler an den Transitionen oder an den Zust nden auftreten Die Tatsache dass eine Transition aus Trigger Guard Effect Pre state und Post state zusammengesetzt ist und dass ein Effect sowohl Variablenzuweisungen als auch Aufrufe anderer Komponenten beinhalten kann wird bei der unten beschriebenen Klassifikation ber cksichtigt Wie schon in Abschnitt er w hnt wurden bei der Modellierung nur eine Teilmenge der f r Zustandsautomaten zul ssigen Konstrukte benutzt Daher werden hier nur Fehler beschrieben die sich auf die eingesetzten Konstrukte beziehen Diese Fehler k nnen wie folgt klassifiziert werden e Trigger Fehler Deshalb ist an keinem der Zust nde von MainControl der Stereotyp ExternalSt angebracht Der Zustandsauto mat der Komponente MainControl wird in Anhang A beschrieben 128 7 1 Erkennungspotential hinsichtlich Modellierungsfehler fehlende Trigger zus tzliche Trigger inkorrekte Trigger e Guard Fehler fehlende Guards zus tzliche Guards inkorrekte Vergleichsoperatoren in Guards z B lt statt lt inkorrekte boolesche Operatoren in Guards z B amp amp statt Bezug auf inkorrekte Variablen e Effect Fehler Variablenzu
53. der Menge Tre ICH ausgew hlt wird Trigger ndern B tr t Z O tr t wird durch einen zuf llig aus der MengeKandidatenTrigger _ ausgew hl ten Trigger ersetzt Guard Operatoren Guard L schen B g t Z t MengeTransitionenF tirGuardc O g t wird gel scht Guard Hinzuf gen B g t t MengeTransitionenF tirGuardc O der Transition t wird ein Guard hinzugef gt der zuf llig aus Gc ausgew hlt wird Vergleichsoperatoren ndern B g t t MengeTransitionenF tirGuardc O g t wird nach Elementen aus der MengeVergleichsoperatoren durchsucht Falls ein 0Dies passiert genau dann wenn im Guard und oder im Effect Parameter des Triggers referenziert werden 134 7 1 Erkennungspotential hinsichtlich Modellierungsfehler solches Element gefunden wird wird es durch ein davon verschiedenes Element das zuf llig aus der MengeVergleichsoperatoren ausgew hlt wird ersetzt Z B wird der Vergleichsoperator gt durch einen der Operatoren aus der Menge lt lt gt ausgetauscht Der Operator wird immer durch ersetzt umgekehrt gilt dies auch Boolesche Operatoren ndern B g t Z t MengeTransitionenF tirGuardc O die booleschen Operatoren im g t werden ge ndert d h amp amp wird durch ersetzt und umgekehrt Guard Variable ndern B g t t MengeTransitionenF tirGuardc O die im Guard referenzierten Variablen werden ge ndert F r jede
54. der Struktur des zu realisierenden Systems mittels Strukturdiagram men kann mittels UML Verhaltensdiagrammen die Dynamik des Systems erfasst werden Zu dieser Klasse z hlen folgende Diagramme e Use Case Diagramm oder Anwendungsfalldiagramm Engl Use Case Diagram stellt die Funktionalit t des Systems grob durch eine Menge von Anwendungsf llen dar Dabei be schreibt ein Anwendungsfall eine m gliche Benutzung des Systems Des Weiteren werden die so genannten Akteure dargestellt die mit dem System interagieren und Funktionen des Systems aufrufen Beispiele f r Akteure sind Personen oder andere Systeme e Aktivit tsdiagramm Engl Activity Diagram beschreibt die Abl ufe in einem System Dazu werden mit Knoten einzelne Aktionen des Systems assoziiert Diese Knoten werden durch gerichtete Kanten verbunden die die Reihenfolge definieren in der die einzelnen Aktionen durchgef hrt werden t Engl State Machine Diagram beschreibt die einzelnen Zust nde ei Zustandsautoma nes Systems und die berg nge zwischen ihnen Dieses Diagramm ist f r diese Arbeit sehr wichtig und wird detailliert in Abschnitt B I beschrieben Sequenzdiagramm Engl Sequence Diagram geh rt zur Klasse der Interaktionsdiagram me Sequenzdiagramme eignen sich besonders f r die Darstellung der Kooperation in Im Rahmen dieser Arbeit werden auch die Begriffe Zustandsdiagramm oder Zustandsmaschine benutzt Diese sind auch Verhaltensdiagra
55. die berdeckten Entit ten von den Simulatoren abgefragt und gespeichert Durch die Vereinigung der Menge aller Entit ten die durch mindestens einen Testfall berdeckt werden wird die Menge der Entit ten aufgebaut die von der Testsuite berdeckt werden Beispielhaft wird die berdeckungsbestimmung eines Komponententestfalls f r die Kompo nente A anhand des folgenden Testfalls beschrieben opA1 88742965 opA4 true opA5 Die Schritte die vom SimulationManager zur Bestimmung der berdeckung dieses Kompo nententestfalls durchgef hrt werden sind e Schritt 1 Instanziierung und Initialisierung des Simulators von A Komponente A ist im Zustand AJ da die Transition tA keinen Trigger besitzt und somit gleich durchlaufen wird e Schritt 2 Bearbeitung des ersten Aufrufs der Testfalls opA1 88742965 Dieser Aufruf 3Dieser Simulator unterst tzt auch Aktivit tsdiagramme diese Diagrammart wurde allerdings in den Modellen die im Rahmen dieser Arbeit betrachtet werden nicht benutzt Siehe Kapitel 80 4 3 Einsatz genetischer Algorithmen zur automatischen modellbasierten Testfallgenerierung wird an den Simulator von A geschickt Der Guard von tA3 wird zu true ausgewertet weil 88742965 gr er als 0 ist was dazu f hrt dass die Transition tA3 traversiert wird wobei der internen Variablen x der Wert 88742965 zugewiesen wird Der neue aktive Zustand von A ist A2 e Schritt 3 Bearbeitung des zweiten Aufrufs des Test
56. die Kosten f r die Behebung eines Fehlers umso geringer ausfallen je fr her der Fehler entdeckt wird Um Entwurfs Modelle zu hinterfragen gibt es mehrere Methoden unter anderem k nnen zu diesem Zweck modellbasierte Testf lle eingesetzt werden Dies sind Testf lle die anhand des Modells generiert werden und es m glichst vollst ndig berdecken Neben der berpr fung der Modelle kann mittels solcher Testf lle der Quelltext der Software dahingehend untersucht werden ob das im Modell beschrie bene Verhalten ad quat umgesetzt wird Bei dieser Vorgehensweise muss aber beachtet werden dass das Modell lediglich eine abstrakte Beschreibung des beabsichtigten Verhaltens darstellt Deshalb wird im Allgemeinen bei der Ausf hrung modellbasierter Testf lle zur berpr fung der Implementierung nur eine grobe berdeckung des Programmcodes erreicht Das bedeutet dass solche Testf lle allein nicht ausreichend sind um den Quelltext der Software gr ndlich zu berpr fen F r eine m glichst gr ndliche und kosteneffiziente Gestaltung des Testprozesses sollte dieser weitgehend automatisiert durchgef hrt werden Da die Testfallgenerierung eine der wichtigs ten und aufw ndigsten Aktivit ten im Testprozess darstellt ist vor allem die Automatisierung 1 2 Zielsetzungen dieses Schrittes von besonderem Interesse Neben der Testfallgenerierung kann auch die Test fallausf hrung eine sehr zeitintensive Aktivit t darstellen wobei besonders di
57. die generierte Testsuite alle Mappings ber deckt wurden gibt es in Abbildung 5 6 kein rot markiertes Mapping 99 5 Werkzeugunterst tzung AO A4 A ud Wat fe T 7 tA3 opA2 x lt 5 opA3 I b opB2 A1 A2 tA2 Abbildung 5 6 Zustandsautomat erg nzt um Notizen und Informationen zu den berdeckten Mappings Neben der F rbung der Notiztexte werden auch die Transitionen an denen die Notizen ange bracht sind eingef rbt Somit kann auch an der Farbe der Transition erkannt werden inwieweit Mappings zu denen diese Transition geh rt berdeckt wurden Dies ist besonders im Falle sehr informationsdichter Notiztextfelder n tzlich da die Transitionsf rbung eine anschauliche Ab straktion darstellt Die Transitionen werden wie folgt eingef rbt e Gr n wenn jede Mapping Gruppe zu der die Transition geh rt durch mindestens einen Testfall berdeckt wurde e Rot wenn nicht alle Mapping Gruppen zu der die Transition geh rt von der Testfallmenge berdeckt wurden Zus tzlich wird auch die Farbe Blau wie folgt benutzt ein blaues Mapping in einem Notiztext feld bedeutet dass dieses von einem bestimmten Testfall berdeckt wurde Dagegen bedeutet die blaue F rbung der Transition dass alle Mapping Gruppen zu der diese Transition geh rt durch den betrachteten Testfall berdeckt wurden D h dass auf jeder Zeile der Notiz an der Transi tion mindestens ein blau markiertes Mapping vorhande
58. diesen Methoden hat die Anwendung modellbasierter Testf lle den Vorteil der systematischen Abdeckung aller Modellentit ten Die Visualisierung einzelner Testf lle im Diagramm un terst tzt die Erkennung fehlerhafter berg nge oder fehlerhafter Pfade Die Anzeige der nicht berdeckten Modellelemente bietet dar ber hinaus eine Hilfestellung beim Finden von Modellfehlern die auf nicht ausf hrbare Modellteile zur ckzuf hren sind Die in der vorliegenden Arbeit betrachteten Kriterien sind auf die strukturelle berdeckung von Modellen ausgerichtet weshalb sie verlangen dass spezifische Entit ten der Modelle ber deckt werden Diese Entit ten lassen sich wie folgt in Kategorien einteilen PSN09 e Atomare Entit ten sind elementare Bestandteile des Zustandsautomaten also Zust nde und Transitionen e Zusammengesetzte Entit ten bestehen aus mehreren atomaren Entit ten Zur berdeckung solcher Entit ten reicht die berdeckung der einzelnen Bestandteile nicht aus da diese Bestandteile im Zusammenhang berdeckt werden m ssen Zu den zusammengesetzten Entit ten geh ren Transitionspaare Mappings und Mapping Gruppen Entsprechend dieser Aufteilung wird in den folgenden zwei Unterabschnitten beschrieben wie die Visualisierung atomarer und zusammengesetzter Entit ten realisiert wurde 18Siehe Abschnitt 2 4 96 5 2 Visualisierung berdeckter sowie zu berdeckender Modellelemente 5 2 1 Visualisierung
59. ein anspruchsvolleres ber deckungskriterium zu Grunde liegt berdeckt es alle Mappings die auch von K3I berdeckt wer den und zus tzlich dazu drei weitere Mappings Die von K8I berdeckten zus tzlichen Mappings sind nicht ausschlaggebend da sie keine Transitionen enthalten die nicht in den von K3I ber deckten Mappings enthalten sind Dies f hrt in diesem konkreten Fall dazu dass die erreichten Mutation scores der beiden Testfallmengen gleich sind 7 1 4 1 Vergleich der Fehlerarten In diesem Abschnitt werden die Arten der Fehler genauer beleuchtet die durch Integrationstest f lle entdeckt werden k nnen hnlich wie im Falle der Komponententestf lle wurde dazu eine Analyse bez glich jeder Mutationsklasse durchgef hrt Im Unterschied zu der Analyse aus Ab schnitt 7 1 3 werden hier f nf Mutationsklassen betrachtet da die Modell Mutationsoperatoren der Klasse Transition Operatoren und Zustand Operatoren nicht angewendet wurden Die von den Testfallmengen K1C bis K8C erreichten Ergebnisse pro Mutationsklasse werden in Abbildung 7 7 dargestellt Beim Vergleich mit den in Abbildung 7 8 und 7 9 beschriebenen Ergebnissen f llt auf dass die Mutationsklasse Guard Mutationen fehlt Der Grund daf r ist dass durch die Anwendung von Guard Operatoren auf diesem Modell keine Mutanten generiert wurden 151 7 Evaluierung des Fehlererkennungspotentials modellbasierter Testf lle B Invoking invoked transitions K8C
60. einem Ausblick 2 Grundlagen Dieses Grundlagenkapitel beschreibt zun chst wesentliche Aspekte der modellbasierten Soft wareentwicklung Abschnitt zusammen mit der weit verbreiteten Modellierungssprache UML Abschnitt 2 2 Mittels UML Diagrammen k nnen unter anderem komponentenbasier te Systeme beschrieben werden die in Abschnitt 2 3 eingef hrt werden Darauf folgend werden Software Qualit tssicherungsverfahren im Allgemeinen vorgestellt Abschnitt 2 4 gefolgt von der detaillierten Betrachtung eines der wichtigsten Repr sentanten solcher Verfahren dem Tes ten Abschnitt 2 5 Abschlie end wird eine spezielle Testart besonders fokussiert und zwar der modellbasierte Test Abschnitt D ol 2 1 Modellbasierte Softwareentwicklung Der Begriff modellbasierte Softwareentwicklung beschreibt ein Softwareentwicklungsparadig ma bei dem Modelle als zentraler Bestandteil betrachtet werden und w hrend des gesamten Softwarelebenszyklus durchg ngig verwendet werden Im Kontext dieser Arbeit ist ein Modell eine abstrakte Beschreibung eines Softwaresystems welche relevante Aspekte der Struktur bzw des Verhaltens des Systems darstellt Als Spezialisierung dieses Paradigmas betont die modellgetriebene Softwareentwicklung spe ziell den generativen Aspekt und wird in wie folgt definiert Modellgetriebene Softwa reentwicklung befasst sich mit der Automatisierung in der Softwareherstellung Dies bedeutet dass m glichst viele Artefakte eine
61. es sich um Modelle die im Zuge der modellbasier ten Softwareentwicklung w hrend der konstruktiven Entwurfsphasen entstanden sind Auf der anderen Seite kann f r die Generierung der Testf lle ein dediziertes separates Test modell erstellt werden Dieses fasst mehrere Testf lle als Modell in einer bersichtlichen Darstellung zusammen was dazu f hrt dass dieses Vorgehen besonders im Vergleich zu der manuellen Testfallerstellung viele Vorteile bietet Die Benutzung der Entwicklermodelle bei der Testfallgenerierung bietet gegen ber der Benutzung separater Testmodelle den Vorteil dass f r die Testfallgenerierung keine zu s tzlichen Modelle erstellt werden m ssen was geringere Kosten bedeutet Dar ber hinaus liefert die berdeckung der Entwicklermodelle beim Test einen Indikator daf r inwiefern die gesamte modellierte Funktionalit t berpr ft wurde Ein Kritikpunkt hinsichtlich der Benutzung der Entwicklermodelle zur Testfallgenerierung Sjehe Kapitel Siehe DS06 40 2 6 Modellbasierter Test ist es dass beim Testen eines Programmcodes der automatisch aus Entwicklermodellen generiert wurde nur die automatische Transformation von Modell in Code berpr ft wird F r Dom nen in denen die Erstellung von Code zu einem hohen Anteil automatisiert ist z B im Bereich der Codegenerierung f r die Electronic Control Units im Automotive Bereich mag diese Bef rchtung auch berechtigt sein Bei den meisten entwickelten k
62. generiert werden Der automatischen Testdatengenerierung haben sich die Arbeiten von und gewidmet indem f r statisch ermittelte Testsequenzen Daten generiert werden Der Ansatz von stellt zun chst Constraints ber die Parameter auf um daraufhin Daten zu generieren die diese Constraints erf llen Die Autoren von setzen Heuristiken ein um f r eine gegebene Test sequenz passende Testdaten zu generieren F r ausf hrbare Testsequenzen solche die sinnvolle Pfade im Automaten beschreiben unterst tzen diese Ans tze die Testdatengenerierung Proble matisch bei dieser Vorgehensweise ist dass nicht ausf hrbare Testsequenzen im Allgemeinen nicht automatisch identifiziert werden k nnen was dazu f hrt dass eine geeignete Datengene 67 4 Automatische modellbasierte Testfallgenerierung mittels genetischer Algorithmen rierung unm glich ist Im Gegensatz dazu gibt der hier beschriebene Ansatz am Ende des Generierungsprozesses nur ausf hrbare Testsequenzen zusammen mit entsprechenden Daten aus Weitere Alleinstel lungsmerkmale dieses Ansatzes sind die Betrachtung neuartiger Integrationstestkriterien und die Optimierung der Testfallmenge hinsichtlich folgender Optimierungsziele e Maximierung der berdeckung es soll eine Testsuite generiert werden die eine m g lichst hohe strukturelle berdeckung des Modells erreicht hinsichtlich klassischer ber deckungskriterien f r den Komponententest und den in Unterabschnitt 3 3 2 bes
63. genetischer Algorithmen aus SP10 71 4 Automatische modellbasierte Testfallgenerierung mittels genetischer Algorithmen te Population schlechter ist als die alte Population Um dies zu vermeiden ist die unver nderte bernahme eines Teils der fittesten Individuen der alten Population in die neue Population sinn voll Dies wird durch den so genannten Elitismusoperator realisiert der als erster angewendet wird und einen Teil der besten Individuen der alten Population in die neue Population unver n dert kopiert Selektion Die Eltern Individuen werden mit Hilfe der Selektionsoperatoren ausgesucht Grunds tzlich w h len solche Operatoren aus der aktuellen Generation die besten Individuen aus also diejenigen mit der h chsten Fitness Um aber zu vermeiden dass sich die Optimierung hin zu einem lokalen Maximum bewegt sollten Selektionsoperatoren auch Individuen ausw hlen die eine schlechte Fitness haben Aufgrund der unterschiedlichen Eigenschaften von schlechten und guten Indivi duen kann es dann vorkommen dass durch ihre Kombination ein sehr gutes Individuum entsteht Es gibt mehrere Selektionsstrategien wobei ein paar hier kurz erw hnt werden Die Best Fitness Strategie besagt dass f r die Erzeugung neuer Individuen immer die besten zwei Individuen der aktuellen Population herangezogen werden sollen Dies ist aufgrund der vorhin beschriebenen Betrachtung zu der Kombination von schlechten und guten Individuen nicht
64. gut erkennbar sind Mutanten die im Unterschied zum originalen Modell eine Transition weniger enthalten Da durch beide Operatoren auf den drei Modellen hnlich viele Mutanten erzeugt wurden und die Transition Hinzuf gen Mutanten im Gegen 5Sind Mutanten die durch den Modell Mutationsoperator Transition Hinzuf gen generiert wurden 146 7 1 Erkennungspotential hinsichtlich Modellierungsfehler satz zu den Transition L schen Mutanten nicht erkannt werden werden etwa die H lfte der Transition Mutationen erkannt Allgemein l sst sich feststellen dass das Fehlererkennungspotential von Komponententestf l len ber die Test berdeckungsma e hinaus wesentlich von der Art der injizierten Mutationen abh ngt Es ist nicht berraschend dass diejenigen Fehlerarten am ehesten erkannt wurden die an den zu berdeckenden Modellentit ten angelehnt waren etwa Trigger Fehler oder Zustand Fehler Andere Fehlerarten dagegen wie z B Effect Fehler oder Guard Fehler die nicht explizit Gegenstand der Modell berdeckung sind konnten mit geringeren H ufigkeiten aufgedeckt wer den 7 1 4 Fehlererkennungspotential der Testfallmengen f r den Integrationstest Das implementierte Mutationsmodul erm glicht auch die Untersuchung der Fehlererkennung von Testf llen die zustandsbasierten Integrationstestkriterien gen gen Dazu wurden zun chst Mutanten generiert die fehlerhafte Interaktionen zwischen Komponenten simulieren
65. lle sind so generiert dass bei der Ausf hrung der Testf lle auf dem initialen Modell die Guards der traversierten Transitionen der Zustandsautomaten zu wahr ausgewertet werden Somit haben haupts chlich die Mutanten eine Chance erkannt zu werden die im Vergleich zum initialen Modell eine strengere Guard Bedingung enthalten Dies wird z B erreicht indem der Oder Verkn pfungsoperator durch den Und Verkn pfungsoperator amp amp ersetzt wird Da dies aber im Allgemeinen nicht der Fall ist werden auch Guard Mutationen zu einem geringen Anteil erkannt Zur Erkennung solcher Mutanten k nnten sich Testfallmengen eignen die Bedingungs berdeckungskriterien auf Modellen erf llen Auch bez glich der Mutationsklasse Transition Mutationen erreicht die Transitionspaar ber deckung niedrige Mutation scores 55 17 auf Konto 49 43 auf InfotainmentGui und 43 88 auf Achstest Zu der Klasse Transition Mutationen geh ren solche Mutanten die sich von dem initialen Modell dadurch unterscheiden dass sie entweder eine Transition mehr oder eine weni ger enthalten Nicht erkennbar sind Mutanten die eine Transition mehr als das initiale Modell beinhalten eine aus dem intialen Modell generierte Testfallmenge wird die im Mutant zus tz lich vorhandene Transition nicht berdecken weil nur die Transitionen des Mutanten berdeckt werden die auch im initialen Modell vorhanden sind Das f hrt dazu dass ein solcher Mutant nicht erkannt wird Dagegen
66. opB4 1B4 tB2 opB1 j int y j ExternalSt A2 opB2 y 0 ExternalSt B2 tA4 opA1 i int i lt 0 tA7 lopAdt boolean j true e KP ExternalSt N m2 e a3 183 opB2 y lt 0 Abbildung 7 1 Beispiel fiir ein Modell mit zwei interagierenden Komponenten die externe Zu st nde enthalten Als Beispiel f r ein Komponententestfall wurde in Abschnitt 4 3 3 1 folgender Testfall f r Komponente A beschrieben opA1 88742965 opA4 true opA5 Der Pfad der bei der Abarbeitung des Testfalls durch den Zustandsautomaten von A durchlau fen wird ist folgender Pfad durch A AO A1 A2 A3 A5 126 7 1 Erkennungspotential hinsichtlich Modellierungsfehler F r die Mutationsevaluation ist allerdings nicht der ganze Pfad sondern nur der Pfad beste hend aus externen Zust nden relevant externer Pfad durch A A2 A3 Der externe Pfad stellt das nach au en sichtbare Verhalten bei der Ausf hrung eines Kompo nententestfalls dar Wenn sich also bei der Ausf hrung des Komponententestfalls auf dem Mu tant die Folge der durchlaufenen externen Zust nde von der Folge der durchlaufenen externen Zust nde auf dem initialen Modell unterscheidet wird der Mutant als erkannt markiert Im Falle der Evaluierung von Integrationstestf llen ist die Frage nach dem nach au en sicht baren Verhalten etwas komplizierter da hier
67. r die Diskussion zwischen Projektbeteiligten und zum Ver st ndnis der Dom ne Sie dienen also nicht explizit der Testfallgenerierung e modellgetriebenes Testen Modelle werden hier nicht mehr nur als Leitfaden gesehen das Ziel dieses Ansatzes ist es ausf hrbare Testf lle aus diesen Modellen zu generieren Dazu bedarf es vor allem leistungsf higer Modellierungswerkzeuge und Werkzeuge zur Testfall generierung e modellzentrisches Testen im Rahmen dieses Vorgehens wird die modellbasierte Testfall generierung nicht mehr als Einbahnstra e betrachtet zus tzlich zur Generierung von Testf llen aus Modellen sollen bei diesem Vorgehen alle relevanten Informationen aus der Testdurchf hrung in das der Testfallgenerierung zugrunde liegende Modell mit einflie en Gem dieser Klassifizierung l sst sich der in dieser Arbeit beschriebene Testfallgenerierungs ansatz der Kategorie modellgetriebenes Testen zuordnen Eine weitere Systematik MBT Ans tze zu kategorisieren wird in UPL06 vorgeschlagen zu sammengefasst wird diese Kategorisierung in Abbildung Hier werden sieben voneinander abh ngige Dimensionen mit verschiedenen Auspr gungen vorgeschlagen Diese Dimensio nen lassen sich in drei Hauptgruppen gliedern Modellierung Model Testgenerierungsmethode 150 z B hat die Auswahl eines bestimmten Modellparadigmas Paradigm entscheidenden Einfluss auf das ein setzbare Testfallgenerierungsverfahren Technology
68. sich in solchen F llen verh lt und ob die umgesetzten Ausnahmebehandlungsmechanis men korrekt funktionieren e Benutzbarkeitstest ob die Software leicht verst ndlich und intuitiv bedienbar ist soll der Benutzbarkeitstest berpr fen e Sicherheitstest ob Sicherheitsma nahmen umgesetzt wurden ist im Rahmen dieser Test art zu untersuchen Interessante Fragestellungen in diesem Fall sind z B wie die Zugriffs rechte verteilt sind ob die Passw rter verschl sselt gespeichert werden oder ob bestimmte Anforderungen an die Passw rter gestellt werden z B Passw rter m ssen eine Mindest l nge haben oder Passw rter m ssen sowohl Buchstaben als auch Zahlen enthalten e Interoperabilit tstest um die Software auf Kompatibilit t mit der geplanten Hard und Softwareumgebung zu testen muss ein Interoperabilit tstest durchgef hrt werden e Konfigurationstest falls die Software f r verschiedene Hardware Software Plattformen geeignet ist muss die Software auf allen m glichen Plattformen durch einen Konfigurati onstest berpr ft werden e Dokumentenpr fung dies ist kein Test im eigentlichen Sinne Im Rahmen dieser Aktivit t 34Tn Bal97 werden vier verschiedene Leistungstestauspr gungen beschrieben Massentest Zeittest Lasttest Stre test 28 2 5 Testen soll berpr ft werden ob die Dokumentation f r den Benutzer in Form von Bedienungs anleitungen und f r die Entwickler im Form von Entwu
69. sich um Fehler die sich bei einer vom normalen Nutzungsprofil abweichenden Benutzung der Software manifestierten Das normale Nutzungsszenario sieht dabei wie folgt aus es werden sequentiell Pr fschritte durchgef hrt Jeder Pr fschritt wird vom Benutzer gestartet nach der Durchf hrung des Schrittes wird das Ergebnis angenommen oder abgelehnt um danach den n chsten Pr fschritt zu betrachten Bei dieser rein sequentiellen Durchf hrung der Schritte ergaben sich keine Probleme Fehlerhaftes Verhalten ergab sich erst bei einer davon abweichen den Benutzung z B wenn ein bestimmter Pr fschritt w hrend der Durchf hrung abgebrochen wurde Zwei der drei Implementierungsfehler f hrten dazu dass in solchen F llen der Status der Pr f schritte nicht richtig abgespeichert wurde So muss etwa nach dem Abbruch eines Pr fschrittes dessen Status auf nicht ausgef hrt zur ckgesetzt werden was allerdings in der implementier ten Anwendung nicht passierte hier wurde der Status auf nicht bestanden gesetzt Diese zwei Fehler waren auf die inkorrekte Interaktion der Steuerungskomponente Achstest mit der Kompo nente PartialResult zur ckzuf hren Der dritte Fehler offenbarte sich beim Wechseln zwischen Pr fschritten w hrend ein bestimmter Pr fschritt gerade abgearbeitet wurde In diesem Fall soll te ein Best tigungsdialog aufkommen Da dieser Dialog nicht angezeigt wurde wich das im plementierte Verhalten allerdings davon ab Hier ha
70. verlangt Neben den kontrollflussbasierten Code berdeckungskriterien k nnen auch die in be schriebenen Bedingungs berdeckungskriterien auf Zustandsautomaten bertragen werden Sol che Kriterien sind auf die berdeckung der Bedingungen in den Guards der Transitionen ausge richtet In werden eine Reihe solcher Kriterien beschrieben So z B verlangt das Condi tion Coverage Kriterium dass jede atomare Bedingung eines Guards einmal zu true und einmal zu false ausgewertet wird Dar ber hinaus werden in dieser Arbeit neue Kriterien definiert die auf Bedingungs berdeckungskriterien aufbauen und zus tzlich die Grenzen der Wertebereiche der Variablen in den Guards betrachten Auch die in Abschnitt 2 5 2 vorgestellten Datenflusskriterien k nnen f r Zustandsautomaten angepasst werden Datenfluss wird in Zustandsautomaten wie folgt beschrieben Variablen wer den in Effects der Transitionen definiert um danach in Guards oder anderen Variablenzuweisun gen referenziert zu werden Die Arbeit von zielt auf die berdeckung der Datenfl sse in Zustandsautomaten Alle bisher beschriebenen Ans tze zielen auf die berdeckung des modellierten und somit gew nschten Verhaltens das mittels Automaten beschrieben ist Um zu berpr fen wie sich das System verh lt wenn Aufrufe ankommen die nicht dem modellierten Verhalten entsprechen wird in ein Verfahren eingef hrt das neben dem gew nschten Verhalten auch das nicht erw nschte Verhalten
71. von 100 Individuen und einer 5 igen Elitismuseinstel lung werden die Individuen der aktuellen und sortierten Population mit Index 0 bis 4 unver ndert bernommen 4 3 4 2 Selektionsoperator Um zu gew hrleisten dass haupts chlich sehr gute Individuen ausgew hlt werden schlechte Individuen aber auch eine Chance bekommen generiert der umgesetzte Operator bei jeder An 83 4 Automatische modellbasierte Testfallgenerierung mittels genetischer Algorithmen wendung zwei Zufallszahlen aus dem Intervall 1 1 Die generierten Werte werden mit der Populationsgr e multipliziert und die absoluten Betr ge dieser Zahlen gespeichert Diese zwei Zahlen stellen die Indizes der Individuen aus der aktuellen Population dar die ausgew hlt wer den Beispiel Anhand eines Experiments wird gezeigt dass die generierten Zahlen meistens sehr klein sind Es wurde ein Generierungsvorgang mit einer Populationsgr eneinstellung von 100 gestartet und f r 10000 Selektionsschritte festgehalten welche Indizes ausgew hlt wurden In jedem Selektionsschritt hat der Index einen ganzen Wert zwischen 0 und 99 weil die Populati onsgr e 100 ausgew hlt wurde Abbildung 4 3 zeigt wie oft Indizes aus bestimmten Wertebe reichen ausgew hlt wurden der Bereich 0 10 stellt die Anzahl aller Indizes dar die gr er oder gleich 0 sind und kleiner als 10 der Bereich 10 20 stellt die Anzahl aller Indizes dar die gr er oder gleich 10 sind und kleiner als
72. vor wenn man sich von der Ebene der abstrakten Spezi fikationsmodelle immer weiter in Richtung detaillierter Entwurfs Modelle bewegt Unabh ngig von der Art der nderung ist es sinnvoll bei nderung eines Modells die aus der vorherigen Version des Modells bereits generierten Testsuites weitgehend wiederzuverwenden da f r diese Testf lle das Testorakel schon definiert sein m sste F r den Fall dass vor Ausf hrung modell basierter Testf lle eine Validierung dieser Testf lle durchgef hrt werden muss k nnen durch die Wiederverwendung bereits validierter Testf lle Kosten eingespart werden Bei nderungen des Modells ist es deshalb sinnvoll bereits generierte Testfallmengen hin sichtlich ihrer Ausf hrbarkeit im ge nderten Modell zu analysieren Regressionsanalyse und gegebenenfalls neue Testf lle hinzuzuf gen Regressionstestgenerierung Neue Testf lle wer den dann ben tigt wenn neue Elemente im Modell dazukommen oder bestimmte Elemente die im alten Modell berdeckt wurden im neuen Modell nicht mehr berdeckt werden kann dann passieren wenn bestimmte Testf lle auf dem neuen Modell nicht mehr lauff hig sind Mit der Fragestellung der Regressionsanalyse befassen sich eine Reihe von Forschungsarbei ten BLSO2 und FIMNO7 Diese beschr nken sich auf die Klassifikation bestehender modellbasierter Testf lle als wieder verwendbare neu zu validierende und zu verwerfende Dar ber hinaus erm glichen die Arbeiten
73. wird f r jedes Kriterium die Anzahl der erzeugten ausf hrbaren Mapping Gruppen z B in Abbildung 6 2 links Datenreihe CabinControl MG beschrieben Dar ber hinaus wird gezeigt inwiefern die Anzahl an generierten Testf llen durch das Weiterf hren des Optimierungsprozesses minimiert werden konnte z B in Abbildung links Datenreihe CabinControl Min Das rechte Diagramm zeigt die Anzahl der generierten Teststeps vor dem zus tzlichen Optimierungsschritt z B in Abbildung 6 2 rechts Datenreihe CabinControl und danach z B in Abbildung 6 2 rechts Datenreihe CabinControl Min Bei allen betrachteten Testsuites konnte die Anzahl der Teststeps minimiert werden Dage gen konnte die Anzahl an ben tigten Testf llen nicht immer optimiert werden Abbildung zeigt dass mit zwei Ausnahmen alle Testsuites die Integrationstestkriterien auf dem Modell CabinControl erf llen hinsichtlich der Testfallanzahl optimiert wurden Auf dem komplexeren Modell Infotainment konnten mit einer Ausnahme alle Testsuites hinsichtlich Testfallanzahl mi nimiert werden wie in Abbildung 6 3 dargestellt Von den sieben Testfallmengen die anhand des Modells Liegenpr fplatz generierten wurden konnten nur zwei hinsichtlich der Testfallan zahl optimiert werden siehe Abbildung 6 4 Bi CabinControl Min 15 30 m CabinControl Min Bi CabinControl 20 4 B CabinControl 10 1 m CabinControl MG 5 4 10 7 E E m mi EN K1 K2 K3 K4 K5 K6 K7 K8 K1 K2 K3 K4 K5 K6 K
74. ziehen Alle Wartungsarten haben gemeinsam dass dabei nderungen in ein bestehendes und getes tetes System eingef gt werden Nach Durchf hrung der nderungen muss das ge nderte System erneut gepr ft werden Zum einen m ssen die ge nderten Codeteile berpr ft werden und zum anderen muss aber auch sichergestellt werden dass die nderungen keine unerw nschten Sei teneffekte haben Die hierzu eingesetzte Testmethode nennt sich Regressionstest In wird das Ziel der Regressionstestphase wie folgt beschrieben Das Ziel des Regressionstests ist nachzuweisen dass Modifikationen von Software keine unerw nschten Auswirkungen auf die Funktionalit t besitzen Im Rahmen des Regressionstests sollten idealerweise auch nach kleinsten Software nderun gen alle vorhandenen Testf lle noch einmal ausgef hrt werden Falls aufgrund bestimmter Pro jekteinschr nkungen nicht alle Testf lle ausgef hrt werden k nnen kann basierend auf den In formationen ber die durchgef hrten nderungen ein so genannter selektiver Regressionstest Engl Selective Regression Testing durchgef hrt werden Das bedeutet dass nicht alle Testf lle nach nderungen wieder ausgef hrt werden sondern nur die die dazu f hren dass ge nderte Codeteile durchlaufen werden 30 2 5 Testen 2 5 2 Testarten Um Testf lle manuell oder automatisch abzuleiten wird Zugang zu bestimmten Informationen ber die zu testende Software ben tigt Diese Informa
75. 12 Testf lle mehr als ZI wodurch 157 zus tz liche Mutanten erkannt werden Beim Vergleich der Testfallmengen TI und TPI f llt ein noch gr erer Unterschied in der Testfallanzahl auf TPI enth lt 32 Testf lle mehr als TI Dadurch entdeckt TPI 33 Mutanten mehr als TI Mit 8 Testf llen erkennt die Testsuite ZA 187 Mutanten die aus dem Zustandsautomat Achs test generiert wurden 19 Testf lle mehr enth lt die Testsuite TA erlaubt dadurch die Erkennung von 246 zus tzlichen Mutanten Die 80 Testf lle der Testsuite die Transitionspaar berdeckung zu 97 84 auf dem Zustandsautomat Achstest erreicht erlauben es 66 mehr Mutanten zu entde cken als die Testsuite f r Transitions berdeckung TA Im Durchschnitt erlaubte die Transitionspaar berdeckung die Erkennung von 72 1 der ge nerierten Mutanten gefolgt von der Transitions berdeckung die 64 7 erkannte Am schlech testen hat die Zustands berdeckung abgeschnitten die im Durchschnitt nur die Erkennung von 27 08 der generierten Mutanten erm glichte Aufgrund der Tatsache dass von den drei betrach teten Kriterien die Zustands berdeckung das schw chste und die Transitionspaar berdeckung das st rkste ist sind diese Ergebnisse nicht berraschend Die Erkl rung f r das schlechte Abschneiden der Zustands berdeckung h ngt mit dem Aufbau der Zustandsautomaten und der Art der durch dieses Kriterium geforderten berdeckung zusam men Zum einen gilt f r die Zust nde eines Zusta
76. 46 e T Tr c x t Tc tr t x die Menge aller Transitionen mit einem bestimmten Trig ger x Anhand des Triggers opAl i int wird diese Menge beispielhaft beschrieben Beispiel T Tr a opAl i int 1A3 tA4 3 1 Verhaltensbeschreibung von Komponenten mittels UML Zustandsautomaten Tr E c x tr Trc 3t Te tr t tr e t x die Menge aller Trigger von Tran sitionen mit einem Effect x Anhand des Effects b opB2 wird diese Menge beispielhaft beschrieben Beispiel Tr E a b opB2 opA3 S E c s Sc 3t Tc s pre t e t Ec die Menge der Pre states von aufrufen den Transitionen Beispiel S E 44 S E c x s Sc at Te s pre t e t x die Menge der Pre states von Tran sitionen mit einem bestimmten Effect x Anhand des Effects b opB2 wird diese Menge beispielhaft beschrieben Beispiel S E A b opB2 A4 S Tr c x s Sc 3t Te s pre t tr t x die Menge der Pre states von Tran sitionen mit einem bestimmten Trigger x Anhand des Triggers opA5 wird diese Menge beispielhaft beschrieben Beispiel S Tr 4 opA5 A1 A3 S Tr E c x s Scl3t T E c s pre t tr t x die Menge der Pre states von aufrufenden Transitionen mit einem bestimmten Trigger x Anhand des Triggers opA3 wird diese Menge beispielhaft beschrieben Beispiel S Tr E a opA3 44 S Tr E c x y
77. 7 2 Pseudocode zur generischen Beschreibung der Vorgehensweise einzelner Modell Mutationsoperatoren trachteten Zust nde alle Zust nde des Zustandsautomaten betrachteteEntit ten Sc Durch Anwendung der Operatoren auf einen einzelnen Zustandsautomaten sollen also intramodulare Fehler simuliert werden Bei Anwendung der Operatoren auf einem Modell das mehrere kom munizierende Zustandsautomaten enth lt sollen intermodulare Fehler eingef gt werden In die sem Fall betrachten die Operatoren nicht mehr alle Transitionen der Zustandsautomaten sondern nur die Transitionen die zu Mappings geh ren Die Zustand Operatoren werden in diesem Fall nicht angewendet Zur Beschreibung der Operatoren werden hier nur die Operatoren betrachtet die f r Transitio nen definiert sind Die Definition der Operatoren auf Zust nde erfolgt analog Diese gehen wie folgt vor erstens wird f r jede Transition berpr ft ob die Bedingung f r das Erzeugen eines Mutanten anhand dieser Transition erf llt ist in Abbildung 7 2 bedingungErf llt t Falls dies nicht der Fall ist wird die Transition nicht weiter betrachtet und es wird zur n chsten bergegan gen Falls die Bedingung erf llt ist wird der Operator eine Menge von Mutanten erzeugen Die Diese Bedingung ist operatorenspezifisch pro Operator wird die dazugeh rige Bedingung bei der Beschreibung des Operators angegeben 131 7 Evaluierung des Fehlererkennungspotentials modellbasie
78. 7 K8 0 0 Abbildung 6 2 Ergebnisse der Integrationstestgenerierung anhand des Modells CabinControl K1 K8 siehe Tabelle 6 5 links Optimierung Testfallanzahl rechts Optimierung Teststepanzahl Auch im Falle der Integrationstestf lle macht eine nachfolgende Optimierung also durchaus Sinn Wie auch im Falle der Komponententestkriterien konnte nicht immer die Anzahl der Test f lle minimiert werden daf r aber die Anzahl der Teststeps 120 6 4 Ergebnisse der Testfallgenerierung f r den Integrationstest E Infotainment Min s i m Infotainment Min E Infotainment E infotainment d E Infotainment MG Fi K4 K5 K K3 K4 K5 K6 K7 K8 Abbildung 6 3 Ergebnisse der Integrationstestgenerierung anhand des Modells Infotainment K1 K8 siehe Tabelle 6 5 links Optimierung Testfallanzahl rechts Optimierung Teststepanzahl 70 4 600 60 1 i 500 50 400 4 E Liegenprifplatz Min E Liegenpr fplatz 300 Bi Liegenpr fplatz Min 3 5 e E Liegenpr fplatz MG E Liegenpr fplatz 20 1H u 5 200 u Ir i rra nu Ki K2 G K KS K6 K KB REESE T T K1 K2 K3 K4 K5 K6 K7 K8 Abbildung 6 4 Ergebnisse der Integrationstestgenerierung anhand des Modells Liegenpr fplatz K1 K8 siehe Tabelle 6 5 links Optimierung Testfallanzahl rechts Optimierung Teststepanzahl o o o
79. 8 Ok Coverage criterion Edge Coverage play E Properti SCH pause u45 externalEndCall Reached coverage 100 0 Properties numberinpe 27 Play STeststeps m tesa TEE e checkingCD u46 stop Average TestSteps 8 42 noCDinUnit wet Reeg Reached finalization 54 0 ll L m Number of Testcase 12 Creation Date 2011 09 30 16 02 13 Testscript Generation Exp Overview Paths and Data Population Distribution Missina El EJ Log amp Validation Sat GB ER Number of elements to cover 54 Number of covered elements 54 e 2011 09 30 16 04 08 510 INFO Total Time 0 hour 1 min 54 sec Abbildung B 12 Generierung Testskripte UN UnITeD Testgenerator C Users pinte Desktop Infotainment Infotainmentuml FlemOptimbatiommVestScriptenm Mutation Optimo Winton elm tory Current Population E NN UNE ap Packagelmpol UnITeD Test Suite Mutation Analyser S eProfileApplica Generated mutants Start mut analysis D ProfileApplic Ze ProfileAppli MUTANTS_TREE_DATA_INFO_NO_DATA ali i ProfileApplici EE Results of the mutation analysis 55 ProfileApplic lu Number of generated mutants Number of killed mutants Number of alive mutanst Nr of Testsuite to be analyzed B 2011 09 30 16 04 08 510 INFO Total Time 0 hour 1 min 54 sec 2011 09 30 16 06 26 150 INFO Generation of code from testcases started
80. A3 externer Pfad durch B im Modell JM und im Mutant MutIM B2 B3 8Solch ein Mutant kann durch den Operator Aufruf L schen erzeugt werden 150 7 1 Erkennungspotential hinsichtlich Modellierungsfehler Nun zur ck zur Erkl rung weshalb K4C besser Abschneidet als K5C Dazu wurde die Er kennbarkeit dieser zwei Testsuites bez glich einzelner Mutationsklassen genauer betrachtet Da bei stellte sich heraus dass bez glich der Mutanten die durch den Operator Aufruf L schen erzeugt wurden K4C besser abschneidet als K5C da sie zus tzlich zu den von KSC erkannten Mutanten noch einen Mutanten M erkennt Beide Testfallmengen berdecken die Transition f an der sich der Mutant M vom initialen Modell unterscheidet Dass K5C diesen Mutanten nicht erkennt kommt daher da K5C einen Testfall enth lt der neben der Transition 7 zus tzliche Tran sitionen berdeckt die denselben Aufruf wie t an die aufgerufene Komponente enthalten Somit wird das Fehlen des Aufrufs an der Transition t verdeckt also eine hnliche Situation wie beim vorhin beschriebenen Testfall T2 was dazu f hrt dass bei der Ausf hrung dieses Testfalls aus K5C auf dem initialen Modell und auf dem Mutanten derselbe externe Pfad in der aufgerufenen Komponente durchlaufen wird Somit entdeckt K5C diesen Mutanten nicht Ein weiteres unerwartetes Ergebnis ist dass die Testfallmenge K3I den gleichen Mutation score erreicht wie die Testfallmenge K8I Da der Testfallmenge K l
81. Abbildung B 10 Anzeige der generierten Testsuite UN UnlTeD Testgenerator CAUsers pinte Desktop Infotainment Infotainmentumd e E File Optimization Test Scripts Mutation Options Window Help m 5 Model e u2TP O E Testsuites u E Data O i955 x E Comment TestSuites TestCases DZ Packagelmport Ba Test Case 2 Steps 8 Paths through UserControl Testsuite TestCor Ti TestCase 1 va Packagelmport Reg en TI M EI System 4 Errors in c ama N TestCase 2 8 E TestSystem Data for selected Path Ti TestCase 35 E auxiliaryResource Trigger Valuel Ti TestCase 4 oe ProfileApplications dPlayingSti 2 navigation I 2 ProfileApplications Communica 4 ez Im um a ProfileApplications waitingForTE e 7 rege TestContext TestContext_ A Di ProfileApplications showCallnfi A4 pem SUT i UserControl D eProfileApplications writeMessaq Jii omingCall Behavior of SUT UserControl u38 Ok Coverage criterion Edge Coverage u45 externalEndCall Reached coverage 100 0 E Properties pause deoa S ul7 play STestSteps 101 Properties numbernpu ere SE Cl checkingCD p See noCDinUnit 16 incomingCall Reached finalization 54 0 4 EA Number of Testcase 12 Creation Date 2011 09 30 16 02 13
82. Anwendun gen werden aus Klassen Objekte erzeugt Dieses Diagramm erlaubt die Darstellung der w hrend der Laufzeit existierenden Objekte mit ihren Links und Attributwerten Somit wird ein so genannter Schnappschuss eines Systems zu einem bestimmten Zeitpunkt dar gestellt e Kompositionsstrukturdiagramm Engl Composite Structure Diagram erlaubt die Darstel Ist eine Ansammlung von Modellelementen z B Klassen wobei innerhalb dieser Strukturierungseinheit der Name der Elemente eindeutig sein muss Ist eine Instanz einer Assoziation 13 2 Grundlagen lung der internen Struktur eines Classifiers sowie der Beziehungen mit anderen interagie renden Systembestandteilen Dabei ist ein Classifier eine abstrakte Metaklasse die eine ganze Gruppe von Modellelementen repr sentiert die gleiche Eigenschaften haben Zu diesen Elementen geh ren z B Klasse Aktivit t Assoziation Komponentendiagramm Engl Component Diagram erm glicht es die Struktur des Sys tems als Menge von Komponenten darzustellen Der Fokus liegt dabei nicht auf der Be schreibung der inneren Funktionsweise oder dem strukturellem Aufbau der Komponente sondern auf den Beziehungen zwischen mehreren Komponenten des Systems Verteilungsdiagramm Engl Deployment Diagram stellt die Zuordnung von Software artefakten auf die Ziel Hardware dar Somit wird die Softwaresicht um die ben tigten Hardware Komponenten vervollst ndigt Neben der Beschreibung
83. Automatische Optimierung und Evaluierung modellbasierter Testf lle f r den Komponenten und Integrationstest Der Technischen Fakult t der Universit t Erlangen N rnberg zur Erlangung des Grades DOKTOR INGENIEUR vorgelegt von Florin Avram Pinte Erlangen 2012 Als Dissertation genehmigt von der Technischen Fakult t der Universit t Erlangen N rnberg Tag der Einreichung Tag der Promotion Dekan Berichterstatter 28 11 2011 27 04 2012 Prof Dr Marion Merklein Prof Dr Francesca Saglietti Prof Dr Fevzi Belli Kurzfassung In Rahmen dieser Arbeit wird ein werkzeuggest tztes Verfahren vorgestellt das zum einen die automatische Testfallgenerierung anhand von UML Modellen erm glicht und zum anderen die generierten Testfallmengen hinsichtlich ihres Fehlererkennungspotentials zu bewerten erlaubt Das Testfallgenerierungsverfahren unterst tzt den modellbasierten Komponenten und Inte grationstest Zu den betrachteten berdeckungskriterien z hlen sowohl etablierte berdeckungs kriterien f r den Komponententest als auch eine Reihe so genannter zustandsbasierter Integra tionstestkriterien Durch Benutzung genetischer Algorithmen erm glicht das entwickelte Werk zeug optimierte Testfallmengen automatisch zu generieren die nicht nur eine hohe berdeckung bez glich der betrachteten Kriterien erreichen sondern auch eine m glichst geringe Anzahl an Testf llen enthalten Des Weiteren unterst tzt d
84. Cont A amp gg ren ES MiddleFloorControl EA TopFloorContro E BaseF E mm v4 ML E MagicDraw UML Personal Edition 15 5 Cabir tro Datei Bearbeiten Ansicht Layout Diagramme Optionen Hilfsmittel Analysiere Fenster Hilfe ERBE Bee BinControl E d m ET I Containment Baum El restcase 2 incomplete Ei c Ea estcase 3 incomplete tcase 4 incompl ate machine CabinControl Sy CabinControl 5 6 Data 56 Abbildung 5 8 Toolbar von MagicDraw Dar ber hinaus k nnen in der Dropdown Liste Testfall spezifische Testf lle dieser Testsuite ausgew hlt werden In der Dropdown Liste Kriterium k nnen spezifische berdeckungskriteri en ausgew hlt werden F r die ganze Testsuite oder einen ausgew hlten Testfall wird dann die berdeckung bez glich des ausgew hlten Kriteriums angezeigt 21 Siehe Abschnitt 5 1 101 5 Werkzeugunterst tzung 5 3 Unterst tzung des Regressionstests Im Rahmen einer modellbasierten Softwareentwicklung sind Modelle die zentralen Entwick lungsartefakte und werden dementsprechend auch oft berarbeitet Bei den dabei eingef gten nderungen handelt es sich entweder um Korrekturen an vorhandenen Modellen oder um Er weiterungen und oder Verfeinerungen der Modelle Korrekturbedarf entsteht dann wenn w h rend der statischen Reviews oder der dynamischen Simulation von Modellen Fehler aufgedeckt werden Verfeinerungen kommen dann
85. Die Abbruchbedingungen der lokalen Optimierung wurden in Abschnitt beschrieben 88 5 Werkzeugunterst tzung Dieses Kapitel beschreibt das implementierte Werkzeug das mittels der im vorigen Kapitel be schriebenen genetischen Algorithmen Testf lle vollautomatisch erzeugt In Abschnitt 5 1 wird der Aufbau der graphischen Benutzeroberfl che des Werkzeugs zusammen mit den dadurch zur Verf gung gestellten Funktionalit ten beschrieben Anschlie end werden in den darauf folgen den Abschnitten weitere n tzliche Funktionalit ten des Werkzeugs vorgestellt und zwar die Vi sualisierung der erreichten Modell berdeckung Abschnitt 5 2 und die Regressionstestgenerie rung Abschnitt 5 3 Eine weitere wichtige Funktionalit t des Werkzeugs ist die Unterst tzung des Modell Mutationstests Diese wird allerdings erst in Kapitel 7 vorgestellt 5 1 Das Werkzeug UnITeD Das Werkzeug namens UnITeD wurde in der Programmiersprache Java umgesetzt und erlaubt die vollautomatische Testfallgenerierung Testsequenzen inklusive zugeh riger Testdaten von modellbasierten Komponenten und Integrationstestf llen Bei der Entwicklung kam dabei die Open Source Softwareentwicklungsplattform Eclipse zum Einsatz F r die Versionsverwaltung der entstehenden Implementierungsartefakte wurde das Open Source Eclipse Plugin Subversi on benutzt Die Bedienung dieses Werkzeugs wird in Anhang B beschrieben Das Werkzeug UnITeD kann mit Modellen umgehen die mittel
86. Effect der Transition t bezeichnet ein Verhalten das beim Durchlaufen von t durchgef hrt wird e t bezeichnet das Fehlen eines Effects an einer Transition Das im Effect beschrie bene Verhalten kann beinhalten SOPO7 e Variablen nderung Variablen die im Kontext der aktuellen Komponente sichtbar sind k nnen im Rahmen einer Zuweisung ver ndert werden Dabei k nnen die Wer te der Parameter des Triggers oder die Attribute der umschlie enden Komponente referenziert werden Beispiel f r eine solche Zuweisung ist x i der Transition tA3 In diesem Fall wird der Variable x der Wert des Parameters i zugewiesen Sei EVe e t t Tc e t besteht nur aus Variablenzuweisungen die Menge aller Effects einer Komponente C die nur aus Variablenzuweisungen bestehen e Aufrufe anderer Komponenten Neben der Variablen nderung kann das Verhalten auch Aufrufe anderer Komponenten beinhalten So z B ist an der Transition tA6 im Effect ein Aufruf der Komponente B modelliert Sei EAc e t t Tc e t besteht nur aus Aufruf en anderer Komponenten die Menge aller Effects einer Komponente C die nur aus Aufrufen anderer Komponenten bestehen 47 3 Modellbasierte Uberdeckungskriterien Sei EVAc e t t Tc e t beinhaltet mindestens eine Variablenzuweisung und mindestens einen Au f ruf einer anderen Komponente die Menge aller Effects einer Kom ponente C die sowohl Variablenzuweisungen als auch Aufrufe
87. Florin Pinte Francesca Saglietti and Achim Neubauer Visualisierung berdeck ter sowie zu berdeckender Modellelemente im modellbasierten Test In Stefan Fischer Eric Maehle and R diger Reischuk editors Informatik 2009 Im Fokus das Leben volume P 154 of Lecture Notes in Informatics page 358 Bonn 2009 K llen Druck Verlag GmbH 165 LITERATURVERZEICHNIS PSO08 PUA06 RBGW10 RHQ 07 RJBPOS5 RKS05 RW85 Sch05 Sch06 S h10 166 Florin Pinte Francesca Saglietti and Norbert Oster Automatic Generation of Op timized Integration Test Data by Genetic Algorithms In Walid Maalej and Bernd Bruegge editors Software Engineering 2008 Workshopband volume P 122 of Lecture Notes in Informatics LNI pages 415 422 Gesellschaft f r Informatik February 2008 Workshop proceedings of the International Conference on Soft ware Engineering 2008 SE 2008 O Pilskalns G Uyan and A Andrews Regression Testing UML Designs In Proc of 22nd IEEE International Conference on Software Maintenance pages 254 264 Sept 2006 T Ro ner C Brandes H G tz and M Winter Basiswissen Modellbasierter Test dpunkt verlag 2010 Chris Rupp J rgen Hahn Stefan Queins Mario Jeckle and Barbara Zengler UML 2 glasklar Praxiswissen f r die UML Modellierung und Zertifizierung Hanser Fachbuchverlag Auflage 2 2007 M Rehman F Jabeen A Bertolino and A Polini Software Component Integ
88. Gui 4 30 17 16 124 54 48 662 207 Achstest 8 80 26 27 284 83 80 1284 272 Mittelwerte 4 67 38 7 17 16 33 148 67 52 50 699 179 ZM Betrachteter Zustandsautomat TC Anzahl generierter Testf lle TS Anzahl generierter Teststeps UE Anzahl berdeckter Entit ten Zust nde Transitionen oder Transitionspaare Tabelle 6 3 Ergebnisse der Komponententestgenerierung und denen f r Transitions berdeckung Erfahrungsgem ben tigt das Werkzeug UnITeD f r die Generierung von Testfallmengen f r den Komponententest aus den in Abschnitt 6 I beschriebenen Modellen meistens nur einige Minuten F r die Generierung der Testfallmenge die Transitionspaar berdeckung auf Infotain mentGui erreicht wurden allerdings mehrere Stunden ben tigt Allein im Falle der sehr schwie rig zu erreichenden Transitionspaar berdeckung auf dem Zustandsautomaten Achstest konnte selbst nach mehreren Tagen keine 100 ige berdeckung erreicht werden In diesem Fall wurde die Generierung manuell durch den Benutzer abgebrochen Um zu berpr fen ob die generierten Testfallmengen weiter optimiert werden k nnen wur de ausgehend von jeder der neun Testfallmengen die in Tabelle 6 3 beschrieben sind ein neuer Generierungsvorgang gestartet und nach 200 Generationen angehalten Dabei wurde im Rahmen Die Testfallgenerierung wurde auf einem Rechner mit Intel Core 2 Quad Prozessor 2 66GHz durchgef hrt Der Rechner verf gt ber 4GB Arbeitsspeicher das da
89. Kontextmen der generierten Testsuite siehe k nnen weitere Funktionalit ten aufgerufen werden So z B kann die Weiterf hrung des Generierungsvorgangs ausgehend von der bereits generierten Testsuite Continue Global Optimization oder das Speichern der Visua lisierungsinformationen der Testsuite Save Visualisation Data ausgew hlt werden Falls der Generierungsvorgang fortgesetzt wird werden so lange Testf lle generiert bis die ausgew hlte Abbruchbedingung erf llt ist oder die Generierung wieder mittels des Cancel Ope ration Buttons unterbrochen wird Dann wird die generierte Testsuite erneut angezeigt siehe B 10 Durch anklicken eines bestimmten Testfalls wird dieser detailliert dargestellt siehe B 1 1 Neben der Veranschaulichung der generierten Testf lle k nnen die Testf lle in verschiedene 183 B Werkzeug UnITeD Formate exportiert werden Dies kann ber den Men punkt Testscripts siehe B 12 realisiert werden Des Weiteren kann f r eine Testsuite eine Mutationsanalyse durchgef hrt werden Dies wird ber einen Dialog siehe B 13 erm glicht der mittels des Men punkts Mutation aufgerufen wird UN UnITeD Testgenerator File Optimization Test Scripts Mutation Options Window Help Ber Model Sum 8 DP Testsuites No Model Loaded EI Or i Ei 3 F TestSuites TestCases TestContext SUT Behavior of SUT Test components Behaviors of test con E3 Properties Covera
90. MSZVal ParisIResultEnum TestNotOK MSHasContinue true myPar MS3Val PartialResultEnum TestOK MSHasinputCtris true myPar MS4Val PartialResultEnum TestDevRep MSHasStart true myPar MS4bVal PartialResultEnum TestDevRep adualMS 2 FirstExeoution false ExternalSt ExternalSte Achstest MS Laschet Achstest MS Lasche2 FirtExeoution StartAchstest2_4bNOK ImyPar MS1Val PartisiResultEnum TestOK myPar MS2Val PartislResultEnum TestOK Step myPar MS3Val PartislResultEnum TestOK Step Init Initial myPar MS4Val PartialResultEnum TestOK ba myPer MS4bVal PartialResultEnum TestOK myPar Init actuaiMS PartialResult num TestNotOK Step Init myPar Init actualMS FirstExecution false TestOK FirstExecution myPar InitiactuslMS false AutoFonward ImyPar LoadPersistedValues PressConfirm AutoForward DevistionExists false IDeviationExistscetrue amp amp actusIMS 4 actualem myPar WaitForDeviationConfirm ReportDeviation DevistionConfirmDone false DevistionConfirmDone ciue myPar ReporiDeviation AcceptDevistion DevistionConfirmDone true DevistionNumberExists ES myPar AcceptDeviation UnscceptDeviation Devistionhumber xists true DeviatiorNumberExists veier myPar UnacceptDeviation gt UnreportDevistion DevistionConfirmDone true DevistionConfirmDone false myPar UnreportDeviation ChangeMS HilfsGuard 9
91. Pfade durch alle interagierenden Komponenten be trachtet werden m ssen Zur Illustration dieses Konzepts sei der Integrationstestfall opA1 4 opB1 69171531 opA2 opA3 Bei Abarbeitung dieses Testfalls werden folgende Pfade durch die Zustandsautomaten aus Abbildung 7 I beschrieben Pfad durch A AO Al A2 A4 A2 Pfad durch B BO B1 B2 B3 Durch Fokussierung auf die externen Zust nde ergeben sich folgende externe Pfade externer Pfad durch A A2 A4 A2 externer Pfad durch B B2 B3 Das nach au en sichtbare Verhalten bei der Ausf hrung eines Integrationstestfalls ist also eine Menge von externen Pfaden Bei der berpr fung ob ein Integrationstestfall einen bestimmten Mutanten erkennt werden pro Komponente die externen Pfade auf dem initialen Modell und auf dem Mutanten betrachtet Falls f r mindestens eine Komponente gilt dass sich der externe Pfad auf dem initialen Modell und auf dem Mutanten unterscheidet dann wird der Mutant als erkannt markiert Beispiel Anschaulich wird das Konzept der externen Zust nde vor allem bei Betrachtung des Modells CabinControl das in Abschnitt 6 1 beschrieben wurde Hier interagieren die Stock werk Steuerungskomponenten mit der MainControl die wiederrum mit der Kabinensteuerung CabinControl interagiert Die Komponente MainControl l uft also im Hintergrund und ist f r die Koordination der Stockwerk Steuerungskomponenten mit der Kabinensteuerung verantwort 127 7 Evalui
92. RGE 98 5 3 Unterst tzung des Regressionstests 2 2222 ll 102 108 6 1 Evaluierte Anwendungen A 108 a 111 6 3 Ergebnisse der Testfallgenerierung f r den Komponententest 113 6 4 Ergebnisse der Testfallgenerierung f r den Integrationstest 116 7 Evaluierung des Fehlererkennungspotentials modellbasierter Testf lle 122 7 Erkennungspotential hinsichtlich Modellierungsfehler 122 KANN Mottionsiest 2 3 wen we eo a aok Soke Se 71 gs Hodes Yow ge Beet oe 123 7 1 2 Modell Mutationstest 2 lens 124 7 1 2 1 Fehlerarten bei der Modellierung kommunizierender UML EECH Dee 128 7 1 2 2 Modell Mutationsoperatoren 130 130 7 1 3 1 Vergleich der Fehlerarten 2 222202200 143 oM 7 1 4 1 Vergleich der Fehlerarten 151 EE es 155 vi 8 Zusammenfassung und Ausblick 158 161 169 173 174 183 191 vii 1 Einleitung Heutzutage gibt es kaum noch Lebensbereiche die ohne Unterst tzung durch Softwaresysteme auskommen Dies f hrt unter anderem dazu dass Softwaresysteme immer h heren Qualit tsan forderungen gen gen m ssen Besonders in sicherheitskritischen Bereichen wie z B der Medi zin oder der Luftfahrt muss die eingesetzte Software verl sslich funktionieren Dar ber hinaus werden Softwaresysteme immer komplexer wobei gleichzeitig ein immer h herer Zeit und Kos tendruck vorherrschen All diese Aspekte f
93. Schritt zuf llig entschieden welche konkrete Aus 86 4 3 Einsatz genetischer Algorithmen zur automatischen modellbasierten Testfallgenerierung pr gung des Operators zum Einsatz kommt 4 3 4 4 Mutationsoperatoren Nachdem durch Rekombination zwei neue Individuen entstanden sind wird jedes Individuum mit einer vor dem Start der Generierung festgelegten Wahrscheinlichkeit mutiert Dar ber hin aus beschreibt ein zus tzlicher Parameter die Mutationsvarianz wie stark die durchgef hrten nderungen sein d rfen hnlich wie die Rekombinationsoperatoren k nnen auch die Mutationsoperatoren auf ver schiedene Eigenschaften der Individuen angewendet werden Auf welcher Ebene die Mutation stattfindet wird vor jeder Mutation zuf llig entschieden dabei gibt es drei M glichkeiten e Testf lle Bei Anwendung dieser Mutationsart werden dem Individuum neue Testf lle hin zugef gt oder bestehende Testf lle gel scht wobei zuf llig entschieden wird ob hinzu gef gt oder gel scht werden soll Wie viele Testf lle gel scht oder hinzugef gt werden h ngt von der Mutationsvarianz ab es handelt sich aber immer um mindestens einen Test fall e Aufrufe Analog geht der Operator auf Ebene der Aufrufe vor mit dem Unterschied dass nun nicht ganze Testf lle hinzugef gt oder gel scht werden sondern nur einzelne Aufrufe e Testdaten Da f r einen bestehenden Aufruf nicht einfach Daten also Parameterwerte gel scht oder hinz
94. Screenshot UnITeD Aufbau der Benutzeroberfl chel 92 5 3 Ausschnitt eines Zustandsautomaten der um berdeckungsinformationen einer Testsuite f r den Komponententest erg nztist 2 2 2m nun 97 5 4 Ausschnitt eines Zustandsautomaten der um berdeckungsinformationen eines einzelnen Komponententestfalls erg nzt et 98 5 5 Zustandsautomat erg nzt um Notizen mit Mappinginformationen PSNO9 99 5 6 Zustandsautomat erg nzt um Notizen und Informationen zu den berdeckten Eder ernennen Modos 100 169 ABBILDUNGSVERZEICHNIS 5 7 Teil eines Zustandsautomaten in dem Mappings und Transitionen farblich mar ee ee ee ee E 101 5 8 Toolbar von MagicDraw 2 2 2 2 Connor 101 5 0 Ver nderter Zustandsautomat 2 2 CC m nn nn 104 5 10 Beispiel f r nderung eines Zustandsautomaten oben Zustandsautomat vor der nderung unten Zustandsautomat nach der Anderung 105 5 11 Dialog Regressionsanalyse 2e 106 5 12 Ergebnisse Regressionsanalyse 2 ees 106 5 13 Ergebnisse Regressionstestgenerierung llle 107 6 1 Die Komponenten des Modells CabinControl 109 6 2 Ergebnisse der Integrationstestgenerierung anhand des Modells CabinControl KI K8 siehe Tabelle 6 zt 0 links Optimierung Testfallanzahl rechts Optimierung Teststepanzahl 120 6 3 Ergebnisse der Integrationstestgenerierung anhand des Modells Infotainment K1 K8 siehe Tabelle 6 ST l
95. Softwareverhal ten angemessen ist werden Informationen ber das erw nschte Verhalten ben tigt diese Infor mationen werden als Testorakel bezeichnet In der vorliegenden Definition von Testfall ist das Orakel nicht im Testfall mit enthalten F r die Einstufung der Ergebnisse des Testlaufs also f r die Zuordnung eines Verdicts zu jedem einzelnen Testfall ist allein der ausf hrende Tester verantwortlich Ein Testfall ist im Allgemeinen dann von hoher Qualit t wenn er ein hohes Fehlererkennungs potential hat Da ein Testfall der eine hohe berdeckung des Testobjekts erreicht auch h here Chancen bietet Fehler zu finden als ein Testfall der eine niedrigere berdeckung erreicht gilt im Kontext dieser Arbeit ein Testfall dann als qualitativ hochwertig wenn er das Modell aus dem er generiert wurde zu einem hohen Anteil berdeckt Eine Menge von Testf llen wird als Testsuite oder Testfallmenge bezeichnet Laut ist eine Testsuite a set of several test cases for a component or system under test where the post condition of one test is often used as the precondition for the next one In Rahmen dieser Arbeit wird diese Definition bernommen wobei die Postcondition eines Testfalls nicht als Precon dition des n chsten Testfalls benutzt wird Nach der Durchf hrung jedes Testfalls muss das System in den Initialzustand zur ck versetzt werden damit alle Testf lle mit der gleichen Vor bedingung ausgef hrt werden k nn
96. Testfallgenerierung an hand von Java Code in der Arbeit Ost07 und von UML Modellen im Rahmen dieser Arbeit eingesetzt werden konnten l sst vermuten dass sie auch f r die Testfallgenerierung im Kontext autonomer Systeme geeignet sind Diese Fragestellung ist Gegenstand aktueller Untersuchungen 160 Literaturverzeichnis ABLNO6 ABuR 06 AFGCO3 AO00 AO04 Bal97 BB00 BDG 04 BH08 James H Andrews Lionel C Briand Yvan Labiche and Akbar Siami Namin Using Mutation Analysis for Assessing and Comparing Testing Coverage Criteria Technical report Carleton University 2006 Shaukat Ali Lionel C Briand Muhammad Jaffar ur Rehman Hajra Asghar Mu hammad Zohaib Z Iqbal and Aamer Nadeem A State based Approach to Integra tion Testing based on UML Models Technical report 2006 Anneliese Andrews Robert France Sudipto Ghosh and Gerald Craig Test adequa cy criteria for UML design models Software Testing Verification and Reliability 13 2003 Aynur Abdurazik and Jeff Offutt Using UML Collaboration Diagrams for Sta tic Checking and Test Generation Proc of 3rd International Conference on The Unified Modeling Language 13 2000 R T Alexander and J Offutt Coupling based Testing of O O Programs Journal of Universal Computer Science 10 4 391 427 2004 Helmut Balzert Lehrbuch der Software Technik Software Management Software Qualit tssicherung und Unternehmensmodell
97. Testscript Generation Paths and Data Population Distribution Missing Ele E Log E Validation ELI B8 Ex Number of elements to cover 54 Number of covered elements 54 a 2011 09 30 16 04 08 510 INFO Total Time 0 hour 1 min 54 sec m H LI e Abbildung B 11 Anzeige einzelner Testf lle aus der generierten Testsuite 189 B Werkzeug UnITeD UN UnITeD Testgenerator CAUsers pinte Desktop Infotainment infotainmentuml ooo E File Optimization Mutation Options Window Help 5 iS From Selected Testcases From All Testcases E amp Testsuites ELI From All Testsuites Bester net ou fel riii O bm X amp poe Target Language Manual Test Specification for TestDirector TestCases E pese Target Directory Vi Manual Test Specification estCor Ti TestCase1 Bn Siem Eno mc m TT C CodeforNUnit T TestCase 2 E TestSystem BE al C Code for NUnit Forms Liese s o 5 D E auxiliaryResource EN Trigs Jaa Ende for ine N TestCase 4 1 D ProfileApplication cdPlayingSti 2 UT TiTestcases D7 ProfileApplication iin munical ET Lal r D ProfileApplications waitingForT E Microsoft Word Document SE D ProfileApplications showCalllnfy A3 7 input ll sur ui UserControl a ProfileApplication writeMessag o 7 n omingcall Behavior of SUT UserControl 2 md D u3
98. Variable wird unter sucht ob die Komponente deren Verhalten durch den Zustandsautomat beschrieben wird Variablen enth lt die den gleichen Typ wie die zu ndernde Variable haben Falls solche Variablen existieren dann wird eine entsprechende Variable zuf llig aus gew hlt und die zu ndernde Variable gegen die ausgew hlte Variable ausgetauscht Z B Guard im initialen Modell a lt 0 Guard im Mutant b lt 0 Somit k nnen durch Anwendung dieses Operators mehrere Mutanten entstehen Die Anzahl der er zeugten Mutanten h ngt davon ab wie viele Variablen im Guard referenziert werden und ob Variablen existieren die als Ersatz in Frage kommen Effect Operatoren Variablenzuweisung Operatoren Variablenzuweisung L schen B e t EVc O e t wird gel scht Variablenzuweisung Hinzuf gen B e t O der Transition wird ein Effect hinzugef gt der zuf llig aus der Menge EVc ausgew hlt wird 135 7 Evaluierung des Fehlererkennungspotentials modellbasierter Testf lle Arithmetischen Operator ndern B e t EVc V e t EVAc O der e t wird nach Elementen aus der MengeArithmetischeO peratoren durch sucht Falls ein solches Element gefunden wird wird es durch ein davon ver schiedenes Element das zuf llig aus der MengeArithmetischeO peratoren aus gew hlt wird ersetzt So z B wird durch einen Operator aus der Menge x ausgetauscht Bearbeitete Variable ndern B e t EVc
99. Ver nderung von Koeffizienten e Verf lschung boolescher Ausdr cke Durch Anwendung einer einzigen Transformation auf den Programmcode entsteht ein so ge nannter Mutant erster Ordnung Engl First Order Mutant Im Gegensatz dazu wird durch An wendung mehrerer Operatoren auf das gleiche Programm ein Mutant h herer Ordnung Engl Higher Order Mutant erzeugt JHO9 Die meisten Ans tze zum Mutationstest betrachten nur Mutanten erster Ordnung so auch der im Folgenden beschriebene Modell Mutationstestansatz 7 1 2 Modell Mutationstest Ans tze zum Modell Mutationstest bertragen die Ideen des Mutationstests von der Codeebe ne auf die Ebene der Modelle Somit soll das Potential von modellbasiert generierten Testf l len hinsichtlich der Erkennung von Modellierungsfehlern bewertet werden So z B werden in Endliche Zustandsmaschinen Engl Finite State Machine Kurz FSM betrachtet Dabei wurden typische Fehler bei der Modellierung von FSM vorgestellt und klassifiziert Danach wur de analysiert inwiefern Testf lle die eine strukturelle berdeckung der FSM erreichen solche Fehler zu entdecken erlauben Der Ansatz baut auf der Arbeit auf und be trachtet Statecharts Im Vergleich zu FSM stellen Statecharts zus tzliche Sprachelemente z B History Zust nde oder Sprachelemente die es erlauben hierarchische und parallele Komposition von Zust nden zu beschreiben zur Verf gung Die in beschriebenen Fehlerarten be treffen deshalb auch F
100. a Menschen komplexe Strukturen leichter ver stehen k nnen wenn diese mittels Diagrammen an Stelle von rein textuellen Notationen beschrieben werden Bei Einsatz semi formaler Sprachen ist zu beachten dass dies eine ausreichende Schulung von Mitarbeitern voraussetzt was mit Kosten verbunden ist e formale Modellierungssprachen z B endliche Zustandsautomaten Petri Netze Diese Sprachen haben eine eindeutige Syntax und Semantik was dazu f hrt dass Modelle die mit Hilfe solcher Sprachen beschrieben wurden eindeutig sind und keinen Spielraum f r Interpretationen erlauben Des Weiteren ist die Erf llung wichtiger Eigenschaften z B Verklemmung oft beweis bar und auch durch den Einsatz von Werkzeugen automatisch durchf hrbar Allerdings entsteht im Vergleich zu semi formalen Sprachen ein noch h herer Einarbeitungsaufwand Diese Sprache eignet sich besonders zur Datenmodellierung im Kontext von Datenbankanwendungen Kurz UML diese Sprache wird in Abschnitt 2 genauer beschrieben SEngl Finite State Machine Kurz FSM 6Diese Sprache eignet sich besonders f r die Modellierung nebenl ufiger Prozesse mit Parallelisierung und Syn 10 chronisation 2 2 Unified Modeling Language f r die Mitarbeiter und dadurch noch h here Kosten Auch die Erstellung solcher Modelle ist im Vergleich zu semi formalen Modellierungssprachen aufw ndiger Unabh ngig von der Syntax oder Semantik wird noch unterschieden ob es sich
101. aluierung der vorgestellten Testfallgenerierungsmethode ZM Z T TP TPausf Konto 8 19 64 58 InfotainmentGui 17 54 227 207 Achstest 26 83 342 278 ZM Zustandsautomat Z Anzahl Zust nde T Anzahl Transitionen TP Anzahl Transitionspaare TP ausf Anzahl ausf hrbare Transitionspaare Tabelle 6 2 Kenngr en der Zustandsautomaten aus denen Komponententestf lle generiert werden sierung sehr problemspezifisch ist F r die betrachteten einfachen Beispiele haben sich Populati onsgr en von 100 250 als optimal erwiesen Bei der Generierung anhand komplexerer Modelle wurde festgestellt dass eine Populationsgr e von 250 zu klein ist Da selbst eine Verdoppe lung der Populationsgr e nicht ausreichend war wurde bei der Generierung ausgehend von dem komplexesten Modell Liegenpr fplatz eine Populationsgr e von 750 ausgew hlt Bei der Ge nerierung von Komponententestf llen haben sich Stagnationsparameter von 2 8 bew hrt F r die Generierung von Integrationstestf llen sollte die lokale Optimierung allerdings abgeschaltet werden da sie die Entdeckung fehlender Mappings nicht unterst tzt Aufgrund dieser Erfahrungen wurde bei der Testfallgenerierung f r die Modelle Konto Ca binControl und Infotainment die Populationsgr e 250 ausgew hlt F r die Generierung anhand des Liegenpr fplatzmodells also bei der Generierung von Komponententestf llen aus dem Zu standsautomat Achstest und von Integrationstestf llen anha
102. and an evaluation is made of some aspect of the system or component Unter Testen versteht man also die Ausfiihrung eines Programms in einer bestimmten Umge bung mit dem Ziel das Programm beziiglich bestimmter Eigenschaften zu evaluieren Beispiele fiir solche Eigenschaften wurden am Anfang des Abschnitts 2 4 beschrieben wobei die Korrekt heit als eine der wichtigsten Eigenschaften anzusehen ist Deshalb ist das Testen in den meisten Fallen darauf ausgerichtet Fehler im Programm zu finden Dabei kann mittels Testen nachge wiesen werden dass ein Programm fiir bestimmte Eingaben unter bestimmten Randbedingungen nicht funktioniert also einen Fehler enth lt Da der Eingaberaum schon f r kleine Programme sehr gro sein kann kann das Programm meistens aus Zeit und Kostengr nden nicht mit allen m glichen Eingaben unter allen m glichen Randbedingungen getestet werden Aufgrund seines stichprobenartigen Charakters kann durch Testen nicht die Korrektheit von Programmen nach gewiesen werden Vielmehr f hrt das Testen dazu dass das Vertrauen in die Korrektheit des Programms w chst falls bei der Ausf hrung der Testf lle keine Fehler entdeckt werden Sehr bekannt ist in dieser Hinsicht die Aussage von Edsger Dijkstra in Dij70 Program testing can be used to show the presence of bugs but never to show their absence Ein Testverfahren das nicht auf das Finden von Fehlern sondern auf die Ableitung von Zu verl ssigkeitsaussagen a
103. anderer Komponenten ent halten Diese Effects werden generische Effects genannt post t Post state der Transition t bezeichnet den Zustand einer Komponente der aktiv wird nachdem 7 durchlaufen wurde Detailliert als 5 Tupel aufgelistet werden die Transitionen des Zustandsautomaten aus Abbil dung 3 1 in Tabelle Name pre t tr t g t e t post t tAl AO Startzustand _ _ L Al tA2 Al opA5 _ _ A5 Endzustand tA3 Al opAl i int i gt 0 x zi A2 tA4 AI opA 1 i int 1 0 _ A3 tA5 A2 opA2 x lt 5 _ A4 tA6 A4 opA3 _ b opB2 A2 tA7 A2 opA4 j boolean j true _ A3 LAN A3 opA5 _ _ A5 Endzustand Tabelle 3 1 Detaillierte Beschreibung der Transitionen der Komponente A Aufbauend auf diesen Konzepten werden nun die f r das Durchlaufen einer Transition notwen digen Bedingungen beschrieben Zu einem bestimmten Zeitpunkt befindet sich der Zustands automat in einem aktiven Zustand Falls ein Aufruf an die Komponente geschickt wird muss folgendes erf llt sein damit dieser Aufruf zu einem Zustands bergang f hrt aus dem aktiven Zustand muss eine Transition f ausgehen deren Trigger gleich dem Aufruf ist und deren Guard erf llt ist Wenn diese Bedingungen erf llt sind wird die Transition t durchlaufen und der neue aktive Zustand des Zustandsautomaten wird der Post state post t der durchlaufenen Transition Falls es keine Transition gibt die diese beiden Bedingungen erf llt verf llt dieser Aufru
104. arkeit des Mutanten MutIM unterscheiden Komponente A Komponente B AQ NEE lt lt ExternalSt gt gt w 5 as T opB40 opB3 eem tA3 opA20 x45 opA30 b opB20 GE d OPA1 i int PO x si i t9 ExternalSt m3 p40 S M e y gt 0 tA4 opA1 i int i lt 0 lt lt ExternalSt gt gt B2 tA7 e tB1 opA4 j boolean gt true b opB20 opAS PO tA8 lt lt ExternalSt gt gt T e S opAS A3 mu m2 Dd O lt Abbildung 7 6 Beispiel f r ein erweitertes Modell IM mit zwei interagierenden Komponenten und mit vier Mappings Der Testfall T7 opA1 4 opB1 69171531 opA2 opA3 erkennt diesen Mutanten da sich bei der Ausf hrung dieses Testfalls die externen Pfade durch Komponente B auf dem Mutant und auf dem initialen Modell unterscheiden Die externen Pfade durch A bleiben gleich Die bei Ausf hrung des Testfalls 77 durchlaufenen externen Pfade durch B sind externer Pfad durch B im Modell IM B2 B3 externer Pfad durch B im Modell MutIM B2 Der Testfall T2 opA1 4 opB1 69171531 opA2 opA3 opA4 true erkennt diesen Mu tanten nicht da sich bei der Ausf hrung dieses Testfalls die externen Pfade durch Komponente A und B auf dem Mutant und auf dem initialen Modell gleichen Die bei Ausf hrung des Testfalls T2 durchlaufenen externen Pfade sind externer Pfad durch A im Modell JM und im Mutant MutIM A2 A4 A2
105. as Werkzeug die Visualisierung der von generier ten Testf llen erzielten berdeckung auf dem Modell und den modellbasierten Regressionstest Zur Bewertung des Fehlererkennungspotentials werden sowohl Testfallmengen f r den Kom ponententest als auch Testfallmengen f r den Integrationstest betrachtet Einerseits wird evalu iert inwiefern solche Testfallmengen die Entdeckung von Modellfehlern erlauben Dies wird durch ein Mutationstestverfahren auf Modellebene umgesetzt das in einem ersten Schritt meh rere Mutanten des Modells automatisch erzeugt Daraufhin wird durch Ausf hrung der Testfall menge auf den Mutanten und auf dem initialen Modell der Anteil an erkannten Mutanten ermit telt Andererseits werden modellbasierte Testf lle mit manuell erstellten Testf llen verglichen und das Potential zur Erkennung von Implementierungsfehlern evaluiert Abstract This thesis presents a tool supported approach which enables the automatic test case genera tion from UML models and allows evaluating the fault detection potential of the generated test cases The test case generation method supports both the model based component and the integration testing phase The considered coverage criteria include established coverage criteria for compo nent testing as well as a series of so called state based integration testing criteria By using gene tic algorithms the developed tool automatically generates optimized test cases maximizing the coverage
106. asierten Systemen Dissertation Friedrich Alexander Universit t Erlangen N rnberg 2007 Y G Kim H S Hong S M Cho D H Bae and S D Cha Test Cases Generation 163 LITERATURVERZEICHNIS KRO3 KTS10 L107 Lig09 Lyu96 MS11 Neu08 NR07 NSVT07 164 from UML State Diagrams In In IEE Proceedings Software pages 187 192 1999 Supaporn Kansomkeat and Wanchai Rivepiboon Automated Generating Test Case Using UML Statechart Diagrams In SAICSIT 03 Proceedings of the 2003 an nual research conference of the South African institute of computer scientists and information technologists on Enablement through technology pages 296 300 Re public of South Africa 2003 South African Institute for Computer Scientists and Information Technologists Jussi Kasurinen Ossi Taipale and Kari Smolander Software Test Automation in Practice Empirical Observations Advances in Software Engineering 2010 Janu ary 2010 R Lefticaru and F Ipate Automatic State Based Test Generation Using Genetic Algorithms In Proceedings of the 9th International Symposium on Symbolic and Numeric Algorithms for Scientific Computing SYNASC 2007 2007 Peter Liggesmeyer Software Qualitdt Testen Analysieren und Verifizieren von Software 2009 Michael R Lyu Handbook of software reliability engineering McGraw Hill Inc Hightstown NJ USA 1996 Matthias Meitner and Francesca Saglietti Software Re
107. ate Specifications Based on Statecharts In JSSRE 99 Proceedings of the 10th International Symposium on Software Reliability Engineering page 210 Washington DC USA 1999 IEEE Computer Society Dorothy Graham Erik Van Veenendaal Isabel Evans and Rex Black Foundations of Software Testing ISTOB Certification Intl Thomson Business Pr 2008 Dirk W Hoffmann Software Oualit t Springer 2008 J Holland Adaptation in Natural and Artificial Systems University of Michigan Press 1975 IEEStd 610 12 1990 IEE Std 610 12 1990 IEEE Standard Glossary of Software Engineering Terminology 1990 IEEEStd 610 1991 IEEE Std 610 1991 IEEE Standard Computer Dictionary Compilation of IEEE Standard Computer Glossaries IEEE Press Piscataway NJ USA 1991 Standard glossary of terms used in Software Testing 2010 Yue Jia and Mark Harman Higher Order Mutation Testing Inf Softw Technol 51 1379 1393 October 2009 Zhenyi Jin and A Jefferson Offutt Coupling based Criteria for Integration Testing The Journal of Software Testing Verification and Reliability 8 133 154 1998 Martin Jung and Francesca Saglietti Supporting Component and Architectural Re usage by Detection and Tolerance of Integration Faults In 9th IEEE International Symposium on High Assurance Systems Engineering HASE 05 IEEE Computer Society 2005 Martin Jung Modellbasierte Generierung von Beherrschungsmechanismen f r Inkonsistenzen in komponentenb
108. atoren Jede Transition eines Zustandsautomaten hat genau einen Pre state Im Unterschied zu Trigger Guard oder Effect kann der Pre state einer Transition nicht einfach gel scht werden Deshalb beinhaltet die Klasse der Pre state Operatoren nur den im Folgenden beschriebenen Operator Pre state ndern ndert den Pre state einer Transition t indem er diesen durch einen anderen Zustand des Zustandsautomaten ersetzt Da dadurch auch nichtdeterministisches Verhalten erzeugt werden kann sind die in Frage kommenden Zust nde nur diejenigen aus denen keine Transition existiert die den gleichen Trigger wie die bearbeitete Transition f hat Des Weiteren muss vor Anwendung des Operators gelten dass der Pre state der Transition mehr als eine ausgehende Kante hat Anderenfalls w rde die Mutation dazu f hren dass der alte Pre state der Transition nach der Mutation keine ausgehenden Kanten mehr hat B Akpre s gt 1 O der Pre state von r wird ge ndert der neue Pre state wird dabei zuf llig aus der MengeKandidatenPreState Anfangszustandc ausgew hlt Post state Operatoren hnlich wie im Falle der Pre state Operatoren beinhaltet diese Klasse nur einen Operator der den Post state einer Transition ndert Post state ndern im Unterschied zur nderung des Pre states kann durch nderung des 137 7 Evaluierung des Fehlererkennungspotentials modellbasierter Testf lle Post states einer Transition kein nichtdeterministis
109. auf bestimmte Komponenten dieses Modells einschr nken zu k nnen Dazu muss beim Start der Testfallgenerierung ein bestimmter TestCon text ausgew hlt werden Der Dialog der dies erm glicht wird in Abbildung 5 1 dargestellt Test Context Selection Please select a TestContext 4 H TestContext TestContext A E SUT sut E Setup setup TestContext TestContex_B E SUT tA E TestComponent tB H Setup setup Abbildung 5 1 Screenshot UnITeD Dialog zur Auswahl eines TestContextes Wenn beim Start des Generierungsprozesses ein TestContext ausgew hlt wird der nur eine Komponente referenziert dann wird nur der Zustandsautomat dieser Komponente ber cksich tigt Das bedeutet dass die generierten Testf lle nur den einen Zustandsautomaten berdecken Ein Beispiel f r einen TestContext der nur eine Komponente referenziert ist der TestContext A Die benutzte Version ist 7 0 Kurz f r Extensible Stylesheet Language Transformations Sind Klassen die den Stereotyp TestContext haben D h dieser TestContext enth lt eine Variable vom Typ der Komponente 90 5 1 Das Werkzeug UnITeD aus Abbildung 5 1 Dieser enth lt mit der Variable sut eine Referenz auf die Komponente A F r den Fall dass ein TestContext bei der Generierung ausgew hlt wird der mehrere Kom ponenten referenziert zielt die Testfallgenerierung auf die berdeckung der Interaktionen der
110. aufbau 158 end wurden entsprechende Modell Mutationsoperatoren implementiert Die Mutationsanalyse erm glicht sowohl die Bestimmung des gesamten Anteils an erkannten Mutanten als auch die Bestimmung der Ergebnisse bez glich einzelner Mutationsklassen Es stellte sich dabei heraus dass die Testfallmengen die den anspruchsvollsten Kriterien auf Komponenten oder Integrationsebene gen gen bez glich der meisten Arten von Mutanten gute bis sehr gute Ergebnisse erreichten Somit wurde gezeigt dass sich modellbasierte Testf lle zur Erkennung von Fehlern in Zustandsautomaten eignen Wie man leicht erkl ren konnte wurden vor allem Fehler in Guards und Variablenzuweisungen nicht zu einem befriedigenden Anteil erkannt Auch die M glichkeit der Erkennung von Implementierungsfehlern durch modellbasierte Test f lle wurde untersucht und mit der Fehlererkennung von manuell erstellten Testfallmengen ver glichen So verursacht die systematische Vorgehensweise anhand von Modellen zwar einen h heren Aufwand dieser lohnt sich allerdings da mit Hilfe modellbasierter Testf lle Implementie rungsfehler gefunden wurden die durch die manuell erzeugten Testf lle nicht entdeckt wurden Nachdem der Beitrag der Arbeit zusammengefasst wurde folgt nun ein kurzer Ausblick Das im Rahmen dieser Arbeit vorgestellte Verfahren unterst tzt den Test von Softwaresystemen die aus synchron kommunizierenden Komponenten zusammengesetzt sind Eine immer wicht
111. berdeckter und noch zu berdeckender atomarer Entit ten Die Visualisierung berdeckter atomarer Entit ten wird durch F rbung realisiert indem die ein zelnen Transitionen oder Zust nde wie folgt eingef rbt werden e Gr n wenn sie von mindestens einem Testfall der Testfallmenge berdeckt wurden e Rot wenn sie noch nicht berdeckt wurden aber zu berdecken sind e Gar nicht markiert wenn sie noch nicht berdeckt wurden und nicht unbedingt zu berde cken sind wie z B nicht durchlaufene Transitionen im Falle einer angestrebten Zustands berdeckung Abbildung 5 3 zeigt die von einer Testsuite auf dem Zustandsautomat InfotainmentGui er reichte Uberdeckung bez glich des Kriteriums Transitions berdeckung Diese Testsuite ber deckt fast alle Transitionen Die nicht berdeckte Transition wird rot markiert navigation navigstorOn true O stop edinUnit PlayO cdinUnit true 1 ay mainMenu radio prSt cddio i LS radio cdinput myCDUntt play dinUrit trug prg a externalEndCall navigatorOn true mainMenu dCall navigatorOn true amp play myCDUnit zfayO prat play cdExit prSt radio f cdinUnit false m me cdinUnit true cdPlayingStopped stop0 1 Si nit stopf pr3 edinUnt false cdExit prSt ragio cq mUnit false Demut E incomingdall prSt play it tr endChil naviga cdnpuo caine tru
112. betrachtet Siehe Abschnitt 3 1 53 3 Modellbasierte Uberdeckungskriterien Das Modell wird dazu um eine komplement re Sicht erweitert Dies bedeutet dass im Auto maten zum einen ein Error State und zum anderen mehrere Faulty Transitions wie folgt beschrie ben eingef hrt werden f r jeden Simple State kein Error State und f r jedes Event des Auto maten welches nicht als Ausl ser f r eine Transition aus dem aktuell betrachteten Zustand gilt wird eine Faulty Transition aus dem aktuellen Zustand in den Error State eingef hrt Somit bein haltet der so genannte Completed Statechart neben den normalen Zust nden und Transitionen den Simple States und Legal Transitions sowohl einen Error State als auch Faulty Transitions Durch Fokussierung auf die berdeckung der normalen Transitionen wird getestet wie sich das System bei erwarteter Beanspruchung verh lt So verlangt z B das Kriterium K transition Coverage die berdeckung aller Sequenzen von normalen Transitionen der L nge k N Im Ge gensatz dazu verlangt das Kriterium Faulty Transition Pair Coverage dass jedes Transitionspaar bestehend aus einer Legal Transition und einer Faulty Transition berdeckt wird 3 3 Modellbasierte berdeckungskriterien f r den Integrationstest Wie schon in Abschnitt 2 5 1 erw hnt zielt der Integrationstest auf das Testen des Zusammen spiels mehrerer Komponenten ab Die Durchf hrung dieser Testphase setzt voraus dass
113. beziehen sich auf den Grad der funktionalen Bindung innerhalb einer Komponente die Koh sion innerhalb der Komponente und auf den Grad der Interaktion zwischen einzelnen Komponenten die Kopplung zwischen Komponenten Ersteres sollte f r die einzelnen Komponenten so hoch wie m glich sein Dagegen sollte der Grad der Interaktion zwischen mehreren Komponenten so gering wie m glich sein Dadurch wird die bersichtlichkeit Wartbarkeit und Wiederverwend barkeit des Systems gewahrt Anderungen innerhalb der Komponente wirken sich nicht nach 16 2 3 Komponentenbasierte Softwareentwicklung au en also auf die anderen Komponenten aus was die Gefahr minimiert dass eine einzelne nderung im Code viele Nebeneffekte in nicht ge nderten Codestellen verursacht Komponen ten die lose mit anderen Komponenten gekoppelt sind k nnen dar ber hinaus leicht in anderen Anwendungen wiederverwendet werden da sie nicht viele Abh ngigkeiten zu anderen Kompo nenten besitzen Ein komponentenbasiert entwickeltes System mit hoch koh siven und gering gekoppelten Komponenten bietet also viele Vorteile allerdings k nnen Fehler die aus Inkompatibilit ten der Komponenten resultieren dadurch nicht ausgeschlossen werden Mit Inkompatibilit ten die bei der Interaktion zwischen Komponenten auftreten k nnen besch ftigen sich die Arbeiten von und Jun07 wobei folgende Klassifikation vorgeschlagen wurde e Syntaktische Inkonsistenzen diese Klasse besch
114. bnisse bez glich der einzelnen Mutationsklassen auf dem Modell Liegenpr fplatz Diese Ergebnisse wurden bereits in ver ffentlicht Die Testfallmenge K8L entdeckt nur geringf gig mehr Mutanten als K7L Hier wird ersichtlich wo dieser kleine Unterschied entsteht und zwar bez glich der Effect Mutationen Sonst schneiden diese zwei Testfallmengen bez glich der Klassen Trigger Effect Pre state und Post state Mu tationen sehr gut jeweils ber 90 ab hnlich wie im Falle der Testfallmengen die anhand des Infotainment Modells generiert wurden ist die Erkennbarkeit bzgl Guard Mutationen schlecht nur 44 64 Zusammenfassend kann gesagt werden dass bez glich vier der f nf Mutationsklassen Testf l le die dem anspruchsvollsten zustandsbasierten Kriterium gen gen sehr gut abschneiden Dies bedeutet dass Fehler die sich auf den Trigger Effect Pre state und Post state von Transitionen 153 7 Evaluierung des Fehlererkennungspotentials modellbasierter Testf lle m Invoking invoked transitions K8L E Invoking transitions on pre states K7L E Triggers and effects in on pre states K6L W Effects in on pre states K5L E Effects on pre states KAL m Invoking transitions K3L E Pre states triggers and effects K2L E Pre states and triggers K1L Abbildung 7 9 Fehlererkennungspotential bzgl einzelner Mutationsklassen von Testfallmen gen die zustandsbasierte Integrationstestkr
115. cel deviation confirm ChangeMS ilfeGusrd 3 ReportDeviation DeviationConfirmDone false v DeviationConfmDone ExteralSts tue Wait for Deviation myPar ReportDeviation Confirm AcoeptDeviation DevistionConfirmDone true IDeviationNumberExists Clio tue JlesveStep felse gt myPar AcceptDeviation UnacceptDeviation DevistionNumberExists true IDevistionNumberExists false myPar UnacceptDeviation UnreportDevistion DevistionConfirmDone true DevistionConfirmDone false myPar UnreportDevistion gas PressConfirm ImyPar ResetResult Cave ai aus myPar Resete d e myPar ResetResult ectusIMS 5 ImyPar ResetResult PressCancel HiltsGuard 9 ImyPar ResetResult Changes HilfsGuard 9 HilfsGuarde ChangeSte bitch Gieres EvalusteResults actusIMS 5 leaveStep true nextMS gt 6 myPar ExitMS Evaluation AutoForward Step Final Abbildung A 2 Modell Liegenpriifplatz Komponente Achstest Teil 2 von 2 175 A UML Modelle PartisiResult Initial Init Jit MS 1 mV MS1Val LosdPersistedValues mV PartialResultEnum TestNotPerformed MS4bVal 1 Ls Noselen LosdPersistesValues H mV PartisiResultEnum Testok H 8 i 2 2 mV PartialResultEnum TestNotOK t E eneen E 23 oC HE 33
116. chen Algorithmen zum Zweck der automatischen modellbasierten Testfallgenerierung erl utert Anschlie end wird in Kapitel 5 Abschnitt 5 1 Jdas Werkzeug UnITeD beschrieben das gene tische Algorithmen einsetzt und dadurch Testf lle automatisch zu generieren und zu optimieren erlaubt Weitere n tzliche Funktionen des Werkzeugs und zwar die Visualisierung der erreichten Modell berdeckung und die Regressionstestgenerierung werden in jeweils einem Abschnitt bzw dieses Kapitels vorgestellt Kapitel stellt die Ergebnisse der Testfallgenerierung dar Zun chst werden dazu in Abschnitt 6 1 die evaluierten Anwendungen beschrieben gefolgt von der Beschreibung der Parametrisie rung der Algorithmen in Abschnitt 6 2 Die Ergebnisse der Komponententestgenerierung werden 1 3 Gliederung in Abschnitt 6 3 vorgestellt Daraufhin beschreibt Abschnitt 6 4 die Ergebnisse der Integrations testgenerierung Die Evaluierung des Fehlererkennungspotentials modellbasierter Testf lle wird in Kapitel beschrieben Einerseits wurde mittels eines Modell Mutationstests evaluiert inwiefern modell basierte Testfallmengen erlauben Modellierungsfehler zu erkennen die Ergebnisse werden in Abschnitt 7 I beschrieben Andererseits wurde evaluiert ob solche Testf lle auch die Erkennung von Implementierungsfehlern unterst tzen was in Abschnitt 7 2 dargestellt wird Abschlie end gibt das Kapitel 8 eine Zusammenfassung der vorliegenden Arbeit zusammen mit
117. ches Verhalten erzeugt werden Deshalb beinhaltet die Menge der in Frage kommenden Zust nde alle Zust nde des Zustandsauto maten au er dem Pre und Post state der aktuellen Transition t und dem Anfangszustand des Automaten B Ek post t c O der Post state von r wird ge ndert der neue Post state wird dabei zuf llig aus der Menge Sc post t U pre t U Anfangszustandc ausgew hlt Transition Operatoren Transition L schen durch das L schen einer Transition kann es vorkommen dass bestimmte Zust nde keine ein oder ausgehenden Transitionen mehr besitzen Deshalb wird der Ope rator auf der Transition f nur angewendet wenn sowohl der Pre als auch der Post state der Transition mehr als eine ausgehende bzw eingehende Transition haben B Weil gt 1 Ekpos o gt 1 A tr t AL O Transition t wird gel scht Dies bedeutet auch dass tr t g t und e t gel scht wer den Transition Hinzuf gen B pre t Z post t tr t Z O ausgehend von einer Transition wird eine neue Transition fneu erzeugt mit fr fneu tr t und post tneu post t Als pre tneu wird ein Zustand zuf llig aus der Menge Sc pre t U An fangszustandc ausgew hlt Zustand Operatoren Zustand L schen dieser Operator betrachtet alle Zust nde S Sc B Aks 1 A Eks 1 O der Zustand S wird gel scht Dar ber hinaus muss die eingehende Transition f mit post t S und die ausgehende Transition t mit pre t
118. chlagen werden Diese basieren auf den klassischen Datenflusskri terien und betrachten die Konzepte der Def und Use von Variablen komponenten bergreifend Diese Kriterien verlangen dass Ausf hrungspfade zwischen Definitionen von Variablen in einer Komponente und ihren Verwendungen in anderen Komponenten berdeckt werden F r den Fall dass die interagierenden Komponenten in einer objektorientierten Sprache pro grammiert wurden muss der Integrationstest f r solche Komponenten auch die spezifischen Kon zepte dieser Sprache ber cksichtigen Aus diesem Grund betrachten die Kriterien von die Konzepte der Polymorphie und Vererbung Sie ziehen in Betracht dass abh ngig vom gegen w rtigen Kontext verschiedene polymorphe Methoden aufgerufen werden k nnen wobei sich in jeder der berschriebenen Methoden ein Use einer Variable befinden kann Die entsprechende Def muss in Kombination mit den Uses aus den polymorphen Methoden berdeckt werden Neben der Frage nach einer ad quaten berdeckung der implementierten Komponenteninter aktion ist eine weitere interessante Fragestellung die nach der quantitativen Zuverl ssigkeits bewertung eines Systems das aus mehreren interagierenden Komponenten besteht Zu diesem Zweck m ssen ebenfalls Testf lle generiert werden deren Auswertung die Ableitung statisti scher Aussagen ber das zu testende System erm glicht Mit der Generierung solcher Testf lle besch ftigt sich die Arbeit MS11 die gl
119. chriebenen zustandsbasierten berdeckungskriterien e Minimierung der Testfallanzahl dies ist deshalb besonders interessant da trotz automati scher Testfallgenerierung die Bewertung der Testf lle Zuordnung eines Verdicts als be standen oder nicht bestanden noch sehr oft manuell durch den Tester erfolgen muss Hier entsteht also auch ein nicht unerheblicher Aufwand der durch die Minimierung der Anzahl auszuf hrender Testf lle reduziert werden kann Bei der Testfallgenerierung handelt es sich also um ein Optimierungsproblem bei dem meh rere Optimierungsziele gleichzeitig verfolgt werden Erschwerend kommt hinzu dass es sich um zwei rivalisierende Ziele handelt eine Testfallmenge mit vielen Testf llen kann im Allgemeinen leichter eine hohe berdeckung erreichen als eine mit wenigen Testf llen Diese zwei Optimie rungsziele sind aber nicht gleich wichtig eine hohe berdeckung hat wesentlich h here Priorit t als die Minimierung der Testfallanzahl da durch eine hohe berdeckung die Wahrscheinlich keit Fehler zu finden erh ht wird Besonders im Kontext sicherheitskritischer Anwendungen wird die Anzahl auszuf hrender Testf lle sekund r sein falls durch mehr Testf lle die Fehlerer kennungswahrscheinlichkeit erh ht wird Zur L sung solcher Optimierungsprobleme eignen sich unter anderem genetische Algorith men welche als so genannte Meta Heuristiken heuristische Verfahren sind die der Suche nach guten nahezu optima
120. chtdeterministischen Mu tanten nicht automatisch erkannt werden k nnen muss bei der Generierung der Mutanten darauf geachtet werden dass m glichst nur deterministische Mutanten erzeugt werden Dazu wurden bei der Umsetzung der einzelnen Operatoren sowohl die Bedingung f r die Durchf hrung einer Mutation an einer Transition oder einem Zustand als auch die Operation an sich entsprechend umgesetzt Wie dies pro Operator realisiert wurde wird in folgender Form beschrieben Mutationsbedingung Kurz B f r jeden Modell Mutationsoperator gibt B die Bedingung an die die Entit t Transition oder Zustand erf llen muss damit dieser Operator auf dieser Entit t angewendet wird Mutationsoperation Kurz O beschreibt die Operation die durchgef hrt wird Zur kompakten Beschreibung der Bedingung B und der durch die Operatoren durchgef hrten F r Details zur genauen Funktionsweise des Operators siehe Beschreibung von Guard Variable ndern F r Details zur genauen Funktionsweise des Operators siehe Beschreibung von Trigger ndern 132 7 1 Erkennungspotential hinsichtlich Modellierungsfehler nderung O werden die in Abschnitt 3 1 beschriebenen Mengen Tc Sc Trc usw benutzt Dar ber hinaus werden noch ein paar zus tzliche Begriffe ben tigt die hier eingef hrt werden F r eine Komponente C COMP und eine Transition t Tc sei MengeKandidatenTrigger Trch tri Tre 3t T Tr c tri pre t
121. de analysierte Testfallmenge eingef hrt K C referenziert die Testfallmenge die auf dem Modell CabinControl das berdeckungskriterium Pre states and triggers erf llt KSC die Testfallmenge die das Kriterium Invoking invoked transitions auf dem Modell Cabin Control erf llt Analog werden f r die anderen Testfallmengen auch die Abk rzungen KJI bis KSI I von Infotainment und K L bis KSL L von Liegenpr fplatz verwendet Am besten schneidet die Testfallmenge K8C ab Sie erlaubt die Erkennung von 98 61 aller anhand von CabinControl generierten Mutanten Daf r wurden 5 Testf lle ben tigt Die Test fallmenge K7C erkennt 2 Mutanten weniger und enth lt 3 Testf lle Auf CabinControl hat die F r die Bedeutung von K1 K8 siehe Tabelle 6 5 148 7 1 Erkennungspotential hinsichtlich Modellierungsfehler Testfallmenge KIC den geringsten Mutation score 73 61 da sie 19 Mutanten nicht erkennt Dies bedeutet dass auf diesem Modell das Kriterium Pre states and triggers das schw chste Fehlererkennungspotential hat Die Mutationsanalyse anhand des Infotainment Modells ergab dass die Testfallmenge K8I am besten abschneidet Sie entdeckt 88 Mutanten was 93 62 der generierten Mutanten entspricht und enth lt 5 Testf lle Auf diesem Modell ist Effects on pre states mit Abstand das schw chste Kriterium da die Testfallmenge K4I nur 47 87 der Mutanten erkennt Dieser Wert liegt mehr als 20 unter dem Wert der durch die Testfall
122. dellbasierter Testf lle sind und D MO T S die Menge der Mutanten die durch die Testsuite TS erkannt wur den Eine modellbasierte Testsuite erkennt einen Mutanten t tet einen Mutanten wenn mindes tens ein darin enthaltener Testfall den Mutanten t tet d h wenn sich das nach au en sichtbare Verhalten bei der Ausf hrung des Testfalls auf dem Mutanten von dem nach au en sichtbaren Verhalten bei der Ausf hrung des Testfalls auf dem initialen Modell unterscheidet Zur Erkl rung des Konzepts nach au en sichtbares Verhalten muss zun chst das Konzept der externen Zust nde eingef hrt werden Diese Zust nde beschreiben im Allgemeinen vom Benut zer wahrnehmbares Systemverhalten z B in Form von Dialogen Welche Zust nde als externe Zust nde zu verstehen sind muss bei der Modellierung festgelegt werden Dazu muss an den entsprechenden Zust nden der Stereotyp ExternalSt angebracht werden Eine Folge von exter nen Zust nden wird als externer Pfad bezeichnet Um dieses Konzept beispielhaft darzustellen werden die Zustandsautomaten aus Abbildung 7 1 zusammen mit den in Abschnitt zur Modell simulation beschriebenen Testf llen ein Testfall f r den Komponententest und einer f r den Integrationstest betrachtet Komponente A Komponente B mi ExternalSt o A4 u 87 t85 we T wf er 5850 lt lt ExternalSt gt gt tA3 opA2 x45 opA3 b opB2 B4 tB6 B3 opA1 i int 50 x i
123. der Bedeutung Test fallmengen die eine bestimmte strukturelle berdeckung eines Modells erreichen wel ches sehr detailliert die zu implementierende Funktionalit t beschreibt haben eine h here Chance Implementierungsfehler zu entdecken als Testfallmengen die eine gleiche struk turelle berdeckung auf einem abstrakteren Modell erreichen Die meisten Ans tze zum modellbasierten Test die im Rahmen dieser Arbeit genannt wer den z B Sok04 WS07 verfolgen dieses Ziel Diesen Szenarien wird auch bei der Evaluierung in Kapitel Rechnung getragen indem das Potential modellbasierter Testf lle sowohl hinsichtlich der Erkennung von Modellierungsfehlern als auch hinsichtlich der Erkennung von Implementierungsfehlern untersucht wird 43 3 Modellbasierte berdeckungskriterien Bevor in Kapitel 4 die zur Testfallgenerierung eingesetzten genetischen Algorithmen vorgestellt werden beschreibt dieses Kapitel im ersten Abschnitt die der Testfallgenerierung zu Grunde lie gende Modellnotation Danach werden modellbasierte berdeckungskriterien beschrieben zum einen werden in Abschnitt 3 2 Uberdeckungskriterien fiir den Komponententest vorgestellt zum anderen werden Uberdeckungskriterien fiir den Integrationstest in Abschnitt 3 3 vorgestellt ge folgt von der Beschreibung zustandsbasierter Integrationstestkriterien in Unterabschnitt 3 2 3 1 Verhaltensbeschreibung von Komponenten mittels UML Zustandsautomaten Als Sprache
124. der Mappings wird anhand der folgenden Formel berechnet Effects in on pre states Y ISIE c e a S Tr c e ecEc Triggers and ef fects in on pre states Kriterium dieses Kriterium verlangt dass f r jedes Viertupel von Pre state Trigger Effect der aufrufenden Komponente C und Pre state der aufgerufenen Komponente C also f r jedes preC trC eC preC wobei preC Sc trC Tro eC Ec preC Sc mindestens ein Mapping m t t Map berdeckt wird f r das gilt pre t preC tr t trC e t eC pre t preC Die Anzahl zu berdeckender Mappings wird anhand der folgenden Formel berechnet Triggers and ef fects in on pre states A S Tr E c tr e S Tr o e treTrc ecEc Invoking transitions on pre states Kriterium dieses Kriterium verlangt dass f r jedes F nftupel von Pre state Trigger Effect und Post state der aufrufenden Komponente C und Pre state der aufgerufenen Komponente C also f r jedes preC trC eC postC preC wobei preC Sc trC Tro eC Ec postC Sc preC Sc 63 3 Modellbasierte Uberdeckungskriterien mindestens ein Mapping m t t Map berdeckt wird f r das gilt pre t preC tr t trC e t eC post t postC pre t preC Die Anzahl zu berdeckender Mappings wird anhand der folgenden Formel berechnet Invoking transitions on pre states Y IS Tr c e t
125. die ein zelnen interagierenden Komponenten bereits erfolgreich einen Komponententest bestanden ha ben damit sichergestellt ist dass die Komponenten ihre Spezifikation erf llen Falls dies nicht der Fall ist wird die Suche nach der Ursache von Fehlern die sich beim Integrationstest offen baren aufwendiger denn der Fehler kann sowohl in der Interaktion der Komponenten unterein ander liegen als auch in der inneren Funktionalit t einzelner Komponenten Als erstes muss bei der Planung dieser Testphase entschieden werden in welcher Reihenfolge die einzelnen Komponenten zusammengesetzt und getestet z B Top down oder Bottom up werden Danach m ssen geeignete Testf lle generiert werden Dabei stellt sich die Frage nach der besten Strategie f r die Herleitung von Integrationstestf llen Eine reine Black Box Betrachtung des Gesamtsystems ist nicht detailliert genug da eine sol che Sicht zwar die Gesamtfunktionalit t des Systems beschreibt aber keinerlei Information ber die einzelnen Komponenten und ihre Interaktionen enth lt 7Siehe Abschnitt 54 3 3 Modellbasierte berdeckungskriterien f r den Integrationstest Auf der anderen Seite bietet eine White Box Perspektive auf die Komponenten Zugang zu die sen Informationen Deshalb gibt es auf Quellcodeebene berdeckungskriterien f r den Integrati onstest die auf die berdeckung der Interaktionen ausgerichtet sind so z B die Coupling Based Criteria die in vorges
126. e Unterschiede in der Art der Fitnessbewertung einer Testsuite und eines Testfalls werden in Un terabschnitt 4 3 3 beschrieben 4 3 2 Anfangspopulation Der genetische Algorithmus startet mit der Generierung einer Anfangspopulation indem eine vor dem Start der Generierung festgelegte Anzahl an Individuen generiert wird Jedes einzel ne Individuum wird wiederum generiert indem eine vorgegebene Anzahl an Testf llen erzeugt wird wobei jeder Testfall eine vor dem Start der Generierung festgelegte Anzahl an Aufrufen nicht berschreiten darf Die Generierung einer Anfangspopulation von Komponententestf llen unterscheidet sich von der Generierung einer Anfangspopulation von Integrationstestf llen Testf lle f r den Komponententest werden generiert indem als erstes Testsequenzen erstellt werden Dazu wird erst statisch eine Folge von Transitionen durch den Zustandsautomat ermit telt Der Algorithmus geht dabei schrittweise wie folgt vor in jedem Schritt wird ein Zustand des Automaten betrachtet und aus der Menge der daraus ausgehenden Transitionen eine Transi tion zuf llig ausgew hlt Eine Nachricht die gleich dem Trigger der ausgew hlten Transition ist wird der Testsequenz hinzugef gt Danach wird der Post state der gerade ausgew hlten Tran sition betrachtet und der Vorgang wiederholt indem wieder zuf llig eine Transition ausgew hlt wird Dies passiert so oft bis f r jede Testsequenz gen gend Nachrichten erzeugt wurden oder e
127. e die es dem Benutzer erm glicht entsprechende Ma nahmen zu treffen Z B kann der Benutzer dann durch Kenntnis der nicht berdeckten En tit ten manuell Testf lle generieren die diese Entit ten berdecken Auch im Falle der Er 6Diese Funktionalit t wird bei der Evaluierung zu akademischen Zwecken benutzt Personen die das Werkzeug zur Testfallgenerierung im industriellen Kontext einsetzen ben tigen diese Funktionalit t wahrscheinlich nicht Dies sind textuelle Informationen zu dem Fortschritt der Testfallgenerierung und beinhalten die Anzahl generier ter Populationen und die erreichte berdeckung 95 5 Werkzeugunterst tzung zielung einer 100 igen berdeckung unterst tzt die Visualisierung den Benutzer Durch Visualisierung der von einem einzigen Testfall berdeckten Entit ten k nnen die Testf lle leicht identifiziert werden die bestimmte Modellteile berdecken Dies ist hilfreich falls nur ein Testfall ausgef hrt werden soll der einen spezifischen Teil des Modells berdeckt Sie unterst tzt die Bewertung der Modelle Die Visualisierung der berdeckten Entit ten eignet sich auch f r die berpr fung der Modelle die der Testfallgenerierung zugrun de liegen Zur berpr fung solcher Modelle haben sich Methoden wie Inspections oder Walkthroughs durchgesetzt Die manuelle Natur solcher Verfahren birgt aber die Ge fahr in sich dass dabei bestimmte Teile des Modells bersehen werden Gegen ber
128. e Anzahl an Teststeps verringert werden konnte Auch die Testfallmengen f r Transitionspaar berdeckung konnten durch diesen zus tzlichen Generierungsvorgang verbessert werden So konnte etwa die Transitionspaar ber deckung f r InfotainmentGui mit einer Testsuite bestehend aus 40 Testf llen und 632 Teststeps erreicht werden Dies bedeutet 8 Testf lle und 30 Teststeps weniger als die urspr nglich ge nerierte Testfallmenge Die Testfallmenge f r Transitionspaar berdeckung auf Achstest konnte nicht nur hinsichtlich der Anzahl an Testf llen und Teststeps verbessert werden sondern auch hinsichtlich der erreichten berdeckung mit einer Testsuite bestehend aus 73 Testf llen und 1204 Teststeps was 7 Testf lle und 80 Teststeps weniger bedeutet als die urspr nglich generier te Testsuite werden zus tzlich zwei Transitionspaare berdeckt was bedeutet dass die erreichte berdeckung auf 98 56 steigt Die Ergebnisse aus Tabelle 6 4 zeigen dass es sich besonders im Falle von Testfallmengen f r Transitions oder Transitionspaar berdeckung lohnen kann erst einmal den genetischen Gene rierungsvorgang bis zum Erreichen einer 100 ige berdeckung laufen zu lassen um daraufhin eine zus tzliche Optimierungsphase zu starten Alternativ k nnte man nur einen Optimierungs prozess durchf hren der nach einer bestimmten Anzahl an Generationen aufh rt Problematisch dabei ist dass vor dem Start der Generierung nicht bekannt ist ob und wenn ja nac
129. e Einstufung der Ergebnisse jedes einzelnen Testfalls mit hohem manuellem Aufwand verbunden ist Angesichts dieser Tatsache ist es wichtig dass w hrend der Testfallgenerierungsphase neben dem Erreichen einer m glichst hohen berdeckung des Testobjekts auch ein m glichst geringer Umfang der Testfallmenge angestrebt wird 1 2 Zielsetzungen Unter Ber cksichtigung der oben beschriebenen Aspekte wurden im Rahmen der vorliegenden Arbeit folgende Zielsetzungen verfolgt Unterst tzung der automatischen Komponententestgenerierung und Optimierung Das werkzeuggest tzte Verfahren das im Rahmen dieser Arbeit beschrieben wird erm glicht die automatische modellbasierte Komponententestgenerierung zur Erf llung etablierter modell basierter berdeckungskriterien f r den Komponententest Zustands Transitions und Transiti onspaar berdeckung Durch Benutzung genetischer Algorithmen erlaubt das Werkzeug neben der automatischen Generierung auch die Optimierung der Testfallmengen hinsichtlich zweier Ziele e einerseits hinsichtlich einer m glichst hohen berdeckung bez glich des angestrebten Kri teriums und e anderseits hinsichtlich einer m glichst geringen Anzahl an Testf llen Die Ergebnisse die durch Anwendung des Werkzeugs bei der Komponententestgenerierung erreicht wurden werden in Abschnitt 6 3 beschrieben Des Weiteren unterst tzt das Werkzeug die Visualisierung der durch Komponententestf lle berdeckten und noch zu
130. e bez glich aller Mutationsklassen schlecht bis sehr schlecht ab Mutanten der Klasse Effect Mutationen werden gar nicht durch diese Testfallmenge erkannt TK und TPK schneiden auf diesem Modell bez glich vier der sieben Klassen hnlich gut ab alle Mutanten der Klassen Pre state Post state und Zustand Mutationen werden durch diese zwei Testfallmengen erkannt bez glich Trigger Mutationen wird ein Mutation score von 87 5 erreicht hnlich schlecht schneiden beide Testfallmen gen bez glich Guard 42 31 der Guard Mutanten werden erkannt und Transition Mutationen 55 17 der Transition Mutanten werden erkannt ab Lediglich hinsichtlich der Klasse Effect Mutationen kann sich TPK absetzen da sie circa doppelt so viele Effect Mutanten erkennt wie TK E Transitionspaar berdeckung Konto TPK E Transitions berdeckung Konto TK m BESBUNJRER oOo000000000 Helene RN o 4 T 1 B Zustands berdeckung Konto ZK e S gt gt gt e e e e e e e S S S S RS RS RS SS uS SF gt o gt SU S S SU S S S A N XS e N S N A A e amp E x ei e AS e A A g q9 AS Abbildung 7 3 Fehlererkennungspotential bzgl einzelner Mutationsklassen von Testfallmen gen die Komponententestkriterien auf der Komponente Konto erf llen hnliche Ergebnisse werden auch anhand des Zustandsautomaten InfotainmentGui erreicht diese werden in Abbildung 7 4 dargestellt Einzig bez glich der Klasse Zustand
131. eaktive Softwaresysteme Regressionsanalyse 102 Regressionstest Regressionstestgenerierung Rekombination Rekombinationsoperator Reviews Risikogetriebene Integration Roulette Wheel Schnittstelle Schwacher Mutationstest Selective Regression Testing 30 Selektion selektiver Regressionstest semi formale Modellierungssprachen Sequenzdiagramm Sicherheitstest Simulated Annealing Software Engineering Software Komponente 194 Softwarefehler Starker Mutationstest State Statechart statische Verfahren statistisches Testen Strong Mutation Test 123 Strukturdiagramm strukturelles Testen 32 strukturierte Pfadtests Strukturorientierte Integration strukturorientierter Test Strukturtest Stub Survival of the fittest 70 System Under Test Systemtest Termingetriebene Integration Test Testauswertung TestContext Testdaten Testdurchfiihrung Testfall Testfallgenerierung Testfallmenge Testgetriebene Integration Testorakel Testplanung Testsequenz Teststep Teststrategie Testsuite Testsystembeschreibung Testtreiber Testumgebung Timingdiagramm Top Down Integration Tournament Selection Transition Transition Hinzuf gen 138 Transition L schen 138 Transition Operatoren 138 Transitions berdeckung Transitionspaar Transitionspaar berdeckung Trigger Trigger ndern 134 Trigger Hinzufiigen Trigger L schen 134 Trigger Opera
132. ehler die bei der Modellierung solcher zus tzlichen Konstrukte auftreten k nnen In werden Mutationsoperatoren f r die Sprache Extended Finite State Machi ne Language Kurz Estelle vorgestellt Diese Sprache erlaubt es Systeme zu spezifizieren die aus mehreren kommunizierenden Modulen bestehen Kommunikation erfolgt ber so genannte Bi directional Channels Erweiterte Endliche Zustandsmaschinen Engl Extended Finite State Siehe Zusammenhang fehlerhafter Zustand und Programmversagen in Abschnitt 4 124 7 1 Erkennungspotential hinsichtlich Modellierungsfehler Machines Kurz EFSM beschreiben dabei das Verhalten der einzelnen Module Von den gerade betrachteten Ans tzen ist der hier beschriebene Modell Mutationstestansatz am ehesten mit der Arbeit von vergleichbar allerdings sind aufgrund der Unterschiede in der benutzten Modellierungssprache die betrachteten Fehlerarten unterschiedlich W hrend EFSMs betrachtet werden f r die Modellierung des Verhaltens einzelner Module im Rahmen dieser Arbeit UML Zustandsautomaten benutzt Des Weiteren wird die Kommunikation unterschiedlich dargestellt durch Bi directional Channels in und durch Aufrufe in Effects von Transitionen in dieser Arbeit Die Durchf hrung eines Mutationstests ist meistens so aufwendig dass sie ohne Werkzeug unterst tzung nicht zu bewerkstelligen ist Um die Evaluierung des Fehlererkennungspotentials modellbasierter Testf lle so weit wie m glich zu automatisi
133. ei M glichkeiten Die eine M glichkeit ist immer nur zwei Eltern Individuen zu selektieren aus denen dann durch Rekombination ein oder zwei neue Kind Individuen erzeugt werden Alternativ kann der Selektionsoperator eine ganze Menge von poten tiellen Eltern generieren wobei der Rekombinationsoperator daraufhin in jedem Durchlauf zwei Individuen aus dieser Menge ausw hlt Zur Erzeugung der Kind Individuen gibt es mehrere Vorgehensweisen Die einfachste Variante ist der point crossover Operator der die zwei Eltern zun chst in die neue Population kopiert dann einen beliebigen Kreuzungspunkt ausw hlt um dann die Bestandteile der Individuen ab diesem Punkt auszutauschen hnlich geht der 2 point crossover Operator vor indem er zwei Kreuzungspunkte setzt Die Menge an Kreuzungspunkten kann auch beliebig erweitert werden so dass im allgemeinen Fall von einem n point crossover gesprochen wird Mutation Zur Erzeugung einer neuen Population wird der Rekombinationsoperator in Kombination mit dem Selektionsoperator mehrmals angewendet W rde sich der Algorithmus nur auf diese zwei Operatoren beschr nken w ren die neu erzeugten Individuen nur durch Kombinationen der In dividuen entstanden die in der zuf llig generierten Anfangspopulation vorhanden waren D h die zuf llig generierte Anfangspopulation w re ausschlaggebend f r den Erfolg der Suche Um dies zu vermeiden wird ein zus tzlicher genetischer Operator ben tigt und zwa
134. eich zur Spezifikation der Software Umsetzungsdetails enthalten Durch Kenntnis bestimmter Umset zungsdetails kann die Software etwas genauer getestet werden als nur anhand der Spezifikation wie es im Black Box Test der Fall ist Da im Grey Box Test nicht die gesamte Quelltextkomple xit t zu berdecken ist ist diese Testart im Vergleich zu White Box Testverfahren mit deutlich weniger Aufwand umsetzbar Somit stellen Grey Box Verfahren einen guten Kompromiss zwi schen der Genauigkeit der White Box und dem vergleichsweise geringem Aufwand von Black Box Testverfahren dar 37 2 Grundlagen 2 6 Modellbasierter Test Modellbasiertes Testen ist eine Testart die formale Modelle benutzt um daraus Testf lle nach vorgegebenen Testkriterien weitgehend automatisch zu generieren Da Modelle auf einer Ab straktionsebene zwischen Code und textueller Spezifikation anzusiedeln sind stellt das modell basierte Testen eine Auspr gung von Grey Box Verfahren dar In wird modellbasiertes Testen Engl Model Based Testing kurz MBT wie folgt definiert Definition 2 6 modellbasierter Test A variant of testing that relies on explicit behaviour mo dels that encode the intended behaviour of a system and possibly the behaviour of its environ ment Laut RBGW 10 gibt es verschiedene Auspr gungen von modellbasierten Testverfahren e modellorientiertes Testen bei diesem Vorgehen werden Modelle nur als Leitfaden benutzt Sie dienen als Grundlage f
135. eichzeitig das Betriebsprofil des Systems und die Kom ponenteninteraktions berdeckung gem ausgew hlter berdeckungskriterien aus und AO04 auf Codeebene ber cksichtigt Die Anwendung von White Box Verfahren bei der Integrationstestfallgenerierung ist aller dings h ufig nicht m glich da der Quelltext der interagierenden Komponenten oft nicht vor liegt dies ist besonders bei Off the shelf Komponenten der Fall Da die Black Box Perspekti ve ebenfalls nicht ad quat ist wurde die Integrationstestfallgenerierung im Rahmen dieser Ar beit ausgehend von einer Grey Box Sicht auf die Komponenten durchgef hrt Es wurden UML Modelle als Eingabe benutzt die das Softwaresystem beschreiben Dabei stellt die UML ver schiedene Diagramme zur Verf gung die sich f r die Modellierung interagierender Komponen ten eignen Besonders Interaktionsdiagramme sind speziell f r die Beschreibung der Kompo Siche Abschnitt Siehe Abschnitt 55 3 Modellbasierte Uberdeckungskriterien nenteninteraktion konzipiert und dienen deshalb in vielen Forschungsarbeiten zum modellbasier ten Integrationstest als Modellierungssprache und Grundlage f r die Testfallgenerierung Die Arbeit von beschreibt berdeckungskriterien f r den Integrationstest die auf die berdeckung von Komponentenschnittstellen ausgerichtet sind Dabei wird nicht explizit an gegeben aus welchen Artefakten Code oder Modell diese Informationen erhoben werden Die Krite
136. el U2TP 7 D E TestContet ATue Oct 04 10 38 58 CEST 2011 H e EM Ex Data ES Population Tes l Oy id Eb gz Comment Teste TestSuites TestCases Ba 3 e Packagelmport Legend Elite History Teste ite TestOne Ti TestCase 1 a a Packagelmport enn nr Range from oldest to late Test Continue Global Optimization E System 4 Errors in c Test Conti Path Ci ontinue Path Coverage E TestSystem i Testt S E auxiliaryResource D Test Save visualisation data ProfileApplications Test ETS DA ProfileApplication es Tes s 57 ProfileApplication E Testt GE e e ee 3 ee E vim ProfileApplications A Test pecie Test S e Test Remove All E D Se A ee netos STestSteps 15 A c e Metu Average TestSteps 8 21 hd PE h Segen Reached finalization 54 5 Ei EI dt 5 3 Individi Number of Testcase 14 Individu Creation Date 2011 10 04 10 38 58 Hide Legend Coverage Fitness z H r Overview Paths and Data Population Distribution MESI Besser E Log E Validation D EB Ek UserControl u18 showCalllnfo gt navigator 2011 10 04 10 40 09 344 INFO Total Time 0 hour 1 min 9 sec 3 4 m H Abbildung B 9 Kontextmen Testsuite 188 UN UnITeD Testgenerator C Users pinte Desktop Infotainment infotainmentuml a File Optimization Test Scripts Mutation Options Window Help 5 Model up E B TestContext_A Fri Sep 30
137. ellt Die Anzahl der ent haltenen Komponenten wird in der Spalte AK angegeben die Spalte M beschreibt die Anzahl der Mappings die in dem jeweiligen Modell vorhanden sind Da nicht alle Mappings ausf hrbar sind gibt die zus tzliche Spalte M ausf die Anzahl der ausf hrbaren Mappings an Modell AK M M ausf CabinControl 6 32 26 Infotainment 2 26 19 Liegenpr fplattz 2 73 65 AK Anzahl Komponenten M Anzahl Mappings M ausf Anzahl ausf hrbare Mappings Tabelle 6 1 Kenngr en der betrachteten UML Modelle mit mehreren Komponenten Die Identifikation nicht ausf hrbarer Mappings wurde manuell durchgef hrt 110 6 2 Parametrisierung der Algorithmen Konto Neben den Modellen die mehrere Zustandsautomaten enthalten wurde ein Beispielmodell er stellt das nur einen Zustandsautomaten enth lt und zwar das Modell Konto Dieses beschreibt die Zust nde eines Geldkontos bei einer Bank Abh ngig von dem Zustand des Kontos z B Gut haben oder berzogen kann der Benutzer bestimmte Funktionen abrufen So kann der Benutzer z B soweit das Konto gedeckt ist Geld abheben Dagegen kann Geld jederzeit eingezahlt werden Um die Generierung von Komponententestf llen an mehreren Beispielen zu evaluieren wur den auch Zustandsautomaten aus den in Tabelle 6 1 beschriebenen Modellen einzeln betrachtet aus Liegenpr fplatz wurde der Zustandsautomat Achstest betrachtet aus dem Modell Infotain ment wurde der Zus
138. en die der Tatsache Rechnung tragen dass ein Aufruf Parameter enthalten kann Zus tzlich zu den Mapping basierten Kriterien betrachten die Message basierten Kriterien die von den Guards der aufgerufenen Transitionen auf dem Wertebereich des Parameters eingef gten Partitionen 64 3 3 Modellbasierte berdeckungskriterien f r den Integrationstest Invoking invoked transitions Invoking transitions on pre states Triggers and effects in on pre states Effects in on pre states Effects on pre states Abbildung 3 3 Subsumptionshierarchie der zustandsbasierten Kriterien aus PS10 Invoking transitions Pre states triggers and effects Pre states and triggers 65 4 Automatische modellbasierte Testfallgenerierung mittels genetischer Algorithmen Dieses Kapitel startet mit einem Motivationsabschnitt in dem die allgemeine Problematik der modellbasierten Testfallgenerierung anhand von Zustandsautomaten dargestellt wird zusammen mit der Beschreibung existierender Ans tze die die automatische Generierung unterst tzen Da bei wird auf die Notwendigkeit des Einsatzes genetischer Algorithmen bei der Testfallgenerie rung eingegangen Danach wird in Abschnitt 2 die allgemeine Funktionsweise genetischer Al gorithmen beschrieben gefolgt von der Darstellung ihrer Anpassung f r die Dom ne der mo dellbasierten Testfallgenerierung in Abschnitt 4 3 4 1 Motivation Wie schon in Ka
139. en Diese Evaluierung wurde anhand der Liegenpr f platz Anwendung durchgef hrt die in Abschnitt 6 I beschrieben ist F r diese Anwendung liegt neben dem UML Modell auch eine manuell erstellte textuelle Testfallspezifikation vor Anhand des UML Modells wurden Testf lle generiert und untersucht inwiefern diese die Erkennung von Implementierungsfehlern erm glichen Zus tzlich dazu wurde der Prozess der manuellen Test fallerstellung mit der modellbasierten Generierung verglichen und in Tabelle 7 3 beschrieben Zusammengefasst wurden diese Ergebnisse bereits in vorgestellt TC TS PU ME DTS Modellbasierte Generierung 36 504 100 18 Stunden 2 Minuten Manuelle Erstellung 2 117 58 12Stunden 6 Minuten TC Anzahl der Testf lle TS Anzahl der Teststeps E Erreichte berdeckung ME Manuelle Erstellungsdauer Modellerstellung vs Testfallerstellung DTS Durchschnittliche Dauer pro Teststep Tabelle 7 3 Vergleich des Aufwands automatische modellbasierte Generierung Kriterium n voking invoked transitions vs manuelle Erstellung Die Spalte ME beschreibt den manuellen Aufwand der in beiden F llen entstanden ist Die manuell erstellten Testf lle wurden anhand der Spezifikation erstellt und in ein Text Dokument zusammengefasst Der Aufwand f r die Erstellung der Testf lle betrug ca 12 Stunden Dabei wurden 2 sehr lange Testf lle generiert die insgesamt 171 Teststeps enthalten F r die Evalu ierung des Potentials modellbasie
140. en Eine Testsuite ist dann angemessen wenn die kumulierte berdeckung der beinhalteten Testf lle hoch und gleichzeitig die Anzahl der Testf lle so gering Beispiele f r Testf lle werden unter anderem in Abschnitt 4 3 1 dargestellt 5Bs wird eingestuft ob sich die Software bei der Ausf hrung eines Testfalls richtig oder falsch verhalten hat 26Engl f r Nachbedingung Bedingung die f r die Software nach Durchf hrung des Tests gilt Engl f r Vorbedingung Bedingung die f r die Software vor Durchf hrung des Tests gilt 22 2 5 Testen wie m glich ist Testen ist eine sehr zeitaufw ndige und kostspielige Aktivit t Deshalb bedarf ein gr ndlicher und systematischer Test einer gut ausgearbeiteten Teststrategie die schon in den fr hen Phasen des Entwicklungsprozesses bestimmt wird Es m ssen qualifizierte Testexperten eingebunden werden die mit der Testplanung gleich nach dem Start des Projekts anfangen Zur Organisation des Testprozesses sind im Allgemeinen folgende Schritte vorgesehen 1 Testplanung In der Planungsphase werden die Testziele festgelegt und bestimmt wie die se zu erreichen sind Unter anderem muss bestimmt werden welches Personal eingesetzt wird welche unterst tzenden Werkzeuge benutzt werden und nach welchen Methoden vorgegangen wird Auch das Testabschlusskriterium muss festgelegt werden bevor alle Ergebnisse in einem Testplan festgehalten werden 2 Testfallgenerierung unter Ber cksichtig
141. en Im Falle der Anwendung dieser Strategie werden keine Platzhalter sondern nur Testtreiber ben tigt In der Praxis kommt es dann oft vor dass Mischformen dieser Strategien zum Einsatz kom men ein Beispiel daf r ist die Outside In Integration Sie versucht die Vorteile der Top Down und Bottom Up Strategien zu verbinden sowohl anwendernahe als auch systemnahe Kompo nenten werden am Anfang integriert und getestet indem erst die Module der obersten und der untersten Softwareschicht integriert werden Danach werden die Komponenten der n chstnied rigen und der n chsth heren Schicht hinzugezogen bis letztendlich die Komponenten der mitt leren Schicht mit betrachtet werden Der Nachteil dabei ist dass sowohl Testtreiber als auch Platzhalter programmiert werden m ssen Sehr selten eingesetzt wird die Strategie Inside Out Integration Durch den Anfang bei den Komponenten der mittleren Softwareschicht bietet sie nicht die Vorteile von Top Down und Bottom Up und hat die gleichen Nachteile wie Outside In 317 B Benutzerschnittstellen Komponenten Auch Sandwich Strategie genannt 26 2 5 Testen Funktionsorientierte Integration Die Strategien dieser Klasse sind auch inkrementell der Unterschied zu den gerade beschrie benen Strategien besteht darin dass die Reihenfolge der Integration jetzt nicht mehr von der Architektur sondern von funktionalen oder operativen Kriterien bestimmt wird Ein Repr sentant dieser Klas
142. en Infotainment und Liegenpr fplatz zu Zus tzlich dazu for dern bezogen auf das Modell Infotainment die Kriterien Invoking invoked transitions und Invoking transitions on pre states die gleiche berdeckung Das gleiche trifft im Modell Cabin Control auf die berdeckungskriterien Triggers and effects in on pre states und Invoking tran sitions on pre states zu Auch Pre states triggers and effects und Invoking transitions fordern auf CabinControl die gleiche berdeckung In der Tabelle 6 5 wird dies wie folgt dargestellt falls zwei Kriterien auf einem Modell die gleiche berdeckung fordern dann wird nur die rech te Zelle ausgef llt in der linken Zelle ist blo ein Verweis auf die rechte Nachbarzelle vorhanden Modell KI K2 K3 K4 K5 K6 K7 K8 CabinControl 13 15 14 21 16 25 20 32 26 Infotainment 13 15 5 1814 22 17 26 19 LPP 23 27 21 39 34 45 40 69 61 73 65 Kl Pre states and triggers K2 Pre states triggers and effects K3 Invoking transitions K4 Effects on pre states K5 Effects in on pre states K6 Triggers and effects in on pre states K7 Invoking transitions on pre states K8 Invoking invoked transitions Tabelle 6 5 Anzahl der zu berdeckenden Mapping Gruppen Die Ergebnisse der Testfallgenerierung f r den Integrationstest werden in Tabelle 6 6 beschrie 117 6 Evaluierung der vorgestellten Testfallgenerierungsmethode ben Ein Teil dieser Er
143. en Integrationstest aus SOPO7 61 6 1 Kenngr en der betrachteten UML Modelle mit mehreren Komponenten 110 6 2 Kenngr en der Zustandsautomaten aus denen Komponententestf lle generiert ap ak ap de Eee a 12 6 3 Ergebnisse der Komponententestgenerierung e 114 6 4 Ergebnisse der Testfallgenerierung f r den Komponententest nach einem weite ren Optimierungsschritt 22e 115 6 5 Anzahl der zu berdeckenden Mapping Gruppen 117 6 6 Ergebnisse der Testfallgenerierung f r den Integrationstest 118 6 7 Ergebnisse der Testfallgenerierung f r den Integrationstest nach einem weiteren Optimierungsschritt eda ah 22 44 NA e E CRI 119 7 1 Ergebnisse der Mutationsanalyse f r Komponententestf lle 140 7 2 Ergebnisse der Mutationsanalyse f r Integrationstestf lle 148 7 3 Vergleich des Aufwands automatische modellbasierte Generierung Kriterium Invoking invoked transitions vs manuelle Erstellung 155 173 A UML Modelle SetMSPars_5_Accepted FirstExecution false SetMSPars 5 Reported m Sept 4 FirstExecution false FirstExeoution taise SetMSPar 3 SeiMSPars_2 FirstExecution false FFirstExecution false StortAchstest2_sbDeviationReported DeviaticnAllowed ImyPar MS1Val PartisiResultEnum TestOK talse myPar
144. en Kompromiss zwischen berdeckung und Testaufwand bietet Andererseits werden Verfahren vorgestellt Random Search Simulated Annealing Multi ob Jective Aggregation die diese zwei Ziele zu einer einfachen Zielfunktion durch eine gewichtete Summe zusammenfassen Am Ende der Generierung steht in diesem Fall eine einzige Testsui te zur Verf gung Diese Vorgehensweise nennt der Autor pseudo multi objektiv da die Ziele nicht v llig unabh ngig voneinander wie im Falle des Verfahrens NSGA betrachtet werden Bei dieser Vorgehensweise m ssen im Gegensatz zum NSGA Verfahren vor dem Start der Generierung die Gewichte f r die Zielfunktion festgelegt werden Nach der Definition aus Ost07 ist das in Abschnitt 4 3 beschriebene Verfahren auch als pseu do multi objektiv zu bezeichnen Im Folgenden beschreibt Abschnitt 4 2 die allgemeine Vorge hensweise genetischer Algorithmen gefolgt von der Beschreibung der Anpassung der Algorith men an die Dom ne der modellbasierten Testfallgenerierung 4 2 Allgemeine Funktionsweise genetischer Algorithmen Genetische Algorithmen imitieren evolution re Prozesse die in der Natur zu beobachten sind und von Charles Darwin in seiner Evolutionstheorie Dar59 beschrieben wurden Diese Algorithmen wurden von John Holland in Hol75 eingef hrt und st tzen sich auf das Prinzip Survival of Siehe Abschnitt 3D h dass es keine andere Testsuite gibt die sowohl eine h here berdeckung erreich
145. en bei der Kreuzung auf Testfall oder Aufrufebene im Ein zelfall zum Einsatz kommt wird bei jeder Anwendung des Rekombinationsoperators zuf llig ausgew hlt F r die Rekombination auf Ebene der Daten gibt es ebenfalls mehrere Auspr gungen Diese haben gemeinsam dass anhand der beiden Werte ein neuer Wert generiert wird der dem Para meter aus dem ersten Individuum zugeordnet wird Abh ngig vom Typ der Daten gehen auch die Operatoren unterschiedlich vor Hier werden nur die Operatoren beschrieben die auf nummeri schen Parametern agieren da die Beschreibung der Operatoren f r alle m glichen Datentypen den Rahmen sprengen w rde Eine Auspr gung davon ist der AverageOperator der den neuen Wert durch Mittelung berech net Falls der RandomInterval Operator angewendet wird wird der neue Wert zuf llig aus dem Intervall zwischen den zwei betrachteten Werten ermittelt Der SinglePoint Operator betrachtet die Werte als Liste von Ziffern setzt f r jeden Wert einen zuf lligen Kreuzungspunkt an und tauscht die Ziffern ab dem Kreuzungspunkt zwischen den Werten aus Welcher dieser Auspr gungen bei der Kreuzung auf Datenebene im Einzelfall zum Einsatz kommt wird aus diesen drei Alternativen zuf llig ausgew hlt Bei jeder Anwendung des Rekombinationsoperators werden also zwei zuf llige Entscheidun gen getroffen Erstens auf welcher Ebene die Rekombination stattfinden soll Abh ngig von der getroffenen Auswahl wird in einem zweiten
146. er Hilfsgraph enth lt in den Knoten die Messages aus dem Se quenzdiagramm eine Kante im Graphen gibt die Reihenfolge wieder in der die Messages die die Kante verbindet aufgerufen werden Auch der Ansatz von basiert auf Transforma tionen des Sequenzdiagramms in einen Graphen dem Labeled Transition System Kurz LTS Im Unterschied zum MFG werden die Message Informationen an den Kanten gespeichert und nicht an den Knoten Der in beschriebene Ansatz erlaubt die Generierung von Testse quenzen anhand des aus Zustandsautomaten und Kommunikationsdiagrammen generierten State Collaboration Test Model Kurz SCOTEM Das berdeckungsziel dieser Ans tze ist es die Knoten bzw die Kanten dieser Hilfsgraphen zu berdecken Gemeinsam haben all diese Ans tze dass sie statisch vorgehen und mittels Gra phensuchalgorithmen Testsequenzen zu erzeugen erlauben Auch Ans tze zur Testfallgenerierung f r den Komponententest wie z B KHC 99 LIO7 WS07 KR03 gehen statisch vor Um Testf lle zu generieren die Uberdeckungskriterien f r den Komponententest erf llen werden Pfade aus den Diagrammen generiert um dann anhand der Trigger an den Transitionen dieser Pfade Testsequenzen zu erstellen Problematisch ist diese statische Vorgehensweise deshalb da die Guards der Transitionen nicht ber cksichtigt werden und dadurch auch Pfade entstehen die nicht ausf hrbar sind Des Weiteren m ssen f r die generierten Testsequenzen geeignete Testdaten
147. er betrachtete Testfall sei opA1 4 opB1 69171531 opA2 opA3 Die Bestimmung der berdeckten Entit ten wird im Folgenden Schritt f r Schritt erkl rt e Schritt 1 Instanziiere und initialisiere die Simulatoren Komponente A ist im Zustand A und Komponente B ist in Zustand B da die Transitionen tA und B keinen Trigger besitzen und somit gleich durchlaufen werden e Schritt 2 Bearbeitung des ersten Aufrufs der Testfalls opA1 4 Dieser Aufruf wird an den 81 4 Automatische modellbasierte Testfallgenerierung mittels genetischer Algorithmen Simulator der Komponente A geschickt Der Guard von 1A3 wird zu true ausgewertet weil 4 gt 0 ist der internen Variablen x wird der Wert 4 zugewiesen und die Transition tA3 wird traversiert Der neue aktive Zustand von A ist A2 Schritt 3 Bearbeitung des zweiten Aufrufs des Testfalls opB1 69171531 Dieser wird an den Simulator von B geschickt Der internen Variablen y von B wird der Wert 69171531 zugewiesen die Transition tB2 wird traversiert Somit ist B2 der neue aktive Zustand von B Schritt 4 Bearbeitung des dritten Aufrufs des Testfalls opA2 Dieser wird an den Simu lator der Komponente A verschickt Da der Guard der Transition tA5 zu true ausgewertet weil x 4 was kleiner als 5 ist wird wird diese Transition durchlaufen was den neuen aktiven Zustand A4 der Komponente A zur Folge hat Schritt 5 Bearbeitung des vierten Aufrufs des Testfalls opA3 Diese
148. erdeckung Sc e Transitions berdeckung verlangt dass jede Transition t Tc eines Zustandsautomaten durchlaufen wird hnlich wie die Zweig berdeckung auf Codeebene gilt die Transitions berdeckung als das minimale Testkriterium bei der Generierung von Testf llen aus Zu standsautomaten Dass dies sinnvoll ist wurde auch im Rahmen der Evaluierung verschie dener berdeckungskriterien festgestellt da die Testf lle f r Transitions berdeckung deut lich mehr Fehler erkannten als Testf lle f r Zustands berdeckung Transitions berdeckung Tc e Transitionspaar berdeckung verlangt dass f r jeden Zustand S Sc der Zustandsmaschi ne einer Komponente C jede eingehende Transition aus Eks in Kombination mit jeder aus 5Siehe Abschnitt 52 3 2 Modellbasierte berdeckungskriterien f r den Komponententest gehenden Transition aus Aks also jedes Transitionspaar des Zustandsautomaten getestet wird Transitionspaar berdeckung Y Eks x Aks T Pc SESC e Pfad berdeckung dieses Kriterium verlangt die berdeckung aller Pfade durch den Zu standsautomaten hnlich wie auf Codeebene ist dieses Kriterium allerdings im Allge meinen nicht erf llbar Deshalb existieren auch abgeschw chte Formen dieses Kriteriums z B das in beschriebene All One Loop Paths Kriterium welches die berde ckung aller schleifenfreien Pfade und die berdeckung der Pfade mit einem einmaligen Schleifendurchlauf
149. eren wurde das in Kapitel 5 beschrie bene Werkzeug UnITeD um ein Modul erweitert das diese Bewertung unterstiitzt indem es zwei Funktionalit ten zur Verf gung stellt e Mutantengenerierung In einem ersten Schritt werden zun chst Mutanten durch Einf gen von nderungen in ein so genanntes initiales Modell erzeugt Dazu wurden eine Reihe von Modell Mutationsoperatoren implementiert die Details zu den einzelnen Operatoren werden in Abschnitt 7 1 2 2 beschrieben e Mutationsevaluation Im Anschluss an die Generierung von Mutanten werden diese mit der zu bewertenden Testsuite ausgef hrt um zu bestimmen welche Mutanten durch die Test suite erkannt werden Daraufhin wird der so genannte Mutation score kurz MS berechnet der den prozentualen Anteil an erkannten Mutanten wiedergibt Neben der Berechnung des Mutation scores erlaubt diese Evaluation auch die Ergebnisse bez glich einzelner Klassen von Mutationen zu bestimmen Die Formel f r die Berechnung des Mutation scores einer Testsuite T S die aus einem Modell MO generiert wurde lautet ID MO Tel ma ower EMO 7 1 Dabei ist M MO die Menge der anhand des Modells MO generierten Modellmutanten E MO die Menge der Modellmutanten die funktions quivalent zum originalen Modell 3Ist das Modell aus dem die zu bewertenden modellbasierten Testf lle erzeugt wurden Siehe Unterabschnitt 7 1 3 1 und 7 1 4 1 125 7 Evaluierung des Fehlererkennungspotentials mo
150. erierung von Modellmutanten wurden Modell Mutationsoperatoren wer den im Folgenden auch einfach Operatoren genannt implementiert die nacheinander auf einem initialen Modell ausgef hrt werden und somit eine Menge von Mutanten erzeugen Alle Operato ren gehen nach dem in Abbildung 7 2 beschriebenen generischen Muster vor Mit Ausnahme des Operators Zustand L schen der alle Zust nde betrachtet betrachten die einzelnen Operatoren ausgew hlte Transitionen aus den Zustandsautomaten des Modells In Abbildung 7 2 beschreibt betrachteteEntit ten die Menge der betrachteten Transitionen oder Zust nde Diese Menge enth lt alle Transitionen eines Zustandsautomaten falls die Opera toren auf ein Modell angewendet werden das nur eine Komponente C mit einem dazugeh rigen Zustandsautomaten enth lt betrachteteEntitdten Tc Analog beinhaltet die Menge aller be Nicht zu verwechseln mit den genetischen Operatoren die in Abschnitt beschrieben werden 130 7 1 Erkennungspotential hinsichtlich Modellierungsfehler Parameter Modell das initiale Modell betrachteteEntit ten Menge an betrachtenden Transitionen Zust nden aus dem Modell for all t in betrachteteEntit ten do if bedingungErf llt t then mutantenMenge operator t for all m in mutantenMenge do if mutantSyntaktischKorrekt m then speichere m endif endfor endif endfor Ergebnis Menge von Mutanten die auf der Festplatte abgespeichert werden Abbildung
151. erlag 2004 Santosh Kumar Swain and Durga Prasad Mohapatra Test Case Generation from Behavioral UML Models International Journal of Computer Applications 6 2010 Simone Do Rocio Senger De Souza Jos Carlos Maldonado Sandra Camargo Pin to Ferraz Fabbri and Wanderley Lopes De Souza Mutation Testing Applied to Estelle Specifications In Proceedings of the 33rd Hawaii International Conference on System Sciences 2000 Dehla Sokenou Testfallgenerierung aus Statecharts und Interaktionsdiagrammen Softwaretechnik Trends 24 2004 Ian Sommerville Software Engineering Addison Wesley 2010 Francesca Saglietti Norbert Oster and Florin Pinte Interface Coverage Criteria Supporting Model Based Integration Testing In Marco Platzner Karl Erwin Gro pietsch Christian Hochberger and Andreas Koch editors ARCS 07 Workshop Proceedings Workshop proceedings of the 20th International Conference on Ar chitecture of Computing Systems ARCS 2007 pages 85 93 Z rich 2007 VDE Verlag GmbH Berlin Offenbach Francesca Saglietti Norbert Oster and Florin Pinte White and Grey Box Verifi cation and Validation Approaches for Safety and Security Critical Software Sys tems Information Security Technical Report 13 1 10 16 March 2008 DOI 10 1016 j istr 2008 03 002 Francesca Saglietti and Florin Pinte Automated Unit and Integration Testing for Component based Software Systems In Brahim Hamid Carsten Rudolph and Christoph Ru
152. ert and Hasan Ural Model based Regression Test Suite Generation Using Dependence Analysis In Proceedings of the 3rd interna tional workshop on Advances in model based testing pages 54 62 New York NY USA 2007 ACM Charles Darwin On the Origin of Species by Means of Natural Selection Murray London 1859 Edsger W Dijkstra Notes on Structured Programming Technical report Techno logical University Eindhoven 1970 Marcio E Delamaro Jos C Maldonado and Aditya P Mathur Interface mutation An approach for integration testing IEEE Trans Softw Eng 27 3 228 247 2001 Wolfgang Domschke and Armin Scholl Heuristische verfahren Jenaer Schrif ten zur Wirtschaftswissenschaft 08 2006 Friedrich Schiller Universit t Jena Wirt schaftswissenschaftliche Fakult t 2006 T Dinh Trong A Systematic Approach to Testing UML Designs Dissertation Colorado State University Fort Collins Colorado 2007 Q Farooq M Iqbal Z Malik and A Nadeem An Approach for Selective State Machine based Regression Testing In Proceedings of the 3rd international work FMSM99 GVEBOS Hof08 Hol75 IEE90 IEE91 Ist10 JH09 JO98 JS05 Jun07 KHC 99 LITERATURVERZEICHNIS shop on Advances in model based testing pages 44 52 New York NY USA 2007 ACM Sandra Camargo Pinto Ferraz Fabbri Jos Carlos Maldonado Tatiana Sugeta and Paulo Cesar Masiero Mutation Testing Applied to Valid
153. erung des Fehlererkennungspotentials modellbasierter Testf lle lich Das bedeutet dass der Zustand in dem sich MainControl befindet f r den Benutzer dieses Systems nicht erkennbar ist Der Benutzer kann nur beurteilen ob z B die T ren auf einem Stockwerk offen oder geschlossen sind Die gerade beschriebe Vorgehensweise entspricht dem in der Literatur zum Code basierten Mutationstest bekannten starken Mutationstest da bei der Bewertung des Testfalls hinsichtlich seiner F higkeit den Mutanten zu erkennen nur die Ausgaben des Systems betrachtet werden Im Gegensatz zu diesem Vorgehen h tte ein schwacher Modell Mutationstestansatz bedeutet dass die Analyse alle Zust nde betrachtet die bei der Abarbeitung des Testfalls durchlaufen wurden Ein Mutant kann nicht erkannt werden wenn er funktions quivalent zum initialen Modell ist In diesem Fall gibt es keinen Testfall der diesen Mutanten erkennt Die in Abschnitt 7 1 3 und 7 1 4 beschrieben Mutation scores wurden alle ohne Ber cksichtigung der funktions quivalen ten Mutanten berechnet Somit ist der Wert f r E MO immer gleich 0 Deshalb sind die im Folgenden angegebenen Mutation scores auch als pessimistisch zu bezeichnen Bevor sinnvolle Modell Mutationsoperatoren definiert werden k nnen m ssen zun chst ty pische Modellierungsfehler f r Zustandsautomaten identifiziert und klassifiziert werden Diese Klassifikation wird im folgenden Unterabschnitt beschrieben gefolgt von
154. esen Modellen handelt es sich sowohl um Beispielmodelle als auch um ein Mo dell das das Verhalten einer in Entwicklung befindlichen Software beschreibt Die Diagramme die das Verhalten der im Folgenden eingef hrten Komponenten beschreiben werden in Anhang Aldargestellt Liegenpr fplatz Das aus dem medizintechnischen Umfeld stammende Modell Liegenpriifplatz beschreibt das Ver halten einer in Entwicklung befindlicher Software zur Steuerung und berpr fung von Patienten 108 6 1 Evaluierte Anwendungen liegen berpr ft wird dabei ob die Positionierung der Liege nach bestimmten Liegenbewegun gen korrekt ist Um diese Funktionalit t zu realisieren kontrolliert und verwaltet diese Software mehrere Pr fschritte und erlaubt es am Ende der Durchf hrung der Schritte ein Protokoll ber die ausgef hrten Pr fschritte zu speichern Die Software besteht aus zwei Komponenten die Komponente Achstest erm glicht es dem Benutzer die Pr fschritte ber eine GUI zu verwalten die Komponente PartialResult ist f r das Speichern des Protokolls verantwortlich CabinControl Bei den Beispielmodellen handelt es sich um Modelle die aus einzelnen oder mehreren kom munizierenden Komponenten bestehen Zu den Modellen mit mehreren Komponenten z hlt das Modell CabinControl das eine Aufzugsteuerung mit sechs Komponenten beschreibt welche in einem Geb ude mit drei Stockwerken eingesetzt werden kann bersichtlich werden die einzel nen Kompo
155. f Dies bedeutet dass der Zustandsautomat im selben Zustand verbleibt in dem er vor dem Eintreffen des Aufrufs war 3Falls die Transition keinen Guard hat also falls g t _ dann gilt der Guard immer als erf llt 48 3 1 Verhaltensbeschreibung von Komponenten mittels UML Zustandsautomaten Im weiteren Verlauf dieses Kapitels werden berdeckungskriterien f r den Komponenten und Integrationstest vorgestellt Zu jedem Kriterium das im Rahmen dieser Arbeit bei der Test fallgenerierung eingesetzt wurde wird eine Formel angegeben die es erlaubt die Anzahl der zu berdeckenden Entit ten zu berechnen Zun chst m ssen deshalb an dieser Stelle ein paar zus tzliche Konzepte eingef hrt werden Manche Konzepte werden erst sp ter bei der Beschrei bung der Modell Mutationsoperatoren in Abschnitt 7 1 2 2 ben tigt Sei COMP die Menge aller Komponenten eines Softwaresystems f r jede Komponente C COMP werden im Folgenden ein Reihe von Begriffen beschrieben von denen ein Gro teil in SOP07 eingef hrt wurden e Sc die Menge der Zust nde von C Beispiel 4 A0 Al A2 A3 A4 A5 e Tc die Menge der Transitionen von C Beispiel TA tAl tA2 tA3 tA4 tA5 tA6 tA7 tA8 e F r einen Zustand S Sc seien die Mengen der damit verbundenen Kanten wie folgt defi niert Eks t Tc post t S Menge der in Zustand S eingehenden Transitionen Beispiel Die Menge aller eingehenden Transitionen des Z
156. falls opA4 true Dieser wird an den Simulator von A geschickt da aus dem aktiven Zustand A2 die Transition tA7 mit Trigger opA4 j boolean existiert und der Guard der Transition erf llt ist wird diese Transition als Folge dieses Aufrufs durchlaufen Somit ist Zustand A3 der neue aktuelle Zustand der Komponente A e Schritt 4 Bearbeitung des dritten Aufrufs des Testfalls opA5 Dieser wird an den Simu lator von A geschickt da aus dem aktiven Zustand A3 die Transition AS mit Trigger opA5 existiert wird diese Transition als Folge dieses Aufrufs durchlaufen Somit ist Zustand A3 der neue aktuelle Zustand der Komponente A Dieser Testfall berdeckt also folgende Transitionen tA tA3 tA7 tA8 D h dass von den insgesamt acht Transitionen durch diesen Testfall vier Transitionen berdeckt werden Eine Test suite die nur diesen Testfall enth lt erreicht also eine 50 ige Transitions berdeckung Um alle Transitionen zu berdecken m sste die Testsuite um zus tzliche Testf lle erweitert werden z B um folgende drei Testf lle opAl 4 opA2 opA3 berdeckt zus tzlich die Transitionen tA5 und tA6 0pA1 1230053765 berdeckt zus tzlich die Transition tA4 opA5 berdeckt zus tzlich die Transition tA2 Am folgenden Beispiel wird gezeigt wie die berdeckung eines Integrationstestfalls f r die Komponenten A und B aus Abbildung B 2 gemessen wird berdeckungsziel ist berdeckung der zwei Mappings m und m2 D
157. fgerufenen Komponente betrachtet ist dieses Ergebnis nicht berraschend Die detaillierten Ergebnisse der Mutationsanalyse f r die Testfallmengen die anhand des Mo dells Infotainment generiert wurden werden in Abbildung dargestellt Wie schon vorhin erw hnt erkennt K3I genau die gleichen Mutanten wie K8I was zur Folge hat dass diese zwei 19Die Mutanten die durch den Operator Aufruf L schen erzeugt wurden geh ren zur Klasse der Effect Mutationen 152 7 1 Erkennungspotential hinsichtlich Modellierungsfehler Testfallmengen auch bei der Betrachtung pro Mutationsklasse identische Ergebnisse aufweisen Bez glich vier der f nf Klassen schneiden beide sehr gut ab da alle Mutationen dieser vier Klassen entdeckt werden Die einzige Ausnahme stellt die Klasse Guard Mutationen dar da be z glich dieser mit einer Ausnahme alle Testfallmengen gleich schlecht abschneiden E Invoking invoked transitions K81 E Invoking transitions on pre states K71 B Triggersand effectsin on pre states K61 W Effects in on pre states KSI m Effects on pre states K41 f E Invoking transitions K3I E Pre states triggers and effects K21 u Pre states and triggers K11 Abbildung 7 8 Fehlererkennungspotential bzgl einzelner Mutationsklassen von Testfallmen gen die zustandsbasierte Integrationstestkriterien auf dem Modell Infotainment erf llen Abbildung zeigt die detaillierten Erge
158. ge criterion Properties Reached coverage E TestSteps Average TestSteps Reached finalization Number of Testcase og E Validation m Abbildung B 1 Startbildschirm des Werkzeugs UnITeD 184 Load Model Unload Model Open File Save File Save Testsuites Delete Testsuites File Abbildung B 2 Men punkt File File Optimization TestScripts Mutation Options Window Help 166K 5 Model Sum E Abbildung B 3 Anzeige des geladenen Modells im Modellbaum 185 B Werkzeug UnITeD 186 UN UnITeD Testgenerator C Users pinte Desktop Modell Modell uml File Optimization Test Scripts Mutation Options Window Help GG 5 Model u2TP EI Ho bm X TestSuites TestCases Coco Com EE Criterium for Component Test Criterium for Integration Test Edge Pair Coverage Invoking Transition UN UnITeD Testgenerator C Users pinte Desktop Modell Modell uml File Optimization TestScripts Mutation Options Window Help Bail E Model up EI D Testsuites a Auto Adjust y E Properties Properties of Model Owned Element C Owner Owned Comment Optimization Conditions Coverage
159. gebnisse wurde bereits in vorgestellt Jede generierte Testsuite er reicht eine 100 ige berdeckung bez glich der ausf hrbaren Mapping Gruppen F r den Fall dass zwei Kriterien die gleiche berdeckung fordern wurden nicht zwei Testfallmengen gene riert die jeweils beide Kriterien erf llen sondern nur eine Testfallmenge die beiden Kriterien gen gt Analog zu Tabelle 6 5 gibt das Symbol in Tabelle 6 6 an dass die entsprechenden Testf lle die gleichen sind wie in den rechten Nachbarzellen M Kl K2 K3 K4 K5 K6 K7 K8 TC TS TC TS TC TS TC TS TC TS TC TS TC TS TC TS C 4 19 6 30 3 34 2 33 3 4 5 59 I 4 36 2 55 2 14 5 60 4 65 3 75 L 7 96 13 185 12 133 13 171 17 264 33 453 36 504 M Betrachtetes Modell C CabinControl I Infotainment L Liegenpr fplatz TC Anzahl generierter Testf lle TS Anzahl generierter Teststeps K1 K8 siehe Tabelle 6 5 Tabelle 6 6 Ergebnisse der Testfallgenerierung fiir den Integrationstest Tabelle 6 6 zeigt dass sich die Hierarchie der berdeckungskriterien im Allgemeinen auch in der Anzahl an Testf llen und Teststeps widerspiegelt je anspruchsvoller das Kriterium desto mehr Testf lle werden f r seine Erf llung ben tigt Allerdings gibt es auch Ausnahmen z B werden f r die Erf llung des Kriteriums nvoking transitions auf Infotainment zwei Testf lle generiert wogegen zur Erf llung des schw cheren Kriteriums Pre states triggers and effects vie
160. gen Kollegen Norbert Dirk Gerd Josef Jutta Andrea f r die tolle Zusammenarbeit und die sch nen gemeinsamen Erlebnisse In diesem Zusammenhang gilt mein Dank auch den Studien und Diplomarbeitern die ich betreuen durfte Bedanken m chte ich mich auch bei der Firma Afra GmbH insbesondere bei Herrn Mirco Richter und bei Herrn Gerhard Baier Mein tiefster Dank gilt meiner Familie und meinem Freundeskreis sowie ganz besonders mei ner Freundin Elisabeth die mich in allen Lebenslagen unterst tzt haben iii Inhaltsverzeichnis Inhaltsverzeichnis iv 1 Ll Motivation 2 lt 6c42ide8 5H 5e 5e4 5 e444 45 4454558 4246 4 1 NEED eR rs Gee Web Wee ee Ae EE ee eee eS 3 1 3 Ghe der gj IL 6 8 2 1 Modellbasierte Softwareentwicklung 2 2 22 a 8 eng Ok ar Gee d Ya Ya ee re re ae as amp 11 2 3 Komponentenbasierte Softwareentwicklung 2 22 22 nennen 16 at 893 208 OS Xs SORS RR GRE ORC RU 18 rOr c EE een a a 21 2 1 Tesipbasen lt i iaci ih awh au oh ere au i ie rie ite lg 24 2 5 1 1 Komponententest es SEN 2 22 448 EEN RR 24 23 1 2 Inlegrationstest 244 22 e RR oes de eee eee 23 213 OC a u soe 3r mc 9o dk EORR ROCK Re XL a 27 2 5 1 4 Abnahmetest ex x 44 2 e De e we a 29 2 5 1 5 Regressionstest 2 2343 939 22 42 a 29 T aa aoa d a 228 a aa ee oe aa Gaia oe Boas 31 2321 Bl ck Bor KEEN 31 iv 2 722 While Bor TEN EES 32 2323 Grey Box les nodo 424 a a 9 ae a ee
161. genetischer Algorithmen bei der Integrationstestgenerierung erreicht wurden werden in Abschnitt 6 4 be schrieben Auch f r Integrationstestf lle kann mittels des Werkzeugs visualisiert werden welche Entit ten berdeckt wurden und welche Entit ten noch zu berdecken sind Diese Funktionalit t wird in Abschnitt 5 2 beschrieben Bewertung modellbasierter Testf lle hinsichtlich ihres Fehlererkennungspotentials bez glich Modellierungs und Implementierungsfehler Eine weitere Zielsetzung dieser Arbeit ist die Bewertung des Fehlererkennungspotentials von Testfallmengen die modellbasierte berdeckungskriterien f r den Komponententest oder Inte grationstest erf llen Dazu wurde zun chst ein Mutationstest auf Modellebene durchgef hrt um zu bewerten inwiefern Modellfehler entdeckt werden k nnen siehe Abschnitt 7 I Um das Po tential hinsichtlich der Erkennung von Implementierungsfehlern zu evaluieren wurde eine mo dellbasiert generierte Integrationstestfallmenge auf eine Software f r die Steuerung und ber priifung von Patientenliegen ausgefiihrt siehe Abschnitt 7 2 All diese Zielsetzungen wurden im Rahmen des Forschungsprojekts Unterst tzung Inkremen teller Testdaten Kurz UnITeD verfolgt Dieses Projekt wurde im Auftrag des Bayerischen Wirt schaftsministeriums von den Verbundpartnern Lehrstuhl f r Software Engineering und der Afra GmbH in Erlangen durchgef hrt Dabei entstand zwischen den Jahren 2006 und 2009 ein Verfah
162. gibt die in Som10 wie folgt klassifiziert werden e Fault repairs falls beim Einsatz in der Kundenumgebung Fehler auftreten m ssen diese im Rahmen einer Fehlerkorrektur behoben werden Dies wird auch als Corrective Mainte nance fehlerbehebende Wartung bezeichnet e Environmental adaption falls sich die Randbedingungen f r den Einsatz der Software 29 2 Grundlagen beim Kunden ndern z B ein unterschiedliches Betriebssystem muss die Software daran angepasst werden Ein anderer Begriff f r diese Wartungsart ist Adaptive Maintenance anpassende Wartung e Functionality addition Diese Wartungsart wird dann durchgef hrt wenn sich die Anfor derungen des Kunden ndern oder der Kunde neue Funktionalit ten ben tigt Sie wird auch noch Perfective Maintenance vervollkommende Wartung genannt Nicht in der Klassifikation enthalten aber trotzdem erw hnenswert ist die Preventive Mainte nance vorbeugende Wartung Diese Wartungsart hat das Ziel die Software so zu ndern dass sp tere Wartungseingriffe jeglicher Art erleichtert werden Dazu geh ren z B die Aktualisierung der Dokumentation und Code Refactorings In der Praxis kann nicht jede nderung immer eindeutig einer bestimmten Wartungskategorie zugeordnet werden So kann es z B vorkommen dass bei der Anpassung an neue Randbedin gungen zus tzliche Funktionalit ten hinzugef gt werden um aus den neuen Randbedingungen den gr tm glichen Nutzen zu
163. gt die durch das Kriterium nvoking invoked transitions durchgef hrte Partitionierung der Mappings Dieses Kriterium verlangt also die berdeckung beider Mappings da die Map pings auf zwei Zeilen getrennt dargestellt werden Darunter zeigt die Notiz b die vom Kriterium Invoking transitions on pre states durchgef hrte Partitionierung F r die Erf llung dieses Krite riums reicht es wenn eines der zwei Mappings berdeckt wird KEN tAB tB4 hg D T tA3 opA2 x lt 5 opA3 tb apB2 i int i gt 0 cei A2 tas b tA6 tB3 tA6 tB4 tA7 opA1 i int i lt 0 nan X j boglean j true A4 tA1 Abbildung 5 5 Zustandsautomat erg nzt um Notizen mit Mappinginformationen PSN09 Nachdem die zu berdeckenden Mappings durch Notizen festgehalten wurden kann innerhalb dieser Notizen nun markiert werden welche Mappings durch eine Testsuite berdeckt wurden Dies wird durch nderung der Textfarbe in den Notiztextfeldern realisiert Die benutzten Farben sind e Gr n wenn das Mapping von der Testsuite berdeckt wird e Rot wenn es nicht berdeckt wird Nachdem Abbildung 5 5 zeigt wie die zu berdeckenden Mappings festgehalten werden be schreibt Abbildung wie die berdeckten Mappings farblich markiert werden Dazu wurde eine Testfallmenge aus diesem Modell generiert die Visualisierungsinformationen abgespeichert und ins Modellierungswerkzeug geladen Da durch
164. h wie vielen Generationen die 100 ige berdeckung erreicht wird In dieser Hinsicht k nnte auch ein weite res Abbruchkriterium f r den Algorithmus sinnvoll sein wie z B 100 ige berdeckung plus 200 zus tzliche Generationen 6 4 Ergebnisse der Testfallgenerierung f r den Integrationstest Neben der Komponententestgenerierung erlaubt das Werkzeug UnITeD auch die vollautomati sche Generierung von Integrationstestf llen Dabei werden die acht in Abschnitt 3 3 2 beschrie benen berdeckungskriterien unterst tzt Bevor die Ergebnisse der Testfallgenerierung beschrie ben werden stellt die Tabelle 6 5 fiir jedes Kriterium dar in wie viele Mapping Gruppen dieses Kriterium die Menge aller Mappings partitioniert Da Mapping Gruppen die nur nicht ausf hr 8Siehe Abschnitt 116 6 4 Ergebnisse der Testfallgenerierung f r den Integrationstest bare Mappings enthalten nicht berdeckt werden k nnen stellt die Tabelle 6 5 neben der Anzahl der Mapping Gruppen auch in Klammern die Anzahl der ausf hrbaren Mapping Gruppen dar die Klammer wird nur angegeben falls nicht alle Mapping Gruppen ausf hrbar sind Generell kann es vorkommen dass zwei oder mehrere berdeckungskriterien auf bestimm ten Modellen die gleiche berdeckung fordern d h sie partitionieren die Menge der Mappings gleich Dies trifft unter anderem f r die Kriterien Pre states and triggers und Pre states triggers and effects bez glich den Modell
165. he ingenieurm ige Herangehensweise bezeichnet man als konstruktive Qualit tssiche rung Jedoch lassen sich trotz ingenieurm iger Softwareentwicklung aufgrund menschlichen Un verm gens Softwarefehler nicht ganz vermeiden An dieser Stelle m ssen analytische Qualit ts sicherungsverfahren eingesetzt werden Diese lassen sich in zwei Klassen aufteilen je nachdem welches Ziel verfolgt wird e Verifikation unter Verifikation versteht man die 19 Grundlagen berpr fung ob die Ergebnisse einer Entwicklungsphase die Anforderungen zu Beginn der Phase erf llen Lig09 Beispiele f r Verifikationst tigkeiten sind der Komponenten und Integrationstest e Validierung Validierung wird in L1g09 wie folgt definiert berpr fung ob ein Software Produkt die Anforderungen und Bed rfnisse des Benutzers befriedigt Im Gegensatz zur Verifikation wird also im Rahmen der Validierungsaktivit ten berpr ft ob die vom Kunden tats chlich gew nschte Funktionalit t umgesetzt wurde Beispiel f r eine Validierungsaktivit t ist die Spezifikation dahingehend zu berpr fen ob sie die Kun denw nsche korrekt und vollst ndig wiedergibt Unabh ngig von dem konkreten Ziel lassen sich analytische Qualit tssicherungsverfahren nach Lig09 wie folgt kategorisieren e statische Verfahren dies sind Verfahren die eine Bewertung der Artefakte z B Modelle oder Quelltext vornehmen ohne diese dabei auszuf
166. hen Struktur eines Systems Die Menge der Strukturdiagramme umfasst folgende Elemente e Klassendiagramm Engl Class Diagram ist eines der meist benutzten Strukturdiagram me der UML Es erlaubt die Modellierung von Klassen und deren Beziehungen unterein Die aktuelle Version der UML Spezifikation ist verf gbar unter http www omg org spec UML Current 12 2 2 Unified Modeling Language W Structure Behavior Diagram Diagram A W gt Component Object Activity Use Case State Machine Class Diagram Diagram Diagram Diagram Diagram Diagram Deployment Package Interaction Diagram Diagram Diagram f Composite Structure Diagram Interaction Overview Diagram Profile Diagram Sequence Diagram Communication Timing Diagram Diagram Abbildung 2 1 Die Diagramme der UML aus OMG 10 s 720 ander e Profildiagramm Engl Profile Diagram eine der St rken der UML ist dass sie sehr gut mittels Profilen an die spezifischen Anforderungen des Kunden angepasst werden kann Das Profildiagramm erlaubt die Beschreibung und Gruppierung eigendefinierter Stereoty pen e Paketdiagramm Engl Package Diagram da Modelle mit vielen Klassen schnell un ber sichtlich werden k nnen erlaubt dieses Diagramm eine bersichtliche Darstellung des Systems indem Pakete und deren Beziehungen dargestellt werden e Objektdiagramm Engl Object Diagram zur Laufzeit von objektorientierten
167. hnitt betrachteten Verfahren zielen auf die berpr fung der Qualit tsmerk male eines Softwaresystems Dabei kann Softwarequalit t aus zwei Blickwinkeln betrachtet wer den Die externe Qualit t bezieht sich auf die Erf llung von Eigenschaften die von einem belie bigen Benutzer der Software bewertbar sind wie z B Korrektheit Benutzerfreundlichkeit Ro bustheit Zuverl ssigkeit Verf gbarkeit Als interne Qualit t bezeichnet man die Erf llung von Eigenschaften die nur von Personen bewertet werden k nnen die Einblick in den Quellcode der Komponente haben Bespiele f r solche Eigenschaften sind Wartbarkeit Wiederverwendbarkeit oder Portierbarkeit Qualit t hat also mehrere Dimensionen die nicht alle gleich wichtig sind F r unterschiedli che Dom nen sind unterschiedliche Qualit tseigenschaften von besonderer Bedeutung so z B 8Engl f r H lle bezeichnet eine Software die eine andere Software umh llt um bestimmte zus tzliche Funktio nalit ten hinzuzuf gen Siehe Abschnitt 20Siehe Abschnitt 18 2 4 Software Qualit tssicherungsverfahren ist f r sicherheitskritische Steuerungssysteme eine hohe Zuverl ssigkeit besonders wichtig f r Anwendersoftware d rfte dagegen meistens eine hohe Verf gbarkeit Vorrang haben Unabh n gig von der Dom ne ist allerdings wichtig dass die Software korrekt ist Dabei unterscheidet man bei der Softwareentwicklung zwischen verschiedenen Arten von Software Inkorrektheite
168. hr Mutanten als Testfallmengen f r Zustands berdeckung und liegen im Schnitt nur 7 4 hinter dem von der Transitionspaar berdeckung erreichten Mutation score zur ck Dies liegt daran dass Testfallmengen f r Transitions berde ckung alle mutierten Entit ten erreichen Auch die Testfallmengen f r Transitionspaar berdeckung erreichen alle mutierten Entit ten Im folgenden Unterabschnitt werden die Arten der erkannten Mutanten genauer betrachtet Da durch wird aufgezeigt weshalb Testfallmengen f r Transitionspaar berdeckung besser abschnei den als Testfallmengen f r Transitions berdeckung 12Die Einschr nkungen beim Anfangs und Endzustand lauten wie folgt der Anfangszustand darf eine ausgehende Transition haben aber keine eingehenden Der Endzustand darf beliebig viele eingehenden aber keine ausge henden Transitionen haben 3Modell Mutationsoperatoren bearbeiten entweder einen Zustand oder eine Transition eine Testfallmenge die alle Transitionen berdeckt berdeckt auch alle Zust nde 142 7 1 Erkennungspotential hinsichtlich Modellierungsfehler 7 1 3 1 Vergleich der Fehlerarten F r den Zweck des Vergleichs der erkennbaren Fehlerarten wurde die Fehlererkennbarkeit be z glich der sieben Mutationsklassen auf den drei Zustandsautomaten einzeln betrachtet Abbil dung stellt die Ergebnisse der Mutationsanalyse pro Mutationsklasse auf dem Modell Kon to dar Die Testfallmenge ZK schneidet mit einer Ausnahm
169. hreiben Auf modellbasierte Ans tze wird in Abschnitt 3 2 und 3 3leingegangen 2 5 1 Testphasen Abh ngig von deren Art variiert der Zeitpunkt zu dem sich Fehler manifestieren so gibt es z B Fehler die bereits beim Test einzelner Komponenten bemerkt werden Andere Fehler u ern sich erst beim Zusammenspiel mehrerer Komponenten oder bei hoher Belastung der Software z B durch viele gleichzeitige Aufrufe Dementsprechend gibt es mehrere Testphasen wobei jede auf die Auffindung spezieller Arten von Fehlern ausgerichtet ist 2 5 1 1 Komponententest Dieser wird auch Unittest oder Modultest genannt und bezeichnet den systematischen Test ein zelner Softwarebausteine der unmittelbar nach deren Implementierung durchgef hrt werden 30Ein Testskript ist ein automatisch ausf hrbarer Testfall zusammen mit einem Testorakel 24 2 5 Testen kann Da Komponenten meistens von anderen Komponenten abh ngig sind und oder anderen Komponenten Funktionalit ten zur Verf gung stellen muss eine geeignete Testumgebung herge stellt werden Dies wird realisiert in dem Testtreiber Engl Driver und oder Platzhalter Engl Stub umgesetzt werden Ein Testtreiber ist eine Komponente deren einzige Funktionalit t darin besteht Dienste der zu testenden Komponente aufzurufen Dagegen simuliert ein Platzhalter ei ne Komponente die der getesteten Komponente Dienste zur Verf gung stellt Meistens bedeutet die Programmierung eines Platzhalters meh
170. hren Solche Verfahren sind somit zu jedem Entwicklungszeitpunkt anwendbar werden meistens bewusst nicht automatisiert durchgef hrt und binden den Menschen sehr stark mit ein Beispiele solcher Verfahren sind Inspections Reviews und Walkthroughs Hierbei werden zur Fehlerfindung Artefakte durch Menschen begutachtet Der Vorteil der Anwendung sol cher Methoden besteht darin dass sie nicht nur solche Fehler zu entdecken erlauben die zu einem Programmversagen f hren e dynamische Verfahren im Gegensatz zu den statischen Verfahren ben tigen die dynami schen Verfahren ausf hrbare Artefakte wie z B den Quelltext der Software Hier geht es nicht mehr um die Durchsicht bestimmter Artefakte sondern um ihre Ausf hrung um dann anhand der erzeugten Ausgabe zu entscheiden ob sie die Anforderungen erf llen Mit Hilfe dieser Verfahren k nnen nur Fehler entdeckt werden die auch zu einem vom Menschen beobachtbaren Programmversagen f hren Im Folgenden wird sich dieses Kapitel dem wichtigsten Repr sentanten der Klasse der dyna mischen Verfahren widmen und zwar dem Testen Siehe Abschnitt 2 5 1 1 2Siehe Abschnitt 2 5 1 2 In L1g09 werden sie Pr ftechniken genannt 20 2 5 Testen 2 5 Testen Im IEE Standard 610 12 1990 IEE90 wird der Begriff Testen wie folgt definiert Definition 2 2 Test An activity in which a system or component is executed under specified conditions the results are observed or recorded
171. hriebenen Verfahren handelt es sich um ein Offline Verfahren 46Diese sind auch auf die Uberdeckung eines Graphen ausgerichtet genauer gesagt auf die berdeckung des Kon 42 trollflussgraphen 2 6 Modellbasierter Test Unabh ngig von dem ausgew hlten Testfallgenerierungsansatz k nnen mit modellbasiert ge nerierten Testf llen unterschiedliche Ziele verfolgt werden Hier sind zwei Szenarien m glich e Szenario 1 in diesem Fall werden die generierten Testf lle auf Modellebene ausgef hrt mit dem Zweck Modellierungsfehler zu finden Solche Fehler schon w hrend der Model lierung und nicht erst sp ter im Entwicklungsprozess zu entdecken ist sehr wichtig da dadurch die Auswirkungen der Fehler minimiert werden Mit dieser Zielsetzung besch ftigt sich z B der in AFGCO3 beschriebene Ansatz Hier geht es darum aus Klassendiagrammen und Kommunikationsdiagrammen Testf lle zu ge nerieren um die Diagramme an sich zu berpr fen e Szenario 2 andererseits k nnen solche Testf lle benutzt werden um zu berpr fen ob die Implementierung dem im Modell beschriebenen Verhalten entspricht In diesem Fall wird vorausgesetzt dass das Modell korrekt ist und Testf lle werden dazu benutzt um das Verhalten der Implementierung gegen ber dem vom Modell beschriebenen Verhalten zu pr fen Diese Vorgehensweise erm glicht das Finden von mplementierungsfehlern Dabei ist der gew hlte Grad der Modellabstraktion von entscheiden
172. ierter Testf lle die Mutationen des Modells ausgef hrt und der Mutation score berechnet Die Ergebnisse wer den in Tabelle 7 2 beschrieben Ein Teil dieser Ergebnisse wurde bereits in PS10 vorgestellt Wie schon in Abschnitt 6 4 erw hnt gilt dass zwei oder mehrere zustandsbasierte berde ckungskriterien auf bestimmten Modellen die gleiche berdeckung fordern k nnen Dies trifft unter anderem f r die Kriterien Pre states and triggers und Pre states triggers and effects be z glich der Modelle Infotainment und Liegenpr fplatz zu In diesem Fall wurden nicht zwei Testfallmengen generiert die beide die gleiche berdeckung erreichen sondern nur eine Test fallmenge die beide Kriterien erf llt Da es eine einzige Testfallmenge f r beide Kriterien gibt ist der Mutation score der beiden berdeckungskriterien gleich was in den entsprechenden Zel len durch angegeben wird M AM Kl K2 K3 K4 K5 K6 K7 K8 CabinControl 72 73 61 gt 77 78 86 11 84 72 gt 95 83 98 61 Infotainment 94 gt 82 98 93 62 47 87 72 34 87 23 gt 93 62 Liegenpr fplaz 263 66 92 74 52 56 27 72 24 77 95 83 27 84 03 Mittelwerte 143 74 5 75 89 81 97 63 42 76 43 87 90 9 92 08 M Betrachtetes Modell AM Anzahl generierter Mutanten K1 K8 siehe Tabelle 6 5 Tabelle 7 2 Ergebnisse der Mutationsanalyse f r Integrationstestf lle Um auf die einzelnen Testfallmengen im Text leichter Bezug nehmen zu k nnen werden hier Abk rzungen f r je
173. ierung Spektrum Akademischer Vig 1997 F Basanieri and Antonia Bertolino A practical approach to UML based derivation of integration test In Proceedings of 4th International Quality Week Europe 2000 Paul Baker Zhen Ru Dai Jens Grabowski ystein Haugen Serge Lucio Eric Sa muelsson Ina Schieferdecker and Clay E Williams The UML 2 0 Testing Profile In Conquest 2004 2004 Fevzi Belli and Axel Hollmann Test Generation and Minimization with Basic 161 LITERATURVERZEICHNIS BLSO2 BRJ06 Cho78 CNMO7 CPUOT Dar59 Dij70 DMM01 DS06 DT07 FIMNO7 162 Statecharts In SAC 06 Proceedings of the 2008 ACM symposium on Applied computing pages 718 723 New York NY USA 2008 ACM L C Briand Y Labiche and G Soccar Automating Impact Analysis and Regres sion Test Selection Based on UML Designs In Proceedings of the International Conference on Software Maintenance ICSMO2 2002 Grady Booch James Rumbaugh and Ivar Jacobson Das UML Benutzerhandbuch Addison Wesley M nchen u a 2006 T S Chow Testing Software Design Modeled by Finite State Machines EEE Trans Softw Eng 4 3 178 187 1978 E G Cartaxo F G O Neto and P D L Machado Test case generation by means of UML sequence diagrams and labeled transition systems In Systems Man and Cybernetics 2007 ISIC IEEE International Conference on pages 1292 1297 2007 Yanping Chen Robert L Prob
174. iger werdende Klasse von Systemen und zwar die so genannten autonomen Systeme waren dage gen nicht im Fokus dieser Arbeit Solche Systeme kommen z B in der industriellen Produktion vor und zeichnen sich meistens durch eine dezentralisierte Architektur aus Das f hrt dazu dass die einzelnen Subsysteme weitgehend autonom arbeiten gleichzeitig aber um den Zugriff auf gemeinsame Ressourcen konkurrieren Damit autonome Systeme verl sslich funktionieren ist es unerl sslich einerseits Modellie rungssprachen zu ermitteln die es erm glichen die Vielfalt der Interaktionsszenarien zu erfas sen und andererseits Testverfahren zu entwickeln die zur berpr fung solcher Systeme geeignet sind Im Rahmen des europ isches Verbundprojekts Robust amp Safe Mobile Co operative Autono mous Systems R3 Cop das sich mit dem Entwurf robuster und sicherer autonomer Systeme f r sicherheitskritische Bereiche besch ftigt werden unter anderem diese zwei Zielsetzungen ver folgt Bisher wurden am Lehrstuhl f r Software Engineering in Erlangen geeignete Notationen f r die Beschreibung solcher Systeme betrachtet und in vorgestellt In einem weiteren Schritt sollen nun geeignete Verfahren f r den Test solcher Systeme entwickelt werden was zu n chst voraussetzt dass ad quate berdeckungskriterien f r die identifizierten Modellnotationen 159 8 Zusammenfassung und Ausblick definiert werden Dass genetische Algorithmen bereits erfolgreich f r die
175. in Endzustand erreicht wird f r den keine ausgehenden Kanten existieren Zum Beispiel k nnte der Algorithmus anhand des Zustandsautomaten der Komponente A aus 8Siehe Unterabschnitt Der erste betrachtete Zustand ist der Anfangszustand des Zustandsautomaten Falls die ausgew hlte Transition keinen Trigger hat wird keine Nachricht hinzugef gt 76 4 3 Einsatz genetischer Algorithmen zur automatischen modellbasierten Testfallgenerierung Abbildung I folgende Transitionen nacheinander ausw hlen tA tA3 tA7 tA8 Dem entspre chend ist ein Beispiel fiir eine Testsequenz die anhand dieses Zustandsautomaten generiert wer den k nnte und 3 Nachrichten enth lt folgende opAl opA4 opAS F r jede auf diese Art generierte Testsequenz werden zu jeder enthaltenen Nachricht zuf llig Testdaten generiert Da opAl und opA4 parametrisiert sind wird f r opA ein zuf lliger Integer wert und f r opA4 ein zuf lliger boolescher Wert generiert Somit k nnte ein solcher Testfall wie folgt aussehen 0pA1 1230053765 opA4 false opA5 Bei der Generierung einer Anfangspopulation von Integrationstestf llen werden f r alle in teragierenden Zustandsautomaten wie oben beschrieben einzeln Testf lle generiert mit einem Unterschied falls eine Transition t ausgew hlt wird die von Transitionen aus anderen Zustands automaten aufgerufen wird falls ein Mapping m t1 t Map existiert wird der Trigger der Transition r der Testseq
176. in gerichteter Graph der aus einer endlichen Menge von Knoten besteht Jeder Kontrollflu graph hat einen Startknoten und einen Endknoten Die Knoten sind durch gerichtete Kanten verbunden Jeder Knoten stellt ei ne ausf hrbare Anweisung dar Eine gerichtete Kante von einem Knoten i zu einem Knoten j beschreibt einen m glichen Kontrollflu vom Knoten i zum Knoten j Die gerichteten Kanten werden als Zweige bezeichnet Eine abwechselnde Folge von Knoten und Kanten die mit dem Startknoten beginnt und mit einem Endknoten endet hei t Pfad In Anlehnung an werden im Folgenden kontrollflussorientierte berdeckungskriterien beschrieben Eines der bekanntesten berdeckungskriterien die auf die berdeckung des Codes und damit auch des Kontrollflussgraphen ausgerichtet ist ist die Anweisungs berdeckung Die ses Kriterium verlangt die berdeckung aller Anweisungen des Programms d h aller Knoten im Kontrollflussgraphen Durch Ausf hrung von Testf llen die das Kriterium Anweisungs berde ckung erf llen wird sichergestellt dass im Programm alle Anweisungen mindestens einmal aus gef hrt wurden Falls f r bestimmte Anweisungen keine geeigneten Testf lle gefunden werden k nnen ist dies ein Indiz daf r dass es sich dabei um nicht ausf hrbare Anweisungen handelt Laut einer in zitierten Studie hat die Anweisungs berdeckung im Vergleich zu an deren kontrollflussorientierten Testverfahren die geringste Fehleridentifizierungsquote
177. incomingChll arSt play myCDUnit pause I 9 incomingPall myCDUnit Dusel prSt play exterhalEndChll naviga Abbildung 5 3 Ausschnitt eines Zustandsautomaten der um berdeckungsinformationen einer Testsuite f r den Komponententest erg nzt ist Details zu diesem Automat werden in Abschnitt 6 1 vorgestellt 97 5 Werkzeugunterst tzung Da neben der Visualisierung der Gesamt berdeckung auch die Visualisierung der von einem Testfall erreichten berdeckung interessant ist wird auch die Farbe Blau benutzt Zust nde oder Transitionen werden so markiert falls ein einzelner Testfall der Testsuite ausgew hlt wird f r den die berdeckung beschrieben werden soll Abbildung 5 4 zeigt die von einem Testfall aus der vorhin erw hnten Testsuite auf dem Zustandsautomat InfotainmentGui erreichte berde ckung F r die anderen Entit ten die nicht von diesem Testfall berdeckt werden bleibt die F rbung gleich navigation navigatorOn true mainMenu Av edinUnit radio prSt r dio play cdinUnit true UI radio cdinput myCDUnft play dinUnit true prS del iA fernalEndCall navigatorOn true mainMenu nkiCall navigatorOn true amp play myCDUnit pfay prSt play a cdExit prSt radio cdinUnit false E sida cdinUnit false e cdExit prSt rag dinUnit false Die noCDiInUnit incomingall
178. inen Mutanten falls mindestens ein darin enthaltener Testfall den Mutanten erkennt Abh ngig von der Art in der berpr ft wird ob ein Testfall einen Mutanten erkennt k nnen Mutationstestverfahren wie folgt klassifiziert werden Lig09 e Starker Mutationstest Engl Strong Mutation Test im Rahmen eines starken Mutati onstests wird die Bewertung der Testf lle hinsichtlich der Erkennbarkeit eines Mutanten nur anhand abweichender Ausgaben des Mutanten gegen ber dem originalen Programm durchgef hrt e Schwacher Mutationstest Engl Weak Mutation Test Im Gegensatz zum starken Mutati onstest wird der Mutant als erkannt markiert falls die eingef gte Programmmodifikation zur Folge hat dass sich bei Ausf hrung des Testfalls die Zwischenzust nde z B die Va riablenbelegungen des Programms und des Mutanten unterscheiden W hrend es beim schwachen Mutationstest f r die Erkennung eines Mutanten ausreicht dass sich die Zwischenzust nde im Mutanten vom initialen Programm unterscheiden muss beim star ken Mutationstest der unterschiedliche Zwischenzustand eine unterschiedliche Ausgabe zur Fol 123 7 Evaluierung des Fehlererkennungspotentials modellbasierter Testf lle ge haben Typische Mutationsoperatoren auf Ebene des Programmcodes sind laut L1g09 e Referenz einer anderen Variablen e Definition einer anderen Variablen e Verf lschung arithmetischer Ausdr cke um multiplikative oder additive Konstanten oder
179. inks Optimierung Testfallanzahl rechts Optimierung Teststepanzahl 121 6 4 Ergebnisse der Integrationstestgenerierung anhand des Modells Liegenpr fplatz K1 K8 siehe Taben zt 0 links Optimierung Testfallanzahl rechts Optimierung Teststepanzahl 7 1 Beispiel f r ein Modell mit zwei interagierenden Komponenten die externe Zu ee e ee td Se et Eee 126 7 2 Pseudocode zur generischen Beschreibung der Vorgehensweise einzelner Modell NER 131 7 3 Fehlererkennungspotential bzgl einzelner Mutationsklassen von Testfallmengen die Komponententestkriterien auf der Komponente Konto erf llen 143 7 4 Fehlererkennungspotential bzgl einzelner Mutationsklassen von Testfallmengen die Komponententestkriterien auf der Komponente InfotainmentGui erf llen 144 170 ABBILDUNGSVERZEICHNIS 7 5 Fehlererkennungspotential bzgl einzelner Mutationsklassen von Testfallmengen die Komponententestkriterien auf der Komponente Achstest erf llen aus PS10 145 7 6 Beispiel f r ein erweitertes Modell M mit zwei interagierenden Komponenten und mit vier Mappings xe 22 wee eee we an ni aa ad 150 7 7 Fehlererkennungspotential bzgl einzelner Mutationsklassen von Testfallmengen die zustandsbasierte Integrationstestkriterien auf dem Modell CabinControl er E Be Pre We e ee ee E e ae See Boe Ee 152 7 8 Fehlererkennungspotential bzgl einzelner Mutationsklassen von Testfallmengen die zustandsbasierte Integra
180. ion berechnet einen Fitnesswert der als gewichtete Summe ber die folgenden Eigenschaften der Testsuite berechnet wird e Anteil an berdeckten Entit ten e Anzahl erforderlicher Testf lle in Relation zur Population Zur Bewertung einer Testsuite ben tigt die Fitnessfunktion also Informationen zu der erreich ten Modell berdeckung Dazu werden zum einen durch statische Analyse des Modells die zu berdeckenden Modellentit ten bestimmt Zur Ermittlung der erreichten Test berdeckung muss danach bestimmt werden welche der angestrebten Entit ten von der betrachteten Testsuite ber deckt wurden Dieses wird durch Modellsimulation realisiert AnschlieBend wird die erreichte Modell berdeckung als Verh ltnis zwischen der Anzahl der von der Testsuite TS berdeckter Siehe 4 3 3 1 78 4 3 Einsatz genetischer Algorithmen zur automatischen modellbasierten Testfallgenerierung Entit ten A TS durch die Anzahl der zu berdeckenden Entit ten AZ berechnet AU TS Der Wert fiir die Anzahl der Testfalle wird durch Windowing in Relation zu den anderen Test suites der Population wie folgt berechnet AT TS aan 4 2 Dabei ist Qmin die Anzahl der Testf lle des Individuums das die wenigsten Testf lle der gan zen Population enth lt und Qmax die Anzahl der Testf lle des Individuums das die meisten Test f lle der ganzen Population enth lt Q ist die Anzahl der Testf lle des betrachteten Individuum
181. ion t bezeichnet den Zustand einer Komponente der aktiv war bevor durchlaufen wurde tr t Trigger der Transition t bezeichnet ein Ereignis das t ausl sen kann Ob die Transition t dann durchlaufen wird h ngt auch davon ab ob der Guard siehe unten erf llt ist Der Trigger kann auch formale Parameter haben Generell muss eine Transition nicht unbedingt einen Trigger enthalten Falls die Transition keinen Trigger hat wird sie sofort durchlaufen wenn ihr Pre state aktiv wird und der Guard erf llt ist 46 3 1 Verhaltensbeschreibung von Komponenten mittels UML Zustandsautomaten tr t _ bezeichnet das Fehlen eines Triggers an der Transition r Guard der Transition t bezeichnet eine Bedingung die erf llt sein muss damit 7 durch laufen wird Die Bedingung kann dabei ber e die Parameter des Triggers formuliert werden z B Guard i gt 0 bezieht sich auf den Parameter i von opAl i int oder e ber die Variablen der umschlie enden Komponente z B Guard x lt 5 bezieht sich auf die Variable x der Komponente A g t _ bezeichnet das Fehlen eines Guards an der Transition r Um mittels der in Kapitel 4 beschriebenen Methode Testf lle aus Zustandsautomaten zu generieren ist es wichtig dass die Guards der Transitionen die aus dem selben Zustand ausgehen und denselben Trigger haben untereinander disjunkt sind so dass die Zustands maschinen deterministisches Verhalten beschreiben
182. ionsbasierte Systeme eine ganze Reihe von berdeckungskriterien Da die zur Modellierung solcher Systeme am h ufigsten benutzten Diagramme z B Zustandsautomaten oder Aktivit tsdiagramme Graphen sind kann ein gro er Teil der in Abschnitt 2 5 2 beschriebenen White Box Test kriterien auf Modelle bertragen werden Die im Rahmen dieser Arbeit betrachteten Kriterien lassen sich der Kategorie Structural Model Coverage zuordnen und werden in Abschnitt 2 beschrieben Die sechste Dimension hei t Technology und bezieht sich auf die Vorgehensweise bei der Testfallgenerierung Zum einen wird die manuelle Generierung erw hnt da aber speziell Modelle eine sehr gute Basis f r die automatische Testfallgenerierung darstellen werden haupts chlich automatische Vorgehensweisen beschrieben Dabei gibt es die M glichkeit Testf lle zuf llig zu generieren Random Generation Diesem unsystematischen Verfah ren stehen viele systematische Verfahren wie z B Graphensuche oder Model Checking gegen ber Die letzte Dimension der Taxonomie ist Test Execution Hier geht es um die zeitliche Ab folge der Testfallgenerierung und Durchf hrung Wird die Testsuite erst vollst ndig ge neriert um danach ausgef hrt zu werden handelt es sich um ein Offline Verfahren Als Alternative dazu kann bei der Generierung die Ausgabe des SUT mit ber cksichtigt wer den was einem Online Verfahren entspricht Utt05 Bei dem im Rahmen dieser Arbeit besc
183. iterien auf dem Modell Liegenpr f platz erf llen beziehen die zu Mappings geh ren mit einer hohen Wahrscheinlichkeit entdeckt werden Zur Erkennung von Guard Fehlern eignen sich die zustandsbasierten Integrationstestkriterien aller dings nicht Dies wurde auch f r Fehlerarten beobachtet die durch Komponententestf lle ent deckt werden Die Erkl rung daf r aus Abschnitt 7 1 3 l sst sich auch auf Integrationstestf lle bertragen Anhand der Abbildungen 7 7 7 8 und 7 9 ist auch zu erkennen dass die Integrationstestfall mengen die das anspruchsvollste Integrationstestkriterium erf llen bez glich der Effect Muta tionen sehr gute Ergebnisse liefern Dies weicht von den Beobachtungen auf Komponentenebe ne ab Das liegt daran dass die hier betrachteten Effect Mutationen von Modell Mutations operatoren erzeugt wurden die Aufrufe betrachten Da die f r den Integrationstest generierten Testf lle speziell auf die berdeckung solcher Aufrufe zwischen Komponenten zielen wird die se Art von Mutationen auch zu einem hohen Anteil erkannt Siche 7 1 3 1 154 7 2 Erkennungspotential hinsichtlich Implementierungsfehler 7 2 Erkennungspotential hinsichtlich Implementierungsfehler Nachdem der vorherige Abschnitt die M glichkeit der Erkennung von Modellfehlern betrachtet widmet sich dieser Abschnitt der Untersuchung ob mit modellbasiert generierten Testf llen Im plementierungsfehler entdeckt werden k nn
184. land editors International workshop on Security and Dependability for Resource Constrained Embedded Systems 2010 J M Spivey The Z notation a reference manual Prentice Hall Inc Upper Saddle River NJ USA 1989 167 LITERATURVERZEICHNIS SPS09 SSL11 TP07 ULO7 UPLO6 Utt05 WCO03 WS07 WS08 168 Francesca Saglietti Florin Pinte and Sven S hnlein Integration and Reliability Testing for Component based Software Systems In Proc of 35th EUROMICRO SEAA 2009 pages 368 374 2009 Francesca Saglietti Sven S hnlein and Raimar Lill Evolution of Verification Techniques by Increasing Autonomy of Cooperating Agents Studies in Compu tational Intelligence 2011 Jens Trompeter and Georg Pietrek editors Modellgetriebene Softwareentwicklung MDA und MDSD in der Praxis Entwickler Press Frankfurt am Main 2007 Mark Utting and Bruno Legeard Practical Model Based Testing A Tools Ap proach Morgan Kaufmann 1 edition 2007 Mark Utting Alexander Pretschner and Bruno Legeard A Taxonomy of Model based Testing 2006 Department of Computer Science The University of Waikato Private Bag 3105 Hamilton New Zealand Mark Utting Position Paper Model Based Testing Verified Software Theories Tools Experiments ETH Z rich IFIP WG 2 2005 Ye Wu Mei Hwa Chen and Jeff Offutt UML based Integration Testing for Component based Software Proc Second International Conference on COTS
185. langt dass f r jedes Viertupel von Pre state Trigger Effect und Post state der aufrufenden Komponente C also f r jedes preC trC eC postC wobei preC Sc trC Trc eC Ec postC Sc mindestens ein Mapping m t t Map berdeckt wird f r das gilt pre t preC tr t trC e t eC post t postC Die Anzahl zu berdeckender Mappings wird anhand der folgenden Formel berechnet Invoking transitions T E c e Effects on pre states Kriterium dieses Kriterium verlangt dass f r jedes Paar von Effect der aufrufenden Komponente C und Pre state der aufgerufenen Komponenten C also f r jedes eC preC wobei eC Ec preC Sc mindestens ein Mapping m t t Map berdeckt wird f r das gilt e t eC pre t preC 3 3 Modellbasierte berdeckungskriterien f r den Integrationstest Die Anzahl zu berdeckender Mappings wird anhand der folgenden Formel berechnet Effects on pre states IS Tr e e ecEc E f fects in on pre states Kriterium dieses Kriterium verlangt dass f r jedes Tripel von Pre state und Effect der aufrufenden Komponente C und Pre state der aufgerufenen Komponente C also f r jedes preC eC preC wobei preC Sc eC Ec preC Sc mindestens ein Mapping m t t Map berdeckt wird f r das gilt pre t preC e t eC pre t preC Die Anzahl zu berdecken
186. le Variablendefinitionen in Kombination mit allen dazugeh rigen berechnenden Verwendungen getestet werden Zus tzlich dazu fordert das All c uses some p uses Kriterium dass falls keine berechnende Verwendung einer Variable exis tiert zumindest eine pr dikative Verwendung erreicht wird Dieses Kriterium subsumiert in der Regel nicht die Zweig berdeckung es subsumiert allerdings das All defs und das All c uses Kriterium Ein weiteres Kriterium das alle bisher beschriebenen Datenflusskriterien subsumiert ist das All uses Kriterium Dieses fordert dass alle Definitionen in Kombination mit allen dazugeh ri gen pr dikativen und berechnenden Verwendungen getestet werden Wie schon vorhin erw hnt gibt es ein Kriterium f r dessen Erf llung es nicht gen gt einen einzigen Pfad zwischen De finition und entsprechender Verwendung zu berdecken Da die berdeckung aller m glichen Pfade genau so unrealistisch ist wie im Falle des kontrollflussbasierten Pfad berdeckungskri teriums beschr nkt sich das All DU Paths Kriterium auf die berdeckung aller schleifenfreien Pfade zwischen allen Definitionen und allen erreichbaren Verwendungen 2 5 2 3 Grey Box Test Grey Box Testverfahren stellen eine Kombination zwischen White Box und Black Box Test verfahren dar Solche Testverfahren konzentrieren sich auf die Testfallgenerierung anhand von Informationen die nicht so detailliert wie der Software Quelltext sind daf r aber im Vergl
187. len L sungen f r verschiedene Optimierungsprobleme in m glichst kur zer Zeit dienen Meta Heuristiken werden sie deshalb genannt da sie L sungsans tze f r Op timierungsprobleme im Allgemeinen beschreiben was dazu f hrt dass sie f r den Einsatz im konkreten Anwendungsgebiet angepasst werden m ssen Der hier beschriebene Ansatz mit genetischen Algorithmen basiert auf am Lehrstuhl f r Soft Siehe Abschnitt 3 3 68 4 2 Allgemeine Funktionsweise genetischer Algorithmen ware Engineering vorausgegangene Arbeiten der Ansatz von erlaubt die vollautoma tische Testfallerstellung f r Java Code und unterst tzt kontroll und datenflussbasierte Code berdeckungskriterien Im Rahmen der Arbeit werden ebenfalls die Ziele der ber deckungsmaximierung bei gleichzeitiger Minimierung der ben tigten Anzahl an Testf llen ver folgt Einerseits werden diese beiden Ziele v llig unabh ngig voneinander betrachtet indem die so genannte Pareto Front im Rahmen der Verfahrens Nondominated Sorting Genetic Algorithm Kurz NSGA optimiert wird Diese Front beschreibt mehrere pareto optimale Testsuites wobei eine Testsuite dann pareto optimal ist wenn es keine andere Testsuite gibt die diese Testsuite hinsichtlich beider Eigenschaften dominiert Am Ende des Generierungsprozesses stehen dem Tester also eine Menge pareto optimaler Testsuites zur Verf gung Aus dieser Menge kann der Tester dann die Testsuite ausw hlen die f r ihn den best
188. liability Assessment based on Operational Representativeness and Interaction Coverage In 24th International Conference on Architecture of Computing Systems ARCS 2011 2011 Achim Neubauer Visualisierung berdeckter sowie zu berdeckender Modellele mente im modellbasierten Test Diplomarbeit Lehrstuhl fiir Software Engineering Universit t Erlangen N rnberg 2008 Leila Naslavsky and Debra J Richardson Using Traceability to Support Model Based Regression Testing In Proceedings of the twenty second IEEE ACM in ternational conference on Automated software engineering pages 567 570 New York NY USA 2007 ACM Arilo C Dias Neto Rajesh Subramanyan Marlon Vieira and Guilherme H Tra vassos A Survey on Model based Testing Approaches A Systematic Review In WEASELTech 07 Proceedings of the 1st ACM international workshop on Empiri OMG10 OSSPO7 Ost07 PBSO08 POSO8 PS10 PSN09 LITERATURVERZEICHNIS cal assessment of software engineering languages and technologies pages 31 36 New York NY USA 2007 ACM OMG OMG Unified Modeling Language OMG UML Superstructure 2010 Norbert Oster Claudia Schieber Francesca Saglietti and Florin Pinte Automati sche modellbasierte Testdatengenerierung durch Einsatz evolution rer Verfahren In Rainer Koschke Otthein Herzog Karl Heinz R diger and Marc Ronthaler edi tors Informatik 2007 Informatik trifft Logistik Band 2 volume P 110 of Lec
189. lls Characteri stics Dabei wird unterschieden zwischen deterministischen und nicht deterministischen Modellen Des Weiteren stellt sich die Frage ob Zeit bei der Modellierung eine Rolle spielt und ob es sich um ein diskretes kontinuierliches oder um ein hybrides Modell han delt Diskrete Systeme sind dynamische Systeme deren Zustand sich durch das Auftreten von Ereignissen ndert Kontinuierliche Systeme ndern ihren Zustand ohne daf r auf das Auftreten externer Ereignisse angewiesen zu sein Hybride Systeme sind Mischformen dieser zwei Varianten Diese enthalten Klassenname Attribute und Methodensignaturen 45 Siehep 5 2 41 2 Grundlagen Die im Rahmen dieser Arbeit betrachteten Modelle enthalten deterministische hybride Zustandsautomaten welche keine zeitlichen Bedingungen beinhalten Die vierte Dimension ist das Modellparadigma Paradigm Dieses bezieht sich auf die Art der verwendeten Modellierungssprache dabei kann es sich unter anderem um transitions basierte Systeme handeln wie z B die in dieser Arbeit betrachteten Zustandsautomaten oder um Systeme deren Operationen durch Preconditions und Postconditions definiert werden in diesem Fall handelt es sich um State Based Notations Ein Beispiel f r so eine Sprache ist die Sprache Z Sp189 Uberdeckungskriterien Test Selection Criteria stellen eine weitere Dimension dieser Ta xonomie dar hnlich wie auf Codeebene gibt es speziell f r transit
190. menge KSI erreicht wird Bei Betrachtung der von den zwei zugrunde liegenden Kriterien geforderten berdeckung wird klar wieso das so ist das Kriterium Effects on pre states fordert auf diesem Modell die berdeckung von min destens 5 ausf hrbaren Mappings Dagegen fordert das Kriterium Effects in on pre states die berdeckung von mindestens 14 ausf hrbaren Mappings Auch auf dem Liegenpr fplatz Modell erkennt die Testfallmenge die das anspruchsvollste Kriterium erf llt die meisten Mutanten K8L erkennt 221 Mutanten was 2 Mutanten mehr sind als die Testfallmenge K7L Auf diesem Modell wird die schw chste Uberdeckung vom Kriterium Effects on pre states gefordert da das Kriterium lediglich 21 Mappings zu berdecken verlangt Deshalb berrascht es nicht dass die Testfallmenge KAL den niedrigsten Mutation score erreicht Wie auch im Falle der Komponententestkriterien l sst sich generell feststellen dass je an spruchsvoller das zugrunde liegende Kriterium ist desto mehr Mutanten werden durch Test fallmengen die dieses Kriterium erf llen erkannt So erkennt pro Modell immer die Testsui te die das anspruchsvollste Integrationstestkriterium erf llt auch die meisten Mutanten Im Durchschnitt erkennen Testfallmengen die das Kriterium Invoking invoked transitions erf llen 92 08 der Mutanten dicht gefolgt von Testfallmengen die das Kriterium Invoking transitions on pre states erf llen die im Schnitt 90 9 der Mutanten erken
191. mingGall prSt play play lay lt lt ExternalSt gt gt showCallinfo cdExit cdinUnit false blay myCDUnit pause extefnalEndCall nafigatorOn true amp amp cdinUnit true amp amp prSt play endCall nayigatdrOn true amp amp cdihUnit true amp amp prSt play edinput cdinUnit true endCall navigatorOn false amp amp cdinUnit true amp amp prSt play myCDUnit play exterhalEndCall navigatorOn false amp amp cdinUnit true amp amp prSt play myCDUnit play endCall navigatorOn false amp amp cdinUnit true amp amp prSt pau e externalEndCall navigatorOn false amp amp cdinUnit true amp amp prSt pause incomir gCall X lt lt ExternalSt gt gt messageRecievedAndShown incomingCall prSt pause i tGu Inmen t Komponente Infota inmen Modell Infotai Abbildung A 10 180 play lt lt ExternalSt gt gt paused Abbildung A 11 Modell Infotainment Komponente CDPlayer 181 A UML Modelle sperren entsperren id int hatBuchung false 88 id gt 0 88 id lt 999 88 id kid entsperren id int kontostand gt 0 amp amp hatBuchung true amp amp id gt 0 amp amp id lt 999 amp amp id k id lt lt ExternalSt gt gt gesperrt s
192. mme und eignen sich besonders gut f r die Modellierung von Interaktionen 14 zwischen mehreren Objekten 2 2 Unified Modeling Language Form von gesendeten und empfangenen Nachrichten mit besonderer Betonung der zeitli chen Abfolgen Eine weitere St rke ist die Darstellungsm glichkeit alternativer Abl ufe e Kommunikationsdiagramm Engl Communication Diagram geh rt auch zu den Inter aktionsdiagrammen und erlaubt eine hnliche Darstellung wie die Sequenzdiagramme al lerdings mit Fokus auf die statischen Beziehungen zwischen den interagierenden Objekten Die zeitliche Abfolge der Nachrichten wird durch Nummerierung angegeben e Timingdiagramm oder Zeitverlaufsdiagramm Engl Timing Diagram dieses Interaktions diagramm erlaubt die Darstellung von Zeitverlaufskurven von Zust nden Mit Hilfe dieses Diagramms werden die Zust nde beschrieben in denen sich ein oder mehrere Classifier zu einem bestimmten Zeitpunkt befinden k nnen e Interaktions bersichtsdiagramm Engl Interaction Overview Diagram zur Darstellung der Abl ufe mehrerer Interaktionsdiagramme eignet sich dieses Diagramm Vom Aufbau hnlich wie das Aktivit tsdiagramm enth lt es in den Knoten allerdings keine einzelnen atomaren Aktivit ten sondern ganze Interaktionsdiagramme Neben der UML hat die OMG viele weitere Standards entwickelt gt die f r die Softwarein dustrie von gro er Bedeutung sind z B e Object Constraint Language Kurz OCL
193. n Lyu96 e Ein Mistake Irrtum ist ein mentaler Vorgang der dazu f hrt dass Fehler entstehen e Ein Fault Softwarefehler Fehler stellt eine Abweichung zwischen einem beabsichtigten und einem tats chlich implementierten Softwareprodukt dar Jeder Irrtum f hrt zwangs l ufig zu dem Entstehen von Fehlern e Ein Error fehlerhafter Zustand stellt eine Abweichung zwischen dem beabsichtigten und dem realisierten internen Zustand dar z B eine fehlerhafte Variablenbelegung Ein Fehler kann zu einem fehlerhaften Zustand f hren muss aber nicht e Ein Failure Programmversagen stellt eine Abweichung zwischen der beabsichtigten und der realisierten Ausgabe des Programms dar Ein fehlerhafter Zustand kann zu einem Pro grammversagen f hren muss aber nicht Das Schwierige beim Auffinden von Fehlern ist dass diese nicht immer zur Folge haben dass bei der Benutzung der Software ein fehlerhaftes vom Benutzer oder Tester der Software be obachtbares Verhalten auftritt Daf r muss das fehlerhafte Programm bei der Ausf hrung erst einmal in einen fehlerhaften Zustand bergehen was dann zu einem beobachtbaren Programm versagen f hren kann Um zu vermeiden dass solche Fehler berhaupt entstehen kann eine ingenieurm ige Heran gehensweise an die Softwareentwicklung Benutzung der Konstruktionsprinzipien Abstraktion Teile und Herrsche Orientierung an Vorgehensmodellen Einsatz von Werkzeugen usw helfen Eine solc
194. n auf der Komponente InfotainmentGui erf llen Nachdem auf den einfacheren Modellen die Transitions berdeckung und die Transitionspaar berdeckung mit Ausnahme der Effect Mutationen relativ hnlich abschneiden ergibt sich f r das komplexeste Modell ein etwas anderes Bild Dies wird in Abbildung 7 5 dargestellt Diese Ergebnisse wurden bereits in ver ffentlicht Die Testfallmenge TPA schneidet im Ver gleich zu TA auf allen Mutationsklassen besser ab Der gr te Unterschied entsteht auch hier bei den Effect Mutanten Trotz dieses Unterschiedes ist der durch TPA erreichte Mutation score bez glich dieser Mutationsklasse schlecht da lediglich 32 4396 der Effect Mutationen erkannt werden Die Zustands berdeckung schneidet auch auf diesem Modell sehr schlecht ab lediglich bez glich Zustand Mutationen werden mehr als 50 der erzeugten Mutanten erkannt 51 95 Zusammenfassend k nnen folgende Bemerkungen zu der Art erkennbarer Fehler gemacht 144 7 1 Erkennungspotential hinsichtlich Modellierungsfehler 90 i 80 7 70 60 4 50 7 E Transitionspaar berdeckung Achstest TPA 20 i E Transitions berdeckung Achstest TA 10 4 4 i E Zustands berdeckung Achstest ZA gt S g e E e amp g Em 4S Es Ba Ba Es ci xs xs xs E E N N x x x x x x a V d gt V K E gt S ge xP oe RN SS as e 5 8 amp S N C Ki g AS Abbildung 7 5 Fehlererkennungspotential bzgl einzelner Mutati
195. n ist Ein weiteres Beispiel das auch die Benutzung der Farbe Blau illustriert wird in Abbildung 5 7 dargestellt Zur Implementierung der gerade beschriebenen Visualisierung wurde im Rahmen der Diplom arbeit ein Plugin fiir MagicDraw entwickelt das es erlaubt die von einer vorgegebenen Testsuite oder einem darin enthaltenen Testfall berdeckten Entit ten im Bezug auf ein auszu w hlendes berdeckungskriterium zu markieren Einmal installiert stellt das Plugin innerhalb von MagicDraw eine zus tzliche Toolbar zur Verf gung siehe Abbildung 5 8 die es erlaubt f r 100 5 2 Visualisierung berdeckter sowie zu berdeckender Modellelemente c8 12 25 c8 c 3 c8 c 4 c8 c 7 c8 c 8 cabinUp isDoorClosed true linContro done c10 17 28 c 2 c10 c 6 c10 cabinUp isDoorC osed false isDoorClosed true myCabinDoorControl closeDoor travelingUp Abbildung 5 7 Teil eines Zustandsautomaten in dem Mappings und Transitionen farblich mar kiert sind ein geladenes Modell eine mittels des Werkzeugs UnITeD gespeicherte Visualisierungsdatei zu laden und zu entladen ns ExtSt mdzip G Daten UML modelle Als Input f r Unit NHS TA CH Ser G Da n expressions ExtSt mdzip ES stcases Kriterium Invoking Transition On All Pre States v 49 Daten laden Daten schlie en Testfall Re Cont amp verer 9 Diag lt Jessen i RS ES e
196. n zum Werkzeug UnITeD darstellt z B auf welchen Plugins dieses Werkzeug basiert Die gerade beschriebene GUI erm glicht es also den Testfallgenerierungsprozess zu starten und die generierten Testsuites zu verwalten Die bei der Generierung von modellbasierten Kom ponententestf llen bzw von Integrationstestf llen erzielten Ergebnisse werden in Kapitel 6 be schrieben Davor werden in den n chsten zwei Abschnitten weitere n tzliche Funktionalit ten des Werkzeugs beschrieben und zwar die Visualisierung der Modell berdeckung und die Re gressionstestgenerierung 5 2 Visualisierung berdeckter sowie zu berdeckender Modellelemente Neben der Testfallgenerierung erlaubt das vorgestellte Werkzeug auch die Visualisierung der durch generierte Testsuites berdeckten Modellentit ten Diese Funktionalit t wurde im Rahmen einer Diplomarbeit am Lehrstuhl f r Software Engineering in Erlangen umgesetzt und im Rahmen einer Publikation PSNO9 erstmalig vorgestellt Die Visualisierung der erreichten berdeckung ist in mehrfacher Hinsicht hilfreich PSN09 e Sie unterst tzt die Testfallbewertung durch Veranschaulichung der durch eine Testsuite berdeckten Modellentit ten wird die Bewertung der vorliegenden Testsuite durch den Benutzer unterst tzt Dies ist besonders dann wichtig wenn die gew nschte Abdeckung durch die generierte Testsuite nicht erreicht wurde In diesem Fall schafft die Visualisie rung eine Entscheidungsgrundlag
197. nd des gesamten Modells wurde die Populationsgr e 750 ausgew hlt F r die Generierung von Komponententestf llen wurde der Stagnationsparameter auf 8 gesetzt 3D h wenn die so parametrisierten genetischen Algorithmen mehrere Male ausgef hrt werden erreichen sie nur in seltenen F llen eine akzeptable berdeckung Sieheft 3 1 112 6 3 Ergebnisse der Testfallgenerierung f r den Komponententest Die der Fitnessfunktion zugewiesenen Gewichte waren 0 99 f r berdeckung und 0 01 f r Minimierung der Anzahl der Testf lle Die Ergebnisse die bei der Anwendung der auf diese Weise parametrisierten Algorithmen erzielt wurden werden in den folgenden zwei Abschnitten beschrieben 6 3 Ergebnisse der Testfallgenerierung f r den Komponententest Um aus einzelnen Zustandsautomaten Testf lle f r den Komponententest zu generieren wurde das in Kapitel 5 beschriebene Werkzeug eingesetzt Aus jedem der in Tabelle 6 2 beschriebenen Zustandsautomaten wurden drei Testfallmengen generiert und zwar jeweils eine zur Erf llung der Kriterien Zustands Transitions bzw Transitionspaar berdeckung Als Abbruchbedingung der Generierung wurde das Erreichen einer 100 igen berdeckung bez glich des angestrebten berdeckungskriteriums ausgew hlt Auf den betrachteten Zustandsautomaten ist jedoch das Kriterium Transitionspaar berdeckung gar nicht erf llbar da jeder Zustandsautomat mehrere nicht ausf hrbare Transitionspaare enth lt
198. nd verursachen neben Kundenunzufriedenheit einen hohen Aufwand bei der Behebung Die Testumgebung sollte jetzt der Produktionsumgebung beim Kunden m glichst hnlich sein Um Kosten zu senken wird diese Testphase oft in der Produktionsumgebung des Kunden selbst 33 Siehe Abschnitt 2 2 27 2 Grundlagen durchgef hrt was ein Risiko darstellt da in diesem Fall ein Ausfall der Software zu hohen Sch den auf Kundenseite f hren kann hnlich wie im Rahmen des Integrationstests wird das Gesamtsystem als Menge von kollabo rierenden Komponenten getestet Der gro e Unterschied zum Integrationstest besteht allerdings darin dass jetzt rein funktional getestet wird Informationen ber die Struktur der einzelnen Komponenten oder ber deren Schnittstellen und Interaktionen sind hierbei irrelevant Es soll allein die Benutzung durch den Kunden simuliert und berpr ft werden ob und in welchem Umfang die funktionalen und nicht funktionalen Anforderungen erf llt wurden Die in beschrieben Systemtestarten sind e Funktionstest im Rahmen dieser Systemtestart muss berpr ft werden ob die einzelnen Funktionalit ten korrekt im Sinne des Auftraggebers umgesetzt wurden e Leistungstest der Leistungstest dient der berpr fung des angestrebten Leistungsverhal tens Das System wird im Rahmen des Leistungstests hohen Belastungen ausgesetzt in dem es z B mit umfangreichen Datenmengen gef ttert wird um zu berpr fen wie es
199. ndelte es sich also um einen Fehler in der Steuerungskomponente Zusammenfassend kann gesagt werden dass die entdeckten Fehler daraus resultieren dass die im Modell beschriebene Funktionalit t im Rahmen der Implementierungsphase nicht rich tig umgesetzt wurde Durch manuell erstellte Testf lle wurden diese Fehler nicht erkannt da bei 156 7 2 Erkennungspotential hinsichtlich Implementierungsfehler der manuellen Erstellung der Testf lle Ausnahmesituationen nicht betrachtet wurden F r die Er kennung solcher Fehler eignet sich die systematische modellbasierte Vorgehensweise Dar ber hinaus besteht ein weiterer gro er Vorteil der modellbasierten Generierung von Testf llen darin dass die Wartung der Testf lle im Falle von Modell nderungen bedeutend vereinfacht wird 157 8 Zusammenfassung und Ausblick In Rahmen dieser Arbeit wurde ein werkzeuggest tztes Verfahren vorgestellt das die automati sche Testfallgenerierung anhand von UML Zustandsautomaten erm glicht Zu den unterst tzten modellbasierten berdeckungskriterien z hlen sowohl Komponententestkriterien als auch Inte grationstestkriterien Was die unterst tzten Integrationstestkriterien betrifft kn pft diese Arbeit an die Publikation an in der mehrere modellbasierte Integrationstestkriterien eingef hrt wurden Das Verfahren wurde im Rahmen des Verbundprojekts UnITeD an dem die Kooperations partner Lehrstuhl f r Software Engineering und Afra GmbH mit
200. nderen Transitionen irgendeiner Komponente des Systems durchlaufen wurden 3Zueinander alternative Mappings sind Mappings von denen bei der Testfallgenerierung nur ein Mapping ber deckt werden muss 60 3 3 Modellbasierte berdeckungskriterien f r den Integrationstest 3 3 2 Zustandsbasierte berdeckungskriterien Da Transitionen als 5 Tupel dargestellt werden k nnen und Mappings Paare von Transitionen sind kann durch unterschiedlich feine berdeckungsgrade der beiden 5 Tupel von t und d eine Hierarchie zustandsbasierter Integrationstestkriterien definiert werden Diese Kriterien werden zusammengefasst in Tabelle B 3 dargestellt Das Zeichen gibt zu jedem Kriterium an welche Entit ten in Kombination betrachtet werden Jedes Kriterium gibt vor dass f r Kombinationen von Entit ten Mappings berdeckt werden m ssen die bestimmte Bedingungen erf llen Zu beachten ist dabei dass im Allgemeinen nicht zu jeder Kombination entsprechende Mappings existieren werden Die Kombinationen f r die es keine entsprechenden Mappings gibt werden von den Kriterien nicht betrachtet Kriterium aufrufende aufgerufene Komp C Komp C pre tr ec Ec post pre post Pre states and triggers Toc Pre states triggers and ef f ects Invoking transitions Effects on pre states Effects in on pre states Triggers and ef fects in on pre states Invoking transitions on pre states
201. ndsautomaten dass au er dem Anfangszustand und dem Endzustand alle Zust nde beliebig viele ein und ausgehende Transitionen haben k n 141 7 Evaluierung des Fehlererkennungspotentials modellbasierter Testf lle en Zum anderen werden von all den Transitionen eines Zustandsautomaten durch Testfall mengen die Zustands berdeckung erreichen im Regelfall nur ein Teil der ein und ausgehenden Transitionen der berdeckten Zust nde durchlaufen In jedem Fall werden solche Testsuites min destens eine eingehende Transition jedes Zustands berdecken Solche Testsuites berdecken also mindestens so viele Transitionen wie die Anzahl der Zust nde des Zustandsautomaten Dies ist deshalb relevant da eine notwendige Bedingung f r die Erkennung eines Mutanten be sagt dass die mutierte Entit t Transition oder Zustand von der Testfallmenge berdeckt werden muss Zusammenfassend kann gesagt werden dass der Grund f r das schlechte Abschneiden der Zu stands berdeckung der ist dass durch Testfallmengen die alle Zust nde des Automaten berde cken viele Transitionen nicht berdeckt werden Somit k nnen Mutanten die eine Abweichung an einer nicht berdeckten Transition enthalten gar nicht erkannt werden Deutlich besser als die Zustands berdeckung hat die Transitions berdeckung abgeschnitten Testfallmengen f r Transitions berdeckung erreichen im Schnitt einen Mutation score von 64 7 Damit erkennen sie im Schnitt 37 62 me
202. nen Testf llen zugeordnet werden k nnen einzelne Testf lle miteinander verglichen werden 79 4 Automatische modellbasierte Testfallgenerierung mittels genetischer Algorithmen 4 3 3 1 berdeckungsbestimmung durch Simulation F r die Berechnung der Fitness einer Testsuite muss unter anderem die von der Testsuite er reichte berdeckung bestimmt werden Dieses wird realisiert indem f r jeden darin enthaltenen Testfall die berdeckung gemessen wird Daf r wurde ein Modellsimulator im Rahmen der Ar beit umgesetzt der Zustandsautomaten zu simulieren erlaubt in der Sprache Java implementiert wurde und als Komponente in das Werkzeug UnITeD integriert ist F r die Bestimmung der berdeckten Entit ten eines Komponententestfalls wird ein einzi ger Simulator f r die Komponente instanziiert Im Gegensatz dazu wird bei der Bestimmung der berdeckten Entit ten von Integrationstestf llen f r jede interagierende Komponente ein Si mulator instanziiert der dann die Aufrufe aus dem Testfall verarbeitet die zu der Komponente geh ren die er simuliert Die Verwaltung der Simulatorinstanzen bernimmt ein so genannter SimulationManager Die Testsuite f r die die berdeckung bestimmt werden soll wird an diesen SimulationManager geschickt Der SimulationManager verarbeitet jeden einzelnen in dieser Testsuite enthaltenen Testfall indem er die enthaltenen Aufrufe an den entsprechenden Simulator schickt Danach werden pro Testfall
203. nen Am schlechtesten abge schnitten hat das Kriterium Effects on pre states da durch Testfallmengen die dieses Kriterium erf llen im Schnitt nur 63 42 der Mutanten erkannt werden Schlussfolgernd kann gesagt werden dass sich die Subsumptionshierarchie der Kriterien auch in den Mutation scores widerspiegelt Eine Testfallmenge die ein bestimmtes Kriterium X er f llt entdeckt tendenziell mehr oder zumindest gleich viele Mutanten wie eine Testfallmenge die ein von K subsumiertes Kriterium erf llt Die einzige Ausnahme stellen die Testfallmen gen K4C und KSC dar Die Testfallmenge K4C erkennt 62 und damit 86 11 der anhand von CabinControl generierten Mutanten Damit erkennt sie einen Mutanten mehr als KSC 149 7 Evaluierung des Fehlererkennungspotentials modellbasierter Testf lle Um den Grund f r dieses unerwartete Ergebnis darzustellen wird hier erst einmal auf die Ab bildung 7 6 verwiesen welches ein initiales Modell JM mit zwei Zustandsautomaten beschreibt Im Unterschied zu dem in Abbildung 7 1 beschriebenen Modell enth lt Transition tA7 densel ben Aufruf an Komponente B wie Transition tA6 Somit gibt es in diesem Modell insgesamt vier Mappings Sei der Mutant namens MutIM ein Modell dass im Unterschied zum initialen Modell IM keinen Aufruf in 146 enth lt Nun wird gezeigt dass es zwei Testf lle geben kann die die Transition tA6 und auch das Mapping m tA6 tB4 berdecken sich aber hinsichtlich der Erkennb
204. nen die einzelnen atomaren Teilbedingungen und zum anderen Variationen von atomaren Teilbedingungen betrachten Das schw chste Kriterium dieser Art ist die einfache Bedingungs berdeckung Dieses Krite rium fordert dass Testf lle die Software so ausf hren m ssen dass jede atomare Teilbedingung mindestens einmal zu wahr und einmal zu falsch ausgewertet wird Da dieses Kriterium weder die Zweig berdeckung noch die Anweisungs berdeckung subsumiert ist es f r den praktischen Einsatz nicht ausreichend Deshalb wurde mit der minimalen mehrfachen Bedingungs berdeckung ein anspruchsvolleres Kriterium eingef hrt welches verlangt dass jede Bedingung atomar oder nicht mindestens einmal zu wahr und einmal zu falsch ausgewertet wird Somit subsumiert dieses Kriterium die Zweig berdeckung Das anspruchsvollste Kriterium dieser Art ist das Kriterium mehrfache Bedingungs berde ckung Dieses Kriterium besagt dass alle Variationen atomarer Bedingungen zu berdecken sind Da sich bei einer Bedingung mit n atomaren Teilbedingungen 2 Variationsm glichkeiten erge ben ist dieses Kriterium im praktischen Einsatz meistens nicht erreichbar Um Schleifen zu testen eignet sich das Pfad berdeckungskriterium Es fordert dass alle un terschiedlichen Anweisungssequenzen des Programms also alle Pfade im Kontrollflussgraphen berdeckt werden Dieses Kriterium nimmt unter den kontrollflussorientierten Testverfahren eine Sonderstellung ein
205. nenten in Abbildung 6 1 dargestellt die Pfeile repr sentieren Aufrufe zwischen den Komponenten MainControl TopFloorControl MiddleFloorControl CabinControl Cabin Door Control BaseFloorControl Abbildung 6 1 Die Komponenten des Modells CabinControl 109 6 Evaluierung der vorgestellten Testfallgenerierungsmethode Pro Stockwerk gibt es eine Stockwerk Steuerungskomponente insgesamt gibt es also drei Stockwerk Steuerungskomponenten TopFloorControl MiddleFloorControl und BaseFloorCon trol die es erlaubt den Aufzug im entsprechenden Stockwerk anzufordern Die zentrale Steue rungskomponente MainControl interagiert mit den Stockwerk Steuerungskomponenten und mit der Kabinensteuerung CabinControl Die Kabinensteuerung interagiert mit der T rsteuerung Ca binDoorControl der Kabine um die T ren zu ffnen oder zu schlie en Infotainment Des Weiteren beschreibt das Modell nfotainment aus dem Kontext der Automobilindustrie ein System das den Insassen eines Autos eine Reihe von Diensten z B Navigation Radio und Telefonie anbietet Dieses System besteht aus zwei Komponenten Die zentrale Komponente InfotainmentGui stellt die genannten Dienste ber eine GUI zur Verf gung Die zweite Kom ponente CDPlayer ist f r das Abspielen von CDs verantwortlich und erh lt Befehle von der Komponente InfotainmentGui Die Eigenschaften dieser drei Modelle werden in Tabelle 6 1 dargest
206. ner Variable tritt in einer Anweisung des Programms auf kann also einem Knoten im Kontrollflussgraphen zugeordnet werden wenn der Variable bei der Durchf hrung dieser Anweisung ein Wert zuge wiesen wird Falls der Wert einer Variable im Rahmen einer Anweisung ausgewertet wird dann handelt es sich um eine Verwendung der Variable Engl Use Bei den Verwendungen von Va riablen wird noch zwischen berechnender und pr dikativer Verwendung unterschieden Eine be rechnende Verwendung Engl Computational Use kurz C use kommt dann vor wenn der Wert dieser Variable bei der Ausf hrung einer datenverarbeitenden Anweisung benutzt wird Solch ein C use kann also genau einem Knoten im Kontrollflussgraphen zugeordnet werden Die pr dika tive Verwendung Engl Predicative Use kurz P use einer Variable bedeutet dass diese Variable bei der Ausf hrung einer Bedingungsauswertung innerhalb eines Verzweigungsknotens ausge wertet wird um den Wahrheitsgehalt dieser Bedingung zu bestimmen Der Wahrheitsgehalt wird dann entscheiden welche der ausgehenden Kanten durchlaufen wird Ein P use wird den Kanten zugeordnet die von dem Verzweigungsknoten ausgehen Beispiel Die Anweisung a 0 beschreibt eine Wertzuweisung der Variable a und enth lt somit ein Def von a Wenn dieser Wert in einer anderen Anweisung b a 1 benutzt wird dann kommt hier sowohl eine C use von a vor als auch ein Def von b vor Eine sp tere Bedingung ber 40Dies ist ein Kn
207. ns zur automatischen Testfallgenerierung f r den Komponenten und Inte grationstest an dem der Autor ma geblich beteiligt war Hierzu konnte auf am Lehrstuhl f r Software Engineering bereits vorhandene Erfahrungen im Bereich der Optimierung mittels ge netischer Algorithmen zur ckgegriffen werden Des Weiteren basiert diese Arbeit auch auf be reits etablierte modellbasierte Komponententestkriterien sowie auf am Lehrstuhl f r Software Engineering entstandene modellbasierte Integrationstestkriterien Der Hauptbeitrag dieser Arbeit besteht in der Bewertung modellbasierter Testfallmengen f r den Komponenten und Integrationstest hinsichtlich ihres Fehlererkennungspotentials Hier wur den neue Mutationsoperatoren auf Modellebene konzipiert und umgesetzt um zu evaluieren in wiefern automatisch generierte Testfallmengen die Entdeckung von Modellfehlern unterst tzen Dar ber hinaus wurde modellbasiertes Testen mit konventionellem Testvorgehen im Hinblick auf ihr Potential zur Erkennung von Implementierungsfehlern verglichen 1 Einleitung 1 3 Gliederung Diese Ausarbeitung ist wie folgt gegliedert Zun chst wird in Kapitel 2 Grundlagenwissen be schrieben auf dem diese Arbeit aufbaut Abschnitt f hrt das modellbasierte Softwareent wicklungsparadigma ein gefolgt von der Beschreibung der weit verbreiteten Modellierungs sprache UML in Abschnitt 2 2 Im darauf folgenden Abschnitt 2 3 wird ein zur modellbasierten Entwicklung orthogonale
208. nten lauff hige Testf lle erhalten werden So z B k nnte Testfall T2 der den Pfad AO A1 A4 A2 A3 A6 im Beispielmodell aus Abbildung 5 9 durchl uft so ge ndert werden dass er auch im neuen Modell lauff hig ist der Pfad im ge nderten Modell k nnte sein AO Al A4 A3 A6 27Testfille der Klasse X 107 6 Evaluierung der vorgestellten Testfallgenerierungsmethode Dieses Kapitel beschreibt die Ergebnisse die bei der automatischen Generierung von Testf llen mittels des im vorigen Kapitel beschriebenen Werkzeugs aus Modellen erzielt wurden Dazu werden zun chst in Abschnitt die evaluierten Anwendungen beschrieben d h es werden die Modelle beschrieben die der Testfallgenerierung zugrunde gelegt wurden Danach wird in Abschnitt 6 2 beschrieben welche Parametrisierung f r die genetischen Algorithmen bei den durchgef hrten Experimenten ausgew hlt wurde Daraufhin werden in Abschnitt 6 3 die bei der Generierung von Komponententestf llen erzielten Ergebnisse beschrieben gefolgt von der Be schreibung generierter Integrationstestf lle in Abschnitt 6 4 Ein kleiner Teil dieser Ergebnisse wurde bereits in diversen Publikationen ver ffentlicht OSSPO7 PSO08 POSOS SOPOS SPS09 SP10 6 1 Evaluierte Anwendungen Zur Erprobung des Werkzeugs wurden mehrere Modelle erstellt die neben der Beschreibung des Softwareverhaltens auch die vom Benutzer wahrgenommene Mensch Maschine Interaktion darstellen Bei di
209. ntostand betrag lt 0 kontostand kontostand betrag hatBuchung true Modell Konto Komponente Konto Abbildung A 12 182 B Werkzeug UnlTeD Im Folgenden wird die Bedienung des Werkzeugs UnITeD beschrieben Nach dem Start des Werkzeugs wird der Startbildschirm angezeigt siehe B 1 ber den Men punkt File Load Model siehe kann eine Modelldatei geladen werden Nach dem Laden wird das Modell im so genannten Modellbaum angezeigt siehe B 3 Durch klicken auf einzelne Elemente des Baumes werden deren Eigenschaften im Tab Properties angezeigt Vor dem Start der Generierung kann der Konfigurationsdialog aufgerufen werden der drei Tabs enth lt Im ersten Tab Coverage Criterion siehe B 4 kann eingestellt werden welche Kri terien verfolgt werden Im zweiten Tab Optimization Conditions siehe kann die Gewich tung f r die Fitnessfunktion festgelegt werden Im dritten Tab Advanced siehe kann der genetische Algorithmus parametrisiert und das Abbruchkriterium ausgew hlt werden Zum Starten der Testfallgenerierung muss der Tester einen TestContext ausw hlen und dann den OK Button dr cken siehe B 7 W hrend der Testfallgenerierungsprozess l uft wird der Fortschritt der Generierung angezeigt siehe B 8 Der Prozess kann dabei jederzeit angehal ten werden indem der Cancel Operation Button unten rechts angeklickt wird Wenn dies ge schieht wird die bis dahin beste generierte Testsuite angezeigt ber das
210. nuell zu erstellen Diese k nnen dann automatisch ausgef hrt werden um f r die einzelnen Testf lle die Verdicts automatisch zu ermitteln Die Testskripte enthalten zum einen Aufrufe an die zu testenden Bausteine und zum anderen so genannte Assertions die das gelieferte Ergebnis mit dem erwarteten Ergebnis automatisch zu vergleichen erlauben Als alternativer Ansatz zur Unterst tzung der automatischen Testdurchf hrung ist noch der Capture Replay Ansatz zu erw hnen Am Anfang ist auch bei diesem Ansatz manuelles Eingrei fen n tig um Testf lle zu erzeugen die danach beliebig oft automatisiert durchgef hrt werden k nnen Dazu wird zun chst die zu testende Software von einer Person bedient w hrend gleich zeitig die Benutzeraktionen Mausklicks Tastatureingaben usw zusammen mit den Ausgaben des Werkzeugs erfasst werden Capture Die so erfassten Testf lle k nnen dann beliebig oft aus gef hrt werden Replay Die Bewertung der gelieferten Ergebnisse bei erneuter Ausf hrung der Testf lle erfolgt durch Vergleich der Ausgabe des Werkzeugs mit der bei der ersten Ausf hrung gelieferten Ausgabe Ans tze zur automatischen Testfallgenerierung gibt es ebenfalls sehr viele diese sind aber nicht so etabliert wie die zur Testdurchf hrung Als Grundlage f r die automatische Testfallge nerierung gilt dabei entweder der Quelltext der Software wie z B in der Arbeit von Ost07 oder Modelle die das beabsichtigte Softwareverhalten besc
211. om merziellen Softwaresystemen ist allerdings immer noch sehr viel manueller Programmier aufwand n tig da sich die automatische Generierung in vielen F llen auf die Generie rung von statischem Code z B Java Klassenger sten beschr nkt Das Verhalten dieser Klassen Implementierung der Methoden muss dagegen manuell programmiert werden In diesem Fall macht die Generierung von Testf llen anhand von Entwicklermodellen sehr viel Sinn weil dadurch berpr ft werden kann ob die gew nschte und modellierte Funk tionalit t auch tats chlich implementiert wurde Ein Nachteil der Testfallgenerierung aus Entwicklermodellen besteht darin dass durch dieses Vorgehen keine Omission Faults entdeckt werden k nnen falls das Modell nicht alle Anforderungen des Kunden ber cksichtigt K nnen solche Fehler mit Hilfe von Testf llen die aus dem Modell generiert wurden nicht entdeckt werden Es besteht also ein hnliches Problem wie bei der Testdurchf hrung von White Box Testfallen Die Benutzung separater Testmodelle f hrt eine zus tzliche Perspektive die Perspektive des Testers auf das Verhalten der Software ein und erlaubt es deshalb auch speziell die vorhin erw hnten Omission Faults zu erkennen Andererseits kann durch berdeckung des Testmodells nicht abgesch tzt werden ob das gesamte umgesetzte Verhalten durch die generierten Testf lle berpr ft wurde 3 Eine weitere Dimension bezieht sich auf die Charakteristiken des Mode
212. onsklassen von Testfallmen gen die Komponententestkriterien auf der Komponente Achstest erf llen aus PS 10 werden nachdem Testfallmengen f r Zustands berdeckung generell einen sehr niedrigen Mu tation score erreichen berrascht es nicht dass sie auch bez glich der einzelnen Mutationsklas sen schlecht abschneiden Nur bez glich Zustand Mutationen erreichen sie Mutation scores die ber 50 liegen auf InfotainmentGui sogar 75 51 Somit eignen sich Testfallmengen die Zustands berdeckung erf llen bestenfalls zur Erkennung einiger Zustandsfehler Im Gegensatz dazu liefert die Transitions berdeckung bez glich vier der sieben Mutations klassen gute bis sehr gute Ergebnisse was dazu f hrt dass sie insgesamt betrachtet nicht viel schlechter als die Transitionspaar berdeckung abschneidet Somit eignen sich Testfallmengen die alle Transitionen oder alle Transitionspaare eines Automaten berdecken gut f r die Erken nung von Trigger Fehlern Pre state Fehlern Post state Fehlern und Zustand Fehlern Bez glich der Mutationsklassen Guard und Transition Mutationen schneiden die Transitions und die Transitionspaar berdeckung hnlich schlecht ab Die einzige Klasse bei der sich die Transitionspaar berdeckung deutlich von der Transitions berdeckung absetzen kann ist die Klas se Effect Mutationen Hier entdeckt die Transitionspaar berdeckung im Schnitt circa doppelt so viele Mutanten wie die Transitions berdeckung Tro
213. opB1 69171531 opA2 opA3 opB3 opB1 1774418 opA2 opA3 Dieser Testfall berdeckt folgende Transitionen tA 1 tBlI tA3 tB2 tA5 tA6 tB4 tB5 tB2 tA5 tA6 tB3 4 3 4 Genetische Operatoren Um aus einer existierenden Population eine neue Population zu generieren m ssen genetische Operatoren wiederholt angewendet werden Sie werden so lange auf die Individuen der exis tierenden Population angewendet bis in der neuen Population gen gend Individuen vorhanden sind wobei die Populationsgr e vor dem Start der Generierung festgelegt wird Vor der ersten Anwendung der Operatoren werden die Individuen der aktuellen Population ihrer Fitness nach absteigend sortiert so dass auf Position 0 der Population das fitteste Individuum und auf Position Populationsgr e 1 das Individuum mit der schlechtesten Fitness ist 4 3 4 1 Elitismusoperator Als erstes wird ein Elitismusoperator angewendet um sicherzustellen dass sich bei der Erzeu gung neuer Populationen keine Verschlechterung im Vergleich zu der alten Population ergibt Deshalb werden die besten Individuen der aktuellen Population unver ndert in die neue Popu lation bernommen indem die Individuen beginnend von der Position 0 ausgew hlt werden Der Anteil an unver ndert zu bernehmenden Individuen wird vor dem Start der Generierung festgelegt Dies wird als prozentueller Anteil bez glich der Populationsgr e angegeben Beispiel Bei einer Populationsgr e
214. oseFloor 179 A UML Modelle navigation navigatorOn true exit cdinput cdinUnit true lt lt ExternalSt gt gt mainMenu communication lt lt ExternalSt gt gt communication writeMessag lt lt ExternalSt gt gt mainMenu radio prSt rddio lt lt ExternalSt gt gt radio mainMenu play myCDUnit play prSt cdExit prSt radio cdinUnit false lt lt ExternalSt gt gt cdPlayingStopped lt lt ExternalSt gt gt navigator gt pause cdinUnit true myCDUnit pause prSt pause stop cdinUnit true myCDUnit stop prSt stop lay cdinUnit true myCDUnit play prSt play cdinput myCDUnft play dalnUrjit trug pieni y vol Um play p play externalEndCall navigatorOn true amp amp prSt play amp amp cdinUnit true myCDUnit play erkiCall navigatorOn true amp amp prSt play amp amp cdinUnit true myCDUnit play pause my CDUnit pause prSt pause prst play lt lt ExternalSt gt gt stop myCDUnit stop prSt stop pause Unit false lt lt ExternalSt gt gt noCDinUnit lt lt ExternalSt gt gt numberinput lt lt ExternalSt gt gt makingCall lt lt ExternalSt gt gt ont waitingForTalkButton writeMessage incomingMegsagd inco
215. oten mit zwei ausgehenden Kanten Er repr sentiert eine Programmverzweigung z B if oder Schleifen z B for oder while 35 2 Grundlagen die Variable b if b gt 5 then enth lt ein P use von b Ein datenflussannotierter Kontrollflussgraph ist ein Kontrollflussgraph der um Informationen zu Defs und Uses erweitert wurde Die berdeckungsziele datenflussbasierter Kriterien beziehen sich auf Definitionen und Ver wendungen gleicher Variablen Es wird angestrebt Paare von Definitionen einer Variable und dazugeh rigen Verwendungen der Variable zu berdecken genauer gesagt geht es darum Pfade des datenflussannotierten Kontrollflussgraphen zwischen dem Knoten der die Definition enth lt und dem Knoten oder der Kante der die Verwendung der Variable zugeordnet ist zu berde cken wobei entlang des Pfades keine erneute Definition der betrachteten Variable vorkommen darf Solche Pfade nennt man definitionsfreie Pfade Engl Def clear path bez glich einer be stimmten Variable Basierend auf diesen Konzepten f hrten datenflussbasierte berdeckungskriterien ein Diese werden hier kurz beschrieben in Anlehnung an Bal97 Diese Kriterien sind was den Aufwand und die Fehlererkennbarkeit angeht zwischen den einfachen kontrollflussbasier ten Kriterien wie Zweig berdeckung und den sehr komplexen und im Allgemeinen nicht erf ll baren Pfad berdeckungskriterien angesiedelt Da zwischen einer Definition und einer Verwend
216. perren entsperren id int kontostand 0 amp amp hatBuchung true amp amp id gt 0 amp amp id lt 30988 id I id sperren abheben betrag int betrag gt 0 amp amp betrag lt 10000 amp amp kontostand etra er ffnet 999 k i id int id gt 0 8 amp id lt lt lt ExternalSt gt gt aufl sen keine Buchung einzahlen betrag int betrag gt 0 amp amp betrag lt 10000 amp amp kontostand betrag lt kontostandMax kontostand kontostand betrag hatBuchung true lt lt ExternalSt gt gt guthaben aufl sen kontostand lt 10000 einzahlen betrag int betrag gt 0 amp amp betrag lt 10000 kontostand kontostand betrag hatBuchung true abheben betrag int betrag gt 0 amp amp betrag lt 10000 amp amp betrag lt kontostand kontostand kontostand betrag lt lt ExternalSt gt gt in Aufl sung abheben betrag int betrag gt 0 amp amp betrag lt 10000 Z kontolstand lt betrag kontostand kontostand einzahlen betrag int betrag gt 0 amp amp betrag lt 10000 amp amp kontostand betrag gt 0 kontostand kontostand betrag hatBuchung true lt lt ExternalSt gt gt berzogen aufl sen AS kontostand kontostand betrag einzahlen betrag int betrag gt 0 amp amp betrag lt 10000 amp amp ko
217. pitel 2 erw hnt stellt die Generierung ad quater Testfallmengen eine der auf wendigsten Aktivit ten des gesamten Test Prozesses dar Deshalb verspricht gerade eine weit gehende automatische Unterst tzung dieser Aktivit t eine verbesserte Qualit t der Testf lle bei gleichzeitiger Minimierung der Kosten die mit der Erstellung der Testf lle verbunden sind Bei der Bewertung modellbasierter Testfallgenerierungsans tze muss differenziert betrachtet werden welcher Teil eines Testfalls automatisch erzeugt wird die Testsequenz und oder die Testdaten Ans tze zur modellbasierten Testfallgenerierung bertragen die Idee der strukturellen ber deckung von der Ebene des Quelltextes auf die Ebene der Modelle Es f llt hierbei auf dass sehr h ufig die UML als Modellierungssprache gew hlt wird Dieser Eindruck wird durch die Studie von best tigt Hier wurden 406 Artikel zum modellbasierten Test ausgewertet und 78 66 4 1 Motivation Ans tze ausgew hlt die genauer betrachtet wurden Von diesen basieren 47 Ans tze also mehr als 60 auf UML Modellen G ngige Ans tze zur modellbasierten Testfallgenerierung f r den Integrationstest f hren eine Transformation der unterst tzten Diagramme in einen Hilfsgraphen durch anhand dessen dann die Generierung von Testf llen durchgef hrt wird So z B zielt auf die berdeckung von Sequenzdiagrammen indem das Diagramm in einen so genannten Model Flow Graph Kurz MFG transformiert wird Dies
218. pping ist also ein Paar von Transitionen fiir das gilt dass der Effect der aufrufenden Transition t gleich dem Trigger der aufgerufenen Transition t ist Diese Gleichheit ist so zu verstehen dass im Effect von ein Aufruf enthalten ist der gleich mit dem Trigger von 1 ist Diese Gleichheit bedeutet also nicht dass die Zeichenketten die im Effect von t und im Trigger von t modelliert sind gleich sein m ssen F r ein Softwaresystem das aus einer Menge COMP von interagierenden Komponenten be steht wird die Menge aller Mappings zwischen den interagierenden Komponenten in SOPO07 wie folgt definiert Map t i 3C C COMP CZC te Tc t To e t tr t F r jedes Mapping m t t Map werden in SOPO07 noch folgende Konzepte beschrie ben e k m COMP die aufrufende Komponente also die Komponente C die Transition f enth lt und e k m COMP die aufgerufene Komponente also die Komponente C die Transition t enth lt Es k nnten im Effect von t neben dem Aufruf auch z B Variablenzuweisungen enthalten sein 39 3 Modellbasierte Uberdeckungskriterien Zur beispielhaften Beschreibung dieses Konzepts stellt Abbildung neben den Zustands automaten der Komponente A auch den Zustandsautomaten einer weiteren Komponente B dar Dabei enth lt die Komponente A eine Transition tA6 deren Effect einen Aufruf der Komponen te B enth lt Auf der anderen Seite hat Komponente B zwei
219. pre t f r eine bestimmte Transition f beschreibt diese Menge die Menge der Trigger der Zustandsmaschi ne die als Ersatz f r den Trigger dieser Transition bei einer Mutation in Frage kommen Um Nichtdeterminismus zu vermeiden kommen hier nur die Trigger in Frage die nicht als Trigger f r andere Transitionen auftreten die aus dem Pre state der Transition f ausgehen MengeKandidatenPreState Sc S Tr c tr t f r eine bestimmte Transition t beschreibt diese Menge die Menge der Zust nde des Zustandsautomaten die als Ersatz f r den Pre state dieser Transition in Frage kommen Um Nichtdeterminismus zu vermeiden kommen hier nur die Pre states in Frage die keine ausgehende Transition haben deren Trigger gleich dem Trigger der Transition t ist MengeTransitionenF rGuardc t Teltr t gU t Tc An Te t t pre t pre ti tr t tr t diese Menge beinhaltet Transitionen auf die Guard Operatoren angewendet werden sollen Da durch nderungen an den Guards nichtdeterministische Automaten erzeugt werden k nnen beinhaltet diese Menge zum einen alle Transitionen ohne Trigger und zum anderen die Transitionen mit Trigger f r die folgendes gilt es existiert im Zustandsautomat keine andere Transition mit dem gleichen Trigger und dem gleichen Pre state wie die aktuell betrachtete Transition Des Weiteren werden noch folgende Mengen eingef hrt MengeVergleichsoperatoren lt lt gt gt
220. r Ansatz beschrieben und zwar die komponentenbasierte Softwareent wicklung Danach werden in Abschnitt 2 4 Software Qualit ts sicherungsverfahren im Allgemei nen vorgestellt Der Abschnitt 2 5 beschreibt eines der wichtigsten Qualit tssicherungsverfahren und zwar das Testen Des Weiteren wird in diesem Abschnitt die Basisterminologie dieser Ar beit Testfall Testsuite usw eingef hrt und verschiedene Testphasen in Unterabschnitt 2 5 1 und Testarten in Unterabschnitt vorgestellt Das modellbasierte Testen wird im letzten Abschnitt des Kapitels eingef hrt Nach dem allgemeinen Einstieg wird in Kapitel 3 auf modellbasierte Uberdeckungskriterien eingegangen Zur Modellierung des Verhaltens von Komponenten wurden UML Zustandsauto maten eingesetzt diese werden in Abschnitt 3 1 beschrieben Im darauf folgenden Abschnitt 3 2 werden berdeckungskriterien f r einzelne Zustandsautomaten vorgestellt Auf modellba sierte Schnittstellen berdeckungskriterien wird in Abschnitt eingegangen gefolgt von der Beschreibung so genannter zustandsbasierter Integrationstestkriterien in Unterabschnitt 3 3 2 Kapitel 4 beschaftigt sich mit genetischen Algorithmen Auf die Notwendigkeit des Einsatzes genetischer Algorithmen zur automatischen Generierung von Testfallen wird in Abschnitt 4 1 eingegangen gefolgt von der Beschreibung der allgemeinen Funktionsweise solcher Algorith men in Abschnitt 4 2 Danach wird in Abschnitt 3 die Anpassung der genetis
221. r Aufwand als die Programmierung eines Testtrei bers da der Treiber nur Aufrufe enthalten muss dagegen muss der Platzhalter eine bestimmte Funktionalit t simulieren 2 5 1 2 Integrationstest Im Rahmen dieser Testart werden mehrere Komponenten zu einem Gesamtsystem zusammen gesetzt mit dem Ziel speziell deren Zusammenspiel zu testen Es sollen dabei Fehler an den Schnittstellen der Komponenten aufgedeckt werden F r das Zusammensetzen der Komponen ten gibt es mehrere Strategien die laut in drei Klassen aufgeteilt werden k nnen Big Bang Integration Diese Vorgehensweise als Strategie zu bezeichnen ist etwas unpassend da sich dahinter keine wirklich systematische Herangehensweise verbirgt Sie gibt nur vor dass erst nach Entwicklung und Test aller ben tigten Bausteine mit der Integration begonnen wird indem alle Bausteine auf einmal zu einem Ganzen zusammengesetzt werden Diese Vorgehensweise ist aber meistens nicht zu empfehlen da sie bedeutende Nachteile mit sich bringt Zum einen kann mit dem In tegrationstest erst begonnen werden nachdem alle Bausteine fertig gestellt worden sind zum anderen wird im Falle dass Fehler entdeckt werden die Suche nach der fehlerhaften Kompo nente erschwert Strukturorientierte Integration Die Strategien dieser Klasse verlangen dass das Gesamtsystem inkrementell aufgebaut wird zun chst sollte nur ein Teil der Komponenten zu einem Subsystem zusammengesetzt und getestet werden Die
222. r Diagramme stellt ein Modell des Systems dar 17 B Java Klassen mit Attributen und Methodensignaturen 2Siehe Abschnitt 2 4 2 Grundlagen Die Semantik einer Sprache ordnet jeder graphischen oder textuellen Entit t eine konkrete Bedeutung zu Je nach Grad ihrer semantischen Pr zision lassen sich Modellierungssprachen wie folgt klassifizieren e informale Modellierungssprachen zu den bekanntesten Vertretern der informalen Spra chen z hlen nat rliche Sprachen wie z B Deutsch oder Englisch Der Vorteil der Benut zung solcher Sprachen besteht darin dass diese Sprachen keinen zus tzlichen Lernauf wand verursachen und dabei sehr ausdrucksm chtig sind Zu den Nachteilen z hlen ihre Mehrdeutigkeit und die Tatsache dass sie schlecht analysierbar sind Deshalb eignen sich solche Sprachen meistens nicht als Mittel zur Beschreibung komplexer Sachverhalte im Kontext der Softwareentwicklung semi formale Modellierungssprachen Beispiele solcher Sprachen sind Entity Relation ship Diagramme oder die Unified Modeling Language Diese stellen einen Kompromiss zwischen informalen und formalen Sprachen dar und enthalten somit sowohl Teile der nat rlichen Sprachen als auch Elemente mit eindeutiger Semantik Im Gegensatz zu informalen Sprachen erm glichen sie somit die Erstellung einer Spe zifikation die kaum unterschiedliche Interpretationen zul sst Des Weiteren ist die meist visuelle Form dieser Sprachen vorteilhaft d
223. r Testf lle generiert werden Die Testsuite zur Erf llung des Kriteriums Invoking transitions enth lt daf r 19 Teststeps mehr Das einzige Beispiel f r eine Testfallmenge die sowohl mehr Testf lle als auch mehr Teststeps beinhaltet als die Testfallmenge die f r ein st rkeres Kriterium generiert wurde ist die Testfallmenge die das Kriterium Effects on pre states auf CabinControl erf llt Mit 3 Testf llen und 34 Teststeps enth lt sie einen Testfall und einen Teststep mehr als die Testfallmenge f r Effects in on pre states Dieses berraschende Ergebnis l sst sich durch die 118 6 4 Ergebnisse der Testfallgenerierung f r den Integrationstest angewendete Heuristik erkl ren die in diesem konkreten Fall keine befriedigende Minimierung erreicht hat Die von dem Kriterium Effects on pre states geforderte berdeckung auf Cabin Control l sst sich n mlich mit deutlich weniger Testf llen erreichen mit einem Testfall und 14 Teststeps was auch in Tabelle 6 7 beschrieben ist Experimente zeigten dass die Dauer der Testfallgenerierung von Integrationstestf llen f r die Modelle CabinControl und Infotainment meistens mehrere Minuten betr gt Die Generierung aus dem weitaus komplexeren Modell Liegenpr fplatz kann selbst im Falle der schw chsten zustandsbasierten Kriterien mehrere Stunden dauern Wie auch im Falle der Komponententestf lle wurden die generierten Testfallmengen f r den Integrationstest einem weiteren Optimie
224. r Transition 7 1 3 Fehlererkennungspotential der Testfallmengen f r den Komponententest Zur Bewertung des Fehlererkennungspotentials von Testfallmengen f r den Komponententest wurde die Mutationsanalyse f r Testfallmengen durchgef hrt die jeweils die Kriterien Zustands Transitions und Transitionspaar berdeckung auf den Zustandsautomaten die in Tabelle 6 2 be schrieben werden erf llen Daf r wurden in einem ersten Schritt Mutanten dieser Zustandsau tomaten generiert Zur Generierung dieser Mutanten wurden alle Modell Mutationsoperatoren mit Ausnahme der Operatoren der Klasse Aufruf Operatoren angewendet Diese Operatoren wurden nicht in Betracht gezogen weil die dadurch erzeugten Mutanten intermodulare Feh ler simulieren die nur die Interaktion von Komponenten betreffen Somit wurden f r jeden Zustandsautomat mehrere Mutanten generiert 132 Mutanten durch Anwendung der Operato ren auf den Zustandsautomat Konto 429 Mutanten durch Anwendung auf den Zustandsautomat InfotainmentGui und 780 Mutanten durch Anwendung auf den komplexesten Zustandsautomat Achstest Il Siehe Abschnitt 7 1 2 1 139 7 Evaluierung des Fehlererkennungspotentials modellbasierter Testf lle Anschlie end wurden die in Tabelle 6 3 beschriebenen Testfallmengen die Komponententest kriterien auf den jeweiligen Zustandsautomaten entsprechen auf diese Mutanten automatisch ausgef hrt und der erreichte Mutation score berechnet gem der
225. r der Mu tationsoperator Dieser f gt in die neu generierten Individuen kleine nderungen ein so dass Individuen entstehen k nnen die nicht als Kombination der Individuen aus der Anfangspopula tion beschrieben werden k nnen 4 3 Einsatz genetischer Algorithmen zur automatischen modellbasierten Testfallgenerierung Als Meta Heuristiken beschreiben genetische Algorithmen ein allgemeines Verfahren zur Suche nach L sungen f r Optimierungsprobleme Um diese Algorithmen zur L sung eines speziellen 73 4 Automatische modellbasierte Testfallgenerierung mittels genetischer Algorithmen Problems einsetzen zu k nnen m ssen sie an das Problemgebiet angepasst werden D h es muss festgelegt werden wie e die Individuen kodiert werden e die genetischen Operatoren Elitismus Selektion Rekombination Mutation vorgehen d h es muss festgelegt werden wie die Individuen durch Anwendung dieser Operatoren ausgew hlt bzw ver ndert werden die Anfangspopulation generiert wird die Fitnessfunktion definiert ist e die Abbruchbedingung des Algorithmus lautet Im Folgenden wird auf die Anpassung der genetischen Algorithmen f r die modellbasierte Testfallgenerierung unter Ber cksichtigung dieser Punkte einzeln eingegangen 4 3 1 Kodierungsvorschrift f r Individuen Eingesetzt im Kontext der automatischen Testfallgenerierung zielt der genetische Algorithmus auf die Generierung einer m glichst optimalen Testsuite Durch
226. r wird an den Si mulator der Komponente A geschickt Transition A6 wird durchlaufen was zu dem neuen aktiven Zustand A2 f hrt Der Effect dieser Transition enth lt einen Aufruf der Kompo nente B Der Guard der Transition tB4 wird zu true evaluiert weil y 69171531 und somit gr er als 0 ist was dazu f hrt dass tB4 traversiert wird Daraus resultiert der neue aktive Zustand B3 von Komponente B Die von diesem Testfall berdeckten Transitionen sind tAl tBl tA3 tB2 tA5 tA6 tB4 Anhand dieser Liste an berdeckten Transitionen l sst sich feststellen dass die Transition tB4 als Folge des Durchlaufens der Transition tA6 traversiert wurde Dieser Testfall hat also das Mapping m tA6 tB4 berdeckt Da es insgesamt zwei Mappings gibt betr gt die von diesem Testfall erreichte berdeckung bez glich dem Kriterium Invoking invoked transitions 50 Zur Uberdeckung des anderen Mappings m sste ein zus tzlicher Testfall generiert werden z B opAl 4 opA2 opB1 1774416 opA3 Dieser Testfall berdeckt folgende Transitionen tA 1 tBl tA3 tA5 tB2 tA6 tB3 Um die gew nschte berdeckung mit einem statt zwei Testf llen zu erreichen m sste der erste Testfall so adaptiert werden dass er beide Mappings berdeckt Ein Beispiel f r einen Testfall der beide Mappings berdeckt ist 82 4 3 Einsatz genetischer Algorithmen zur automatischen modellbasierten Testfallgenerierung opA1 4
227. ra tion Testing A Survey Technical Report 2005 TR 41 Italian National Research Council 2005 Atanas Rountev Scott Kagan and Jason Sawin Coverage Criteria for Testing of Object Interactions in Sequence Diagrams In Fundamental Approaches to Soft ware Engineering LNCS 3442 pages 282 297 2005 S Rapps and E J Weyuker Selecting Software Test Data Using Data Flow Infor mation Software Engineering IEEE Transactions on SE 11 4 367 375 1985 Peter Scholz Softwareentwicklung eingebetteter Systeme Grundlagen Modellie rung Qualitdtssicherung Springer Berlin 2005 Dominik Schindler Bewertender Vergleich und Erweiterung unterschiedlicher UML Simulatoren zur Bestimmung der Modelliiberdeckung Diplomarbeit Lehr stuhl f r Software Engineering Universit t Erlangen N rnberg 2006 Sven S hnlein Quantitative Bewertung der Softwarezuverl ssigkeit komponenten basierter Systeme durch statistische Auswertung der Betriebserfahrung Disserta tion Friedrich Alexander Universit t Erlangen N rnberg 2010 SJ04 SM10 SMFS00 Sok04 Som10 SOPO7 SOP08 SP10 Spi89 LITERATURVERZEICHNIS Francesca Saglietti and Martin Jung Classification Analysis and Detection of Interface Inconsistencies in Safety Relevant Component based Systems In U Schmocker C Spitzer and V N Dang editors Proceedings of Probabilistic Sa fety Assessment and Management volume 4 pages 1864 1869 Springer V
228. rauf installierte Betriebssystem ist Windows 7 64 Bit Version 7D h es wird berpr ft ob der genetische Algorithmus die Testfallmengen so optimieren kann dass die erreichte berdeckung verbessert werden kann dies kann nur im Falle der Testfallmenge f r Transitionspaar berdeckung auf Achstest erreicht werden da nur hier die 100 ige berdeckung nicht erreicht wurde oder ob die berde ckung auch mit weniger Testf llen bzw Teststeps erreicht werden kann 114 6 3 Ergebnisse der Testfallgenerierung f r den Komponententest dieses Generierungsschrittes bei der Bewertung der Individuen auch die Anzahl an generierten Teststeps ber cksichtigt mit dem Ziel die Teststepanzahl auch zu minimieren Wie dies umge setzt wurde wird hier kurz skizziert Wie schon in Abschnitt 4 3 4 beschrieben werden vor dem Anwenden der genetischen Operatoren auf eine Population die Individuen der Population der Fitness nach absteigend sortiert Die Fitness wird dabei als gewichtete Summe ber die ber deckung und ber die Anzahl an Testf llen berechnet gem Formel Im Rahmen dieses zus tzlichen Generierungsvorgangs ber 200 Generationen wird diese Sortierung dahingehend erweitert dass bei gleicher Fitness zweier Individuen auch deren Teststepanzahl betrachtet wird D h wenn zwei Individuen die gleiche Fitness haben dann wird das Individuum besser be wertet das weniger Teststeps enth lt Die Ergebnisse des zus tzlichen Generierungsvorgang
229. reibt Probleme die bei der bersetzung des Quellcodes in Maschinencode entdeckt werden k nnen Ein Beispiel f r solch ein Problem ist wenn die Parameter an den Operationen der Schnittstellen unterschiedliche Datentypen haben e Semantische Inkonsistenzen solche Inkonsistenzen treten auf falls Daten die zwischen Komponenten ausgetauscht werden von den einzelnen Komponenten unterschiedlich in terpretiert werden So z B wenn eine Komponente einen bestimmten Integer Wert als Kenngr e f r das Gewicht in Ma einheiten des metrischen Systems wohingegen die an dere Komponente diesen Wert in Ma einheiten des amerikanischen Systems interpretiert e Anwendungsbasierte Inkonsistenzen wenn Komponenten wiederverwendet werden dann werden sie h ufig in einer anderen als der urspr nglich gedachten Anwendungslandschaft eingesetzt Falls die Komponenten die Vorgaben der neuen Umgebung nicht erf llen dann bestehen anwendungsbasierte Inkonsistenzen Beispiel f r so eine Inkonsistenz ist wenn eine Komponente in der neuen Umgebung mit Parameterwerten aufgerufen wird die au Derhalb des Wertebereichs liegen der von der Komponente unterst tzt wird e Pragmatische Inkonsistenzen solche Inkonsistenzen betreffen Unstimmigkeiten in der Rech nerumgebung in der die Komponente eingesetzt wird Pragmatisch werden diese In konsistenzen deshalb genannt weil es um die tats chliche Ausf hrung unter Einfluss der Rechnerumgebung geht Inkonsi
230. ren werden zun chst im folgenden Unterabschnitt die Grundlagen des Mutationstests beschrieben Siehe Abschnitt 6 3 122 7 1 Erkennungspotential hinsichtlich Modellierungsfehler 7 1 1 Mutationstest Der Mutationstest ist eine Testart die sich von den in Abschnitt beschriebenen Testarten grundlegend unterscheidet hierbei geht es nicht mehr darum Softwarefehler zu finden sondern um die Bewertung einer Testsuite hinsichtlich ihres Fehlererkennungspotentials Der Mutationstest basiert auf zwei wichtigen Annahmen Zum einen auf der Annahme dass erfahrene Programmierer fast korrekte Programme schreiben die nur geringf gig vom vorge sehenen Verhalten abweichen Engl Competent Programmer Hypothesis Zum anderen wird angenommen dass komplexe Fehler an einfache Fehler gekoppelt sind Das hei t dass Testf lle die in der Lage sind einfache Fehler zu entdecken sich auch dazu eignen komplexere Fehler zu finden Engl Coupling Effect Hypothesis Ans tze zur Bewertung von Testsuites mittels Mutationstest sind vor allem auf Codeebene sehr verbreitet So z B werden in Ost07 DMMOI WSOS alle Testf lle einer Test suite auf der Originalversion und auf ge nderte Versionen der Software so genannte Mutanten welche durch so genannte Mutationsoperatoren entstehen ausgef hrt Durch Vergleich des sich dabei ergebenden Verhaltens wird bewertet ob ein Testfall bestimmte Mutanten zu entdecken erlaubt Eine Testsuite erkennt e
231. rfsspezifikationen ausreichend detailliert und korrekt vorhanden ist e Installationstest Tests dieser Art berpr fen ob sich die Software so installieren l sst wie es im Benutzerhandbuch beschrieben ist e Wiederinbetriebnahmetest es soll durch solche Tests gepr ft werden ob ein System nach dessen Ausfall wieder in Betrieb genommen werden kann 2 5 1 4 Abnahmetest Im Rahmen dieser Testart wird anhand der Vorgaben des Pflichtenhefts bewertet in welchem Umfang die Software den Vertrag zwischen Kunden und Entwickler erf llt Dieser Test wird in der Einsatzumgebung des Kunden durchgef hrt mit dem Ziel dass der Kunde am Ende dieser Testphase ber die Abnahme oder Ablehnung des Systems entscheiden kann Aufgrund der Tatsache dass w hrend des Systemtests die Produktionsumgebung des Kunden nur simuliert wird kann es beim Abnahmetest vorkommen dass Testf lle die in der simulierten Umgebung beim Entwickler als bestanden markiert wurden bei Ausf hrung in der Kundenum gebung Fehler aufdecken 2 5 1 5 Regressionstest Die bisher beschriebenen Testphasen werden vor der Erstinstallation der Software beim Kunden durchgef hrt Der Lebenszyklus ist allerdings nicht mit der Abnahme durch den Kunden beendet Es folgen noch die Phasen der Wartung und Abl sung der Software Im Rahmen der Wartung werden nderungen an der Software vorgenommen Dies kann meh rere Gr nde haben was dazu f hrt dass es mehrere Wartungsarten
232. rienbeschreibung basiert auf folgenden Definitionen als Ereignisse Engl Events werden Aufrufe von Schnittstellenoperationen definiert Einzelne Events k nnen abh ngig voneinander sein wobei zwischen zwei Arten von Abh ngigkeiten unterschieden wird Context dependence bedeutet dass ein Event als Folge des Aufrufs eines anderen Events aufgerufen wird Zwei Events sind dagegen Content dependent wenn der Wert einer Variable durch ein Event ge n dert und durch das andere Event ausgelesen wird Folgende berdeckungskriterien wurden ein gef hrt das Interface Test Coverage Kriterium verlangt dass jede Operation der Schnittstelle einer Komponente mindestens einmal aufgerufen wird im Gegensatz dazu verlangt das Event Test Coverage Kriterium dass die Aufrufe der Operation aus jedem m glichen Kontext heraus berdeckt werden Das Context dependence Test Coverage Kriterium verlangt dass Sequenzen von Events berdeckt werden die in einer Context dependent Abh ngigkeitsbeziehung stehen Das Content dependence Test Coverage Kriterium fordert die berdeckung von Events die in einer Content dependent Abh ngigkeitsbeziehung stehen Eine Reihe von Arbeiten zur modellbasierten Herleitung von Integrationstestf llen besch fti gen sich mit der automatischen Testfallgenerierung aus Sequenzdiagrammen RKS05 SM 10 CNMO7 und BBOO Dabei sind die Kriterien darauf ausgerichtet entweder einzelne Messages des Diagramms oder Message Sequenzen zu
233. rschiedene Arten von Black Box Testverfahren Die funktionale quivalenzklassen bildung beschreibt eine Systematik die darauf basiert dass der ganze Eingaberaum der Soft ware in einzelne Klassen aufgeteilt wird so dass alle Eingaben aus einer bestimmten Klasse von der Software gleichartig bearbeitet werden Deshalb kann davon ausgegangen werden dass jede Klasse durch eines ihrer Elemente ad quat repr sentiert wird Darauf aufbauend verlangt dieses Testverfahren dass die Software mit mindestens einem Repr sentanten jeder quivalenzklasse getestet wird 31 2 Grundlagen Eine Erweiterung der funktionalen Aquivalenzklassenbildung stellt die Grenzwertanalyse dar die als Eingaben nicht beliebige Vertreter der quivalenzklasse verlangt sondern speziell die Vertreter die sich an den Grenzen der Klassen befinden Dieses Verfahren basiert auf der Erfah rung dass Fehler in der Software besonders h ufig auftreten wenn Werte ausgew hlt werden die an den Grenzen der Aquivalenzklassen liegen Lig09 2 5 2 2 White Box Test Diese Testart wird auch Strukturtest strukturelles Testen oder strukturorientierter Test genannt und wird wie folgt definiert Definition 2 4 White Box Test aus Ist10 Procedure to derive and or select test cases based on an analysis of the internal structure of a component or system Wie es der Name schon suggeriert orientieren sich die Verfahren die sich dieser Kategorie zuordnen lassen an der Strukt
234. rt generierter Testf lle bzgl der Erkennung von Implementie rungsfehlern wurde die in Abschnitt 6 4 beschriebene Testfallmenge die das nvoking invoked transitions Kriterium erf llt betrachtet Da diese Testfallmenge automatisch generiert wurde entstand kein manueller Aufwand bei deren Erstellung Allerdings ben tigte die Erstellung des der Testfallgenerierung zugrunde liegenden Modells ca 18 Stunden 135 7 Evaluierung des Fehlererkennungspotentials modellbasierter Testf lle Bei Betrachtung der Anzahl enthaltener Teststeps f llt auf dass die automatisch generierte Testfallmenge mehr als viermal mehr Teststeps enth lt als die manuell erstellte Testfallmenge Die dabei resultierende berdeckung betr gt im Falle der automatisch generierten Testfallmen ge 100 bez glich der ausf hrbaren Mappings Dagegen betr gt die von der manuell erzeugten Testfallmenge auf dem Modell erzielte berdeckung bez glich aller ausf hrbaren Mappings blo 58 Sowohl hinsichtlich Umfang als auch Modell berdeckung sind diese zwei Testfall mengen also sehr unterschiedlich Insofern lohnt sich das aufw ndigere modellbasierte Verfah ren erst dann wenn dadurch Fehler entdeckt werden die von den manuell erstellten Testf llen nicht erkannt werden Durch Ausf hrung der automatisch generierten Testsuite wurden drei Fehler entdeckt die von der manuell erzeugten Testsuite nicht entdeckt wurden Bei den dabei aufgefundenen Feh lern handelte es
235. rter Testf lle meisten Modell Mutationsoperatoren erzeugen pro Transition nur einen Mutant wenige Opera toren z B der Guard Variable Andern Operator k nnen aber mehrere Mutanten erzeugen Alle erzeugten Mutanten werden in einem weiteren Schritt berpr ft in Abbildung mu tantSyntaktischKorrekt m Falls der betrachtete Mutant syntaktisch korrekt ist wird er auf der Festplatte abgespeichert in Abbildung 7 2 speichere m falls nicht wird er verworfen Wes halb diese zus tzliche berpr fung erforderlich ist wird anhand des folgenden Beispiels erkl rt Wird der Operator Trigger ndern auf der Transition rA3 aus Abbildung angewendet tauscht er den Trigger dieser Transition durch einen Trigger einer anderen Transition aus z B durch den Trigger der Transition fA2 Dann ndert sich die Transition tA3 wie folgt aus 143 Al opAl i int i gt 0 x i A2 wird tA3 Al opAS del x i A2 Durch diese nderung ist der Guard und der Effect der Transition tA3 ung ltig geworden da die Variable i die im Guard und im Effect referenziert wird nicht mehr definiert ist Des Weiteren kann durch nderung des Triggers einer Transition ein nichtdeterministischer Zustandsautomat erzeugt werden Dies kommt dann vor wenn nach der nderung des Triggers im Automaten zwei Transitionen den gleichen Pre state und den gleichen Trigger bei gleichzei tig nicht disjunkten Guards haben Da durch das Werkzeug solche ni
236. rung verfolgt Wann die lokale Optimierung eingesetzt wird wird ber den Stagnationsparameter gesteuert Dieser muss vor dem Start der Generierung festgelegt werden und gibt an nach wie vielen Gene rationen ohne berdeckungsfortschritt der globalen Optimierung die lokale Optimierung einge schaltet werden soll Die Abbruchbedingung f r die lokale Optimierung wird ber zwei weitere Parameter gesteuert Der lokale Stagnationsparameter gibt an nach wie vielen Generationen oh ne Fitnessfortschritt der lokalen Optimierung zur ck zur globalen Optimierung gewechselt wird 7Die berdeckungsbestimmung dieses Integrationstestfalls wird in Abschnitt 4 3 3 1 beschrieben 75 4 Automatische modellbasierte Testfallgenerierung mittels genetischer Algorithmen Ein weiterer Parameter gibt die Anzahl der lokalen Generationen an nach denen auf jeden Fall zur ck zur globalen Optimierung gewechselt wird W hrend der lokalen Optimierungsphase werden einzelne Testf lle als Individuen angesehen der umgesetzte Basisalgorithmus ist aber derselbe jedoch mit einer unterschiedlichen Fitness funktion und einer Einschr nkung in der Wahl der genetischen Operatoren Von den verf gba ren Rekombinations und Mutationsoperatoren werden im lokalen Optimierungsschritt nur die Operatoren betrachtet die auf Aufruf und Testdatenebene angewendet werden k nnen Der Elitismus und Selektionsoperator funktionieren hnlich wie bei der globalen Optimierung Di
237. rungsschritt unterzogen mit dem Abbruchkriterium 200 Generationen Die Ergebnisse werden in Tabelle 6 7 beschrieben wobei fett markiert die Werte dargestellt werden die geringer sind als die Werte aus den dazu entsprechenden Zellen der Tabelle M Kl K2 K3 K4 K5 K6 K7 K8 TC TS TC TS TC TS TC TS TC TS TC Ts TC TS TC TS C 2 16 4 22 1 14 2 3 3 37 4 49 I 1 32 2 50 1 9 1 47 2 51 3 54 L 7 89 11 166 12 128 13 160 17 250 33 440 35 477 M Betrachtetes Modell C CabinControl I Infotainment L Liegenpr fplatz TC Anzahl generierter Testf lle TS Anzahl generierter Teststeps K1 K8 siehe Tabelle Tabelle 6 7 Ergebnisse der Testfallgenerierung f r den Integrationstest nach einem weiteren Optimierungsschritt Die Testfallgenerierung wurde auf einem Rechner mit Intel Core 2 Quad Prozessor 2 66GHz durchgef hrt Der Rechner verf gt ber 4GB Arbeitsspeicher das darauf installierte Betriebssystem ist Windows 7 64 Bit Version 119 6 Evaluierung der vorgestellten Testfallgenerierungsmethode Zur bersichtlichen Beschreibung der erreichten Ergebnisse pro Modell werden die Daten aus den vorigen drei Tabellen in jeweils einer Abbildung graphisch aufgearbeitet Jede Abbildung enth lt zwei Diagramme Im linken Diagramm werden die Anzahl der f r das Erreichen einer 100 igen Uberdeckung generierten Testf lle pro Kriterium z B in Abbildung 6 2 links Daten reihe CabinControl dargestellt Des Weiteren
238. rzeugt wird Dieser Vorgang wird iterativ fortgesetzt und terminiert sobald einer der generierten Individuen einer Population einen vorgegebenen Fitnesswert erzielt hat bzw ein vorgegebenes Abbruchkriterium etwa eine vorgegebene Anzahl an Iterationen erreicht wurde Skizziert wird dieses Vorgehen in Abbildung 4 1 Zentral f r die Effizienz solcher Algorithmen sind also die Operatoren die aus einer beste henden Population eine neue Population erzeugen sollen Dazu werden die Operatoren so lange angewendet bis die neue Population eine vorgeschriebene Populationsgr e erreicht Im Fol genden werden die genetischen Operatoren allgemein beschrieben bevor die konkrete Imple mentierung der Operatoren f r das im Rahmen dieser Arbeit betrachtete Problem in Abschnitt 4 3 beschrieben wird Elitismus Grundidee der genetischen Algorithmen ist es aus einer bestehenden Population durch Anwen dung genetischer Operatoren auf Eltern Individuen neue Kind Individuen zu generieren die die neue Population bilden Bei der Erzeugung neuer Individuen kann es vorkommen dass diese eine schlechtere Fitness als ihre Eltern Individuen haben Dies kann dazu f hren dass die neu erzeug 70 4 2 Allgemeine Funktionsweise genetischer Algorithmen initiale Population l Evaluierung Abbruchbedingung erf llt Anwendung genetischer Operatoren V bestes Individuum Abbildung 4 1 Allgemeine Vorgehensweise
239. s also der Testsuite T S Basierend auf den gerade beschriebenen Konzepten wird nun die Formel f r die Berechnung der Fitness einer Testsuite TS angegeben F TS GU EU TS GT AT TS wobei G GT 0 1 AG GT 1 4 3 Dabei steht GU f r das Gewicht das f r die berdeckung festgelegt wurde EU T S steht f r die erreichte berdeckung dieser Wert wird anhand der Formel 4 1 berechnet GT steht f r die Gewichtung die f r die Testfallanzahl festgelegt wurde und AT T S f r einen Wert der anhand der in der Testsuite enthaltenen Anzahl an Testf llen nach der Formel 4 2 berechnet wird Die Gewichte G und GT m ssen vor dem Start der Testfallgenerierung festgelegt werden wobei die einzelnen Gewichte den Wertebereich 0 1 haben und die Summe der Gewichte 1 ist Die lokale Fitnessfunktion bewertet jeden Testfall indem der durch den Testfall berdeckte Pfad betrachtet wird Unter anderem wird berechnet wie weit sich das letzte Element dieses Pfades vom gesuchten Element befindet Dazu wird statisch ermittelt wie viele Kanten mindes tens vom letzten Element das durch den Testfall berdeckt wird bis zum Element das berdeckt werden soll durchlaufen werden m ssen Danach wird berechnet wie viele Aufrufe im Testfall fehlen um diese Kanten zu berdecken Des Weiteren wird berechnet inwiefern die Guards an diesen Kanten durch den aktuellen Testfall erf llt werden Dadurch dass diese Werte einzel
240. s werden in Tabelle 6 4 dargestellt Fett markiert werden Werte die im Vergleich zu den Werten aus Tabelle 6 3 kleiner sind ZM Zustands b Transitions b Transitionspaar b TC Ts TC TS TC TS Konto 2 6 4 25 21 133 InfotainmentGui 4 21 12 98 40 632 Achstest 8 76 20 233 73 1204 ZM Betrachteter Zustandsautomat TC Anzahl generierter Testf lle TS Anzahl generierter Teststeps Tabelle 6 4 Ergebnisse der Testfallgenerierung f r den Komponententest nach einem weiteren Optimierungsschritt Durch diesen zus tzlichen Generierungsvorgang konnten fast alle Testfallmengen minimiert werden Nicht in allen F llen konnte die Anzahl an Testf llen verringert werden daf r konn te aber in den meisten F llen die Anzahl an Teststeps minimiert werden Bei den Testfallmen gen die Zustands berdeckung erreichen bestand das geringste Optimierungspotential Die aus 2 Testf llen bestehende Testfallmenge die Zustands berdeckung auf Konto erreicht konnte nicht weiter optimiert werden Bei den anderen zwei Testfallmengen f r Zustands berdeckung konn ten ebenfalls keine Testf lle eingespart werden daf r konnte aber die Anzahl der Teststeps mi nimiert werden zum einen von 30 auf 21 und zum anderen von 80 auf 76 115 6 Evaluierung der vorgestellten Testfallgenerierungsmethode Im Gegensatz dazu konnten alle Testfallmengen f r Transitions berdeckung bedeutend ver bessert werden da sowohl die Anzahl an Testf llen als auch di
241. s 37 2 6 Modellbasierter Test 2n 38 3 Modellbasierte berdeckungskriterien 44 3 Verhaltensbeschreibung von Komponenten mittels UML Zustandsautomaten 44 Edd Zuusta d amp wk a EKER S X HR e ed 45 3 12 KETTEN 45 3 2 Modellbasierte berdeckungskriterien f r den Komponententest 52 3 3 Modellbasierte berdeckungskriterien f r den Integrationstest 54 Dor Mappine WEE 59 3 3 2 Zustandsbasierte berdeckungskriterien 222222222220 61 4 Automatische modellbasierte Testfallgenerierung mittels genetischer Algorithmen 66 4 1 Motivation eo antares CRUS E E UR AC UR AOACE ra nr E Poss 66 69 TD UE TE ER PN 73 4 3 1 Kodierungsvorschrift f r Individuen 2 2 2222 222 none 74 rr 76 Tr LETT 78 4 3 3 1 berdeckungsbestimmung durch Simulation 80 m 83 4 3 4 1 Bh smisoperatgt os sos a o oo eR Brad Be OS mos 83 4 34 2 Selek onsoperator 2 2222 llle 83 4 3 4 3 Rekombinationsoperatoren 85 EE 87 4 3 5 Abbruchbedingungen A ee qd e 2 Gate kh et Bs he D as 87 5 Werkzeugunterst tzung 89 5 1 Das Werkzeug UNITED 34 uoa amp aoa 24 0 wa 2 wa RC RS ADR Den 89 5 2 Visualisierung berdeckter sowie zu berdeckender Modellelemente 95 5 2 1 Visualisierung berdeckter und noch zu berdeckender atomarer Entit ten 97 5 2 2 Visualisierung berdeckter und noch zu berdeckender zusammenge EE ENEE SE
242. s Softwaresystems generativ aus formalen Modellen abge leitet werden Bei den erzeugten Artefakten handelt es sich nicht nur um den Quelltext einer ausf hrbaren Programmiersprache z B Java oder C sondern auch um andere Dateien die f r die Lauff higkeit des Systems ben tigt werden z B Konfigurationsdateien Resource Bund les und Datenbankskripte Dar ber hinaus k nnen auch den Entwicklungsprozess unterst tzende 2 1 Modellbasierte Softwareentwicklung Artefakte generiert werden z B Softwaretests und Dokumentationen Dank der guten Werkzeugunterst tzung bei der Erstellung von Modellen k nnen im Rahmen der modellgetriebenen Softwareentwicklung aus Artefakten einer spezifischen Phase Artefakte generiert werden die in den darauf folgenden Phasen benutzt werden k nnen So z B bieten Modellierungswerkzeuge die M glichkeit aus Modellen automatisch Codeger ste zu generie ren Um die erw nschte Funktionalit t zu erhalten m ssen diese Codeger ste in einem weiteren Schritt verfeinert werden indem das Verhalten Implementierung der Methoden manuell codiert wird Aufgrund der zentralen Bedeutung der Modelle h ngt der Erfolg modellbasiert entwickelter Softwaresysteme sehr davon ab ob die erstellten Modelle eine hohe Qualit t erreichen d h ob sie die zu modellierenden Aspekte korrekt und vollst ndig wiedergeben und dabei verst ndlich und berschaubar bleiben widmet sich grundlegenden Betrachtungen zur Quali t
243. s unterschiedlicher UML Werkzeuge erstellt wurden Voraussetzung daf r ist dass die Werkzeuge den Export in das EMF UML2 XMI Format unterst tzen Hier kann von den Erfahrungen mit der Benutzung von zwei UML Werkzeugen berichtet werden Zum einen handelt es sich um das Werkzeug MagicDraw http www eclipse org eclipse http subversion tigris org 3Die benutzte in Version ist 15 5 89 5 Werkzeugunterst tzung und zum anderen um das Werkzeug Enterprise Architect Der von MagicDraw erzeugte Modell export kann unver ndert mit dem Werkzeug UnITeD geladen werden Im Gegensatz dazu ist der von Enterprise Architect erzeugte XMI Export nicht ganz im vom Werkzeug UnITeD ben tigten Format Deshalb m ssen diese XMI Dateien mittels eines XSLT Skripts nachtr glich bearbeitet werden Neben der Beschreibung der statischen Struktur und des dynamischen Verhaltens des zu mo dellierenden Systems muss das Modell auch eine Testsystembeschreibung enthalten Diese bein haltet zus tzliche Informationen die f r die Testfallerstellung relevant sind Dazu enth lt es meh rere TestContexte die eine oder mehrere Komponenten referenzieren Dar ber hinaus enth lt jeder TestContext ein Setup Sequenzdiagramm das die referenzierte n Komponente n instan ziert und Beziehungen zwischen ihnen herstellt Da ein Modell im Allgemeinen mehrere Komponenten enthalten kann wird dieses Testsystem ben tigt um bei der Testfallgenerierung den Fokus
244. schen Al gorithmen gezielt eingesetzt Der Unterschied zur gew hnlichen Testfallgenerierung besteht dar in dass bei der Generierung der Anfangspopulation die alte Testsuite f r die die Regressi onsanalyse durchgef hrt wurde bernommen und im Verlauf der weiteren Generierung nicht 24Siehe Abschnitt 104 5 3 Unterst tzung des Regressionstests mehr ver ndert wird Ziel dieser Generierung ist es die alte Testsuite so um weitere Testf l le zu erweitern dass sie eine 100 ige berdeckung auf dem ge nderten Modell erreicht bei gleichzeitiger Minimierung der Anzahl ben tigter zus tzlicher Testf lle Als Beispiel f r solch eine Testfallmenge sei TNeu T1 T2 T3 T4 die auf dem ge nderten Modell eine 100 ige Transitions berdeckung erreicht Zur Beschreibung der Funktionsweise der Regressionstestgenerierung anhand eines konkre ten Zustandsautomaten wurde aus InfotainmentGui eine Testsuite generiert die 16 Testf lle enth lt und eine 100 ige Transitions berdeckung erreicht Danach wurde der Automat wie folgt ge ndert zum einen wurde eine Transition gel scht daf r wurde eine zus tzliche Transition hinzugef gt und zuletzt wurde der Name eines Zustands ge ndert Dies wird in Abbildung 5 10 dargestellt incomingCall gt waitingForTalkButton F Ok incomingMegsagd incomirjgCall messageReceivedAndShown ke I DI a gel schte Transition i incomingCall Okf
245. se ist die Termingetriebene Integration Engl Schedule Driven Diese gibt vor dass nach dem Prinzip First Come First Serve Komponenten entsprechend ihrer Verf gbarkeit integriert werden sollen Die Risikogetriebene Integration Engl Risc Driven geht nach dem Prinzip Hardest First vor es werden erst die Komponenten zusammengesetzt deren Ausfall ein hohes Risiko darstellt Die Testgetriebene Integration Engl Test Driven orientiert sich an Testf llen und verlangt dass erst einmal die Komponenten integriert werden m ssen die f r die Ausf hrung bestimmter Testf lle ben tigt werden hnlich wie die testgetriebene Integration geht auch die anwendungsgetriebene Integration Engl Use Case Driven vor mit dem Unterschied dass hier nicht Testf lle als Startpunkt dienen sondern einzelne Use Cases oder Gesch ftsprozesse Es gibt also eine F lle von Strategien Die Wahl der im Einzelfall optimalen Integrationstest strategie obliegt dem Testmanager wobei dazu die Randbedingungen des Projekts zusammen mit dem Projektmanager analysiert werden m ssen 2 5 1 3 Systemtest Diese Testart zielt auf die Bewertung der Funktionalit t der Software hinsichtlich der Erf llung der Kunden Anforderungen Der Systemtest ist sehr wichtig weil er die letzte M glichkeit bietet Fehler zu finden und zu beseitigen bevor die Software an den Kunden ausgeliefert wird Alle Fehler die danach gefunden werden beeinflussen den Kunden direkt u
246. ses Subsystem wird dann nach und nach um weitere Komponenten erweitert Welche Komponenten zuerst integriert werden wird anhand der Architektur bestimmt Ein kleiner Nachteil dieser Strategien im Vergleich zur Strategie Big Bang Integration ist 25 2 Grundlagen dass f r die noch nicht integrierten Komponenten Testtreiber und oder Platzhalter programmiert werden m ssen was zus tzlichen Aufwand bedeutet Die Vorteile strukturorientierter Integration berwiegen aber wie die folgenden Ausf hrungen zeigen Top Down Integration ist eine Strategie die fordert dass als erstes die Komponenten der obers ten Softwareschicht also die anwendernahen Komponenten integriert werden Dies sind meis tens Komponenten die andere Komponenten aufrufen selbst aber nicht von anderen Kompo nenten sondern nur von der Umgebung z B durch den Benutzer aufgerufen werden Da die dadurch aufgerufenen Komponenten am Anfang nicht mit integriert werden werden Platzhalter ben tigt Ein Vorteil dieser Strategie ist dass die anwendernahen Komponenten fr h verf gbar sind und getestet werden k nnen Somit kann der Kunde fr h in den Beurteilungsprozess mit einbezogen werden Bottom Up Integration entgegengesetzt zur Top Down Strategie verlangt diese dass erst die systemnahen Komponenten integriert werden Dies sind Komponenten die meistens aufer Be triebssystemfunktionen keine anderen Funktionen f r die Umsetzung deren Funktionalit t aufru f
247. sgraph Kontrollflussorientierter Test Kopplung Leistungstest lokale Optimierung 75 Mapping Mapping basierte Kriterien Mapping Gruppe MBT mehrfache Bedingungs berdeckung Message basierte Kriterien INDEX Mutant Mutantengenerierung Mutation Mutation score 125 Mutationsevaluation 125 Mutationsklasse 143 Mutationsoperator Mutationstest Nachbedingung Nachricht 22 Nondominated Sorting Genetic Algorithm 69 NUnit 23 Object Constraint Language 15 Object Management Group Objektdiagramm Off the shelf Komponente Omission Fault Outside In Integration minimale mehrfach Bedingungs berdeckung 34 P use Mistake Model Checking Model Driven Architecture Model Based Testing Modell Mutationstest modellbasierter Test modellgetriebenes Testen modellorientiertes Testen modellzentrisches Testen Modul Modultest Multi objective Aggregation Paketdiagramm Pareto Front pareto optimal Perfective Maintenance Petri Netze Pfad berdeckung Pfad berdeckungskriterium Platzhalter Post state Post state Andern 137 Post state Operatoren 137 Postcondition 193 INDEX Pre state Pre state ndern 137 Pre state Operatoren 137 Pre states and triggers 61 Pre states triggers and effects 62 Precondition Preventive Maintenance Profildiagramm Programmversagen Protokollzustandsautomat pseudo multi objektiv Random Search r
248. sinnvoll da etwas schlechtere Individuen durch diese Strategie gar nicht beachtet werden Um auch schw chere Individuen bei der Auswahl zu ber cksichtigen beruht die Roulette Wheel Strategie auf die Zuweisung von Auswahlwahrscheinlichkeiten zu einzelnen Individu en wobei die Wahrscheinlichkeit pro Individuum proportional zu der Fitness des Individuums innerhalb der aktuellen Population ist Tournament Selection ist ein weiteres Beispiel f r eine Strategie die auch schw chere Indi viduen ber cksichtigt Um ein Individuum auszuw hlen werden im Rahmen dieser Strategie zun chst zuf llig Individuen aus der aktuellen Generation ausgew hlt Aus der Menge der aus gew hlten Individuen wird das Individuum mit der h chsten Fitness ermittelt Daher auch der Name der suggeriert dass mehrere Auswahlvorg nge Turniere ausgef hrt werden wobei am Ende jedes Turniers ein Sieger das fitteste Individuum selektiert wird Dies bedeutet dass das fitteste Individuum der alten Population eine h here Fitness hat als das fitteste Individuum der neuen Population 5Wird auch Fitness proportionate selection genannt 72 4 3 Einsatz genetischer Algorithmen zur automatischen modellbasierten Testfallgenerierung Rekombination Um ausgehend von den Eltern Individuen neue Kind Individuen zu erzeugen werden Rekom binationsoperatoren eingesetzt Bez glich der Reihenfolge in der Selektion und Rekombina tion ausgef hrt werden gibt es zw
249. stenzen dieser Art treten z B auf wenn die Komponente Dieser Begriff wird in der Arbeit Jun07 stellvertretend f r die komplette Hard und Softwareumgebung der Komponente benutzt 17 2 Grundlagen die an sie gestellten Zeitanforderungen f r die Erbringung eines Dienstes nicht erf llen kann Zur Erkennung solcher Inkonsistenzen eignen sich Qualit tssicherungsverfahren speziell der in Abschnitt 2 5 1 beschriebene Integrationstest Falls solche Inkonsistenzen auftreten miissen die betroffenen Komponenten entweder angepasst werden oder Mechanismen geschaffen wer den um diese Inkonsistenzen zu umgehen Da die Anpassung besonders im Falle von Off the shelf Komponenten nicht durchgef hrt werden kann m ssen Wrapper um die einzelnen Kom ponenten geschaltet werden Jun07 Ein Beispiel f r eine zus tzliche Funktionalit t die durch Wrapper realisiert werden kann ist die Transformation von Werten Im bisherigen Verlauf dieses Kapitels wurden zwei Entwicklungsparadigmen vorgestellt die sich kombinieren lassen so k nnen mit Hilfe der Modellierungssprache UML komponentenba sierte Softwaresysteme entworfen werden Mit den Komponentendiagrammen gibt spezielle Diagrammtypen die sich f r die Beschreibung mehrerer Komponenten und deren Beziehungen eignen Das Verhalten einzelner Komponenten kann mittels Verhaltensdiagrammen der UML beschrieben werden 2 4 Software Qualit tssicherungsverfahren Die in diesem Absc
250. t T E c IT Elc e Istrrje e ecEc e Invoking invoked transitions Kriterium dieses Kriterium verlangt dass f r jedes Sech stupel von Pre state Trigger Effect und Post state der aufrufenden Komponente C und Pre state und Post state der aufgerufenen Komponente C also f r jedes preC trC eC postC preC postC wobei preC Sc trC Tro eC Ec postC Sc preC Sc postC Sc mindestens ein Mapping m t t Map berdeckt wird f r das gilt pre t preC tr t trC e t et post t postC pre t preC post t postC Die Anzahl zu berdeckender Mappings wird anhand der folgenden Formel berechnet Invoking invoked transitions Y Tele e t t T E c Diese Kriterien wurden im Rahmen der Arbeit in eine Hierarchie eingeordnet wel che Subsumptionsrelationen enth lt die wie folgt definiert sind ein Kriterium X subsumiert ein anderes Kriterium L wenn jede beliebige Testfallmenge die K erf llt auch L erf llt Notation in der Hierarchie K L Die aufgestellte Hierarchie wird in Abbildung B 3 dargestellt Neben diesen Kriterien wurden in eine Reihe weiterer neuartiger berdeckungskri terien definiert Zum einen handelt es sich um so genannte Mapping basierte Kriterien die auf die berdeckung einzelner Mappings oder von ganzen Mapping Sequenzen zwischen zwei oder mehreren Komponenten zielen Dar ber hinaus werden Message basierte Kriterien beschrieb
251. t als auch weniger Testf lle enth lt 69 4 Automatische modellbasierte Testfallgenerierung mittels genetischer Algorithmen the fittest Dies bedeutet dass im Laufe der Evolution nur die Individuen berleben die an die u eren Bedingungen am besten angepasst sind also eine hohe Fitness haben Somit k nnen haupts chlich solche gut angepassten Individuen ihre Erbmerkmale weitergeben was dazu f hrt dass die n chste Generation blicherweise besser an die u eren Bedingungen angepasst sein wird als die vorangegangene Der gr te Vorteil genetischer Algorithmen besteht darin dass sie universell einsetzbar sind d h auch f r Probleme die systematisch nicht gel st werden k nnen Ein Nachteil dieser Algo rithmen ist dass sie nicht garantieren eine optimale L sung zu finden Sie erlauben es jedoch innerhalb eines akzeptablen Zeitraums optimierte L sungen zu finden Die Algorithmen funktionieren nach folgendem generischem Prinzip Zun chst wird eine An Jangspopulation von Individuen zuf llig generiert die anschlie end im Hinblick auf ihre Fitness bewertet wird Aus dieser Anfangspopulation geht durch sukzessive Anwendung genetischer Operatoren Elitismus Selektion Rekombination und Mutation eine neue Population hervor die die Anfangspopulation berschreibt Diese neu generierte Population wird hinsichtlich ih rer Fitness bewertet wonach eine neue Population durch erneute Anwendung der genetischen Operatoren e
252. t von Modellen zu den darin erw hnten Qualit tseigenschaften z hlen Korrektheit Einfach heit Verst ndlichkeit Angemessenheit nderbarkeit Vollst ndigkeit Widerspruchsfreiheit und Pr fbarkeit Zur berpr fung von Modellen hinsichtlich dieser Eigenschaften gibt es eine Reihe systematischer Qualit tssicherungsverfahren In erster Linie sollte ein Modell korrekt sein da Fehler die bei der Modellierung entstehen und unentdeckt bleiben sich auch in den aus dem Modell generierten oder anhand des Modells manuell erstellten Artefakten wiederfinden lassen Allgemein bekannt ist dass die Behebung solcher Fehler in den sp teren Phasen des Softwarelebenszyklus z B Implementierungs oder Testphasen das Vielfache der Kosten verursacht die bei einer Behebung w hrend der Modellie rungsphase entstanden w ren GVEBOS F r die Erstellung von Modellen gibt es eine Vielzahl von Modellierungssprachen Abh n gig von dem zugrunde liegenden Vokabular unterscheidet man zwischen visuellen und textuel len Sprachen wobei es auch Sprachen gibt die sowohl textuelle als auch visuelle Konstrukte beinhalten Textuelle Sprachen haben als Vokabular W rter der nat rlichen Sprachen Dagegen stellt das Vokabular der visuellen Modellierungssprachen geometrische Formen z B Rechtecke Kanten Pfeile zur Verf gung Durch Zusammensetzung solcher Formen werden Diagramme er stellt Jedes Diagramm hebt bestimmte Aspekte des Systems hervor die Menge alle
253. tandsautomat InfotainmentGui betrachtet Die Eigenschaften der drei Zustandsautomaten werden in Tabelle 6 2 beschrieben Zu jedem Automaten Spalte ZM werden die Anzahl der enthaltenen Zust nde Spalte Z Transitionen Spalte T und Transitionspaare Spalte TP angegeben hnlich wie f r Mappings gilt auch f r Transitionspaare dass manche Paare gar nicht ausf hrbar sind Deshalb gibt es eine zus tzliche Spalte die die Anzahl ausf hrbarer Transitionspaare angibt Spalte TP ausf 6 2 Parametrisierung der Algorithmen Vor dem Start der Testfallgenerierung m ssen die genetischen Algorithmen parametrisiert wer den Dabei stellt sich die Frage bei welchen Parameterbelegungen der Generierungsprozess am effizientesten funktioniert Zur Bestimmung von Richtwerten f r die einzelnen Parameter wurde das Werkzeug unterschiedlich parametrisiert und ausgef hrt bis eine 100 ige Transiti ons berdeckung auf Modellen mit nur einer Komponente bzw Invoking invoked transitions berdeckung auf dem Modell CabinControl mit mehreren Komponenten erreicht wurde Aus den Parametrisierungen f r die die erzeugte Testfallmenge am kleinsten war wurde diejenige als Richtwert festgelegt f r die die Erstellung der Testfallmenge am schnellsten war Bei der Durchf hrung dieser Experimente wurde schnell deutlich dass die optimale Parametri 7Die Identifikation nicht ausf hrbarer Transitionspaare wurde manuell durchgef hrt 111 6 Ev
254. ten zentrales Konzept ist der Zustand Engl State Die Interpretation des Zustands nach OMG10OJ ist A state models a situation during which some usually implicit invariant condition holds The invariant may represent a static situation such as an object waiting for some external event to occur However it can also model dynamic conditions such as the process of performing some behavior i e the model element under consi deration enters the state when the behavior commences and leaves it as soon as the behavior is completed Der Zustand beschreibt also eine Situation in der sich eine Komponente oder ein Softwaresys tem befinden kann wobei w hrend dieser Situation bestimmte Invarianten erf llt sind Es kann sich dabei um eine statische Situation z B das System zeigt ein Dialogfeld an und wartet auf Eingaben durch den Benutzer oder um eine dynamische Situation z B das System f hrt Be rechnungen durch handeln Zu einem bestimmten Zeitpunkt befindet sich das System in genau einem Zustand dem aktiven Zustand Dargestellt werden Zust nde als Rechtecke mit abgerun deten Ecken Eine spezielle Art von Zust nden sind die so genannten Pseudozust nde Diese dienen unter anderem zur einfachen Darstellung komplexer Beziehungen zwischen Zust nden Beispiele f r Pseudozust nde sind Verzweigungen oder History Zust nde Ein weiterer Pseudozustand ist der Startzustand der den Zustand angibt der beim Betreten des Zustandsa
255. tionen k nnen beispielsweise aus der tex tuellen Spezifikation den Entwurfs Modellen oder dem Quelltext erhoben werden Anhand des Informationsstands der der Generierung zugrunde gelegt wird werden Testans tze in folgende Kategorien aufgeteilt 2 5 2 1 Black Box Test Diese Testart wird auch funktionales Testen oder funktionsorientierter Test genannt und wird wie folgt definiert Definition 2 3 Black Box Test aus Ist10 Procedure to derive and or select test cases based on an analysis of the specification either functional or non functional of a component or system without reference to its internal structure Mittels dieser Testart kann die bereinstimmung eines Softwaresystems mit seiner Spezifika tion berpr ft werden Das zu testende System wird hierbei als Black Box betrachtet was bedeu tet dass Informationen ber die innere Funktionsweise der Software nicht von Bedeutung sind Als Basis f r die Testfallerstellung dient bei diesem Vorgehen allein die Spezifikation Durch die Ausf hrung solcher Testf lle und durch Auswertung der Testergebnisse zeigt sich inwiefern das Softwareprodukt der Spezifikation entspricht Nachteil dieser Vorgehensweise ist dass dadurch nicht abgesch tzt werden kann zu welchem Anteil der Quelltext durch die Ausf hrung dieser Testf lle berdeckt wurde Dies ist deshalb problematisch weil sich in den m glicherweise un berdeckten Quellcodeteilen Fehler befinden k nnten Es gibt ve
256. tionstestkriterien auf dem Modell Infotainment erf llen 153 7 9 Fehlererkennungspotential bzgl einzelner Mutationsklassen von Testfallmengen die zustandsbasierte Integrationstestkriterien auf dem Modell Liegenpr fplatz er EE EE 154 eee 174 175 ae TE mr 176 Ke ER E CECR 177 be sendy Be ae 178 T 179 179 179 oa 179 EE 180 WEE 181 E 182 EE EE 184 B2 Men ppnEt Pile s soe 244 04 2 204 S pu ye Te mei ae ee 185 n RE 185 171 ABBILDUNGSVERZEICHNIS 172 B 4 Konfiguration Auswahl der berdeckungskriterien 2 2 22 22222 186 T ee Bene She Are ae 186 B 6 Konfiguration Einstellungen f r den genetischen Algortihmus 187 B 7 Auswahl TestContext 52 voe vox Ee e ar 9X ar er ee 187 B 8 Anzeige Testfallgenerierungsfortschritt 2 22 20m nn 188 B 9 Kontextmen Testsuite 4 oe e OC RR E ee a nee dea 188 B 10 Anzeige der generierten Testsuitel a 189 B 11 Anzeige einzelner Testf lle aus der generierten Testsuite 189 BIZ Generierung Testskriptej lt s es Gene Du Bae Sue aan dr an des 190 IB 13 Mutationsanalyse J 4 4 22 4228 646444 4644 aa 46 04 aan 190 Tabellenverzeichnis 3 1 Detaillierte Beschreibung der Transitionen der Komponente A 48 3 2 Zusammenfassung existierender Ans tze die modellbasierte berdeckungskri terien f r den Integrationstest beschreiben 58 3 3 Zustandsbasierte berdeckungskriterien f r d
257. toren 1134 Triggers and effects in on pre states 63 UML UML 2 0 Testing Profile 11 Unified Modeling Language Unit UnITeD Unittest Use Use Case Diagramm Validierung Variablenzuweisung Hinzuf gen 135 Variablenzuweisung L schen 135 Variablenzuweisung Operatoren 135 INDEX Verdict Vergleichsoperatoren ndern Verhaltensdiagramme Verhaltenszustandsautomat Verifikation Verteilungsdiagramm vervollkommende Wartung Vorbedingung vorbeugende Wartung Walkthroughs Wartung Wartungsarten Weak Mutation Test White Box Test Wiederinbetriebnahmetest Wrapper XML Metamodel Interchange xUnit Framework Zusammengesetzte Entit ten Zustand Zustand Hinzuf gen 1138 Zustand L schen 138 Zustand Operatoren Zustands berdeckung Zustandsautomat zustandsbasierte Integrationstestkriterien Zustandsdiagramm Zustandsmaschine Zweig berdeckung 195
258. tr3g3ye3 J t2 tr2 92 e2 t9 tr9 g9 e9 tre g8 e8 t5 trs g5eS _ t6 tr amp g6 e6 A6 Abbildung 5 9 Ver nderter Zustandsautomat T3 AO AI A2 A5 A3 A6 Im Hinblick auf die durchgef hrten nderungen am Automaten lassen sich die Testf lle der Testsuite T wie folgt klassifizieren e T1 geh rt der Klasse dentical I da er ausschlie lich unver nderte Modellbereiche durchl uft und somit unver ndert bernommen werden kann e T2 geh rt der Klasse Obsolete X da er im neuen Modell nicht mehr lauff hig ist da der bergang von A4 zu A2 gel scht wurde verbleibt der Zustandsautomat bei der Ausf hrung mit diesem Testfall im Zustand A4 e T3 geh rt zur Klasse Retest Required da er lauff hig ist aber ver nderte Modellteile Zustand A5 durchl uft Dieser Test muss noch einmal durchgef hrt werden Auf dem ge nderten Modell erreicht die Testsuite T also keine 100 ige Transitions berde ckung mehr da die neu eingef gte Transition 79 nicht berdeckt wird Deshalb muss ein zus tz licher Testfall generiert werden der die neu hinzugekommene Transition berdeckt Ein Beispiel f r solch einen Testfall ist der Testfall T4 e T4 dieser berdeckt den Pfad AO A1 A4 A3 A6 also auch die neue hinzugekommene Transition t9 Somit geh rt dieser Testfall zur Klasse New N Zur Generierung solcher Testf lle werden die in Abschnitt H beschriebenen geneti
259. tsuites eingef hrt die InfotainmentGui und Achstest berdecken hier wird das X durch J J von InfotainmentGui re spektive A A von Achstest ersetzt Als Beispiel mit TPI ist die Testfallmenge gemeint die Transitionspaar berdeckung auf dem Zustandsautomat InfotainmentGui erreicht 140 7 1 Erkennungspotential hinsichtlich Modellierungsfehler Von den neun betrachteten Testsuites erreichte TPI mit 78 09 den h chsten Mutation score gefolgt von der Testsuite TPK Bei Betrachtung der Ergebnisse pro Modell f llt auf dass die Testfallmengen f r Transitionspaar berdeckung immer besser abschneiden als die anderen zwei Testfallmengen die auf Grundlage desselben Modells generiert wurden und die Kriterien Tran sitions berdeckung bzw Zustands berdeckung erf llen Auch im Falle des Zustandsautomaten Achstest trifft das zu obwohl TPA nur 97 84 der machbaren Transitionspaare berdeckt Im Folgenden werden diese Ergebnisse pro Modell etwas genauer beleuchtet Die Testsuite ZK enth lt lediglich 2 Testf lle die 23 48 also insgesamt 31 Mutanten zu erkennen erlauben Die Testsuite TK enth lt 6 Testf lle und entdeckt 90 Mutanten was 59 mehr bedeutet als ZK Die Testfallmenge TPK beinhaltet mit 22 Testf llen 16 Testf lle mehr als TK entdeckt allerdings lediglich 8 zus tzliche Mutanten Die Testsuite ZI mit 4 Testf llen erm glicht die Erkennung von 145 Mutanten was 33 8 aller Mutanten entspricht Die Testfallmenge TI enth lt
260. ture Notes in Informatics pages 398 403 Bonn 2007 K llen Druck Verlag GmbH Norbert Oster Automatische Generierung optimaler struktureller Testdaten f r objekt orientierte Software mittels multi objektiver Metaheuristiken Dissertation Friedrich Alexander Universit t Erlangen N rnberg Erlangen 2007 Florin Pinte Gerhard Baier Francesca Saglietti and Norbert Oster Automatische Generierung optimaler modellbasierter Regressionstests In Heinz Gerd Hegering Axel Lehmann Hans J rgen Ohlbach and Christian Scheideler editors Informatik 2008 Beherrschbare Systeme dank Informatik Band 1 volume P 133 of Lecture Notes in Informatics LNI pages 193 198 Bonn September 2008 Gesellschaft f r Informatik e V GI K llen Druck Verlag GmbH Florin Pinte Norbert Oster and Francesca Saglietti Techniques and tools for the automatic generation of optimal test data at code model and interface level In C SE Companion 08 Companion of the 13th International Conference on Software engineering ICSE 2008 pages 927 928 New York NY USA 2008 ACM Florin Pinte and Francesca Saglietti Evaluierung des Fehlererkennungspotentials modellbasierter Komponenten und Integrationstestf lle In Klaus Peter F hnrich and Bogdan Franczyk editors Informatik 2010 Service Science Neue Perspek tiven f r die Informatik Band 2 volume P 176 of Lecture Notes in Informatics pages 375 380 Bonn 2010 K llen Druck Verlag GmbH
261. tzdem ist der erreichte Mutation score be z glich dieser Mutationsklasse niedrig Im Folgenden werden die drei Mutationsklassen bez g lich deren die Transitionspaar berdeckung schlecht abschneidet etwas genauer betrachtet Eine dieser Mutationsklassen ist die Klasse Effect Mutationen Der Grund weshalb Effect 145 7 Evaluierung des Fehlererkennungspotentials modellbasierter Testf lle Mutanten nur zu einem niedrigen Anteil erkannt werden ist dass die nderung eines Effects e t keine Auswirkung auf das Durchlaufen der betroffenen Transition t hat Falls die Transition t im initialen Modell durchlaufen wird dann wird sie auch im Mutant durchlaufen Diese nderun gen beeintr chtigen nur das Durchlaufen anderer Transitionen die im Guard die Variable die im ge nderten Effect bearbeitetet wird referenzieren Um berhaupt die M glichkeit zu haben einen solchen Mutanten zu erkennen m sste ein Testfall also die Transition t in Kombination mit anderen Transitionen berdecken die entsprechende Guards beinhalten Das Kriterium Transi tionspaar berdeckung ist aber nicht auf so eine berdeckung ausgerichtet F r die Erkennung solcher Mutanten k nnten sich Testfallmengen eignen die datenflussbasierte berdeckungskri terien auf Modellebene erf llen hnlich schlecht wie gegen ber Effect Mutationen schneidet die Transitionspaar berdeckung bez glich Guard Mutationen ab Die zur Transitionspaar berdeckung generierten Testf
262. u entwickelten oder vorgefertigten Komponenten die miteinander interagieren F r die Qualit t eines solchen Systems ist zun chst wichtig dass die einzelnen Komponen ten fehlerfrei funktionieren Dies kann durch einen Komponententest berpr ft werden Die Zu sammenstellung mehrerer Komponenten die einzeln st rungsfrei funktionieren garantiert aller dings nicht dass das daraus resultierende Gesamtsystem auch korrekt funktionieren wird Eine sehr ernstzunehmende aber meistens untersch tzte Fehlerquelle ist die Komponenteninterakti on SJO4 Zum Zweck der Entdeckung fehlerhafter Komponenteninteraktionen eignet sich der Integrationstest Eine systematische Herangehensweise an die Qualit tssicherung ist folglich be sonders auf Komponenten und Integrationsebene von sehr hoher Bedeutung Um die Wahr scheinlichkeit der Entdeckung von Komponenten und Interaktionsfehlern zu erh hen m ssen die im Rahmen dieser zwei Testphasen generierten Testfallmengen den Quelltext der Software m glichst vollst ndig abdecken Damit solche Fehler bei der Implementierung gar nicht erst entstehen sind vorbeugende Ma nahmen zu treffen Dazu z hlt die systematische berpr fung aller Artefakte die im Laufe des Softwarelebenszyklus vor der Implementierungsphase entstehen z B Anforderungsspezifikati on oder Entwurfs Modelle Somit k nnen Fehler fr hzeitig entdeckt und behoben werden was f r den Projekterfolg von entscheidender Bedeutung ist da
263. uch andere Diagrammarten die aber f r die Integrationstestgenerierung nicht von Bedeutung sind So z B betrachtet auch Klassendiagramme um die statische Struktur der Modelle zu berpr fen Diese Diagrammarten werden in der Tabelle nicht ber ck sichtigt RKSO gt OK SS Sg Sg Lo E ba EI ei m E gl oo a assests 5 S DEE N a S e S AFGC O O B E wow Sg x ABuR 06 S Sequenzdiagramm K Kommunikationsdiagramm Z Zustandsautomat Tabelle 3 2 Zusammenfassung existierender Ans tze die modellbasierte berdeckungskriteri en f r den Integrationstest beschreiben Um sowohl die Zust nde der aufgerufenen als auch der aufrufenden Komponente zu beachten 58 3 3 Modellbasierte berdeckungskriterien f r den Integrationstest wurden in SOP07 neuartige zustandsbasierte berdeckungskriterien definiert welche in Ab schnitt beschrieben werden Das Verfahren zur automatischen Generierung von Testf llen die diese Kriterien erf llen wird in Kapitel 4 vorgestellt 3 3 1 Mapping Bevor im n chsten Abschnitt die zustandsbasierten berdeckungskriterien vorgestellt werden beschreibt dieser Abschnitt ein zentrales Konzept dieser Arbeit und zwar das Mapping Dieses Konzept wurde in SOP07 eingef hrt und ist wie folgt definiert Definition 3 1 Mapping Ein Mapping ist ein Paar t t von Transitionen unterschiedlicher Zustandsautomaten mit folgender Eigenschaft e t tr t Ein Ma
264. uenz nicht hinzugef gt Dies ist dadurch bedingt dass diese Transition als Folge interner Komponentenaufrufe durchlaufen wird und nicht durch den Testfall aufgeru fen werden kann Als Beispiel f r eine Folge von Transitionen die aus dem Zustandsautomaten der Komponente B aus Abbildung 3 2 generiert wurde sei BI tB2 tB3 tB7 Der dadurch generierte Testfall ist opB1 69171531 opB4 Die generierten Testf lle aus A und B rufen also nur jeweils eine Komponente auf Um daraus einen Integrationstestfall zu generieren werden diese zwei Testf lle zu einem einzigen Testfall zusammengefasst indem nacheinander Aufrufe aus dem ersten und aus dem zweiten Testfall dem neu erzeugten Integrationstestfall hinzugef gt werden Ein Beispiel f r einen Integrationstestfall ist 0pA1 1230053765 opB1 69171531 opA4 false opB4 opA5 Durch die statische Vorgehensweise bei der Generierung der Anfangspopulation werden auch Testf lle generiert die nicht komplett abgearbeitet werden k nnen D h dass manche Aufrufe des Testfalls bei der Ausf hrung auf dem entsprechenden Zustandsautomaten verfallen da keine passende Transition aus dem aktuellen Zustand ausgeht Der gerade beschriebene Testfall ist IT Der Trigger opB2 von Transition tB3 wurde nicht hinzugef gt da dieser als Effect der Transition 146 aufgerufen wird 77 4 Automatische modellbasierte Testfallgenerierung mittels genetischer Algorithmen ein Beispiel daf r
265. ugef gt werden d rfen sonst w re der Aufruf unvollst ndig geht der Operator wie folgt vor zun chst wird zuf llig ein Aufruf ausgew hlt der einen Parameter enth lt Abh ngig von dem Typ des Parameters wird dann eine entsprechende Mutation umgesetzt So z B wird falls es sich um einen nummerischen Wert handelt dieser Wert um einen zuf llig bestimmten Wert erh ht oder verkleinert 4 3 5 Abbruchbedingungen Der genetische Algorithmus generiert durch Anwendung der oben beschriebenen Operatoren immer neue Populationen bis eine vor dem Start der Generierung einzustellende Abbruch bedingung erf llt ist Die im Folgenden beschriebenen Abbruchbedingungen geben an wann die 7Dieser Wert h ngt auch von der Mutationsvarianz ab 87 4 Automatische modellbasierte Testfallgenerierung mittels genetischer Algorithmen globale Optimierung angehalten wird e keine Abbruchbedingung in diesem Fall generiert der Algorithmus so lange Testf lle bis der Generierungsprozess manuell durch den Benutzer angehalten wird e maximale Anzahl an Generationen falls diese Abbruchbedingung eingestellt ist wird der Generierungsprozess beendet nachdem eine bestimmte Anzahl an Generationen erzeugt wurde e gew nschte berdeckung erreicht f r den Fall dass diese Abbruchbedingung eingestellt ist beendet der Algorithmus die Generierung falls ein generiertes Individuum die ge w nschte berdeckung erreicht hat 8
266. um Sprachen handelt die nur in einer bestimmten Dom ne einsetzbar sind also so genannte Domain Specific Languages Kurz DSL oder um Sprachen die zur Beschreibung allgemeiner Problemstellungen geeignet sind General Purpose Languages Kurz GPL 2 2 Unified Modeling Language Die Unified Modeling Language Kurz UML ist eine Sprache die sich besonders gut f r die Modellierung objektorientierter Softwaresysteme eignet Diese Sprache erfreut sich in letzter Zeit immer gr erer Akzeptanz was mehrere Gr nde hat Zum einen ist sie als General Purpose Language nicht auf eine bestimmte Softwaredom ne eingeschr nkt und zum anderen kann sie durch so genannte Profile auf bestimmte Anwendungsgebiete zugeschnitten werden Ein Beispiel f r so ein Profil ist das UML 2 0 Testing Profile Kurz U2TP BDG 04 Dieses Profil erlaubt die Spezifikation von Artefakten die f r die Testphase relevant sind so z B die Modellierung des System Under Test Kurz SUT Die UML unterst tzt die modellbasierte Softwareentwicklung indem sie es erm glicht so wohl die statische Struktur als auch das dynamische Verhalten der Software zu modellieren Weiterhin kann diese Sprache als semi formale Sprache eingestuft werden da sie zum einen Sprachkonstrukte mit eindeutiger Semantik zur Verf gung stellt wie z B Aktivit tsdiagramme welche auf der Semantik der Petri Netze aufbauen Auf der anderen Seite erlaubt sie auch die Benutzung nat rlicher Sprache Die
267. ung der Testziele und der durch die Testplanung vorgegebenen Randbedingungen sollen im Rahmen dieses Schrittes ausf hrbare Testf lle erstellt werden 3 Testdurchf hrung die im Rahmen der Testfallgenerierung erstellten Testf lle m ssen in diesem Schritt manuell oder automatisch ausgef hrt werden Die Testdurchf hrung ist b licherweise mit der Testauswertung stark verzahnt 4 Testauswertung Dieser Schritt vergleicht die bei der Ausf hrung der Testf lle geliefer ten Ergebnisse mit den erwarteten Ergebnissen diese werden anhand der Spezifikation bestimmt Danach wird der durchgef hrte Test im Hinblick auf die in der Testplanung vorgegebenen Ziele bewertet speziell um festzustellen ob das Testendekriterium erf llt wurde Darauf aufbauend wird ein Testbericht erstellt Die zeitaufw ndigsten und damit auch kostspieligsten Schritte sind die Testfallgenerierung und die Testdurchf hrung Deshalb gibt es viele Forschungsans tze und Werkzeuge die diese Schritte unterst tzen Ans tze zur Automatisierung der Testdurchf hrung sind in der Industrie etabliert KTS10 wobei einer der bekanntesten Vertreter solcher Ans tze das xUnit Framework ist Zu diesem Framework geh ren unter anderem das JUnit Testing Framework f r Java Programme und das NUnit Framework f r NET Programme Diese Frameworks erlauben es eine Menge von 5http www junit org http www nunit org 23 2 Grundlagen Testskripten ma
268. ung entlang des Kontrollflussgraphen im All gemeinen mehrere definitionsfreie Pfade existieren gen gt es im Falle der meisten unten be schriebenen Kriterien mit Ausnahme von All DU paths wenn mindestens einer dieser Pfade berdeckt wird Das All defs Kriterium verlangt dass jede Kombination einer Variablendefinition mit mindes tens einer dazugeh rigen Verwendung getestet wird Falls keine Verwendung der entsprechenden Variable gefunden werden kann ist die Variable und die entsprechende Zuweisung im Quelltext sinnlos Als schw chstes Kriterium dieser Klasse subsumiert es weder das Kriterium Anwei sungs berdeckung noch das Kriterium Zweig berdeckung Ein Kriterium das diese zwei Kriterien subsumiert ist das All p uses Kriterium Dieses Krite rium gilt dann als erf llt wenn jede Variablendefinition in Kombination mit jeder dazugeh rigen pr dikativen Verwendung getestet wird F r den Fall dass solche Paare nicht existieren wurde das All p uses some c uses Kriterium definiert Dieses fordert zun chst hnlich wie das All p uses Kriterium die berdeckung aller 36 2 5 Testen Paare von Definitionen und entsprechenden pr dikativen Verwendungen f r den Fall dass f r bestimmte Variablen keine pr dikativen Verwendungen existieren soll zumindest eine berech nende Verwendung dieser Variablen berdeckt werden Somit subsumiert dieses Kriterium das All p uses Kriterium Das All c uses Kriterium fordert dass al
269. ur des zu testenden Programms Bei der Testfallgenerierung wer den Testf lle so erstellt dass sie eine m glichst hohe berdeckung des Quelltextes erreichen ohne dabei die Spezifikation bei der Generierung in Betracht zu ziehen Die Spezifikation ist allerdings auch in diesem Fall von entscheidender Bedeutung und zwar bei der Bewertung der Ergebnisse der Testdurchf hrung Vorteil dieser Verfahren ist dass der erstellte Quelltext viel gr ndlicher getestet wird als bei einer rein funktionalen Herangehensweise Problematisch ist allerdings dass nicht abgesch tzt werden kann ob das implementierte Verhalten das in der Spezifikation beschriebene Verhalten vollst ndig abdeckt Beispiele f r Fehlerarten die mit solchen Verfahren nicht entdeckt werden k nnen sind so ge nannte Omission Faults gt Andererseits k nnen White Box Verfahren unspezifiziertes Verhalten aufdecken White Box Testverfahren lassen sich in kontrollflussorientierte und datenflussorien tierte Verfahren aufteilen 35Fehler die daraus resultieren dass in der Spezifikation beschriebene Funktionalit t nicht vollst ndig oder gar nicht durch das implementierte Werkzeug umgesetzt wurde 32 2 5 Testen Kontrollflussorientierter Test Solche Testverfahren gehen von der Repr sentation des Quelltextes der Software als Kontroll flussgraph aus In Bal97 wird dieser Graph wie folgt definiert Definition 2 5 Kontrollflussgraph Ein Kontrollflu graph ist e
270. usgerichtet ist ist das so genannte statistische Testen Hier geht es dar um durch Ausf hrung einer bestimmten Anzahl an korrekt ausgef hrten Testf llen quantitative Aussagen ber die Zuverl ssigkeit des Systems zu treffen Mit der quantitativen Bewertung der Softwarezuverl ssigkeit komponentenbasierter Systeme mittels statistischer Testverfahren be sch ftigt sich die Arbeit S6h10 In der vorliegenden Arbeit wird unter Testen das Verfahren gemeint das auf die Aufdeckung von Fehlern in reaktiven Softwaresystemen ausgerichtet ist Dies sind Systeme die st ndig auf die Aufrufe aus ihrer Umgebung reagieren indem sie Ausgaben produzieren Sch05 Um sol che Systeme zu testen werden als Eingaben Testf lle ben tigt Ein Testfall ist eine Folge von 21 2 Grundlagen Aufrufen im Verlauf der Arbeit auch Teststeps genannt wobei jeder Aufruf aus einer Nachricht und falls ben tigt aus Parameterwerten besteht Test fall Aufrufi Aufrufn wobei Vi 1 n Aufruf Nachricht Parameterwerte Ein Testfall kann auch als Testsequenz mit dazugeh rigen Testdaten beschrieben werden Die Testsequenz ist die Folge der im Testfall enthaltenen Nachrichten Da einzelne Nachrichten auch Parameter enthalten k nnen m ssen f r diese Parameter Werte festgelegt werden Deshalb ent halten die Testdaten zu jeder Nachricht Werte f r die Parameter Um nach der Ausf hrung der Testf lle zu bewerten ob das dabei beobachtete
271. ustands A2 Sz ist Eka tA3 tA6 Aks t Tc pre t S Menge der aus Zustand S ausgehenden Transitionen Beispiel Die Menge aller ausgehenden Transitionen des Zustands A2 Sy ist Ak tA5 tA7 e TPo t t2 Tc x Tc 3S Sc t Eks to Aks die Menge aller Transitions paare von C Beispiel TP4 tAl tA2 tAl tA3 tA1 tA4 tA3 tA5 Zur beispielhaften Beschreibung dieser Konzepte wird die Komponente A aus Abbildung B 1 benutzt 49 3 Modellbasierte berdeckungskriterien 50 tA3 tAT tA4 tA8 tA5 tA6 tA6 tA5 tA6 tA7 DAT tA8 e Anfangszustandc S Sc Eks 0 der Anfangszustand von C Beispiel Anfangszustand4 A0 e Endzust ndec S Sc Aks 0 die Menge der Endzust nde von C Beispiel Endzustdnde A5 e Trc tr t t Tc die Menge aller Trigger von C Beispiel Tra opAl i int opA2 opA3 opA4 j boolean opA5 e Gc g t t Tc g t Z die Menge aller nicht trivialen Guards von C Beispiel G4 i gt 0 i lt 0 x lt 5 j true e Ec e t t Tc e t EAc V e t EVAc die Menge aller Effects von C die Aufrufe enthalten Beispiel E4 b opB2 e T E c t Tcle t Ec die Menge aller Transitionen die im Effect einen Aufruf enthalten die so genannten Invoking Transitions aufrufende Transitionen Beispiel T E 4 1
272. utomaten aktiv wird 3 1 2 Transition Die durchgezogenen und gerichteten Pfeile zwischen Zust nden jeglicher Art stellen Transitio nen dar und beschreiben berg nge zwischen den Zust nden Nachdem eine aus dem aktiven Zustand ausgehende Transition durchlaufen wurde wird dieser Zustand inaktiv und der Ziel zustand der Transition aktiv Die berg nge zwischen Zust nden erfolgen ohne zeitliche Verz Engl Initial Pseudo State wird dargestellt als schwarzer gef llter Kreis 45 3 Modellbasierte Uberdeckungskriterien gerung Mittels Beschriftungen werden die Bedingungen erfasst die gelten m ssen damit eine Transition durchlaufen wird Eine solche Beschriftung hat die Form RHQ 07 Trigger Guard E f fect wobei alle Elemente optional sind Aufgrund dieser Beschriftung und der Tatsache dass eine Transition einen Quell Engl Pre state und einen Zielzustand Engl Post state hat kann eine Transition als 5 Tupel folgenderma en dargestellt werden SOPO7 t pre t tr t g t e t post t Im Folgenden werden die Elemente des Tupels in Anlehnung an und erkl rt wobei zur Veranschaulichung auf die in Abbildung B I dargestellte Komponente A hin gewiesen wird Hier ist an jeder Transition tiber der Beschriftung auch der Name der Transition angebracht tA bis tA6 Abbildung 3 1 Zustandsautomat der das Verhalten einer Komponente A beschreibt aus PSOO08 pre t Pre state der Transit
273. utzt Dabei wurden die 16 Testf lle bernommen und im Verlauf des weiteren Generierungsprozesses nicht weiter ver ndert Am Ende konnte durch Erweiterung der alten Testsuite um einen zus tzlichen Testfall Abbildung 5 13 Testfall TestCa se 17 ist neu dazugekommen und wird mit N markiert eine 100 ige Transitions berdeckung auf dem ge nderten Modell erreicht werden HO 6Ha X TestSuites TestCases Testsuite TestContext_A Data TestSy TE TestCase 3 Steps 8 ID 3 Ti TestCase 4 Steps 9 ID 4 Ti TestCase 5 Steps 7 ID 5 Tx TestCase 6 Steps 5 ID 6 Ti TestCase 7 Steps 9 ID 7 Ti TestCase 8 Steps 9 ID 8 Ti TestCase 9 Steps 9 ID 9 Ti TestCase 10 Steps 5 ID 10 Ti TestCase 11 Steps 9 ID 11 Ti TestCase 12 Steps 9 ID 12 Ti TestCase 13 Steps 9 ID 13 Ti TestCase 14 Steps 9 ID 14 Ti TestCase 15 Steps 9 ID 15 Ti TestCase 16 Steps 7 ID 16 Th TestCase 17 Steps 4 ID 1 4 m D TestContext TestContext_A SUT ui UserControl Behavior of SUT UserControl Coverage criterion Edge Coverage Reached coverage 100 0 Abbildung 5 13 Ergebnisse Regressionstestgenerierung Die Vorgehensweise bei der Regressionstestgenerierung l sst sich dadurch verbessern dass f r die Uberdeckung neuer Entit ten nicht komplett neue Testf lle generiert werden sondern die im neuen Modell nicht mehr lauff higen Testf lle bei der Generierung mit ber cksichtigt werden Durch Anpassung dieser Testf lle K n
274. viationConfirmDone false DevistionNumberExists false myPar Stan MS Abbildung A 1 Modell Liegenpr fplatz Komponente Achstest Teil 1 von 2 174 ChangeStep AutoForward HilfsGuard 9 E actualMSi 5 ChangeStep HillsGuerd 9 n d ie ele ExecutionReturnsOK MS5 Selection all true olvistionki I actusims lt s lise ClicNo TestResult TestResultEnum OK HasCor tinue IMSContsinsDevishionCtri false myPar ExecuteOK ele I Devistiont ise FS ClidNo M HasinpptCtris Pe NeaveStep false bechte actualMtS 3 flemveStep ler angeStep KE Repest repeatNotEnabled false nexiMS HasStalt etre HilfsGuard gt 5 amp amp actuaIMS 3 amp amp mi adualMS adualMS rer gg a enbens actual MS myPar Statt Kemer eS s0 ExecutionRetumsNotPerformed i ifsGuard t IMS5_Selection_sl UP ees eee a le imyPar NoSelect ep en s dodi A Ek DevisfionAllk false MSHakCortinue true Re becht HillsGuard e amp amp D sauelust 58 Selecion site I Ask User Cancel current execution Sg Aus Wien rn ChangeStep TestResultEnum NOK HillsGuard 9 ExecutionReturmsDeviation DeviationAllowed true 88 MS5_Selection_sll tue actusIMS lt 5 JTestResult estResultEnum DevistionDetected ChangeStep Daiana tse HilfsGuard 3 expDeviationOcoured true ExternalSt Ask Can
275. von und die Generierung zus tzlich erforderlicher Testf lle indem sie mittels statischer Analyse neue Pfade durch den Graphen er mitteln und somit neue Testsequenzen ableiten Aufgrund der statischen Vorgehensweise sto en diese Ans tze auch auf die in Abschnitt 4 1 schon angesprochenen Grenzen die sich auf die Generierung von Pfaden beziehen die eventuell gar nicht ausf hrbar sind Der hier beschriebene Ansatz wurde erstmalig in PBSO08 vorgestellt zur Generierung zu s tzlich erforderlicher Testf lle berwindet diese Grenzen durch die Benutzung heuristischer Verfahren und erlaubt dar ber hinaus neben der Generierung passender Testdaten auch die Mi nimierung der Anzahl neu erforderlicher Testf lle 102 5 3 Unterst tzung des Regressionstests nderungen an Zustandsautomaten lassen sich wie folgt klassifizieren PBSO08 e Erweiterung des Modells um zus tzliche graphische Elemente Knoten oder Kanten e Entfernen graphischer Elemente e Umbenennung graphischer Elemente ohne nderung ihrer Semantik z B nderung des Namens einer Transition Dies ist keine nderung der Semantik da die Semantik einer Transition nur ber die Elemente des 5 Tupels definiert ist e Semantische nderung graphischer Elemente z B nderung des Namens eines Zu stands Im Gegensatz zur nderung des Namens einer Transition ist die nderung des Namens eines Zustands eine semantische nderung e Verfeinerung von Modellteilen
276. weisung Fehler fehlende Zuweisungen zus tzliche Zuweisungen x inkorrekte arithmetische Operatoren z B statt x Bezug auf inkorrekte Variablen Aufruf Fehler fehlende Aufrufe zus tzliche Aufrufe inkorrekte Aufrufe Generische Effect Fehler fehlende generische Effects zus tzliche generische Effects e Pre state Fehler inkorrekter Pre state einer Transition e Post state Fehler inkorrekter Post state einer Transition 129 7 Evaluierung des Fehlererkennungspotentials modellbasierter Testf lle e Transition Fehler fehlende Transitionen zus tzliche Transitionen e Zustand Fehler fehlende Zust nde zus tzliche Zust nde Bei Betrachtung der Auswirkungen der oben beschriebenen Fehler wird klar dass manche Fehler schon w hrend der Komponententestphase aufgedeckt werden k nnten Im Gegensatz da zu k nnen sich andere Fehler nur beim Zusammenspiel mehrerer Komponenten manifestieren Dementsprechend k nnen die gerade beschriebenen Fehler auch folgenden Kategorien zugeord net werden e intramodulare Fehler Fehler die beim Test einzelner Komponenten aufgedeckt werden k nnen e intermodulare Fehler Fehler die sich nur u ern wenn die fehlerhafte Komponente mit anderen Komponenten interagiert Beispiele f r solche Fehler sind Aufruf Fehler die nur durch einen Integrationstest entdeckt werden k nnen 7 1 2 2 Modell Mutationsoperatoren Zur automatischen Gen
277. wie sich der im Rahmen dieser Arbeit beschriebene mo dellbasierte Testfallgenerierungsansatz in diese Taxonomie einordnen l sst Bei der Dimension Test Generation Technology wurde ein neuer Begriff eingef gt da in dieser Taxonomie die im Rahmen dieser Arbeit beschriebene Methode zur Testfallgenerierung nicht erw hnt wird und zwar genetische Algorithmen die zur Klasse der heuristischen Verfahren Engl Heuristic Methods z hlen Im Folgenden werden die einzelnen Dimensionen der Taxonomie dargestellt und speziell die Konzepte erkl rt die f r die Einordnung der vorliegenden Arbeit relevant sind F r eine detaillierte Beschreibung der Taxonomie wird auf UPL06 oder ULO7 verwiesen 1 Die Dimension Subject gibt an ob das Modell das Softwaresystem an sich SUT System Under Test oder die Au enwelt Environment beschreibt die mit dem System interagiert Die als Basis f r die Testfallgenerierung in dieser Arbeit benutzten Modelle sind Model le die reaktive Softwaresysteme beschreiben Somit beschreiben sie das SUT welches auf Eingaben der Umwelt reagiert was dazu f hrt dass auch ein Teil des Au enwelt verhaltens in diesen Modellen enthalten ist Dies wird durch Umrandung beider Begriffe gekennzeichnet Die Dimension Redundancy gibt an ob ein Entwicklermodell Shared test amp dev model oder ein separates Testmodell Separate test model der Testfallerstellung zugrunde liegt Bei den Entwicklermodellen handelt
278. wirkten entwickelt Bei der Durchf hrung des Projekts Konnte auf die am Lehrstuhl bereits vorhandene Erfahrung mit dem praktischen Einsatz genetischer Algorithmen zur ckgegriffen werden Einen wichtigen Beitrag zu diesem Projekt leisteten zwei Abschlussarbeiten in wurde ein Modellsimulator f r Zustandsautomaten entwickelt im Rahmen der Arbeit von wurde das Verfahren zur Visualisierung der Modell berdeckung konzipiert und das ben tigte Plugin f r MagicDraw um gesetzt Das implementierte Software Werkzeug erlaubt Komponenten und Integrationstestf lle auto matisch zu generieren und hinsichtlich zweier Ziele zu optimieren einerseits hinsichtlich einer hohen berdeckung des Modells und anderseits hinsichtlich einer geringen Anzahl an Testf llen Praktisch wurde das Verfahren anhand mehrerer Modelle evaluiert die angestrebte berdeckung konnte bis auf eine Ausnahme in allen F llen erreicht werden Des Weiteren wurde im Rahmen dieser Arbeit der Frage nach dem Fehlererkennungspotenti al von Testfallmengen nachgegangen die modellbasierte berdeckungskriterien f r den Kom ponententest oder Integrationstest erf llen Um zu untersuchen ob mit Hilfe modellbasierter Testf lle Modellierungsfehler entdeckt werden k nnen wurde ein modellbasiertes Mutations testverfahren von Grund auf neu entwickelt F r diesen Zweck mussten zun chst Fehlerarten bei der Modellierung von Zustandsautomaten identifiziert und kategorisiert werden Darauf
279. zur Modellierung des Verhaltens einzelner Komponenten wurden Zustandsautoma ten ausgew hlt Sie geh ren zu den Verhaltensdiagrammen der UML und sind eine der meist benutzten Diagrammarten Da Zustandsautomaten sehr m chtig sind und sehr viele Sprachkon strukte zur Verf gung stellen w rde eine detaillierte Beschreibung all dieser Konstrukte den Rahmen der Arbeit sprengen Deshalb werden nur die Modellierungskonstrukte beschrieben die im Rahmen dieser Arbeit eingesetzt wurden Die UML Spezifikation beschreibt zwei Arten von Zustandsautomaten und zwar Verhaltens zustandsautomaten Engl Behavioral State Machine und Protokollzustandsautomaten Engl Protocol State Machine Diese unterscheiden sich unter anderem in der Semantik von Transitio nen so kann z B f r eine Transition in einem Protokollzustandsautomaten kein Verhalten ange geben werden w hrend dies f r Verhaltensautomaten m glich ist das Verhalten kann in Effects von Transitionen beschrieben werden Da sie geeignete Sprachkonstrukte zur Modellierung des Verhaltens an Transitionen zur Verf gung stellen werden im Folgenden nur Verhaltenszustands Wie das genau passiert wird in Unterabschnitt beschrieben 44 3 1 Verhaltensbeschreibung von Komponenten mittels UML Zustandsautomaten automaten betrachtet Wenn im Rahmen dieser Arbeit also Zustandsautomaten erw hnt werden sind immer Verhaltenszustandsautomaten gemeint 3 1 1 Zustand Ein f r Zustandsautoma

Dokument_45.

Contents

Download Pdf Manuals

Related Search

Related Contents