51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 11512|回复: 30
打印 上一主题 下一主题

[原创] 最新关键字+数据联合驱动框架结构

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2009-6-25 12:06:13 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
在几年的自动化测试中,开发过数据驱动模式的框架,也开发过关键字驱动的数据框架,但总有些遗憾,总感觉这些框架还不是我想要的,因为他们有两点还有欠缺:
1.数据驱动模式可以比较方便的设计修改测试数据,但不支持快速自动化开发与后期脚本维护,功能函数非常多。
2.关键字驱动可以比较方便维护脚本和进行快速自动化开发,但对不断变化的测试数据支持又显得乏力

在又接手一个大型项目后,决心打破这些模式,经过一个月的开发,初步完成了关键字+数据联合驱动框架,只是目前还有一些细节处理上面需要加强,基本已能解决上面两种框架的问题了,现在先把这种联合驱动框架的结构分享给大家,可能你们会觉得就几个字而已,呵呵,看得懂的用心体会,看不懂的回帖说没有用也行,后期等我觉得足够成熟了会把框架核心部分源代码分享出来,当然会剔除公司业务部分。

关键字+数据联合驱动框架结构:

     采用三层架构:框架底层支持函数-->脚本解析层(可根据不同规则二次开发)-->脚本层(包含场景恢复)、用例层、数据层(三者相互调用、支持)

1 底层文件:FramworkFunction.vbs(主要分为基本功能函数与对象操作函数)、Parameter.vbs(记录设置全局参数)、PrintScreen.vbs(完成截屏功能)、Report.vbs(与测试报告相关函数)
2 脚本解析层:RunTestCase.vbs、WritTestData.vbs ……
3 脚本层:MainConturl(主控脚本,控制整个测试流程中各action的调用)
                          Action(各子脚本,以功能模块为单位)
  用例层:LoginERP.xlsx、ProjectInformation.xlsx、CreateFangYuan.xlsx……等,也是以功能模块为单位,其中的testcase是以各模块中单独功能为单位
  数据层:Main_DATA.xlsx(主控脚本驱动文件,等整个流程完善再做)、LoginERP_DATA.xlsx、ProjectInformation_DATA.xlsx、CreateFangYuan_DATA.xlsx ……

[ 本帖最后由 Robel.Yi 于 2009-6-25 12:07 编辑 ]
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2009-6-25 12:36:55 | 只看该作者
附件呢?

回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2009-6-25 13:08:54 | 只看该作者
你准备用 (脚本解析层:RunTestCase) 解析 (用例层:LoginERP.xlsx) 吗?
这样的话有个疑问,就是对于脚本中,需要人工编写代码的部分怎么办?
比如在执行某个操作前,我要先执行一小段代码来取得当前某些数据,然后才执行这个操作.
回复 支持 反对

使用道具 举报

该用户从未签到

4#
 楼主| 发表于 2009-6-25 13:30:12 | 只看该作者

回复 3# 的帖子

1.不是准备用,是已经在用

2.这个问题问得好,呵呵,处理办法是这样的,在testcase中可以选择是对象还是FUNCTION,如果是选择FUNCTION就再填入FUNCTION名,这样在脚本中就可以调用框架不支持或特殊情况的脚本了。
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2009-6-25 15:23:08 | 只看该作者
mark
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2009-6-25 15:57:05 | 只看该作者
别用Excel了,太慢.尤其是用例间的转换,开发一套系统,把用例的测试数据放数据库里,执行起来才快呢!!
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2009-6-25 21:06:21 | 只看该作者
期待……
回复 支持 反对

使用道具 举报

  • TA的每日心情
    难过
    2015-9-21 13:50
  • 签到天数: 4 天

    连续签到: 1 天

    [LV.2]测试排长

    8#
    发表于 2009-6-25 21:54:47 | 只看该作者
    希望楼主早日分享核心代码,嘿嘿
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2009-6-26 10:00:58 | 只看该作者

    回复 4# 的帖子

    这的确是一种方法.
    可是这样我感觉怎么像QTP中的关键字视图呢.
    并且关键字视图可能还更好编写这样的用例.

    另外我还想说,楼主你是准备用一个Action当做一个用例吧.
    这样的话,多级调用可能就会一团糟了.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2009-6-26 11:42:01 | 只看该作者
    QTP的关键字视图(Keyword View) 和 框架中谈到的 (Key-word Drivne) 有本质的区别.

    Keyword Driven本身就是为了重用的目的做的,这是为了保证被重用的模块每次都保持一致,如果代码设计得当,每一个被写成Keyword的模块都应该有保持独立,错误处理以及结果返回的功能。

    给楼主一个建议,没有必要用xlsx的话就别用xlsx,还是用xls会比较稳定。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2009-6-26 14:14:07 | 只看该作者
    最近自己也在尝试搭建自动化测试框架,感觉楼主搭建的健壮性挺强的,希望能够早如分享核心代码.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2009-6-30 11:41:08 | 只看该作者
    请把代码共享吧
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2009-6-30 14:01:28 | 只看该作者
    基本都是大同小异吧,本质还是数据驱动框架。LZ提出的关键字和Mercury的关键字驱动么啥关系~~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2009-6-30 14:10:38 | 只看该作者
    我用的是三层结构:
    用例层脚本;
    操作层脚本;
    对象层脚本;
    对象层是最底层,负责提供对象识别和获取的代码,如getObject(String id,String value),另外还提供了一些基础服务,比如对EXCEL的创建、读写、删除、比较,还有生成日志的功能;我的自动化测试过程中,测试数据的存储、读取、输入全部使用的是EXCEL
    操作层脚本封装的软件的操作,它有对象层中的方法调用而形成,比如一个登录操作,会涉及到输入用户名、密码、点击登录三个操作,那我会封装一个方法public void login(String usrname,String pasword),这样就形成了可重用的操作组件;
    用例层就是用例脚本,所有的用例脚本都调用操作层的脚本,考虑到以后的可维护性,规定除非不得已,否则用例层脚本不允许直接访问对象层的方法;
    另外还有一些辅助功能,一个是脚本调度的类,其作用类似于MainConturl,只是调用的是用例脚本而不是action,还有一个log类,用来创建自动化测试的日志,并形成简单的统计结果。目前我们在做的自动化测试,有一个思路就是尽可能的把工具提供的功能抽出来,用自己的代码实现,希望能通过这样的方式,将自动化测试对工具的依赖程度降到最低

    [ 本帖最后由 dreamever 于 2009-6-30 14:30 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2009-6-30 23:28:45 | 只看该作者
    有具体脚本作为参考吗?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2009-7-1 09:35:43 | 只看该作者
    这个……代码都是现成的,但是给不了……
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2009-7-1 09:53:41 | 只看该作者
    这框架越做越强大,都不亚于被测系统了。不过这维护成本也要高很多哦
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2009-7-2 23:04:10 | 只看该作者
    我们所用的自动化测试框架,跟LZ所说的有点相似。
    有一套自动化用例生成工具,把用例翻译成自动化脚本伪代码,同时将数据部分提取出来专门放到一个文件中,便于数据修改。
    再在QTP中将伪代码翻译执行。
    这样做的好处是,QTP很多核心代码功能函数都可以共用,维护工作量相对少一些,而且测试数据部分修改起来也比较容易。
    不过也有不好的地方,就是那个自动化用例生成工具操作起来可能会有点复杂,上手需要一定的时间。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2009-7-3 09:10:45 | 只看该作者
    最近也一直 在找 框架方面的资料 来学习,希望早日看到楼主的 源码
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
    发表于 2009-7-3 14:44:25 | 只看该作者
    记得当时我在刚开始用的时候,就有好多人提起说框架很重要,当时没有感觉
    后来用了一段时间后,作了几个测试模块后
    感觉好乱,这才想起来框架来,于是我就痛定思痛后,下决心,自己作了个简单的框架
    也假膜假释的分了层次,其实我也说不清,是2曾还是3层,反正现在无论是新规还是维护感觉舒服多了,昨天看了一下印度发过来的代码,感觉就像没有头绪的苍蝇乱飞,。。。。现在想想这个多亏了那个框架阿,要不我的脚本估计比他们的好不了多少
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-22 16:40 , Processed in 0.084155 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表