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

shanxi

通俗点说 就是 投入产出比

hsjzfling

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

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

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

shanxi

我这边的数据是ROI非常低 自动化测试比不上手工测试重要  跑几百次才有可能发现1个bug，而且bug还是手工已经报过的。

要你给的数据也是个大概描述，你们的boss难道不会考虑这个？
我这也不缺你一个人的数据，起个头大家交流一下有什么不好的？遮遮掩掩的干嘛？这里大部分人的水平本来就低，弄点有技术含量的话题大家讨论一下为何某些人就那么逃避？很想不通。
关于自动化你公司的技术并不会高去哪，我对贵公司的界面自动化测试技术也根本没兴趣，没多少公司能开发自己的工具来做这个。

[ 本帖最后由 shanxi 于 2009-7-8 16:54 编辑 ]

hsjzfling

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

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

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

shanxi

你总喜欢抬杠，挑刺的一些东西我感觉也不在点上

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

hsjzfling

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

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

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

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

hsjzfling

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

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

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

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

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

hsjzfling

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

shanxi

路过的无视楼上的发言就行了

原帖由 hsjzfling 于 2009-7-8 17:30 发表
真的不想做人身攻击。前两天看你在peimzh招募出书作者的帖子中说你就小学文化

我就小学文化，也没觉得丢人！中国的学历教育流毒甚广啊：
平等、博爱等美好的品格在中国现在的教育中被忽视
，造成了许多人格不健全的。

[ 本帖最后由 shanxi 于 2009-7-8 18:09 编辑 ]

天高地远

不懂qtp的人来学习。

onlonely

这年头怎么都这么激动呢。

就我感觉来看,框架虽然不是所谓多高深的东西(装高深者令论)。不过要充分理解,设计一个很健壮的框架确实不容易
但是在使用QTP做自动化测试的时候(那些不使用或者不希望使用者令论)没有一定的框架思想来应用的话。
可以保证100%自动化是失败的。

当然,我们最初可以先使用些简单的,做些代码规范啊,公共函数库呀,脚本目录设计啊。
这些简单的还是非常必要的。

shanxi

其实楼主的话题有两个意义：
对一般人来说，选择用QTP这个工具利用好它基于它的设计思路也即框架就算是到顶了；

但对那些不拘泥于QTP这个工具的人来说，所谓的框架不过是每个人对UI自动化测试组织理解的一种反应：需求是什么就开发出什么样的脚本！

所谓的"激动"仅仅是某人强行想把观点加载于另一个人身上的一种言辞反应，但某些不变的结论是不会以个人意志为转移的。

[ 本帖最后由 shanxi 于 2009-7-8 19:22 编辑 ]

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 编辑 ]

dexterEar

话说发现新缺陷不是自动化测试的任务，记的一本书上是这么说的

lijinshui

关注中,有意思 赫赫
其实大家都挺有耐心的 哈哈
一字一句挑对方的语病,

dreamever

我比较同意hsjzfling的观点。
首先，推广自动化测试是我们国内测试领域的大势所趋，对自动化测试的研究和应用也必然不会停留在录制/回放的层面上。自动化测试要做的事情就是用代码去测试代码，用软件去测试软件。那么必然涉及到一个代码如何组织的问题，资源如何整合的问题，流程如何规范的问题，这些其实都是“框架”要去解决的问题。对于自动化测试刚刚起步的团队，不必将过多的精力投入到框架的研究上来。但是如果自动化测试进行了很长时间，已经形成了几千个用例的规模甚至更多，如果说没有相对成熟的框架，那么测试脚本的维护和扩展是不可想象的。
框架不是万能的，但是我们不能因此就断定框架是忽悠人的；框架的概念也可大可小，不见得框架都是一些虚无缥缈的理论和复杂的东西。我非常同意楼主“不能把QTP神话了”的观点，同时我也认为不能因此而把“框架”也一并送上断头台

loho1968

自动化测试的引入阶段，本来就应该在软件开发基本完成，功能、界面已经稳定的情况了。
这个和楼主所说的是否使用“框架“无关。

imlele

支持 hsjzfling

观点，论据很清楚了~

谁无理取闹，一眼就能看出来了

nbkhic

ROI的问题没必要讨论了。记得某位大师说过
自动化测试最多只能找到20%的bug
80%以上的bug都是手工测试发现的。
因此自动化测试的ROI就是如何以最快最廉价的方式执行那能发现20%bug的测试用例。没有太大疑问，用自动化的方式去执行那部分重复性极高的测试是一个比较好的方案。
因此自动化测试还是有市场的。