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

Thursday, September 2, 202 Software Testing 1

1
 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

Thursday, September 2, 202 Software Testing 2

1
 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

Thursday, September 2, 202 Software Testing 3

1
 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

Thursday, September 2, 202 Software Testing 4

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

Thursday, September 2, 202 Software Testing 5

1
 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

Thursday, September 2, 202 Software Testing 6

1
 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

Thursday, September 2, 202 Software Testing 7

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

Thursday, September 2, 202 Software Testing 8

1
 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

Thursday, September 2, 202 Software Testing 9

1
 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

Thursday, September 2, 202 Software Testing 10

1
 Flow Graph Notation and Cyclomatic
Complexity

33

6 4
4

7 88
5
9
10

11

Thursday, September 2, 202 Software Testing 11

1
 Flow Graph Notation and Cyclomatic
Complexity

2,3

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

Edges R4
11

Thursday, September 2, 202 Software Testing 12

1
 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

Thursday, September 2, 202 Software Testing 13

1
 Flow Graph Notation and Cyclomatic

Complexity
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

Thursday, September 2, 202 Software Testing 14

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

Thursday, September 2, 202 Software Testing 15

1
 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

Thursday, September 2, 202 Software Testing 16

1
 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

Thursday, September 2, 202 Software Testing 17

1
 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

Thursday, September 2, 202 Software Testing 18

1
 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.”

Thursday, September 2, 202 Software Testing 19

1
 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

Thursday, September 2, 202 Software Testing 20

1
 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’

Thursday, September 2, 202 Software Testing 21

1
 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

Thursday, September 2, 202 Software Testing 22

1
 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

Thursday, September 2, 202 Software Testing 23

1
 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

Thursday, September 2, 202 Software Testing 24

1
 Unstructured loop
 Whenever possible this class of
loop should be redesigned to
reflect the use of structured
programming construct

Thursday, September 2, 202 Software Testing 25

1
 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?

Thursday, September 2, 202 Software Testing 26

1
 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

Thursday, September 2, 202 Software Testing 27

1
 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

Thursday, September 2, 202 Software Testing 28

1
 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

Thursday, September 2, 202 Software Testing 29

1
 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

Thursday, September 2, 202 Software Testing 30

1
 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

Thursday, September 2, 202 Software Testing 31

1
 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

Thursday, September 2, 202 Software Testing 32

1
 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

Thursday, September 2, 202 Software Testing 33

1
 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

Thursday, September 2, 202 Software Testing 34

1
 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

Thursday, September 2, 202 Software Testing 35

1
 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

Thursday, September 2, 202 Software Testing 36

1
 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

Thursday, September 2, 202 Software Testing 37

1
 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

Thursday, September 2, 202 Software Testing 38

1
 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
Thursday, September 2, 202 Software Testing 39
1
 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

Thursday, September 2, 202 Software Testing 40

1
 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

Thursday, September 2, 202 Software Testing 41

1
 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

Thursday, September 2, 202 Software Testing 42

1
 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

Thursday, September 2, 202 Software Testing 43

1
 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

Thursday, September 2, 202 Software Testing 44

1
 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

Thursday, September 2, 202 Software Testing 45

1
 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

Thursday, September 2, 202 Software Testing 46

1
 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

Thursday, September 2, 202 Software Testing 47

1
 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

Thursday, September 2, 202 Software Testing 48

1
 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

Thursday, September 2, 202 Software Testing 49

1
 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

Thursday, September 2, 202 Software Testing 50

1
 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

Thursday, September 2, 202 Software Testing 51

1
 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

Thursday, September 2, 202 Software Testing 52

1
 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

Thursday, September 2, 202 Software Testing 53

1
 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

Thursday, September 2, 202 Software Testing 54

1
 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

Thursday, September 2, 202 Software Testing 55

1
 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.

Thursday, September 2, 202 Software Testing 56

1
 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

Thursday, September 2, 202 Software Testing 57

1
 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

Thursday, September 2, 202 Software Testing 58

1
 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

Thursday, September 2, 202 Software Testing 59

1
 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

Thursday, September 2, 202 Software Testing 60

1
 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()

Thursday, September 2, 202 Software Testing 61

1
 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

Thursday, September 2, 202 Software Testing 62

1
 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

Thursday, September 2, 202 Software Testing 63

1
 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

Thursday, September 2, 202 Software Testing 64

1
 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

Thursday, September 2, 202 Software Testing 65

1
 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

Thursday, September 2, 202 Software Testing 66

1
 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?”

Thursday, September 2, 202 Software Testing 67

1
 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

Thursday, September 2, 202 Software Testing 68

1
 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

Thursday, September 2, 202 Software Testing 69

1
 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

Thursday, September 2, 202 Software Testing 70

1
 Continued….
4) For each Message determine next level of operation that are invoked and
incorporate these in to test sequence

Thursday, September 2, 202 Software Testing 71

1
 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

Thursday, September 2, 202 Software Testing 72

1
 End of Syllabus
 This to declare that syllabus for object oriented
analysis and software testing is over today dated
09/02/21 08:07 AM

 For Queries mail to: [email protected]

Thursday, September 2, 202 Software Testing 73

1