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

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

1背景

1.1Web程序中的接口

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.2Web接口的概念

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

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

1.2WEB接口自动化

1.2.1Web接口测试

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 系统的特征适合哪种自动化模式。所以这里特别要关注的就是分层自动化测试：

如上图所述，

web 系统可以做几种功能测试：单元测试，集成测试，系统测试。大多数的产品QA 不会太多介入单元测试，集中在集成测试和系统测试。结合上面提到的迭代排期，其实在一般项目中上层UI 的开发往往比较滞后，赶工的结果也是提测质量不高。所以可推荐的一种模式是迭代周期内按照UI 接口划分功能点做排期，UI 的开发可以放在UI 接口稳定之后提测。所以迭代周期内，面向UI 接口的自动化就是一个将测试前置，并且积累自动化case 以待回归时代替手工操作的大好机会。

就着上面这个结论，再分析一下本节开头抛出的第二个问题：“系统级自动化测试的稳定性与可靠性”，先提出几个观点如下：

1. 有一些测试点，从系统级角度做自动化的性价比不高：

第一：目前技术手段上还不具备低成本的实现手段的，比如flash 、js 实现的一些效果、不规范HTML 标签、对浏览器运行版本环境考虑不周等引发的问题。导致开发成本高，运行的稳定性较低。

第二：UI 实现逻辑比较薄，比如只是查询DB 一个字段然后显示在页面，把重点放在后端逻辑检查上性价比更高

2. 系统级测试和集成测试的关注点不同：系统级测试关注的是用户从UI 直接操作所

能见到的结果，而集成测试关注的是UI 接口数据的准确性。比如报表功能，页面上看到的就是一个表格，而对UI 接口来讲需要覆盖N 种参数组合。