Defect testingTopics coveredThe testing processSlide 4Testing prioritiesTest data and test casesThe defect testing processBlack-box testingSlide 9Equivalence partitioningSlide 11Slide 12Structural testingWhite-box testingPath testingProgram flow graphsCyclomatic complexityBinary search flow graphIndependent pathsIntegration testingIncremental integration testingApproaches to integration testingTop-down testingBottom-up testingTesting approachesInterface testingSlide 27Interfaces typesInterface errorsInterface testing guidelinesStress testingObject-oriented testingTesting levelsObject class testingWeather station object interfaceObject integrationApproaches to cluster testingScenario-based testingCollect weather dataWeather station testingTesting workbenchesA testing workbenchTetsing workbench adaptationKey pointsSlide 45©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 1Defect testingTesting programs to establish the presence of system defects©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 2Topics coveredDefect testingIntegration testingObject-oriented testingTesting workbenches©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 3The testing processComponent testing •Testing of individual program components•Usually the responsibility of the component developer (except sometimes for critical systems)•Tests are derived from the developer’s experienceIntegration testing•Testing of groups of components integrated to create a system or sub-system•The responsibility of an independent testing team•Tests are based on a system specification©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 4Defect testingThe goal of defect testing is to discover defects in programsA successful defect test is a test which causes a program to behave in an anomalous wayTests show the presence not the absence of defects©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 5Only exhaustive testing can show a program is free from defects. However, exhaustive testing is impossibleTests should exercise a system's capabilities rather than its componentsTesting old capabilities is more important than testing new capabilitiesTesting typical situations is more important than boundary value casesTesting priorities©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 6Test data Inputs which have been devised to test the systemTest cases Inputs to test the system and the predicted outputs from these inputs if the system operates according to its specificationTest data and test cases©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 7The defect testing processDesign testcasesPrepare testdataRun programwith test dataCompare r esultsto test casesTestcasesTestdataTestresultsTestreports©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 8Black-box testingAn approach to testing where the program is considered as a ‘black-box’The program test cases are based on the system specification Test planning can begin early in the software process©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 9Black-box testingIeInput test dataOeOutput test resultsSystemInputs causinganomalousbehaviourOutputs which revealthe presence ofdefects©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 10Equivalence partitioningInput data and output results often fall into different classes where all members of a class are relatedEach of these classes is an equivalence partition where the program behaves in an equivalent way for each class memberTest cases should be chosen from each partition©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 11Equivalence partitioningSystemOutputsInvalid inputs Valid inputs©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 12Partition system inputs and outputs into ‘equivalence sets’•If input is a 5-digit integer between 10,000 and 99,999, equivalence partitions are <10,000, 10,000-99, 999 and > 10, 000Choose test cases at the boundary of these sets•00000, 09999, 10000, 99999, 10001Equivalence partitioning©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 13Sometime called white-box testingDerivation of test cases according to program structure. Knowledge of the program is used to identify additional test casesObjective is to exercise all program statements (not all path combinations)Structural testing©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 14White-box testingComponentcodeTestoutputsTest dataDerivesTests©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 15Path testingThe objective of path testing is to ensure that the set of test cases is such that each path through the program is executed at least onceThe starting point for path testing is a program flow graph that shows nodes representing program decisions and arcs representing the flow of controlStatements with conditions are therefore nodes in the flow graph©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 16Describes the program control flow. Each branch is shown as a separate path and loops are shown by arrows looping back to the loop condition nodeUsed as a basis for computing the cyclomatic complexityCyclomatic complexity = Number of edges - Number of nodes +2Program flow graphs©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 17The number of tests to test all control statements equals the cyclomatic complexityCyclomatic complexity equals number of conditions in a programUseful if used with care. Does not imply adequacy of testing. Although all paths are executed, all combinations of paths are not executedCyclomatic complexityBinary search flow graph1234657while bottom <= topif (elemArray [mid] == key(if (elemArray [mid]< key89bottom > top©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 191, 2, 3, 8, 91, 2, 3, 4, 6, 7, 21, 2, 3, 4, 5, 7, 21, 2, 3, 4, 6, 7, 2, 8, 9Test cases should be derived so that all of these paths are executedA dynamic program analyser may be used to check that paths have been executedIndependent