5年经验之谈 —— 如何编写有效的接口测试？

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036【暗号：csdn999】

二、 测试原则

基础原则：

• 自动化：接口测试是非交互式的自动化执行，不需要人参与。
• 独立性：接口测试之间不应该相互依赖。
• 可重复：接口测试可重复执行，不受环境影响。
• 接口测试遵守BCDE原则，保障接口交付质量。 Border：边界测试。 Correct：正确的输入，正确的预期输出。 Design：按照需求和设计文档编写测试逻辑。 Error：错误输入，预期输出。
• 数据准备：数据准备通过系统服务进行，不能通过直接插入db方式。
• 可测性：对于不可测的代码需要进行重构成合理的结构。
• 覆盖性：接口测试需要覆盖所有UC，同时代码覆盖率和分支覆盖率应达到一定标准，新增代码必须被覆盖。
• 持续性：如果代码修改导致已有接口测试执行失败，必须修复代码问题或者测试代码逻辑。
• 时间要求：接口测试应该在项目发布之前完成，不应放到项目发布之后补充。

以上的基本原则应适用于所有层的自动化测试用例，在编写接口测试时，除了上面这些原则，还有其他原则需要遵守，先看一张图：

从系统角度来分析入口调用，以HSF服务为例：

• 外围系统调用由我们系统提供的服务。
• 系统执行了一堆代码逻辑，其中包含有分支逻辑。
• 系统执行过程中依赖外部HSF服务，进行了调用，并得到了返回值。
• 系统执行过程中依赖DB查询或者落地了数据，依赖缓存查询或者落地了数据。
• 系统执行过程中对外发送了消息。
• 给上游系统返回HSF执行结果。

有效接口测试的关键原则是要覆盖所有入口，mock所有依赖，校验执行过程中所留下的痕迹，总结如下：

• 入口覆盖：接口测试用例必须覆盖HSF服务入口、消息入口、定时任务入口。
• 依赖mock：在基本原则中，有可重复这个原则，即接口测试不能受环境依赖，需要mock掉对外依赖。但对于db依赖，不建议完全mock掉，一方面mock成本高，另外可能覆盖不到sql和表约束逻辑。
• 校验完整：有效的接口测试，应该具备完整的校验，没有校验的接口测试是没有意义的。只要执行过程中，留下的痕迹对业务有影响，都要进行完整校验，方能保障接口测试的有效性。 HSF接口返回值校验：按照场景和接口约定进行HSF返回参数校验。 DB校验：校验落地数据的正确性。 缓存校验：校验存入缓存中数据的正确性。 HSF依赖入参校验：通过mock工具获得依赖HSF调用的入参，进行入参校验。 消息校验：通过mock工具获得发送的消息对象，进行消息体校验。

三 、测试代码结构

在编写测试代码的时候，也应跟写业务代码一样，考虑代码的可读、可扩展、可复用性。同时也可以根据系统的业务特性，在测试框架的基础上封装适合当前系统的测试组件，提高测试代码编写效率，规范测试代码结构。

一个接口的测试代码，大概的结构如下：

1 、测试准备

依赖数据准备

很多时候，我们的测试有数据依赖，可能是配置数据，也有可能是业务数据(例如退款需要依赖支付数据)。

• 配置数据：可以通过定义配置文件来初始化配置。
• 业务数据：这类数据，禁止通过直接插入数据方式产生，而是应通过调用业务服务产生。

依赖mock

对于外部依赖，需要对被依赖的服务进行mock，避免真实调用。

接口测试入参准备

准备接口方面的入参。

2 、测试执行

调用接口方法，执行业务逻辑。

3、 测试校验

• 返回参数校验：校验接口的返回参数。
• DB：校验DB落地数据。
• 缓存数据校验：校验落地到缓存中的数据。
• 消息校验：校验对外发送的消息对象。
• 对外HSF调用校验：校验对外HSF调用的入参。

四 、实践技巧

1 、执行效率

对于接口测试，执行效率是不得不关注的一个点，若一个接口测试执行3分钟以上才能看到结果，会大大降低开发同学编写接口测试的热情。对于测试执行效率提高，建议的方案为：

• 最小化启动测试上下文，例如spring boot的应用，启动spring就可以了
• 使用内存数据库，例如h2
• 将中间件依赖mock掉

2、测试框架选择

对于测试框架，建议选择基于testng，能够提供通过配置文件做数据准备的测试框架。如果找不到合适的，可以自己基于testng进行封装。

3、 接口测试覆盖度

场景的完整性影响着测试用例的覆盖度，一方面需要开发同学基于业务场景的输入和测试经验枚举出正常和异常情况，另一方面接口方法也有一些固定需要测试的点，例如幂等测试，边界值测试，参数不正确测试等等。

同时也要通过覆盖率工具查看接口未覆盖的代码或分支逻辑，进行针对性的场景覆盖测试。根据我的经验，分支完整覆盖非常重要，特别是异常的分支。

五 、总结

要保障系统线上运行稳定，质量保障手段必不可少。虽然现在有很多自动化的保障手段，但接口测试依然是最基本的和最重要的保障手段之一。如能做到持续保障接口测试覆盖度和有效性，很大程度上会降低线上bug的产生，开发同学也会更有积极性去重构代码。

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走！

软件测试面试文档

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

进阶课程，涵盖了95%以上软件测试知识点，真正体系化！**

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取