qtp基于界面测试的硬伤，如何克服？

volvoo

软件版本演进，界面不可避免要调整，如果您的软件要管理物理设备，如果您的软件运行过程中依赖于其他系统的数据来显示界面，每次测试界面和数据都是不同的，这时候qtp显得多么无力，越发感觉仅仅是一个能够截获消息循环的小工具，借助ms vb脚本引擎包装了些易用的功能. 不知道大家是否有同感？

如何克服界面依赖的硬伤呢？大家可以发表高见

yabest

只要界面元素是QTP识别的，只要界面变化是有规律的，那QTP就能操作它呀！不懂LZ的意思。

风过无息

楼主说:每次测试界面和数据都是不同的?
问题:每次变化有规律 吗?

wtucel

我也觉得QTP有些无奈，回归测试的时候经常找不到对象，而界面并没变化，重新录制后发现以前名为browser的窗口变成了browser_2，然后整个脚本都要重录了。

winfood

3楼问的很好，我也没明白LZ说的“测试界面和数据每次都不同”是什么意思？如果被测试的对象变化这么频繁，恐怕手工测试都难以保证质量了sdlkfj2
对于一个UI功能测试的自动化测试工具来说，界面依赖恐怕是不可避免的。

克服“硬伤”不能靠工具本身，而是使用工具的人。如果LZ感觉QTP不好用，不妨换个角度看问题。
有没有其他工具比QTP更好？
QTP到底适不适合当前项目和被测对象？
使用QTP能否带来效率提高？

个人感觉QTP比较适合的项目有如下特点：
开发的应用程序或系统足够的规模；
在应用程序或系统的生命周期内功能稳定，并且周期性的更新和升级；

yabest

原帖由 wtucel 于 2007-6-15 20:26 发表
我也觉得QTP有些无奈，回归测试的时候经常找不到对象，而界面并没变化，重新录制后发现以前名为browser的窗口变成了browser_2，然后整个脚本都要重录了。

这个是你没研究透QTP，很好解决的。

[ 本帖最后由 yabest 于 2007-6-15 22:29 编辑 ]

wtucel

回楼上的，我接触QTP的时间确实短，都是自己摸索出来的

在录制脚本这方面很多感觉不是很规范，像我上面说的问题如何去解决呢？

还有像录制脚本时，对对象的规范有什么好的建议么？

Jimmyshao

原帖由 wtucel 于 2007-6-15 20:26 发表
我也觉得QTP有些无奈，回归测试的时候经常找不到对象，而界面并没变化，重新录制后发现以前名为browser的窗口变成了browser_2，然后整个脚本都要重录了。

这是QTP的Smart identify功能，可以Disable掉的.

wtucel

谢谢LS的，找到了，在tools->Object Identification里

我现在再试试会不会出现重复识别的问题。

[ 本帖最后由 wtucel 于 2007-6-16 23:27 编辑 ]

lovelovecat

原帖由 Jimmyshao 于 2007-6-16 00:37 发表



这是QTP的Smart identify功能，可以Disable掉的.

请问这种方法是怎么造成的呢,为什么用这种方法就能解决掉呀,谢谢啦

volvoo

个人感觉还是理解qtp的精髓了，开发的脚本在不同版本间基本能够平滑迁移
我觉得，如果mercuy或者第三方，开发一些方便识别的例程代码，所有定制的控件只要套用一下代码，
甚至拷贝一下，这样，前后台结合到一起识别起来威力更大

kursk

我认为LZ的这个问题其实i搞错了方向

试想一下如果是一个人，第一次面对一个换了对象的系统一样无所是从，QTP和人的识别原理是一样的，而且也应该一样！！！因为如果QTP能够做人不能做的事，那么QTP就可能将BUG遗漏——因为它可以发现人看不见的东西！

所以问题不在于QTP不够灵活，而在LZ所要测试系统居然总是在改变页面!是否应该反思一下自己的开发管理有些问题？减少重复和浪费性的工作

另外我建议采用编写脚本，而不是录制方式，将会减少QTP重复识别的问题写脚本，而不是录制方式，将会减少QTP重复识别的问题

[ 本帖最后由 kursk 于 2007-6-18 23:06 编辑 ]