In this section:

build.id

This setting specifies a build identifier used to label results. It may be unique for each build but may also label more than one test sessions that were executed during a specified build.

The maximum length for a build ID is 128 characters.

Acceptable Values

Example Usage

The default build ID includes the name of the project in DTP and the date of the build. For example, for the ATM project, the build ID included in the report may resemble the following: ATM-2017-07-07. 

The following configuration specifies the custom build ID that consists of the name of the project and the build number passed via the environmental variable BUILD:

build.id=${dtp_project}-${env_var:BUILD}

For the ABC project and the build number 114 on a CI server, this may resolve to ABC-114.

dupcode.sorting.mode

This setting specifies how elements in the code duplication findings are sorted. 

Acceptable Values

exec.env

This setting specifies a string that describes the environment where the run was executed. It allows you to tag an entire testing session, as well as individual test suites, tests, or test cases via services API. By default, the tag is a combination of the operating system name (e.g., Windows, Linux) and its architecture (e.g., x86, x86_64).

Acceptable Values

Example Usage

The following configuration specifies that the run was executed on a 64-bit Linux machine with the GCC 5.4 compiler:

exec.env=linux_x86_64_gcc5.4

goal{n}.name

This setting specifies the name of a goal–a subset of findings that meet the specified criteria (see goal.severities, goal.projects, goal.max.to.recommend, goal.rules, goal.deadline). The findings are listed in the "Goals" section of the HTML report as recommended for each developer.

You can configure more than one goal by adding a number to the "goal" prefix.

Acceptable Values

Example Usage

The following configuration enables two goals: "Priorities1" and  "Priorities2".

goal1.name=Priorities1

goal2.name=Priorities2

goal{n}.severities

This setting specifies the severity level of findings you want to be reported for a goal. This setting requires goal.name to be configured.

You can specify more than one severity.

Acceptable Values

Example Usage

The following configuration enables the "Priorities1" goal that is a subset of findings with the severity level  1 or 2.

goal1.name=Priorities1

goal1.severities=1,2

goal{n}.max.to.recommend

This setting specifies the maximum number of findings reported for each developer in the "Goals" section of the HTML report. This setting requires goal.name to be configured.

Acceptable Values

Example Usage

The following configuration specifies a reporting limit for the "Priorities1" goal to be 20.

goal1.name=Priorities1

goal1.severities=1,2

goal1.max.to.recommend=20

goal{n}.projects

This settings specifies that you want a goal to only include findings for a particular project. This setting requires goal.name to be configured.

Acceptable Values

Example Usage

The following configuration specifies that the "Priorities1" goal will only include severity 1 and 2 findings reported for the "examples" project.

goal1.name=Priorities1

goal1.severities=1,2

goal1.projects=examples

goal{n}.rules

This setting specifies the rule(s) that you want to report findings for a goal. This setting requires goal.name to be configured.

Acceptable Values

Example Usage

The following configuration specifies that the "Priorities1" goal will only include findings reported for the BD_SECURITY_VPPD  and BD_PB_VALRANGE rules.

goal1.name=Priorities1

goal.rules=BD_SECURITY_VPPD,BD_PB_VALRANGE

goal{n}.deadline

This setting specifies the deadline for fixing the findings. The number of findings reported for the goal depends on the time left to the deadline: the total number of findings is divided by the number of days left. This setting requires goal.name to be configured.

Acceptable Values

Example Usage

The following configuration specifies that all findings reported by the BD_SECURITY_VPPD  and BD_PB_VALRANGE rules are to be fixed by May 10, 2019.

goal1.name=Priorities1

goal.rules=BD_SECURITY_VPPD,BD_PB_VALRANGE

goal1.deadline=2019-05-10

goal.ref.report.file

This setting specifies the path to a reference report.xml file that will be used as a baseline to identify new findings during the current analysis. Findings detected in the current analysis run are marked as 'new' if they are not present in the reference file specified with this setting.

Acceptable Values

Example Usage

The following configuration specifies that findings detected during the current analysis will be compared against the report.xml file in the 'baseline' directory:

goal.ref.report.file=C:/parasoft/baseline/report.xml

goal.ref.report.findings.exclude

This setting enables or disables excluding existing findings from the report. Existing findings are identified by comparing findings detected in the current analysis run against the reference report.xml file report configured with goal.ref.report.file. If enabled, current findings that are also present in the reference file are excluded from the report.

Acceptable Values

Example Usage

The following configuration excludes existing findings from the report:

goal.ref.report.file=http://mycompany.com/sa/baseline/report.xml

goal.ref.report.findings.exclude=true

issue.tracking.tags

This setting specifies a list of issue tracking tags. It requires the report.associations option to be enabled.

Acceptable Values

Example Usage

The following configuration disables the default tag asset and enables the custom tag high:

report.associations=true

issue.tracking.tags=fr,pr,req,task,high,test


project.module

This setting specifies a custom name for the project's module. The setting may be used to describe unique runs. If unspecified, the tested module is detected automatically based on the analyzed code.

Acceptable Values

Example Usage

The following configuration specifies the custom XTests module name:

project.module=xTests

report.active_rules

This setting specifies if the report contains a list of the rules that were enabled during analysis. 

Acceptable Values

Example Usage

The following configuration disables showing the rules that were enabled during analysis in the report:

report.active_rules=false

report.archive

This setting enables or disables archiving reports into a ZIP file.

Acceptable Values

report.associations

This setting enables or disables showing requirements, defects, tasks, and feature requests associated with a test in the report.

Acceptable Values

Example Usage

The following configuration disables showing requirements, tasks and feature requests in the report:

report.associations=false

report.assoc.url.[tag]

This setting generates a link to an association inside the HTML report. The URL is a query string that contains an [%ID%] placeholder for the PropertyAttribute value. The associated tag must be configured with the issue.tracking.tags option.

Acceptable Values

Example Usage

The following configuration enables a custom tag high and generates a link in the HTML report.

report.associations=true

issue.tracking.tags=high

report.assoc.url.high=http://bugzilla.company.com/workitem?id=[%ID%]

report.authors_details

This setting specifies whether the report includes an overview of the number and type of tasks assigned to each developer.

Acceptable Values

Example Usage

The following configuration disables including details about numbers and types of tasks for each developer:

report.authors_details=false

report.contexts_details

This setting specifies whether the report includes an overview of the files that were checked or executed during analysis.

Acceptable Values

Example Usage

The following configuration disables including a list of files that were checked.

report.contexts_details=false

report.coverage.images

This setting specifies a set of tags that will be used to create coverage images in DTP. DTP supports up to 3 coverage images per report. 

Acceptable Values

report.coverage.limit

This setting that specifies the lower coverage threshold. Coverage results lower than the specified value are highlighted in the report.

Acceptable Values

Example Usage

The following configuration sets the lower coverage value to 50:

report.coverage.limit=50

report.coverage.line.hashes

This setting specifies if line hashes are included in the XML coverage report.

Acceptable Values

report.coverage.version

This setting specifies the version of the XML coverage report.

Acceptable Values

report.custom.extension

This setting specifies the report file extension of the XSL file for a custom format. It requires the report.format option to be set to custom, as well as report.custom.xsl.file to be configured.

Acceptable Values

report.custom.xsl.file

This setting specifies the location of the XSL file for a custom format.

Acceptable Values

Use double backslashes to specify the file path on Windows.

report.developer_errors

This setting specifies whether manager reports will include details about developer errors. 

Acceptable Values

Example Usage

The following configuration enables including details about developer errors in the report:

report.developer_errors=true

report.developer_reports

This setting specifies whether the system generates detailed reports for all developers (in addition to the summary report for managers).

Acceptable Values

Example Usage

The following configuration enables generating detailed reports for developers:

report.developer_reports=true

report.dtp.publish

This setting determines whether the current installation of the product reports results of local analysis to the DTP server.

Acceptable Values

Example Usage

The following configuration enables sending local analysis results to DTP.

report.dtp.publish=true

Related

• Reviewing Results

report.dtp.publish.src

This setting specifies whether the tested source code is published to the DTP server.  

Acceptable Values

Example Usage

The following configuration enables partial publishing of source code to DTP.

report.dtp.publish.src=min

Related

• Reviewing Results

report.format

This setting specifies the report format. Use a comma separated list of formats to reports in more than one format.

Acceptable Values

Example Usage

The following configuration specifies the PDF report format:

report.format=pdf

report.graph.start_date

This setting specifies the start date for trend graphs that track static analysis task, test execution, and cover­age. Requires configuring the report.graph.period option.

Acceptable Values

report.graph.period

This setting specifies the duration from the start date for trend graphs that track static analysis task, test execution, and coverage. Requires configuring the report.graph.start_date option.

Acceptable Values

report.location

This setting specifies the directory where the report will be created.

Acceptable Values

Example Usage

The following configuration specifies the path to the new_reports directory:

report.location=C:\\Users\\user1\\new_reports

report.mail.enabled

This setting enables or disables report emails to developers and additional recipients specified with the report.mail.cc setting. 

Acceptable Values

report.mail.server

This setting specifies the mail server used to send reports.

Acceptable Values

report.mail.port

This setting specifies the port for SMTP  server.

Acceptable Values

report.mail.security

This setting specifies SMTP server connection security. 

Acceptable Values

report.mail.subject

This setting specifies the subject line of the emails that are sent.

Acceptable Values

Example usage

report.mail.subject=ABC Project Results

report.mail.username

report.mail.password

report.mail.realm

These settings specify required information for SMTP server authentication. The realm value is required only for those servers that authenticate using SASL realm.

Example usage

report.mail.username=user1
report.mail.password=Psm#3P!

report.mail.domain

This setting specifies the mail domain used to send reports.

Acceptable Values

report.mail.time_delay

This setting specifies a delay between emailing reports (to avoid bulk email restrictions).

Acceptable Values

report.mail.from

This setting specifies the content of the "from" field of the emails sent.

Acceptable Values

report.mail.attachments

This setting enables or disables sending reports as attachments. All components are included as attachments; before you can view a report with images, all attachments must be saved to the disk.

Acceptable Values

report.mail.compact

This setting specifies how the report information is delivered in the email. This setting is not configured by default.

Acceptable Values

report.mail.format

This setting specifies the content type for the email. 

Acceptable Values

report.mail.cc

This setting specifies email address for sending comprehensive manager reports. Multiple addresses must be separated with a semicolon. This setting is commonly used to send reports to managers or architects, as well as select developers.

Acceptable Values

Example Usage

[email protected];[email protected]

report.mail.include

This setting specifies email addresses of developers that you want to receive developer reports.  Multiple addresses must be separated by a semicolon.  This setting is commonly used to send developer reports to developers if developer reports are not sent automatically (e.g., because the team is not using a supported source control system). 

Acceptable Values

report.mail.exclude

This setting specifies email addresses that should be excluded from automatically receiving reports.

Acceptable Values

report.mail.exclude.developers

This setting enables or disables report emails to developers who are not explicitly listed in the report.mail.cc setting. This setting is used to prevent reports from being mailed to individual developers.

Acceptable Values

report.mail.unknown

This setting specifies where to email reports for errors assigned to "unknown".

Acceptable Values

report.mail.on.error.only

This setting enables or disables email reports to the manager when an error is found or a fatal exception occurs. Developer emails are not affected by this setting; developer emails are sent only to developers who are responsible for reported errors.

Acceptable Values

report.metadata

This setting specifies whether additional metadata about findings should be downloaded from DTP. Only the findings that are already available on DTP are affected. The DTP server must also support the metadata service for this setting to take effect.

Acceptable Values

Example Usage

The following configuration disables downloading additional metadata from DTP:

report.metadata=false

report.metrics.attributes

This setting specifies a list of additional attributes for metric results. 

Acceptable Values

report.rules

This setting specifies a directory for storing static analysis rules HTML files (retrieved by clicking the Printable Docs button in the Test Configuration's Static Analysis tab). 

Acceptable Values

Example Usage

Example 1:

report.rules=file:///C:/parasoft/gendoc/

Example 2:

report.rules=../gendoc/

report.scontrol

This setting specifies if and how much additional information from source control is included in the report.

Acceptable Values

Example Usage

The following configuration enables including  information about repositories, file paths, and revisions in the report:

report.scontrol=min

report.suppressed_msgs

This setting specifies whether the report includes suppressed messages.

Acceptable Values

Example Usage

The following configuration enables including suppressed messages:

report.suppressed_msgs=true

report.setup.problems

This setting specifies where the Setup Problems section is placed in the report.

report.setup.problems.category_limit

This setting specifies a limit to the number of messages reported in a single setup problem category.

Acceptable Values

report.setup.problems.display_limit

This setting specifies a limit to the total number of messages displayed in the HTML report in the setup problem section.

Acceptable Values

report.setup.problems.console

This setting specifies whether setup problems will be printed on the console.

Acceptable Values

report.separate_vm.xmx

This setting specifies how much memory should be used for reports generation. 

Acceptable Values

report.separate_vm

This setting enables or disables generating reports as a separate virtual machine.

Acceptable Values

report.separate_vm.launch.file

This setting specifies the path to launch file that should be used during reports generation.

Acceptable Values

Use double backslashes to specify the file path on Windows.

report.test_params

This setting specifies whether the report includes test parameter details. 

Acceptable Values

session.tag

This setting specifies a tag for signing results from the test session. The tag is a unique identifier for the specified analysis process made on a specified module. Reports for different test sessions should be marked with different session tags.

You can create a tag using a string of characters, as well as the variables (see Using Variables).

Acceptable Values

Example Usage

The default session tag includes variables that specify the source control branch name and the execution environment. For example, if source control integration is not configured, and the test session is performed on a 64-bit Windows, the report will include a session tag that may look as follows: ${scontrol_branch}-win32_x86_64.

The following configuration specifies a tag other than the default:

session.tag=ut_win