Testing Implementation Conformance with respect to its Architectural specification Software Architectures and Testing Begin Antonia Bertolino IEI - CNR,

Testing Implementation Conformance with respect to its

Architectural specification

Software Architectures and Testing Software Architectures and Testing

BeginBegin

Antonia BertolinoAntonia Bertolino

IEI - CNR, Pisa IEI - CNR, Pisa

[email protected] [email protected]

Paola Inverardi, Henry MucciniPaola Inverardi, Henry Muccini

University of L’Aquila University of L’Aquila

{inverard, muccini}@univaq.it {inverard, muccini}@univaq.it

2

Main Research AreaMain Research AreaMain Research AreaMain Research Area


HenryMuccini HenryMuccini

Integration Testing + Software Architecture =

Architecture-based Testing

Keywords:Keywords:Testing: Integration Testing, Functional TestingSA: Architectural Languages, models and views

Traceability, Graph coverage,

ClickClick

3

High level DescriptionHigh level DescriptionHigh level DescriptionHigh level Description



Testing

Implementation

Software

Specification

(informal)

FormalArchitectural

Description

drives

4

Overview on SA and TestingOverview on SA and Testing



5

Software Architecture (SA)Software Architecture (SA)Software Architecture (SA)Software Architecture (SA)

Describes (in a formal language) how a system is structured into components and how these components interact

SA:

Structure (statics)Behavior (dynamics)

Given the SA description (in some ADL), the model can be automatically generated; the dynamics is expressed in terms of components interactions via connectors

Architectural Description Language



6

TestingTestingTestingTesting

Testing is a process of executing a program with the intent of finding errors or defects: a successful test is one that uncovers an as yet undiscovered error.

To increase our confidence in the proper functioning of the software.

Not exaustive approach

Module Unit Integration SystemModule ModuleM

M

M

M

Structural Functional


Code LevelOriented to SyntaxUnit Tests

Functional propertiesFormal specifications

7

Architecture-based Integration TestingArchitecture-based Integration TestingArchitecture-based Integration TestingArchitecture-based Integration Testing

Integration Testing: interconnects sets of previously tested modules to ensure that the sets behave as well as they did as independently tested modules.

Integration Testing is aimed at exposing problems in the interfaces and interactions between the system components

Functional: focus on the functional requirements of the software Architectural: information for testing are extracted from the

Architectural specification



8

Motivations and ExpectedBenefitsMotivations and ExpectedBenefits



9

To combine Structural and Specification-based Testing To mitigate their respective problemsTo handle complexity in the testing of large systemsTo detect and eliminate problems as early as possibleTest planning interwoven with development and

evolution (from Requirements to Code)High reusabilityCBSE and COTS



10

The SA-based Testing ApproachThe SA-based Testing Approach



11


[ICECCS’97]

Abstract LTS

Architectural

Test Plan

Testing the

Implementation

Software Architecture formal description

Global LTS

[ICSE00]

[ICSE01]

The ApproachThe ApproachThe ApproachThe Approach

[IR22/00]

12

AssumptionAssumption:

Architectural Description Language (ADL) that produces a global Labelled Transition System (LTS) in which:

L defines the LTS labels, also called LTS actions

Nodes carry on info about the state of each SA component

Arcs carry on info about the interactions

ADL Formal DescriptionADL Formal DescriptionADL Formal DescriptionADL Formal Description


HenryMucciniHenryMuccini

[ICSE00]

[ICSE01]

Chemical Abstract Machine (CHAM)

Finite State Process (FSP)

Dynamics in terms of Component interactions

Used ADLs

13

Each LTS complete path represents a possible behavior, i.e. an LTS complete path could be taken as a test class

BUT…a lot of information (views) in a single graph and we can select many many potential test classes… how to select interesting test classes?



14

Architectural Views

Flow view

Component Based view

Concurrency view

...

Given the LTS, we apply an Obs Functions to view the system only from a perspective that is relevant for testing

Obs : L D {}

Minimization and Reduction

The AbstractionThe AbstractionThe AbstractionThe Abstraction

Operational Description (LTS)

Observation View(ALTS)

DynamicView



15F R n o

F R n o F R n o

T R a ck 1T R a ck 2

F R n o

T R a ck 2T R a ck 1

F R a 1F R a 2

F R a 2F R a 1

D

A

BC

Flow view:

ComponentBased View:

R e c e iv e A c k 1

R e c e iv e A c k 2R e c e iv e A c k 1

S e n d A la r m 1S e n d A la r m 2


A

B C

D




16

ALTS Path Coverage

Each complete path corresponds to an Architectural Test Class

...

Architectural Test ClassArchitectural Test ClassArchitectural Test ClassArchitectural Test Class





A

B C

D






A

B C

D






A

B C

D




17

1 51 7

1 3

1 8

1 61 41 26

5

3

97

5

117

6

976

5

1 3

32

11

6

43

4

11

3

25

4

35 2

2 1

0

11

6

4

21

0

9

2 92 6

1 3

113 21 5

2 0 51 4 39 05 12 6

2 5

1 9

2 3

2 0

4 14 0

3 9

3 8

7 2

7 1

1 5 9 1 0 76 7

1 0 7

11 7

5 3

9 3 4

SendAlarm1.ReceiveAck1 corresponds to many LTS complete paths [IR22/00]

ReceiveAck1

SendAlarm1

A

B

From ALTS to LTSFrom ALTS to LTSFrom ALTS to LTSFrom ALTS to LTS



18

Testing the Software ImplementationTesting the Software ImplementationTesting the Software ImplementationTesting the Software Implementation

Given ar architectural path to be tested:

We can verify this behavior against the Requirements.

We can test whether the system as-built implements this architectural behavior

How are the LTS paths implemented by the Code?

Re-Architecting Context

SA and Code have been developed

independently :

Design is independent of the SA topology

SA after Implementation

Forward Development

SA drives the system design:

COTS

Component Based



19

Re-Architecting ContextRe-Architecting ContextRe-Architecting ContextRe-Architecting Context



Let act1, act2, …, actN the LTS actions, each Test class is composed by a sequence of these actions and:

4.1 Each path may be represented by an architectural scenario;

4.2 For each action, we try to understand how these functionalities are implemented by the source code

4.3 The source code scenarios are put together to implement the test class, i.e., tha architectural scenario

4.4 The tester runs the code

20



Comp1 Comp2

act1

Comp2 Comp3

act2

Comp2 Comp4

act3

the events areimplemented

by

Comp1 Comp4Comp3Comp2

act1

act2

act3

act1act2

Obj1m1

ObjN...Obj3Obj2

m6m3

m1

act1 Implementation

Obj1m1

ObjK...Obj8Obj3

m6m2

m2

act2 Implementation

Obj3m1

ObjL...Obj1Obj5

m5m1

m2

act3 Implementation

Obj1

m1

Obj5Obj3Obj2

m6

m3

ObjN

Objk

Obj8

ObjL

m1m6

m3

m1

m2

m2

1act

3act

2act2act

act1.act3.act2.act2.act1

eventsin the SA path

21

U ser1 R o u terU ser2

<<Input>>SendA larm 1

<<Input>>SendA larm 2

<<O utput>>ReceiveAck2

<<O utput>>ReceiveAck1

ResultsResultsResultsResults





A

B C

D




22

xU ser U serR epeatEvent

A tT im eC lient

C onnectionSendN

M essagesTryEvent

xR outerM asterR outer

ServerC onnection

ServerSocket

R eceiveU serA larm

ServerService

R eceiveNM essages

a1) User Send Alarm Scenario

a2) Router Receive Alarm Scenario

if_1

new ()

if_2

new ()

cc=new ()

snm =new(cc,...)new ()

snm .send()

for (i=0; i<x)runEvent() s= new

Socket()if_3

new ()new ()

ss=new ()if_a new ()

runEvent() while (true)accept()

if_b rnm =new()

rnm .receive()read()



23

Results and Future WorksResults and Future WorksResults and Future WorksResults and Future Works

We found an architectural error in the TRMCS case

study, BUT...… we need to compare our approach with other

functional testing approaches.

To apply this approach to an italian telecommunication

systemTo encrease the integration testing approach

automationTo use model-checking to manage the state explosion

problem and to verify the architectural behavior againts

the requirements



Software Architectures and TestingSoftware Architectures and Testing

Henry MucciniHenry MucciniPh-D Student in Computer Science

University of L’Aquila - [email protected]@univaq.it

http://www.dm.univaq.it/~muccinihttp://www.dm.univaq.it/~muccini

[ICECCS’97]A. Bertolino, P. Inverardi, H. Muccini and A. Rosetti.An Approach to Integration Testing Based on Architectural DescriptionsOn IEEE Proc. ICECCS-97, Como, 1997.[ICSE2000]A. Bertolino, F. Corradini, P. Inverardi, H. Muccini.Deriving Test Plans from Architectural Descriptions.Proc. 22nd Int. Conf. on Softw. Eng. (ICSE2000), June 4th-11th, 2000.[IR22/00]A. Bertolino, P. Inverardi and H. MucciniSpecification-based Testing In-The-Large Driven by the Software ArchitectureIR 22/00, University of L'Aquila.On-line at:http://www.dm.univaq.it/~muccini/Page2.html[ICSE2001]A. Bertolino, P. Inverardi and H. Muccini.An Explorative Journey from Architectural Tests Definition downto Code Tests ExecutionProc. 23nd Int. Conf. on Softw. Eng. (ICSE2001), May 2001.

ReferencesReferencesReferencesReferences

Documents

Testing Implementation Conformance with respect to its Architectural specification Software Architectures and Testing Begin Antonia Bertolino IEI - CNR,