接口自動化測試之httprunner初探

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

介紹：

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

主要特征：

• 以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的執行流程呢？跟着我來看下:

調試技巧

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

• 安裝：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())

工作流

調試日志：

• 進入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文件繼續調試。
• 這里我做了一個比較簡單的演示，小伙伴們如果有興趣，可以根據我的思路繼續你的調試之旅哦。

用例管理

關鍵概念：

概括來說，測試用例分層機制的核心是將接口定義、測試步驟、測試用例、測試場景進行分離，單獨進行描述和維護，從而盡可能地減少自動化測試用例的維護成本。

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

V2.0

建議大家用最新版本的，但是有興趣了解httprunner的架構變化的同學，可以繼續讀V2.0模塊的內容。

測試用例分層模型

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

• 所有的api都置於api文件夾，每個api創建一個yml/json文件進行管理
• testcase中的teststep引用對應的api

優點是：api管理方便；缺點是：在testcase中的teststep可以直接引用api definition，不管testcase是單個步驟的簡單場景還是多個步驟的復雜場景，都需要進行引用api definition。這樣的話，對於單個步驟的簡單場景而言，又和api definition很相似，這樣就會造成重復描述，而且容易混淆。
**

那么，我們如何在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 實現參數化數據驅動機制：https://debugtalk.com/post/httprunner-data-driven/
HttpRunner 再議參數化數據驅動機制：https://debugtalk.com/post/httprunner-data-driven-refactor/

使用

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

參數配置概述

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

具體使用
https://v2.httprunner.org/prepare/parameters/

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文件）。大家可以對比學習下~。