首先，此偏文章来自我公众号的第一位 partner，既感谢加入，又十分鄙视的延期给我提供稿子，当然，我们并非全职投入，最初的初心，其实是想当自己学习的总结，知识的积累，若能对他人再起到一些帮助，就更好了。

关于接口测试，资料太多，分享太多，这也正说明了接口测试在测试中的地位。而我们的理解我觉得达不到多么高深的地步，所以这篇文章不敢在用 “我们到底该如何。。。” 之类的标题了，转而想，叫做我们应该更好的把接口测试做起来。

随着前后端分离、微服务、CI/CD 越来越流行，接口测试也更多的进入各个公司的规划，今天主要是梳理一下对接口的一些理解，并将其分享给大家，希望能有一些作用吧。

先从接口测试的地位说起吧

从上图中可以看到接口是服务对外的 “外交官”，从代码质量层面来讲，底层函数的完整覆盖单元测试将是更好的选择，但是这属于理想情况，当前互联网产品的特色用雷总的话来讲就是：专注、口碑、极致和快。而一个 “快” 字很无情的将完整覆盖消除，很多公司为了更快的抢占市场和应对市场变化，甚至没有单元测试，这里暂不讨论其错对，正是这种问题的产生使函数上层的接口变得更为突出，首先接口不像函数，它本身即承载着业务责任，其次它同样包含着一部分前端的功能需求，最后它的返回值本身也是对底层函数的一种验证。

接口测试的官方定义为：测试系统组件间接口的一种测试。其目的只要是验证接口的正确性和稳定性，基于其目的做以下的用例设计，设计思路主要分为两个维度，一个是接口本身，一个是接口功能。前者是接口本身的稳定性，后者是业务流。其中接口本身即是对接口自身属性的验证，接口功能是对接口为满足某些业务需求而设计的逻辑功能的测试，而接口本身的稳定性这里并不是指其业务场景中的性能，指的是接口本身的性能及稳定性。至于最后的业务流，只是对接口间业务数据传递做的一种验证，从某种程度上来说，如果接口功能和接口本身覆盖足够完全的时候，业务数据流转验证已经被包含在上述两个验证中。之所以把它单独提出来，是因为在许多不懂测试原理的管理层眼中，仍然会觉得这种验收级的业务数据流转覆盖在任何场景下都是必须的。

也许会有人有这样的疑问，如此设计那就是维护工作量是怎么样的？的确完整的接口测试设计本身就是很大的工作量，如果项目变更较为频繁或架构设计并不合理的时候，维护的成本是一定要提前考虑的。业务稳定性及用例设计策略是所有自动化用例的关键。如果本身业务层面变动较大，那么类冒烟这样用例少覆盖点重要的设计策略就较为实用；反之，本身业务变动较少，增量业务较多的项目，完整覆盖的自动化测试投入产出比将更高也更贴近于理想中的自动化测试项目，同时很多 Team 在做的时候会将数据分离进而做成数据驱动，强烈推荐。以下是针对各种测试场景需求的一个划分：

策略的设计理解起来并不困难，这里就不对其做展开说明了，这里要注明的是每个项目有每个项目的特性，同样不同公司对测试的要求也不尽相同，没有满足万法的规则，只有适合特性的策略，所以如何能够让每一项技术尽快落地同时又能起到作用，则是每一个管理者应该重点思考的。

接着我们再聊聊接口工具的事，随着接口测试越来越被人们关注，更多的接口测试工具也如雨后春笋般的出现在行业内，下图就是我个人对现有部分接口工具做的一些对比，当然有些可能我了解的并不如工具设计之初那么深刻，仅给初涉者做一些参考吧。

Jmeter，当前主流工具之一，使用便捷，支持多协议且支持自主脚本，而且属于开源工具，很多大型公司都根据各自公司需求及项目特色进行二次开发，并能很好跟 CI 工具集成，推荐度五星，当然这个五星有个人偏好存在，后续会为大家讲解一个个人使用 jmeter 实现接口测试的一个实例。

自主研发工具最大的好处就是可以根据当前协议、需求、实际操作人等因素设计完全满足自身需求的接口工具。但缺点同优点同样明显，它对工具维护人员有很高要求，例如较高的技术要求、扎实的测试知识并对项目特性有很好的理解，虽然它有很大的局限性，但是它的优点 ‘一美遮百丑’，仍然让很多公司对它念念不忘，故而推荐值为四星。

Loadrunner，性能测试主流工具之一，它支持的协议远不止我列出的这些，它的功能也是业内公认的强大，但是为什么只有三星推荐值那？首先从产品角度，它是收费软件且费用不菲。其次从功能角度，它的强大使它的关注点并不局限与接口测试，换句话说使用它做单一性的接口测试是一种浪费。

Postman，开发常用的接口调试工具之一，它跟 Loadrunner 恰恰相反，它的功能较为轻量，开发人员使用较多，但不可否认它存在的意义，故而推荐值为三星（无法对接 CI 的，一定是限制我们提高整体生产力的）。

SoapUI，开源工具，支持 SOAP 和 HTTP 协议，支持自定义脚本，同样可接入 CI 工具进行持续集成，个人用的不多，但是感觉接口编写过程中较为繁复（也许并未学到其精髓），个人偏心的将其推荐为四星，哈哈，不喜勿喷。

以上就是我对现有主流工具的一点个人倾向和描述吧，最后以两张张近 12 个月内以上几款工具的 google 全球搜索和国内搜索情况做一个结束吧，这里就不对这两张图做过多的介绍了，仁者见仁智者见智~~

最后，和大家分享一个实例。

既然讲项目的接口测试，那就不得不先介绍一下项目背景，首先我在这段经历中是乙方，没错！这是一个外包项目，客户的需求是一款中后端的店铺管理系统，系统当时在我介入的时候已经存在了两年多，这个项目在这两年之间只有 BA 没有测试，导致项目后期甲方对项目的测试覆盖率、质量标准和 UT 存在很大的疑问，当然疑问产生的原因就不多做复述了。

说说项目本身吧，项目功能较为繁复，框架设计采用前后端分离的方式并向微服务转型，甲方为保证后期的业务可扩展性，所有业务功能均为人工配置，也就是说软件本身的功能远远大于业务需求，测试工作如果从覆盖的角度来说不是一般的 ‘坑’，值得庆幸的是那时对接的测试接口人是一个有十年工作经验的专业人士，这大大减少了我对后续设计的测试策略的解释难度。

切回接口设计的正题吧，由于代码初期设计的并未做很好的解耦，导致新人在代码的后续修复历史问题和需求扩展中影响范围较大且无法明确边界，故而为保证项目的基本功能可用性，故引入接口测试，从刚才的介绍的过程中大家肯定以为我做的是业务类回归接口测试设计了，对吧？但是事实是由于甲方高层对需求重点并不了解，只追求更高的覆盖率，故而接口测试的意见被采纳，但范围变为全接口测试覆盖（所以项目实施方案不仅看项目还要看金主的意思）。

---------------------------------------------------实施方案及设计说明---------------------------------------------

项目说完了，说说过程吧。由于人力问题，为保证当前功能的上线质量，接口测试以伴随功能迭代方式 + 加班模式进行，初期的架构设计较为简单，仅对新增和修改接口通过构造测试数据进行新增和修复点的验证，新增接口进行全量覆盖，修改的接口进行修复点覆盖。但是问题来了，首先甲方再次对修改的接口进行增量点覆盖存在异议，希望也同样进行全面覆盖；其次由于数据处于构造状态，很多系统设置级的数据经常被开发或客户变更，导致用例失败（由于已经集成 CI，故客户每日可看到接口通过率），虽然我们已经设定了专人每日跟进并处理、回复告知问题原因，但是甲方仍不希望看到这类错误，故这种简单的架构需要推翻重做。

如何根据业务数据进行业务结果分析那？数据源将是所有运算产生的根本，基于这样的思路，最终设计为基于关键数据的数据索引及逻辑运算的方式设计架构（参见下图），首先分析接口请求数据，选定关键数据作为第一层数据，关键数据选定标准基于业务数据及关联性高低来评判。然后通过这些数据，根据数据关联关系在对应的数据库中查出接口入参所需的其他数据作为第二层数据。最后第三层数据也可以称为业务数据，它是基于前两层数据，按照接口本身的业务逻辑功能实现通过编写脚本的方式进行二次计算所产生的数据。将接口返回的结果数据与第三层数据进行断言比对，最终用于验证接口业务功能实现的正确性，并展示到对应的报告中。

---------------------------------------------------jmeter 框架、CI 集成及报告展示--------------------------------------------
基于上面的设计图，jmeter 脚本框架设计如下，分为公共区和接口功能验证区两部分
公共区包含：
数据库链接区
公共数据存储区
HTTP 请求及消息头管理区

接口功能验证区：
业务数据池（包含第一层基础数据和第二层关系数据）
接口自身功能验证区（按设计用例划分）
入参自身约束验证
入参必填性及非必填性验证
出参验证
接口业务功能验证区（按用例组成划分）
私有化自定义脚本
私有化业务数据池（第三次逻辑数据）
私有化断言区

脚本完成后如何触发那？针对于这个问题，引入了 jenkins（jenkins 安装大家可自行在网上搜索）。
最终报告展示，报告以 html 网页样式生成，显示报告时间，总共执行数量、失败数量、成功率、平均响应时间、最小响应时间、最大响应时间和大于等于 90% 事务的响应时间，详细页展示对应的事务或接口用例名称、采样数、失败数、成功率、平均响应时间、最小响应时间、最大响应时间、大于等于 90% 事务的响应时间及展开收缩按钮，模板样例为 jmeter 报告结果模板 jmeter-results-detail-report_90Line.xsl（大家可自行上网搜索下载，也可根据个人或项目需要进行二次调整）

---------------------------------------------------小结---------------------------------------------

虽然这个架构做了很久，客户的认可度也较高，但是我仍然觉得它还有可改进的空间，它最大的问题是维护成本仍然很高，一个 20 个参数的单接口，整体覆盖后用例数量达 150 条，而这样的接口存在较多且变化较为频繁（所以数据驱动一定是大家要做的过程中考虑到的）。虽然这种高成本问题在上面说明项目的策略选择时已是可预见的，但是作为一个技术人员高层的方向及思维永远不是我们考虑的重点，我们更多的关注应在于如何解决当前现有的技术问题及架构问题，由于个人原因，后续退出了项目，以至于设计优化也就到此为止了，有想法的朋友可以继续针对自己项目深入思考并持续优化，不断改进提高，从而提升自己个人价值。

PS：由于个人原因，在做完架构和大体方向后就离开了项目，上面后续的完善都是又几个妹妹辛苦编写完成的，再次感谢大家对本文编写的支撑和帮助。