The Variables feature allows you to define variables, assign values to them, and reuse them in functional test cases.

A variable consists of a name and a value. You can use it in free-text fields when creating test cases in functional testing, for example:

• A test request's URL,
• Request headers,
• Conditions,
• POST request body or payload.

A variable can be reused within a single test suite and is defined at the test suite level.

Assigning values to variables

There are two ways you can assign a value to a variable: statically and dynamically.

Static assignment

With static assignment, you create a variable with a specific value and reuse the variable within a test suite. When needed, it’s enough to edit the variable’s value in one place and automatically it’s applied to all variable’s uses in the test suite. In UI, you can see in how many places each variable is used. We recommend you check the variable’s uses before editing it, to make sure the edit works for all test cases.

How to - API:

1. Create a variable.
2. Update a test suite with child objects and refer to the variable by providing its name in {{ }}.

Dynamic assignment

Dynamic assignment of variable values is designed for writing a test case that requires Test Center to extract a piece of information from a response in real time during the test run and use it in subsequent test cases, for example session cookie from a login page. Note that the same variable can get assigned a value more than once, by different test cases, during the course of a test run. In the API, you can check the resolved value for a variable in the resolvedSetVariables object for each test case.

Dynamically assigned variables work only in stateful test suites.

How to - API:

1. Create a variable. You can create a variable with a name, or, if you want to dynamically assign a value to it, leave the value empty.
2. Update a test suite with child objects and use the setVariables array to assign one of the available functions to the variable.

How to - UI:

1. Open the Variables tab in the Create and add test cases window for a stateful test suite. To learn more, see create and manage variables.
2. Expand the Dynamically overwrite variable value section
   1. In the Variables name field, enter or select a name of a variable already created. If you don't have a variable created yet, see create and manage variables to learn how to do it.
   2. In the New value field, enter the new value you want to assign to the provided variable name. Use available functions for this.
3. To check how functions work or to test your new value, click Check how functions work. This opens the Functions tab on the right.
   1. Click Try it next to a function of interest.
   2. Specify the parameters.
   3. Enter data sample to run the function on. If you don't have any samples, click Enter an example to get a default example.
   4. Click Submit.

Available functions

To extract the value from the test case response and assign it to a variable dynamically, you need to use functions. There are three functions you can use:

• fn_getResponseCode() — Extracts a response status code from a test case response.
• fn_getResponseHeaderValue(<headerName>, <regex>) – Extracts a value of a response header and applies specific regex, if provided.
  • headerName - mandatory parameter,
  • regex - optional parameter,
  • examples: fn_getResponseHeaderValue(Location, .*), fn_getResponseHeaderValue(Location)
• fn_getCookie(<name>, <field>, <regex>) – Looks for the Set-Cookie response header with a specific name, extracts associated field value, and applies specific regex, if provided.
  • name - mandatory parameter,
  • field - mandatory parameter (possible values are: value, expires, secure, domain and path). If a secure field is given, the function results in on or off if the secure field is present/not present in Set-Cookie.
  • regex - optional parameter.
  • examples: fn_getCookie(test, value, .*), fn_getCookie(test, path)
• fn_getMetadataVariable(variable_name, regex) - Extracts a variable value for a given variable name and applies specific regex, if provided in theX-Akamai-Session-Info response headers.
  • variable_name - mandatory parameter,
  • regex - optional parameter.
  • example: fn_getMetadataVariable(AKA_PM_RUM_RATE), where AKA_PM_RUM_RATE is the variable name returned by the X-Akamai-Session-Info response header.

📘

Supported regex

Test Center supports JAVA-based regex patterns.

Example 1

This example shows how dynamically assigned variables work for pages behind login with the help of fn_getResponseHeaderValue() dynamic variable function.

Login behind page scenario use case:

• Log in to an application.
• As a login response, receive a token-extract in the response header.
• This token-extract can be used in the subsequent test cases to access the post login API end-points of an application by using the token-extract as a Bearer Authentication token.

At the level of a test suite we have one variable defined:

Test case 1:

{
  "testRequest": {
    "testRequestUrl": "http://test.akaorigin.com/rest/user/login/",
    "requestMethod": "POST",
    "requestBody": "{\"email\":\"test@akamai.com\",\"password\":\"Test\"}",
    "encodeRequestBody": false,
    "requestHeaders": [
      {
        "headerName": "Content-Type",
        "headerValue": "application/json",
        "headerAction": "MODIFY"
      }
    ]
  },
  "clientProfile": {
    "clientType": "CURL",
    "ipVersion": "IPV4"
  },
  "condition": {
    "conditionExpression": "Response code is one of \"200\""
  },
  "setVariables": [
    {
      "variableId": 118575,
      "variableName": "tokenExtract",
      "variableValue": "fn_getResponseHeaderValue(token-extract)"
    }
  ]
}

With the above test case we:

• Log in to the Test application http://test.akaorigin.com/rest/user/login/ with set credentials.
• After logging in, use the function fn_getResponseHeaderValue(token-extract) to fetch the token-extract which can be used as a Bearer Authentication for the subsequent test case.

Test case 2:

{
  "testRequest": {
    "testRequestUrl": "http://test.akaorigin.com/api/Addresss",
    "requestMethod": "GET",
    "requestHeaders": [
      {
        "headerName": "Authorization",
        "headerValue": "Bearer {{tokenExtract}}",
        "headerAction": "ADD"
      }
    ]
  },
  "clientProfile": {
    "clientType": "CURL",
    "ipVersion": "IPV4"
  },
  "condition": {
    "conditionExpression": "Response code is one of \"200\""
  }
}

At the time of test run with the above test cases we:

• Capture the token-extract from the Test Case 1 response headers. The extracted token-extract is assigned to the tokenExtract variable.
• Use the tokenExtract variable in the requestHeders -> headerValue (Payload of test case 2).
• At the run time, the token-extract parsed from the Test Case 1 is used in the Test Case 2 requestHeders -> headerValue as an Authorization to achieve a successful end-to-end scenario.

The below shows the test run response of Test Case 1:

"testSuiteId": 647286,
  "testCaseExecutions": [
    {
      "testCaseId": 529825,
      "testCaseExecutionId": 604937,
      "status": "COMPLETED",
      "order": 1,
      "conditionEvaluationResult": {
        "result": "PASSED",
        "actualConditionData": [
          {
            "name": "Response code",
            "value": "200"
          }
        ]
      },
      "resolvedSetVariables": {
        "tokenExtract": "eyJ0eXAiOiJUzI1NiJ9.eyJzdGF0dXMiOiJzdWNjZXNzIiwiZGF0YSI6eyJpZCmVtYWlsIjoic2JtMUBha2FtYWkuY29tIiwicGFzc33NTRlNW0000000"
      },
      "completedDate": "2022-12-13T08:56:06+0000"
    }

As we can see, in the above test run response of the Test Case 1, the resolvedSetVariables object contains the extracted token.

The below shows the context test-run response for Test Case 2:

"testCaseId": 529827,
  "testRequest": {
    "testRequestUrl": "http://test.akaorigin.com/api/Addresss",
    "requestMethod": "GET",
    "requestHeaders": [
      {
        "headerName": "Authorization",
        "headerValue": "Bearer eyJ0eXAiOiJUzI1NiJ9.eyJzdGF0dXMiOiJzdWNjZXNzIiwiZGF0YSI6eyJpZCmVtYWlsIjoic2JtMUBha2FtYWkuY29tIiwicGFzc33NTRlNW0000000",
        "headerAction": "ADD"
      }
    ]
  },
  "clientProfile": {
    "clientType": "CURL",
    "ipVersion": "IPV4",
    "browser": {
      "name": "curl",
      "version": "98.0"
    },
    "geoLocation": "US"
  },
  "condition": {
    "conditionExpression": "Response code is one of \"200\""
  }

In the above test run context response of the Test Case 2, the resolved static variable value of tokenExtract (Which contains the token-extract updated from the setVariables of Test Case 1) got updated under the requestHeaders -> headerValue.

Example 2

This example shows how a user can validate that all the subsequent test case’s hostnames are hit with the same country region.

At the level of a test suite we have one variable defined:

Test case 1:

"testRequest": {
               "testRequestUrl": "https://www.example.com/",
               "requestMethod": "GET"
           },
           "clientProfile": {
               "clientType": "BROWSER",
               "ipVersion": "IPV4"
           },
           "condition": {
               "conditionExpression": "Response code is one of \"200\""
           },
           "setVariables": [
               {
                   "variableName": "expectedCountryRegion",
                   "variableValue": "fn_getCookie(country_region,value)"
               }
           ]

This test case:

• Hits a test request URL https://www.example.com/.
• Captures the country region from the Set-Cookie response header from the setVariable section and stores in the static variable expectedCountryRegion.

At this point, the variable expectedCountryRegion updated to:

Test case 2:

"testRequest": {
               "testRequestUrl": "https://www.example.com/offer/",
               "requestMethod": "GET"
           },
           "clientProfile": {
               "clientType": "BROWSER",
               "ipVersion": "IPV4"
           },
           "condition": {
               "conditionExpression": "Response header \"Set-Cookie\" has a value that contains \"country_region={{expectedCountryRegion}}\""
           }
       }

This test case:

• Hits another test request URL https://www.example.com/offer/,
• Resolves the variable expectedCountryRegion (dynamically resolved in the previous test case and stored statically) under condition evaluation.
• Validates that the second test request URL https://www.example.com/offer/ has the same country region as the previous test case.

This is the response for test case 1:

"testCaseId": 541132,
                       "testCaseExecutionId": 608086,
                       "status": "COMPLETED",
                       "order": 1,
                       "conditionEvaluationResult": {
                           "result": "PASSED",
                           "actualConditionData": [
                               {
                                   "name": "Response code",
                                   "value": "200"
                               }
                           ]
                       },
                       "resolvedSetVariables": {
                           "expectedCountryRegion": "CA"
                       },
                       "completedDate": "2022-12-23T07:09:02+0000"
                   }

We can observe from the above response that, the setVariable function fn_getCookie(country_codes, domain), has parsed the value as CA.

The below shows the context test-run response for test case 2:

{
                       "createdBy": "cmath",
                       "createdDate": "2022-12-23T07:13:20+0000",
                       "modifiedBy": "cmath",
                       "modifiedDate": "2022-12-23T07:13:20+0000",
                       "testCaseId": 541137,
                       "testRequest": {
                           "testRequestUrl": "https://www.example.com/offer/",
                           "requestMethod": "GET"
                       },
                       "clientProfile": {
                           "clientType": "BROWSER",
                           "ipVersion": "IPV4",
                           "browser": {
                               "name": "chrome",
                               "version": "98.0"
                           },
                           "geoLocation": "US"
                       },
                       "condition": {
                           "conditionExpression": "Response header \"Set-Cookie\" has a value that contains \"country_region=CA\""
                       },
                       "order": 2
                   }

You can see from this test run context response that the parsed value of country region CA is used in the condition evaluation and validating even the second test case’s test request URL is pointing to the same country region.

Variable groups

This feature is currently available only for API. The Variable group feature allows you to assign multiple values to a specific variable and refer to them in test cases. In test cases where a variable group is used, the test case acts as a template and at the time of test run, Test Center generates multiple test cases, called derived test cases. They are based on the values defined in the variable group.
This feature is useful if you want to, for example, add host keys with different source paths and iterate over the same host to add destination keys file or paths and create multiple test requests.

Example:

This example contains one variable assigned statically (1:1) and one variable group (1:2).

[
   {
      "variableName":"redirectCode",
      "variableValue":"301"
   },
   {
      "variableName":"redirect",
      "variableGroupValue":[
         {
            "columnHeader":"sourceUrl",
            "columnValues":[
               "https://www.example.com/",
               "https://www.example2.com/"
            ]
         },
         {
            "columnHeader":"redirectUrl",
            "columnValues":[
               "https://www.example.org/",
               "https://www.example2.org/"
            ]
         }
      ]
   }
]

Restrictions

• The columnHeader name must be unique within a variable.
• The variableGroupValue limit per array is 50.
• The columnValue limit for stateful test cases is 100.
• The columnValue limit for stateless test cases is 3000.
• The variable array can contain either variableValue or variableGroupValue.
• Group variables can’t be used in the dynamically assigned variables, that is in the setVariable array of test cases.

Referring a variable group in a test case

Variable groups are referred just like other variables, but with the dot notation: {variableName.columnHeader}}, for example: {{redirect.sourceUrl}}.

Example:
This is how a test case with group variables looks like:

{
   "testRequest":{
      "testRequestUrl":"{{redirect.sourceUrl}}",
      "requestMethod":"GET"
   },
   "condition":{
      "conditionExpression":"Redirect response code is one of \"{{redirectCode}}\" and location is \"{{redirect.redirectUrl}}/\""
   },
   "clientProfile":{
      "ipVersion":"IPV4",
      "client":"CHROME"
   }
}

Derived test cases and resolving variables

Derived test cases are test cases executable in a test run after resolving group and static variables. For one test case created by you using a group variable, Test Center creates multiple executable test cases. Their number depends on the number of columnValues for a columnHeader.

To see the derived test cases, GET them with the resolveVariables query parameter set to true.

Test case order

In stateful test suites you can configure the order of the test cases using the Reorder test cases in a test suite operation. Derived test cases for group variables are executed in the order the columnValues are added.

Example:

This is an example for GET /test-management/v3/test-suites/{testSuiteId}/test-cases?resolveVariables=true:

{
   "areAllTestCasesIncluded":true,
   "testCases":[
      {
         "createdBy":"atctest@akamai.com",
         "createdDate":"2023-04-26T07:04:25+0000",
         "modifiedBy":"test@akamai.com",
         "modifiedDate":"2023-04-26T07:04:25+0000",
         "testCaseId":12,
         "testRequest":{
            "testRequestUrl":"{{redirect.sourceUrl}}",
            "requestMethod":"GET"
         },
         "clientProfile":{
            "client":"CHROME",
            "ipVersion":"IPV4",
            "geoLocation":"US"
         },
         "condition":{
            "conditionExpression":"Redirect response code is one of \"{{redirectCode}}\" and location is \"{{redirect.redirectUrl}}/\""
         },
         "order":1,
         "derivedTestCases":[
            {
               "testRequest":{
                  "testRequestUrl":"https://www.example.com/",
                  "requestMethod":"GET"
               },
               "clientProfile":{
                  "client":"CHROME",
                  "ipVersion":"IPV4",
                  "geoLocation":"US"
               },
               "condition":{
                  "conditionExpression":"Redirect response code is one of \"301\" and location is \"https://www.example.org//\""
               },
               "order":1
            },
            {
               "testRequest":{
                  "testRequestUrl":"https://www.example2.com/",
                  "requestMethod":"GET"
               },
               "clientProfile":{
                  "client":"CHROME",
                  "ipVersion":"IPV4",
                  "geoLocation":"US"
               },
               "condition":{
                  "conditionExpression":"Redirect response code is one of \"301\" and location is \"https://www.example2.org//\""
               },
               "order":2
            }
         ]
      }
   ]
}