 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
 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
 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
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 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)
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
 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
 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”
 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 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
 1

33

6 4
4

7 88
5
9
10

11
 1

2,3

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

Edges R4
11
 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
 How do we know 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
 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
 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
 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 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
 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.”
 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
 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 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
 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 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
 Whenever possible this class of
loop should be redesigned to
reflect the use of structured
programming construct
 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
 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
 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
 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
 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
 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
 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
 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

 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 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
 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
 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
 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 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
 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
 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
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
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 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
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 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 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
 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
 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
 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
 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
  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
 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
 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
 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.
 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
 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 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
 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
 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()
 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
 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
 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
 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
 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
 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?”
 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

 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
 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
4) For each Message determine next level of operation that are invoked and
incorporate these in to test sequence
 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