|
前段时间公司需要实施WinRunner来进行回归测试,包括制定一套方案和一套标准脚本,通过实施起来真的是学到了很多东西,还是赶快总结出来,久了可能又忘记了。
先说我和我们老大共同制定的一套方案(也是结合网上很多资料制订的),欢迎大家看了后给点意见,不要像上2篇那样,看的人比较多,但留言的一个都没,伤心啊,可能是我水平问题,相信以后会越来越好的。
PS:由于论坛传图片比较麻烦,所以自动化测试方案放在附件中下载,下面只是实施WinRunner的一些简单总结。
自动化测试总结:
通过进行自动化测试操作,在其中学习到了很多脚本设计上,技巧上的方法,现总结如下:
1, 首先编写测试脚本前,考虑产品可以分为那几个模块,模块中分为那个步骤,测试模块中的那些点,最好是先写一个简单的列表,这样在编写脚本时就比较清晰整体的架构和逻辑。例:在做XXXX前就是因为没有对整体预先进行设计,导致后面很多地方进行修改,如在设计测试报告输出方面就没考虑到以那种形式进行输出,开始是对整个报告输出到一个HTML文件中,后面改成先有一整模块的报告来显示那些用例通过,那些失败,然后通过点击通过的或者失败的就可以查看用例测试的详细信息。
2, 对于每一个输入条件都要进行判断,判断是否正确,不正确就把不正确的信息写入测试报告中,然后根据需要是否退出整个测试。如加载GUI_PATH路径就要进行判断,判断不存在就输出错误信息并退出测试。
3, 所有关于路径方面的变量都应该是相对路径,不能是绝对路径,不管是输出还是输入。如函数库路径LIB,应该这样写(比如static lib_path = getvar("testname") & "\\..\\..\\..\\share\\lib";),就是通过getvar("testname")获取到当前脚本的路径,然后在后加上LIB所在文件夹路径,其他的变量也是一样,最好不要用绝对路径(如:c:\abd\aaa\lib),绝对路径对后期维护很差,而且当脚本转移到其他电脑上,放的路径和以前不相同,则测试脚本将跑不成功。
4, 脚本中尽量在最前面进行变量定义,然后在脚本中进行调用变量,这样维护脚本就只需要修改变量中定义的值,而不需要去脚本中到处修改。
5, 变量名字定义尽量通俗易懂,看到就大概知道定义的什么
6, 脚本定义格式:
1, 测试模块名称
2, 创建日期
3, 创建版本
4, 修改记录
5, 创建人
6, 被测程序用的语言
7, 测试目的
8, 参数
9, 返回值
7, 注释:定义的变量,测试的步骤都必须进行注释说明
8, 函数定义:函数尽量定义成多用,只接受外面传来的参数,在函数中不要进行过多操作。
9, 函数格式:
1, 函数名称
2,函数目的
3,函数参数
4,函数返回值
10,脚本中加载函数后,在测试结束必须用UNLOAD释放
11,GUI整理:
1,可以对某GUI的Logical Name进行修改,修改为易懂的名称
2,对GUI的Physical Description进行模糊匹配(一般把MSW_class: *这个去掉)
3,对GUI进行通配符,如
{
class: window,
label: "[已连接]127.0.0.1"
}
可以修改为
{
class: window,
label: "!\\[已连接\\].*"
}
PS:[ ] 是WR中进行通配符中的,所有当要对带有[ ]进行通配符的话,如上面。其他的符号也是一样
4,每个模块的GUI生成一个GUI文件
12, 进行脚本调试时多用PAUSE进行调试
PS:
上传了一个脚步,来简单介绍我文档中写的内容,希望对大家有帮助,欢迎大家讨论,请大家多多指教
网页查看报告在那个flight\TestReport\login目录下,我只是简单写了点,大家也可以根据这个进行修改。
[ 本帖最后由 hjjlearning 于 2008-1-6 22:56 编辑 ] |
|