v4.0 的诞生背景

HttpRunner 经过近 5 年的迭代,即将进入到 v4.0 版本了。非常欣喜的是,HttpRunner 已经有了较大的用户基数和知名度,在搜索引擎和各种主流技术社区搜索 HttpRunner 都能看到一些用户自发分享的文章,甚至还有培训班以此开设了付费课程,以及有人写书时做了较大篇幅的介绍。这些反馈给了我极大的鼓舞,让我有更大的动力将 HttpRunner 变得更好。

那 HttpRunner v4.0 作为一个全新的大版本,诞生的背景是什么?期望达成的目标是什么呢?

我的 2021 年终总结中有讲到,我所在的团队从去年开始重点投入到 ToB 方向。经过一段时间的探索和思考之后,我们选择以接口性能测试工具作为切入点(产品命名 QuickRunner),并计划采用 Open Core 的商业模式(核心能力基于开源的 HttpRunner),希望可以通过这种方式更多地触达用户收集反馈,借助开源社区打磨产品。

不过,既有的 HttpRunner 可能还没法直接满足我们的需求。因为我们的核心目标是要做一款性能测试工具,对于发压能力和数据准确度具有非常高的要求;而之前的 HttpRunner 是基于 Python 开发的,性能测试部分使用的是 Locust,其单机发压能力和数据准确性都存在较大的问题。

经过短暂的思考后,我打算采用 Golang 按照 HttpRunner v2 的思路重写一遍,在保持使用方式基本不变的前提下,使功能更丰富、运行更稳定、性能更强、更易部署和使用。同时,为了避免 Golang 版本在迭代初期过程中影响到已有的 Python 版本,我还新建了一个新的项目,命名为 HttpRunner+(简称 hrp),在项目结构基本稳定后才合并到 HttpRunner 仓库,这也就是我们即将发布的 v4.0 版本。

v4.0 的核心目标

总的来说,HttpRunner v4.0 最核心的目标是支撑 QuickRunner 成为行业领先的专业级一体化 API 测试解决方案。

具体方面,HttpRunner v4.0 在继承 v2/v3 已有功能和保持前向兼容的基础上,重点会在如下几个维度进行提升:

v1/v2/v3/v4 版本对比概览

可能你还是会感到有些困惑,HttpRunner v4 相比于之前的 v1/v2/v3/hrp 版本,他们的关系和差异到底是什么?

为了让你感观更加清晰,我整理出了如下表格,详细对比了各个版本间的关键差异点。

版本 v1 v2 v3 HttpRunner+ v4
发布时间 2018.3.7 2019.1.1 2020.03.10 2021.11.18 2022.5.1
开发语言 Python Python Python Golang Golang + Python
版本号规范(semver)
网络协议 HTTP(S)/1.1 HTTP(S)/1.1 HTTP(S)/1.1 HTTP(S)/1.1 多协议 HTTP(S)/HTTP2/WebSocket/TCP/RPC
脚本转换工具 HAR HAR HAR HAR HAR/Postman/Swagger/Curl
工程脚⼿架
测试⽤例(集)格式 v1 v2 v2 v2 v2
测试⽤例分层机制 v1 v2 v2 v2 v2
脚本格式类型 YAML/JSON YAML/JSON YAML/JSON/pytest YAML/JSON YAML/JSON/pytest/gotest
脚本格式校验 jsonschema TODO
脚本编写语法提示 pytest 链式调用 gotest 链式调用 gotest 链式调用 + pytest 链式调用
脚本执行引擎 Python unittest Python unittest Python pytest Go 自研 Go 自研 + Python pytest
插件化语言(debugtalk.xx) Python Python Python 多语言(Go/Python) 多语言(Go/Python/Java/etc.
参数提取机制 regex + 点分隔符 jmespath + regex + 点分隔符 jmespath jmespath + regex jmespath + regex
skip 机制 TODO
接口测试报告 html 自研(jinja2) html 自研(jinja2) pytest-html/allure html 自研(Go template) html 自研(Go template)+ pytest-html/allure
性能测试引擎 Python Locust Python Locust Python Locust Go Boomer Go Boomer
运行环境依赖 Python 2.7/3.3+ Python 2.7/3.5+ Python 3.7+ pytest 无需依赖 Go 引擎无需依赖
pytest 引擎依赖 Python 3.7+
网络性能采集
安装部署方式 pip pip pip curl/wget curl/wget

注:v4 中 斜体 代表当前还未支持,但计划会实现。

从上面的表格可以看出,HttpRunner v4 颇有点金刚葫芦娃的意思,囊括了之前所有版本的功能,并且增加了很多新特性。

HttpRunner v4 = v2 + v3 + hrp + ...

在使用体验和用例格式兼容性方面,v4 也会与之前的 v2/v3/hrp 做到兼容,因此后续 HttpRunner 的维护工作都将转到 v4 版本,之前的版本将不再单独维护。

v4.0 核心功能介绍

在 v4.0 版本中,HttpRunner 整体完成了重新设计,重点支持了双执行引擎、多网络协议、多编程语言、多测试用途等能力。

这里先只挑选部分进行简单介绍,后续我们会补充完善的用户说明文档。

双执行引擎

HttpRunner v4.0 可能给很多用户带来的第一直观印象,就是将项目语言替换为了 Golang。

这种说法其实是不太准确的,确切地说,HttpRunner v4.0 同时采用了 Golang/Python 两种编程语言,底层会有两套相对独立的执行引擎,目标是兼具 Golang 的高性能和 pytest 的丰富生态。

具体实现方面,HttpRunner v4.0 采用 Golang 基本上实现了所有的功能,除了用例执行引擎(hrp run)和压测引擎(hrp boom)外,脚手架工具(hrp startproject)、用例生成工具(hrp har2case)、脚本转换工具(hrp convert)等都优先采用 Golang 进行编写,目的是提升执行效率(毕竟是 Go)和代码质量(静态语言 & 类型系统)。而唯一继续采用 Python 进行编写的则是基于 Python pytest 的接口测试执行引擎(hrp pytest),主要考虑是支持 pytest 的丰富插件生态,并且与 v3 保持兼容。

不过需要特别说明的是,使用 HttpRunner v4.0 并不是必须要具备 Go 语言基础。

HttpRunner 的测试用例脚本支持:

并且动态运算逻辑(plugin)支持多种编程语言(详见后文),包括 Python。

因此你完全可以选择使用 JSON/YAML 格式编写维护测试用例,插件语言选择 Python,使用方式和体验可以做到基本上和 HttpRunner v2.x 一致。或者你可以选择 pytest 代码形态的脚本,在使用体验上也可以做到和 v3.x 基本一致。

但如果你是期望使用 HttpRunner v4.0 做专业的性能测试,那么最好还是选择使用 golang 编写插件,单机发压性能(QPS)可以达到 2w 以上,这是 Python 插件远远无法达到的。

多网络协议

HttpRunner v4.0 已不再局限于 HTTP 协议,当前已成长为一个支持多协议可扩展的测试工具。

截至当前,HttpRunner v4 已经新增支持了 HTTP/2 和 WebSocket 协议,RPC(thrift)协议正在开发中,后续将逐步支持 TCP/UDP/gRPC 等协议类型。

不过,HttpRunner 会继续保持该命名。HTTP 作为最广泛使用的网络协议,可以作为协议的代表,就像 Postman 中的 POST 那样,也是可以讲得通的。

多编程语言

针对动态运算逻辑(plugin)部分,HttpRunner v4.0 不再局限于 Python,而是采用了 gRPC 的方案。因此理论上,gRPC 支持 10+ 主流编程语言 HttpRunner v4 都可以支持。

当前已支持的插件语言:

这部分能力已经单独抽离出了一个基础组件,有兴趣可以详见 httprunner/funplugin

多测试用途

HttpRunner 在创建之初就以「能力复用」为目标,期望只需编写维护一套脚本,就可以同时实现接口测试、性能测试、服务可用性监控等能力。

在 v4.0 版本中,HttpRunner 更进一步,将新增支持「网络性能监测」,实现数字体验监测(DEM)的能力。

同时,v4 还对 step 的类型进行了抽象,方便进行扩展。

基于该机制,我们可以扩展支持新的网络协议类型,也可以支持新的测试类型,例如 SQL 操作或 UI 自动化。甚至我们还可以在一个测试用例中混合调用多种不同的 Step 类型,例如实现 HTTP/RPC/SQL/UI 混合场景。

是不是很有想象力空间?

开源项目运营

开源项目不仅仅是将代码进行公开,同时还需要建立好用户社区,帮助并引导更多的人加入进来。而在这方面 HttpRunner 一直做得都不大好,接下来必须得加强开源社区运营的投入。

从 v4.0 版本开始,HttpRunner 期望从以下几个方面进行改进。

核心开发团队

截至当前,HttpRunner 已经有 21 位开发者贡献过代码。虽然看上去还不错,但之前主要的开发维护工作基本上都还是我一个人,这对项目的健康度是非常不利的。

庆幸的是,在 QuickRunner 项目立项之初,我们团队又投入了 2 位同学到 HttpRunner 的开发工作;同时在字节内部,其它部门另一位同样在重度使用 HttpRunner 的同学也加入了开源共建。

因此,HttpRunner 当前有了 4 位真正意义上的核心开发者:

在这里也非常欢迎更多的朋友参与进来,特别是在工作中重度使用 HttpRunner 的朋友,「独行者速,众行者远」。

用户调研问卷

为了更好地收集 HttpRunner 用户反馈,明确需求迭代路径,我们从今年开始尝试了用户调研问卷的形式。

通过调研问卷,我收集到了非常多宝贵的反馈和建议,这对 HttpRunner 的发展起到了非常重要的指引作用。

在此非常感谢大家的积极参与,也希望大家后续可以通过这个途径给予 HttpRunner 更多的反馈(共性需求会高优实现哦~)。

Issue 管理 & 版本规划

GitHub Issues 是 HttpRunner 的项目需求管理工具,也是 HttpRunner 用户和开发者的主要交流渠道。

大家在使用 HttpRunner 的过程遇到问题都可以通过 issue 反馈(建议先搜下是否有重复问题),我们通过其它渠道收集到的问题也会汇总到这里。

同时为了更高效地管理 issues,HttpRunner 设置了多个维度的标签(Labels),每个 issue 会采用 1~N 个标签进行组合管理。具体可阅读 HttpRunner 的 Issue 管理机制

另一方面,HttpRunner 从 v4.0 开始要做版本规划了。具体形式采用的是 GitHub 的里程碑(milestone)功能,每个版本会设定为一个里程碑,例如 v4.1、v4.2。然后我们会把所有的 issue(包括新功能、优化、bugfix 等)规划到具体版本中,并在 GitHub 的 Projects 中进行管理。

如果大家想了解 HttpRunner 后续的版本规划,可以到 Projects 中进行查看。当然啦,需求规划后也会动态进行调整,如果你发现你想要的功能排期比较靠后,也可以多多进行反馈。还是那句话,共性需求会高优实现的。

用户使用文档

HttpRunner 首轮用户调研报告(2022.02) 中,用户使用文档相关的吐槽在所有问题中排名首位,远超其它问题。

这个问题的确非常严重,我们在 v4.0 中必须得改!

当前已经明确的改进措施有三条。

文档链接:https://httprunner.com/docs/

针对一些技术分享类的文章,也会同步到 TesterHome 社区和 HttpRunner 微信公众号

用户交流社区

HttpRunner 的交流途径挺多的,当前重点维护的包括:

如果上面的途径都无法满足你的需求,你也可以加我个人微信(leolee023),但需要在加好友的时候做下稍微详细点的自我介绍(至少包含姓名和所在公司,最好是再注明下期望交流的内容)。

总结

以上便是 HttpRunner v4.0 发布将带来的主要变化。在今年的 MTSC 大会的开源专场,我也会对 HttpRunner v4.0 的设计思路和核心原理进行分享,到时候可以线下当面做更多的交流。

最后再做个小预告,我们团队基于 HttpRunner 研发的一体化 API 测试工具 QuickRunner 已经完成了初版迭代,很快就要面向社区开放体验了,感兴趣的朋友可以先关注下。

最后的最后,开源不易,要是 HttpRunner 对你有过帮助,麻烦帮忙给个 ⭐️star⭐️ 鼓励下吧。

https://github.com/httprunner/httprunner


↙↙↙阅读原文可查看相关链接,并与作者交流