前言

最近看了 “hrun4j【开源 hrun4j】致敬 DebugTalk，又一接口测试利器发布，网友：真香！ ” 有些感想， 整理一下我们这几年对 httprunner 的玩法， 希望能起到抛砖引玉的作用。

为什么选择 httprunner

17 年的时候我们开发了一版 springboot testng 纯写 java 代码的， 项目整体结构类似开发框架， 把一个 http 请求封装成一个单独的 service，并引用请求的 http 实现类。 把 http 请求字段比较多的 body、params 封装成 model。 handler 层引用多个 service 构造一些公共的子流程。 后期甚至直接引用了开发的 dubbo 接口、sql 脚本等来构造数据。 testcase 层引用 handler、service 来构造自动化用例， 一个 springboot testng 类为一个 testcase, 加入 dataprovider 类从 excel 里面读取参数数据。在这个框架的基础上，堆了几百条长流程测试用例。 因为有一定的编码门槛， 除几个资深 leader 会写写外， 其他测试人员参与不进来 (那时招的都是 2-3 人外包)。 而且代码因每个人水平不一样写的参差不齐， 后面随着那几个资深测试的离职后， 基本上剩下我一个人来维护， 工作剧增， 每次发布上线跑一轮， 前排查要排查很久， 但当时还有大量业务工作要进行。人个总结一下： 代码型接口测试框架， 对整体测试人员的要求比较高， 代码如果不统一， 后期维护成本很高。
为摆脱这种困境， 想让全员参与进来写接口测试，降低门槛， 我们又搭建了 yapi， 经过几轮培训， 界面的傻瓜点点点基本全员都能写了。 但是一些特殊的场景支持很弱， 比如取 header 里面的字段、支持多环境跑同一条测试用例、 数据的参数化、与数据库连接、与 cicd 结合等等问题。 总结起来对测试人员编写门槛低， 但是扩展性比较差， 二次开发工作量很大。
最后经过一段时间的调研， 我们决定使用 httprunner, 出于下面几方面的原因考虑：
1）httprunner yml、json 格式， 关键字比较少， 格式统一， 容易学、风格也统一， 交接维护成本比较少；
2）可以调用自定义的 python 方法， 扩展性比较好。 脚本解决不了， 代码来补；
3）期望引导整体测试往编码技术去发展， 而不是仅仅点点点， 技术门槛也不能一下太高；

httprunner 从编写到 执行的整体思路

我们构建了两个项目， 一个是专门编写保存脚本的项目， 另一个是一个平台项目

脚本项目

主要是用于编写保存脚本的项目， 项目结构基本按照 httprunner 推荐的格式， 如下：

脚本插件

开始我们也提供了方便编写代码的 har2case.sh 及运行的自动化用例的 runtestCase.sh、runProject.sh 等脚本来帮助测试人员更快更好的编写运行测试用例。 但是编写了一段时间， 发现实在不是很方便，大量的工作是在做 http 请求转成 api，加断言， api 转成 testcase， 加断言， 生成 testsuit, 重复工作比较多； 当时接触了sofa acts ， 算是一个单测的框架， 改改和 springboot 结合用到了项目中。 于是也想开发一个基于 httpunner 的插件 (idea 系列包含了 pycharm、IntelliJ IDEA、Goland 等， 插件开发规则都是一样的), 看了一下 idea 插件可基于 java、swing 实现， 经过一段时间摸索实现了下面这些功能。

• 1、 har 文件转成 api
• 2、选中多个 api 转成 testcase
• 3、选中多个 testcase 右击生成 testsuit
• 4、har 文件一键生成 testcase (1、2 的升级版)
• 5、文件间关联路跳转定位
• 6、运行 testsuit
• 7、各种配置
• 8、脚本关键字提示
• 9、格式化 har
• 10、使用 execl 打开 data cvs 文件

注： 由于这个插件是基于 httprunner2.1.2 版本， 当时 yml、json 的格式与后期的版本不太一样， 所以不兼容后期版本。 所以只说一下主要思路。 httprunner2.1.2 对应的 json、yml 很不规范， 不能序列化和反序列化， 写插件的时候真是很痛苦。 后期版本有改进， 但是当时我们基本于 2.1.2 写的好多测试用例，也进行过二次开发， 升级比较麻烦。

于是编写脚本就变成了 ：
从charles抓包(包含一个流程的所有请求) -> 放到hars文件夹下 -> 右击har文件 生成 testcase及api -> 完善api及testcase -> 右击生成testsuit -> 完善测试数据

对应插件操作：
1、 右击 har 文件 生成 testcase 及 api

2、输入测试用例名称， 确认

3、对测试用例进行编辑， 填写 api 名称 (如果 api 文件夹已经有了， 直接引用原来名称)

4、处理好， 会生成测试 api、testcase。 手动完善 api 及 testcase， 包括一些参数修改、增加断言等， 第 3 步可以增强，增加参数断言等修改， 但是 json 不规范， 序列化反序列化处理起来很难。

5、生成 testsuit

结果：

6、运行
运行写了两版， 一版是放在右击的菜单中， 可以看上图； 另一版主要是为了体验更好一些， 当成一种语言来运行

编辑运行参数

运行结果：

注： 主要功能是这些，其他都是一些辅助功能。 大量抄袭了 idea 源码、swagger 插件源代码、python idea 插件等源代码。

平台项目

平台项目没有用 httprunner manager 或者 fast manager 等 httprunner 的推荐的，因为还是希望测试人员自己去写脚本， 不想在页面上让他们点点点。 平台项目主要引用了脚本项目来辅助管理脚本的执行、展示执行报告、定时运行、对接 cicd 执行、打通企业微信报警等功能。 利用 git hook 机制， 在脚本项目合并代码时去执行测试用例验证提交用例可用、并把增加的用例自动添加到平台。

以上。 写的不好， 见谅。