不管是 Web 系統，還是移動 APP，前後端邏輯的分離設計已經是常態化，相互之間通過 API 調用進行數據交互。在基於 API 約定的開發模式下，如何加速請求 / 響應的 API 測試，讓研發人員及早參與到調試中來呢？既然 API 是基於約定開發，為何不按照這個規範編寫測試用例，直接進入待測試狀態，使用自動化的方式來推進研發過程的質量改進呢？遵循：測試 -> 重構 -> 測試 -> 重構，這樣的閉環，過程產出的質量會更加可控，在重構的同時進行快速的功能回歸驗證，大大提高效率。下面主要講解基於 HTTP 協議的 API 測試，從手工測試到平臺的演變過程。
　　
　　手工測試帶來的困惑
　　
　　測試團隊采用《敏捷腦圖用例實踐之路》的方式編寫測試用例：
　　
　　圖 -1- 分計費單元查詢帶寬
　　
　　圖 -1- 分計費單元查詢帶寬
　　
　　優點：
　　
　　要點清晰簡潔展現
　　
　　所有測試故事點經過用例評審，產生質量高，研發參與感強；
　　
　　版本同步保持一份
　　
　　API 測試腦圖帶來的問題：
　　
　　腦圖用例對測試人員的素質要求相當高
　　
　　完善的腦圖用例編寫，需要有資深的測試人員，對業務精通、對測試技能精通，很強的思維能力；如果研發人員僅僅參考這個腦圖用例進行測試，往往很多時候需要花費大量的溝通時間，其中有很多測試 API 的過程、措施，在腦圖裏面沒有具體體現，造成一些信息丟失。
　　
　　重復執行不變的是規則，變的只是參數，要消滅重復部分
　　
　　還可以深度優化腦圖用例，API 接口規範，再怎麽天馬行空，也得有個度，應當把重復思考的部分交給工具去做，需要發揮創造力、值得關註部分，交給人工完成；按照這個測試流程，，測試人員編寫完用例，去驗證 API 接口，如果失敗了，打回給研發人員重新修改，但是下一次研發人員提交測試，測試人員又得重新驗證一遍，這一遍中實際沒有多少有價值的思考，是重復工作，要去挖掘測試價值。另外，如果測試人員請假了，那是不是測試就需要延期了呢？消除等待、消除單點作業，改變是唯一出路，嘗試過如下方式：
　　
　　圖 -2-Chrome DHC 組件
　　
　　圖 -2-Chrome DHC 組件
　　
　　組員通過使用 Chrome DHC（是一款使用 chrome 模擬 REST 客戶端向服務器發送測試數據的谷歌瀏覽器插件），進行 API 自動化測試，用例文件保存到本地並且同步到 svn，簡單粗暴解決重復請求問題，註意強調的是解決重復請求，並沒有包括參數和結果的自動化驗證的過程，還是需要人工參與，至少前進了一步，當然我們也解決了單點問題，其他組員可以更新用例本地運行，還差參數校驗，數據校驗等等一堆關鍵業務點要用自動化去突破。
　　
　　俗話說：術業有專攻，DHC 只是玩玩而已，並不擅長做那麽多活，也做不好，更期望的是平臺化。
　　
　　平臺雛形：沒有經驗，多麽痛的領悟
　　
　　經歷了手工測試的繁瑣操作，丟棄了簡單的 DHC，決定另尋新路，API 測試最簡單的場景請求參數組合產生各類別的測試用例。思路很簡單，做一個 WEB 平臺，登記 API 接口，填寫請求參數，對響應結果進行校驗，初期進行了技術選型，使用 Django 做 Python Web 開發，後臺腳本執行使用開源框架 RobotFramework，RF 優點如下：
　　
　　是一個通用的關鍵詞驅動自動測試框架；
　　
　　易於使用的表格數據展現形式，采用關鍵字驅動的測試方法，使用在測試庫中實現的關鍵詞來在測試中運行程序。
　　
　　是靈活和可擴展的，適合用於測試用戶接口；
　　
　　在這個平臺中，RobotFramework 主要用於後臺執行 Robot 關鍵字腳本，而關鍵字腳本，是平臺通過讀取 YAML 文件生成，該文件是通過笛卡爾乘積產生的用例，工作原理如圖所示：
　　
　　圖 -3- 工作原理
　　
　　圖 -3- 工作原理
　　
　　那話說回來，YAML 幹什麽呢？為什麽不是 XML 呢？
　　
　　YAML 的可讀性好
　　
　　YAML 和腳本語言的交互性好
　　
　　YAML 使用實現語言的數據類型
　　
　　YAML 有一個一致的信息模型
　　
　　YAML 易於實現
　　
　　聽起來 YAML 試圖用一種比 XML 更敏捷的方式，來完成 XML 所完成的任務。下面通過一段實際例子說明配置生成的 YAML 代碼段：
　　
　　主接口配置界面：
　　
　　圖 -4- 接口配置頁面
　　
　　圖 -4- 接口配置頁面
　　
　　設置 API 參數：
　　
　　圖 -5- 設置 API 參數
　　
　　圖 -5- 設置 API 參數
　　
　　配置文件 byChannelsDaily.yaml（列舉一個參數示例）：
　　
　　- byChannelsDaily: # 接口名稱
　　
　　method: get # 與服務器交互的方法
　　
　　format: json #API 數據格式
　　
　　url: /reportdata/flux/byChannelsDaily #API 的 URL，與奇臺配置文件裏面的 host 變量組成整個 URL 的前半部分。
　　
　　url_path:
　　
　　url_params: #URL 參數部分，固定寫法。
　　
　　username: #API 的參數名。
　　
　　required: true # 該參數是否必須（true/false）。
　　
　　value: chinacache # 該參數的值。如此值是從另一個接口獲取的，可在 from_api 設置，此處可不填。如果值是 Boolean，必須加雙引號。
　　
　　type: string # 該參數值的類型。
　　
　　len: 10 # 該參數值的長度。
　　
　　max: -100 # 該參數值的最大值。-100 相當於忽略此參數
　　
　　min: -100 # 該參數值的最小值。-100 相當於忽略此參數
　　
　　from_api: # 如參數的值是從另一個接口、global.yaml 中獲取的，請設置 from_api，如 global
　　
　　jsonpath: # 可通過 jsonpath 來指定取值範圍，如 $.version[2:4]
　　
　　range:
　　
　　response: # 期望結果
　　
　　verification:
　　
　　success: [] #success 是一個 list, 它的元素也是 list，success[0] = [ RF 關鍵字 ，驗證字段，正則匹配]
　　
　　failure: []
　　
　　error_msg: [] # 錯誤信息集合</pre>
　　
　　測試報告：
　　
　　圖 -6-rf 測試報告
　　
　　圖 -6-rf 測試報告
　　
　　按照這個思路做下來，得到什麽收益呢？
　　
　　自動化
　　
　　自動化
　　
　　說到這裏，其實，真沒有帶來多少收益，思路對了，但是方向有偏差了，主要體現在：
　　
　　使用了笛卡爾乘積來生成不同參數的測試用例，發現一堆的測試用例生成文件是 M 的單位，而且也給測試服務器帶來性能問題，數量 4980 個中占 95% 的用例都是沒有實際意義的，對服務器頻繁請求造成壓力；
　　
　　圖 -7- 龐大的測試用例文件
　　
　　圖 -7- 龐大的測試用例文件
　　
　　通過 WEB 配置將 YAML 文件轉為 robot 可以識別的，這種做法坑太深、維護難，參數越多， 文件越臃腫，可讀性差；
　　
　　後來嘗試將笛卡爾乘積換成全對偶組合算法，效果改進顯著，無效用例數明顯下降，有效用例數顯著提升；
　　
　　敗了，就是敗了，沒什麽好找借口，關鍵問題是：
　　
　　有效的測試用例占比例很低，無效的占了大部分；
　　
　　沒有化繁為簡，前端隱藏了配置，復雜的配置還是需要在後端處理；
　　
　　沒有實際測試參與動腦過程，測試人員不會窮舉，會根據業務編寫實際用例；
　　
　　平臺易用性很重要：需要測試人員直接在上面編寫，合理的邏輯步驟，有利於引導測試參與；
　　
　　重構：發現測試的價值
　　
　　回到起點，測試要解決什麽問題，為什麽要做 API 自動化測試平臺？做這個平臺，不是為了滿足老板的提倡全民自動化的口號，也不是為了浮誇的 KPI，更不是宣傳自動化可以解決一切問題，發現所有 bug。叔本華說過一句話：由於頻繁地重復，許多起初在我們看來重要的事情逐漸變得毫無價值。如果 API 測試僅僅依靠純手工的執行，很快將會面臨瓶頸，因為每一個功能幾乎都不能是第一次提交測試後就測試通過的，所以就需要反復 bug 修復、驗證，以及回歸的過程。另外，很多的 API 測試工作手工做起來非常的繁瑣，甚至不便，比如針對接口協議的驗證、針對返回數據格式的驗證，這些都依賴於測試自動化的開展。因此，真正的目的是解放測試人員重復的手工生產力，加速回歸測試效率，同時讓研發人員在開發過程及早參與測試（自測、冒煙測試），驅動編碼質量的提升。
　　
　　回顧以往，重新梳理頭緒，更加清晰的展現：
　　
　　圖 -8-HTTP API 自動化測試圖解
　　
　　圖 -8-HTTP API 自動化測試圖解
　　
　　HTTP API 傳統手工測試
　　
　　重復請求參數基礎校驗、正確參數查詢返回數據校驗，測試工程師沒有新的創造價值，不斷重復工作，甚至可能壓縮其中的測試環節，勉強交付；
　　
　　HTTP API 自動化測試
　　
　　重復步驟（請求接口是否有效、參數校驗可以作為冒煙測試，研發參與自測）用自動化解決，關鍵業務步驟數據對比人工參與和 schema 自動化校驗；
　　
　　如果對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣可以175317069，群內會有不定期的發放免費的資料鏈接，這些資料都是從各個技術網站搜集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。
　　
　　最大的收益，重復步驟自動化後，不管是研發人員自測，還是執行功能回歸測試，成本可以很快收回（前提是你這個項目周期長，構建頻繁；如果僅僅是跑幾個月的項目，真沒那個必要湊熱鬧去自動化，當然有平臺的另當別論），測試的關註點會落實到更加關鍵的業務環節去；
　　
　　總體規劃如下：
　　
　　[
　　
　　圖 -9-HTTP API 重構規劃
　　
　　圖 -9-HTTP API 重構規劃
　　
　　技術選型
　　
　　由於原來的測試平臺使用 Python 編寫，為了保持風格一致，從界面錄入到文件生成處理依然采用 Python、Django，去掉了全對偶組合算法，改為根據測試人員思維去產生用例；去掉了後臺 RobotFramework 框架，采用 Python 的 HTTP 類庫封裝請求。
　　
　　HTTP API 項目管理 Web 前臺
　　
　　使用 Python+Django+MySQL 進行開發，分為項目首頁、項目配置、API 配置、全局配置四大部分
　　
　　圖 -10- 管理 Web
　　
　　圖 -10- 管理 Web
　　
　　項目首頁
　　
　　介紹：列出 API 規範、API 測試用例、定時任務數量，以及某段時間內的測試結果趨勢圖形。
　　
　　圖 -11- 項目首頁
　　
　　圖 -11- 項目首頁
　　
　　項目配置
　　
　　重點介紹：全局變量、常用方法、驗證器。
　　
　　全局變量
　　
　　設計思路：在 API 測試過程中，可以切換生產、測試環境進行對比校驗，如果寫兩套測試用例是冗余，全局變量功能，是一種在執行測試用例時動態改變用例屬性的方法。
　　
　　作用範圍：當前項目內
　　
　　使用方法：{變量名}
　　
　　能在以下測試用例屬性中使用：URL、請求頭、請求參數
　　
　　圖 -12- 全局變量配置頁
　　
　　圖 -12- 全局變量配置頁
　　
　　在 API 用例庫的 URL 可以直接填寫：{host}/reportdata/monitor/getChannelIDsByUserName；當運行測試用例的時候，可以選擇不同的參數套件，後臺代碼執行會直接替換，這樣子可以分別快速驗證生產環境和測試環境的 API 接口執行結果的差異。
　　
　　圖 -13- 用例執行頁
　　
　　圖 -13- 用例執行頁
　　
　　常用方法
　　
　　圖 -14- 常用方法列表頁
　　
　　圖 -14- 常用方法列表頁
　　
　　√ 設計思路：常用方法是一個 Python 函數，對入參進行處理並且返回結果，例如：
　　
　　gen_md5 作用是生成 MD5，對應代碼直接填寫：
　　
　　import hashlib
　　
　　def gen_md5(raw_str):
　　
　　m = hashlib.md5()
　　
　　m.update(raw_str)
　　
　　md5_str = m.hexdigest()
　　
　　return md5_str
　　
　　√ 應用場景：
　　
　　在 API 請求中，有些參數例如 pass 需要加密處理，可以通過引入 [常用方法] 來解決。
　　
　　在參數 pass 的值中直接填寫：
　　
　　{{get_apipwd("{123456}","ChinaCache")}}</pre>
　　
　　圖 -15- 接口配置頁
　　
　　圖 -15- 接口配置頁
　　
　　驗證器
　　
　　√ 設計思路
　　
　　驗證器是一個 Python 函數，如果函數返回 True，則測試通過；返回 False，則測試失敗。平臺默認提供一個默認驗證器。
　　
　　默認驗證器是驗證期望結果與實際結果（response body）是否完全一致。如果結果不一致則判斷為失敗，默認驗證器只適用於靜態的響應結果對比。
　　
　　自義定驗證器，如果默認驗證器不能滿足某些特殊的測試需求，用戶可以在“項目配置 - 驗證器”中添加自定義的驗證器。
　　
　　√ 應用場景：在 API 測試的返回結果中，可以添加自定義驗證器對數據進行校驗，判斷測試是否通過。
　　
　　圖 -17- 測試用例驗證展示頁
　　
　　圖 -17- 測試用例驗證展示頁
　　
　　API 配置
　　
　　重點介紹：通用響應配置、API 依賴庫、API 用例庫、定時任務、測試報告
　　
　　通用響應配置
　　
　　圖 -18- 通用響應配置列表頁
　　
　　圖 -18- 通用響應配置列表頁
　　
　　√ 設計思路
　　
　　在合理的 API 設計中，存在通用的錯誤響應碼，[用戶名錯誤，返回期望響應內容]，如果所有 API 的響應結果中都需要重復寫是相當繁瑣的，作為共同配置調用即可。
　　
　　√ 應用場景
　　
　　查詢接口遇到用戶名密碼為空，可以自定義寫返回內容，以及選擇 [通用響應配置] 下的相關錯誤類型，例如：用戶名密碼為空 (計費單元)，自動填充期望的返回值：
　　
　　<BillingIDs>
　　
　　<Result>fail<www.michenggw.com /Result>
　　
　　<DetailInfo>invalid userName or password</DetailInfo>
　　
　　</BillingIDs>
　　
　　圖 -19- 期望返回值校驗頁
　　
　　圖 -19- 期望返回值校驗頁
　　
　　API 依賴庫
　　
　　√ 設計思路 & 應用場景
　　
　　API-A 的參數 r_id 依賴與 API-B 返回結果的某個參數（多個參數同樣道理），這裏登記 API-B，並且提取返回參數。除了特有的變量提取器，基本信息與請求，與後面提到的 API 接口一致的
　　
　　填寫方式 ：
　　
　　圖 -20- 變量提取器展示頁
　　
　　圖 -20- 變量提取器展示頁
　　
　　該接口返回數據如下；
　　
　　{
　　
　　"r_id": "567bbc3f2b8a683f7e2e9436"
　　
　　}
　　
　　通過 [變量提取器]，可以獲取 r_id 的值，以供依賴 API-A 作為參數使用。
　　
　　圖 -21- 用例中參數包含 r_id 變量展示頁
　　
　　圖 -21- 用例中參數包含 r_id 變量展示頁
　　
　　其中請求參數的獲取如下：
　　
　　圖 -22- 請求參數變量提取設置
　　
　　圖 -22- 請求參數變量提取設置
　　
　　測試結果：
　　
　　1- 顯示依賴接口；2- 顯示為需要測試的接口，依賴接口返回的 r_id 會傳入作為測試接口的參數；
　　
　　圖 -23- 測試結果中展示運行時變量提取結果
　　
　　圖 -23- 測試結果中展示運行時變量提取結果
　　
　　API 用例庫
　　
　　圖 -24- 用例庫設計腦圖
　　
　　圖 -24- 用例庫設計腦圖
　　
　　如果對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣可以175317069，群內會有不定期的發放免費的資料鏈接，這些資料都是從各個技術網站搜集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。
　　
　　√ 設計思路
　　
　　通過自助配置：請求頭、請求參數，響應頭、響應結果校驗，來聚合測試人員日常思考產生的測試用例。
　　
　　√ 應用場景
　　
　　支持 HTTP1.1 協議的 7 種請求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE 和 TARCE。最常用的方法是 GET 和 POST：
　　
　　支持 query（問號後）帶參數、www.yigouyule2.cn path 的 GET|POST 請求
　　
　　Query:http://192.168.1.11/internal/refresh?username=ChinaCache&password=123456
　　
　　Path:http://192.168.1.11/internal/refresh/username/password
　　
　　POST 請求支持 application/json、text/xml
　　
　　示例如下：
　　
　　請求頭設置：Content- www.mhylpt.com/ Type:application/json
　　
　　請求體設置：保存為 JSON 格式
　　
　　{
　　
　　"username": www.meiwanyule.cn"ChinaCache",
　　
　　"password": "123456",
　　
　　"task": {
　　
　　"dirs": [ 如果對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、
　　
　　"" 面試經驗交流。感興趣可以175317069，群內會有不定期的發放免費
　　
　　], 的資料鏈接，這些資料都是從各個技術網站搜集、整理出來的，如果
　　
　　"callback": { 你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。
　　
　　"url": "",
　　
　　"email": []
　　
　　},
　　
　　"urls": [
　　
　　"http://www.chinacache.com/news/test.html"
　　
　　]
　　
　　}
　　
　　}

HTTP API 自動化測試從手工測試到平臺的演變