httprunner 3.x ---Study

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，而且需要将文件拷贝至所用到的每台机器上