QTP框架及问题-求解惑
本人刚接触自动化，总过做过两个项目：1、用java自己开发的一个自动化工具，封装成了客户端的方式，可实现跨平台运行（程序实现部分），用例部分是用Excel维护的（基本思想是程序实现读取EXCEL用例；转换成报文发送要测试的系统中；把需要的被测系统返回的报文回写到EXCEL中，然后与预期结果进行比较，如果包含预期结果则成功，否则失败）
2、用QTP录制脚本，修改脚本（用例维护在QTP的datatable中），脚本实现从datatable中读取用例；然后把要校验的内容从界面获取放到变量中；把变量的内容写入EXCEL中）
一直都没有进行过框架的研究，看了很多大拿的帖子，也没搞太明白QTP：
1、现在有没有框架？如果有是什么？
2、我上面的两个项目组中有没有融入框架的思想？
3、帖子中老说数据驱动脚本是什么意思？
希望各位大拿能积极参与讨论，能让刚接触自动化的菜鸟们理解，谢谢 怎么没人说话呢？？？？？？？？？:'( 帮顶 首先要理解何为框架
框架（Framework）是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法;另一种定义认为，框架是可被应用开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。
只要对自动化套件有一定规划，都可以称之为框架，问题的关键是框架的好坏，涉及到以下几个方面：效率，易用性，易维护行，易扩展性等等。
让我们从下到上来分析，以QTP为例。
对一个系统进行自动化，测试用例会有很多，对应的实现自动化的脚本也会有很多。如何对这些脚本进行规划呢？
最简单的，使用录制/回放测试框架。
quote：录制/回放测试框架所采用的原理是通过录制应用程序产生的线性脚本进行回放从而达到自动化测试的目的。 其优点是简单，通过录制就可以得到所需脚本。但同时也有很大的缺点，它不具有逻辑判断的能力，可维护性差，效率低下。
例如，同一个测试流程，比如登陆功能，测试一个valide的用户登陆，再加上一个invalide用户登陆，你就要录制两遍，生成两个脚本，代码复用性差，效率低。
假如某天登陆界面的页面元素发生了改变，你的脚本要相应的进行更改才能继续使用，你要做的是对这两个脚本都进行修改，你可能觉得这没有什么，但是假如你有成千上万个测试用例呢？所以说可维护性差。
对以上框架进行改进，数据驱动的自动化测试框架。
quote：该种框架的原理是采用了数据驱动脚本进行测试，数据驱动脚本是将数据输入存储在独立的数据文件中，脚本只存放控制信息，测试时输入直接从文件中读取，这样同一脚本可以运行于不同的测试用例中，实现了脚本与数据的分离。
还是登陆的功能，用QTP录制完测试流之后，对用户名，密码，验证点等进行参数化，放入数据文件，如excel，运行时读取数据文件。这样一个脚本，就可以实现valide和invalide用例的覆盖，增强了代码的重用性。相应的，页面发生了变化，只需要修改一个脚本就可以了，可维护性得到增强。
进一步改进，关键字驱动的自动化测试框架
关键字驱动（表驱动）是对数据驱动的逻辑扩展，它的核心思想可以概括为“三个分离”：
（1）界面元素名与测试内部对象名的分离：在被测应用程序和录制生成的测试脚本之间增加一个抽象层，它可以将界面上的所有元素映射成相对应的一个逻辑对象，测试针对这些逻辑对象进行，界面元素的改变只会影响映射表，而不会影响测试。
(2）测试描述与具体实现细节的分离:把测试描述和测试的具体实现细节分离开来。测试描述只说明软件测试要做什么以及期待什么样的结果，而不管怎样执行测试或怎样证实结果。这样做是因为测试的实现细节通常和特定的平台，以及特定的测试执行工具有着密切的联系。这种分离使得测试描述对于应用实现细节是不敏感的，而且有利于测试在工具和平台间的移植。
(3）脚本与数据的分离:最后，可以把测试执行过程中所需的测试数据从脚本中提取出来，在运行时测试脚本再从数据存放处读取预先定制好的数据，这样脚本和数据可以独立维护。
以上这“三个分离”各司其职、互相独立，最大程度地减少相互之间的影响。从关键字驱动的思想可以看出，该种测试框架不仅实现了将数据和脚本相分离，而且实现了测试逻辑和数据的分离，大大提高了脚本的复用度和维护性，从而更大限度得实现了测试工具的自动化 QTP自身就提供了一个关键字驱动框架,结合QC的控制管理,就是一个完整的自动化框架了,在研究其他所谓框架之前,先看看是否已经研究透了QTP所提供的所有功能及QC,研究基于QTP的框架切忌将原本工具就具备的实用功能复杂化,避免写的人高深莫测,学的人云里雾里 首先要理解何为框架
框架（Framework）是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互 ...
BlueSkyLoser 发表于 2011-4-21 12:22 http://bbs.51testing.com/images/common/back.gif
我对"三个分离"中的第二点不是怎么理解...... 本帖最后由 BlueSkyLoser 于 2011-4-21 16:27 编辑
回复 6# 43528782
可以这样理解，相同的测试用例，需要在不同的平台上跑，window下用一个脚本，linux是另一个脚本，使用框架，使其自动根据平台，调用相应脚本。
根据我的理解, 楼主做的就属于数据驱动.
至于框架, 这样说吧, 如果一个项目, 基于Web GUI, 总共100个Web功能页面, 几万个验证页面功能的测试用例, 如何进行测试脚本设计?
脚本要考虑到易维护, 易扩展, 并且要做到尽量少的重复性代码.
这应该就属于框架的范围吧.
PS, 几年没回这个论坛了, 感觉冷清了不少啊...对现在论坛的显示风格也不习惯了 回复43528782
可以这样理解，相同的测试用例，需要在不同的平台上跑，window下用一个脚本，linux是另一个 ...
BlueSkyLoser 发表于 2011-4-21 16:25 http://bbs.51testing.com/images/common/back.gif
是不是加上判断，把两个脚本给串联起来，放在不同的分支中就可以做到呢？ 根据我的理解, 楼主做的就属于数据驱动.
至于框架, 这样说吧, 如果一个项目, 基于Web GUI, 总共100个Web ...
木卫十二 发表于 2011-4-21 17:28 http://bbs.51testing.com/images/common/back.gif
数据驱动就是传说的通过读取用例中的数据来驱动脚本的运行，从而实现测试用例的自动化执行吧？ 数据驱动就是传说的通过读取用例中的数据来驱动脚本的运行，从而实现测试用例的自动化执行吧？
renquande 发表于 2011-4-27 10:42 http://bbs.51testing.com/images/common/back.gif
我的理解是这样的，呵呵．
另外，我觉得自动化测试不必要拘泥于这些名词，想办法最快，最优的解决测试任务才是王道． 本帖最后由 lyscser 于 2011-4-27 14:03 编辑
其实大家怎么理解自动化测试框架都是有道理的，毕竟自己所看到的、别人想要表达和别人已经表达出来的很可能就都不是一码事，满足自身的需求才是最重要的，每个人都应该有自己的理解。1、自动化测试管理框架，偏向于自动化测试的全局架构理论，把自动化测试的各个环节、要素的说明和规范文档化，测试管理结构文件实例化，在没有背离测试主旨的前提下，自动化可以在规范圈定范围内任意发挥，只要满足测试需求即可。这种框架本身也带有一些基于本公司业务特点和使用需求的其他功能，例如测试运行调度、邮件服务的使用、文件服务的使用和报表分析等等。这种框架在管理上下了较多的功夫，有了成型的架构之后就可以不依赖任何一个技术核心人物，大大降低了技术储备的难度和人员离职带来的风险。缺点是在这种理论指导下若没有相应的业工具支持，框架开发或工具和框架的二次开发比较费时费力。2、自动化测试开发框架，典型的代表就是被很多人推崇的QTP的自动化测试框架SAFFRON。这种框架的作用就是简化自动化脚本编写，分离业务、脚本操作和数据，自定义封装一些常用的操作，使自动化脚本在业务系统发生变更时更容易维护、开发速度更快。这种框架立意于直接达到关键字驱动的效果，但是如何能与整个测试部门或公司的管理有效的整合在一起，对测试管理工作起到决策支持的作用呢？很显然，单凭这个原型化的框架本身是很难做到的，因为它很单纯的应用于自动化测试程序开发这个动作本身，笔者觉得这种框架有一个更贴切的名字：自动化测试脚本开发辅助框架。个人理解，关键字驱动和数据驱动的最大区别在于描述性语言的使用上，描述性编程的优势是大幅减少了脚本对页面对象稳定性的依赖。像SAFFRON这种框架的好处也就在于即便页面控件的属性发生了一些变化，在它下面开发的脚本也能继续运行，除非出现逻辑上的不一致。而事实上对于我们的系统来说，页面元素的变化对我们来说也是一个系统监控点：是什么样的需求让编码人员去做这样的变动呢？带着这个疑问系统测试会做得更细致，如果忽略了这些微小的变更，测试缺陷遗留的风险将有可能会提高。所以两种编程方式各自有着自己的优缺点，从自动化测试脚本维护工作量和脚本灵活性的角度笔者更愿意使用描述性语言，但是从系统测试的可信度和是否足够细致的角度上去考虑，有些人可能更愿意使用傻瓜式的对象库。一种是理论化的概念管理型，一种是实际化的开发应用型，我们的理想自然是理论结合实际了。那么不妨把两种框架实例化地整合在一起，扬长避短，用来满足我们自身的需求。仔细考察一下上面描述的两种具有代表性的典型自动化测试框架，我们会发现他们并没有冲突，并且在本质追求上都是一致的：让自动化测试更加快捷方便。我们可以考虑把小的框架封装起来，作为大框架的一个组件来使用，这样并不影响他们各自的长处发挥，并且能够很好的消除各自的弱点。同时很明显，以大框架的包容性是不仅仅只能容纳一个小框架的，需要指出的是，不同的测试脚本开发原型框架有着不同的特点，对脚本编写人员的技能、测试工具、测试开发环境等因素的要求不一样，引进的时候我们或许会发现它本身存在与整体框架规范冲突的地方，这就需要我们在执行该领域规范的时候灵活变通，实现兼容并蓄。如果单从概念形式上还不能明确定义什么是自动化测试框架的话，那么我们不妨从自动化测试的发展进程来看看。众所周知基于QTP的自动化测试经历了下面这四个阶段：A、简单的录制、回放B、录制、参数化、加检查点C、模块复用、数据分离——数据驱动D、对象、操作、数据分离——关键字驱动——组件分离这是一个自动化测试由简单到复杂的过程，一个自动化技术难度越来越大的过程，一个让自动化测试更具灵活性的过程，也是一个让自动化测试越来越有趣的过程。不过，无论自动化测试如何发展，测试对自动化的需求始终没有变化：简化复杂的操作过程、保证测试的简单高效！那么我们如何把这些被拆解得支离破碎的一个个组件有机地组织在一起，来满足测试的简单高效的要求呢？自动化测试框架！所以，或许大家现在明白什么叫做自动化测试框架了：能够有效组织和管理自动化测试中所必需的各个组件、有计划地进行自动化测试执行并且支持测试结果分析和测试过程改进的结构实例或文件实例就是自动化测试框架。 学习了 回复 12# lyscser
高见，做到了跳出自动化，站在高处看问题，不过我用了SAFFRON框架，但是不知道怎么在不同的脚本里面能够直接引用里面封装好的函数，每个脚本每次都得重新导入一次这个VBS格式的框架 回复lyscser
高见，做到了跳出自动化，站在高处看问题，不过我用了SAFFRON框架，但是不知道怎么在不同 ...
renquande 发表于 2011-4-28 14:52 http://bbs.51testing.com/images/common/back.gif
app.test.action.item(x).setscript
app.test.settings.resource.add……
总之QTP自带的方法支持临时生成你需要的脚本 还得多学习啊…… 顶下，学习了 还在初级阶段 本帖最后由 小孩 于 2011-5-4 17:09 编辑
:) 框架不框架不重要，框架只是个名词而已，做自动化应该从实际出发，
自动化只要做到降低脚本开发成本和维护成本，减短自动化开发周期即可。
别太去在乎框架，这东西没人说的清楚，都是 人云亦云
我就整过根据用例去跑自动化的自动化脚本（不知道属不属于框架），这东西本身就是QTP关键字驱动（一个概念），但是我重写一遍，QTP关键字驱动还是不够亲切。
然测试人员根据用例规范去写用例，写出来的用大多数都可以自动化。不用再去写脚本或者录脚本。
自动化以人为本，越简单越好。 学习了~看来qtp要学习的还有很多呀~
页:
[1]
2
