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

時間 2019-11-12

原文原文鏈接

無論是 Web 系統，仍是移動 APP，先後端邏輯的分離設計已是常態化，相互之間經過 API 調用進行數據交互。在基於 API 約定的開發模式下，如何加速請求 / 響應的 API 測試，讓研發人員及早參與到調試中來呢？既然 API 是基於約定開發，爲什麼不按照這個規範編寫測試用例，直接進入待測試狀態，使用自動化的方式來推動研發過程的質量改進呢？遵循：測試 -> 重構 -> 測試 -> 重構，這樣的閉環，過程產出的質量會更加可控，在重構的同時進行快速的功能迴歸驗證，大大提升效率。下面主要講解基於 HTTP 協議的 API 測試，從手工測試到平臺的演變過程。html

手工測試帶來的困惑

測試團隊採用《敏捷腦圖用例實踐之路》的方式編寫測試用例：前端

圖 -1- 分計費單元查詢帶寬面試

優勢：算法

要點清晰簡潔展示chrome
全部測試故事點通過用例評審，產生質量高，研發參與感強；json
版本同步保持一份後端

API 測試腦圖帶來的問題：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: []                         # 錯誤信息集合&lt;/pre&gt;

測試報告：

圖 -6-rf 測試報告

按照這個思路作下來，獲得什麼收益呢？

自動化

說到這裏，其實，真沒有帶來多少收益，思路對了，可是方向有誤差了，主要體如今：

使用了笛卡爾乘積來生成不一樣參數的測試用例，發現一堆的測試用例生成文件是 M 的單位，並且也給測試服務器帶來性能問題，數量 4980 箇中佔 95% 的用例都是沒有實際意義的，對服務器頻繁請求形成壓力；

圖 -7- 龐大的測試用例文件

經過 WEB 配置將 YAML 文件轉爲 robot 能夠識別的，這種作法坑太深、維護難，參數越多，文件越臃腫，可讀性差；
後來嘗試將笛卡爾乘積換成全對偶組合算法，效果改進顯著，無效用例數明顯降低，有效用例數顯著提高；

敗了，就是敗了，沒什麼好找藉口，關鍵問題是：

有效的測試用例佔比例很低，無效的佔了大部分；
沒有化繁爲簡，前端隱藏了配置，複雜的配置仍是須要在後端處理；
沒有實際測試參與動腦過程，測試人員不會窮舉，會根據業務編寫實際用例；
平臺易用性很重要：須要測試人員直接在上面編寫，合理的邏輯步驟，有利於引導測試參與；

重構：發現測試的價值

回到起點，測試要解決什麼問題，爲何要作 API 自動化測試平臺？作這個平臺，不是爲了知足老闆的提倡全民自動化的口號，也不是爲了浮誇的 KPI，更不是宣傳自動化能夠解決一切問題，發現全部 bug。叔本華說過一句話：因爲頻繁地重複，許多起初在咱們看來重要的事情逐漸變得毫無價值。若是 API 測試僅僅依靠純手工的執行，很快將會面臨瓶頸，由於每個功能幾乎都不能是第一次提交測試後就測試經過的，因此就須要反覆 bug 修復、驗證，以及迴歸的過程。另外，不少的 API 測試工做手工作起來很是的繁瑣，甚至不便，好比針對接口協議的驗證、針對返回數據格式的驗證，這些都依賴於測試自動化的開展。所以，真正的目的是解放測試人員重複的手工生產力，加速回歸測試效率，同時讓研發人員在開發過程及早參與測試（自測、冒煙測試），驅動編碼質量的提高。

回顧以往，從新梳理頭緒，更加清晰的展示：

圖 -8-HTTP API 自動化測試圖解

HTTP API 傳統手工測試
重複請求參數基礎校驗、正確參數查詢返回數據校驗，測試工程師沒有新的創造價值，不斷重複工做，甚至可能壓縮其中的測試環節，勉強交付；
HTTP API 自動化測試
重複步驟（請求接口是否有效、參數校驗能夠做爲冒煙測試，研發參與自測）用自動化解決，關鍵業務步驟數據對比人工參與和 schema 自動化校驗；

若是對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣能夠175317069，羣內會有不按期的發放免費的資料連接，這些資料都是從各個技術網站蒐集、整理出來的，若是你有好的學習資料能夠私聊發我，我會註明出處以後分享給你們。

最大的收益，重複步驟自動化後，無論是研發人員自測，仍是執行功能迴歸測試，成本能夠很快收回（前提是你這個項目週期長，構建頻繁；若是僅僅是跑幾個月的項目，真沒那個必要湊熱鬧去自動化，固然有平臺的另當別論），測試的關注點會落實到更加關鍵的業務環節去；

整體規劃以下：

[

圖 -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")}}&lt;/pre&gt;

圖 -15- 接口配置頁

驗證器

√ 設計思路

驗證器是一個 Python 函數，若是函數返回 True，則測試經過；返回 False，則測試失敗。平臺默認提供一個默認驗證器。

默認驗證器是驗證指望結果與實際結果（response body）是否徹底一致。若是結果不一致則判斷爲失敗，默認驗證器只適用於靜態的響應結果對比。

自義定驗證器，若是默認驗證器不能知足某些特殊的測試需求，用戶能夠在「項目配置 - 驗證器」中添加自定義的驗證器。

√ 應用場景：在 API 測試的返回結果中，能夠添加自定義驗證器對數據進行校驗，判斷測試是否經過。

圖 -17- 測試用例驗證展現頁

API 配置

重點介紹：通用響應配置、API 依賴庫、API 用例庫、定時任務、測試報告

通用響應配置

圖 -18- 通用響應配置列表頁

√ 設計思路

在合理的 API 設計中，存在通用的錯誤響應碼，[用戶名錯誤，返回指望響應內容]，若是全部 API 的響應結果中都須要重複寫是至關繁瑣的，做爲共同配置調用便可。

√ 應用場景

查詢接口遇到用戶名密碼爲空，能夠自定義寫返回內容，以及選擇 [通用響應配置] 下的相關錯誤類型，例如：用戶名密碼爲空 (計費單元)，自動填充指望的返回值：

&lt;BillingIDs&gt;
      &lt;Result&gt;fail&lt;/Result&gt;
      &lt;DetailInfo&gt;invalid userName or password&lt;/DetailInfo&gt;
    &lt;/BillingIDs&gt;

圖 -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": [                  若是對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、
                    ""                     面試經驗交流。感興趣能夠175317069，羣內會有不按期的發放免費
                ],                         的資料連接，這些資料都是從各個技術網站蒐集、整理出來的，若是
                "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"
                }
            }
        }

定時任務

√ 設計思路 & 應用場景

定時任務是在計劃好的時間點自動執行指定的測試用例。一個項目支持多個定時任務，若是同一時間點有多個測試任務，將依次執行。定時任務有兩種類型：定時、循環（間隔：秒，

分鐘，小時，天，周）。經過定時任務，能夠作到晚上運行，早上查看結果報告分析。

圖 -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 自動化測試平臺，研發人員在提測以前，首先進行一輪冒煙測試，根據自動化測試用例檢查結果，提高提測以前的功能質量；一旦提測以後，測試人員的關注重點落到返回結果對比上，這種研發測試過程的效率會獲得很大的提高，或許有人要問，到底提高多少呢？這個每一個團隊的痛點不一樣，研發、測試人員磨合程度不一樣，不能一律而論，大膽邁出一步去嘗試，就會發現價值；固然，往深處去想，下一步能夠接入性能的自動化測試，喝杯咖啡的時間，等到自動化運行結果報告產出，是有可能的場景。

原文連接：http://www.javashuo.com/article/p-wmiidaat-eq.html