1. Conquering Complex and Changing Systems Object-Oriented Software Engineering Art for Chapter 9, Testing

2. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2 Figure 9-1. Taxonomy of quality control activities (UML class diagram).

3. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3 Figure 9-2. Testing activities and their related work products (UML activity diagram). Swimlanes indicate who executes the test. (diagram continued on next slide) Object design Functional test Structure test Unit test UserClientDeveloper Integration test From ODD Integration strategy From TP System decomposition From SDD Functional requirements From RAD Continued on next slide

4. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4 Figure 9-2. Continued from previous slide. Acceptance test User manual Performance test Daily operation Functional test Installation test Field test UserClientDeveloper From RAD Functional requirements From RAD Nonfunctional requirements Project agreement

5. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5 Figure 9-3. Model elements used during testing (UML class diagram). is caused by ** Test case FailureFaultError Test suite is caused by * * CorrectionComponent Test stub Test driver exercises is revised by findsrepairs * ** * * * 1…n * *

6. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6 Figure 9-4. An example of a fault.

7. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7 Figure 9-7. An example of an error.

8. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8 Figure 9-8. A fault can have an algorithmic cause.

9. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9 Figure 9-9. A fault can have a mechanical cause, such as an earthquake.

10. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10 Figure 9-10. Test model with test cases. TestA consists of two tests, TestA1 and TestA2. TestB and TestC can be tested independently, but only after TestA has been performed. TestA:TestCase TestA1:TestCase TestA2:TestCase TestB:TestCaseTestC:TestCase precedes

11. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11 Figure 9-11. Use of the Bridge design pattern to interface to a component that is not yet complete, not yet known or unavailable during testing of another component (UML class diagram).

12. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12 Figure 9-12. Interface for a method computing the number of days in a given month (Java). The getNumDaysInMonth() method takes two parameters, a month and a year, both specified as integers. class MyGregorianCalendar {... public static int getNumDaysInMonth(int month, int year) {…}... }

13. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13 Figure 9-13. Equivalent flow graph for the getNumDaysInMonth() method implementation of Figure 9-14 (UML activity diagram). [year < 1] [month in (1,3,5,7,10,12)] n=32 throw2n=29 return throw1 n=28 n=30 [month in (4,6,9,11)] [month == 2][leap(year)]

14. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14 Figure 9-14. An example of a (faulty) implementation of the getNumDaysInMonth() method (Java). (continued on next slide) public class MonthOutOfBounds extends Exception {…}; public class YearOutOfBounds extends Exception {…}; class MyGregorianCalendar { public static boolean isLeapYear(int year) { boolean leap; if (year%4) { leap = true; } else { leap = false; } return leap; } /* … continued on next slide */

15. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15 Figure 9-14. An example of a (faulty) implementation of the getNumDaysInMonth() method (Java). (continued from previous slide) /* … continued from previous slide */ public static int getNumDaysInMonth(int month, int year) throws MonthOutOfBounds, YearOutOfBounds { int numDays; if (year < 1) { throw new YearOutOfBounds(year); } if (month == 1 || month == 3 || month == 5 || month == 7 || month == 10 || month == 12) { numDays = 32; } else if (month == 4 || month == 6 || month == 9 || month == 11) { numDays = 30; } else if (month == 2) { if (isLeapYear(year)) { numDays = 29; } else { numDays = 28; } } else { throw new MonthOutOfBounds(month); } return numDays; }... }

16. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 16 Figure 9-15. Equivalent flow graph for the (faulty) isLeapYear() method implementation of Figure 9-14 (UML activity diagram) and derived tests. The test in italic is redundant with a test we derived for the getNumDaysInMonth() method.

17. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17 Figure 9-16. UML statechart diagram and resulting tests for 2Bwatch set time function. Only the first eight stimuli are shown. (test cases on next slide)

18. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18 Figure 9-17. Example of a hierarchal system decomposition with three layers (UML class diagram, layers represented by packages).

19. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 19 Figure 9-18. Test coverage of integration test. The test case shown cover all possible dependencies in the subsystem decomposition.

20. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 20 Figure 9-19. Sandwich testing strategy (UML activity diagram). None of the components in the target layer (i.e, B, C, D) are unit tested.

21. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 21 Figure 9-20. An example of modified sandwich testing strategy (UML activity diagrams). The components of the target layer are unit tested before they are integrated with the top and bottom layers.

22. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22 Figure 9-21. An example of use case model for a subway ticket distributor (UML use case diagram).

23. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 23 Figure 9-24. Example of a PERT chart for a schedule of the sandwich tests shown in Figure 9-19.