Distributed Tes,ng R. M. Hierons Brunel University, UK - - PowerPoint PPT Presentation

Distributed ¡Tes,ng ¡

• R. ¡M. ¡Hierons ¡

Brunel ¡University, ¡UK ¡ rob.hierons@brunel.ac.uk ¡ h@p://people.brunel.ac.uk/~csstrmh ¡

TAROT 2010

Work ¡With ¡

• Mercedes ¡Merayo ¡
• Manuel ¡Nunez ¡
• Jessica ¡Chen ¡
• Hasan ¡Ural ¡

TAROT 2010

Mul,-­‑port ¡systems ¡

• Physically ¡distributed ¡interfaces/ports. ¡
• A ¡tester ¡at ¡each ¡port. ¡

TAROT 2010

SUT tester tester tester

Distributed ¡tes,ng ¡

• Mainly ¡focus ¡on ¡the ¡simplest ¡approach: ¡
• The ¡testers ¡cannot ¡communicate ¡with ¡one ¡another ¡
• There ¡is ¡no ¡global ¡clock ¡
• Observa,ons ¡are ¡‘local’ ¡

TAROT 2010

Mo,va,on ¡

 Ini,ally ¡just ¡tes,ng/test ¡genera,on. ¡  The ¡discussion ¡will ¡be ¡around ¡both ¡

• tes%ng ¡and ¡
• implementa%on/conformance ¡rela%ons. ¡

 Tes,ng ¡from: ¡

• input ¡output ¡transi,on ¡systems ¡and ¡
• a ¡few ¡notes ¡on ¡finite ¡state ¡machines ¡

TAROT 2010

Tes,ng ¡and ¡Observa,ons ¡

TAROT 2010

Global ¡Traces ¡

• A ¡global ¡trace ¡is ¡a ¡sequence ¡of ¡inputs ¡and ¡
• utputs. ¡
• We ¡assume ¡there ¡are ¡m ¡ports ¡and: ¡

– xp ¡will ¡denote ¡an ¡input ¡at ¡port ¡p ¡(from ¡Xp) ¡ – (y1,...,ym) ¡∈Y, ¡Y=(Y1∪{-­‑})×…×(Ym∪{-­‑}), ¡will ¡be ¡an ¡

• utput ¡
• A ¡global ¡trace ¡is ¡an ¡element ¡of ¡(X ¡× ¡Y)* ¡ ¡

TAROT 2010

Consequences ¡

• Each ¡tester ¡observes ¡only ¡the ¡interac,ons ¡(local ¡

trace) ¡at ¡its ¡port ¡

• The ¡tester ¡at ¡port ¡1 ¡observes ¡x1y1x1y1 ¡and ¡the ¡tester ¡

at ¡2 ¡observes ¡y2 ¡only. ¡

TAROT 2010

Tester 1 SUT Tester 2 x1 x1 y1 y2 y1

What ¡the ¡testers ¡observe ¡

• Given ¡global ¡trace ¡z, ¡the ¡tester ¡at ¡p ¡observes ¡a ¡

local ¡trace ¡πp(z) ¡. ¡

TAROT 2010

Tester 1 Tester 2 x1 x1 y1 y2 y1

Controllability ¡problems ¡

• The ¡following ¡test ¡has ¡a ¡controllability ¡

problem: ¡introduces ¡nondeterminism ¡into ¡ tes,ng. ¡

TAROT 2010

tester SUT tester

Observability ¡problems ¡

• The ¡following ¡look ¡the ¡same ¡
• Testers/users ¡cannot ¡‘map’ ¡output ¡to ¡input ¡

TAROT 2010

tester Spec tester tester SUT tester x1 x1 x1 x1 y1 y1 y1 y1 y2 y2

Equivalent ¡global ¡traces ¡

• Since ¡we ¡only ¡observe ¡local ¡traces: ¡

– Global ¡traces ¡z ¡and ¡z’ ¡are ¡indis,nguishable ¡if ¡their ¡ projec,ons ¡are ¡iden,cal: ¡the ¡local ¡traces ¡are ¡the ¡

• same. ¡

– We ¡denote ¡this: ¡z∼z’ ¡

• The ¡following ¡are ¡equivalent ¡under ¡∼ ¡

– x1/(y1,y2)x1/(y1,-­‑) ¡ – x1/(y1,-­‑)x1/(y1, ¡y2) ¡

• Both ¡have ¡x1y1x1y1 ¡at ¡port ¡1 ¡and ¡y2 ¡at ¡2. ¡

TAROT 2010

Problem: ¡Test ¡effec,veness ¡is ¡not ¡ monotonic ¡

• Example: ¡x1 ¡detects ¡a ¡fault ¡but ¡x1x1 ¡does ¡not. ¡ ¡

TAROT 2010

tester SUT tester tester Spec tester x1 x1 x1 x1 y1 y1 y1 y1 y2 y2

Two ¡approaches ¡to ¡defining ¡ implementa,on ¡rela,ons ¡

• We ¡might ¡have: ¡

– Agents ¡at ¡ports ¡are ¡en,rely ¡‘independent’: ¡

• No ¡external ¡agent ¡can ¡receive ¡informa,on ¡regarding ¡
• bserva,ons ¡at ¡more ¡than ¡one ¡port ¡

– Or ¡the ¡local ¡traces ¡observed ¡at ¡the ¡ports ¡can ¡be ¡ ‘brought ¡together’ ¡later. ¡

TAROT 2010

Differences ¡

• Specifica,on ¡
• SUT ¡

TAROT 2010

Tester 1 Tester 2 x y z Tester 1 Tester 2 x y' z' Tester 1 SUT Tester 2 x y' z

Using ¡an ¡external ¡network ¡

• If ¡we ¡connect ¡the ¡testers ¡using ¡an ¡external ¡

network, ¡some%mes ¡we ¡can ¡overcome ¡ controllability ¡and ¡observability ¡problems. ¡

TAROT 2010

tester SUT tester tester SUT tester

But ¡

• If ¡a ¡system ¡has ¡physically ¡distributed ¡interfaces ¡

then ¡the ¡implementa,on ¡rela,on ¡should ¡ reflect ¡this: ¡

 Even ¡if ¡we ¡can ¡connect ¡the ¡testers, ¡we ¡should ¡be ¡ careful ¡that ¡we ¡do ¡not ¡give ¡the ¡verdict ¡fail ¡when ¡ the ¡behaviour ¡is ¡acceptable ¡in ¡use. ¡  The ¡users ¡will ¡only ¡observe ¡local ¡traces. ¡

TAROT 2010

Past ¡research ¡

• Mainly ¡on ¡tes,ng ¡from ¡a ¡determinis,c ¡finite ¡

state ¡machine ¡(DFSM): ¡

– Genera,ng ¡test ¡sequences ¡that ¡do ¡not ¡suffer ¡from ¡ controllability ¡and/or ¡observability ¡problems ¡ – Adding ¡coordina,on ¡messages ¡(possibly ¡adding ¡a ¡ minimum ¡number). ¡

TAROT 2010

Problems/issues ¡

• A ¡DFSM ¡can ¡have ¡transi,ons ¡that ¡can’t ¡be ¡

executed ¡without ¡controllability ¡problems. ¡

• Test ¡genera,on ¡algorithms ¡place ¡condi,ons ¡on ¡

the ¡DFSM ¡– ¡they ¡are ¡not ¡general. ¡

• The ¡methods ¡test ¡against ¡the ¡‘tradi,onal’ ¡

implementa,on ¡rela,on ¡– ¡aiming ¡to ¡do ¡too ¡ much? ¡

• Using ¡DFSMs ¡is ¡restric,ve. ¡

TAROT 2010

The ¡solu,on ¡

• We ¡need ¡a ¡good ¡understanding ¡of ¡what ¡it ¡

means ¡to ¡dis,nguish ¡two ¡models ¡with ¡ distributed ¡ports. ¡

• This ¡gives ¡us ¡new ¡implementa,on ¡rela,ons. ¡
• We ¡want ¡to ¡test ¡against ¡these. ¡

TAROT 2010

Input ¡Output ¡Transi,on ¡Systems ¡ (IOTSs) ¡

TAROT 2010

The ¡models ¡

• These ¡are ¡labelled ¡transi,on ¡systems ¡in ¡which ¡

we ¡dis,nguish ¡between ¡input ¡and ¡output. ¡

• We ¡have ¡states ¡and ¡transi,ons ¡between ¡the ¡
• states. ¡
• Nota,on: ¡

– Normally ¡we ¡precede ¡the ¡name ¡of ¡an ¡input ¡by ¡? ¡ and ¡the ¡name ¡of ¡an ¡output ¡by ¡!. ¡

TAROT 2010

Internal ¡events ¡and ¡quiescence ¡

• We ¡have ¡two ¡special ¡types ¡of ¡events: ¡

– Internal ¡events ¡(τ) ¡are ¡state ¡transi,ons ¡that ¡do ¡not ¡ require ¡input ¡and ¡do ¡not ¡produce ¡output. ¡ – A ¡state ¡s ¡is ¡quiescent ¡if ¡from ¡s ¡output ¡cannot ¡be ¡ produced ¡without ¡first ¡providing ¡input. ¡ – If ¡s ¡is ¡quiescent ¡then ¡we ¡add ¡a ¡self-­‑loop ¡transi,on ¡ from ¡s ¡with ¡label ¡δ. ¡

TAROT 2010

A ¡simple ¡example ¡

• A ¡(very) ¡simple ¡coffee ¡machine ¡
• We ¡have ¡not ¡shown ¡the ¡self-­‑loops ¡for ¡
• quiescence. ¡

TAROT 2010

?1 !tea ?2 !coffee

IOTS ¡models ¡

• IOTS ¡models ¡are ¡more ¡general ¡than ¡FSMs: ¡

 They ¡can ¡be ¡infinite ¡state ¡models ¡  Input ¡and ¡output ¡need ¡not ¡alternate ¡  There ¡can ¡be ¡internal ¡(unobservable) ¡ac,ons. ¡

• We ¡assume: ¡

 IOTSs ¡are ¡input ¡enabled ¡  We ¡can ¡observe ¡quiescence ¡

TAROT 2010

Implementa,on ¡rela,ons ¡

• There ¡is ¡a ¡standard ¡implementa,on ¡rela,on ¡

(for ¡tes,ng) ¡called ¡ioco ¡

• It ¡requires: ¡
• If ¡σ ¡is ¡a ¡(suspension) ¡trace ¡of ¡the ¡specifica,on ¡s ¡

and ¡the ¡implementa,on ¡can ¡produce ¡output ¡!o ¡ aoer ¡σ ¡then ¡s ¡must ¡be ¡able ¡to ¡produce ¡output ¡!o ¡ aoer ¡σ ¡

TAROT 2010

Two ¡equivalent ¡processes ¡

• We ¡cannot ¡dis,nguish ¡the ¡following: ¡
• Note: ¡assume ¡processes ¡completed ¡to ¡make ¡

them ¡input-­‑enabled. ¡

TAROT 2010

?i1 !o1 !o2 ?i1 !o2 !o1

Issue ¡

• When ¡can ¡we ¡‘bring ¡together’ ¡local ¡
• bserva,ons’? ¡
• In ¡this ¡example ¡not ¡aoer ¡?i1!o1 ¡or ¡?i1!o2 ¡

TAROT 2010

?i1 !o1 !o2 ?i1 !o2 !o1

When ¡do ¡we ¡make ¡observa,ons? ¡

• For ¡an ¡FSM ¡we ¡observe ¡the ¡projec,ons ¡of ¡

input/output ¡sequences ¡-­‑ ¡we ¡can ¡‘stop’ ¡aoer ¡ an ¡input/output ¡sequence. ¡

• When ¡can ¡we ¡‘stop’ ¡when ¡considering ¡IOTSs? ¡

Possibly: ¡

– Whenever ¡we ¡have ¡quiescence. ¡

• We ¡can ¡then ¡‘bring ¡together ¡local ¡traces’ ¡

TAROT 2010

An ¡implementa,on ¡rela,on ¡dioco ¡

• We ¡say ¡that ¡i ¡dioco ¡s ¡if: ¡

– For ¡every ¡trace ¡z ¡of ¡i ¡that ¡can ¡take ¡i ¡to ¡a ¡quiescent ¡ state, ¡there ¡is ¡some ¡trace ¡z’ ¡of ¡s ¡such ¡that ¡z’ ¡∼ ¡z. ¡

• This ¡means: ¡

– If ¡i ¡has ¡a ¡‘run’ ¡z ¡that ¡ends ¡in ¡quiescence ¡then ¡s ¡has ¡ a ¡specified ¡behaviour ¡that ¡is ¡‘equivalent’ ¡to ¡z. ¡

TAROT 2010

dioco ¡does ¡not ¡imply ¡ioco ¡ ¡

• Example: ¡

TAROT 2010

?i1 !o1 !o2 ?i1 !o2 !o1

Result ¡

• If ¡s ¡and ¡i ¡are ¡input ¡enabled ¡then: ¡

 i ¡ioco ¡s ¡implies ¡that ¡i ¡dioco ¡s ¡

• Normally ¡IOTS ¡implementa,ons ¡are ¡required ¡

to ¡be ¡input ¡enabled. ¡

• So: ¡

 For ¡input ¡enabled ¡specifica,ons ¡we ¡have ¡that ¡ dioco ¡is ¡weaker ¡than ¡ioco. ¡

TAROT 2010

Test ¡cases ¡

• These ¡can ¡be ¡defined ¡as ¡processes ¡that ¡can ¡

interact ¡with ¡the ¡SUT. ¡

• We ¡can ¡have: ¡

– A ¡global ¡tester ¡that ¡interacts ¡with ¡every ¡port ¡ – One ¡local ¡tester ¡for ¡each ¡port. ¡

• In ¡our ¡context, ¡we ¡cannot ¡implement ¡a ¡global ¡

tester ¡(but ¡we ¡can ¡map ¡it ¡to ¡a ¡set ¡of ¡local ¡ testers). ¡

TAROT 2010

Controllability ¡

• A ¡local ¡tester ¡observes ¡only ¡the ¡events ¡at ¡its ¡
• port. ¡
• As ¡a ¡result, ¡if ¡it ¡has ¡to ¡supply ¡an ¡input ¡then ¡it ¡

can ¡only ¡know ¡when ¡to ¡do ¡this ¡on ¡the ¡basis ¡of ¡ its ¡observa,ons. ¡

TAROT 2010

A ¡controllability ¡problem ¡

• The ¡tester ¡at ¡port ¡2 ¡does ¡not ¡know ¡when ¡to ¡send ¡its ¡
• input. ¡

TAROT 2010

tester SUT tester

The ¡effect ¡of ¡nondeterminism ¡

• We ¡might ¡have ¡pairs ¡of ¡allowed ¡traces ¡with ¡

prefixes ¡like ¡the ¡following: ¡

TAROT 2010

tester Spec tester tester Spec tester x1 x1 x1 x1 y1 y1 y1 y2 y2 y2 x2 x2

Choice ¡

• A ¡tester ¡makes ¡a ¡choice ¡based ¡on ¡its ¡
• bserva,ons. ¡
• This ¡is ¡the ¡no,on ¡of ¡‘local ¡choice’. ¡
• Also ¡studied ¡in ¡the ¡context ¡of ¡Message ¡

Sequence ¡Charts ¡(e.g. ¡non-­‑local ¡choice ¡ pathologies). ¡

• Difference ¡in ¡problems ¡considered ¡and ¡our ¡

problem ¡has ¡addi,onal ¡‘structure’ ¡

TAROT 2010

Defining ¡controllability ¡

• A ¡test ¡case ¡t ¡is ¡controllable ¡if ¡each ¡tester ¡can ¡

make ¡‘local ¡choices’ ¡

• there ¡should ¡not ¡be ¡two ¡prefixes ¡z ¡and ¡z’ ¡of ¡traces ¡that ¡

can ¡be ¡produced ¡using ¡t ¡that ¡look ¡the ¡same ¡to ¡a ¡tester ¡ at ¡port ¡p ¡and ¡yet ¡this ¡tester ¡should ¡behave ¡differently ¡ aoer ¡these. ¡

• Result: ¡

– We ¡can ¡decide ¡in ¡polynomial ¡,me ¡whether ¡a ¡test ¡ case ¡is ¡controllable. ¡

TAROT 2010

Addi,onal ¡implementa,on ¡rela,ons? ¡

• In ¡dioco ¡we ¡assume ¡traces ¡can ¡be ¡brought ¡

together ¡at ¡the ¡end ¡of ¡tes,ng. ¡

• We ¡have ¡allowed ¡the ¡use ¡of ¡test ¡case ¡with ¡

controllability ¡problems. ¡

• So, ¡there ¡are ¡alterna,ve ¡implementa,on ¡

rela,ons. ¡

TAROT 2010

An ¡example ¡

• We ¡can ¡require ¡that ¡local ¡traces ¡are ¡not ¡

brought ¡together. ¡

• Makes ¡sense ¡if ¡this ¡corresponds ¡to ¡expected ¡
• usage. ¡
• We ¡require: ¡

– For ¡every ¡trace ¡z ¡of ¡the ¡implementa,on ¡and ¡port ¡p ¡ there ¡is ¡a ¡trace ¡z’ ¡of ¡the ¡specifica,on ¡such ¡that ¡πp (z)=πp(z’) ¡

TAROT 2010

Can ¡be ¡weaker ¡

• Specifica,on ¡and ¡implementa,on ¡
• Looks ¡ok ¡if ¡we ¡cannot ¡bring ¡together ¡local ¡traces. ¡

TAROT 2010

?i1 !o2 !o1 ?i1 !o2 !o’1 ?i1 !o’2 !o’1

Can ¡be ¡stronger ¡

• No ¡quiescence: ¡
• Suggests: ¡only ¡allowing ¡traces ¡ending ¡in ¡

quiescence ¡is ¡problema,c. ¡

TAROT 2010

!o2 !o1

Addi,onal ¡alterna,ves ¡

• Instead ¡of ¡only ¡considering ¡quiescent ¡traces ¡

we ¡could: ¡

 Combine ¡(conjoin) ¡the ¡previous ¡two ¡ implementa,on ¡rela,ons. ¡  Consider ¡infinite ¡traces. ¡

TAROT 2010

Using ¡infinite ¡traces ¡

• We ¡can ¡compare ¡the ¡infinite ¡traces ¡of ¡the ¡

implementa,on ¡with ¡those ¡of ¡the ¡ specifica,on. ¡

• This ¡is ¡an ¡answer ¡to ¡‘when ¡do ¡we ¡bring ¡

together ¡local ¡traces’. ¡

• In ¡prac,ce ¡we ¡will ¡have ¡to ¡define ¡conserva,ve ¡

decision ¡procedures ¡for ¡oracles. ¡

TAROT 2010

Other ¡Types ¡of ¡Models ¡

TAROT 2010

The ¡following ¡are ¡equivalent ¡

• !o1!o2, ¡!o2!o1 ¡
• !o1!o1!o2, ¡!o2!o1!o2 ¡
• …. ¡
• (!o1)1000!o2, ¡!o2(!o1)1000 ¡
• …. ¡
• When ¡does ¡this ¡stop ¡being ¡reasonable? ¡

TAROT 2010

One ¡possible ¡approach ¡

• We ¡could ¡include ¡,me ¡in ¡our ¡model. ¡
• Problem: ¡

– Local ¡clocks ¡need ¡not ¡synchronise. ¡

• We ¡might ¡have ¡e.g.: ¡

– bounds ¡in ¡drio, ¡ – informa,on ¡about ¡,me ¡taken ¡by ¡messages, ¡ – messages ¡between ¡testers ¡

• This ¡is ¡future ¡work. ¡

TAROT 2010

Using ¡scenarios ¡

• An ¡alterna,ve: ¡

– Allow ¡the ¡users ¡and ¡testers ¡to ¡effec,vely ¡ synchronise ¡at ¡certain ¡points. ¡

• We ¡can ¡

– consider ¡scenarios ¡and; ¡ – add ¡explicit ¡synchronisa,on ¡points ¡in ¡a ¡ specifica,on. ¡

• These ¡should ¡reflect ¡expected ¡usage. ¡

TAROT 2010

Adding ¡probabili,es ¡

• Some ¡systems ¡have ¡probabilis,c ¡
• requirements. ¡
• We ¡can ¡add ¡probabili,es ¡to ¡transi,ons. ¡
• It ¡is ¡straighsorward ¡to ¡extend ¡IOTSs ¡to ¡

probabilis,c ¡IOTSs. ¡

TAROT 2010

A ¡Genera,ve ¡Approach ¡

• In ¡a ¡state ¡s ¡the ¡sum ¡of ¡probabili,es ¡of ¡transi,ons ¡

leaving ¡s ¡add ¡up ¡to ¡1. ¡

• The ¡implementa,on ¡rela,ons ¡are ¡similar ¡to ¡dioco ¡– ¡

we ¡just ¡add ¡requirements ¡regarding ¡probabili,es. ¡

• However, ¡if ¡we ¡have ¡inputs ¡and ¡outputs ¡this ¡

approach ¡requires ¡us ¡to ¡have ¡probabilis,c ¡ informa,on ¡regarding ¡the ¡environment. ¡

TAROT 2010

A ¡reac,ve/genera,ve ¡approach ¡

• Instead ¡we ¡can ¡assume ¡that: ¡

– There ¡is ¡no ¡probabilis,c ¡informa,on ¡regarding ¡ inputs ¡from ¡the ¡environment ¡(a ¡reac,ve ¡ approach). ¡ – In ¡state ¡s, ¡the ¡sum ¡of ¡the ¡probabili,es ¡of ¡outputs ¡ from ¡the ¡SUT ¡(including ¡δ) ¡is ¡1: ¡outputs ¡are ¡ genera,ve. ¡

TAROT 2010

Probabili,es ¡of ¡observa,ons ¡

• Consider ¡the ¡following ¡
• What ¡is ¡the ¡probability ¡of ¡observing ¡!coffee ¡

aoer ¡?i1?i2 ¡

TAROT 2010

?i1 !tea ?i2 !coffee ?i1 ?i2

The ¡problem ¡

• We ¡can ¡have ¡races ¡between ¡events ¡at ¡

different ¡ports. ¡

• We ¡have ¡no ¡probabilis,c ¡informa,on ¡

regarding ¡the ¡outcome ¡of ¡these ¡races. ¡

TAROT 2010

Possible ¡solu,ons ¡

• Two ¡alterna,ves: ¡

– Outlaw ¡such ¡situa,ons ¡(effec,vely ¡say ¡that ¡we ¡ know ¡nothing ¡about ¡the ¡probabili,es). ¡ – Assume ¡that ¡the ¡(unknown) ¡environment ¡has ¡such ¡ probabili,es ¡and ¡define ¡corresponding ¡ implementa,on ¡rela,ons: ¡

• quan,fy ¡over ¡environments. ¡

TAROT 2010

Finite ¡State ¡Machines ¡

TAROT 2010

Key ¡components ¡of ¡tes,ng ¡

• When ¡tes,ng ¡from ¡an ¡FSM ¡we ¡want ¡to ¡be ¡able ¡

to: ¡

 Reach ¡states ¡  Dis,nguish ¡states ¡(and ¡machines) ¡  Check ¡output ¡against ¡the ¡specifica,on ¡(oracle ¡ problem). ¡

TAROT 2010

The ¡Oracle ¡Problem ¡

• For ¡DFSMs ¡this: ¡

 Can ¡be ¡solved ¡in ¡polynomial ¡,me ¡for ¡controllable ¡ test ¡sequences ¡  Otherwise ¡is ¡NP-­‑hard ¡

• For ¡NFSMs: ¡

 NP-­‑hard ¡even ¡for ¡controllable ¡tes,ng ¡  Polynomial ¡if ¡we ¡restrict ¡further ¡

TAROT 2010

Reaching ¡and ¡dis,nguishing ¡states ¡

• Problem ¡

 Is ¡there ¡a ¡strategy ¡for ¡each ¡tester ¡that ¡leads ¡to ¡ tes,ng ¡taking ¡the ¡FSM ¡to ¡a ¡par,cular ¡state ¡(or ¡ dis,nguishes ¡two ¡states)? ¡

• This ¡problem ¡is ¡undecidable. ¡
• Decidable ¡for ¡controllable ¡tes,ng ¡from ¡a ¡DFSM ¡

(result ¡does ¡not ¡hold ¡for ¡NFSMs). ¡

TAROT 2010

Future ¡work ¡

– Genera,ng ¡test ¡cases ¡to ¡sa,sfy ¡a ¡test ¡criterion. ¡ – Condi,ons ¡under ¡which ¡problems ¡can ¡be ¡solved ¡ (efficiently). ¡ – Genera,ng ¡complete ¡test ¡suites. ¡ ¡ – Tes,ng ¡using ¡coordina,on ¡messages ¡but ¡the ¡‘new’ ¡ implementa,on ¡rela,ons. ¡ – Timed ¡automata. ¡ – Enriching ¡models ¡with ¡data, ¡stochas,c ¡,me, ¡... ¡ – Minimising ¡an ¡FSM. ¡

TAROT 2010

Papers ¡(FSMs) ¡

– B. ¡Sarikara ¡and ¡G. ¡Von ¡Bochmann, ¡Synthesis ¡and ¡Specifica,on ¡Issues ¡in ¡ Protocol ¡Tes,ng, ¡IEEE ¡Transac%ons ¡on ¡Communica%ons, ¡32 ¡4, ¡pp. ¡389-­‑395: ¡

• 1984. ¡

– R. ¡Dssouli ¡and ¡G. ¡von ¡Bochmann. ¡Error ¡detec,on ¡with ¡mul,ple ¡observers, ¡ Protocol ¡Specifica%on, ¡Tes%ng ¡and ¡Verifica%on ¡V, ¡pp. ¡483-­‑494: ¡1985. ¡ – R. ¡Dssouli ¡and ¡G. ¡von ¡Bochmann,. ¡Conformance ¡tes,ng ¡with ¡mul,ple ¡

• bservers, ¡Protocol ¡Specifica%on, ¡Tes%ng ¡and ¡Verifica%on ¡VI, ¡pp. ¡217-­‑229: ¡
• 1986. ¡

– J. ¡Chen, ¡R. ¡M. ¡Hierons, ¡and ¡H. ¡Ural. ¡Overcoming ¡observability ¡problems ¡in ¡ distributed ¡test ¡architectures, ¡Informa%on ¡Processing ¡LeCers, ¡98, ¡pp. ¡177-­‑182: ¡

• 2006. ¡ ¡

– R. ¡M. ¡Hierons ¡and ¡H. ¡Ural. ¡The ¡effect ¡of ¡the ¡distributed ¡test ¡architecture ¡on ¡the ¡ power ¡of ¡tes,ng, ¡The ¡Computer ¡Journal, ¡51 ¡4, ¡pp. ¡497-­‑510: ¡2008. ¡ ¡ – R. ¡M. ¡Hierons: ¡Canonical ¡Finite ¡State ¡Machines ¡for ¡Distributed ¡Systems, ¡ Theore%cal ¡Computer ¡Science, ¡411 ¡2, ¡pp. ¡566-­‑580: ¡2010. ¡ ¡ – R.M. ¡Hierons: ¡Reaching ¡and ¡Dis,nguishing ¡States ¡of ¡Distributed ¡Systems, ¡SIAM ¡ Journal ¡of ¡Compu%ng ¡(to ¡appear) ¡

TAROT 2010

Papers ¡(IOTSs) ¡

– R. ¡M. ¡Hierons, ¡M. ¡G. ¡Merayo, ¡and ¡M. ¡Nunuez. ¡Implementa,on ¡rela,ons ¡for ¡the ¡ distributed ¡test ¡architecture, ¡20th ¡FIP ¡Interna%onal ¡Conference ¡on ¡Tes%ng ¡ Communica%ng ¡Systems ¡(TestCom ¡2008), ¡LNCS ¡5074, ¡pp. ¡200-­‑215: ¡2008. ¡ – R. ¡M. ¡Hierons, ¡M. ¡G. ¡Merayo, ¡and ¡M. ¡Nunez. ¡Controllable ¡test ¡cases ¡for ¡the ¡ distributed ¡test ¡architecture, ¡6th ¡Interna%onal ¡Symposium ¡on ¡Automated ¡ Technology ¡for ¡Verifica%on ¡and ¡Analysis ¡(ATVA ¡2008), ¡LNCS ¡volume ¡5311, ¡pp. ¡ 201-­‑215: ¡2008. ¡ – R. ¡M. ¡Hierons ¡and ¡M. ¡Núñez: ¡Scenarios-­‑based ¡Tes,ng ¡of ¡Systems ¡with ¡ distributed ¡Ports, ¡The ¡10th ¡Interna%onal ¡Conference ¡on ¡Quality ¡SoPware ¡(QSIC ¡ 2010), ¡2010. ¡ – R. ¡M. ¡Hierons ¡and ¡M. ¡Núñez: ¡Tes,ng ¡probabilis,c ¡distributed ¡systems, ¡30th ¡ IFIP ¡Formal ¡Techniques ¡for ¡Networked ¡and ¡Distributed ¡Systems ¡(FORTE ¡2010), ¡ LNCS, ¡2010. ¡

TAROT 2010

Conclusions ¡

• If ¡a ¡system ¡has ¡distributed ¡interfaces/ports ¡

then ¡we ¡have ¡different: ¡

– observa,onal ¡power; ¡ – implementa,on ¡rela,ons. ¡

• This ¡can ¡affect ¡tes,ng ¡but ¡also ¡development. ¡
• We ¡get ¡new ¡no,ons ¡of ¡e.g. ¡a ¡design ¡being ¡
• minimal. ¡
• The ¡effect ¡is ¡even ¡greater ¡for ¡nondeterminis,c ¡

models/systems. ¡

TAROT 2010