UFT takes too long to execute steps

Question

UFT takes more than 5 minutes to execute steps while timeout is set to 10 seconds. It only happens in some web pages, other scripts do it almost inmediately.

Answer 1

This sounds like a smart-identification issue, if this is the case, the report should show that the step was replayed using smart id.

You should fix the description of the object, or, if you want the test to fail in this scenario, disable smart identification.

Answer 2

While smart identification might be the issue here, others come to mind that are not as easy to solve:

FRAMESETs. If you are not using IE but Chrome or Edge, there are constellations where every UFT interaction (reading or writing) with the webpage will hang for about 15 seconds (but finish correctly) if the webpage contains a FRAMESET element.

Modal dialog boxes. If a messagebox (a la VBScript MsgBox or JavaScript altert()) exists, similar things happen: On Edge/Chrome, every UFT interaction with the webpage generates a 15 second freeze/hang then. On IE, it generates unwanted focus/defocus operations which also take time (but not as much as 15 seconds).

We've tracked this down to UFT sending a message (JavaScript message, I think) to the webpage, and waiting for the reply message times out because the reply message should be generated by JavaScript code injected by the UFT browser extension (I think), but the reply message is not sent for some reason (this I know for sure).

MicroFocus used to say FRAMESET is unsupported for Edge and Chrome. (Above facts have been digged out using hardcore debugger sessions inspecting browser message traffic, and more, i.e. they are not ack'd by MicroFocus.) That note is gone, but the fact persists. Only fix: Eliminate FRAMESET, or stick to IE (which is not a real option).

The messagebox issue I have not brang up to MicroFocus (yet). They have notes in their documentation that say the extension is blocked by the modal dialog when you start an app that initially displays such a dialog, so this might be similar issues with modal dialogs that apply here as well.

RegisterUserFunc. If you use it, earlier UFT versions (upto 14.52) had a huge performance penality if you call the registered function as a method AND have a lot of library code in total (6 seconds overhead per call if you have thousands and thousands of lib code lines). Later versions (15.02, I think) eliminated this but moved the delay to the RegisterUserFunc instead, so every RegisterUserFunc call takes many, many seconds if you have a lot of lib code. Meaning that startup can take minutes (!). Microfocus got that demonstrated by us, but did not fix that for us because they said it is untypical to have many thousand lib code lines active. I disagree, but what does it help? My consequence was: Eliminate all dependency on RegisterUserFunc (had to modify all registered method calls to function calls).

Finally, we see a huge performance penalty when we compare 14.52 to 2021R1; everything is slower for no apparent reason. MicroFocus says this is by design because they added features which complicate what UFT has to do. So they say it's ok. I don't share this opinion. Our tests take almost twice as long just after upgrading to a newer version. (Unfortunately, switching from 14.52 to 15 included switching from Windows 7 to Windows 10, so it might be that Windows 10 contributes to the performance penalty as well.) I think it is a shame that this is not taken seriously.

Your issue might just as well have some other cause. To dig it out, we would need to see the script and get info about the app.