HttpRunner4.x 安装与使用
HttpRunner4.x 安装与使用
以下只介绍Windows下 python 方式安装和使用 HttpRunner ，Linux下安装方式官方文档也写得很明确，只需执行一条 shell 命令，即可完成 hrp 的下载和安装操作。
$ bash -c "$(curl -ksSL https://httprunner.com/script/install.sh)"
安装
HttpRunner 存储于 PyPI, 支持通过pip命令安装，推荐安装到虚拟环境下，这样的话不同的虚拟环境可以使用不同版本的 HttpRunner，有人喜欢用 HttpRunner3.x版本的内容，有人喜欢最新版本的内容，
pip3 install httprunner （默认安装最新版本）
pip3 install httprunner==4.2.0 （安装指定的HttpRunner4.x版本）
查看 HttpRunner 版本：httprunner -V 或 hrun -V
查看可以使用的功能选项：httprunner -h
安装HttpRunner4.x后，还不能使用 hrp 命令行工具，这一步需要手动配置，需要下载编译产物，在 GitHub Releases 页面中，自行选择版本进行下载
在 C 盘根目录下创建 HttpRunner 目录（自定义目录），将下载的压缩包解压之后的hrp.exe 文件放在该目录下
在「我的电脑=>属性=>高级系统设置=>环境变量」配置中，在 PATH 下新增系统变量，将 C:\\HttpRunner 写入 PATH
启动虚拟环境，执行命令hrp -v，若显示hrp版本号，则说明配置成功
使用
运行脚手架项目
使用命令hrp startproject demo新增一个Httprunner项目，命名为demo
demo
├── .env 环境配置文件，存储项目环境变量，通常用于存储项目敏感信息
├── .gitignore 上传git忽略文件
├── debugtalk.py 自定义函数辅助实现业务逻辑测试py文件
├── har har文件目录
│ └── .keep
├── reports 报告文件目录
│ └── .keep
└── testcases 测试用例文件目录
├── demo_ref_testcase.yml 测试用例模板文件
├── demo_requests.yml 测试用例模板文件
└── demo_with_funplugin.json 测试用例模板文件
脚手架项目有几个有效的测试用例，可以无需编辑直接执行命令hrp run demo运行，若命令运行成功，则说明Python版本及Httprunner依赖包没有冲突，可正常使用。若产生报错情况，则需要根据报错信息更新依赖包或下载更新的Python版本
方式一：录制生成用例
步骤1：导出har文件
通过fiddler/Charles等抓包工具进行抓包，生成har文件
fiddler点击File > Export Sessions > Selected Sessions > ，选择httparchive v1.2格式，导出文件到项目目录的har目录下
步骤2：转化成测试用例文件
HttpRunner4.x将所有的转换功能都集中在 hrp convert 一个指令中。通过执行 hrp convert -h 可以查询该指令的功能简介、用法和各个选项的介绍：
$ hrp convert -h
convert to JSON/YAML/gotest/pytest testcases
Usage:
hrp convert $path... [flags]
Flags:
-h, --help help for convert
-d, --output-dir string specify output directory, default to the same dir with har file
-p, --profile string specify profile path to override headers (except for auto-generated headers) and cookies
--to-gotest convert to gotest scripts (TODO)
--to-json convert to JSON scripts (default true)
--to-pytest convert to pytest scripts
--to-yaml convert to YAML scripts
Global Flags:
--log-json set log to json format
-l, --log-level string set log level (default "INFO")
除了转换成JSON/YAML/pytest 类型的文件，HttpRunner4.x还支持将 HAR 包转换为gotest测试用例（gotest测试用例不进行说明）
hrp convert xxx.har 将HAR文件默认转换成转换成Json文件 文件名为xxx_test.json
hrp convert xxx.har --to-yaml 将HAR文件转换成YAML文件 文件名为xxx_test.yaml
hrp convert xxx.har --to-json 将HAR文件转换成Json文件 文件名为xxx_test.json
hrp convert xxx.har --to-pytest 将HAR文件转换成pytest文件
hrp convert xxx.har --to-gotest 将HAR文件转换成gotest文件
执行hrp convert xxx.har --to-pytest命令，会先将 xxx.har转化成xxx_test.json，然后再将xxx_test.json转化成xxx_test_test.py
hrp convert 指令支持指定目录输出，--output-dir 后接测试用例的期望输出目录的路径，用于将转换生成的测试用例输出到对应的文件夹
hrp convert xxx.har --to-pytest --output-dir ./cases 输入文件到当前目录下的cases文件夹中
步骤3：执行测试用例
JSON/YAML(/pytes)类型的测试用例文件，HttpRunner3.x 使用hrun命令执行，HttpRunner4.x 使用hrp run命令执行
hrun xxx.json 执行json格式的测试用例
hrun xxx.yaml 执行yaml格式的测试用例
hrp run xxx.json 执行json格式的测试用例
hrp run xxx.yaml 执行yaml格式的测试用例
hrp run cases/ 执行cases文件夹下的测试用例
HttpRunner4.x 也可以使用hrun命令执行测试用例文件，但hrp run命令控制台打印日志会更加详细，同时，hrp run命令还支持执行文件夹中的测试用例
pytest文件可通过pytest命令执行该测试用例文件
pytest xxx.py
目前的 HttpRunner 支持运行 pytest 的测试用例进行接口测试。由于 HttpRunner wraps pytest，因此 pytest 所有的参数都可以与 hrp 命令一起使用
$ hrp pytest [options] [file_or_dir] [file_or_dir] [...]
hrp pytest testcases/py_test.py --html=/report/index.html --junit-xml=/report/report.xml
执行testcases文件夹下的py_test.py测试用例文件，并输入html和xml格式的测试报告
方式二：手工编写测试用例
pytest 、 YAML 和 JSON 格式的测试用例完全等价，包含的信息内容也完全相同。
在httprunner中，测试用例组织主要基于三个概念：
- 测试用例集(testsuite)：对应一个YAML/JSON/Python文件，包含单个或多个测试用例文件。通俗来将，测试用例集就是「一堆」测试用例。对应地，HttpRunner 除了支持指定单个文件来运行某一测试用例，也支持指定多个文件或指定文件夹来运行一整个测试用例集
- 测试用例(testcase)：对应一个YAML/JSON/Python文件，包含单个或多个测试步骤。
- 测试步骤(teststep)：对应YAML/JSON/Python中 teststeps 下的一个节点，描述单次接口测试的全部内容，包括发起接口请求、解析响应结果、检验结果等。
pytest 、 YAML 和 JSON 格式的测试用例，用例结构整体结构都包含两部分：
- config：每个测试用例都必须有config部分，作为整个测试用例的全局配置项，用于配置用例
- teststeps：包含测试步骤相关信息，测试用例存在顺序关系，运行时将从前往后依次运行各个测试步骤，其中步骤可以引用其他测试用例
| 用例配置项（config）名称 | 含义 |
|---|---|
| name（必填） | 用例名称描述，将在log和报告中展示 |
| verify（非必填） | 客户端是否进行 SSL 校验（todo） |
| base_url（非必填） | 测试用例中的通用Host，例如https://httprunner.com，若base_url被指定，测试步骤中的url只能写相对路径 |
| headers（非必填） | 定义测试用例级别的请求头 |
| environs（非必填） | 配置环境变量（如果未指定则会从 .env 文件导入） |
| variables（非必填） | 定义的全局变量，作用域为整个用例，每个测试步骤都可以引用config variables。测试步骤中的 step variables 优先级高于 config variables |
| parameters（非必填） | 全局参数，用于实现数据化驱动，作用域为整个用例 |
| parameters_setting（非必填） | 配置参数驱动的具体策略 |
| think_time（非必填） | 配置思考时间的具体策略、超时时间限制等 |
| websocket（非必填） | 配置 WebSocket 断开重连的最大次数和间隔等（todo） |
| export（非必填） | 导出当前测试用例中的变量 |
| weight（非必填） | 性能测试过程中，分配给当前测试用例的虚拟用户权重 |
| path（非必填） | 当前测试用例所在路径（通常不需要手工填写） |
| 测试步骤类型 | 含义 | 适用的测试步骤 |
|---|---|---|
| name（必填） | 用例步骤描述，将在log和报告中展示 | |
| request（必填） | 用于发起 HTTP 请求的步骤类型，包含method、url、params、headers、cookies等请求信息（method和url必填） | |
| api（非必填） | 用于引用 API 的步骤类型 | |
| testcase（非必填） | 用于引用其他测试用例的步骤类型 | |
| transaction（非必填） | 用于定义一个事务 | |
| rendezvous（非必填） | 集合点 | |
| think_time（非必填） | 思考时间 | |
| websocket（非必填） | 用于发起 WebSocket 请求的步骤类型 | |
| variables（非必填） | 局部变量 | 通用 |
| setup_hooks（非必填） | 前置函数 | request/api/websocket |
| teardown_hooks（非必填） | 后置函数 | request/api/websocket |
| extract（非必填） | 变量提取。参数提取格式， 变量名: body.属性名，指从响应体body里提取属性的值 | request/api/websocket |
| validate（非必填） | 结果校验 | request/api/websocket |
| export（非必填） | 导出变量 | testcase |
test.yaml
config:
name: classinfo
variables: {}
verify: false
teststeps:
- name: "getclass"
request:
method: GET
url: http://127.0.0.1:8080/api/mgr/sq_mgr/
params:
action: list_course
pagenum: "1"
pagesize: "20"
headers:
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Connection: keep-alive
Host: 127.0.0.1:8080
Referer: http://127.0.0.1:8080/mgr/ps/mgr/index.html
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.0.0 Safari/537.36
X-CSRFToken: ABjPB9CYXuc0dPy8Wu2hJppDVu1sdhWRrfoWPBM7DimSrMtkHVUAoNAXeWqOIh0d
cookies:
csrftoken: ABjPB9CYXuc0dPy8Wu2hJppDVu1sdhWRrfoWPBM7DimSrMtkHVUAoNAXeWqOIh0d
sessionid: b1g42w3ynatxpphy0fhahpdi7g4pn2vg
extract:
msg: body.msg
cookie: header.Set-Cookie
validate:
- check: status_code
assert: equals
expect: 200
msg: assert response status code
- eq: ["body.msg","成功"]
test.json
{
"config": {
"name": "classinfo"
},
"teststeps": [
{
"name": "getclass",
"request": {
"method": "GET",
"url": "http://127.0.0.1:8080/api/mgr/sq_mgr/",
"params": {
"action": "list_course",
"pagenum": "1",
"pagesize": "20"
},
"headers": {
"Accept": "application/json, text/plain, */*",
"Accept-Encoding": "gzip, deflate, br",
"Accept-Language": "zh-CN,zh;q=0.9",
"Connection": "keep-alive",
"Host": "127.0.0.1:8080",
"Referer": "http://127.0.0.1:8080/mgr/ps/mgr/index.html",
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.0.0 Safari/537.36",
"X-CSRFToken": "ABjPB9CYXuc0dPy8Wu2hJppDVu1sdhWRrfoWPBM7DimSrMtkHVUAoNAXeWqOIh0d",
"sec-ch-ua-platform": "\"Windows\""
},
"cookies": {
"csrftoken": "ABjPB9CYXuc0dPy8Wu2hJppDVu1sdhWRrfoWPBM7DimSrMtkHVUAoNAXeWqOIh0d",
"sessionid": "b1g42w3ynatxpphy0fhahpdi7g4pn2vg"
}
},
"validate": [
{
"check": "status_code",
"assert": "equals",
"expect": 200,
"msg": "assert response status code"
},
{
"check": "body.msg",
"assert": "equals",
"expect": "成功",
"msg": "assert response body msg"
}
]
}
]
}
YAML 和 JSON 是两种常用的定义结构化数据的格式，YAML 与 JSON 各有优劣，用户在编写测试用例的时可以根据自己的喜好和使用场景来进行选择，不过二者具有较强的相似性：
- 编写风格：YAML 必须使用空格来表示缩进，并且对空格具体数量没有要求，只需要相同层级左侧对齐即可，这种缩进风格简洁且易于阅读，针对同一测试用例，YAML 文件的篇幅通常要比带缩进的 JSON 文件简短很多，用户可以较快地把握整体结构，但是对于手动编写 YAML 测试用例的场景而言，则需要重点注意相同层级左侧对齐，否则很容易导致测试用例的加载错误。JSON 的编写风格则是频繁地使用 {} [] 和 “"，对缩进并没有严格要求（习惯上还是采用良好的缩进风格来便于阅读），正是由于额外的符号过多，容易降低阅读和手工编写上的体验
- 功能多样性：在功能方面，YAML 是 JSON 的超集，YAML 有许多 JSON 缺乏的附加功能，包括注释、可扩展数据类型、关系锚、不带引号的字符串等等，尤其是添加注释的功能在编写测试用例供他人阅读时尤为实用，而 JSON 只支持数值、字符串、布尔值、数组、对象和空值六种数据类型。
- 解析效率：与 YAML 相比，JSON 对机器来说更容易解析，序列化/反序列化的速度更快