Software Engineering
Lecture 13
Software Testing Strategies
1
Verification and Validation


Verification refers to the set of activities that
ensure that software correctly implements a
specific function.
It asks the question: “Are we building the
product right?”
Validation refers to a different set of
activities that ensure that the software that
has been built is traceable to customer
requirements.
It asks the question: “Are we building the
right product?”
2
Testing Strategy
unit test
system
test
integration
test
validation
test
3
Unit Testing
module
to be
tested
results
software
engineer
test cases
4
Unit Testing
module
to be
tested
interface
local data structures
boundary conditions
independent paths
error handling paths
test cases
5
Unit Test Environment
driver
interface
local data structures
Module
boundary conditions
independent paths
error handling paths
stub
stub
test cases
RESULTS
6
Integration Testing Strategies
Options:
• the “big bang” approach
• an incremental construction strategy
7
Top Down Integration
A
B
F
top module is tested with
stubs
G
stubs are replaced one at
a time, "depth first"
C
as new modules are integrated,
some subset of tests is re-run
D
E
8
Bottom-Up Integration
A
B
F
G
drivers are replaced one at a
time, "depth first"
C
worker modules are grouped into
builds and integrated
D
E
cluster
9
Sandwich Testing
A
B
F
Top modules are
tested with stubs
G
C
Worker modules are grouped into
builds and integrated
D
E
cluster
10
Validation Testing
Validation Testing can be defined as
ensuring that software functions in a
manner that can be reasonably expected
by the customer.
 Achieve through a series of black-box
testings tha demonstrate conformity with
requirements.
 A series of acceptance tests (include both
alpha and beta testing) are conducted
with the end users.

11
Alpha vs. Beta Testing
Alpha Testing
 Is conducted at the
Developer’s site by a
customer
 The developer would
supervise
 Is conducted in a
controlled
environment
Beta Testing
 Is conducted at
customer’s site by
the end user of the
software
 The developer is
generally not present
 Is conducted in a
“live” environment
12
System Testing
System testing is actually a series of
different tests whose primary purpose is
to fully exercise the computer-based
system
 Although each system test has a different
purpose, all work to verify that all system
elements have been integrated and
perform allocated functions

13
System Testing Examples

Recovery Testing
A system test that forces software to fail in a variety of ways and
verifies that recovery is properly performed

Security Testing
Attempts to verify tha protection mechanism built into a system
will in fact protect it from improper penetration

Stress Testing
Is designed to confront programs with abnormal situation where
unusual quantity, frequency, or volume of resources are demanded

Performance Testing
Seeks to test the run-time performance of software within the
context of an integrated system
14
Debugging:
A Diagnostic Process
15
The Debugging Process
test cases
regression
tests
new test
cases
results
suspected
causes
corrections
Debugging
identified
causes
16
Debugging Effort
time required
to correct the error
and conduct
regression tests
time required
to diagnose the
symptom and
determine the
cause
17
Symptoms & Causes
symptom and cause may be
geographically separated
symptom may disappear when
another problem is fixed
cause may be due to a
combination of non-errors
cause may be due to a system
or compiler error
symptom
cause
cause may be due to
assumptions that everyone
believes
symptom may be intermittent
18
Debugging Techniques
brute force / testing
backtracking
Cause elimination
19
Debugging: Final Thoughts
1. Don't run off half-cocked, think about the
symptom you're seeing.
2. Use tools (e.g., dynamic debugger) to gain
more insight.
3. If at an impasse, get help from someone else.
4. Be absolutely sure to conduct regression tests
when you do "fix" the bug.
20
References

Pressman, Chapter 18
21