User Guide Integration with third-party tools Zephyr integration Features of TestArchitect-Zephyr integration

 Executing tests from Zephyr

Executing tests from Zephyr

As an alternative to executing tests from TestArchitect, TestArchitect test cases and test modules may be executed from Zephyr.

• 6.2
  • Zephyr Cloud
  • TestArchitect 8.4 Update 4 & 5

Ensure that you have already taken the following steps:

• Registered the Zephyr server with TestArchitect.
• Mapped the TestArchitect project containing the test cases of interest to a Zephyr project.
• Installed the ZBot agent and launched it.

To run automated tests from Zephyr, do as follows:

1. Start Zbot.

2. In Zephyr’s left tool dock, click Test Execution.

3. In the Test Execution tree, select the folder containing the test cases to be executed.

4. In the list view of test cases, select the check boxes corresponding to the desired test cases. Next, click the button next to Execution.
   
   

5. In the Execute Automation Scripts dialog box, from the Select ZBot dropdown list select the machine whose ZBot will run the automation scripts. Next, click the Run button.
   
   

   Zephyr connects to the TestArchitect engine in order to carry out the tests. Then the TestArchitect Execution dialog box is launched.
   
   

6. In the dialog box, enter the requested information as described below:

   1. TestArchitect Information panel:
      
      

      • Repository Server: Name or IP address of TestArchitect Repository Server holding the repository of the tests.
      • Port: Port number of the TestArchitect Repository Server host.
      • Repository Name: Name of TestArchitect repository hosting the tests.
      • User Name: TestArchitect user name whose account has permission to access and execute tests on the host.
      • Password: Password for the above user account.

   2. General tab:
      
      

      1. Automation Tools panel:
         
         

         Click the Automation Tools button to set the automation tools (see Lesson #8: Using an automation harness).
         
         

         The following settings are available for automation tools:

         • Playback Tool: Select the automation playback tool.
         • Executable(s): Path to the automation playback tool executable file.
         • Script(s): Path to the automation script folder.
         • Command Line: Add any command line switches you may wish to include to control the third-party tool.

      2. Controllers/Devices panel:
         
         

         • Select Controllers/Devices: Click this button to designate which controller and device the test will execute on.
           
           

           1. Lab Manager Server panel: (Display only) IP and port number of the Lab Manager Server to which the test controllers and devices are registered.

           2. Controllers/Devices panel: Lists all available controllers and cloud/physical mobile devices on which the test can be executed. The list consists of those controllers and devices that are either registered with the Lab Manager Server or have been manually added with the Add Controller or Add desired capabilities files button.

              Tip:
              To select multiple cloud devices to be executed at launch time, see the following topics.
              • WebDriver based cloud services (Appium enabled).
              • In Remote TestKit service
                • Chrome Android
                • Safari iOS

           3. Controller Port Configuration: Use this panel to specify to TestArchitect the port number that the remote machine is using for its TestArchitect Controller, if not using the default.

              • IP/Server Name: (Display only) IP address of remote machine currently selected in the Controllers/Devices panel.
              • Port: Port number through which TestArchitect will attempt to communicate with the controller on the host specified in the IP/Server Name field. If this is not the port on which the controller is known to be listening, change this value and then click Save .
         Restriction:
         Only one controller or one physical mobile device may be selected to run tests at a time. In other words, multiple controller/physical mobile device execution is prohibited.

      3. Variation Specification panel:
         
         

         1. Keyword: Keyword, or comma-delimited list of keywords, specifying the test variation to be executed, if any. (See Creating keyword variations.)
         2. AUT Version: Enter a value or click the Select Version button to specify a variation tailored to an AUT version or platform (See Creating linked variations.)
         3. Time Traveling: To opt for time traveling execution, which selects a historical “snapshot” of the test’s project items for execution during the test run, select the check box and provide an appropriate timestamp. (See Time Traveling for details.)

   3. Advanced tab:
      
      

      1. Export Result(s) to TARESULT: Select this check box to export TA results as .TARESULT files.

         Note:
         .TARESULT is an archive extension, developed by LogiGear.
         
         
         • Include screenshots: Include all captured screenshots in the exported test result.
         • Include all sub test results: If the exported test result is a master result, meaning it is a test suite result, or it contains subresults, the Include all sub test results check box is available. With this option chosen, the master result and its subresults are all exported into .TARESULT format.

      2. Export Result(s) to HTML: Export test results to HTML file automatically once the text execution is complete (learn more).
         
         

         • Create folder structure: Select whether the folder structure or flat structure directory is created to store HTML results.
           • Folder structure (the Create folder structure check box is enabled): TestArchitect creates a hierarchical tree structure, or subdirectories to store HTML results.
           • Flat structure (the Create folder structure check box is cleared): TestArchitect does not create subdirectories. There is only a single top-level directory that contains all HTML results.
         • Include all sub test results: If the exported test result is a master result, that is, it is a test suite result or it contains subresults, the Include all sub test results check box is available. With this option chosen, the master result and its subresults are all exported into HTML files.
         • Apply customized XSLT template: Export HTML results with your own view layout.
         • Include screenshots: Retain all captured screenshots in the exported HTML test result.
           • Optimized resolution: Included screenshot’s dimensions are optimized to save space in the exported HTML test results. Specifically, the screenshots are saved as thumbnail images.
           • Regular resolution: Original resolution of included screenshots is retained. Specifically, the screenshots are saved as full size images.

      3. Export result(s) to xUnit: Export test results to a XML file automatically in xUnit-format for integrating into the continuous integration tools once the text execution is complete.
         
         

      4. Export result(s) to XML detail: Export test results to XML file automatically once the text execution is complete (see Exporting test results to XML for more details).
         
         

      5. Automatically add result(s) to repository: Select this check box if you want to add test results automatically to the repository once the test concludes.
         
         

         • Repository destination: Add test results to the repository at the specified location.
         • By result: Limit the results stored to the repository in accordance with the following check box selections:
           • Passed: Passed test results are stored.
           • Passed with Warnings/Errors: Passed test results with warnings/errors status are stored.
           • Passed with known bug: Test results that passed, but are marked known bugs whose outcomes have been ignored, are stored.
           • Failed: Failed test results are stored.
           • Not Finished: Incomplete test results.

   4. Startup Settings tab:
      
      

      • Startup Settings: Select this check box to enable user-defined settings and/or reconfigured built-in settings to be loaded at the startup of test automation.

7. Click Run to execute the tests.

   Note:
   On each subsequent test run, the information you provide is retained and automatically populates the TestArchitect Execution dialog box.
   Important:
   If you are executing tests for the first time, you are prompted to enter your TestArchitect license server information. Enter the required information in the dialog box. If the specified license server is reached successfully, or the trial key is validated, the provided license information is stored. From then on, you will be able to execute tests without being prompted for this information again.
   
   

TestArchitect executes the test, and the test results are uploaded to Zephyr as ZIP files for the associated Zephyr test cases.

• When running an automated test, the execution of every single Zephyr test case entails the execution of the INITIAL section, if any. However, the execution of the last Zephyr test case entails the execution of both the INITIAL and FINAL sections. For example, execution of test case 01 (the first in the sequence) starts off with execution of the INITIAL section; the same is true for each subsequent test case, including test case 05, the last one. Note, however, that only test case 05 concludes with execution of the FINAL section.
• If, in the TestArchitect Execution dialog box, you specify a non-default test variation (using the Keyword and/or AUT version boxes), the results of the variation’s test run are uploaded as follows:
  • if the variation has been mapped with Zephyr: the results are uploaded to the correct mapped variation.
  • if the variation has not been mapped with Zephyr: the results are uploaded to the default test.