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

hsjzfling

原帖由 volvoo 于 2009-7-7 14:06 发表
qtp说白了就是一个界面搜索工具+编辑界面+vb脚本，其使用过程中，受限因素特别多，光维护脚本，就需要惊人的工作量，用在那里合适？
1 界面和开发用组件基本极少改变的情况
2 反复简单的压力测试
3 被测系统构造数 ...

如你所说，QTP自动化的最大作用就在于替代繁杂的重复性劳动。比如有个产品需要在4个不同的操作系统，3种主流浏览器，10个操作流程的组合，15组操作数据的情况下进行测试，自动化的作用就非常明显了。再比如每次发布后的Smoking Testing，也可以考虑用自动化来实现。

而框架则可以帮助我们统一的管理自动化工作过程，让我们可以便捷的遵从框架规范来开发、维护自动化脚本，更大程度上去利用HP Mercury已经集成在QTP中的功能，使得自动化过程有条不紊，而并不在于自己写的核心代码有多么的深奥，那只会让维护框架的成本更大，风险更大。

QTP确实只是一个工具，我们既然选择了它，就应该多去发掘它的最大价值，思考如何能更有效率的使用它，而不是一味想着如何去自己写更好的东西，那样还不如自己去开发新工具。

hsjzfling

原帖由 heqingbluesky 于 2009-7-8 11:56 发表


是的，用QTP主要是在测试软件的功能更改很小，界面更改很小的情况下使用。只能作为手工测试的一个补充。我们公司取消的专职的自动化职位，要求测试组基本都会操作这个软件。

框架的东西仁者见仁，智者见智。

自动化测试的存在可不仅仅只是作为手工测试的补充，它与手工测试的侧重点不太一样。手工侧重与对于程序业务功能上的测试，更多的倾向于发现程序新缺陷，这在测试活动中需要有想法有创造性的，具备自动化所没有的"联想"；而自动化侧重与重复性较高的回归测试，以及LS提到的正交法生成的用例的测试，一般这种情况下使用自动化会比手工去做效率要高。每天跑100个类似的用例，人会疲劳，机器可不太会。

所以你可以认为在你们公司自动化只是手工测试的补充，而不能一概而论。事实上，在一些产品成熟的企业，自动化的需求是很高的。

hsjzfling

这个就无可奉告了，你是否认可我所说的这些那也与我无关痛痒，你完全可以提出你的观点让大家来讨论，没必要给你说这些统计数据。

再说了，我若是随口说个数据，谁能证明是还是不是？有说服力么？数据是不会说谎，但人可能会。

如果你有兴趣给大家做个你们公司的报告，我想大家也很乐于看到吧。

hsjzfling

原帖由 shanxi 于 2009-7-8 16:39 发表
我这边的数据是ROI非常低 自动化测试比不上手工测试重要  跑几百次才有可能发现1个bug，而且bug还是手工已经报过的。

要你给的数据也是个大概描述，你们的boss难道不会考虑这个？
我这也不缺你一个人的数据，起个 ...

ROI不是这么算的，你说的那个叫 自动化测试用例的缺陷率。
自动化投入与产出的比应该是：以"用人工来完成某个测试任务需要花费的成本"来做为产出记做M，这个是可以根据测试管理的统计数据来计算出来，"自动化来完成同样的测试任务花费掉的总成本"做为投入记做A，这部分实打实花费掉了的成本。
A和M完成同样的测试任务，只是完成的方式不同，这样才会有可比性，A/M才是你所想要知道的投入产出比，A/M越大，那么该自动化过程实施的效益就越大。并且在M的开销中还包括了可以复用的产出，比如可复用的脚本、公用函数等，比如期间产生的自动化测试规范文档等等，这些都是可以在下一个自动化过程中节省下来的。
这些数据对企业来说或许重要，但是对于这里的技术人员来说就不见得有多大意义了，这话题也并没有什么技术含量，常识倒是包含了一点。
至于你的最后一句话，就真的有点不知所云了。
跟你交流次数也不少了，貌似实在跟你没什么共同语言

hsjzfling

原帖由 shanxi 于 2009-7-8 17:12 发表
以前碰到过一帮人，写了一个JS库能支持web自动化。我去问这帮人，此库同Selenium有何不同，当时没人正面回答我。当时很怀疑它们的库中有部分是抄袭得来的。

我这里想说
UI 自动化测试并没大家想象中的技术含量那 ...

真的很好笑啊，不告诉你我们公司的统计数据，这就叫遮掩技术了啊？还盖上阻挡技术为广大人民所掌握的大帽子。。。呵呵，逻辑思维还真是天马行空啊。。。

真的不想做人身攻击。前两天看你在peimzh招募出书作者的帖子中说你就小学文化，当时还觉得你很幽默，现在看来。。。这不会是真的吧。。。

hsjzfling

原帖由 shanxi 于 2009-7-8 17:23 发表
你总喜欢抬杠，挑刺的一些东西我感觉也不在点上

你所说是我计算错误其实不然，我没说几百次是耗费了多少人力写并维护，产生出了这么少的bug
要说ROI没技术含量，我感觉你们的自动化评估就没做好

此技术非彼技术，你要说项目管理是技术，那扫大街也是一技术活啊。

还好意思跟我说抬杠？要不要我把你以前跟我胡搅蛮缠还口吐恶言抬杠的几篇帖子在这里贴出来？看看是谁前几次都说的无话可说然后灰溜溜的删掉自己的所有回复装作没发生过一样？

唉，无视掉你的所有发言好了，跟你真没什么好说的。

hsjzfling

扶一下楼，LZ抱歉啊，真不是有意在你的帖子中说上这么多跟你主题完全不相干的回复。

hsjzfling

shanxi能不能先将我的论述一一有理有据的反驳以后再来给出一些结论来？

在我的发言中，我没有一句话说ROI不重要，只是说这和我们测试工程师想要学习的测试技术关系不大，ROI应该是项目经理或者测试经理级别的人去关心的问题。你从哪里得到我要抹杀ROI在自动化过程中的作用？

我不鄙视小学文化的人，我鄙视的是连一点基本的逻辑思维能力的人都欠缺却还不停大放阙词的人，鄙视你每次都是莫名其妙的得出一些结论。所以我说跟你没话好说。

你若想再下什么结论，请先学会有条理的反驳掉我的论述，不然，敬请你闭嘴。

hsjzfling

原帖由 shanxi 于 2009-7-8 17:23 发表
你总喜欢抬杠，挑刺的一些东西我感觉也不在点上

你所说是我计算错误其实不然，我没说几百次是耗费了多少人力写并维护，产生出了这么少的bug
要说ROI没技术含量，我感觉你们的自动化评估就没做好

就当时你说了几百次是耗费了多少人力写并维护，产生出了这么少的bug，请问你如何来评估ROI高还是低了，标准是什么？多少个bug才算多?怎么来评估投入与产出的比例？
不管你花了多少代价去做这些事情，你用bug数量来评估，得到的还是自动化测试用例的缺陷率。

在我的论述中，只要A(自动化成本)/M(手工成本) <1 那么就可以认为自动化实施是成功的，即使等于1或者略大于1也可以认为它是成功的，因为第一在自动化实施的工程中有可以复用到其它自动化过程的产出，第二，我想没人愿意去天天做重复劳动吧。

[ 本帖最后由 hsjzfling 于 2009-7-8 21:40 编辑 ]

hsjzfling

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

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

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

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

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

hsjzfling

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

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

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

hsjzfling

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

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

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

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

hsjzfling

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