Sometimes a simple IE Page wont be loaded in scheduled test script

Hi Mathys,

What you describe is likely an IE hang. IE hang happens in some cases when IE is being run under the ESM Recorder, and the exact reasons for the hang are not always known.With that said, I can offer you two solutions, one sometimes helps in just a pretty narrow case, the other in my experience always brings good results, but requires a significant rigorous effort.

I also like to clarify that IE hangs do not happen with most HTML applications, so these recommendations are only for monitoring applications that do expose IE hangs when run under the Recorder.

Approach 1.

This one might help if the problem happens only during loading the application’s first page, but after that IE works fine. This solution usually helps when the Web application requires loading a lot of additional modules (plug-ins, custom fonts, etc.), but, as I mentioned earlier, this solution might not help, since you cannot know if you experience exactly this problem. I still like to mention it since it’s easier to implement than another approach.

The idea here is to:

• Start IE with loading the page but without checking IE’s ready state before starting the first transaction.
• Wait for some time that would guarantee that page is loaded.
• Start a transaction.
• Force reloading page without cache by sending {Ctrl {F5}}.
• Wait for a condition that would indicate that the page has been displayed.
• Finish the transaction.
  

The code might look approximately like this:

LaunchToPage "http…", False
Sleep 15 ' assume that it is guaranteed that IE starts and loads the page within
15 seconds

StartTrace "Transaction1"

IEWindow("Internet Explorer MainWindow").Type "{Ctrl {F5}}"

WaitFor…StopTimerAndTrace "Transaction1"

Employing some elements of the second approach might help too.

Approach 2.

This approach is based on avoiding scripting elements that are known from experience to cause IE hangs. Such areas include:

• Interrogating IE ready state. Check the signatures of the Framework functions you are using, many of them have a parameter to avoid waiting for IE to be redy, which eliminates such checks, like the second parameter in LaunchToPage finction in the approach above.
• Using the Recorder text capture functionality. This includes Framework functions like WaitForText, and Recorder functionality, like .CaptuteText .TextExists properties, screen events, text checks.
• Using HTML controls. This means all methods whose names start with HTML and all objects whose names start with THTML should not be used.
  

To avoid the areas listed above you should:

• Always reference an IE frame window (please see https://msdn.microsoft.com/en-us/library/5c2fsa5a.aspx if you need explanation of what "frame window" means); if you have only one, then IEWindow("Internet Explorer MainWindow") is all you need.
• When you need to wait for synchronization or time measurements, rely on OCR and image recognition-based functions. You may also use selecting text and putting it onto the clipboard and monitoring the title of the IE frame window. The Framework contains quite a few examples on using such wait functions.

Once again, this approach proved to deliver when IE hangs become a problem. It requires more effort for script development. One of the reasons for that that is, well.., you cannot use Recorder’s recording functionality. This is why I’d recommend it only when IE hangs are indeed is a problem.

Please post any questions regarding the approaches above. This, of course, includes doubts if specific Framework or Recorder functionality would be appropriate for the approach 2.

Thank you,

Yuriy

Can you confirm the highlighted field is NOT selected for your Agent Manager? If it is, could you try deselecting it and see if that clears it up?

Hi Mathys,

DNS is apparently not the culprit in your case, but the last report gives several errors that could be of interest: no response error and proxy authentication error. I would assume that something about security policies or Internet Explorer configuration may be impeding your tests.

I’m wondering what happens when you try to run the test manually, i.e. try to open the page in Internet Explorer, does it improve on a second attempt? Does it work any better when you open the same page in a different browser such as Firefox or Chrome?

Try to disable Compatibility View also for intranet sites: Tools > Compatibility View Settings, and if it’s acceptable, disable Protected Mode/Enhanced Protected Mode, since it may block some of the scripts from downloading.

Regards

Tomasz