总结:
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中等。但是不影响对比结果,如有问题请和我联系。
本文地址:http://com.8s8s.com/it/it37091.htm