Show TOC

Coverage Analyzer: TechnologyLocate this document in the navigation structure

Use

Structure

Coverage analysis in ABAP involves an interplay between kernel-level instrumentation for measuring coverage and higher-level mechanisms for managing coverage analysis and the data that the instrumentation provides.

This section describes important features of this infrastructure:

  • What happens when you activate or deactivate the Coverage Analyzer

  • How the Coverage Analyzer generates and manages metadata for consuming raw data from the coverage analyzer instrumentation in the kernel

  • How the Coverage Analyzer transports coverage data from the kernel instrumentation to the database efficiently

  • How the Coverage Analyzer generates coverage history data

  • What happens to coverage data if code is changed

  • How the Coverage Analyzer aggregates coverage data from other systems

  • Which ABAP statements count in calculating coverage.

Activating and Deactivating the Coverage Analyzer

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 starts the job RSCVR_INIT_START. It also schedules a periodic background job ( RSCVR_TRIGGER_COLLECT) for persisting code coverage data in the database.

When you deactivate the Coverage Analyzer, it runs background job RSCVR_DELETE_COVTAB to delete the statistics held in the Coverage Analysis tables. There is no reason to retain coverage data if the Coverage Analyzer has been deactivated.

Generating and Managing Metadata

For calculating results, the Coverage Analyzer needs metadata about the programs in the system, such as a database of the processing blocks in each program. Before SAP NetWeaver Release 7.0 EHP3, this metadata was generated during a resource-intensive initialization step when the Coverage Analyzer is switched on.

As of EHP3, the Coverage Analyzer builds its metadata on the fly, on an as-needed basis. The expensive initialization step has been eliminated.

And the Coverage Analyzer no longer increases the workload during activation of programs. Previous to EHP3, the Coverage Analyzer used the event of activation as a trigger for re-generating its metadata. As of EHP3, this time-consuming step has been removed from activation.

Transporting Coverage Analysis Data to the Database

When the Coverage Analyzer is active, 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.

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.

Generating a Code Coverage History

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.

What Happens to Coverage Data If Code Changes

If the code in a system changes, then the reset functionality of the Coverage Analyzer comes into play. This functionality ensures that:

  • Changes to code - direct or by way of imports - do not falsify the code coverage statistics

  • You can reset the statistics collected by the Coverage Analyzer at will. You can, for example, reset the statistics to start a new test cycle in a Quality Assurance test system.

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 is 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.

Figure 1: Example: Combined Procedure Coverage Statistics from Local and Remote Systems

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:

  • Data declaration statements (for example DATA)

  • Code structure statements (for example METHOD/ ENDMETHOD)

  • Control flow statements (for example, ELSE/ ENDIF)

  • Selection screen statements and program events (for example SELECTION-SCREEN)

  • The ENDEXEC statement

  • Macro definitions ( DEFINE/ END-OF-DEFINITION and statements in the body of the macro)

  • INCLUDE statements (but included statements are counted).