1. Loops. A Loop is a group of sequential requests or pages, requested multiple times within a test case iteration. Loops are implemented as extensions of transactions. Once a transaction is created, it can be converted to a loop by changing its "Transaction or Loop Type" property. Two types of loops are supported:
- Unconditional Loops are repeated a specified number of times.
- Conditional Loops have a condition, which is checked at the end of the loop to determine if the loop should continue or exit. You can set up a loop to exit when the condition returns true or false. Two types of conditions are supported.
- Text Based condition depends on finding in a response a specified text or regular expressions.
- Extractor Based condition depends on matching an extractor value with a specified text.
Example of using loops: User postbacks "check status" page multiple times until the server completes a slow asynchronous transaction and redirects to a "result" page. When recording such test case it is not possible to predict how many times during the load test each virtual user should postback to "check status" until the transaction is complete.
To configure such scenario, create a conditional loop including all requests of the "check status" page. Define a Text Based exit condition that looks for "Location: http://website.com/result.aspx" in the response text, as shown below
The following properties are available for transactions and loops:
| Name |
Description |
| Name |
The Transaction or Loop name |
| Description |
The Transaction or Loop description |
| Goal (s) |
The transaction's completion time limit |
| Include in Transaction Detail Report? |
Select Yes to include this loop in the report located in the "Analyzing Results" section. Select No to exclude this loop from the report. |
| Transaction or Loop Type |
Select "Transaction" for a transaction. Transactions are executed once within a test case iteration. Select "Unconditional Loop" for a loop repeated specified number of times. Select "Conditional Loop" for a loop with an exit condition. |
| Number of Repeats (Max.) |
For an Unconditional Loop, set a number of repeats. For a Conditional Loop, set a maximum number of repeats, which cannot be exceeded. To remove the cap, set "-1". |
| Loop Condition Type |
A type of the condition that is checked at the end of the conditional loop to determine whether the loop should continue or exit. If the condition is based on finding in an HTTP response a specified text or regular expressions, select "Text Based". If the condition is based on evaluating an extractor, select "Extractor Based". |
| Response to Search |
Select a response number from the drop-down, where the specified text or regular expressions will be searched. |
| Search String |
Specify a character string that will be searched in the HTTP response. |
| Search String Type |
If the search string is a text, select "Text". If the search string is regular expressions, select "Regular Expression" |
| Exit Loop if Found? |
Select Yes to repeat the loop, when "Search String" is not found, and exit the loop, when "Search String" is found. Select No to repeat the loop, when "Search String" is found and exit the loop when "Search String" is not found. |
| Extractor Name |
Select from the drop-down an Extractor that will be used in the "Extractor Based" condition. |
| Text to Compare |
Specify a text to compare with the Extractor value in the "Extractor Based" condition. |
| Exit Loop if Match? |
Select Yes to repeat the loop, when "Text to Compare" does not match the Extractor, and exit the loop, when "Text to Compare" matches the Extractor. Select No to repeat the loop, when "Text to Compare" matches the Extractor, and exit the loop, when "Text to Compare" does not match the Extractor. |
To change the loop / transaction definition, click "Edit the selected Transaction or Loop" button on the toolbar.
2. Sequential test cases execution. In the previous versions, test cases could be only executed concurrently. In 3.5, a sequential-concurrent test case mixing model is added.
Now test cases can be combined into groups, called Test Case (TC) Groups. Test cases in a TC Group are executed sequentially in a predetermined order. If a Test has more than one TC Group, then they are executed concurrently. The Mix Weight property of each TC Group determines the relative frequency of its replays in the mix. Every VU is assigned to a specific TC Group for the entire duration of the test. A VU executes all test cases in a TC Group before starting the next iteration of the TC Group.
To create a test case group, select Test Case Group tab, click Create button on the toolbar and add selected test cases to the group. Then arrange the order of test case execution by moving them up or down on the list.
Note: When at least one TC Group is created, the Mix Weight and cache control-related properties are moved from Test Cases to TC Groups because all test cases in a TC Group are executed with the same frequency and must have the same cache control settings.
3. Import Test Cases (teamwork feature). Test cases from one test now can be imported to another test. This can be helpful to create a consolidated test by combining multiple test cases configured prepared by several team members.
In multi test cases section, click "Import Test Cases from another Test" button on the toolbar and then in the Windows Explorer pop-up window select an .ssconfig file and click Open. All test cases from the selected test will be imported into the current test. All test objects will be copied into the .ssconfig file of the current test, and all .saz files with sessions will be copied into the current folder.
If you need to import some but not all test cases, then after import delete the test cases you do not need.
To navigate to other parts of the v3.0 release notes, click the links below:
StresStimulus 3.5 beta is available here.