Dependable Software Systems (Control-Flow Testing)
Dependable Software Systems (Control-Flow Testing) © SERG
Dependable Software Systems
Topics in
Control-Flow Testing
Material drawn from [Beizer, Mancoridis]
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Control Flow Testing - Dependable Software Systems | CS 576, Exams of Computer Science
Material Type: Exam; Professor: Mancoridis; Class: Dependable Software Systems; Subject: Computer Science; University: Drexel University; Term: Unknown 1989;
Typology: Exams
Pre 2010
1 / 66
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Control Flow Testing - Dependable Software Systems | CS 576 and more Exams Computer Science in PDF only on Docsity!
Dependable Software Systems
Topics in Control-Flow Testing Material drawn from [Beizer, Mancoridis]
Control-Flow Testing
- Control-flow testing is a structural testing strategy that uses the program’s control flow as a model.
- Control-flow testing techniques are based on judiciously selecting a set of test paths through the program.
- The set of paths chosen is used to achieve a certain measure of testing thoroughness.
- E.g., pick enough paths to assure that every source statement is executed as least once.
Control Flowgraphs
- The control flowgraph is a graphical representation of a program’s control structure.
Flowgraphs Consist of
Three Primitives
- A decision is a program point at which the control can diverge. - ( e.g., if and case statements).
- A junction is a program point where the control flow can merge. - ( e.g., end if, end loop, goto label)
- A process block is a sequence of program statements uninterrupted by either decisions or junctions. ( i.e., straight-line code). - A process has one entry and one exit. - A program does not jump into or out of a process.
Exponentiation Algorithm
(^1 23 45 ) 1 scanf(“%d %d”,&x, &y); 2 if (y < 0) pow = -y; else pow = y; 3 z = 1.0; 4 while (pow != 0) { z = z * x; pow = pow - 1; 5 } 6 if (y < 0) z = 1.0 / z; 7 printf (“%f”,z);
Bubble Sort Algorithm
1 2 3 4 5 6 7 1 for (j=1; j<N; j++) { last = N - j + 1; 2 for (k=1; k<last; k++) { 3 if (list[k] > list[k+1]) { temp = list[k]; list[k] = list[k+1]; list[k+1] = temp; 4 } 5 } 6 } 7 print(“Done\n”);
Paths (Cont’d)
- The length of a path is the number of links in a path.
- An entry/exit path or a complete path is a path that starts at a routine’s entry and ends at the same routine’s exit.
Paths (Cont’d)
- Complete paths are useful for testing because: - It is difficult to set up and execute paths that start at an arbitrary statement. - It is difficult to stop at an arbitrary statement without changing the code being tested. - We think of routines as input/output paths.
How do we define
“complete” testing?
- Exercise every path from entry to exit.
- Exercise every statement at least once.
- Exercise every branch (in each direction) at least once.
- Clearly, 1 implies 2 and 3
- However, 1 is impractical for most routines.
- Also, 2 is not equal to 3 in languages with goto statements.
Demonstration that
2 does not imply 3
- 2.Statement Coverage: For x < 0 the program produces the correct result AND every statement has been executed.
- 3.Branch Coverage: Would have found the bug! Therefore 2 does not imply 3. 1 2 Correct Code 1 if (x >= 0 ) { x = x + A; } 2 x = x + A Buggy Code 1 if (x >= 0 ) { /* missing statement */ } 2 x = x + A
Control-flow Testing Criteria
- We have explored 3 testing criteria from an infinite set of strategies: - 1) Path Testing ( ): - 100% path coverage. - Execute all possible control flow paths through the program. ! P
Control-flow Testing
Criteria (Cont’d)
- Statement Testing ( ):
- 100% statement coverage.
- Execute all statements in a program at least once under some test.
- Branch Testing ( ):
- 100% branch coverage.
- Execute enough tests to assure that every branch alternative has been exercised at least once under some test.
1
P
2
P
P " P " ... " P
Common Sense Strategies (Cont’d)
- It makes sense to use branch coverage because software has a high density of conditional branches, loop, etc. (25% in most PLs)
- It is better to leave out untested code than to include it in a product release.
Quote
“The more we learn about testing, the more we realize that statement and branch coverage are minimum floors below which we dare not fall, rather that ceilings to which we should aspire.”
- B. Beizer.