Improving the performance of your Coded UI tests

  • Article

Today, we have a guest post from Deepak Mittal, our CSS rep who was recently involved in a case where he helped a customer get significant perf gains in their Coded UI test.

Few recommendations that you could try for improving the performance of your CodedUI tests in VS2010 are :

1. If you are trying to run the test for multiple times for recorded action, avoid using for loop as it may result in stale objects being used second time and as a result giving performance hit, it is always suggested to use Ordered test or load test. Ordered test: https://msdn.microsoft.com/en-us/library/dd286704.aspx It guarantees that the other tests will run in the defined sequence.

2. While recording the test for web site application, you may see lots of additional mouse hovering actions recorded with menu items which might not be related to actual recording and testing, this is due to the reason that the recording engine looks for property changes during mouse moves to figure out if there’s a need to record hover. Since the engine is tweaked to perform on different websites, sometime the default setting used results in lots of extra hovers being recorded. However there is config which can be tweaked to reduce the amount of hovering on menu items. 

Set the below values as per your need in CodedUITestBuilder.exe.config:

<add
key=”ImplicitHoverLevel” value=”1”> No hovers will be recorded.

<add
key=”ImplicitHoverLevel” value=”14”> (OR’ed 2,4,8 will not consider css class name change for recording hover, plus will look for hover changes within a restricted window of mouse hover event and mouse move event). To get more detail about this, refer the blog from one of our product group member: https://blogs.msdn.com/b/shivash/archive/2011/01/24/hover-recording-in-coded-uitest-builder-and-microsoft-test-manager.aspx              
Note: You can also at the recorded action and remove the mouse hovering event manually, but it will be your responsibility to ensure the validity.

 3. If you want to speed up your tests, you could try switching off smart match and instead tweak the code to locate the exact control with title and window” Read about smart match concept in CodedUI: https://blogs.msdn.com/b/vstsqualitytools/archive/2009/08/10/configuring-playback-in-vstt-2010.aspx and https://blogs.msdn.com/b/mathew_aniyan/archive/2011/03/01/smart-match-amp-slow-coded-ui-tests.aspx

 4. To check if your test is really using smart match, enable the verbose logging for CodedUI testing and check for something like this in the logs:

W, 8748, 6, 2011/03/01,
08:28:28.195, 155961250575, QTAgent32.exe, Playback - [WARNING] Internal
warning: Window with Class "WindowsForms10.Window" and Title
"Application v1.0.1.3" was not found, so similar window with Class
"WindowsForms10.Window.8.app.0.2bf8098_r13_ad1" and Title
"Application v1.0.2.0" was accepted.

This would mean that smart match was used to find windows.

5. Wait for ready is a playback setting that you can tweak to get performance gains. Seehttps://blogs.msdn.com/b/mathew_aniyan/archive/2009/08/10/configuring-playback-in-vstt-2010.aspx for more details. Configuring the timeout on this will help tune the test execution time: https://msdn.microsoft.com/en-us/library/gg131072.aspx

Comments

  • Anonymous
    September 06, 2011
    this is really working and got rid of lots of overheads , would like to hear more about this.

  • Anonymous
    October 03, 2011
    Good Article ... I am now constantly checking the logs to make sure the controls are found without using smart match... some test that were taking several minutes are now down to 35 seconds or so. Thank You!

  • Anonymous
    October 28, 2013
    Very helpful. Need to close tag /> :)