Presentation on theme: "Chapter 13 & 14 Software Testing Strategies and Techniques"— Presentation transcript:
1 Chapter 13 & 14 Software Testing Strategies and Techniques Software Engineering: A Practitioner’s Approach, 6th editionby Roger S. Pressman
2 Software Testing Testing is the process of exercising a program with the specific intent of findingerrors prior to delivery to the end user.
3 What Testing Shows errors requirements conformance performance an indicationof quality
4 Who Tests the Software? developer independent tester Understands the systemMust learn about the system,but, will test "gently"but, will attempt to break itand, is driven by "delivery"and, is driven by quality
5 Validation 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?
6 Testing Strategy unit test integration test system validation test
7 Testing StrategyBegin 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 togetherValidation testing – test the application as a whole against user requirementsSystem testing – test the application in the context of an entire system
8 Unit Testingmoduleto betestedresultssoftwareengineertest cases
9 Unit Testing module to be tested interface local data structures boundary conditionsindependent pathserror handling pathstest cases
10 Unit Test Environment test cases RESULTS driver Module stub stub interfacelocal data structuresModuleboundary conditionsindependent pathserror handling pathsstubstubtest casesRESULTS
11 Integration Testing Strategies Options:• the “big bang” approach• an incremental construction strategy
12 Top Down Integration A top module is tested with stubs B F G stubs are replaced one ata time, "depth first"Cas new modules are integrated,some subset of tests is re-runDE
13 Bottom-Up Integration FGdrivers are replaced one at atime, "depth first"Cworker modules are grouped intobuilds and integratedDEcluster
14 Regression TestingThe 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
15 High Order Testing Validation testing System testing Focus is on software requirementsSystem testingFocus is on system integrationAlpha/Beta testingFocus is on customer usageRecovery testingforces the software to fail in a variety of ways and verifies that recovery is properly performedSecurity testingverifies that protection mechanisms built into a system will, in fact, protect it from improper penetrationStress testingexecutes a system in a manner that demands resources in abnormal quantity, frequency, or volumePerformance Testingtest the run-time performance of software within the context of an integrated system
16 What is a “Good” Test?A good test is one that has a high probability of finding an error.
17 Test Case Design "Bugs lurk in corners and congregate at boundaries ..."Boris BeizerOBJECTIVEto uncover errorsCRITERIAin a complete mannerCONSTRAINTwith a minimum of effort and time
18 Exhaustive Testing There are 10 possible paths! If we execute one loop < 20 X14There are 10 possible paths! If we execute onetest per millisecond, it would take 3,170 years totest this program!!
21 White-Box Testing ... our goal is to ensure that all statements and conditions havebeen executed at least once ...
22 Why Cover? logic errors and incorrect assumptions are inversely proportional to a path'sexecution probabilitywe oftenbelievethat a path is notlikely to be executed; in fact, reality isoften counter intuitivetypographical errors are random; it'slikely that untested paths will containsome
23 Basis Path Testing First, we compute the cyclomatic complexity: number of simple decisions + 1ornumber of enclosed areas + 1In this case, V(G) = 4
24 Cyclomatic Complexity A number of industry studies have indicatedthat the higher V(G), the higher the probabilityor errors.modulesV(G)modules in this range aremore error prone
25 Basis Path Testing Next, we derive the independent paths: 12345678independent paths:Since V(G) = 4,there are four pathsPath 1: 1,2,3,6,7,8Path 2: 1,2,3,5,7,8Path 3: 1,2,4,7,8Path 4: 1,2,4,7,2,4,...7,8Finally, we derive testcases to exercise thesepaths.
26 Basis Path Testing Notes you don't need a flow chart,but the picture will help whenyou trace program pathscount each simple logical test,compound tests count as 2 ormorebasis path testing should beapplied to critical modules
29 Sample Equivalence Classes Valid datauser supplied commandsresponses to system promptsfile namescomputational dataphysical parametersbounding valuesinitiation valuesoutput data formattingresponses to error messagesgraphical data (e.g., mouse picks)Invalid datadata outside bounds of the programphysically impossible dataproper value supplied in wrong place
30 Boundary Value Analysis userqueriesoutputformatsFKinputmousepicksdatapromptsoutputdomaininput domain
31 OOT Methods: Behavior Testing The tests to be designed should achieve all state coverage [KIR94]. That is, the operation sequences should cause the Account class to make transition through all allowable states