1. CS48715-1/51 Illinois Institute of Technology CS487 Software Engineering Software Testing Techniques Mr. David A. Lash

2. CS48715-2/51 Why Test? u Testing is the filter to catch bugs before the are “discovered” by customer – Every time the program is run by a customer, it generates a “test-case”. u Software development is a human activity with huge potential for errors u Testing before release helps assure quality and save money

3. CS48715-3/51 Testing Steps u Start at testing each individual new component and work way out – Unit test – Integration test – High Order Test – Customer Acceptance testing u Different testing techniques are used at different times in the process u A test specification is often used as a testing road-map that is generally reviewed by a team.

4. CS48715-4/51 u Purpose of testing is... – To find errors u A good test... – Trys to discover undetected errors – Is successful when errors are found u To design good test cases must understand the system and the software development process. u Zero Defects is not possible. – Always a condition or usage that can lead to an incorrect behavior. – Done testing when continued testing is no longer economical. Testing Objectives

5. CS48715-5/51 Tester VS Developer It is critical that developers and testers work together as a team

6. CS48715-6/51 Software Quality Assurance Modes u Verification – “Are we building the product right?” – Does product meet requirements during this particular phase – Can and should be done as part of implementation. u Validation – “Are we building the right product?” – Evaluating software at end of software development process VS requirements – 3rd party is generally most effective validators (developer ego can interfere with judgment). u Formal Reviews u Quality and Configuration audits

7. CS48715-7/51 Testing Goals u Show that the program is correct. – Zero Defect Software is not possible. u There is always some condition that you are not aware of that can cause a incorrect behavior. – Microsoft does test. u Their testing covers “main-line” systems. u There are several million possible hardware configurations. u It is the integrators responsibility to ensure that the system works with Microsoft Software.

8. CS48715-8/51 Testing Goals - Reality u To Have “confidence” in the software system. u To Find all major defects – You must first define major. – Defect scale u To find all major defects with given resources – Number of testers – Amount of time. u Design a set of test cases that have a high probability of finding defects.

9. CS48715-9/51 Testing Case Design u Test cases should be designed to have the highest likelihood of finding problems u Can test by either – Black-box or using the specifications of what the software should do u Tests are derived from the I/O specification. u Used in most functional tests. u A.K.A. data-driven, input/output-driven. – White-Box - testing internal paths and working of the software u Examine internal program structure and derive tests from an examination of the program’s logic. u Used to develop test cases for unit and integration testing u A.K.A. Glass-box, Logic-driven, Structural.

10. CS48715-10/51 White-Box Strategies u Statement – Requires each statement of the program to be executed at least once. u Branch – Requires each branch to be traversed at least once. u Multi-condition – Requires each condition in a branch be evaluated.

11. CS48715-11/51 White-Box Strategies u Basis Path – Execute all control flow paths through the code. Based on Graph Theory. u Thomas McCabe’s Cycolmatic Complexity: u V(g) : #edges - #nodes + 2 u Data Flow – Selects test data based on the locations of definition and the use of variables. u And a number of others

12. CS48715-12/51 Statement Coverage u The criterion is to require every statement in the program to be executed at least once u Weakest of the white-box tests. u Specified by the F.D.A. as the minimum level of testing.

13. CS48715-13/51 Statement Coverage u Example: voidexample(int a, int b, float *x) { 1if ((a>1) && (b==0)) 2x /= a; 3if ((a==2) || (x > 1) 4x++; } u Test case(s) 1.a=2, b=0, x=3

14. CS48715-14/51 Statement Coverage u Test Case a=2, b=0 & x=3 u Coverage – acbed u What happens with data that takes: – abed – abd

15. CS48715-15/51 Branch Coverage u This criterion states that one must write enough test cases such that each decision has a true and false outcome at least once. u A.K.A. Decision coverage u More comprehensive than statement coverage.

16. CS48715-16/51 Branch Coverage u Example: voidexample(int a, int b, float *x) { 1if ((a>1) && (b==0)) 2x /= a; 3if ((a==2) || (x > 1) 4x++; } u Test case(s) 1.a=2, b=0, x=3 2.a=3, b=1, x=1

17. CS48715-17/51 Branch Coverage u Test Case 1. a=2, b=0 & x=3 2. a=3, b=1 & x=1 u Coverage 1. ace 2. abd u What happens with data that takes: – abe, or – acd

18. CS48715-18/51 Multiple-condition Coverage u This criterion requires one to write sufficient test cases such that all possible combinations of condition outcomes in each decision, and all points of entry are invoked at least once. u More comprehensive than branch coverage u First step is to identify the test conditions – ifs, whiles, for – reduce to simple predicates

19. CS48715-19/51 Multiple-condition Coverage u Example: voidexample(int a, int b, float *x) { 1if ((a>1) && (b==0)) 2x /= a; 3if ((a==2) || (x > 1) 4x++; } u Test Conditions a>1, b=0; a>1, b!=0; a<=1, b=0; a<=1, b!=0; a==2, x > 1; a!=2, x>1; a==2, x<=1; a!=2, x<=1.

20. CS48715-20/51 Multiple-condition Coverage u Test Conditions 1. a>1, b=05. a=2, x >1 2. a>1, b!=06. a=2, x 1 4. a<=1,b!=08. a!=2, x<=1 u Test Cases 1. a=2, b=0 & x=4 (1,5) 2. a=2, b=1 & x=1 (2,6) 3. a=1, b=0 & x=2 (3,7) 4. a=1, b=1 & x=1 (4,8) u Coverage – all

21. CS48715-21/51 Basis Path u Execute all independent flow paths through the code. Based on a flow graph. – An independent flow path is on that introduces at least 1 new set of statements or conditions – Must move along at least 1 new edge on flow graph – Flow graph shows the logical control flow using following notation: Sequence If while until

22. CS48715-22/51 Control Flow Example 1 2 3 4 5 6 78 910

23. CS48715-23/51 Corresponding Flow Graph

24. CS48715-24/51 Number of Independent Paths

25. CS48715-25/51 Another Example

26. CS48715-26/51 Corresponding Flow Graph

27. CS48715-27/51 Corresponding Flow Graph

28. CS48715-28/51 Number of Paths V(g) = E - N + 2 17-13 + 2 = 6 R = 6

29. CS48715-29/51 Black-Box Testing u Focuses on functional requirements of the software without regard to the internal structure. u A.K.A. data-driven, input/output-driven or behavior testing u Used in most system level testing – Functional, – Performance, etc. u Tests set up to exercise full functional requirements of system

30. CS48715-30/51 Black Box Testing Find Errors in... u Incorrect or missing functions (compare to white box) u Interface errors u Errors in External Data structures u Behavior performance problems (Combinations of input make it behave poorly). u Initialization and Termination errors (Sensitive to certain inputs (e.g., performance) u Blackbox done much later in process than white box.

31. CS48715-31/51 Black-box Strategies u Exhaustive input testing – A test strategy that uses every possible input condition as a test case. – Ideal u Random – Test cases are created from a pseudo random generator. – Broad spectrum. Not focused. – Hard to determine the result of the test.

32. CS48715-32/51 Black-box Strategies u Equivalence Partitioning – A black-box testing method that divides the input domain of a program into classes of data which test cases can be derived. u Boundary Value Analysis – A test case design technique that complements equivalence partitioning, by selecting test cases at the “edges” of the class. u And others.

33. CS48715-33/51 Equivalence Partitioning u Divides the input domain of a program into classes of data which test cases can be derived. – 1 test case uncovers classes of errors u Helps reduce the number of inputs u What are the properties of a well-selected test cases: – It reduces, by more than one, the number of test case that must be developed. – It covers a large set of other possible test cases.

34. CS48715-34/51 Identifying Equivalence Classes u Take each input condition (a sentence or phrase in the specification) partition or divide it into 2 or more classes. u Class – Valid equivalence classes – Invalid equivalence classes

35. CS48715-35/51 Rules for Equivalence Classes u Range - If an input condition specifies a range (i.e. n is an integer from 1 to 1000). – 1 valid(1< n < 1000) – 2 invalid(n 1000) u Specified Value - A black-box testing method that If an input condition specifies a specific value ( i.e. 6 character string) identify: – 1 valid(6 character string) – 2 invalid(5 character string, 7 char string)

36. CS48715-36/51 Rules for Equivalence Classes u Value Set - If the input specifies a set of valid values, define: – 1 valid condition within the set. – 1 invalid condition outside the set.

37. CS48715-37/51 Rules for Equivalence Classes u Boolean - If an input condition specifies a “must be” situation (e.g. “first character alpha”) then identify: – 1 valid (first character alpha). – 1 invalid (first character not alpha). u If there is any reason to believe that elements in an equivalence class are not handled in an identical manner by the program, split the equivalence class into smaller equivalence classes.

38. CS48715-38/51 Equivalence Partition Example

39. CS48715-39/51 Equivalence Partition Example

40. CS48715-40/51 Boundary Value Analysis u Experience shows that test cases exploring boundary conditions have a high payoff. – E.g., Most program errors occur in loop control. u Different from equivalence partitioning: – Rather than any element in class, BVA selects tests at edge of the class. – In addition to input condition, test cases can be derived for output conditions. u But similar to Equivalence partitioning...

41. CS48715-41/51 Guideline for Boundary-Value Analysis u If an input condition specifies a range of values, write test cases for the ends of the range, and invalid-input test cases for situations just beyond the ends. – If a domain of an input is -1.0 to 1.0 write test cases for the situation -1.01 to 1.01. – Or in general, if bounded by a and b write test cases just above and below

42. CS48715-42/51 Guideline for Boundary-Value Analysis u If an input condition specifies a number of values, write test cases for the minimum and maximum number of values and one beneath and beyond these values. – For example an input file can contain 1-255 records, write test cases for 0, 1, 255 and 256

43. CS48715-43/51 Guideline for Boundary-Value Analysis u Apply the preceding rules to the output. – For example, if output is a output report, then create an output report with maximum and minimum allowable table entries. u Apply rules to internal data structures... – If use an array that has 1-100 elements max then set up test cases for 0, 1, 100, 101 elements. u Look for other applications for BVA

44. CS48715-44/51 Test Case Grid

45. CS48715-45/51 Test Case Grid u Equivalence Class case and Boundary-Value analysis cases can be shown on the same table. – Separate sections for Equivalence Class cases and Boundary-Value analysis. – Equivalence Class cases first

46. CS48715-46/51 Test Case Documentation u Minimum information for a test case – Identifier – Input data – Expected output data u Recommended to add the condition being tested (hypothesis). u Format of test case document changes depending on what is being tested. u Always include design worksheets.

47. CS48715-47/51 Simple Test Case Format

48. CS48715-48/51 Test Case Formats u Testing worksheet – Test Case u Identifier (serial number) u Condition (narrative or predicate) u Input (Stimuli data or action) u Expected Output (Results) – Test Results u Actual Output (Results) u Status (Pass/Fail)

49. CS48715-49/51 PSP Test Case Format

50. CS48715-50/51 ANSI/IEEE Test Case Outline u Test-case-specification Identifier – A unique identifier u Test Items – Identify and briefly describe the items and features to be exercised by this case u Input Specifications – Specify each input required to execute the test case. u Output Specifications – Specify all of the outputs and features required of the test items.

51. CS48715-51/51 ANSI/IEEE Test Case Outline u Environmental needs – Hardware – Software – Other u Special procedural requirements – Describe any special constraints on the test procedures which execute this test case. u Interfaces dependencies – List the id’s of test cases which must be executed prior to this test case