1、背景
隨着H5在各行業領域的運用，無論是在APP內嵌入H5頁面的hybrid應用還是直接在微信公衆號或者輕應用中使用H5頁面都是非常的常見（比如前端頁面通過HTTP 接口調用拉取數據進行交互，實現前後臺分離）。 而隨着此類技術的應用和發展，作爲一個測試人員，跟上時代的變化，除了保證前端頁面UI的正確性，也要保證HTTP接口的正確性，從而保證了整個業務功能邏輯的正確性，而接口如果手工測試，不僅工作量很大，而且效率比較地下，而它的特點更適合通過搭建自動化框架來測試，既能提升效率，又能保證質量。
HTTP 接口一般有兩種請求方式，一種是POST，一種是GET, 需要關注發起請求headers（POST請求還要關注post 數據）和響應的headers和body，一般情況下返回的數據都是json格式。從Chrome的Network去分析一個網頁的請求加載順序大概就能看出，目前很多網頁的請求順序都是先去請求html，從html裏得到css和js的地址，去請求css和js，從js裏的http接口去請求相關的數據，如果拉取回來的數據還有很多圖片或其他地址，在繼續請求圖片，回填內容到html網頁裏，網頁內容不斷更新變化，其實也就是接口拉取出來數據的變化，頁面的樣式基本都是一樣的：
1.1、手工測試hold不住的問題
1) 如上圖，視頻分類很多，電影、電視劇、綜藝、動漫等，每次都把各個頻道測試一遍，比較耗時；
2) 在進行視頻組合查詢時，各種條件組合能拉取回不同的數據，而組合的方式有上千種，如何都保證查詢過濾的正確性；
3) 前端頁面都是正常的，可用戶總反饋有時候拉取不到數據，到底哪裏出了問題；
4) 寫了用例，但是發現覆蓋不全，因爲組合場景太多，每個組合場景都測試，工作量又太大；
5) 線上出現問題了我們卻不是第一個知道出問題了，沒法對頁面的內容進行很好的監控，因爲用戶場景變化多端；
1.2、怎麼來通過HTTP接口測試很好的解決上面問題呢
1) 抽取接口（chrome爬取？ http工具分析？手工提取）
2) 拿到接口後，怎麼獲取接口參數所有的值（通過線上數據去挨個查找？從運營平臺獲取數據？）
3) 怎麼把所有線上接口都全部抓取並監控起來
4) 發現問題的反饋處理
5) 接口修改維護
帶着這些問題，進行了下面整個自動化接口測試平臺的搭建。
2、接口自動化測試思路
2.1、整個測試流程的梳理
根據上面1.2所描述將會遇到的問題，整理測試設計思路，每個大項劃分出要完成的子項，流程圖如下：
2.2、運行時機
設計這個測試，是爲了更好的更快的發現問題，能儘早的完成測試閉環，找出產品缺陷，反饋開發同學，加快整個迭代的速度。具體有以下場景：
1）開發自測：開發同學開發完新的接口後，不知道對其他接口有沒有影響，可以跑一遍接口測試來確定；
2）冒煙測試：開發提測後，可以把所有接口和參數都運行一遍，所需要修改域名爲測試環境域名和新增接口；
3）線上監控：對已上線業務進行監控，當某些組合條件查詢不到數據或者某些接口拉取不到數據時，能夠及時提醒相關測試和開發人員。
3、HTTP接口自動化測試平臺搭建
3.1、技術選型
1） 前端和後臺邏輯：根據目前所熟悉的框架和語言，選擇Python+Django+Bootstrap
2） 存儲：使用Mysql存儲所有接口數據，分爲3塊數據（抓取回來所有接口數據、唯一接口數據、參數化接口數據）
3） 接口監控任務調起管理：Jenkins
3.2、接口數據抓取
1） 手工抓取 （模塊、標籤是爲了方便從業務角度管理http接口腳本）
2） 自動批量抓取：測試人員在手機上訪問業務，手機通過筆記本商的Fiddler來代理上網，這樣Fiddler可以抓取到所有數據，相關設置可以參考Fiddler手機抓包教程http://jingyan.baidu.com/article/03b2f78c7b6bb05ea237aed2.html，抓包並分析出HTTP 接口數據的流程如下：
a、設置Fiddler的Customize Rules…
b、修改Script內容，具體代碼和相關描述如下圖，注意你需要過濾的主要域名，因爲手機上有很多其他的請求也會被抓出來，通過域名過濾可以過濾出來當前域名的請求；
c、在這個腳本中，還可以定義請求中以html、gif、css、js、jpg等等其他和接口無關的請求；
3）把所有有效的接口請求頭，請求body，返回頭，返回body全部存儲到文件裏，等待下一步分析；
抓取到的文件數據如下：
3.3、分析接口
1）接口清洗：
a、作用：接口回放，迴歸測試；
b、過濾掉提取的http session中的js、css、圖片等雜質；
c、Post請求：過濾掉經過加密請求（暫不考慮），其他session保留；
d、Get請求：api返回數據都是json類型，根據response中的”Content-Type”字段是否爲json判定是否爲有效接口；
e、保留返回碼爲301/302跳轉的http session；
2）唯一接口過濾：
a、作用：接口回放，迴歸測試；
b、過濾掉提取的http session中的js、css、圖片等雜質；
c、Post請求：過濾掉經過加密請求（暫不考慮），其他session保留；
d、Get請求：api返回數據都是json類型，根據response中的”Content-Type”字段是否爲json判定是否爲有效接口；
e、保留返回碼爲301/302跳轉的http session；
3）接口清洗流程
3.4、接口測試
1）對清洗的接口進行測試，測試通過後，接口再做入庫處理；
2）接口調用的處理流程：
3.5、腳本管理
1） 可以對測試任務進行管理，設置在批量運行時是否要進行運行，運行的狀態展示，運行詳情設置以及刪除操作，因爲接口數量衆多，可以選擇刪除選中或是全部刪除：
2） 右側可以看到所有請求的原始數據（請求時間、接口更新時間、請求數據、請求頭部、響應頭部、響應內容數據），左側可以對響應進行校驗，分爲基礎校驗和自定義斷言，基礎校驗可以校驗返回頭代碼、返回內容類型、內容長度，自定義斷言可以自己添加任何返回數據的字段並設置對比方式和值進行對比，可設置多個字段：
自定義斷言：
3）接口參數化，在獲取到接口後，可以通過接口參數的key，加上從開發或者運維那裏獲取到的參數值列表，進行快速參數化，所有參數進行排列組合，生成該接口全集，進行回放測試；
3.6、更新接口
在使用過程中，會遇根據由於業務變動來 新增、修改、刪除HTTP API的情況，所以在接口自動化測試時，我們可以通過下面兩種情況來處理接口的變動；
1）從開發那裏得知有更改變化的接口，手動通過接口管理頁面進行參數的刪減或者直接手工新建接口，添加到隊列裏；
2）如果是不知道接口是否有變動，目前採用半自動去分析接口（和初始錄製接口一樣，測試人員在手機上操作一遍業務，Fiddler錄製所有接口，再自動識別接口的變更，來更數據庫中的接口）；
3）具體實現流程圖：
3.7、日常監控 和 結果輸出
日常監控可以使用Jenkins來做後臺管理，通過前端頁面提交任務表單後，自動根據提交數據在Jenkins裏建立新的job，可以手動觸發執行任務或者自動定時觸發任務：
1）在前端頁面填寫form表單（包括任務名稱、業務分類、運行計劃、結果郵件推送列表等），提交後，自動在後臺添加任務到Jenkins裏，如下圖；
2）根據運行計劃執行後生成監控郵件結果，通知項目相關人員，此處可以配置爲當失敗時在進行通知，線上的監控一般都是每半小時執行一次，這樣能夠儘快的獲得線上接口運行情況;
3）發現問題的閉環：打通缺陷管理系統，如果發現監控失敗的接口，可以點擊詳情頁查看具體失敗詳情，確認是缺陷，可以一鍵提交缺陷到缺陷管理系統，方便後面對該問題的跟蹤處理。