9 - 基于客户反馈梳理HttpRunner痛点和优势

米哈游-平台部

基于 HttpRunner 搭建接口自动化测试体系

 

为什么选择 HttpRunner

背景

整个部门没有系统性的开展接口自动化测试，都是一些比较零散的个人项目，框架不同、风格不同，随着规模的扩大，无法有效的管理 case、统计以及评估产出收益比。

需求

希望搭建一套完善的接口自动化体系以便于更好的开展质量保障工作，对测试框架的期望包括：

• 易于上手不需要很高的学习成本
• 框架要灵活、扩展性高、最好有一定的受众方便交流
• 框架能统一用例格式
• 可以对执行的结果进行持久化存储用来进行分析
• 提供接入 CI 和巡检的能力

这样看下来 HttpRunner 似乎是不二之选。

 

HttpRunner 的使用情况

二次开发

• 小伙伴基于 HttpRunner v3.1.6 进行二次开发，定制化解决特定的使用场景
• 目前平台部门以 HttpRunner 作为用例执行引擎搭建了一个接口自动化的 Web 服务，用来满足调试用例、运行用例、定时任务执行用例、开发提交代码通过 CI 自动触发对应模块的测试用例、执行的结果会通过企业微信进行通知、告警，且内部制定了一套完整的工作流
• 接入了代码覆盖率，更好的衡量代码质量以及自动化 case 的覆盖率

使用场景

• 测试阶段通过手动调用运行用例服务、CI 触发进行测试环境辅助回归验证
• 上线之后通过 CI 触发、定时任务覆盖测试环境，线上环境则只通过定时任务进行巡检
• 平台部门的大部分业务基本都在使用中，接口自动化测试用例的数量 2000+，每分钟都会有 case 在运行

收益

• 明显减少回归测试的人力成本
• 通过机器的巡检发现一些偶现的问题
• 测试环境：能够第一时间发现服务的异常（比如配置问题、环境依赖问题、明显的代码逻辑问题），且自动通知相关开发同学进行处理
• 线上环境：通过高频率的巡检 case 检查服务的运行状态，第一时间通报异常

些许展望

• 对以上的功能进行完善以及补充，同时探索更多的可能性，比如结合 HttpRunner 的性能测试能力进行实战
• 最后希望 HttpRunner 做大做强哈哈～

 

有米科技-测试与工程质量保障部

基于 HttpRunner 建设自动化测试平台

 

为什么选择 HttpRunner

这几年公司重心逐步从一家移动营销服务商迈向一家移动营销大数据 SaaS 服务商，从基于客户端的全球广告 SDK 产品，转向基于以多维海量移动营销数据为基础的智能营销大数据产品。数据产品的质量保障逻辑跟客户端 SDK 产品有着非常大的不同，核心在于数据质量。在日常产品敏捷快速迭代中，如何保障产品数据的准确性、完整性、时效性、稳定性、一致性、合规性，给质量团队带来了前所未有的的挑战，此时单纯仅靠人工测试肯定是完全无法满足产品质量的需求。因此，深入开展自动化测试成为我们的必然选择。

自动化测试主要是 API 自动化和 UI 自动化，对于其中的 API 自动化，在 HttpRunner 之前，团队使用过各种各样的工具，比如 Postman、JMeter、Python Requests、Pytest、自研脚本工具等等，但总有一些不如意的地方。

主要问题是：

• 有些工具上手简单，但是效率不高，如 Postman、JMeter等；
• 有些工具效率很高，但是有一定门槛，无法让所有成员快速上手，如Python Requests、Pytest、自研脚本工具；
• 由于上述两个问题，同时团队各成员能力上下不一，另一方面产品在持续敏捷迭代，所以在一开始没能找到统一的共识工具，姿势不一，造成脚本维护成本增加，团队能力积累不明显，效率不高；

而 HttpRunner 的出现让我们如获珍宝，因为它就是我们自研脚本工具在努力的方向，相比其他工具，HttpRunner 优势明显：

• 小巧、灵活、功能齐全，满足日常数据接口验收需要；
• 开源，支持定制和扩展，可以进行 Web 可视化；
• 用例与代码分离，实现用例标准化，方便生成和转换，方便统一和维护
• 降低了使用门槛，适合不同团队成员，而且极大提升用例设计效率；

HttpRunner 的使用情况

通过借助 API 自动化开源工具 HttpRunner 和 UI 自动化开源工具 Cypress，经过一年多的努力和实践，我们的自动化测试覆盖到了公司所有的产品线，同时搭建了自己的 Web 自动化工具平台 AutoQA，并初步建立起了相对完整的自动化落地策略、自动化执行机制和自动化价值衡量指标，极大地推进了公司各条产品线的自动化测试进程和覆盖度。

核心亮点有：

• API 自动化用例 3200+，核心项目覆盖率平均 85%以上；
• UI 自动化用例 1500+，核心项目覆盖率平均 70%以上；
• 搭建了自动化测试平台，实现测试任务、用例、数据的复用和可视化，进一步提升日常质量工作的效率和推进公司质量工作全流程化上线；

后续展望

随着公司产品的发展，产品数据量、用户量的与日俱增，产品性能问题逐步也提上日程，后续我们质量团队将持续加大对 AutoQA 的投入，刚好结合近期 HttpRunner v4 底层更好的性能测试能力，来拓展 AutoQA 对性能测试任务的支持，打通自动化测试到性能测试的转换，提升对自动化脚本的复用能力，助力产品高效开展日常持续性性能测试。

也期待 HttpRunner 继续发光发热，早日实现对 UI 自动化测试的支持与落地。

同时，祝愿HttpRunner 早日成为行业家喻户晓的国人原创测试利器。

 

 

通用环球医疗-环球健康

使用 HttpRunner 实践接口自动化测试

 

为什么选择 HttpRunner？

我在刚接手环球健康项目时还没有接口自动化测试平台，接口的测试只是单接口调试，期间使用过 Postman、JMeter 等接口调试工具，后面随着项目逐步迭代，更新频率及更新需求与日俱增，接口数量也越来越多，接口自动化回归测试的需求提上了日程。

经过调研，选择了 HttpRunner 的 v2.5.7 稳定版本，考虑到如下几个方面的优势：

• 纯 Python 开源项目，比较符合当时组内技术栈，易于维护
• 基于稳定的 Python 框架搭建，稳定性基本有保障
• 业务脚本使用 Yaml 或者 Json 的形式维护，入门门槛低，脚本支持录制导入，相对方便
• hook、数据提取、环境及变量维护、数据驱动、动态加载、断言等功能可以满足构建复杂业务场景的接口用例集
• CLI 执行形式易于部署，快速集成 CI，集成 H5 报告模板，方便定时查看执行结果

HttpRunner 使用情况

适合的就是最好的，基于这个原则，一直在使用该版本，从未升级更新。

目前实现了互联网医院项目的主要业务流程相关的业务接口集成自动化脚本维护，项目接口维护总量共计 600+ ，其中使用 HttpRunner 维护起来的自动化接口有 100+，用例 200+。定时执行，基本上能保障主流业务接口被回归遍历到，采用定时执行+根据需要临时手工调度的方式，每天定时分析执行结果，主要业务流程接口的覆盖让版本更新时对新版本的质量有了些许底气。

后续展望

目前听说作者重新组建了产研团队，研发 GUI 版本及加强了压力测试方面的能力，将压力测试和接口自动化测试脚本统一维护，进一步解放测试资源，减少重建，非常期待新版本的落地，能够成为质量人从业路上的一把趁手的利剑。

 

 

大疆创新-互联网事业部

基于 HttpRunner 构建完整的自动化测试体系

 

为什么选择 HttpRunner？

大疆在高速发展的过程中，业务和人员都处于快速增长阶段。如何「低成本」地满足众多项目普遍存在的接口自动化测试、性能测试、持续集成、线上监控等需求，这对质量团队带来了非常大的挑战。

在 HttpRunner 之前，团队有使用过 Postman、Python Requests、pytest、Locust、Jenkins 等工具，但效果并不好。

主要的问题在于：

• 接口测试、性能测试、线上监控使用的工具相互独立，数据不通且存在大量的重复投入的问题
• 测试脚本形式风格迥异，团队协作困难，维护成本高昂

而 HttpRunner 恰好非常完美地解决了这些问题。相比于其它测试工具，HttpRunner 最大的不同在于如下几点：

• 一体化解决方案：一套脚本可同时支持接口自动化测试、性能测试、线上监控等多维度需求，投入产出比极高
• 约定大于配置：测试用例是标准结构化的，格式统一，方便协作和维护；同时也支持与 HAR/Postman/Swagger/Curl/JMeter 等工具对接，轻松实现用例生成和转换
• 高可扩展性：具有很高的可扩展性和二次开发能力，可以很方便地集成到各种测试平台
• 融入最佳工程实践：不仅仅是一款测试工具，在功能中融入最佳工程实践，极大地提升了团队的整体效率

HttpRunner 的使用情况

在 HttpRunner 的基础上，我们建设了一整套的自动化测试体系，包括功能测试用例管理平台、接口自动化测试平台、性能测试平台、持续集成、测试数据平台等。

核心亮点包括：

• 覆盖支撑了 10+ 业务线的项目，自动化测试用例总数 3000+
• 打通了功能测试用例管理平台（TestRail）和接口自动化测试平台，提升了回归测试效率
• 打通了接口测试平台、性能测试平台和测试数据生成服务，实现了测试用例和测试数据的复用
• 性能测试平台基于 HttpRunner 的底层能力，结合 PID 自动控制算法实现了智能加压的高级特性

详细的逻辑框架如下图所示：

在 2018 年的 MTSC 大会上，我们也分享了 HttpRunner 在大疆内部的实践经验，收获了非常多的好评，并被评选为服务端测试专场 11 个议题中的最佳议题。

PPT 链接：大疆互联网的一站式自动化测试解决方案（基于HttpRunner）

些许展望

基于 HttpRunner 的一体化测试平台从 2018 年建成以来，一直持续支撑着大疆互联网事业部各个业务线的自动化测试工作。即使在我从大疆离职 3 年后的今天，平台仍然还在维护使用。

前几天跟还在大疆的前同事收集了下反馈，当前平台主要存在的问题主要有 2 个：

• 平台底层还基于 HttpRunner v2.x 版本，想升级到最新版本遇到些问题
• 平台无法支持 WebSocket 协议的测试需求

所幸这都不是啥大问题，平台只需要针对 HttpRunner v4.x 做少量的适配改造，即可获得 HttpRunner v4.x 更多的网络协议支持和更强的性能发压能力。

 

 

 

当前现状：