从测试工程师蜕变成为测试架构师的过程中，我逐渐形成了对接口测试的认知。因此，和大家聊一下接口测试这件‘小’事，以及分享一下我和接口测试之间的缘分开始。
大量重复的工作让我逐渐失去目标，甚至开始怀疑人生；
刚进入测试行业时，大部分时间都集中在功能测试，主要工作内容就是设计测试用，然后按照设计的测试用例反复执行，每天被各种项目的测试用例淹没在工作中。那时我认为，测试就是一个点工的操作，并不是一个纯技术性质的一个工作。
后来在自动化测试的潮流中，开始接触Selenium，并开始自发的写一些自动化测试脚本。刚开始，沉浸在自己写的自动化脚本之中自娱自乐，每次手头负责项目迭代时候只要运行一下测试脚本，直接等着脚本自行结束就可以了，简直轻松又愉快。
可是随着自己负责的项目不断的迭代，从 month release 到 week release；Selenium 脚本越来越难以满足当前的测试任务了。一开始通过 Selenium 可以节省测试时间，高效的执行测试任务到快速的交付。后来，这反而变成了我测试工作中的一个负担，维护 or 不维护，这真的是一个值得思考的问题。维护，给自己工作之外的时间增加了更多的任务量；不维护，心里觉着很不甘心。做过UI自动化测试的同学应该会遇到过这样的一些问题，比如：每个项目前端页面更新的很快就会导致维护测试自动化脚本的成本极高，页面重构的工作也会导致脚本大面积的实效等问题，类似于这样的问题使得测试人员加班时间越来越长，哪怕通过996的工作模式基本勉强跟得上项目迭代。
Eolink 这个工具让测试人员重新思考了测试工作，让我逐渐体会到，测试工作也是一项技术驱动的工作，测试工程师也是一个技术岗位。
那时候其实没有太好的学习平台来让自己的技术能得到实际的应用，我把大部分的碎花片时间主要用在了刷技术博客上。机缘巧合之下，在测试窝平台看到一篇关于介绍测试工具类的文章吸引了我，让我了解到 Eolink 这个做接口测试的小工具，有些类似于国外的 Postman，当时这个工具的功能还没有现在这么强大，但是因为是全中文的，对比 Poatman 功能全是英文的，这点还是被我吸引的，但是因为方便，易学和易用的优点也是不容忽视的。随之变把 Eolink 应用到日常的工作当中，从接口测试开始完成我的测试任务，并逐渐积累了很多测试脚本。在使用 Eolink开始接口测试后，我逐渐放弃了 Selenium 的界面自动化测试，也摆脱了加班维护界面自动化测试脚本的困境；同时伴随着 Eolink 版本的升级，依靠它强大的功能，也提升了整个项目的测试工作速度，因此在很长一段时间里，我的工作都很轻松，每天都能准时下班。
接着在一次工作中，我主要负责中台的微服务接口测试，以及提高质量效能的工作，我的工作目标就是做完接口自动化测试中费时、费力的事情，这包括测试脚本的开发、测试数据的准备、测试执行以及测试结果收集等待等一系列工作。从使用工具完成接口测试，到自己写代码完成接口测试，在这个过程中我最深的感触就是：无论你在工作中参与了一个多么智能的测试平台的设计与开发，还是引入了一个多么强大的自动化测试框架，你首先都要会用最原始的方式完成这件事情，这才是万变不离的宗。测试行业是一个技术驱动的行业，而在测试的工作内容中，接口测试又是一项基础技术能力。
接口测试是测试人员的一门必修课
**对测试人员来说，为什么非要强调接口测试的必要性呢？**
单对项目的影响来讲的话，接口测试直接测试后端服务，更加接近服务器上运行的代码程序，也更能发现影响范围广泛的 Bug。引用一本 《软件测试的艺术》中至理名言：“越早发现 Bug，修复的成本越低。”
随着现在中台化、微服务化的发展，一套服务支持多种终端，例如Android 端、iOS 端、Web 端等，这些服务都是由一套后端服务支持的，上面这句话就可延伸为“越接近底层的 Bug，影响用户范围越广泛”。就如同你发现了一个 Web 端的界面错误，那么这个 Bug 只会影响 Web 端用户，但是如果后端服务有一个 Bug，这个 Bug 有可能会影响所有用户，无论他是使用电脑还是手机访问我们的系统。而接口测试就是为了后端服务测试而生的，它会保证后端服务的质量，避免这种情况出现。抛开它对项目的影响，单单从它对你自身的影响来看，你会发现，如今进入任何一个招聘网站，随意点开一个测试工程师的招聘要求，接口测试几乎已经成为测试招聘中一项必备的技能了。所以作为一名测试工程师，掌握接口测试，并能熟练完成接口测试，无疑对我们来说在求职时和工作中都有很多好处。
接口测试为什么重要？
业内测试同行们肯定听过这么一句话：**“测试要尽早介入，测试进行得越早，软件开发的成本就越低，就越能更好地保证软件质量。”**
是的，没错！
但是如何尽早地进入测试，作为软件测试工程师的你，是不是也没办法说得清楚呢？其实上面那句话中的“测试”，所指的并不是测试工程师这个人，而是指包含了单元测试、接口测试、界面测试等一系列质量保障活动的测试工作。说到单元测试、接口测试和界面测试，你是不是马上就想到了“测试金字塔模型”呢？
在这个金字塔模型中，界面测试、接口测试和单元测试，每一个阶段所占面积的大小，代表了它们在测试过程中的投入和工作量占比。你可以看到，单元测试在测试过程中，占据了绝大部分的比重，这表示单元测试需要你投入更多的时间和人力成本。但是，单元测试并非测试工程师的本职工作，它属于开发工程师的工作范畴。说到这你可能会问了：“如果开发工程师从来不写单元测试怎么办？”毕竟大部分开发人员都不爱写测试。
作为一个聪明的测试工程师，提供了两种解决手段：一种是用一些智能化框架补充单元测试工作；另外一种，就是加大我们自己主导的接口测试的工作投入比重，来弥补单元测试的不足，这样，上面那个金字塔模型就会逐渐演变成菱形模型。
那之所以出现从“金字塔模型”到“棱形模型”这种变化，并不是有人刻意提高测试工程师在整个交付流程中的地位，这其实是随着工作的不断进行，逐渐形成的结果。
在质量保障过程中，我们的测试工程师会不断增大接口测试的测试深度和测试广度，往下逐渐覆盖一些公共接口的单元测试内容，往上则逐渐覆盖应该由 UI 层保障的业务逻辑测试，这么做的主要目的，就是为了更好地完成质量保障工作，交付一个可靠的、高质量的项目。
所以，从接口测试这一环节开始，测试工程师就变成了质量保障工作的主要推动者，接口测试也变得愈发重要。想要做好接口测试，掌握了整个过程的推进方法，这包括如何分析一个不理想的提测项目的接口，并在自己的能力范围内完善和维护接口文档，最终设计一个流程化接口测试用例。
其中的关键点主要在于：
-
工具辅助。借助一些工具的辅助来完成接口分析。
-
分析问题。通过分析接口的访问方式、参数等信息整理出要解决问题。
-
询问解惑。针对问题和研发工程师进行沟通，把一些不知道的参数含义、参数取值范围等问题定义清楚。
那么，这些都准备好后，你又如何通过一个实际方法落地接口测试呢？
简单来说，Eolink 就是一个基于 HTTP/S 协议客户端工具。但它只是我们完成这次任务的手段，接口测试用例的设计和实现过程才是重点内容，所以，我们需要知道接口的每一个参数，以及一些接口的处理逻辑。
开始接口测试：
先通过接口测试的方法，测试每一个接口都是正确的，既要保证单接口的正确性，也要保证接口的业务逻辑正确性，这里所说的“正确”指的是“正确接受合法 Request 入参，正确拒绝非法 Request 入参”。
a，单接口的测试
单接口测试的重点，其实就是保证该接口的正确性和健壮性，也就是说，你既要保证这个接口可以按照需求，正确处理传入的参数，给出正确的返回；也可以按照需求，正确的拒绝传入非正确的参数，给出正确的拒绝性返回。
现在，我就带你一起使用 Eolink 来检测单接口的测试；
检查返回参数信息；
第二个接口：登录接口，它的访问方式是 POST，参数是 username 和 password，这两个参数均不可以为空，也不可以超过 10 个字符；如果 username 和 password 这两个字符串相同，会登录成功并返回后续的说明性文本，否则，就会正确拒绝登录。所以在这一步，我们会多检查一项 Request 的参数设计，用边界值方法设计的参数:
在获取了参数后，选择 Post 访问方式，输入登录接口的 URL，在 Request 的 Body 中输入 username&password的参数，然后点击发送，接下来，你就会在 Response 的 Body 中对应返回内容。如下图所示：
检查返回参数，并获取token值；针对token值做业务场景关联测试，也就是多接口测试；
通过单接口测试，可以更加接近于单元测试；通过业务流的接口测试，可以更加接近于界面所承载的交互中的业务流验证，这也是为什么现在很多人在提倡将测试模型由原来的金字塔形往菱形转变的依据之一了。
而完成了这一系列流程，其实你也就掌握了接口测试的思维：先从单个接口的测试开始，保障单个接口的正确性和健壮性，然后通过单个接口的测试完成多个接口的业务逻辑串联，站在业务逻辑的角度完成业务逻辑的正确性检测。你的接口测试也可以和持续集成结合到一起
通过 这个 Eolink 工具完成从单接口测试用例的设计到业务逻辑接口测试用例的设计，你就已经掌握了接口测试的思维以及具体的实现方法。但是到目前为止，测试人员可能还处在手动测试的阶段，虽然已经和以前基于界面的业务测经有了很大区别，但是距离自动化的接口测试还有一定的差距。不过你不用担心，因为这个差距仅仅是一个工具的距离。
不管是接口测试的了解，还是 Eolink 工具的选择，这篇文章让你有新的启发，也欢迎你把文章分享给你的朋友，我们一起来探讨和学习。
