Se361 Chapter 17 - Software Engineering At RIT

Chapter 17 Software Testing StrategiesSlide Set to accompanySoftware Engineering: A Practitioner’s Approach, 7/eby Roger S. PressmanSlides copyright 1996, 2001, 2005, 2009 by Roger S. PressmanFor non-profit educational use onlyMay be reproduced ONLY for student use at the university level when used in conjunctionwith Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use isprohibited without the express written permission of the author.All copyright information MUST appear if these slides are posted on a website for studentuse.These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.1Software TestingTesting is the process of exercisinga program with the specific intent offinding errors prior to delivery to theend user.These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.2

What Testing Showserrorsrequirements conformanceperformancean indicationof qualityThese slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.3Strategic Approach To perform effective testing, you should conducteffective technical reviews. By doing this, many errorswill be eliminated before testing commences.Testing begins at the component level and works"outward" toward the integration of the entire computerbased system.Different testing techniques are appropriate for differentsoftware engineering approaches and at different pointsin time.Testing is conducted by the developer of the softwareand (for large projects) an independent test group.Testing and debugging are different activities, butdebugging must be accommodated in any testingstrategy.These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.4

V&V Verification refers to the set of tasks that ensurethat software correctly implements a specificfunction.Validation refers to a different set of tasks thatensure that the software that has been built istraceable to customer requirements. Boehm[Boe81] states this another way: Verification: "Are we building the product right?"Validation: "Are we building the right product?"These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.5Who Tests the Software?developerUnderstands the systembut, will test "gently"and, is driven by "delivery"independent testerMust learn about the system,but, will attempt to break itand, is driven by qualityThese slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.6

Testing StrategySystem engineeringAnalysis modelingDesign modelingCode generation Unit testIntegration testValidation testSystem testThese slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.7Testing Strategy We begin by ‘testing-in-the-small’ and movetoward ‘testing-in-the-large’For conventional software The module (component) is our initial focusIntegration of modules followsFor OO software our focus when “testing in the small” changes froman individual module (the conventional view) to anOO class that encompasses attributes andoperations and implies communication andcollaborationThese slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.8

Strategic Issues Specify product requirements in a quantifiable mannerlong before testing commences.State testing objectives explicitly.Understand the users of the software and develop aprofile for each user category.Develop a testing plan that emphasizes “rapid cycletesting.”Build “robust” software that is designed to test itselfUse effective technical reviews as a filter prior to testingConduct technical reviews to assess the test strategyand test cases themselves.Develop a continuous improvement approach for thetesting process.These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.9Unit Testingmoduleto betestedresultssoftwareengineertest casesThese slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.10

Unit Testingmoduleto betestedinterfacelocal data structuresboundary conditionsindependent pathserror handling pathstest casesThese slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.11Unit Test Environmentdriverinterfacelocal data structuresModuleboundary conditionsindependent pathserror handling pathsstubstubtest casesRESULTSThese slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.12

Integration Testing StrategiesOptions: the “big bang”bang” approach an incremental construction strategyThese slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.13Top Down IntegrationABFtop module is tested withstubsGstubs are replaced one ata time, "depth first"Cas new modules are integrated,some subset of tests is rere-runDEThese slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.14

Bottom-Up IntegrationABFGdrivers are replaced one at atime, "depth first"Cworker modules are grouped intobuilds and integratedDEclusterThese slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.15Sandwich TestingABFTop modules aretested with stubsGCWorker modules are grouped intobuilds and integratedDEclusterThese slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.16

Regression TestingRegression testing is the re-execution of some subset oftests that have already been conducted to ensure thatchanges have not propagated unintended side effectsWhenever software is corrected, some aspect of thesoftware configuration (the program, its documentation,or the data that support it) is changed.Regression testing helps to ensure that changes (due totesting or for other reasons) do not introduce unintendedbehavior or additional errors. Regression testing may be conducted manually, by reexecuting a subset of all test cases or using automatedcapture/playback tools. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.17Smoke Testing A common approach for creating “daily builds” for productsoftwareSmoke testing steps: Software components that have been translated into code areintegrated into a “build.” A build includes all data files, libraries, reusable modules, and engineeredcomponents that are required to implement one or more product functions. A series of tests is designed to expose errors that will keep the buildfrom properly performing its function. The intent should be to uncover “show stopper” errors that have thehighest likelihood of throwing the software project behind schedule. The build is integrated with other builds and the entire product (in itscurrent form) is smoke tested daily. The integration approach may be top down or bottom up.These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.18

Object-Oriented Testing begins by evaluating the correctness andconsistency of the analysis and design modelstesting strategy changes the concept of the ‘unit’ broadens due toencapsulationintegration focuses on classes and their executionacross a ‘thread’ or in the context of a usagescenariovalidation uses conventional black box methodstest case design draws on conventionalmethods, but also encompasses specialfeaturesThese slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.19Broadening the View of “Testing”It can be argued that the review of OO analysis anddesign models is especially useful because thesame semantic constructs (e.g., classes, attributes,operations, messages) appear at the analysis,design, and code level. Therefore, a problem in thedefinition of class attributes that is uncoveredduring analysis will circumvent side effects thatmight occur if the problem were not discovereduntil design or code (or even the next iteration ofanalysis).These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.20

OO Testing Strategy class testing is the equivalent of unit testing operations within the class are testedthe state behavior of the class is examinedintegration applied three different strategies thread-based testing—integrates the set ofclasses required to respond to one input or eventuse-based testing—integrates the set of classesrequired to respond to one use casecluster testing—integrates the set of classesrequired to demonstrate one collaborationThese slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.21WebApp Testing - I The content model for the WebApp is reviewedto uncover errors.The interface model is reviewed to ensure thatall use cases can be accommodated.The design model for the WebApp is reviewedto uncover navigation errors.The user interface is tested to uncover errors inpresentation and/or navigation mechanics.Each functional component is unit tested.These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.22

WebApp Testing - II Navigation throughout the architecture is tested.The WebApp is implemented in a variety of differentenvironmental configurations and is tested forcompatibility with each configuration.Security tests are conducted in an attempt to exploitvulnerabilities in the WebApp or within its environment.Performance tests are conducted.The WebApp is tested by a controlled and monitoredpopulation of end-users. The results of their interactionwith the system are evaluated for content and navigationerrors, usability concerns, compatibility concerns, andWebApp reliability and performance.These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.23High Order Testing Validation testing System testing Alpha/Beta testing Recovery testing Focus is on software requirementsFocus is on system integrationFocus is on customer usageforces the software to fail in a variety of ways and verifies that recovery isproperly performedSecurity testing verifies that protection mechanisms built into a system will, in fact, protect itfrom improper penetration Stress testing Performance Testing executes a system in a manner that demands resources in abnormal quantity,frequency, or volumetest the run-time performance of software within the context of an integratedsystemThese slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.24