主流介面測試框架對比

公司計畫系統的開展介面自動化測試，需要我這邊調研一下主流的介面測試框架給後端測試（主要測試介面）的同事介紹一下每個框架的特定和使用方式。後端同事根據他們介面的特點提出一下需求，看哪個框架更適合我們。

1、介面編寫方便。

2、方便除錯介面。

3、支援資料初始化。

4、生成測試報告。

5、支援引數化。

優點

缺點

*** settings *** library requestslibrary library collections *** test cases *** test_get_event_list # 查詢發布會（get請求） $= create dictionary eid=1 create session event $= get request event /get_event_list/ params=$ should be equal as strings $ 200 log $ $ set variable $ #斷言結果 $ get from dictionary $ message should be equal $ success $ get from dictionary $ status $ evaluate int(200) should be equal $ $

結果：不考慮，沒人願意這麼寫介面用例。

優點

缺點

總結：不考慮，介面編寫不方便，最主要是不能生成測試報告，如果做介面效能的話可以考慮。

優點:

缺點:

[}}
},,        "method": "post",
"date": 
},"validate": [,,
]}}]

總結：可以考慮，至於介面資料的初始化可能需要單獨處理。

doc:

bdd行為驅動測試框架。

優點:

缺點:

行為描述檔案：

## test post request
* post "" inte***ce     
|key  | status_code|     
|------|-----------|     
|value1|200        |     
|value2|200        |     
|value3|200        |

測試指令碼：

……
@step("post inte***ce ")
def test_get_request(url, table):
values = 
status_codes = 
for word in table.get_column_values_with_name("key"):
for word in table.get_column_values_with_name("status_code"):
for i in range(len(values)):
r = requests.post(url, data=)
result = r.json()
assert r.status_code == int(status_codes[i])

總結：推薦使用，bdd有一定門檻，看測試人員的學些能力和接受速度。

doc:

利用現有的框架和庫自己定製。

優點:

缺點:

資料檔案：

, "test_case2": , "test_case3": , "test_case4": }

測試用例：

import requests
import unittest
from ddt import ddt, file_data
@ddtclass inte***cetest(unittest.testcase):
def setup(self):
self.url = ""
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=)
self.result = r.json()
self.assertequal(r.status_code, status_code)

總結：推薦使用，**相對簡單，功能足夠靈活。

我花了兩天時間整理這些框架，其實重點就是了解httprunner 和 gauge 。

yghttprunner 沒有編輯器外掛程式，本身就是乙個yaml/json配置檔案，所以配置寫錯了，但只要是合法的yaml/json格式，也看不出來，只有執行的過後才知道。就像你用記事本寫**一樣，只有執行了才知道**有沒有寫錯。

另外，擴充套件起來也不是特別方便，單獨用python實現一些函式：在json檔案中

"}

以這樣的方式引用gen_random_string()函式。

gauge我已經分享過兩篇基礎文章了，雖然用bdd拿來做介面理念不搭，但並不是不可以，唯一的缺點是用bdd來描述介面行為不合適，其他的都沒毛病，可以引數化，斷言寫起來也簡單，測試報告也漂亮，本質上還是用python實現一些功能，所以非常靈活。

unittest + requests + htmltestrunner是我最熟悉的方案，幾乎沒什麼短板。以前通過這種方案寫過很多測試用例，這次把tdd加上似乎更完美了。

主流介面測試框架對比

主流php框架對比

對比主流深度學習框架

android測試框架對比

主流介面測試框架對比

主流php框架對比

對比主流深度學習框架

android測試框架對比

相關推薦