1. Chapter 8 Testing the Programs

2. Integration Testing  Combine individual comp., into a working s/m.  Test strategy gives why & how comp., are combined to test the working s/m.  Strategy affects not only the integration timing, coding, cost & thoroughness of the testing.

3.  S/m viewed as hierarchy of comps.  Approaches  Bottom-up  Top-down  Big-bang  Sandwich testing  Modified top-down  Modified sandwich

4. Bottom-up Integration  Merging comp.,  Lowest level of s/m hierarchy is tested individually first then next comp., are those that call the previously tested comp.,  Component Driver: a routine that calls a particular component and passes a test case to it.  Drawback – functionally decomposed s/m – is that top level comp., are important but last to be tested.  Top level are more general, whereas bottom level are more specific.  Bottom up testing is most sensible for OOpgms.,

5.  System viewed as a hierarchy of components  The sequence of tests and their dependencies  We need comp., driver for E,F,G

6. Top-Down Integration  Reverse of bottom-up  Top level – one controlling comp., is tested by itself.  Then all comps., called by the tested comp., are combined & tested  Stub: a special-purpose program to simulate the activity of the missing component  The stub answers the calling seq., & passes back o/p data that lets the testing process continue.

7.  Only A is tested by itself  Stubs needed for B,C & D.  Top down allows the test team to exercise one fn., at a time  Test cases defined in terms of fns., being examined.  Design faults abt fnality., addressed at the beginning of testing.  Drivers pgms., are not needed.  Writing stubs can be difficult, its correctness may affect the validity of the test.

8.  Drawback with top-down testing is possibility that a very large no., of stubs may be required.  One way to avoid is to alter the strategy slightly  Modified Top-Down Integration  Each level’s components individually tested before the merger takes place.

9. Bing-Bang Integration  Used for small s/m, not practical for large s/m.  First, it requires both stubs and drivers to test the independent components  Second, b’coz all comp., are merged at once, it is difficult to find the cause of failures.  Finally, i/f faults cannot be distinguished easily

10. Sandwich Integration  Combines top down with bottom-up  Viewed system as three layers: target layer in middle, levels above the target, levels below the target.  Top down in top level & bottom up in lower layer.  Testing converges towards target layer – chosen on the basis of s/m char., & struc., of comp., hierarchy.  Ex., comp., hierarchy - Target layer in the middle level, comp., B, C, D  Drawback – it does not test the indiv., comp before integration.

11. Modified Sandwich Integration  Allows upper-level components to be tested before merging them with others

12. Comparison of Integration Strategies Bottom-upTop- down Modified top- down Bing-bangSandwichModified sandwich IntegrationEarly LateEarly Time to basic working program LateEarly LateEarly Component drivers needed YesNoYes Stubs neededNoYes Work parallelism at beginning MediumLowMediumHighMediumHigh Ability to test particular paths EasyHardEasy MediumEasy Ability to plan and control sequence EasyHard EasyHardhard

13. Testing Object-Oriented Systems  Rumbaugh ask several ques.,:  Is there a path that generates a unique result?  Is there a way to select a unique result?  Are there useful cases that are not handled?  Next check obj., & classes themselves for excesses & deficiencies  Missing obj, useless classes, associations or attributes

14. Differences Between OO and Traditional Testing  OO comp., - reused, helps minimize testing  First, test – base classes having no parents – test each fn., individually then the interactions among them.  Next – provide an alg., to update incrementally the test history for parent class.  OO unit testing is less difficult, but integration testing is more extensive

15.  The farther the gray line is out, the more the difference Requires special treatment

16. Test Planning  Test planning helps us to design & organize the tests  Test steps:  Establish test objectives  Design test cases  Write test cases  Testing test cases  Execute tests  Evaluate test results  Test obj., - tells us what kind of test cases to generate.

17.  Purpose of the Plan  Test plan explains  who does the testing?  why the tests are performed?  how tests are conducted?  when the tests are scheduled?  Contents of the Plan  What the test objectives are?  How the test will be run?  What criteria will be used to determine when the testing is complete?  Statement, branch, & path coverage at the comp., level  Top-down, bottom-up at the integration level  Resulting test plan for merging the comps., into a whole sometimes called S/m Integration Testing

18. Automated Testing Tools  Code Analysis Tool  Static analysis – src pgm before it is run  Code analyzer  Structure checker  Data analyzer  Sequence checker  Dynamic analysis – pgm is running  Program monitors: watch and report program’s behavior  Test execution – automate the planning & running of the test themselves  Capture and replay  Stubs and drivers  Automated testing environments  Test case generators – automate test case generation

19. When to Stop Testing  More faulty?  Probability of finding faults during the development

20. Stopping Approaches  Fault seeding or error seeding – to estimate no., of faults in a pgm  One team – seeds or inserts a known no., of faults  Other team – locate as many faults as possible  No. of undiscovered faults acts as indicator  The ratio: detected seeded Faults detected nonseeded faults total seeded faults total nonseeded faults  Expressing ratio formally : N = Sn /s  N – no., of nonseeded faults  S – no., seeded faults placed in a pgm.  n – actual no., of nonseeded faults detected during testing  s – no., of seeded faults detected during testing

21.  Confidence in the software, - use fault estimate to tell how much confidence we can place in the s/w we are testing.  Confidence expressed in percentage. = 1, if n >N C = S/(S – N + 1),if n ≤ N  Coverage criteria

22. Identifying Fault-Prone Code  Track the number of faults found in each component during the development  Collect measurement (e.g., size, number of decisions) about each component  Classification trees : a statistical technique that sorts through large arrays of measurement information and creates a decision tree to show best predictors  A tree helps in deciding the which components are likely to have a large number of errors

23. An Example of a Classification Tree