QTP回放iFrame控件时间非常慢的问题分析
2010-11-15 15:41
218 查看
最近在用QTP实现录制回放Web应用时,又碰到了iFrame这个对象。虽然我对开发中,这个对象的用法知道的不多,但是对这个对象回放非常慢,已经是我第二次遇到了,上次的客户那里,我没有找到什么好的办法,但这次偶然发现了一个折中的解决办法。
首先还是要抱怨一下,貌似网上就没有对这个问题的讨论贴,难道大家都那么好命,没有遇到?要不就是这本身就是一个很好解决的问题,不用这么大费周折? 不管了,记录下我的思路,留着用吧。
描述一下现象:
首先,录制是没问题的,iFrame对象和它包含的对象都能正确识别,当回放一个用到iFrame对象的页面的时候,如果当前的页面的载入状态是完成(IE左下角标识)的时候,识别是非常快的,回放也很快,对这个对象或对象里的对象的操作也马上会完成。
但是,如果当前页面的载入状态不是完成,而是剩下1项或2项,或者对于IE来说,右上角的棋子是飘动状态,而不是静止状态的时候,对这个iFrame对象的识别就非常慢,有时会持续到10~20分钟,虽然在界面上,这个对象以及他包含的对象,已经全部装载进来了。
分析:
出现这样的问题,我首先想到的,就是页面没有装载完,还剩下几项没有完成,所以QTP的步骤就一直在等待页面装载。可是从QTP识别对象的方式讲,1.它同步页面装载,是有time out限制的,一般是60s,但我设小后,对这个case也不起作用,我将一些对识别对象有影响的timeout时间都调小了,还是无济于事;2.QTP一般只要找到界面上的某个对象,马上就会对他进行操作,有时都不会等页面装载完成,这个时间快得有时都看不清楚。在这个case里,我肉眼已经清清楚楚的看到被操作的对象已经出现了,但QTP还是要等那么久。
这样的话,就有极大的可能,是页面还没有装载进来的那1项,2项,可能有问题了。不然为什么对“完成”状态的iFrame识别很好很快,对这种“剩下1项”的就出问题呢。
可是,从开发的角度讲,开发人员目前并不能定位出,出现这种“剩下1项”的问题在哪里,而且这样的问题,对用户在界面上的操作,的确不会产生任何影响,因为用户手动操作界面,他看到要操作的对象,直接点击,赋值之类的,不用管状态栏的“剩下1项”,也能正常操作,不会报任何错误。不过QTP就卡在这了。
由此看来,开发不讲其定位为缺陷,又要让QTP对这类功能加快回放速度(这种等待,对于脚本调试工作来讲,简直就是梦魇),只能找个折中的办法了,那就是 ————
一个偶然的操作,在界面中等待的时候,我点击了一下IE窗口的还原按钮,一下子就识别出来了,后面的操作一溜烟儿的就进行下去了。于是我在脚本中的那个需要等待的操作前,增加了一步对IE还原和最大化的动作,这样在回放时,每到这个位置,IE自动缩放一下,后面的动作就迅速的进行下去了。
这样,算是变相解决了这个问题,不过还是要反思的:
1. 我还没有在其他浏览器中尝试,不知道是不是问题依旧。如果其他浏览器也存在这个问题,就说明这种“剩下1项”的问题,是程序中一个潜在的问题,不知道他会不会引发更严重的问题,当然如果仅此而已,也就是仅仅会对QTP回放产生影响。如果其他浏览器没有这个问题,那么可以用IE录制,其他浏览器回放。不过也说明这个“剩下1项”的问题,开发没有对IE做好适配。
2. 究其深层次的原因,如果这个回放巨慢的问题,应用的内部bug引起的,那么这次我碰到的是“剩下一项”,而使用缩放IE可以解决,万一下次碰到的不是一个可以表露在外的现象,又或找不到折中解决的途径呢。不知道,如果是应用的问题,QTP能不能定位一下是哪的问题,或者如果是QTP识别的问题,能不能优化下它的识别策略呢。
期待以后更深入的研究吧
@版权所有,转载请注明
首先还是要抱怨一下,貌似网上就没有对这个问题的讨论贴,难道大家都那么好命,没有遇到?要不就是这本身就是一个很好解决的问题,不用这么大费周折? 不管了,记录下我的思路,留着用吧。
描述一下现象:
首先,录制是没问题的,iFrame对象和它包含的对象都能正确识别,当回放一个用到iFrame对象的页面的时候,如果当前的页面的载入状态是完成(IE左下角标识)的时候,识别是非常快的,回放也很快,对这个对象或对象里的对象的操作也马上会完成。
但是,如果当前页面的载入状态不是完成,而是剩下1项或2项,或者对于IE来说,右上角的棋子是飘动状态,而不是静止状态的时候,对这个iFrame对象的识别就非常慢,有时会持续到10~20分钟,虽然在界面上,这个对象以及他包含的对象,已经全部装载进来了。
分析:
出现这样的问题,我首先想到的,就是页面没有装载完,还剩下几项没有完成,所以QTP的步骤就一直在等待页面装载。可是从QTP识别对象的方式讲,1.它同步页面装载,是有time out限制的,一般是60s,但我设小后,对这个case也不起作用,我将一些对识别对象有影响的timeout时间都调小了,还是无济于事;2.QTP一般只要找到界面上的某个对象,马上就会对他进行操作,有时都不会等页面装载完成,这个时间快得有时都看不清楚。在这个case里,我肉眼已经清清楚楚的看到被操作的对象已经出现了,但QTP还是要等那么久。
这样的话,就有极大的可能,是页面还没有装载进来的那1项,2项,可能有问题了。不然为什么对“完成”状态的iFrame识别很好很快,对这种“剩下1项”的就出问题呢。
可是,从开发的角度讲,开发人员目前并不能定位出,出现这种“剩下1项”的问题在哪里,而且这样的问题,对用户在界面上的操作,的确不会产生任何影响,因为用户手动操作界面,他看到要操作的对象,直接点击,赋值之类的,不用管状态栏的“剩下1项”,也能正常操作,不会报任何错误。不过QTP就卡在这了。
由此看来,开发不讲其定位为缺陷,又要让QTP对这类功能加快回放速度(这种等待,对于脚本调试工作来讲,简直就是梦魇),只能找个折中的办法了,那就是 ————
一个偶然的操作,在界面中等待的时候,我点击了一下IE窗口的还原按钮,一下子就识别出来了,后面的操作一溜烟儿的就进行下去了。于是我在脚本中的那个需要等待的操作前,增加了一步对IE还原和最大化的动作,这样在回放时,每到这个位置,IE自动缩放一下,后面的动作就迅速的进行下去了。
这样,算是变相解决了这个问题,不过还是要反思的:
1. 我还没有在其他浏览器中尝试,不知道是不是问题依旧。如果其他浏览器也存在这个问题,就说明这种“剩下1项”的问题,是程序中一个潜在的问题,不知道他会不会引发更严重的问题,当然如果仅此而已,也就是仅仅会对QTP回放产生影响。如果其他浏览器没有这个问题,那么可以用IE录制,其他浏览器回放。不过也说明这个“剩下1项”的问题,开发没有对IE做好适配。
2. 究其深层次的原因,如果这个回放巨慢的问题,应用的内部bug引起的,那么这次我碰到的是“剩下一项”,而使用缩放IE可以解决,万一下次碰到的不是一个可以表露在外的现象,又或找不到折中解决的途径呢。不知道,如果是应用的问题,QTP能不能定位一下是哪的问题,或者如果是QTP识别的问题,能不能优化下它的识别策略呢。
期待以后更深入的研究吧
@版权所有,转载请注明
相关文章推荐
- QTP的那些事--QTP回放iFrame控件时间非常慢的问题分析
- 解决 my97 时间控件在iframe 下不能够准确对齐的问题
- 线程间操作无效: 从不是创建控件“Control Name'”的线程访问它问题的解决方案及原理分析
- 修正Raize的时间日期控件不能正确显示星期几的问题
- 粗心造成的小错误!时间控件使用时的问题!
- 修正Raize的时间日期控件不能正确显示星期几的问题
- 时间控件只读问题
- 封装my97时间控件成asp.net 时间控件,支持多语言,皮肤,时间大小限制,时间格式验证功能,非常强大。
- qtp时间控件的操作
- vs数据控件中时间显示问题
- 算法导论-最大子数组问题-线性时间复杂度算法分析与实现
- WebApp由于需要从Spring官网下载schema文件导致启动时长时间卡住问题的分析和解决
- Linux系统时间不准问题分析
- 【01背包问题】:动态规划、回溯法和分支限界法 三种算法的对比与分析(时间复杂度方面)
- 约瑟夫问题的数学角度分析 C 数组实现 循环链表实现 递归实现时间复杂度O(logN)
- recovery恢复工程设置的时候时间过长且有黑屏问题分析
- 关于mobiscroll时间控件没能正常绑定值问题
- 关于 $cordovaDatePicker 默认时间控件样式的问题
- Android ListView滑动过程中控件显示重复/错误问题之原理分析...
- 线程间操作无效: 从不是创建控件“Control Name'”的线程访问它问题的解决方案及原理分析