Ranorex Forum

Hi Team,

I have observed that script execution time is high in Ranorex, Like each test case, execution time is high compared to Selenium.
I am working on a web application. I don't have any delays in scripts and even modified inbuilt time as below

Mouse.DefaultMoveTime = 10;
Keyboard.DefaultKeyPressTime = 5;
//Delay.SpeedFactor = 1.0;

Bit still i didn't see any progress,

For me just for 25 cases, it is taking 1hr + time . In that meantime manual, we can do twice just for 25 cases.

Can you please help me on how to improve this?

Hi,

I’m afraid, there is not enough information regarding your problem, to provide a reasonable answer. Could you please answer some questions?

Ranorex version? Most recent is 9.0.1.
What web browser you are using?
Have you tried to add the webbrowser you are using to Ranorex whitelist? This could speed up things significantly.
Please post an example xpath you are using, ideally, also with Ranorex snapshot (NOT screenshot) of the page you are automating.

Hi ,

Thank you for response

Ranorex version? Most recent is 9.0.1. - - I am using 8.3 version
What web browser you are using? - I am using Chrome browser 74 Version
Have you tried to add the webbrowser you are using to Ranorex whitelist? This could speed up things significantly. - Tried but didn't see any improvement


Xpath example : .//input[@type='email']


Please find the attached snapshot.

"//" means search everything for this element. That's really slow. I would not do that. I would use a more precise path to the element rather than a vague wildcard such as that. Removing wildcards massively speeds things up in my experience.

Hi,

Selecting the absolute XPath what you are referring to as a more precise one is not recommended in the industry because UI is changing as the business requirement changes
If we select the absolute Xpath we again have to change all our repository items
It's always good to find out a unique element in the XPath and design a relative XPath (Its correct that it will take time but its robust)
So here to speed up the execution duration, we need to think of some other solution

Regards

You can try to find some elements or containers that don't change all the time.
as example:
1. //button[@automationid='btnEnter'] - slowest
2. /form[@processname='MyApp']//button[@automationid='btnEnter'] - slow
3. /form[@processname='MyApp']/container[@controlname='cntFrame']//button[@automationid='btnEnter'] - faster
4. /form[@processname='MyApp']/container[@controlname='cntFrame']/container[@text="Text"]/button[@automationid='btnEnter'] - fastest

mohan.pentyala wrote: ↑

Wed May 08, 2019 7:28 am

Ranorex version? Most recent is 9.0.1. - - I am using 8.3 version

From the snapshot you posted I see, you are using 8.3.0. This is really old and no longer supported version, not to mention, there are some nasty bugs in this version. If you cannot update to 9.0.1 yet, then use, at very least, 8.3.3. Debugging your problem with anything older is just a waste of time and energy.

mohan.pentyala wrote: ↑

Wed May 08, 2019 7:28 am

Please find the attached snapshot.

The snapshot you posted contains only Chrome "Form" element, and not the DOM element, which is critical for the page evaluation (along with the xpath you posted).

mohan.pentyala wrote: ↑

Wed May 08, 2019 7:28 am

Xpath example : .//input[@type='email']

The xpath you posted is too broad. As already mentioned by Stub, such path may really slow the speed of search. If all xpaths in your repo look like this, then it's the most probable reason why it takes so long to find elements in your app. I agree with you, that using absolute xpaths is no go, because they may change at any time in future. However, Ranorex settings offers some great xpath generation presets (I would suggest to use StepCostReduce), plus some advanced options to change the xpath generation behaviors. So I would recommend you to explore these options and let Ranorex to construct the xpaths for you. Of course, a manual xpath optimization is almost always required, but removing all preceding elements from the xpath is definitely not the right approach!