DOC PREVIEW
UMD CMSC 132 - Program Testing

This preview shows page 1-2-19-20 out of 20 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CMSC 132: Object-Oriented Programming IIProgram TestingDepartment of Computer ScienceUniversity of Maryland, College ParkOverviewTestingTypes of testingLevels of testingProgram TestingGoalDetect and eliminate errors in programFeedback to improve softwareSpecification changesAdd new functionalityExtremely important for success!Program TestingEmpirical testingTest software with selected test casesMore scalable than verificationNot guaranteed to detect all errorsTesting – TerminologyTest caseIndividual testTest suiteCollection of test casesTest harnessProgram that executes a series of test casesTest frameworkSoftware that facilitates writing & running testsExample – JUnitTesting – TerminologyTest driverProgram to create environment for running testsDeclares variables, creates objects, assigns valuesExecutes code and displays results of testsStubSkeleton code in place of unfinished method / classSimply return if calledPossibly print message indicating stub calledAllows software testing to beginTesting – TerminologyTester (Quality Assurance)Person devising and / or performing testsMore effective if 2nd person writes testsWalkthroughProgrammer explains code to 2ndpersonTypes of TestingClear box testingAllowed to examine codeAttempt to improve thoroughness of testsBlack box testingNo knowledge of codeTreat program as “black box”Test behavior in response to inputsLevels (Stages) of Testing1.Unit test2.Integration test3.System test4.Acceptance testUnit TestTest individual units extensivelyClassesMethodsCentral part of Extreme Programming (XP)Extensive unit testing during developmentPair programming (1 coder, 1 tester)Design unit tests along with specificationApproachTest each method of classTest every possible flow path through methodFlow PathUnique execution sequence through programExample S1while (B1) {if (B2)S2elseS3}FlowsS1S1, S2S1, S3S1, S2, S2S1, S2, S3S1, S3, S2S1, S3, S3…Unit Test – Flow PathNot possible to test all flow pathsMany paths by combining conditionals, switchesInfinite number of paths for loopsNew paths caused by exceptionsTest coverageWhether code is executed by some test caseAlternative to flow pathEnsure high % (if not all) of lines of code testedDoes not capture all possible flow pathsEven if all lines of code tested by some test caseUnit Test – Test CoverageAutomated test coverage Performed by submit server For code, reports # tests executing codeFor set of tests selected (from link)E.g., all public tests, individual testFor conditionals, reports X/Y whereX = # tests executing TrueY = # tests executing FalseColorGreen = executed by some test casePink = not executedUnit Test – Test Coverage ExampleIntegration TestTest interaction between unitsPossible units fail when combinedMay find problems in specificationsApproachTest units togetherProceed bottom up, in increasing sizeExample test sequence1.AB, AC, AD, CD, CE2.ACD3.ABCDEBACDESystem TestTest entire softwareInclude all components of softwareIn context in which software will be usedEnsure all pieces of software interact correctlyAcceptance TestTest full functionality of softwareEnsure program meets all requirementsApproachPlace software in user environmentTest software withReal-world dataReal usersTypical operating conditionsTest cases selected by usersAcceptance Test – StagesAlpha testTest components during developmentUsually clear box testBeta testTest in real user environmentAlways black box testRegression TestEnsure functionality is not lost / changedAs software is modified / extendedApproachSave suite of tests and expected resultsRerun test suite periodically after software changesReport any loss of functionalityTypically run overnight Software is more stable when developers leave workDeveloping Test CasesQuality of testing depends on test casesTips on developing test casesDevelop test data during analysis & design phasesAttempt to exercise alternate program pathsCheck boundary conditions 1stand last iterations of loop1stand last values added to data structurePay close attention to problem specificationUML use cases →→→→ test


View Full Document

UMD CMSC 132 - Program Testing

Documents in this Course
Notes

Notes

8 pages

Recursion

Recursion

12 pages

Sorting

Sorting

31 pages

HTML

HTML

7 pages

Trees

Trees

19 pages

HTML

HTML

18 pages

Trees

Trees

19 pages

Honors

Honors

19 pages

Lecture 1

Lecture 1

11 pages

Quiz #3

Quiz #3

2 pages

Hashing

Hashing

21 pages

Load more
Download Program Testing
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Program Testing and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Program Testing 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?