1University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 1Lecture 20:Black Box & Exploratory TestingUse Cases as Test CasesQuicktestsExploratory TestingWhen to stop testingUniversity of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 2Generating Tests from Use Cases1 Test the Basic Flow2 Test the Alternate FlowsBuy a ProductPrecondition: Customer has successfully logged inMain Success Scenario:Customer browses catalog and selects items to buyCustomer goes to check outCustomer fills in shipping information (address, next-day or 3-day delivery)System presents full pricing informationCustomer fills in credit card informationSystem authorizes purchaseSystem confirms sale immediatelySystem sends confirming email to customerPostcondition: Payment was received in full, customer has received confirmationExtensions:3a: Customer is Regular Customer .1 System displays current shipping, pricing and billing information .2 Customer may accept or override these defaults, returns to MSS at step 66a: System fails to authorize credit card .1 Customer may reenter credit card information or may cancelBuy aProductCustomerStart Use CaseEnd Use CaseEnd Use CaseEnd Use CaseBasic FlowAlternate Flow 1Alternate Flow 2AlternateFlow 3Alternate Flow 42University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 3Generating Tests from Use CasesBuy a ProductPrecondition: Customer has successfully logged inMain Success Scenario:Customer browses catalog and selects items to buyCustomer goes to check outCustomer fills in shipping information (address, next-day or 3-day delivery)System presents full pricing informationCustomer fills in credit card informationSystem authorizes purchaseSystem confirms sale immediatelySystem sends confirming email to customerPostcondition: Payment was received in full, customer has received confirmationExtensions:3a: Customer is Regular Customer .1 System displays current shipping, pricing and billing information .2 Customer may accept or override these defaults, returns to MSS at step 66a: System fails to authorize credit card .1 Customer may reenter credit card information or may cancelBuy aProductCustomer3 Test the PostconditionsAre they met on all pathsthrough the use case?Are all postconditions met?4 Break the PreconditionsWhat happens if this is not met?In what ways might it not bemet?5 Identify options for eachvariableselect combinations of optionsfor each test caseUniversity of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 4Classes of input variablesvalues that trigger alternativeflowse.g. invalid credit carde.g. regular customertrigger different error messagese.g. text too long for fielde.g. email address with no “@”inputs that cause changes in theappearance of the UIe.g. a prompt for additional informationinputs that causes differentoptions in dropdown menuse.g. US/Canada triggers menu ofstates/provincescases in a business rulee.g. No next day delivery after 6pmborder conditionsif password must be min 6 characters,test password of 5,6,7 charactersCheck the default valuese.g. when cardholder’s name is filledautomaticallyOverride the default valuese.g. when the user enters different nameEnter data in different formatse.g. phone numbers:(416) 555 1234416-555-1234416 555 1234Test country-specificassumptionse.g. date order: 5/25/08 vs. 25/5/083University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 5Limits of Use Cases as Test CasesUse Case Tests good for:User acceptance testing“Business as usual” functional testingManual black-box testsRecording automated scripts for commonscenariosLimitations of Use CasesLikely to be incompleteUse cases don’t describe enough detailof useGaps and inconsistencies between usecasesUse cases might be out of dateUse cases might be ambiguousDefects you won’t discover:System errors (e.g. memory leaks)Things that corrupt persistent dataPerformance problemsSoftware compatibility problemsHardware compatibility problemsUniversity of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 6Quick TestsA quick, cheap teste.g. Whittaker “How to Break Software”Examples:The Shoe Test (key repeats in any input field)Variable boundary testingVariability Tour: find anything that varies, and vary it as far as possible in everydimension4University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 7Whittaker’s QuickTestsExplore the input domain1. Inputs that force all the errormessages to appear2. Inputs that force the software toestablish default values3. Explore allowable character sets anddata types4. Overflow the input buffers5. Find inputs that may interact, and testcombinations of their values6. Repeat the same input numeroustimesExplore the outputs7. Force different outputs to begenerated for each input8. Force invalid outputs to be generated9. Force properties of an output tochange10. Force the screen to refreshExplore stored data constraints11. Force a data structure to store toomany or too few values12. Find ways to violate internal dataconstraintsExplore feature interactions13. Experiment with invalidoperator/operand combinations14. Make a function call itself recursively15. Force computation results to be toobig or too small16. Find features that share dataVary file system conditions17. File system full to capacity18. Disk is busy or unavailable19. Disk is damaged20. invalid file name21. vary file permissions22. vary or corrupt file contentsUniversity of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 8Interference TestingGenerate
View Full Document
Unlocking...