Component Based Software TestingI.T.S GhaziabadPresented By -Shreesh Tiwari

OutlineIntroduction to CBST

Advantages of CBST

Challenges in testing Components

Techniques for building testable components

Regression Testing of Component Systems

Conclusions

IntroductionWhat 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.

IntroductionWhat 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.

Advantages of CBSTDevelopment cost is reduced

Development time is reduced

Complex systems can be built by reusing pre-existing components

Testing effort is reduced.

Component Based Systems: ArchitectureLaymans interpretation of Component Based System:

Component Based Systems: A cautionary Tale-Ariane exampleAriane 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: ChallengesTesting 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 TestingComponent Services are accessible through interfaces.CBSTInput InterfaceOutput Interface

Coverage Notions for Context Sensitive Component TestingInterface Coverage criterion: Requires that all interfaces for a component should be exercised at least once.Similar to Black box testing.

Interface 1Interface 2Test these 2 interfaces

Coverage Notions for Context Sensitive Component TestingEvent Coverage Criterion:Test an interface against all its possible invocationsTest 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 TestingContext 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.

Component 3Interface 1Interface 2Component 2Interface 1Interface 2Component 1Interface 1Interface 2Test all possible operational sequences in the in the componentSimilar to path Coverage

Coverage Notions for Context Sensitive Component TestingContent 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 componentsTechniques for building testable componentsBuilt In testsInterface ProbingTraceable ComponentsSelf testing componentsState Machine Models.

All these techniques involve the efforts of both the Component developer and Component User

Built In testsThe 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 ProbingComponent 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 ComponentsTractability is a facility that a component provides to track its internal and external behavior.

Tractability can be used to create test oracles.

Self Testing ComponentsAugment 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 modeMaintenance mode

State Machine ModelsTechniques 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 ModelTest 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 ModelBased 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 ComponentsDeveloper Tests ComponentsComponent Repository with adequately tested componentsComponent User validates the componentsFinal Software ProductUser tests the CBST in their Context

Regression Testing of Component SystemsSoftware 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.

ConclusionsTesting 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.