【解决方案】1万+接口测试与管理的进阶之路

**【关键导读】**

本文着重详解了接口测试解决方案的进阶之路，如何从典型的java+TestNG+Jenkins，围绕着提高接口测试ROI（减小投入成本，增长使用率）的目标，一步步结合业务应用实践，打造了一个高效的基于接口的团队协做平台GoAPI，让接口测试人人能作，人人能用，随处可用，以及如何作到1万+接口的业务的接口测试与管理。

1、历史的接口测试与管理

1.1 一个“活着”的接口

接口是应用开发中必然存在的产物，不管你是开发、测试仍是运维人员，你都会与接口产生千丝万缕的联系。开发是接口的创造者，他们定义了接口，同时赋予了他们血肉之躯。测试是接口的健康守护者，不管在哪一个阶段，都在默默的为他们找出伤害他们健康的“蛀虫”（To BUG）。听了个人YY，有没有以为接口是有生命的，若是没有，那么能够看下下图

接口的“成长历程”java

如此看来，接口是具备生命周期的，结合软件研发流程来看的话，在不一样的阶段，不一样角色都会围绕着接口作不一样的事情。以下，一个“典型”的接口生命周期

一个“典型”的接口生命周期node

接口生命周期中的每个阶段都须要获得“细心的照料”，这就涉及到接口的测试与管理。接下来，将从历史的进程来看下，接口是如何被获得“照顾”的。

1.2 "历史”的接口管理与测试缩影

想到2014年，那是一个····的年头，咱们的接口管理与测试是这么玩的，接口文档管理采用的是wiki，接口手工测试采用的是Postman/Jmeter，接口自动化是基于TestNG编写的测试框架，接口线上监控是采用的Jenkins CI驱动。

2014年的接口测试与管理python

能够看下当时封装的接口自动化测试框架

Java+TestNG接口测试框架web

提及框架特色当时还很“自豪”的讲出了几大特色：特色:  Annotation  依赖性测试  支持并发测试  支持错误重运行测试  参数化测试  支持测试分组  经过testng.xml来管理测试  详实的报告，可按照本身须要进行二次开发定同时在当时也调研过python的方案，Python Nose 方案，二者对好比下：

在业务的发展过程当中，对于接口的测试与管理，遇到了不少问题和瓶颈，以下也许会感同：

**同一件事情被多人重复作了:**

开发人员在开发完一个API接口，会部署到开发环境中，而后经过本身写自动化脚本或者利用 POSTMAN工具验证一下这个API 接口是否符合预期，这时候其实已经作过一个简单的API测试了。到了提测阶段开发会将写好的API接口文档给测试人员，测试人员会部署代码到测试环境中去，而后经过 testNG 或者其余自动化测试框架写接口测试用例，咱们发现，API的正向用例测试，开发人员作过一次，测试人员用不一样的方式又作了一次，有没有可能开发人员作完后，测试人员就能够直接拿来在测试环境里面用呢?

**开发提测的质量不可度量:**

开发人员提测，通常只是执行一下冒烟测试用例，提交接口文档，口头叙述一下这些接口我在开发环境都验证经过，符合提测标准了。可是对于测试人员来说这个口头叙述是无法来度量提测的质量的，测试人员缺乏客观的数据来评估接口的质量是否符合预期，从而致使后期由于质量问题出现版本回退的现象，拖延了开发周期。有没有什么办法来客观的度量开发的提测质量呢?

**API 接口的变更引发的叠加效应:**

API 接口变更是常有的事情，可是现有的流程中，一个接口的变更会牵扯出一系列的变更，接口文档的变更，接口测试用例的变更，接口测试代码的变更，持续集成的变更......，时间成本瞬间提升。有没有办法只要一个地方修改了这个变更，那么其余全部的事情都解决了呢?

“变更”的叠加效应docker

以上的问题都会致使在接口测试与管理上效率低下，也就是咱们常说的ROI低下，一个直观的分析图示以下

接口测试与管理ROI分析api

接口测试的ROI = f（成本，收益），要想提高ROI，那么就应该作两件事情：减小投入成本，增长使用率。减小投入成本，能够从如下几个方面入手：

减小用例编写的成本（1个接口/10个用例/2小时）
减小用例优化的成本 (用例描述清楚，很难分层优化 )
减小用例维护的成本（1个接口变更，平均维护1小时）
减小工具开发的成本（公共测试服务无法公用，重复造轮子）

增长使用率，能够从如下几个方面入手：

手工能用
人人能用
当工具用
各个阶段用

为此围绕着接口测试与管理的ROI提高专项活动就不得不实施起来。从接口测试与管理的全生命周期分析所面临的挑战。

问题与挑战安全

2、接口测试与管理的解决方案进阶

2.1 接口测试编写的6大要素

如何真正的减小“用例编写、优化、维护”的成本，应该要分析接口测试用例编写应该具有哪些部分，从中提取出能够优化的元素进行细致的分析和对症下药。以下所示在接口测试编写过程当中所列举的6大要素：

接口测试编写的6大要素markdown

针对其中2大要素示例展现下分析所面临的问题及解决方案

**【面临的问题】**

首先要明确的是参数化和生成器的定义，参数化：即把具体值换成参数形式来表达的过程就是参数化。生成器：根据需求去产生具体特性的值。能够预知在构建一个接口测试场景的时候，一个接口入参，它多是固定值，亦或是变量，而变量的生成，须要根据需求按照场景去特定的去生成，好比建立账号须要随机生成，那么就须要随机数；参数的签名和加解密；时间戳参数的构造；等等；另一个层面，参数是具有位置属性和做用域属性的。位置属性中可能在路径、URL、请求体或者请求头。而做用域属性多是对全部接口测试场景全局有效的公共参数，也多是在一个场景中生效的，甚至于只是临时产生的。如此看来，要解决参数化及生成器的问题，要结合上述所分析的特色。

**【解决方案】**

针对参数化及生成器的解决，是做用于不一样的接口测试场景及接口测试阶段。参数化的实施分为两大类：通用型参数化和业务型参数化。通用型参数化实施是围绕着GoAPI接口全生命周期测试平台去完成的，业务型参数化是自研测试数据服务平台

2.2 接口测试执行的5个多

从接口测试执行的多维度分析，涉及5个多：

多粒度：单接口、接口场景、执行集
多环境：测试环境、预发布环境、生产环境
多角色：开发、测试、运维
多数据：global数据、local数据、temp数据
多阶段：开发调试、自测冒烟、功能测试、发布验证、线上回归、持续集成、线上监控

接口测试执行的5个“多”架构

在接口测试执行层面分析面临的问题及挑战，涉及4个层面：

执行环境受限
使用阶段受限
使用角色受限
线上监控不成体系

2.2.1 执行环境受限

分析历史对于采用java+TestNG+ Jenkins的典型接口测试框架，在执行环境层面面临的问题有以下3点：节点资源利用率不高、资源配置存在冲突、扩展节点迁移不便捷。如此第一阶段实施，在当时采用的是“容器化”的思路：Jenkins集成docker实现slave容器化，根据不一样环境构建不一样类型的slave node镜像模版，每次执行自动拉起对应容器，执行完整自动销毁。

第二阶段的实施，在完成接口测试平台化以后，一样的思路解决问题，也就是在GoAPI中引入执行器的概念，而每个执行器都是一个容器，容器内部会启动一个服务与GoAPI平台联动。不管你是哪一个环境，能够动态在执行接口测试任务的过程当中修改对应的hosts，保证环境的无缝切换，完全解决了执行环境受限的问题。整个容器管理采用的是rancher+K8s，以下图所示

这种解决方案具有6大特色：

多节点：稳定可靠
多环境：知足平常功能测试、回归测试、预发布验证
多机房：快速验证异地多机房的高可用架构
可管控：私有化部署线上监控执行器，对线上测试请求进行安全管控
可调度：与自动化发布集成，发布后马上调度执行器，触发自动化验证
可共享：共享执行器信息，方便开发同窗快速自测，协同QA测试

2.2.2 接口测试使用阶段受限

当你解决了接口测试编写及执行过程的问题，将各个业务对应的接口覆盖度提高到了95%以上的时候，就须要开展实施的是如何将已有的自动化价值最大化。而如何最大化，就是要让已有的自动化用例使用贯穿整个软件开发周期，且使用者要包含开发、测试、运维等

结合以上图示分析，存在的问题是实施阶段不完善，角色使用受限。那么从解决方案来讲能够从如下3个方面实施：

结合持续集成实施开发自测验证
结合发布平台实施PE发布过程验证
结合GoAPI实施完整的线上接口监控

接下来看下这3个方面是如何实施的。

结合持续集成实施开发自测验证并发

结合持续集成实施开发自测验证

以上提供的是内部业务目前正在实施的持续集成pipeline，将在GoAPI上已有的自动化，归入持续集成链路，只须要经过GoAPI提供的很是友好的OpenAPI，一样的能够花点看剧的时间写个GoAPI执行驱动插件，也是极好的。以上流程扭转以下：

开发提交代码经过webhook自动触发构建，构建成功；
执行单元测试卡点，所有PASS且覆盖率卡点经过；
执行静态代码检查，联动sonar完成卡点判断；
打包镜像上传到私有仓库并执行部署服务；
调用GoAPI接口测试平台openAPI执行对应接口自动化；
调用smartauto智能UI自动化平台openAPI执行对应UI自动化；
调用npt性能压测平台openAPI执行对应性能自动化回归；
调用CR变动代码覆盖平台获取本轮变动代码覆盖率；
输出总体质量测试报告，涵盖多维度质量度量；

**结合发布平台实施PE发布过程验证**

某个业务线上应用集群上百台机器，而线上回归执行运行一次不能完整覆盖到每台机器上应用实例的可用性，可能会形成某台应用实例由于不可知因素带着问题上线，致使线上故障。那么对于PE而言，他们的诉求是但愿每次发布的每一台应用实例都是通过自动化回归过的，基于此，结合内部发布平台实施方案以下

发布自动回归方案

通常的发布平台都应该具有如下步骤：offline、deploy、check、online；先将当前实例下线，接着部署，而后check服务可用性，最后online到线上提供服务。只是当前check这一步只是健康检查，而非服务功能性验证。那么如此能够基于check扩展去调用GoAPI openAPI实施自动化执行，经过后再自动online。经过这个方案实施后，PE每次发布不再会“提心吊胆”，由于每个应用实例都是通过严格功能回归后上线的。以上从软件研发周期，针对开发自测、发布过给出了解决方案，但最重要的环节是线上接口监控。经过监控是否可以及时发现接口不可用，减小对用户的使用及体验是很是重要的，接下来就聊下在作线上接口监控所面临的问题及解决方案

2.3 线上接口监控闭环

回到2014年，基于java+TestNG+jenkins所实施的线上接口监控，所面临有4大挑战：

执行稳定性影响因素多（环境因素、用例依赖问题等）
告警机制不完善（只有单一的告警通知，且告警没有可配置策略）
失败分析耗时（基于TestNG执行日志分析以及用例场景链路数据依赖，耗时长）
未很好的造成闭环（告警准确率低，线上接口问题召回率低）

为此针对以上问题结合接口监控，分析监控应该具有6大要素：

持续稳定的7*24小时监控
完善的告警通知机制
接口返回码监控
接口异常监控
接口性能监控
接口业务逻辑监控

接口监控6大要素及解决方案

结合内部监控系统完成对接口异常、返回码、性能等的监控，而业务逻辑定向监控依赖GoAPI接口管理平台实施从监控、告警、处理、归档、统计造成有效闭环，以下图示是1个业务线的监控实施状况：

2.4 接口测试与管理的收益

围绕着减小投入成本和增长使用率两个方面进行了多项实践活动，使得总体的ROI获得了大幅度的提高。以下基于一个内部业务的统计分析

接口测试与管理的ROI

3、一个行业领先的接口测试平台

GoAPI 是围绕接口全生命周期管理、提高研发与测试效率为目标的团队协做平台。平台提供便捷的接口管理，无门槛与多维度的自动化测试，完善的 OpenAPI 扩展等多种丰富能力，大幅下降企业研发和测试成本。体验访问：[GoAPI接口测试平台](https://www.163yun.com/product/goapi?fromyice=M_juejin_6857026426718453768)

基于接口的团队协做平台

一个xx业务应用详情，来感觉下1万+接口的测试是如何作到的：

产品概览

接口测试

场景测试

执行集

【关键总结】

一个平台的诞生必定是源于业务的问题与挑战不断的演进而成；
如何提高ROI，其核心是围绕着减小投入成本和增长使用率；