Presentazione di PowerPoint

1
ICSE 2003, May 7th, Portland, Oregon - USA
A Framework for Component Deployment Testing
Antonia Bertolino Andrea Polini Istituto di
Scienza e Tecnologie dellInformazione A.
Faedo Area della ricerca del CNR di Pisa - Italy
2
Component-based SE

• Why do we need to build systems out of
  components?
• - we can do without, but the cost is high!!
• - cheaper, more reliable and faster
  development
• Many kinds of components, along a continuous
  spectrum

Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
3
Towards the COTS end

• Advantages of a COTS approach components
  developed by expert organizations for the
  specific area, more reliable components, no
  development overhead
• Lack of information leads to the
• Component Trust Problem
• Many approaches to mitigate the CTP
  (Design-by-Contract, Formal Methods, )
• Testing
• - Tests conducted by the (component) developer
• - Tests conducted by the customer (or system
  constructor)

Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
4
Concerning the CB process

• Generally recognized that a process specifically
  targeted to CB is required
• The architecture specification must also be
  influenced by the granularity of the retrievable
  component
• Without considering a specific process we can
  suppose that the following phases will be
  present
• 1. specification phase features of required
  components are identified
• 2. provisioning phase some candidate components
  are identified
• 3. validation phase identified components are
  validated against the spec. for the searched comp.

Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
5
Rethinking the test process in a CB setting

• Component test performed by the component
  developer before delivery
• Deployment test performed by the system
  constructor we can foresee two steps
• 1. the component is directly tested by invoking
  its API (components required services to be
  provided, e.g., as stubs)
• 2. the component is (incrementally) tested as
  part of a larger subsystem
• System test system tested as a whole (does not
  show notable differences with respect to
  traditional development)

Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
6
Related Work

• Proposed approaches, related to testing, to
  mitigate the Component Trust Problem
• - Built-in Tests
• - Testable Architecture
• - XML-based Test Documentation
• - Certification Agency
• - Metadata
• - Customers Specified Tests

Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
7
Related Work

• Proposed approaches, related to testing, to
  mitigate the Component Trust Problem
• - Built-in Tests
• - Testable Architecture
• - XML-based Test Documentation
• - Certification Agency
• - Metadata
• - Customers Specified Tests

Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
8
Our Objectives

• We intend to develop mechanisms allowing for
• 1. the early codification of test cases by the
  customer, based on the expected behavior
  from the component within the target system
• 2. the easy re-use of the established test
  cases, in order to evaluate a set of candidate
  components
• 3. the easy configuration/re-configuration
  of a system, in order to execute the test
  cases
• 4. reducing the number of test cases to be
  re- executed when a component is substituted

Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
9
Starting assumptions

• We start by realistically considering how a
  component is delivered by the developer, rather
  than how we would like it could be done ideally
• We assume that the available information
  includes
• 1. provided services
• 2. required services
• 3. summary description of the behavior of
  methods in the provided interface
  (e.g., JavaDoc format)

Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
10
Virtual vs. Real Components

• Virtual Component the component as expected in
  the system architecture specification
• Real Component an actual component as built
• In an established component domain it should be a
  one-to-one correspondence, but, in general, there
  is not such a direct correspondence and virtual
  components might become composite components.

Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
11
The CDT Framework
Test Specification
Concrete Component 1
Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
12
The CDT Framework

• Elements in the framework and main interactions

Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
13
The CDT Framework
SPY
Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
14
CDT The SPY

• It permits to early codify the test cases
  before/without the need of an implementation
• To be developed for each virtual component, but
  according to a standard structure
• It keeps the Driver informed about any component
  invocation made by the Test Cases

Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
15
The CDT Framework
Test Repository
Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
16
CDT The Test Repository

• It contains the test cases specified by the
  system constructor each test refers to a SPY
  element as the test target
• It is mainly realized by using JUnit (as a
  storage component)
• When a test session starts, a set of test cases
  is retrieved and executed

Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
17
The CDT Framework
Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
18
CDT The XMLAdapter

• Elements necessary to correlate the virtual and
  the real components
• The XMLAdapter encodes the rules to adapt the
  virtual component to the real component
• Cases handled by the XMLAdapter
• 1. Differences in the method signatures
• 2. One method in the SPY corresponding to
  several methods in the real component
  (inverse case not of interest)

Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
19
CDT An XMLAdapter example
ltMataHarigt lttestPackage name"it.cnr.isti.test.ba
nk" /gt lttestClass name"BankTest" /gt
ltrealPackage name"real" /gt ltVirtualMethod
name"deposit" parameters"accNum
amount"gt ltcreateObject class"REAL_PACKAGE.Coupl
e" objectName"c"gt ltparameter value"accNum"
/gt ltparameter type"int" value"amount"
/gt lt/createObjectgt ltexecMethod object"bank"
name"put"gt ltparameter value"c"
/gt lt/execMethodgt ltexecMethod object"bank"
name"howMuch" putResultIn"aCouple"gt ltparamete
r value"accNum" /gt lt/execMethodgt ltexecMethod
object"aCouple" name"getSum" putResultIn"output
" /gt lt/VirtualMethodgt lt/MataHarigt

• Why we use the XMLAdapter

Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
20
The CDT Framework
Driver
Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
21
CDT The Driver

• Core of the approach, developed once and for all
• It retrieves the information from the XMLAdapter
  by using the XMLHandler
• Analyzing the retrieved information, it
  identifies the tests to be executed
• It opportunely redirects the invocations (by
  reflection) according to the SPY information

Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
22
CDT at Work
CDT
Test Cases
Virtual Component Codification
XML Adapter
Driver
Real Component
Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
23
How the customer can use CDT

• System Specification
• Development of a suitable architecture, following
  for instance the UML Components methodology
• The established interfaces are coded in Java
  classes, each generally referred to as the SPY
• Test specification
• Based on the specifications, testers develop test
  suites to evaluate the components using the SPY
  as the test target
• Provisioning
• Other teams search suitable candidate components
• Deployment testing
• Found candidate components are evaluated using CDT

Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
24
How the developer can (also) use CDT

• As a by-product, CDT could be used to transfer
  the developers test cases to the customer
• One redirection overhead
• Same power of the Built-in Test approach (if the
  component implements a specific particular
  interface, similarly to the testable architecture
  approach)
• Internally, the developer can use CDT for testing
  different versions of a component or components
  with similar functionality

Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
25
Adds-on

• WCT a wrapper to interconnect real components,
  forming a virtual component, and to control the
  interactions
• Contract checking
• - iContract has been integrated in the
  framework
• - SPY classes are instrumented with pre- and
  post-conditions, and recompiled via iContract
• Tracing mechanisms in XML format (e.g., after
  failure detection)

Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
26
Major Benefits

• Decoupling of test specifications and design from
  component implementation and adaptation
• No specific requirements on the candidate
  components for testing purposes
• Test cases reuse
• Test suite flexibility (easy to add new test
  cases to a suite)
• Simple mechanisms to group test cases for
  regression testing purposes (by JUnit)

Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
27
We are working on

• Tools to simplify and automate the creation of
  the needed artifacts (e.g., the drawing up of the
  XMLAdapter)
• Integration with strategies to derive test cases
  from UML diagrams (currently we are working at
  extending Cow_Suite)

Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA
28
UML Combination

• Combining different methodology to produce a
  Integrated Deployment Testing Environment
• 1. UML Components
• 2. Cow_Suite
• 3. CDT

29
Cow_Suite Reviewing

• Two phases
• 1. Single virtual component weight on the CDs
  reflected on each method invocation that appear
  in a CD. Components tested using stubs
• 2. Subsystem test difficulties in driving test
  execution since we suppose the use of black-box
  component.
• - weight as a operational profile
• - how information collected (by WCT) in step 1
  can be usefully used, now?

30
UML Combination experimentation

• Currently we have produced a component based
  specification of the JAIN-MAP layer and reviewed
  part of the code

31
UML Combination experimentation

• We started deriving test cases for the single
  components and we have executed some of them
• It seems to work )

32
Thanks
Antonia Bertolino, Andrea Polini A Framework
for Component Deployment Testing
ICSE 2003, May 7th, Portland, Oregon - USA