Analysis Tools - Coverage API

Using the Coverage API
PDF download from SAP Help Portal:

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/b7/d1dd55e08c4ddbb2a6cb812ef9861a/content.htm
Created on April 04, 2014
The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.
Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.
2014 SAP AG or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG
and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by
SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be
liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express
warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other
SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other
countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.
Table of content
PUBLIC
2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 1 of 30
Table of content
1 Using the Coverage API
1.1 Prerequisites for Using the Code Coverage API
1.2 Differences Between the Coverage Analyzer and the Coverage API
1.3 Measuring Code Coverage in Overview
1.4 Coverage API: Quick Reference
1.5 Tutorial: Measuring Code Coverage with the Coverage API
1.5.1 Step 1: Creating a Measurement
1.5.2 Step 2: Measuring Code Coverage
1.5.3 Step 3: Calculating Code Coverage Results
1.5.4 Step 4: Traversing the Hierarchy of Results
1.5.5 Step 5: Displaying the Code Coverage Results
1.5.6 Step 6: Saving and Retrieving Code Coverage Results
1.5.7 Step 7: Finalizing a Measurement
1.5.8 Measurement Tutorial: Sample Program
1.6 Tutorial: Working with a Measurement Series
1.6.1 Step 1: Creating or Loading a Measurement Series
1.6.2 Step 2: Setting Defaults for a Measurement Series
1.6.3 Step 3: Creating and Running a Measurement in a Measurement Series
1.6.4 Step 4: Calculating Coverage Results in a Measurement Series
1.6.5 Step 5: Saving Measurements and Results in a Measurement Series
1.6.6 Step 6: Finding Measurements and Results in a Measurement Series
1.6.7 Measurement Series Tutorial: Sample Program
1.7 Default Settings: Result Configurations and Object Selections
1.7.1 Using Selection Objects
1.7.2 Configuring Results
1.8 Coverage API: Additional Topics
1.8.1 Saving and Reloading a Measurement
1.8.2 Merging Code Coverage Measurements
1.8.3 Assigning Measurements to a Measurement Series
1.8.4 Handling Exceptions in the Code Coverage API
1.8.5 Recovering From a Blocked Measurement
1.8.6 Naming Measurements and Results
1.9 Glossary
1.9.1 Measurement
1.9.2 Branch Code Coverage
1.9.3 Statement Code Coverage
1.9.4 Procedure Code Coverage
1.9.5 Measurement Series
1.9.6 Coverage API Repository
1.9.7 Coverage API Users
1.9.8 Raw Data
1.9.9 Result
1.9.10 Selection Object
1.9.11 Configuration Object
1.9.12 Test Key
PUBLIC
Page 2 of 30
1 Using the Coverage API
Use
The Coverage API - new with NetWeaver 7.0 EHP2 (SAP_BASIS Release 7.02, delivered with SAP ERP EHP5) - gives you programmatic access to ABAP's
technology for measuring code coverage.
The Coverage API lets you precisely control the measurement of code coverage. You can start and stop measurements, specify which users are to be measured,
calculate and display coverage results, and work with series of repeated measurements.
The API offers you an alternative to the Coverage Analyzer, transaction SCOV, for collecting and displaying code coverage statistics. See also Differences
Between the Coverage Analyzer and the Coverage API.
Intended Uses
The API is intended for these uses:
Instrumentation of test infrastructures for measuring code coverage: Owners of test infrastructures can add code coverage instrumentation to their
infrastructures. The test infrastructure can then switch code coverage on and off by itself.
In this way, the infrastructure can collect code coverage statistics that are limited precisely to tests run by the infrastructure. The measurement excludes
other activity from the statistics, even if it generated by the test users.
Example: An infrastructure for running integration tests could use the API to switch on code coverage when a user starts a test and then stop it when the test
is completed. The measurement excludes other activity in the system by the test user.
Ad hoc measurement of code coverage by developers or quality managers who wish to collect their own code coverage statistics. The API is quite
easy to use, so that collecting your own statistics is possible with relatively little effort.
Example: A developer can already use the ABAP Unit Browser to measure the code coverage of ABAP Unit tests. With the Coverage API, a developer can
instrument other test programs and can check the code coverage of these programs.
Main Links
Prerequisites for Using the Code Coverage API
Measuring Code Coverage in Overview
Tutorial: Measuring Code Coverage with the Coverage API
Tutorial: Working with a Measurement Series
Default Settings: Result Configurations and Object Selections
Coverage API: Additional Topics
Glossary
1.1 Prerequisites for Using the Code Coverage API
Procedure
In addition to ABAP developer authorizations for programming with the API, you must fulfill these prerequisites to use the Code Coverage API:
Code Coverage authorizations: A user who runs an instrumented program must have an authorization for authorization object S_COV_ADM with ACTVT
03. Otherwise the API raises an exception.
Activated Coverage Analyzer: The main switch of the Coverage Analyzer in transaction SCOV must be on.
In addition, the Coverage Analyzer ( SCOV) must be activated on the ABAP application servers on which the measurements are made.
The Coverage API checks that these conditions are met when you create a measurement. It raises an exception if the Coverage Analyzer is not correctly
activated.
Test group: Users in measurements:
May not be registered in a test group in the Coverage Analyzer ( SCOV)
May not be registered in another measurement that is currently running ( IF_SCV_MEASUREMENT->START method has been called).
The Coverage API raises an exception if these conditions are not fulfilled.
1.2 Differences Between the Coverage Analyzer and the
Coverage API
Definition
The Coverage Analyzer (transaction SCOV) and the Coverage API use the same ABAP technology for measuring code coverage. But there are important
differences between them. These are summarized here.
Integrated workplace versus Do-It-Yourself API: The Coverage Analyzer offers you a ready-to-use integrated workplace for measuring code coverage.
The Coverage API offers you the programming tools for collecting and optionally displaying code coverage yourself.
The next couple of points explain which tool to use for the purposes you have in mind.
Control over measurement: With the Coverage API, you can control measurement of code coverage more precisely than you can with the Coverage
Analyzer.
With the Coverage Analyzer, you switch on code coverage measurement for an entire application server or entire ABAP System. You let it run while users
in test groups perform their tests. The coverage measurement captures all activity by the test users.
This kind of blanket measurement of activity works fine if you have a dedicated test or consolidation system. You can for example let the Coverage Analyzer
run during a testing week. Because only test users use the system, the code coverage statistics provide an accurate view of test quality.
But this measurement model works less well if you want to do ad hoc checks of the code coverage of test programs or if you want to precisely limit
measurements to test activity.
For such purposes, the Coverage API is the better tool. You can instrument your test programs or your test infrastructure. You can limit measurements quite
precisely to the time when a test activity is actually running.
PUBLIC
Page 3 of 30
Reuse of test results: It is easier to extract code coverage statistics for reuse from the Coverage API than it is from the Coverage Analyzer.
If you want to reuse coverage statistics for sending e-mails to developers or for external reporting, then the Coverage API is the better tool to use.
1.3 Measuring Code Coverage in Overview
Definition
Here in overview is what you need to do to measure code coverage with the Coverage API.
We start with the steps required to use a standalone measurement, a measurement that is not part of a measurement series. After that, we review how to work with
a measurement series.
Overview: Using a Code Coverage Measurement
Create a measurement. Specify the users to measure if they are other than the current user. The SY-UNAME user is the default measurement user.
Start the measurement to record the activity of the specified users.
Perform the test activities whose code coverage you wish to record.
Models for interaction between the Coverage API and the code to be measured include the following:
You can use the API to instrument your test programs directly.
You can instrument the test infrastructure with which you are working. The infrastructure then turns code coverage measurement on and off as tests
are run. (The ABAP Unit test infrastructure already offers integrated coverage measurement.)
You can start a measurement in a test system and let it run, so that it measures any and all activities of the measurement users.
Stop the measurement to end data collection and calculate results. You can calculate code coverage results only after a measurement has been stopped.
Calculate results for as many different programs, packages, application components, or selections thereof as you wish.
Extract the code coverage results in text form for reuse in e-mail or in reporting on code coverage.
You can also use the built-in graphical display of the Coverage API to look at the results.
If you have the test key of the measurement, then you can also display the results in the Details Display of the Coverage Analyzer, transaction SCOV. (Enter
the test key as the Test group in the Details Display .)
If you wish to, you can save a measurement and its results to the repository of the Coverage API.
If you save the measurement in the started state, it remains running. All activity by the test users is recorded. You can then retrieve the measurement to
stop it and calculate results. You can use this technique to record multiple disparate tests.
If you save a measurement after it has been stopped condition, then you can retrieve it to calculate additional results, as long as the raw data still exists.
You retrieve standalone measurements and results with the ID that the repository returns when you save the entities. Measurement series offer more comfort
for retrieving measurements and results. We recommend measurement series if you plan to do systematic saving and retrieval for tracking coverage and
other purposes.
If necessary, you can merge a set of measurements.
Let us say that you have measurements for two discrete tests that actually belong together. By merging the measurements, you aggregate them into a single
new measurement. You can then obtain aggregated results from the merged measurement.
You can finalize the measurement, if you wish to delete the bulky raw data of the measurement.
The measurement itself and any results are not deleted. If you have saved them, then they disappear from the system only if you explicitly delete them.
(Since they consume little storage space, it is not really necessary to reorganize and delete them.)
After the raw data of a measurement has been deleted, you cannot calculate any more code coverage results. You also cannot merge a measurement with
another measurement (to aggregate their results).
The raw data of a measurement is deleted not only when you finalize the measurement but also when the raw data is reorganized automatically. Raw data is
reorganized by default after one week, but you can set other retention intervals, if you wish. The raw data is also deleted when the source code of a
procedure or processing block is changed either directly or through the arrival of imported code.
Overview: Using a Measurement Series
PUBLIC
Page 4 of 30
A measurement series is essentially a container for a chronologically ordered set of measurements. To set up a series, you do the following:
Create the series, giving it a name that is unique in the system. You retrieve the series for the next measurement and set of results using this unique name.
Set the default configuration and object selection for the series. The defaults are used automatically when you calculate code coverage results. The
measurement users and server selection are also saved as defaults.
The defaults help you to create identically customized measurements in the series, so that the measurements can meaningfully be compared to one
another. But you can override the defaults if you need to calculate differently customized results from measurements in the series. .
Save the series, which automatically saves the default configuration and object selection. After the first save, you need to load the series to use it.
Create a measurement in the series. The measurement life cycle in a series is approximately the same as that shown above for standalone measurements.
Measurement series are designed to work best with a single set of measurements, and not with several sets of measurements running in parallel in the
series. But you can calculate as many results from each measurement in the set as you wish.
Series are also designed to have only one started measurement at a time. You may of course have several series with active measurements all running at
the same time. The user restrictions and performance cautions shown above apply to active measurements in measurement series.
If you calculate more than one result per measurement, then it is wise to use a naming convention for the results. Then you can use the names to retrieve
particular series of results.
Save the measurement(s) and results. Just save your results to also save measurements and the series to which they belong.
Optionally, you can add a standalone measurement to a series by assigning the measurement to the series.
1.4 Coverage API: Quick Reference
Use
Here are some of the more important declarations and method calls of the Coverage API in short form as an overview.
Standalone Measurement
DATA: factory TYPE REF TO if_scv_factory,
measurement TYPE REF TO if_scv_measurement,
result TYPE REF TO if_scv_result,
coverage TYPE REF TO if_scv_coverage,
repository TYPE REF TO if_scv_repository,
display TYPE REF TO if_scv_result_display.
factory = cl_scv_coverage_api=>get_factory( ).
measurement = factory->create_measurement( ).
measurement->start.
measurement->stop.
result = measurement->build_<>_result( ).
coverage = result->get_coverage( ).
display = cl_scv_coverage_ui=>get_result_display( result ).
display->show_as_fullscreen( ).
display->show_as_popup( ).
repository = cl_scv_coverage_api=>get_repository( ).
repository->save_result( result ).
repository->save_measurement( measurement ).

Measurement Series
PUBLIC
Page 5 of 30
series TYPE REF TO if_scv_series,
measurements TYPE if_scv_measurement=>tab,
measurement_results TYPE if_scv_result=>tab.
series = factory->create_series( 'UNIQUE_NAME' ).
selection = series->get_selection( ).
configuration = series->get_result_configuration( ).
repository->save_series( series ).
series = repository->load_series( 'UNIQUE_NAME' ).
measurement = series->create_measurement( 'M_NAME' ).
measurements = repository->find_measurements_by_series( series ).
results = repository->find_results_by_measurement( measurement ).
results = repository->find_results_by_series(
i_series = series i_result_name = 'PACKAGE_SMOI' ).

Configuration and Selection Objects
DATA: configuration TYPE REF TO if_scv_result_configuration,
selection TYPE REF TO if_scv_selection.
* Standalone measurement
configuration = measurement->get_result_configuration( ).
configuration->stop_at( <> ).
configuration->remove_all_coverage_types( ).
configuration->add_coverage_type( <> ).

* In conjunction with a standalone measurement
selection = factory->create_selection( ).
selection->include_<>( <> ).
selection->exclude_<>( <> ).
<> = selection->get_<>_range( ).
result = measurement->build_selection_result( i_selection = selection ).

Exceptions
DATA: execution_error TYPE REF TO cx_scv_execution_error,
call_error TYPE REF TO cx_scv_call_error.
TRY.
CATCH cx_scv_execution_error INTO execution_error.
CATCH cx_scv_call_error INTO call_error.
ENDTRY.

1.5 Tutorial: Measuring Code Coverage with the Coverage API
Procedure
This tutorial shows you the main steps in measuring code coverage with the Coverage API. The sample program in the tutorial creates a standalone measurement
(not a measurement in a series), runs a test program, and then reports the code coverage results.
The scenario illustrates a good way to instrument a test program for a quick ad hoc measurement of code coverage.
For more systematic measurement of code coverage, see the tutorial on measurement series.
The tutorial measures code coverage synchronously in a single program context.- coverage instrumentation and test program inline in a single program. But of
course the Coverage API also lets you record asynchronous user activity. See for example: Saving and Reloading a Measurement.
The tutorial topics are the following:
Step 1: Creating a Measurement
Step 2: Measuring Code Coverage
Step 3: Calculating Code Coverage Results
Step 4: Traversing the Hierarchy of Results
Step 5: Displaying the Code Coverage Results
PUBLIC
Page 6 of 30
Step 6: Saving Code Coverage Results
Step 7: Finalizing a Measurement
Tutorial: Sample Program
Additional topics relating to measurements include these:
Measuring Code Coverage in Overview
Merging Code Coverage Measurements
Saving and Reloading a Measurement
Assigning Measurements to a Measurement Series
Handling Exceptions in the Code Coverage API
Recovering From a Blocked Measurement
1.5.1 Step 1: Creating a Measurement
Procedure
Create a standalone measurement with the factory that is provided by the class CL_SCV_COVERAGE_API. This class is the central entry point to the Coverage
API.
You might use standalone measurements for ad hoc checks of code coverage. For example, as a developer, you might produce such a measurement to verify
and document the code coverage of a test program.
Sample Code: Creating a Measurement
Here is code for creating a measurement. All of the parameters of the measurement factory are shown, all are optional.
users TYPE if_scv_measurement=>users.
APPEND 'AUNIT_USER' TO users. "Coverage will be recorded
APPEND 'ECATT_USER' TO users. "for these users.
measurement = factory->create_measurement(
i_name = 'myMeasurement'
i_local_server_only = abap_false "Record activity on all servers
i_users = users
i_testkey_expiration = cl_scv_expiration=>create( i_weeks = 2) ).
"Keep the raw data for two weeks - there are other parameters
"and methods available.

For simplicity, exception handling is not shown in these tutorial code examples.
Continue to start the measurement and record code coverage statistics.
See also the complete sample program.
Parameters in More Detail
When you create a new measurement, you can specify the following optional parameters:
i_name: A name for the measurement. The name is not unique and has a purely documentary role. Default: No name.
You can omit a name for standalone measurements that you do not save. If you save measurements, providing a name remains optional, but you can apply
standard names to measurements (and also to results) that are semantically related. For example, if you calculate a weekly result for package SMOI, you
can use the name i_name = 'Package SMOI' for each instance of the result.
i_local_server_only: Whether coverage should be measured on all servers of the system or only on the current server.
Default: Coverage is measured only on the current logon server.
i_users: A list of the users for whom coverage is measured.
Default: Coverage is measured only for the current user (system field sy-uname).
i_testkey_expiration: How long the raw data of the measurement should be kept before being automatically deleted. Express the retention interval as
an instance of class CL_SCV_EXPIRATION, as the sample above shows. See also Finalizing a Measurement.
Default: Raw data is deleted after one week. The measurement itself and any results that have been generated from the raw data are not deleted, if they
have been saved to the repository.
1.5.2 Step 2: Measuring Code Coverage
Procedure
After you have created a measurement, you do the following to collect code coverage data:
Start measurement of code coverage
Run the tests or activities that should be measured.
Stop the measurement of code coverage.
Stopping a measurement ends the measurement. You cannot add any more code coverage data to it. .
Sample Code: Measuring Code Coverage
Here is code for starting and stopping the measurement of code coverage.
PUBLIC
Page 7 of 30
DATA measurement TYPE REF TO if_scv_measurement.
measurement->start( ). " Start the measurement
" Run your tests. Here, a harmless CCMS standard report
submit rsdssmpl_status and return.
" Stop the measurement - no more data is recorded
measurement->stop( ).

This sample turns on measurement only for a short time and for a discrete activity (though any other activity by the measurement users is also recorded while the
measurement is running).
You can also start a measurement in a background job or in a test infrastructure to record multiple separate activities or to record activity for a period of time. See
Saving and Reloading a Measurement.
Note the following:
A measurement is client-specific. That is, it is visible only in the client in which you create it. However, a measurement collects activity data from other
clients, if the measurement user is also present under the same user name in other clients. Such data is aggregated without distinction in the measurement.
You can have as many measurements active in a system as you wish. The active measurements may be standalone measurements, or they may belong
to measurement series.
The users whose activity is being recorded may not overlap in measurements. You cannot start a measurement if:
A user specified in the measurement is already associated with another measurement; and
The other measurement is currently running.
The Coverage API is careful not to affect performance adversely. Even so, you should run as few measurements in parallel as possible.
You cannot restart a stopped measurement. Once a measurement has been stopped, you cannot add new data to it. (You can merge measurements to
aggregate their data).
You have now recorded raw data on code coverage. Continue to calculate code coverage results.
See also the complete sample program.
1.5.3 Step 3: Calculating Code Coverage Results
Procedure
Once you have collected raw data on code coverage, you can calculate coverage results.
Calculating a Result: Sample Code
Here is code for calculating the code coverage of a program and the package to which it belongs. In each case, the code returns the statement coverage.
DATA: measurement TYPE REF TO if_scv_measurement,
text TYPE string.
* Get the aggregate statement coverage for package SMOI
result = measurement->build_package_result( 'SMOI' ).
coverage = result->get_coverage( if_scv_coverage=>con_statement ).
text = |Package SMOI has a statement coverage of { coverage->get_percentage( ) }%|.
WRITE:/ text.
* Get the statement coverage of a specified program
result = measurement->build_program_result( 'RSDSSMPL_STATUS' ).
text = |Program RSDSSMPL_STATUS has a statement coverage of { coverage->get_percentage( ) }%|.
WRITE:/ text.
* Extra credit: This method gets all available coverage statistics
DATA: coverage_tab TYPE if_scv_coverage=>tab.
coverage_tab = result->get_coverages( ).

As the code shows, you first build a result for a specific entity - an application component, package, program, or selection of such entities. The result is calculated
according to the prevailing configuration. The ' BUILD' methods of IF_SCV_MEASUREMENT return objects of type IF_SCV_RESULT to you.
Then, you request code coverage statistics from the result. The IF_SCV_RESULT methods return objects of IF_SCV_COVERAGE to you. You then use methods of
IF_SCV_COVERAGE to get the actual statistics.
You can calculate as many different results from a single measurement as you wish - as long as the measurement has not been finalized. The FINALIZE method
discards the raw data. The Coverage API also discards raw data through a reorganization mechanism or when the code under measurement is changed.
You must stop a measurement- end the collection of raw data - before you can calculate results.
Note
Note that the BUILD_PROGRAM_RESULT method needs a technical program name for classes and function groups:
For classes, this is the name of the class pool, not CL_CCMS_AL_DATA_ENVIRONMENT but CL_CCMS_AL_DATA_ENVIRONMENT===CP.
For function groups, this is the name of the function pool, not SALI but SAPLSPALI.
PUBLIC
Page 8 of 30
To convert from the commonly visible names of these objects and their members to the technical names, you can use the function module
RS_TADIR_TO_PROGNAME. The function module takes as input the TADIR name of a repository object, as shown in the object entry or in a transport request.
Continue on to traversing the hierarchy of results, if the object for which you have calculated coverage has subcomponents.
Here is the complete sample program.
Calculating a Result: Additional Methods
In addition to IF_SCV_MEASUREMENT->BUILD_PACKAGE_RESULT and ->BUILD_PROGRAM_RESULT (shown above), there are two other methods for
calculating code coverage results:
BUILD_COMPONENT_RESULT- This method calculates the coverage for an application component such as BC-ABA or BC-CCM-MON.
By default, the method calculates coverages for all of the subcomponents, packages, programs, and processing blocks (methods) contained in the
application component.
BUILD_SELECTION_RESULT- With this method, you supply a selection object (parameter I_SELECTION) to specify the components, packages, and/or
programs for which coverage is to be calculated.
selection TYPE REF TO if_scv_selection.
" Define entities for which results are to be
" calculated with if_scv_selection methods
result = measurement->build_selection_result(
i_selection = selection ).

By default the method calculates results for any and all subcomponents of a selected entity. For example, BUILD_PACKAGE_RESULT returns by default not only
the aggregated coverage of a selected package, but also the coverage results for all subpackages, programs, and processing blocks in the package.
You can configure the results calculation - including the recursive calculation of results - for all of these methods with a configuration object (parameter
I_CONFIGURATION).
DATA: result TYPE REF TO if_scv_result,
configuration TYPE REF TO if_scv_result_configuration.
" Specify how the result is to be calculated with the
" methods of if_scv_result_configuration
result = measurement->build_component_result(
i_component_name = 'BC-ABA'
i_configuration = configuration ).

Code Coverage Metrics
You can calculate three code coverage measures. As the code example shows, you specify which statistics you wish to see with constants of
IF_SCV_COVERAGE. These constants are as follows:
IF_SCV_COVERAGE=>CON_BRANCH: The coverage of branches in control structures.
IF_SCV_COVERAGE=>CON_PROCEDURE: The coverage of procedures or processing blocks in ABAP code.
IF_SCV_COVERAGE=>CON_STATEMENT: The coverage of ABAP statements.
Note
The IF_SCV_COVERAGE constants shown above are effective only in NetWeaver 7.0 EHP2 up until Support Package level 5 or 6. In higher release
levels, the IF_SCV_COVERAGE constants are deleted and are replaced with these constants:
CE_SCV_COVERAGE_TYPE=>BRANCH
CE_SCV_COVERAGE_TYPE=>PROCEDURE
CE_SCV_COVERAGE_TYPE=>STATEMENT
If you have used the old constants, then you must change your code if you upgrade or port your code to such a higher release.
You can ask for both raw numeric values and calculated code coverage percentages. Here are the available methods:
IF_SCV_COVERAGE->GET_EXECUTED: Returns the number of executed branches, statements, or procedures in the specified entity or set of entities in a
selection object.
IF_SCV_COVERAGE->GET_NOT_EXECUTED: Returns the number of branches, statements, or procedures that were not executed during a measurement.
IF_SCV_COVERAGE->GET_PERCENTAGE: Returns the percentage of code coverage for branches, statements, or procedures in the specified entity or
selection object.
IF_SCV_COVERAGE->GET_TOTAL: Returns the total number of branches, statements, or procedures in the specified entity or set of entities.
1.5.4 Step 4: Traversing the Hierarchy of Results
Procedure
If you ask for the code coverage result of a high-level entity, then the Coverage API also automatically calculates the code coverages of all of the subentities of the
high-level entity.
Example: If you ask for the code coverage of the application component BC-ABA, then the Coverage API returns not only the aggregate code coverage of the
component, but also the code coverages of all of the subcomponents, packages, and programs in the component.
PUBLIC
Page 9 of 30
In this section we show you how to traverse this coverage result tree.
Note
If you wish to have the code coverage calculated only for the top-level object, you can prevent the recursive calculation. You can also configure the depth to
which the code coverage should be recursively calculated. See Configuring Results.
Sample Code
Here is how to traverse the hierarchy of entities in such a coverage result tree.
DATA: root_node TYPE REF TO if_scv_result_node,
subnodes TYPE if_scv_result_node=>tab,
subnode TYPE REF TO if_scv_result_node,
text TYPE string.
root_node = result->get_root_node( ).
subnodes = root_node->get_children( ).
LOOP AT subnodes INTO subnode.
" Report the statement coverage of child objects
coverage = subnode->get_coverage(
if_scv_coverage=>con_statement ).
text = |Object { subnode->name } statement coverage is { coverage->get_percentage( ) }%|.
WRITE: / text.
ENDLOOP.

This example returns the statement coverage of all of the children of the entity for which RESULT was calculated.
Example: If RESULT is calculated for a package, then this code snippet would report on the code coverage of the subpackages and programs that belong to the
package.
This code snippet produces ABAP list output suitable, for example, for downloading in a simple text file format. But the Coverage API also lets you display and
analyze code-coverage results in a more comfortable form online. Go on to Step 5: Displaying Results.
Note
The IF_SCV_COVERAGE constants shown above in the sample code are effective only in NetWeaver 7.0 EHP2 up until Support Package 5 or 6. In higher
releases, the IF_SCV_COVERAGE constants are deleted and are replaced with these constants:
1.5.5 Step 5: Displaying the Code Coverage Results
Procedure
Once you have created a measurement and collected code coverage data, you can view the coverage statistics in a graphical display. You fetch the display with
CL_SCV_COVERAGE_UI=>GET_RESULT_DISPLAY, which takes a result object as its argument.
Sample Code
Here is sample code for displaying the result from the sample program in full-screen mode. Display in a dialog box is also possible.
DATA: display TYPE REF TO if_scv_result_display,
result TYPE REF TO if_scv_result.
" Show code coverage in a graphical display
"Or: display->show_as_popup( )"

If you need to, you can also save the results of your code coverage measurement. Go on to Step 6: Saving Code Coverage Results.
Details
Results Hierarchy: By default, the Coverage API calculates coverages for all of the subcomponents of an entity that you specify. For example,
IF_SCV_MEASUREMENT->BUILD_PACKAGE_RESULT returns by default the aggregate coverage for the package, as well as the results for all of the
subpackages and programs in the package.
For this reason, the display generally shows a hierarchy of objects. The contents of the hierarchy are controlled by the configuration and selection that you specify.
If you calculated results for application components, then the top-level entities in the results are application components. If, on the other hand, you asked for
results for programs, then the top-level elements in the display are programs.
In the coverage result tree, classes are shown under their class pool names, function groups are shown under their function pool names:
The display shows class CL_CCMS_AL_DATA_ENVIRONMENT as CL_CCMS_AL_DATA_ENVIRONMENT===CP.
PUBLIC
Page 10 of 30
The display shows function group SALI as SAPLSALI.
Source code display: If the display includes processing blocks, then you can click a processing block to display the branch and statement coverage in the
source code. See The Details Display of the ABAP Coverage Analyzer for more information on the branch and statement display. The source code display is
available only as long as the raw data is available.
Coverage Analyzer Display: Are you a QM and do you want to let your developers display the results of a measurement? Relax. You don't have to build your
own display tool to do this. Instead, you can let your developers view measurement results in the Coverage Analyzer (transaction SCOV). Just give them the
measurement test key and tell them to enter it as the Test group in the Details Display of the Coverage Analyzer. They can then view a measurement just as
they could with the IF_SCV_RESULT_DISPLAY methods.
1.5.6 Step 6: Saving and Retrieving Code Coverage Results
Procedure
Do you need to save your code coverage results and measurements for future reference? You can do this with the services of the code coverage repository.
Here is code for saving a code coverage result and the measurement from which it was calculated.
You need only save results in order to save both results and the measurements from which they derive.
DATA: repository TYPE REF TO if_scv_repository,
result_id TYPE cva_uuid,
measurement_id TYPE cva_uuid,
result TYPE REF TO if_scv_result..
* The Repository of the Coverage API is
* responsible for all save and reload
* operations on measurements, results, and
* measurement series
* The Repository takes care that no inconsistencies in
* the data objects of the Coverage API can occur. For
* this reason, you need only save results in order to
* save the associated measurements and measurement series.
* Saves the result and measurement
result_id = repository->save_result( result ).
* You can separately save a measurement if necessary.
measurement_id = repository->save_measurement( measurement ).
* Retrieve the measurement
CLEAR measurement.
measurement = repository->load_measurement( i_id = measurement_id ).
* Retrieve the result
CLEAR result.
result = repository->load_result( i_id = result_id ).

The save functions return an ID with which you can retrieve a result or a measurement. .
To retrieve a standalone measurement, you need either:
The ID that the repository returns when you save the measurement (method IF_SCV_REPOSITORY->LOAD_MEASUREMENT)
The test key of the measurement (methods IF_SCV_REPOSITORY->LOAD_MEASUREMENT and IF_SCV_REPOSITORY-
>FIND_MEASUREMENT_ID_BY_TESTKEY). You can obtain the test key with IF_SCV_MEASUREMENT->GET_TEST_KEY.
From a result object, you can also navigate to the associated measurement with IF_SCV_RESULT->GET_MEASUREMENT.
Finally, you can retrieve all measurements saved in the repository with the generic method IF_SCV_REPOSITORY->FIND_MEASUREMENTS. The
measurements contain metadata such as time stamps, with which you could select among the set of 'found' measurements.
To retrieve a result that was generated from a standalone measurement, you need either:
The ID that the repository returns when you save the result (method IF_SCV_REPOSITORY->LOAD_RESULT)
The measurement object from which the result was generated (method IF_SCV_REPOSITORY->FIND_RESULTS_BY_MEASUREMENT).
You must save test keys or measurement and result IDs yourself, if you want to retrieve stored standalone measurements and results from the repository without
using the generic FIND_MEASUREMENTS method.
Recommendation
Measurement series offer more convenient ways of accessing saved measurements and results for trend analysis and tracking.
Switch to measurement series - rather than standalone measurements - if you plan to do extensive trend analysis and tracking of code coverage.
If you do not need to calculate any more coverage results, then you can go on to finalize the measurement.
1.5.7 Step 7: Finalizing a Measurement
PUBLIC
Page 11 of 30
Procedure
The Coverage API stores raw data for calculating code coverage in the database. It is a good idea to delete this data once you have calculated the coverage
statistics that you need. If you do not explicitly delete the raw data, then it is deleted automatically at the end of the retention interval.
Use method IF_SCV_MEASUREMENT->FINALIZE to delete the raw data of a measurement.
DATA measurement TYPE REF TO if_scv_measurement.
* Discard the raw data of the measurement
measurement->finalize( ).

Once you have finalized data, you can no longer calculate new code coverage results. Example: You want to add branch coverage to the results that you have
calculated for a program. You can add this metric only as long as you still have the raw data.
After you finalize, you also cannot merge measurements to aggregate them. Merging measurements requires the raw data of the measurements.
This section finishes the tutorial for measuring code coverage with the Coverage API. You can continue to Tutorial: Working with a Measurement Series.
Here is the complete tutorial program.
1.5.8 Measurement Tutorial: Sample Program
Definition
This sample program includes the calls to the Coverage API that are explained in the individual tutorial sections.
The program creates a measurement of code coverage. By running the program, you do the following:
Create a measurement in the Coverage API
Run a test program and measure its code coverage
Calculate the code coverage of the package to which the test program belongs
Display the code coverage results in graphical and in text form
Save the results and discard the raw data from which the result was calculated.
The program shows how you could instrument your test programs for quick, ad hoc checks of their code coverage.
As an alternative to inline instrumentation, you can measure activities by test users you specify over a period of time or during their use of a testing infrastructure.
*&---------------------------------------------------------------------*
*& Report Z_COVERAGE_API_EXAMPLE
*&
*&---------------------------------------------------------------------*
*&
*&
*&---------------------------------------------------------------------*
REPORT z_coverage_api_example.
* Measure the code coverage of a test program inline in a single
* session. The program makes no permanent changes to your system
* and so may be run in a customer system.
* The measurement
users TYPE if_scv_measurement=>users,
testkey TYPE cva_testk.
* The results
text TYPE string.
* The results for entities in package
DATA: root_node TYPE REF TO if_scv_result_node,
subnodes TYPE if_scv_result_node=>tab,
subnode TYPE REF TO if_scv_result_node.
* The display
DATA: display TYPE REF TO if_scv_result_display.
* Optionally saving the measurement and results
result_id TYPE cva_uuid.
* Exceptions
* Create a measurement and specify user to measure
* Code coverage will be measured only on the local ABAP server
PUBLIC
Page 12 of 30
TRY.
* Default is actually sy-uname if no user is specified
APPEND 'AUNIT_USER' TO users.
i_name = 'myMeasurement'
i_local_server_only = abap_true
i_users = users ).
* Start the measurement and execute the test programs whose
* code coverage is to be measured.
measurement->start( ).
* Execute anything you want to measure
SUBMIT rsdssmpl_status AND RETURN. "Harmless standard CCMS report
* Stop the measurement - no further code coverage data may be added
* Obtain the test key - Optional - just to show that it can be done
testkey = measurement->get_testkey( ).
* Calculate the code coverage in package SMOI - processing block,
* branch, and statement coverage are all calculated by default.
* The coverages of all subcomponents of SMOI are also calculated
* Display the results in a graphical pop-up - show_as_fullscreen also available
* For download to a mail, for example, add the results in list form
* Write the statement coverage of package SMOI
text = |Package SMOI has a statement coverage of
{ coverage->get_percentage( ) }%|.
WRITE:/ text.
* Add the statement coverage of the program objects in package SMOI
root_node = result->get_root_node( ).
subnodes = root_node->get_children( ).
LOOP AT subnodes INTO subnode.
coverage = subnode->get_coverage( if_scv_coverage=>con_statement ).
text = |Object { subnode->name } has a statement coverage of
{ coverage->get_percentage( ) }%|.
WRITE: / text.
ENDLOOP.
* Optionally: Save the results for future re-use
* You need to save the ID to retrieve the results -
* see also the measurement series tutorial.
* The measurement is implicitly saved as well.
result_id = repository->save_result( result ).
* Finalize the measurement to discard the raw data
* The measurement and results are not deleted
measurement->finalize( ).
* Exception handling
text = |Execution error occurred. Message: { execution_error->get_text( ) }|.
WRITE: / text.
text = |Call error occurred. Message: { execution_error->get_text( ) }|.
WRITE: / text.
ENDTRY.

Note
The IF_SCV_COVERAGE constants shown above in the sample code are effective only in NetWeaver 7.0 EHP2 until Support Package 5 or 6. In higher
releases, the IF_SCV_COVERAGE constants are deleted and are replaced with these constants:
PUBLIC
Page 13 of 30
1.6 Tutorial: Working with a Measurement Series
Procedure
As a rule, code coverage measurements are done repetitively. For example, your development group may measure code coverage weekly to guide test
development and execution. Such series of measurements usually repeat the same configuration and measure the same entities.
The Coverage API supports regular code coverage measurement with the measurement series. A measurement series simplifies the task of performing regular
measurements by allowing you to do the following:
Define default configurations for calculating coverage results
Define default sets of entities for which coverage is to be calculated
Easily execute measurements and calculate coverage results using the defaults
Manage measurements and results as chronologically ordered sets in a series.
The following tutorial sections show you how to create and use a measurement series.
Step 1: Creating or Loading a Measurement Series
Step 2: Setting Defaults for a Measurement Series
Step 3: Creating and Running a Measurement in a Measurement Series
Step 4: Calculating Coverage Results in a Measurement Series
Step 5: Saving Measurements and Results in a Measurement Series
Step 6: Finding Measurements and Results in a Measurement Series
Measurement Series Tutorial: Sample Program
Special topics relating to measurement series include these:
Naming Measurements and Results
1.6.1 Step 1: Creating or Loading a Measurement Series
Procedure
You create a measurement series with the Coverage API factory. You must specify a name for the series that is unique in the ABAP system. It is best to save a
series right after you create it; the Coverage API checks the uniqueness of the name only when the series is saved.
Normally, you would set the defaults for the series before saving. For simplicity, this step is shown separately.
series TYPE REF TO if_scv_series.
series = factory->create_series( 'MY_UNIQUE_SERIES' ).
" Set defaults before saving
repository->save_series( series ). " Uniqueness of series name is checked.

If you have already created a series, then you load it to use it. A combined operation might look like this:
DATA: ex type ref to cx_scv_execution_error.
TRY.
CATCH cx_scv_execution_error.
TRY.
series = repository->load_series( 'MY_UNIQUE_SERIES' ).
CATCH cx_scv_execution_error into ex.
<error message>
ENDTRY.
ENDTRY.

The next step (which should actually be integrated in this step) is to set defaults for the series.
1.6.2 Step 2: Setting Defaults for a Measurement Series
Procedure
To make measurement series more convenient, you can store default settings with the series. You can store both the configuration for calculating results and the
PUBLIC
Page 14 of 30
selection of entities for which coverage results should be calculated. The default settings are automatically used when you calculate results from measurements of
the series.
Make default settings before you save a series the first time. You cannot change the default configuration and the default object selection once you have saved a
series.
Here is some sample code to show how to make default settings.
series TYPE REF TO if_scv_series,
selection TYPE REF TO if_scv_selection,
* Set the scope of measurement directly in the series
* Here, activity on all instances of the system will be measured
series->set_local_server_only( abap_false ).
* Also, set the default users directly in the series.
* The user set is saved with the series as the default for
* measurements.
APPEND 'USER01' TO users.
series->set_users( users ).
* Get and set the default object selection
* By default, coverage of MY_PACKAGE will be calculated
selection->include_package( 'MY_PACKAGE' ).
* Get and set the results configuration.
* Here, only a single aggregated coverage will be
* calculated. For example, Coverage will be
* calculated for MY_PACKAGE, but not for any
* sub-components of MY_PACKAGE. No coverage tree is generated.
configuration->set_ignore_hierarchy( abap_true ).
* Save the default configuration and selection
repository->save_series( series ).

As you can see in the sample code, you set the test users and the scope of the measurement (local server or all servers) in the series itself. Both the test
users and the scope are saved as part of the default settings of the series. They are used automatically by any measurements that you create in the series.
Note that you can change the default test users and the scope of the measurement on the fly if you need to. Example: You can use IF_SCV_SERIES-
>SET_USERS to add an additional test user or change the test user before creating a new measurement in a series. The measurement uses the new test-users
setting.
Any changes to the test users or scope are saved with the series if you save a measurement of the series. This action performs an implicit save of the series as
well as saving the measurement.
The next step is to measure code coverage.
For more information about result configurations and object selections, see Default Settings.
1.6.3 Step 3: Creating and Running a Measurement in a
Measurement Series
Procedure
To measure code coverage in a measurement series, you simply create measurements in the series. The series orders the measurements (and the results)
chronologically in the series.
Here is a code snippet showing how to create and run a measurement in a series.

* Set the retention interval for raw data if the default 1 week is not okay
series->set_testkey_expiration( cl_scv_expiration=>create( i_weeks = 2 ) ).
* Create the next measurement in the series
* Measurements that belong to the same set in the series
* can all use the same name (see below)
measurement = series->create_measurement( 'MY_STANDARD_MEASUREMENT' ).
* Start the measurement
* Execute test activities, here a harmless CCMS standard report
SUBMIT rsdssmpl_performance AND RETURN.
PUBLIC
Page 15 of 30

The life cycle of a measurement in a series is like that of a discrete, standalone measurement. That is, you create the measurement, start it to record activity, and
so on.
There are differences:
You create the measurement in the series, not directly from the Coverage API factory.
The series applies its default configuration and selection to the measurement, unless you supply your own configuration and/or selection objects.
For more information about result configurations and object selections, see Default Settings.
It is not sensible to have more than one measurement running at a time in a series. Otherwise, the complications defeat the purpose of measurement series,
which is to make it easy to create sets of identical, repetitive measurements.
You can have multiple measurement series active at the same time, as long as the users do not overlap while the measurements are active.
Note
Do you have a standalone measurement that you would like to add to a series? No problem, you can assign the measurement to a series.
Continue to calculate code coverage results.
1.6.4 Step 4: Calculating Coverage Results in a Measurement
Series
Procedure
The default configuration and object set saved with a measurement series make it easy to calculate code coverages. The series defaults are passed automatically
to each measurement. That means that you can simply use the BUILD_SELECTION_RESULT method to get the default results.
Here is sample code for generating the series-default code coverage statistics.
* The measurement must be stopped before
* you can calculate results. Here, you
* calculate the default results saved with
* the series.
result = measurement->build_selection_result( ).
result->set_name( "STANDARD_RESULT" ).
" Series default selection is used
* Request an additional result and
* name it for later retrieval.
DATA package_result TYPE REF TO if_scv_result.
package_result = measurement->build_package_result( 'SMOI' ).
package_result->set_name( "PACKAGE_SMOI" ).

The sample code first uses the BUILD_SELECTION_RESULT method, which automatically uses the default configuration and object selection saved with the
series. Then BUILD_PACKAGE_RESULT generates a second result. This measurement uses the default configuration as well. Both are named for ease in
retrieval.
You can calculate as many different additional results as you wish. You can either use the named-entity methods, like BUILD_PACKAGE_RESULT. Or define
additional configuration and/or selection objects and specify them when you calculate the additional results. The default configuration and selection remain
unchanged.
Note
If you wish to work with multiple sets of results, see Naming Measurements and Results.
Continue to Step 5: Saving Measurements and Results in a Measurement Series.
1.6.5 Step 5: Saving Measurements and Results in a
Measurement Series
Procedure
Save results and measurements so that you can use them for tracking and trend analysis in code coverage. You must explicitly save these objects to persist
them as part of a measurement series. They are not automatically saved.
The API ensures that no inconsistencies can occur when you save. In practice, this means that you need only save result objects in order to also save an
associated measurement and measurement series.
The code required to save these objects is shown below. Use it after running a measurement and generating results from it:
* Save your results in order to store them, the associated
* measurements, and the series for future reference
PUBLIC
Page 16 of 30
measurement TYPE REF TO if_scv_measurement.
repository->save_result( result ).
* You can also save a measurement or series separately,
* if necessary. Saving a measurement does not save any
* associated results.
repository->save_measurement( measurement ).

For ease in reloading series, measurements, and results, be sure to name them.
Here is what each object offers in persisted data:
Measurement Series: Management information, such as the last save of the series and the user who did the save.
Measurement: The state of the measurement (initial, started, stopped), the users whose activity is being recorded, start and stop timestamps, and other
metainformation on the measurement.
Save a measurement in state STARTED if you want it to run to record asynchronous activity - across user contexts, over a period of time.
Results: The actual code coverage statistics for the entities that you selected, calculated according to the active configuration.
Continue to Step 6: Finding Measurements and Results in a Measurement Series.
Click here to see the complete sample code.
1.6.6 Step 6: Finding Measurements and Results in a
Measurement Series
Procedure
In the last tutorial step, we saved measurement series, measurements, and results in the repository of the Coverage API.
In this section, we look at the repository methods for retrieving these objects from the repository. Here, the focus is on retrieving results for purposes of reporting or
trend analysis.
Here is some sample code for finding measurements and results.
" Start by loading a series by name
DATA: series TYPE REF TO if_scv_series,
repository TYPE REF TO if_scv_repository.
series = repository->load_series( 'MY_UNIQUE_SERIES' ).
" Find the measurements in a series
DATA: measurements TYPE if_scv_measurement=>tab,
measurement_results TYPE if_scv_result=>tab.
" Get all measurements saved in a series
measurements = repository->find_measurements_by_series( series ).
" Get the results from one measurement
read measurements into measurement index 1.
measurement_results =
repository->find_results_by_measurement( measurement ).
" Get a set of results by name from a series
DATA series_results TYPE if_scv_result=>tab.
" Get all instances of the result with the name 'PACKAGE_SMOI'
series_results = repository->find_results_by_series(
i_series = series i_result_name = 'PACKAGE_SMOI' ).

The repository FIND methods are flexible. You can retrieve:
measurements that belong to a series
results that belong to a series
results that belong to a measurement
You can also retrieve series and results by name.
The FIND methods return measurements and results in chronological order, newest last (highest row number in the internal table). .
Here are the repository FIND methods:
IF_SCV_REPOSITORY->FIND_MEASUREMENTS: Returns all measurements in the repository. You can then select among them by measurement name or
other attribute.
IF_SCV_REPOSITORY->FIND_MEASUREMENT_ID_BY_TESTKEY: Finds the identifier of a measurement by way of the test key of the measurement.
With IF_SCV_REPOSITORY->LOAD_MEASUREMENT you can then load the measurement using the ID.
IF_SCV_REPOSITORY->FIND_RESULTS_BY_MEASUREMENT: Returns the results of a measurement. You can specify the name of the set of results that
you wish to have.
IF_SCV_REPOSITORY->FIND_SERIES: Returns all measurement series.
IF_SCV_REPOSITORY->FIND_MEASUREMENTS_BY_SERIES: Returns the measurements of a measurement series. You can specify the status of the
PUBLIC
Page 17 of 30
measurements that you wish to see.
IF_SCV_REPOSITORY->FIND_RUNNING_MEASUREMENT: Returns the active measurement of a measurement series.
IF_SCV_REPOSITORY->FIND_RESULTS_BY_SERIES: Returns the results of a measurement series. You can specify the name of the set of results that
you wish to have.
Once you have found results, you can extract the coverage statistics from individual results for use in e-mails or reporting. You can also display a result with the
built-in graphical display of the Coverage API.
The Coverage API does not offer any display facilities for working with sets of results. For trend analysis or more sophisticated reporting, you can use SAP
Graphics or download coverage statistics to a spreadsheet program.
This section ends the tutorial about working with measurement series.
1.6.7 Measurement Series Tutorial: Sample Program
Procedure
Here is the complete program that is described in the measurement series tutorial.
The program performs the following tasks. It:
Creates a measurement series. If the series name already exists, then the program loads the existing series.
Creates default selection and configuration settings for the series. The resulting objects are used only when a series is created. The default settings cannot
be changed after the initial save of the series.
Executes a code coverage measurement and calculates a result. The result uses the default calculation configuration and entity selection that were saved
with the series. The program also calculates a second result for a specified package.
Saves the and result and implicitly the measurement and series.
Displays the current results in the graphical browser of the Coverage API. The coverage statistics could also be extracted as text for reuse.
REPORT z_coverage_api_series_example.
* The Series
* Default configuration
* Measurements and results
default_result TYPE REF TO if_scv_result,
package_result TYPE REF TO if_scv_result.
* Display
DATA: display TYPE REF TO if_scv_result_display.
* Exceptions
DATA: ops_ex TYPE REF TO cx_scv_execution_error,
call_ex TYPE REF TO cx_scv_call_error.
TRY.
* Create measurement series
series = factory->create_series( 'TEST_SERIES_NW_EHP3' ).
* Set defaults for the series - first the scope of recording
series->set_local_server_only( abap_false ).
* Set the default users
append 'KELLERH' to users.
series->set_users( users ).
* Then the selection of entities for which results are calculated
* (not changeable after initial save)
selection->include_component( 'BC-CCM-MON' ).
" Exclude a sub-component of BC-CCM-MON
selection->exclude_component( 'BC-CCM-MON-SHM' ).
" Include explicitly two packages
selection->include_package( 'SCSM' ).
selection->include_package( 'SMOI' ).
" Exclude a class pool and function group - the full
" technical names of these entities must be used.
selection->exclude_program( 'CL_CCMS_AL_DOC_VIEW_AL_FILTER=CP' ).
selection->exclude_program( 'SAPLSALF' ).
* Then the configuration of the results calculation
* (read-only after initial save)
" Calculate only top-level aggregated results
PUBLIC
Page 18 of 30
configuration->set_ignore_hierarchy( abap_true ).
* Try to save the series
CATCH cx_scv_execution_error.
TRY.
* Load the series if it already has been created
series = repository->load_series( 'TEST_SERIES_NW_EHP3' ).
CATCH cx_scv_execution_error INTO ops_ex.
ENDTRY.
ENDTRY.
* Create a measurement in the series - the name can be the
* same for all instances of measurement
TRY.
measurement = series->create_measurement( 'MONITORING_API' ).
* Run test programs - here a harmless CCMS standard program
SUBMIT rsdssmpl_status AND RETURN.
* Calculate the results using the defaults of the measurement series
* Series default selection and configuration are used
default_result = measurement->build_selection_result(
i_result_name = 'MONITORING_COVERAGE' ).
* Calculate the results for a separate package
package_result = measurement->build_package_result( 'SCSM' ).
* Save the results and implicitly the measurement and series
repository->save_result( default_result ).
repository->save_result( package_result ).
* Display the results in a graphical pop-up - show_as_fullscreen also available
* The display
display = cl_scv_coverage_ui=>get_result_display( default_result ).
display = cl_scv_coverage_ui=>get_result_display( package_result ).
CATCH cx_scv_execution_error INTO ops_ex.
CATCH cx_scv_call_error INTO call_ex.
ENDTRY.

1.7 Default Settings: Result Configurations and Object Selections
Use
The customizing objects of the Coverage API - object selections and result configurations - let you control how the Coverage API calculates code coverage results:
A selection object (an object of type IF_SCV_SELECTION) lets you specify the group of entities - application components, packages, and programs - for
which results are calculated from the raw data. A selection object works with the method IF_SCV_MEASUREMENT->BUILD_SELECTION_RESULT.
A configuration object (an object of type IF_SCV_RESULT_CONFIGURATION) lets you control what results are returned when the Coverage API calculates
code coverage.
You can, for example, tell the API which set of the three values - procedure coverage, branch coverage, and statement coverage- you would like to have
returned with coverage results.
You can set result configurations and object selections dynamically when you work with the IF_SCV_MEASUREMENT->BUILD...RESULT methods.
But result configurations and object selections are even more useful when you work with a measurement series. You can save the configuration and selection
objects with the series as the default settings of the series. The series automatically provides the configuration and selection to IF_SCV_MEASUREMENT-
>BUILD_SELECTION_RESULT method calls that you make in the context of the series.
Here is more information:
Configuring Results
Using Object Selections
1.7.1 Using Selection Objects
Use
A selection object lets you specify a set of application components, packages, and programs for which you want to have coverage results calculated. Use a
selection object with method IF_SCV_MEASUREMENT->BUILD_SELECTION_RESULT.
The advantage of using selection objects is that you can tailor the set of entities for which you want code coverage results calculated. For example, you can get
PUBLIC
Page 19 of 30
results for an entire application component, yet still exclude packages that you do not want to see in the results.
Working with an Object Selection - Standalone Measurement
Here is how to use an object selection with a standalone measurement. This code snippet uses the INCLUDE and EXCLUDE methods of IF_SCV_SELECTION to
customize the results calculated for a component.
You start by instantiating a selection object. You put the selection into effect by providing it as an argument to the IF_SCV_MEASUREMENT-
>BUILD_SELECTION_RESULT method.
* Customize the results with an object selection
* An object must be created, as it is not initially present.
selection = factory->create_selection( ).
* Include my main component
selection->include_component( 'BC-CCM-MON' ).
* But exclude this component - doesn't belong to me
selection->exclude_component( 'BC-CCM-MON-SHM' ).
* And exclude this package as well
selection->exclude_package( 'SCSM' ).
* And exclude this program too
selection->exclude_program( 'S_TEST_FRAMEWORK' ).
* Do some measuring of code coverage...
* Calculate the results for the selected objects
result = measurement->build_selection_result( i_selection = selection ).
* Display the results in a graphical pop-up -
* show_as_fullscreen also available

Working with an Object Selection - Measurement Series
You can save a selection as the default of a measurement series. When you first set up a measurement series, do the following before you save the series for the
first time:
Obtain the selection object from the series with IF_SCV_SERIES->GET_SELECTION.
Set up the default object selection for the series.
When you save the series, the selection is saved with it. The series passes the saved selection automatically to IF_SCV_MEASUREMENT-
>BUILD_SELECTION_RESULT in the context of the series.
In effect, you can streamline and standardize the calculation of results in the series. One method call returns the standard set of results.
You can still calculate additional results in a message series. You can either call the BUILD methods that specify the entities for which results are to be
calculated. Or you can substitute a different selection object for the series default object.
For details, see Step 2: Setting Defaults for a Measurement Series and Step 4: Calculating Coverage Results in a Measurement Series in the measurement
series tutorial.
Object Selection Methods
Here are the methods you can use to tailor an object selection.
Note
An empty selection or a selection that specifies only exclusions are not supported. These selections cause an exception of type CX_SCV_CALL_ERROR in
IF_SCV_MEASUREMENT->BUILD_SELECTION_RESULT.
Use these methods to include or exclude a single component, package, or program in a selection object.
Method of IF_SCV_SELECTION Use
exclude_component Exclude an application component in the component hierarchy from the code coverage
results.
Example: If you request coverage results for objects in component BC-CCM-MON, you
can use exclude_component( i_name = 'BC-CCMS-MON-SHM' ) to exclude the
SHM subcomponent of BC-CCM-MON from the results. Objects that belong to BC-CCM-
MON-SHM are also excluded from the results.
exclude_package Exclude an ABAP package and its objects from the code coverage results.
Example: If you request coverage results for objects in component BC-CCM-MON, you
can use exclude_package( i_name = 'SMOI' ) to exclude that package and its
objects from the results.
exclude_program Exclude an ABAP program by name from the code coverage results.
For class pools and function groups and modules, the API needs the full technical name.
For a class, this is the class pool name, not CL_CCMS_AL_DATA_ENVIRONMENT, but
PUBLIC
Page 20 of 30
Use these methods to include or exclude ranges of objects in a selection object.
1.7.2 Configuring Results
Procedure
A configuration object lets you control how the Coverage API calculates code coverage results. With a configuration object, you can customize the following:
The depth and content of the hierarchy of results that the Coverage API calculates.
Example: By default, the Coverage API calculates results for all of the subpackages and programs in a package that you specify.
With a configuration object, you can ask for only the package aggregate code coverage. Or you can have the result hierarchy stop at a specified level.
The coverage statistics that are included in the results. Example: If you want, you can have only branch coverage statistics returned in a result.
Whether global and local classes in class pools and other types of programs are shown as a separate level in the hierarchy between programs and
processing blocks.
You can supply a configuration object to any of the IF_SCV_MEASUREMENT->BUILD...RESULT methods.
You can also save a configuration object as the default configuration of a measurement series. It is then used as the default configuration in all BUILD...RESULT
method calls.
If you do not provide a configuration, then the results hierarchy has these default characteristics:
It includes the full hierarchy of subcomponents that are contained in the entities for which you requested results.
All types of code coverage statistics are calculated: branch, statement, and processing block.
Global and local classes in class pools and other programs are shown in their own hierarchy level between programs and processing blocks.
Working with a Configuration Object: Standalone Measurement
Here is sample code for getting a configuration object from a measurement and customizing the way a result is calculated.
configuration TYPE REF TO if_scv_result_configuration,
* Get the configuration object
configuration = measurement->get_result_configuration( ).
* Truncate the results hierarchy at the program level
configuration->stop_at( ce_scv_node_type=>program ).
* Return only the branch coverage in results
configuration->remove_all_coverage_types( ).
* Constants before NW 7.0 EHP2 SP5 or 6
configuration->add_coverage_type( IF_SCV_COVERAGE=>CON_BRANCH ).
* Constants after NW 7.0 EHP2 SP5 or 6
configuration->add_coverage( CE_SCV_COVERAGE_TYPE=>BRANCH ).
* Get the result - the new configuration is used
result = measurement->build_component_result( 'BC-CCM-MON' ).
* Show the configured result
CL_CCMS_AL_DATA_ENVIRONMENT===CP. For a function group, this is the function
pool name, not SALK but SAPLSALK.
You can use the RS_TADIR_TO_PROGNAME function module to translate an object entry
( Goto Object Directory Entry ) to a technical program name. For example,
object type FUGR and object name SALK yields the function pool name SAPLSALK.
include_component
include_package
include_program
Include a component, package, or program and any subcomponents in the code coverage
results. For details, see the EXCLUDE-methods above.
Method of IF_SCV_SELECTION Use
get_component_range
get_package_range
get_program_range
These methods return the specifications in the selection object for each of these
categories of entities. For example, you might see that a component is to be included and
a set of packages is to be excluded.
get_root_components
get_root_packages
These methods evaluate the relationships in the selection specifications and return root
component and package specifications.
Example: If you have specified that a selection object should include components BC-
CCM-MON and BC-CCM-MON-SHM, then the get_component_range method returns
both component specifications, get_root_components returns only the specification
for BC-CCM-MON.
set_component_range
set_package_range
set_program_range
With these methods, you can write a set of object selection specifications to a selection
object.
The methods take as a parameter a ranges table, with which you can flexibly define sets
of entities.
PUBLIC
Page 21 of 30

Working with a Configuration Object: Measurement Series
In a measurement series, you can save an initial configuration object as the default configuration of the series. The series uses the configuration by default in all
results calculations. Here is sample code: Step 2: Setting Defaults for a Measurement Series.
You can override the default by providing an additional configuration object as an argument to a BUILD...RESULT method call.
IF_SCV_RESULT_CONFIGURATION Methods
Here are the configuration methods in overview. The first table shows the methods for tailoring the results hierarchy that is calculated.
Here are the methods for setting the code coverage statistics that are calculated.
You can restore a configuration to the Coverage API default by calling method RESET_TO_DEFAULT.
1.8 Coverage API: Additional Topics
Use
Here are some special topics relating to measurements and measurement series:
Saving and Reloading a Measurement
Merging Code Coverage Measurements
Recovering From a Blocked Measurement
Naming Measurements and Results
Database Persistence in the Coverage API and Loss of Test Data
1.8.1 Saving and Reloading a Measurement
Procedure
Imagine that you have a set of tests for which you want to measure coverage. Some of them take longer than a typical unit test (perhaps an ECATT integration
test). Others must be started with a different user, and some might even need to be executed manually.
A typical solution for this scenario is to schedule two batch jobs for example weekly. The first job runs every Monday to start and persist a measurement. The
second job runs every Friday to retrieve and stop the measurement. After the measurement has been stopped, you can calculate the coverage results.
Between the start and stop of the measurement, the Coverage API records all automatic or manual tests by the users specified in the measurement.
The Coverage API works in this scenario almost like the Coverage Analyzer (transaction SCOV), in that all activity by the specified users is recorded, not just the
IF_SCV_RESULT_CONFIGURATION Method Use
STOP_AT Truncates the results hierarchy after the level that you specify. Level constants are these:
CE_SCV_NODE_TYPE=>BLOCK: Processing block
CE_SCV_NODE_TYPE=>CLASS: Class (presented as extra level below program)
CE_SCV_NODE_TYPE=>PROGRAM: Program
CE_SCV_NODE_TYPE=>PACKAGE: Package
CE_SCV_NODE_TYPE=>COMPONENT: Application component, as shown in the Package
Builder
CE_SCV_NODE_TYPE=>SELECTION: The tree is truncated at the respective entities
specified with a selection object.
DONT_STOP The results hierarchy is calculated to its full depth.
SET_IGNORE_HIERARCHY Do not calculate a results hierarchy. Return only an aggregated result for each requested
entity.
SET_SKIP_CLASS_LEVEL Do not display a separate hierarchy level for global and local classes between the
Program and Processing Block levels. For each program, there is only an aggregated
result. The next and final hierarchy level is then Processing Blocks.
IF_SCV_RESULT_CONFIGURATION Method Use
REMOVE_ALL_COVERAGE_TYPES Configures a result to return none of the three types of code coverage statistics.
ADD_ALL_COVERAGE_TYPES Configures a result to return all of the three types of code coverage statistics.
ADD_COVERAGE_TYPE Configure a result to return one of the three code coverage statistics.
In NW 7.0 EHP2 up to SP5 or 6, the constants are
IF_SCV_COVERAGE=>CON_STATEMENT
IF_SCV_COVERAGE=>CON_BRANCH
I F_SCV_COVERAGE=>CON_PROCEDURE
As of NW 7.0 EHP2 SP5 or 6, the constants are:
REMOVE_COVERAGE_TYPE Configure a result not to return a specified type of coverage statistic. The constants are as
shown above for method ADD_COVERAGE_TYPE.
PUBLIC
Page 22 of 30
relevant tests.
Note
Be sure in this scenario not to import or otherwise change the code under measurement while the measurement is running.
If measured code is changed, then the system automatically deletes the raw data of affected programs. This is necessary: The raw data no longer corresponds
to the source code.
Any results that you calculate in this situation are unreliable and not reproducible.
Sample Code
Here is sample code for saving a measurement and then later retrieving and stopping the measurement.
REPORT START_MEASUREMENT_AND_SAVE.
* This report starts a measurement and saves it.
* A second report, perhaps started interactively,
* stops the measurement and calculates coverage
* results.
id_records TYPE my_measurements.
* Create a measurement
APPEND 'AUNIT_USER' TO users. "Coverage will be recorded
APPEND 'ECATT_USER' TO users. "for these users.
i_users = users ).
* Start the measurement
* Save the measurement and store the measurement ID
* for use when stopping the measurement.
measurement_id = repository->save_measurement( measurement ).

* You need to save the UUID for reloading the measurement
id_records-id = measurement_id.
id_records-date = sy-datum.
INSERT INTO z_table_of_measurements VALUES id_records.

While the measurement is running (status started), the Coverage API records all of the tests and other activity of users AUNIT_USER and ECATT_USER (in this
example).
To end the measurement and calculate and report results, you could run a second program that might look like this sample code.
REPORT STOP_MEASUREMENT_AND_REPORT.
id_records TYPE my_measurements.
* Get the UUID of the active measurement
SELECT SINGLE * FROM my_table_of_measurements INTO id_records WHERE...
measurement_id = id_records-id.
* Get the repository
* Retrieve the measurement and stop it
measurement = repository->load_measurement( measurement_id ).
* Calculate and report results....
result = measurement->build_package_result( "MY_PACKAGE" ).
...

For more information on saving and retrieving standalone measurements from the repository of the Coverage API, see Step 6: Saving Code Coverage Results.
PUBLIC
Page 23 of 30
For more information about saving and reloading measurements in measurement series, see Step 5: Saving Measurements and Results in a Measurement
Series.
For more information on using results to report coverage statistics and on displaying results, see Step 3: Calculating Code Coverage Results, Step 4: Traversing
the Hierarchy of Results, and Step 5: Displaying the Code Coverage Results.
1.8.2 Merging Code Coverage Measurements
Procedure
You can merge a set of measurements to form a new measurement that combines the merged measurements.
Example: Perhaps you have a set of related measurements that actually belong together. And you want a single aggregate coverage statistic for you upper-level
management. Merging lets you get that aggregated result.
You can use the merged measurement exactly as you would any other measurement - you can calculate results from it, save it in the repository, and so on.
Merging combines the raw data of the measurements according to one of these three strategies:
CE_SCV_MERGE_STRATEGY=>UNION: Create a measurement that aggregates the coverage of all programs in the merged measurements. Answers the
question: "What is the overall coverage resulting from my measurements?"
CE_SCV_MERGE_STRATEGY=>INTERSECTION: Create a measurement that aggregates the coverage of all programs that were executed during both
measurements. Answers the question "What is the overall coverage of the objects executed in both measurements?"
CE_SCV_MERGE_STRATEGY=>DIFFERENCE: Create a measurement that reports the coverage only of programs that were executed during the first
measurement and not in any of the other merged measurements. Answers the question "What is the coverage of the objects executed in only one
measurement?"
Prerequisites for combining measurements are the following:
The raw data of each measurement to be merged is still available (has not been deleted or finalized)
The measurements to merge have been stopped (no more data is being collected).
You can merge as many measurements at a time as you wish.
Sample Code
Here is sample code for merging measurements.
* Source measurements
another_measurement TYPE REF TO if_scv_measurement.

* Merging of measurements
DATA: measurements TYPE if_scv_measurement=>tab,
merged_measurement TYPE REF TO if_scv_measurement.
* Results
text TYPE string.
* Create two measurements and measure two test programs
APPEND sy-uname TO users.
i_users = users ).
another_measurement = factory->create_measurement(
i_users = users ).
* First measurement
SUBMIT rsdssmpl_performance AND RETURN.
* Second measurement
another_measurement->start( ).
another_measurement->stop( ).
* Report the code coverage of the first measurement
text = |Package SMOI has after measurement 1 a statement coverage of { coverage->get_percentage( ) }%|.
WRITE:/ text.
* Report the code coverage of the second measurement
result = another_measurement->build_package_result( 'SMOI' ).
PUBLIC
Page 24 of 30
text = |Package SMOI has after measurement 2 a statement coverage of { coverage->get_percentage( ) }%|.
WRITE:/ text.
* Merge the measurements
* Insert the measurements to be merged into a parameter table
INSERT measurement INTO TABLE measurements.
INSERT another_measurement INTO TABLE measurements.
* Here are the constants for the supported merge strategies
* CE_SCV_MERGE_STRATEGY=>UNION Merge Coverage Measurements
* CE_SCV_MERGE_STRATEGY=>INTERSECTION Intersect Coverage Measurements
* CE_SCV_MERGE_STRATEGY=>DIFFERENCE Report Differences of Coverage Measurements
* We use the UNION strategy to aggregate the code coverages
merged_measurement = factory->merge_measurements(
i_name = 'myMerger'
i_measurements = measurements
i_strategy = ce_scv_merge_strategy=>union ).
* Report the merged code coverage
result = merged_measurement->build_package_result( 'SMOI' ).
text = |Object SMOI has a merged statement coverage of { coverage->get_percentage( ) }%|.
WRITE: / text.

In the example, we combine two standalone measurements. But you can also merge measurements in measurement series. You can even merge merged
measurements.
1.8.3 Assigning Measurements to a Measurement Series
Procedure
Do you have a standalone measurement that actually should be added to a series?
No problem: You can assign a measurement to a series.
Assigning a measurement to a series adds it to the set of measurements associated with the series. No aggregation of the measurement with other series
measurements occurs. You can assign a measurement even if the raw data of the measurement has been deleted. Assigning a measurement to a measurement
series also assigns any results of the measurement to the series.
Sample Code
Here is sample code for loading a preexisting measurement series and then assigning a standalone measurement to the series.
REPORT z_coverage_api_series_assign.
* Measurement Series
DATA: series TYPE REF TO if_scv_series.
* Standalone Measurement and Results
standalone_measurement TYPE REF TO if_scv_measurement,
standalone_result TYPE REF TO if_scv_result.
* Coverage API Repository
DATA repository TYPE REF TO if_scv_repository.
* Exceptions
DATA: ex_ops TYPE REF TO cx_scv_execution_error,
ex_call TYPE REF TO cx_scv_call_error.
* Load the series from the Coverage API repository
TRY.
series = repository->load_series( 'SERIES_SMOI_29_7' ).
CATCH cx_scv_execution_error INTO ex_ops.
CATCH cx_scv_call_error INTO ex_call.
ENDTRY.
* Create the repository
* Create a measurement that is not part of the series.
* You could also load a standalone measurement
* that was saved to the repository
TRY.
standalone_measurement = factory->create_measurement( 'STANDALONE_MEASUREMENT' ).
standalone_measurement->start( ). "Coverage API defaults are used
PUBLIC
Page 25 of 30
standalone_measurement->stop( ).
standalone_result = standalone_measurement->build_package_result( 'SMOI' ).
" Add the standalone measurement and result to the series.
series->assign_measurement( standalone_measurement ).
" Save the measurement and result in the series
repository->save_measurement( standalone_measurement ).
CATCH cx_scv_execution_error INTO ex_ops.
CATCH cx_scv_call_error INTO ex_call.
ENDTRY.

1.8.4 Handling Exceptions in the Code Coverage API
Procedure
The methods of the Coverage API raise two exceptions:
CX_SCV_EXECUTION_ERROR for unexpected errors during operation.
CX_SCV_CALL_ERROR for illegal method calls in programs that use the Coverage API.
Below is sample code showing the exceptions. The sample program for single measurements and the code examples in the Measurement Series tutorial show
some typical situations in the handling of these exceptions.
TRY.
"execute measurement and get result
"use execution_error->get_text( ) to log error
"issue an error message'
ENDTRY.

1.8.5 Recovering From a Blocked Measurement
Procedure
This section explains how to recover when a running measurement prevents you from starting new measurements.
In practice, this situation can come up only if you are doing in line coverage measurements in a single program context. The sample program for the first tutorial is
an example of this type of measurement.
Assume, for example, that you are measuring a program that runs an integration test. The program ends with a short dump. You correct the problem and restart
your integration test.
To your surprise, the new test run ends with an exception from the Coverage API. The reason: Another measurement is already running. What has happened?
The short dump prevented your old inline test from stopping the measurement. It now remains in status active, and prevents you from starting a new
measurement.
As long as a measurement is in status 'started', no other measurement that specifies any of the same users can start. How can you resume your code coverage
measurements?
Essentially, you just need to reload and stop the measurement. You do the same if you run the Coverage API over extended periods of time.
To reload and stop a blocking measurement in an inline test environment, you can add the following code to your IF_SCV_MEASUREMENT->START method call.
execution_error TYPE REF TO cx_scv_execution_error.
* Catch an operation exception when starting a measurement.
TRY.
* If the cause is a blocking measurement, then it is
* captured in the exception. You can use it to stop the
* blocking measurement.
IF execution_error->blocking_measurement IS BOUND.
execution_error->blocking_measurement->stop( ).
execution_error->blocking_measurement->finalize( ).
ENDIF.
ENDTRY.

If the exception was raised because of a blocking measurement, then the exception object contains a reference to the blocking measurement in attribute
BLOCKING_MEASUREMENT. You can use BLOCKING_MEASUREMENT to stop and finalize the blocking measurement. You can then try to start the new
PUBLIC
Page 26 of 30
measurement once again.
1.8.6 Naming Measurements and Results
Procedure
Measurements, and results can optionally be named. Naming these objects helps document your code coverage statistics. If you are working with a measurement
series object or measurement object, you can also use names to retrieve sets of measurements or results from the repository.
Here are some guidelines for naming conventions:
You are not required to give names to measurements and results. You can skip them if:
You are working with standalone measurements that you are not going to save to the repository
You are working with a measurement series that has only one measurement and only one result per measurement. Here, the relationship between the
objects is clear. In this case, the name of the measurement series by itself may be enough to document the series measurements and results.
Names are not the technical keys of measurements and results. That means that you can give the same name to all of a set of related measurements or
results.
If you calculate more than one result for each measurement you make, then give each set of results a name. You can then use the result name to retrieve
each set of results separately.
Example: You might want to calculate separate results for each of a set of disparate packages. .
Figure 1: Naming Convention for Multiple Results per Measurement in a Measurement Series
For the example shown in the graphic, the code to retrieve the second set of results might look like this:
DATA: results TYPE if_scv_result=>tab,
results = repository->find_results_by_series( i_series = series i_result_name = 'r2' ).
LOOP AT results INTO result.
" Analyze the trend of R2 results over time. You could pass the
" coverage data to an SAP-internal or external graphing or
" spreadsheet program.
ENDLOOP.

The same technique is possible with sets of results generated from a standalone measurement. If you have reloaded the measurement object, then you can
find the results of the measurement by name.
measurement TYPE REF TO if_scv_measurement.
results = repository->find_results_by_measurement(
i_measurement = measurement
i_result_name = 'r2' ).

1.9 Glossary
Definition
Code coverage
Branch Code Coverage
Statement Code Coverage
Procedure Code Coverage
Measurement
Measurement series
Repository
Users
Test key
Raw data
Result
Selection object
Configuration object
PUBLIC
Page 27 of 30
1.9.1 Measurement
Definition
The element in the Coverage API with which you collect code coverage data. A measurement lets you start and stop the recording of code coverage data. It also
exposes the methods that let you generate results from the raw data collected by the measurement.
A measurement is represented by an object of type IF_SCV_MEASUREMENT.
Typically, a measurement may occur as in line instrumentation in a test program or may be switched on by a test infrastructure. In these cases, the measurement
can be precisely restricted to a particular test activity or set of activities by one or a few users.
Alternatively, a measurement can be started at the start of a test period - a test week perhaps. It records all activity - potentially including nontest activity - by the
measurement users until it is stopped. This approach to collecting code coverage data is similar to that used in the Coverage Analyzer, transaction SCOV.
A measurement is client-specific. That is, it is visible only in the client in which it was created. However, because of technical limitations, a measurement records
all activity across clients by the measurement users. A measurement that records the activity of user 'AUNIT_TEST' in client 005 also records activity of a user
AUNIT_TEST in client 100.
Here is the tutorial on creating a standalone measurement, as in line instrumentation in a program.
Here is the tutorial on working with measurements in measurement series.
1.9.2 Branch Code Coverage
Definition
One of the three coverage measures that the Coverage API calculates.
Branch coverage reports on whether all paths through control structures have been taken. In general, control structures express branching decisions in the form of
boolean expressions, so that branch coverage measures whether such expressions have evaluated to both true and false. But ABAP also has non-conditional
branch statements, in which branching is not governed by the evaluation of a boolean expression.
Example: An IF...ELSEIF...ENDIF construct has 100% branch coverage if both the IF and ELSEIF statements have been executed with both true and
false results.
Details
The Coverage API statistic reports the percentage of branches in the code under test that were executed at least once.
ABAP distinguishes between conditional, unconditional, and 'switchable' branching statements.
Conditional branching statements each define a true and a false branch. For 100% coverage, each of the conditions of the statement must evaluate to both
true and false.
The conditional ABAP branch statements are as follows:
AT in control structures (with ENDAT)
CHECK
DO when used with TIMES
IF and ELSEIF ( ELSE is not counted as a branching statement)
LOOP
ON
PROVIDE
SELECT when used with ENDSELECT
WHEN ( OTHERS is not counted as a branching statement)
WHILE
Unconditional branching statements define only one branch each. CATCH and CLEANUP are the unconditional branch statements in ABAP. If they are
executed, their branch coverage is 100%. If not, their branch coverage is 0%.
Switchable branch statements are as follows: ASSERT, ENHANCEMENT, ENHANCEMENT-POINT, and ENHANCEMENT-SECTION. The Coverage API
ignores switchable branch statements for purposes of measuring branch code coverage.
In addition, each processing block is considered to contain a default branch defined by the processing block itself. This default branch has a coverage of 100% if
the processing block is executed, 0% if the processing block does not run.
You can display the exact coverage of branches in ABAP source code in the graphical display of the Coverage API.
ABAP's branch coverage does not offer the possibility of measuring condition coverage - whether boolean subexpressions in a control statement have evaluated
to both true and false. However, in the display of coverage at the source code level, you can display how subexpressions in a branching statement evaluated
during a code coverage measurement.
Branch coverage is often considered the most useful commonly available measure of code coverage. A high percentage of branch coverage implies that many
execution paths have been taken through the code under test. Further, as a rule a given level of branch coverage provides more comprehensive testing than the
same level in statement coverage.
Branch coverage is also known as decision coverage.
See also Step 3: Calculating Code Coverage Results.
1.9.3 Statement Code Coverage
Definition
Statement coverage reports on the percentage of ABAP statements in the code under test that were executed while a measurement was running.
PUBLIC
Page 28 of 30
As a rule of thumb, statements that count toward code coverage calculations are those at which you can set a breakpoint. Not included are data declarations,
some modularization statements, and other nonoperative statements.
You can display the exact coverage of statements in ABAP source code in the graphical display of the Coverage API.
1.9.4 Procedure Code Coverage
Definition
Procedure coverage measures how many of the functional entry points in the code under test have been called. Procedure coverage offers only a rough measure
of code coverage in comparison to branch and statement coverage. But it remains important for verifying that all functional entry points to the code under test have
been tested.
Procedure is something of a misnomer in ABAP code coverage. The actual granularity is processing blocks. This includes not only procedures (methods, function
modules, and subroutines) but also dialog modules and event blocks. However, if you are following SAP's ABAP programming guidelines, then the processing
blocks in new and refactored code are for the most part procedures in the form of ABAP Objects methods.
Procedure coverage is also known as function coverage.
1.9.5 Measurement Series
Process
The construct in the Coverage API that makes it easier to run and to manage repetitive series of code coverage measurements.
A measurement series offers these features:
The capability of specifying and saving a default configuration of code coverage calculation
The capability of specifying and saving a default selection of entities for which code coverage is to be calculated
The capability of saving a default set of users and a default scope setting (all servers of the system or only the local server)
Chronological ordering of measurements and results in the series, together with convenient mechanisms for accessing these objects.
A measurement series is represented by an object of type IF_SCV_SERIES.
Here is the tutorial on working with measurement series.
1.9.6 Coverage API Repository
Definition
Persistence facility of the Coverage API.
The repository of the Coverage API lets you store measurements, measurement series, and results in the database. It also lets you retrieve these entities for
further use.
The repository ensures that no inconsistencies can occur when saving. Saving a result also saves the associated measurement and measurement series, if
applicable. Saving a measurement also saves the associated series, if applicable.
To help you with retrieval, the repository offers convenient methods. You can, for example, retrieve measurements or results by measurement series, or results by
measurements.
In programs, you use the repository via an object of type IF_SCV_REPOSITORY.
1.9.7 Coverage API Users
Definition
In the Coverage API, the users whose activity is to be recorded in measurements.
While it is active (has been started), a measurement accumulates as raw data the activity of the users. Code coverage results are calculated from this raw data.
By default, the current user (the value of system field SY-UNAME) is the measurement user.
In a standalone measurement, you set the test users when you create the measurement.
In a measurement series, you set the users as part of the customizing of the series. The series supplies the user settings to any measurement that you create in
the series. If necessary, you can change the user settings on the fly before you create a new measurement in a series.
See also Step 1: Creating a Measurement and Step 2: Setting Defaults for a Measurement Series.
1.9.8 Raw Data
Definition
In the Coverage API, the code coverage data that is recorded during a measurement.
From raw data you calculate the code coverage results for specified application components, packages or individual programs.
PUBLIC
Page 29 of 30
The Coverage API collects raw data when a measurement is started and automatically persists the data in the database. Since raw data is bulky, it is deleted
automatically at the expiration of a retention period or when you finalize a measurement.
Raw data is also automatically deleted whenever the source code in a procedure or processing block is changed. If for example you monitor code coverage in a
test or consolidation system, the raw data is reset whenever new code is imported into the system. Measurements and results that have been saved are not
affected.
You can calculate new results or merge measurements only as long as the raw data of the measurement or measurements is available. The display of code
coverage in the source code is also available only as long as the raw data is available.
1.9.9 Result
Definition
In the Coverage API, an object that offers code coverage statistics calculated from a measurement. A result offers coverage figures for a selected set of entities.
The result is calculated according the current calculation configuration.
A result is represented by an object of type IF_SCV_RESULT. You can display the result directly using the built-in graphical display of the Coverage API. You
can extract particular statistics from the set stored in a result using the methods of IF_SCV_RESULT.
You can store and retrieve a result with the methods of the r epository of the Coverage API.
The Coverage API can provide three types of code coverage result: branch, statement, and process block coverage.
See also Step 3: Calculating Code Coverage Results and Step 4: Calculating Coverage Results in a Measurement Series.
1.9.10 Selection Object
Definition
In the Coverage API, a selection object specifies the set of entities for which code coverage is to be calculated.
The selection may contain application components from the SAP hierarchy, packages, and/or individual programs. You can explicitly include or exclude such
entities from a selection. You can also define ranges of entities as part of the selection.
You access a selection with methods of the IF_SCV_SELECTION interface.
If you are working with a standalone measurement, you can use a selection object with the IF_SCV_MEASUREMENT-BUILD_SELECTION_RESULT method to
build a single result for your selection.
In measurement series, you can save a selection object as the default selection. The series automatically passes the selection to the
BUILD_SELECTION_RESULT method, if you call this method with measurements of the series. (You can of course override the default by specifying a different
selection object.)
See also Using Object Selections.
1.9.11 Configuration Object
Definition
In the Coverage API, specifies how code coverage results are calculated from the raw data in a measurement.
With a configuration, you can specify which of the three types of code coverage are calculated in a result ( branch, statement, and procedure).
You can also control how results are calculated for entities that have hierarchies. You can, for example, have only a single aggregate result calculated for a
component or package. Or you can have individual results calculated for the entities in the component or package hierarchy as well.
You access configuration objects with the methods of the IF_SCV_RESULT_CONFIGURATION interface.
See also Configuring Results.
1.9.12 Test Key
Definition
In the Coverage API, the key under which a set of raw data generated by a particular measurement is stored.
Technically, a test key plays a similar role to a test group in the Coverage Analyzer, transaction SCOV. Both are keys to raw data on code coverage. For this
reason, a measurement cannot record data for a user if the user is registered to a test group in transaction SCOV. Similarly, two started measurements cannot
track the same user.
Unlike test groups, whose names you assign by hand in transaction SCOV, names of test keys are generated automatically by the Coverage API.
Tip: You can use a test key to display Coverage API data in the Details Display of the Coverage Analyzer. If you are a Quality Manager, you can let your
developers view a Coverage API measurement by giving them the test key and telling them to use it in the Detail Display.
PUBLIC
Page 30 of 30

Analysis Tools - Coverage API

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analysis Tools - Coverage API

Enviado por

Direitos autorais:

Formatos disponíveis

Using the Coverage API

PDF download from SAP Help Portal:

Você também pode gostar