刚看了梦醒十分的自动化框架演示视频，感觉。。。

yabest

感觉比较好笑

视频1：测试人员在Excel里写伪码，自动化专家再将其转化为QTP脚本
   这种在Excel里写伪码的所谓QTP框架在网上多的是，但功能都是弱智的可笑，根本没实用性，拿来推销也太不负责了。

视频2：测试人员在Excel里写伪码，点按钮自动转换为QTP描述性方式脚本
   在Excel里写伪码已经够弱智的了，还要把弱智伪码做这样的简单转换，简直多此一举，还不如直接写QTP脚本呢！

视频3：测试人员录制了QTP对象库方式脚本，点按钮自动转换为QTP描述性方式脚本
   总算开窍了，知道在Excel里写伪码是弱智的了。以为还有救，谁知道竟拿出了更让人晕倒和吐血的方案！
   人家QTP费这么大心血搞出的对象库，简直是QTP的精华，有人却费尽心机的要把这精华阉割掉，估计QTP设计者会被活活气死！
   真那么喜欢描述性方式脚本，就直接用Robot好了！Robot没有对象库，生成的脚本直接就是描述性的，何必转换来转换去这么麻烦呢！
   
自己做做实验未尝不可，不过要给人家做培训，那就得谨慎，不要把不成熟不实用的东西随便推销给别人！

实话实说，不要介意！

[ 本帖最后由 yabest 于 2007-8-17 23:26 编辑 ]

wasd2615

我没分下不了哦 你可以发给我看看不咯 楼主大哥

QTP高手

这是我对他框架的评价！和你有同感！呵呵
看了视频，不得不说一个话题，这是一个QTP熟悉者玩得花招！如果把它作为框架无疑是误人子弟，如果让新手看到之后，反而把别人带到一个错误的自动化框架的方向。而且一个业务人员一个QTP人员就能实施公司的自动化，那么公司老总发财了。这些言论无疑实在对自动化讽刺。以及自动化的神化。建议新手看看他的技巧，别学思想。另外一个建议：想通过视频作培训，不如把QTP谈谈好，否则别人也不感请你做培训，因为老板很喜欢听你的言论，但是苦了辛辛苦苦工作的同行们

dionysus

原帖由 yabest 于 2007-8-10 18:36 发表
可笑得都有点生气，还是等晚上消消气了再说！

————————————————————————————————————————————————————————
继续说：

视频1：测试人员在Excel里 ...

我认为梦醒十分上传的自动化架构视频是他逐步探索总结的一个过程，通过调用函数自动转换成描述性编程在测试过程中是十分有用的。我想lz肯定是没有做过多语言版程序的自动化测试吧。同一个网站包含FJGK多钟语言，但总体结构却是一样的，这样只需录制一遍操作之后批量转换成描述性脚本即可。这是实践出来的结果。

raymanan

期待各位高手进一步的讨论.
谢谢!

wtucel

感觉LZ说得有点过分了,人家抽出自己的空余时间录制了这么多实际的例子,确实给我们这些还在探索中的人开阔了很多思路,自动化框架的实践本来就是逐渐改进的过程,大家都不是傻瓜,自动化本来就是用来提高效率,舍易求难肯定会失败,所以根本不存在你说的误倒.
      我觉得这里还是一个'做'与'不做'的问题,去做了,就算做出的东西是拙劣的,也总比纸上谈兵,大谈理论的强,相信大家小时侯都学过'第三只小板凳'的故事吧.

梦醒十分

特此声明：
此贴不存在为“梦醒十分”炒作之嫌
两位批评者并不是我请的托儿。
期待两位高手做一个真正的自动化框架视频，让大家分享。


[ 本帖最后由 梦醒十分 于 2007-8-13 09:46 编辑 ]

yabest

原帖由 dionysus 于 2007-8-11 10:30 发表

我认为梦醒十分上传的自动化架构视频是他逐步探索总结的一个过程，通过调用函数自动转换成描述性编程在测试过程中是十分有用的。我想lz肯定是没有做过多语言版程序的自动化测试吧。同一个网站包含FJGK多钟语言，但总体结构却是一样的，这样只需录制一遍操作之后批量转换成描述性脚本即可。这是实践出来的结果。

多语言版程序就更应该用对象库了！

我们测试的系统都是同时有中文、英文、日文等多种语言的。一般都是在英文版本下录制好脚本，然后只要修改对象库，用正则表达式匹配兼容其他语言版本，根本就不用修改脚本，简直太方便不过了！

我不知道你说的描述性编程对处理多语言版本有什么作用。
难道转换成描述性脚本后，将里面的文字一个个替换过去？这也太累，太容易出错了吧！
而且这样处理过后，就存在多套脚本了，将来怎么修改，怎么维护呢，难道要同时修改、维护多套脚本？

yabest

原帖由 梦醒十分 于 2007-8-11 11:02 发表
十分感谢LZ的批评，包括8月10日才新注册的“QTP高手”，我早知道“培训”同行是冤家，在我预料之中。
我想会有很多新注册的“QTP高手”对我进行批评，我都会“虚心”接受。

再次感谢楼主的这个贴子，它会让更多的初学者来看我的视频，“从此上当而走向QTP的弯路”，
我希望看过的人，像LZ这样多给一些直率的批评，谢谢。

做培训师给人做培训，就要更加谦虚，更加谨慎，要虚心接受别人的批评，时刻反省自己。
因为这不是你一个人的事，你犯的错误，将通过培训传播给很多人，到时只会害了很多人。

[ 本帖最后由 yabest 于 2007-8-15 15:16 编辑 ]

dionysus

原帖由 yabest 于 2007-8-11 13:30 发表


多语言版程序就更应该用对象库了！

我们测试的系统都是同时有中文、英文、日文等多种语言的。一般都是在英文版本下录制好脚本，然后只要修改对象库，用正则表达式匹配兼容其他语言版本，根本就不用修改脚 ...

我说一下描述性编程对多语言软件的测试吧，我这里同样也是首先在英文版上录制一遍操作，这时脚本里面记录的都是英文版的对象和属性值，之后调用automatic framework（一个函数库，里面包含将录制出的语句自动转换为描述性编程语句的一系列函数和操作），把脚本语句中所有的逻辑对象替换成属性和属性值，通常是以index来替换。这时生成的这一套描述性编程的脚本就可以在所有语言环境下回放了。当然其中肯定还需要调试。
在对象库中使用正则表达式兼容所有语言也是一个方法，但我想它的工作量一定不小，而且还需要对正则表达式掌握较熟练的人才能操作。
使用自动化框架则可以只运行一个自定义好的函数就将所有录制的语句转换过来，对一般操作人员来说相对简单不少，不过这个框架的编写和维护也是很需要技术的。
另外lz不要动怒，这只是一个技术上的讨论和分歧，QTP提供多种方法支持回放，我们就找一个适合自己的。如果发现以后在应用中逐渐不满足了，看看其他的方法也是一种启发。练剑练气全看自己的选择，我们不用非要灭了一派吧sdlkfj3

yabest

原帖由 dionysus 于 2007-8-11 14:23 发表
我说一下描述性编程对多语言软件的测试吧，我这里同样也是首先在英文版上录制一遍操作，这时脚本里面记录的都是英文版的对象和属性值，之后调用 automatic framework（一个函数库，里面包含将录制出的语句自动转换为描述性编程语句的一系列函数和操作），把脚本语句中所有的逻辑对象替换成属性和属性值，通常是以index来替换。这时生成的这一套描述性编程的脚本就可以在所有语言环境下回放了。当然其中肯定还需要调试。
在对象库中使用正则表达式兼容所有语言也是一个方法，但我想它的工作量一定不小，而且还需要对正则表达式掌握较熟练的人才能操作。
使用自动化框架则可以只运行一个自定义好的函数就将所有录制的语句转换过来，对一般操作人员来说相对简单不少，不过这个框架的编写和维护也是很需要技术的。
另外lz不要动怒，这只是一个技术上的讨论和分歧，QTP提供多种方法支持回放，我们就找一个适合自己的。如果发现以后在应用中逐渐不满足了，看看其他的方法也是一种启发。练剑练气全看自己的选择，我们不用非要灭了一派吧

啊，你转换成描述性脚本，就是为了去掉对象的其它属性，改成只用index附加属性？
可用index也太不可靠了吧，不然QTP干嘛要设置一大堆属性啊，都用index属性好了！

我说的对象库兼容，不需要用太复杂的正则表达式啊，只要用最简单的|表达式即可，比如 “OK|确定”、"Cancel|取消“这样子，就可以兼容中英文了，而且这样才准确才有保证嘛!

各种技术都有各自的特点的，虽然万法归一，条条通罗马，但是适用情况和成本代价是不一样的。
就像现在没人要灭了汇编语言，汇编语言还是有它的特点和适用范围的，但是你要跟初学者说明，大部分情况用高级语言，特殊情况才用汇编啊！这可不能搞混的！不然就没必要讨论了！

danmy

原帖由 dionysus 于 2007-8-11 14:23 发表


我说一下描述性编程对多语言软件的测试吧，我这里同样也是首先在英文版上录制一遍操作，这时脚本里面记录的都是英文版的对象和属性值，之后调用automatic framework（一个函数库，里面包含将录制出的语句自 ...

automatic framework 这玩意在哪? 貌似挺有用d

dionysus

原帖由 yabest 于 2007-8-11 14:41 发表


啊，你转换成描述性脚本，就是为了去掉对象的其它属性，改成只用index附加属性？
可用index也太不可靠了吧，不然QTP干嘛要设置一大堆属性啊，都用index属性好了！

我说的对象库兼容，不需要用太复杂的正 ...

肯定不止是用index一个属性来标识对象的。在我们测试的程序通常都很有7、8个语言的版本，如果在对象库中把每一个对象的label或text都加上不同语言那是很费时间的，而且容易出错（德语的单词比其他欧洲语言要长很多，8个语言都写到一个属性值里，不知道是否有长度的限制，对于GB18030四字节的文字能否正确显示没有试过，也不太清楚）
我开始接触描述性编程的时候也对它的便捷性有过疑问，如果真是对照对象库来把脚本都一一改成描述性语句，那纯粹是胡闹，有时间没处打发了。
但后来接触到自动化框架后，觉得普通tester只需调用一个函数就能自动转换所有语句为描述性语句，确实方便快捷。
在QTP的一般应用里对象库优点很明显，甚至都无需对它做什么修改，但接触到像这种多语言版本测试时，使用自动化框架转为描述性编程，脱离语言的限制效果更好。
像我这样的QTP初学者肯定偏向于用对象库，简单明了何乐而不为。而企业级的应用或高手们的自动化框架探索则描述性编程可以发挥更大的作用吧

yabest

原帖由 dionysus 于 2007-8-11 15:45 发表

肯定不止是用index一个属性来标识对象的。在我们测试的程序通常都很有7、8个语言的版本，如果在对象库中把每一个对象的label或text都加上不同语言那是很费时间的，而且容易出错（德语的单词比其他欧洲语言要长很多，8个语言都写到一个属性值里，不知道是否有长度的限制，对于GB18030四字节的文字能否正确显示没有试过，也不太清楚）
我开始接触描述性编程的时候也对它的便捷性有过疑问，如果真是对照对象库来把脚本都一一改成描述性语句，那纯粹是胡闹，有时间没处打发了。
但后来接触到自动化框架后，觉得普通tester只需调用一个函数就能自动转换所有语句为描述性语句，确实方便快捷。
在QTP的一般应用里对象库优点很明显，甚至都无需对它做什么修改，但接触到像这种多语言版本测试时，使用自动化框架转为描述性编程，脱离语言的限制效果更好。
像我这样的QTP初学者肯定偏向于用对象库，简单明了何乐而不为。而企业级的应用或高手们的自动化框架探索则描述性编程可以发挥更大的作用吧

我还是很好奇，也没看懂你这个转换是怎么做的，能简单举个例子吗?

比如 Button("OK").Click，对象库里OK按钮的属性是Text=OK，那你转换后的描述性脚本是怎么样的？
因为要兼容很多种语言，又不一一修改成多种语言文字，也就是你就不用Text属性了，只用index附加属性了？但是你怎么知道OK按钮的index是多少？

dionysus

就如你举的这个例子，我可以使用GetTOProperty函数取得"OK"的index或其他属性值，最后将取得的值替换掉这个逻辑名称，生成一个新的语句，如Button("index:=1").Click这样的语句，再次回放的时候qtp就不会受语言的限制了

QTP高手

我来回复梦兄的疑问，第一、我不是做培训的，我听得你后面的话觉得很有趣。我想你的目的希望寻求培训的机会。这个无可厚非。只要你有本事就出来做了。我想你做QTP可以但是你硬说这是框架，把框架说的这个神乎。简直难以想象的
第二：你把别人的看法，当成对你的攻击言辞，是不是非得我捧你几下才不算是攻击呢

你把QTP中的技巧当作框架，让我实在无法接受，你不懂框架的基本的设计模式，而谈框架。实在听不下去。也许你的QTP知识不错。但是距离框架一说差的太远了。我在我的答复过程中我希望大家学习的QTP技巧，而不能学你的框架思路。而且什么一个业务人员一个QTP人员来写这种你想得框架。唯一结果你是把别人带到死胡同里面去了。

QTP高手

Button("index:=1")，这种写法也许在某一特定环境下可用，但是有个很大的局限性。你的开发人员将这个顺序换掉了。这个对程序一点影响都没有。那你的脚本就完蛋了。而且使用这种方法会影响运行速度！不建议使用！大家有兴趣去看看win32 SDK的属性识别技巧！呵呵！

yabest

原帖由 dionysus 于 2007-8-11 22:17 发表
就如你举的这个例子，我可以使用GetTOProperty函数取得"OK"的index或其他属性值，最后将取得的值替换掉这个逻辑名称，生成一个新的语句，如Button("index:=1").Click这样的语句，再次回放的时候qtp就不会受语言 ...

更晕了，对象库里OK按钮的属性只有“Text=OK”，没有index属性的。即使有，那也是index=0（因为只有一个Text=OK的按钮）。
但是窗口里按钮有多个，OK按钮不一定是排第一个，Button("index:=0")不一定指向OK按钮的。

所以我更糊涂了，是不是记错了？

QTP高手

在答复的dionyons一个问题，如果梦醒十分，是把QTP语言转化成描述性语言来写，那他就太傻了点。我想十之七八是借助了EMOS的做法，你可以去看看EMOS的源码。说起来也挺简单的！

yabest

原帖由 wtucel 于 2007-8-11 10:56 发表
      感觉LZ说得有点过分了,人家抽出自己的空余时间录制了这么多实际的例子,确实给我们这些还在探索中的人开阔了很多思路,自动化框架的实践本来就是逐渐改进的过程,大家都不是傻瓜,自动化本来就是用来提高效率,舍易求难肯定会失败,所以根本不存在你说的误倒.
      我觉得这里还是一个'做'与'不做'的问题,去做了,就算做出的东西是拙劣的,也总比纸上谈兵,大谈理论的强,相信大家小时侯都学过'第三只小板凳'的故事吧.

主要是对他期望太高了，当初他那口气（是回复我对他视频一的意见），把我胃口吊得老高。
就耐心等啊等的，等到视频二、三出来了，一看，简直。。。
我们在这边随便讨论和尝试也就算了，但是培训师不一样，培训师要更加负责任的！

原帖由 梦醒十分 于 2007-7-20 09:43 发表
1：我讲的都是以前在项目中的亲身经历，我想经验能使人少走弯路。
2：我想传达的是一种设计思想和方法（要求是能真正理解），实不实用另说。
3：如果讲完第二期，甚至第三期，你还不理解什么是框架或还把某段框架代码看成是实用的万能工具，那么是我讲的不好。
4：如果讲完第二期，甚至第三期，你还不能自己动手用VBS或excel VBA(宏)写出类似的东东，只能向别人索取现成的，那么我白费劲了。。

[ 本帖最后由 yabest 于 2007-8-15 15:25 编辑 ]