QTP框架及问题-求解惑

renquande

本人刚接触自动化，总过做过两个项目：
1、用java自己开发的一个自动化工具，封装成了客户端的方式，可实现跨平台运行（程序实现部分），用例部分是用Excel维护的（基本思想是程序实现读取EXCEL用例；转换成报文发送要测试的系统中；把需要的被测系统返回的报文回写到EXCEL中，然后与预期结果进行比较，如果包含预期结果则成功，否则失败）

2、用QTP录制脚本，修改脚本（用例维护在QTP的datatable中），脚本实现从datatable中读取用例；然后把要校验的内容从界面获取放到变量中；把变量的内容写入EXCEL中）

一直都没有进行过框架的研究，看了很多大拿的帖子，也没搞太明白QTP：
1、现在有没有框架？如果有是什么？
2、我上面的两个项目组中有没有融入框架的思想？
3、帖子中老说数据驱动脚本是什么意思？
希望各位大拿能积极参与讨论，能让刚接触自动化的菜鸟们理解，谢谢

qtp老菜鸟

框架太抽象，目前还没有一本书能写的很明白的，再加上学习的人水平参差不齐，学的云里雾里的很正常。

lilygethope

学习了，我也是新手准备研究自动化测试工具QTP。

louqqson008

一步步来，等到学习框架时再来这学习下

luckybo716

框架这东西，我说个简单易懂的说法。这个说法也是别人告诉我的。
  一天，开发工程师完成一个新版本，发一封邮件给测试，告诉测试可以开始这个版本的测试了；这时你的电脑收到这封邮件，就自动从配置服务器下载软件，并开始测试；几个小时后测试完成，自动生成报告，并且自动发邮件给开发以及领导，告诉他们测试已经完成，有某某BUG，有哪些是Passed。作为测试工程师的你只需要喝咖啡看报子。支撑这个整个过程元素就是框架。
   上面是个理想状态。要做到上面的框架不是没可能，只是成本巨大（这个也要看软件规模）。越靠近这个状态需要成本越大，维护越难，也越容易失败。从上面的例子也可以看出QTP（或者其他工具）在上面的测试中只占了一小部分，你还需要大量其他东西去支撑自动化。

lintongyan

学习了

vipwork

真的不清楚框架是什么，对于一些流程模块，只是利用global表储存填写信息和操作信息，然后让测试人员改表中的信息而已，不知道算不算是框架

hbycyf123

新手搞框架还是有难度，慢慢摸索吧

dingheng9546

回复 22# metoto


    先弄清楚什么是框架。框架只是一个管理程序而已。数据驱动读读轻量级自动化框架。关键字驱动读读QTKEY。行为驱动，。。。我不知道QTP有没这个概念。百度一下BDD。我是selenium里面接触到BDD的。

metoto

mark

fanzhk

不错，学习。

yychenyuan

学习了~看来qtp要学习的还有很多呀~

小孩

框架不框架不重要，框架只是个名词而已，做自动化应该从实际出发，
自动化只要做到降低脚本开发成本和维护成本，减短自动化开发周期即可。
别太去在乎框架，这东西没人说的清楚，都是 人云亦云

我就整过根据用例去跑自动化的自动化脚本（不知道属不属于框架），这东西本身就是QTP关键字驱动（一个概念），但是我重写一遍，QTP关键字驱动还是不够亲切。
然测试人员根据用例规范去写用例，写出来的用大多数都可以自动化。不用再去写脚本或者录脚本。
     自动化以人为本，越简单越好。

jinwei6078

还在初级阶段

shanfeng1419

顶下，学习了

lyhgq321

还得多学习啊……

lyscser

回复  lyscser

高见，做到了跳出自动化，站在高处看问题，不过我用了SAFFRON框架，但是不知道怎么在不同 ...
renquande 发表于 2011-4-28 14:52

app.test.action.item(x).setscript
app.test.settings.resource.add……
总之QTP自带的方法支持临时生成你需要的脚本

renquande

回复 12# lyscser

高见，做到了跳出自动化，站在高处看问题，不过我用了SAFFRON框架，但是不知道怎么在不同的脚本里面能够直接引用里面封装好的函数，每个脚本每次都得重新导入一次这个VBS格式的框架

datouniuniu

学习了

lyscser

其实大家怎么理解自动化测试框架都是有道理的，毕竟自己所看到的、别人想要表达和别人已经表达出来的很可能就都不是一码事，满足自身的需求才是最重要的，每个人都应该有自己的理解。

1、自动化测试管理框架，偏向于自动化测试的全局架构理论，把自动化测试的各个环节、要素的说明和规范文档化，测试管理结构文件实例化，在没有背离测试主旨的前提下，自动化可以在规范圈定范围内任意发挥，只要满足测试需求即可。这种框架本身也带有一些基于本公司业务特点和使用需求的其他功能，例如测试运行调度、邮件服务的使用、文件服务的使用和报表分析等等。这种框架在管理上下了较多的功夫，有了成型的架构之后就可以不依赖任何一个技术核心人物，大大降低了技术储备的难度和人员离职带来的风险。缺点是在这种理论指导下若没有相应的业工具支持，框架开发或工具和框架的二次开发比较费时费力。

2、自动化测试开发框架，典型的代表就是被很多人推崇的QTP的自动化测试框架SAFFRON。这种框架的作用就是简化自动化脚本编写，分离业务、脚本操作和数据，自定义封装一些常用的操作，使自动化脚本在业务系统发生变更时更容易维护、开发速度更快。这种框架立意于直接达到关键字驱动的效果，但是如何能与整个测试部门或公司的管理有效的整合在一起，对测试管理工作起到决策支持的作用呢？很显然，单凭这个原型化的框架本身是很难做到的，因为它很单纯的应用于自动化测试程序开发这个动作本身，笔者觉得这种框架有一个更贴切的名字：自动化测试脚本开发辅助框架。个人理解，关键字驱动和数据驱动的最大区别在于描述性语言的使用上，描述性编程的优势是大幅减少了脚本对页面对象稳定性的依赖。像SAFFRON这种框架的好处也就在于即便页面控件的属性发生了一些变化，在它下面开发的脚本也能继续运行，除非出现逻辑上的不一致。而事实上对于我们的系统来说，页面元素的变化对我们来说也是一个系统监控点：是什么样的需求让编码人员去做这样的变动呢？带着这个疑问系统测试会做得更细致，如果忽略了这些微小的变更，测试缺陷遗留的风险将有可能会提高。所以两种编程方式各自有着自己的优缺点，从自动化测试脚本维护工作量和脚本灵活性的角度笔者更愿意使用描述性语言，但是从系统测试的可信度和是否足够细致的角度上去考虑，有些人可能更愿意使用傻瓜式的对象库。

一种是理论化的概念管理型，一种是实际化的开发应用型，我们的理想自然是理论结合实际了。那么不妨把两种框架实例化地整合在一起，扬长避短，用来满足我们自身的需求。仔细考察一下上面描述的两种具有代表性的典型自动化测试框架，我们会发现他们并没有冲突，并且在本质追求上都是一致的：让自动化测试更加快捷方便。我们可以考虑把小的框架封装起来，作为大框架的一个组件来使用，这样并不影响他们各自的长处发挥，并且能够很好的消除各自的弱点。同时很明显，以大框架的包容性是不仅仅只能容纳一个小框架的，需要指出的是，不同的测试脚本开发原型框架有着不同的特点，对脚本编写人员的技能、测试工具、测试开发环境等因素的要求不一样，引进的时候我们或许会发现它本身存在与整体框架规范冲突的地方，这就需要我们在执行该领域规范的时候灵活变通，实现兼容并蓄。

如果单从概念形式上还不能明确定义什么是自动化测试框架的话，那么我们不妨从自动化测试的发展进程来看看。众所周知基于QTP的自动化测试经历了下面这四个阶段：

A、简单的录制、回放

B、录制、参数化、加检查点

C、模块复用、数据分离——数据驱动

D、对象、操作、数据分离——关键字驱动——组件分离

这是一个自动化测试由简单到复杂的过程，一个自动化技术难度越来越大的过程，一个让自动化测试更具灵活性的过程，也是一个让自动化测试越来越有趣的过程。不过，无论自动化测试如何发展，测试对自动化的需求始终没有变化：简化复杂的操作过程、保证测试的简单高效！那么我们如何把这些被拆解得支离破碎的一个个组件有机地组织在一起，来满足测试的简单高效的要求呢？自动化测试框架！所以，或许大家现在明白什么叫做自动化测试框架了：

能够有效组织和管理自动化测试中所必需的各个组件、有计划地进行自动化测试执行并且支持测试结果分析和测试过程改进的结构实例或文件实例就是自动化测试框架。