Software Testing Fundamentals

Testing present an interesting anomaly for Software engineer

In software engineering activities, the engineer attempts to build
software from abstract concept to tangible product
In case of testing the tester creates a series of test case that are
intended to demolish the software that has been built
Considering all above aspect testing can be termed as destructive step
rather than constructive
Testing Objective :
The three basic testing objective can be specified as follows
1) Testing is process of executing a program with an intend of finding
error
2) A good test case is one which has high probability of finding an as yet
undiscovered error
3) A successful test case is one that uncovers an as-yet-undiscovered error
 Software Testing principle
All test should be traceable to customer requirements: it follows
that the most severe defects are those that cause the program to
fail to meet it requirements
Test should be planned long before testing begins
Test planning should start as soon as design model has been
created
Testing should begin in “small” and progress toward testing in the
“large”
The first test planned and executed generally focus on individual
components. As testing progress focus is shifted to integrated
cluster
Exhaustive testing is not possible
To be most effective testing should be done by an independent
third party
 Software Testability
A software engineer design a computer program, a system or
product with “testability” in mind

Software testability is simply how easily a computer program can be

tested. Since testing is so profoundly difficult, it pays to know what
can be done to streamline it

The checklist that follows provide a set of characteristic that lead to

testable software. It is listed as follows

Operability:” The better it works the more efficiently it can be tested”

The system has few bugs
No bugs block execution of tests
The product evolves in functional stages
 Software Testability continued…..
Observability: “ What you see is what you test”
Distinct output is generated for each input
System state and variables are visible or queriable during execution
Past System state and variables are visible or queriable during
execution
All fact affecting the output are visible
Internal error are automatically detected through self testing
mechanism
Internal error are automatically detected
Source code is accessible

Controllability: “ The better we can control the software, the more the
testing can be automated and optimize”
All possible output can be generated through some combination of
input
All code is executable through some combination of input
 Software Testability continued…..
Software and hardware state and variables can be controlled directly by
the test engineer
Input and output format are consistent and structured
Tests can be conveniently specified, automated and reproduce.

Decomposability: “ By controlling the scope of Testing, we can more

quickly isolate problem and perform smarter retesting”
Software system is developed from independent module
Software module can be tested independently

Simplicity: “The less there is to test, the more quickly we can test it”
Functional simplicity (minimum requirement)
Structural simplicity (architecture is modularized to limit propagation of

fault)
Code Simplicity (a coding standard is adopted for ease of inspection and
maintenance)
 Software Testability continued…..
Stability: “ The fewer the changes ,the Fewer the disruption to testing”
Changes to software are infrequent
Changes to software are controlled
Change to software do not invalidate existing tests
The software recovers well from failures

Understandability:” The more Information we have the smarter we will test”

Design is well understood
Dependencies between internal and external and shared component is
understood
Changes to design are communicated
Technical documentation is well organized and instantly accessible
Technical documentation is accurate
 Attribute of Good test

A good test has high probability of finding error

A good test is not redundant (repetition)

A good test should be “best of breed”

A good test case should be neither too complex nor too

simple
 Test Case Design
A rich variety of test case design method has evolved for software.
These method provide the developer with systematic approach to
testing
Any engineered product can be tested in two ways
1) Knowing the specified function that a product has been designed to
perform, test can be conducted that demonstrate each function is fully
operational while at same time searching for error in each function

2) Knowing internal workings of the product test can be conducted to ensure

that internal operation are performed accurately according to specification
and all internal components have been adequately exercised

The first approach is termed as “Black-Box testing”

The second approach is termed as “ White-Box testing”
 White Box Testing
It is sometime termed as glass box testing, is a test case design
method that uses the control structure of procedural design to derive
test cases
Using this approach the software engineer can derive test case that
1) Guarantee that all independent path within a module have been
exercised at least once
2) Exercise all logical decision on their true and false sides
3) Execute all loops at their boundaries and within operational bound
4) Exercise internal data structure to ensure their validity
Following methods are available in white box (B G D C L)
Basis path testing
Graph matrices
Condition testing
Data flow testing
Loop testing
 Basis Path Testing
Basis path testing is white box testing technique proposed by Tom
Mccabe.
It enables the test case designers to derive a logical complexity
measure of procedural design and use this measure as a guide for
defining a basis set of execution paths
In this method the flow graph method is used to depict logical control
flow using the notation as follows

While until

Sequence

If Statement

Case
 Flow Graph Notation and Cyclomatic
Complexity

33

6 4
4

7 88
5
9
10

11
 Flow Graph Notation and Cyclomatic
Complexity

2,3

6 4,5 node
R2
7 R3 8 R1
9
10

Edges R4
11
 Flow Graph Notation and Cyclomatic
Complexity
Cyclomatic complexity is software metrics that provide a quantitative
measure of the logical complexity of program
When used in the context of the basis path method ,the value computed
defines the number of independent path in basis set of the program and
provides us with an upper bound for the number of test that must be
conducted to ensure that all statement have been executed at least
once
An independent path is any path through the program that introduce at
least one new set of processing statement or new condition
For previous flow graph following are different independent path
Path1 : 1—11
Path2: 1—2—3— 4 – 5 – 10 – 1 – 11
Path3 : 1 – 2 – 3 – 6 – 8 – 9 – 10 – 1 – 11
Path 4: 1 – 2 – 3 – 6 – 7 – 9 – 10 – 1 – 11
Each path introduce a new edge
 Flow Graph Notation and Cyclomatic
How do we know Complexity
how many paths to look for?. The
computation of cyclomatic complexity provide the answer
Complexity is computed in any one of following ways

1. The number of region of the flow graph correspond to

cyclomatic complexity

2. Cyclomatic complexity , V(G), for flow graph G is defined

as
V(G) =E – N + 2
where E is number of Edges, n is nodes

3. Cyclomatic complexity V(G), for flow graph G is defined

as
V(G) = P + 1
 Deriving Test Cases
This method can be applied to procedural language
The following steps can be applied to derive the basis set
1. Using the design or code as a foundation ,draw a
corresponding flow graph.

2. Determine cyclomatic complexity from the flow graph

using any one three methods specified for same

3. Determine a basis set of linearly independent paths. The

value of V(G) provides number of linearly independent
path through the program control structure
4. Prepare test case that will force execution of each path
in basis set. Data should be chosen so that condition at
predicate node are appropriately set as each path is
tested
 Graph Matrices
To develop a software tool that assist in basis paths testing ,
a data structure called graph matrices method is used
A graph matrix is square matrices whose size is equal to
number of nodes on the flow graph
Each row and column correspond to an identified node and
matrix entries correspond to connection between node.
Following diagram and matrices represent same
1 2 3 4 5
1
a 1 a
e
3 2
f b
5 3 d b
4 d
g
4 c F
2
5 g e
 Graph Matrices Continued…
Till this point matrix is nothing more then tabular
representation of flowchart. But adding link weight to each
matrix entry the graph matrix will become powerful tool for
evaluating program control structure during testing
The link weight can be assigned following values

Probability that link will be executed

Processing time expended during traversal of link

Memory required during traversal of link

Resource required during traversal of link

 Control Structure Testing
Control structure testing broadens coverage and improve quality of white box
testing. There are three type of testing
Condition testing
Data flow testing
Loop testing

Condition Testing
Condition testing is a test case design method that exercise the logical
condition contained in program module
A simple condition is a Boolean variable or a relational expression ,possibly
preceded with not operator. A relational operator may takes the form
E1 <relational-operator> E2
E1 and E2 are arithmetic Expression and <relational operator > is on of
following :<, <=,>,>=,=, !=
A compound statement is composed of two or more simple conditions, Boolean
operator and parenthesis
A condition without relation expression is referred to as Boolean Expression
 Condition Testing Continued……
If a condition is incorrect, then at least one component of the condition is
incorrect. Therefore types of errors in condition include following

Boolean operator error (incorrect/missing/extra Boolean operators)

Boolean variable error
Boolean parenthesis error
Relational operator error
Arithmetic expression error
Condition testing focuses on testing each condition in program
A number of condition testing strategies have been proposed

Branch testing is probably the simplest condition test strategy. For

compound condition c , “the true and false branches of c and every
simple condition in c need to be executed at least once.”
 Condition Testing Continued……
BRO (branch and relational operator) testing the technique guarantees
the detection of branch and relational operator error in condition
provided that all Boolean variables and relational operator in condition
occur only once and have no common variables
BRO strategy uses condition constraint for condition C and defined as
(D1,D2,D3….Dn) where Di(0<i<n)
A condition constrain D for condition C is said to be covered by execution
of C if during the Execution of C outcome of each simple condition
satisfies constraint D
C1: B1 && B2
The condition Constraint will be (D1,D2) where Each of D1,D2 is t or f
The BRO strategy require the constraint set { (t, t) ( t, f) ( f, t) ( f, f)} to
be covered by execution of C1
If C1 is incorrect due to one or more Boolean operator errors at least
one of the constraint set will force C1 to fail
 Data Flow Testing
The data flow testing method select tests path of a program
according to location of definition and uses of variable in
program
To illustrate this technique assume that each statement in
program is assigned a unique statement number and each
function does not modify its parameter or global variables
For a statement with S as its statement numbers,
DEF(S)= {X| statement S contains a definition of X }
USES(S)= {X | statement S Contain use of X}
If the statement S is a loop or if statement, its DEF set is
Empty and USE set is based on condition of statement
A Definition –use (DU) chain of variables X is of the form
[X,S,S’] where S and S’ are statement numbers ,X is in
DEF(S) and USES(S’) and definition of X in statement is live
at statement S’
 Loop Testing
Loop testing is white box testing method that focuses exclusively on
validity of loop construct. Four different types of loop are their
1) Simple Loop:

•Following steps are followed for Simple loop

•Skip the loop entirely
•Only one pass through the loop
•Two passes through the loop
• m passes through the loop where m<n
• n-1, n+1, n passes through the Loop
 Nested Loops
For nested loops following steps are followed

Start at innermost loop. Set all other loops to

minimum values

Conduct simple loop tests for innermost loop

while holding the outer loop at their minimum
iteration parameter values. Add other test for out
of range or excluded values

Work outward conducting test for next loop but

keeping all other outer loops at minimum values
and other nested loop tom typical values

Continue until all loops have been tested

 Concatenated Loops
Concatenated loops can be
tested using the approach
defined for simple loops, if
each loop is independent
of other
If two loops are
concatenated and loop
counter for loop1 is as
initial value for loop2 then
the loops are not
independent
When loops are not
independent the approach
applied to nested loop is
recommended
 Unstructured loop
Whenever possible this class of
loop should be redesigned to
reflect the use of structured
programming construct
 Black Box Testing
Black box testing is also termed as behavioral testing focuses on
functional requirement of software
It enables software engineer to derive set of inputs condition that will
fully exercise all functional requirement for a program
It attempts to find error in following categories
1) Incorrect or missing function
2) Interface error
3) Error in Data structure or external Database access
4) Initialization and Termination error
Test are designed to answer following question
How is functional validity tested?
How is system behavior and performance tested?
What class of input will make good test case?
Is the system sensitive to particular data?
What data rate and volume system can tolerate?
How are boundaries of data class isolated?
The first step in black box testing is to understand the
objects that are modeled in software and relationship that
connect these objects
Once this has been accomplished the next step is to define a
series of test that verifies “all objects have the expected
relationship one another”
Software testing begins by creating a graph of important
objects and their relationship and then devising a series of
tests that will cover the graph so that each object and
relationship is exercised and errors are uncovered
A graph is designed which is collection of nodes that
represent object
Link that represent the relationship between objects node
weight describe the properties of node and link weight
describe some characteristic of link
Following example depicts same aspect
Graph-Based Testing Methods continued…..
Directed link Object#2
Object#1 Node
weight

Undirected link
Parallel link

Object#3

New file menu Menu Select generates

Document
select
{generation time<1.0sec} Window

Allows editing of
Is Represented as

Contains

Document
Text
 Graph-Based Testing Methods continued…..
Bezier describe number of behavioral testing methods that can make
use of graphs

Transaction flow modeling: the node represent some transaction and

link represent the logical connection between steps

Finite state Machine: The node represent different user observable

states in software and link represent transition that occur to move from
state to state

Data flow Modeling: The nodes are data objects and link are their
transformation that occur to translate one data object to other

Timing model: The nodes are program objects and link are sequential
connection between those objects

All objects are tested for transitive, symmetric and reflexive properties
 Equivalence Partitioning
It is black box testing method that divides the input domain of
program into classes of data from which test case can be
designed
It strive to define a test case that uncover classes of errors
thereby reducing the number of test case that must be developed
Test case designed is based on evaluation of equivalence classes
from an input condition
An Equivalence class represent a set of valid or invalid state for
input condition
They are defined according to following guidelines
1) If input condition specifies a range one valid and two invalid
equivalence classes are defined
2) If an input condition require a specific value one valid and two
invalid classes are defined
3) If input specifies a set then one valid and one invalid equivalence
class is defined
4) If an input is Boolean then one valid and one invalid equivalence
class is defined
 Equivalence Partitioning continued……
Applying guideline for the derivation of equivalences classes test
cases for each input domain data item can be developed and
executed
Consider a banking application in which following input is requires:
area code, prefix, password, command
Following equivalence classes can be formed
Area code: input condition Boolean area code may or may not exists
Input condition range: value defined in particular range
Prefix : input condition range values >200
Input condition value – four digit value
Password : Input condition Boolean, may or may not be present
input condition value – six character string
Command : input condition set – containing command noted
 Boundary Value Analysis
A greater number of error occur at the boundaries of input domain
rather than at the “centre”
Boundary value analysis is a test case design technique that
complements equivalence partitioning. Rather than focusing on input
condition BVA derives test cases from output domain as well
Following step are followed
1) If an input condition specifies a range bounded by values a and b
test case should be designed with values of a and b and just above
a and b and just below a and b
2) If the input condition specifies a number of values test case should
be designed that exercise the minimum and maximum numbers.
Values just above and below the maximum and minimum vales are
also to be tested
3) Apply guideline 1 and 2 to output condition
4) If internal data structures have prescribed boundaries be certain to
design test case to exercise the data structure at its boundary
 Orthogonal array testing
There are many application in which the input domain is
relatively limited. The number of input parameter is
small and value each parameter may take are clearly
bounded
It is possible to consider every input permutation and
exhaustively test processing of the input domain
However as the number of input values grow and the
number of discrete value for each data item increase
exhaustive testing become impossible
Orthogonal array testing can be applied to problem in
which input domain is relatively small but too large to
accommodate exhaustive testing
This method is useful in finding error associated with
region faults an error category associated with faulty
logic within software component
 Testing for Specialized Environment
Architectures and Application
This Include following
Testing GUI’s

Testing for Client/Server Architeture

Testing Documentation and Help Facilities

It include two type as defined

Review and inspect
Live test

Testing for Real time System

 Software testing Strategies
There are testing strategies which start from small modules
and move towards formation of entire system

It first step is Unit testing which focuses on single

module/program in the entire system

The second form is integrating the single tested

module/program to form a system while checking for error

Then the third step is to validate the system obtained from

previous step and also check for errors

The last step is to check for system security when the

software is integrated with hardware and people
 Unit Testing Consideration
Unit testing focuses verification effort on smallest unit of software design
the software component or module
Using component level design description as a guide important control
paths are tested to uncover error within boundary of the module

Module Interface
Local data structure
~~~~~
Boundary condition
~~~~~
Independent Paths
~~~~~ Error handling Paths

Test
Cases
 Unit Testing Consideration continued…..
The module interface is tested to ensure that information properly flows
into and out of program unit under test

The local data structure is examined to ensure that data stored

temporarily maintains it integrity during all step in an algorithm
execution

Boundary condition are tested to ensure that module operates properly

at boundaries established to limit or restrict processing

All independent path through the control structure are exercised to

ensure that all statement in module have been executed at least once

And finally all error handling path are tested

All above things are checked for unit testing but they are following one
particular sequence
 Unit Testing Consideration continued…..
Data flow across a module interface are required before any test is
initiated . If data do not enter and exit properly all other test are moot
Selective testing of execution path is an essential task during unit
testing. This test should be designed to uncover erroneous computation
Basis path testing are effective techniques for uncovering a broad array
of path error
Test case should uncover error such as
1) Comparisons of data types 2) incorrect logical operators
3) Expectation of equality when precision error makes equality unlikely
4) Incorrect comparison of variables
5) Improper or nonexistent of loop termination
6) Failure to exit when divergent iteration is encountered
7) Improperly modified loop variables
Boundary testing is the last task of unit test step since software often
occur at its boundaries
 Unit Testing Procedures
Since a component is not a stand alone program driver and/or stub
software must be developed for each unit test
A driver is nothing more than a main program that accepts test case
data passes such data to the component (to be tested) and prints
relevant result
Stubs serve to replace modules that are subordinate to the component
to be tested. It represent dummy program use the subordinate module
interface may do minimal data manipulation print verification of entry
and return control to module undergoing testing

Driver
Interface
Local data structure
Module to Boundary condition
be Independent Paths
tested Error handling Paths

Stubs Stubs Test

Results case
 Integration Testing
Integration testing is a systematic approach for constructing the
program structure while at the same time conducting test to
uncover errors associated with interfacing
There are two different approach as stated
 Top-Down Integration:
 It is an incremental approach to construction of program
structure. Modules are integrated by moving downwards through
the control hierarchy beginning with main control module
 Module subordinate to the main control are incorporated into
structure in either a depth-first or breadth- first search

M1

M2 M3 M4

M5 M6
M7
 Integration Testing continued……
Depth first integration would integrate all components vertically
Breadth first will integrate all components directly subordinate at
each level moving across structure horizontally
The integration process is performed as follows

The main control module is used as test driver and stubs are
substituted for all components directly subordinate to main control
module
Depending on integration approach selected subordinate stubs are
replaced one at time with actual components
Test are conducted as each component is integrated
On completion of each set of tests another stub is replaced with
real world component
Regression testing may be conducted to ensure that new error have
not introduce
 Integration Testing continued…
 Top down integration verifies major control decision in test
process
 Decision making occur at upper level in hierarchy and is
therefore encountered first
 If depth first search is selected a complete function of
software may be implemented and demonstrated
 There are certain problem associated with this approach like
stubs replace lower level module at the beginning of this
method therefore no significant data can flow upward in
program structure
 The tester is left with three approach

Delay many test until stub are replaced by actual modules

Develop stub that perform limited function that simulate
actual model
Integrate the software from bottom of hierarchy to upward
 Bottom-Up Integration
As it name implies begins construction and testing with
atomic module (i.e components at the lowest level in the
program structure)
Because components are integrated from bottom up
processing required for components subordinate to given
level is always available and no need of stubs
It is implemented by following steps
Low level components are integrated into cluster that
perform software specific function
A driver is written to coordinate test case input and
output
The cluster is tested
Drivers are removed and cluster are combined moving
upward in program structure
 Regression Testing
Each time a new module is added as part of integration the
software changes. New data flow are established, new I/O may
occur and new control logic may be invoked
These changes may cause problem with function that previously
worked flawless
Regression testing is the re-execution of some subset of test that
have already been conducted to ensure change have not
propagated unintended side effects
Regression testing may be conducted manually by re-executing a
subset of all test cases
The other way is using automated capture/playback tool. It enables
the software engineer to capture test case and result for
subsequent playback and comparison
It basically checks following 1)representative sample of tests that
will exercise all software function 2) software function that are likely
to be affected 3) test focuses on software component that have
been changed
 Smoke Testing
Smoke testing is applied to software which are time critical
It allow software team to asses its project on a frequent basis
It has following activities

Software components that have been translated into code are

integrated into a “ build ”. A build include all data files , libraries,
reusable module and engineered components that requires to
implement one or more product function

A series of test is designed to expose errors that will keep the build
from performing properly its function

The build is integrated with other builds and entire product is smoke
tested daily. Integration approach may be top down or bottom up
 Validation testing and System testing
It has following criteria for following
Validation test criteria
Configuration review
Alpha and Beta Testing

System Testing : It has following testing to be performed

Recovery testing
It does testing of how fault tolerant system? For this it
will check whether it is done manually or automated
If automated it will check reinitialization check point
mechanism data recovery and restart are evaluated for
correctness
If it is manual mean-time-to-repair is evaluated to
determine whether it is within acceptable limit
 Security testing and Stress testing
Security testing start with developer thinking in terms of hacker and
trying to seek out different penetration point in the system
Once such point are found the tester design the test case to check no
one penetrates system from that point
STRESS TESTING
It executes a system in manner that demands resource in abnormal
quantity frequency or volume
For example 1)ten interrupt when system can handle 2 interrupt per sec
2) increase input data rate as compared to what system can handle
3) maximum memory or resource requirement
4) thrashing in virtual memory of operating system
This testing attempts to uncover data combination within valid input
classes that may cause instability and improper processing
 Performance testing and art of debugging
Performance testing is performed at each stage whenever other test are
performed
Art of debugging deals with how test case are used for checking the
software
It has following three type
Brute force
Backtracking
Cause elimination
 Broadening The view of testing
The construction of object oriented software begins with
creation of analysis and design Model
These model are relatively informal representation of
system requirement and evolve into detailed model of
classes , class connection and relationships, system
design and allocation and object design
At each stage the model can be tested in an attempt to
uncover errors prior to their propagation to next
Iteration
The review of OO analysis and design model is especially
useful because the same semantics constructs appear at
analysis design and code level
Consider an Example in which mistake is done initially in
analysis phase ,and if not detected how extra effort will
be done as it propagates to other phases
 Error in analysis Phase
Consider a class in which number of attribute are defined during
first phase of analysis
An Extraneous attribute is appended due to wrong interpretation
and two function are added to manipulate that attribute
If the model is shown to particular Domain expert errors can be
detected, but suppose errors are not detected what will happens.
1) Special subclasses may have generated to accommodate
the unnecessary attribute or exception to do it
2) A misinterpretation of class Definition may lead to
incorrect or extraneous class description
3) The behavior of system or it classes may be improperly
Characterized to accommodate Extraneous attribute
 Error propagated to Design
Following error will propagate in design phase
1) Improper allocation of Classes to subsystem and/or
tasks may occur during these phase

2) Unnecessary design work may be expended to

create
the procedural design for operation that address
extraneous attribute

3) The messaging Model will be incorrect

If error remained undetected during design and passes

to code activity more effort will be expended to generate
code, in addition testing will absorb more time
 Testing OOA and OOD Model
Analysis and design model cannot be tested in conventional
sense ,because they cannot be executed
The different step for testing are as follows

1) Correctness of OOA and OOD Models

1.1) The notation and syntax used to represent analysis and
design model will be tied to specific analysis and design
method that is chosen for product
1.2) Syntactic correctness is judged on proper use of
symbology each model is reviewed for correct symbolic
notation
1.3) Semantic correctness can be judged based on model
conformance to real world domain. If model accurately
reflect the real world then it is semantically correct
 Consistency of OOA and OOD Models
An inconsistent model has representation in one part
that are not reflected in other portion of Model
To access consistency CRC (class-responsibility-
collaborator) card is used .It is represented as follows

The card consist of class name , its responsibility (operations) and its
collaborators (other classes to which it sends message and on which it depends
for accomplishment for its responsibilities
Evaluating consistency of Class Model using
CRC
To evaluate the class model following step recommended
1) Revisit the CRC model and object relationship model. Cross check to
ensure that all collaboration implied by the OOA model are properly
Represented
2) Inspect the description of each CRC index card to determine if
delegated responsibility is part of collaboration definition
3) Invert the connection to ensure that each collaborator that is asked
for services is receiving request from a reasonable source
4) Using the inverted connection examined in step 3, determine
whether other classes might be required and whether responsibility
are properly grouped among the classes
5) Determine whether widely requested responsibility might be
combined into single responsibilities
6) Step 1 through 5 are applied iteratively to each model
 Evaluating consistency of Class Model
contd…
Once OOD model is created review of system design and object
design has to be conducted

In system design the overall product architecture, subsystem that

compose product ,the manner in which subsystem are allocated to
processors, the allocation of classes to subsystem and the design of
user interface has to be tested

The object model should be tested against the object relationship

network to insure that all design objects contain the necessary
attribute and operation to implement the collaboration defined for
each CRC index card
 Object Oriented Testing Strategies
Unit Testing in Object oriented Context
When object oriented software is considered the concept of Unit testing
changes Drastically
The reason for same is Encapsulation which drives the definition of
classes and object (i.e variable and function are represented in same
class)
Instead of testing an Individual model, the smallest testable unit is
encapsulated class or object
Because a class contain number of different operation and particular
operation may exist as a part of different classes the meaning has
changed
Class testing in OO software is Equivalent to unit testing in conventional
software which tend to focus on algorithmic details of module and data
flow across the module. Class testing for OO software is driven by
operation encapsulated by the class and state behavior of class.
 Integration Testing in the OO Context
Object oriented software does not have a hierarchical control structure,
conventional top-down and bottom-up integration strategies can not be
implemented
There are two different strategies for integration testing of OO system
1)Thread Based testing
> It integrate the set of Classes required to respond to one particular
event or input for the system
> Each Thread is Integrated and tested individually. Regression testing
is applied to ensure that no side effect occurs
2) Used based testing
> It begins construction of the system by testing those independent
classes that use very few of Server classes
> After Independent classes are tested, the next layer of dependent
classes that use this class is tested
> This process continues until entire system is constructed
 Validation Testing in an OO Context
At the validation or system level, details of class connection disappear

The validation of OO software focuses on user-visible action and user-

recognizable output from the system

To assist in the derivation of validation tests, the tester should draw

upon the use-case that are part of analysis model

The use-case provide a scenario that has high likelihood of uncovered

errors in user requirement

Conventional Black Box Testing Method can be used

 Test Case Design For OO Software
Test case design for OO Software is still evolving
The overall approach defined by Berard is as follows
1) Each test case should be uniquely and explicitly associated with class
to be tested
2) The purpose of state should be stated
3) The list of Testing step should be developed for each test case and
should contain
> List of Specified state for object that has to be tested
> List of Message and operation that will be exercised as a
consequence of the state
> List of exception that may occur when object is tested
> List of External condition
> Supplementary information that is needed understanding and
implementing the test
 Test Case design Implication of OO
Concepts
Encapsulation is Major problem while implementing the test case
design which is designed by tester
Unless built-in-operation are provided to report the value for class
attribute , a snapshot of the state of an object may be difficult to
acquire
Inheritance may also lead additional challenge for test case designer
Multiple inheritance complicate testing futher by increasing number
of contexts for which testing is required
White-box testing can be applied to the operation in class, but
many class operation cause some argue that effort applied to white-
box testing might be redirected to tests at class level
Black-box testing Method are as appropriate for OO System as they
are for System developed using conventional SE methods
 Fault based Testing
The object of fault based testing within an OO system is to design
test that have high likelihood of uncovering plausible fault (aspect of
the implementation of the system that may result in defects)
The product or system must conform to customer requirement, the
preliminary planning required to perform fault based testing begins
with analysis model
To determine whether these fault exists, test case are designed to
exercise design or code

Consider simple example. Software engg often make errors at

boundary of problem
When testing SQRT operation that returns error for negative value,
we know try the boundaries a negative number close to zero or zero
itself check whether the programmer made mistake like
if (x>0) calculate_the_square_root()
 Fault based Testing Continued……
Instead of correct
if (x>=0) calculate_the_square_root()
Consider another example of Boolean expression
if (a&&!b||c)
Multicondition testing and related technique probe for certain plausible
fault in this expression ,such as
&& should be ||
! Was left out where it was needed
there should be parenthesis around !b||c
For each plausible fault we design test case that will force the incorrect
expression to fail
Integration testing looks for plausible fault in operation call or message
connection. Three type are encountered
1)Unexpected result
2)wrong operation/message used
3)incorrect Invocation
 Test cases and Class Hierarchy
Inheritance does not obviate the need for thorough testing of all
derived classes. In fact, it actually complicate the testing process

Base::refined and Derived:: refined if this type of classes are

defined then a tester has to go through all the aspect of base class
then the one defined as derived class and as both are interrelated
the test case design becomes complicated

In such case a long path has to be traversed then tester has to be

precautious
 Scenario based testing
Fault based testing misses two main error
1) Incorrect specification
2) Interaction among Subsystem
In first type of error the product does not do what the
customer want, it might omit important functionality
Error associated with subsystem interaction occur when
the behavior of one subsystem create circumstance that
cause another subsystem to fail
Scenario based testing concentrate on what user does,
not what product does. This means capturing the task
user has to perform ,then applying them and their
variants as test.
Scenario uncovers the interaction error. But to
accomplish this, test case must be more complex and
more realistic than fault based test
 Scenario Based Testing
Consider following example
Use Case: Print a New Copy

Background :Someone ask the user for a fresh copy of the

document. It must be printed

1) Open the Document

2) Select print in the menu
3) Check if your printing a page range, click print entire
document
4) Click on Print Button
3) Close the Document

Test case will be designed to check all the above step listed are
correctly executed
 Testing Surface Structure
Surface structure refers to the externally observable structure of an OO
program. The structure that is immediately obvious to an end user

Rather than performing function, the user of many OO system may be

given an object to manipulate in some way

The best test case are derived when designer look at the system in a
new or unconventional way

Ask a question like “Might the user want to use this operation which
applies only to Scanner Object while working with the printer?”

Whatever the interface style, test case design that exercise the surface
structure should use both objects and operation as clues leading to
overlooked tasks
 Testing Deep structure
Deep structure refers to internal technical details of OO
Program
Deep structure testing is designed to exercise
dependencies behavior and communication mechanism
that have been established as part of system and object
design
Analysis and design model are used as basis for deep
structure testing
For example the object-relationship diagram or the
subsystem collaboration diagram depicts collaboration
between objects and subsystem that may not be
externally visible
The test case design then ask “Have we captured some
task that exercise the collaboration noted on the object-
relationship diagram or the subsystem collaboration
diagram? If not why not?”
 Testing Method applicable at the class level
1) Random Testing for OO Classes
Consider a banking application in which an account class has following
operation: open, setup, deposit, withdraw, balance, summarize,
creditlimit and close
Each of these operation may be applied for account but certain
constraint are implied by the nature of problem (account must be open
before doing any specific operation)
Even with these constraint, there many permutation of the operation like
open-setup-deposit-withdraw-close
A variety of different operation sequence can be generated

Test case1: open-- setup – deposit – deposit –balance – summarize -- close

Test case2:open – setup – deposit – withdraw – balance – close

 Partitioning testing at class level
Partition testing reduce number of test case required to exercise the
class in much same manner as equivalence partitioning. There are two
type of this test
1) State based Partitioning
> It categorize class operation based on their ability to change the
state of class. In previous example state operation include deposit
and withdraw. Test case will be as follows
Testcase1:open-setup-deposit- withdraw-withdraw-close
Testcase2:open– setup – deposit – summarize – close
Testcase1 is responsible for changing state while testcase2 does not
change state
2) Attribute based testing
It categorize class operation based on attribute they use. For account
class attribute balance and creditlimit can be used as partition
Test sequence are then designed for each partition
 Interclass test case design
Test case design can become more complicated as
integration of OO System is done
Like testing of the individual classes, class collaboration
testing can accomplished by applying random and
partitioning methods as well as scenario based testing and
behavioral testing
Multiple class Testing
Following step are suggested to generate multiple class
random test case
1)For each client class, use the list of class operation to
generate a series of random test sequence. The operation
will send message to other server classes
2)For each class that is generated determine the collaborator
class and the corresponding operation in server object
3)For each operation in server object determine the message
it transmits
 Continued….
4) For each Message determine next level of operation that are invoked and
incorporate these in to test sequence
Test derived from behavior model
Behavior model can be used as test case design
State based technique can be used to derive test cases
The state model can be traversed in ‘breadth-first” manner
In these context breadth first implies that a test case
exercise a single transition and that when a new transition
is to be tested only previously tested transition are used
Consider credit card object a breadth first approach to this
type of testing would not exercise submitted before it
exercised defined and undefined
If it did ,it would make use of transition that had been
previously tested and would therefore violate breadth first
crieteria