1. Wednesday, February 15,
2023 1
Software Testing
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
2. Wednesday, February 15,
2023 2
Software Testing
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
3. Wednesday, February 15,
2023 3
Software Testing
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
4. Wednesday, February 15,
2023 4
Software Testing
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
5. Wednesday, February 15,
2023 5
Software Testing
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)
6. Wednesday, February 15,
2023 6
Software Testing
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
7. Wednesday, February 15,
2023 7
Software Testing
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
8. Wednesday, February 15,
2023 8
Software Testing
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”
9. Wednesday, February 15,
2023 9
Software 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
10. Wednesday, February 15,
2023 10
Software 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
Sequence
If Statement
While until
Case
13. Wednesday, February 15,
2023 13
Software Testing
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
14. Wednesday, February 15,
2023 14
Software Testing
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
15. Wednesday, February 15,
2023 15
Software Testing
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
16. Wednesday, February 15,
2023 16
Software Testing
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
3
4
2
5
a
b
d
e
f
g
a
d b
c F
g e
1 2 3 4 5
1
2
3
4
5
17. Wednesday, February 15,
2023 17
Software Testing
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
18. Wednesday, February 15,
2023 18
Software Testing
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
19. Wednesday, February 15,
2023 19
Software Testing
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.”
20. Wednesday, February 15,
2023 20
Software Testing
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
21. Wednesday, February 15,
2023 21
Software Testing
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’
22. Wednesday, February 15,
2023 22
Software Testing
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
23. Wednesday, February 15,
2023 23
Software Testing
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
24. Wednesday, February 15,
2023 24
Software Testing
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
25. Wednesday, February 15,
2023 25
Software Testing
Unstructured loop
Whenever possible this class of
loop should be redesigned to
reflect the use of structured
programming construct
26. Wednesday, February 15,
2023 26
Software Testing
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?
27. Wednesday, February 15,
2023 27
Software Testing
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
28. Wednesday, February 15,
2023 28
Software Testing
Graph-Based Testing Methods continued…..
Object#1
Object#3
Object#2
Directed link
Parallel link
Undirected link
New file menu
select
Document
Text
Document
Window
Node
weight
Menu Select generates
{generation time<1.0sec}
Is Represented as
Allows editing of
Contains
29. Wednesday, February 15,
2023 29
Software Testing
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
30. Wednesday, February 15,
2023 30
Software Testing
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
31. Wednesday, February 15,
2023 31
Software Testing
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
32. Wednesday, February 15,
2023 32
Software Testing
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
33. Wednesday, February 15,
2023 33
Software Testing
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
34. Wednesday, February 15,
2023 34
Software Testing
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
35. Wednesday, February 15,
2023 35
Software Testing
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
36. Wednesday, February 15,
2023 36
Software Testing
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
~~~~~
~~~~~
~~~~~
Test
Cases
Interface
Local data structure
Boundary condition
Independent Paths
Error handling Paths
37. Wednesday, February 15,
2023 37
Software Testing
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
38. Wednesday, February 15,
2023 38
Software Testing
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
39. Wednesday, February 15,
2023 39
Software Testing
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
Module to
be
tested
Stubs Stubs Test
case
Interface
Local data structure
Boundary condition
Independent Paths
Error handling Paths
Results
40. Wednesday, February 15,
2023 40
Software Testing
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
41. Wednesday, February 15,
2023 41
Software Testing
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
42. Wednesday, February 15,
2023 42
Software Testing
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
43. Wednesday, February 15,
2023 43
Software Testing
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
44. Wednesday, February 15,
2023 44
Software Testing
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
45. Wednesday, February 15,
2023 45
Software Testing
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
46. Wednesday, February 15,
2023 46
Software Testing
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
47. Wednesday, February 15,
2023 47
Software Testing
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
48. Wednesday, February 15,
2023 48
Software Testing
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
49. Wednesday, February 15,
2023 49
Software Testing
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
50. Wednesday, February 15,
2023 50
Software Testing
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
51. Wednesday, February 15,
2023 51
Software Testing
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
52. Wednesday, February 15,
2023 52
Software Testing
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
53. Wednesday, February 15,
2023 53
Software Testing
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
54. Wednesday, February 15,
2023 54
Software Testing
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
55. Wednesday, February 15,
2023 55
Software Testing
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
56. Wednesday, February 15,
2023 56
Software Testing
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.
57. Wednesday, February 15,
2023 57
Software Testing
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
58. Wednesday, February 15,
2023 58
Software Testing
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
59. Wednesday, February 15,
2023 59
Software Testing
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
60. Wednesday, February 15,
2023 60
Software Testing
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
61. Wednesday, February 15,
2023 61
Software Testing
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()
62. Wednesday, February 15,
2023 62
Software Testing
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
63. Wednesday, February 15,
2023 63
Software Testing
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
64. Wednesday, February 15,
2023 64
Software Testing
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
65. Wednesday, February 15,
2023 65
Software Testing
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
66. Wednesday, February 15,
2023 66
Software Testing
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
67. Wednesday, February 15,
2023 67
Software Testing
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?”
68. Wednesday, February 15,
2023 68
Software Testing
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
69. Wednesday, February 15,
2023 69
Software Testing
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
70. Wednesday, February 15,
2023 70
Software Testing
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
71. Wednesday, February 15,
2023 71
Software Testing
Continued….
4) For each Message determine next level of operation that are invoked and
incorporate these in to test sequence
72. Wednesday, February 15,
2023 72
Software Testing
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
73. Wednesday, February 15,
2023 73
Software Testing
End of Syllabus
This to declare that syllabus for object oriented analysis
and software testing is over today dated 2/15/2023
2:43:00 PM