信息系统开发平台OpenExpressApp:【OpenTest】 之 如何实现自动化测试框架

在OpenExprssApp的Roadmap图中的OpenTool中明确列出了测试，自动化测试框架是OpenTest的一个主要组成部分，在前面blog中我也介绍了OpenTest自动化测试框架的一些内容，本篇我介绍一下为什么现在在OEA中实现自动化测试框架，以及我是如何思考的。

两周内搭建自动化测试工具

　　我现在所在项目组开发的产品都属于新产品系列，一开始连测试人员都没有，业务人员充当测试人员，做的也只能是一些操作性的点击验证，这在项目前期还没有表现出明显的问题。到产品成型，需要交付用户上线使用时，这时问题就会很快的暴露出来了，由于一个系统并不只是一个计算器那么简单，有很多地方都需要测试，而没有专人专岗进行这项测试工作室很难保证质量的。后期，我们组进入了两名测试人员，质量也有所提高，但是每次发版他们都要进行大量的回归测试，由于时间压力、对业务和系统的把握上总会遗留一些需要回归的地方，即使他们考虑周全，这种重复性的手工测试方法也不是我所希望的工作方式，IT人工作要的就是高效能，所以我给自己的要求就是两周内支持OEA中的OpenTest自动化测试。　　

自动化测试框架的总体要求

　　在实现自动化测试框架之前，我并不是急于考虑使用什么语言，如何设计等，我考虑的是我的测试框架应用时应该是什么样子的

1. 面向测试人员，甚至需求人员，脚本简单易学易懂
2. 测试脚本易维护
   
3. 可以与需求、开发工作同步，不需要等待开发结束后才开始编写脚本
4. 框架可以由有编码经验的测试人员维护扩充

方案选择

　　根据上面自动化测试框架的总体要求，我没有使用VS2010自带的录制自动化测试功能，而是在OEA中加入自己的自动化测试支持：

1. 不做通用自动化测试框架，专为OpenExpressApp编写自动化脚本，减少复杂性
2. 编写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】的使用

框架使用方法介绍

1. 修改inc.rb中的$ExePath = "d:/GZJ/OpenExpressApp/OpenExpressApp.Host.WPF/bin/Debug"为你的程序路径
2. 在框架的TestCase目录下编写测试用例文件：XXX.rb，文件大致结构如下
   
   view source print ?

   01	$用例名称 = "这个测试用例的中文名称"  #出现错误后，邮件中会使用这个名称来报错

   02

   03	#以下两个require是必须的

   04	require "inc.rb"

   05	require "TestCase/run_app.rb"

   06

   07	#以下为用例步骤描述区域，相当于以前写的测试用例步骤

   08

   #用例步骤描述:

   09	# 1 新增部门， 编码：Test  名称：自动化测试

   10	# 2 选择前两行和【一审人员】

   11	# 3 选中一审人员，设置部门管理的功能权限，取消部门管理下的全部展开和全部折叠功能

   12	# 4 选择数据权限页签，添加PBS业务对象，设置可读表达式为 1=1

   13

   # 5 保存

   14	# 6 删除当前新增记录

   15

   16

   #以下为具体脚本

   17	打开模块 "部门管理"

   18

   19	# 1 新增部门， 编码：Test  名称：自动化测试

   20

   添加

   21	属性编辑器("编码").输入("Test")

   22	属性编辑器("名称").输入("自动化测试")

   23

   ....

3. 在框架main.rb中增加测试用例的启动命令
   
   view source print ?

   01	require "inc.rb"

   02	require "mail.rb"

   03

   04	运行测试用例文件 "demo/project.rb"

   05	运行测试用例文件 "demo/org_manage.rb"

   06	#运行测试用例文件 "demo/contract.rb"

   07

   08

   发送邮件

   09

   10	# TestApplication.instance.app.close

   11	Playback.Cleanup()

4. 在框架main.rb中增加邮件接收人地址
   
   view source print ?

   1

   #增加收件人列表

   2	$收件人 << "zhoujg@grandsoft.com.cn"

5. 执行rub.bat运行自动化测试脚本

todo

1. 增加检查点支持，例如行号、值，以及异常二级窗口弹出检测等
2. 增加调度服务器，支持多个客户端分布执行测试用例
3. 增加在OpenExpressApp应用中的录制功能，自动生成自动化测试脚本
4. OpenMetaEdit完成后，增加图形化自动化编写工具

回顾

1. 框架设计不能一开始陷入细节，必须先确定方向，对主要方面进行思考后才动手
2. 执行时大致想好计划，哪些当前做，哪些后期做
3. 时刻站在使用者角度去考虑如何简化开发方法

 本文转自 jingen_zhou 51CTO博客，原文链接：http://blog.51cto.com/zhoujg/518550，如需转载请自行联系原作者