主流介面測試框架對比
公司計劃系統的開展介面自動化測試，需要我這邊調研一下主流的介面測試框架給後端測試（主要測試介面）的同事介紹一下每個框架的特定和使用方式。後端同事根據他們介面的特點提出一下需求，看哪個框架更適合我們。
### 需求：
1、介面編寫方便。
2、方便除錯介面。
3、支援資料初始化。
4、生成測試報告。
5、支援引數化。
#### robot framework
優點
關鍵字驅動，自定義使用者關鍵字。
支援測試日誌和報告生成。
支援系統關鍵字開發，可擴充套件性好。
支援資料庫操作。
缺點
介面測試用例寫起來不簡潔。
需要掌握特定語法。
*** Settings *** Library RequestsLibrary Library Collections *** Test Cases *** test_get_event_list # 查詢釋出會（GET請求） ${payload}= Create Dictionary eid=1 Create Session event http://127.0.0.1:8000/api ${r}= Get Request event /get_event_list/ params=${payload} Should Be Equal As Strings ${r.status_code} 200 log ${r.json()} ${dict} Set variable ${r.json()} #斷言結果 ${msg} Get From Dictionary ${dict} message Should Be Equal ${msg} success ${sta} Get From Dictionary ${dict} status ${status} Evaluate int(200) Should Be Equal ${sta} ${status}
結果：不考慮，沒人願意這麼寫介面用例。
#### JMeter
優點
支援引數化
不需要寫程式碼
缺點
建立介面用例效率不高。
不能生成檢視每一個介面執行情況的測試報告。
總結：不考慮，介面編寫不方便，最主要是不能生成測試報告，如果做介面效能的話可以考慮。
####HttpRunner
優點:
基於YAML/JSON格式，專注於介面本身的編寫。
介面編寫簡單
生成測試報告
介面錄製功能。
缺點:
沒有編輯器外掛對語法校驗，容易出錯。
官方文件沒有詳細的說明。
擴充套件不方便。
[ { "config": { "name": "testcase description", "variables": [], "request": { "base_url": "http://127.0.0.1:5000", "headers": { "User-Agent": "python-requests/2.18.4" } } } }, { "test": { "name": "test case name", "request": { "url": "/api/get-token", "headers": { "device_sn": "FwgRiO7CNA50DSU", "user_agent": "iOS/10.3", "os_platform": "ios", "app_version": "2.8.6", "Content-Type": "application/json" }, "method": "POST", "date": {"sign": "958a05393efef0ac7c0fb80a7eac45e24fd40c27"} }, "validate": [ {"eq": ["status_code", 200]}, {"eq": ["headers.Content-Type", "application/json"]}, {"eq": ["content.success", true]}, {"eq": ["content.token", "baNLX1zhFYP11Seb"]} ] } }]
總結：可以考慮，至於介面資料的初始化可能需要單獨處理。
doc: https://cn.httprunner.org/quickstart/
####gauge
BDD行為驅動測試框架。
優點:
行為檔案與指令碼檔案分離，本質上實現了資料驅動。
功能強大靈活，本質上還用Python寫介面用例。
自動生成測試報告。
VS Code有支援外掛
缺點:
門檻略高，需要了解BDD的用法。
需要會markdworn語法
行為描述檔案：
## test post request * post "http://httpbin.org/post" interface |key | status_code| |------|-----------| |value1|200 | |value2|200 | |value3|200 |
測試指令碼：
……
@step("post <url> interface <table>")
def test_get_request(url, table):
values = []
status_codes = []
for word in table.get_column_values_with_name("key"):
values.append(word)
for word in table.get_column_values_with_name("status_code"):
status_codes.append(word)
for i in range(len(values)):
r = requests.post(url, data={"key": values[i]})
result = r.json()
assert r.status_code == int(status_codes[i])總結：推薦使用，BDD有一定門檻，看測試人員的學些能力和接受速度。
doc: https://docs.gauge.org/latest/writing-specifications.html#special-parameter-csv
#### Unittest+Request+HTMLRunner
利用現有的框架和庫自己定製。
優點:
- 足夠靈活強大: 分層測試、資料驅動、測試報告，整合CI...
缺點:
- 有一定的學習成本
資料檔案：
{
"test_case1": {
"key": "value1",
"status_code": 200
},
"test_case2": {
"key": "value2",
"status_code": 200
},
"test_case3": {
"key": "value3",
"status_code": 200
},
"test_case4": {
"key": "value4",
"status_code": 200
}}測試用例：
import requests
import unittest
from ddt import ddt, file_data
@ddtclass InterfaceTest(unittest.TestCase):
def setUp(self):
self.url = "http://httpbin.org/post"
def tearDown(self):
print(self.result)
@file_data("./data/test_data_dict.json")
def test_post_request(self, key, status_code):
r = requests.post(self.url, data={"key": key})
self.result = r.json()
self.assertEqual(r.status_code, status_code)總結：推薦使用，程式碼相對簡單，功能足夠靈活。
~~~~~~
我花了兩天時間整理這些框架，其實重點就是了解HttpRunner 和 gauge 。
yg
HttpRunner 沒有編輯器外掛，本身就是一個YAML/JSON配置檔案，所以配置寫錯了，但只要是合法的YAML/JSON格式，也看不出來，只有執行的過後才知道。就像你用記事本寫程式碼一樣，只有運行了才知道程式碼有沒有寫錯。
另外，擴充套件起來也不是特別方便，單獨用python實現一些函式：在json檔案中
{"device_sn": "${gen_random_string(15)}"}
以這樣的方式引用gen_random_string() 函式。
gauge我已經分享過兩篇基礎文章了，雖然用BDD拿來做介面理念不搭，但並不是不可以，唯一的缺點是用BDD來描述介面行為不合適，其他的都沒毛病，可以引數化，斷言寫起來也簡單，測試報告也漂亮，本質上還是用Python實現一些功能，所以非常靈活。
unittest + requests + HTMLTestRunner是我最熟悉的方案，幾乎沒什麼短板。以前通過這種方案寫過很多測試用例，這次把tdd加上似乎更完美了。