I was trying to run a test to see the performance results when users log in to our University's portal and click on our Office 365 icon. However, I get an "Exception occurred waiting for the new browser to connect" error. I believe this is due to the fact that there are multiple redirects taking place once the icon is clicked and Test Studio can't capture each of them. These redirects are part of the process we have in place so that the user won't have to login to office 365 again. So is there anyway to capture multiple redirects?
The test is basically as follows:
1. User navigates to our portal.
2. User enters their username and password
3. User signs in to Portal
4. User clicks on Office 365 icon.
5. Pop up window appears. (SSO and redirects occur in this step).
6. User lands in Office 365 homepage
10 Answers, 1 is accepted
Hi Jose,
Thank you for the detailed explanation of the observed misbehavior - these are really helpful to understand what the issue could be.
As far as I understand you only see the error if executing the test as a performance run - please correct me if I have misread the details. Have you tried to include a Wait for URL step? Will that change the execution of the performance test?
In case there is no change in the behavior, please collect the application log generated during the run and send for further investigation. You can use the following steps for reference how to collect a log with the necessary details:
- Ensure to enable and clear the log
- Start the performance run until you get the error
- Open the log and save it to a text file
- Send the generated records zipped
I hope that this will be sufficient for us to find out what might be going wrong. Thank you in advance for your cooperation.
Regards,
Elena
Progress Telerik
Hi Elena,
Attached is the log file that was generated. Please let me know if you need anything else. Also, would it be possible to schedule a GoToMeeting? I think that would make it easier for both of us to see what's going on. Thanks.
Hello Jose,
Thanks for the shared log - I reviewed this and noticed it is actually the execution log, which is also presented in the test list result. Still, it contains sufficient information for me to provide some suggestions.
Let me, first, share my assumption that the issue is not related to the performance test or test list execution - basically, a performance test in Test Studio uses a valid web test to measure the time required for each step execution. Having this in mind, I suspect that the test in question is failing to connect to the popup also if executed as a web test only.
Thus, my suggestion is to set aside the performance test list and focus on the web test itself and debug it. Can you, please, switch back to the Test tab and quick execute that same test to confirm if my guess is correct? Does the test fail with the same error?
Following this assumption, here are few things you can give a try to.
Option 1
I noticed the browser you used to run the test is Internet Explorer. If you intend to use only this particular browser, you can modify the Connect to popup step as follows:
- enable the isModalPopup checkbox
- enter the name of the window Caption
- if this doesn't change the behavior, you can try to increase the InitializationTimeIE property
Option 2
In case the above suggestion is not applicable for any reason, you can try the following modification of the Connect to popup step:
- restore the properties to the default recorded step - uncheck the isModalPopup and set back the InitializationTimeIE
- try to capture the first URL which is navigated to in the popup in question
- enter this URL in the PopupUrl property
- insert a Wait for URL step after the Connect to popup one
- enter the final URL expected in the popup as the url to wait for
Please, let me know of the outcome for the two options - such feedback will certainly help me in continuing the investigation.
Also, please let me know your time zone and availability for next week, in case the issue is still not resolved. Our available hours for a possible online meeting are between 12.00-3.00 PM GMT.
Thank you for your time spent in this discussion.
Regards,
Elena
Progress Telerik
Hi Elena,
I'm in the central timezone (cst) and am free pretty much all week after 10am. We can definitely schedule something for next week. However, after trying out your suggestions I just realized that the url in the pop-up always changes each time. I completely overlooked that part, sorry about that. It makes sense why the test fails each time. Honestly I'm not even sure if that can be captured. Is there a way to capture that?
Hi Jose,
Which is the always changing URL in the sequence of redirects? Do you mean this is the first URL to navigate to?
If so, you can then try to modify the Connect to popup step to use partial URL and thus leave only the static part of the web address. Will this change anything in the test execution behavior?
If the issue still persists and we need to schedule a meeting, I would like to know, if there is any morning next week which you can attend an online session in 8.00 AM CST? Due to the time zone difference this will be the suitable time frame for both sides.
Thank you for your time and cooperation once again.
Regards,
Elena
Progress Telerik
Hi Elena,
I got the test to run successfully in the tests tab but when I try to run a performance test, it doesn't go through all the steps in the test. Also, yes I would really like to schedule an online session. 8:00AM CST is ok on any day for me next week.
I really appreciate your help on this.
Hi Jose,
I am glad to know we managed to resolve one of the issues.
However the performance run is still not successful and I would like to continue the discussion on this topic. Can you, please, elaborate details on what results are generated from the performance run - on which step the execution fails and is there any error listed?
Can you generate the application log during that performance run and send it zipped for review? This will help me explore what might be going wrong and prepare for a meeting next week
I hope that Tuesday 10/29/2019 in 8:00 AM CST is still applicable for you. The meeting details below are set for that time, but if we need to reschedule, please let me know.
1434639 - Is there a way to capture multiple redirects?
Tue, Oct 29, 2019 8:00 AM - 9:00 AM CDT (4:00 PM - 5:00 PM EET)
Please join my meeting from your computer, tablet or smartphone.
https://global.gotomeeting.com/join/138114573
You can also dial in using your phone.
United States (Toll Free): 1 866 899 4679
United States: +1 (646) 749-3117
Access Code: 138-114-573
More phone numbers
Canada (Toll Free): 1 888 299 1889
Join from a video-conferencing room or system.
Dial in or type: 67.217.95.2 or inroomlink.goto.com
Meeting ID: 138 114 573
Or dial directly: 138114573@67.217.95.2 or 67.217.95.2##138114573
New to GoToMeeting? Get the app now and be ready when your first meeting starts:
https://global.gotomeeting.com/install/138114573
Thanks in advance for your cooperation.
Regards,
Elena
Progress Telerik
Hi Elena,
Yes, Tuesday at 8am CST works for me. Attached are the logs you requested. Please let me know if these are correct.
Thanks.
Hi Jose,
As far as I understand the performance test is failing on the Connect to popup step, although this now works fine in a web test run - is that correct?
The meeting details for Tuesday morning are listed below. Please, let me know if anything changes and we need to reschedule.
1434639 - Is there a way to capture multiple redirects?Tue, Oct 29, 2019 8:00 AM - 9:00 AM CDT (4:00 PM - 5:00 PM EET)
Please join my meeting from your computer, tablet or smartphone.
https://global.gotomeeting.com/join/138114573
You can also dial in using your phone.
United States (Toll Free): 1 866 899 4679
United States: +1 (646) 749-3117
Access Code: 138-114-573
More phone numbers
Canada (Toll Free): 1 888 299 1889
Join from a video-conferencing room or system.
Dial in or type: 67.217.95.2 or inroomlink.goto.com
Meeting ID: 138 114 573
Or dial directly: 138114573@67.217.95.2 or 67.217.95.2##138114573
New to GoToMeeting? Get the app now and be ready when your first meeting starts:
https://global.gotomeeting.com/install/138114573
Regards,
Elena
Progress Telerik
Hi Jose,
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.
Regards,
Elena
Progress Telerik