 CS 5380 Software Engineering Chapter 8 Testing

  • Published on

  • View

  • Download

Embed Size (px)


<p>Figures Chapter 4</p> <p>CS 5380 Software Engineering</p> <p>Chapter 8 TestingSValidation vs VerificationValidationAre we building the right product?VerificationAre we building the product right?Chapter 7 - Design and Implementation2Purpose of TestingDemonstration of fulfillment of requirementsIdentification of defectsChapter 7 - Design and Implementation3Meeting Requirements(Validation)At least one test per requirementxxxxxxxxxOften more than one testSeveral valid cases xxxxxxxxxChapter 7 - Design and Implementation4Identification of DefectsIdentifying undesirable resultsSystem crashIncorrect computationData corruptionMay need many tests</p> <p>Chapter 7 - Design and Implementation5Testing is Never FinalDijkstra: Testing can show presence of errors, not their absenceThere is always one more bugChapter 7 - Design and Implementation6How Much Testing?- Factors Driving TestingSoftware purposeSafety drives high requirementsUser expectationsSome toleranceMarketingWe lose money every day the product is not delivered</p> <p>Chapter 7 - Design and Implementation7Inspection vs TestingBoth address same issuesDoes the software meet requirements?Does the software fail in some situations?Advantage of InspectionIdentification of multiple errors at one time possibleIdentification of errors in incomplete softwareLooks beyond defectsInefficient code, poor code structure, reuseAdvantage of testingCan be automatedDetailed scenarios evaluatedChapter 7 - Design and Implementation8InspectionGives insight into the method, and hence potential flawsDoes not give us automation, regressionMay be difficult to comprehend all casesComplements other methodsGood review point is before check-inChapter 7 - Design and Implementation9Testing StagesDevelopmentDone during development, by programmersOften on development systemsReleaseTesting complete system before deliveryGenerally on a separate test systemFormal test plansUserTest by users, on their systemsReal world applicationBeta testingChapter 7 - Design and Implementation10Development TestingLevelsUnitObject, function levelComponentInteraction of several objectsFocus on component interactionsSystemEntire systemFocus on interactionsChapter 7 - Design and Implementation11Unit TestingObjectAutomatedSetupPerform operationEvaluate ResultsExecutionNot UIChapter 7 - Design and Implementation12State Diagram TestingSystem or object for which you have a state diagramTest all transitionsState, eventChapter 7 - Design and Implementation13Activity Diagram TestingDiagram clearly shows alternatives to be tested.Chapter 7 - Design and Implementation14Chapter 7 - Design and Implementation15Component TestingTesting of composite components Several objectsInterfaces to considerParameter (object)Procedural (object) Shared memoryMessage passing Chapter 7 - Design and Implementation16Component ExamplesObjectsFast city grocersWeb browser</p> <p>Chapter 7 - Design and Implementation17System TestingTesting all components that come togetherInternal objectsExternal objects GUI, dbExternal systems credit cardChapter 7 - Design and Implementation18Regression TestingTesting that past cases should still workAutomation is key to effective regression testingChapter 7 - Design and Implementation19Release testingSimilar to system testing, butSeparate team (not development)Goal: more about meeting requirements than finding bugsGoal: verify to the customer that the software is readyChapter 7 - Design and Implementation20Scenario TestingComplete scenarios with dataMay be followed by userMay be automated.Chapter 7 - Design and Implementation21Performance TestingResponse timesConcurrency responseIdentify degradation issuesFailure due to unexpected combination of eventsStress the system beyond normal use</p> <p>Chapter 7 - Design and Implementation22User TestingAlpha users with developersBeta Users in production modeGenerally to identify bugsAcceptance testing Customer acceptanceAcceptance plan neededChapter 7 - Design and Implementation23Release CutoffSoftware released when number of bugs/type tolerableUnusual case causes software to crashUnexplained loss of data single record lostData corrupt (verified in customer data)Single minor function (.1% of users use this) failsSoftware lacks feature (50% of users want it)</p> <p>Chapter 7 - Design and Implementation24Extent of TestingDepends on PurposeHealth/Safety Critical insulin pumpCredit card retentionWeb orderingDepends on User ExpectionsDepends on Marketing pressuresNew customer delivery neededCustomer testimonials/referencesFeatures for existing customersExisting customer response to errorsChapter 7 - Design and Implementation25TestersWho does test?Object level?Programmer other than developerComponent level?Programmers/ Test bed specialistsIntegration level?User domain / ProgrammersFull scenarioCustomers / BetaChapter 7 - Design and Implementation26Experience with TestersSearch for people that test wellMost people will use a system for 1 hour and say it has 2 bugsAnother tester might use the same software for 10 minutes and find 10 bugsChapter 7 - Design and Implementation27</p>