UI layout and objects
1. The Test Case Tree is movable to Fiddlers grid's position. This UI upgrade substantially expands StresStimulus screen real estate and simplifies navigation through test configuration options. The Test Case Tree can be docked in the fiddler grid (on the left) or can be moved back to its original position (in the StresStimulus Test Case section on the right). Once on the left, the tree can be used to quickly navigate from object to object, while the object's details are displayed in StresStimulus pane on the right.
- To move the Test Case Tree to the Fiddler position, click "Dock to the Fiddler on the left" button on the Test Case Tree toolbar (Fig. 1).
- To move it back, click "Dock to StresStimulus on the right" on the Test Case Tree toolbar.
Fig. 1
2. The Test Case Tree auto-positioning.The most convenient position of the Test Case Tree is automatically determined based on the UI context, selected by the user. For example, when the Test Case Tree is on the right, and the user double-clicks on the object to view its details on the right, the Test Case Tree will be repositioned to the left. Or, conversely, when the Test Case Tree is on the left and the user select one over the "Show…" command to display fiddler sessions, the Test Case Tree will be repositioned to the right.
3. The Test Case Tree displays more object types. The following objects are displayed (Fig. 1):
a. Page.
b. Primary request.
c. Dependent requests.
Note: A page has one primary request and can have one or several dependent requests. A primary request is an HTML page request triggered by users' actions, such as a mouse click, as determined by StresStimulus. Dependent requests represent page resources, such as images, scripts or style sheets. Once the primary response is received, StresStimulus replays dependent requests as fast as possible (in parallel) while complying with simulated performance constrains of a selected browser and network type.
Additional objects added in v2.0
d. Response Extractor.
e. Request Parameters. The request parameter types are recited in the next paragraph.
4. Multiple types of request parameters. The Test Case Tree displays multiple types of request parameters that can be broken down into the following groups:
By request part:
- Body.
- URL.
- Query string.
- Headers.
By format (Fig. 1):
- Name / value pair. This type of parameters is used to parameterize parts of a request that have name / value format, such as a request form, a query string with multiple parameters or request headers. These parameters can be created or changed using the Parameterization Grid that has the Name and Value columns (Fig. 2). One request can have one or several named parameters of that type that are displayed on the Test Case Tree in the "box "container.
- Autocorrelation. This is a special case of the name / value parameter, which is automatically created by StresStimulus. Each autocorrelated parameter is created along with its a corresponding hidden extractor. The example of an autocorrelation parameter is __VIEWSTATE (the parameter is used to store Web page state in ASP.NET).
- Free format. This type of parameters is used to parameterize parts of the request that cannot be (easily) presented as name / value pairs, such as JSON or XML POST request or RESTful URL. These parameters are created with the parameterization editor (Fig. 3). Only one free format parameters per request can be displayed in the Test Case Tree. The free format parameter is always unnamed, can store multiple parameterization rules and encompasses values derived from multiple extractors and datasets. Such rules are stored as an encoded text.
The list of supported parameters and the icons used to depict them are provided in the table below:
Parameter Type
|
Request Part
|
Format
|
| Form Parameter |
Body |
Name Value Pair |
 |
| Form Parameter |
Body |
Autocorrelation |
| Body Parameter |
Body |
Free Format |
| Query String Parameter |
Query String |
Name Value Pairs |
| URL Parameter |
URL |
Free Format |
| Header Parameter |
Headers |
Name Value Pairs |
Test Case: editing and deleting objects from the Test Case Tree
5. Editing and deleting a name/value parameter from the Test Case Tree. In the Test Case Tree, double-click on a name / value parameter (Fig. 2). Alternatively, right-click and select "Edit Parameter”, or select the parameter and click the “Edit Object” button on the Test Case Tree toolbar. As a result, in the Navigation Tree, the Parameters section will be highlighted and in the Parameterization Grid the parameter will be selected. Also, if the Test Case Tree was docked in StresStimulus, it will be automatically re-docked to Fiddler.
To edit the parameter, enter a different value in the Value column, or right-click and select a different extractor or dataset from the Parameterization Control. To remove the parameterization, clear the Value column in the Parameterization Grid.
Fig. 2
6. Overwriting/restoring autocorrelation. Access and edit an autocorrelation parameter as described in the previous paragraph (Fig. 2). To delete the autocorrelation parameter, clear “{{Auto-Correlated}}” string from the Value column. To restore the autocorrelation parameter, select “{{Auto-Correlated}}” from the Parameterization Control.
7. Editing and deleting a free format parameter from the Test Case Tree. In the Test Case Tree, double-click on a free format parameter (Fig. 3). Alternatively, right-click and select "Edit Parameter”, or select the parameter and click the “Edit Object” button on the Test Case Tree toolbar. The request will be displayed in the parameterization editor. If the Test Case Tree was docked in StresStimulus, it will be automatically re-docked to Fiddler.
To edit the parameter, select a body or URL portion of the request which you wish to parameterize, right-click and then select a dataset or an extractor from the appeared Parameterization Editor. To remove the parameterization, click the "Restore to Recorded" button on the parameterization editor toolbar.
Fig. 3
8. Editing and deleting an extractor from the Test Case Tree. In the Test Case Tree, double-click on an extractor (Fig. 3). Alternatively, right-click and select "Edit Extractor”, or select the extractor and click the “Edit Object” button on the Test Case Tree toolbar. The extractor will be selected on the Extractor Grid. If the Test Case Tree was docked in StresStimulus, it will be automatically re-docked to Fiddler. To edit the extractor, enter different values in the extractor row. To delete the extractor, right-click it and select Delete or click Delete on the Extractor Toolbar.
9. Editing a page from the Test Case Tree. In the Test Case Tree, double-click on a page (Fig. 3). The page will be selected on the Page Settings Grid. If the Test Case Tree was docked in StresStimulus, it will be automatically re-docked to Fiddler. To edit the page, enter different values in the page row.
10. Renaming and deleting a page from the Test Case Tree. Page initial name is derived from its Title tag, or the URL, if the Title is missing. To rename the page, right-click and select “Rename Page” (Fig. 4). Alternatively, a page can be renamed in the Page Settings Grid. To delete the page, right-click on it and select Delete or click Delete on the Page Settings Toolbar.
Fig. 4
11. Editing a request from the Test Case Tree. In the Test Case Tree, double-click on a request (Fig. 4). Alternatively, right-click and select "Edit Request”, or select the request and click the “Edit Object” button on the Test Case Tree toolbar. The session will be displayed in the Fiddler Inspectors tab. To edit the request, select the desired inspector and make necessary changes. To return to StresStimulus, click the StresStimulus tab.
To navigable to other parts of the v2.0 release notes, click the links below:
V2.0 beta is available for download here.