51Testing软件测试论坛

标题: 脚本如何组织才好,大家看看我的方法行不行,给点意见 [打印本页]

作者: ls_721521    时间: 2010-10-27 15:04
标题: 脚本如何组织才好,大家看看我的方法行不行,给点意见
不用对象库,不用action调用的方法。
采用qtp10;使用描述性编程;把脚本写在一个project里面,使用函数来调用,例如:
call a()
call b()

function a(){call c()}

function b(){}

function c(){}
作者: ls_721521    时间: 2010-10-27 15:06
前提是这个自动化项目很庞大,业务也很复杂
作者: 17800455    时间: 2010-10-27 15:39
采用全手工的方法去写脚本没必要去用对象库

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

然后去文件里读。。

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

这样多方便啊。
作者: ls_721521    时间: 2010-10-27 16:07
想问问大家我的这种脚本结构在实施的时候会有哪些弊端?
作者: lantianwei    时间: 2010-10-27 17:34
采用全手工的方法去写脚本没必要去用对象库

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

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


难道你的配置文件要比QTP的对象库强大?
作者: wugecat    时间: 2010-10-27 17:45
呵呵版主是一直支持对象库的
作者: wugecat    时间: 2010-10-27 17:58
如果想LZ这样做,直接写VBS就行,然后一个Action运行所有...也别用对象库了,如果这样还用的话就会给自己带来麻烦,这样做可以放SVN等工具管理,有了修改合并也方便,对象库就不同,对象库不好合并,还有就是你数据放哪?
作者: 17800455    时间: 2010-10-28 08:34
回复 4# ls_721521


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

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

 这样开发速度会很慢。

 前期投入会很大。

 
作者: ls_721521    时间: 2010-10-28 09:06
回复 7# wugecat

写脚本和调试脚本时还是要在qtp中进行的,脚本写完后可以用vbs保存。有一个问题就是:保存成多个vbs文件里还是只放到一个vbs文件。如果保存到多个vbs里会不会存在调用冲突等问题;如果保存到一个vbs里会存在加载时间长的问题。
数据还是放到excel或者xml里呗
至于对象库,我一开始就说不用它了
作者: ls_721521    时间: 2010-10-28 09:09
回复 8# 17800455

采用全手工编写和采用对象库所花费的时间只是差在识别对象上。如果对被测系统对象的属性熟悉,描述性也是很快的。而且维护简单。
作者: kavensyw    时间: 2010-11-1 22:28
本帖最后由 kavensyw 于 2010-11-1 22:35 编辑

回复 10# ls_721521

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

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

自动化本来就就是为了节省人力和时间的,别搞得很复杂,即使实现了又有何意义呢。
作者: ls_721521    时间: 2010-11-2 12:34
回复 11# kavensyw

至于VBS脚本,尽可能一种类型的放在一个class文件里,如excel,ado,shell,filesystemobject,....
-----------------------------------------------
我的意思是把所有脚本都放到vbs里,包括识别对象的脚本。当然公共函数要有单独的vbs文件
作者: xhhuang1618    时间: 2010-11-5 13:30
回复  wugecat

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



    1.将脚本分开保存,并且脚本的名称和你的用例名称对应起来,这样在维护脚本的时候方便一点
   2.”如果保存到一个vbs里会存在加载时间长的问题--??为什么要会有加载时间长的问题?你是在QTP的setting里将脚本加载进去了?一般都是先做个plan,然后你的QTP会先读取plan里面的数据,每读取一行就执行里面脚本
作者: ls_721521    时间: 2010-11-7 23:04
回复 13# xhhuang1618
  2.”如果保存到一个vbs里会存在加载时间长的问题--??为什么要会有加载时间长的问题?你是在QTP的setting里将脚本加载进去了?一般都是先做个plan,然后你的QTP会先读取plan里面的数据,每读取一行就执行里面脚本
能具体说一下怎么实现吗?读取plan里面的数据前vbs里的脚本不需要全部加载进来吗?是在plan中选择加载要运行的vbs脚本吧?
作者: ls_721521    时间: 2010-11-7 23:05
也就是说要运行那部分的脚本就加载那部分吧
作者: Jun_Li    时间: 2010-11-8 08:49
一直比较青睐QTP的对象库, 描述性虽好, 但不适宜大批量应用,  代码量会不会大的惊人

不用Action完全可以, 可以自己写个开发和运行框架,  底层函数 业务逻辑 数据...   层次清晰  维护成本低
作者: kavensyw    时间: 2010-11-9 20:00
本帖最后由 kavensyw 于 2010-11-9 21:08 编辑

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

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

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

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

作者: ls_721521    时间: 2010-11-10 09:10
回复 17# kavensyw

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

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

我打算采用的方法是 先录制,然后修改成描述性。这样做只是在做第一个脚本时会很耗时(因为不熟悉对象属性),再做第二个第三时就会快很多了。
录制一百行的脚本,在熟悉属性的前提下,将他修改成描述性并调试通过,一般也就一小时左右搞定。
作者: xhhuang1618    时间: 2010-11-10 13:37
也就是说要运行那部分的脚本就加载那部分吧
ls_721521 发表于 2010-11-7 23:05



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




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2