SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 9483|回复: 2

[推荐] 基于RFT开发 Web 应用自动化测试框架

[复制链接]
发表于 2011-6-9 23:34:48 | 显示全部楼层 |阅读模式
本帖最后由 技术狂人 于 2011-6-9 23:38 编辑 % h. h+ {3 f- n- q3 J* U# A; f

! V' }$ K- J- y* d# m$ z; M背景知识
  [1 q3 G3 n. q4 E5 ZIBM Rational Functional Tester(简称 RFT)是一款先进的、自动化的功能和回归测试工具,它适用于测试人员和 GUI 开发人员。使用它,测试新手可以简化复杂的测试任务,很快上手;测试专家能够通过选择工业标准化的脚本语言,实现各种高级定制功能。通过 IBM 的最新专利技术,例如基于 Wizard 的智能数据驱动的软件测试技术、提高测试脚本重用的 ScriptAssurance 技术等等,大大提高了脚本的易用性和可维护能力。同时,它第一次为 Java 和 Web 测试人员,提供了和开发人员同样的操作平台(Eclipse),并通过提供与 IBM Rational 整个测试生命周期软件的完美集成,真正实现了一个平台统一整个软件开发团队的能力。
) o- x' c5 H9 d, y$ Y" R+ H' x  h3 S0 _4 h6 M
RFT 提供的自动化测试方式一般分为两种,一是采用录制器录制生成测试脚本,二是由 QA 人员编写测试脚本。由于录制生成脚本的方式存在一些弊端,比如脚本复用性不高,不易维护,脚本可移植性不高等等,我们选择了第二种方式作为了自动化测试框架的脚本生成方式。本文实现的测试框架能够从数据文件中读取测试数据,然后传入自动化脚本,不同的数据文件对应不同的测试用例。这种模式实现了数据和脚本分离。提高了脚本的利用率,并使脚本的可维护性大大提高。本文实现的框架另一个特点是脚本编写人员无需掌握编程语言,只需要用 xml 文件来编写一个个基础的测试单元,再通过通过统一的 xml 文件来组织这些小的测试单元,从而形成真正的测试用例,这种方式可以灵活组织测试用例,测试单元可以得到很大程度的复用,编写效率很高。
, A+ \2 }) U7 ?9 e2 Q# O  k# C" l
8 k' U& e) S: k通过以往的尝试,发现真正实现自动化测试,并不是掌握了某个自动化测试工具,掌握了脚本的编写技术就能够达成,面对复杂的 ERP 系统,简单的录制 / 回放并不能达到自动化测试的要求,虽然花费巨大代价但起到的效果甚微。
8 e+ j& l* ~9 Y' J! W. j基于以上因素并结合行业发展思路,在正式实施自动化之前,必须搭建一套适合的自动化测试框架,将脚本能够有效的组织、连贯应用起来,提高测试脚本的可维护性和可读性。 " Y5 {( Z0 Y) @4 i' E3 j4 q
* \7 n9 c* B% X! n1 ?( v! y
在进行自动化框架的开发工作时,我们需要从以下几点进行考虑:( [- c! t* N$ \. Y& \' f
  • 高复用性
  • 高可维护性
  • 稳定性
  • 快速编写脚本
  • 自动执行
  • 正确输出结果
  • 能够不断提升自动化测试比例( K% B" J: d2 a- d' G
本文实现的自动化测试框架,也正是基于以上方面的考虑,分析设计的。1 p/ L' S5 R) {1 @. a
示例背景1 _- T! L6 t% j9 d9 N
DM (Decision Management) 是一个基于 Web 开发的决策管理产品,DM 自动化框架是以 DM 产品为测试目标开发的一套自动化测试框架,当然它同时适用于大多数的 Web 产品的测试。
7 l0 c( X; E8 O1 x如图所示:DM 产品是一个标准的富客户端应用,以 GWT 来编写 Ajax 前端。需要进行自动化测试的部分主要是 view 层用户和应用的交互,前端在调用服务器端服务后,返回数据的效验以及异步调用后数据的效验等等。
  N- x; d( M: Z7 N% ?; j* g2 M3 C8 O
图 1. DM Web 端架构设计- M! ]: }0 ?  R2 _) r. P5 {/ |. w$ m
4 }5 E7 u* U9 `( A! z$ h
- E6 l8 T1 u! l3 Q5 ?


5 |8 p: U" h9 `+ _) \/ h5 }
5 D2 t. D/ ]* v$ N3 t; t
2 c0 F7 O7 j$ f3 ^$ M自动化测试框架的设计原理
+ X7 b+ N7 Y' T/ F0 }! z8 r5 v+ sITCL 框架是 IBM 公司内部被广泛使用的自动化设计框架,也叫做 IBM 框架。主要的设计宗旨就是将代码划分成三层结构,即对象层(AppObjects layer)、任务层(Task layer)、测试用例层(TestCases layer)。将代码划分成三层结构使得“做什么“和”如何做“分离开来,有利于代码的组织,结构清晰。同时提高了代码的可复用性和扩展性。当使用 ITCL 框架开发自动化测试脚本时,其核心的任务就是合理的设计和组织对象层和任务层。
: {8 m" x! }0 V" a/ |9 s在自动化测试框架中合理的设计对象层和任务层常常会使整个自动化项目的开发和后期维护达到事半功倍的效果,DM 测试框架的分层结构在基于 ITCL 框架的基础上进行了一系列的改变,简化了对象层,将 object 层与 task 合并为 task 层,每一个 task 由一个 xml 文件来定义,task 是由多个 step 标签组成的,每一个 step 可以看成是以往的 object。同时增加了 Utile 工具包,主要存放通用的方法,例如:测试单元中使用的所有的标签类、xml 解析类、文件读取类、日志类、效验类等等。对于这些基础的类是框架最为固定的部分,因为无论将自动化框架在哪一个 Web 应用中使用,这部分内容都是可以完全重用并可以持续扩展的。9 \8 F2 ~8 a0 X' M7 Q. {3 a
$ s% N( S, h4 e- o$ P# Z
图 2. 自动测试框架示意' d" f  S3 g" ?8 U
# b5 |/ z$ y- y- W4 u

0 Y, O* J# O2 Y( B) ]( b/ F对于 Web 应用来说,主要是靠浏览器来解释页面中的 html 元素来运行程序。对于每一个 Web 页面来说都是由不同的 html 标签组成的,虽然页面元素是多种多样的,不同的应用所使用的控件也不尽相同,但是对于一个应用来说,使用的控件是相对固定的。而用户对于页面上的操作无非只有一下几种事件:1 鼠标点击,2 键盘操作,3 等待。对于自动化测试来说只要能够按顺序表示出某个页面中对于指定控件的一组操作(例如:输入,输入,点击,等待…)就可以实现对于这个页面的业务逻辑操作。
7 w8 o6 n* ^# i我们将用户在 Web 应用中的操作都定义相对应的标签,比如输入定义为 <input>、点击事件定义为 <click>、等待定义为 <sleep> 等等。<find> 标签则是用来找到指定的控件,find 标签有三个属性 findType、property、value,只要在 xml 文件中将这三个值设置上,xml 解析器就可以通过获取 xml 中指定的值,调用 RFT 的查找方法来实现控件的查找,<find> 标签和用户的操作组合起来使用。具体的标签的实现方式则是封装了 RFT 提供的方法来完成的。同时我们定义了效验标签 <Validate>,当用户操作到某一步骤时候需要加一个验证点时可以直接使用 validate 标签,在该处插入验证点即可。将操作定义为标签可以极大的降低测试人员开发脚本的难度,更容易复用,和灵活的调用。同时,我们可以自己在增加一些自定义的标签,在一个应用中非常公用的组件可以定义成一个通用标签,从而减少整个测试脚本代码量,减少错误。
' M9 P# F7 P& a+ k7 w( J. V<Click> 标签的实现写法如下:- @; Z; C2 W, B9 c
public class ClickTagParser extends TagParser {public ClickTagParser(Element rootTagElement) {super(rootTagElement);}@Overridepublic void takeAction(TestObject component) {  if (component != null) {    try {         ((GuiTestObject) component).click();    } catch (Exception e) {    e.printStackTrace();  }}}}

' t3 \% u. q7 q$ g8 D& m例如一个点击动作在 xml 文件中的的写法是9 g+ E1 o* {9 m5 _. z
<click><find findType="Html.TABLE" property="class" value="x-btn-wrap x-btn" /></click>

" P" G+ U4 ~6 ]  q  I9 i$ p5 p/ f/ q
0 l- ~, J" B2 H5 g
9 B( k- b, O  d$ M: ^, ?2 s& h- ]

7 B  l. j$ ]7 n实例4 X) p* u5 F9 B6 y1 e+ u7 x$ _
一个登陆的业务操作由两次输入(输入用户名,输入密码)和一次点击动作(点击登陆按钮)完成那么测试人员仅仅需要编写如下的 xml 内容即可,而这一个功能就可以当作一个测试单元,我们为它命名为“LogingSucess”,并可以在最终的测试用例脚本中去调用,由多个小的测试单元最终会组合成一个完整的测试用例。
$ u( ?# L3 ]% g7 r0 Z. G
<step index="LoginSucess"><input value="admin"><find findType="Html.INPUT.text" property="type" value="text" /></input><input value="spss"><find findType="Html.INPUT.password" property="type" value="password" /></input><click><find findType="Html.TABLE" property="class" value="x-btn-wrap x- btn" /></click></step>
+ S/ |2 l0 {! N2 D2 G

6 F; M7 a+ d/ C, q, U0 @图 3. 一个登陆的业务操作+ q9 Z3 E+ R3 l) m

( ?2 }% j2 ?, o- A6 C* b
3 D8 _0 {* ?: h) d使用自动化测试框架后,测试人员不必关心框架的实现细节,只需要根据业务逻辑组织 xml 文件。然后再将写好的 xml 文件通过统一调用的方式在一个总的 xml 文件中里进行灵活组装和调用,从而组成一个完整的测试用例。3 `) j% O) b  q. b) {
通过配置 xml 来定义出一个真实的测试用例,如下为总的测试入口 xml 的部分配置信息:& {$ _7 r& j$ t0 K* S
<Root><testcase value="CMBVT" ><testscript scriptName="commontasks.LoginPage" step="LoginSucess" /><testscript scriptName="commontasks.LaunchPage" step="CreateCM" /><testscript scriptName="commontasks.HomePage" step="NavToData" /><testscript scriptName="commontasks.DataStep"…</testcase></Root>
& K3 {' [7 n0 }& M: V: F
. s6 L& N7 u, {" K2 O, X
图 4. DM Automation 框架示意图
( B; {, X  f5 g' n1 T* y! ^& ?& r8 W' w/ o

5 |1 M9 s. X1 c如同所示,框架首先通过 RFT 启动脚本调用 Test Suite 这个 xml 文件(Test Suite 由测试工程师来组织需要运行的 TestCases)然后通过 XML 解析器逐层来解析 TestCases 里有哪些 Task,并找到这些 Task 对应 xml 文件,然后继续去解析 Task 中的标签,而标签的相应动作则定义在标签库中,通过 RFT 提供的方法,而最终完成整个自动化测试的过程。整个过程中每一个步骤都是可以通过 XML 文件灵活的装配,从而使测试工程师的精力都集中在如何去组织,调用 Task 而成为实际的测试用例。  G+ g% v9 P: U: @' h# @
DM 自动化测试框架的输入分为两部分,一部分来自外部数据文件,是以 property 文件来存放数据。另一部分输入则是直接在实际的测试用例中传入指定的参数,小的测试单元根据名字接收这些参数来实现数据输入。
( G7 |# @% [- Z) g& \& F效验和最终的日志对于自动化测试来说是非常重要的部分,在 DM 自动化测试框架中,将这两部分功能进行了重新的开发。日志分为两个部分,一是总体的测试结果,二是具体每一个测试单元的详细信息,同时具有错误用例,正确用例的过滤功能。测试不会因为一个页面错误,比如控件不存在而中断。测试的过程会跳转到下一个测试用例,继续进行。0 w6 r+ `6 t7 m1 \
* r$ j" I* x% V( ^! `; f9 v
图 5. 日志示意 19 ~$ K% Z+ ]( d* M, s+ F8 `
: I  z) X% ^" L
所有运行结果通过时候,日志的抓图。9 ]/ i, I6 y0 S8 I
1 c6 A) R+ N9 |5 z  x( O; W
图 6. 日志示意 2" [0 f; ]9 d) ]! E
/ Q3 }1 ]8 U0 U0 H( X0 u
图中红色表示运行状态失败的效验点,框架会自动为效验结果失败的用例抓取错误时的图像。5 T) w' T/ _$ x
* E/ n& e+ F' ?6 y3 f8 a- N
图 7. 日志示意 3
" B  x8 G) r4 i* \3 q+ M9 A" T- G% L/ m; X8 t
发布:通过批处理命令,设置 RFT 启动的计划。这样自动化测试可以随时运行。一般较长的测试用例,可以安排在周末进行运行。在周一工作日时直接查看测试用例日志。
5 n6 d- n4 S( Q' K# `

  w" |3 v+ O! w. I8 j% b3 c9 Q4 ~; R. o. t3 B6 ^* q4 ~

( N9 [! u, Y$ ^% F: y总结
/ M: H& }3 K; j* i9 }- x优点* W& R4 p# b; l8 f" z$ {
  • 简化测试人员脚本开发难度,测试人员仅需要根据页面的操作逻辑顺序编写 xml 文件,不需要掌握 java 等开发语言
  • 复用方便,一些公用的组件可以写成统一的标签,在 xml 里直接调用
  • 脚本是解释性的,因此框架 DLL 不需要重新编译。
  • 脚本由于成为配置,那么其管理也就变得更加容易和简单。
  • 可以让测试人员,完全只是关心业务上的脚本。
  • 配置中,可以方便地记录每一步的执行内容。原先的编译方式,失去了很多信息。
  • 配置可以动态组织,这样有可能实现部分脚本的执行。
    6 c) ?9 t* }, y% d% w: C
缺点3 x0 @3 ]) v2 v6 @* A# K- ]
本框架对于基于 C/S 架构的应用仍需要进行一定程度的修改。
8 A9 ^8 k3 l" O, {' j& }有一个良好的框架,再开始自动化测试,这样可以确保较低的维护成本。DM 自动化测试框架是对 RFT 的一种实践方式,目前还有很多方面需要改进,例如在线日志,支持多种 C/S 应用等,不过通过实践检验对于测试人员的自动化测试工作起得到了有效地帮助,是一次成功的尝试,自动化测试框架还将根据项目的变化生成后续版本不断的完善提高。
# G- b, h' D7 b; H1 Y! Q2 m

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
 楼主| 发表于 2011-6-9 23:36:53 | 显示全部楼层
回复 支持 反对

使用道具 举报

发表于 2013-7-5 16:24:12 | 显示全部楼层
谢谢共享
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|小黑屋|手机版|无图版|SCMLife.com ( 京ICP备06056490号-1 )

GMT+8, 2018-1-20 11:54 , Processed in 0.068419 second(s), 6 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

快速回复 返回顶部 返回列表