| Statement Coverage | | Print | |
|
This metric reports whether each executable statement is encountered. The chief advantage of this metric is that it can be applied directly to object code and does not require processing source code. Performance profilers commonly implement this metric. The chief disadvantage of statement coverage is that it is insensitive to some control structures. For example, consider the following C/C++ code fragment: int* p = NULL; if (condition) p = &variable; *p = 123; Without a test case that causes condition to evaluate false, statement coverage rates this code fully covered. In fact, if condition ever evaluates false, this code fails. This is the most serious shortcoming of statement coverage. If-statements are very common. Statement coverage does not report whether loops reach their termination condition - only whether the loop body was executed. With C, C++, and Java, this limitation affects loops that contain break statements. Since do-while loops always execute at least once, statement coverage considers them the same rank as non-branching statements. Statement coverage is completely insensitive to the logical operators (|| and &&). Statement coverage cannot distinguish consecutive switch labels. Test cases generally correlate more to decisions than to statements. You probably would not have 10 separate test cases for a sequence of 10 non-branching statements; you would have only one test case. For example, consider an if-else statement containing one statement in the then-clause and 99 statements in the else-clause. After exercising one of the two possible paths, statement coverage gives extreme results: either 1% or 99% coverage. Basic block coverage eliminates this problem. One argument in favor of statement coverage over other metrics is that bugs are evenly distributed through code; therefore the percentage of executable statements covered reflects the percentage of faults discovered. However, one of our fundamental assumptions is that faults are related to control flow, not computations. Additionally, we could reasonably expect that programmers strive for a relatively constant ratio of branches to statements. In summary, this metric is affected more by computational statements than by decisions.
Set as favorite
Bookmark
Email this
Hits: 1742 Comments (0)
![]() Write comment
|
| Related Articles: |
|---|
|
Software Testing
- Introduction to Software Testing
- Automated Software Testing
- Different Types Of Software Testing
- Software Testing Levels
- Software Testing Tools
- Software Performance Testing
- Web Testing Techniques
- Software Security Assurance
- Software Testing Certification
- Testing Check Lists
- Software QA Testing Career
- SOA and Web Services Testing
Statement Coverage