In this guide:
This guide is intended to help you collect coverage information for applications developed with .NET framework or Java technology.
The primary audience for this user guide is people responsible for ensuring compliance with your organization's policy regarding the application coverage level, including QA Engineers, developers, and build masters.
We assume that you are familiar with Parasoft technologies and have already deployed and licensed the following products:
The following options must be configured in the .properties file where you configure your dotTEST or Jtest settings to ensure that coverage data is correctly displayed on DTP:
report.coverage.images
– Specifies 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. DTP supports up to three coverage images per report.session.tag
– Specifies a unique identifier for the test run and is used to distinguish different runs on the same build.build.id
– Specifies a build identifier used to label results. It may be unique for each build, but it may also label several test sessions executed during a specified build.The static coverage file must be generated on the build machine that contains the source code. The name of the file is static_coverage.xml.
Run the following test configuration on the solution:
dottestcli.exe -config "builtin://Collect Static Coverage" -solution SOLUTION_PATH |
The location of the static_coverage.xml file will be printed to the console.
The static coverage file is included in the monitor.zip package generated by the Jtest Plugin for Maven, Gradle, or Ant during the build process.
monitor
task or goal to your build command and execute the command in the AUT's main directory to generate the monitor.zip package. The location of the package will be printed to the console.Maven
mvn package jtest:monitor |
Gradle
gradle assemble jtest-monitor -I [INSTALL]/integration/gradle/init.gradle |
Ant
ant -lib [INSTALL]/integration/ant/jtest-ant-plugin.jar -listener com.parasoft.Listener jtest-monitor |
Ant requires all classes to be compiled before the monitor task is executed. Modify your project prior to the build and configure the task to ensure the correct sequence. The following example shows how the target can be configured:
|
Attaching the Coverage Agent to the AUT allows you to enable collecting dynamic (runtime) coverage.
To attach the Coverage Agent to the AUT, you need to launch the IIS Manager tool shipped with dotTEST on the machine where IIS is installed and the AUT is deployed.
<DOTTEST_INSTALLATION_DIR>\integration\IIS
directory to the machine where IIS is installed and the AUT is deployed.Invoke the following command to launch the IIS Manager tool:
dottest_iismanager.exe |
Go to the following address to check the status of the coverage agent: http://host:8050/status
. If the Coverage Agent is attached, you should receive the following response:
{"session":null,"test":null} |
To attach the Coverage Agent to the AUT, you need to add Jtest's -javaagen
t VM argument to the startup script of the server where the AUT is deployed.
Run the agent.sh/agent.bat script to print the Jtest Java agent VM argument to the console:
Jtest Agent VM argument: -javaagent:"[path to agent dir]\agent.jar"=settings="[path to agent properties file]\agent.properties",runtimeData="[path to monitor dir]\monitor\ runtime_coverage" |
-javaagent
argument to the application server’s startup script.Go to the following address to check the status of the coverage agent: http://host:8050/status
. If the Coverage Agent is attached, you should receive the following response:
{"test":null,"session":null,"testCase":null} |
You need to configure SOAtest, which SOAtest enables you to collect application coverage during automated functional test execution.
jtest.agent.port
setting in the agent.properties file (default is 8050
). You can click Test Connection to verify that SOAtest can communicate with the coverage agent. In the next step, you will execute your tests using the new test configuration from the command line. But in order for DTP to be associated the test results with the coverage information, you will need to create a properties file and specify the settings required for DTP to properly match and display application coverage data. The simplest way is to export the properties referenced by the SOAtest desktop.
report.coverage.images
– Specifies 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. DTP supports up to three coverage images per report.session.tag
– Specifies a unique identifier for the test run and is used to distinguish different runs on the same build.build.id
– Specifies a build identifier used to label results. It may be unique for each build, but it may also label several test sessions executed during a specified build. If you want to merge SOAtest 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 in this file must match the build ID set for dotTEST or Jtest when collecting static coverage.dtp.project
– Specifies the project on DTP with which you want to associate the coverage results. The DTP project set in this file must match the DTP project set for dotTEST or Jtest when collecting static coverage.Run SOAtest in the command line mode using the test configuration and the .properties file created in the previous step. You will also need to include the workspace and test assets (.tst files).
./soatestcli -config "/path/to/your/test-configuration/app-cov.properties" -data "/path/to/your/workspace" -resource "/path/to/your/tests/your_tests.tst" -localsettings "/path/to/your/localsettings/file/soatest-app-cov.properties" |
In order to view coverage in the DTP dashboard, you will need to associate the coverage data sent to DTP with the filter.
Application Coverage
and choose the coverage image tag you specified from the Coverage Image menu. You can collect coverage information for functional tests even when multiple users are simultaneously accessing the same Java or IIS web application server. This allows QA engineers to perform testing sessions in parallel with automation and associate coverage with functional tests.
Collecting coverage data from multiple users requires additional configuration steps before you start your testing session. You need to:
You can enable the multi-user mode by modifying the invocation of the dotTEST IIS Manager tool (see Step 2: Attach the Coverage Agent to the Application Under Test (AUT)). Launch the tool with the -multiuser
switch:
dottest_iismanager.exe -multiuser |
You can enable the multiple-user mode by modifying the options in the agent.properties file, which is included in the monitor.zip package (see Generating Static Coverage with Jtest). Open the file and configure the following option:
jtest.agent.enableMultiuserCoverage=true |