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 已有性能和放弃前向兼容的根底上，重点会在如下几个维度进行晋升：
- 简略易用、功能强大：这是 HttpRunner 始终以来从未扭转过的指标；在放弃简略易用的根底上，v4.0 会重点反对双执行引擎、多网络协议、多编程语言、多测试用处等性能
- 数据精准：v4.0 致力于成为一款专业级的 API 测试工具，不论是单用户的接口申请耗时和网络性能采集，还是高并发下的性能测试指标，测试后果数据精准是底线，必须通过严格的 benchmark 测试
- 海量并发：重点加强压测能力，占用资源更少，发压效率更高，单机轻松反对万级别并发压力，联合分布式稳固撑持百万级实在并发压力测试
- 开源生态：充沛与 API 相干工具和规范进行买通，加强数据流通性和二次开发可扩大能力
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 引擎无需依赖 <br/>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 的测试用例脚本反对：
- 文本状态：JSON、YAML
- 代码状态：pytest 和 go test
并且动静运算逻辑（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 都能够反对。
以后已反对的插件语言：
- Go
- Python
- Java（打算中，期待奉献）
这部分能力曾经独自抽离出了一个根底组件，有趣味能够详见 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 位真正意义上的外围开发者：
- debugtalk：负责我的项目的整体架构和布局；哪里有砖哪里搬
- xucong053：奉献了多机负载分布式压测能力、Prometheus 性能数据采集能力、参数化数据驱动、html 报告等
- bbx-winner：奉献了 HTTP2/WebSocket 网络协议、benchmark 数据准确性测试等
- billduan：重点投入 pytest 引擎局部，奉献了 thrift RPC 协定、集成 SQL 调用等
在这里也十分欢送更多的敌人参加进来，特地是在工作中重度应用 HttpRunner 的敌人，「独行者速，众行者远」。
用户调研问卷
为了更好地收集 HttpRunner 用户反馈，明确需要迭代门路，咱们从往年开始尝试了用户调研问卷的模式。
- HttpRunner 用户调研问卷 => HttpRunner 首轮用户调研报告（2022.02）
- HttpRunner 增值服务调研问卷
- QuickRunner 用户需要调研
通过调研问卷，我收集到了十分多贵重的反馈和倡议，这对 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/
针对一些技术分享类的文章，也会同步 HttpRunner 微信公众号。
用户交换社区
HttpRunner 的交换路径挺多的，以后重点保护的包含：
- TesterHome 社区：开设了 HttpRunner 主题板块，这也是 HttpRunner 我的项目的发源地
- 微信公众号：不定期推送 HttpRunner 重点资讯（搜寻 HttpRunner 进行关注）
- GitHub Discussions：GitHub 上开设的 discussions 社区板块（布告、想法、答疑、分享）
- 微信交换群：为了保障交换品质顺便设置了一些门槛，须要认真填写一份调研问卷
如果下面的路径都无奈满足你的需要，你也能够加我集体微信（leolee023），但须要在加好友的时候做下略微具体点的自我介绍（至多蕴含姓名和所在公司，最好是再注明下冀望交换的内容）。
总结
以上便是 HttpRunner v4.0 公布将带来的次要变动。在往年的 MTSC 大会的开源专场，我也会对 HttpRunner v4.0 的设计思路和外围原理进行分享，到时候能够线下当面做更多的交换。
最初再做个小预报，咱们团队基于 HttpRunner 研发的一体化 API 测试工具 QuickRunner 曾经实现了初版迭代，很快就要面向社区凋谢体验了，感兴趣的敌人能够先关注下。
最初的最初，开源不易，要是 HttpRunner 对你有过帮忙，麻烦帮忙给个 ⭐️star⭐️ 激励下吧。
https://github.com/httprunner…