If RapiTime provides Ipoint coverage, why do I need RapiCover?

Users of RapiTime will probably be aware that one of the categories of information shown in a RapiTime report is "Ipoint Coverage". So, given that RapiTime supplies coverage information, why do you need RapiCover?

The answer relates to the way this information is intended to be used, and also the sections of the source code that it relates to.

What is the purpose of RapiTime's Ipoint coverage measurement?

At first glance, RapiTime provides coverage information, i.e. an indication of how much code was exercised during testing. However, there is a specific motivation behind RapiTime’s display of coverage data.

RapiTime's analysis is carried out at the basic block level - as part of the process it generates a control-flow graph representing all the possible paths through all the blocks in the software. It then inserts instrumentation at the scope boundaries to allow it to calculate the execution time of each basic block. By a combination of analysing all the possible paths through the code, and measuring the execution time for each basic block, RapiTime is able to calculate a worst-case execution time value for the software.

In order to ensure this value is accurate (in particular, to make sure that the WCET is not optimistic) the software must be adequately exercised during the testing. As a minimum, to obtain an accurate WCET value it is necessary to have executed each basic block of code at least once. As each Ipoint is associated with a single block of code, we can tell how effectively the code has been exercised by reporting the number of executed and un-executed Ipoints. This is reason behind the Ipoint coverage measurement shown in the RapiTime report.

So why do I need RapiCover?

Typical coverage tools provide information on so-called "structural coverage metrics" - that is, the coverage information is associated with particular elements of the source code structure. Typical structural elements include functions, statements and decisions. Software developed at the highest levels of criticality is tested for coverage at MC/DC level, which requires that the effect of each condition that can contribute to the outcome of a decision must be observed during testing. Structural code coverage information is used to confirm that software has been adequately exercised during testing, and it is this type of coverage measurement, up to and including MC/DC, that RapiCover is intended to provide.

Figure 1: RapiCover structural coverage

Because RapiTime’s Ipoint coverage is reported at the basic block level it is not possible to use it to determine structural coverage using any of the traditional metrics (other than function coverage). RapiCover inserts instrumentation to allow it to calculate structural coverage for the chosen metric. Typically, this requires more instrumentation than is necessary for timing, located at different points in the source code. The execution traces generated by instrumentation provide you with code coverage metrics which identify which sections of code are either untested or covered by unnecessary test cases.