Structure

The following diagram illustrates how the Coverage Analyzer and ABAP Interpreter interact:

Let's start with the central User Interface section of the diagram above. When a user activates the Coverage Analyzer, then the Coverage Analyzer performs a set of preparatory steps before code coverage measurement can start. Among other tasks, the Coverage Analyzer activates its instrumentation in the ABAP Engine and schedules a periodic background job (RSCVR_TRIGGER_COLLECT) for persisting code coverage data in the database.

As part of this initialization, the Coverage Analyzer must re-generate all of the ABAP code in the system, largely in order to build a database of the processing blocks in the programs. This initialization task, performed in the background jobs RSCVR_INIT_START and RSCVR_INIT, is shown in the ABAP Engine section of the diagram as the 'generate' operation.

The initialization phase is the only workload-intensive part of Coverage Analyzer operation. The Coverage Analyzer should therefore be activated at a time of low workload (evening or weekend). After the initialization, the Coverage Analyzer maintains its database of processing blocks on an incremental, as-needed basis.

Should any of the initialization tasks fail, you will receive messages and find alerts describing the problem in the Monitor.

The ABAP Engine section of the diagram shows the collection of code coverage statistics in the 'run' operation. Instrumentation embedded in the ABAP kernel measures the execution of processing blocks, branches, and statements as programs run.

Initially, code coverage statistics are held in the local memory of the individual work processes. From there, they migrate to server shared memory. To persist this data in the database, the Coverage Analyzer starts the periodic batch job RSCVR_TRIGGER_COLLECT. This job in turn runs the collector report RSCVR_COLLECT on all application servers of a system at which the Coverage Analyzer is active. Initially, RSCVR_COLLECT transfers data to the 'staging area' of table COVRES0. Finally, the new data is aggregated with the statistics in tables COVRES and COVREF, among others.

A separate optional job — the history collector, job RSCVR_BUILD_GLOBAL_VIEW — can also run to aggregate code coverage statistics for the Global Display. You determine the frequency with which this job runs. Each run adds a data record to the current history version. A job period of 1 day therefore creates one data record for each day in the current history.

A history aggregates code coverage to the level of the packages in the system. The Detail Display offers a look at the raw code coverage data for individual programs and their components.

The kernel-level instrumentation and the staged transfer of data from work-process memory to the database ensure that measuring code coverage costs very little in terms of performance.

The Resetting section of the diagram illustrates the reset functionality of the Coverage Analyzer. This functionality ensures that:

Whenever a processing block is changed, the Coverage Analyzer automatically resets the current counters of the processing block. It also increments the reset counter to show that a reset has occurred. The current counters record code coverage since the last reset. The cumulative counters, which record code coverage since the last activation of the Coverage Analyzer or the last manual reset of the statistics in transaction SCOV, are not affected by automatic resets in the event of code changes. The effects of automatic resets become visible only after the affected program has been activated.

If a processing block is deleted, then the Coverage Analyzer deletes all current and cumulative counters that pertain to the processing block.

If you manually reset the statistics in transaction SCOV, then the Coverage Analyzer resets both the current and cumulative counters of the affected programs and their processing blocks.

Code coverage statistics saved in histories are not affected by resets, automatic or manual.

Aggregated Data from Remote Systems

You can have the Coverage Analyzer consolidate code coverage results from multiple systems in your local system. For this feature, the Coverage Analyzer uses RFC to gather code coverage statistics from the remote system or remote systems. The collector runs in the background job RSCVR_FILL_REMOTE.

The Coverage Analyzer gathers statistics only for the processing blocks that have been successfully initialized in the local system.

It combines the local and remote statistics at the level of processing blocks to create a statistic for total procedure coverage across the systems. The combined statistics are viewable both at the package level in the Global Display and for individual program objects in the Detail Display.

In both displays, the combined statistics are stored under test group COND, for 'condensed'. The code coverage status for the combined statistics are calculated with respect to the settings in the system that collects the statistics.

The aggregated systems must have the same Release, and must be newer than Release 4.6C.

The example in the following graphic shows how four systems [S1, S4] with a total of four processing blocks [V1, V4] are aggregated. The names of the processing blocks used are inverted and underlined.

In this example, the aggregated degree of coverage is 100% because each processing block is called up at least once in all the systems. In the local systems, the degree of coverage is only 25% for S1 –S3 and 75% for S4. A degree of coverage > 0 is achieved if the conditions defined under Settings are fulfilled.

Which Statements Count?

The Coverage Analyzer counts all statements (for calculating statement and branch coverage) except for the following ABAP statements:

Clean-Up on Deactivation

When you deactivate the Coverage Analyzer, it runs background job RSCVR_DELETE_COVTAB to delete the statistics held in table COVRES.