This is the name of your Test Project in TestLink. You can use environment variables in this field.
This is the name of your Test Plan in TestLink. You can use environment variables in this field.
This is the name of your Build in TestLink. You can use environment variables in this field.
On setting the build name you should wisely choose and review the underlying concept and workflow inside your testing process. Mind that in previous chapter it is mentioned that creating a build in TestLink is optional, as the plug-in automatically creates a new build if there is none with the name that you provided in the Jenkins job configuration page.
Unfortunately TestLink is been reported to slow down enormously and to be unresponsive on a project's TestLink own web interface on high amount of TestLink builds being in status open.
Thus if using environment variables in this build name field of Jenkins that might change their value often (like Jenkins' build number, current time or date) an increasing number of TestLink Builds will be created with correlated frequency accordingly inside TestLink then.
As a first recommendation your process should assure that the amount of open builds in TestLink is limited in an acceptable range. Even if this might mean to manually close builds in TestLink. Mind that especially in huge testing projects this means that this type of strategy does not scale. Another recommendation could be to simply avoid or at least reduce any usage of frequently changing environment variables in that place thus avoiding all or most new creation of open builds.
These Build Steps are executed iteratively for each test case retrieved from TestLink. For these Build Steps, a set of environment variables are available. We will discuss more about them soon.
This is the Result Seeking Strategy chosen to seek and update test results in TestLink.
The plug-in uses this pattern to find test results of your tests execution (single test command or iterative). It supports Ant-like expressions like TEST*.xml or target/**/testng*.xml.
This is the custom field used by the plug-in to link a test case in TestLink with your test results. This custom field must exist in the list of custom fields.
If this option is checked the plug-in will attach the TestNG XML file to TestLink execution. This way you can open the XML in TestLink.
By default, in TestNG, skipped tests are not updated in TestLink. It means that they appear as Not Run in TestLink. If this option is checked, the plug-in updates the test case in TestLink as Blocked.
The plug-in retrieves all the information from TestLink for your Test Project, Test Plan, Build and automated Test Cases. You can then use any of this information to execute your tests. Jenkins itself provides the Environment Variables, plus Build Environment Variables (such as BUILD_ID, which holds the date time of your job).
The plug-in injects the information retrieved from TestLink as extra environment variables. This way you can use the value of the Java class custom field value that you created in Chapter 4, TestLink Configuration in any of your iterative Build Steps. Below you can find an example of how to execute a single test with Maven and one of these environment variables.
mvn test -Dtest=$TESTLINK_TESTCASE_JAVA_CLASS
As you can see, our test command uses the Java class custom field value to specify the name of the test to Maven (Maven Surefire Plug-in, actually). Below you will find a list with the information that the plug-in makes available for your job configuration. As custom fields names may vary, the strategy used is capitalize the custom field name, replace spaces with _ and append it to TESTLINK_TESTCASE_, which represents information of a Test Case in TestLink.
TESTLINK_TESTCASE_ID
TESTLINK_TESTCASE_NAME
TESTLINK_TESTCASE_TESTPROJECTID
TESTLINK_TESTCASE_AUTHOR
TESTLINK_TESTCASE_SUMMARY
TESTLINK_BUILD_NAME
TESTLINK_TESTPLAN_NAME
TESTLINK_TESTCASE_$CUSTOM_FIELD_NAME