公司計劃系統的開展接口自動化測試,須要我這邊調研一下主流的接口測試框架給後端測試(主要測試接口)的同事介紹一下每一個框架的特定和使用方式。後端同事根據他們接口的特色提出一下需求,看哪一個框架更適合咱們。html
一、接口編寫方便。
二、方便調試接口。
三、支持數據初始化。
四、生成測試報告。
五、支持參數化。python
優勢ios
關鍵字驅動,自定義用戶關鍵字。數據庫
支持測試日誌和報告生成。json
支持系統關鍵字開發,可擴展性好。後端
支持數據庫操做。api
缺點app
接口測試用例寫起來不簡潔。框架
須要掌握特定語法。dom
*** 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}
結果:不考慮,沒人願意這麼寫接口用例。
優勢
支持參數化
不須要寫代碼
缺點
建立接口用例效率不高。
不能生成查看每個接口執行狀況的測試報告。
總結:不考慮,接口編寫不方便,最主要是不能生成測試報告,若是作接口性能的話能夠考慮。
優勢:
基於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/
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
利用現有的框架和庫本身定製。
優勢:
缺點:
數據文件:
{ "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是我最熟悉的方案,幾乎沒什麼短板。之前經過這種方案寫過不少測試用例,此次把ddt加上彷佛更完美了。