Testing Implementation Conformance with respect to its Architectural specification

1
Testing Implementation Conformance with respect
to its Architectural specification
Software Architectures and Testing
Antonia Bertolino IEI - CNR, Pisa
bertolino_at_iei.pi.cnr.it
Paola Inverardi, Henry Muccini University of
LAquila inverard, muccini_at_univaq.it
Begin
2
Main Research Area

• Integration Testing
• Software Architecture
• Architecture-based Testing

Click

• Keywords
• Testing Integration Testing, Functional Testing
• SA Architectural Languages, models and views
• Traceability, Graph coverage,

3
High level Description
drives
4
Overview on SA and Testing
5
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
Software Architectures and Testing
Testing

• 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

System
Unit
Integration
Code LevelOriented to SyntaxUnit Tests
Functional propertiesFormal specifications
Functional
Structural
7
Architecture-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 ExpectedBenefits
9

• To combine Structural and Specification-based
  Testing
• To mitigate their respective problems
• To handle complexity in the testing of large
  systems
• To detect and eliminate problems as early as
  possible
• Test planning interwoven with development and
  evolution (from Requirements to Code)
• High reusability
• CBSE and COTS

10
The SA-based Testing Approach
11
Software Architectures and Testing
The Approach
ICECCS97
Software Architecture formal description Global
LTS
ICSE00
Abstract LTS
Architectural Test Plan
IR22/00
Testing the Implementation
ICSE01
12
ADL Formal Description

• Assumption
• 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

• Chemical Abstract Machine (CHAM)
• Finite State Process (FSP)
• Dynamics in terms of Component interactions

ICSE00
Used ADLs
ICSE01
13

• Each LTS complete path represents a possible
  behavior, i.e. an LTS complete path could be
  taken as a test class
• BUTa lot of information (views) in a single
  graph and we can select many many potential test
  classes how to select interesting test classes?

14
The Abstraction

• 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

15
Flow view
ComponentBased View
16
Architectural Test Class
...

• ALTS Path Coverage
• Each complete path corresponds to an
  Architectural Test Class

17
From ALTS to LTS

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

18
Testing 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 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
(No Transcript)
21
Results
22
(No Transcript)
23
Results 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 system
• To encrease the integration testing approach
  automation
• To use model-checking to manage the state
  explosion problem and to verify the architectural
  behavior againts the requirements

24
Software Architectures and Testing
Henry MucciniPh-D Student in Computer
ScienceUniversity of LAquila -
Italymuccini_at_univaq.ithttp//www.dm.univaq.it/m
uccini
25
References
ICECCS97 A. Bertolino, P. Inverardi, H.
Muccini and A. Rosetti. An Approach to
Integration Testing Based on Architectural
Descriptions On 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.
Muccini Specification-based Testing In-The-Large
Driven by the Software Architecture IR 22/00,
University of L'Aquila.On-line athttp//www.dm.un
ivaq.it/muccini/Page2.html ICSE2001 A.
Bertolino, P. Inverardi and H. Muccini. An
Explorative Journey from Architectural Tests
Definition downto Code Tests Execution Proc. 23nd
Int. Conf. on Softw. Eng. (ICSE2001), May 2001.