前言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部分，您可以在其中配置测试用例级别的设置，有以下属性 | | |
|---|
| | 指定测试用例名称。这将显示在执行日志和测试报告中。 | | | 如果base_url指定，则 teststep 中的 url 可以设置相对路径部分 | | | https请求时，是否校验证书，默认True,忽略证书校验可以设置为False | | | | | | 指定测试用例的公共变量。每个测试步骤都可以引用未在步骤变量中设置的配置变量。换句话说，步骤变量比配置变量具有更高的优先级。 | | | (早期版本用的output)指定导出的测试用例会话变量，把变量暴露出来，设置为全局变量 | | | |
除了上面的一些自动化会用到的参数，4.x 版本新增了一些关键字 | | |
|---|
| | | | | | | | 设置 WebSocket 断开重连的最大次数和间隔等（todo） | | | | | | 配置环境变量（如果未指定则会从 .env 文件导入） | | | |
teststep 测试步骤每个用例可以有多个测试步骤，每个步骤可以看成是一个接口的请求，发送 http 协议接口，可以用到request 关键字，相关参数和requests 库的参数完全一致。 测试步骤 teststep 常用的一些基本关键字 每个步骤可以加变量，前置/后置，以及 提取和校验相关操作 httprunner4.x 版本新增的一些关键字 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 环境变量等等
| 
