|
Brianna Blanchard Posts: 76
6/12/2013
|
***Not a StresStimulus issue. The test error was fixed***
When running a test that has 60 requests per iteration, I get 1 to 2 400 errors (Bad Request: Invalid Verb) each iteratation/each time I "Verify" the test case. The 400 errors are not being returned from the server: there is no record of the requests that returned on the IIS logs, and the 400 errors occurs even when the server is taken down (meaning I get ~59 404 errors and one 400 errors. The request that gives the error seems to be random out of the 60, so it is not a mistake in one particular request. After performing a WireShark trace, it appeared that there was an extra null character being added to the beginning of the request (before the GET) that caused the error. The test case has been uploaded to the support repository. I have experienced this on the two of my test cases with 60 unique requests, but do not see the same problem with another test where I took my 15 unique requests and duplicated them four times.
|
|
|
0
link
|
|
Vadim @StresStimulus Administrator Posts: 583
6/12/2013
|
Hello Brianna,
Can you please upload your test one more time?
Thank you,
-Vadim
|
|
|
0
link
|
|
Brianna Blanchard Posts: 76
6/12/2013
|
Uploaded the test again.
|
|
|
0
link
|
|
Vadim @StresStimulus Administrator Posts: 583
6/12/2013
|
Got it. The test is quite sophisticated with over 150 parameters. Probably one or few of them cause the issue with sporadic null character. However, because you use external SQL Server, and not the default SQL CE, the test result with the errors was not uploaded. So, we could not see the errors while I understand the description you provided.
The best way to track down the issue is to run your test from our computer lab. Is your host accessible from the Internet and can you arrange permission for us to run you test? If yes, please provide the information via a private message. Otherwise, I'm not sure how to assist you.
|
|
|
0
link
|
|
Brianna Blanchard Posts: 76
6/12/2013
|
I'm confused as to why you couldn't see the results, as I changed that test to using SQL CE before I ran it again and uploaded the support case. I'll try again; perhaps I didn't save my changes.
You cannot access the host remotely, but as I said, I got the 400 errors even when the host was not running, so you should be able to reproduce the errors without having access to the host.
I am substituting in for the same 2-3 parameters in each request (one test case substitutes in for 2, one for 3), and there are 60 requests -- is that what you mean by 150 parameters?
|
|
|
0
link
|
|
Brianna Blanchard Posts: 76
6/12/2013
|
As a followup to the host issue, if you enter an invalid host to get 502s, the 400s don't show up, but if the host is valid but simply does not have the application installed, giving you 404s, you'll get the 1-2 400 errors when verifying the test.
Also, if I re-run any of the requests that generated the error, I no longer get a 400 error, so it doesn't seem to be a problem with specific substituted values.
|
|
|
0
link
|
|
Vadim @StresStimulus Administrator Posts: 583
6/13/2013
|
Hi Brianna,
We found the issue with your test and fixed it as explained below. Also here are the answers to your questions:
- The test results were missing in all uploads. Since you switched from an external SQL Server to SQL CE, the only other explanation to this happening is that you did not check the "test result sessions" in the upload support case options.
- On your question about the number of parameters, I meant that the total number of parameters in your script exceeded 150, which correspond with what you said about 60 requests with 2-3 parameters each. However as it turned out, all parameters worked fine (see below).
We used your recommendation about replicating the 400 error without accessing your host and it worked. Thank you for the hint. We were able to receive the Invalid Request (400) errors. In further analysis we found that request #1 in your test case is corrupt. The screenshot below shows a special unprintable character. Since only one out of 60 requests was corrupt, you got an impression of a sporadic error.
We did not need to use a WireShark trace since Fiddler exposed the issue. Once this request was removed from the test, the 400 error disappeared.
You should be able to fix your test by fixing or replacing this request.
-Cheers,
-Vadim
|
|
|
0
link
|
|
Brianna Blanchard Posts: 76
6/13/2013
|
hmm, I definitely checked both boxes, but perhaps I double-clicked one box and didn't notice.
I was able to remove the stray character, and now my test is working, which is great (though I found that editing in raw view wouldn't save the change; I had to edit in hexview). Thank you for your help.
I'm mostly confused as to how the character got there in the first place, confidering the fact that I didn't ever edit these test cases manually: they were generated from the same request using parameterization, then dragged-and-dropped into a testcase. This is how I've generated all my test cases, and I haven't had problems with any other set of requests. Furthermore, I'm not sure why replaying the same request (by dragging and dropping the request into composer) didn't result in an error. I guess it doesn't matter at this point, since it was easy enough to fix. It also seems possible that the error lies with Fiddler rather than with SS.
|
|
|
0
link
|
|
Vadim @StresStimulus Administrator Posts: 583
6/13/2013
|
You're welcome, Brianna.
I agree that StresStimulus did not create this error since the stray character was introduced into the recorded request, and not by replayed requests created by StresStimulus. Also, we have never experienced an issue when Fiddler introduced any stray characters.
|
|
|
0
link
|