Versions Compared

Old Version 5

changes.mady.by.user Robert Andelin

Saved on

compared with

New Version Current

changes.mady.by.user Chieko Sugizaki

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from space DTPDEVEL and version 2022.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 (i.e., 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>&testCaseSetId=<Azure DevOps_TEST_CASE_SET_ID>"

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

    The following table describes the endpoint parameters.

    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
    testCaseSetId
    		ID of set of test cases

    Specifies the ID of a test case set in Azure DevOps where Parasoft DTP should create new test case definitions, if not found in Azure DevOps. When a test case definition is found in Azure DevOps, whether in this testCaseSetId or another, it is just updated and not moved to this specific test case set. 

    The value for the testCaseSetID parameter should be an ID for a "Set of Test Cases" item type in Azure DevOps (see Requirements). You must use the ID from Azure DevOps URL and not the ID generated in the UI. You can get the ID from the URL after clicking on the test cases node in the project tree.


    		Optional

    The set of test cases is the item where DTP can create new test cases as necessary. DTP will create new test cases when it sends results to Azure DevOps Connect if equivalent test cases do not exist, as described in the next step. 

    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=abcdefencrypted_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=ghijklencrypted_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-sync.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. 

...