有关WR的学习，版主一定要进来看一看
关于WINRUNNER的学习接触了一段时间WINRUNNER后，大家都知道使用这个测试工具的基本流程：先是让WR学习GUI MAP—>录制脚本—>回放脚本，回放前还可以做，插入检查点、插入同步点、建立数据池，问题是，在实际实施起来时，都不知从何下手，我个人认为，主要是存在以下几个问题，可能也是大家还没有弄明白的：
1、当一个系统比较大时，是否是分模块来学习GUI？
2、录制脚本时，是否是要录制一个本系统的正常业务流程的脚本，还要录制一个非正常的业务流程（作用是检查系统是否对一些非法操作做了一些相应的控制）
3、一个好的WR测试脚本的怎样的？我的看法是：
a检查系统的业务流程、模块接口是否有误；
b检查各个界面的输入框，对一些非法的、特殊的字符的输入是否做了控制。 Originally posted by mojinde at 2004-12-14 08:58 AM:
关于WINRUNNER的学习
接触了一段时间WINRUNNER后，大家都知道使用这个测试工具的基本流程：先是让WR学习GUI MAP—>录制脚本—>回放脚本，回放前还可以做，插入检查点、插入同步点、建立数据池，问题是，在 ...
为什么没有人回复呢，请大家进行讨论，我认为这些问题都很迷茫啊，小生在此谢谢啦！ 1.我觉得WinRunner的脚本开发过程是根据他的软件自身的特定决定的！
对于脚本开发过程：WR学习GUI MAP—>录制脚本—>回放脚本
我觉得不大适合当前实际开发，实际开发过程中我觉得这个过程才是核心部分：
录制脚本-增强脚本-回放脚本-分析结果
学习GUI,我觉得应该放在录制脚本之后，这样不会因为修改脚本后（业务流程改变）你仍然要先学习GUI,这样可以通过设置GUI MAP类型进行自动修改！而且灵活性更大，你的专注点可以放在脚本开发上！
WinRunner中有两种GUI MAP类型，这两种类型一种是全局的，一种是针对每一个脚本自动生成的GUI MAP。
我觉得后一种更加好，因为全局类型的GUI MAP需要每次你脚本运行前用代码加载，从WinRunner来说我觉得他影响效率，而且不容易维护！即使选择全局类型也应该分开保存GUIMAP,通过脚本加载指定的GUI Map。这样模块更加容易维护！ 2、第二个问题我觉得自动化脚本开发是一个特殊的开发过程,他受到软件业务逻辑制约,软件GUI元素（其实是后台的开发语言起作用）等因素制约。
而软件测试是为了验证软件功能，还应该有软件测试技术在里边。
测试软件是代替软件测试工程师的工作，把手工劳动变为自动化让测试工程师投入到其他工作中去，软件测试工程师的基本任务之一是测试用例的编写，测试用例的分那些？设计用例的方法包含边界值，因果法，等价类划分等无非是对业务，GUI元素测试，自动化的目的我们知道了，那么开发脚本其实我们就是测试两种用例，一种是正确的用例（执行肯定正确，正确输入，预期的结果），一种是错误的用例（其实也是正确的，错误的输入，预期的输出）
那么自动化脚本主要是处理这两种，但是由于软件功能还没有完善，你需要处理的是脚本中的两种错
一种是错误
一种是异常
错误是预期的，也就是上边错误的用例的内容（其实也是正确的用例），一种是异常，没有办法预料到是什么结果，这就需要你在脚本中加必要的错误处理，来处理这种异常结果！
你的说的第二点说法上我觉得有偏差，有些时候没必要开发两套脚本，脚本开发过程录制脚本，后开发脚本中，开发脚本过程中就有可能把两种用例结合，用一个脚本就可以处理的。 3.自动化测试我觉得是代替人的手工劳动，它只能检查到已经发现的错误是否修改，功能是否完善（因为只有在软件稳定的情况下引入自动化才是最理想的）
只要做到上边的自动化测试就达到了效果，而且自动化化受到很多因素的制约，不可能完全达到自动化。过分的预期只能导致自动化的失败！ 非常感谢版主的回复！
这样说来，WR只能做回归测试了？ 测试工具不是只有一种！软件自动化测试不单单说的wr等功能自动化测试工具，还有很多不同的测试阶段可以使用不同的测试工具！ 再次感谢版主，我会努力的。更希望所有的中国测试人员一起进步！ 1、当一个系统比较大时，是否是分模块来学习GUI？
这个不需要,因为WR会自己加入GUI中,
如果认不到的控件,你自己可以加入到起动脚本中或者做虚拟控件!
2、录制脚本时，是否是要录制一个本系统的正常业务流程的脚本，还要录制一个非正常的业务流程（作用是检查系统是否对一些非法操作做了一些相应的控制）
本人觉得没有必要,你可以这样一般系统会分很多个模块,
你可以一个模块分好多种录制方式,
工具是死的,人是活的,想怎么录,要因系统而实施,
所以你不能说录一种正常,
一种非正常!
因为WR能做的不只这个,它还可以程序化,
就是编写复杂的测试脚本,以带出隐藏在应用程序中的信息,
在D:\Program Files\Mercury Interactive\WinRunner\lib下面有很多TSL脚本,
你可以调用里面的程序!
这个就可以实现很我的功能了! WR的测试流程:
1.识别应用程序的GUI对象.
2.建立测试脚本
3.对测试脚本进行排错(debug)
4.在新的版本中执行测试
5.检查测试结果
6.回报缺陷(defect)
3、一个好的WR测试脚本的怎样的？我的看法是：
a检查系统的业务流程、模块接口是否有误；
b检查各个界面的输入框，对一些非法的、特殊的字符的输入是否做了控制。
这两点本人同意
其它的以上版主都说得差不多了
其它本人觉得WR不是个人的工具,
他是一个团队工具!从经理到测试员需要很多人才能实行,
所以对于个人的工具,我们能做出什么来呢? 非常感谢，QA_BAY 版主的回复，现在我觉得思路清晰多了，目的也比较明确了，但应该还要多多动手去做才行 这两天一直在琢磨两位版主的回复内容，小生还有一点不明白，pcl2004_27版主所说的应该专注到脚本开发上，但是脚本开发都包括一些什么呢？ 调用FUNCTION吧!
在LIB下面有很多!都是自带的! 说的太好了！受益匪浅！！ QA_BAY说WR可以检查各个界面的输入框，对一些非法的、特殊的字符的输入是否做了控制。
请问如何实现这一测试？谢谢！！ WR你说简单就简单说复杂就复杂,
简单就是录制回放,
复杂就是加TSL语言!
对于一个输入方框你首先要看上下的条件是怎么样的,
例如有一个方框是有限制的,
如果用户名超出20个字符就出错,而你的系统没有做到你就可以这样加上去!Name="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
Name1="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
#在输入框里输入
set_window("输入姓名的窗口");
obj_type("姓名输入框",Name);
#应该弹出提示输入不合法的提示窗口
if(length(name)>20)
{
report_msg("你的输入已经超出20个字符");
#关闭提示窗口
win_close("提示");
}
else
report_msg("长度合法");
写完一个IF条件框架之后,你就可以慢慢的觉得要加什么就加进去!
WR自带的就是那些检查点还有FUNCTION之类的东西.
你要把它们用起来,
还有一个比较有用的就TSL的调用这方面的要了解LIB下面的FUNCTION!
对于字符就没有分得特别清楚,
这方面没有怎么深入! 请问版主：还有的就是，有这样的三种情况：
1、当输入的字符长度超出规定的长度，系统也没有报错；如需求规定只能输入20个字符，但输入大于20个字符，系统也没有出现报错提示。
2、系统已控制只能输入所规定的字符长度；就输入20个字符就不能再输入了。
3、还有一种情况是：所输入的内容是唯一性的，如，用户编号、单据编号等
这三种情况，又怎能样处理呢？
[ Last edited by mojinde on 2004-12-31 at 10:56 ] 对于一二个问题,你用手工不是更快的测试出来吗?
如果你真的用WR判断那你用LENGTH就可以解决一二点的问题!
如果长度超出让WR显示出来,这样即使系统没有提示也可以显示出来!
对于第三点:你可以让WR跑两次(就是循环),如果没有出错那就代表不唯一性. 1、一二个问题，手工测试并不快，因为对于某些系统来说，输入框是很多的。
2、如果真的强调快的话，自动化测试并不比手工测试快，因为在完善测试脚本的时候，是一个很漫长的过程。
3、再有就是我好象听版主说过，很少能用测试工具找出BUG。
基于以上几点，我认为，用自动化测试工具来做测试，意义并不大。 Originally posted by mojinde at 2005-1-4 08:41 AM:
1、一二个问题，手工测试并不快，因为对于某些系统来说，输入框是很多的。
2、如果真的强调快的话，自动化测试并不比手工测试快，因为在完善测试脚本的时候，是一个很漫长的过程。
3、再有就是我好象听版主说过 ...
可能我说得不够清楚,对于第一点我所说的是一个输入框,如果是很多的话,那当然用测试工具会比较好一点!
对于第二点,没有找到BUG的工具并不代表他不会找到或者意义不大.我不这么认为,
当你的工作量很大而又很多还有人手不够的时候,那工具就派上用场了!
如果工具找到的BUG跟人一样多,那老板还用请你吗?工具是辅助,主要测试还是我们!
对于工具重要还是看用工具的那个人,而不是工具本身.
个人意见!
[ Last edited by QA_BAY on 2005-1-4 at 10:56 ]
