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

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

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

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

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

難以應(yīng)對驗證碼
上面的問題僅僅只是使用不便，這個問題就是直接就給該方案判了死刑。當然，爬蟲界也有不少應(yīng)對驗證碼的解決方案，比如依托 OCR 軟件啊，人工判別 API 啦, 更厲害的還有自己做圖像處理和算法進行識別。可是，作為一個簡單的接口測試，這種方案是不是太小題大做了點？

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

既然定下了方案，下一步就是設(shè)計。作為接口測試的解（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 都用于存放資源文件。

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

提供測試配置

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

點擊插件圖標，打開新 tab 頁

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

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

- manifest.json

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

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

- js/background.js

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

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

- html/main.html

  
  
  
  
  
  


  

    請在登陸后點擊按鈕開始測試
  
  

在這個 html 中，載入了三個 js 文件。其中，config/index.js 是測試配置文件。api.conf.dist.js 是入口文件經(jīng) webpack 打包后的壓縮文件。mocha 之所以獨立載入，是因為在瀏覽器環(huán)境中，mocha 必須部署在 window 對象下，所以不能打包進去。核心的邏輯代碼，放在 api.conf.dist.js 文件中。
頁面中放置了一個按鈕和一個 id 為 mocha 的 div。前者點擊后會觸發(fā) mocha 執(zhí)行，后者作為一個容器，用于顯示測試結(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 是打包的入口文件。這里主要做了兩件事：
第一，為按鈕定義了一個事件監(jiān)聽函數(shù)，點擊時執(zhí)行 mocha。
第二，初始化 mocha，設(shè)置其執(zhí)行模式(bdd)和超時時間。
第三，執(zhí)行 mainTest 函數(shù)，在這里定義了所有測試用例。測試用例根據(jù)用戶配置文件動態(tài)，這也是核心邏輯。下面將進一步詳述。

下面展示本文使用的測試配置：

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

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

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

common：對接口返回數(shù)據(jù)的格式上的公共部分進行驗證。比如 success 必須為 true，errorcode 必須為 0 等。

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

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

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

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

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

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

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

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

驗證屬性如果是一個空對象，則直接通過。

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

驗證屬性如果是一個至少包含了required, value, type三者之一的對象，則進行標準化驗證

required

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

value

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

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

如果 value 是一個對象，則進一步判斷：

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

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

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

start:開始字符，僅僅對字符串有效

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

type

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

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

length
當數(shù)據(jù)是數(shù)組時才有效，是對數(shù)組長度做的驗證

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

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

item

當數(shù)據(jù)是數(shù)組時才有效，里面進一步規(guī)定對數(shù)組中每一項的驗證

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

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

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

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

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

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