摘要：本文主要關(guān)注的是接口測(cè)試。所謂接口測(cè)試，就是檢查系統(tǒng)提供的接口是否符合事先撰寫的接口文檔。作為接口測(cè)試的解決方案，我們必須具備通用性與易用性。

最近幾年，前端測(cè)試漸漸被人重視，相關(guān)的框架和方法已經(jīng)比較成熟。
斷言庫有should, expect, chai。 單元測(cè)試框架有mocha, jasmine, Qunit。 模擬瀏覽器測(cè)試環(huán)境有Phantomjs, Slimerjs。 集成測(cè)試任務(wù)管理工具有karma。此外，還有一堆諸如Selenium、nightwatch（冰火出戲）等各色思路不同的關(guān)注UI測(cè)試的工具。
本文主要關(guān)注的是接口測(cè)試。
接口是前后端協(xié)作的橋梁，是系統(tǒng)得以順利運(yùn)行的關(guān)鍵。所謂接口測(cè)試，就是檢查系統(tǒng)提供的接口是否符合事先撰寫的接口文檔。數(shù)據(jù)結(jié)構(gòu)是否完備，數(shù)據(jù)類型和取值是否符合標(biāo)準(zhǔn)。
實(shí)際上，接口測(cè)試由后端來做會(huì)比較方便，但是由于一些實(shí)際原因（后端大哥比較忙，人手不足等），后端往往不能確保接口數(shù)據(jù)一定符合接口文檔規(guī)定。此時(shí)，作為前端，我們?yōu)槭裁床荒芰肀脔鑿?，探索一番呢?/p> 思路分析

接口測(cè)試最大的難點(diǎn)是什么？我覺得是登錄狀態(tài)的獲取。
眾所周知，一個(gè)系統(tǒng)的大部分接口都只會(huì)對(duì)登錄用戶開放。在測(cè)試接口之前，首先必須確保這次會(huì)話已經(jīng)登錄，發(fā)送給后臺(tái)的請(qǐng)求中必須攜帶登錄后獲取的 cookie。面對(duì)這個(gè)問題，最直接的想法是在后臺(tái)模擬登錄。

mocha 可以運(yùn)行在node中，理論上我們完全可以在node環(huán)境下，使用一些http client( request, superagent等)，模擬進(jìn)行登錄。手動(dòng)獲取cookie，并加在之后的每一次接口請(qǐng)求中。獲得到接口數(shù)據(jù)后，就可以結(jié)合 mocha，愉快地進(jìn)行測(cè)試了。
可是，實(shí)際實(shí)驗(yàn)之后，我發(fā)現(xiàn)這個(gè)方案存在一些缺陷。

難以封裝復(fù)用
不同系統(tǒng)的登錄流程并不相同。相當(dāng)多的系統(tǒng)要求在登錄時(shí)需要附帶其他的 cookie 或者額外的表單參數(shù)。
以本人測(cè)試的系統(tǒng)為例，登錄時(shí)就需要帶上一個(gè) key 為 jsessionid 的 cookie，以及一個(gè) key 為 nlt 的表單參數(shù)。這個(gè) cookie 是怎么來的呢？是訪問登錄頁時(shí)返回的 set-cookie 頭設(shè)置的。這個(gè)表單參數(shù)又是怎么來的呢？是藏在登錄頁面的表單中的一個(gè)隱藏域。
所以，如果簡(jiǎn)單地用 http client 向登錄地址發(fā)一個(gè) post 請(qǐng)求，僅僅帶上自己的用戶名密碼，你就會(huì)發(fā)現(xiàn)，登錄毫無疑問的···失敗了。
更煩人的是，如果你的系統(tǒng)登錄依賴 SSO，內(nèi)部存在 302 請(qǐng)求轉(zhuǎn)發(fā)，那么很有可能會(huì)出現(xiàn) cookie 丟失的情況（有兩個(gè) set-cookie header，瀏覽器能識(shí)別并正確設(shè)置，但是很多 http client 只能拿到最后一個(gè)）。
我們當(dāng)然可以動(dòng)用各種奇技淫巧，手動(dòng)獲取和設(shè)置各種特定的 cookie，去網(wǎng)頁里爬出隱藏域的值?？墒?，這一切，僅僅對(duì)特定的系統(tǒng)有效。如果換一套系統(tǒng)，你就必須重新研究一遍登錄流程，重新寫一遍模擬登陸代碼，感覺還是挺崩潰的。

難以應(yīng)對(duì)驗(yàn)證碼
上面的問題僅僅只是使用不便，這個(gè)問題就是直接就給該方案判了死刑。當(dāng)然，爬蟲界也有不少應(yīng)對(duì)驗(yàn)證碼的解決方案，比如依托 OCR 軟件啊，人工判別 API 啦, 更厲害的還有自己做圖像處理和算法進(jìn)行識(shí)別?？墒牵鳛橐粋€(gè)簡(jiǎn)單的接口測(cè)試，這種方案是不是太小題大做了點(diǎn)？

mocha 也可以在瀏覽器環(huán)境運(yùn)行，當(dāng)后臺(tái)模擬登陸遇到困難，我們很容易想到，在瀏覽器環(huán)境進(jìn)行測(cè)試是否可行呢？
普通的瀏覽器環(huán)境確實(shí)會(huì)有一定問題，那就是前端的老大難：跨域。
我們的目的是前端接口測(cè)試，原則上不應(yīng)也不能讓后臺(tái)搭配測(cè)試工作去改接口，所以，CORS，jsonp 都是不可行的。
難道這條路又堵死了？非也，我們還有一個(gè)選項(xiàng)，那就是——瀏覽器擴(kuò)展。
以 chrome extension 為例，只要在 manifest.json 文件中配置好 permissions ,擴(kuò)展發(fā)起的請(qǐng)求就可以成功跨域。事實(shí)證明，完全沒有問題。不僅可以跨域，還可以攜帶登錄后的 cookie，所以，只要在瀏覽器正常登錄后，再打開插件相關(guān)頁面進(jìn)行驗(yàn)證，就可以解決登錄狀態(tài)的問題。簡(jiǎn)直完美。

既然定下了方案，下一步就是設(shè)計(jì)。作為接口測(cè)試的解（wa）決（keng）方（zhi）案（lv），我們必須具備通用性與易用性。使用者只需提供配置，不需要再進(jìn)入源代碼修改打包。
本方案中中測(cè)試框架和斷言使用 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 是用戶測(cè)試配置文件。css, html, js, lib 都用于存放資源文件。

安裝插件（如果已安裝過就可以省略）

提供測(cè)試配置

用戶去系統(tǒng)登錄頁完成登錄

點(diǎn)擊插件圖標(biāo)，打開新 tab 頁

在 tab 頁中進(jìn)行測(cè)試，并在頁面上顯示結(jié)果

讓我們從 manifest.json 文件開始，一步一步深入，看目標(biāo)流程是如何實(shí)現(xiàn)的。

- manifest.json

"permissions": [
    "tabs",
    "http://*/*",
    "https://*/*"
],
"background": {
   "scripts": "js/background.js"
}

在 manifest.json 文件中，定義 background 屬性。定義的 js/background.js 文件將自動(dòng)在后臺(tái)運(yùn)行。permissions 屬性定義了擴(kuò)展的權(quán)限?！皌abs”指明可以打開瀏覽器本身的 tab 標(biāo)簽頁，后面兩個(gè)配置指明瀏覽器可以向任何 url 發(fā)送請(qǐng)求。（不配置會(huì)跨域）

- js/background.js

chrome.browserAction.onClicked.addListener(function(){
  var url = chrome.extension.getURL("../html/main.html");
  window.open(url, "main_page");
})

在 js/background.js 文件中，注冊(cè)了一個(gè)事件函數(shù)。當(dāng)用戶點(diǎn)擊插件圖標(biāo)時(shí)，打開一個(gè) html/main.html 作為新的 tab 頁。我們所有的任務(wù)都將在這個(gè) tab 頁中實(shí)現(xiàn)。

- html/main.html

  
  
  
  
  
  


  

    請(qǐng)?jiān)诘顷懞簏c(diǎn)擊按鈕開始測(cè)試
  
  

在這個(gè) html 中，載入了三個(gè) js 文件。其中，config/index.js 是測(cè)試配置文件。api.conf.dist.js 是入口文件經(jīng) webpack 打包后的壓縮文件。mocha 之所以獨(dú)立載入，是因?yàn)樵跒g覽器環(huán)境中，mocha 必須部署在 window 對(duì)象下，所以不能打包進(jìn)去。核心的邏輯代碼，放在 api.conf.dist.js 文件中。
頁面中放置了一個(gè)按鈕和一個(gè) id 為 mocha 的 div。前者點(diǎn)擊后會(huì)觸發(fā) mocha 執(zhí)行，后者作為一個(gè)容器，用于顯示測(cè)試結(jié)果。

- 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 是打包的入口文件。這里主要做了兩件事：
第一，為按鈕定義了一個(gè)事件監(jiān)聽函數(shù)，點(diǎn)擊時(shí)執(zhí)行 mocha。
第二，初始化 mocha，設(shè)置其執(zhí)行模式(bdd)和超時(shí)時(shí)間。
第三，執(zhí)行 mainTest 函數(shù)，在這里定義了所有測(cè)試用例。測(cè)試用例根據(jù)用戶配置文件動(dòng)態(tài)，這也是核心邏輯。下面將進(jìn)一步詳述。

下面展示本文使用的測(cè)試配置：

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"]
          }
        }
      }
    }
  }
}

測(cè)試配置決定了測(cè)試用例的組織和測(cè)試用例內(nèi)斷言的編寫。其結(jié)構(gòu)學(xué)習(xí)了一些表單驗(yàn)證插件，比表單驗(yàn)證插件復(fù)雜的地方在于，表單驗(yàn)證僅僅針對(duì)一維的單一字段，而接口返回的數(shù)據(jù)則是具備一定的嵌套結(jié)構(gòu)的。下面對(duì)該配置進(jìn)行簡(jiǎn)述。

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

common：對(duì)接口返回?cái)?shù)據(jù)的格式上的公共部分進(jìn)行驗(yàn)證。比如 success 必須為 true，errorcode 必須為 0 等。

publicStruc：接口核心數(shù)據(jù)部分的路徑。系統(tǒng)將根據(jù)該路徑一步步尋找。如果沒找到將會(huì)在斷言中報(bào)錯(cuò)。如果定義了多個(gè)路徑，則會(huì)按順序從前往后查找。

apis：核心部分，對(duì)接口數(shù)據(jù)進(jìn)行驗(yàn)證。

AccountCenter：該 key 可變。在這一層級(jí)對(duì)接口進(jìn)行分組，比如 AccountCenter 說明下面定義的是賬戶中心的接口的測(cè)試配置。

110620001：該 key 可變。這是真實(shí)接口的路徑。該 key 值下的對(duì)象，就是針對(duì)具體數(shù)據(jù)結(jié)構(gòu)和字段進(jìn)行配置了。下面將介紹這部分的配置和驗(yàn)證規(guī)則，可能會(huì)有點(diǎn)枯燥，不感興趣的讀者可以略過不看。

字段驗(yàn)證規(guī)則：
字段驗(yàn)證規(guī)則指的是接口下data屬性下定義的規(guī)則。是對(duì)接口核心數(shù)據(jù)的存在與否、數(shù)據(jù)類型和值所做的規(guī)定

基本規(guī)則規(guī)則

規(guī)則僅僅對(duì)類型是數(shù)字，字符串，布爾值和數(shù)組的字段有效，如果要驗(yàn)證的字段是對(duì)象，則不起作用。需要對(duì)對(duì)象內(nèi)的屬性（同樣看做字段）做進(jìn)一步的驗(yàn)證，而不是對(duì)對(duì)象本身做驗(yàn)證。

驗(yàn)證屬性可寫的值是對(duì)象，數(shù)組和字符串，其他類型的值都是非法的

驗(yàn)證屬性如果是一個(gè)空對(duì)象，則直接通過。

驗(yàn)證屬性如果是一個(gè)數(shù)組或字符串，則視為 type 處理

驗(yàn)證屬性如果是一個(gè)至少包含了required, value, type三者之一的對(duì)象，則進(jìn)行標(biāo)準(zhǔn)化驗(yàn)證

required

驗(yàn)證真實(shí)字段必須指定，且必須不為空字符串（也就是說false,0能通過驗(yàn)證。）

value

如果 value 是數(shù)組，則驗(yàn)證真實(shí)值是否至少等于數(shù)組中的某一個(gè)值

如果 value 是數(shù)字，字符串或者布爾值，驗(yàn)證真實(shí)值與其是否相等

如果 value 是一個(gè)對(duì)象，則進(jìn)一步判斷：

min:規(guī)定最小值，僅僅對(duì)數(shù)字有效

max:規(guī)定最大值，僅僅對(duì)數(shù)字有效

not:不為其值?？梢允且粋€(gè)數(shù)組，此時(shí)不為數(shù)組中的所有值

start:開始字符，僅僅對(duì)字符串有效

end:結(jié)束字符串，僅僅對(duì)字符串有效

type

type 可寫的值是字符串。這些字符串的可選值為:"number","string","boolean","array"。沒有"object","undefined","null"，因?yàn)闆]有意義

type 可以是一個(gè)數(shù)組，數(shù)組中的值也是上面的可選值。此時(shí)，只要滿足數(shù)組中的一個(gè)值，就能通過驗(yàn)證

length
當(dāng)數(shù)據(jù)是數(shù)組時(shí)才有效，是對(duì)數(shù)組長(zhǎng)度做的驗(yàn)證

min:規(guī)定最小值，僅僅對(duì)數(shù)字有效

max:規(guī)定最大值，僅僅對(duì)數(shù)字有效

item

當(dāng)數(shù)據(jù)是數(shù)組時(shí)才有效，里面進(jìn)一步規(guī)定對(duì)數(shù)組中每一項(xiàng)的驗(yàn)證

設(shè)計(jì)完各種規(guī)則后，接下來就是依樣畫葫蘆地編寫代碼了。由于代碼量比較多，這里就不再贅述。其核心思想就是根據(jù)配置項(xiàng)生成各種測(cè)試用例和斷言。最后供 mocha 運(yùn)行，輸出結(jié)果。

本文所設(shè)計(jì)的方案基本能夠滿足前端接口測(cè)試的要求，但還是有一些缺陷，弊端，及有待改進(jìn)的地方。

驗(yàn)證規(guī)則涉及不夠全面和嚴(yán)密，有待豐富，

可以將總體目錄結(jié)構(gòu)以及內(nèi)部的 TestCreater 封裝成 npm 包，更方便使用。

測(cè)試通過時(shí)，無法看到通過了哪些斷言。測(cè)試失敗時(shí)，只輸出未通過的第一條斷言的信息。輸出信息不夠全面豐富。這一定程度上是 mocha 和 chai本身的特性，不知道有什么方式可以優(yōu)化。

最后，本文中若出現(xiàn)了錯(cuò)誤，或是讀者有更好的方案，望不吝嗇賜教。