Scribd
Upload
306 views27 pages

Software Testing Strategies

Software testing is the process of exercising a program with the intent of finding errors. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner's Approach. The courseware materials may be reproduced ONLY for student use at the university level.

Uploaded by

cmc0912
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
306 views27 pages

Software Testing Strategies

Software testing is the process of exercising a program with the intent of finding errors. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner's Approach. The courseware materials may be reproduced ONLY for student use at the university level.

Uploaded by

cmc0912
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 27

Software Engineering: A Practitioners Approach,

6/e

Chapter 13
Software Testing Strategies
copyright 1996, 2001, 2005

R.S. Pressman & Associates, Inc.


For University Use Only
May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.

Thesecoursewarematerialsaretobeusedinconjunction

Software Testing
Testing is the process of exercising a
program with the specific intent of finding
errors prior to delivery to the end user.

Thesecoursewarematerialsaretobeusedinconjunction

What Testing Shows


errors
requirements conformance
performance
an indication
of quality

Thesecoursewarematerialsaretobeusedinconjunction

Who Tests the Software?

developer
Understands the system
but, will test "gently"
and, is driven by "delivery"

independent tester
Must learn about the system,
but, will attempt to break it
and, is driven by quality

Thesecoursewarematerialsaretobeusedinconjunction

Testing Strategy
unit test

system
test

integration
test

validation
test

Thesecoursewarematerialsaretobeusedinconjunction

Testing Strategy

We begin by testing-in-the-small and move toward


testing-in-the-large
For conventional software

The module (component) is our initial focus


Integration of modules follows

For OO software

our focus when testing in the small changes from an


individual module (the conventional view) to an OO class that
encompasses attributes and operations and implies
communication and collaboration

Thesecoursewarematerialsaretobeusedinconjunction

Strategic Issues

State testing objectives explicitly.


Understand the users of the software and develop a profile for each user category.
Develop a testing plan that emphasizes rapid cycle testing.
Build robust software that is designed to test itself
Use effective formal technical reviews as a filter prior to testing
Conduct formal technical reviews to assess the test strategy and test cases themselves.
Develop a continuous improvement approach for the testing process.

Thesecoursewarematerialsaretobeusedinconjunction

Unit Testing
module
to be
tested
results
software
engineer

test cases

Thesecoursewarematerialsaretobeusedinconjunction

Unit Testing
module
to be
tested

interface
local data structures
boundary conditions
independent paths
error handling paths
test cases

Thesecoursewarematerialsaretobeusedinconjunction

Unit Test Environment


driver
interface
local data structures

Module

boundary conditions
independent paths
error handling paths

stub

stub

test cases
RESULTS
Thesecoursewarematerialsaretobeusedinconjunction

10

Integration Testing Strategies


Options:
the big bang approach
an incremental construction strategy

Thesecoursewarematerialsaretobeusedinconjunction

11

Top Down Integration


A

stubs are replaced one at


a time, "depth first"

top module is tested with


stubs

as new modules are integrated,


some subset of tests is re-run

Thesecoursewarematerialsaretobeusedinconjunction

12

Bottom-Up Integration
A

drivers are replaced one at a


time, "depth first"

worker modules are grouped into


builds and integrated

cluster
Thesecoursewarematerialsaretobeusedinconjunction

13

Sandwich Testing
A

Top modules are


tested with stubs
G

Worker modules are grouped into


builds and integrated

cluster
Thesecoursewarematerialsaretobeusedinconjunction

14

Object-Oriented Testing

begins by evaluating the correctness and consistency of


the OOA and OOD models
testing strategy changes

the concept of the unit broadens due to encapsulation


integration focuses on classes and their execution across a
thread or in the context of a usage scenario
validation uses conventional black box methods

test case design draws on conventional methods, but also


encompasses special features
Thesecoursewarematerialsaretobeusedinconjunction

15

Broadening the View of Testing


ItcanbearguedthatthereviewofOOanalysisand
designmodelsisespeciallyusefulbecausethe
samesemanticconstructs(e.g.,classes,attributes,
operations,messages)appearattheanalysis,
design,andcodelevel.Therefore,aprobleminthe
definitionofclassattributesthatisuncovered
duringanalysiswillcircumventsideeffectsthat
mightoccuriftheproblemwerenotdiscovered
untildesignorcode(oreventhenextiterationof
analysis).
Thesecoursewarematerialsaretobeusedinconjunction

16

Testing the CRC Model


1. Revisit the CRC model and the object-relationship model.
2. Inspect the description of each CRC index card to determine if a
delegated responsibility is part of the collaborators definition.
3. Invert the connection to ensure that each collaborator that is
asked for service is receiving requests from a reasonable source.
4. Using the inverted connections examined in step 3, determine
whether other classes might be required or whether responsibilities
are properly grouped among the classes.
5. Determine whether widely requested responsibilities might be
combined into a single responsibility.
6. Steps 1 to 5 are applied iteratively to each class and through
each evolution of the OOA model.

Thesecoursewarematerialsaretobeusedinconjunction

17

OOT Strategy

class testing is the equivalent of unit testing

operations within the class are tested


the state behavior of the class is examined

integration applied three different strategies

thread-based testingintegrates the set of classes


required to respond to one input or event
use-based testingintegrates the set of classes required
to respond to one use case
cluster testingintegrates the set of classes required to
demonstrate one collaboration

Thesecoursewarematerialsaretobeusedinconjunction

18

Smoke Testing

A common approach for creating daily builds for product


software
Smoke testing steps:

Software components that have been translated into code are


integrated into a build.

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

A build includes all data files, libraries, reusable modules, and engineered
components that are required to implement one or more product
functions.

The intent should be to uncover show stopper errors that have the
highest likelihood of throwing the software project behind schedule.

The build is integrated with other builds and the entire product (in its
current form) is smoke tested daily.

The integration approach may be top down or bottom up.

Thesecoursewarematerialsaretobeusedinconjunction

19

High Order Testing

Validation testing

System testing

verifies that protection mechanisms built into a system will, in fact, protect it from
improper penetration

Stress testing

forces the software to fail in a variety of ways and verifies that recovery is properly
performed

Security testing

Focus is on customer usage

Recovery testing

Focus is on system integration

Alpha/Beta testing

Focus is on software requirements

executes a system in a manner that demands resources in abnormal quantity,


frequency, or volume

Performance Testing

test the run-time performance of software within the context of an integrated


system

Thesecoursewarematerialsaretobeusedinconjunction

20

Debugging:
A Diagnostic Process

Thesecoursewarematerialsaretobeusedinconjunction

21

The Debugging Process


test cases

new test
regression cases
tests
suspected
causes
corrections
identified
causes

results

Debugging

Thesecoursewarematerialsaretobeusedinconjunction

22

Debugging Effort

time required
to correct the error
and conduct
regression tests

time required
to diagnose the
symptom and
determine the
cause

Thesecoursewarematerialsaretobeusedinconjunction

23

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

Thesecoursewarematerialsaretobeusedinconjunction

24

Consequences of Bugs
infectious
damage
catastrophic
extreme
serious
disturbing
annoying
mild
Bug Type
Bug Categories: function-related bugs,
system-related bugs, data bugs, coding bugs,
design bugs, documentation bugs, standards
violations, etc.

Thesecoursewarematerialsaretobeusedinconjunction

25

Debugging Techniques
brute force / testing
backtracking
induction
deduction

Thesecoursewarematerialsaretobeusedinconjunction

26

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.

Thesecoursewarematerialsaretobeusedinconjunction

27

You might also like