1.我在iButtonOne="124"+i;后加上PAUSE(iButtonOne);时显示的iButtonOne的值时后面好像并没有自动加上0，不过我明白了您的用意了！
2.脚本中直接引用对象的物理属性，将GUI MAP的维护直接放到脚本中，方法确实不错！不过在很多不同类型对象的测试过程中，要将物理属性复制到脚本中来，这样做脚本的时候是不是增加了写脚本的时间呢？或者，您是不是有什么方法在录制的过程中将对象的物理属性直接读到脚本中来阿？
3.WR测试响应速度是不是就是同步点？ Originally posted by pcl2004_27 at 2005-10-13 11:52 PM:
送给存在疑虑的人！
第一。 Window 2000 和 Window xp的计算器是完全两个软件，但是不同的地方在于软件本身的显示结果的控件对象是一个是static，一个是edit！所以这是两个软件，脚本跑不通很正常！还有就是路 ...
送给喜欢用！的人：
看你的贴子第一印象就是喜欢用这个粗粗的感叹号啊，至于有这么多重点强调么？就算你是希望大家”可以悟出很多东西“，可也令人想起上世纪60，70年代随处可见的大字报，呵呵。
言归正传：
1。”Window 2000 和 Window xp的计算器是完全两个软件"
完全？真的是这样的么？仅仅从WR对GUI的识别不一样就断言软件不同，未免武断了些。从表面上看，一个版本5.0(2195),一个版本5.1(2600)，基本可以判断2者相差不多。可是为何两者GUI识别不同呢，如何验证一下，可以做个试验：把XP的calc.exe copy到2K里，运行一下，看到什么？两者竟然一样。再把原来2K中的calc.exe copy到XP里，运行一下，竟然运行结果也和XP的一样。看来这两个EXE在不同OS里所进行时做的某些系统调用是完全相同的，如果真的要辨别是否完全相同，可能得看看其代码了。
"如果从实际的项目中来看，也不会用同一套脚本在两个不同平台上测试两个不同的版本的软件！"
为何不能通用？如果2个测试脚本逻辑部分完全相同，不同的仅仅是不同OS上GUI的某些物理描述不同，那为何不能在脚本目录中放入2个不同的GUI文件，让脚本自己判断OS并自动调入GUI文件里？从而实现一个脚本配多个GUI的而实现不同OS的适应性。
2。可维护性。
对于一个正常情况下的WR测试脚本，待测软件的GUI物理描述可能完全不像计算器中的GUI物理描述那样有规律可循。那种情况下，如果再拘泥于简单的减少GUI对象，我不确定是否会适得其反。就算你坚持这样操作，那么从实际操作过程来说，你也得先人工用WR学习一遍所有得GUI对象，然后再分类，归纳总结出其内在规律，再编写脚本，这样是否耽误太多时间？实际测试往往进度很紧，有那么多时间给你么？万一碰到某个版本中那所谓的“内在规律“改变了，你还得重新再归纳总结一遍。而如果使用GUI文件，只需自动重新学习一遍即可，你的做法有些舍本逐末。
”可维护的工作量更加少！脚本可扩展性也更好了，可扩展性好意味着可维护性也就越好！“
这话读起来使我想起数学里的”充要条件“，呵呵，或者说回文诗。
真的如你所讲的那样么，恐怕你还是以偏概全了吧。难道用了GUI文件的脚本扩展性就不好么？正因为有了GUI，用户就可以在GUI文件里简单的添加新的对象，就可以实现在自己原有脚本的基础上增加其他测试逻辑来测试新增的GUI属性。
3。 ”还有一个wr是可以测试响应速度的！请多想想！"
呵呵，我是测试新手，才入行没半年，想不出这个如何解决，烦请斑竹再抽半小时给个脚本，“实现测试计算器在不同CPU负载百分比下的各种响应速度。”。对了，只能用WR来实现哦。谢了！
[ Last edited by fengqiwen on 2005-10-14 at 12:35 ] 没想到楼上这么大的反应！呵呵 先说声对不起！
可能平时聊天惯了！那么对不起！我承认自己没有注意到"细节问题！
我把上边的帖子给改了！不好意思又用了感叹号！
其他的两个问题，我们晚一点讨论！ 呵呵，哪里哪里，斑竹实在客气！
斑竹的确很心细的，比如在变量转换时考虑到用一些代码保护，都是值得大家学习的！
大家继续讨论哈！
继续学习，这些天学习到了不少东西，支持~！ pcl2004_27:呵呵,应该说我没有曲解你的话.
首先,对于你这一贴中感叹号的减少表示欣赏,毕竟,大家心平静气讨论一个技术问题,本来就没必要大呼小叫的.
其次,这一贴中你的观点也较少偏激绝对化的观点,也是值得赞扬的,诚如你所言,大家对一个问题可以有多种想法,有多种解决途径.不同的方法在一个测试环境中可能表现比较好,可换一个测试条件和环境就未必是最佳.
再次,从你的帖子里看到你所从事的测试规模都比较大,也积累了很多心得体会.我和我的一些同行的朋友所从事的都是一些小规模的测试.基本没有一个脚本20000行的测试用例,基本上我偏重于脚本小型化,把一个大的测试用例分解成若干个小的测试用例,一来便于脚本的调用,二来便于脚本维护.同时,我的经验是把脚本用batch 方法整合起来,或者在专用机器上跑测试,或者下班后开机运行测试脚本,这样就不会有上班时间花费时间等测试结果的现象,而可以把上班时间花在测试设计,编写和调试脚本上,工作效率也能保证.
有幸你那里的项目需求写的那么详细,我这里可没你那的详细,基本粗的就像用户手册的function list,呵呵,没办法,小公司.我这一个production下分如干个项目,这些项目彼此都基于一个基本框架,可是GUI又不完全类似,每个项目周期不长,所以要求我们的脚本要小型化,模块化,便于组装.
按你的帖子,你所说的维护是指那些不变的GUI对象,这样的话,那放在GUI文件里不变的GUI对象更可以说不必维护了.所以我觉得,你的方法也许是可能在速度上有所谓的提高,但是你又说速度提高是基于脚本算法的提高,当然也许你说的算法也包括把一些GUI直接放在脚本而不是GUI文件,这个观点有官方的论据么?或者说有无一个第三方软件来测试一下.不过我觉得对于WR这种本省就是低速运行的解释型脚本程序,其本身的每一句脚本之间的间隔将是决定一个脚本运行时间长短的主要因素,在此基础上才可能是调用GUI对象文件查找对象花费的时间,而对于一般中等规模的脚本来说,前者的时间可是远远大于后者的,起码我们可以人工调节WR每一句脚本之间运行的间隔.
当然,可能存在你说的那种超大规模的脚本和超大规模的GUI文件,导致查找时间足以影响整个脚本运行时间,这时,也许你的方法的确会有效一些,呵呵,希望我不要碰到那种case,我觉得写那种脚本简直是受罪.
关于最后一个问题,我不知为何你不能理解?你作为一个WR高手,我也确定这个对于你来说不成为问题.我再把问题细化一下并且简单形象化一下,我们在windows任务管理器中都能看到CPU使用性能,对吧,有个百分比那个.现在的要求是"在计算器的进程分别设为实时,高,标准,低4种优先级状态下,对应于CPU使用从0%,到100%,每隔10%测试一下计算器计算5*5的相应速度".这个描述是否清楚?呵呵,我们的software requirment里的响应时间需求比这个粗多了,都靠我们测试人员和PM, RD后期沟通确定细化的指标.没办法,小公司,不正规啊.
还是那个要求,用WR本身来实现,不能借助其他中间软件哦.
我这里屏蔽了所有的IM工具端口,没办法,老板黒啊,上班就得干活,欲哭无泪. 斑竹：
运行到这句 obj_mouse_click(strButtonOne,19,12,LEFT);
弹出没找到cant find "{class: object,MSW_id:"&iButtonOne&",MSW_class:Button}";
是不是这句有错啊？strButtonOne="{class: object,MSW_id:"&iButtonOne&", MSW_class:Button}";
[ Last edited by jeeee on 2005-10-16 at 19:04 ] 斑竹强。尽量少用GUI外部文件的调用，我很赞成~
strButtonOne="{class: object,MSW_id:"&iButtonOne&", MSW_class:Button}";这个我也不懂~。在XP中LEARN的和这个完全不一样啊
[ Last edited by johngan on 2005-10-17 at 12:08 ] 我手里没有xp系统，你把gui map拿出来看一下! 问题已经解决了，class:object改成class:push_button;
还要在GUI CONFIGURATION里面设置到MSW_id到RECORD里面。
另外“static_get_info ("{class: static_text,MSW_id: 403}","label",jResult);”这一句我把static_text改成edit;label改成value,才可以取得计算器算出的结果，我不知道这是不是在XP和在2000中LEARN计算器得到的不同之处？ Originally posted by pcl2004_27 at 2005-10-16 02:13 PM:
首先谢谢你能正确理解我说的话，
我说的调整算法已经不是gui map的维护了，我在前面提到了wr的可维护性的两点。。。。你一直强调我对gui map的维护，呵呵。是否有点。。。强加于人的味道。
有个疑问，你说我 ...
pcl2004_27:
"你一直强调我对gui map的维护....",真的是我一直强调么?好好看看你的帖子,从这个开始:
*********************************
发表于 2005-10-12 05:55 PM
我整个应用是基于winrunner之上的，没有用到gui map！
*********************************
你就在一直强调你自己对脚本中关于GUI的一些看法,我想一般你可能真的需要需要统计一下你的留言中GUI出现的数量了,正是由于你一再强调这个,我才跟贴表达我的看法.
喝醉的人一般不说自己喝醉了,喜欢偏激的人一般也不说自己容易偏激.比如,你到现在也没能证明你如何认为XP中的计算器和2K的计算器是完全两个软件?我不太懂,一个连XP OS都没装的高人,如何断言这个结论?呵呵.我想,还有一些话,都可以仔细推敲一下.我就不一一罗列了.
让我们继续讨论一下那个技术问题:
我们知道,任何测试及其结论都要放在一定的测试条件和环境下才有意义.这也是一开始我说"如果说真的要测试反应速度,WR也是无能为力的."的初衷,也就是说,如果单单用WR测某个软件所谓的反应速度是没有意义的,因为诚如你所言,WR不能自身形成CPU负载,而一般情况下,测试一个软件或者Server的反应速度,CPU负载率是一个必须考虑的条件.
当然,如果借助API或者外挂DLL等来实现这个测试用例的先决条件是可行的,可问题就在于这些外挂并不是属于WR的?对么?我们的分歧也许就在于是否依靠WR本身(你对本身不太理解,我建议你可以把本身理解为WR的纯粹的功能,或者说WR安装完后形成的原始功能,如果,你还不能理解,呵呵,我也没办法解释了)来实现这个测试用例.我想,起码,如果不借助其他外挂,WR本身很难实现这个测试用例,这是我们的共识.
你提及的VB,我想我们还是不要讨论那个被程序员笑谈为"玩具"的东西了.我们还是仅仅针对WR,毕竟这是WR的水库,你建议我自己做个试验,由于我之前说了,我这没有你碰到一个脚本20000行的大型例子,可能确实无法试验你的结论,所以我也说了"可能存在你说的那种超大规模的脚本和超大规模的GUI文件,导致查找时间足以影响整个脚本运行时间,这时,也许你的方法的确会有效一些."
"好像没有设置时间间隔的问题",我不清楚你是否注意到WR的"General Options中有相关CS语句Delay设置时间的选项",我的原本意思是,如果这里设置了一些Delay,它所导致的延时可能会比较明显一些.请再仔细阅读一下以便于理解我的本意"不过我觉得对于WR这种本省就是低速运行的解释型脚本程序,其本身的每一句脚本之间的间隔将是决定一个脚本运行时间长短的主要因素,在此基础上才可能是调用GUI对象文件查找对象花费的时间,而对于一般中等规模的脚本来说,前者的时间可是远远大于后者的,起码我们可以人工调节WR每一句脚本之间运行的间隔."
[ Last edited by fengqiwen on 2005-10-17 at 15:43 ] 呵呵
后边的技术帖没有必要在讨论下去了！
有很多东西好像不再一个层面上，对东西的理解也有问题。
很高兴这次与你讨论。
希望将来还有讨论的机会! 求同存异,那就不讨论了吧. 斑竹，我说一句您不要不高兴哈，您的脚本我读起来很困难。因为象这种function覆盖的脚本，维护成本本来就很高；所以我觉得GUI的方式比较好，要好维护一点。 呵呵,好像看不到pcl2004_27的帖子了,可惜了.
昨天一个福州WR网友聊到这两个脚本速度问题,我想还是实际做个试验比较好.毕竟,实践是检验真理的唯一标准嘛.
一台机器,PIIII 2.8 G, 40G HD, 521M 双系统,XP+SP2, 2K+SP4.
分别运行一下脚本.这里注明一下,为使2个脚本站在一个起跑线上.我对我的脚本修改了一下2处:
1. 改自动调用GUI为人工事先在GUI Editor里打开再运行脚本.
2. 我的原先脚本循环次数为9*9=81次,pcl2004_27的脚本是45次,故修改我的脚本也运行45次.
运行结果,我的脚本5秒,pcl2004_27的7秒,具体见附件.可见,对于这种小型脚本,pcl2004_27推崇的速度优势几乎显示不出来,甚至可能还更慢.
可以稍微分析一下原因,当然,我的猜测也不一定对啊:极有可能是pcl2004_27的脚本多次使用求字符串长度和字符串提取函数,导致速度降低.当然也不能完全排除2个OS速度的差异性.
以上结果,供大家参考.
事不目见耳闻而臆断其有无,可乎? 我在发帖中提到速度的那个问题，是说算法。呵呵
我会仔细看 aswoon911的report。
