在OpenExprssApp的Roadmap图中的OpenTool中明确列出了测试,自动化测试框架是OpenTest的一个主要组成部分,在前面blog中我也介绍了OpenTest自动化测试框架的一些内容,本篇我介绍一下为什么现在在OEA中实现自动化测试框架,以及我是如何思考的。
两周内搭建自动化测试工具
我现在所在项目组开发的产品都属于新产品系列,一开始连测试人员都没有,业务人员充当测试人员,做的也只能是一些操作性的点击验证,这在项目前期还没有表现出明显的问题。到产品成型,需要交付用户上线使用时,这时问题就会很快的暴露出来了,由于一个系统并不只是一个计算器那么简单,有很多地方都需要测试,而没有专人专岗进行这项测试工作室很难保证质量的。后期,我们组进入了两名测试人员,质量也有所提高,但是每次发版他们都要进行大量的回归测试,由于时间压力、对业务和系统的把握上总会遗留一些需要回归的地方,即使他们考虑周全,这种重复性的手工测试方法也不是我所希望的工作方式,IT人工作要的就是高效能,所以我给自己的要求就是两周内支持OEA中的OpenTest自动化测试。
自动化测试框架的总体要求
在实现自动化测试框架之前,我并不是急于考虑使用什么语言,如何设计等,我考虑的是我的测试框架应用时应该是什么样子的
- 面向测试人员,甚至需求人员,脚本简单易学易懂
- 测试脚本易维护
- 可以与需求、开发工作同步,不需要等待开发结束后才开始编写脚本
- 框架可以由有编码经验的测试人员维护扩充
方案选择
根据上面自动化测试框架的总体要求,我没有使用VS2010自带的录制自动化测试功能,而是在OEA中加入自己的自动化测试支持:
- 不做通用自动化测试框架,专为OpenExpressApp编写自动化脚本,减少复杂性
- 编写DSL自动化测试框架,让语法变得更简单,也增加可维护性
采用技术方案选择
由于我只给了自己两周时间完成自动化测试框架,所以只能实现一个初步可以执行的框架,完成的也是核心的部分,以下对过程中的一些技术方案进行简要说明一下
- 自动化测试支持框架:CodeUI、TestApi
一开始我是准备使用TestApi来做支持的,但是使用后发现并不是很好,随着VS2010的发布,我看到了CodedUI功能,所以想到了使用它的类库作为支持,对于CodedUI的了解可以查看我之前的blog
使用VS2010的CodedUI来做自己的自动化测试框架
OpenTest:CodedUI如何支持下拉树形列表选择?
测试:VS2010的Coded UI Test参考内容列表
- 开发语言:IronRuby、IronPython、C#
一开始我是使用C#来验证CodeUI类库的自动化支持功能的,并不是想实用C#来作为开发,因为我希望UITest测试框架由测试人员维护,所以不希望他们必须安装庞大的Visual Stuio,所以考虑使用脚本语言,因为他们轻巧。在脚本语言,由于需要和.Net集成,所以自然考虑了IronRuby和IronPython。对于Ruby和Python,我都懂点皮毛而已,之所以选择IronRuby,是因为公司有人对Ruby熟悉,而现在公司的自动化测试框架也是使用Ruby的,所以最后选择了IronRuby。对于选择IronRuby是经过几天的技术验证的,大家可以通过以前的blog对IronRuby进行一些了解
IronRuby – 如何在VS2010下调试IronRuby代码
IronRuby – 怎么就没有好用的IDE呢??
IronRuby – 文件编码惹的祸
IronRuby – 使用NetBeans编写IronRuby代码
IronRuby - 快速在半小时学习Ruby基础知识
IronRuby – 编写自动化测试脚本
IronRuby:请教如何在DOS窗口正确显示UTF-8字符后执行bat文件呢?
IronRuby:元编程特性【method_missing】的使用
框架使用方法介绍
- 修改inc.rb中的$ExePath = “d:/GZJ/OpenExpressApp/OpenExpressApp.Host.WPF/bin/Debug”为你的程序路径
- 在框架的TestCase目录下编写测试用例文件:XXX.rb,文件大致结构如下
1234567891011121314151617181920212223
$用例名称 =
"这个测试用例的中文名称"
#出现错误后,邮件中会使用这个名称来报错
#以下两个require是必须的
require
"inc.rb"
require
"TestCase/run_app.rb"
#以下为用例步骤描述区域,相当于以前写的测试用例步骤
#用例步骤描述:
# 1 新增部门, 编码:Test 名称:自动化测试
# 2 选择前两行和【一审人员】
# 3 选中一审人员,设置部门管理的功能权限,取消部门管理下的全部展开和全部折叠功能
# 4 选择数据权限页签,添加PBS业务对象,设置可读表达式为 1=1
# 5 保存
# 6 删除当前新增记录
#以下为具体脚本
打开模块
"部门管理"
# 1 新增部门, 编码:Test 名称:自动化测试
添加
属性编辑器(
"编码"
).输入(
"Test"
)
属性编辑器(
"名称"
).输入(
"自动化测试"
)
....
- 在框架main.rb中增加测试用例的启动命令
1234567891011
require
"inc.rb"
require
"mail.rb"
运行测试用例文件
"demo/project.rb"
运行测试用例文件
"demo/org_manage.rb"
#运行测试用例文件 "demo/contract.rb"
发送邮件
# TestApplication.instance.app.close
Playback.Cleanup()
- 在框架main.rb中增加邮件接收人地址
12
#增加收件人列表
$收件人 <<
"zhoujg@grandsoft.com.cn"
- 执行rub.bat运行自动化测试脚本
todo
- 增加检查点支持,例如行号、值,以及异常二级窗口弹出检测等
- 增加调度服务器,支持多个客户端分布执行测试用例
- 增加在OpenExpressApp应用中的录制功能,自动生成自动化测试脚本
- OpenMetaEdit完成后,增加图形化自动化编写工具
回顾
- 框架设计不能一开始陷入细节,必须先确定方向,对主要方面进行思考后才动手
- 执行时大致想好计划,哪些当前做,哪些后期做
- 时刻站在使用者角度去考虑如何简化开发方法
开发新产品时,通常是没有测试人员,只有业务人员充当测试人员。产品成型时,就会暴露许多问题,没有专人专岗进行这项测试,很难保证质量的。当需要进行大量的回归测试时,由于时间压力、对业务和系统的把握上总会遗留一些需要回归的地方。IT人工作要的就是高效能。
自动化测试框架的总体要求:1、面向测试人员,需求人员,脚本简单易学易懂2、测试脚本易维护3、与需求、开发工作同步4、框架可由编码经验的测试人员维护扩充
框架设计不能陷入细节,先确定方向,进行思考后才动手;执行时想好计划;时刻站在使用者角度去考虑如何简化开发。
你也是做自动化测试吗?