Please, excuse me for the short delay in sending the summary of our meeting - I was busy with some tasks related to the latest Service Pack release we published yesterday.
So, the performance scenario you intended to accomplish was to somehow measure the time needed for each of the URLs in the redirect sequence of URLs. However, this seems to be quite a challenge as usually the redirects are using external services. over which one does not have much control.
Having that said the solution that Test Studio can offer is to measure the whole time for the redirect, which will represent the overall user experience. This can be accomplished with some additional adjustments to fit the test run to the specific scenario. Below are the details we discussed during our conversation.
The WaitForUrl step - although you tried to insert wait steps for each of the URLs (or at least for these, you managed to catch), the test was often failing because the URLs are changing too fast and Test Studio may miss the one set in the waitForUrl step. The reason behind this is the mechanism used for that step - Test Studio refreshes the DOM to get the current URL and since that action requires some time, a URL from the redirects may be completely missed. This, however, fails the test, although it is sort of a false failure.
Connect to popup step - the initial troubles were to connect to that popup, which is again related to the specific scenario. Test Studio distinguishes the different windows by their URL (could be partial also). Having this in mind and in the case with redirects, you need to identify the first URL in the new window and use it for the connect step.
To complete the scenario, there are two possible options to wait until the redirect sequence is finished - to insert a wait for element step, or wait for Url step.
- the wait step to wait for an element on the already loaded page - this will ensure that all of the redirects did go through and the page is really loaded. Though, it was required to increase the element timeout in the step properties, as the default wasn't sufficient and again the test was failing.
- the waitForUrl step - this can be used, but to wait for the last expected URL, when the page is already loaded. Probably it will require partial match if the final URL is somehow related to the logged user.
During our discussion I mentioned a Telerik tool, which captures the generated http traffic. This is Fiddler and may be helpful for you to find out more about the redirect URLs sequence and how you can optimize it. When you have the time you can explore its features and check if it can fit your needs.
Thanks once again for your time and cooperation. In case there is something else you need to further discuss, please do not hesitate to get back to me.