Download Chapter 14 Software Testing Techniques and more Exercises Designs and Groups in PDF only on Docsity!
Chapter 14
Software Testing Techniques
- Testing fundamentals
- White-box testing
- Black-box testing
- Object-oriented testing methods (Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)
Characteristics of Testable
Software
- Operable
- The better it works (i.e., better quality), the easier it is to test
- Observable
- Incorrect output is easily identified; internal errors are automatically detected
- Controllable
- The states and variables of the software can be controlled directly by the tester
- Decomposable
- The software is built from independent modules that can be tested independently
(more on next slide)
Test Characteristics
- A good test has a high probability of finding an error
- The tester must understand the software and how it might fail
- A good test is not redundant
- Testing time is limited; one test should not serve the same purpose as another test
- A good test should be “best of breed”
- Tests that have the highest likelihood of uncovering a whole class of errors should be used
- A good test should be neither too simple nor too complex
- Each test should be executed separately; combining a series of tests could cause side effects and mask certain errors
Two Unit Testing Techniques
- Black-box testing
- Knowing the specified function that a product has been designed to perform, test to see if that function is fully operational and error free
- Includes tests that are conducted at the software interface
- Not concerned with internal logical structure of the software
- White-box testing
- Knowing the internal workings of a product, test that all internal operations are performed according to specifications and all internal components have been exercised
- Involves tests that concentrate on close examination of procedural detail
- Logical paths through the software are tested
- Test cases exercise specific sets of conditions and loops
White-box Testing
- Uses the control structure part of component-level design to derive the test cases
- These test cases
- Guarantee that all independent paths within a module have been exercised at least once
- Exercise all logical decisions on their true and false sides
- Execute all loops at their boundaries and within their operational bounds
- Exercise internal data structures to ensure their validity “Bugs lurk in corners and congregate at boundaries”
Basis Path Testing
- White-box testing technique proposed by Tom McCabe
- Enables the test case designer to derive a logical complexity measure of a procedural design
- Uses this measure as a guide for defining a basis set of execution paths
- Test cases derived to exercise the basis set are guaranteed to execute every statement in the program at least one time during testing
10
Flow Graph Example
R
R
R
R
FLOW CHART FLOW GRAPH 0
Independent Program Paths
- Defined as a path through the program from the start node until the end node that introduces at least one new set of processing statements or a new condition (i.e., new nodes)
- Must move along at least one edge that has not been traversed before by a previous path
- Basis set for flow graph on previous slide
- Path 1: 0- 1 - 11
- Path 2: 0- 1 - 2 - 3 - 4 - 5 - 10 - 1 - 11
- Path 3: 0- 1 - 2 - 3 - 6 - 8 - 9 - 10 - 1 - 11
- Path 4: 0- 1 - 2 - 3 - 6 - 7 - 9 - 10 - 1 - 11
- The number of paths in the basis set is determined by the cyclomatic complexity
Deriving the Basis Set and Test Cases
- Using the design or code as a foundation, draw a corresponding flow graph
- Determine the cyclomatic complexity of the resultant flow graph
- Determine a basis set of linearly independent paths
- Prepare test cases that will force execution of each path in the basis set
14 A Second Flow Graph Example 1 int functionY(void) 2 { 3 int x = 0; 4 int y = 19; 5 A: x++; 6 if (x > 999) 7 goto D; 8 if (x % 11 == 0) 9 goto B; 10 else goto A; 11 B: if (x % y == 0) 12 goto C; 13 else goto A; 14 C: printf("%d\n", x); 15 goto A; 16 D: printf("End of list\n"); 17 return 0; 18 }
16 A Sample Function to Diagram and Analyze 1 int functionZ(int y) 2 { 3 int x = 0; 4 while (x <= (y * y)) 5 { 6 if ((x % 11 == 0) && 7 (x % y == 0)) 8 { 9 printf(“%d”, x); 10 x++; 11 } // End if 12 else if ((x % 7 == 0) || 13 (x % y == 1)) 14 { 15 printf(“%d”, y); 16 x = x + 2; 17 } // End else 18 printf(“\n”); 19 } // End while 20 printf("End of list\n"); 21 return 0; 22 } // End functionZ
Loop Testing - General
- A white-box testing technique that focuses exclusively on the validity of loop constructs
- Four different classes of loops exist
- Simple loops
- Nested loops
- Concatenated loops
- Unstructured loops
- Testing occurs by varying the loop boundary values
- Examples: for (i = 0; i < MAX_INDEX; i++) while (currentTemp >= MINIMUM_TEMPERATURE)
Testing of Nested Loops
- Start at the innermost loop; set all other loops to minimum values
- Conduct simple loop tests for the innermost loop while holding the outer loops at their minimum iteration parameter values; add other tests for out-of-range or excluded values
- Work outward, conducting tests for the next loop, but keeping all other outer loops at minimum values and other nested loops to “typical” values
- Continue until all loops have been tested
Testing of Concatenated Loops
- For independent loops, use the same approach as for simple loops
- Otherwise, use the approach applied for nested loops