Slides chapters 13-14
-
Upload
priyanka-shetty -
Category
Documents
-
view
3.800 -
download
0
description
Transcript of Slides chapters 13-14
![Page 1: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/1.jpg)
1
Chapter 13 & 14Software Testing
Strategiesand Techniques
Chapter 13 & 14Software Testing
Strategiesand Techniques Software Engineering: A Practitioner’s Approach, 6th edition
by Roger S. Pressman
![Page 2: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/2.jpg)
2
Software Testing
Testing is the process of exercising aTesting is the process of exercising aprogram with the specific intent of findingprogram with the specific intent of findingerrors prior to delivery to the end user.errors prior to delivery to the end user.
![Page 3: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/3.jpg)
3
What Testing Shows
errorserrors
requirements conformancerequirements conformance
performanceperformance
an indicationan indicationof qualityof quality
![Page 4: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/4.jpg)
4
Who Tests the Software?
developerdeveloper independent testerindependent tester
Understands the system Understands the system
but, will test "gently"but, will test "gently"
and, is driven by "delivery"and, is driven by "delivery"
Must learn about the system,Must learn about the system,but, will attempt to break itbut, will attempt to break itand, is driven by qualityand, is driven by quality
![Page 5: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/5.jpg)
5
Validation vs VerificationValidation vs Verification
Verification – Are we building the product right? Is the code correct with respect to its
specification?
Validation – Are we building the right product? Does the specification reflect what it should?
Verification – Are we building the product right? Is the code correct with respect to its
specification?
Validation – Are we building the right product? Does the specification reflect what it should?
![Page 6: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/6.jpg)
6
Testing Strategy
unit testunit test integrationintegrationtesttest
validationvalidationtesttest
systemsystemtesttest
![Page 7: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/7.jpg)
7
Testing StrategyTesting Strategy Begin with unit testing and work your way up to
system testing. Unit testing – test individual components (modules in
procedural languages; classes in OO languages) Integration testing – test collections of components
that must work together Validation testing – test the application as a whole
against user requirements System testing – test the application in the context of
an entire system
Begin with unit testing and work your way up to system testing.
Unit testing – test individual components (modules in procedural languages; classes in OO languages)
Integration testing – test collections of components that must work together
Validation testing – test the application as a whole against user requirements
System testing – test the application in the context of an entire system
![Page 8: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/8.jpg)
8
Unit Testing
modulemoduleto beto betestedtested
test casestest cases
resultsresults
softwaresoftwareengineerengineer
![Page 9: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/9.jpg)
9
Unit Testing
interface interface local data structureslocal data structures
boundary conditionsboundary conditionsindependent pathsindependent pathserror handling pathserror handling paths
modulemoduleto beto betestedtested
test casestest cases
![Page 10: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/10.jpg)
10
Unit Test Environment
ModuleModule
stubstub stubstub
driverdriver
RESULTSRESULTS
interface interface
local data structureslocal data structures
boundary conditionsboundary conditions
independent pathsindependent paths
error handling pathserror handling paths
test casestest cases
![Page 11: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/11.jpg)
11
Integration Testing Strategies
Options:Options:•• the “big bang” approachthe “big bang” approach•• an incremental construction strategyan incremental construction strategy
![Page 12: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/12.jpg)
12
Top Down Integration
top module is tested with top module is tested with stubsstubs
stubs are replaced one at stubs are replaced one at a time, "depth first"a time, "depth first"
as new modules are integrated, as new modules are integrated, some subset of tests is re-runsome subset of tests is re-run
AA
BB
CC
DD EE
FF GG
![Page 13: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/13.jpg)
13
Bottom-Up Integration
drivers are replaced one at a drivers are replaced one at a time, "depth first"time, "depth first"
worker modules are grouped into worker modules are grouped into builds and integratedbuilds and integrated
AA
BB
CC
DD EE
FF GG
clustercluster
![Page 14: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/14.jpg)
14
Regression TestingRegression Testing
The selective retesting of a modified system to help ensure that no bugs have been introduced during modification.
Fixing one part of the code can break another
The selective retesting of a modified system to help ensure that no bugs have been introduced during modification.
Fixing one part of the code can break another
![Page 15: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/15.jpg)
15
High Order TestingHigh Order Testing Validation testing
Focus is on software requirements System testing
Focus is on system integration Alpha/Beta testing
Focus is on customer usage Recovery testing
forces the software to fail in a variety of ways and verifies that recovery is properly performed Security testing
verifies that protection mechanisms built into a system will, in fact, protect it from improper penetration
Stress testing 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
Validation testing Focus is on software requirements
System testing Focus is on system integration
Alpha/Beta testing Focus is on customer usage
Recovery testing forces the software to fail in a variety of ways and verifies that recovery is properly performed
Security testing verifies that protection mechanisms built into a system will, in fact, protect it from improper
penetration Stress testing
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
![Page 16: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/16.jpg)
16
What is a “Good” Test?What is a “Good” Test?
A good test is one that has a high probability of finding an error.
A good test is one that has a high probability of finding an error.
![Page 17: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/17.jpg)
17
Test Case Design
"Bugs lurk in corners "Bugs lurk in corners and congregate at and congregate at boundaries ..."boundaries ..."
Boris BeizerBoris Beizer
OBJECTIVEOBJECTIVE
CRITERIACRITERIA
CONSTRAINTCONSTRAINT
to uncover errorsto uncover errors
in a complete mannerin a complete manner
with a minimum of effort and timewith a minimum of effort and time
![Page 18: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/18.jpg)
18
Exhaustive Testing
loop < 20 Xloop < 20 X
There are 10 possible paths! If we execute oneThere are 10 possible paths! If we execute onetest per millisecond, it would take 3,170 years totest per millisecond, it would take 3,170 years totest this program!!test this program!!
1414
![Page 19: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/19.jpg)
19
Selective Testing
loop < 20 Xloop < 20 X
Selected pathSelected path
![Page 20: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/20.jpg)
20
Software Testing
Methods
Strategies
white-boxmethods
black-box methods
![Page 21: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/21.jpg)
21
White-Box Testing
... our goal is to ensure that all ... our goal is to ensure that all statements and conditions have statements and conditions have been executed at least once ...been executed at least once ...
![Page 22: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/22.jpg)
22
Why Cover?
logic errors and incorrect assumptions logic errors and incorrect assumptions are inversely proportional to a path's are inversely proportional to a path's execution probabilityexecution probability
we often we often believebelieve that a path is not that a path is not likely to be executed; in fact, reality is likely to be executed; in fact, reality is often counter intuitiveoften counter intuitive
typographical errors are random; it's typographical errors are random; it's likely that untested paths will contain likely that untested paths will contain some some
![Page 23: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/23.jpg)
23
Basis Path TestingFirst, we compute the cyclomatic
complexity:
number of simple decisions + 1
or
number of enclosed areas + 1
In this case, V(G) = 4
![Page 24: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/24.jpg)
24
Cyclomatic Complexity
A number of industry studies have indicated A number of industry studies have indicated that the higher V(G), the higher the probability that the higher V(G), the higher the probability or errors.or errors.
V(G)V(G)
modulesmodules
modules in this range are modules in this range are more error pronemore error prone
![Page 25: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/25.jpg)
25
Basis Path TestingNext, we derive the Next, we derive the
independent paths:independent paths:
Since V(G) = 4,Since V(G) = 4,there are four pathsthere are four paths
Path 1: 1,2,3,6,7,8Path 1: 1,2,3,6,7,8Path 2: 1,2,3,5,7,8Path 2: 1,2,3,5,7,8Path 3: 1,2,4,7,8Path 3: 1,2,4,7,8Path 4: 1,2,4,7,2,4,...7,8Path 4: 1,2,4,7,2,4,...7,8
Finally, we derive testFinally, we derive testcases to exercise these cases to exercise these paths.paths.
11
22
3344
55 66
77
88
![Page 26: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/26.jpg)
26
Basis Path Testing Notes
you don't need a flow chart, you don't need a flow chart, but the picture will help when but the picture will help when you trace program pathsyou trace program paths
count each simple logical test, count each simple logical test, compound tests count as 2 or compound tests count as 2 or moremore
basis path testing should be basis path testing should be applied to critical modulesapplied to critical modules
![Page 27: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/27.jpg)
27
Black-Box Testing
requirementsrequirements
eventseventsinputinput
outputoutput
![Page 28: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/28.jpg)
28
Equivalence Partitioning
useruserqueriesqueries
mousemousepickspicks
outputoutputformatsformats
promptsprompts
FKFKinputinput
datadata
![Page 29: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/29.jpg)
29
Sample Equivalence Classes
user supplied commandsuser supplied commandsresponses to system promptsresponses to system promptsfile namesfile namescomputational datacomputational data physical parameters physical parameters bounding valuesbounding values initiation valuesinitiation valuesoutput data formattingoutput data formattingresponses to error messagesresponses to error messagesgraphical data (e.g., mouse picks)graphical data (e.g., mouse picks)
data outside bounds of the program data outside bounds of the program physically impossible dataphysically impossible dataproper value supplied in wrong placeproper value supplied in wrong place
Valid dataValid data
Invalid dataInvalid data
![Page 30: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/30.jpg)
30
Boundary Value Analysis
useruserqueriesqueries
mousemousepickspicks
outputoutputformatsformats
promptsprompts
FKFKinputinput
datadata
outputoutputdomaindomaininput domaininput domain
![Page 31: Slides chapters 13-14](https://reader036.fdocuments.net/reader036/viewer/2022062513/555a82d6d8b42a98568b4ece/html5/thumbnails/31.jpg)
31
OOT Methods: Behavior TestingOOT Methods: Behavior Testing
emptyacctopen setup Accnt
set upacct
deposit(initial)
workingacct
withdrawal(final)
deadacct close
nonworkingacct
deposit
withdrawbalance
creditaccntInfo
Figure 14.3 State diagram for Account class (adapted from [ KIR94])
The tests to be The tests to be designed designed should achieve should achieve all state all state coverage coverage [KIR94]. That [KIR94]. That is, the is, the operation operation sequences sequences should cause should cause the Account the Account class to make class to make transition transition through all through all allowable allowable statesstates