Hui guys can anyone let me know about the Statement Coverage :

- Vignesh

This document lists the requirements for a statement coverage tool for modules, describes some issues in design and implementation, and compares with other statement coverage implementations.

1.You can run many tests and perform coverage analysis based on all the tests.

2.You can get a summary report showing coverage for a set of modules and the total.

3.You can annotate program source code to show which statements are covered.

4.Recording of coverage information doesn't slow down a test case more than necessary.

Statement Coverage
This measure reports whether each executable statement is encountered.
Also known as: line coverage, segment coverage and basic block coverage. Basic block coverage is the same as statement coverage except the unit of code measured is each sequence of non-branching statements.
The chief advantage of this measure is that it can be applied directly to object code and does not require processing source code. Performance profilers commonly implement this measure.
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 measures is that faults 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 measure is affected more by computational statements than by decisions.

Thanks & Regards,
Santosh Malvi
Module Lead