Web自动化测试中的接口测试
1、背景
1.1 Web程序中的接口
1.1.1 典型的Web设计架构
web是实现了基于网络通信的浏览器客户端与远程服务器进行交互的应用,通常包括
两部分:web服务器和web客户端。web客户端的应用有html,JavaScript,ajax,
flash等;服务器端的应用非常丰富,比如java的servlet,jsp,ssh框架,.net的aspx,
还包括其他脚本如php,python。
web服务器端的设计架构近年来一直比较流行的是三层架构(3-tier application),
通常意义上的三层架构就将业务应用划分为:表现层(UI)、业务逻辑层(BLL)、
数据访问层(DAL)。分层的目的在于降低代码见耦合,提高代码架构的可维护性。
总的来说,这三层架构的意义如下:
1)表现层(UI):用户界面,即用户可见的操作界面或者入口。
2)业务逻辑层(BLL):封装具有业务含义的操作函数。
3)数据访问层(DAL):封装对数据库或者其他存储介质的原子性操作。
1.1.2 Web接口的概念
web接口是服务器与客户端交互的方式,即浏览器或者其他客户端工具与we
b服务UI层交互的协议.常见的有两大类,一是浏览器与服务器交互的HTTP协议的
接口,另一类web?service接口如soap,rmi,rpc等协议。
HTTP接口请求方法常用的有GET、POST两种请求类型。具有无连接无状态的特征。
HTTP请求例如GET?/images/logo.gif?HTTP/1.1,表示从/images目录下请求
logo.gif这个文件。
1.2 WEB接口自动化
1.2.1 Web接口测试
web接口测试即站在web服务程序UI层之上的自动化测试一种手段,是站在用户的
角度上测试web服务程序业务逻辑的正确性。测试的重点是围绕web服务暴露的接
口检查接口数据的正确性,这个过程是将web服务程序当做黑盒,通过自动化测试
技术提高测试执行效率降低人工回归的成本。
1.2.2 什么要做接口测试
下图说明了基于HTTP接口的web应用的整体架构特征,按照这种架构设计开
发项目,引发两个问题:
第一、系统级测试一定要等到web服务器程序和浏览器端的程序都开发完毕后
才能进行吗?参考以下传统的RD与QA合作进行的项目流程,可以看到,QA在RD
提测程序后才能真正进入到测试阶段,那么项目的发布周期自然受到这种串行下来
的工作安排影响,是1+1的时间周期。
第二、为了提高效率,公司的团队引入了系统级自动化测试的工具或方案,既然
是从用户角度去测试,当然要寄希望于从模拟用户行为代替手工操作来进行测试。
比如从浏览器操作的方式去测试,能很直接的覆盖用户的一手操作,但是需要思
考的是,浏览器各个版本如ie6,7,8,chrome,firefox等,各自有各自特性,
JavaScript在浏览器内表现效果又不尽相同,浏览器在不同windows环境下、不
同网络条件下运行的状况又不一样,给QA带来一个难题:如何保证浏览器上的自
动化case稳定、高效执行?
我们先分析第一个问题,项目团队需要提高产品发布效率,提前QA测试介入
的时间点,我们可以想到有几种方案:
1)QA跟随RD进度,加入到各个层级代码参与单元测试:
假设我们没有引入TDD模式没有引入敏捷,那么常规的解决方式是一批被测
函数代码由RD写完之后提交svn,然后QA update代码后先花十几分钟阅读代码
再加上对业务需求的理解然后再花费十几分钟写Xunit case,与QA预期结果一
致则好,不一致则需要再花时间与RD沟通原因等等。其一QA花费更多时间,要深
入到RD的代码逻辑深处;其二对 QA?coding能力要求也很高,这取决于公司QA人
员的定位,是要求QA更熟悉测试设计而代码能力次之呢,还是QA的整体技术能力
都要很高,一般来讲大多数的QA强项在于业务需求的熟悉和测试设计能力,所以这
种方式对团队整体人员素质的要求非常高。
2)QA不参与单测,RD依据需求纵向拆分功能点然后迭代提测,QA能提前一定时
间介入测试:
对照如下的流程示意图说明这个过程,实际上是传统瀑布模型做了拆分,变为
了多个短期的“小瀑布模型”,这样的效果能使得项目周期长的产品,可提前介入测
试以提前发现问题。
在这样的迭代流程中,如何合理利用自动化手段来提高测试效率呢?一般来讲迭
代周期不会很长,常规性的为3~5天一个周期,做太复杂的自动化投入成本较 高。对
于web系统来讲,为避免过多的自动化投入得不偿失,需要谨慎的判断web系统的特征
适合哪种自动化模式。所以这里特别要关注的就是分层自动化测 试:
欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) | Powered by Discuz! X3.2 |