HTTP API自動化測試從手工到平臺的演變
不管是Web系統，還是移動APP，前后端邏輯的分離設計已經是常態化，相互之間通過API調用進行數據交互。在基于API約定的開發模式下，如何加速請求/響應的API測試，讓研發人員及早參與到調試中來呢？既然API是基于約定開發，為何不按照這個規范編寫測試用例，直接進入待測試狀態，使用自動化的方式來推進研發過程的質量改進呢？遵循：測試->重構->測試->重構，這樣的閉環，過程產出的質量會更加可控，在重構的同時進行快速的功能回歸驗證，大大提高效率。本文主要講解基于HTTP協議的API測試，從手工測試到平臺的演變過程。
手工測試帶來的困惑
測試團隊采用 《敏捷腦圖用例實踐之路》 的方式編寫測試用例：
(點擊放大圖像)
圖-1-分計費單元查詢帶寬
優點（文中已有詳細介紹，這里簡單列舉）：
- 要點清晰簡潔展現
- 所有測試故事點經過用例評審，產生質量高，研發參與感強；
- 版本同步保持一份
API測試腦圖帶來的問題：
- 腦圖用例對測試人員的素質要求相當高
- 完善的腦圖用例編寫，需要有資深的測試人員，對業務精通、對測試技能精通，很強的思維能力；如果研發人員僅僅參考這個腦圖用例進行測試，往往很多時候需要花費大量的溝通時間，其中有很多測試API的過程、措施，在腦圖里面沒有具體體現，造成一些信息丟失。
- 重復執行不變的是規則，變的只是參數，要消滅重復部分
- 還可以深度優化腦圖用例，API接口規范，再怎么天馬行空，也得有個度，應當把重復思考的部分交給工具去做，需要發揮創造力、值得關注部分，交給人工完成；按照這個測試流程，，測試人員編寫完用例，去驗證API接口，如果失敗了，打回給研發人員重新修改，但是下一次研發人員提交測試，測試人員又得重新驗證一遍，這一遍中實際沒有多少有價值的思考，是重復工作，要去挖掘測試價值。另外，如果測試人員請假了，那是不是測試就需要延期了呢？消除等待、消除單點作業，改變是唯一出路，嘗試過如下方式：
(點擊放大圖像)
圖-2-Chrome DHC組件
組員通過使用Chrome DHC（是一款使用chrome模擬REST客戶端向服務器發送測試數據的谷歌瀏覽器插件），進行API自動化測試，用例文件保存到本地并且同步到svn，簡單粗暴解決重復請求問題，注意強調的是解決重復請求，并沒有包括參數和結果的自動化驗證的過程，還是需要人工參與，至少前進了一步，當然我們也解決了單點問題，其他組員可以更新用例本地運行，還差參數校驗，數據校驗等等一堆關鍵業務點要用自動化去突破。
俗話說：術業有專攻，DHC只是玩玩而已，并不擅長做那么多活，也做不好，更期望的是平臺化。
平臺雛形：沒有經驗，多么痛的領悟
經歷了手工測試的繁瑣操作，丟棄了簡單的DHC，決定另尋新路，API測試最簡單的場景請求參數組合產生各類別的測試用例。思路很簡單，做一個WEB平臺，登記API接口，填寫請求參數，對響應結果進行校驗，初期進行了技術選型，使用Django做Python Web開發，后臺腳本執行使用開源框架RobotFramework，RF優點如下：
- 是一個通用的關鍵詞驅動自動測試框架；
- 易于使用的表格數據展現形式，采用關鍵字驅動的測試方法，使用在測試庫中實現的關鍵詞來在測試中運行程序。
- 是靈活和可擴展的，適合用于測試用戶接口；
在這個平臺中，RobotFramework主要用于后臺執行Robot關鍵字腳本，而關鍵字腳本，是平臺通過讀取YAML文件生成，該文件是通過笛卡爾乘積產生的用例，工作原理如圖所示：
(點擊放大圖像)
圖-3-工作原理
那話說回來，YAML干什么呢？為什么不是XML呢？
- YAML的可讀性好
- YAML和腳本語言的交互性好
- YAML使用實現語言的數據類型
- YAML有一個一致的信息模型
- YAML易于實現
聽起來YAML試圖用一種比XML更敏捷的方式，來完成XML所完成的任務。下面通過一段實際例子說明配置生成的YAML代碼段：
主接口配置界面：
(點擊放大圖像)
圖-4-接口配置頁面
設置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: [] #錯誤信息集合
測試報告：
(點擊放大圖像)
圖-6-rf測試報告
按照這個思路做下來，得到什么收益呢？
(點擊放大圖像)
說到這里，其實，真沒有帶來多少收益，思路對了，但是方向有偏差了，主要體現在：
- 使用了笛卡爾乘積來生成不同參數的測試用例，發現一堆的測試用例生成文件是M的單位，而且也給測試服務器帶來性能問題，數量4980個中占95%的用例都是沒有實際意義的，對服務器頻繁請求造成壓力；
- 通過WEB配置將YAML文件轉為robot可以識別的，這種做法坑太深、維護難，參數越多， 文件越臃腫，可讀性差；
- 后來嘗試將笛卡爾乘積換成全對偶組合算法，效果改進顯著，無效用例數明顯下降，有效用例數顯著提升；
(點擊放大圖像)
圖-7-龐大的測試用例文件
敗了，就是敗了，沒什么好找借口，關鍵問題是：
- 有效的測試用例占比例很低，無效的占了大部分；
- 沒有化繁為簡，前端隱藏了配置，復雜的配置還是需要在后端處理；
- 沒有實際測試參與動腦過程，測試人員不會窮舉，會根據業務編寫實際用例；
- 平臺易用性很重要：需要測試人員直接在上面編寫，合理的邏輯步驟，有利于引導測試參與；
重構：發現測試的價值
回到起點，測試要解決什么問題，為什么要做API自動化測試平臺？做這個平臺，不是為了滿足老板的提倡全民自動化的口號，也不是為了浮夸的KPI，更不是宣傳自動化可以解決一切問題，發現所有bug。叔本華說過一句話：由于頻繁地重復，許多起初在我們看來重要的事情逐漸變得毫無價值。如果API測試僅僅依靠純手工的執行，很快將會面臨瓶頸，因為每一個功能幾乎都不能是第一次提交測試后就測試通過的，所以就需要反復bug修復、驗證，以及回歸的過程。另外，很多的API測試工作手工做起來非常的繁瑣，甚至不便，比如針對接口協議的驗證、針對返回數據格式的驗證，這些都依賴于測試自動化的開展。因此，真正的目的是解放測試人員重復的手工生產力，加速回歸測試效率，同時讓研發人員在開發過程及早參與測試（自測、冒煙測試），驅動編碼質量的提升。
回顧以往，重新梳理頭緒，更加清晰的展現：
(點擊放大圖像)
圖-8-HTTP API自動化測試圖解
- HTTP API傳統手工測試
- 重復請求參數基礎校驗、正確參數查詢返回數據校驗，測試工程師沒有新的創造價值，不斷重復工作，甚至可能壓縮其中的測試環節，勉強交付；
- HTTP API自動化測試
- 重復步驟（請求接口是否有效、參數校驗可以作為冒煙測試，研發參與自測）用自動化解決，關鍵業務步驟數據對比人工參與和schema自動化校驗；
最大的收益，重復步驟自動化后，不管是研發人員自測，還是執行功能回歸測試，成本可以很快收回（前提是你這個項目周期長，構建頻繁；如果僅僅是跑幾個月的項目，真沒那個必要湊熱鬧去自動化，當然有平臺的另當別論），測試的關注點會落實到更加關鍵的業務環節去；
總體規劃如下：
(點擊放大圖像)
圖-9-HTTP API重構規劃
-
技術選型
由于原來的測試平臺使用Python編寫，為了保持風格一致，從界面錄入到文件生成處理依然采用Python、Django，去掉了全對偶組合算法，改為根據測試人員思維去產生用例；去掉了后臺RobotFramework框架，采用Python的HTTP類庫封裝請求。
-
HTTP API項目管理Web前臺
使用Python+Django+MySQL進行開發，分為項目首頁、項目配置、API配置、全局配置四大部分
(點擊放大圖像)
圖-10-管理Web
> 項目首頁
介紹：列出API規范、API測試用例、定時任務數量，以及某段時間內的測試結果趨勢圖形。
(點擊放大圖像)
圖-11-項目首頁
-
項目配置
重點介紹：全局變量、常用方法、驗證器。
>全局變量
設計思路：在API測試過程中，可以切換生產、測試環境進行對比校驗，如果寫兩套測試用例是冗余，全局變量功能，是一種在執行測試用例時動態改變用例屬性的方法。
作用范圍：當前項目內
使用方法：{變量名}
能在以下測試用例屬性中使用：URL、請求頭、請求參數
(點擊放大圖像)
圖-12-全局變量配置頁
在API用例庫的URL可以直接填寫：{host}/reportdata/monitor/getChannelIDsByUserName；當運行測試用例的時候，可以選擇不同的參數套件，后臺代碼執行會直接替換，這樣子可以分別快速驗證生產環境和測試環境的API接口執行結果的差異。
(點擊放大圖像)
圖-13-用例執行頁
>常用方法
(點擊放大圖像)
圖-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")}}(點擊放大圖像)
圖-15-接口配置頁
> 驗證器
(點擊放大圖像)
圖-16-驗證器配置頁
√ 設計思路
驗證器是一個Python函數，如果函數返回True，則測試通過；返回False，則測試失敗。平臺默認提供一個默認驗證器。
默認驗證器是驗證期望結果與實際結果（response body）是否完全一致。如果結果不一致則判斷為失敗，默認驗證器只適用于靜態的響應結果對比。
自義定驗證器，如果默認驗證器不能滿足某些特殊的測試需求，用戶可以在“項目配置-驗證器”中添加自定義的驗證器。
√ 應用場景：在API測試的返回結果中，可以添加自定義驗證器對數據進行校驗，判斷測試是否通過。
(點擊放大圖像)
圖-17-測試用例驗證展示頁
-
API配置
重點介紹：通用響應配置、API依賴庫、API用例庫、定時任務、測試報告
> 通用響應配置
(點擊放大圖像)
圖-18-通用響應配置列表頁
√ 設計思路
在合理的API設計中，存在通用的錯誤響應碼，[用戶名錯誤，返回期望響應內容]，如果所有API的響應結果中都需要重復寫是相當繁瑣的，作為共同配置調用即可。
(點擊放大圖像)
√ 應用場景
查詢接口遇到用戶名密碼為空，可以自定義寫返回內容，以及選擇[通用響應配置]下的相關錯誤類型，例如：用戶名密碼為空(計費單元)，自動填充期望的返回值：
<BillingIDs> <Result>fail</Result> <DetailInfo>invalid userName or password</DetailInfo> </BillingIDs>
(點擊放大圖像)
圖-19-期望返回值校驗頁
> API依賴庫
√ 設計思路&應用場景
API-A的參數r_id依賴與API-B返回結果的某個參數（多個參數同樣道理），這里登記API-B，并且提取返回參數。除了特有的變量提取器，基本信息與請求，與后面提到的API接口一致的
填寫方式 ：
(點擊放大圖像)
圖-20-變量提取器展示頁
該接口返回數據如下；
{ "r_id": "567bbc3f2b8a683f7e2e9436" }通過[變量提取器]，可以獲取r_id的值，以供依賴API-A作為參數使用。
(點擊放大圖像)
圖-21-用例中參數包含r_id變量展示頁
其中請求參數的獲取如下：
(點擊放大圖像)
圖-22-請求參數變量提取設置
測試結果：
1-顯示依賴接口；2-顯示為需要測試的接口，依賴接口返回的r_id會傳入作為測試接口的參數；
(點擊放大圖像)
圖-23-測試結果中展示運行時變量提取結果
-
API用例庫
(點擊放大圖像)
圖-24-用例庫設計腦圖
√ 設計思路
通過自助配置：請求頭、請求參數，響應頭、響應結果校驗，來聚合測試人員日常思考產生的測試用例。
√ 應用場景
支持HTTP1.1協議的7種請求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。最常用的方法是GET和POST：
- 支持query（問號后）帶參數、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-Type:application/json 請求體設置：保存為JSON格式 { "username": "ChinaCache", "password": "123456", "task": { "dirs": [ "" ], "callback": { "url": "", "email": [] }, "urls": [ "http://www.chinacache.com/news/test.html" ] } }結果如下：
(點擊放大圖像)
圖-25-body參數展示頁
-
支持返回結果的schema驗證
在返回大量數據的場景下，把數據格式的正確性交給程序去判斷，通過之后進行人工干預的數據對比，假如返回幾百K的數據，你不知道格式是否正確，就開始去做數據對比，這個方向是不對的。
{ "r_id": "567cfce22b8a683f802e944b" } Schema驗證如下： { "$schema": "http://json-schema.org/draft-04/schema#", "required": [ "r_id" ], "type": "object", "id": "http://jsonschema.net", "properties": { "r_id": { "type": "string", "id": "http://jsonschema.net/r_id" } } }
- 支持query（問號后）帶參數、path的GET|POST請求
-
定時任務
√ 設計思路&應用場景
定時任務是在計劃好的時間點自動執行指定的測試用例。一個項目支持多個定時任務，如果同一時間點有多個測試任務，將依次執行。定時任務有兩種類型：定時、循環（間隔：秒，
分鐘，小時，天，周）。通過定時任務，可以做到晚上運行，早上查看結果報告分析。
(點擊放大圖像)
圖-26-添加定時任務
-
測試報告&郵件通知
√ 設計思路&應用場景
每次執行測試用例（包括手動執行和定時任務）之后，都會生成一份測試報告。
報告會詳細列出每個接口的基本信息（名稱，請求方法，驗證器等），請求信息（URL和body參數），響應信息包括headers, body, schema, content type, status code 5部分的測試結果，每一部分都有實際結果、期望結果（失敗時顯示）以及DIFF對比（失敗時顯示），當在
執行測試時出現錯誤，也會把錯誤信息顯示出來 。
(點擊放大圖像)
圖-27-測試報告列表頁
(點擊放大圖像)
圖-28-郵件通知
API實戰：324個用例（包括GET|POST請求，參數有加密、依賴場景，返回結果有簡單驗證數據、錯誤碼驗證、schema驗證），運行耗時：8min，猜想下，如果人工去跑，需要多久呢？
提速：研發測試流程改進
(點擊放大圖像)
圖-29-使用HTTP API平臺改進API研發測試過程
-
改進前：傳統手工測試
測試用例掌握在測試人員手里，研發人員無法運行，修復bug之后，只能等待測試人員驗證，交付過程繁瑣、效率低；
-
改進后：HTTP API自動化測試
研發、測試協作同步，研發人員可以及早通過平臺執行用例，驗證功能可用性、正確性，測試人員可以釋放部分勞動力，重點關注業務數據正確性；修復bug之后，研發人員無需等待，可以自助配置用例執行、查看結果，驅動過程質量的提升，同時做到夜間構建、郵件通知，工作時間review、bug fix。
-
問題：何時收回投入成本？
API項目周期不超過半年的，不建議做自動化，有自動化平臺基礎的另當別論，因為在最初API測試用例編寫需要投入大量的時間；這種投入，只有不斷進行回歸驗證、多次運行，成本才可以回收，往后都是收益，這個道理淺顯易懂。
總結
“由于頻繁地重復，許多起初在我們看來重要的事情逐漸變得毫無價值”，在提測過程有個重要環節：冒煙測試，但是頻繁的去做的話，就是重復性的工作了。
那HTTP API接口測試痛點是什么？研發人員提測之后，需要等待測試人員進行驗證；測試人員發現bug，需要等待研發人員bug fix；這里就產生大量的等待成本（當然，測試人員可以切換到其他項目中去，但是這種上下文的切換成本很高）。通過HTTP API自動化測試平臺，研發人員在提測之前，首先進行一輪冒煙測試，根據自動化測試用例檢查結果，提升提測之前的功能質量；一旦提測之后，測試人員的關注重點落到返回結果對比上，這種研發測試過程的效率會得到很大的提升，或許有人要問，到底提升多少呢？這個每個團隊的痛點不同，研發、測試人員磨合程度不同，不能一概而論，大膽邁出一步去嘗試，就會發現價值；當然，往深處去想，下一步可以接入性能的自動化測試，喝杯咖啡的時間，等到自動化運行結果報告產出，是有可能的場景。
感謝魏星對本文的審校。
給InfoQ中文站投稿或者參與內容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博（@InfoQ，@丁曉昀），微信（微信號： InfoQChina ）關注我們。
來自： http://www.infoq.com/cn/articles/http-api-automated-test-from-manual-to-platform