Browse Prior Art Database

Simple Automated Code Coverage Method for test metrics.

IP.com Disclosure Number: IPCOM000201864D
Publication Date: 2010-Nov-29
Document File: 5 page(s) / 46K

Publishing Venue

The IP.com Prior Art Database

Abstract

Simple Automated Code Coverage Method for test metrics.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 27% of the total text.

Page 01 of 5

Simple Automated Code Coverage Method for test metrics .

Disclosed is a process for instrumentation of statement code coverage that is applicable to large software packages (in source code form). The disclosed process uses a flat bitmapped shared memory that represents unique code blocks in a targeted software package and inserts unique coverage macro entries to set the memory per code-block via a coverage code-block language

p

providing metrics on statement coverage upon testing.

Quality of a software product highly depends on product testing. Once a product is shipped, the cost of fixing a defect increases significantly and customer satisfaction decreases. This highlights the importance of testing. Testing of a software product will trigger a certain amount of source code during test runs. There are several metrics in code coverage to be considered.

Function coverage deals with granularity at function level whether the code is called or not. A very high level view of the coverage may not be very useful. Statement coverage defines whether all statements in the code executed. Branch coverage deals with branches in the code. Even when all statements are covered, all branches are not necessarily covered. For example when an else case does not exist in a code block, statements could be covered without all

possible branches traversed.

Condition coverage determines for each condition written, whether a value of true or false may be obtained with changing input. An exception test is built with intelligence, in which for

N

                   test cases to cover all conditions and is impractical. In practice, a simplified version of this approach eliminates the case from a logical derivation to reduce the number of test cases. For example using (a && b && c) a logical evaluation can be tested by four test cases instead of 23 = 8.

a = true b= true c = true a = true b = true c = false a = true b = false c =

N

N

Path coverage is traversing all possible paths instead of branch and condition coverage. Path coverage is not useful when program loops are considered. The definition of path coverage is (

/ number of paths) in this case path coverage becomes always zero. In a more

.

Implementation of previously defined methods typically suffers from a number of drawbacks. The previously defined methods are typically intrusive, lose performance, resources and inapplicable to large software packages. The previously defined methods are further impractical (for example,

p

         ath coverage, branch coverage, condition coverage that requires a number of test cases approximated by a power of 2 for a simple function) or not enough granularity, for example, function coverage.

1

arser. When the source is recompiled, using the disclosed process, the package is ready for

conditions there needs to be 2

N

/A

/A

a = false b =

N/A c =

p

d

aths traverse

practical manner only interesting subsets of paths are targeted in the coverage


Page 02 of 5

The previously defined methods are typically...