轻量级的自动化测试框架

mstiunicon

解压rar文件，执行Driver.vbs文件即可，需要安装QuickTest。

yabest

下载看看。
好像driver test无法打开，QTP报告格式错误！

jinsen

感谢LZ，学习一下。

lantianwei

呵呵...谢谢LZ共享

marygao929

driver.vbs 报：can not open test

mstiunicon

QTP应该是9.0版本或以上。
如果driver.vbs打不开，直接用QTP打开Driver脚本，一样的效果。

three116

deng deng 看看 先谢谢了

gy21st

层次结构很清晰，顶一下。
楼主说得不错，所谓框架，不是一个什么都淘得进去的模子，有了基本的思想，和具体项目结合才是正解。

mstiunicon

原帖由 gy21st 于 2008-1-19 22:51 发表
层次结构很清晰，顶一下。
楼主说得不错，所谓框架，不是一个什么都淘得进去的模子，有了基本的思想，和具体项目结合才是正解。

哈哈，握个手

隐形人

谢了,现在正在找这个

jackymail

对于QTP地认识从最开始的大量使用action到逐步淘汰Action转向Function
从最开始的拒绝使用对象库，到减少使用描述性编程而大量使用对象库。
从把对象倒入到Excel表再倒回来，到省略了那个反复传送。
从复杂的设计开发出各种概念，制定一些复杂的制度，到最后简单到QTP设计的初衷。

大家都在探索。。。。。。

这个PPT里面提到的缺陷其实都是没有做而已，而不是提出这种方方法的缺陷。

个人意见：减少所谓Test Set，直接把最小概念定义到Test Case, 这是每个人都要接触的也都熟悉的，不要因为作了自动化就要引入一些新的概念，只能增加复杂度，更不宜于推广。

这个ppt让我欣赏的地方就是把log case data等一些东西分开文件夹管理，这样的确很清晰。值得学习。

我觉得log地记录最好是用case为单位，再做一个集成相同类型log的vbs，把需要集中在一起的log通过简单的vbs调用创建一个整体的log.

算了不写了。。随便说说，交流而已。

mstiunicon

原帖由 jackymail 于 2008-1-21 01:04 发表
对于QTP地认识从最开始的大量使用action到逐步淘汰Action转向Function
从最开始的拒绝使用对象库，到减少使用描述性编程而大量使用对象库。
从把对象倒入到Excel表再倒回来，到省略了那个反复传送。
从复杂的设计 ...

按照我的理解，不管是使用Action，还是使用Function，都是使用工具的一种方式，QTP仅仅只是QTP，最重要的是你想用它来干什么。做这个东西，一是要目的性强，二是要简单方便。
1 testSet其实只是用来管理testcase的Excel文件的索引而已，如果不用这个，会不会比较散？不过如果能用TD来实现这个功能是最好的，研究一下。
2 日志文件这样存放倒是有点意思，我试着写一个这样的Function。

lantianwei

原帖由 mstiunicon 于 2008-1-18 10:51 发表
解压rar文件，执行Driver.vbs文件即可，需要安装QuickTest。

看了你的PPT,惊人的发现和我现在设计的QTP框架非常相似,因此再也忍不住了,我也来说两句吧,我当初也是因为ACTION太难使用和管理,所以选择FUNCTION的,我觉得ACTION只有在和TD/QC进行集成时才可以发挥他的优势.在设计过程中也发现测试用例和测试数据的组织非常重要.
下面说说我对你的框架的看法吧,
1.我觉得你把testcase和testdata有点搞混了,你的testcase真正意义上我觉得应该是一个配置文件,决定了该运行哪个excel;而你的testdata其实是放用例步骤和测试数据的.不知道你是怎么处理测试数据的,怎么知道一个功能要调用到表中的哪一行测试数据,是不是缺少了字段,请兄才指点!
2.为什么不把你测试要加载的一些资源放在配置文件里进行配置呢?那么这个框架的复用性就更高了.
3.LOG文件和QTP报告我觉得最好不要覆盖原有的,QTP报告可以用自定义XLS来生成自己特定的报告样式,效果还不错.
4.不知道你这个框架能不能保证在前面用例出错的情况还可以正常运行下去
就说这几点吧,可能其他都是优化方面的,就不说了.
以上只是个人意见,如有不妥指出,还请指出!
下面是我设计的框架架构图:

mstiunicon

原帖由 lantianwei 于 2008-1-21 14:51 发表

看了你的PPT,惊人的发现和我现在设计的QTP框架非常相似,因此再也忍不住了,我也来说两句吧,我当初也是因为ACTION太难使用和管理,所以选择FUNCTION的,我觉得ACTION只有在和TD/QC进行集成时才可以发挥他的优势.在设计 ...

哈哈，能和lantianwei进行交流真是太好了。
1 testSet是沿用了TD的说法，其作用或者说角色是用来管理TestCase的。用来表现testSet的方式至少有3种，Excel表格，XML文件，数据库。个人比较倾向使用Excel和数据库的形式，因为不太习惯使用XML文件，呵呵。另外也是因为Excel手工操作起来比较方便。如果可以的话，还是想用数据库的形式，这样，可以做一个类似TD的东西出来。。。。
2 testcase一般是包含测试步骤和测试数据两部分，我把它们分开，在理念上有误，我会修改一下的。
3 “怎么知道一个功能要调用到表中的哪一行测试数据”，这个是由测试步骤的filter字段来控制的。
4 要加载的资源的确是应该放到配置文件中，我这是偷了一点懒，直接写死了，哈哈。
5 日志和错误处理暂时没有更好的想法。

看了你的框架图，有一些疑问：
1 你的controller调用TestCase的数据，执行Case脚本，这么说来，你的测试用例的步骤是写在脚本中的？
2 GUI map，看到这个我就头疼，因为我测试的系统不是很标准，做GUI map的可行性不高。你也是用GUI map实现了类似QTP的关键字驱动的功能？
3 Modules的目的是用来做什么的？这个不太理解。
更希望看到你做出来的例子，这样才能更好的理解你的思想啊。

xiaoyaoke

貌似主体结构都差不多...只是一些细节上有差距
唉
想问问楼主，你的这个自动化测试框架受过谁的影响？

lantianwei

原帖由 mstiunicon 于 2008-1-22 10:11 发表


哈哈，能和lantianwei进行交流真是太好了。
1 testSet是沿用了TD的说法，其作用或者说角色是用来管理TestCase的。用来表现testSet的方式至少有3种，Excel表格，XML文件，数据库。个人比较倾向使用Excel和数据库 ...

呵呵....我做一下简单的回答吧!
1.controller就想一台电脑的CPU,它是处理测试脚本的运行,结果的导出,异常的处理等等.我的业务逻辑和测试脚本是分离的,所以用例是写在testcses里的.你可以看到我用绿色标注的是手工测试人员或业务人员应该关注的.
2.可以用描述性编程,对象库都可以,只不过用描述性编程的话要做特殊的处理,已便于最快的定位到对象,以便于在后期进行维护;而对象库整理比较麻烦,比如命名规则什么的.两者各有所长,我在之前做的一个是用描述性编程,可以根据项目的特性来确定用什么,比如GUI变更少的话,就可以选择描述性编程,因为它开发起来比较快.
3.Modules是单个功能的脚本文件,可能这里的功能粒度划分的比较细点(但不是以一个动作为单位的),这些脚本也可以独立的完成某一特定任务,该脚本是以模块来划分的;casescripts是通过组合多个Modules里的函数而生成的一个特殊业务功能脚本,这样做主要是为了提高复用性,以及减少用例的步骤数

[ 本帖最后由 lantianwei 于 2008-1-23 16:56 编辑 ]

今天有雾

先学习一下楼主的资料，然后听了各位楼建意，收获不少，对我的框架学习很有帮助，Thank LZ

musk

给我很大的启发~谢谢2位

loho1968

WR有一个开源的自动化测试框架项目,我曾经模仿这个项目做了一个QTP的.

一个管理控制文件,用于设置需要执行哪些CASE
一个CASE描述文件,用于描述一个CASE应该如何执行.

自动化测试框架想想很好,但实际应用会有很多问题,个人感觉最麻烦的是如果这个框架没有较深的积累,无法处理有复杂逻辑的测试目标.可以完成简单的功能执行和检查点的检查,但如果有业务逻辑检查就比较麻烦了.

lantianwei

原帖由 loho1968 于 2008-1-22 16:13 发表
WR有一个开源的自动化测试框架项目,我曾经模仿这个项目做了一个QTP的.

一个管理控制文件,用于设置需要执行哪些CASE
一个CASE描述文件,用于描述一个CASE应该如何执行.

自动化测试框架想想很好,但实际应用会有很 ...

你这个是关键字驱动框架啊,如何做好确实有一定的难度!