Push test results to ALM Octane

To send test results to the ALM Octane server from other applications: 

  1. Authenticate and sign in.

  2. Retrieve the XSD schema of the payload containing the test results.

  3. Verify that the payload conforms to the XSD schema before pushing the test results.

  4. Push the test results using test-results.

  5. Check the status of the POST.

Retrieve the test results payload

Before pushing the test results, retrieve the XSD schema of the payload using a GET operation:

GET .../api/shared_spaces/<shared_space_id>/workspaces/1002/test-results/xsd

Use the XSD schema to prepare and validate your payload before using it. You will use the payload to:

Back to top

Validate the test results payload

Get familiar with the payload XML and how it relates to entities in ALM Octane.

For sample payloads, see Sample Payloads.

The following table describes the XML elements to use in the payload for each entity type in ALM Octane:

To refer to this ALM Octane entity / attribute Use this ALM Octane entity name in REST Use this element/attribute in the payload XML

Release

release

release or release_ref

Story or Feature

story or feature

backlog_items or backlog_item_ref

Application module

product_area

product_areas or product_area_ref

Test

test

test_fields or test_field or test_field_ref

Environment

taxonomy_node

environment or taxonomy or taxonomy_ref

Automated run

run_automated

test_runs or test_run

Build

ci_build

build_name

CI server

ci_server

server_id

Build job

ci_job

job_name

Back to top

Report the tests and test runs

Verify that the payload is defined according to these guidelines.

For details on the elements, see test_run element.

Back to top

Set test characteristics and each report's context globally

If the set of tests included in the report share the same characteristics and context, you can specify those globally for all the tests in the report.

Set test characteristics and each report's context individually

If the test report contains tests with different characteristics or context, you can specify it per test. To do this, use the same elements as you would use for setting the context per report.

Resolve conflicts

Context elements might be set both per report and per test, causing conflicts. To handle these conflicts, see Resolving conflicts between per-report and per-test configuration.

Back to top

POST the test results

Set the Content-Type header field set to application/xml. Make sure that the XML payload containing the test results conform to the XSD schema as described above.

POST .../api/shared_spaces/<shared_space_id>/workspaces/1002/test-results

By default, errors that occur while pushing the test results are not ignored and the POST fails. To skip the errors, specify the skip-errors parameter:

POST .../api/shared_spaces/<shared_space_id>/workspaces/1002/test-results?skip-errors=true

For details on this parameter, see skip-errors.

Note: You can also use the POST request to update test run results. To update test run results, send another POST request with a unique module, package, class, and name. If a matching test run exists, its data is updated (such as status, starting time, and duration) and new test run results are not created.

Back to top

Check status and results

Back to top

See also: