html 接口测试页面,关于前端接口测试的探索和挖坑

开始

最近几年，前端测试渐渐被人重视，相关的框架和方法已经比较成熟。

断言库有should, expect, chai。 单元测试框架有mocha, jasmine, Qunit。 模拟浏览器测试环境有Phantomjs, Slimerjs。 集成测试任务管理工具有karma。此外，还有一堆诸如Selenium、nightwatch(冰火出戏)等各色思路不同的关注UI测试的工具。

本文主要关注的是接口测试。

接口是前后端协作的桥梁，是系统得以顺利运行的关键。所谓接口测试，就是检查系统提供的接口是否符合事先撰写的接口文档。数据结构是否完备，数据类型和取值是否符合标准。

实际上，接口测试由后端来做会比较方便，但是由于一些实际原因(后端大哥比较忙，人手不足等)，后端往往不能确保接口数据一定符合接口文档规定。此时，作为前端，我们为什么不能另辟蹊径，探索一番呢？

思路分析

接口测试最大的难点是什么？我觉得是登录状态的获取。

众所周知，一个系统的大部分接口都只会对登录用户开放。在测试接口之前，首先必须确保这次会话已经登录，发送给后台的请求中必须携带登录后获取的 cookie。面对这个问题，最直接的想法是在后台模拟登录。

后台模拟登录

mocha 可以运行在node中，理论上我们完全可以在node环境下，使用一些http client( request, superagent等)，模拟进行登录。手动获取cookie，并加在之后的每一次接口请求中。获得到接口数据后，就可以结合 mocha，愉快地进行测试了。

可是，实际实验之后，我发现这个方案存在一些缺陷。

难以封装复用

不同系统的登录流程并不相同。相当多的系统要求在登录时需要附带其他的 cookie 或者额外的表单参数。

以本人测试的系统为例，登录时就需要带上一个 key 为 jsessionid 的 cookie，以及一个 key 为 nlt 的表单参数。这个 cookie 是怎么来的呢？是访问登录页时返回的 set-cookie 头设置的。这个表单参数又是怎么来的呢？是藏在登录页面的表单中的一个隐藏域。

所以，如果简单地用 http client 向登录地址发一个 post 请求，仅仅带上自己的用户名密码，你就会发现，登录毫无疑问的···失败了。

更烦人的是，如果你的系统登录依赖 SSO，内部存在 302 请求转发，那么很有可能会出现 cookie 丢失的情况(有两个 set-cookie header，浏览器能识别并正确设置，但是很多 http client 只能拿到最后一个)。

我们当然可以动用各种奇技淫巧，手动获取和设置各种特定的 cookie，去网页里爬出隐藏域的值。可是，这一切，仅仅对特定的系统有效。如果换一套系统，你就必须重新研究一遍登录流程，重新写一遍模拟登陆代码，感觉还是挺崩溃的。

难以应对验证码

上面的问题仅仅只是使用不便，这个问题就是直接就给该方案判了死刑。当然，爬虫界也有不少应对验证码的解决方案，比如依托 OCR 软件啊，人工判别 API 啦, 更厉害的还有自己做图像处理和算法进行识别。可是，作为一个简单的接口测试，这种方案是不是太小题大做了点？

浏览器扩展

mocha 也可以在浏览器环境运行，当后台模拟登陆遇到困难，我们很容易想到，在浏览器环境进行测试是否可行呢？

普通的浏览器环境确实会有一定问题，那就是前端的老大难：跨域。

我们的目的是前端接口测试，原则上不应也不能让后台搭配测试工作去改接口，所以，CORS，jsonp 都是不可行的。

难道这条路又堵死了？非也，我们还有一个选项，那就是——浏览器扩展。

以 chrome extension 为例，只要在 manifest.json 文件中配置好 permissions ,扩展发起的请求就可以成功跨域。事实证明，完全没有问题。不仅可以跨域，还可以携带登录后的 cookie，所以，只要在浏览器正常登录后，再打开插件相关页面进行验证，就可以解决登录状态的问题。简直完美。

方案设计

既然定下了方案，下一步就是设计。作为接口测试的解(wa)决(keng)方(zhi)案(lv)，我们必须具备通用性与易用性。使用者只需提供配置，不需要再进入源代码修改打包。

本方案中中测试框架和断言使用 mocha + chai。这方面的资料汗牛充栋，本篇不再赘言。

目录结构

apiTest

│ package.json

│ webpack.conf.js

│ api.conf.dist.js

│ api.conf.dist.js.map

│ index.js

│ manifest.json

│ test.png

├─config

│ index.js

├─css

├─html

├─js

├─lib

└─TestCreator

其中，index.js 是入口文件; manifest.json 是 chrome 插件配置文件; config/index.js 是用户测试配置文件。css, html, js, lib 都用于存放资源文件。

使用流程

安装插件(如果已安装过就可以省略)

提供测试配置

用户去系统登录页完成登录

点击插件图标，打开新 tab 页

在 tab 页中进行测试，并在页面上显示结果

让我们从 manifest.json 文件开始，一步一步深入，看目标流程是如何实现的。

- manifest.json

"permissions": [

"tabs",

"http://*/*",

"https://*/*"

],

"background": {

"scripts": "js/background.js"

}

在 manifest.json 文件中，定义 background 属性。定义的 js/background.js 文件将自动在后台运行。permissions 属性定义了扩展的权限。“tabs”指明可以打开浏览器本身的 tab 标签页，后面两个配置指明浏览器可以向任何 url 发送请求。(不配置会跨域)

- js/background.js

chrome.browserAction.onClicked.addListener(function(){

var url = chrome.extension.getURL("../html/main.html");

window.open(url, "main_page");

})

在 js/background.js 文件中，注册了一个事件函数。当用户点击插件图标时，打开一个 html/main.html 作为新的 tab 页。我们所有的任务都将在这个 tab 页中实现。

- html/main.html

请在登陆后点击按钮开始测试

在这个 html 中，载入了三个 js 文件。其中，config/index.js 是测试配置文件。api.conf.dist.js 是入口文件经 webpack 打包后的压缩文件。mocha 之所以独立载入，是因为在浏览器环境中，mocha 必须部署在 window 对象下，所以不能打包进去。核心的逻辑代码，放在 api.conf.dist.js 文件中。

页面中放置了一个按钮和一个 id 为 mocha 的 div。前者点击后会触发 mocha 执行，后者作为一个容器，用于显示测试结果。

- index.js

import {expect} from 'chai'

import test from './js/main'

function click(e) {

mocha.run()

document.querySelector("#startBtn").style.display = 'none';

}

document.addEventListener('DOMContentLoaded', function () {

var btn = document.querySelector("#startBtn")

btn.addEventListener('click', click);

});

mocha && mocha.setup('bdd')

mocha.timeout(4000)

const mainTest = testCreator(window.apiTestConf)

mainTest()

index.js 是打包的入口文件。这里主要做了两件事：

第一，为按钮定义了一个事件监听函数，点击时执行 mocha。

第二，初始化 mocha，设置其执行模式(bdd)和超时时间。

第三，执行 mainTest 函数，在这里定义了所有测试用例。测试用例根据用户配置文件动态，这也是核心逻辑。下面将进一步详述。

测试配置的设计

下面展示本文使用的测试配置：

window.apiTestConf = {

name:"foo",

path:"http://baz/japi/platform/",

common:{

success: {

value: true,

type:["boolean"],

},

errorCode: {

value: [0]

}

},

publicStruc:[

"results>items",

"results"

],

apis:{

AccountCenter:{

"110620001":{

name:"获收货地址列表",

fullUrl:false,

data:{

length:{

min:1

},

item:{

area:{

type:"string"

},

areaStr:"string",

consignee:"string",

detail:"string",

id:"number",

ifDefault:"boolean",

mobile:["string","number"]

}

}

}

}

}

}

测试配置决定了测试用例的组织和测试用例内断言的编写。其结构学习了一些表单验证插件，比表单验证插件复杂的地方在于，表单验证仅仅针对一维的单一字段，而接口返回的数据则是具备一定的嵌套结构的。下面对该配置进行简述。

path：接口地址的公共部分。

common：对接口返回数据的格式上的公共部分进行验证。比如 success 必须为 true，errorcode 必须为 0 等。

publicStruc：接口核心数据部分的路径。系统将根据该路径一步步寻找。如果没找到将会在断言中报错。如果定义了多个路径，则会按顺序从前往后查找。

apis：核心部分，对接口数据进行验证。

AccountCenter：该 key 可变。在这一层级对接口进行分组，比如 AccountCenter 说明下面定义的是账户中心的接口的测试配置。

110620001：该 key 可变。这是真实接口的路径。该 key 值下的对象，就是针对具体数据结构和字段进行配置了。下面将介绍这部分的配置和验证规则，可能会有点枯燥，不感兴趣的读者可以略过不看。

字段验证规则

字段验证规则：

字段验证规则指的是接口下data属性下定义的规则。是对接口核心数据的存在与否、数据类型和值所做的规定

基本规则规则

规则仅仅对类型是数字，字符串，布尔值和数组的字段有效，如果要验证的字段是对象，则不起作用。需要对对象内的属性(同样看做字段)做进一步的验证，而不是对对象本身做验证。

验证属性可写的值是对象，数组和字符串，其他类型的值都是非法的

验证属性如果是一个空对象，则直接通过。

验证属性如果是一个数组或字符串，则视为 type 处理

验证属性如果是一个至少包含了required, value, type三者之一的对象，则进行标准化验证

required

验证真实字段必须指定，且必须不为空字符串(也就是说false,0能通过验证。)

value

如果 value 是数组，则验证真实值是否至少等于数组中的某一个值

如果 value 是数字，字符串或者布尔值，验证真实值与其是否相等

如果 value 是一个对象，则进一步判断：

min:规定最小值，仅仅对数字有效

max:规定最大值，仅仅对数字有效

not:不为其值。可以是一个数组，此时不为数组中的所有值

start:开始字符，仅仅对字符串有效

end:结束字符串，仅仅对字符串有效

type

type 可写的值是字符串。这些字符串的可选值为:"number","string","boolean","array"。没有"object","undefined","null"，因为没有意义

type 可以是一个数组，数组中的值也是上面的可选值。此时，只要满足数组中的一个值，就能通过验证

length

当数据是数组时才有效，是对数组长度做的验证

min:规定最小值，仅仅对数字有效

max:规定最大值，仅仅对数字有效

item

当数据是数组时才有效，里面进一步规定对数组中每一项的验证

设计完各种规则后，接下来就是依样画葫芦地编写代码了。由于代码量比较多，这里就不再赘述。其核心思想就是根据配置项生成各种测试用例和断言。最后供 mocha 运行，输出结果。

结束和展望

本文所设计的方案基本能够满足前端接口测试的要求，但还是有一些缺陷，弊端，及有待改进的地方。

验证规则涉及不够全面和严密，有待丰富，

可以将总体目录结构以及内部的 TestCreater 封装成 npm 包，更方便使用。

测试通过时，无法看到通过了哪些断言。测试失败时，只输出未通过的第一条断言的信息。输出信息不够全面丰富。这一定程度上是 mocha 和 chai本身的特性，不知道有什么方式可以优化。

最后，本文中若出现了错误，或是读者有更好的方案，望不吝啬赐教。