接口测试解决方案进阶之路

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

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

1.1 一个“活着”的接口

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

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

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

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

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

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

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

在业务的发展过程中，对于接口的测试与管理，遇到了很多问题和瓶颈，如下也许会感同：
同一件事情被多人重复做了:
开发人员在开发完一个API接口，会部署到开发环境中，然后通过自己写自动化脚本或者利用 POSTMAN工具验证一下这个API 接口是否符合预期，这时候其实已经做过一个简单的API测试了。到了提测阶段开发会将写好的API接口文档给测试人员，测试人员会部署代码到测试环境中去，然后通过 testNG 或者其他自动化测试框架写接口测试用例，我们发现，API的正向用例测试，开发人员做过一次，测试人员用不同的方式又做了一次，有没有可能开发人员做完后，测试人员就可以直接拿来在测试环境里面用呢?
开发提测的质量不可度量:
开发人员提测，一般只是执行一下冒烟测试用例，提交接口文档，口头叙述一下这些接口我在开发环境都验证通过，符合提测标准了。但是对于测试人员来讲这个口头叙述是没法 来度量提测的质量的，测试人员缺少客观的数据来评估接口的质量是否符合预期，从而导致后期因为质量问题出现版本回退的现象，拖延了开发周期。有没有什么办法来客观的度量开发的提测质量呢?
API 接口的变动引起的叠加效应:
API 接口变动是常有的事情，但是现有的流程中，一个接口的变动会牵扯出一系列的变动，接口文档的变动，接口测试用例的变动，接口测试代码的变动，持续集成的变动…， 时间成本瞬间提高。有没有办法只要一个地方修改了这个变动，那么其他所有的事情都解决了呢?

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

接口测试的ROI = f（成本，收益），要想提升ROI，那么就应该做两件事情：减少投入成本，增加使用率。
减少投入成本，可以从以下几个方面入手：

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

增加使用率，可以从以下几个方面入手：

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

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

二、接口测试与管理的实践

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

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

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

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

2.2 接口测试执行的5个多

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

• 多粒度：单接口、接口场景、执行集
• 多环境：测试环境、预发布环境、生产环境
• 多角色：开发、测试、运维
• 多数据：global数据、local数据、temp数据
• 多阶段：开发调试、自测冒烟、功能测试、发布验证、线上回归、持续集成、线上监控
  
  在接口测试执行层面分析面临的问题及挑战，涉及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小时监控
• 完善的告警通知机制
• 接口返回码监控
• 接口异常监控
• 接口性能监控
• 接口业务逻辑监控
  
  结合内部监控系统完成对接口异常、返回码、性能等的监控，而业务逻辑定向监控依赖GoAPI接口管理平台实施从监控、告警、处理、归档、统计形成有效闭环，如下图示是1个业务线的监控实施情况：

2.4 接口测试与管理的收益

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

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

GoAPI 是围绕接口全生命周期管理、提升研发与测试效率为目标的团队协作平台。平台提供便捷的接口管理，无门槛与多维度的自动化测试，完善的 OpenAPI 扩展等多种丰富能力，大幅降低企业研发和测试成本。体验试用：GoAPI接口测试平台

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

【关键总结】
一个平台的诞生一定是源于业务的问题与挑战不断的演进而成；
如何提升ROI，其核心是围绕着减少投入成本和增加使用率；