1. Software Testing See also Sommerville, Chapter 8 Amman and Offut, Introduction to Software Testing, Cambridge University Press, 2008.

2. Testing Most basic form of post-hoc SQA Helps define program functionality Can be used as documentation (c.f. XP) Must ensure program is testable (c.f. PSS docs) Methods become callable Modules get looser coupling

3. Basic Terminology The system under test (SUT) can be of different types (procedural, reactive, etc.) A test case consists of a single input for the SUT A verdict is a judgment after a test case terminates – pass/fail/warning/dont know An oracle is a method to produce verdicts A test suite is a set of test cases How much have we tested? – coverage measures!

4. User Requirements Software Requirements Architecture Design Detailed design & CodingUnit Testing Integration testing The V model Integrates design and testing Time Test cases 4 System testing Acceptance testing Test cases

5. Structural Testing (Glass or white box) An error must exist along a path If tests dont exercise that path then error can never be observed So identify and exercise each path No loops – finitely many paths – good! Loops – infinitely many paths – bad! Loops + branches – exponential growth in path numbers with loop depth – very bad !!!!

6. Structural Testing - Problems What about sins of omission? – no path to go down! What about dead code – is a path possible? How to avoid redundant testing?

7. Condensation Graph Assignments1 Assignments2 Assignments3Assignments4 Halt Start Cond1 Cond2 Path analysis: 1&3, 1&4, 1&2&3, 1&2&4 …etc

8. Structural Testing Requirements These are structural requirements on a test suite They ignore functionality! Easy to define using graph theory Possible to automate generation by constraint solving Easy to measure coverage!

9. Graph Coverage A path is a sequence of nodes n 0,…, n k in a (condensation) graph G, such that each adjacent node pair, (n i, n i+1 ) forms an edge in G. A test requirement tr(.) is a predicate on paths – Node n ( p ) p has node n – Edge e (p) p has edge e

10. Graph Coverage Definition: Given a set TR of test requirements for a graph criterion C, A test suite T satisfies C on graph G if, and only if for every test requirement tr(.) TR, there is at least one path p in G such that tr(p) is true (i.e. p satisfies tr(.))

11. Why so Formal? Answer: Sometimes coverage properties become very technical to define for efficiency reasons.

12. Structural Coverage Criteria (Amman and Offut, Chapter 2) 2.1. Node Coverage (NC) TR contains each reachable node in G. 2.2. Edge Coverage (EC) TR contains each reachable path of length 1. 2.3 Edge-Pair Coverage (EPC) TR contains each reachable path of length 2.

13. 2.7. Complete Path Coverage (CPC) TR contains all paths in G. 2.8. Specified Path Coverage (SPC) TR contains a set S of test paths, where S is supplied as a parameter. Example. S contains paths that traverse every loop free path p in G and every loop in G both 0 and 1 times.

14. Functional Testing (Black-box Testing) Black-box = structure of code is invisible +Tests the specification not the code + Insensitive to code refactoring -Hard to find test verdicts – aka oracle problem -Hard to define coverage -Huge volume of testing – user profiles? -Use cases are an excellent source of tests

15. Random Testing Generate input vectors (or sequences) at random, fire into system and observe. Easy or tricky to implement – Low level data types … e.g. Int … easy – High level data types … e.g. graphs … tricky High volume of test cases … but is that good structural coverage? Good for low input dimension 1-5? – But poor for high input dimension

16. Random Testing Oracle step is difficult to automate without precise requirements Set up and tear down must also be considered Does random distribution match expected distribution? Are some data combinations meaningless? Data interdependencies and constraints! – Example consider calendar combinations: – Year/month/day/day of week – 1961/02/29/Wednesday … is this legal or not? Can try to filter out bad data but this can be very slow

17. k-wise testing Some components have fixed input size k e.g. a method myMethod(X:string,Y:char,Z:int) We need test vectors of length k i.e. ( i 1, …, i k ) Choose (say) C=10 input values V i = v i 1,…,v i c for each 1 i k Test suite S k is all combinations of V 1,…, V k Cartesian Product S = V 1 … V k Test suite size S is then C k = 10 k Probably not feasible for S 10,000

18. Example Suppose k = 3, C = 2, then C k = 2 3 = 8 V 1 = Sat, Sun V 2 = A, B V 3 = 1, 2 S 3 = (Sat, A, 1), (Sun, A, 1), (Sat, B, 1), (Sun, B, 1), (Sat, A, 2), (Sun, A, 2), (Sat, B, 2), (Sun, B, 2) Clearly S 3 has size 8 In general S k has size C k which is exponential in k.

19. n-Wise Testing – for nk For 1 ik, let c i be a fixed value from V i An n-wise test is a vector ( i 1, …, i k ) such that n elements are chosen from V 1,…, V k and the rest are chosen from c 1, …, c k. Let S n be the set of all n-wise tests.

20. Example: 1-wise testing Suppose n = 1 and let c 1 = Sat, c 2 = A, c 3 = 1 V 1 = Sat, Sun V 2 = A, B V 3 = 1, 2 S 1 = (Sat, A, 1), (Sun, A, 1), (Sat, B, 1), (Sat, A, 2) Clearly S 1 has size k*(C-1)+1 which is linear in k. So S 1 is small but has limited coverage.

21. Example: 2-wise testing (aka all-pairs or pairwise testing) Suppose n = 2 and c 1 = Sat, c 2 = A, c 3 = 1 V 1 = Sat, Sun V 2 = A, B V 3 = 1, 2 S 2 = (Sat, A, 1), (Sun, A, 1), (Sat, B, 1), (Sun, B, 1) (Sat, A, 2), (Sun, A, 2), (Sat, B, 2) Clearly S 2 has size 7 which is not much smaller than S 3. In general S 2 is much smaller than S k. S 2 grows O(C 2 ), which is much slower than C k !

22. Why Pairwise Testing? Bugs involving interactions between three or more parameters are progressively less common[2]. NASA database application. 67 percent of the failures were triggered by only a single parameter value, 93 percent by two- way combinations, and 98 percent by three-way combinations [13]. 10 UNIX commands. Cohen et al. showed that the pairwise tests gave over 90 percent block coverage [9]. Medical software devices. Only 3 of 109 failure reports indicated that more than two conditions were required to cause the failure [14].

23. Why Pairwise Testing Browser and server. More than 70 percent of bugs were detected with two or fewer conditions (75 percent for browser and 70 percent for server) and approximately 90 percent of the bugs reported were detected with three or fewer conditions (95 percent for browser and 89 percent for server) [13]. User interface software at Telcordia. Studies [8] showed that most field faults were caused by either incorrect single values or by an interaction of pairs of values. Their code coverage study also indicated that pairwise coverage is sufficient for good code coverage. Established tools, e.g. PICT See www.pairwise.org

24. Test Cases from Use Cases Instantiate a scenario with concrete data values, and expected results. Different flows lead to different use cases – Sunny day and rainy day scenarios Use graph coverage to measure use case coverage Structured and easy to use Natural focus on most significant use cases Good approach to system and acceptance testing, but may be difficult and unit and integration levels

25. UseCaseName: PurchaseTicket Precondition: The passenger is standing in front of ticket distributor and has sufficient money to purchase a ticket. Sequence: 1.The passenger selects the number of zones to be travelled, If the passenger presses multiple zone buttons, only the last button pressed is considered by the distributor. 2.The distributor displays the amount due 3.The passenger inserts money

26. 4. The passenger selects a new zone before inserting sufficient money, the distributor returns all the coins and bills inserted by the passenger 5. If the passenger inserted more money than the amount due the distributor returns excess change. 6. The distributor issues ticket. 7. The passenger picks up the change and ticket.

27. TestCaseName: PurchaseTicket_SunnyDay Precondition: The passenger is standing in front of ticket distributor and has two 5 notes and 3 * 10 Cent coins Sequence: 1. The passenger presses in succession the zone buttons 2, 4, 1 and 2 2. The distributor should display in succession the fares 1.25 2.25, 0.75 and 1.25 3. The passenger inserts a 5 note 4. The distributor returns 3*1 coins, 75Cent and a 2-zone ticket.

28. Postcondition The passenger has one 2-zone ticket We should also derive test cases that exercise rainy day scenarios (when something goes wrong) to test robustness.

29. Unit Testing with JUnit Developed by the XP community 2002 Framework for automating the execution of unit test for Java classes Write new test cases by subclassing the TestCase class Organise TestCases into TestSuites Automates testing process Built around Command and Composite patterns

30. Why use Junit? Junit tightly integrates development and testing, supports the XP approach Allows you to write code faster while increasing quality (???) – Can refactor code without worrying about correctness JUnit is simple. – Easy as running the compiler on your code

31. JUnit tests check their own results (oracle step) and provide immediate feedback – No manual comparison of expected with actual – Simple visual feedback JUnit tests can be composed into a hierarchy of test suites – Can run tests for any layer in the hierarchy Writing JUnit tests is inexpensive – No harder than writing a method to exercise the code JUnit tests increase the stability of software – More tests = more stability

32. Junit tests are developer tests – Tests fundamental building blocks of system – Tests delivered with code as a certified package Junit tests are written in Java – Seamless bond between test and code under test – Test code can be refactored into software code and vice-versa – Data type compatibility (float, double etc.) Junit is free

33. Junit Design A TestCase is a Command object A class of test methods subclasses TestCase A TestCase has public testXXX() methods To check expected with actual output invoke assert() method Use setUp() and tearDown() to prevent side effects between subsequent testXXX() calls

34. Test Run(TestResult) Test run(TestResult) setUp() tearDown() runTest() TestSuite addTest() Run(TestResult) Test setUp() tearDown() run(TestResult) testName:String

35. TestCase objects can be composed into TestSuite hierarchies. Automatically invoke all the testXXX() methods in each object A TestSuite is composed of TestCase instances or other TestSuite instances Nest to arbitrary depth Run whole TestSuite with a single pass/fail result Get your own installation instructions

36. Writing a Test Case Define a subclass of TestCase Override the setUp() method to intialise object(s) under test Optionally override the tearDown() method to release objects under test Define 1 or more public testXXX() methods hat exercise the object(s) under test and assert expected results

37. Import junit.framework.TestCase Public class ShoppingCartTest extends TestCase Private ShoppingCart cart; Private Product book1; Protected void setUp() Cart = new ShoppingCart(); Book1 = new Product(myTitle, 50); Cart.addItem(book1)

38. Protected void tearDown() //release objects under test here if necessary Public void testEmpty() Cart.empty(); // empty out cart assertEquals(0,cart.getItemCount() );

39. Public void testAddItem() Product book2 = new Product(title2, 65); cart.addItem(book2); double expectedBalance = book1.getPrice() + book2.getPrice(); assertEquals(expectedBalance, cart.getBalance()); assertEquals(2, cart.getItemCount() );

40. Public void testRemoveItem() throws productNotFoundException Cart.removeItem(book1); assertEquals(1, cart.getItemCount() ); Public void testRemoveItemNotInCart() try Product book3 = new Product(title3, 10); Cart.removeItem(book3); fail(should raise a ProductNotFoundException); Catch(ProductNotFoundException expected) //passed the test! // of class ShoppingCartTest