Yves Le Traon 2005 1 Plan 1.Problématique du test 2.Rappels test de logiciel 3.Test de composants...

1 Yves Le Traon 2005

Plan

1. Problématique du test

2. Rappels test de logiciel

3. Test de composants unitaires OO

4. Test d'intégration

5. Test système

6. Diagnostic

Test d’intégration pour des systèmes à objets

Yves Le Traon

[email protected]

[email protected]


Plan




4. Test d'intégration1. L’intégration: approches classiques

2. Le test d’intégration de classes par l’exemple

3. L’approche à objets et l’intégration

4. Modélisation et stratégies d’ordonnancement

5. Test système

6. Diagnostic


Plan








5. Test système

6. Diagnostic

4.1. L’intégration: approches classiques


Contexte

• Réalisation d’une « bonne » stratégie :pour planifier l’intégration des systèmes à

objets,le plus tôt possible dans le cycle de vie,en minimisant le coût du test.


Test d’intégration

• ObjectifVérifier l’interaction entre unités (méthode, classe ou

package).

• Difficultés principales de l’intégration Interfaces floues (ex. ordre des paramètres de même

type). Implantation non conforme à la spécification (ex.

dépendances entre unités non spécifiées).Réutilisation d’unités (ex. risque d’utilisation hors

domaine).


Architecture de dépendances

Unité à tester

Dépendance à tester


Intégration – Approches classiques

• On obtient une architecture arborescenteSADT, SART, SAO (Aérospatiale)

• ApprochesBig-Bang : non recommandéDe haut en bas (top-down)De bas en haut (bottom-up)


Approche classique : De haut en bas

Unité à tester


Dépendance sous test

Unité sous test

Bouchon de test (stub)

Dépendance simulée

Unité testée

Dépendance testée


Approche classique : De bas en haut

Unité à tester


Unité sous test

Unité testée

Dépendance sous test

Dépendance testée


Plan








5. Test système

6. Diagnostic

4.2. Le test d’intégration de classes par l’exemple


Intégration

• But : tester les interactions entre classes

• Lien entre test d’intégration et unitaire:il faut ordonner les classes pour le test

• Il faut identifier les dépendances entre classesProblème dans le cas de cycles de dépendances


Cas simple : un graphe acyclique

A B

C

D

E

F

- b

*

- e

1

- d 0..1

- d

0..1

- f

*

- f 0..1

Ordre partiel pour le test: F, (C, D), E, B, A

A

B

E

D C

FGraphe de dépendances

acyclique


Étape 1

A B

C

D

E

F

testF

- b

*

- e

1

- d 0..1

- f

*

- f 0..1

- d

0..1

- f

1


Étape 2

A B

C

D

E

F

testF

testC

testD

- b

*

- e

1

- d 0..1

- f

*

- f 0..1

- d

0..1

- f

1

- c1

- d

1


Étape 3

A B

C

D

E

F

testF

testC

testD

testE - b

*

- e

1

- d 0..1

- f

*

- f 0..1

- d

0..1

- f

1

- c1

- d

1

- e

1


Étape 4

A B

C

D

E

F

testF

testC

testD

testE

testB

- b

*

- e

1

- d 0..1

- f

*

- f 0..1

- d

0..1

- f

1

- c1

- d

1

- e

1

- b1


Étape 5

A B

C

D

E

F

testF

testC

testD

testE

testBtestA

- b

*

- e

1

- d 0..1

- f

*

- f 0..1

- d

0..1

- f

1

- c1

- d

1

- e

1

- b1 - a1


Cas moins simple: présence de cycles

- balance: float

- number: int

- overdraft: float

+ deposit()

+ withdraw()

+ Account()

Account

- accountNumbers: int

+ Bank()

+ addAccount()

+ closeAccount()

+ deposit()

+ getAccount()

+ getClient()

+ withdraw()

+ getAccountsOfClient()

Bank

- amount: float

+ Operation()

+ getOperationType()

Operation+ displayAccountsOfClient()

+ process()

+ readInt()

+ menu()

+ readNumber()

+ closeAccount()

+ withdraw()

+ history()

+ clients()

Display

- name: String

+ Person()

Person + DepositOperation()


DepositOperation

+ WithdrawOperation()


WithdrawOperation

- accounts*

+ owner0..1

- history

*

- accounts

*

- clients

*

- display - bank

1

Display Bank

Person

Account Operation

DOp WOp


Intégration avec cycles

• Il faut casser les cyclesdévelopper des simulateurs de classes («

bouchon de test » ou « stub »)un simulateur a la même interface que la classe

simulée, mais a un comportement contrôlé

• Exemple


Exemples de stub

/** * Creates an account for the person named name * If no client has this name, a new client object is created and is added to the list of clients, then the account is created * If the client exists the account is created, added to the bank's and the client's list of accounts */public int addAccount(String name, float amount, float overdraft) {

this.accountNumbers++;Person p = getClient(name);//if a client named name already exists in the bank's set of clientsif (p!=null){

Account a = new Account(p, amount, overdraft, accountNumbers);p.addAccounts(a);this.addAccounts(a);

}//if the client does not exist, add it tp the bank's list of clients and create accountelse{

Person client = new Person(name);this.addClients(client);Account a = new Account(client, amount, overdraft, accountNumbers);client.addAccounts(a);this.addAccounts(a);

}return accountNumbers;

}


Exemples de stub

Stub 1

/** * Creates an account for the person named name * If no client has this name, a new client object is created and is * added to the list of clients, then the account is created * If the client exists the account is created, added to the bank's and the client's list of accounts */public int addAccount(String name, float amount, float overdraft) {

return 0;}

Stub 2

/** * Creates an account for the person named name * If no client has this name, a new client object is created and is * added to the list of clients, then the account is created * If the client exists the account is created, added to the bank's and the client's list of accounts */public int addAccount(String name, float amount, float overdraft) {

return 1;}


Exemples de stub

/** * Looks for a person named name in the set of clients. * Returns the Person object corresponding to the client if it exists * Returns null if there is no client named name */public Person getClient(String name) {

Iterator it = this.clientsIterator();while (it.hasNext()){

Person p = (Person)it.next();if(p.getName()==name){

return p;}

}return null;

}


Exemples de stub

Stub 1


return null;}

Stub 2


return new Person(“toto”);}


Exemple Banque

• Exemple, pour tester en présence de ce cycle

Person

Account

public class Person { /* * Initializes the name of the person with the param n * Creates a new vector to intialize the acounts set */ public Person(String n){ name = n; accounts = new Vector(); }

public String getName(){return name;}}

Stub de la classe Person

public class Person { /* * Initializes the name of the person with the param n * Creates a new vector to initialize the accounts set */ public Person(String n){ }

public String getName(){return (“toto”);}}

Regarder quelles sont les méthodes de Person utilisées par Account


Exemple Banque

• Etape 1Tester la classe Account avec le stub de Person

• Etape 2Tester la classe Person avec Account

• Etape 3Retester la classe Account avec la vraie classe

Person


Plan








5. Test système

6. Diagnostic

4.3. L’approche à objets et l’intégration


(…) Cycle de vie en « spirale »

Intégration

Réalisation

Conception

Analyse détaillée

Analyse préliminaire « (de risque) »

V1 V2

Validation

Synergie avec approche par objets


Test unitaire et d’intégration

• ClassiquementÉtapes séparées

• Dans un cycle en spiraleUn composant unitaire ne peut pas être testé

hors de son contexte d’exécution> conséquence : test unitaire et test

d’intégration sont des activités inséparables


Efficient Strategies for Integration and Regression Testing of OO Systems

• The problem domain: Use OO modeling for early Test Planning

Integration» deduced from UML models

» to master integration cost and duration

Regression» separation of reusable tests from implementation

the test model must be refinable with design refinement stages.



• A OO test model mustbe as simple as possible

easy to understand limited to its purpose

catch all the information concerning test test dependencies between components from a rough to a precise level of detail

– (class method)

determine design parts due to implementation choices test cases reuse test cases enhancement with system evolution

Integration

Regression



• Integration plan - What we have to deal with...

Where to begin with ?How to organize test ?

problem

interdependencies loops of dependenciesbetween componentsinto an architecture

Re tr. listSummary

StatusMaster/Sl

LSReq list

Neighbor

NME LME GARME

L3_SDU

IADU GADUNMM

Header

Serv type

Dst a ddrSrc addr

Length

.........

L3_Payloa d Pad

L3_D TPDU

DTE

ISSI Link Se t

Link ID

UpMetricsMeth.Updt

Key_Spac e

L_ID

Line

Ca pacity

Relat iveDKey_Range

Key

Current CL

Pre vious CL

Para m. smoothSampleTime

W T M

CME

(durations)

CMPDU

CMP_Heade r

ECN

DeadIntHelloInt

RxmtIntMa xRetrTime

InfTransDelay

MinLSIntLSRefreshTime

Ma xAgeMa xAgeDiff

RME

RMPDU

LState

HeaderLSA

Encapsulate

wit

h

wit

h

com

.

com

.

com

.w

ith

Hello

Cooperate for routing

made of

consult

com

.w

ith

1..*

2*

Ma nagerSystem

Operator

Entity

Clockconsult

withCommunicate

NeighborCongested

PU D count

DP NeighborCL Neighbor

manage

1..*

Cooperate for congestion

Read

Tab

leR

out

ing Path Type

Advertiser

Root

Next Hops

Table

Floading

Prev. H op

has areprese ntation

RM_Data

RMP_Header

Next H

op

Exch. Nb

Subscriber

com

uni

cate

thro

ugh

has

loc

al

c omunicate through communicate with local

GroupGroupID

Made of

Traffic Simula tor

Profile



• A simple solution, with constraints on the design no loops in an architecture often possible

but local optimizations are not always optimal for the architecture

but designing interdependent components may also be relevant

• The solution presented here takes any model optimizes the way to deal with loops of interdependent components

pck1 pck2

pck3pck4

S


Interdépendance

• InterdépendancesCycle de dépendancesComposantes fortement

connexes (CFC)

• IntégrationBig-BangDécomposer des CFCs – Utilisation de

bouchons

State

Handle()

Context

Request()

ConcreteStateA

Handle()

ConcreteStateB

Handle()

state.Handle()


Décomposition des CFCs – Bouchon

• Bouchon : une unité quisimule le comportement d’une unitéévite l’utilisation des services d’autres unités

de la même CFC.

A

B

CC’

Bouchon réaliste

A

B

C

CFC

A

B

C

CA

CB

Bouchon spécifique



Integration Testing

• Based on a TDG, how to order components ?Minimizing the number of stubs

realistic stub => dedicated simulator, « old component »

C’ stub simulates the behavior of Cwhen A and B are tested

A Test depends on C’C stub

B Test depends on



Minimizing the number of stubs specific stub => deterministic component behavior

A Test depends onC

B Test depends on

A Test depends on C’stub

B Test depends on C’’stub

A stub for A and a stub for B


Plan








5. Test système

6. Diagnostic

4.4. Modélisation et stratégies d’ordonnancement


Problème de test d’intégration

• Modéliser la structure de dépendances

• Décomposer des composantes fortement connexes en minimisant le coût de création des bouchons

• Planifier le test.


• Modélisation et algorithmes d’ordonnancement



The Test Dependency Graph

preliminary modeling inheritance

Two basic types of test dependencies

client/provider

Contractual dependencies = specified in the public part of classes included in the body of internal methods

Implementation dependencies = not contractual ones



2 types of nodes class node method node

A A

A

…mA1(…)

...

A

mA1

Class A Class node

Method mA1 in Class A Method node in a class node

The Test Dependency Graphpreliminary modeling



3 types of edgesclass_to_class

method_to_classmethod_to_method

…A B

A is test dependent

from B

Semantic of a directed edgeSemantic of a directed edge

The Test Dependency Graphpreliminary modeling



Method_to_class A

...

+mA1(...v1: B...) …mA2(…v: A…)...

A

mA1

mA2

B

Method_to_method A+mA1(...v: B...){…v.mB1…}+mA2(...v: A...){…v.mA1…}

A

mA1

mA2

B

mB1

an action language (ASL/OCL)code level

refinement

…



Class-to-class

A

B

A

B

association

A

B

composition

A

B

aggregation

A

B

navigability

dependency

A

B

A

C

B

association class

A

B

Interfaces

Interface Name A

B

A

B

inheritance

A BC


Modélisation statique 1/2

B

A

B

AUne classe Un nœud

AA

A

B

A

B

A

B

A

B B

AA

B

A

B B

AA

B

A

B

h


Modélisation statique 2/2

A

B

A

B

B

A

B

A

«bind»

<B>AB

B

AT

A

B

B

A

B

A

B

AA

B


Modélisation dynamique

C

B

A C

B

A C

B

A C

B

A

A«abstract»

BA

B C D

CA

DAE

A F

FEet

hhhh


Éliminer les doublons

B

A

B

A

B

A

B

A

B

A

B

A

B

A

B

A

h h



B

+mB1(v1: C)…-pB1(v: C)-pB2(v: G)….#redefine pA1 {…}

D

- pD1(v1:E, v2 : F)

E

F

C

H

G

+mA1(v1: C) {….}#pA1(…){…}

A

F

E

B

G H

pA1 mB1

pB1

pB2

A

C

D

mA1

pD1

pA1

Implementation dependencyClient contractual dependencyInheritance contractual dependency



Implementation-dependent graph

F

E

B

G H

pA1 mB1

pB1

pB2

A

C

D

mA1

pD1

pA1

Delete non-reusable part

C

D

A

mA1

B

mB1

Contractual graph



Normalization rules

mB1

mB2

mB3

Preliminary test dependency graph

A

mA1

mA2

B

Problem : Not a classical graphA B

class-to-class graph

solution 1

Loss of information

A mA1

mA2

B

mB1 mB2 mB3

mixed classes and methods graph

solution 2

No loss of information

homomorphism



• An efficient strategy (1) a

b

e

k

f

d

c

i

j

g

h

l

Optimal ordering => NP-completecomplexity = n!



• An efficient strategy (2)

Tarjan’s algorithm

Determination and ordering of connected components

A

B

C

[(e) or C] [A or B] [(a)]thenthen

a

b

e

k

f

d

c

i

j

g

h

l

a

b

e

k

f

d

c

i

j

g

h

l

Complexity linear with #nodes



• An efficient strategy (3)

Bourdoncle’s algorithm

Break the connected componentReapply Tarjan

[(e) or C] [A or B] [(a)]thenthen

f

i

jg h

2

3

4

5

[g, h, j, i, f][c, b, d][l, k]

Candidate node =# max(fronds)

B

f

i

j

g

h 1


• Result = a partial ordered tree all possible strategies

a

b

e

k

f

d

c

i

j

g

h

l

#specific stubs = 4

#realistic stubs = 3

Random selection

Optimized algorithm

#specific stubs = 9.9

#realistic stubs = 5Partial ordered tree



Exo

• Plan de test d’intégration pour :

B

E

F

HG

A

C

D

I J


Cases Studies

• SMDSTelecommunication Switching System: Switched

Multimegabits Data Service running on top of connected networks such as the Broadband

Integrated Service Digital Network (B-ISDN) based on the asynchronous transfer mode (ATM).

22 Kloc

• Gnu Eiffel Compileropen-source Eiffel compiler70 Kloc of Eiffel code

(http://SmallEiffel.loria.fr)


Case studySMDSUML diagram

Retr. listSummary

StatusMa ster/SlLSReq list

Ne ighbor

NME LME GARME

L3_SDU

IADU GADUN MM

H eader

Serv type

D st addrSrc addr

Length

.........

L3_Payload Pad

L3_DTPDU

DTE

ISSI Link Set

Link ID

UpMe trics

Me th.Updt

Key_Space

L_ID

Line

Capacity

RelativeDKey_Range

Key

Current CL

Previous CL

Pa ram. smoothSampleTime

W T M

CME

(durations)

CMPDU

CMP

ECN

DeadIntHelloInt

RxmtIntMaxRetrTime

InfTransDelay


MaxA geMaxA geDiff

RME

RMPDU

LSta te

HeaderLSA

Encapsulate

Read and Write

with

with

com

.

com

.

com

.w

ith

Hello

Coope rate for routing

Store

and

updat

e

made of

consult

compu

te

(c omparaison)

sel ect

Read and Modify

com

mu

nica

te

sen d

spec

ial E

CNSt or e an

d upd a

t e

com

.w

ith

1..*

2*

ManagerSystemOperator

S up ervise

Entity

Clockconsult

withCommunicate

Supe

r vis

e

NeighborCongested

PUD count


manage

1..*


Read

Tab

leR

out

ing Path Type

Advertiser

Root

Next Hops

Table

Floading

Prev. Hop

has arepresentation

RM_Data

RMP_Hea der

Next H

op

Exch. Nb

Subsc riber

com

uni

cate

thro

ugh

has

loca

l

comunic ate through comm unic ate with local

GroupGroupID

Made of

Traffic Simulator

Profile

1

2 3 4 5 6

7 8 9

10

11

12

13 14 15

16

17 18

1920 21 22

23

24 2526

2728

29

30 31

3233

34

35 36

37


Case studySMDS

Test Dependency Graph


SMDS realistic stubs

Encapsulate

Read and Write

with

com

.

with

com

com

wit

Cooperate for routing

Store

and

updat

e

made of

compu

te

(c omparaison)

sel ect

Read and Modify

St or e an

d upd a

t e

com

wi

consult2*

S up ervise

consult

withCommunicate

Supe

r vis

e

manage

1..*


1..*

Read

RootTable

Next HopsFloading

Prev. Hop

representation

Tab

leR

out

ing

Next H

op

com

uni

cate

thro

ugh

has

loca

l

comunicate through communicate with local

GroupID

Made of

has a

3

Subscriber

Exch. Nb

com

mu

nic a

te

se

CMPDU

15

Hello

23LSA

Entity1

NMM7

ECN

17

Header25

t

Group6

RM_Data

18

L3_Payload

20

Retr. listSummary

StatusMaster/SlLSReq list

Neighbor

33

n d sp

ecia

l ECN

13

NeighborCongested

PUD count


29

L_ID

Line

Capacity

RelativeDKey_Range

37

RMPDUL3_SDU14

RMP_Header

16

LState

27

Path TypeAdvertiser

2224

NME

. h

Clock2

CMP

12

LME

.

4

Traffic Simulator

Profile 11

Operator

35

L3_DTPDU

26

10

DeadIntHelloInt

RxmtIntMaxRetrTime

InfTransDelay


MaxAgeMaxAgeDiff

RME31

Key

34

Current CL

Previous CL

Param. smoothSampleTime

W T M

CME

(durations)

28

GARME5

IADU8

ManagerSystem

36

DTE

Key_Space

30

GADU9

Header

Serv type

Dst addrSrc addr

Length

.........

19 Pad

21

ISSI Link Set

Link ID

UpMetrics

Meth.Updt

32


Gnu Eiffel Compiler

LOCAL_NAMEARGUMENT_NAME

NAME

+ is_manifest_string : Boolean+ is_result : Boolean+ is_void : Boolean

TYPE_CLASS

(from TYPE)

GLOBALS

PROCEDURE

DEFERRED_ROUTINE

DEFERRED_PROCEDURE

WRITABLE_ATTRIBUTE

ONCE_ROUTINE

ONCE_PROCEDUREE_CHECK

E_RETRY

REVERSE_ASSIGNMENT

ROUTINE

CALL

ONCE_FUNCTION

FUNCTION

DEFERRED_FUNCTION

ATTRIBUTE

DECLARATION_LISTDECLARATION

+ count : Integer

EXPRESSION

CST_ATT

+value

PROC_CALLASSIGNMENT

TYPE

CREATION_CALL

+call

+type

DECLARATION_1DECLARATION_GROUP

RENAME_PAIR

(from InheritanceClause)

EXPORT_ITEM


EXPRESSION

+left_side+right_side

+result_type

1

+writable

1

LOCAL_ARGUMENT

+name

+name_list

FORMAL_GENERIC_LIST

PARENT


+rename_list+export_list

CALL_PROC_CALL

1

+target

1

0..*

+arguments

0..*

FEATURE_NAME_LIST

+undefine_list

+redefine_list

+select_list

TYPE

+result_type

CLASS_NAME

SMALLEIFFEL

+ magic_count : Integer+ is_ready : Boolean

+ load_class()+ get_started()+ falling_down()+ afd_check()

PARENT_LIST


FEATURE_NAME

+ is_frozen : Boolean

CLASS_NAME

+to_runnable

FEATURE_CLAUSE_LIST

CREATION_CLAUSE_LIST

CLIENT_LIST

+list

BASE_CLASS

+ path : String+ is_deferred : Boolean+ is_expanded : Boolean/+ is_generic : Boolean+ is_any : Boolean = initval+ is_general : Boolean

+base_class

+base_class_dictionary

+base_class

+parent_list

+base_class

+origin_base_class

+base_class

+name

+feature_clause_list

+creation_clause_list

FORMAL_ARG_LIST

TYPE

FEATURE_CLAUSE

+clients

+list

CREATION_CLAUSE

+list

E_FEATURE

+ is_deferred : Boolean = initval

+clients

+base_class

+arguments

+result_type

+list

FEATURE_NAME_LIST

+procedure_list

+names

FEATURE_NAME

INFIX_NAMEPREFIX_NAMEFROZEN_FEATURE_NAME

WHEN_ITEM_1WHEN_ITEM_2

LOCAL_VAR_LIST

INSTRUCTION

E_LOOP

IFTHENELSEIFTHEN

E_DEBUG

EFFECTIVE_ROUTINE

+local_vars

COMPOUND

0..*0..*

+loop_body

+initialize

+else_compound

+then_compound

+routine_body

+rescue_compound

WHEN_ITEMWHEN_LIST

E_INSPECT

+else_compound

E_WHEN +list+list

SIMPLE_FEATURE_NAME

EXPRESSION

EXTERNAL_FUNCTIONEXTERNAL_PROCEDURE

NATIVE

+ language_name : String

EXTERNAL_ROUTINE+native

NATIVE_C NATIVE_SMALL_EIFFELNATIVE_JVM

TYPE_GENERIC

(from TYPE)

FORMAL_GENERIC_ARG

+ constrained : boolean+ rank : Integer

+list

TYPE_FORMAL_GENERIC

(from TYPE)

+formal_generic_list

TYPE

/ path : String

+generic_list

+constraint

+formal_generic_list

+current_type

TYPE_ANY

TYPE_CHARACTER

TYPE_POINTER TYPE_NONE

1 2

10

3

4 85 6 7 911

12

20

1314

15 16 17 18 19

21 22 23 24

25 26

27

28 29 30

60

31

51

32

3334

35

36

37 3839

40

41 4243 44

45

46 4748 49 50

52

5354

55

5657

58

5961

6263

6465

66 67

68 69 70

71

72 7374 75 76 77

78

7980

81

82

83 84

85

86 87 88



A comparison with

• 4 strategiesRC : Random Components selectionMC : Most Used ComponentsRT : Random Thread of DependenciesMT : Most Used Components Threads of

Dependencies (intuitive integration)

100 000 times for random strategies



25 26 27 28

20

36

26

3934

20

48

26

47

38

20

0

10

20

30

40

50

60

RC MC RT MT Optim.

Strategies

#stu

bs

Min

Mean

Max

• Specific stubs



13

19 18 19

9

2119

25 24

9

29

19

3027

9

0

5

10

15

20

25

30

35

RC MC RT MT Optim.

Strategies

#stu

bs

Min

Mean

Max

• Realistic stubs


Results summary

22 25 22

3225

3528

9

43

46

34

0

10

20

30

40

50

RC MC RT MT Optim.

#stu

bs40 38

27

63

28

63

34

17

87 85

27

0

20

40

60

80

100

RC MC RT MT Optim.

#st

ub

s

Min

Mean

Max

SMD

S ca

se s

tudy

GN

U E

iffe

l cas

e st

udy

Specific stubs counting Realistic stubs counting

25 27 28

36

26

39

34

20

48 47

38

0

10

20

30

40

50

60

RC MC RT MT Optim.

#st

ub

s

1318 1921 19

25 24

9

29 30 27

0

10

20

30

RC MC RT MT Optim.

#st

ub

s


Variantes possibles

• Mixte Big-Bang/Incrémental strict

• Planifier aussi le contexte dont on dépend (Pascale Thévenod)


Subsystem that can be integratedin one block (would need at least 1 stub)

Remaining part of the system

M A IL E R

-C losedSate closed;-C onnectingS tate connecting;-C onnectedS tate connected;-*string pendingQ ueue

+M ailer(){ currentS tate = closed}+void send (string m ess){ currentS tate .send(m ess)}+void steS tate (M ialerS tate s){ currentS tate = s;}+string getS tate ()+*string getPendingQ ueue ()…

M A ILE R STA TE

+M ailerS tate (M ailer m ){ m ailer = m ;}+ send(string m )

-currentS tate-m ailer

C L O SE D ST A T E

+send(string m ){ prin t(“T rying to send w hile closed : connecting”); m ailer.set_pending_m essage(m ess); m ailer. setS tate (connecting);}+ getM ailer ()

C O N N E C T IN G ST A T E

+send(string m ){ prin t(“T rying to send w hile connecting”); m ailer.set_pending_m essage(m ess);}

C O N N E C T E D ST A T E

+send(string m ){ prin t(« E ffective send w hile connected »); send_m essage(m ess);}-send_m essage(string m )

C losed C onnecting

C onnected

send

open

close

send

send

notify_connect

in it

DeadIntHelloInt

RxmtIntMaxRetrTime

InfTransDelay


MaxAgeMaxAgeDiff

RME

RMPDU

LState

HeaderLSA

Hello

Tab

leR

out

ing Path Type

Advertiser

Root

Next Hops

Table

Floading

Prev. Hop

has arepresentation

RM_Data

RMP_Header

Next H

op

Exch. Nb

Subscriber

com

uni

cate

thro

ugh

has

loca

l

GroupGroupID

Made of

Traffic Simulator

Profile


• Mixte Big-Bang/incrémental strict

B

E

F

HG

A

C

D

I J


• 3 classes par composante : problème NP-complet … encore !

B

E

F

HG

A

C

D

I J

Mixte Big-Bang/incrémental strict


• 6 classes par composante

B

E

F

HG

A

C

D

I J



Taille max SCC 1 5

SMDS, 37 classes, 72 connects 9 9

SmallEiffel, 104 classes, 140 connects

1 1

InterViews, 146 classes, 419 connects

6 3

Pylon, 50 classes, 133 connects 3 1

Java, 588 classes, 1935 connects 7 6

Swing, 694 classes, 3819 connects

14 1




• A new problem Testing Resources Optimal Repartition

• Using the partial ordered tree (acyclic)

• Assumption: a tester needs 1 time unit to integrate 1 componentto simplify presentationHeuristic to reduce integration duration


Titre:/home/ulla/d02/pampa/pmorel/./partial.bcgAuteur:bcg_editAperçu:Cette image EPS n'a pas été enregistréeavec un aperçu intégré.Commentaires:Cette image EPS peut être imprimée sur uneimprimante PostScript mais pas surun autre type d'imprimante.

Minimum steps >=max (A, B)A= longest_path

B= [nb_nodes/nb_testers] +1

4 testers37 nodesmax length = 8

Minimum steps= 10

10

Property



An optimal solution

components steps testers 20 33 18 6 1 414 22 27 16 2 41 25 7 17 3 424 12 2 3 4 415 13 29 37 5 431 10 34 28 6 421 19 9 32 7 48 30 36 5 8 426 35 4 11 9 423 10 1

Reaches the

optimal

A Test Resources Driven exampleSMDS



• Allocate the needed resources to obtain the minimum integration duration : at least (88 div 7 +1 = ) 13 testers

• Minimum delay : 7 steps

A Delay Driven example

GNU Eiffel

1

2

34

5

7

6



1

2

3

4

5

6

7

54 4 5 26 25 2 3 18 19 37 55 56 16

17 65 22 33 38 15 23 48 49 51 52 11 36

28 32 85 78 47 53 21 34 9 1 13 20 10

79 82 45 6 7 8 42 60 31 10 27 57 66

71 81 67 74 75 76 77 29 39 40 46 61 44

59 83 84 86 87 88 58 68 62 63 50 12 14

64 43 30 41 69 70 24 72 73 80

Component/node Step

A Delay Driven exampleGNU Eiffel

7 steps =

Optimum delay



• Conclusionsan adapted test model

Test Dependency Graph

efficient algorithms for early stage test planning (UML)

integration non-regression

evolving with design evolution test economics criterion (early repartition of testing

resources)

Yves Le Traon 2005 1 Plan 1.Problématique du test 2.Rappels test de logiciel 3.Test de composants...

Documents

Transcript of Yves Le Traon 2005 1 Plan 1.Problématique du test 2.Rappels test de logiciel 3.Test de composants...