| Table of Contents |
|---|
...
ZebraTester keeps the entire recorded Web surfing session in its transient memory cache.
For this reason, you should save the recorded Web surfing session to disk by using the Save Session icon inside the Web Admin GUI. All data from the Web surfing session are saved, including all HTTP request- and response-headers, all recorded HTTP content data, and all page break definitions. Any special session enhancements made by using the Variable Handler, or by using the content test configuration menu, are also saved. We recommend that you also enter a small comment describing the recorded session. |
 |
After saving the session, the Project Navigator menu appears. |
 |
You can later restore the Web surfing session by clicking on the “Load Recorded Session” icon of a saved session inside the Project Navigator. |
 |  |
Reviewing the Recorded Web Surfing Session
After you have recorded a Web-surfing session, you should review the results by checking the following:
Does the recorded session contain only URL calls to the webserver(s) you want to test?
Has the automatically-applied content test check for the recorded Web pages been correctly configured?
Reviewing the Stressed Web Servers
...
In addition to searching for the occurrence of a simple text inside the received response content of an URL call, the following special search patterns are supported:
String | Description |
|---|---|
| The search text must not occur inside the received content. |
| The search text must occur exactly <int> times inside the received content. |
| The search text must occur a minimum of <int> times inside the received content. |
| The search text must occur a minimum of |
Search Text Examples
Text | Description |
|---|---|
| The search text "hello" must occur at least once inside the received content. |
| The search text "ORA-01652" must not occur inside the received content. |
| The search text "Dear Mr." must occur exactly one time inside the received content. |
| The search text "Order Number" must occur a minimum of one time and a maximum of two times inside the received content. |
| The search text "new order" must occur a minimum of three times inside the received content. |
Note: One or more variable text patterns in the form of ${<variable name>} are supported as a part of the search text; for example, Welcome ${gender} {$name}.
...
The Failure Action determines what happens in case the URL call fails.
| This means that the current loop (repetition of Web surfing session) of the simulated user is aborted and that the simulated user executes subsequent to that the next loop (if more loops per user are planned, or if the duration of the load test is not exceeded). Such failures are also named fatal errors. |
Optionally, you can activate the checkbox Terminate User which effects that all simulated users for which this failure occurs are removed from further load test execution.
| This means that the simulated user continues to execute the current loop (repetition of web surfing session). Such failures are also named non-fatal errors. This option should only be used if no variables have to be extracted from the response of the URL call - or in other words - only if the succeeding URL calls do not depend on the response of this URL. |
Reset Settings
By clicking on the Apply Default Settings button at the bottom of the window you can undo your changes and the default settings are reapplied.
...
Normally the first URL of a standard Web page should always be executed serial - analog to the behavior of a normal Web browser. Additionally, any redirects located at the start of a Web page should also be executed serially. Subsequently following URLs of a Web page such as images can then be executed in parallel. The synchronization point for all in parallel executed URLs is always at the end of a page.
...
It might be necessary to consider variables that are assigned or extracted to or from URLs, meaning that a variable cannot be extracted from a parallel executed URL and then assigned to another succeeding URL which is also executed in parallel on the same page. Therefore to avoid unexpected runtime errors during a load test we recommend that you always use the Auto-Configuration for Parallel URL Runtime Execution, which considers almost all aspects.
...
| Note |
|---|
|
Tip: If your load test fails and a permanent error occurs at the same URL you should call the Var Finder menu – and verify if the handling for dynamically exchanged session parameters must be applied. Example below.
In these cases, we strongly recommend reading the installed ZT manual about Handling "Dynamically-Exchanged Session Parameters" (Attached)
...