Automated testing

Perforce ALM builds a bridge to your continuous integration/continuous delivery (CI/CD) pipeline. Regardless of your automated testing tool, you can automatically send build and test results back to ALM and associate the test results with test cases for complete traceability.

If you use Jenkins, we recommend using the Perforce ALM Jenkins Plugin to submit build and test results to ALM. See Using the Perforce ALM Jenkins Plugin in the web client documentation.

If your automated tests produce a report format that is not supported by the plugin, or you are not using Jenkins, you can use the Perforce ALM REST API to work with automation suites and submit build and test results to ALM.

Submitting results via the REST API requires writing a REST API client and result parser that parses a report file and translates the data to the REST API JSON structure for submitting builds and test results.

If you use both Jenkins and other tools for testing, you can use the Jenkins plugin and REST API in parallel.

The following information guides you through basic information and an example for using the REST API to submit automated testing data to ALM. If you need additional help creating a solution to support your automated testing efforts in ALM, contact Perforce Services.

Concepts

In Perforce ALM, automation suites define a group of related automated tests that run together. You can add suites based on functional area, specific testing type, or any logical organization that supports your testing needs.

An automation suite contains:

• Details about the group of automated tests.
• Test cases related to the automated tests.
• Builds and automated test results.
• Other data, such as run configurations, which are used to run builds in Jenkins from ALM.

To view meaningful testing data in ALM after builds complete in your automated testing tool, build and test result data needs to be submitted to ALM and test results need to be associated with related test cases. Association can be done automatically or manually. See Associating automated test results with test cases in the web client documentation for more information.

Regardless of how builds and test results are submitted to ALM, after submission, you can view detailed information about builds and test results in the ALM web client. See Viewing builds in the web client documentation for more information.

Endpoints

REST API endpoints and examples for automated testing are available in the following categories in the REST API reference:

• test case automation
• automation suites
• automation builds
• automation results
• automated testing configurations

Workflow for submitting builds and test results via the REST API

1. Add an automation suite to the ALM project. You can add suites in the web client or using the POST /{projectID}/automationSuites endpoint.

2. Find the automation suite recordID using the GET /{projectID}/automationSuites endpoint.

3. Submit the build to ALM using the POST /{projectID}/automationSuites/{automationSuiteID}/submitBuild endpoint.

Example

See Example – Submitting a build and automated test results using the REST API for help understanding what is required to submit a build and automated test results using the REST API and how the submitted data is displayed in the ALM web client.

Considerations

• The REST API supports setting additional data on builds that is not included in JUnit reports. For example, the REST API supports a device parameter for each test result, but this is not supported in JUnit reports. If your report has data like this that you want to submit to ALM, you need to create JSON in the submit request to populate the data in ALM.
• For builds, you can add any name/value pairs for the properties property. Any submitted properties are displayed as name/value pairs in the Build Properties area in the ALM web client.
• Each test result can be associated to a test case automatically using a script ID in the name or tags properties. You can also manually associate results with test cases in the ALM web client. When you create a manual association, the result uniqueName is used to associate the result with the test case for all subsequent builds.

Test result status IDs

Test result status has id and label properties. For example:

"status": {
    "id": 1,
    "label": "passed"
},

The status name, specified in label, is renamable. You may want to use the numeric values for id instead of label.

Following are the numeric values for id and how they correspond to statuses.