Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from space DTPDEVEL and version 2024.2

...

  1. Create requirements in Azure DevOps that you can associate with tests executed by Parasoft tools. 
  2. In your test file, map the Azure DevOps Connect system requirement IDs to the tests using the following annotation format:
    For users who have not created their own test case definition to see traceability results in Azure DevOps, use @req:

    * The following annotation maps the test to a requirement:
    * @req <<Azure DevOps ID>
    @TEST
    ...

    Use @req in Parasoft and trigger sending results from Parasoft DTP to Azure DevOps.

    For users who have created their own test case definition in Azure DevOps, use @test:

    * The following annotation maps the test to a requirement:
    * @test <<Azure DevOps ID>
    @TEST
    ...

    Associate each test case definition with your tested requirement in Azure DevOps.

    • Use the @test <Azure DevOps ID> annotation to associate tests with test definitions in Azure DevOps. When using @test make sure that you have no test case steps defined in the tests whose run statuses you plan to send from Parasoft DTP to Azure DevOps. Parasoft DTP is not able to update test case runs for test cases that have steps defined.

    • Use the @req <Azure DevOps ID> annotation to associate tests with stories in Azure DevOps. When using @req make sure the following relation type is defined in the Azure DevOps project you plan to send results to: "verified by". Such relation is needed by Parasoft DTP when it creates a test case in Azure DevOps and relates it to a requirement in Azure DevOps.

      Annotating tests links them to entities in Azure DevOps Connect so that they can be visualized in DTP reports. The annotation is added to the unit test file for Parasoft language tools (C/C++test, dotTEST, Jtest). For functional tests executed with SOAtest, the annotation is added to the .tst file. Refer to your Parasoft tool documentation for details on adding annotations. You must use the ID from Azure DevOps Connect URL and not the ID generated in the UI:


  3. Execute your tests as part of the CI process. You can also manually execute the tests from the IDE.
  4. As part of the test execution, Parasoft test execution tools will tag the results with the filter and build IDs and send the data to DTP. You can verify the results in DTP by adding Test Widgets to your DTP dashboard and setting the filter and build ID. Developers can download the test execution data from DTP into their IDEs so that they can address any failed tests.
  5. If you deployed the Sending Test Data to External System flow (see Deploying the Sending Test Data to External System Flow), then unit and functional testing results will automatically be sent to Azure DevOps Connect when Data Collector receives the data from the Parasoft tool. By default, the flow forwards unit and functional test results that were received by Data Collector for any project, but you can configure the flow to only send data for a specific project (see Sending Results from a Specific DTP Project). 
    You can also manually s
    end a POST request to the DTP REST API endpoint to send results from the DTP database to Azure DevOps Connect. Pass the IDs for the DTP filter and build, as well as the ID for a set of Azure DevOps test cases, as URL parameters in the API call:

    No Format
    curl -X POST -u <username>:<password> "http://<host>:<port>/grs/api/v1.7/linkedApps/configurations/1/syncTestCases?filterId=<filterID>&buildId=<buildID>

    The filter and build IDs are available in the Test Explorer URL:

    The following table describes the endpoint parameters.

    Scroll Table Layout
    orientationdefault
    sortDirectionASC
    tableFitdefault
    repeatTableHeadersdefault
    widths35%,15%,35%,15%
    sortByColumn1
    tableStylingconfluence
    sortEnabledfalse
    cellHighlightingtrue

    ParameterValueDescriptionRequired
    filterId integerSpecifies the filter ID containing the test data. The filter ID is an integer value and should not be confused with the filter name.Required
    buildId stringSpecifies the build ID containing the test data.Required
    groupResultsBySOAtestTST 
     
    boolean

    Setting to true groups SOAtest results by .tst file. As a result, one .tst file will be associated with one Azure DevOps test.

    Setting to false associates each test step within a SOAtest .tst with a Azure DevOps test.

    Default is false 

    Optional
    testPlanIdinteger

    Specifies the test plan ID in Azure DevOps to which to send the results. DTP will generate a test suite in the format of "Results from Parasoft DTP - <DTP_PROJECT_NAME>" in the specified test plan. Test cases to be synced will be copied into this test suite and their test points will be run. If the test suite was generated previously, then it is re-used in future syncTestCases runs against the specified test plan. If this is not specified, DTP will generate a new Test Plan and sync the test case results into that Test Plan.

    Optional
    updateResultsOnlyboolean

    Specifies a syncing mode where test cases in a particular test plan will be updated in-place. If set to true, the testPlanId parameter must also be provided so that DTP can search in the correct test plan for which test cases to update. In this mode, the test case definitions to be updated must exist before running the sync operation. DTP will not create a new test suite, test plan, or test cases in this mode.

    Default is false

    Optional
    Info
    titleSupport for Multiple Azure DevOps Implementations

    If you are using the /syncTestCases REST API endpoint to synchronize test cases between DTP and Azure DevOps, you can configure DTP to distribute test data to different Azure DevOps implementations. The functionality is only available using the API call.

    You can configure DTP to recognize as many Azure DevOps implementations as needed by adding them to the end of the ExternalSystemSettings.properties file located in the <DTP_DATA_DIR>/conf directory. Any time the API sends DTP data to Azure DevOps and does not find a match in ExternalSystemSettings.properties, it will send the data to the Azure DevOps configuration you set up in the UI in Connecting DTP to Azure DevOps instead. Add Azure DevOps configurations to the ExternalSystemSettings.properties file in a format that mirrors the example below:

    No Format
    azuredevops.config1.appUrl=http://azure.test1:8888/organization1
    azuredevops.config1.displayUrl=http://azure.test1:8888/organization1
    azuredevops.config1.username=john
    azuredevops.config1.apiToken=encrypted_token
    azuredevops.config1.project1.dtpProject=bank
    azuredevops.config1.project1.externalProject=Bank
    azuredevops.config1.project2.dtpProject=atm-core
    azuredevops.config1.project2.externalProject=Atm 

    This configuration"config1"will cause data from the DTP project "bank" to be sent to the external project called "Bank" on the server http://azure.test1:8888/organization1, which is will access using the API token "abcdef." The DTP project and external project are linked by virtue of both belonging to "project1" and the appropriate server and login credentials are known because all of them belong to "config1."

    Understanding this, you can use the example above as a template to define additional configurations for your other Azure DevOps implementations. Each configuration must have a unique "azuredevops.config#" value. For example, using the configuration shown above as a base, a second configuration might look something like this:

    No Format
    azuredevops.config2.appUrl=http://azure.test2:8888/organization1
    azuredevops.config2.displayUrl=http://azure.test2:8888/organization1
    azuredevops.config2.username=jane
    azuredevops.config2.apiToken=encrypted_token
    azuredevops.config2.project1.dtpProject=foo
    azuredevops.config2.project1.externalProject=bar

    You can set up as many configurations as you need. Some things to keep in mind:

    • The "project#.dtpProject=" and "project#.externalProject=" pairs in these examples show how you can associate a DTP project to an external project. Multiple associations are allowed, but a "dtpProject" is expected to be unique across all configurations.
    • The current External System configuration as configured in the Report Center settings UI must be configured to "Azure DevOps."
    • All additional Azure DevOps configurations in the ExternalSystemSettings.properties configuration file must be valid.
    • The "apiToken" property for each configuration must be encrypted or else the configuration is deemed invalid. To encrypt this value, use the -encodepass CLI option included with any Parasoft tool (for example, soatestcli.exe -encodepass <API TOKEN>).
    • Traceability Widgets and reports will only show the primary ADO (that is, the one defined in the UI).
    • Requirements from multiple ADOs cannot be imported into SOAtest.

    The API call will determine which configuration to use based on the filterId that is passed to it (see the table above that describes the endpoint parameters). DTP will look up the project associated with that filter and find a configuration that specifies that DTP project. The first match is used. If no matches are found, the default configuration is used.

  6. DTP will locate the test results that match the filterId and buildId parameters and send the data to the Azure DevOps Connect system requirements.
    • When DTP locates results with an @req <ID>, it will search for a matching item in Azure DevOps. If a match is found, test results will be added to the test cases associated with the item. If there are no test cases for the requirement ID, then test cases will be created and test runs will be added to them.
    • An external-app.log file will also be written to the the <DTP_INSTALL>/logs directory. This log file contains progress information about sending test results from DTP to Azure DevOps. 

...