一定不要把qtp神话了，所谓的框架是忽悠人的

shanxi

请你闭嘴,停止无理取闹！
我不想把此贴的内容引向偏离主题太远的地方。我根本没兴趣对你的话一句一句评论，这对我来说并没有value。

这里大部分人的自动化仍然建立在QTP这一个工具之上，离开了这个工具，连造轮子的能力都没有。
对一个特定工具来说，它的设计思想决定了最适合它的框架总是集中在那几个方向上，但这并不否认其它方式设计的框架不行，只要你在点和面上完成统一，只要开发出的代码符合项目的实际需求并得到公司领导的认同即可。

回复 40# 的帖子
我想楼主当然还有我，并没有完全否定掉自动化测试的作用。却是在一定程度上放大了自动化的局限性。关于自动化还有一个比较高的数据：
单元自动化测试最高能达到70%的覆盖率。

[ 本帖最后由 shanxi 于 2009-7-9 10:49 编辑 ]

mealready

╮(╯▽╰)╭
一个人会玩 他是神
但很多人都会了 他就是人了

xiaoyaoke

首先：我是坚定的站在shanxi的这个阵营的
然后说说我的理解：自动化测试理论上相当于用软件测软件，这里面分为两个层次，如果你是是从产品的层次角度去考虑来写测试脚本，这就说明你基本上是在干研发的活，因为你要考虑代码复用，函数的性能，还有容错处理等等研发需要考虑的问题，如果只是单纯的将测试用例反映为脚本，你还只是普通的测试员工，也就是说：我们先行的所谓框架，不过就是在开发一款测试你产品的软件中所考虑的基本的编程事项，试想：你开发一款软件能叫开发一款“框架”吗？
嗯，那接下来说框架吧，我们公司一个10多年的研发写了一款页面开发的框架，PHP的，问题挺多，去年我们测试组的4个人想写一款测试用的框架，但由于时间，能力等原因没成型
从中我也思考一点问题：框架是什么？研发在给我们培训的时候说过：框架就是预先定义的各种接口，你按照接口的定义去编写一些简单或附件的代码就可以实现整个逻辑的实现，也就是说：“框架”的可重用性不能单纯的只是项目本身，而至少是同类软件或者更广阔的范围。
我们所谓的框架，封业务逻辑，业务逻辑的实现就已经注定这所谓的“框架”不要说应用到同类软件，就是换一个项目也已经无法使用了。。。试想，只是针对特定项目的测试代码能够叫框架吗？一点通用性都没有的

hsjzfling

谢谢37，39楼的支持
说话是要有根据要讲道理的，大家的眼睛是明亮的

回40楼，你说的没错，自动化的目的就是为了去解决那些重复度较高的工作，其目的不是为了发现新的bug，而是在于减轻部分手工测试的压力，主要是应用在冒烟测试等重复性很高的测试活动中。

想提高自动化的ROI那就需要把有限的自动化资源投入到重复度最高的工作中。在资源较充沛的情况下，再去考虑扩大自动化覆盖率，可以按手工测试的重复度及自动化实施的可行性来排优先级。

回37楼，每个人对于框架都有不同的理解，我以前也认为一个脚本的组织结构就是一个框架。当然也没有最好的框架，只有最适合的框架，适合各自企业各自项目各自产品的框架。框架这个概念确实比较虚，因此我们需要将它实体化，让它能够真正的很好的协助我们工作，框架的设计应该是与具体的公司环境、产品、项目环境密不可分的。

我现在认为框架可以这样来定义，一个广义的完整的自动化框架应该定义一个完整的自动化测试过程。它应该可以让一个公司或一个项目组很清楚的知道如果他们想要按照框架来实现自动化，那么具体应该要准备什么样的资源，并评估其可行性。
通过框架他们需要知道应该按照什么步骤来做些什么事情，如何来做这些事情，做的过程中需要注意些什么问题，每个过程的输入和输出又是什么，等等，这些与我们通常所提到的自动化测试技术关系不大。
然后框架中再包含我们通常提到的脚本组织结构的狭义框架，比如如何来分层，驱动的模式，数据文件的结构等等。

hotcaoyong

我认为框架是让编程人员更傻瓜 让代码更规范

wuei9090

一部分测试人员觉的  凭什么都是IT 我们就不能写代码   于是自动化脚本出现了

又一部分测试人员觉的  凭什么他们开发天天框架框架的 strus spring的  我们也能 于是自动化测试框架这一概念又出来了

hsjzfling

原帖由 xiaoyaoke 于 2009-7-9 11:26 发表
首先：我是坚定的站在shanxi的这个阵营的
然后说说我的理解：自动化测试理论上相当于用软件测软件，这里面分为两个层次，如果你是是从产品的层次角度去考虑来写测试脚本，这就说明你基本上是在干研发的活，因为你要 ...

你说的确实是一种比较失败的尝试运用框架的实例，这能够给我们探索出更有效更可行的框架提供可参考的经验。

建议你了解下HP BPT，它提供了一种使自动化工程师(不是自动化测试工程师)独立于业务之外的方案，部分思想值得我们去借鉴。

xiaoyaoke

“建议你了解下HP BPT，它提供了一种使自动化工程师(不是自动化测试工程师)独立于业务之外的方案，部分思想值得我们去借鉴。”  我认为正是这种BPT使测试脚本增加了对QTP工具的依赖性，从而无法独立于被测试项目。

简单的说QTP是关键字驱动的框架，如果你的框架可以基本实现QTP的功能，那么可以说是框架了。

dreamever

原帖由 shanxi 于 2009-7-9 10:21 发表
请你闭嘴,停止无理取闹！
我不想把此贴的内容引向偏离主题太远的地方。我根本没兴趣对你的话一句一句评论，这对我来说并没有value。

这里大部分人的自动化仍然建立在QTP这一个工具之上，离开了这个工具，连造轮子 ...

那个……弱弱的说一下，可能你想说的是“并没有价值”，但是在英文里合适的翻译应该是worthless ，比如说：
Talent is worthless unless you persevere in developing it.除非你坚持不懈地发展天赋，否则它是没有价值的。
或者你用valueless也可以，但是不能把汉语的“没有”和英文的“value“加在一起，
刚才看到了就顺带一提，其实我英文也不好，都是从词典里搬来的。

hsjzfling

我们讨论的就是QTP呀，既然QTP工具提供了这些很好的功能和特性，为什么我们不去尽可能的发掘它已有的价值呢？使用HP Mercury提供的QC+QTP的结构，已经能很好的帮助我们解决一些问题了，再加上BPT提供的组件功能和思想，我想这应该比我们自己去开发效率要高的多吧。

如果太多的去关注如何不依赖QTP提供的功能，如何去不依赖QTP这个工具，那这已经有违讨论QTP使用技术的初衷了。我想更多在这个QTP专区的朋友们也是希望能够更好的使用QTP来完成自动化任务吧。

BPT的思想之一是要将业务与自动化技术剥离，也就是说自动化工程师只需要专心让脚本跑通就好，并不用去研究业务逻辑到底是怎样的，测试逻辑测试验证点这些都是由业务专家、测试人员来指定。
这一套操作模式结合QTP+QC提供的功能就组成了一套很好的可以被复用的框架了。对于我们来说，只需要略微做些修改，让其符合本公司的模式即可。
实在复用不了那也没办法，因为它也不是万能的，不可能照顾到每个企业的情况。

如果自己能开发出比QTP更好用的同类工具，那就真的太牛啦。

hsjzfling

当然，我们也可以不用QC不用BPT，但QTP总还是要用的吧，结合企业一些特性，我们一样可以设计出适合自己企业使用的框架。

小_麦

支持hsjzfling~!
做工作,就是尽量快速,有效...QTP可以实现我们的目的当然要用,及时我们站在QTP的平台上,做开发,写框架..那样都是很好的,毕竟工具为我们实现了很多方便的功能,我们不一定非要抛开QTP,从最底层做起...那样做怎么完成测试工作?

heqingbluesky

原帖由 xiaoyaoke 于 2009-7-9 11:26 发表
首先：我是坚定的站在shanxi的这个阵营的
然后说说我的理解：自动化测试理论上相当于用软件测软件，这里面分为两个层次，如果你是是从产品的层次角度去考虑来写测试脚本，这就说明你基本上是在干研发的活，因为你要 ...

可能你说的框架是为了实现某个C/S或者B/S结构的软件来说的。对于QTP而言，我们要说的框架，业务的逻辑不在框架内实现，是在每个脚本中实现的。只有这样，你框架的通用型才强，不会每个软件一个框架。

xiaoyaoke

请问你所说的框架主要包含的功能有哪些?

f84248860

我说两句~

中国人的习惯，先抄再改。(TAOBAO. XIAONEI..etc)

所以在我们准备想改之前，最好问问自己，你抄全了没有？

billhu

我们公司是大公司不用盗版软件，另外调研时发现QTP太大，有时死机不太稳定，不能脱离QTP运行造成部署不便等原因，自己开发了测试工具，是针对特定产品开发的，实现了测试业务逻辑和实现分离。相当小，程序加上测试业务逻辑（大约实现了1、2千个测试用例的自动化）不过10M多。运行时间大约20小时。产生的效益我认为象小马过河，既不能神化，也不会一无是处。回过头看看，QTP还是很了不起的工具，做的那么通用，能够适应多种情况，可用性很强。现在，我们的兴趣在计算机辅助进行测试设计。

xiaoyaoke

未来之路

heqingbluesky

原帖由 xiaoyaoke 于 2009-7-9 16:30 发表
请问你所说的框架主要包含的功能有哪些?

就是可以让QTP在不同的架构的软件下运行，有入口，输入/输出，错误处理，日志，数据比对等等。

具体业务的实现在不同的case中。不知道这个是否可以称为框架？

xiaoyaoke

就是可以让QTP在不同的架构的软件下运行，有入口，输入/输出，错误处理，日志，数据比对等等。

QTP不是都实现了吗？

wtucel

原帖由 jadeyu712 于 2009-7-8 13:15 发表



不能做压力测试。但是可以把功能脚本放到LR中当作压力来测试。

还有这个功能？不是吧，QTP是依靠对象库的，我还不知道LR也有对象库的概念。