脚本如何组织才好，大家看看我的方法行不行，给点意见

ls_721521

不用对象库，不用action调用的方法。
采用qtp10；使用描述性编程；把脚本写在一个project里面，使用函数来调用，例如：
call a()
call b()

function a(){call c()}

function b(){}

function c(){}

ls_721521

前提是这个自动化项目很庞大，业务也很复杂

17800455

采用全手工的方法去写脚本没必要去用对象库

甚至你可以把对象都写在一个文件里。

然后去文件里读。。

如果软件对象改变了。只需要在配置文件里改就可以了。

这样多方便啊。

ls_721521

想问问大家我的这种脚本结构在实施的时候会有哪些弊端？

lantianwei

采用全手工的方法去写脚本没必要去用对象库

甚至你可以把对象都写在一个文件里。

然后去文件里读。。 ...
17800455 发表于 2010-10-27 15:39

难道你的配置文件要比QTP的对象库强大？

wugecat

呵呵版主是一直支持对象库的

wugecat

如果想LZ这样做,直接写VBS就行,然后一个Action运行所有...也别用对象库了,如果这样还用的话就会给自己带来麻烦,这样做可以放SVN等工具管理,有了修改合并也方便,对象库就不同,对象库不好合并,还有就是你数据放哪?

17800455

回复 4# ls_721521


    弊端是一定有的。每个框架都有它不好的一面。

　采用全手工编写，不采用对象库。

　这样开发速度会很慢。

　前期投入会很大。

　

ls_721521

回复 7# wugecat

写脚本和调试脚本时还是要在qtp中进行的，脚本写完后可以用vbs保存。有一个问题就是：保存成多个vbs文件里还是只放到一个vbs文件。如果保存到多个vbs里会不会存在调用冲突等问题；如果保存到一个vbs里会存在加载时间长的问题。
数据还是放到excel或者xml里呗
至于对象库，我一开始就说不用它了

ls_721521

回复 8# 17800455

采用全手工编写和采用对象库所花费的时间只是差在识别对象上。如果对被测系统对象的属性熟悉，描述性也是很快的。而且维护简单。

kavensyw

回复 10# ls_721521

如果项目不大，还不如就直接用对象库呢，对象库默认我一般用ID来识别，特殊的再加上其他的一些属性。
因为在开发修改的过程中有可能会修改各空间的一些属性值，但ID一般是很少反复修改的

至于VBS脚本，尽可能一种类型的放在一个class文件里，如excel,ado,shell,filesystemobject,....
至于测试数据，放在excel,xml,database都无所谓，关键是用着方便就行

自动化本来就就是为了节省人力和时间的，别搞得很复杂，即使实现了又有何意义呢。

ls_721521

回复 11# kavensyw

至于VBS脚本，尽可能一种类型的放在一个class文件里，如excel,ado,shell,filesystemobject,....
-----------------------------------------------
我的意思是把所有脚本都放到vbs里，包括识别对象的脚本。当然公共函数要有单独的vbs文件

xhhuang1618

回复  wugecat

写脚本和调试脚本时还是要在qtp中进行的，脚本写完后可以用vbs保存。有一个问题就是：保 ...
ls_721521 发表于 2010-10-28 09:06

    1.将脚本分开保存，并且脚本的名称和你的用例名称对应起来，这样在维护脚本的时候方便一点
   2.”如果保存到一个vbs里会存在加载时间长的问题--？？为什么要会有加载时间长的问题？你是在QTP的setting里将脚本加载进去了？一般都是先做个plan，然后你的QTP会先读取plan里面的数据，每读取一行就执行里面脚本

ls_721521

回复 13# xhhuang1618
  2.”如果保存到一个vbs里会存在加载时间长的问题--？？为什么要会有加载时间长的问题？你是在QTP的setting里将脚本加载进去了？一般都是先做个plan，然后你的QTP会先读取plan里面的数据，每读取一行就执行里面脚本
能具体说一下怎么实现吗？读取plan里面的数据前vbs里的脚本不需要全部加载进来吗？是在plan中选择加载要运行的vbs脚本吧？

ls_721521

也就是说要运行那部分的脚本就加载那部分吧

Jun_Li

一直比较青睐QTP的对象库, 描述性虽好, 但不适宜大批量应用,  代码量会不会大的惊人

不用Action完全可以, 可以自己写个开发和运行框架,  底层函数 业务逻辑 数据...   层次清晰  维护成本低

kavensyw

（一）把对象库当成数据库，脚本当成控件来看待。
控件要运行必须绑定数据，那么QTP脚本要运行就必须关联自己需要的相应的对象库就是了

那么脚本要运行就变成了这样：
1. 确定要运行的脚本；确定支持脚本运行的对象库
2. 查找对象库，找到后关联之
3. 调用脚本
4. 运行
5. 运行完毕，取消关联的对象库
（二）直接使用描述性编程，就相当于把数据揉进了脚本中，只不过这个数据值是控件的属性值而已。
（三）而直接录制的Action，相当于数据路径都给你找好，并且已经给你关联好了。

至于对象库，不必所有的都用一个公共的tsr，因为都用一个，如果有父对象难以识别，会影响到很多脚本运行;
也不用每个小脚本单独都有各自独立的对象库，因为如果有多个脚本公用的父对象属性（比如Page的Url）变更时，要改的对象库就会太多;
可以考虑按功能或者其他来划分多个tsr。比如：
登录.tsr;权限管理.tsr;用户管理.tsr;每个单独的业务（新增、编辑、删除）.tsr...

方法	优点	缺点
直接录制，稍加修改	简单，方便,还易上手	占用空间大，各个Action对象也要单独维护
直接描述性编程,不要对象库	脚本小	对象属性变更时，维护脚本困难
脚本与对象库分离	脚本和对象库都便于维护	多了些步骤，需要查找、关联对象库

ls_721521

回复 17# kavensyw

谢谢！！
你说的脚本与对象库分离的方法是怎么实现的？先批量导入对象库、手写脚本、最后再关联吗？

我的看法是一个系统要应用自动化，其对象属性就基本不会变化了，变化的也只是少数，如url、title等，直接把这些属性写到参数化或变量里就行了。。

我打算采用的方法是 先录制，然后修改成描述性。这样做只是在做第一个脚本时会很耗时（因为不熟悉对象属性），再做第二个第三时就会快很多了。
录制一百行的脚本，在熟悉属性的前提下，将他修改成描述性并调试通过，一般也就一小时左右搞定。

xhhuang1618

也就是说要运行那部分的脚本就加载那部分吧
ls_721521 发表于 2010-11-7 23:05

    是的，建议你看一下网上的小型自动化框架，里面有些思想还是不错的。
   还有，在你做自动化测试的时候，考虑一直对象库维护的问题，否则如果页面有改动的话，那你的工作量会变的很多