总结：
1）功能基本实现,测试用例得到扩展
2）winrunner,quick test调试功能不够强大，错误提示不正确，robot错误信息提示简单。错误定位不准确。
3）quick test 有不稳定的地方。脚本开发完毕， 需要重新录制操作过程才能运行。可能跟设置有关系。
4) Quick Test 开发环境可以移植到vb开发环境中，vb中引用对象可以直接开发。
5）自动化测试经常多个脚本一起运行，不需要用户每次手工启动。在三种测试工具都可以达到多个脚本一起运行的目的。
例如：WinRunner中
将录制的脚本开发成函数.
1. 改动设置，file->test properties->test type(compiled module)。
2. public function login_ok()
{
加入脚本
}
Robot
1.录制的脚本加入到lib中
一．建立library source “demo”文件，整理测试脚本为函数
Sub Login_Ok()
加入测试脚本
End Sub
保存
二．建立library head “demo”文件
Declare Sub login_ok basiclib “demo”
三．在主脚本中添加头文件 demo
2.直接调用脚本
Callscript “test”
备注：第二种方法一般在所有测试脚本都是针对一个测试工程的时候用，他不能达到脚本共享的目的。
QuickTest
1. 直接在脚本中添加新的action就可以达到连续测试的目的
Treeview中右键添加action copy就可以
稳定性评测：
三种测试工具在整个使用过程winrunner,quicktest测试工具测试环境因素影响比较大，录制和回访过程中出现很多问题。robot受环境影响相对比较小。
综合比较
1. 从易用性，稳定性，扩展性来看WinRunner不太适合web的功能测试，他识别web对象能力比较差，现有脚本函数不能解决web对象元素的识别的问题，需要开发大量的脚本，来支持他对web测试能力，工作量大，对测试人员要求过高。前期投入过大，收益不明显。
2. Robot相对其他工具来说，功能强大比较稳定。但要达到脚本共享需要一定技巧，尽量避免在类文件中的添加验证点（robot自带的），通过其他方式来实现。对没有编程经验的测试人员来说有一定难度。
3. quicktest针对web测试的工具，所以不管脚本的可读性，还是脚本开发的稳定性都是值得赞赏的。但是调试环境相对来说差一点。
4. 通过对比，个人认为quick test和rational robot两种测试工具对于web测试更加适合稳定。但是quicktest只支持vbscript，这样要注意vbscript不支持的语言特性，如声明变量尽量不要带类型，文件的操作尽量用filesystemobject对象。
5. 测试工具完全可以用后两种工具。
以上脚本比较简单，只是提供利用测试工具解决自动化测试的思路，各个脚本可能在其他地方无法运行，根源是环境差异。可以按照评测中的方法和思路自己动手做一遍，具体问题具体分析。由于时间仓促有些问题写的不够细致，大家请多指教。上边脚本省略了验证点，省略了除错处理，省略了添加自定义信息到report中等。但是不影响对比结果，如有问题请和我联系。
