Testing of Object-Oriented Software www.carrertime.in www.facebook.com/carrertime.in

1. 1
Research Project Proposal
on
Testing of Object-Oriented
Software
Dr. D. P. Mohapatra
Assistant Professor, C. S. E. Deptt.
National Institute of Technology, Rourkela

2. 2
Outline of the Presentation
• Introduction
• Motivation for Research
• Objectives of research
• Plan of action
• Summary

3. 3
Introduction
• In a typical software development project,
more than 50% of the software development
effort is being spent on testing.
• Quality of the end product and effective
reuse of software depend to a large extent
on testing.
• So, Developers spend considerable amount
of time and effort to achieve thorough
testing.

4. 4
• Regardless of the test strategy being used, large
systems such as OOPs are inherently complex to
test and require large number of test cases to be
designed.
• Creation of test cases is possibly the most difficult
step in testing.
• To reduce the testing cost and effort and to
achieve better quality software, automatic testing
has become an urgent necessity.

5. 5
• Automatic test case generation
- can reduce development cost by
eliminating costly manual test case
design effort &
- help increase reliability through
increased test coverage.

6. 6
Current Relevance
• Software industries spend a huge amount of effort
for testing their developed software.
• The proposed testing algorithms can be used by
software industries to minimize the effort required
for testing of very large object-oriented programs.
• The proposed testing algorithms can also be used
in other disciplines such as electrical engineering,
electronics and communication engineering etc.
for testing of concerned software.

7. 7
Motivation
• Present-day software systems are basically object-
oriented due to several advantages.
• Quality and effective reuse of software depends on
thorough testing.
• Conventional testing methods are inadequate to
test object- oriented systems as it cannot address
the issues related to O-O features such as
inheritance, polymorphism etc.
• The O-O features such as inheritance,
polymorphism etc. need to be considered
carefully in the testing process.
• Hence, new methods and tools are to be developed
for testing of O-O S/W.

8. 8
Objectives
• The objective of the project would be to
design & develop a tool for testing O-O
S/W.
• This work would involve the following:
• Design of a framework for automated
testing. The framework would be based on
constructing an intermediate program graph
representation.

9. 9
• Automatically or semi-automatically
generate test cases from an analysis of the
constructed graph.
• Develop an effective GUI.
• Evaluate the performance of the proposed
testing algorithms.

10. 10
Testing of OOPs
• Test cases are commonly designed based on
program source code. This makes test case
generation difficult especially for testing at
cluster levels.
• Further this approach proves to be
inadequate in component-based software
development, where the source code may
not be available to the developers.
• It is therefore desirable to generate test
cases automatically from the software
design documents.
• Test generation from design documents has
the added advantage of allowing test cases
to be available early in the SDLC, thereby
making test planning more effective.

11. 11
Plan of Action
• We shall propose techniques for testing OOPs
using UML diagrams & slicing methodology.
• We shall first develop an intermediate graph
representation for the OOPs.
• Then, we will generate test cases from the
intermediate graph representation by applying
- function minimization technique.
- slicing technique.
• We will develop an effective GUI to efficiently
carry out the testing activities.

12. 12
• We concentrate upon automatically generating test
cases based on communication diagrams.
• Communication diagrams represent both the
messages passed between objects and their
sequences.
• So, communication diagrams can provide both
data flow and control flow infn.
• Data flow and control flow infn. have significant
bearing on test case generation.
• Hence, using communication diagrams, it is
possible to generate cluster level test cases even
before any code is written.

13. 13
• The first step will be constructing a
communication tree from the commn. diagram.
• Then, we will iteratively select a predicate from
this tree.
• We then transform this predicate to find the test
data corresponding to the predicate.
• For each selected predicate, we then record test
cases & the next predicate is selected for test
generation.
• For each selected predicate, the transform
predicate step & the generate test data step are
repeated. The process continues till all predicates
are considered .

14. 14
Plan of Action cont …

15. 15
Example

16. 16
Example

17. 17
Class diagram for generating test cases

18. 18
• The important classes which will be used in
our implementation are as follows:
• XmlBoundary class will be responsible for
accepting a communication diagram in
XML format. This class will display a
prompt to user and will ask for a filename.
• TestCaseController class coordinates the
different activities of the program.

19. 19
• ElementFinder class uses the
getElementsByTag-Name method of
Element object to obtain the list of nodes
inside parent node. Element is an interface
of org.w3c.dom package. It represents an
element in an HTML or XML document.
• DocumentParser class parses the XML file
for the message names, arguments,
sequence numbers etc. and constructs the
communication tree.

20. 20
• TestDataFinder uses the parsed information
and finds the test data in the form of a
string.
• TestCaseBoundary class is responsible for
displaying the list of test cases for a
communication diagram.

21. 21
Performance Evaluation
• At last, we shall
- test all the proposed algorithms with several sets
of input data.
- evaluate the performance of each algorithm.
- compare the results.

22. 22
Activity Time in months
0 – 6 6 –
12
12 – 18 18 – 24 24 – 30 30 – 36
Obtaining quotations for different
consumables and equipment.
Placement of order and recruitment
of Project Associate.
Set up of equipments.
Constructing the intermediate graph
representation.
Generating test cases from an
analysis of the intermediate graph
representation.
Providing utilities to the tester for
determining static and dynamic
coverage of the program from the
generated test suite.
Developing an effective graphical
user interface (GUI).

23. 23
Summary
• Develop a technique for automatic generation of test case
for OOPs.
• Our technique will be based on an intermediate graph
representation.
• We will use use-case diagrams, class diagrams, sequence
diagrams and collaboration diagrams for the testing
purpose.
• Implement our algorithms using Java.
• Analyze and compare the results.
• Measure the performance of the algorithms.

24. 24
Thank You

25. 25
Program Slice
• Slice of a program w.r.t. program point p
and variable x:
- All statements and predicates that
might affect the value of x at point p.
• <p, x> known as slicing criterion.

26. 26
Example
1 main( )
2 {
3 int i, sum;
4 sum = 0;
5 i = 1;
6 while(i <= 10)
7 {
8 Sum = sum + 1;
9 ++ i;
10 }
11 printf(“%d”, sum);
12 printf(“%d”, i);
13 }
An Example Program & its slice w.r.t. <12, i>