HTTP Requests

This section describes how to send HTTP Request using QFTest.

'Server HTTP request'

Web This highly specialized node sends a web request via HTTP/HTTPS directly to a web server. Such a request can be very helpful for load tests or mass data computing scenarios (e.g. filling out a form) since the simulation of user interactions and the respective loading time of the SUT are omitted during replay. The use of requests is an enhancement of the functionalities for load tests and data-driven testing described in chapter 31 and section 40.4.

If the status code returned from the server is 400 or higher, an exception is thrown. This behaviour can be changed using the 'Error level if status code >= 400' attribute. A detailed description of the different status codes can be found at http://www.w3.org/Protocols/HTTP/HTRESP.html. Additionally you can store the response from the server in a variable and if the attribute 'Add server response to run log' is active the response is also written to the run log.

Contained in: All kinds of sequences.

Children: None

Execution: The web request is sent directly by QF-Test via HTTP/HTTPS to the specified URL. If the status code returned from the server is >= 400, an exception is thrown. This behaviour can be changed using 'Error level if status code >= 400' attribute.

Attributes:

Server HTTP Request Attributes
Figure 40.85:  'Server HTTP request' Attribute
'URL'

The URL to which to send the request, not including parameters. HTTP and HTTPS are acceptable values for the protocol.

Variable: Yes

Restrictions: Must not be empty.

'Method'

This attribute defines the method of the request, GET, POST,HEAD, PUT, DELETE, TRACE or CONNECT .

Variable: Yes

Restrictions: None

'Executable parameters'

Here you can specify the parameters for the request. The parameters will be URL encoded by QF-Test at execution. See subsection 2.2.5 for further information how to work with the table.

Variable: Yes

Restrictions: None

'Headers'

To use custom headers you can set them with this value. You can specify the name of the header and the header value. See subsection 2.2.5 for further information how to work with the table.

Variable: Yes

Restrictions: None

'Additional headers'

As an alternative or in addition to the headers table, this field holds additional headers in text form. This makes it easier to use variables and maybe exclude some headers. Each line holds one header in the format Header: Value.

Variable: Ja

Restrictions: Keine

'Payload'

For POST Methods additional payload can be attached to the request. It can be of various types like plain text, JSON or XML. To successfully add the specific format the "Content-Type" header needs to be set to the corresponding value. For more information about the "Content-Type" see: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type.

Variable: Yes

Restrictions: None

'Variable for HTTP status code'

The name of the variable to which the HTTP status code is assigned (see chapter 6).

Variable: Yes

Restrictions: None

'Variable for response headers'

The name of the variable to which the response headers value is assigned (see chapter 6).

Variable: Yes

Restrictions: None

'Variable for response body'

The name of the variable to which the server response is assigned (see chapter 6).

Variable: Yes

Restrictions: None

'Local variable'

This flag determines whether to create local or global variable bindings. If unset, the variables are bound in the global variables. If set, the topmost current binding for a variable is replaced with the new value, provided this binding is within the context of the currently executing 'Procedure', 'Dependency' or 'Test case' node. If no such binding exists, a new binding is created in the currently executing 'Procedure', 'Dependency' or 'Test case' node or, if there is no such node in the topmost node on the variables stack, falling back to the global bindings if necessary. See chapter 6 for a detailed explanation of variable binding and lookup.

In order to predefine the option use Enable 'Local variable' attribute by default.

Variable: No

Restrictions: None

'Add server response to run log'

If activated the server response is written to the run log in addition to the status code.

Variable: Yes

Restrictions: None

'Save response to file'

If set the response is written to this file. This enables QF-Test to download files.

Variable: Yes

Restrictions: QF-Test must be able to write to the file.

'Error level if status code >= 400'

This attribute can change the error level of requests that return with a status code greater than or equal to 400.

Variable: No

Restrictions: None

'Timeout'

Time limit in milliseconds until the HTTP Request must succeed. To disable the limit, leave this value empty.

Variable: Yes

Restrictions: Must not be negative.

'Error level if time limit exceeded'

This attribute determines what happens in case the time limit is exceeded. If set to "exception", a CheckFailedException will be thrown. Otherwise a message with the respective error-level will be logged in the run log.

Variable: No

Restrictions: None

'QF-Test ID'

At the moment the 'QF-Test ID' attribute has no meaning for this type of node.

Variable: No

Restrictions: Must not contain any of the characters '\', '#', '$', '@', '&', or '%' or start with an underscore ('_').

'Delay before/after'

These attributes cause a delay before or after the execution of the node. If a value is empty, the Default delay from the global options is used.

Variable: Yes

Restrictions: Valid number >= 0

'Comment'

Here you can enter a comment that explains the purpose of this node. This is the preferred way of documenting the test suite.

Note For detailed documentation, especially for 'Test set', 'Test case' or 'Procedure' nodes, this text area might not be the right place. There are many excellent editors that are much better suited to this task. The option External editor command lets you define an external editor in which comments can be edited conveniently by pressing [Alt-Return] or by clicking the External editor button.

You can trigger special behaviors of some nodes using doctags, please see Doctags.

If you enter text in the comment field of a 'Component' node, the node will be considered as 'used' when you want to mark or delete unused components.

Variable: Yes

Restrictions: None

'Browser HTTP request'

Web This highly specialized node sends a GET or POST request via HTTP/HTTPS directly to a web server. Such a request can be very helpful for load tests or mass data computing scenarios (e.g. filling out a form) since the simulation of user interactions and the respective loading time of the SUT are omitted during replay. The use of requests is an enhancement of the functionalities for load tests and data-driven testing described in chapter 31 and section 40.4.

Contained in: All kinds of sequences.

Children: None

Execution: The GET/POST request is sent within the browser via HTTP/HTTPS to the specified URL. The response is shown directly in the Browser.

Attributes:

Browser HTTP Request Attributes
Figure 40.86:  'Browser HTTP request' Attribute
'Client'

The name of the SUT client process in which to execute the request.

Variable: Yes

Restrictions: Must not be empty.

'QF-Test component ID'

The 'Web page' in which the request should be submitted.

The "Select component" button [Select component] brings up a dialog in which you can select the component interactively. You can also get to this dialog by pressing [Shift-Return] or [Alt-Return], when the focus is in the text field. As an alternative you can copy the target node with [Ctrl-C] or »Edit«-»Copy« and insert its QF-Test component ID into the text field by pressing [Ctrl-V].

This attribute supports a special format for referencing components in other test suites (see section 24.1). Furthermore, sub-elements of nodes can be addressed directly without requiring separate nodes for them (see section 5.9). When using SmartIDs, you can address a GUI element directly via its recognition criteria. For more information, refer to SmartID and 'Component' nodes versus SmartID.

Variable: Yes

Restrictions: Must not be empty.

'URL'

The URL to which to send the request, not including parameters. HTTP and HTTPS are acceptable values for the protocol.

Internationalized domain names (IDN) are not supported in the URL attribute as well as links to local file system starting with 'file:///'.

Variable: Yes

Restrictions: Must not be empty.

'Method'

This attribute defines the method of the request, GET or POST.

Variable: Yes

Restrictions: None

'Executable parameters'

Here you can specify the parameters for the request. The parameters will be URL encoded by QFTest at execution. See subsection 2.2.5 for further information how to work with the table.

Variable: Yes

Restrictions: None

'QF-Test ID'

At the moment the 'QF-Test ID' attribute has no meaning for this type of node.

Variable: No

Restrictions: Must not contain any of the characters '\', '#', '$', '@', '&', or '%' or start with an underscore ('_').

'Delay before/after'

These attributes cause a delay before or after the execution of the node. If a value is empty, the Default delay from the global options is used.

Variable: Yes

Restrictions: Valid number >= 0

'Comment'

Here you can enter a comment that explains the purpose of this node. This is the preferred way of documenting the test suite.

Note For detailed documentation, especially for 'Test set', 'Test case' or 'Procedure' nodes, this text area might not be the right place. There are many excellent editors that are much better suited to this task. The option External editor command lets you define an external editor in which comments can be edited conveniently by pressing [Alt-Return] or by clicking the External editor button.

You can trigger special behaviors of some nodes using doctags, please see Doctags.

If you enter text in the comment field of a 'Component' node, the node will be considered as 'used' when you want to mark or delete unused components.

Variable: Yes

Restrictions: None