案例分享｜MeterSphere接口测试在互联网零售平台朴朴超市的实践分享

案例分享｜MeterSphere接口测试在互联网零售平台朴朴超市的实践分享 - FIT2CLOUD飞致云的个人空间 - OSCHINA - 中文开源技术交流社区

编者注：本文作者为互联网零售平台朴朴超市的林拥龙。

朴朴超市是一家30分钟即时配送的移动互联网购物平台。超市内商品品类主要包含：水果蔬菜、肉禽蛋奶、粮油调味、酒水饮料、休闲食品、个人护理、化妆品、清洁用品、日用百货等，日常生活所需品类一应俱全，一站式购齐。用户足不出户，即可在手机上随时随地搞定日常生活所需。

朴朴超市（以下简称为朴朴科技）希望以创新的商业模式，高效的仓储配送模式，打造出客户体验超越现有主流电商网站的新一代B2C电商平台。以技术为核心驱动力，提升效率降低成本；以30分钟送达的速度、更低的价格为用户省时省钱，打造极致体验；以可靠的品质推动中国电商环境改善，同时推动中国食品安全进程，成为一家受到消费者喜爱、贡献社会价值的优秀互联网公司。

为了满足公司高速发展的业务需求，朴朴科技的测试团队在提质增效的道路上不断摸索。测试团队很早就意识到单纯靠增加人力来提高业务测试的交付速度已经不是一个优质的选择，同时业务复杂度的持续增加也给测试工作带来新的挑战。

为了保障需求的交付速度，在功能测试方面除了常规功能的测试手段外，我们也跟大多数企业一样展开自动化测试，其中接口自动化测试是通过“Java+TestNG+Jenkins”等工具的组合来实现的。在执行了大半年后也完成了线上P0接口的持续集成测试。

但是很快我们就发现测试开发对业务的熟练度总是不尽如人意，如何才能让自动化测试的每一个用例请求都带有丰富的业务逻辑成为了测试工作的新痛点。

为此，我们调研了主流的自动化测试平台，最后选择了看上去最可能快速、高效、轻松地学会的MeterSphere一站式开源持续测试平台。

测试现状与思考

朴朴科技的测试团队有将近70人的规模，隶属于朴朴集团的研发中心，各个产品线并行在测项目超过30个并且全部基于微服务架构。主要包含App端、功能、接口、UI、性能、Elasticsearch、大数据、运维平台、中间件等测试内容。由于日常工作中普遍存在项目交付周期短、任务重、测试时间比较紧张的情况，很难做到测试的100% 覆盖和回归。

结合这些因素进行考量后，相对于已有的单元测试、系统测试（UI、集成等）等实践成本较高的测试内容，我们选择将接口自动化测试纳入功能测试同学的岗位职能，通过精准测试来指导回归测试，运用接口自动化增加测试频率，并且使用覆盖率鉴定测试有效性。

因此，自动化用例的生产速度就是我们必须要解决的问题。根据目前已有的策略，摆在我们面前的选择有两个：一是自研平台，二是购买SaaS服务或引用开源平台。鉴于其他测试平台的自研经验，最终我们被MeterSphere的场景用例编写功能所打动。

■ 业务项目：从线上流量监控平台、核心业务以及核心流程梳理出P0接口与场景，在功能测试的同时借助Chrome的F12、Charles、Postman、JMeter、TestNG、HttpRunner等工具，以手工抓包和录制脚本的方式验证页面外部接口请求和响应断言；

■ 运维项目：针对公司内外运维系统的接口进行测试，这类项目数量大、周期短，且每个项目接口设计方案均不相同，牵一发而动全身，稍有不慎就会出现重大的线上故障。通常情况下，我们基本都是通过Code进行UT与FT的自动化测试保障。

另外，各项目对外的HTTP接口多达上万个接口（不包含Dubbo、SQL、Elasticsearch等），HTTP接口需要统一通过Swagger进行维护。另外，项目还需要进行单接口测试、基于业务场景的多接口测试，需要长期迭代维护接口测试用例和脚本。

日常测试工作的痛点

朴朴科技测试团队在多人协作，以及测试与开发、运维、产品之间的协作上存在一定的困难。MeterSphere一站式开源持续测试平台恰好能够解决这个问题。对于我们来说，MeterSphere的一站式持续测试能力是非常吸引人的。

在日常的测试工作中，各测试组进行接口测试的现状各式各样，无论是用例管理方法还是策略都各有不同，而这种状况甚至会出现在仅针对同一个业务产品的情况中。比方说，测试工作有基于HttpRunner框架开展的，有基于JMeter、Postman开展的，各类测试脚本难以统一规范与整合，更无法进行统一管理。另外，项目之间人员效能、产品质量也无法合理地进行度量和横向对比，持续构建更是一个难以实现的课题。

与此同时，接口测试用例的执行在开发阶段的自测环节没有打通。我们希望由测试人员编写好接口测试用例，甚至培养开发自行编写，交由开发人员完成测试准入，通过后由测试人员进行最终的验收。而不是由测试人员去反复执行用例后再将结果通知到开发人员。这看似简单的环节，由于没有统一平台的支持，只依靠Postman、Git、Jenkins等工具维护用例脚本，在开发和测试之间想无缝对接是很难实现的。

我们的接口测试平台，除了对用例编写有要求，还需要对接其他的测试平台，比如精准测试、CI/CD等，需要将接口自动化测试接入到各个研测流程和调度工具。

MeterSphere持续测试平台的优势

在调研了包括一些大厂的SaaS平台，以及一些开源平台在内的各有特色的测试平台后，我们发现MeterSphere开源持续测试平台有着很强的易用性，测试团队很容易上手使用。随着使用的深入，我们也发现了MeterSphere越来越多的优点，总结下来基本上包含以下几方面的优势：

1. 切换成本低且易上手

无论是对传统手工功能测试，还是对接口自动化测试来说，MeterSphere平台的易用性设计都非常不错。特别是用例编写的环节，但凡有过一年互联网产品测试经验的同学都可以很快上手。本司测试团队从试用MeterSphere到实际输出2000多条测试用例只经过了短短一个月的时间；

2. 优秀的场景用例编写功能

当前我们已经实现了接口测试平台联动CI/CD研发流程，可以轻松完成精准测试推荐、接口自动化及覆盖率的整体测试闭环，并输出准入/准出测试报告。

① 接口定义：通过Swagger快速实现接口定义，并可实现定时同步，甚至是一键同步的导入功能；

② 单接口接口测试用例：MeterSphere支持定义各类请求、参数化、关联、断言这些通用能力，特别是JSONPath的快速断言和List提取参数传递更是高效；同时，扩展了前置脚本、后置脚本、SQL、参数提取、全局设置等更多的利器，支持BeanShell、Python等多种脚本语言。比较可惜的是Python只支持基本库，不过即便如此，目前MeterSphere依然可以基本满足各项目绝大多数的接口测试场景；

③ 场景接口测试：除了完成单接口的正反向常规接口测试外，我们还需要根据业务场景进行有效、有意义的接口请求，从而提升用例质量。场景用例比较复杂，需要预置基础场景、数据库以及一些第三方接口，还要考虑到业务的时效性。在这方面MeterSphere表现良好，不仅可以支持接口与场景的引用、常用的各类控制器以及自定义请求，脚本也足以编写出80%以上的复杂场景。

④ 灵活的用例Tag：除了针对用例进行级别与类别的定义，MeterSphere还支持自定义Tag的功能，可以很好地完成各类测试策略的用例过滤筛选。

CI/CD的落地

MeterSphere开源持续测试平台可以有效地提升自动化测试用例的生产速度，以自动化测试的方式提升软件的持续交付能力。

在引入MeterSphere后，我们试行了由测试人员并行编写接口测试用例，通过CI/CD流程整合公司各平台调度自动化测试，由开发人员自行执行自动化测试计划通过后提测，从而减少测试执行过程中的反复沟通，实现测试的左移。为了实现测试左移也间接规范了开发的接口设计规范，否则测试用例无法编写且执行通过率低。

此外，通过“精准+自动化测试+覆盖率测试策略”进行兜底，我们在提升测试效率的同时也增加了免测需求的发布频率。

期待改进之处

最后谈谈对MeterSphere开源持续测试平台的一些期望和改进建议，希望这个开源项目能够越做越好：

■ 尽早支持Python3。大部分的测试人员从业者基本都是选择Python3作为入门语言的。MeterSphere如果支持Python3对用例进行数据转换，会大大提高平台的易用性和用户数；

■ 场景用例支持的控制器可以多参考Pytest，例如Skip、Re-runs、失败退出等功能；

■ 优化报告的可读性。一方面，报告在多层嵌套场景引用时容易发生步骤错乱；另一方面，在步骤较多的场景下进行错误定位非常费时。关于这方面的内容可以参考Allure报告的步骤详情。