Running tests

To check how the application or the system responds, you can run the recorded tests. Test scripts and their dependent assets are stored in a Git repository. HCL OneTest™ Server connects to the Git repository to display the test scripts on the Execute page.

Before you begin

You must have completed the following tasks:

  • Be assigned the Tester or Project Owner role to run the tests.
  • Confirmed with your Administrator that the appropriate license parameters point to the license server during the software installation process.
  • As the Project Owner, connected to the appropriate folder and branch of the Git repository to view test assets on the Execute page.

About this task

The following table lists the supported and not supported tests run from HCL OneTest Server:
Product Supported test runs Not supported test runs
HCL OneTest Performance VU Schedule, Rate Schedule, Compound test A single test script of any test extension.

Tests that belong to 32-bit test extensions and SOA Quality included in VU Schedule, Rate Schedule, and Compound Test.

HCL OneTest UI Accelerated Functional Testing (AFT) suite or Compound test with only Web UI tests Tests that belong to the Functional Test perspective.

An independent Web UI test and a mobile test outside of a compound test or AFT suite.

HCL OneTest API Test suite Test suites that have scenarios with references satisfied by local stubs.

Test suites that have tests with subscribe actions that operate in the watch mode.

A stand-alone API test case cannot be run independently. An API test case must be part of a Test suite.

Note: All the supported test types can be run only on the Mozilla Firefox browser.
HCL OneTest API suites might reference local stubs and depend on user libraries of the target transport. If you have such suites, you must have completed the following tasks before you can execute them:
  • Removed local stubs or published them to HCL Quality Server for API test suites. To change the stub reference from local to remote, see Publishing stubs and Scenario reference settings.
  • Copied the library files (JAR files) of one or more transports to a directory under UserLibs on HCL OneTest Server for API test suites. For example /myFiles/Userlibs/<userlibraryname> where <userlibraryname> is either blank or one of the following names:


    Directory under UserLibs to which third-party library files must be copied.

    File Not applicable
    FIX Not applicable
    HTTP Not applicable
    MQTT Not applicable
    RabbitMQ Not applicable
    Software AG webMethods Integration Server webMethods
    TIBCO Rendezvous TIBCO
    TIBCO SmartSockets TIBCO
    WebSphere Application Server 
Service Integration Bus (SiBus) WAS
    WebSphere MQ WMQ
    Database JDBC
After copying the user libraries, you must run the following Docker command to create or update the volume that contains the library files to be used by HCL OneTest Server.
Attention: You must run the following Docker command when no tests are running to prevent concurrent access problems:
docker run --rm -v /<anyFolder>/UserLibs:/ulsrc -v userlibs:/uldest alpine:latest cp -r /ulsrc/.  /uldest/UserLibs

See Docker command for more information about Docker run commands.

For example, the following command creates or updates the userlibs volume from files and directories under /opt/myFiles/UserLibs.
docker run --rm -v /opt/myFiles/UserLibs:/ulsrc -v userlibs:/uldest alpine:latest cp -r /ulsrc/.  /uldest/UserLibs
Remember: When you are using a transport with the host name set to localhost for the HTTP/TCP proxy, you must replace the host name with fully-qualified-domain-name or IPAddress of the proxy host.
To run JMeter tests as part of the VU Schedule or Rate Schedule from the server, you must have installed the JMeter application on the computers that have HCL OneTest Performance Agent and set the environment variable JMETER_HOME pointing to the JMeter installation directory.

If there is a long list of test assets and you want to view the tests by the type or by last results, you can filter the list by creating various queries.


  1. Initiate the test run on the Execution page. If the tests are already associated with an environment, dataset, or variables in the desktop client, you can choose to configure these options when running the test from the server.
    Note: The changes that you make in the Execution dialog box for the test run are preserved when you run the same test again. Those changes are not visible when another user logs in to HCL OneTest Server. For example, if you created new variables on the server, those variables are available only for you when the same test is run again.
  2. Create or pick a label for the test run to identify the run. After the run completes, the label is displayed against the run on the Results page. The label, once created, can be used by all the members of the project.
  3. Select secrets to be used for the test run. The ENVIRONMENT tab is applicable only for the API test suites. The environment asset (.ghe) was created in the desktop client and added to the Git repository as part of the API test project.
    Note: Secrets are created by the project owner. You can select them in the ENVIRONMENT tab.
  4. Click the DATA SOURCES tab and select a dataset to override the dataset that was associated to the test in the desktop client. The dataset that you override should be compatible with the existing dataset. For example, if the existing data with the test uses columns such as 'Name', 'Age', and 'Gender', you can override it with a dataset that uses a superset with columns 'ID', 'Name', 'DOB', 'Address', and 'Gender'.
    Note: If the test contains an encrypted dataset, the Project Owner must classify it in the DATA SECURITY tab on the Project page before running the test.
  5. Optionally, click the Variables tab and create new variables to override them on the server. Choose one of the following ways to override the variables:
    • To add new variables manually, click the Add icon Add icon.
    • To add new variables from your local computer or from the Git repository that is associated with your server project, click the Upload icon Upload and select Upload from local system or Browse from Server.
  6. Optionally, click Advanced Settings to make the following advanced modifications for the test run:
    1. Enter any Java arguments to pass to the execution runtime. For example, you can set a maximum Java heap size.
    2. Enter program arguments that you want to pass to the execution runtime.
    3. Enter the environment variables to pass to the execution runtime. For example, third-party libraries used in test execution might refer to environment variables for configuration.
    Note: You can separate the arguments by a white space in the same line or start each argument on a new line.
  7. Run the test.
  8. To view the progress of the run, go to the Progress page. This page displays high-level progress of the test runs triggered by you. From this page, you can closely monitor the run of the Schedules, Compound Test, and AFT Suites, by clicking Monitor Test.
  9. After the run completes, the test report can be viewed from the Results page. You can also check the Execution Logs and Test Logs to understand how the test ran.

What to do next

You can view the verdict of the run. The verdicts are as follows: Pass, Fail, Inconclusive. Each verdict is indicated by a color. For example, Green indicates pass, Red indicates failure, and Blue indicates inconclusiveness.

You can monitor a test run, check the logs, and run tests on remote computers.

Monitoring a test run

Long-running tests require continuous monitoring so that they run as expected and provide correct results. Due to various reasons, sometimes the tests start failing but continue to run till it completes. In such cases, you might want to adopt different techniques such as changing the number of virtual users, changing the rate of the run, or changing the log level to achieve the desired results. You can also stop the test run.

About this task

You can monitor the run for VU Schedule, Rate Schedule, Compound Tests, and AFT Suites. For Compound Tests, the only action available is to stop the run.


  1. Start a test run from the Execution page.
  2. Go to the Progress page. When the status of the run changes to Running, from the Action column, click Monitor Test.
    Moniter test

    The Statistics report opens.

  3. From the Running menu, select an appropriate action.

Canceling a test run

At times after you initiated the test run, you realized that you did not configure all the settings for a test or you want to change a few settings for the test, you might want to cancel the test run.

Before you begin

You must have initiated or scheduled a test run from the Execution page.

About this task

You can cancel the run if you are the one who initiated or scheduled a test run. The option to cancel the test is not available to other users if they did not initiate or schedule the run. You can cancel a scheduled or running test that you initiated from the Execution page by using the Cancel icon Image of the cancel icon available on the Progress page. You cannot cancel the test run if the test has already completed its run.


  1. Go to the Progress page and identify the test that you want to cancel.
    Note: You can cancel a running test if it is in the In Transition or Running state.
  2. Click the Cancel icon Image of the cancel icon in the Action column of the selected test.

    The Cancel test execution dialog box is displayed.

  3. Click Yes.

    A notification message is displayed for the canceled test run.


You have successfully canceled a running or scheduled test. The canceled test runs are not displayed on the Results page and are not considered in the count of tests executed displayed on the Overview page.

What to do next

You can re-initiate the test run from the Execution page by completing the configurations that you want for the test.

Checking logs

To verify how the test ran or to debug test run failure, you can check the Test Log and Execution Log.

About this task

The Test Log displays the interaction between the desktop client and the application or system under test. After the test run completes, the verdict of the run can be Pass, Fail, or Inconclusive. If the verdict of the run is Pass, the Test Log is available in the Results page.
Test Log

The Execution log displays the console message of the runtime process that runs the test. This log is useful in determining the cause of the failure if the verdict of the run is Fail or Inconclusive. You can view the Execution Log from the Progress page.