Component Based

Software Testing

I.T.S
Ghaziabad
Presented By Shreesh Tiwari

Outline

Introduction to CBST

Advantages of CBST

Challenges in testing Components

Techniques for building testable components

Regression Testing of Component Systems

Conclusions

Introduction

What is Component Based Software Engineering (CBSE)?

This approach is based on the idea to develop software

systems by selecting appropriate off-the-shelf components
and then assemble them with a well-defined software
architecture.

CBSE has three major functions:

Developing software from prefabricated, reusable

parts.
The ability to use those parts in other applications.
Easily maintaining and customizing those parts to
produce new functions and features.

Introduction

What is a Component Based Software Testing (CBST) ?

A component is an independent and replaceable part of a system

that fulfills a clear function.
A component works in the context of a well defined architecture.
A component communicates with other components by its
interfaces.
Can be developed by different developers, using different
languages and different platforms.
Component
1
Component
repository

select

Component
2

Component
n

Software
system

assemble

Advantages of CBST

Development cost is reduced

Development time is reduced

Complex systems can be built by reusing preexisting components

Testing effort is reduced.

Component Based Systems:

Architecture

Laymans interpretation of Component Based

System:
Developer
Builds
Component

Developer
Tests
Component

Final Software
Product

Component Repository
with adequately tested
components

Component User
uses the components

Component Based Systems: A

cautionary Tale-Ariane example

Ariane Flight 501 crashed 30 sec after take-0ff

One of the reasons for the failure of the first Ariane 5 was that a
conversion to integer its software failed (overflow)

That code was taken from Ariane 4, and had been successfully
tested for Ariane 4.

But Ariane 5 had a higher initial velocity and was heavier than
Ariane 4.

The story learnt: Even adequately tested components can fail when
the context in which it is used changes.

Testing Components:
Challenges

Testing is done by the developer.

System Requirements not available. Instead the developer

has to use Component specifications.

Unpredictable Environment.

Unpredictable interaction with other components.

Context Sensitive Component

Testing: Challenges

Testing is done by the Component User.

Unavailability of source code.

Source code in various languages.

Dependencies and interactions among components is

complex.

Coverage Notions for Context

Sensitive Component Testing

Input Interface
CBST
Output Interface

Component Services are accessible through interfaces.

Coverage Notions for Context

Sensitive Component Testing

Interface Coverage criterion: Requires that all

interfaces for a component should be exercised at least
once.
Similar to Black box testing.
Test these 2
interfaces
Interface 1

Interface 2

Coverage Notions for Context

Sensitive Component Testing

Event Coverage Criterion:

Test an interface against all its possible

invocations

Interface 1

Interface 2

Interface 1

Component 1

Interface 2

Component 2

Interface 1

Interface 2

Component 3

Test Interface 1 of component 3

invocated by Interface1 of
Component1.
Test Interface 1 of Component 3
invocated by Interface 2 of
component 2

Coverage Notions for Context

Sensitive Component Testing

Context Dependency Test Coverage criterion:

Sometimes events can have sequential dependencies on each

other and the order in which they are triggered can result in
different program behavior.
Such dependencies are called context dependencies.

Interface 1

Interface 2

Component 1

Interface 1

Interface 2

Component 2

Interface 1

Component 3

Test all possible operational sequences in the in the component

Similar to path Coverage

Interface 2

Coverage Notions for Context

Sensitive Component Testing

Content Dependency test criterion

A content dependency exists between 2 interfaces I1

and I2 if an operation of I2 modifies the value of a
variable used in an operation of I1.

In this case I2 is said to be content dependent on I1.

Test all the content dependencies in the software.

Similar to All Def-Use criterion

Coverage Notions for Context

Sensitive Component Testing

Testable CBST components

Techniques for building testable components

Built In tests
Interface Probing
Traceable Components
Self testing components
State Machine Models.
All these techniques involve the efforts of both the
Component developer and Component User

Built In tests

The developer Packages components with the test

cases.

These test cases may be executed on the component by

using a test executor.

Using built in test cases a component user can validate

the behavior of the CBST functionalities.

Interface Probing

Component users might employ this technique to

understand the component functionalities.

The functionality can then be used as the basis for

creating test oracles.

The component developer can reduce the effort

required to determine component properties by
automating certain aspects of interface probing.

Traceable Components

Tractability is a facility that a component provides to

track its internal and external behavior.

Tractability can be used to create test oracles.

Self Testing Components

Augment the component with functionality of analysis

and testing tools.

A component augmented accordingly is capable of

performing some or all activities of the component users
testing process.

Component can run in 2 modes:

Normal mode
Maintenance mode

State Machine Models

Techniques discussed in the previous slides are

techniques for better exchange of information between
Component developer and user.

Based on the knowledge gained the component user has

to write test cases to validate if the component will work
in its context.

An automated technique to check if a component will

work in its context is needed

State Machine Model

Test cases generated for testing components in their

context.

This component considers each component as a FSM.

For representing a system and its context all the Finite

State Machines are combined together to form a
Component Based Flow Graph (CBFG)

State Machine Models

State Machine Model

Based on the CBFG test cases that are context

adequate and content adequate are generated.

Problem in State Machine Models: The testing effort of a

component can be greater than the re-development
effort of the same component!

Modified CBS Architecture

Developer
Builds
Testable
Components
Final Software
Product

Developer
Tests
Components

User tests the

CBST in their
Context

Component Repository
with adequately tested
components

Component User
validates the
components

Regression Testing of
Component Systems

Software built using components have system

components and CBST.

New challenges:
System components might evolve while CBST
components remain static.
CBST components might evolve while the system
components remain static.
Both CBST and system components can evolve.

Conclusions

Testing components in the context of their system is not trivial!

Current research is focusing on 'building testable components'

than 'testing components in their context'

This gives an indication that if a component is not testable it is

difficult/ impossible to test it in it in the context of its system.

Future research in this field might focus on making use of the

testable components to automate testing components in the
context of their system.