After recording a test case, it's highly recommended to verify it. If you run a test without verification, you may encounter issues related to incorrect or incomplete test configuration. The purpose of verification is to discover such issues.
This information should be used to add some configuration settings that will fix verification errors or warnings. After all, verification errors and warnings are resolved; all the test errors are likely related to your website’s inability to handle multiple users properly.
During verification, StresStimulus replays the recorder test case once with one virtual user in debug mode. Reissued sessions are automatically compared with the corresponding recorded sessions, and the recorded and replayed server responses are analyzed. After the verification is completed, errors, warnings, configuration recommendations, and other diagnostics are displayed.
Note: Some Test Profile settings, such as browser type and network type, are not simulated during verify. To start the Verify process: 1. Click Verify & Auto-Config (a) in the workflow tree. 2. A pop-up dialog Verify the Test Case (b) will appear. 3. Sometimes it is desirable to verify the test case with a different VU. For example, if a test case uses a dataset to parameterize an authentication form, then you might want to verify a few times under different credentials each time. To simulate a different VU, set the numeric boxes to the desired VUs (c) and # of iterations (d) to verify. It is sometimes beneficial to verify more than one iteration. For example, you might want to make sure you have no errors on subsequent iterations when a login transaction is marked to run on the first iteration only. 4. Optionally, you can specify a session number, after which Verify will stop, to save time. For example, if the error/warnings occurred in sessions 20, 22, 40, 42, 60 … and you just addressed session 20; then, you can run Verify to session 40 or 42. To do so, enter the session number in the Stop after session box (e). 5. You can add a description for each verify run (f) so that you can keep track of the changes you make to your test case between Verifys. 6. During verify, the test case is replayed at a slower pace to give a user a chance to preview the succession of web pages that appear in the web view. To run verify at a faster pace without the page preview, check Quick Verify box (g). This option will persist for future verifies. 7. Click Verify. The session grid will display sessions as they get issued in real-time. Tip: If, during test case verification, some errors or warnings are discovered, they should be reviewed one by one in the order of appearance from top to bottom. Depending on the situation, use the appropriate technique to address them. For example, create a missing parameter, delete a request that should be excluded from the test, or ignore warnings that are irrelevant to the test's execution. After that, re-run Verify and move to the next error warning resolution. Since you should only focus on the subsequent 1-2 errors/ warnings, there is no need to Verify the entire test. 8. During the test replay, the browser object displays the sequence of the web pages as they get accessed. This helps to determine whether the test case is replayed correctly quickly. For example, if the pages in the browser object repeatedly display the login screen or error messages, it is an indication of authentication or session integrity issues.
9. The following options are available to control the verification process:
The Verify progress bar displays real-time time statistics, including the number of processed sessions, and detected errors and warnings.
Info: During verify, the timeout mechanism is disabled. StresStimulus will wait for all responses to come back. The timeout of the request does not limit the wait time. |   | ||||||||||||||||||
10. If verification determines that there are too many redundant extractors that can be safely deleted, it will prompt you to confirm their deletion. Autocorrelation sometimes creates excess extractors to avoid correlation errors. They should be removed to reduce resource utilization. 11. After Verify is completed, a new tab (j) will appear. It displays the Session Verification tab (k) with a tree showing the outcome of verification for each session and the test case overall. |  | ||||||||||||||||||
 12. Next, to every request, there is a status image describing the outcome. One of 4 status es can be assigned to a session.
13. To display a subset of sessions with the same status, click one of the filtering buttons (l) on the toolbar session verification: Errors, Warnings, or Notifications. To display all sessions, click URLs. 14. To display a tooltip with a specific error or warning, mouse-over a session (m). 15. To view session content, double-click the Recorded or Replayed node (n), and Session Inspector (o) will appear. 16. Right-click a session to display the context menu. To compare recorded and replayed sessions, click Compare (p) in the context menu or on the toolbar, and the Compare Sessions Inspector (q) will appear. Session Inspectors are described in the next section. 17. The Verify command also generates an Extractor Verification Tree (r). In a separate tab, it displays extractor values, errors (if the extractors cannot be validated), or warnings (if the extractors are not used). 18. Click Verify Description (s) to see the test case you verified, the time, or the description. You can also modify the description here. 19. By default, the verification tree shows the test case hierarchy as transactions > pages > sessions. If you wish to show sessions only, check the "Show sessions only" box (t). |
Tip: You can export a session replayed during verify and save it as a .saz file. To do so, right-click anywhere in the verification tree, then select Export Replayed.
Overview
Content Tools
