Versions Compared

Old Version 8

changes.mady.by.user SS Doc Editor

Saved on

compared with

New Version Current

changes.mady.by.user SS Doc Editor

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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 issues. 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 properly handle multiple users properlyusers.

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

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.


Tip

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 (1). This option will persist for future verifies.

7. Check Generate trace log (2) to generate a trace log to inspect test case execution along with component and scriptable variable errors.

8. Click Verify button. The session grid will display sessions as they get issued in real-time.


Tip

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' sequence 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 browser's pages repeatedly display the login screen or error messages, it is an indication of indicates authentication or session integrity issues.

      • In the standalone version, the webpage view Is located in the right pane.
      • In the add-on version, Fiddler automatically switches to the Inspectors -> web view tab.


9. The following options are available to control the verification process:

  • Click Pause (h) to suspend issuing requests. Click Resume to continue verification
  • Click Step (g) after pausing to send a single next-in-the-queue request for every VU. This option is used to debug for debugging the test case further.
  • Click Abort (i) to stop verification.

The Verify progress bar displays real-time time statistics, including the number of processed sessions , and detected errors and warnings. 

 

Info

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.



StatusDescription
PassSession completed normally
ErrorSessions with errors related to the test configuration. Configuration-related errors indicate that some test configuration should be adjusted. Most often, such errors can be fixed by adding missing parameters. Try to find and create such parameters using Parameter Finder.
WarningSessions with issues that may or may not be related to the test configuration. Try using Parameter Finder to eliminate or reduce the number of warnings. After that, inspect the remaining warnings to make sure ensure that missing settings in the test configuration's missing settings do not cause them.
Notification

Sessions with issues unrelated to the test configuration. Notifications can be rectified by refining your application. For example, broken links of missing images will cause 404 HTTP errors. Such errors can be fixed by making adjustments in the tested application.

Unknown size

Used when comparing recorded and replayed in an agent iteration when a session is configured to be truncated.


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 A separate tab , it displays 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).

20. If Generate trace log (2) was checked, then the Trace log tab (u) will contain the verified trace information similar to a test log.

21. Click Show Verify waterfall diagram... (v) button to bring up the verify's waterfall diagram for the verify.



Tip

Tip: You can export a session replayed during verify the verification and save it as a .saz file. To do so, right-click anywhere in the verification tree, then select Export Replayed.

...