主流接口測試框架對比

公司計劃系統的開展接口自動化測試,須要我這邊調研一下主流的接口測試框架給後端測試(主要測試接口)的同事介紹一下每一個框架的特定和使用方式。後端同事根據他們接口的特色提出一下需求,看哪一個框架更適合咱們。html

### 需求:

一、接口編寫方便。
二、方便調試接口。
三、支持數據初始化。
四、生成測試報告。
五、支持參數化。python


#### robot framework

優勢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}

結果:不考慮,沒人願意這麼寫接口用例。


#### 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是我最熟悉的方案,幾乎沒什麼短板。之前經過這種方案寫過不少測試用例,此次把ddt加上彷佛更完美了。

相關文章
相關標籤/搜索