Chapter 8 Software Testing

Software Engineering (3rd ed.), By K.
K Aggarwal & Yogesh Singh, Copyright New Age International Publishers, 2007
Software Testing
What is Testing?
Many people understand many definitions of testing : 1. Testing is the process of demonstrating that errors are not present. 2. The purpose of testing is to show that a program performs its intended functions correctly. 3. Testing is the process of establishing confidence that a program does what it is supposed to do.
These definitions are incorrect.

2
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright New Age International Publishers, 2007
Software Testing
A more appropriate definition is:
Testing is the process of executing a program with the intent of finding errors.
Software Testing
Why should We Test ?
Although software testing is itself an expensive activity, yet launching of software without testing may lead to cost potentially much higher than that of testing, specially in systems where human safety is involved. In the software life cycle the earlier the errors are discovered and removed, the lower is the cost of their removal.
Software Testing
Who should Do the Testing ?
o Testing requires the developers to find errors from their software. o It is difficult for software developer to point out errors from own creations. o Many organisations have made a distinction between development and testing phase by making different people responsible for each phase.
Software Testing
What should We Test ?
We should test the programs responses to every possible input. It means, we should test for all valid and invalid inputs. Suppose a program requires two 8 bit integers as inputs. Total possible combinations are 28x28. If only one second it required to execute one set of inputs, it may take 18 hours to test all combinations. Practically, inputs are more than two and size is also more than 8 bits. We have also not considered invalid inputs where so many combinations are possible. Hence, complete testing is just not possible, although, we may wish to do so.
Software Testing
Fig. 1: Control flow graph

Software Testing
The number of paths in the example of Fig. 1 are 1014 or 100 trillions. It is computed from 520 + 519 + 518 + + 51; where 5 is the number of paths through the loop body. If only 5 minutes are required to test one test path, it may take approximately one billion years to execute every path.
Software Testing
Some Terminologies
Error, Mistake, Bug, Fault and Failure
People make errors. A good synonym is mistake. This may be a syntax error or misunderstanding of specifications. Sometimes, there are logical errors. When developers make mistakes while coding, we call these mistakes bugs. A fault is the representation of an error, where representation is the mode of expression, such as narrative text, data flow diagrams, ER diagrams, source code etc. Defect is a good synonym for fault. A failure occurs when a fault executes. A particular fault may cause different failures, depending on how it has been exercised.
Software Testing
Test, Test Case and Test Suite
Test and Test case terms are used interchangeably. In practice, both are same and are treated as synonyms. Test case describes an input description and an expected output description.
Test Case ID Section-I (Before Execution) Purpose : Pre condition: (If any) Inputs: Expected Outputs: Post conditions: Written by: Date: Section-II (After Execution) Execution History: Result: If fails, any possible reason (Optional); Any other observation: Any suggestion: Run by: Date:
Fig. 2: Test case template
The set of test cases is called a test suite. Hence any combination of test cases may generate a test suite.
10
Software Testing
Verification and Validation
Verification is the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. Validation is the process of evaluating a system or component during or at the end of development process to determine whether it satisfies the specified requirements . Testing= Verification+Validation
11
Software Testing
Alpha, Beta and Acceptance Testing
The term Acceptance Testing is used when the software is developed for a specific customer. A series of tests are conducted to enable the customer to validate all requirements. These tests are conducted by the end user / customer and may range from adhoc tests to well planned systematic series of tests. The terms alpha and beta testing are used when the software is developed as a product for anonymous customers. Alpha Tests are conducted at the developers site by some potential customers. These tests are conducted in a controlled environment. Alpha testing may be started when formal testing process is near completion. Beta Tests are conducted by the customers / end users at their sites. Unlike alpha testing, developer is not present here. Beta testing is conducted in a real environment that cannot be controlled by the developer.
12
Software Testing
Functional Testing
Input domain System under test Output domain
Input test data
Output test data
Fig. 3: Black box testing
13
Software Testing
Boundary Value Analysis
Consider a program with two input variables x and y. These input variables have specified boundaries as: axb
cyd
Input domain
d y c a x b
14
Fig.4: Input domain for program having two input variables

Software Testing
The boundary value analysis test cases for our program with two inputs variables (x and y) that may have any value from 100 to 300 are: (200,100), (200,101), (200,200), (200,299), (200,300), (100,200), (101,200), (299,200) and
(300,200). This input domain is shown in Fig. 8.5. Each dot represent a test case and inner rectangle is the domain of legitimate inputs. Thus, for a program of n variables, boundary value analysis yield 4n + 1 test cases.
Input domain
400 300 y 200 100 0 100 200 x 300 400
Fig. 5: Input domain of two variables x and y with boundaries [100,300] each
15
Software Testing
Example- 8.I Consider a program for the determination of the nature of roots of a quadratic equation. Its input is a triple of positive integers (say a,b,c) and values may be from interval [0,100]. The program output may have one of the following words. [Not a quadratic equation; Real roots; Imaginary roots; Equal roots] Design the boundary value test cases.
16
Software Testing
Solution Quadratic equation will be of type: ax2+bx+c=0 Roots are real if (b2-4ac)>0 Roots are imaginary if (b2-4ac)<0 Roots are equal if (b2-4ac)=0 Equation is not quadratic if a=0
17
Software Testing
The boundary value test cases are :
Test Case 1 2 3 4 5 6 7 8 9 10 11 12 13 a 0 1 50 99 100 50 50 50 50 50 50 50 50 b 50 50 50 50 50 0 1 99 100 50 50 50 50 c 50 50 50 50 50 50 50 50 50 0 1 99 100 Expected output Not Quadratic Real Roots Imaginary Roots Imaginary Roots Imaginary Roots Imaginary Roots Imaginary Roots Imaginary Roots Equal Roots Real Roots Real Roots Imaginary Roots Imaginary Roots
18
Software Testing
Example 8.2 Consider a program for determining the Previous date. Its input is a triple of day, month and year with the values in the range 1 month 12 1 day 31 1900 year 2025 The possible outputs would be Previous date or invalid input date. Design the boundary value test cases.
19
Software Testing
Solution The Previous date program takes a date as input and checks it for validity. If valid, it returns the previous date as its output. With single fault assumption theory, 4n+1 test cases can be designed and which are equal to 13.
20
Software Testing
The boundary value test cases are:
Test Case 1 2 3 4 5 6 7 8 9 10 11 12 13 Month 6 6 6 6 6 6 6 6 6 1 2 11 12 Day 15 15 15 15 15 1 2 30 31 15 15 15 15 Year 1900 1901 1962 2024 2025 1962 1962 1962 1962 1962 1962 1962 1962 Expected output 14 June, 1900 14 June, 1901 14 June, 1962 14 June, 2024 14 June, 2025 31 May, 1962 1 June, 1962 29 June, 1962 Invalid date 14 January, 1962 14 February, 1962 14 November, 1962 14 December, 1962
21
Software Testing
Example 8.3 Consider a simple program to classify a triangle. Its inputs is a triple of positive integers (say x, y, z) and the date type for input parameters ensures that these will be integers greater than 0 and less than or equal to 100. The program output may be one of the following words: [Scalene; Isosceles; Equilateral; Not a triangle] Design the boundary value test cases.
22
Software Testing
Solution The boundary value test cases are shown below:
Test case 1 2 3 4 5 6 7 8 9 10 11 12 13 x 50 50 50 50 50 50 50 50 50 1 2 99 100 y 50 50 50 50 50 1 2 99 100 50 50 50 50 z 1 2 50 99 100 50 50 50 50 50 50 50 50 Expected Output Isosceles Isosceles Equilateral Isosceles Not a triangle Isosceles Isosceles Isosceles Not a triangle Isosceles Isosceles Isosceles Not a triangle
23
Software Testing
Robustness testing
It is nothing but the extension of boundary value analysis. Here, we would like to see, what happens when the extreme values are exceeded with a value slightly greater than the maximum, and a value slightly less than minimum. It means, we want to go outside the legitimate boundary of input domain. This extended form of boundary value analysis is called robustness testing and shown in Fig. 6 There are four additional test cases which are outside the legitimate input domain. Hence total test cases in robustness testing are 6n+1, where n is the number of input variables. So, 13 test cases are: (200,99), (200,100), (200,101), (200,200), (200,299), (200,300) (200,301), (99,200), (100,200), (101,200), (299,200), (300,200), (301,200)
24
Software Testing
400 300 y 200 100 0 100 200 x 300 400
Fig. 8.6: Robustness test cases for two variables x and y with range [100,300] each
25
Software Testing
Worst-case testing
If we reject single fault assumption theory of reliability and may like to see what happens when more than one variable has an extreme value. In electronic circuits analysis, this is called worst case analysis. It is more thorough in the sense that boundary value test cases are a proper subset of worst case test cases. It requires more effort. Worst case testing for a function of n variables generate 5n test cases as opposed to 4n+1 test cases for boundary value analysis. Our two variables example will have 52=25 test cases and are given in table 1.
26
Software Testing
Table 1: Worst cases test inputs for two variables example
Test case number 1 2 3 4 5 6 7 8 9 10 11 12 13 Inputs x 100 100 100 100 100 101 101 101 101 101 200 200 200 y 100 101 200 299 300 100 101 200 299 300 100 101 200 Test case number 14 15 16 17 18 19 20 21 22 23 24 25 -Inputs x 200 200 299 299 299 299 299 300 300 300 300 300 y 299 300 100 101 200 299 300 100 101 200 299 300
27
Software Testing
Example - 8.4
Consider the program for the determination of nature of roots of a quadratic equation as explained in example 8.1. Design the Robust test case and worst test cases for this program.
28
Software Testing
Solution
Robust test cases are 6n+1. Hence, in 3 variable input cases total number of test cases are 19 as given on next slide:
29
Software Testing
Test case 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 a -1 0 1 50 99 100 101 50 50 50 50 50 50 50 50 50 50 50 50 b 50 50 50 50 50 50 50 -1 0 1 99 100 101 50 50 50 50 50 50 c 50 50 50 50 50 50 50 50 50 50 50 50 50 -1 0 1 99 100 101 Expected Output Invalid input` Not quadratic equation Real roots Imaginary roots Imaginary roots Imaginary roots Invalid input Invalid input Imaginary roots Imaginary roots Imaginary roots Equal roots Invalid input Invalid input Real roots Real roots Imaginary roots Imaginary roots Invalid input
30
Software Testing
In case of worst test case total test cases are 5n. Hence, 125 test cases will be generated in worst test cases. The worst test cases are given below:
Test Case 1 2 3 4 5 6 7 8 9 10 11 12 13 14 a 0 0 0 0 0 0 0 0 0 0 0 0 0 0 b 0 0 0 0 0 1 1 1 1 1 50 50 50 50 c 0 1 50 99 100 0 1 50 99 100 0 1 50 99 Expected output Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic
31
Software Testing
Test Case 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 A 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 b 50 99 99 99 99 99 100 100 100 100 100 0 0 0 0 0 1 c 100 0 1 50 99 100 0 1 50 99 100 0 1 50 99 100 0 Expected output Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Equal Roots Imaginary Imaginary Imaginary Imaginary Real Roots
32
Software Testing
Test Case 32 33 34 35 36 37 38 39 40 41 42 43 44` 45 46 47 48 A 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 b 1 1 1 1 50 50 50 50 50 99 99 99 99 99 100 100 100 C 1 50 99 100 0 1 50 99 100 0 1 50 99 100 0 1 50 Expected output Imaginary Imaginary Imaginary Imaginary Real Roots Real Roots Real Roots Real Roots Real Roots Real Roots Real Roots Real Roots Real Roots Real Roots Real Roots Real Roots Real Roots
33
Software Testing
Test Case 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 A 1 1 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 b 100 100 0 0 0 0 0 1 1 1 1 1 50 50 50 50 50 C 99 100 0 1 50 99 100 0 1 50 99 100 0 1 50 99 100 Expected output Real Roots Real Roots Equal Roots Imaginary Imaginary Imaginary Imaginary Real Roots Imaginary Imaginary Imaginary Imaginary Real Roots Real Roots Imaginary Imaginary Imaginary
34
Software Testing
Test Case 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 A 50 50 50 50 50 50 50 50 50 50 99 99 99 99 99 99 99 b 99 99 99 99 99 100 100 100 100 100 0 0 0 0 0 1 1 C 0 1 50 99 100 0 1 50 99 100 0 1 50 99 100 0 1 Expected output Real Roots Real Roots Imaginary Imaginary Imaginary Real Roots Real Roots Equal Roots Imaginary Imaginary Equal Roots Imaginary Imaginary Imaginary Imaginary Real Roots Imaginary
35
Software Testing
Test Case 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 A 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 b 1 1 1 50 50 50 50 50 99 99 99 99 99 100 100 100 100 100 C 50 99 100 0 1 50 99 100 0 1 50 99 100 0 1 50 99 100 Expected output Imaginary Imaginary Imaginary Real Roots Real Roots Imaginary Imaginary Imaginary Real Roots Real Roots Imaginary Roots Imaginary Imaginary Real Roots Real Roots Imaginary Imaginary Imaginary
36
Software Testing
Test Case 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 A 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 b 0 0 0 0 0 1 1 1 1 1 50 50 50 50 50 99 99 99 C 0 1 50 99 100 0 1 50 99 100 0 1 50 99 100 0 1 50 Expected output Equal Roots Imaginary Imaginary Imaginary Imaginary Real Roots Imaginary Imaginary Imaginary Imaginary Real Roots Real Roots Imaginary Imaginary Imaginary Real Roots Real Roots Imaginary
37
Software Testing
Test Case 119 120 121 122 123 124 125 A 100 100 100 100 100 100 100 b 99 99 100 100 100 100 100 C 99 100 0 1 50 99 100 Expected output Imaginary Imaginary Real Roots Real Roots Imaginary Imaginary Imaginary
38
Software Testing
Example 8.5
Consider the program for the determination of previous date in a calendar as explained in example 8.2. Design the robust and worst test cases for this program.
39
Software Testing
Solution
Robust test cases are 6n+1. Hence total 19 robust test cases are designed and are given on next slide.
40
Software Testing
Test case 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Month 6 6 6 6 6 6 6 6 6 6 6 6 6 0 1 2 11 12 13 Day 15 15 15 15 15 15 15 0 1 2 30 31 32 15 15 15 15 15 15 Year 1899 1900 1901 1962 2024 2025 2026 1962 1962 1962 1962 1962 1962 1962 1962 1962 1962 1962 1962 Expected Output Invalid date (outside range) 14 June, 1900 14 June, 1901 14 June, 1962 14 June, 2024 14 June, 2025 Invalid date (outside range) Invalid date 31 May, 1962 1 June, 1962 29 June, 1962 Invalid date Invalid date Invalid date 14 January, 1962 14 February, 1962 14 November, 1962 14 December, 1962 Invalid date
41
Software Testing
In case of worst test case total test cases are 5n. Hence, 125 test cases will be generated in worst test cases. The worst test cases are given below:
Test Case 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Month 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Day 1 1 1 1 1 2 2 2 2 2 15 15 15 15 Year 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 2024 Expected output 31 December, 1899 31 December, 1900 31 December, 1961 31 December, 2023 31 December, 2024 1 January, 1900 1 January, 1901 1 January, 1962 1 January, 2024 1 January, 2025 14 January, 1900 14 January, 1901 14 January, 1962 14 January, 2024
42
Software Testing
Test Case 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 A 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 b 15 30 30 30 30 30 31 31 31 31 31 1 1 1 1 1 2 c 2025 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 Expected output 14 January, 2025 29 January, 1900 29 January, 1901 29 January, 1962 29 January, 2024 29 January, 2025 30 January, 1900 30 January, 1901 30 January, 1962 30 January, 2024 30 January, 2025 31 January, 1900 31 January, 1901 31 January, 1962 31 January, 2024 31 January, 2025 1 February, 1900
43
Software Testing
Test Case 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 Month 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 Day 2 2 2 2 15 15 15 15 15 30 30 30 30 30 31 31 31 Year 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 Expected output 1 February, 1901 1 February, 1962 1 February, 2024 1 February, 2025 14 February, 1900 14 February, 1901 14 February, 1962 14 February, 2024 14 February, 2025 Invalid date Invalid date Invalid date Invalid date Invalid date Invalid date Invalid date Invalid date
44
Software Testing
Test Case 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 Month 2 2 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 Day 31 31 1 1 1 1 1 2 2 2 2 2 15 15 15 15 15 Year 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 Expected output Invalid date Invalid date 31 May, 1900 31 May, 1901 31 May, 1962 31 May, 2024 31 May, 2025 1 June, 1900 1 June, 1901 1 June, 1962 1 June, 2024 1 June, 2025 14 June, 1900 14 June, 1901 14 June, 1962 14 June, 2024 14 June, 2025
45
Software Testing
Test Case 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 Month 6 6 6 6 6 6 6 6 6 6 11 11 11 11 11 11 11 Day 30 30 30 30 30 31 31 31 31 31 1 1 1 1 1 2 2 Year 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 Expected output 29 June, 1900 29 June, 1901 29 June, 1962 29 June, 2024 29 June, 2025 Invalid date Invalid date Invalid date Invalid date Invalid date 31 October, 1900 31 October, 1901 31 October, 1962 31 October, 2024 31 October, 2025 1 November, 1900 1 November, 1901
46
Software Testing
Test Case 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 Month 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 Day 2 2 2 15 15 15 15 15 30 30 30 30 30 31 31 31 31 31 Year 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 Expected output 1 November, 1962 1 November, 2024 1 November, 2025 14 November, 1900 14 November, 1901 14 November, 1962 14 November, 2024 14 November, 2025 29 November, 1900 29 November, 1901 29 November, 1962 29 November, 2024 29 November, 2025 Invalid date Invalid date Invalid date Invalid date Invalid date
47
Software Testing
Test Case 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 Month 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 Day 1 1 1 1 1 2 2 2 2 2 15 15 15 15 15 30 30 30 Year 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 Expected output 30 November, 1900 30 November, 1901 30 November, 1962 30 November, 2024 30 November, 2025 1 December, 1900 1 December, 1901 1 December, 1962 1 December, 2024 1 December, 2025 14 December, 1900 14 December, 1901 14 December, 1962 14 December, 2024 14 December, 2025 29 December, 1900 29 December, 1901 29 December, 1962
48
Software Testing
Test Case 119 120 121 122 123 124 125 Month 12 12 12 12 12 12 12 Day 30 30 31 31 31 31 31 Year 2024 2025 1900 1901 1962 2024 2025 Expected output 29 December, 2024 29 December, 2025 30 December, 1900 30 December, 1901 30 December, 1962 30 December, 2024 30 December, 2025
49
Software Testing
Example 8.6
Consider the triangle problem as given in example 8.3. Generate robust and worst test cases for this problem.
50
Software Testing
Solution
Robust test cases are given on next slide.
51
Software Testing
` 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 x 50 50 50 50 50 50 50 50 50 50 50 50 50 0 1 2 99 100 100 y 50 50 50 50 50 50 50 0 1 2 99 100 101 50 50 50 50 50 50 z 0 1 2 50 99 100 101 50 50 50 50 50 50 50 50 50 50 50 50 Expected Output Invalid input` Isosceles Isosceles Equilateral Isosceles Not a triangle Invalid input Invalid input Isosceles Isosceles Isosceles Not a triangle Invalid input Invalid input Isosceles Isosceles Isosceles Not a triangle Invalid input
52
Software Testing
Worst test cases are 125 and are given below:
Test Case 1 2 3 4 5 6 7 8 9 10 11 12 13 14 x 1 1 1 1 1 1 1 1 1 1 1 1 1 1 y 1 1 1 1 1 2 2 2 2 2 50 50 50 50 z 1 2 50 99 100 1 2 50 99 100 1 2 50 99 Expected output Equilateral Not a triangle Not a triangle Not a triangle Not a triangle Not a triangle Isosceles Not a triangle Not a triangle Not a triangle Not a triangle Not a triangle Isosceles Not a triangle
53
Software Testing
Test Case 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 A 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 b 50 99 99 99 99 99 100 100 100 100 100 1 1 1 1 1 2 c 100 1 2 50 99 100 1 2 50 99 100 1 2 50 99 100 1 Expected output Not a triangle Not a triangle Not a triangle Not a triangle Isosceles Not a triangle Not a triangle Not a triangle Not a triangle Not a triangle Isosceles Not a triangle Isosceles Not a triangle Not a triangle Not a triangle Isosceles
54
Software Testing
Test Case 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 A 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 b 2 2 2 2 50 50 50 50 50 99 99 99 99 99 100 100 100 C 2 50 99 100 1 2 50 99 100 1 2 50 99 100 1 2 50 Expected output Equilateral Not a triangle Not a triangle Not a triangle Not a triangle Not a triangle Isosceles Not a triangle Not a triangle Not a triangle Not a triangle Not a triangle Isosceles Scalene Not a triangle Not a triangle Not a triangle
55
Software Testing
Test Case 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 A 2 2 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 b 100 100 1 1 1 1 1 2 2 2 2 2 50 50 50 50 50 C 50 99 100 1 2 50 99 100 1 2 50 99 100 1 2 50 99 Expected output Scalene Isosceles Not a triangle Not a triangle Isosceles Not a triangle Not a triangle Not a triangle Not a triangle Isosceles Not a triangle Not a triangle Isosceles Isosceles Equilateral Isosceles Not a triangle
56
Software Testing
Test Case 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 A 50 50 50 50 50 50 50 50 50 50 50 99 99 99 99 99 99 B 99 99 99 99 99 100 100 100 100 100 1 1 1 1 1 2 2 C 1 2 50 99 100 1 2 50 99 100 1 2 50 99 100 1 2 Expected output Not a triangle Not a triangle Isosceles Isosceles Scalene Not a triangle Not a triangle Not a triangle Scalene Isosceles Not a triangle Not a triangle Not a triangle Isosceles Not a triangle Not a triangle Not a triangle
57
Software Testing
Test Case 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 A 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 b 2 2 2 50 50 50 50 50 99 99 99 99 99 100 100 100 100 100 C 50 99 100 1 2 50 99 100 1 2 50 99 100 1 2 50 99 100 Expected output Not a triangle Isosceles Scalene Not a triangle Not a triangle Isosceles Isosceles Scalene Isosceles Isosceles Isosceles Equilateral Isosceles Not a triangle Scalene Scalene Isosceles Isosceles
58
Software Testing
Test Case 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 A 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 b 1 1 1 1 1 2 2 2 2 2 50 50 50 50 50 99 99 99 C 1 2 50 99 100 1 2 50 99 100 1 2 50 99 100 1 2 50 Expected output Not a triangle Not a triangle Not a triangle Not a triangle Isosceles Not a triangle Not a triangle Not a triangle Scalene Isosceles Not a triangle Not a triangle Not a triangle Scalene Isosceles Not a triangle Scalene Scalene
59
Software Testing
Test Case 119 120 121 122 123 124 125 A 100 100 100 100 100 100 100 b 99 99 100 100 100 100 100 C 99 100 1 2 50 99 100 Expected output Isosceles Isosceles Isosceles Isosceles Isosceles Isosceles Equilateral
60
Software Testing
Equivalence Class Testing
In this method, input domain of a program is partitioned into a finite number of equivalence classes such that one can reasonably assume, but not be absolutely sure, that the test of a representative value of each class is equivalent to a test of any other value. Two steps are required to implementing this method: 1. The equivalence classes are identified by taking each input condition and partitioning it into valid and invalid classes. For example, if an input condition specifies a range of values from 1 to 999, we identify one valid equivalence class [1<item<999]; and two invalid equivalence classes [item<1] and [item>999]. 2. Generate the test cases using the equivalence classes identified in the previous step. This is performed by writing test cases covering all the valid equivalence classes. Then a test case is written for each invalid equivalence class so that no test contains more than one invalid class. This is to ensure that no two invalid classes mask each other.
61
Software Testing
Invalid input Valid inputs System under test Outputs
Input domain
Output domain
Fig. 7: Equivalence partitioning
Most of the time, equivalence class testing defines classes of the input domain. However, equivalence classes should also be defined for output domain. Hence, we should design equivalence classes based on input and output domain.
62
Software Testing
Example 8.7
Consider the program for the determination of nature of roots of a quadratic equation as explained in example 8.1. Identify the equivalence class test cases for output and input domains.
63
Software Testing
Solution Output domain equivalence class test cases can be identified as follows: O1={<a,b,c>:Not a quadratic equation if a = 0} O1={<a,b,c>:Real roots if (b2-4ac)>0} O1={<a,b,c>:Imaginary roots if (b2-4ac)<0} O1={<a,b,c>:Equal roots if (b2-4ac)=0}` The number of test cases can be derived form above relations and shown below:
Test case 1 2 3 4 a 0 1 50 50 b 50 50 50 100 c 50 50 50 50 Expected output Not a quadratic equation Real roots Imaginary roots Equal roots
64
Software Testing
We may have another set of test cases based on input domain. I1= {a: a = 0} I2= {a: a < 0} I3= {a: 1 a 100} I4= {a: a > 100} I5= {b: 0 b 100} I6= {b: b < 0} I7= {b: b > 100} I8= {c: 0 c 100} I9= {c: c < 0} I10={c: c > 100}
65
Software Testing
Test Case 1 2 3 4 5 6 7 8 9 10 a 0 -1 50 101 50 50 50 50 50 50 b 50 50 50 50 50 -1 101 50 50 50 c 50 50 50 50 50 50 50 50 -1 101 Expected output Not a quadratic equation Invalid input Imaginary Roots invalid input Imaginary Roots invalid input invalid input Imaginary Roots invalid input invalid input
Here test cases 5 and 8 are redundant test cases. If we choose any value other than nominal, we may not have redundant test cases. Hence total test cases are 10+4=14 for this problem.
66
Software Testing
Example 8.8
Consider the program for determining the previous date in a calendar as explained in example 8.3. Identify the equivalence class test cases for output & input domains.
67
Software Testing
Solution
Output domain equivalence class are: O1={<D,M,Y>: Previous date if all are valid inputs} O1={<D,M,Y>: Invalid date if any input makes the date invalid}
Test case 1 2
M 6 6
D 15 31
Y 1962 1962
Expected output 14 June, 1962 Invalid date
68
Software Testing
We may have another set of test cases which are based on input domain. I1={month: 1 m 12} I2={month: m < 1} I3={month: m > 12} I4={day: 1 D 31} I5={day: D < 1} I6={day: D > 31} I7={year: 1900 Y 2025} I8={year: Y < 1900} I9={year: Y > 2025}
69
Software Testing
Inputs domain test cases are :
Test Case 1 2 3 4 5 6 7 8 9 M 6 -1 13 6 6 6 6 6 6 D 15 15 15 15 -1 32 15 15 15 Y 1962 1962 1962 1962 1962 1962 1962 1899 2026 Expected output 14 June, 1962 Invalid input invalid input 14 June, 1962 invalid input invalid input 14 June, 1962 invalid input (Value out of range) invalid input (Value out of range)
70
Software Testing
Example 8.9
Consider the triangle problem specified in a example 8.3. Identify the equivalence class test cases for output and input domain.
71
Software Testing
Solution
Output domain equivalence classes are: O1={<x,y,z>: Equilateral triangle with sides x,y,z} O1={<x,y,z>: Isosceles triangle with sides x,y,z} O1={<x,y,z>: Scalene triangle with sides x,y,z} O1={<x,y,z>: Not a triangle with sides x,y,z} The test cases are:
Test case 1 2 3 4 x 50 50 100 50 y 50 50 99 100 z 50 99 50 50 Expected Output Equilateral Isosceles Scalene Not a triangle
72
Software Testing
Input domain based classes are: I1={x: x < 1} I2={x: x > 100} I3={x: 1 x 100} I4={y: y < 1} I5={y: y > 100} I6={y: 1 y 100} I7={z: z < 1} I8={z: z > 100} I9={z: 1 z 100}
73
Software Testing
Some inputs domain test cases can be obtained using the relationship amongst x,y and z. I10={< x,y,z >: x = y = z} I11={< x,y,z >: x = y, x z} I12={< x,y,z >: x = z, x y} I13={< x,y,z >: y = z, x y} I14={< x,y,z >: x y, x z, y z} I15={< x,y,z >: x = y + z} I16={< x,y,z >: x > y +z} I17={< x,y,z >: y = x +z} I18={< x,y,z >: y > x + z} I19={< x,y,z >: z = x + y} I20={< x,y,z >: z > x +y}
74
Software Testing
Test cases derived from input domain are:
Test case 1 2 3 4 5 6 7 8 9 10 11 12 13 x 0 101 50 50 50 50 50 50 50 60 50 50 60 y 50 50 50 0 101 50 50 50 50 60 50 60 50 z 50 50 50 50 50 50 0 101 50 60 60 50 50 Expected Output Invalid input Invalid input Equilateral Invalid input Invalid input Equilateral Invalid input Invalid input Equilateral Equilateral Isosceles Isosceles Isosceles
75
Software Testing
Test case 14 15 16 17 18 19 20
x 100 100 100 50 50 50 25
y 99 50 50 100 100 50 50
z 50 50 25 50 25 100 100
Expected Output Scalene Not a triangle Not a triangle Not a triangle Not a triangle Not a triangle Not a triangle
76
Software Testing
Decision Table Based Testing
Condition Stub True C1 True C2 C3 Action Stub a1 a2 a3 a4 True X X X X False X X X X X True False True X X False --False True False Entry False
Table 2: Decision table terminology

77
Software Testing
Test case design
C1:x,y,z are sides of a triangle? C2:x = y? C3:x = z? C4:y = z? a1: Not a triangle a2: Scalene a3: Isosceles a4: Equilateral a5: Impossible
N ---X Y Y N Y Y N N
Y N Y Y N Y N N
X X X X X X
78
Table 3: Decision table for triangle problem

Software Testing
Conditions C1 : x < y + z ? C2 : y < x + z ? C3 : z < x + y ? C4 : x = y ? C5 : x = z ? C6 : y = z ? a1 : Not a triangle a2 : Scalene a3 : Isosceles a4 : Equilateral a5 : Impossible X X X X X X X F -----X T F ----X T T F ---X X T T T T T T T T T T T F T T T T F T T T T T F F T T T F T T T T T F T F T T T F F T T T T F F F
Table 4: Modified decision table

79
Software Testing
Example 8.10 Consider the triangle program specified in example 8.3. Identify the test cases using the decision table of Table 4.
80
Software Testing
Solution
There are eleven functional test cases, three to fail triangle property, three impossible cases, one each to get equilateral, scalene triangle cases, and three to get on isosceles triangle. The test cases are given in Table 5.
Test case 1 2 3 4 5 6 7 8 9 10 11 x 4 1 1 5 ? ? 2 ? 2 3 3 y 1 4 2 5 ? ? 2 ? 3 2 4 z 2 2 4 5 ? ? 3 ? 2 2 5 Expected Output Not a triangle Not a triangle Not a triangle Equilateral Impossible Impossible Isosceles Impossible Isosceles Isosceles Scalene
Test cases of triangle problem using decision table

81
Software Testing
Example 8.11 Consider a program for the determination of Previous date. Its input is a triple of day, month and year with the values in the range 1 month 12 1 day 31 1900 year 2025 The possible outputs are Previous date and Invalid date. Design the test cases using decision table based testing.
82
Software Testing
Solution
The input domain can be divided into following classes: I1= {M1: month has 30 days} I2= {M2: month has 31 days except March, August and January} I3= {M3: month is March} I4= {M4: month is August} I5= {M5: month is January} I6= {M6: month is February} I7= {D1: day = 1} I8= {D2: 2 day 28} I9= {D3: day = 29} I10={D4: day = 30} I11={D5: day = 31} I12={Y1: year is a leap year} I13={Y2: year is a common year}
83
Software Testing
The decision table is given below:
Sr.No. C1: Months in C2: days in C3: year in a1: Impossible a2: Decrement day a3: Reset day to 31 a4: Reset day to 30 a5: Reset day to 29 a6: Reset day to 28 a7: decrement month a8: Reset month to December a9: Decrement year
1
M1 D1 Y1
2
M1 D1 Y2
3
M1 D2 Y1
4
M1 D2 Y2
5
M1 D3 Y1
6
M1 D3 Y2
7
M1 D4 Y1
8
M1 D4 Y2
9
M1 D5 Y1 X
10
M1 D5 Y2 X
11
M2 D1 Y1
12
M2 D1 Y2
13
M2 D2 Y1
14
M2 D2 Y2
15
M2 D3 Y1
X X X
84
Software Testing
16
M2 D3 Y2
17
M2 D4 Y1
18
M2 D4 Y2
19
M2 D5 Y1
20
M2 D5 Y2
21
M3 D1 Y1
22
M3 D1 Y2
23
M3 D2 Y1
24
M3 D2 Y2
25
M3 D3 Y1
26
M3 D3 Y2
27
M3 D4 Y1
28
M3 D4 Y2
29
M3 D5 Y1
30
M3 D5 Y2
X X X X
85
Software Testing
31
M4 D1 Y1
32
M4 D1 Y2
33
M4 D2 Y1
34
M4 D2 Y2
35
M4 D3 Y1
36
M4 D3 Y2
37
M4 D4 Y1
38
M4 D4 Y2
39
M4 D5 Y1
40
M4 D5 Y2
41
M5 D1 Y1
42
M5 D1 Y2
43
M5 D2 Y1
44
M5 D2 Y2
45
M5 D3 Y1
X X X
X X X
X X X X X
86
Software Testing
46
M5 D3 Y2
47
M5 D4 Y1
48
M5 D4 Y2
49
M5 D5 Y1
50
M5 D5 Y2
51
M6 D1 Y1
52
M6 D1 Y2
53
M6 D2 Y1
54
M6 D2 Y2
55
M6 D3 Y1
56
M6 D3 Y2 X
57
M6 D4 Y1 X
58
M6 D4 Y2 X
59
M6 D5 Y1 X
60
M6 D5 Y2 X
X X X
87
Software Testing
Test case 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Month June June June June June June June June June June May May May May May Day 1 1 15 15 29 29 30 30 31 31 1 1 15 15 29 Year 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 Expected output 31 May, 1964 31 May, 1962 14 June, 1964 14 June, 1962 28 June, 1964 28 June, 1962 29 June, 1964 29 June, 1962 Impossible Impossible 30 April, 1964 30 April, 1962 14 May, 1964 14 May, 1962 28 May, 1964
88
Software Testing
Test case 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Month May May May May May March March March March March March March March March March Day 29 30 30 31 31 1 1 15 15 29 29 30 30 31 31 Year 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 Expected output 28 May, 1962 29 May, 1964 29 May, 1962 30 May, 1964 30 May, 1962 29 February, 1964 28 February, 1962 14 March, 1964 14 March, 1962 28 March, 1964 28 March, 1962 29 March, 1964 29 March, 1962 30 March, 1964 30 March, 1962
89
Software Testing
Test case 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 Month August August August August August August August August August August January January January January January Day 1 1 15 15 29 29 30 30 31 31 1 1 15 15 29 Year 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 Expected output 31 July, 1962 31 July, 1964 14 August, 1964 14 August, 1962 28 August, 1964 28 August, 1962 29 August, 1964 29 August, 1962 30 August, 1964 30 August, 1962 31 December, 1964 31 December, 1962 14 January, 1964 14 January, 1962 28 January, 1964
90
Software Testing
Test case 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 Month January January January January January February February February February February February February February February February Day 29 30 30 31 31 1 1 15 15 29 29 30 30 31 31 Year 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 Expected output 28 January, 1962 29 January, 1964 29 January, 1962 30 January, 1964 30 January, 1962 31 January, 1964 31 January, 1962 14 February, 1964 14 February, 1962 28 February, 1964 Impossible Impossible Impossible Impossible Impossible
91
Software Testing
Cause Effect Graphing Technique Consider single input conditions do not explore combinations of input circumstances Steps 1. Causes & effects in the specifications are identified. A cause is a distinct input condition or an equivalence class of input conditions. An effect is an output condition or a system transformation. 2. The semantic content of the specification is analysed and transformed into a boolean graph linking the causes & effects. 3. Constraints are imposed 4. graph limited entry decision table Each column in the table represent a test case. 5. The columns in the decision table are converted into test cases.
92
Software Testing
The basic notation for the graph is shown in fig. 8
Fig.8. 8 : Basic cause effect graph symbols

93
Software Testing
Myers explained this effectively with following example. The characters in column 1 must be an A or B. The character in column 2 must be a digit. In this situation, the file update is made. If the character in column 1 is incorrect, message x is issued. If the character in column 2 is not a digit, message y is issued. The causes are c1: character in column 1 is A c2: character in column 1 is B c3: character in column 2 is a digit and the effects are e1: update made e2: message x is issued e3: message y is issued
94
Software Testing
Fig. 9: Sample cause effect graph
95
Software Testing
The E constraint states that it must always be true that at most one of c1 or c2 can be 1 (c1 or c2 cannot be 1 simultaneously). The I constraint states that at least one of c1, c2 and c3 must always be 1 (c1, c2 and c3 cannot be 0 simultaneously). The O constraint states that one, and only one, of c1 and c2 must be 1. The constraint R states that, for c1 to be 1, c2 must be 1 (i.e. it is impossible for c1 to be 1 and c2 to be 0),
96
Software Testing
Fig. 10: Constraint symbols

97
Software Testing
Fig. 11: Symbol for masks constraint

98
Software Testing
Fig. 12 : Sample cause effect graph with exclusive constraint

99
Software Testing
Example 8.12
Consider the triangle problem specified in the example 8.3. Draw the Cause effect graph and identify the test cases.
100
Software Testing
Solution The causes are c1: c2: c3: c4: c5: c6: side x is less than sum of sides y and z side y is less than sum of sides x and y side z is less than sum of sides x and y side x is equal to side y side x is equal to side z side y is equal to side z
and effects are e1: Not a triangle e2: Scalene triangle e3: Isosceles triangle e4: Equilateral triangle e5: Impossible stage
101
Software Testing
The cause effect graph is shown in fig. 13 and decision table is shown in table 6. The test cases for this problem are available in Table 5.
Conditions C1: x < y + z ? C2: y < x + z ? C3: z < x + y ? C4: x = y ? C5: x = z ? C6: y = z ? e1: Not a triangle e2: Scalene e3: Isosceles e4: Equilateral e5: Impossible
0 X X X X X 1
1 0 X X X X 1
1 1 0 X X X 1
1 1 1 1 1 1
1 1 1 1 1 0
1 1 1 1 0 1
1 1 1 1 0 0
1 1 1 0 1 1
1 1 1 0 1 0
1 1 1 0 0 1
1 1 1 0 0 0 1
1 1 1 1 1
Table 6: Decision table
102
Software Testing
Fig. 13: Cause effect graph of triangle problem

103
Software Testing
Structural Testing A complementary approach to functional testing is called structural / white box testing. It permits us to examine the internal structure of the program. Path Testing Path testing is the name given to a group of test techniques based on judiciously selecting a set of test paths through the program. If the set of paths is properly chosen, then it means that we have achieved some measure of test thoroughness. This type of testing involves: 1. generating a set of paths that will cover every branch in the program. 2. finding a set of test cases that will execute every path in the set of program paths.
104
Software Testing
Flow Graph The control flow of a program can be analysed using a graphical representation known as flow graph. The flow graph is a directed graph in which nodes are either entire statements or fragments of a statement, and edges represents flow of control.
Fig. 14: The basic construct of the flow graph

105
Software Testing
106
Software Testing
107
Software Testing
108
Software Testing
109
Software Testing
Fig. 15: Program for previous date problem

110
Software Testing
Fig. 16: Flow graph of previous date problem
111
Software Testing
DD Path Graph Table 7: Mapping of flow graph nodes and DD path nodes
Flow graph nodes 1 to 9 10 11 12 13,14 15,16,17 18 19 20 21 22 23 DD Path graph corresponding node n1 n2 n3 n4 n5 n6 n7 n8 n9 n10 n11 n12 Remarks
There is a sequential flow from node 1 to 9 Decision node, if true go to 13 else go to 44 Decision node, if true go to 12 else go to 19 Decision node, if true go to 13 else go to 15 Sequential nodes and are combined to form new node n5 Sequential nodes Edges from node 14 to 17 are terminated here Decision node, if true go to 20 else go to 37 Intermediate node with one input edge and one output edge Decision node, if true go to 22 else go to 27 Intermediate node Decision node, if true go to 24 else go to 26
112 Cont.
Software Testing
Flow graph nodes 24,25 26 27 28,29 30 31,32 33,34,35 36 37 38,39 40,41,42 43 DD Path graph corresponding node n13 n14 n15 n16 n17 n18 n19 n20 n21 n22 n23 n24 Sequential nodes Two edges from node 25 & 23 are terminated here Two edges from node 26 & 21 are terminated here. Also a decision node Sequential nodes Decision node, if true go to 31 else go to 33 Sequential nodes Sequential nodes Three edge from node 29,32 and 35 are terminated here Decision node, if true go to 38 else go to 40 Sequential nodes Sequential nodes Three edge from node 36,39 and 42 are terminated here Remarks
Cont.
113
Software Testing
Flow graph nodes 44 45 46 47,48,49,50 51 52 53 54 55 56,57 58 59 DD Path graph corresponding node n25 n26 n27 n28 n29 n30 n31 n32 n33 n34 n35 n36 Remarks
Decision node, if true go to 45 else go to 82. Three edges from 18,43 & 10 are also terminated here. Decision node, if true go to 46 else go to 77 Decision node, if true go to 47 else go to 51 Sequential nodes Decision node, if true go to 52 else go to 68 Intermediate node with one input edge & one output ege Decision node, if true go to 54 else go to 59 Intermediate node Decision node, if true go to 56 else go to 58 Sequential nodes Two edge from node 57 and 55 are terminated here Decision node, if true go to 60 else go to 63. Two edge from nodes 58 and 53 are terminated.
Cont.
114
Software Testing
Flow graph nodes 60,61,62 63,64,65,66 67 68 69,70,71 72,73,74,75 76 77,78,79 80 81 82,83,84 85 86,87 DD Path graph corresponding node n37 n38 n39 n40 n41 n42 n43 n44 n45 n46 n47 n48 n49 Sequential nodes Sequential nodes Two edge from node 62 and 66 are terminated here Decision node, if true go to 69 else go to 72 Sequential nodes Sequential nodes Four edges from nodes 50, 67, 71 and 75 are terminated here. Sequential nodes Two edges from nodes 76 & 79 are terminated here Intermediate node Sequential nodes Two edges from nodes 81 and 84 are terminated here Sequential nodes with exit node Remarks
115
Software Testing
Fig. 17: DD path graph of previous date problem
116
Software Testing
Fig. 18: Independent paths of previous date problem

117
Software Testing
Example 8.13 Consider the problem for the determination of the nature of roots of a quadratic equation. Its input a triple of positive integers (say a,b,c) and value may be from interval [0,100]. The program is given in fig. 19. The output may have one of the following words: [Not a quadratic equation; real roots; Imaginary roots; Equal roots] Draw the flow graph and DD path graph. Also find independent paths from the DD Path graph.
118
Software Testing
Cont.
119
Software Testing
Fig. 19: Code of quadratic equation problem

120
Software Testing
Solution
Fig. 19 (a) : Program flow graph
121
Software Testing
Fig. 19 (b) : DD Path graph

122
Software Testing
The mapping table for DD path graph is:
Flow graph nodes 1 to 10 11 12 13 14,15 16 17 18 19 20,21 22 23,24,25 DD Path graph corresponding node A B C D E F G H I J K L Sequential nodes Decision node Intermediate node Decision node Sequential node Two edges are combined here Two edges are combined and decision node Intermediate node Decision node Sequential node Decision node Sequential node Remarks
Cont.
123
Software Testing
Flow graph nodes 26,27,28,29 30 31 32,33 34,35,36 37 38,39 DD Path graph corresponding node M N O P Q R S Sequential nodes Three edges are combined Decision node Sequential node Sequential node Three edges are combined here Sequential nodes with exit node Remarks
Independent paths are: (i) ABGOQRS (iii) ABCDFGOQRS (v) ABGHIJNRS (vi) ABGHIKMNRS (ii) ABGOPRS (iv) ABCDEFGOPRS (vi) ABGHIKLNRS
124
Software Testing
Example 8.14 Consider a program given in Fig.8.20 for the classification of a triangle. Its input is a triple of positive integers (say a,b,c) from the interval [1,100]. The output may be [Scalene, Isosceles, Equilateral, Not a triangle]. Draw the flow graph & DD Path graph. Also find the independent paths from the DD Path graph.
125
Software Testing
126
Software Testing
Fig. 20 : Code of triangle classification problem

127
Software Testing
Solution : Flow graph of triangle problem is:
Fig.8. 20 (a): Program flow graph

128
Software Testing
The mapping table for DD path graph is:
Flow graph nodes DD Path graph corresponding node Remarks
1 TO 9 10 11 12, 13 14 15, 16, 17 18 19 20, 21 22 23, 24 25, 26, 27
A B C D E F G H I J K L
Sequential nodes Decision node Decision node Sequential nodes Two edges are joined here Sequential nodes Decision nodes plus joining of two edges Decision node Sequential nodes Decision node Sequential nodes Sequential nodes
Cont.
129
Software Testing
Flow graph nodes 28 29 30, 31 32, 33, 34 35 36, 37 DD Path graph corresponding node Remarks
M N O P Q R
Three edges are combined here Decision node Sequential nodes Sequential nodes Three edges are combined here Sequential nodes with exit node
Fig. 20 (b): DD Path graph
130
Software Testing
DD Path graph is given in Fig. 20 (b)
Independent paths are: (i) ABFGNPQR (ii) ABFGNOQR (iii) ABCEGNPQR (iv) ABCDEGNOQR (v) ABFGHIMQR (vi) ABFGHJKMQR (vii)ABFGHJMQR
Fig. 20 (b): DD Path graph

131
Software Testing
Cyclomatic Complexity
McCabes cyclomatic metric V(G) = e n + 2P. For example, a flow graph shown in in Fig. 21 with entry node a and exit node f.
Fig. 21: Flow graph

132
Software Testing
The value of cyclomatic complexity can be calculated as : V(G) = 9 6 + 2 = 5 Here e = 9, n = 6 and P =1
There will be five independent paths for the flow graph illustrated in Fig. 21. Path 1 : Path 2 : Path 3 : Path 4 : Path 5 : acf abef adcf a b e a c f or a b e a b e f abebef
133
Software Testing
Several properties of cyclomatic complexity are stated below:
1. V(G) 1 2. V (G) is the maximum number of independent paths in graph G. 3. Inserting & deleting functional statements to G does not affect V(G). 4. G has only one path if and only if V(G)=1. 5. Inserting a new row in G increases V(G) by unity. 6. V(G) depends only on the decision structure of G.
134
Software Testing
The role of P in the complexity calculation V(G)=e-n+2P is required to be understood correctly. We define a flow graph with unique entry and exit nodes, all nodes reachable from the entry, and exit reachable from all nodes. This definition would result in all flow graphs having only one connected component. One could, however, imagine a main program M and two called subroutines A and B having a flow graph shown in Fig. 22.
Fig. 22
135
Software Testing
Let us denote the total graph above with 3 connected components as
V ( M A B) = e n + 2 P
= 13-13+2*3 =6
This method with P 1 can be used to calculate the complexity of a collection of programs, particularly a hierarchical nest of subroutines.
136
Software Testing
Notice that V ( M A B ) = V ( M ) + V ( A) + V ( B ) = 6 . In general, the complexity of a collection C of flow graphs with K connected components is equal to the summation of their complexities. To see this let Ci,1 I K
denote the k distinct connected component, and let ei and ni be the number of edges and nodes in the ith-connected component. Then
k i =1 k i =1 k i =1 k i =1
V (C ) = e n + 2 p = ei ni + 2 K = (ei ni + 2) = V (Ci )
137
Software Testing
Two alternate methods are available for the complexity calculations. 1. Cyclomatic complexity V(G) of a flow graph G is equal to the number of predicate (decision) nodes plus one. V(G)= +1 Where is the number of predicate nodes contained in the flow graph G. 2. Cyclomatic complexity is equal to the number of regions of the flow graph.
138
Software Testing
Example 8.15
Consider a flow graph given in Fig. 23 and calculate the cyclomatic complexity by all three methods.
Fig. 23
139
Software Testing
Solution Cyclomatic complexity can be calculated by any of the three methods. 1. V(G) = e n + 2P = 13 10 + 2 = 5 2. V(G) =+1 =4+1=5 3. V(G) = number of regions =5
Therefore, complexity value of a flow graph in Fig. 23 is 5.
140
Software Testing
Example 8.16
Consider the previous date program with DD path graph given in Fig. 17. Find cyclomatic complexity.
141
Software Testing
Solution
Number of edges (e) = 65 Number of nodes (n) =49 (i) (ii) V(G) = e n + 2P = 65 49 + 2 = 18 V(G) = + 1 = 17 + 1 = 18
(iii) V(G) = Number of regions = 18 The cyclomatic complexity is 18.
142
Software Testing
Example 8.17
Consider the quadratic equation problem given in example 8.13 with its DD Path graph. Find the cyclomatic complexity:
143
Software Testing
Solution
Number of nodes (n) = 19 Number of edges (e) = 24 (i) V(G) = e n + 2P = 24 19 + 2 = 7 (ii) V(G) = + 1 = 6 + 1 = 7 (iii) V(G) = Number of regions = 7 Hence cyclomatic complexity is 7 meaning thereby, seven independent paths in the DD Path graph.
144
Software Testing
Example 8.18
Consider the classification of triangle problem given in example 8.14. Find the cyclomatic complexity.
145
Software Testing
Solution
Number of edges (e) = 23 Number of nodes (n) =18 (i) V(G) = e n + 2P = 23 18 + 2 = 7 (ii) V(G) = + 1 = 6 + 1 = 7 (iii) V(G) = Number of regions = 7 The cyclomatic complexity is 7. Hence, there are seven independent paths as given in example 8.14.
146
Software Testing
Graph Matrices
A graph matrix is a square matrix with one row and one column for every node in the graph. The size of the matrix (i.e., the number of rows and columns) is equal to the number of nodes in the flow graph. Some examples of graphs and associated matrices are shown in fig. 24.
Fig. 24 (a): Flow graph and graph matrices

147
Software Testing
Fig. 24 (b): Flow graph and graph matrices

148
Software Testing
Fig. 24 (c): Flow graph and graph matrices

149
Software Testing
Fig. 25 : Connection matrix of flow graph shown in Fig. 24 (c)

150
Software Testing
The square matrix represent that there are two path ab and cd from node 1 to node 2.
151
Software Testing
Example 8.19 Consider the flow graph shown in the Fig. 26 and draw the graph & connection matrices. Find out cyclomatic complexity and two / three link paths from a node to any other node.
Fig. 26 : Flow graph

152
Software Testing
Solution The graph & connection matrices are given below :
To find two link paths, we have to generate a square of graph matrix [A] and for three link paths, a cube of matrix [A] is required.
153
Software Testing
154
Software Testing
Data Flow Testing
Data flow testing is another from of structural testing. It has nothing to do with data flow diagrams.
i. ii.
Statements where variables receive values. Statements where these values are used or referenced.
As we know, variables are defined and referenced throughout the program. We may have few define/ reference anomalies:
i. ii.
A variable is defined but not used/ referenced. A variable is used but never defined.
iii. A variable is defined twice before it is used.

155
Software Testing
Definitions
The definitions refer to a program P that has a program graph G(P) and a set of program variables V. The G(P) has a single entry node and a single exit node. The set of all paths in P is PATHS(P) (i) Defining Node: Node n G(P) is a defining node of the variable v V, written as DEF (v, n), if the value of the variable v is defined at the statement fragment corresponding to node n.
(ii) Usage Node: Node n G(P) is a usage node of the variable v V, written as USE (v, n), if the value of the variable v is used at statement fragment corresponding to node n. A usage node USE (v, n) is a predicate use (denote as p) if statement n is a predicate statement otherwise USE (v, n) is a computation use (denoted as c).
156
Software Testing
(iii) Definition use: A definition use path with respect to a variable v (denoted du-path) is a path in PATHS(P) such that, for some v V, there are define and usage nodes DEF(v, m) and USE(v, n) such that m and n are initial and final nodes of the path. (iv) Definition clear : A definition clear path with respect to a variable v (denoted dc-path) is a definition use path in PATHS(P) with initial and final nodes DEF (v, m) and USE (v, n), such that no other node in the path is a defining node of v. The du-paths and dc-paths describe the flow of data across source statements from points at which the values are defined to points at which the values are used. The du-paths that are not definition clear are potential trouble spots.
157
Software Testing
Hence, our objective is to find all du-paths and then identity those du-paths which are not dc-paths. The steps are given in Fig. 27. We may like to generate specific test cases for du-paths that are not dc-paths.
Fig. 27 : Steps for data flow testing

158
Software Testing
Example 8.20 Consider the program of the determination of the nature of roots of a quadratic equation. Its input is a triple of positive integers (say a,b,c) and values for each of these may be from interval [0,100]. The program is given in Fig. 19. The output may have one of the option given below: (i) Not a quadratic program (ii) real roots (iii) imaginary roots (iv) equal roots (v) invalid inputs Find all du-paths and identify those du-paths that are definition clear.
159
Software Testing
Solution Step I: The program flow graph is given in Fig. 19 (a). The variables used in the program are a,b,c,d, validinput, D. Step II: DD Path graph is given in Fig. 19(b). The cyclomatic complexity of this graph is 7 indicating there are seven independent paths. Step III: Define/use nodes for all variables are given below:
Variable Defined at node Used at node 11,13,18,20,24,27,28 11,18,20,24,28 11,18 19,22,23,27 24,28 17,31
160
a b c d D Validinput
6 8 10 18 23, 27 3, 12, 14
Software Testing
Step IV: The du-paths are identified and are named by their beginning and ending nodes using Fig. 19 (a).
Variable
a
Path (beginning, end) nodes
Definition clear ?
6, 11 6, 13 6, 18 6, 20 6, 24 6, 27 6, 28 8, 11 8, 18 8, 20 8, 24 8, 28
Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
161
Software Testing
Variable
c d
Definition clear ?
10, 11 10, 18 18, 19 18, 22 18, 23 18, 27 23, 24 23, 28 27, 24 27, 28 3, 17 3, 31 12, 17 12, 31 14, 17 14, 31
Yes Yes Yes Yes Yes Yes Yes Path not possible Path not possible Yes no no no no yes yes
162
validinput
Software Testing
Example 8.21 Consider the program given in Fig. 20 for the classification of a triangle. Its input is a triple of positive integers (say a,b,c) from the interval [1,100]. The output may be: [Scalene, Isosceles, Equilateral, Not a triangle, Invalid inputs]. Find all du-paths and identify those du-paths that are definition clear.
163
Software Testing
Solution Step I: The program flow graph is given in Fig. 20 (a). The variables used in the program are a,b,c, valid input. Step II: DD Path graph is given in Fig. 20(b). The cyclomatic complexity of this graph is 7 and thus, there are 7 independent paths.
Step III: Define/use nodes for all variables are given below:
Variable Defined at node Used at node 10, 11, 19, 22 10, 11, 19, 22 10, 11, 19, 22 18, 29
a b c valid input
6 7 9 3, 13, 16
164
Software Testing
Step IV: The du-paths are identified and are named by their beginning and ending nodes using Fig. 20 (a).
Variable
a
Definition clear ?
5, 10 5, 11 5, 19 5, 22 7, 10 7, 11 7, 19 7, 22
Yes Yes Yes Yes Yes Yes Yes Yes
165
Software Testing
Variable
c
Definition clear ?
9, 10 9, 11 9, 19 9, 22 3, 18 3, 29 12, 18 12, 29 16, 18 16, 29
Yes Yes Yes Yes no no no no Yes Yes
valid input
Hence total du-paths are 18 out of which four paths are not definition clear
166
Software Testing
Mutation Testing
Mutation testing is a fault based technique that is similar to fault seeding, except that mutations to program statements are made in order to determine properties about test cases. it is basically a fault simulation technique. Multiple copies of a program are made, and each copy is altered; this altered copy is called a mutant. Mutants are executed with test data to determine whether the test data are capable of detecting the change between the original program and the mutated program. A mutant that is detected by a test case is termed killed and the goal of mutation procedure is to find a set of test cases that are able to kill groups of mutant programs.
167
Software Testing
When we mutate code there needs to be a way of measuring the degree to which the code has been modified. For example, if the original expression is x+1 and the mutant for that expression is x+2, that is a lesser change to the original code than a mutant such as (c*22), where both the operand and the operator are changed. We may have a ranking scheme, where a first order mutant is a single change to an expression, a second order mutant is a mutation to a first order mutant, and so on. High order mutants becomes intractable and thus in practice only low order mutants are used. One difficulty associated with whether mutants will be killed is the problem of reaching the location; if a mutant is not executed, it cannot be killed. Special test cases are to be designed to reach a mutant. For example, suppose, we have the code. Read (a,b,c); If(a>b) and (b=c) then x:=a*b*c; (make mutants; m1, m2, m3 .)
168
Software Testing
To execute this, input domain must contain a value such that a is greater than b and b equals c. If input domain does not contain such a value, then all mutants made at this location should be considered equivalent to the original program, because the statement x:=a*b*c is dead code (code that cannot be reached during execution). If we make the mutant x+y for x+1, then we should take care about the value of y which should not be equal to 1 for designing a test case. The manner by which a test suite is evaluated (scored) via mutation testing is as follows: for a specified test suite and a specific set of mutants, there will be three types of mutants in the code i.e., killed or dead, live, equivalent. The sum of the number of live, killed, and equivalent mutants will be the total number of mutants created. The score associated with a test suite T and mutants M is simply.
# killed 100% # total # equivalent
169
Software Testing
Levels of Testing
There are 3 levels of testing: i. ii. iii. Unit Testing Integration Testing System Testing
170
Software Testing
Unit Testing
There are number of reasons in support of unit testing than testing the entire product.
1. The size of a single module is small enough that we can locate an error fairly easily. 2. The module is small enough that we can attempt to test it in some demonstrably exhaustive fashion. 3. Confusing interactions of multiple errors in widely different parts of the software are eliminated.
171
Software Testing
There are problems associated with testing a module in isolation. How do we run a module without anything to call it, to be called by it or, possibly, to output intermediate values obtained during execution? One approach is to construct an appropriate driver routine to call if and, simple stubs to be called by it, and to insert output statements in it. Stubs serve to replace modules that are subordinate to (called by) the module to be tested. A stub or dummy subprogram uses the subordinate modules interface, may do minimal data manipulation, prints verification of entry, and returns. This overhead code, called scaffolding represents effort that is import to testing, but does not appear in the delivered product as shown in Fig. 29.
172
Software Testing
Fig. 29 : Scaffolding required testing a program unit (module)

173
Software Testing
Integration Testing
The purpose of unit testing is to determine that each independent module is correctly implemented. This gives little chance to determine that the interface between modules is also correct, and for this reason integration testing must be performed. One specific target of integration testing is the interface: whether parameters match on both sides as to type, permissible ranges, meaning and utilization.
174
Software Testing
Fig. 30 : Three different integration approaches

175
Software Testing
System Testing
Of the three levels of testing, the system level is closet to everyday experiences. We test many things; a used car before we buy it, an on-line cable network service before we subscribe, and so on. A common pattern in these familiar forms is that we evaluate a product in terms of our expectations; not with respect to a specification or a standard. Consequently, goal is not to find faults, but to demonstrate performance. Because of this we tend to approach system testing from a functional standpoint rather than from a structural one. Since it is so intuitively familiar, system testing in practice tends to be less formal than it might be, and is compounded by the reduced testing interval that usually remains before a delivery deadline. Petschenik gives some guidelines for choosing test cases during system testing.
176
Software Testing
During system testing, we should evaluate a number of attributes of the software that are vital to the user and are listed in Fig. 31. These represent the operational correctness of the product and may be part of the software specifications.
Usable Secure Compatible Dependable Documented Is the product convenient, clear, and predictable? Is access to sensitive data restricted to those with authorization? Will the product work correctly in conjunction with existing data, software, and procedures? Do adequate safeguards against failure and methods for recovery exist in the product? Are manuals complete, correct, and understandable?
Fig. 31 : Attributes of software to be tested during system testing

177
Software Testing
Validation Testing
o It refers to test the software as a complete product. o This should be done after unit & integration testing. o Alpha, beta & acceptance testing are nothing but the various ways of involving customer during testing.
178
Software Testing
Validation Testing
o IEEE has developed a standard (IEEE standard 1059-1993) entitled IEEE guide for software verification and validation to provide specific guidance about planning and documenting the tasks required by the standard so that the customer may write an effective plan. o Validation testing improves the quality of software product in terms of functional capabilities and quality attributes.
179
Software Testing
The Art of Debugging
The goal of testing is to identify errors (bugs) in the program. The process of testing generates symptoms, and a programs failure is a clear symptom of the presence of an error. After getting a symptom, we begin to investigate the cause and place of that error. After identification of place, we examine that portion to identify the cause of the problem. This process is called debugging.
Debugging Techniques
Pressman explained few characteristics of bugs that provide some clues. 1. The symptom and the cause may be geographically remote. That is, the symptom may appear in one part of a program, while the cause may actually be located in other part. Highly coupled program structures may complicate this situation. 2. The symptom may disappear (temporarily) when another error is corrected.
180
Software Testing
3. The symptom may actually be caused by non errors (e.g. round off inaccuracies). 4. The symptom may be caused by a human error that is not easily traced. 5. The symptom may be a result of timing problems rather than processing problems. 6. It may be difficult to accurately reproduce input conditions (e.g. a real time application in which input ordering is indeterminate). 7. The symptom may be intermittent. This is particularly common in embedded system that couple hardware with software inextricably. 8. The symptom may be due to causes that are distributed across a number of tasks running on different processors.
181
Software Testing
Induction approach
Locate the pertinent data Organize the data Devise a hypothesis Prove the hypothesis
182
Software Testing
Fig. 32 : The inductive debugging process

183
Software Testing
Deduction approach
Enumerate the possible causes or hypotheses Use the data to eliminate possible causes Refine the remaining hypothesis Prove the remaining hypothesis
184
Software Testing
Fig. 33 : The inductive debugging process
185
Software Testing
Testing Tools
One way to improve the quality & quantity of testing is to make the process as pleasant as possible for the tester. This means that tools should be as concise, powerful & natural as possible. The two broad categories of software testing tools are :
Static Dynamic
186
Software Testing
There are different types of tools available and some are listed below: 1. Static analyzers, which examine programs systematically and automatically. 2. Code inspectors, who inspect programs automatically to make sure they adhere to minimum quality standards. 3. standards enforcers, which impose simple rules on the developer. 4. Coverage analysers, which measure the extent of coverage. 5. Output comparators, used to determine whether the output in a program is appropriate or not.
187
Software Testing
6. Test file/ data generators, used to set up test inputs. 7. Test harnesses, used to simplify test operations. 8. Test archiving systems, used to provide documentation about programs.
188
Multiple Choice Questions

Note: Choose most appropriate answer of the following questions:
8.1 Software testing is: (a) the process of demonstrating that errors are not present (b) the process of establishing confidence that a program does what it is supposed to do (c) the process of executing a program to show it is working as per specifications (d) the process of executing a program with the intent of finding errors 8.2 Software mistakes during coding are known as: (a) failures (b) defects (c) bugs (d) errors 8.3 Functional testing is known as: (a) Structural testing (c) Regression testing (b) Behavior testing (d) None of the above
8.4 For a function of n variables, boundary value analysis yields: (a) 4n+3 test cases (b) 4n+1 test cases (c) n+4 test cases (d) None of the above
189

8.5 For a function of two variables, how many cases will be generated by robustness testing? (a) 9 (b) 13 (c) 25 (d) 42 8.6 For a function of n variables robustness testing of boundary value analysis yields: (a) 4n+1 (b) 4n+3 (c) 6n+1 (d) None of the above 8.7 Regression testing is primarily related to: (a) Functional testing (b) Data flow testing (c) Development testing (d) Maintenance testing 8.8 A node with indegree=0 and out degree 0 is called (a) Source node (b) Destination node (c) Transfer node (d) None of the above 8.9 A node with indegree 0 and out degree=0 is called (a) Source node (b) Predicate node (c) Destination node (d) None of the above
190

8.10 A decision table has (a) Four portions (c) Five portions 8.11 Beta testing is carried out by (a) Users (c) Testers (b) Three portions (d) Two portions (b) Developers (d) All of the above
8.12 Equivalence class partitioning is related to (a) Structural testing (b) Blackbox testing (c) Mutation testing (d) All of the above 8.13 Cause effect graphing techniques is one form of (a) Maintenance testing (b) Structural testing (c) Function testing (d) Regression testing 8.14 During validation (a) Process is checked (b) Product is checked (c) Developers performance is evaluated (d) The customer checks the product
191

8.15 Verification is (a) Checking the product with respect to customers expectation (b) Checking the product with respect to specifications (c) Checking the product with respect to the constraints of the project (d) All of the above 8.16 Validation is (a) Checking the product with respect to customers expectation (b) Checking the product with respect to specifications (c) Checking the product with respect to the constraints of the project (d) All of the above 8.17 Alpha testing is done by (a) Customer (b) Tester (c) Developer (d) All of the above 8.18 Site for Alpha testing is (a) Software company (c) Any where (b) Installation place (d) None of the above
192

8.19 Site for Beta testing is (a) Software company (c) Any where 8.20 Acceptance testing is done by (a) Developers (c) Testers 8.21 One fault may lead to (a) One failure (c) Many failure 8.22 Test suite is (a) Set of test cases (c) Set of outputs (b) Users site (d) All of the above (b) Customers (d) All of the above (b) No failure (d) All of the above (b) Set of inputs (d) None of the above
8.23 Behavioral specification are required for: (a) Modeling (b) Verification (c) Validation (d) None of the above
193

8.24 During the development phase, the following testing approach is not adopted (a) Unit testing (b) Bottom up testing (c) Integration testing (d) Acceptance testing 8.25 Which is not a functional testing technique? (a) Boundary value analysis (b) Decision table (c) Regression testing (d) None of the above
8.26 Decision table are useful for describing situations in which: (a) An action is taken under varying sets of conditions. (b) Number of combinations of actions are taken under varying sets of conditions (c) No action is taken under varying sets of conditions (d) None of the above 8.27 One weakness of boundary value analysis and equivalence partitioning is (a) They are not effective (b) They do not explore combinations of input circumstances (c) They explore combinations of input circumstances (d) None of the above
194

8.28 In cause effect graphing technique, cause & effect are related to (a) Input and output (b) Output and input (c) Destination and source (d) None of the above 8.29 DD path graph is called as (a) Design to Design Path graph (b) Defect to Defect Path graph (c) Destination to Destination Path graph (d) Decision to decision Path graph 8.30 An independent path is (a) Any path through the DD path graph that introduce at least one new set of processing statements or new conditions (b) Any path through the DD path graph that introduce at most one new set of processing statements or new conditions (c) Any path through the DD path graph that introduce at one and only one new set of processing statements or new conditions (d) None of the above 8.31 Cyclomatic complexity is developed by (a) B.W.Boehm (b) T.J.McCabe (c) B.W.Lettlewood (d) Victor Basili
195

8.32 Cyclomatic complexity is denoted by (a) V(G)=e-n+2P (b) V(G)= +1 (c) V(G)=Number of regions of the graph (d) All of the above 8.33 The equation V(G)= +1 of cyclomatic complexity is applicable only if every predicate node has (a) two outgoing edges (b) three or more outgoing edges (c) no outgoing edges (d) none of the above 8.34 The size of the graph matrix is (a) Number of edges in the flow graph (b) Number of nodes in the flow graph (c) Number of paths in the flow graph (d) Number of independent paths in the flow graph
196

8.35 Every node is represented by (a) One row and one column in graph matrix (b) Two rows and two columns in graph matrix (c) One row and two columns in graph matrix (d) None of the above 8.36 Cyclomatic complexity is equal to (a) Number of independent paths (c) Number of edges 8.37 Data flow testing is related to (a) Data flow diagrams (c) Data dictionaries (b) Number of paths (d) None of the above (b) E-R diagrams (d) none of the above
8.38 In data flow testing, objective is to find (a) All dc-paths that are not du-paths (b) All du-paths (c) All du-paths that are not dc-paths (d) All dc-paths
197

8.39 Mutation testing is related to (a) Fault seeding (c) Fault checking (b) Functional testing (d) None of the above
8.40 The overhead code required to be written for unit testing is called (a) Drivers (b) Stubs (c) Scaffolding (d) None of the above 8.41 Which is not a debugging techniques (a) Core dumps (b) Traces (c) Print statements (d) Regression testing 8.42 A break in the working of a system is called (a) Defect (b) Failure (c) Fault (d) Error 8.43 Alpha and Beta testing techniques are related to (a) System testing (b) Unit testing (c) acceptance testing (d) Integration testing
198

8.44 Which one is not the verification activity (a) Reviews (b) Path testing (c) Walkthrough (d) Acceptance testing 8.45 Testing the software is basically (a) Verification (c) Verification and validation 8.46 Integration testing techniques are (a) Topdown (c) Sandwich (b) Validation (d) None of the above (b) Bottom up (d) All of the above
8.47 Functionality of a software is tested by (a) White box testing (b) Black box testing (c) Regression testing (d) None of the above 8.48 Top down approach is used for (a) Development (c) Validation (b) Identification of faults (d) Functional testing
199

8.49 Thread testing is used for testing (a) Real time systems (c) Event driven systems (b) Object oriented systems (d) All of the above
8.50 Testing of software with actual data and in the actual environment is called (a) Alpha testing (b) Beta testing (c) Regression testing (d) None of the above
200
Exercises
8.1 What is software testing? Discuss the role of software testing during software life cycle and why is it so difficult? 8.2 Why should we test? Who should do the testing? 8.3 What should we test? Comment on this statement. Illustrate the importance of testing 8.4 Defined the following terms: (i) fault (ii) (iii) bug (iv) failure mistake
8.5 What is the difference between (i) Alpha testing & beta testing (ii) Development & regression testing (iii) Functional & structural testing 8.6 Discuss the limitation of testing. Why do we say that complete testing is impossible?
201
Exercises
8.7 Briefly discuss the following (i) Test case design, Test & Test suite (ii) Verification & Validation (iii) Alpha, beta & acceptance testing 8.8 Will exhaustive testing (even if possible for every small programs) guarantee that the program is 100% correct? 8.9 Why does software fail after it has passed from acceptance testing? Explain. 8.10 What are various kinds of functional testing? Describe any one in detail. 8.11 What is a software failure? Explain necessary and sufficient conditions for software failure. Mere presence of faults means software failure. Is it true? If not, explain through an example, a situation in which a failure will definitely occur. 8.12 Explain the boundary value analysis testing techniques with the help of an example.
202
Exercises
8.13 Consider the program for the determination of next date in a calendar. Its input is a triple of day, month and year with the following range 1 month 12 1 day 31 1900 1 year 2025 The possible outputs would be Next date or invalid date. Design boundary value, robust and worst test cases for this programs. 8.14 Discuss the difference between worst test case and adhoc test case performance evaluation by means of testing. How can we be sure that the real worst case has actually been observed? 8.15 Describe the equivalence class testing method. Compare this with boundary value analysis techniques
203
Exercises
8.16 Consider a program given below for the selection of the largest of numbers
204
Exercises
(i) Design the set of test cases using boundary value analysis technique and equivalence class testing technique. (ii) Select a set of test cases that will provide 100% statement coverage. (iii) Develop a decision table for this program. 8.17 Consider a small program and show, why is it practically impossible to do exhaustive testing? 8.18 Explain the usefulness of decision table during testing. Is it really effective? Justify your answer. 8.19 Draw the cause effect graph of the program given in exercise 8.16. 8.20 Discuss cause effect graphing technique with an example. 8.21 Determine the boundary value test cases the extended triangle problem that also considers right angle triangles.
205
Exercises
8.22 Why does software testing need extensive planning? Explain. 8.23 What is meant by test case design? Discuss its objectives and indicate the steps involved in test case design. 8.24 Let us consider an example of grading the students in an academic institution. The grading is done according to the following rules:
Generate test cases using equivalence class testing technique
206
Exercises
8.25 Consider a program to determine whether a number is odd or even and print the message NUMBER IS EVEN Or NUMBER IS ODD The number may be any valid integer. Design boundary value and equivalence class test cases. 8.26 Admission to a professional course is subject to the following conditions:
207
Exercises
If aggregate marks of an eligible candidate are more than 225, he/she will be eligible for honors course, otherwise he/she will be eligible for pass course. The program reads the marks in the three subjects and generates the following outputs: (a) Not Eligible (b) Eligible to Pass Course (c) Eligible to Honors Course Design test cases using decision table testing technique. 8.27 Draw the flow graph for program of largest of three numbers as shown in exercise 8.16. Find out all independent paths that will guarantee that all statements in the program have been tested. 8.28 Explain the significance of independent paths. Is it necessary to look for a tool for flow graph generation, if program size increases beyond 100 source lines? 8.29 Discuss the structure testing. How is it different form functional testing?
208
Exercises
8.30 What do you understand by structural testing? Illustrate important structural testing techniques. 8.31 Discuss the importance of path testing during structural testing. 8.32 What is cyclomatic complexity? Explain with the help of an example. 8.33 Is it reasonable to define thresholds for software modules? For example, is a module acceptable if its V(G) 10? Justify your answer. 8.34 Explain data flow testing. Consider an example and show all du paths. Also identify those du paths that are not dc paths. 8.35 Discuss the various steps of data flow testing. 8.36 If we perturb a value, changing the current value of 100 by 1000, what is the effect of this change? What precautions are required while designing the test cases?
209
Exercises
8.37 What is the difference between white and black box testing? Is determining test cases easier in back or white box testing? Is it correct to claim that if white box testing is done properly, it will achieve close to 100% path coverage? 8.38 What are the objectives of testing? Why is the psychology of a testing person important? 8.39 Why does software fail after it has passed all testing phases? Remember, software, unlike hardware does not wear out with time. 8.40 What is the purpose of integration testing? How is it done? 8.41 Differentiate between integration testing and system testing. 8.42 Is unit testing possible or even desirable in all circumstances? Provide examples to Justify your answer? 8.43 Peteschenik suggested that a different team than the one that does integration testing should carry out system testing. What are some good reasons for this?
210
Exercises
8.44 Test a program of your choice, and uncover several program errors. Localise the main route of these errors, and explain how you found the courses. Did you use the techniques of Table 8? Explain why or why not. 8.45 How can design attributes facilitate debugging? 8.46 List some of the problem that could result from adding debugging statements to code. Discuss possible solutions to these problems. 8.47 What are various debugging approaches? Discuss them with the help of examples. 8.48 Researchers and practitioners have proposed several mixed testing strategies intended to combine advantages of various techniques discussed in this chapter. Propose your own combination, perhaps also using some kind of random testing at selected points. 8.49 Design a test set for a spell checker. Then run it on a word processor having a spell checker, and report on possible inadequacies with respect to your requirements.
211
Exercises
8.50 4 GLs represent a major step forward in the development of automatic program generation. Explain the major advantage & disadvantage in the use of 4 GLs. What are the cost impact of applications of testing and how do you justify expenditures for these activities.
212

Chapter 8 Software Testing

Uploaded by

Copyright:

Available Formats

Chapter 8 Software Testing

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 8 Software Testing

Uploaded by

Copyright:

Available Formats

Software Engineering (3rd ed.), By K.

These definitions are incorrect.

Fig. 1: Control flow graph

Fig. 2: Test case template

Input test data

Output test data

Fig. 3: Black box testing

Fig.4: Input domain for program having two input variables

400 300 y 200 100 0 100 200 x 300 400

Fig. 7: Equivalence partitioning

Expected output 14 June, 1962 Invalid date

x 100 100 100 50 50 50 25

Table 2: Decision table terminology

Table 3: Decision table for triangle problem

Table 4: Modified decision table

Test cases of triangle problem using decision table

Fig.8. 8 : Basic cause effect graph symbols

Fig. 9: Sample cause effect graph

Fig. 10: Constraint symbols

Fig. 11: Symbol for masks constraint

Fig. 12 : Sample cause effect graph with exclusive constraint

Table 6: Decision table

Fig. 13: Cause effect graph of triangle problem

Fig. 14: The basic construct of the flow graph

Fig. 15: Program for previous date problem

Fig. 16: Flow graph of previous date problem

Fig. 17: DD path graph of previous date problem

Fig. 18: Independent paths of previous date problem

Fig. 19: Code of quadratic equation problem

Fig. 19 (a) : Program flow graph

Fig. 19 (b) : DD Path graph

Fig. 20 : Code of triangle classification problem

Fig.8. 20 (a): Program flow graph

1 TO 9 10 11 12, 13 14 15, 16, 17 18 19 20, 21 22 23, 24 25, 26, 27

Fig. 20 (b): DD Path graph

Fig. 20 (b): DD Path graph

Fig. 21: Flow graph

(iii) V(G) = Number of regions = 18 The cyclomatic complexity is 18.

Fig. 24 (a): Flow graph and graph matrices

Fig. 24 (b): Flow graph and graph matrices

Fig. 24 (c): Flow graph and graph matrices

Fig. 25 : Connection matrix of flow graph shown in Fig. 24 (c)

Fig. 26 : Flow graph

iii. A variable is defined twice before it is used.

Fig. 27 : Steps for data flow testing

Path (beginning, end) nodes

Path (beginning, end) nodes

Path (beginning, end) nodes

Yes Yes Yes Yes Yes Yes Yes Yes

Path (beginning, end) nodes

9, 10 9, 11 9, 19 9, 22 3, 18 3, 29 12, 18 12, 29 16, 18 16, 29

Yes Yes Yes Yes no no no no Yes Yes

# killed 100% # total # equivalent

Fig. 29 : Scaffolding required testing a program unit (module)

Fig. 30 : Three different integration approaches

Fig. 31 : Attributes of software to be tested during system testing

Fig. 32 : The inductive debugging process

Fig. 33 : The inductive debugging process

Multiple Choice Questions

Multiple Choice Questions