1 配置环境
需要python 3.6 以上环境
参考：https://ontheway-cool.gitee.io/httprunner3doc_cn/
pip install httprunner
检查环境是否安装
httprunner 参数详解
run 制作HttpRunner测试用例并使用pytest运行。
startproject 使用模板结构创建新项目。
har2case 将HAR文件转换为HttpRunner的YAML/JSON测试用例
make 将YAML/JSON测试用例转换为pytest用例。
2 创建htpprunner工程
httprunner startproject [projectName]
3 文件目录
har：用来存放 har 文件 （har文件 可以在抓包工具或浏览器的F12网络中导出）
logs：日志存放的位置 日志是自动生成的
reports：测试报告存放的位置
testcases：测试文件存放的位置（可以是yaml 或者json 文件，也可以是py文件，它们之间是可以转换的）
.env：环境变量或者有需要的配置都可以写到里面
debugtalk.py：这个文件类似于pytest框架中的conftest.py，可以自定义一些函数 获取内容，在case文件导入
个人感觉这个框架的好处在于：用例极其少量的代码或者不用代码，完成接口测试工作，并且yaml/json 和 py 文件之间可以转化，使不懂pytest或unitest等测试框架的同学也能快速入手接口自动化。达到工作目标
下面是2.x 版本的目录结构
在3.x 版本中，这些目录是可以自主添加的
4 hrun 参数
hrun [options] [file_or_dir] [file_or_dir] [...]
====
可以跟多个用例目录或者文件
====
====
-k EXPRESSION(表达式)
表达式仅运行与给定子字符串表达式匹配的测试。表达式是python可计算表达式，其中所有名称都是
子字符串与测试名称及其父类匹配。示例：-k“test_method or test_other”匹配所有测试
名称包含“test_method”或“test_other”的函数和类，而-k“not test_method”匹配那些不包含“test_method”或“test_other”的函数和类
在名称中包含“test_method”-k“not test_method and not test_other”将消除匹配项。其他关键字匹配到“extra_keyword_matches”集中包含额外名称的类和函数，以及直接为其指定名称。匹配不区分大小写。
-m MARKEXPR
仅运行与给定标记表达式匹配的测试。示例：-m“mark1而非mark2”
--markers 显示标记（内置、插件和每个项目标记）。
-x, --exitfirst 第一次出错或测试失败时立即退出。
--maxfail=num 第一个num失败或错误后退出。
--strict-markers, --strict 未在配置文件的“markers”部分注册的标记会引发错误。
-c file 从“file”加载配置，而不是尝试查找其中一个隐式配置文件。
--continue-on-collection-errors 即使发生集合错误，也强制执行测试。
--rootdir=ROOTDIR
定义测试的根目录。可以是相对路径：“root_dir”，”/root_dir“，”root_dir/another_dir/'；绝对路径：“/home/user/root_dir”；带变量的路径：“$HOME/root_dir”。
--fixtures, --funcargs 显示可用的装置，按插件外观排序（前导为“_”的装置仅显示为“-v”）
--fixtures-per-test 显示每个测试的前置装置
--import-mode={prepend,append} 前置/附加到系统。导入测试模块时的路径，默认为前置
--pdb 在出现错误或键盘中断时启动交互式Python调试器。
--trace 运行每个测试时立即中断。
-s 终端打印case内容
--lf, --last-failed 仅重新运行上次运行失败的测试（如果没有失败，则全部重新运行）
--cache-clear 在测试运行开始时删除所有缓存内容。
--sw, --stepwise 测试失败时退出，下次从上次失败的测试继续
--stepwise-skip 忽略第一个失败测试，但在下一个失败测试时停止
-v, --verbose 增加详细信息 具体参考pytest参数
-q, --quiet 减少冗余内容 具体参考pytest参数
-r chars 显示字符指定的额外测试摘要信息：（f）失败，（E）错误，（s）中断，（x）失败，（x）通过，（p）已通过，（p）已通过输出，（a）除通过外的所有（p/p）或（a）所有。（w） 默认情况下启用警告（请参阅--禁用警告），“N”可用于重置列表。（默认值：“fE”）。
--disable-warnings, --disable-pytest-warnings 禁用警告摘要
--color=color 彩色端子输出 (yes/no/auto).
--html=path 在给定路径创建html报告文件。 具体参考pytest参数
--confcutdir=dir 仅加载conftest.py相对于指定的目录。
-V, --version 显示pytest版本和插件信息。
--alluredir=DIR 在指定目录中生成allure报告（可能不存在）
-clean-alluredir 清除alluredir文件夹（如果存在）
--cov-config=PATH 覆盖率的配置文件 default: .coveragerc
--reruns=RERUNS 重新运行失败测试的次数 default: 0
4.1 har2case 参数
har2case
-2y, --to-yml, --to-yaml 转换为YAML格式，如果未指定，则默认情况下转换为pytest格式。
-2j, --to-json 转换为JSON格式，如果未指定，则转换为pytest 默认设置格式。
演示
文件的内容过于庞大，不展示了
5 运行 har文件的 case
先获取har 文件 使用抓包工具 或者 浏览器的F12 导入 har文件
在将har 转换成 yaml或者 json 在使用hrun 命令运行
6 运行yaml或json 文件的case
以yaml 文件为例，不会yaml格式的同学赶紧学起来吧！（只是文件的类型不同，内容是一样的）
6.1 一个简单的请求
注意：文件名称的结尾必须以 _test 结尾，例如：
文件名：request_1_test.yaml
文件内容
内容分为两个部分
（1） config：每个测试用例都必须有config部分，可以配置用例。
（1.1）name：***必填项***，测试用例的名称，将在log和报告中展示。
（2）teststeps: 每个测试用例都有1个或多个测试步骤（List[step]），每个测试步骤对应一个API请求或其他用例的引用。
（2.1）name：***必填项***，name用来定义测试步骤 name，将出现在log和测试报告中。
（2.2）request：***必填项***，一个请求的开始标志
（2.2.1）method：**必填项***，设置http方法，支持的方法（GET/POST/PUT/PATCH/DELETE/）
（2.2.2）url：**必填项***，设置Url,
（3）validate：测试用例中定义的结果校验项，作用域为当前测试用例，用于实现对当前测试用例运行结果的校验。
原理：用jmespath 提取Json response的内容，并进行断言校验。还不懂jmespath使用同学，赶紧补习了哦！
（3.1）- eq：equal: 等于 具体内容参见 `https://ontheway-cool.gitee.io/httprunner3doc_cn/concepts/testcase_structure/#validate`
(3.2) 列表中的第一个值是key 存在多层嵌套时用点分割
eq: ["body.code", 0] 取body中code的值
# 执行脚本的命令
# hrun 路径+文件名.yaml -s -q
httprunner run 路径+文件名.yaml -s -q
注意：执行第二个命令，会自动生成对应名称的py文件，
生成的这个py文件，可以使用pytest 直接运行，这个文件的写法可以学习一下，不过还是直接写yaml文件更简单，也可以使用hrun或httprunner run 运行，很是灵活
============================================================================
yaml或json文件有许多用例结构，上面只是一个简单例子，下面我们 一 一来使用，一 一 解释
============================================================================
6.2 base_url
base_url: 属于 config 中的可选配置，如果base_url被指定，测试步骤中的url只能写相对路径
书写方式
6.3 variables
variables：配置在config中和teststeps中都可以使用，在config中，属于全局遍历，在测试步骤中的任何地方都可以使用；在 teststeps中，仅供当前请求测试步骤使用，因为局限性，使用不多。
6.3.1 在config中的使用
书写方式：
看一下 日志内容
6.3.2 在teststeps中的使用
书写方式
同样可以请求成功，这里日志就不看日志了
6.4 verify
verify: 指定是否验证服务器的TLS证书。如果我们想记录测试用例执行的HTTP流量，这将特别有用，因为如果没有设置verify或将其设置为True，则会发生SSLError。
书写方式
为false时，请求为https时，会忽略证书
6.5 parameters
parameters：全局参数，用于实现数据化驱动，作用域为整个用例。
书写方式：
会请求3次，请求的次数使用parameters 下id 的数量
日志就不看了，比较多。
parameters 还有其他用法，在后面参数化具体解释，这里只是一个简单的使用
6.6 export
export：可选，指定输出的测试用例变量。将每个测试用例看作一个黑盒，config variables是输入变量，config export是输出变量。当一个测试用例在另一个测试用例的步骤中被引用时，config export将被提取并在随后的测试步骤中使用。
在config中和teststeps中都可以添加
书写方法
这个主要用于跨文件调用参数使用
6.7 params
params：在get请求时，需要添加参数时使用
相当于红框中的内容
书写方法
多个参数，都可以写成key: value 格式
6.8 headers
headers: 设置请求的headers
6.9 cookies
cookies: 设置Http请求的cookies
6.10 body
body: 设置http请求的Body
6.11 json
json: 设置http请求json格式的body
6.12 extract
extract: 可选，从当前 HTTP 请求的响应结果中提取参数，并保存到参数变量中（例如token），后续测试用例可通过$token的形式进行引用。
书写格式
提取返回数据的方式（如果返回的数据格式是json格式，使用content提取数据）
1使用 content.key ，取key 对应的value
2 使用content.int.key ，取对应的列表中的索引，在通过key取value
提取返回值的数据还可以使用body提取
1使用 body.key ，取key 对应的value
2 使用body.int.key ，取对应的列表中的索引，在通过key取value
提取cookie数据方式
1 cookie.key 或 header.Set-Cookie.key 取 单个值
2 cookie 或 header.Set-Cookie 提取全部cookie
缺点：如果存在多个提取的值，key 必须不相同才行
6.13 hooks
hook 机制分为两个层级
测试用例层面（testcase）
测试步骤层面（teststep）
6.13.1 测试步骤层面
书写方式
debugtalk.py的配置
日志查看运行结果
请求前的调用
请求后调用
打印一下请求信息和响应信息
转成字典方便操作
setup_hooks: 修改请求头信息，例如鉴权
teardown_hooks: 处理统一的结果，例如状态码等
6.13.2 测试用例层面
setup_hooks: 在整个用例开始执行前触发 hook 函数，主要用于准备工作。
teardown_hooks: 在整个用例结束执行后触发 hook 函数，主要用于测试后的清理工作。
比较奇怪：没有触发用例层面的配置
7 .env 文件的使用
在debugtalk.py 中获取环境变量值
执行机制：在用例开始执行前，可以对环境变量进行一个修改
8 debugtalk.py 的使用
作为项目根路径的锚，测试用例中的相对路径（例如引用测试用例或CSV文件）都基于此根路径。
存储自定义的python函数，在测试用例中调用的函数均在此文件中定义
上文中也有用到
９测试套件
测试用例编写方式
测试套件
testcase: 后面是路径，以下图为根路径，注意windows和Mac linux的 路径分割符书写
执行测试套件的yaml名称
10 参数化
单个参数的参数化
yaml 格式
从日志中看，请求的了三次，每次的结果于ID对应
对应py文件
关联性的参数化
yaml 格式
从日志中看出，请求了三次，每次都取list中的值与对应的参数匹配
py文件
笛卡尔积组合
yaml文件
从日志看出，执行了九次，怎会是九次呢？原因是 Id 的数量 * Name 的数量
py 文件
11 性能测试
pip install locust
参数说明
Common options:
-h, --help 显示此帮助消息并退出
-f LOCUSTFILE, --locustfile LOCUSTFILE
--config CONFIG 配置文件路径
-H HOST, --host HOST 主机负载测试如下http://10.21.32.33
-u NUM_USERS, --users NUM_USERS 并发的用户数量
-r SPAWN_RATE, --spawn-rate SPAWN_RATE 每秒生成的用户数
-t RUN_TIME, --run-time RUN_TIME Stop after the specified amount of time, e.g. (300s, 20m, 3h, 1h30m, etc.)默认为永远运行
-l, --list 显示可能的用户类列表并退出
Web UI options:
--web-host WEB_HOST 要将web界面绑定到的主机 默认为'*'
--web-port WEB_PORT, -P WEB_PORT 运行web主机的端口
--headless 禁用web界面，并立即启动测试。使用-u和-t控制时间
--autostart 立即启动测试（不禁用web UI）。使用-u和-t控制时间
--autoquit AUTOQUIT 执行X秒后自动退出
Master options: 运行Locust distributed时运行Locust主节点的选项。主节点需要辅助节点才能运行负载测试。
--master 将locust设置为以该进程为主进程的分布式模式运行
--master-bind-host MASTER_BIND_HOST 主机应绑定到的接口（主机名，ip）
Request statistics options
--csv CSV_PREFIX 将当前请求统计信息存储到CSV格式的文件中
--csv-full-history 以CSV格式将每个统计条目存储到_stats_history.csv文件。还必须指定“-csv”参数才能启用此功能。
--print-stats 在控制台中打印统计信息
--only-summary 仅打印摘要统计信息
--reset-stats 生成完成后重置统计信息。在分布式模式下运行时，应在主机和工作机上设置
--html HTML_FILE 将HTML报告存储到指定的文件路径
Other options:
--enable-rebalancing 如果在测试运行期间添加或删除了新工作线程，则允许自动重新平衡用户。
11.1 一个简单的测试
locusts -f .\testcases\request_1_test.yaml
命令运行没有卡住，已经开启了一个服务
在浏览器中输入：http://localhost:8089/
第一个输入：用户数量
第二个输入：每秒启动的用户数量
第三个输入：设置主机的主机名或IP，分布式压测每台机器上都要需要安装locust，而且需要将文件拷贝至所用到的每台机器上
扫一扫
227
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
