httprunner（4.x）基本使用（二）"/>
httprunner（4.x）基本使用（二）
上一章：
Django实现接口自动化平台（五）httprunner（4.x）介绍【持续更新中】_做测试的喵酱的博客-CSDN博客
下一章：
一、变量（variables） 的处理
基于变量机制实现参数的生命周期管理
在测试用例中，很多时候我们需要对参数进行声明和引用，这就需要用到变量（variables）机制。
1.1 变量声明
在 HttpRunner 测试用例中，有 4 个地方可以对变量进行声明。
1.1.1 声明全局变量（config variables）
在 config 下声明的 variables 为测试用例全局变量，作用域为整个测试用例，在测试用例的所有地方都可以引用。
1.1.2 声明数据驱动（parameters）
在 config 下声明的 parameters 为测试用例的驱动参数；它的作用域也是覆盖整个测试用例，在测试用例的所有地方都可以引用。
1.1.3 声明局部变量（teststeps variables）
在单个测试步骤（teststep）下声明的 variables 是测试步骤局部变量，作用域仅限当前步骤。
各个测试步骤的变量相互独立，互不影响。
1.1.4 提取参数变量（session variables）
还有一种变量声明的方式，可以在某个测试步骤（teststep）中提取（extract）特定的响应参数，并赋值给指定的变量名。该操作也常被成为 参数关联。
提取的参数变量类似于 session 参数，作用域为当前步骤及之后的步骤。
1.2 变量引用
在 HttpRunner 的测试用例中，约定通过 ${} 或 $ 的形式来引用变量。
例如：$var 或 ${var}
大多数情况下，采用 $var 或 ${var} 这两种形式都是可以的。但如果在某些字段中存在部分引用变量的情况，例如 abc123def 中 123 需要引用变量，那么就只能使用 ${var} 的形式，即 abc${num}def；如果使用 abc$numdef 的话，变量名称会被识别为 numdef。
另一种需要说明的情况，如果在测试用例中本身就存在 $ 符号，那么可以通过 $$ 进行转义。
例如，测试用例中某个字段的原始内容为 $m，那么为了避免将其解析为变量，则需要将其写为 $$m。
1.3 变量优先级
针对上述的 4 类变量类型，如果声明的变量名称出现重复，则会按照一定的优先级策略进行处理。
优先级从高到低依次为：step variables > session variables > parameter variables > config variables
1.4 示例
下面通过一个完整的示例进行说明。
config:{"name": xxx"variables": { # config variables"varA": "configA""varB": "configB""varC": "configC"}"parameters" : { # parameters variables"varA-varB": [["paramA1", "paramB1"],["paramA2", "paramB2"],]}
}teststeps:[{"name": "step 1""variables": { # step variables"varA": "step1A"},"request": {"method" : "GET""url" : /$varA/$varB/$varC # varA="step1A", varB="paramB1", varC="configC"}"extract": {"varA": "body.data.A", # suppose varA="extractVarA""varB": "body.data.B" # suppose varB="extractVarB"}},{"name": "step 2""varialbes": { # step variables"varA" : "step2A"}"request": {"url" : /$varA/$varB/$varC # varA="step2A", varB="extractVarB", varC="configC""method" : "GET"}}
]
在步骤 1 中：
- varA 定义了局部变量，优先级最高，因此实际值为 step1A
- varB 未定义局部变量，将继承全局变量；而在全局变量中，parameter 的优先级高于 variables，因此 varB 实际值为 paramB1
- varC 未定义局部变量，将继承全局变量；在全局变量中，varC 仅在 variables 中进行了声明，因此 varC 的实际值为 configC
在步骤 2 中：
- varA 定义了局部变量，优先级最高，因此实际值为 step2A
- varB 未定义局部变量；而步骤 1 中有提取该变量，优先级高于全局变量，因此 varB 实际值为 extractVarB
- varC 未定义局部变量，也不存在同名 session 变量，将继承全局变量，因此 varC 实际值为 configC
二、参数提取（extract）
基于参数提取机制实现响应结果字段提取和参数关联
在实际业务场景中，很多时候存在参数关联的情况，即当前接口请求参数来自于之前接口的响应结果。
例如，通过手机号登录的场景中，登录接口请求参数需要带上服务端预先返回的短信验证码；如果缺少这个参数关联操作，接口调用将会失败。
目前，HttpRunner 支持 2 种响应结果字段提取方式。
提取的参数变量类似于 session 参数，作用域为当前步骤及之后的步骤，引用方式与普通的变量一致。
2.1 jmespath 表达式
若响应结果为 JSON 结构，支持采用 jmespath 表达式进行参数提取。
jmespath 是一种 JSON 查询语言，可以使用非常灵活且强大的表达式查询 JSON 数据结构中的字段，并返回符合条件的数据。
针对 jmespath 官网中的示例：
{"locations": [{"name": "Seattle", "state": "WA"},{"name": "New York", "state": "NY"},{"name": "Bellevue", "state": "WA"},{"name": "Olympia", "state": "WA"}]
}
- 查询所有城市名称：
locations[*].name - 查询第二个城市名称：
locations[1].name=> “New York” - 查询最后一个州名：
locations[-1].state=> “WA”
HttpRunner 完全继承了 jmespath 的强大能力，只需要重点注意两点：
1、extract 的对象仅有 5 种类型：
- status_code：提取响应状态码，例如 200、404
- proto：提取协议类型，例如 “HTTP/2.0”、“HTTP/1.1”
- headers：从响应 headers 中提取字段，例如 headers.name
- cookies：从响应 cookies 中提取字段，例如 cookies.Token
- body：从响应 body 中提取字段，例如 body.args.foo1
2、如果表达式中存在 - 的情况，那么需要加引号处理。
例如 headers."Content-Type"
"teststeps": [{"name": "","variables": {"name": "demo"},"request": {"method": "POST","url": "","params": {},"headers": {"name": "$name","Content-Type": "text/plain"},"body": ""},"validate": [],"extract": {"name": "body.headers.Name"}}
]
2.2 正则表达式（regex）
若响应结果为 text/html 格式，支持采用正则表达式的方式提取目标参数。
例如响应的 body 为：
<html>
<title>参数提取（extract） | HttpRunner</title>
</html>
如果我们想提取页面的 title 字段，就可以这样做：<title>(.*)</title>
即在提取表达式中指定目标参数的左右边界，然后将目标参数替换为 (.*)；这样我们就能将正则匹配到的值赋值给参数变量了。
"teststeps": [{"name": "","variables": {"name": "demo"},"request": {"method": "GET","url": "","params": {},"headers": {"name": "$name","Content-Type": "text/plain"}},"validate": [],"extract": {"title": "<title>(.*)</title>"}}
]更多推荐
httprunner（4.x）基本使用（二）
发布评论