IT一哥：1071235258（qq）白话版本，写博客不易，请鼓励！

1、介绍

HttpRunner 是一款面向 HTTP(S) 协议的通用测试框架，只需编写维护一份 YAML/JSON 脚本，即可实现自动化测试、性能测试、线上监控、持续集成等多种测试需求。 

---

2、安装

python 3.7 以上

pip install httprunner   （有可能安装失败，失败需跳墙）

验证安装成功：

---

3、部署官方提供的demo

 快速找官方提供的dmo ,玩一遍，因为官方的demo，玩的越明白，后期才能很熟练应用到项目里。

 官方写好的web端的服务，带一些token,和接口，可以用HttpRunner 来玩耍！这个demo文件，没有写main方法，需要在控制台运行。
 
 我偷偷在里面加了main方法，可以在pycharm 你直接运行。
     

 被测服务运行文件，点他下载copy 到你的pycharm里面： https://cn.httprunner.org/data/api_server.py   

不会弄找IT一哥~

---

4、抓包*（抓demo服务，生成接口数据）

进行抓包，是为了生成接口详细的数据请求和返回记录，这嘎达你就按照我说的做，做完你就懂了！
打开我们的fiddler 如果fiddler 不知道是撒，不会用，那还得去找IT一哥,让他给你培训一下！。

打开我们的抓包工具，来抓包（抓我们运行pycharm 那个api_server.py  的运行的服务）

---

5、用postman 来构造get 和post 请求

  目的：来模拟用户访问api_server.py  的运行的服务。让demo服务产生请求的记录被我们抓包工具fiddler 抓到！

 如果小伙伴还不知道get ,post 是什么鬼，那一哥会直挠头，简单来说，我们单纯的登陆淘宝，不购物，不登录，不搜索，就点点的这种的叫做get 请求，然后由浏览器自动发出获取到我们想要看的资源。

辣种登陆淘宝，搜索商品，下单，填写地址，支付一气呵成，辣种叫做post 请求！
 
 接下来我们打开外号叫小飞侠的postman ,它就是个工具，用来代替谷歌浏览器，来模拟浏览器发出get和post 请求，用来验证，这两个请求返回的数据，是不是用户想要的。下面就是它了！

首先我们构造一个post请求：（不会弄，没关系，跟我一致就行了，模仿我！）

获取服务的token:

这个token 有了之后，才能创建用户哦！

获取sign （获取之后，黏贴到上幅图中的postman中，这样才会访问成功获取token）

用户添加成功

---

6、查看Fiddler 并导出 har 文件

  这时候看看我们Fiddler 应该获取到了请求get_token  和添加用户的两个接口的具体交互了：
  （这个fiddler 事先一定要设置过滤哦，要不然抓了一大堆的不相关的链接）过滤设置

  然后打开我们的Fiddler 把session 会话列表，导出
  HAR 格式的文件，假设导出的文件名称为 demo-quickstart.har。



  这里我们点击file --->Export Sessions -->AllSessions:

---

7、把Fiddler 导出 har 文件，转换成接口自动化测试用例json.

  然后我们在控制台里执行，命令把这个har文件生成HttpRunner 认识的测试用例
  
  下面的命令是转换命令
  >har2case  demo-quickstart.har 

 不加-2y 是生成json 文件。加了会生成yaml 文件。

这是官方的介绍：
现在我们只需要知道如下几点：每个 YAML/JSON 文件对应一个测试用例（testcase）每个测试用例为一个list of dict结构，其中可能包含全局配置项（config）和若干个测试步骤（test）config 为全局配置项，作用域为整个测试用例test 对应单个测试步骤，作用域仅限于本身如上便是 HttpRunner 测试用例的基本结构。

---

8、自动化运行我们的接口测试用例

然后开始运行我们 的测试用例：

>hrun demo-quickstart.json


非常不幸，两个接口的测试用例均运行失败了。不要紧，整个测试过程，没问题，出问题的点是不能直接用以前失效的token,拿过来直接使用。那必须是会报错的。所以下面我会优化。

因为：请求/api/get-token接口时，每次生成的 token 都会是不同的，因此将生成的 token 作为校验项的话，校验自然就无法通过了。

优化测试用例¶从两个测试步骤的报错信息和堆栈信息（Traceback）可以看出，第一个步骤失败的原因是获取的 token 与预期值不一致，第二个步骤失败的原因是请求权限校验失败（403）。接下来我们将逐步进行进行优化。



开始调整那个罪魁祸首 。

正确的做法是，在测试步骤的 validate 中应该去掉这类动态变化的值。去除该项后，保存！

我们再来运行一遍：

原因：
经过修改，第一个测试步骤已经运行成功了，第二个步骤仍然运行失败（403），还是因为权限校验的原因。

因为涉及到权限检验了，又因为两个接口的token值是动态相关联的，所以需要进行参数关联。

正确的做法是，我们应该在每次运行测试用例的时候，先动态获取到第一个测试步骤中的 token，然后在后续测试步骤的请求中使用前面获取到的 token。


所以必须先让http://127.0.0.1:5000/api/get-token   动态生成的token 可以友好的传给
http://127.0.0.1:5000/api/users/1000  这个创建用户的接口。

官方的话：眨眼一看，我都有点蒙，别怕实验，主要看俄的图！
在 HttpRunner 中，支持参数提取（extract）和参数引用的功能（$var）。在测试步骤（test）中，若需要从响应结果中提取参数，则可使用 extract 关键字。extract 的列表中可指定一个或多个需要提取的参数。在提取参数时，当 HTTP 的请求响应结果为 JSON 格式，则可以采用.运算符的方式，逐级往下获取到参数值；响应结果的整体内容引用方式为 content 或者 body。

创建用户的接口就可以愉快玩耍的获取get_token 的动态生成token值（因为token会过期，每次生成都不一样） 保存好我们的json
文件以后，再次运行。

再次运行（运行之前，一定要改变用户，或者重启服务，因为之前实验那创建用户的接口，用户名不能再次使用了 ）：

所以改下json: 

改json以后 也提示用户已经存在，这个从报告里看。当你运行完hrun demo-quickstart.json 会生成reports 目录，目录下就是报告。。

没办法，只能重启api_server.py 服务，。

看了下代码原来是这个问题

最终结果（花了一个多小时调通，嘴角终于露出了孩子般的微笑）