关于UI Automation中Cache性能的疑惑

之前花了数周的时间搭了个基于UI Automation的自动化框架。期间发现一个问题,当被测试程序中的element非常多的时候,恰巧要寻找的element位于tree的末端的话,可能性能会比较的低(不知道微软对FindFirst方法有没有做性能上的优化)。于是乎想寻找有没有效率比较高的方法,在MSDN中查询了一下,发现提供了Cache的功能(链接)。后来才发现高效的原理是在进行FindFirst之时将element相应的propertypattern进行cache处理,以后再对elementpropertypatter进行查询的时候会比较高效,而且还特别强调了对与服务器相连的WPF程序特别有效。虽然和我本意有点出入,但是也算个提高效率的技能,研究一下先:

编写了个两个函数,一个采用了cache,另一个没有,功能都是寻找被测试程序上的一个element,然后再得到其property(选择得到其property的结果也类似),来看看其效率到底差多少。为了使其结果更加明显,故采用了循环来进行高次数访问下的效率区别。

class Program

{

        static void Main(string[] args)

        {

            AutomationElement aeDesktop = AutomationElement.RootElement;

            AutomationElement appElement = aeDesktop.FindFirst(TreeScope.Children,

                new PropertyCondition(AutomationElement.AutomationIdProperty, "_RVMainWindow"));

 

            SearchElememtWithoutCache(appElement);

            SearchElementWithCache(appElement);

 

            Console.ReadLine();

        }

 

        static void SearchElememtWithoutCache(AutomationElement appElement)

        {

            Stopwatch stopwatch = new Stopwatch();

            AutomationElement aeName =

                    appElement.FindFirst(TreeScope.Subtree,

                    new PropertyCondition(AutomationElement.AutomationIdProperty, "name"));

            stopwatch.Start();

            string nameID="";

            for (int i = 0; i < 10; i++)

            {

                nameID = aeName.Current.AutomationId;

            }

 

            stopwatch.Stop();

            Console.WriteLine("Without cache used milliseconds: " + stopwatch.ElapsedMilliseconds);

        }

 

        static void SearchElementWithCache(AutomationElement appElement)

        {

            Stopwatch stopwatch = new Stopwatch();

            stopwatch.Start();

 

            CacheRequest cacheRequest = new CacheRequest();

            cacheRequest.AutomationElementMode = AutomationElementMode.None;

            cacheRequest.TreeFilter = Automation.ControlViewCondition;

            cacheRequest.Add(AutomationElement.AutomationIdProperty);

 

            AutomationElement aeName = null;

 

            using (cacheRequest.Activate())

            {

                aeName =

                    appElement.FindFirst(TreeScope.Subtree,

                    new PropertyCondition(AutomationElement.AutomationIdProperty, "name"));

            }

 

            stopwatch.Start();

            string nameId="";

            for (int i = 0; i < 10; i++)

            {

                nameId = aeName.Cached.AutomationId;

            }

 

            stopwatch.Stop();

            Console.WriteLine("With cache used milliseconds: " + stopwatch.ElapsedMilliseconds);

 

        }

}

 

运行结果如下:

·         进行10次循环:

Without cache used milliseconds: 2

With cache used milliseconds: 310

·         进行100次循环:

Without cache used milliseconds: 23

With cache used milliseconds: 312

·         进行1000次循环:

Without cache used milliseconds: 252

With cache used milliseconds: 305

·         进行10000次循环:

Without cache used milliseconds: 2430

With cache used milliseconds: 315

结果令我大吃一惊,在elememt被的属性被访问1000次之前,其效率都是差于普通方式访问的,当访问次数达到10000次的时候,其效率的提高的是比较明显的,难道说如果被测试程序element操作次数少于1000次的话,不建议采用cache?不知道事实的真相是不是如此!

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值