2005年5月20日 0:03I have recorded a test which looks like this:
- signin.aspx -> submiting page lands on search.aspx
- click Register link on search.aspx -> lands on register.aspx
- fill out page and submit -> lands on ValidateAddress.aspx (for mailto)
- submit page -> lands on ValidateAddress.aspx (for billto)
- submit page -> lands on RegisterComplete.aspx
The actual recording skips the search.aspx page, apparently since I didn't really navigate to it. So the list of urls in the recording is:
When I run the test and view the results, the list of urls is (bolded ones are of interest):
Reguest Http Status
I'm confused by the following:
search.aspx shows up, but its not in the recording (although I think it should be). It tends to fail loading dependent files, although this failure in no way impacts the test (it keeps right on and ultimately succeeds).
ValidateAddress.aspx is extra, since in the recording I only visited this page twice. I actually think the 1st instance of ValidateAddress.aspx is the actual response from submiting register.aspx. the 2nd instance is from the 1st recorded visitation, and the 3rd (extra) instance is from the 2nd recorded visitation. I believe this from looking at the the Web Browser tab in the results window. The 3rd instance, the Web Browser tab shows "Object moved to here." I've seen this in other results as well.
This doesn't seem right to me. It seems like the tool is forcing navigation to particular pages instead of letting the recorded user actions direct the navigation. At best, its confusing to see these deviations from what really happened during the recording (and when the user performs this process).
2005年5月20日 6:32When you see a "Object moved to here" message this is caused when you do a Response.Redirect in the page. This just sends a HTTP status code 302 back to the browser who will then request the alternative URL provided with the code. So this is correct behaviour when you use response.redirect
2005年5月20日 16:44I will take these in order:
search.aspx - This is not included in the recording because as you mentioned, you did not explicity navigate there. You were redirected there by signin.aspx. By default, the web test engine will automatically follow any redirects. If you would prefer not to do that. You can set the FollowRedirects property of the signin.aspx page to false then add an explicit request to search.aspx to your recorded test.
Not sure why the dependents request are failing, but I would verify the proxy setting on the web test, perhaps the dependent requests are coming form a different server (ala Akamia) and the proxy setting is not right so they can't be retrieved.
ValidateAddress.aspx - Without looking at your script it is a bit hard to tell why you ae seeing 3 requests to this page instead of 2 but I suspect it has to do with the fact that register.aspx redirects to validateaddress.aspx. Taking a close look at the referrer header will tell you if these came form a postback or from a redirect
I think in order for this to do what you want, you need to set FollowRedirect on register.aspx to false. Then the two recorded ValidateAddresses.aspx will still be called.
Our decision to display a page for the 302 in the preview screen is a bit confusing because though the browser also receives this page, the user doesn't see it. This is one area where the playback experience is slightly different than the recorded experience. However, as a test developer, it is good to know that the redirect happened so therefore we show it.