引用:

原帖由 ppent 于 2007-8-10 22:33 发表
对象库和描述性编程都是基于对象识别原理上的应用，两者在识别原理上是一致的，唯一的差别是对象库比描述性的对象识别多了一层封装，正如高级语言对于汇编语言。也正是如此，所以在使用上有信手拈来的感觉。
在应用技术上，关键字视图大大降低了用户的技术门槛，而相对来说，描述性编程灵活一些。
两者并非决然对立，而是相辅相成，共同构成了一个功能强大、有竞争力的工具。
最后引用魔兽世界中流行的一句话：没有垃圾的种族或职业，只有垃圾的玩家。大家体会一下这句话

我不喜欢你这种和稀泥的说法，这样子说只会让初学者更迷惑更无所适从，甚至走上歧路！

就像你说的，对象库和描述性编程，就像高级语言和汇编语言的关系，一个简单高效，一个繁琐低效。
现在编程都首选高级语言，只有特殊的高级语言无法实现的地方，才用汇编语言，否则就是自找苦吃！

每种技术都有特点和适用范围，你应该跟初学者说明清楚，好让他们知道该如何选择。
而不是跟初学者说一通“两者并非决然对立，而是相辅相成，共同构成了一个功能强大、有竞争力的工具”、“没有垃圾的技术，只有垃圾的使用者”，这样的说法表面看起来是绝对正确，但实质上却是最没用的废话，说了跟没说一样，甚至比没说还误导人家！

我不希望有初学者看了你这样的说法后，一头栽进汇编语言（或描述性编程）的泥潭里，再也无法出来！

[ 本帖最后由 yabest 于 2007-8-11 03:19 编辑 ]

引用:

原帖由 ppent 于 2007-8-10 22:33 发表
对象库和描述性编程都是基于对象识别原理上的应用，两者在识别原理上是一致的，唯一的差别是对象库比描述性的对象识别多了一层封装，正如高级语言对于汇编语言。也正是如此，所以在使用上有信手拈来的感觉。
在 ...

强烈赞同,感觉去争论是用编程描述还是录制回放没有什么意义,存在即是合理,两者相铺相成,讨论这还不如讨论什么时候用录制回放什么时候用编程描述的方式.

引用:

原帖由 wtucel 于 2007-8-11 11:08 发表



强烈赞同,感觉去争论是用编程描述还是录制回放没有什么意义,存在即是合理,两者相铺相成,讨论这还不如讨论什么时候用录制回放什么时候用编程描述的方式.

对，要讨论清楚，什么时候用高级语言，什么时候用汇编，免得让初学者糊里糊涂的，大多时候都用汇编，少数时候才用高级语言，全颠倒了！

[ 本帖最后由 yabest 于 2007-8-11 14:24 编辑 ]

引用:

原帖由 loho1968 于 2007-8-3 13:20 发表

>>QTP对对象的识别和处理，关键在它对运行对象的识别和操作
就是说，QTP可以识别更多的对象，可以对这些对象进行更多的操作，比如，WR对网页的支持就没有QTP好，但WR的对象管理与QTP的对象管理没有本质上的区 ...

求这个识别对象为XML的工具,呵呵

引用:

原帖由 yabest 于 2007-8-11 14:18 发表


对，要讨论清楚，什么时候用高级语言，什么时候用汇编，免得让初学者糊里糊涂的，大多时候都用汇编，少数时候才用高级语言，全颠倒了！

兄弟不要极端了, 比如B/S系统的测试,大量的对象都是动态生成,增加一个记录,生成一个链接,表格增加一行,这些动态的东西太多了,不用描述性编程,参数化以后根本不能流畅运行.

比如 Link("text:="&datatable.value("职员",dtLocalSheet))可以对应页面上的某员工链接,录制的化只能针对这一个员工有效, 要匹配datatable里大量的员工,只能描述性编程.

所以不用录制的方式,是不影响自动化测试流程的,但是不使用描述性编程,往往很多流程根本无法覆盖.

[ 本帖最后由 danmy 于 2007-8-11 16:17 编辑 ]

引用:

原帖由 danmy 于 2007-8-11 16:16 发表

兄弟不要极端了, 比如B/S系统的测试,大量的对象都是动态生成,增加一个记录,生成一个链接,表格增加一行,这些动态的东西太多了,不用描述性编程,参数化以后根本不能流畅运行.

比如 Link("text:="&datatable.value("职员",dtLocalSheet))可以对应页面上的某员工链接,录制的化只能针对这一个员工有效, 要匹配datatable里大量的员工,只能描述性编程.

所以不用录制的方式,是不影响自动化测试流程的,但是不使用描述性编程,往往很多流程根本无法覆盖.

你可能对象库用的不熟吧，对象库一样可以动态设置的，一样可以解决问题！

只要动态设置一下对象属性
Link("职员").SetTOProperty("text", datatable.value("职员",dtLocalSheet))

然后就可以反复的使用此对象了
Link("职员").Click
...
Link("职员").Click
...
Link("职员").Click


总结下描述性脚本的三大罪状：
一是写脚本效率底下容易出错。
二是脚本繁杂难看，充斥着复杂的属性描述。不像对象库方式那样，把复杂的属性描述封装在对象库里，只留给脚本一个清晰易读的对象名。
三是对象描述分散重复，每处脚本都要重复描述一遍对象。对象一变，天才知道要修改多少处的脚本，要修改哪些行的脚本。

QTP推出对象库，就是为了解决这些问题的！
所以要尽量多用对象库，少用描述性。

不知道你是怎么看待和解决这些罪状的？

[ 本帖最后由 yabest 于 2007-8-11 17:02 编辑 ]

jackymail的帖子貌似都有舌战的说……
QTP的精华就是对象库。能用对象库的尽量用对象库。
我自己就用9.0自带的那个例子做了一个插入订单，然后再删除，再试着去打开刚删除的订单号，代码太多了，很不方便！
引用一位QTP高手的话：学习和使用QTP，多使用spy和F7(Step Generator)!
yabest每次都好像很激昂的控诉描述性编程罪状的说……sdlkfj5

[ 本帖最后由 MarsNoNo 于 2007-8-11 19:55 编辑 ]

引用:

原帖由 MarsNoNo 于 2007-8-11 19:49 发表
...
yabest每次都好像很激昂的控诉描述性编程罪状的说……sdlkfj5
...

呵呵，见笑了！sdlkfj1

我现在正在尝试写 描述性编程

谁可以教教我们啊

谁有很好的资料啊

dddddddddddd

ddddddddddddddddddddddddd

你勇于辩论的精神我很佩服，但极端的方式并不会给讨论交流带来良好的解决。现在很多事情，都没办法也不应该一句话对和错去判定的。
要不我们换个角度来交流吧，也别列举什么罪状了，在什么情况下使用对象库，什么情况下使用描述性编程更合适。

QTP只不是一个工具,任工具都有一定的极限性.
      用对象库或用描述性编程,我觉得要看个具体公司的情况来说.如果公司有专门自动测试人员,会有一套相应的规定.因为自动化测试人员不一定非常明白第个项目的每个流程.如果没有专门的自动测试人员.那在许多项目中,您又要如何让自动化测试来节省自己的测试时间和工作呢?还有一点是:如何去管理众多的对象库和脚本?

引用:

原帖由 ppent 于 2007-8-13 09:55 发表
你勇于辩论的精神我很佩服，但极端的方式并不会给讨论交流带来良好的解决。现在很多事情，都没办法也不应该一句话对和错去判定的。
要不我们换个角度来交流吧，也别列举什么罪状了，在什么情况下使用对象库，什 ...

真奇怪了，我讨论问题都是摆事实讲道理，有理有据的，怎么就被说成是极端了，不利交流了？
难道要放弃自己的观点，当和事佬，和稀泥，才不是极端？

我列的罪状，其实就是描述性的缺点，对象库的优点。
你也可以列出描述性的优点，对象库的缺点。
然后就可以对照双方的优缺点，衡量一下，就很容易得出哪些情况下用对象库好，哪些情况下用描述性好了。

引用:

原帖由 danmy 于 2007-8-11 15:50 发表

求这个识别对象为XML的工具,呵呵

QTP9.2就支持把共享对象库保存为XML

[quote]原帖由 yabest 于 2007-8-11 17:00 发表


你可能对象库用的不熟吧，对象库一样可以动态设置的，一样可以解决问题！

只要动态设置一下对象属性
Link("职员").SetTOProperty("text", datatable.value("职员",dtLocalSheet))
>>这是非常好的解决办法，这个方法实际就是动态的改变对象的Description的值

总结下描述性脚本的三大罪状：
一是写脚本效率底下容易出错。
>>这个不对，如果程序结构设计好，描述性编程中对对象的处理部分一样可以封装。
二是脚本繁杂难看，充斥着复杂的属性描述。不像对象库方式那样，把复杂的属性描述封装在对象库里，只留给脚本一个清晰易读的对象名。
>>描述性编程一样的可以只留给脚本一个清晰易读的对象名，对象库的对象要清晰易读还得在识别后手工修改。
三是对象描述分散重复，每处脚本都要重复描述一遍对象。对象一变，天才知道要修改多少处的脚本，要修改哪些行的脚本。
>>描述性编程一样的可以集中处理生成需要使用测试对象，如果要修改，同样只修改一个地方。描述性编程一样可以使用SetTOProperty。

QTP推出对象库，就是为了解决这些问题的！
>>QTP对象库确实有它方便的地方，比如是基于对象的使用，当你输入vbwindow(后，就需要列出当前Action中你可以使用的vbwindow对象，而描述性编程就不能，你需要记住可以使用的对象。
所以要尽量多用对象库，少用描述性。
>>如果是针对软件测试这个目标，使用什么方式不是最重要的，关键在于你是否掌握了，能否熟悉的运用，并达成的你的目标，结果才是最重要的。

引用:

原帖由 loho1968 于 2007-8-13 12:13 发表
[quote]原帖由 yabest 于 2007-8-11 17:00 发表


你可能对象库用的不熟吧，对象库一样可以动态设置的，一样可以解决问题！

只要动态设置一下对象属性
...

总结下描述性脚本的三大罪状：
一是写脚本效率底下容易出错。
>>这个不对，如果程序结构设计好，描述性编程中对对象的处理部分一样可以封装。

  我说的是，如果不用对象库，你就不能用录制的方式生成脚本，只能自己一个字母一个字母的写脚本，效率低下，容易出错！
  用对象库，QTP就可以帮你用录制的方式自动的生成大部分的脚本，你只要少量修改就可以了，何必自己一个字母一个字母的写呢！
  你这是在做测试，要讲究效率，不要搞得为了测试一个软件系统，却要先编程开发一个新的软件系统，得不偿失。

二是脚本繁杂难看，充斥着复杂的属性描述。不像对象库方式那样，把复杂的属性描述封装在对象库里，只留给脚本一个清晰易读的对象名。
>>描述性编程一样的可以只留给脚本一个清晰易读的对象名，对象库的对象要清晰易读还得在识别后手工修改。

  只留给脚本一个清晰易读的对象名？那对象描述跑哪里去了？不在对象库里，就是在脚本里了！
  嗯，你可以把对象描述存在变量里！那天啊，一个软件系统里有多少个对象啊，你要定义多少个变量啊，你记得住嘛，不是很容易写错吗？
  而且有些对象需要用几个属性才能标识呢，你还要定义好几个变量呢！
  我想一想都要晕倒了！  


三是对象描述分散重复，每处脚本都要重复描述一遍对象。对象一变，天才知道要修改多少处的脚本，要修改哪些行的脚本。
>>描述性编程一样的可以集中处理生成需要使用测试对象，如果要修改，同样只修改一个地方。描述性编程一样可以使用SetTOProperty。

  “集中处理生成需要使用测试对象”，呵呵，怎么看你这样子是想自己做一个对象库！那何必呢？QTP都给你做好了，而且是集成的，更方便更好用。
  你自己做的话，要手工描述一遍所有的对象，那得费多大的功夫啊！
  人家QTP的对象库可以在录制中自动建立的，最多只要改下对象名，多轻松啊。
  而且一个系统里有多少个对象啊，你集中生成这么多个对象变量啊，你记得住吗？！
  

QTP推出对象库，就是为了解决这些问题的！
>>QTP对象库确实有它方便的地方，比如是基于对象的使用，当你输入vbwindow(后，就需要列出当前Action中你可以使用的vbwindow对象，而描述性编程就不能，你需要记住可以使用的对象。
所以要尽量多用对象库，少用描述性。
>>如果是针对软件测试这个目标，使用什么方式不是最重要的，关键在于你是否掌握了，能否熟悉的运用，并达成的你的目标，结果才是最重要的。
  
又来了，和稀泥。不同方式，虽然一样可以达到目的，但是要付出的成本和代价可能相差很远的！
  所以使用什么方式是非常重要的，关系到事半功倍，还是事倍功半的差别！


  说来说去，很简单的事情，对象库又好用又方便，描述性又难用又麻烦。搞不懂为什么一心要用描述性呢？！（少量使用我是不反对的）

引用:

原帖由 yabest 于 2007-8-11 17:00 发表


你可能对象库用的不熟吧，对象库一样可以动态设置的，一样可以解决问题！

只要动态设置一下对象属性
Link("职员").SetTOProperty("text", datatable.value("职员",dtLocalSheet))

然后就可以反复的使 ...

受教~~ 不过本人还是对对象库持保留意见

就说这个例子吧
其实
Link("职员").SetTOProperty("text", datatable.value("职员",dtLocalSheet))
Link("职员").click

和Link("text:="& datatable.value("职员",dtLocalSheet)).click 的作用是一样的,还得加上录制,录制后在对象库里修改对象的工作

再说说我用对象库时碰到的问题
一个弹出对话框的对象,这个对话框的上层可能时frame,也可能时网页对话框(识别为window)下的page,但是这个对话框基本是一样的,我写个函数获取这个对话框的提示信息.
对这个弹出框用描述性编程的话

set myFrame = Page().frame()
myframe.getpopmsg()

set myframe = page().Dialog().page.().frame()
myframe.getpopmsg()

是可以的, 但是用对象库录制的话, 这个弹出对话框所指的对象就必须在这frame和网页对话框对象下层都存在,否则myframe.getpopmsg()就出现对象找不到,这个函数复用性就很差了

所以还是怎么最方便怎么用,我无意完全否定对象库的好处,但是描述性编程确实也有无法替代的优点