42.12
HTTP Requests

This section describes how to send HTTP Request using QFTest.

42.12.1
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 33 and section 42.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 42.86:  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

42.12.2
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 33 and section 42.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 42.87:  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 26.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