|
Tessa Adair Posts: 5
7/29/2014
|
During a test, I am seeing many sessions show up in the sessions list that all have the same HTTP error code and otherwise seem the same. However, only a scattered handful of these sessions are marked in red and included in the error count. What are the default settings that determine which sessions show up in red as errors?
|
|
|
0
link
|
|
Vadim @StresStimulus Administrator Posts: 583
7/30/2014
|
Hello Tessa,
If I understood correctly, you made two observations:
- During the test run, a number of sessions in the session grid appear with the same error, but only some of them are marked in red.
- Only some of these errors are included in the StresStimulus error count.
Please note the following:
- On your 1st observation: By design, Fiddler marks all sessions with response code in the 400 and 500 ranges in red. Are you sure that HTTP errors in the Fiddler grid are not highlighted in red? I suggest to double check that all those sessions are in fact the HTTP errors. To do so, sort Fiddler grid by the response code to verify that all those sessions have the same error.
- On the 2nd observation: StresStimulus has two stage error checking.
a. On the Verify stage, StresStimulus registers 3 types of issues, as described here http://support.stresstimulus.com/display/doc37/Verifying+the+Test+Case
- Errors - Sessions 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.
- Warnings - Sessions with issues that may or may not be related to the test configuration. Try using Parameter Finder to eliminate or reduce number of warnings. After that, inspect remaining warnings to make sure that they are not caused by missing settings in the test configuration.
- Notifications - Sessions with issues unrelated to the test configuration. Notifications can be rectified by refining your application. For example, broken links of missing images will causes 404 HTTP errors. Such errors can be fixed by making adjustments in the tested application.
- On the test run stage, only the errors that are caused by the load are counted. So if a 404 error was registered on the verify stage, it will be not be counted as a load test error.
If you cannot sort-out errors in you test, feel free to contact support so we can set up a support session.
|
|
|
0
link
|
|
Tessa Adair Posts: 5
8/12/2014
|
Regarding my first observation, here is what I see when I sort by response code.
My test case only has that one page, and as far as I can tell they are all the same except for the fact that some are bolded red, some are bolded grey, and some are unbolded yellowish. Any idea what the differences might be between these?
|
|
|
0
link
|
|
Vadim @StresStimulus Administrator Posts: 583
8/13/2014
|
Hello Tessa,
This error indicates that your application requires server authentication (like NTML or Kerberos). Go to the Authentication tab in the Workflow tree and add at least one set of credentials as described here. This will fix all errors it once.
|
|
|
0
link
|
|
Tessa Adair Posts: 5
8/18/2014
|
Hi,
Yep, I am already using authentication (without which there are way more 401 errors), but the ones in the screenshot are still sticking around. Some 401 errors are recorded with the test case, so I expect to see some, but not all of these. I am now trying to understand which of these 401s are expected and which are not. This is why I want to know what the color-coding means.
|
|
|
0
link
|
|
Vadim @StresStimulus Administrator Posts: 583
8/19/2014
|
Hi Tessa,
Session color is determined by Fiddler depending on the status code, mime type and traffic type as described here. For example, errors are red; authentication demands are yellow; CONNECTs are gray.
From authentication standpoint, StresStimulus emulates real browser behavior. It does not record sessions with 401 responses. Instead StresStimulus issues authentication requests when server responds with 401. The number of such requests is determined dynamically. So 401 received during the test run are not caused by recorded 401 sessions.
Does this make sense?
|
|
|
0
link
|
|
Tessa Adair Posts: 5
8/20/2014
|
Yes, makes sense.
Can you provide any more details about this:
The number of such requests is determined dynamically.
|
|
|
0
link
|
|
Vadim @StresStimulus Administrator Posts: 583
8/20/2014
|
Tessa,
As I said before, StresStimulus issues authentication requests when the server responds with 401. For example, if the application sends two 401 responses before authenticating a session, then StresStimulus will emulate real browser behavior by sending three authentication requests per session.
The number of round-trips to authenticate a client depends on the authentication method used by your application. For example, Kerberos uses one round trip. NTLM has a "challenge" phase that adds a second round trip.
Hope this will help.
|
|
|
0
link
|
|
Tessa Adair Posts: 5
8/22/2014
|
Okay, so for an example test case, my application sends two 401 responses before authenticating a session. When I run a test with 1500 total requests, I see 1000 sessions in Fiddler that have a 401 response code, and the other 500 are all 200s. From what I understand, this is expected.
However, StresStimulus says there were 70 HTTP errors. Yet there were no errors, warnings, or notifications in the verify stage. So does this mean that StresStimulus is deciding that 70 of the 401 responses are "caused by the load"?
Only 21 of the sessions appear red in the Fiddler grid.
|
|
|
0
link
|
|
Vadim @StresStimulus Administrator Posts: 583
8/23/2014
|
Tessa,
Here is the logic/process I suggest you to follow for analyzing your test result:
- Because " .. there were no errors, warnings, or notifications in the verify stage" your test configuration is correct. You should expect no test run errors caused by incorrect script.
- Because "StresStimulus says there were 70 HTTP errors" it is likely that all of these errors were caused by the load.
- Retrieve the 70 error sessions from the test log as described here http://support.stresstimulus.com/display/doc37/Querying+the+Test+Log On the test log query window, make sure that all fields are cleared and check the Error box. The exactly 70 sessions will appear in the session grid. Analyzing these 70 sessions to determine if they are caused by 401 responses or different reasons. Disregard the 1000 sessions with 401 which you saw before, because 1000 is a (configurable) limit of sessions displayed in the session grid when test runs in debug mode.
- To analyze every error, double-click the session. The content of the request and response will be displayed in the appeared session inspector. The response body may display a server error message or give you a clue on what went wrong.
Does this make sense?
-Vadim
|
|
|
0
link
|