httprunner 4.x学习 - 2.测试用例结构（testcase）

前言

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 环境变量等等