API研发实现规范化管理的价值

随着公司业务的增长、项目需求的不断变化，运维的成本越来越高，开发人员996也越来越常态化，而在大部分公司实行前后端分离的当下，研发团队用在沟通、测试、管理API中的时间和用在开发项目代码上的时间也越来越相差无几。
以下和API相关的问题广泛出现：
API 文档不清晰而不知道怎么对接和测试，需要反复和后端沟通，甚至要看代码；
前端和测试需要等待API开发完成才能继续进行工作，测试用例无法复用；
API变更了没有及时跟进，不知道哪里改动；
接口文档和测试是两套系统，来回切换并且无法同步数据；
自动化测试需要写脚本，学习成本、时间成本、维护成本高；

不着急说解决方案，我们先来理一下API开发的驱动方式。

在API开发的过程中，基本可以分为文档驱动和测试驱动。前者是指开发前先写好接口文档，用标准文档代替口头约定和笔记文档；后者是指在开发前先写好测试用例，快速用测试结果推动开发进度。

那么这两种驱动方式是割裂的吗？答案我会说不是。
传统接口文档的缺陷在于三点：自然语言的描述容易产生歧义；不能自动化地验证；不能保证文档与开发同步。由此，延伸出了与之对应的测试驱动。
那么换个思路，如果有个工具，能自动生成文档、还可以满足大部分的接口测试功能，不就可以了？
我们公司最近由于国产化需求，开始找新的API管理工具，后面找到了一个还不错的，叫Eolinker，能满足我们研发团队的API开发管理需求，还能直接导入原来的Postman和Swagger上的API项目和接口文档。
放两张使用的图，有用过的可以一起交流一下~
场景1：前端开发已经对接完API，将当前API状态改为待测试，并且通知相关测试人员进行测试。

场景2：后端已经开发完成API，自行使用测试人员写好的测试用例对API进行批量测试，排查错误。

使用地址：www.eolinker.com