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

Robel.Yi

在几年的自动化测试中，开发过数据驱动模式的框架，也开发过关键字驱动的数据框架，但总有些遗憾，总感觉这些框架还不是我想要的，因为他们有两点还有欠缺：
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 编辑 ]

shanxi

附件呢？

onlonely

你准备用 (脚本解析层：RunTestCase) 解析 (用例层：LoginERP.xlsx) 吗?
这样的话有个疑问,就是对于脚本中,需要人工编写代码的部分怎么办?
比如在执行某个操作前,我要先执行一小段代码来取得当前某些数据,然后才执行这个操作.

Robel.Yi

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

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

mklodoss

mark

wugecat

别用Excel了,太慢.尤其是用例间的转换,开发一套系统,把用例的测试数据放数据库里,执行起来才快呢!!

kam

期待……

fei.ge

希望楼主早日分享核心代码，嘿嘿

onlonely

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

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

f84248860

QTP的关键字视图(Keyword View) 和 框架中谈到的 (Key-word Drivne) 有本质的区别.

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

给楼主一个建议，没有必要用xlsx的话就别用xlsx，还是用xls会比较稳定。

blizzardlyk

最近自己也在尝试搭建自动化测试框架,感觉楼主搭建的健壮性挺强的,希望能够早如分享核心代码.

billhu

请把代码共享吧

hsjzfling

基本都是大同小异吧，本质还是数据驱动框架。LZ提出的关键字和Mercury的关键字驱动么啥关系~~

dreamever

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

[ 本帖最后由 dreamever 于 2009-6-30 14:30 编辑 ]

shuishixingyu

有具体脚本作为参考吗？

dreamever

这个……代码都是现成的，但是给不了……

blueeagle9999

这框架越做越强大，都不亚于被测系统了。不过这维护成本也要高很多哦

vingo1983

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

dyp125

最近也一直 在找 框架方面的资料 来学习，希望早日看到楼主的 源码

lijinshui

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