UNIT - 4

OBJECT ORIENTED TESTING AND

MAINTENANCE
UNIT - IV OBJECT ORIENTED TESTING AND MAINTENANCE

Software testing: Software Verification Techniques – Object Oriented

Checklist :- Functional Testing – Structural Testing – Class Testing –
Mutation Testing – Levels of Testing – Static and Dynamic Testing Tools -
Software Maintenance – Categories – Challenges of Software Maintenance
– Maintenance of Object Oriented Software – Regression Testing.

Reference:
1. Yogesh Singh, Ruchika Malhotra, “Object – Oriented Software
Engineering”, PHI Learning Private Limited, First edition, 2012
Software Testing
 Software Testing
• Testing is the process of executing a program with the intent
of finding errors.
• Types of errors:
Ø Language (Syntax) errors – result from incorrectly
constructed code. Eg. Incorrectly typed keyword, some
necessary punctuation omitted.
Ø Run-Time errors – errors detected during program running.
Eg. To access nonexistence file.
Ø Logic error – when code does not perform the way you
intended. Eg. The code syntactically valid but produced
wrong results.
 Software Testing
• Testing is divided into 2 parts:
1. Verification
2. Validation
• Software testing is the process of verifying the outcomes
of every phase of software development and validating
the program by executing it with the intention of finding
faults.
• Software Verification (Static Testing): testing activities are
carried out without executing the program.
• Validation (dynamic testing): the program is executed
with given inputs.
Software Verification Techniques
 Software Verification Techniques
• Software verification are applicable in every phase
software development lifecycle
• The purpose of such techniques to review the outcomes of
every phase of software development lifecycle that is from
requirements and analysis phase to testing phase.
• It may include:
Ø walkthrough
ØReview inspections
Øpeer reviews
 Software Verification Techniques
• Peer reviews
• Simplest, informal and oldest verification technique
• It is applicable every document produced any stage of
software development
• Programs are also reviewed executing them
• To give documents/programs to someone else and ask
them to review with an objective of finding faults
• Easily applicable to small sized documents and programs
 Software Verification Techniques
• Walkthroughs
• Is a group activities for reviewing the documents and
programs
• It is more formal and systematic technique peer reviews
• A group of 2 to 7 people is constituted for the purpose of
reviewing
• The author of the document presence the document to the
group using display mechanism (whiteboard, projector, etc.)
• All participants are free to ask questions and write their
observations on any display mechanism in such a way
everyone can see it.
 Software Verification Techniques
• Inspections
• It is more formal, systematic and effective
• There are many names: formal reviews, formal technical
reviews and inspections
• A group of 3 to 6 people are constituted
• The author of the document is not the presenter
• An independent presenter is appointed for this specific
purpose
• A senior will conduct a meeting smoothly
• A recorder is also engaged to record the procedings of
the meeting
Checklist: A popular verification tool
 Checklist
• A checklist is normally used which consist of a list of
important information contents that a deliverable must
contain.
• A checklist may discipline the reviewing process and may
identify duplicate information, missing information, unclear
and wrong information.
• A checklist maybe a applicable in all verification techniques
but it is more effective during inspections.
SRS Document Checklist
Object-Oriented Analysis Checklist
Object-Oriented Design Checklist
Functional Testing
 Functional Testing
• Functional testing techniques are validation techniques
because execution of the program is essential for the
purpose of testing.
• Inputs are given to the program during execution and the
observed output is compared with the expected output.
• If the observed output is different than the expected output,
the situation is treated as a failure of the program.
• Functional testing is also called black box testing because
internal structure of the program is completely ignored.
Functional Testing
Boundary Value Analysis:
• The boundary value analysis technique focuses upon on or close
to boundary values of input domain.
• Consider a program “ square root” which takes a as an input
value and prints the square root of a. The range of input value a
from 100 to 1000.
• We may execute the program for all input values from 100 to
1000 and observe the outputs of the program 900 times to see
the output for every possible valid input.
• On or close to boundary values cover the following:
• Minimum value
• Just above the minimum value
• Maximum value
• Just below the maximum value
• Nominal(average) value
• The technique selects only 5 values instead of 900 values to test
the program. These values of a are 100, 101, 550, 999, 1000
which cover the boundary portions of the input value except
one nominal value (say, 550).
• The number of test cases designed by this technique is 4n + 1,
where n is the no. of input values.
• The test cases generated for the “square route” program are
given in the next slide.
Example:
Consider a program to multiply and divide 2 numbers. The inputs
maybe too valid integers (a,b) in the range of [0, 100].generate
boundary value analysis test cases.
Solution:
Equivalence class testing:
Equivalence partitioning or equivalence class partitioning
(ECP) is a software testing technique that divides the input
data of a software unit into partitions of equivalent data from
which test cases can be derived. In principle, test cases are
designed to cover each partition at least once.
Example:
Consider the program “square root” which takes a as an input
the range (100 - 1000) and prints the square root of a.
We may generate the following equivalence classes for the input domain:
I1 = {100<=a<=1000} (valid input range from 100 to 1000)
I2 = {a<100} (any invalid input where a is less than 100)
I3 = {a>1000} (any invalid input where a is more than 1000)

The corresponding test cases are:

Test Case Input a Expected Output
I1 500 22.36
I2 10 Invalid input
I3 1100 Invalid input

Test case of “square root” program for Input domain

The output domain is also partitioned to generate equivalence classes.
We generate the following output domain equivalence classes:
O1 = {Square root of input value a}
O2 = {Invalid value}
The corresponding test cases are:
Test Case Input a Expected Output
I1 500 22.36
I2 10 Invalid input
I3 1100 Invalid input
Test case of “square root” program for Output domain
Decision Table-Based Testing:
• Decision table testing is a software testing technique used to
test system behavior for different input combinations. This is a
systematic approach where the different input combinations
and their corresponding system behavior (Output) are captured
in a tabular form.
• There are 4 portions of the decision table.
There are two types of decision tables:
1. Limited Entry decision table – where input values
represent only true and false condition.
2. Extended Entry decision table – multiple conditions are
used instead of true and false conditions.
Structural Testing
 Structural Testing
• It is complementary to functional testing where the source
code is considered for the design of test cases rather than
specifications.
• It focus on the internal structure of the source code and ignore
the functionality of the program
• It also called white box testing
• Path testing is a popular structural technique
 Path Testing
• The source code of the program is converted into a program
graph which represents the flow of control in terms of directed
graphs
• The program is further converted into the decision to decision
path graph
• A program graph is a graphical representation of the source code
where statements of the program are represented by notes and
flow of control by edges
Basic constructs of a program graph
Program to determine whether a number is odd or even
Class Testing
 Class Testing
• A class is a fundamental entity in object oriented software
development activities.
• A class is treated as a unit which is similar to the module/function
of conventional programming
• During testing we may like to generate test cases on the basis of
structure of a class
• The most popular way to design test cases is from pre – and post
conditions as specified in the use cases
• Every operation of a class ma have pre and post conditions all
operation will be initiated only when a pre condition is true. After
the successful execution one or more post conditions to be
generated
• Every logical relationship will generate a test case
For example, consider a class “queue”
Mutation Testing
 Mutation Testing
• Mutation testing is a useful testing technique to determine the
effectiveness of an existing test suite of any program.
• Technique to verify the quality of the tests.
• Generally it is applicable at the unit level, but we can also apply
it at the system level without any difficulty.
Levels of Testing
Levels of Testing

ü Unit Testing
ü Component
Testing
ü Integration
Testing
ü System Testing
ü Acceptance
Testing
ü Alpha Testing
 Unit Testing

v Unit testing is a method by which individual units of

source code together with associated control data
are tested to determine if they are fit for use.

v A unit is the smallest testable part of an

application like functions/procedures, classes,
interfaces.

v Unit tests are typically written and run by software

developers to ensure that code meets its design and
behaves as intended.
 Component Testing

ü Component testing is also known as module and

program testing.
ü Component testing is the phase in which individual
software modules are tested to find defects in the
module and verifies the functioning of software
Module.
ü Component testing may be done in isolation from
rest of the system depending on the development
life cycle model chosen for that particular
application.
 Integration Testing

Ø Integration testing is the phase in which individual

software modules are combined and tested as a
group to make verify integrated system is ready
for system testing.

Ø It occurs after unit testing and before validation

testing.

Ø Integration testing is done by a specific integration

tester or test team.
 System Testing
ü System testing is conducted on a complete,
integrated system to evaluate the system's
compliance with its specified requirements.
ü System testing falls within the scope of black box
testing, and as such, should require no knowledge of
the inner design of the code or logic.
ü System testing is most often the final test to verify
that the system to be delivered meets the
specification and its purpose.
ü System testing should investigate both functional
and non- functional requirements of the testing.
 Acceptance Testing
Ø After the system test has corrected all or most
defects, the system will be delivered to the user or
customer for acceptance testing.

Ø Acceptance testing is a test conducted to determine if

the requirements of a specification or contract are
met prior to its delivery.

Ø Acceptance testing is basically done by the user or

customer although other stakeholders may be
involved as well.
 Alpha Testing

ü Alpha testing is simulated or actual operational testing

by potential users/customers or an independent test
team at the developers' site.
ü Alpha testing is often employed for off-the-shelf
software as a form of internal acceptance testing,
before the software goes to beta testing.
ü This test takes place at the developer’s site.
 Beta Testing
ü It is also known as field testing. It takes place at
customer’s site.
ü It sends the system to users who install it and use it
under real-world working conditions.
ü A beta test is the second phase of software testing in
which a sampling of the intended audience tries the
product out.
ü Versions of the software, known as beta versions, are
released to a limited audience outside of the
programming team.
Software Testing Tools
 Software Testing Tools data
• Help us to design and execute test cases, analyze the program
complexity, identify the non-coverage area of the source code
and ascertain the performance of the software.
• Software tools are very effective for repeated testing where
similar data set is to be given again and again.
• These tools may be partitioned into 3 categories:
1. Static
2. Dynamic
3. Process management
1.Static Testing Tools:
• Analyze the program without executing it.
• May calculate program complexity.
• The identified faults may range from logical faults to syntax
faults and may include non-declaration of a variable, double
declaration of a variable, divide by zero issue, unspecified
inputs, etc.
• Some popular tools are:
ü CMTJava (complexity measures tool for java)
ü Jenssoft’s Code Companion
ü Sun Microsystem’s JavaPureCheck
ü CMT++
2. Dynamic testing tools:
• It execute the programs for specified inputs.
• The observed output is compared with the expected output
and if they are different , the program is considered in a
failure condition.
• It is very effective to test the non – functional requirements
such as performance, reliability, efficiency and portability.
• Performance testing tools (also called stress and load testing)
ü Mercury Interactive’s Load Runner
ü Apache JMeter
ü Rational’s Performance Tester
ü Sun microsystem’s java load
• Functional/Regression Testing tools
ü Junit
ü Test Manager
ü Rational’s robot
ü Mercury Interactive’s Win Runner
• Coverage analysis tools
ü Rational’s Pure Coverage
ü Vision Soft’s
ü Quality Checked Software’s Cantata++
ü QC/Coverage
3. Process Management Tools
• It is to improve the testing processes
• Help us to allocate resources, prepare test plan and keep
track off the status of testing
• Some popular tools are:
ü IBM Rational Test Manager
ü Mercury Interactive’s Test Director
ü Segue Software’s Silk Plan pro
ü Compuware’s QA Director.
SOFTWARE MAINTENANCE
 INTRODUCTION
• Software maintenance is the last stage of s/w
life cycle .
• After the product has been released, the
maintenance phase keeps the s/w up to date
with environment changes & changing user
requirements.
• It consumes about 40-70% of the cost of the
entire life cycle.
• Maintenance can only happen efficiently if the
earlier phases are done properly.
Cost distribution of SDLC
 SOFTWARE AS AN EVOLUTIONARY ENTITY
• Software Maintenance includes error correction,
enhancements of capabilities, deletion of obsolete
capabilities & optimization.
• As changes cannot be avoided, we should
develop mechanism for evaluating, controlling &
making modifications.
• Hence any work done to change the s/w after its
operation is considered to be a maintenance
work.
• The term “evolution” has been used with
reference to s/w since 1960’s to signify the
growth dynamics of s/w.
WHAT IS SOFTWARE MAINTENANCE
 NEED FOR MAINTENANCE
• Software Maintenance is needed for:-
– Correct errors.
– Change in user requirement with time.
– Changing hardware/software environment.
– To improve system efficiency
– To optimize the code to run faster
– To modify the components.
– To eliminate any unwanted side effects.
Thus, the maintenance is needed to ensure
that the system continues to satisfy user
requirements.
 AIM of Software Maintenance
• To correct errors.
• To enhance the s/w by changing its functions.
• To update the s/w.
• To adapt the s/w to cope with changes in
the environment.
CATEGORIES OF SOFTWARE MAINTENANCE
4. Preventive maintenance:
It is the process by which we prevent our system from
being obsolete. It involves the concept of reengineering
& reverse engineering in which an old system with an
old technology is re-engineered using new technology.
This maintenance prevents the system from dying
out.
SOFTWARE MAINTENANCE

Fig: Distribution of
maintenance effort
 Challenges of Software Maintenance
• Often the program is written by
another person or group of persons.
• Often the program is changed by person who
did not understand it clearly.
• Program listings are not structured.
• High staff turnover.
• Information gap.
• Poor documentation and manuals.
• Inadequate budgetary provisions
• Emergency fixing of bugs (known as patching)
Potential Solutions to Maintenance Problems
• Budget and effort
reallocation
• Complete replacement of the
system
• Maintenance of existing
system
The Maintenance Process
• Program Understanding
The first phase consists of analyzing the
program in order to understand.

• Generating Particular Maintenance Proposal

The second phase consists of generating a
particular maintenance proposal to accomplish
the implementation of the maintenance
objective.

• Ripple Effect
The third phase consists of accounting for all of
the ripple effect as a consequence of program
modifications.
• Modified Program Testing
The fourth phase consists of testing the modified
program to ensure that the modified program has
at least the same reliability level as before.

• Maintainability
Each of these four phases and their associated
software quality attributes are critical to the
maintenance process. All of these factors must be
combined to form maintainability.
How easy is to maintain a program depends on
how easy is to understand it.
 COST OF MAINTENANCE
• To estimate maintenance cost, two models
have been proposed. They are:
1. Belady and Lehman model
2. Boehm model
 Belady and Lehman Model
This model indicates that the effort and cost can
increase exponentially if poor Software
development approach is used & the person or
group that used the approach is no longer available
to perform maintenance. The basic equation is
given by:
Where,
M : Total effort expended
P : Productive effort that involves analysis, design, coding, testing
and
evaluation.
K : An empirically determined constant.
c : Complexity measure due to lack of good design and
Boehm Model
 Maintenance of Object Oriented Software
§ One of the reasons of the popularity of object-oriented
paradigm is that such software products are easy to maintain
and help to reduce maintenance effort.
§ Inheritance and dynamic binding are two important
characteristics of OOSD. With all their great advantages (like
software reuse),these characteristics complicate the
operations and also reduce the understandability of the
program.
§ Poor understanding may further make the maintenance tasks
difficult and challenging.
 Regression Testing
• When the software is modified in the maintenance phase, it
requires retesting to assure its continued operation. This
process of retesting is known as regression testing.
• Regression testing is defined as the process of testing the
modified parts of the software and ensures that no new faults
have occurred in the previously developed source code due to
these modifications.
• Regression testing not only tests the modified part of the
software, but also checks the parts affected by the change.
• Regression testing is done to ensure that:
1. There are no faults in the other parts of the software due to
modifications.
2. Correctness of the software.
3. Quality and reliability of the software.
4. Confidence in the modified parts.
• Regression testing is not only a part of maintenance activity, it
may also be performed during the later stages of software
development life cycle.
• The process of regression testing is very costly and involves
the following steps:
1. Analysis of failure report
2. Debugging of the source code
3. Identification of faults in the source code
4. Source code modification (new and old programs will be
different)
5. Selection of test cases from existing test suite to ensure
the correctness of modifications
6. Addition of new test cases, if required
7. Performing retesting to ensure correctness using selected
test cases and new test cases, if any