基于WEB UI接口轻量级测试框架及实施方案

发表于:2012-11-05来源:百度质量部作者:不详点击数: 标签:自动化测试框架
1 背景介绍 1.1 接口 web ui接口是服务器与客户端交互的方式,即浏览器或者其他客户端工具与web服务UI层交互的协议.常见的有两大类,一是浏览器与服务器交互的 HTTP,HTTPS协议的接口,另一类web service接口如soap,rmi,rpc等协议。这些接口

  1 背景介绍

  1.1 接口

  web ui接口是服务器与客户端交互的方式,即浏览器或者其他客户端工具与web服务UI层交互的协议.常见的有两大类,一是浏览器与服务器交互的 HTTP,HTTPS协议的接口,另一类web service接口如soap,rmi,rpc等协议。这些接口的共通特征都是作为Server对外的UI提供通信服务。

  1.2 接口测试

  web ui接口测试即站在web服务程序UI层之上自动化测试的一种手段,是站在用户的角度上测试web服务程序业务逻辑的正确性。测试的重点是围绕web服务 暴露的接口检查接口数据的正确性,这个过程是将web服务程序当做黑盒,通过自动化测试技术提高测试执行效率降低人工回归的成本。

  1.3 可测性分析

  1.3.1 为什么做接口测试

  在业务模块的分层测试中,各种测试方式的比重如下图所示,实践中我们从系统级测试发现的bug数目最多,所以系统级测试占比比较大;除此之外,由于现在敏 捷的尝试以及普遍开展的项目迭代,面向模块提前介入测试的方式也越来越频繁,而此时并不具备系统级可测性,因此模块的接口就成为测试自动化的最好入口。

  在业务系统常用测试方案中,有以下说明:

  (1. 单测在不同的团队和模块有不同的作法,如果QA太多的介入,则对QA coding能力要求较高,case的传承性也受到挑战

  (2. 业务模块接口测试主要关注接口请求参数与返回数据的正确性,以参数覆盖为测试等价类

  (3. 系统级case对web业务模块来说都是基于浏览器用户行为的,目前有selenium自动化,大部分是手工测试。

  从分层测试的特征,业务系统的结构出发,我们认为,接口测试的必要性包括:

  (1. 迭代开发模式中,接口测试可先于系统级测试提前进行,属于测试前置

  (2. 相比于基于浏览器客户端的系统级测试,接口测试更专注接口数据正确性,稳定性与可靠性的性价比高

  1.3.2 接口可测性

  接口在业务模块中的类型为典型的HTTP接口(Ajax,Dwr,Action…),也有Java类型的一些接口(RPC,RMI,SOAP),在可测性上具有一些共通特征:

  (1. 可自动化率高:接口总能通过相应的client来发送请求

  (2. 脱离RD代码依赖,只针对接口:属于黑盒测试范畴,难度较白盒

  (3. 执行速度介于系统级与单测之间:对于业务模块来讲,脱离浏览器后的接口测试稳定性与效率都是大幅提升

  (4. 容易实现数据分离与数据驱动,容易抽取公共的框架性内容,降低case编写维护人员对coding的依赖

  2 轻量级测试框架itest

  itest是interface test接口测试框架的简称:支持基于网络通信的WEB UI接口自动化测试,支持HTTP,SOAP,RPC等几种常见协议,支持多种验证结果的模式,支持数据分离,最主要的特征还是通过数据文件驱动测试执行,不需要编码实现测试用例

  2.1 架构设计

  itest功能组成与基本处理流程如下图,以主要协议HTTP为例:

  基本设计思想:

  1. itest框架支持case文件与执行的分离,case并非coding模式,而是通过各类文件描述case信息(请求文件,数据准备清理文件,验证结果文件…),itest解析case信息后转化为接口请求

  2. 登录是针对uc,uuap等测试环境下,模拟请求并获得sessionid,HTTP请求的case需要带着sessionid

  3. 参数化:itest作为执行框架,执行接口的部分逻辑比较薄,是基于数据驱动的方式,把case数据转为Junit4的参数化数组,循环执行

  4. setup与teardown:以不同文件后缀代表不同的行为,itest内部可扩展实现对不同后缀名文件的操作逻辑,如后缀为.sql,则当做sql语句直接执行

  5. 验证:也是以文件后缀名做有区别的验证,如后缀.response是直接判断expected.equals(actual)? 而后缀是.csv的则拼装为sql后查询db是否结果匹配

  基础结构:

  Junit4+HTTPunit+Ant

  2.2 数据驱动

  为降低自动化过程中case编写人员的编程成本,采用的模式是itest作为核心的执行与验证框架,傻瓜式的执行外部case目录内的各类文件,每一个 case都不需要coding。如下图所示:case的存在形式为文件目录,1个case是1个目录,itest顺序读取case,以相同流程执行每一个 case。

  2.3 结果验证

  结果验证按照业务系统的特征,现在支持以下几种:对接口返回的内容直接做对比验证;对数据库update后的内容做验证;将接口返回的json做处理后做验证。

  2.4 测试数据

  对业务系统自动化测试来说,业务测试数据非常关键,因为它需要符合一定的业务规则;如何构造数据有几个争议的地方:

  1. 数据(包括DB,server文件,桩文件)一次性构造好放那不动,无法保证数据不被污染,且移植性受限;

  2. 如果能做整个环境的备份还原则不怕污染,但是case与case之间可能会互相干扰数据

  3. 自动化case是否严格要求数据的隔离,如果要求,则每个case都自己负责生命周期内的数据准备和清理;如果不要求,则需要case设计时刻意避免数据的使用混乱

  不同业务系统在设计上各有千秋,哪一种数据准备的方案都是有不同的代价,结合笔者所处产品线的特征,认为自动化case自己负责生命周期内的数据准备与清理,是综合效果比较好的模式:1个独立的case,能有自己生命周期内的数据准备和清理,则最大程度上保证了case运行的稳定性和可靠性,避免case之间互相因为数据发生干扰!

原文转自:http://www.ltesting.net