Coverage Analyzer: Performance

Before Release SAP NetWeaver 7.0 EHP2, the performance impact of the Coverage Analyzer was minimal as long as

• You use less than five test groups- the fewer the better. For each user group, a separate set of coverage statistics is created.

• You do not collect histories and do not use the Global Display. The Global Display is a valuable tool for tracking trends in code coverage. But it does have an impact on the workload in the ABAP application server.

The addition of statement and branch coverage as of EHP2 changes this favorable picture. Collecting statement and branch coverage causes significant workload, and collection of these statistics cannot be separately switched on or off.

Recommendations for activating the Coverage Analyzer:

• In Production Systems: Only as necessary to create coverage profiles from real users for such purposes as the following:

  • Validating your unit and integration testing by comparing the code coverage of test and production users

  • Finding unused code.

• In Development Systems: Only as necessary to support test-driven development with its reliance on ABAP Unit testing.

  Activating the Coverage Analyzer in development systems may be sensible if you practice test-driven development or create ABAP Unit or other tests. Note, however, that developers can check the code coverage of ABAP Unit tests with the ABAP Unit Browser, even if the Coverage Analyzer is not activated.

• In Quality Assurance Test Systems: The Coverage Analyzer should be switched on in such systems.

  Since the performance impact is usually tolerable, you can in principle activate the Coverage Analyzer routinely on Quality Assurance Test systems. However, the Coverage Analyzer should be activated only in systems in which testing is being done and in which you wish to analyze test coverage. Otherwise, you are collecting data that is not used.

The phases in which the Coverage Analyzer has an impact on system workload and performance are as follows:

1. Measurement: When the Coverage Analyzer is working, it records the execution of processing blocks using instrumentation in the kernel.

   Since the addition of statement and branch coverage to processing block coverage, the cost of measurement has become too large to be ignored, as was previously the case.

2. Transferring data from shared memory to the database: The data collected by the Coverage Analyzer is picked up from shared memory at regular intervals by background jobs. This data is then written to the database.

   The time required for this operation depends on the quantity of data involved. Performance measurements on representative systems show a processing speed of approximately 10 programs or 100 processing blocks per second. The number of processing blocks to be included is generally in linear proportion to the number of test groups. For this reason, the number of test groups must be kept as small as possible. The number of test groups should not exceed 5 in any case.

3. Creating histories: With an optional background job, you can create aggregated histories of code coverage.

   You select the packages to be included in a history through the menu path  Administration  Settings  Packages to be included when creating the history . You should limit the data aggregated in histories to the packages that belong to your development projects.

   Each run of the history batch job creates a data set for the history. You should not choose too fine a granularity for these data sets. One code coverage measurement per day should be adequate.

4. Creating combined statistics with data from the local system and from one or more remote systems. With an optional background job, you can create combined, total code coverage statistics across systems.

   Since this job typically collects data from only a few systems and runs infrequently, its performance impact is negligible.