前言
httprunner 4.x 版本，YAML/JSON 格式用例（testcase）结构延续了之前的config 和 teststeps 两个部分
config 配置部分
config 部分示例
config:
name: "request methods testcase with functions"
variables:
foo1: config_bar1
foo2: config_bar2
expect_foo1: config_bar1
expect_foo2: config_bar2
headers:
User-Agent: ${get_user_agent()}
verify: False
export: ["foo3"]
每个测试用例都应该有一个config部分，您可以在其中配置测试用例级别的设置，有以下属性
| 属性名称 | 是否必填 | 作用 |
|---|---|---|
| name | 必填 | 指定测试用例名称。这将显示在执行日志和测试报告中。 |
| base_url | 可选 | 如果base_url指定，则 teststep 中的 url 可以设置相对路径部分 |
| verify | 可选 | https请求时，是否校验证书，默认True,忽略证书校验可以设置为False |
| headers | 可选 | 公共请求头部 |
| variables | 可选 | 指定测试用例的公共变量。每个测试步骤都可以引用未在步骤变量中设置的配置变量。换句话说，步骤变量比配置变量具有更高的优先级。 |
| export | 可选 | (早期版本用的output)指定导出的测试用例会话变量，把变量暴露出来，设置为全局变量 |
| parameters | 可选 | 参数化设置，对整个文件生效 |
除了上面的一些自动化会用到的参数，4.x 版本新增了一些关键字
| 属性名称 | 是否必填 | 作用 |
|---|---|---|
| parameters_setting | 可选 | 配置参数驱动的具体策略 |
| think_time | 可选 | 设置思考时间，性能测试用到 |
| websocket | 可选 | 设置 WebSocket 断开重连的最大次数和间隔等（todo） |
| weight | 可选 | 性能测试用到，分配给当前测试用例的虚拟用户权重 |
| environs | 可选 | 配置环境变量（如果未指定则会从 .env 文件导入） |
| path | 可选 | 当前测试用例所在路径（通常不需要手工填写） |
teststep 测试步骤
每个用例可以有多个测试步骤，每个步骤可以看成是一个接口的请求，发送 http 协议接口，可以用到request 关键字，相关参数和requests 库的参数完全一致。
测试步骤 teststep 常用的一些基本关键字
| 测试步骤类型 | 含义 |
|---|---|
| name | 步骤名称 |
| request | 用于发起 HTTP 请求的步骤类型 |
| api | 用于引用 API 的步骤类型 |
| testcase | 用于引用其他测试用例的步骤类型 |
每个步骤可以加变量，前置/后置，以及 提取和校验相关操作
| 测试步骤类型 |作用 |适用的测试步骤|
| variables | 局部变量 | 通用 |
| setup_hooks | 前置函数 | request/api/websocket |
| teardown_hooks | 后置函数 | request/api/websocket |
| extract | 参数提取 | request/api/websocket |
| validate | 结果校验 | request/api/websocket |
| export | 导出变量 | testcase |
httprunner4.x 版本新增的一些关键字
| 测试步骤类型 | 含义 |
| transaction | 用于定义一个事务 |
| rendezvous | 集合点 |
| think_time | 思考时间 |
| websocket | 用于发起 WebSocket 请求的步骤类型 |
teststep 部分使用示例
teststeps:
-
name: get with params
variables:
foo1: ${ENV(USERNAME)}
foo2: bar21
sum_v: "${sum_two_int(10000000, 20000000)}"
request:
method: GET
url: $base_url/get
params:
foo1: $foo1
foo2: $foo2
sum_v: $sum_v
extract:
foo3: "body.args.foo2"
validate:
- eq: ["status_code", 200]
- eq: ["body.args.foo1", "debugtalk"]
- eq: ["body.args.sum_v", "30000000"]
- eq: ["body.args.foo2", "bar21"]
-
name: post raw text
variables:
foo1: "bar12"
foo3: "bar32"
request:
method: POST
url: $base_url/post
headers:
Content-Type: "text/plain"
body: "This is expected to be sent back as part of response body: $foo1-$foo2-$foo3."
validate:
- eq: ["status_code", 200]
- eq: ["body.data", "This is expected to be sent back as part of response body: bar12-$expect_foo2-bar32."]
-
name: post form data
variables:
foo2: bar23
request:
method: POST
url: $base_url/post
headers:
Content-Type: "application/x-www-form-urlencoded"
body: "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"]
测试用例（testcase）
一条测试用例（testcase）应该是为了测试某个特定的功能逻辑而精心设计的，并且至少包含如下几点：
- 明确的测试目的（achieve a particular software testing objective）
- 明确的输入数据（inputs）
- 明确的运行环境（execution conditions）
- 明确的测试步骤描述（testing procedure）
- 明确的预期结果（expected results）
按照上述的测试用例定义，HttpRunner 的测试用例应该保证是完整并且可以独立运行的。
从测试用例的组成结构来看，一个测试用例可以分为「测试脚本」和「测试数据」两部分：
- 测试脚本：重点是描述测试的业务功能逻辑，包括预置条件、测试步骤、预期结果等，并且可以结合辅助函数（debugtalk.go/debugtalk.py）实现复杂的运算逻辑
- 测试数据：重点是对应测试的业务数据逻辑，例如数据驱动文件中的定义的 UUID、用户名等等，以及环境配置文件中定义的 base_url 环境变量等等