Web自动化测试中的接口测试.docx

Web自动化测试中的接口测试

背景

Web程序中的接口

典型的Web设计架构

web是实现了基于网络通信的浏览器客户端与远程服务器进行交互的应用，通常包括两部分：web服务器和web客户端。web客户端的应用有html，JavaScript，ajax，flash等；服务器端的应用非常丰富，比如java的servlet，jsp，ssh框架，.net的aspx，还包括其他脚本如php，python。

web服务器端的设计架构近年来一直比较流行的是三层架构(3-tierapplication)，通常意义上的三层架构就将业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层

（DAL）。分层的目的在于降低代码见耦合，提高代码架构的可维护性。总的来说，这三层架构的意义如下：

表现层（UI）：用户界面，即用户可见的操作界面或者入口。

业务逻辑层（BLL）：封装具有业务含义的操作函数。

数据访问层（DAL）：封装对数据库或者其他存储介质的原子性操作。

Web接口的概念

web接口是服务器与客户端交互的方式，即浏览器或者其他客户端工具与web服务UI层交互的协议.常见的有两大类，一是浏览器与服务器交互的HTTP协议的接口，另一类webservice接口如soap，rmi，rpc等协议。

HTTP接口请求方法常用的有GET、POST两种请求类型。具有无连接无状态的特征。HTTP请求例如GET/images/logo.gifHTTP/1.1，表示从/images目录下请求logo.gif这个文件。

WEB接口自动化

Web接口测试

web接口测试即站在web服务程序UI层之上自动化测试的一种手段，是站在用户的角度上测试web服务程序业务逻辑的正确性。测试的重点是围绕web服务暴露的接口检查接口

需求分析详细设计

需求分析

详细设计

编码实现

测试

分什么要做接口测试

下图说明了基于HTTP接口的web应用的整体架构特征，按照这种架构设计开发项目，引发两个问题：

第一、系统级测试一定要等到web服务器程序和浏览器端的程序都开发完毕后才能进行吗？参考以下传统的RD与QA合作进行的项目流程，可以看到，QA在RD提测程序后才能真正进入到测试阶段，那么项目的发布周期自然受到这种串行下来的工作安排影响，是1+1的时间周期。

第二、为了提高效率，公司的团队引入了系统级自动化测试的工具或方案，既然是从用户角度去测试，当然要寄希望于从模拟用户行为代替手工操作来进行测试。比如从浏览器操作的方式去测试，能很直接的覆盖用户的一手操作，但是需要思考的是，浏览器各个版本如ie6，7，8，chrome，firefox等，各自有各自特性，JavaScript在浏览器内表现效果又不尽相同，浏览器在不同windows环境下、不同网络条件下运行的状况又不一样，给QA带来一个难题：如何保证浏览器上的自动化case稳定、高效执行？

我们先分析第一个问题，项目团队需要提高产品发布效率，提前QA测试介入的时间点，我们可以想到有几种方案：

QA跟随RD进度，加入到各个层级代码参与单元测试：

假设我们没有引入TDD模式没有引入敏捷，那么常规的解决方式是一批被测函数代码由RD写完之后提交svn，然后QAupdate代码后先花十几分钟阅读代码再加上对业务需求的理解然后再花费十几分钟写Xunitcase，与QA预期结果一致则好，不一致则需要再花时间与RD沟通原因等等。其一QA花费更多时间，要深入到RD的代码逻辑深处；其二对QAcoding能力要求也很高，这取决于公司QA人员的定位，是要求QA更熟悉测试设计而代码能力次之呢，还是QA的整体技术能力都要很高，一般来讲大多数的QA强项在于业务需求的熟悉和测试设计能力，所以这种方式对团队整体人员素质的要求非常高。

QA不参与单测，RD依据需求纵向拆分功能点然后迭代提测，QA能提前一定时间介入测试：

对照如下的流程示意图说明这个过程，实际上是传统瀑布模型做了拆分，变为了多个短期的“小瀑布模型”，这样的效果能使得项目周期长的产品，可提前介入测试以提前发现问题。

需求分

需求分

析

详细设

计

迭代1编

程实现

迭代1测

试

迭代2

迭代2开发

迭代2测试

在这样的迭代流程中，如何合理利用自动化手段来提高测试效率呢？一般来讲迭代周期不会很长，常规性的为3~5天一个周期，做太复杂的自动化投入成本较高。对于web系统来讲，为避免过多的自动化投入得不偿失，需要谨慎的判断web系统的特征适合哪种自动化模式。所以这里特别要关注的就是分层自动化测试：

系统测试：以系统为整体进行黑盒测试，手