This topic provides information about how to use SOAtest as part of the Parasoft Application Coverage workflow. For complete information about using the Application Coverage solution, refer to the Collecting Coverage for Web Applications guide. In this section:

Introduction

Parasoft Application Coverage enables you to measure test coverage while executing tests on your running applications. This enables you to gauge the effectiveness of your existing test suite, determine where additional tests need to be added, and more efficiently execute tests as the application evolves. 

The following steps describe the Application Coverage workflow:

1. Generating the static coverage file. The static coverage file (static_coverage.xml) is generated by Jtest or dotTEST. It is an XML file that contains metadata about user classes, methods, and lines.
2. Attaching the Coverage Agent to the application under test (AUT). The Coverage Agent ships with Jtest and dotTEST, and allows you to monitor the code being executed when the AUT is running.
3. Connecting Coverage Agent Manager (CAM) to the Coverage Agent. Create the connection before you start interacting with the AUT.
4. Performing test sessions. You can either execute tests with SOAtest or use Parasoft's Coverage Agent Manager (CAM), which is a functional testing UI that allows you to mark the beginning and end of test and test sessions while collecting coverage on the running AUT. CAM is available from the Parasoft customer portal.
5. Downloading test results and the dynamic (runtime) coverage data when a test session is finished. The dynamic coverage data is saved in the runtime_coverage_<timestamp>.data file. The test results are stored in the report.xml file.
6. Uploading the test results to DTP. Data Collector Upload Form allows you to upload the report.xml file to DTP.
7. Merging the dynamic and static coverage information and send it to DTP. Use Parasoft Jtest or dotTEST to merge the static coverage data (static_coverage.xml) and dynamic coverage data (runtime_coverage_<timestamp>.data) into a coverage.xml file, and send the coverage.xml file to DTP. If the coverage images, session tags, and build IDs associated with the coverage.xml file and report.xml file match, DTP can properly aggregate, associate, and display the data in a range of reporting mechanisms.

Refer to the Collecting Coverage for Web Applications guide for complete details.

You can also install the Parasoft Process Intelligence Pack extension for DTP and deploy the Test Impact Analysis (TIA) flow to your DTP environment. TIA calculates testing metrics that are affected by code changes and reports the data in DTP interfaces. Test Impact Analysis collects all files in a code base and analyzes the test cases associated with each file. If a file has been modified within the specified date range and the test cases associated with it have not run since the change, then the test case "Action" field will be set to "Retest" in the Test Explorer. Otherwise, the test case "Action" will not be modified.

Configuring the Application Under Test for Coverage

The first step in the application coverage workflow is to configure the application under test (AUT) for coverage. This involves generating a static coverage data file that captures information about the source code as well as configuring the coverage agent for the AUT. To do this:

1. On a build machine, generate a static coverage file as described in the Jtest or dotTEST documentation.
2. Configure the application under test with the Parasoft coverage agent as described in the Jtest or dotTEST documentation.

Test Configuration and Execution

With the proper configuration, SOAtest will collect application coverage during test execution. To configure and execute SOAtest for application coverage data collection:

1. Configure a SOAtest Test Configuration to collect application coverage data as follows:
   1. Open the Test Configuration that you want to collect application coverage data.
   2. Open the Execution> Application Coverage tab.
   3. Enable the Collect application coverage option.
   4. Under Coverage agent host, specify the host name or IP address of the machine where the coverage agent resides.
   5. Under Coverage agent port, specify the coverage agent’s port. The default is 8050. You can click Test Connection to check if your settings are working properly.
   6. (Optional) Under Coverage agent user ID, you can specify a user ID so that coverage results can be associated with a specific user. A user ID should only be specified when the coverage agent is configured to run in multi-user mode. See the DTP Engine documentation for details.
   7. If you want test failures reported when the coverage agent connection fails, check Report coverage agent connection failures as test failures. Otherwise connection problems will be reported to the console, but will not cause the test to fail.
   8. Check Retrieve coverage data, then use Coverage data storage directory to indicate where you want the dynamic coverage data stored. You do not need to enable this option if the coverage agent is running on the build machine where static coverage was generated (since, in this case, both the static and runtime data can be published to DTP directly from the build machine).
   9. If you want the coverage data on the AUT deleted as soon as SOAtest retrieves it, also check Delete coverage data on retrieval. We recommend enabling this option in order to prevent the buildup of data files on the machine where the coverage agent is located.
   10. Apply the Test Configuration changes.
2. Configure a SOAtest localsettings file that sets:
   • The build id (build.id) based on how you want to correlate coverage results. If you want to merge these coverage results with those from other types of testing—such as unit testing and manual testing of the same application—they must all use the same build id. The build id set here must match the one that will be set on the DTP engine when collecting the static and dynamic coverage files and uploading the coverage data.
   • The project (dtp.project). This value must match the dtp.project value that will be set on the DTP engine when collecting the static and dynamic coverage files and uploading the coverage data.
3. Run a test in command line mode using the Test Configuration and localsettings file that were previously configured (described in Application Coverage). This test should be part of an automated process.

Uploading Test Results to DTP

In order for DTP to correlate coverage results with SOAtest test results, it needs details about what tests were executed along with the test execution results. Make sure that the Enable reporting results to DTP option under Parasoft> Preferences> DTP is enabled. A valid license with the Command Line option is required.

Creating a Combined Coverage Report and Uploading it to DTP

The final step in the workflow is to use Jtest or dotTEST to correlate the static and dynamic coverage data. The report produced by this step determines which source code was covered by the executed tests. To perform this processing and upload the results to Parasoft DTP:

1. Use Jtest or dotTEST to generate a coverage.xml file and upload it to DTP as described in the Jtest or dotTEST documentation. SOAtest stores dynamic coverage data in the location specified in the SOAtest Test Configuration’s Coverage data storage field.

Reviewing Coverage in DTP

Click on a coverage widget in DTP to open the Coverage Explorer and review the application coverage achieved by your SOAtest tests. The Coverage Explorer shows the merged correlated coverage from SOAtest and other test execution tools when a coverage report is created as described in the DTP Engines documentation. See the DTP Documentation (Report Center> Explorer Views> Coverage Explorer) for details on using the Coverage Explorer.

The tests panel shows details about the file and associated coverage. Test names also link to the Test Explorer in DTP so you can view additional test and coverage information.

Test Impact Analysis with DTP

If you use Parasoft DTP, you can install the Parasoft Process Intelligence Pack and deploy the Test Impact Analysis (TIA) flow, which identifies the test cases directly related to your most recent source code modifications. TIA presents test cases affected by changes so that you can run a minimum set of tests rather than retesting the entire system after each modification. For details, see Test Impact Analysis in the DTP documentation.