Reusable Components and Subsystems

1
Reusable Componentsand Subsystems

• Ahmed Lamkanfi
• Bart Meyers
• Karen Segers

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)?
• Voorbeeldengeneric classes, abstract classes,
  frameworks

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
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
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
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
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
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
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
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
Strategie(3)?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Strategy Test Model (1)?

• Multiple Test Sets
• Multiplicity parameters specifieren de grenzen
  voor een aanvaardbare mapping tussen twee
  objecten.
• Voorbeeld 2..14 ? An(B) 2 en An(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
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
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
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
Consequences

• N associaties max 8n basic multiplicity test
  cases
• 2 minimum en maximum AB
• 2 minimum en maximum BA
• 4 Zero-intervals zoals 1..1
• Teveel test cases

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
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
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
• transformeer diagramma in een flow graaf
• zoek paden in de graaf om te testen
• zoek paden in graaf met exceptions en
  polymorfisme
• kies inputs voor elk pad

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
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
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 servers
  verantwoordelijkheden

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
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
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
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 servers source code om de gewenste
  exception te triggeren

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
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
Strategy Automation

• Stubs worden vaak gebruikt om applicatie-specifiek
  e exceptions te simuleren.
• Om anomalous conditions waardoor dan exceptions
  gegooid worden, te genereren, kunnen command-line
  scripts gebruikt worden.

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
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
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
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
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
Identificeer het Dominant Control Object

• Via statechart of collaboration diagram van het
  subsystem
• Control responsibilities
• stimulus-response cycles
• errors exceptions
• startup shut down

54
State model voor Controller
55
Modelleer externe eventsen -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
System events
57
Mode Machine

• Figure 12.22 p. 613

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
Conformance tests transition tree
60
Conformance tests
61
Guarded transition expansion

• COIN DROP guarded transition met twee condities
• dfDepository.depAmt() lt price
• dfDepository.depAmt() gt price
• COIN DROP kan na twee states voorkomen
• IDLE (test run 2 en 8)?
• ACCEPTING COINS (test run 3 en 6)?

62
Iteration expansion
63
Implicit transition expansion

• POWEROFF event kan altijd gebeuren

64
Sneak paths

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

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