浅谈Web接口测试

我在之前的文章里提到过有些情况不适合跑UI测试的，而适合用接口测试来覆盖，我是传送门。

尺有所短，寸有所长。接口测试是UI自动化测试的一个强有力的补充。

1. 首先接口测试较UI测试效率更高，速度更快
2. 其实接口测试较UI测试稳定性更高

打个比方，请求某API，正常情况下它返回一堆数据。如果走UI测试，可能需要登录>去到相应页面>把相应条件设置好>点击某按钮触发请求>等待页面响应，直至加载完成>然后去DOM Tree里面检索相应元素，把数据提取出来，有可能数据量太大导致分了很多页，提取速度不快，中间页面操作可能还出问题。

这种情况就十分适合走接口测试。Web接口测试（Web API测试）一般都是去Request某个URL（Get或Post），同时传递必须的参数，拿到Response后对它进行解析，将我们感兴趣的部分提取出来，跟预期的结果比对。Web接口测试需要API文档支持，如果缺失，开发GG应予以说明。

各类开发语言里都有HTTP模块，用于构造HTTP请求>Request>Get Response。都是大同小异。常见的HTTP返回值对应的状态如下：
- 200 OK是最常见的，表明请求已被受理，Response已返回
- 300开头的一般指重定向，比较少见
- 400开头一般是Client端错误，比如，请求的URL不对，
- 500开头的一般都是Server端错误，比如Server端这个服务挂了

具体的返回值释义请看我是传送门。

本着数据驱动测试的精神，接口测试的参数以及预期的结果放到文件里比较好，维护起来也明了方便。

在这里推介一个工具：Telerik公司出品的小而美的Fiddler。在它被启动时，它就将自己注册为Windows Internet Service（WinINet）的系统代理，位于HTTP层，Internet Explorer, Chrome, Firefox, Safari, Opera…等等应用在发送请求及接收返回时都是要调用WinINet的。所以，不管用什么浏览器，只要启动了Fiddler，那么它发送的所有请求都会先到Fiddler，经由Fiddler将请求传至服务端，服务端返回的Response也会先到Fiddler，再由Fiddler将Response传给浏览器。

Fiddler功能很强大，开发们可以用它进行Web Debug或者性能分析，测试人员亦可以用它来模拟HTTP请求，并观察返回值。

因为我们项目的UI自动化用的就是Telerik的测试框架，所以，天然无缝地会Fiddler很亲和 ;-)

网上有太多Fiddler的帖子，同学们自己搜吧，Fiddler官方文档在这里我是传送门，英语没问题的自己去看吧。