接口自动化之HttpRunner初探 ｜Python 主题月

本文正在参加「Python主题月」，详情查看 活动连接

今天来介绍一个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 实现参数化数据驱动机制：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文件）。你们能够对比学习下~。