Use Jenkins to trigger tests from ALM
This topic describes how to run OpenText Functional Testing tests saved in ALM.
Define ALM credentials on the Jenkins server
Define the ALM credentials that Jenkins uses to connect to ALM when running OpenText Functional Testing tests saved in ALM.
This table describes where to define credentials, depending on the version of the OpenText Application Automation Tools plugin you are using:
Plugin version | ALM credentials |
---|---|
6.3 and earlier |
Enter the credentials in each job that runs OpenText Functional Testing tests from ALM. |
6.4 to 7.0 |
Define the ALM credentials globally on the Jenkins configuration page (Manage Jenkins > Configure System, Application Lifecycle Management section). You can define credentials for multiple ALM servers and for multiple users on the same ALM server. Define either usernames and passwords or client IDs and API key secrets, depending on the ALM server requirements. Then, in a job that runs OpenText Functional Testing tests from ALM, select from the configured ALM usernames or ALM Client IDs as necessary. |
7.1 and later |
Select one of the following credential handling modes from the Credential Scope drop down.
Note: If you upgrade to Application Automation Tools plugin version 7.1 or later, for any jobs you previously configured, the System (global) credentials mode is used by default. |
If you defined ALM credentials within your jobs, and subsequently upgraded to an Application Automation Tools plugin version between 6.4 and 7.0:
-
You cannot edit the credentials within the jobs but Jenkins continues to use them when running the job.
-
You can automatically move ALM credentials defined in existing Jenkins jobs to the Jenkins global configuration area:
Create and run a Jenkins job with the post-build action Migrate ALM Credentials. The first run of this job migrates the ALM credentials from all jobs to the Jenkins configuration page. Subsequent runs do nothing.
Run OpenText Functional Testing tests from ALM test sets
Use Jenkins to run server-side and unattended functional tests from test sets in ALM. ALM test sets enable you to organize test execution in the ALM Test Lab module according to specific testing goals.
Note: Parallel testing is not supported for running tests from ALM.
For details, see the ALM Help Center.
To configure a Jenkins build step to trigger a test set run from ALM
-
In the Jenkins job, scroll down to the Build section, click Add build step, and select Execute functional tests from OpenText ALM for a freestyle project.
Note: For a pipeline, in the Pipeline Syntax page, select runFromAlmBuilder from Sample Step drop-down, generate the script, and copy the script to the pipeline script box.
-
Select one of the configured ALM servers and enter the server credentials, project, and domain.
Depending on the authentication type required by your ALM server, credentials can either be a username and password or an API key for SSO authentication.
To use SSO authentication, select the SSO enabled and enter the Client ID and API key secret obtained from your ALM site administrator.
For more details, see Define ALM credentials on the Jenkins server.
Note: If you are using the ALM scheduler, it will run under the Jenkins agent user.
For example, if Jenkins is running as a System user, the scheduler will run the tests as a System user. This does not affect test execution.
-
Add the test set folders, or the specific test sets that you want to include, using the ALM path.
-
To add a specific test, add the test name after the test set path.
-
To add multiple entries, click the down arrow on the right of the field, and enter each item on a separate line.
For example:
Root\testfolder1\testset_a
Root\testfolder1\testset_b
Root\testlab_folder
Root\testlab_folder\testset_a\test-name
-
-
(Optional) Specify test parameters to use in one of the following ways:
Specify test parameters in Test sets areaIn the Test sets area, use the following syntax:
<test or test set path> "<parameter name>":"<string value>", "<parameter name>": <number value>
Where:
-
<test or test set path> is the path to the test or test set.
If you specify a test, the specified parameters are used for that test only.
If you specify a test set, the specified parameters are used for all of the tests in that test set. When the test set runs, each test uses the parameters it requires and ignores any others.
-
<parameter name> is the name of your test parameter
-
<string value> is a string value for your parameter, in quotes
-
<number value> is a number value for your parameter, without quotes
For example:
TestSet\ "Country":"US", "Count": 3
TestSet2\ "Country":"UK"
TestFolder\Test1 "Country":"China", "Count": 4
Specify test parameters in a tableSupported on Application Automation Tools plugin version 7.3 and later
-
Select Specify test parameters.
-
In the parameter table, specify the test number and the name, value, and type of a parameter.
The test number indicates the 1-based order of tests defined in the Test sets area. After you define the test number, the test path is automatically filled in read-only mode.
Specify the parameter name as defined in OpenText Functional Testing.
-
Click + PARAMETER to add more parameters to the table.
Note:
-
We recommend specifying test parameters in the table instead of specifying them in the Test sets box. The first method, which lets you provide only string or number parameter values, is supported for backward compatibility only.
-
Make sure that the parameter types you configured are correct. Otherwise, the test run may fail with the error status due to a parameter type mismatch.
-
Specify values for all test parameters required by your tests, or make sure that the parameters have default values defined in OpenText Functional Testing or ALM.
-
OpenText Application Automation Tools plugin version 7.6 and later: You can define a GUI test parameter of type Password in the table. For information on how to encrypt the values of Password parameters in the test run results, see Encode passwords in test run results.
-
-
(Optional) Indicate a timeout, in seconds, after which the job will fail.
-
(Optional) Set up a filter for your ALM test set, instructing Jenkins to run only part of the test in the test set.
Select Filter ALM test sets, and filter the tests to run by name or status or both:
-
In Run tests with names containing, specify a string to find within the test names.
- In Run tests with status, specify the statuses of the tests you want to run. For example, if you don't want to rerun tests that already passed, don't select the Passed status.
-
-
Click Advanced to indicate a Run mode, such as local, remote, or planned host.
Note:
-
If you specify a remote host mode, also specify a host name. This must be a machine with a valid OpenText Functional Testing installation.
You can configure the OpenText Functional Testing machine so that Jenkins can run tests without anyone manually logging in to the machine and starting OpenText Functional Testing. For details, see Running OpenText Functional Testing and OpenText Functional Testing tests in a remote session.
-
We recommend that you run functional test sets from ALM Lab Management. The following limitations exist when running them from ALM:
-
Functional test sets are not supported to run on a planned host.
-
You can only get run results of each test when running functional test sets on a local or remote host.
-
-
-
Click Apply to save your changes and continue with more build steps. Click Save when you are finished adding build steps.
-
In the Post-build Actions section, click Add post-build action and select Publish OpenText test result for the freestyle project.
Note: For a pipeline, in the Pipeline Syntax page, select publishMicroFocusTestResults from Sample Step drop-down, generate the script, and copy the script to the pipeline script box.
-
Run or schedule the job as you would with any standard Jenkins job.
To review the test run results from ALM
- From the dashboard, click on the job.
- Click the Console link to view the ALM information.
- Copy the ALM link to your browser and view the Test Set Run results from within ALM.
See also: