Coverage Analyzer
Coverage Analyzer
developer to monitor processing blocks such as reports, subroutines, function-modules and methods.
Powerful filtering system in Coverage Analyzer facilitates developer to enter the number of calls
separately according to periods, users and functional areas.
In a nut-shell; Coverage Analyzer is a function for monitoring the system-wide execution of ABAP
programs;
Developer can use this tool to trace programs for development purpose and Quality Manager can use this
tool to check system performance for quality assurance.
It helps carry out a range of Administration Settings and the Monitoring Activity. Moreover it helps get
summarized information of number of program executions, number of runtime errors, number of program
resets. Fascinatingly, the results can be formatted separately according to user-group; each user-group
can contain any number of users under one test key.
1. Administration Settings
On/Off.
Test Groups.
Registrations.
Reset.
Settings.
Monitor.
Consistency Checks.
2. Display
Global.
Detail.
A simple exercise will help us easily understand Coverage Analyzer, rather simply going through
documentation.
In order to make use of Coverage Analyzer, user has to have an appropriate role. To check user
authorization;
Once user authorization is checked to have absolute access to SCOV (Coverage Analyzer) transaction;
user can proceed further. If a role is not assigned to a user, Basis consultant has to be consulted in this
regards.
In fact, a tip to be remembered is that Coverage Analyzer tool should be used on weekends or in the
evening, when all users and packages are on loose ends. Since backup server collects data from all the
servers including local and remote; system needs all packages and users to be in the passive mode.
Let’s start up with a simple example to understand Coverage Analyzer in a better way:
STEP 1: Call up the transaction SCOV or navigate through SAP Easy Access->SAP Menu->Tools-
>ABAP Workbench->Test->SCOV (Coverage Analyzer).
General Status of the system is shown on the right hand pane of the window;
Coverage Analyzer administration includes all of the functions required for carrying out settings and
checks.
Administration and Display nodes are shown on the left pane of the window.
STEP 2: Before the Coverage Analyzer being switched on, settings have to be maintained for backup
server and filters are to be set. Having not made settings for backup server, if Coverage Analyzer is
started, it simply throws out an information message to maintain background server for data collection.
So, Administration settings are to be done before starting up the Coverage Analyzer.
Settings function is used to set the parameters for the Global and Detail views, and to filter the programs
to be checked via the package.
Tip to remember: A program is regarded as tested if the following conditions are fulfilled;
Unicode Check = 1.
Count1 and RABAX1 indicate the number of programs executed and runtime errors since the Coverage
Analyzer was started.
Count2 and RABAX2 indicate the number of programs executed and runtime errors since the last reset.
Further, assign package to be used during analysis. When a package is pre-selected, the evaluation for
the Global view is only performed for this package. If this restriction is not applied, all of the programs are
included together with those from local packages ($*) and programs generated locally without
packages ( ).
If ABAP programs with a set Unicode flag are only to be traced by the Coverage Analyzer, then
selectUnicode checkbox. Checking Unicode is to mark it as ‘X’, else leave it unattended.
It’s optional to set the lights; lights provide a visual means of representing the status of the results for the
degree of coverage in the Global and Detail views.
Lights are set by default, which can be set according to developer’s way of analysis.
RED 0 LT 33 %
YELLOW 33 LT 66 %
GREEN 66 LE 100%
Further, Monitor Settings have to be done, which includes setting Trace Level and Maximum Entries Log
and Maximum Entries Data Monitor.
There are 4 different trace levels (1-4), the higher the trace level, the more information is drawn for
debugging.
Tip: The values for Maximum Entries Log and Maximum Entries Data Monitor limit the lines displayed for
the General Log and Monitor Data Volumes in the monitor function.
The defaulted lines for log file are 100 and for data volume are 200.
Background server has to be specified, where precisely data is to be collected. Moreover, the period for
which background job has to be repeated is also to be specified.
The defaulted value for Data Collection: Period (Min) is 30 mins, which can be modified based on
developer’s way of analysis. In this case, current server is specified as Background server.
Further, Summarization function facilitates checking the same processing blocks in several systems
simultaneously.
Tip to remember: The results from the individual systems are local and those from the remote
systemsare summarized.
To determine RFC connection with current server, call up transaction SM59->RFC Destinations->R/3
Connections->E6SCLNT900.
Desired RFC connections in Summarize coverage results can be specified; moreover period and start
time for summarize data can also be specified.
STEP 3: Choose On/Off, Status in the Administration node and start up the Coverage Analyzer.
Switch Coverage Analyzer On/Off: This displays the number of programs that have been initialized.
Switch Automatic Recordings On/Off: This displays the automatic recording period and the version
number for the Global view.
Switch Data Aggregations from Different Remote Systems: This displays background server and all of the
other systems whose results are used for Data-aggregation.
If the server is in switched-off mode exception shows RED signal, GREEN signifies server to be in
switched-on mode and YELLOW represents either RFC problem or database and shared memory
inconsistency.
In this case, we’ll proceed without switching on Switch Automatic Recording On/Off.
The servers which are actually running are shown as flagged up.
STEP 4: Create Test-Groups; Test-Groups are made to summarize and display the results of the
Coverage Analyzer for a particular set of users under one generic key/heading.
Tip to remember: Test-groups should not be created more than 10. Moreover, only users assigned a
role with the authorization object S_COV_ADM are allowed to define group.
ALL – Coverage results summarized for all test groups on the local system.
To create a test-group; switch on the Change Mode, click Append Row icon provided in the application
tool-bar.
To assign Users to a test-group; switch on the Change Mode, click Append Row icon provided in the
application tool-bar.
Select desired test-group for which users have to be assigned; in this case we assign SAPDEV02 as user
to test-group ZTST.
Tip: A test-group can contain any number of users, for example, all HR developers in one group. That
makes filtering pretty easy. Moreover, comparison of performance of test-groups can be done in Global
view.
STEP 6: An optional function to be done is Reset; explicitly this function is intended for situations in which
the results of the previous analyses are no longer required. It resets all the counters of the Coverage
Analyzer to 0 for all the programs of a selected group.
Further more, implicit reset is carried out automatically as soon as the flow or the data of a program
changes.
STEP 7: Consistency check has to be done for all the servers including remote ones, before proceeding
to actual analysis;
Check Status of All Servers checks whether the status in the shared memory matches the status in the
database.
Check Status of Background Jobs checks whether all the batch jobs of the Coverage Analyzer are
activated. If this is not the case, the batch jobs are all rescheduled by means of the Repair function.
Check Table Consistency (Long Runtime) may become inconsistent if the Coverage Analyzer fails on an
application server due to system error.
Repair function also bridges the gap between activating and generating a program.
So, in order to check inconsistencies, check the types of inconsistencies accordingly and Execute
Checks, and then choose monitor to check for the inconsistency messages,
GREEN indicates Information message, YELLOW indicates Warning message and RED indicates Error
message.
In the present case; no inconsistencies have been found while starting All Servers. In case, there arise
any warning or error messages, those problems are to be fixed and then select particular row of the
warning/error message and click Completed.
General Log gives general information, whileMonitor Volume gives detailed information of started server.
Once the warning is attended, select the row and hit Completed, which will going to turn yellow signal to
green signal.
Tip: Every time inconsistencies are checked; General Log should be refreshed.
Views can be based on Author or Package. ALL signifies all the authors on local system based on view
given and the COND (y/z test groups) signifies all the authors on both local and remote systems based on
view given. If ‘Other view’ is selected as Package, then selection is done accordingly.
Note: Since Automatic Recordings were not switched on; percentage-based progress display over time
cannot be seen for selected SAPDEV02 author.
Normally, Display view gives Quality Managers to view the system, the following way;
Unicode:
This value indicates how many percent of the processing blocks have the Unicode flag set (the flag itself
is set per program)
Capacity Utilization:
This value is computed as the ratio of used processing blocks to loaded processing blocks to loaded
processing blocks.
This value indicates in percent how many processing blocks have been executed since the start of the
Coverage Analyzer.
This value indicates in percent how many processing blocks have been executed in the actual version
without runtime errors.
In the example above you can see that currently 98% of the processing blocks in the system belong to a
program that has the Unicode flag set, 26% have been executed since start of the coverage analyzer, 9%
have been executed in the active version without errors and the capacity utilization is 29%.
STEP 9: Exact Value Table can be viewed for author SAPDEV02; which displays number processing
blocks for author SAPDEV02 on timely manner.
Graphical view of the selected row can be seen using icon; that displays graphical view of the
individual date and all dates when no row is selected.
STEP 10: Details view; gives summarized and detailed results. Details give low-level view.
Strong filtering options allow user to select on what conditions results are to be displayed.
Conditions can be set for range of test-groups, packages and authors pertaining to those test-groups.
In the present example; test-group ZTST and Author SAPDEV02 is taken as single-value selection, which
gives results pertaining to specified criteria. Moreover, other filters can also be set and settings should be
done defining access via Package Object, Package and Author. Defaulted access-via is Program Object.
Hitting Standard Settings is going to reset all the values.
Once settings are done; hit execute button, that is going to get detailed information, including number of
calls made to that particular object, number of processing blocks, load size in Kilo byte. Besides all the
information given; double-clicking the object name will navigate to the particular program or executing
block where exactly error has been found.
Note: Current Executions = Program units currently used / Total no. of Program units.
Capacity Utilization = No. of Program units currently used / Loaded Program units.
Conclusion: Likewise, many such program executions, runtime errors and program resets can be easily
traced using this powerful ABAP runtime analysis tool - Coverage Analyzer.