主流介面測試框架對比
公司計劃系統的開展介面自動化測試,需要我這邊調研一下主流的介面測試框架給後端測試(主要測試介面)的同事介紹一下每個框架的特定和使用方式。後端同事根據他們介面的特點提出一下需求,看哪個框架更適合我們。
### 需求:
1、介面編寫方便。
2、方便除錯介面。
3、支援資料初始化。
4、生成測試報告。
5、支援引數化。
#### robot framework
優點
-
關鍵字驅動,自定義使用者關鍵字。
-
支援測試日誌和報告生成。
-
支援系統關鍵字開發,可擴充套件性好。
-
支援資料庫操作。
缺點
-
介面測試用例寫起來不簡潔。
-
需要掌握特定語法。
*** Settings *** LibraryRequestsLibrary LibraryCollections *** Test Cases *** test_get_event_list# 查詢釋出會(GET請求) ${payload}=Create Dictionaryeid=1 Create Sessioneventhttp://127.0.0.1:8000/api ${r}=Get Requestevent/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}Evaluateint(200) Should Be Equal${sta}${status}
結果:不考慮,沒人願意這麼寫介面用例。
#### JMeter
優點
-
支援引數化
-
不需要寫程式碼
缺點
-
建立介面用例效率不高。
-
不能生成檢視每一個介面執行情況的測試報告。
總結:不考慮,介面編寫不方便,最主要是不能生成測試報告,如果做介面效能的話可以考慮。
####HttpRunner
優點:
缺點:
-
沒有編輯器外掛對語法校驗,容易出錯。
-
官方文件沒有詳細的說明。
-
擴充套件不方便。
[ { "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行為驅動測試框架。
優點:
缺點:
-
門檻略高,需要了解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加上似乎更完美了。