Simple Automated Code Coverage Method for test metrics.
Publication Date: 2010-Nov-29
The IP.com Prior Art Database
Simple Automated Code Coverage Method for test metrics. Fast , automated and reusable instrumentation of statement code coverage method that is even applicable to large software packages (in source code form) by using a flat bitmapped shared memory that represents unique code blocks in the targeted software package and inserting unique coverage macro entries to set this memory for per code-block via a coverage code-block language parser. Once source is recompiled the package is ready for giving metrics on statement coverage upon tests.
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
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
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 =
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,
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.
arser. When the source is recompiled, using the disclosed process, the package is ready for
conditions there needs to be 2
a = false b =
N/A c =
practical manner only interesting subsets of paths are targeted in the coverage
Page 02 of 5
The previously defined methods are typically...