持续集成下接口自动化测试实践
目录：导读
引言
目前很多持续集成项目都需要执行接口层的测试，当你了解其基本概念，理解了接口协议、如何传参、测试原理后，无需 掌握程序语言，使用 行业 内成熟的接口测试 工具，就 可 以快速地在项目中展开接口测试，甚至可以实现自动化接口测试，并用于整个持续集成的过程。
进入正题前，不得不先提到测试分层，这是近年比较热议的主题，我们看看下图：
Unit 代表单元测试，Service 代表服务集成测试(或接口集成测试)，UI 代表页面系统测试。单元测试需要强大的代码能力，很多测试人员还没有能力去执行，因此目前大多数公司还处于开发自测的阶段。随着开源 UI 自动化测试框架 Selenium 的发展，WebUI 自动化测近几年已趋于成熟(Appium 是移动端 UI 自动化测试的代表框架)，但其有3个明显的缺点:
- UI 测试介入测试时机较晚，修复发现的漏洞成本较大；
- UI 测试很难发现底层逻辑问题；
- 页面元素经常变换，导致自动化产出、投入比偏低，而这些恰恰是接口自动化测试所能解决的问题。
针对接口自动化测试，目前在业内有两大类解决方案：
- 一类是通过代码编写接口测试框架，实现接口自动化测试，其要求测试人员掌握扎实的编程基础；
- 另一类是借助接口测试工具，配合 Postman、Eolink 等集成工具实现接口自动化测试持续集成。
前者灵活，但是具有一定的学习门槛，而后者的学习成本更低，适合新人上手。
接口自动化测试工具介绍
接口测试工具有很多，其中 Eolink 安装简单、使用方便、功能强大，还支持团队协同、接口监控、Mock 等功能，这些是 Postman 等一些海外工具所不具备的。我们可以借助 Eolink 工具，更好的组织内开展接口测试持续集成。
Eolink体验地址：Eolink-api接口管理平台_api管理系统_接口自动化平台
我所在的电力行业支付项目，每周需要迭代1次，每次系统集成前必须优先安排进行接口测试，测试的内容包括内部和第三方接口（特别是支付网关、银行接口、监管服务等）进行功能或数据处理，在短时间内将进行高集中遍历：
发布前需要对项目进行回归测试，但是传统测试方式的覆盖面窄、效率低下，使用 Eolink 自动化测试，提高了测试范围以及效率；
2. 产品需求变动/代码改动后，测试人员无法确定测试范围。可以用自动化测试进行大范围回归测试，保证基本业务正常，借助测试工具的监控能力及时发现接口变化与代码变动；
如图：Eolink获取swagger同步 openapi 界面
如图：gitlab中设置钩子界面
接口自动化测试在持续集成中的运用
3.传统测试方式的周期长，无法每天24小时随时执行测试，并且依赖于人的专业性，测试效果不可靠。可以用 API 自动化测试的定时测试任务或者将 API Studio 集成到 Jenkins 上，实现代码提交即触发测试并实时得到测试报告。
4.传统测试团队成员之间缺乏协作，互相不清楚各自编写的测试用例、测试脚本、测试结果等，导致重复劳动，可以用 API Studio 实现测试团队的在线协作。
如图：团队成员可以协同测试用例设计
如图：当 API 发生变化时通过邮件和站内信自动通知相关成员，并且已与QQ和飞书打通
5.测试团队使用 API Studio 日常维护 API 自动化测试用例后，可有效解决上述问题，帮助测试团队提高测试能力和效率。
小结
持续集成的概念其实并不复杂，就是一系列频繁的操作流程：包括构建、部署、测试和发布等。能够快速发现错误、防止分支大幅偏离主干、快速更新迭代和发布。
为了达到使产品可以快速迭代，同时还能保持高质量的集成效果。它的核心措施是在代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能成功集成。
所以在分层自动化测试的思想指引下，接口层的自动化测试是最为行之有效、门槛不高、且 ROI 最优的投入策略，值得我们开展与实践。
这篇贴子到这里就结束了，最后，希望看这篇帖子的朋友能够有所收获。
获取方式：留言【软件测试学习】即可
如果你觉得文章还不错，请大家 点赞、分享、留言 下，因为这将是我持续输出更多优质文章的最强动力！