Code Coverage

Code Coverage(from wikipedia)

This article defines "Code Coverage" and gives the main forms of coverage criteria. You can go tohttp://en.wikipedia.org/wiki/Code_coverage to visit the origianl. IP address of china can access this site. You have to find a valid oversea proxy for your IE.

Code coverageis a measure used insoftware testing. It describes the degree to which thesource codeof aprogramhas been tested. It is a form of testing that looks at the code directly and as such comes under the heading ofwhite box testing.

Code coverage techniques were amongst the first techniques invented for systematic software testing. The first published reference was by Miller and Maloney inCommunications of theACMin 1963.

To measure how well the program is exercised by atest suite, one or morecoverage criteriaare used. There are a number of coverage criteria, the main ones being:

 Function coverage- Has each function in the program been executed?

 Statement coverage- Has each line of the source code been executed?

 Condition coverage- Has each evaluation point (such as a true/false decision) been executed?

 Path coverage- Has every possible route through a given part of the code been executed?

 Entry/exit coverage- Has every possible call and return of the function been executed?

Safety-criticalapplications are often required to demonstrate that testing achieves 100% of some form of code coverage.

Some of the coverage criteria above are connected. For instance, path coverage implies condition, statement and entry/exit coverage. Statement coverage doesnotimply condition coverage, as the code (in theC programming language) below shows:

void foo(int bar)

{

   printf("This is ");

    if (bar <= 0)

   {

       printf("not ");

   }

   printf("a positive integer.\n");

   return;

}

If the functionfoowere called with variablebarset to −1, statement coverage would be achieved. Condition coverage, however, would not.

Full path coverage, of the type described above, is usually impractical or impossible. Any module with a succession ofndecisions in it can have up to2ⁿpaths within it; loop constructs can result in an infinite number of paths. Many paths may also be infeasible, in that there is no input to the program under test that can cause that particular path to be executed. However, a general-purpose algorithm for identifying infeasible paths has been proven to be impossible (such an algorithm could be used to solve thehalting problem). Techniques for practical path coverage testing instead attempt to identify classes of code paths that differ only in the number of loop executions, and to achieve "basis path" coverage the tester must cover all the path classes.

Usually the source code is instrumented and run through a series of tests. The resulting output is then analysed to see what areas of code have not been exercised, and the tests are updated to include these areas as necessary. Combined with other code coverage methods the aim is to develop a rigorous yet manageable set of regression tests.

Code coverage is ultimately expressed as a percentage, as in "We have tested 67% of the code." The meaning of this depends on what form(s) of code coverage have been used, as 67% path coverage is more comprehensive than 67% statement coverage.

The value of code coverage as a measure of test quality is debated (see external links).