共计 763 个字符，预计需要花费 2 分钟才能阅读完成。
随着公司业务的增长、我的项目需要的一直变动，运维的老本越来越高，开发人员 996 也越来越常态化，而在大部分公司履行前后端拆散的当下，研发团队用在沟通、测试、治理 API 中的工夫和用在开发我的项目代码上的工夫也越来越相差无几。
以下和 API 相干的问题宽泛呈现：
API 文档不清晰而不晓得怎么对接和测试，须要重复和后端沟通，甚至要看代码；
前端和测试须要期待 API 开发实现能力持续进行工作，测试用例无奈复用；
API 变更了没有及时跟进，不晓得哪里改变；
接口文档和测试是两套零碎，来回切换并且无奈同步数据；
自动化测试须要写脚本，学习老本、工夫老本、保护老本高；
不焦急说解决方案，咱们先来理一下 API 开发的驱动形式。
在 API 开发的过程中，根本能够分为文档驱动和测试驱动。前者是指开发前先写好接口文档，用规范文档代替口头约定和笔记文档；后者是指在开发前先写好测试用例，疾速用测试后果推动开发进度。
那么这两种驱动形式是割裂的吗？答案我会说不是。
传统接口文档的缺点在于三点：自然语言的形容容易产生歧义；不能自动化地验证；不能保障文档与开发同步。由此，延长出了与之对应的测试驱动。
那么换个思路，如果有个工具，能主动生成文档、还能够满足大部分的接口测试性能，不就能够了？
咱们公司最近因为国产化需要，开始找新的 API 管理工具，前面找到了一个还不错的，叫 Eolinker，能满足咱们研发团队的 API 开发治理需要，还能间接导入原来的 Postman 和 Swagger 上的 API 我的项目和接口文档。
放两张应用的图，有用过的能够一起交换一下~
场景 1：前端开发曾经对接完 API，将以后 API 状态改为待测试，并且告诉相干测试人员进行测试。
场景 2：后端曾经开发实现 API，自行应用测试人员写好的测试用例对 API 进行批量测试，排查谬误。
应用地址：www.eolinker.com
