Reusable Components and Subsystems Ahmed Lamkanfi Bart Meyers Karen Segers.

Presentatie over: "Reusable Components and Subsystems Ahmed Lamkanfi Bart Meyers Karen Segers."— Transcript van de presentatie:

1 Reusable Components and Subsystems Ahmed Lamkanfi Bart Meyers Karen Segers

2 2 Reusable Components Components kunnen hergebruikt worden door -source code augmentation -Tranlation-time binding -Link-time interfaces Hergebruiken van code verlaagt de development effort (schrijven van code en debug time) ‏ Voorbeelden:generic classes, abstract classes, frameworks

3 3 Inhoud Reusable Components -Abstract Class Test -Generic Class Test -New Framework Test -Popular Framework Test Subsystems -Class Association Test -Round-trip Scenario Test -Controlled Exception Test -Mode Machine Test

4 4 Context, Fault Model, Entry & exit criteria Abstracte klasse testen -probleem: kan niet geïnstantieerd worden -testinstantie gebruiken Fault Model -design errors over de responsibilities -problemen met reusability Entry Criteria -geen (code moet compileren) ‏ Exit Criteria -minimum: method scope branch coverage

5 5 Strategy Maak een subklasse met een implementatie voor elke abstracte methode (subclass driver) ‏ Specification-based test suite voor methodes Test cases -elke overridden method -elke niet-overridden geïmplementeerde methode van de abstracte klasse Integration testing voor elke subklasse

6 6 Inhoud Reusable Components -Abstract Class Test -Generic Class Test -New Framework Test -Popular Framework Test Subsystems -Class Association Test -Round-trip Scenario Test -Controlled Exception Test -Mode Machine Test

7 7 Doel en Context Doel: -implementatie van test en test suite maken voor een generische klasse Context: -probleem: gedrag afhankelijk van zowel implementatie als type-parameter -aan de hand van testinstanties Vragen bij testen generische klassen: -welke type parameters uittesten? -hoeveel verschillende type parameters testen? -wanneer is een generische klasse betrouwbaar?

8 8 Fault Model Type-dependent faults -return van een message naar geaccepteerde klasse bepaald door intramethod of intraclass control/data flow -precisie van types, initializatie, static variabelen,.. Type-specific faults -generische klasse enkel geschikt voor subset van geaccepteerde klassen -methoden generische klasse werken enkel bij specifieke geaccepteerde klassen Multiple type interaction faults -combinatie van type parameters

9 9 Strategie(1) ‏ Enkele Type Parameter -kies type-parameter die zoveel mogelijk responsabilities uitvoert -kies gepaste methode en klasse test patterns -voer test suite uit op geinstantieerde generische klasse -design en maak type-dependent test instanties boundary tests, polymorphic classes test -design en maak type-specific test instanties -test overloaded operaties voor elk combinatie van type-parameters

10 10 Strategie(2) ‏ Type-specific test: -schrijf test voor alle instanties met verschillende contract -schrijf test voor elke type-specifieke feature -test robuustness door niet toegelaten type parameters te gebruiken

11 11 Strategie(3) ‏

12 12 Strategie(4) ‏ Twee of meerdere type parameters -kies meest gebruikte types -maak test suite met gepaste coverage -test alle combinaties van deze types uit

13 13 Entry/Exit Criteria Entry Criteria -parameter types moeten aan eigen testen voldoen -alle entry criteria voldoen van elke toegepaste test pattern Exit Criteria -100 % branch coverage -alle exit criteria voldoen van elke toegepaste test pattern

14 14 Inhoud Reusable Components -Abstract Class Test -Generic Class Test -New Framework Test -Popular Framework Test Subsystems -Class Association Test -Round-trip Scenario Test -Controlled Exception Test -Mode Machine Test

15 15 Doel en context Framework = Implementatie van een herbruikbaar, domein-specifiek design Doel = test implementatie en een test suite voor framework dat enkele instantiaties heeft Frameworks kunnen op 2 manieren ontwikkeld worden: -Model-based framework: ontwikkeld om een familie van applicatiesystemen die eenzelfde verzameling van klassen delen, te ondersteunen -Generalized framework: ontwikkeld door een bestaand applicatiesysteem te veralgemenen

16 16 Fault model Frameworks moeten in het algemeen aan volgende voorwaarden voldoen: -Complete en consistente voorstelling van de belangrijkste aspecten van het probleemdomein (bvb. Klassen en associaties) ‏ -Basisoperaties voorzien (creëren, verwijderen, lezen, updaten van objecten van deze klassen en de associaties ertussen) ‏ -Sequential control wordt geforceerd (voor vereist gedrag) ‏

17 17 Fault model (2) ‏ Soorten bugs (voor elke component in het framework): -Design omissions: essentieel gedrag of voorstelling is niet compleet of is er niet -Representational integrity bugs: association constraints tussen objecten behouden Order geassocieerd met 1 Customer, Customer moet geen Order hebben -Control bugs -Infrastructure bugs

18 18 Strategy Test Model -Test suite ontwikkeld van de analyse en design models -“Demo app” is de testbare instantie -Extended Use Case Test voor elke use case -Class Association Test voor elke association Automation -Capture / playback script -Test harness

19 19 Entry Criteria Frameworks worden in increments ontwikkeld. Een testbaar system scope model moet beschikbaar zijn Alle componentklassen en subsystemen moeten een individuele test suite gepasseerd zijn Een system scope test harness en de test environment moeten geïnstalleerd, getest en stabiel zijn.

20 20 Exit Criteria Minstens 1 test moet de Extended Use Case Test exit criteria halen Minstens 1 minimale test voor elke associatie in het klassemodel moet Class Association Test exit criteria gehaald hebben CRUD coverage Control model coverage

21 21 Inhoud Reusable Components -Abstract Class Test -Generic Class Test -New Framework Test -Popular Framework Test Subsystems -Class Association Test -Round-trip Scenario Test -Controlled Exception Test -Mode Machine Test

22 22 Context en Fault Model Popular framework -er bestaan al veel instanties van het framework -nieuwe features moeten toegevoegd worden Fault Model -feature interaction twee features interageren -compatibility bug oude feature werkt niet meer door nieuwe feature -latent bug fout die nog niet gevonden of behandeld was -Fault Model van New Framework Test pattern

23 23 Strategy Feature interaction testing -toevoegen van feature test cases -zoek feature interactions die anti-requirements kunnen waarmaken -automatisch genereren van feature combinaties Compatibility testing -Regression testing met bestaande instanties Nieuwe instanties toevoegen aan suite om latent bugs te vinden Test nieuwe features apart

24 24 Entry en exit criteria Entry criteria -er is een system scope model -componenten en subsystemen zijn getest -er zijn system scope test drivers (i.e. een instantie van het framework) ‏ -er is een test environment -maak een instantie van de nieuwe release gemaakt (optioneel) ‏ -analyseer de nieuwe en veranderde features Exit Criteria -zelfde als New Framework Test

25 25 Consequences Door gebruik van instanties worden veel compatibility bugs gevonden Stabiliseren van framework -rate of test decay zal verminderen minder werk: kost vermindert -pesticide paradox “gemuteerde bugs” die niet ontdekt werden door de gelijkaardigheid van de instanties bugs worden ontdekt bij een atypische instantie -vanaf het begin zoveel mogelijk verschillende instanties!

26 26 Subsystems Subsysteem is een verzameling van -Klassen -Objecten -Componenten -Modules Eigenschappen: -Uitvoerbaar en testbaar -Delen moeten afzonderlijk getest kunnen worden Voorbeelden: small/large cluster, build group, task group, …

27 27 Inhoud Reusable Components -Abstract Class Test -Generic Class Test -New Framework Test -Popular Framework Test Subsystems -Class Association Test -Round-trip Scenario Test -Controlled Exception Test -Mode Machine Test

28 28 Doel en context Doel: Een test suite maken om de implementatie van vereiste associaties tussen klassen te controleren De klassen zijn verantwoordelijk voor associaties met andere klassen. Class diagram

29 29 Fault Model Incorrect multiplicity: afwijzen / accepteren van juiste / onjuiste combinaties (bvb. personen zonder hond toestaan in Kaynine) ‏ Update anomaly: verkeerde of geen update (bvb. Persoon heeft 5 honden, verandert van adres. Adressen van alle honden aanpassen.) ‏ Delete anomaly: object wordt verwijderd (bvb. Persoon wordt verwijderd, honden moeten ook verwijderd worden.) ‏ Missing link (bvb. Pointer van verzameling honden naar persoon is er wel, maar die van de persoon naar de honden niet) ‏ Wrong link: alle links zijn er, maar ze zijn incorrect of inconsistent (bvb. Pointer van verzamelingen honden naar Piet ipv naar Jos) ‏

30 30 Strategy Test Model (1) ‏ Multiple Test Sets -Multiplicity parameters specifieren de grenzen voor een aanvaardbare mapping tussen twee objecten. -Voorbeeld: 2..14  A:n(B) ≥ 2 en A:n(B)  14 -Associaties = 2 richtingen  test ook in 2 richtingen Testen van Update / Delete bugs -Slechts 1 instantie aangepast ipv alle instanties -Hoe testen? -Voorbeeld: Ms Marge Pack Adres: 123 Oak Street Ze heeft 5 honden

31 31 Strategy Test Model (2) ‏ -Update bug: adres veranderen -Is het adres van de honden veranderd? -Delete bug: verwijder Ms. Pack -Zijn de honden verwijderd? -Delete side-effect bug: verwijder honden -Ms. Pack moet nog bestaan -Ms. Pack verwijderen  geen info meer over Ms. Pack op te vragen

32 32 Strategy Test Model (3) ‏ Wrong and missing links -Door multiplicity tests worden er al veel gevonden -Keyed collections om associaties te implementeren -ID van object vergelijken

33 33 Entry and Exit Criteria Entry -Elke klasse is de alpha-omega cycle gepasseerd -Keyed collections moeten individueel getest zijn met het Quasi-modal Class Test Exit -Elke multipliciteit on point test is geslaagd -Elke multipliciteit off point test is geslaagd -Een deletion anomaly test is geslaagd -Een update anomaly test is geslaagd -All tests for mutual exclusion zijn geslaagd

34 34 Consequences N associaties = max 8n basic multiplicity test cases -2 minimum en maximum A:B -2 minimum en maximum B:A -4 Zero-intervals zoals 1..1 Teveel test cases

35 35 Inhoud Reusable Components -Abstract Class Test -Generic Class Test -New Framework Test -Popular Framework Test Subsystems -Class Association Test -Round-trip Scenario Test -Controlled Exception Test -Mode Machine Test

36 36 Doel en Context Doel -extraheren van control flow model uit een UML Sequence diagram -paden testen die minimale branch en lus coverage bieden Context -verschillende scenarios mogelijk in diagram -round-trip scenario -verzekeren dat alle scenarios getest worden

37 37 Fault Model en Strategie(1) ‏ Fault Model -fout in een subsysteem is altijd binnen 1 pad te vinden in de diagram Strategie – Test Model -Sequence diagram als een graaf voorstellen Strategie – Test Procedure 1.transformeer diagramma in een flow graaf 2.zoek paden in de graaf om te testen 3.zoek paden in graaf met exceptions en polymorfisme 4.kies inputs voor elk pad

38 38 Entry, Exit criteria en gevolgen Entry Criteria -Alle objecten, componenten of subsystemen moeten aan hun test suite voldoen Exit Criteria -coverage van alle branches -elke loop is minimaal aantal keer doorgelopen -elke loop is 1 keer doorgelopen -elke loop is maximaal keer doorgelopen Gevolgen -Gedetailleerde sequence diagramma nodig

39 39 Inhoud Reusable Components -Abstract Class Test -Generic Class Test -New Framework Test -Popular Framework Test Subsystems -Class Association Test -Round-trip Scenario Test -Controlled Exception Test -Mode Machine Test

40 40 Doel en context (1) ‏ Doel: Een test suite maken die gebruik maakt van exception handlers en een systematisch middel voorziet om alle excepties te genereren. Context -Exception-handling code maakt meestal deel uit van de client, maar wordt gecontroleerd door de server -Wordt vooral getest als een deel van de server’s verantwoordelijkheden

41 41 Intent en context (2) ‏ Exceptions -Computational Exceptions arithmetic exceptions, underflow / overflow -I/O errors device not ready, parity check -File errors empty, overflow, missing -Main storage management allocate, dealloceate, garbage collection -Task Management process start, suspend, resume, terminate, interprocess communication Target environment exceptions ontstaan meestal door incorrect gebruik van VM

42 42 Fault Model Verschillende fouten: -Een exception is onjuist van de server naar client gestuurd -Een exception propageert out of scope -Een applicatie-specifieke exception handler is missing of incorrect -Een exception werd genegeerd (resultaat is een mysterieuze failure) ‏ -… Een fout kan enkel bereikt worden door de code te activeren die de exception behandelt.

43 43 Strategy Test Model (1) ‏ Veel exceptions genereren een errorboodschap en stoppen de uitvoering. Application-specific exceptions: complex -Deze hebben een gepast test model nodig: bvb. een state machine Irregular behavior: Category-Partition (gebaseerd op input/output analyse) ‏

44 44 Strategy Test Model (2) ‏ Exception testing op 3 manieren: Exception activation: exceptions worden geactiveerd door de input en state value van test cases -Analyse van server’s source code om de gewenste exception te triggeren

45 45 Strategy Test Model (3) ‏ Exception inducement: exceptions worden bereikt door manipulatie van de implementatie van test of doelomgeving -Doelomgeving exceptions: 4 ways Mistune: bvb. Beschikbare storage verlagen  resource allocatie / deallocatie exceptions Cripple: verwijderen, hernoemen, … van nodige resources Pollute: selectief met input data, files, … knoeien Mutate, zap: wijzig object code of data om een error na te bootsen

46 46 Strategy Test Model (4) ‏ Exception simulation: exceptions worden gesimuleerd door gebruik te maken van controllable wrappers -API van VM of systeem vervangen door API met zelfde interface maar controleerbare implementatie -Test wrapper voorziet o.a. volgende checks: Check de call order Check parameters Oproep van de originele functie Set de returnwaarde Throw an exception Verander output parameters …

47 47 Strategy Automation Stubs worden vaak gebruikt om applicatie- specifieke exceptions te simuleren. Om anomalous conditions waardoor dan exceptions gegooid worden, te genereren, kunnen command-line scripts gebruikt worden.

48 48 Entry and Exit Criteria Entry -Alle responsibilities van de server en client moeten getest zijn Exit -Elke server exception moet minstens 1x bereikt zijn

49 49 Consequences Technisch begrip nodig ivm welke exceptions ontstaan door de target environment en welke applicatie-specifieke exception strategie nodig is. In sommige situaties is het testen van exceptions moeilijk en gevaarlijk.

50 50 Inhoud Reusable Components -Abstract Class Test -Generic Class Test -New Framework Test -Popular Framework Test Subsystems -Class Association Test -Round-trip Scenario Test -Controlled Exception Test -Mode Machine Test

51 51 Context en Fault Model Geschikt voor (sub)systemen waarbij dezelfde externe events niet altijd dezelfde responses geven -“mode” machine: state-based Elk systeem heeft een Dominant Control Object Mogelijke control faults: missing transition, incorrect action, invalid state, sneak path,... Voorbeeld: vending machine

52 52 Strategy Maak een state-based model -identificeer het Dominant Control Object -modelleer externe events en –acties Genereer een N+ test suite -conformance tests -guarded transition expansion -iterator expansions -implicit transition expansion -sneak paths...

53 53 Identificeer het Dominant Control Object Via statechart of collaboration diagram van het subsystem Control responsibilities: -stimulus-response cycles -errors & exceptions -startup & shut down

54 54 State model voor Controller

55 55 Modelleer externe events en -acties Want we willen niet alleen de Controller testen, maar het hele subsysteem Externe events: door OS of ander systeem Externe events moeten afgehandeld kunnen worden door Controller -zo niet: er zijn design omissions Elk extern event wordt gemapt op de Controller -negeer externally invisible transitions bijvoorbeeld: wait loop

56 56 System events

57 57 Mode Machine Figure 12.22 p. 613

58 58 Strategy Maak een state-based model -identificeer het Dominant Control Object -modelleer externe events en –acties Genereer een N+ test suite -conformance tests -guarded transition expansion -iterator expansions -implicit transition expansion -sneak paths...

59 59 Conformance tests: transition tree

60 60 Conformance tests

61 61 Guarded transition expansion COIN DROP: guarded transition met twee condities: -dfDepository.depAmt() < price -dfDepository.depAmt() >= price COIN DROP kan na twee states voorkomen -IDLE (test run 2 en 8) ‏ -ACCEPTING COINS (test run 3 en 6) ‏

62 62 Iteration expansion

63 63 Implicit transition expansion POWEROFF event kan altijd gebeuren

64 64 Sneak paths Test elk mogelijk illegaal event Sneak paths: tables 12.12-16 blz 618-622

65 65 Entry & exit criteria Entry criteria: operability threshold voor elke cluster -elke component of cluster kan succesvol hun test pattern toepassen -elke cluster voldoet aan minimal operability requirements Exit criteria: N+ coverage -de test voor elk pad in de transition tree en elk sneak path is succesvol