UNIT -V

Implementation, Testing & Maintenance

 Top - Down, Bottom-Up, object oriented product
Implementation & Integration. Software Testing
methods-White Box, Basis Path-Control Structure
- Black Box - Unit Testing - Integration testing -
Validation & System testing - Testing Tools –
Software Maintenance & Reengineering.
Top - Down, Bottom-Up, object oriented product
Implementation & Integration

2
 Hierarchy of Testing
Testing

Ad Hoc Program Testing System Testing Acceptance

Testing
Unit Testing Integration Testing Function
Benchmark
Black Box Properties
Top Down
Performance Pilot
Equivalence
Bottom Up
Boundary Reliability Alpha
Big Bang
Decision Table Availability
Beta
State Transition Sandwich Security

Use Case Usability

Domain Analysis Documentation

White Box Portability

3

Control Flow Data Flow Capacity

 Outline
 Big bang
 Top-down
 Bottom-up
 Sandwich
 Regression

4
4
 In Class
 Suppose you have constructed and tested all of the
units.
 What are the possible things you can do next?

5
 Review: Test Procedures

Driver

Module to be
tested Results Test
cases

Stub Stub

6
 Integration Testing
 Assumes the units have been tested individually
 Tests units working together
 Identifies errors in the interfaces between units
 Approaches
Big bang
Top-down
Bottom-up
Sandwich

7
 Big-bang Integration
 Test all components in isolation, then mix them all
together and see how it works.
 As all components are merged at once, it is difficult
to identify the cause of a failure.

 Q: Need test drivers and stubs for big-bang

testing?

8
 Top-Down Integration Testing

 Modules are integrated by M1

moving downward
through control hierarchy.
M2 M3 M4
 Modules subordinate to
main control module are
incorporated
M5 M6 M7
Depth-first
Breadth-first
M8

Pairs: What get’s tested first in 9

breadth first?
 Top-Down Integration Testing

 In Top Down, Breadth M1

First
M1 tested with stubs for M2,
M3 and M4 M2 M3 M4

Then M1-M2 tested with stubs

for M3, M4, M5, and M6
Then M1-M2-M3 tested with M5 M6 M7
stubs for M4, M5, M6, and M7
…
M8

10
 Steps in Top-Down Integration
Testing

 The main module is used as a test driver

 Stubs are substituted for all components directly
subordinate to the main control module
 Stubs are replaced one at a time with actual
components
 Tests are conducted as each component is integrated.

11
 Evaluation of Top-Down Strategy
 Verifies major control or decision early in the test
process
 Allows early recognition of major problems
 Depth first strategy allows a complete function of
the software to be implemented
 Stubs replace lower-level modules so no significant
data can flow upward
Delay some tests until have actual modules
Add code to simulate module
12
 Bottom-Up Integration

 Low-level components are combined into clusters

 A driver is written to coordinate test case input
and output
 Cluster is tested
 Drivers are removed and clusters are combined
moving upward in program structure.

13
 Bottom Up Integration Testing

In Bottom Up: M1

M2 M3 M4

M5 M6 M7

M8

Pairs: What get’s 14

tested first?
 Bottom Up Integration Testing

In Bottom Up: M1
M8 tested with drivers
M5-M8 is tested with M2 M3 M4
drivers for M5
M5-M6-M8 is tested with
drivers for M5-M6 M5 M6 M7

…
M8

15
 Evaluation of Bottom-Up Strategy

 Need for stubs is eliminated

 Operational modules tested thoroughly
 Begins construction and testing with atomic
modules

16
 Sandwich Integration

 Combination of bottom-up and top-down integrations

 System is viewed as layers
 Approach 1:
Top-down approach is used for the top layer
A bottom-up approach is used for the bottom layer
Allows integration to begin early in the testing phase
Does not test individual components thoroughly before
integration

17
 Sandwich integration (Cont.)

 Approach 2:
Start with a layer in the middle
Use drivers to and stubs to check
Work out from middle
Allows integration to begin early in the testing phase
Does not test individual components thoroughly before
integration

18
 Regression Testing
 Adding new or changing module impacts the
system
New data flow paths established
New I/O may occur
New control logic invoked
 Regression testing is re-execution of subset of tests
that have already been conducted
Ensures changes have not propagated unintended side
effects

19
 Regression Test (Cont.)
 Approaches
Manual testing
Capture/Playback tools: capture test cases and results for
subsequent playback and comparison
 Test suite contains following classes of test cases:
Representative sample of tests that exercises all software
functions
Focus on functions likely affected by change
Focus on components that have been changed

20
 Testing Object-Oriented Applications

21
 Software Configuration Management

22
The “First Law”
No matter where you are in the system life cycle, the system will change, and the desire to change it will persist
throughout the life cycle.

Bersoff, et al, 1980

23
 What Are These Changes?
changes in
business requirements
changes in
technical requirements
changes in
user requirements other
documents

software models

Project
Plan
data
Test
code

24
 The Software Configuration

programs documents

The pieces
data

25
 Baselines
 The IEEE (IEEE Std. No. 610.12-1990) defines a
baseline as:
 A specification or product that has been formally reviewed and agreed
upon, that thereafter serves as the basis for further development, and
that can be changed only through formal change control procedures.

 a baseline is a milestone in the development of

software that is marked by the delivery of one or
more software configuration items and the
approval of these SCIs that is obtained through a
formal technical review

26
 Baselines
modified
SCIs
Project database
approved
Software Formal
engineering SCIs technical SCIs
tasks reviews

stored

SCIs

extracted
SCM
SCIs
controls

BASELINES :
System Specification
Software Requirements
Design Specification
Source Code
Test Plans/Procedures/Data
Operational System

27
Software Configuration Objects
Data model

Design specification

data design
architectural design
module design
interface design

Component N

interface description
algorithm description
Test specification PDL

test plan
test procedure
test cases

Source code

28
 SCM Repository
 The SCM repository is the set of mechanisms and
data structures that allow a software team to
manage change in an effective manner
 The repository performs or precipitates the
following functions [For89]:
Data integrity
Information sharing
Tool integration
Data integration
Methodology enforcement
Document standardization
29
 Repository Content
u se -case s
b u sin e ss ru le s an aly sis m o d e l so u rce co d e
b u sin e ss fu n ct io n s sce n ario -b ase d d iag ram s o b j e ct co d e
o rg an izat io n st ru ct u re flo w -o rie n t e d d iag ram s sy st e m b u ild in st ru ct io n s
in fo rm at io n arch it e ct u re class-b ase d d iag ram s
b e h av io ral d iag ram s Const ruct ion
d e sig n m o d e l
Cont ent
arch it e ct u ral d iag ram s
Business in t e rface d iag ram s
Cont ent co m p o n e n t -le v e l d iag ram s
t e ch n ical m e t rics t e st case s
t e st scrip t s
t e st re su lt s
q u alit y m e t rics
Model
Cont ent
V&V
Cont ent

Project
Management
p ro j e ct e st im at e s Cont ent
p ro j e ct sch e d u le
SCM re q u ire m e n t s
Pro j e ct Plan
ch an g e re q u e st s Document s SCM/ SQA Plan
ch an g e re p o rt s
Sy st e m Sp e c
SQA re q u ire m e n t s
Re q u ire m e n t s Sp e c
p ro j e ct re p o rt s/ au d it re p o rt s
De sig n Do cu m e n t
p ro j e ct m e t rics
Te st Plan an d Pro ce d u re
Su p p o rt d o cu m e n t s
Use r m an u al

30
 Repository Features
 Versioning.
saves all of these versions to enable effective management of product releases and to
permit developers to go back to previous versions
 Dependency tracking and change management.
The repository manages a wide variety of relationships among the data elements stored
in it.
 Requirements tracing.
Provides the ability to track all the design and construction components and
deliverables that result from a specific requirement specification
 Configuration management.
Keeps track of a series of configurations representing specific project milestones or
production releases. Version management provides the needed versions, and link
management keeps track of interdependencies.
 Audit trails.
establishes additional information about when, why, and by whom changes are made.

31
 SCM Elements
 Component elements—a set of tools coupled within a file management system
(e.g., a database) that enables access to and management of each software
configuration item.
 Process elements—a collection of procedures and tasks that define an effective
approach to change management (and related activities) for all constituencies
involved in the management, engineering and use of computer software.
 Construction elements—a set of tools that automate the construction of software
by ensuring that the proper set of validated components (i.e., the correct
version) have been assembled.
 Human elements—to implement effective SCM, the software team uses a set of
tools and process features (encompassing other CM elements)

32
 The SCM Process
Addresses the following questions …

 How does a software team identify the discrete elements of a

software configuration?
 How does an organization manage the many existing versions of a
program (and its documentation) in a manner that will enable
change to be accommodated efficiently?
 How does an organization control changes before and after
software is released to a customer?
 Who has responsibility for approving and ranking changes?
 How can we ensure that changes have been made properly?
 What mechanism is used to appraise others of changes that are
made?

33
 The SCM Process
Software
Vm.n

reporting

configuration auditing

version control

change control

identification

SCIs

34
 Version Control
 Version control combines procedures and tools to manage different
versions of configuration objects that are created during the
software process
 A version control system implements or is directly integrated with
four major capabilities:
a project database (repository) that stores all relevant configuration objects
a version management capability that stores all versions of a configuration
object (or enables any version to be constructed using differences from
past versions);
a make facility that enables the software engineer to collect all relevant
configuration objects and construct a specific version of the software.
an issues tracking (also called bug tracking) capability that enables the team
to record and track the status of all outstanding issues associated with
each configuration object.

35
Change Control

STOP

36
 Change Control Process—I
need for change is recognized

change request from user

developer evaluates

change report is generated

change control authority decides

request is queued for action

change request is denied
user is informed
change control process—II
37
 Change Control Process-II
assign people to SCIs

check-out SCIs

make the change

review/audit the change

establish a “baseline” for testing

change control process—III

38
 Change Control Process-III
perform SQA and testing activities

check-in the changed SCIs

promote SCI for inclusion in next release

rebuild appropriate version

review/audit the change

include all changes in release

39
 Auditing

Change
Requests
SQA
Plan

SCIs

SCM Audit

40
 Status Accounting
Change
Change Reports
Requests
ECOs

SCIs

Status Accounting

Reporting
41
 SCM for Web Engineering-I
 Content.
A typical WebApp contains a vast array of content—text, graphics, applets,
scripts, audio/video files, forms, active page elements, tables, streaming
data, and many others.
The challenge is to organize this sea of content into a rational set of
configuration objects (Section 27.1.4) and then establish appropriate
configuration control mechanisms for these objects.
 People.
Because a significant percentage of WebApp development continues to be
conducted in an ad hoc manner, any person involved in the WebApp can
(and often does) create content.

42
 SCM for Web Engineering-II
 Scalability.
As size and complexity grow, small changes can have far-reaching and
unintended affects that can be problematic. Therefore, the rigor of
configuration control mechanisms should be directly proportional to
application scale.
 Politics.
Who ‘owns’ a WebApp?
Who assumes responsibility for the accuracy of the information on the Web
site?
Who assures that quality control processes have been followed before
information is published to the site?
Who is responsible for making changes?
Who assumes the cost of change?

43
 Content Management-I

 The collection subsystem encompasses all actions required to create

and/or acquire content, and the technical functions that are
necessary to
convert content into a form that can be represented by a mark-up language
(e.g., HTML, XML
organize content into packets that can be displayed effectively on the client-
side.
 The management subsystem implements a repository that
encompasses the following elements:
Content database—the information structure that has been established to
store all content objects
Database capabilities—functions that enable the CMS to search for specific
content objects (or categories of objects), store and retrieve objects, and
manage the file structure that has been established for the content
Configuration management functions—the functional elements and associated
workflow that support content object identification, version control,
change management, change auditing, and reporting.

44
 Content Management-II

 The publishing subsystem extracts from the repository, converts it

to a form that is amenable to publication, and formats it so that it
can be transmitted to client-side browsers. The publishing
subsystem accomplishes these tasks using a series of templates.
 Each template is a function that builds a publication using one of
three different components [BOI02]:
Static elements—text, graphics, media, and scripts that require no further
processing are transmitted directly to the client-side
Publication services—function calls to specific retrieval and formatting
services that personalize content (using predefined rules), perform
data conversion, and build appropriate navigation links.
External services—provide access to external corporate information
infrastructure such as enterprise data or “back-room” applications.

45
 Content Management

conf igurat ion object s

dat abase Cont ent

Management
Syst em

t emplat es

HTML code client -side browser

+ script s

server-side
46
Change Management for WebApps-I

classify t he
request ed change

class 1 change class 4 change

class 2 change class 3 change

dev elop brief writ t en dev elop brief writ t en

acquire relat ed object s
assess impact of change descript ion of change descript ion of change

t ransmit t o all t eam t ransmit t o all st ake-

members for rev iew holders for rev iew
changes
required
in relat ed
object s

furt her furt her

ev aluat ion ev aluat ion
is required OK t o make is required OK t o make

47
Change Management for WebApps-II

check out object ( s)

t o be changed

make changes
design, const ruct , t est

check in object ( s)
t hat were changed

publish t o WebA pp

48
 OO Testing
 To adequately test OO systems, three things
must be done:
the definition of testing must be broadened to
include error discovery techniques applied to
object-oriented analysis and design models
the strategy for unit and integration testing must
change significantly, and
the design of test cases must account for the unique
characteristics of OO software.

49
 ‘Testing’ OO Models
 The review of OO analysis and design models
is especially useful because the same
semantic constructs (e.g., classes, attributes,
operations, messages) appear at the
analysis, design, and code level
 Therefore, a problem in the definition of class
attributes that is uncovered during analysis
will circumvent side affects that might occur
if the problem were not discovered until
design or code (or even the next iteration of
analysis).
50
 Correctness of OO Models
During analysis and design, semantic correctness can be
asesssed based on the model’s conformance to the real world
problem domain.
 If the model accurately reflects the real world (to a level of detail
that is appropriate to the stage of development at which the
model is reviewed) then it is semantically correct.
 To determine whether the model does, in fact, reflect real world
requirements, it should be presented to problem domain
experts who will examine the class definitions and hierarchy for
omissions and ambiguity.
 Class relationships (instance connections) are evaluated to
determine whether they accurately reflect real-world object
connections.

51
 Class Model Consistency
 Revisit the CRC model and the object-relationship model.
 Inspect the description of each CRC index card to determine if a
delegated responsibility is part of the collaborator’s definition.
 Invert the connection to ensure that each collaborator that is
asked for service is receiving requests from a reasonable
source.
 Using the inverted connections examined in the preceding step,
determine whether other classes might be required or whether
responsibilities are properly grouped among the classes.
 Determine whether widely requested responsibilities might be
combined into a single responsibility.

52
 OO Testing Strategies
 Unit testing
the concept of the unit changes
the smallest testable unit is the encapsulated class
a single operation can no longer be tested in isolation (the
conventional view of unit testing) but rather, as part of a class
 Integration Testing
Thread-based testing integrates the set of classes required to respond to one
input or event for the system
Use-based testing begins the construction of the system by testing those
classes (called independent classes) that use very few (if any) of server
classes. After the independent classes are tested, the next layer of classes,
called dependent classes
Cluster testing [McG94] defines a cluster of collaborating classes (determined
by examining the CRC and object-relationship model) is exercised by
designing test cases that attempt to uncover errors in the collaborations.

53
 OO Testing Strategies
 Validation Testing
details of class connections disappear
draw upon use cases (Chapters 5 and 6) that are
part of the requirements model
Conventional black-box testing methods (Chapter
18) can be used to drive validation tests

54
OOT Methods
Berard [Ber93] proposes the following approach:

1. Each test case should be uniquely identified and should be explicitly

associated with the class to be tested,
2. The purpose of the test should be stated,
3. A list of testing steps should be developed for each test and should
contain [BER94]:
a. a list of specified states for the object that is to be tested
b. a list of messages and operations that will be exercised as
a consequence of the test
c. a list of exceptions that may occur as the object is tested
d. a list of external conditions (i.e., changes in the environment
external to the software that must exist in order to properly
conduct the test)
e. supplementary information that will aid in understanding or
implementing the test.

55
 Fault-based testing Testing Methods
The tester looks for plausible faults (i.e., aspects of the implementation of the system
that may result in defects). To determine whether these faults exist, test cases are
designed to exercise the design or code.
 Class Testing and the Class Hierarchy
Inheritance does not obviate the need for thorough testing of all derived classes. In fact,
it can actually complicate the testing process.
 Scenario-Based Test Design
Scenario-based testing concentrates on what the user does, not what the product does.
This means capturing the tasks (via use-cases) that the user has to perform, then
applying them and their variants as tests.

56
 OOT Methods: Random Testing
 Random testing
identify operations applicable to a class
define constraints on their use
identify a minimum test sequence
 an operation sequence that defines the minimum life history of
the class (object)

generate a variety of random (but valid) test

sequences
 exercise other (more complex) class instance life histories

57
 OOT Methods: Partition Testing
 Partition Testing
reduces the number of test cases required to test a class in much the
same way as equivalence partitioning for conventional software
state-based partitioning
 categorize and test operations based on their ability to change the state
of a class
attribute-based partitioning
 categorize and test operations based on the attributes that they use
category-based partitioning
 categorize and test operations based on the generic function each
performs

58
OOT Methods: Inter-Class Testing
 Inter-class testing
For each client class, use the list of class operators to generate a
series of random test sequences. The operators will send
messages to other server classes.
For each message that is generated, determine the collaborator
class and the corresponding operator in the server object.
For each operator in the server object (that has been invoked by
messages sent from the client object), determine the messages
that it transmits.
For each of the messages, determine the next level of operators
that are invoked and incorporate these into the test sequence

59
 OOT Methods: Behavior Testing
The tests to be empty set up
acct acct
designed should open setup Accnt

achieve all state

deposit
coverage [KIR94]. (initial)
That is, the deposit
operation
sequences should working
acct
cause the Account balance
credit withdraw
class to make accntInfo
transition through withdrawal
all allowable states (final)

dead nonworking
acct close acct

Figure 1 4 .3 St at e diagram f or A ccount class ( adapt ed f rom [ KIR9 4 ] )

60