Page History

...

If you have access to the application source code, you should generate the static coverage file using Jtest in .xml or .data format if at all possible. The method Doing it this way has several advantages, including containing metadata about user classes, methods, and lines, as well as supporting showing source code annotated with coverage data when viewing coverage results in DTP. It also improves Test Impact Analysis, as static coverage generated this way provides for more precise analysis so tests will only be flagged as impacted if they traverse any methods that have been changed. While you can use TIA with static coverage generated from application binaries, TIA results will be broader (since analysis is done at the level of classes) and some tests may be flagged as being impacted when they don't need to be. See Jtest user guide at at docs.parasoft.com for more information on generating static coverage files with those tools.

...

• build.id: Set to the build ID with which to correlate coverage results. If you want to merge Selenic coverage results with results 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 build ID set for Jtest when collecting the static and dynamic coverage files and uploading the coverage data.
• dtp.project: This value must match the dtp.project value set for Jtest when collecting the static and dynamic coverage files.
• report.dtp.publish: Set to true to enable publishing test result data to DTP.
• application.coverage.enabled: Set to true. This enables application coverage.
• application.coverage.agent.url: Specify the URL where the application under test and coverage agent are hosted. Include the protocol (HTTP/HTTPS) and port number of the agent. Separate multiple entries with a semi-colon ( ; ). For example: http\://<Agent Host>\:8050;http\://<Agent Host>\:9050.
• application.coverage.user.id: Optional. 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 jtest.agent.enableMultiuserCoverage below.
• application.coverage.dtp.publish: Set to true to upload coverage reports to DTP or false to not upload coverage reports to DTP. If you have configured multiple coverage agents, their coverage reports will be merged into a single coverage report for DTP. Defaults to the value of report.dtp.publish (see Configuring Settings) or to true if -publish is passed to seleniccli.
• application.coverage.binaries: Optional. Specify the URL or local file that contains binaries of the application under test (AUT). You can specify the path to a folder or a .war, .jar, .zip, or .ear file. Not needed if the static coverage file is uploaded to DTP separately. Do not use if application.coverage.static.file has been specified.
• application.coverage.binaries.exclude: Optional but recommended. Specify a comma-separated pattern of application binaries to exclude during AUT scanning. If neither this nor application.coverage.binaries.include is configured, analysis of binaries will take longer and analyze more of the application than needed is configured, analysis of binaries will take longer and analyze more of the application than needed. In many cases, there is no need to measure code coverage of third-party library code, so it is preferable to limit code coverage to project code using this setting. Do not use if application.coverage.static.file has been specified. By default, all binaries are accepted. For example, application.coverage.binaries.exclude=jakarta/**,java/**,javax/**,org/apache/**,org/springframework/**
• application.coverage.binaries.include: Optional but recommended. If neither this nor application.coverage.binaries.exclude is configured, analysis of binaries will take longer and analyze more of the application than needed. In many cases, there is no need to measure code coverage of third-party library code, so it is preferable to limit code coverage to project code using this setting. Specify a comma-separated pattern of application binaries to include during AUT scanning. Do not use if application.coverage.static.file has been specified. By default, all binaries are accepted. For example,  application.coverage.binaries.include=com/myapp/data/*,com/myapp/common/**
• application.coverage.static.file: Optional. Specify the path to the static coverage file generated with Jtest in the .xml or .data format, or by the Selenic coverage tool that analyzed the application binaries. Not needed if the static coverage file is uploaded to DTP separately. Do not use if application.coverage.binaries has been specified.
• application.coverage.images: Specify a set of tags that are used to create coverage images in DTP. A coverage image is a unique identifier for aggregating coverage data from runs with the same build ID. Separate multiple entries with a semi-colon ( ; ). For details, see the Parasoft DTP user guide. For example: ${dtp_project};${dtp_project}_Functional Test.

...