接口自動化之HttpRunner初探｜Python 主題月

本文正在參加「Python主題月」，詳情查看活動連接html

今天來介紹一個python的一個開源項目：httprunner，接口自動化工具。第一次輸入，不免有不周到的地方，輕噴~python

介紹：

HttpRunner是一個簡單優雅但功能強大的 HTTP(S) 測試框架。以YAML或JSON格式定義測試用例，保障測試用例描述的統一性和可維護性。程序執行的時候，會處理用戶輸入的yml/json文件並基於模板生成測試文件。最終經過pytest.main([])的方式去執行生成的用例文件。用戶只須要經過json/yml文件去維護用例便可，不須要關心程序如何處理json/yml文件，如何生成測試文件等，簡單快速經過pytest運行用例，並獲取詳細的測試報告。git

主要特徵：

以YAML或JSON格式定義測試用例，保障測試用例描述的統一性和可維護性
- testsuite > testcase > teststep(api)
- 支持設計一系列的測試場景，每一個測試場景可包含多個teststep。
- 支持參數化設計
- 支持variables/ extract/ validate/hooks機制（使用jmespath ，提取和驗證json響應）
- 支持添加邏輯運算輔助函數（debugtalk.py），在測試腳本中實現複雜的動態邏輯
在HAR 支持下記錄並生成測試用例。（使用charles去抓取請求，生成的用例文件可能還須要手動處理）
使用pytest執行測試文件，數百個插件隨時可用。使用allure ，測試報告能夠很是強大。
- run_testcase()：處理請求前的數據
- __run_step() > __run_step_request(使用requests發起api請求並導出其餘用例引用的變量(__step_datas))
經過重複使用locust ，您能夠進行性能測試，而無需進行額外的工做。
支持CLI命令，與CI/CD完美結合。

工做流程

想要了解其工做流程，最好的辦法就是使用debug模式，那在這裏應該如何使用debug來參透httprunner的執行流程呢？跟着我來看下:github

調試技巧

使用pycharm進行調試，且python環境使用Virtualenv進行管理shell

安裝：pip install httprunner
在/venv/bin/ 目錄下找到hrun文件

編輯hrun文件，爲sys.argv賦值。第一個是hrun的絕對路徑，第二個是用例的絕對路徑
在sys.exit(main_hrun_alias())這裏打個斷點，那麼就能夠開始愉快的調試之旅了~

# -*- coding: utf-8 -*-
import re
import sys
from httprunner.cli import main_hrun_alias
if __name__ == '__main__':
    sys.argv = ['/Users/boyizhang/PycharmProjects/apitest/venv/bin/hrun', '/Users/boyizhang/PycharmProjects/apitest/hruntests/testcases/testheader.yml']

    sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0])
    sys.exit(main_hrun_alias())

複製代碼

工做流

調試日誌：json

進入main_hrun_alias()中，併爲sys.argv的列表插入新的一項「run」(由於咱們是執行用例)

進入main()，由於咱們含有「run」，因此如今開始執行用例。

進入main_run(extra_args)，根據extra_args（yml/json路徑）將yml/json文件生成python文件（測試文件）

進入main_make()，判斷路徑是否存在

進入 __make() ，加載yml/json文件，並準備數據（按照數據的優先級進行復制，從低到高）

進入make_testcase()，將yml/json文件基於模板生成對應的py文件

最後回到main_run()方法，繼續執行main_make()如下的代碼，能夠發現，程序最終將建立的py文件交給pytest.main()來執行

上面演示了用例文件從yml/json到py文件的生成流程。接下來能夠對生成的py文件繼續調試。
這裏我作了一個比較簡單的演示，小夥伴們若是有興趣，能夠根據個人思路繼續你的調試之旅哦。

用例管理

關鍵概念：

歸納來講，測試用例分層機制的核心是將接口定義、測試步驟、測試用例、測試場景進行分離，單獨進行描述和維護，從而儘量地減小自動化測試用例的維護成本。api

測試用例（testcase）應該是完整且獨立的，每條測試用例應該是均可以獨立運行的
測試用例（測試場景）是測試步驟（teststep）的 **有序 **集合，每個測試步驟對應一個 API 的請求描述
測試用例集（testsuite）是測試用例的無序集合，集合中的測試用例應該都是相互獨立，不存在前後依賴關係的；若是確實存在前後依賴關係，那就須要在測試用例中完成依賴的處理
- 多個測試場景組成一個測試套件，運行一個測試套件，能夠同時執行多個測試場景。
接口定義（api definition）：爲了更好地對接口描述進行管理，使用獨立的文件對接口描述進行存儲，即每一個文件對應一個接口描述。

V2.0

建議你們用最新版本的，可是有興趣瞭解httprunner的架構變化的同窗，能夠繼續讀V2.0模塊的內容。數組

測試用例分層模型

V2.0的版本中，存在api definition的概念。bash

全部的api都置於api文件夾，每一個api建立一個yml/json文件進行管理
testcase中的teststep引用對應的api

優勢是：api管理方便；缺點是：在testcase中的teststep能夠直接引用api definition，無論testcase是單個步驟的簡單場景仍是多個步驟的複雜場景，都須要進行引用api definition。這樣的話，對於單個步驟的簡單場景而言，又和api definition很類似，這樣就會形成重複描述，並且容易混淆。 **markdown

那麼，咱們如何在testcase>teststep中引用api呢？如何引用testcase呢？ **

V2.0案例學習

在teststep中能夠經過api字段引用api definition 、經過testcase字段引用testcase。下面咱們根據腳手架快速建立一個項目httprunner --startproject hruntest2.0（須要確保安裝的是httpruner3.0如下的版本）來講明：

$ httprunner --startproject hruntest2.0 && tree hruntest2.0 
Start to create new project: hruntest2.0
CWD: /Users/boyizhang/PycharmProjects/apitest

created folder: hruntest2.0
created folder: hruntest2.0/api
created folder: hruntest2.0/testcases
created folder: hruntest2.0/testsuites
created folder: hruntest2.0/reports
created file: hruntest2.0/api/demo_api.yml
created file: hruntest2.0/testcases/demo_testcase.yml
created file: hruntest2.0/testsuites/demo_testsuite.yml
created file: hruntest2.0/debugtalk.py
created file: hruntest2.0/.env
created file: hruntest2.0/.gitignore

hruntest2.0
├── api
│   └── demo_api.yml
├── debugtalk.py
├── reports
├── testcases
│   └── demo_testcase.yml
└── testsuites
    └── demo_testsuite.yml
複製代碼

api definition

# api/demo_api.yml
name: demo api
variables:
    var1: value1
    var2: value2
request:
    url: /api/path/$var1
    method: POST
    headers:
        Content-Type: "application/json"
    json:
        key: $var2
validate:
    - eq: ["status_code", 200]

複製代碼

testcase

config:
    name: "demo testcase"
    variables:
        device_sn: "ABC"
        username: ${ENV(USERNAME)}
        password: ${ENV(PASSWORD)}
    base_url: "http://127.0.0.1:5000"

teststeps:
-
    name: demo step 1
    api: path/to/api1.yml
    variables:
        user_agent: 'iOS/10.3'
        device_sn: $device_sn
    extract:
        - token: content.token
    validate:
        - eq: ["status_code", 200]
複製代碼

在teststep中使用api選項來引用api definition，執行testcase/demo_testcase.yml用例文件。（注：api definition不屬於testcase範疇，沒法直接執行api/下的yml/json文件）。在teststep中傳的字段的優先級會比api definition下的高，也就是說，若是teststep傳某個字段，那麼會有限使用teststep傳的那個，若是沒有，則再使用api definition的字段。

V3.0

爲了簡單，在HttpRunner v2.x中的API概念已經被取消了。能夠將API定義爲只有一個請求步驟的測試用例**（須要重點注意一下這裏）**。

測試用例分層模型

去掉api的概念，把api的概念轉爲測試用例的概念。將API定義爲只有一個請求步驟的測試用例。以統一的概念：測試用例，使得維護用例的工做更加方便。
按照V2.0的邏輯，須要維護api definition，也須要維護只有一個測試步驟的testcase，而V3.0中，咱們只須要維護testcase便可。v2->v3的轉變，使得能夠在避免重複描述的同時，解決測試用例的依賴關係，從而保證每一個測試用例都是獨立可運行的。

那麼，問題來了，咱們應該如何在某個testcase的teststep中引用其餘testcase呢？

v3.0案例學習

在測試步驟（teststep）中，可經過 testcase 字段引用其它測試用例，引用方式爲對應測試用例文件的路徑，絕對路徑或相對路徑都可。推薦使用相對路徑，路徑基準爲項目根目錄，即 debugtalk.py 所在的目錄路徑。

**經過 **httprunner startproject hruntest3.0 快速建立項目。

$ tree hruntest3.0 
hruntest3.0
├── debugtalk.py
├── har
├── reports
└── testcases
    ├── demo_testcase_ref.yml
    └── demo_testcase_request.yml
複製代碼

# demo_testcase_request.yml
config:
    name: "request methods testcase with functions"
    variables:
        foo1: config_bar1
        foo2: config_bar2
        expect_foo1: config_bar1
        expect_foo2: config_bar2
    base_url: "https://postman-echo.com"
    verify: False
    export: ["foo3"]

teststeps:
-
    name: post form data
    variables:
        foo2: bar23
    request:
        method: POST
        url: /post
        headers:
            User-Agent: HttpRunner/${get_httprunner_version()}
            Content-Type: "application/x-www-form-urlencoded"
        data: "foo1=$foo1&foo2=$foo2&foo3=$foo3"
    validate:
        - eq: ["status_code", 200]
        - eq: ["body.form.foo1", "$expect_foo1"]
        - eq: ["body.form.foo2", "bar23"]
        - eq: ["body.form.foo3", "bar21"]

複製代碼

# demo_testcase_ref.yml 
config:
    name: "request methods testcase: reference testcase"
    variables:
        foo1: testsuite_config_bar1
        expect_foo1: testsuite_config_bar1
        expect_foo2: config_bar2
    base_url: "https://postman-echo.com"
    verify: False

teststeps:
-
    name: request with functions
    variables:
        foo1: testcase_ref_bar1
        expect_foo1: testcase_ref_bar1
    testcase: testcases/demo_testcase_request.yml
    export:
        - foo3
-
    name: post form data
    variables:
        foo1: bar1
    request:
        method: POST
        url: /post
        headers:
            User-Agent: HttpRunner/${get_httprunner_version()}
            Content-Type: "application/x-www-form-urlencoded"
        data: "foo1=$foo1&foo2=$foo3"
    validate:
        - eq: ["status_code", 200]
        - eq: ["body.form.foo1", "bar1"]
        - eq: ["body.form.foo2", "bar21"]

複製代碼

在teststep中使用testcase字段來引用，執行demo_testcase_ref.yml用例文件，當執行到name = request with functions這個步驟的時候會先執行其引用的testcase：testcases/demo_testcase_request.yml。在根目錄下，執行hrun testcases/demo_testcase_ref.yml，能夠看到，程序也生成了該case：testcases/demo_testcase_request.yml的測試文件：

hook機制

涉及hook處理

背景

在自動化測試中，執行用例前，須要執行一些預處理操做，執行用例後，須要作一些清理工做。若是手動去操做的話，就不是很合適。因此就須要用到hook機制，在執行用例先後執行hook函數。

使用

hook 機制分爲兩個層級：

測試用例層面（testcase）
- 在測試用例層面，主要在config字段新增兩個關鍵字 setup_hooks 和 teardown_hooks。在這裏，其主要目的就是用於測試前的準備工做以及測試後的清理工做。
測試步驟層面（teststep）
- 在每一個teststep中新增關鍵字 setup_hooks 和 teardown_hooks。實現對請求的 request 內容進行預處理以及實現對響應的 response 進行修改。

編寫hook函數

hook 函數的定義放置在項目的 debugtalk.py 中，在 YAML/JSON 中調用 hook 函數仍然是採用 ${func($ a, $b)} 的形式。
可傳自定義參數：對於測試用例層面的 hook 函數，與 YAML/JSON 中自定義的函數徹底相同，可經過自定義參數傳參的形式來實現靈活應用。
可傳request與response參數：對於單個測試用例層面的 hook 函數，除了可傳入自定義參數外，還能夠傳入與當前測試用例相關的信息，包括請求的 $request（請求頭，請求體，請求方法等）和響應的$ response（對於requests.Response，也就是響應體），用於實現更復雜場景的靈活應用。如${print_req(``$request``)} 。

# ${print_request($request)}
2021-07-18 09:30:46.740 | DEBUG    | httprunner.runner:__call_hooks:121 - call hook function: ${print_reqeust($request)}
{'method': 'GET', 'url': '/get', 'params': {'foo1': 'bar11', 'foo2': 'bar21', 'sum_v': 3}, 'headers': {'User-Agent': 'HttpRunner/3.1.5', 'HRUN-Request-ID': 'HRUN-7768261f-0abf-4ce5-abf2-06327de85fd7-846739'}, 'req_json': None, 'data': None, 'cookies': {}, 'timeout': 120, 'allow_redirects': True, 'verify': False}
# ${print_req($response)}
2021-07-18 09:36:03.019 | DEBUG    | httprunner.runner:__call_hooks:121 - call hook function: ${print_req($response)}
<httprunner.response.ResponseObject object at 0x109c87e50>
複製代碼

環境（.env）

涉及env的處理，文檔

# parser.py
def get_mapping_function( function_name: Text, functions_mapping: FunctionsMapping ) -> Callable:
    #省略
    if function_name in functions_mapping:
        return functions_mapping[function_name]

    elif function_name in ["environ", "ENV"]:
        return utils.get_os_environ
	#省略
    raise exceptions.FunctionNotFound(f"{function_name} is not found.")

# utils.py

def set_os_environ(variables_mapping):
    """ set variables mapping to os.environ """
    for variable in variables_mapping:
        os.environ[variable] = variables_mapping[variable]
        logger.debug(f"Set OS environment variable: {variable}")
        
def get_os_environ(variable_name):
    try:
        return os.environ[variable_name]
    except KeyError:
        raise exceptions.EnvNotFound(variable_name)
複製代碼

加載用例以前，會先把.env文件中的變化加載到環境中，若是用例用含有ENV或者environ，則經過os.environ去讀取相應的值。

參數化：

實現

HttpRunner 實現參數化數據驅動機制：debugtalk.com/post/httpru… HttpRunner 再議參數化數據驅動機制：debugtalk.com/post/httpru…

使用

須要注意的是，從v2.0開始，參數化只支持在 testsuite 中實現。再也不支持在測試用例文件中進行參數化配置。

參數配置概述

獨立參數：指的是不與其餘參數有任何關聯關係，與其餘參數是相互獨立的。
關聯參數：假如測試用例中定義了多個參數，那麼測試用例在運行時會對參數進行笛卡爾積組合，覆蓋全部參數組合狀況。

具體使用 v2.httprunner.org/prepare/par…

extract/export

底層使用jmespath ，提取和驗證json響應，使得提取更簡單。 extract用來抓取響應體中的字段，export導出當前用例抓取的字段，供引用該用例的用例使用。

測試報告

pytest內置報告
- hrun /path/to/testcase --html=report.html
allure報告
- pip install allure-pytest
- 執行：hrun /path/to/testcase --alluredir=/tmp/my_allure_results
- 在線打開報告：allure serve /tmp/my_allure_results 或者生成html報告：allure generate reports/allure -o reports/allure/html

總結

好好利用httprunner，能夠覆蓋80%的場景，能夠說是一個不錯的工具，固然咱們除了學習應該如何使用以外，更應該學習人家設計的思想，這樣本身以後纔能有機會作好一點的工具。另外推薦一個Java版本的接口自動化工具你們能夠參考rest-assured。httprunner與rest-assured實現方式大同小異，不過rest-assured並無經過json/yaml去管理用例，而是直接寫測試文件（相似httprunner生成的py文件）。你們能夠對比學習下~。

接口自動化之HttpRunner初探 ｜Python 主題月

介紹：

主要特徵：

工做流程

調試技巧

工做流

用例管理

關鍵概念：

V2.0

測試用例分層模型

V2.0案例學習

V3.0

測試用例分層模型

v3.0案例學習

hook機制

背景

使用

環境（.env）

參數化：

實現

使用

extract/export

測試報告

總結

接口自動化之HttpRunner初探｜Python 主題月