A SOAP load test allows you to test the performance of a SOAP-based web service under user load.
Configuring a Test
You can manually configure a SOAP request using a SOAP envelope or you can use the SOAP Wizard by clicking the Use WSDL button at the top of the page.
The HTTP/SOAP wizard allows you to specify a WSDL URL and lets you select valid parameters to test before you continue.
Enter the URL of the page you wish to perform the test on. Specify the entire URL including HTTP. For example, “http://www.example.com/wsdl.asmx?WSDL.”
Time Validation Threshold (in seconds)
Enter the number of seconds the system should wait for a response from the target resource before returning an error. If this is left blank the default timeout is 120 seconds.
The SOAPAction HTTP request header field can be used to indicate the intent of the SOAP HTTP request. The value is a URI identifying the intent. SOAP places no restrictions on the format or specificity of the URI or that it is resolvable. An HTTP client MUST use this header field when issuing a SOAP HTTP Request.
The presence and content of the SOAPAction header field can be used by servers, such as firewalls, to appropriately filter SOAP request messages in HTTP. The header field value of empty string (“”) means that the intent of the SOAP message is provided by the HTTP Request-URI. No value means that there is no indication of the intent of the message.
Enter the body of the XML request.
Content Validation Keywords are used to ensure that the expected content was loaded onto a web page. In the Keyword fields, you can specify one or more words or phrases that you wish to search for in the web page content. If the expected keywords are not found, the task will return an error.
You can enter multiple strings into the keyword fields. The values you enter can be separated by logical expressions as follows:
{[("keyword1"&"keyword2")|!"keyword3"]}
Where:
{[ – keyword expression start;
]} – keyword expression end;
() – grouping brackets;
& – logical AND;
| – logical OR;
! – logical NOT;
“string” – a keyword.
A successful keyword expression must include the start and end brackets as follows:
{["keyword"]}
The HTTP authentication protocol is used to allow users to access content on some websites.
The following authentication schemes are available:
- Basic Authentication: This method encodes the username and password in base64 and sends them in the request header. It’s simple but not secure unless used with HTTPS.
- Digest Authentication: This scheme hashes credentials using a nonce (a random value) before sending them over the network, providing better security than Basic Authentication by preventing replay attacks.
- NTLM Authentication: A challenge-response mechanism developed by Microsoft, NTLM is used for securing credentials in Windows environments. It provides strong security by using multiple hashing and challenge-response protocols.
Once provided, login credentials will be passed along with the request header to the web server.
- Username: contains a username for HTTP/S authentication.
- User Password: contains a password for HTTP/S authentication.
Do not confuse HTTP authentication with other authentication schemes such as Bearer Authentication that involves bearer tokens and OAuth 2.0 that uses access tokens.
Read the articles on Basic Authentication Username and Password and Monitoring OAuth 2.0-based APIs for more information.
The DNS Options feature allows users to choose how domain name server (DNS) requests are conducted during a test.
The Custom DNS Hosts section allows setting up the mapping of IP addresses to hostnames. IPv6 and IPv4 DNS resolutions are supported.
To specify the mapping, enter the IP address and the hostname in the corresponding fields.
See also: DNS Mode Options.
Note that the option is not supported by LoadView On-site Agents. To find detailed guidelines on how to set up custom DNS hosts for On-site Agent, visit the How to Set Up Custom DNS Hosts for Load Testing with On-site Agent article of our Knowledge Base.
If you want to ignore an error with a specific code and type while testing, you can configure the Ignore Error Codes option in the test target settings. If the system detects a response with the specified error type and code, the response will be considered as successful and its status will be changed to OK. Note that ignored errors will not be reflected on the reports and can’t be tracked down.
You can find a comprehensive list of Error Codes in the HTTP Status Codes List | HTTP Error Codes Explained article of this wiki.