Unit 8

Unit 8
Software Testing Strategies
Software Testing
Testing is the process of exercising a
program with the specific intent of finding
errors prior to delivery to the end user.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005
Reliability is a measure of success

Software Reliability is the probability that a software
system will not cause system failure for a specified time
under specified conditions
Failure is any deviation of the observed behavior from
the specified behavior.
Testing is the systematic attempt to find faults in a
planned way in the implemented software.
What Testing Shows

errors
requirements conformance
performance
an indication
of quality
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
Testing Strategy
unit test
system
test
integration
test
validation
test
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
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.
Unit Testing
module
to be
tested
results
software
engineer
test cases
10
Unit Testing
module
to be
tested
interface
local data structures
boundary conditions
independent paths
error handling paths
test cases
11
Unit Test Environment

driver
interface
local data structures
Module
boundary conditions
independent paths
error handling paths
stub
stub
test cases
RESULTS
12
Drivers/Stubs
Sl.No
Drivers
Stubs
Driver is a piece of software that drives

(invokes) the Unit being tested. I.e. A
piece of code that passes test cases to
another piece of code
Stub is a piece of software that works

similar to a unit which is referenced by the
Unit being tested, but it is much simpler
that the actual unit
i.e. A piece of code that simulates the
activity of missing components
A driver creates necessary Inputs

A Stub works as a Stand-in for the
required for the Unit and then invokes the subordinate unit and provides the minimum
Unit
required behavior for that unit
Driver is called component
Stubs is calling Component
4.
Used in the Bottom Up Test strategy
Used in the Top Down Testing Strategy
13
Test Cases
A test case is a set of input data and expected results that exercises a
component with the purpose of causing failures and detecting faults.
A test case has five attributes:
1.Name:It allows the tester to distinguish between different test cases. Name
given should be meaningful.
Ex: If you are testing a use case Deposit() ,we can name it as Test_Deposit.
2.Location :Full path of executable
3.Input: Input data or commands
4.Expected test results
5.log:Output produced by the test(time stamped test results)
14
Test Case Preparation

the test condition is identified and the expectation out of it is provided, it is important to understand the condition correctly so that you
proceed with all validation
steps which are important part of your condition.
Thing to remember while creating test case
_ Check for the request and response of each interacting application
_ Validate the same case with large amount of test data and also different data
_ Check for the value what the integrating application/interfacing application should have
versus what it is currently having. Is that correct? Sometimes the interfacing applications
interpret the request in different way and respond wrong but do not fail. Be careful!
_ In case you have database validation, check for the columns which are affecting with the
different data. Dont ignore any of the tables which are impacting the transaction/flow
_ Check for the error logs. Sometimes there are error logged even though the transaction is
flown correctly in the interfacing application
_ Provide the proper description of the test case with the changes in the interfacing
application, this helps to understand the flow at a higher level
_ If different data respond differently for the same test condition, provide that and dont
forget to test that. Think Out of the Box to break the system
_ Last but not least, when data flows from one application to another test immediately
when you are expecting the data to flow. Dont think that it could be tested later. The
more active you are with the data flow validation, more defects you have in your bucket
Once
15
Test cases are classified into blackbox tests and whitebox

tests.
Blackbox testing: Focus on input/output behavior of the
component. Blackbox tests do not deal with the internal
aspects of the component, nor with the structure of the
component.
Whitebox testing focus on the internal structure of the
component.
Unit Testing combines both testing techniques:
16
Test stubs and drivers
Stubs and drivers are written after the component is

completed.
A test driver passes the test inputs identified in the test
case analysis to the component and displays results.
If the interface of a component changes, the
corresponding drivers and stubs must change as well.
17
Integration Testing Strategies

Options:
the big bang approach
an incremental construction strategy
18
Big bang testing strategy assumes that all components are first
tested individually and then tested together as a single system.
Big bang testing is expensive.
2 types of Integration testing:
Bottom up and top down testing
Bottom up testing strategy first test each component of the
bottom layer individually.
In Top down testing strategy unit tests the components of the
top layer first n then integrates the components of the next
layer
19
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
20
Bottom-Up Integration
A
drivers are replaced one at a

time, "depth first"
worker modules are grouped into

builds and integrated
cluster
21
Sandwich Testing
A
Top modules are

tested with stubs
G
Worker modules are grouped into

builds and integrated
cluster
22
System Testing
Functional Testing: is also called requirement testing.

Is a black box testing
Test cases are derived from the use case model.
Performance Testing: Finds the differences between the design goals selected
during system design and the system.
Stress Testing : Checks if the system can respond to many simultaneous requests.
Volume Testing: Find faults associated with large amounts of data
Security Testing:Testing team break into the system using their experience and
knowledge of security flaws.
Timing Testing: attempts to find behaviors that violate timing constraints
described by the nonfunctional requirements.
Recovery Tests evaluates the ability of the system to recover from erroneous
states, such as the unavailability of resources, a hardware failure,network failure
23
System Testing Continued

Pilot Testing : is also called field test.
Pilot tests are useful when a system is built without a specific set of
requirements or without a specific customer in mind
Alpha test is a pilot test with users exercising the system in the
development environment.
Beta test , the acceptance test performed by a limited number of end
users in the target environment.
Stress Testing: Stress testing executes a system in a manner that
demands resources in abnormal quantity.
Ex:Special tests may be designed that generate ten interrupts per
second, when one or two are the average rates.
24
Acceptance Testing:
The client prepares a set of test cases that represent typical conditions under
which the system should operate.
After the acceptance testing the client reports to the project manager which
requirements are not satisfied.
Installation Testing:
After the system is accepted , it is installed in the target environment. A good
testing plan allows the easy configuration of the system from the
development envi to target environment
25
Validation Testing
Validation testing begins at the culmination(result)

of integration testing
Testing focuses on user visible actions and user
recognizable output from the system
Validation succeeds when software functions in a
manner that can be reasonably expected by the customer
A SRS contains a section called validation criteria.
Information contains in that section forms the basis for
validation testing.
26
Validation Test criteria
Software validation is achieved through a series of tests

that demonstrate conformity with requirements
A test plan outlines the classes of tests to be conducted.
Test procedure defines specific test cases.
All functional,behavioral,performance requirements has
to be satisfied.
Documentation is checked
Usability ( transportability, compatibility, error recovery)
are met after validation testing
27
Validation Testing Continued..

Configuration Review:
An important element of the validation process is configuration
review.
The intent of this review is to ensure that all elements of the
software configuration have been properly developed.
The configuration review is sometimes called as audit
Alpha and Beta Testing:
Alpha test is conducted at the develops site by the end users.
Beta testing is conducted at end users sites. The developer is not
present during the beta testing. Therefore beta testing is like a live
application of the software .
28
What is a Good Test?
A good test has a high probability of finding

an error
A good test is not redundant.
A good test should be best of breed
A good test should be neither too simple nor
too complex
29
Software Testing
black-box
methods
white-box
methods
Methods
Strategies
30
White-Box Testing
... our goal is to ensure that all

statements and conditions have
been executed at least once ...
31
Basis Path Testing

Basis path testing is white box testing
Here the test cases are derived to exercise the
every statement in the program at least one
time during testing.
First, we compute the cyclomatric Complexity V(G)
+1
1) V(G) = E N + 2
= 11-9+2
2) V(G)= No. Predicate nodes
=3+1
In both the cases, V(G) = 4
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005
32
Cyclomatic Complexity
A number of industry studies have indicated
that the higher V(G), the higher the probability
or errors.
modules
V(G)
modules in this range are
more error prone
33
Basis Path Testing
Next, we derive the

independent paths:
Since V(G) = 4,
there are four paths
2
3
Path 1:
Path 2:
Path 3:
Path 4:
1,2,3,6,7,8
1,2,3,5,7,8
1,2,4,7,8
1,2,4,7,2,4,...7,8
Finally, we derive test

cases to exercise these
paths.
34
Basis Path Testing Notes

you don't need a flow chart,
but the picture will help when
you trace program paths
count each simple logical test,
compound tests count as 2 or
more
basis path testing should be
applied to critical modules
35
Control Structure Testing
Condition testing a test case design method that

exercises the logical conditions contained in a program
module. Test cases are designed using boolean operators,
parenthesis, relational operators(=,>,<etc).
Condition testing method focuses on testing each
condition in the program to ensure that it does not
contain errors.
Data flow testing selects test paths of a program
according to the locations of definitions and uses of
variables in the program
36
Loop Testing
Simple
loop
Nested
Loops
Concatenated
Loops
Unstructured
Loops
37
Loop Testing: Simple Loops

Minimum conditionsSimple Loops
1. skip the loop entirely
2. only one pass through the loop
3. two passes through the loop
4. m passes through the loop m < n
5. (n-1), n, and (n+1) passes through
the loop
where n is the maximum number
of allowable passes
38
Loop Testing: Nested Loops

Nested Loops
Start at the innermost loop. Set all outer loops to their
minimum iteration parameter values.
Test the min+1, typical, max-1 and max for the
innermost loop, while holding the outer loops at their
minimum values.
Move out one loop and set it up as in step 2, holding all
other loops at typical values. Continue this step until
the outermost loop has been tested.
Concatenated Loops
If the loops are independent of one another
then treat each as a simple loop
else* treat as nested loops
endif*
for example, the final loop counter value of loop 1 is
used to initialize loop 2.
39
Black-Box Testing
requirements
output
input
events
40
Black-Box Testing
How is functional validity tested?

How is system behavior and performance tested?
What classes of input will make good test cases?
Is the system particularly sensitive to certain input
values?
How are the boundaries of a data class isolated?
What data rates and data volume can the system
tolerate?
What effect will specific combinations of data have
on system operation?
41

Unit 8

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Unit 8

Hochgeladen von

Copyright:

Verfügbare Formate

Unit 8

Software Testing Strategies

Reliability is a measure of success

What Testing Shows

Who Tests the Software?

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

The module (component) is our initial focus

State testing objectives explicitly.

Unit Test Environment

Driver is a piece of software that drives

Stub is a piece of software that works

A driver creates necessary Inputs

Driver is called component

Stubs is calling Component

Used in the Bottom Up Test strategy

Used in the Top Down Testing Strategy

Test Case Preparation

Test cases are classified into blackbox tests and whitebox

Test stubs and drivers

Stubs and drivers are written after the component is

Integration Testing Strategies

Top Down Integration

stubs are replaced one at

top module is tested with

as new modules are integrated,

drivers are replaced one at a

worker modules are grouped into

Top modules are

Worker modules are grouped into

Functional Testing: is also called requirement testing.

System Testing Continued

Validation testing begins at the culmination(result)

Validation Test criteria

Software validation is achieved through a series of tests

Validation Testing Continued..

What is a Good Test?

A good test has a high probability of finding

... our goal is to ensure that all

Basis Path Testing

In both the cases, V(G) = 4

Basis Path Testing

Next, we derive the

Finally, we derive test

Basis Path Testing Notes

Control Structure Testing

Condition testing a test case design method that

Loop Testing: Simple Loops

Loop Testing: Nested Loops

How is functional validity tested?

Das könnte Ihnen auch gefallen