说起接口测试，我想测试同学们并不感觉陌生。作为一名测试工程师，尤其是做了多年业务测试的测试工程师，在开始接触接口测试时，无论开发工程师是否提供了接口文档，我相信你都会对下面几种场景似曾相识：

➢ 开发人员提交测试的项目，附带着一个几十页的 Word 文档，里面是一行一行的访问地址和路由，面对这样的 Word 文档，不知道如何开始验证；
➢ 开发人员在即时通讯工具上，甩给你有好几页的这么一个传输消息，里面有各种嵌套的参数，你不知道这些参数都是干什么用的；
➢ 开发人员口头告诉你需要测试的接口地址，然后就什么都没再多说，你问了他几句话后，他就借口说自己忙，不再理你，而你看到那个又长、又复杂的地址，束手无策。

难道，面对这些状况，测试同学们就没办法自己分析接口，完成测试吗？

我现在告诉你，当然不是。

接下来，我就带你一起看看，一个理想的提测项目是什么样的，在实际工作中，绝大部分的提测项目又是什么样的，然后我们一起看看，如何一步一步解决一个不理想的提测项目。

一、关于一个理想的提测项目

一个理想的提测项目，在提测的过程中应该既包含前期参与的产品需求、原型设计，这些是由产品经理来提供的；也包含后端接口文档、代码单元测试脚本，这些是由开发工程师来提供的。这些都是你开展测试的必要输入内容，它们具体有这些作用：

➢ 产品需求
描述了系统的业务逻辑，通过这个文档，你才能知道怎么来设计测试用例；
➢ 原型设计
会更加直观地告诉你系统的使用逻辑，这对测试用例的设计、对系统的前期认知都是有辅助作用的；
➢ 接口文档
详细地描述了后端接口的访问方式和参数说明，使用这个输入项才能开展接口测试用例的设计、测试脚本的准备和测试数据的构建；
➢ 单元测试脚本
它是保障提测质量的必要环节，是研发工程师自测的一个有效手段，可以保障提测项目的提测质量；

这些内容不局限于 SUT（System Under Test，被测系统）的类型，SUT 既可以是一个手机 App，也可以是一个 Web 服务，甚至还可以是一个微服务接口。

所以，对于接口测试阶段来说，一个非常理想的接口测试，就是从完美的接口文档开始的。开发工程师在设计和开发接口的过程中，就在不断维护和更新接口文档，这其中包含了每一开发工程师提交测试的项目，附带着一个几十页的 Word 文档，里面是一行一行的访问个接口的访问方式、访问路由、输入参数含义、返回参数含义，以及一个完整的例子。

这种接口文档可能是以 Word 文档形式存在，也有可能是以Eolink 这种规范文档工具形式存在。说到 Eolink，这只是我使用过的一个接口文档的存在形式，是一个从代码生成的、以 Web 服务形式存在的接口文档，它可以伴随代码的变更同步变化，这就减少了很多开发工程师和测试工程师之间的沟通成本。

这样，当你拿到接口文档时，就可以快速使用各种工具或者代码来完成你的单个接口测试任务了。与此同时，你还可以通过一些参数设计、参数上下文传递，来完成接口的流程测试。

二、理想的情况很难发生

上面我说的是很理想的情况，但往往理想很丰满，现实很骨感，我相信你测试同学们肯定遇见过下面这些场景：

场景一：根据产品经理的一句话需求，开发工程师便开始任意发挥，“所见系统即需求”的情况普遍存在，这就更别说后续的单元测试和接口文档了；

场景二：开发工程师从来不写单元测试脚本，提测项目质量无法保障，接口文档更无从谈起，测试更是不知道如何开始完成接口测试；

场景三：就算拿到提测项目后，从部署测试环境到开始测试，一直都是摸索着前进，由于接口测试没有充分的输入条件，只能从 UI 层开始测试，结果导致交付质量大打折扣。

就像墨菲定律说的那样：可能发生的事情必将会发生。所以，上面我列举的接口测试难以推行的一些常见情况，都是日常在工作中会碰见的问题。

传统API文档管理繁琐：

• API数量，协议，规范众多
• 编写文档麻烦，协作效率下降
• 项目维护成本增加

规范化API文档管理：
统一的API文档有助于减少项目维护和沟通成本，无论什么项目、什么人编写什么API，系统都可以保证API文档的可读性，方便后续维护和团队协作。有一款方便管理、查阅API文档，提高日常代码（CV）效率，如果有一款API文档管理工具可以大大提高工作效率和高质量交付工作。

传统API开发协作慢：
➢ 前端开发进度受制于后端：单纯API文档缺乏Mock API，前端需要等待后端开发完成才能拿到测试数据，自己构造测试数据费时费力。
➢ 反复沟通浪费时间：由于文档滞后于代码，而开发经常在开发最后才完善文档，导致前后端对接需要反复沟通确认。
➢ 缺少统一沟通平台：如果API出现了什么问题，只能在内部通讯工具交流，既没有存档，也不便于多人协作。
➢ 文档变更不通知：后端开发改了代码和接口习惯于口头沟通，而不是通过文档明确地指出修改的内容，导致后期沟通成本高昂。
➢ 文档阅读体验差：文档不标准、内容不清晰、平台不统一等问题导致最终文档效果也不好，体验越差越不维护，导致破窗效应。
➢ 接口测试不方便：需要看着接口文档再另外使用工具进行测试，如果接口发生了变化，写好的测试也作废了，增加了重复工作量。

管理缺乏工具，针对研发工作需要有深入参与研发的管理工具才行。
通过Eolink工具管理API帮助团队内部进行协作，共享劳动成果：
团队之间没有参与任何沟通协作的内容，缺乏API定义、测试、协作的主动权。

测试维护成本高：
➢ 测试工作重复：需要看着接口文档再另外使用工具进行测试，如果接口发生了变化，写好的测试也作废了，增加了重复工作。
➢ 工作成果无法分享：每个测试人员都用单机测试工具编写测试脚本，但却没法共享和协作。
➢ 测试工作不自动化：一直希望促进自动化测试，但是没有真正运作起来，每天“点点点”依然消耗大量测试团队的精力。
➢ 测试效果无法量化：无法准确了解测试效果，没人可以说清今天、昨天、上周、这个月的测试情况如何，和之前比有何改进。
➢ 测试工作被动：测试总是排在最后进行，无法参与项目讨论，无法进行快速大范围回归测试，甚至无法按时完成测试任务，导致项目延期或带着忐忑上线。

引入Eolink管理API测试:
将文档和测试关联起来有助于减少API测试和维护测试用例的时间，不再需要一边对照API文档，一边打开其他的工具来测试。提高测试人员的工作效率。所有API测试数据、用例、报告都在平台中统一管理，减少测试团队的重复工作，让团队成员可以共享工作成果。

使用Eolink工具可以整合测试数据，测试用例，丰富测试报告；缩减API测试和维护测试用例的时间，减少测试团队的重复工作，提高测试人员的工作效率，并让团队人员可以共享工作成果。

借助工具开展自动化测试
传统API自动化测试工具上手门槛高，对成员水平要求高，无法快速在团队推广API自动化测试经常受到测试人员编码水平等因素的影响，难以大范围和高效实施。Eolink提供的API自动化测试可以不编写代码，测试人员进行简单的培训后即可编写复杂的测试用例，通过自动化取代手工来进行重复的API测试。

Eolink工具可以帮助测试团队提高测试效率和测试覆盖率

目前面临的测试过程中，我们完全可以借助工具作为辅助并且可以提高完成接口分析的效率：

➢ 通过 Eolink 来完成接口信息；
➢ 通过分析接口的访问方式、参数等信息整理出一些问题，和研发工程师沟通这些问题，将一些不知道的参数含义、参数取值范围等问题问清楚；
➢ 通过 Eolink 接口信息进行编辑，测试，一键生成测试用例，mock测试数据，监控，等功能促进团队高效协作；

通过这三步的循环，你就可以完成一个对系统接口信息的完善和维护，最终得到一份完整的高质量的测试结果。

https://www.eolink.com/ 可以把整个过程流程化，规范化，可能只需要我们花费一部分的时间去了解和真正使用这个工具，就可以做到在工作中效率最大化，不妨测试和开发同学都来试一试这个工具，感受是否可以让工作变的更加的高效呢？