关于QTP的移植

wtucel

感觉QTP的移植真的很不爽，高手指教下该怎么来做比较合适吧

1、同一个页面，有时候录制出来名字为“browser”，有时录制出来又不是，虽然可以在对象库里改名，但是为什么会这么不稳定呢？

2、有时回放的时候经常找不到对象，但是页面的界面也没变化，重新录了一下那个页面发现那个页面从以前的名为”browser“变成了”browser_2“，在对象库里又多了个browser出来，这种情况最容易发生在弹出的页面中，感觉QTP太傻了点

对于第2种情况感觉很无奈，必须要对整个脚本重新录过才行，只是增加识别不了的还不行。

大家说说怎么办吧？别指望描述性语言了，系统那么复杂，全用描述性来做是不现实的。

winfood

这是对象识别问题，不是移植性问题。这个问题已经被讨论多次了，通过更改QTP的识别对象设定应该可以解决，LZ在坛子里搜一下就行了。
很不赞同“系统那么复杂，全用描述性来做是不现实的。”，越是复杂系统才越需要描述性编程。业务逻辑复杂的时候，用录制回放将降低测试工作的效率。
以登陆测试为例，仅仅靠录制回放只能把所有的Case分成多个Case，或者分成重复的多个Action才能达到目的。而描述性编程很容易就可以把这些重复的测试步骤归纳为带有条件分支的一个统一的Case。

yangkinki

如果QTP 不按照这些对象、属性去识别的话，那么QTP本身测试就没有意义了，说不定QTP测试的都是错误的结果，因为QTP进行了错误的识别，错误的操作， 自动化测试，维护起来是有些麻烦，所以要求系统相对稳定之后才启用自动化测试。

yabest

原帖由 winfood 于 2007-6-15 21:29 发表
这是对象识别问题，不是移植性问题。这个问题已经被讨论多次了，通过更改QTP的识别对象设定应该可以解决，LZ在坛子里搜一下就行了。
很不赞同“系统那么复杂，全用描述性来做是不现实的。”，越是复杂系统才越 ...

>>很不赞同“系统那么复杂，全用描述性来做是不现实的。”，越是复杂系统才越需要描述性编程。
还是要尽量避免描述行编程吧，把脚本复杂了，是无益的。
谁愿意看你的脚本里写了一大堆属性条件啊，晕。
还是尽量把属性条件塞入仓库里，关上门，让外面的脚本干干净净，漂漂亮亮的，看起来多爽快啊！

>>业务逻辑复杂的时候，用录制回放将降低测试工作的效率。
不一定要录制才能将对象加入仓库，我就经常直接抓取对象放入仓库，然后手工写脚本


其实仓库对象和描述性编程的道理是相通的，只是方式不同而已，两种方式基本能互换。
描述性编程有其独特的用处，但真正需要用它的地方还是很少的！

对象仓库是QTP的精华所在！
不仅可以统一存储对象特征，避免在多处脚本里重复定义对象特征；
还可以将复杂的对象特征设置屏蔽在仓库里，保持脚本的简洁，美化脚本，增加可读性和可维护性。

所以可以的话，还是尽量多用对象仓库，少用描述性编程。

[ 本帖最后由 yabest 于 2007-6-16 12:33 编辑 ]

winfood

原帖由 yabest 于 2007-6-16 11:33 发表


>>很不赞同“系统那么复杂，全用描述性来做是不现实的。”，越是复杂系统才越需要描述性编程。
还是要尽量避免描述行编程吧，把脚本复杂了，是无益的。
谁愿意看你的脚本里写了一大堆属性条件啊，晕。
还 ...

sdlkfj4 是我没有说清楚，还是LS会错意了？描述性编程好像被LS理解成了“描述对象而不用对象仓库”的编程。
Browser("title:=***")的确属于这种类型，但是描述性编程不仅限于此吧。假如对象都在对象仓库里面，下面的这组语句不算描述性编程吗？
If Browser("***").Page("***").WebElement("***").Exist(*) Then
...
Else
...
End If

QTP里面把脚本开发方式大体分成了两类，录制回放(Record/Playback)和描述性编程(Descriptive Programming)。我觉得录制回放和描述编程是相辅相成的，适用的方法是最好的。我的想法和LS的没有什么区别，实际使用的开发方式也差不多，就是对象仓库+手工脚本开发。LS不觉得这种开发方式是描述性编程吗？
虽然没必要和一个概念过不去，我还是查了一下QTP帮助（谁让咱是QA呢）。QTP的确把对象仓库+手工脚本的方式归为描述编程里面了。sdlkfj2
描述性编程仅仅是针对录制回放而言的，一个主要是Expert View里面以编程方式开发脚本，另外一个则是在Keyword View里面以录制回放和编辑属性等方式开发脚本。

同意LS的对象仓库观点（QTP的精华就在对象仓库上），正确的使用对象仓库才能保证测试项目的效率。

[ 本帖最后由 winfood 于 2007-6-16 13:41 编辑 ]

yabest

原帖由 winfood 于 2007-6-16 13:29 发表


sdlkfj4 是我没有说清楚，还是LS会错意了？描述性编程好像被LS理解成了“描述对象而不用对象仓库”的编程。
Browser("title:=***")的确属于这种类型，但是描述性编程不仅限于此吧。假如对象都在对象仓库里 ...

晕了晕了，在我的印象里，我到过的论坛里，见过的帖子里，描述性编程都是指“不用对象仓库，直接用脚本描述对象”的。

怎么突然“描述性编程”变成是“手工写脚本”了，是跟“录制脚本”相区别的了？

看来得找个时间，好好查一下这概念！

winfood

原帖由 yabest 于 2007-6-16 16:16 发表


晕了晕了，在我的印象里，我到过的论坛里，见过的帖子里，描述性编程都是指“不用对象仓库，直接用脚本描述对象”的。

怎么突然“描述性编程”变成是“手工写脚本”了，是跟“录制脚本”相区别的了？

...

sdlkfj1 不好意思，是我理解错了。刚刚查了一下QTP帮助，补了一点儿钙。
描述性编程的确是利用对象属性识别对象而非对象仓库保存对象。在QTP的帮助里面有几段说明：
Such a programmatic description can be very useful if you want to perform an operation on an object that is not stored in the object repository. You can also use programmatic descriptions in order to perform the same operation on several objects with certain identical properties, or in order to perform an operation on an object whose properties match a description that you determine dynamically during the run session.
[描述性编程可以用于识别对象仓库中未保存的对象，识别某个属性相同的几个对象，或者识别属性值在运行过程中动态决定的对象。]
There are two types of programmatic descriptions. You can either list the set of properties and values that describe the object directly in a test statement, or you can add a collection of properties and values to a Description object, and then enter the Description object name in the statement.
[编程式描述有两种，一种是在测试语句中使用对象的属性和属性值对，另外一种是把属性和属性值集合加入一个Description类型的对象然后在测试语句中使用这个对象。]

[ 本帖最后由 winfood 于 2007-6-16 16:48 编辑 ]

wtucel

今天在我脚本中引入了描述性编程，确实解决了很多问题，比如弹出窗口识别的问题，而且在我的脚本里有很多对页面的操作实际是相同的，因此，我把对弹出窗口的那部分描述性编程放在一个子过程sub中，后面的地方再调用这个过程，大大简化了我的脚本，但是我觉得如果全部都使用描述性编程来实现还是很麻烦的，我现在真的是两种方法夹杂起来用，相铺相成，提高了不少的效率。

fanzhikang_2002