2022 年 7 月 8-9 日，QECon 全球软件质量&效能大会在深圳举办。大会聚焦“研发效能、卓越工程、质量工程、数智化测试” 四大主题，吸引了数千名行业从业者参与。
会上，Eolink CEO 刘昊臻发表主题演讲《围绕 API 团队协作与自动化测试的实践》。在 API 资产被越来越多开发者和企业重视的情况下，我们如何做好围绕 API 的全生命周期管理以及研发协作？
刘昊臻从行业趋势、痛点，建设目标、实践经验、案例成果以及开源计划等几个方面，和大家分享了 Eolink 在 API 的团队协作与自动化测试方面的一些实践。
演讲概要：
-
API 管理的行业趋势、现状、痛点
-
API 管理平台的建设目标
-
API 管理与自动化测试平台的实践经验
-
应用案例与成果介绍
-
开源计划与 Todo List
以下为刘昊臻演讲全文：
大家好，我是 Eolink CEO 刘昊臻，我们在 2017 年创办的 Eolink，至今为超过十万家企业客户管理 API，也是目前国内最大的 API 管理 SaaS 平台，我们希望能帮助企业通过 API 连接全球的数据和服务。
| API 管理的行业趋势、现状、痛点
在早期开发软件，由于软件的系统复杂度不高，通常我们把所有代码都封装成一个整体，我们把这种架构叫做单体应用。
随着软件架构、开源生态的发展、以及我们对软件开发效率的追求，企业逐步开始使用开源代码或者第三方 API 。
现在随着云原生的普及，和微服务架构改造，几乎所有企业都大量使用了开源组件、第三方的 API ，甚至底层的核心技术几乎都是来自于第三方 API 。
来自 Linux 基金会的数据显示 7090% 的代码是由开源和第三方 API 来组成的，并且通过 API 产生的经济价值也变得非常巨大。现在行业内的绝大部分公司的现状，发现大家都面临一些基础问题的挑战。
比如有一半以上的团队，将半数时间花在了围绕 API 相关的工作上面。包括 API 开发、文档管理、前后端对接联调、自动化测试、安全防护、稳定性保障等方面。
现在随着企业对降本增效的进一步追求，代码管理及 CI/CD 也已经普及的情况下，许多团队也开始思考从 API 方面是否能够进一步提高团队的效率，让大家能够加更少的班，做出更好的产品，保障更好的质量。
Eolink 在过去每半年都会对用户做一次访谈，了解用户的一些痛点及需求的变化。
我们发现，大部分的团队都会认为 API 管理是一个非常繁琐的事情，API 的数量、协议、规范很多，编写麻烦，导致 API 文档的维护成本居高不下。其中有以下几项：
通过这些用户反馈，我们会发现 API 管理的问题往往分布在不同的团队里面，各种的诉求也不一样，因此很难通过一个简单的单点产品来解决。
于是便有了第一个问题：
我们要建设一个什么样的 API 管理平台，它的建设目标是什么？
| API 管理平台的建设目标
IT 系统的建设往往是为了实现业务目标，API 系统的建设，其实就是要让 API 成为推动业务发展的手段。
良好的 API 能够让内部迭代新产品或者新版本更快，能够让外部的协作者，合作方或者是客户更容易对接大家的产品，逐渐形成产品生态，甚至是让 API 能够产生交易的价值。前段时间企业微信就开始对微信第三方接口的调用进行收费，许多 SaaS 公司也将开放 API 作为重要的战略。因此，建设 API 系统并不仅仅是为了降本增效，更加是为了让 API 能够帮助企业完成业务目标，甚至成为第二增长曲线。
在这个目标之下，我们首先要让开发变得更简单，让我们 API 的管理变得更规范，让测试的工作能够逐步自动化，让运维能够更加智能，并且让 API 能够成为一个平台上的服务，而不是分散的管理。
于是就有了接口快速生成、前后端对接、零代码自动化测试等等的一些需求，背后对接着各种的数据库，各种类型的接口，帮助我们去整合微服务，甚至是与代码管理等平台能够关联起来，让 CI/CD 体系更加完善。
API 全生命周期一览图
有了目标，有了整体设计，接下来我们把 API 的各个阶段列出来，就能够看到 API 管理其实是一个流程长，且内容复杂的系统性问题，我们把它称之为 API 的全生命周期管理。
Eolink 在过去几年经历了许多探索，根据 API 全生命周期的需求，逐步推出了一系列 API 相关的产品，包括 API 快速生产、研发管理、自动化测试、网关、监控、开放平台等，实现对 API 的全生命周期覆盖。
| API 管理与自动化测试的实践经验
我们团队在 2016 年思考如何解决上述问题时，提出需要结合文档驱动与测试驱动两种模式。
首先文档驱动 指的是在开发 API 之前先把文档写好，明确功能需求、入参出参定义、异常情况处理等之后再进行开发。
测试驱动，则是要求每次迭代、每个接口都需要及时测试，如果测试不通过则需要持续进行改进，尽量不要将测试工作留到最后。
结合文档与测试驱动，就要求团队用清晰的文档代替口头表达，让开发、测试、运维、协作有迹可循；用测试结果推动开发进度，让团队沟通更直接。
我们发现在整个协作过程中，API 的信息其实是在不同的团队之间反复传递的，并且团队与团队之间往往存在等待的情况。前端需要等后端把接口先写好才能进行对接，测试团队需要对照着接口文档才能够设计测试用例，或者是编写测试代码，而接口在开发的过程中也不是一成不变的，即使上线了也有可能会修改。
因此，前端和测试团队就得根据最新的接口来调整自己的前端页面，或者是测试脚本。
于是我们总结出几个关键的问题：
-
如何解决团队之间的 API 共享？
-
如何让前端能够脱离后端提前进行对接？
-
如何能更快创建甚至自动创建测试用例？
-
如何让接口的变化能够自动通知到相关人员，甚至是推送到相关的测试用例或者是 Mock ？
-
如何解决多团队之间的异步协作？让大家都能够同时工作，而不需要互相等待。
这些问题在当时业内都没有很好的解决办法，因为要实现跨团队 API 协作，就需要打通不同团队的工具及数据，而市面上的产品都比较独立。
比如文档管理用 Swagger、Wiki 甚至是 Word 和 Excel、测试用 Postman、Jmeter、Pytest、运维也有自己的 APM 等，因此我们团队只能通过自研的方式逐步完善产品，并且实现全流程覆盖，开始了一系列的填坑之旅。
文档管理
首先一个好的文档是成功的开始。
我们做了一个图形化的 API 设计界面，支持 HTTP、Websocket、TCP、UDP 以及 Dubbo 等协议，让我们可以通过模板以及数据结构来快速创建 API 文档。文档里面会记录详细的参数、说明、示例等信息，并且自动生成 Mock。如果之前用过 Swagger 和 Postman 的也可以直接导入数据，或者绑定代码仓库，让我们从注解中扫描生成文档。
为了让生成文档更方便一点，我们做了 IDE 插件，可以直接鼠标右键生成 API 文档，目前支持 Java，未来也会考虑支持更多语言。
版本管理和共享
有了详细的 API 文档，接下来我们就可以像代码一样对 API 进行版本管理，比如每次 API 修改了哪里，字段的增删改查都可以标注出来。并且配合自动通知，比如通过邮件、飞书、企微、钉钉或者其他方式通知相关人员，让 API 的变更通知更加及时。
为了解决 API 在团队间共享的问题，我们还加入了分享链接，可以设置密码和分享范围，直接把文档链接发出去就可以让其他成员查看或者测试。有些情况下我们还希望对文档进行归档或者发给外部人员，这时候直接导出为离线文件，比如 PDF、Word、Excel 或者 HTML 都会更加安全。
通过以上的一些功能，我们就可以基本解决 API 信息在团队之间的共享问题。
快速测试
在整个 API 的迭代过程中，测试是一个非常高频且刚需的需求，当我们把 API 文档给管理好之后，我们希望能够让程序自动帮我们生成接口的测试页面。
因为在 Postman 或者是其他的测试工具里面去构造 Json 等数据是比较麻烦，只能够直接写一个完整的 Json 字符串，所以我们做了一个 Json 数据的图形化编辑器，让新手也可以在界面上直接编写 Json 和 XML 的请求数据。相信大家在测试过程中也经常需要对数据加解密或者生成随机数据，为了解决这个需求，我们还做了一个叫做数据构造器的功能，让开发和测试的同学可以在界面上直接对数据进行处理。
比如做 MD5、SHA 加解密、截取字符串或计算长度等。还可以随机生成各种类型的数据，比如说像身份证，手机号，邮编等等。
为了让测试好的接口和数据能够直接用在代码里面，我们做了代码的生成，可以直接从测试用例来生成各种语言的代码，直接复制粘贴就可以用在项目里面。
用例管理
当我们做完测试，往往还希望把这些测试的数据给保存成测试用例，方便我们下一次测试的时候能够快速调用。因此，我们在产品里面也集成了测试用例的管理，除了保存测试用例之外，还可以在测试用例里面设置断言规则，让系统自动判断返回结果。
下次当我们在进行回归测试的时候，就可以直接一键批量测试完所有的用例，并且看到接口在各种条件下是否产生异常，可以极大的提升测试的效率。
Mock
那么如何基于 API 文档做前后端对接呢？这里就少不了要用到 Mock API。
Eolink 可以自动根据 API 文档来生成 Mock API，比如 API 文档里面标注了有几种返回结果，系统会自动针对每种返回结果都生成一个对应的 Mock API。
如果觉得系统自动生成的 Mock 比较简单，我们还可以手动创建更强的 Mock，比如根据不同的请求参数触发不同的结果，通过编写 Javascript 来处理请求和返回数据，还支持 MockJS 等工具来快速生成数据，基本可以模拟各类 API 的情况。API 文档结合 Mock，让 Mock API 的使用更加简单，配合 API 版本管理和变更通知，也让前后端的工作流程自然结合到了一起。
自动化测试 & 测试报告
解决了前后端协作，接下来就是让测试工作也能自动化起来，在这里我们也做了一些新尝试。
比如有了 API 文档，我们会根据文档中对 API 的定义来排列组合，自动生成各种情况的测试用例，比如边界值、异常类型、参数缺失等情况。
而且可以在界面上直接编排测试流程，比如注册、登录、下订单、查物流、退出登录等一系列流程，里面涉及参数传递、数据处理、数据库查询、结果校验等工作，都可以在界面上完成。当我们设计好测试流程，下一步就是考虑怎么样能够让他自动地执行？在了解了许多用户的使用场景之后，我们在产品里面加入了定时以及触发式两种方式来执行自动化测试。
比如说我希望每天凌晨的两点钟，对关键业务或者是前一天提交的代码进行完整的测试，或者是每一次代码提交的时候都能够通过 Jenkins 或者是 Gitlab 之类的产品来调用我们的接口，触发相应模块的自动化测试。测试完成之后，我们还需要一个地方来统一管理所有的测试报告，报告里面需要展示测试的成功率，耗时，错误的用例列表以及错误的原因等，一个好的测试报告，可以帮助我们快速排查错误，减少非常多的不必要沟通。
而且和 Mock 一样，测试用例也是有可能发生改变的，那怎么样能够把这些 API 变更自动同步到测试用例里面呢？我们做了几种方案之后，最终决定做一个功能，可以一键将最新的 API 文档同步到测试用例里面，比如说文档添加或者删除了某些字段，那么用例里面也相应地增加或减少这些字段。
这样就可以进一步降低 API 自动化测试的学习和维护门槛，让一个实习生也能快速掌握 API 自动化测试。
新的尝试 & 改进
当然这还不够，我们尝试将流程图也加入到自动化测试中，让我们可以真正地拖拉拽生成测试流程，并且支持循环、分支等判断条件。更进一步的，我们在目前尝试结合 AI 的功能，让系统可以自动生成测试流程和测试数据，真正减少 90% 的自动化测试工作。
经过以上的一些调整之后，我们就可以发现，原本的 API 协作流程从一个串行的流程变成了并行的流程，后端、前端以及测试团队能够独立的开展工作，又互相之间有合作。比如像现在的这个流程图，后端先在产品里设计好 API，然后可以通过平台来生成基础的框架代码，并且在框架代码的基础上继续开发。
因为 API 文档已经事先设计好了，所以系统能够自动地根据 API 文档来生成 Mock API，让前端能够直接对接 Mock API 来调试页面，测试团队也能够直接在系统中基于 API 文档来编写测试用例。这些测试用例并不是像传统的那种思维导图，而是能够直接运行的测试用例，相当于将测试用例的设计和编码工作都提前进行了。
当接口开发完成之后，后端可以自行使用测试团队写好的测试用例来自测，前端可以将 Mock API 的地址注释掉然后再做更进一步的调试，测试团队可以针对所有的接口进行冒烟，或者是回归测试，并且将测试用例按照业务场景编排成测试流程，设置定时测试任务，或者是当下一次代码提交或版本发布时，对整个项目进行大范围的回归测试，保证系统质量。
| 应用案例与成果介绍
现在 Eolink 提供线上 SaaS 和私有化部署两种产品。并且已经应用在了多家成熟企业中。比如像奇安信、深信服、泰康集团等客户目前都在使用我们的 API 管理与自动化测试产品，管理内部超过 10 万的 API 信息并且进行自动化测试。
奇安信的许多产品线在版本发布地都需要经过我们进行全面自动化测试，确保产品的核心业务流程没有问题才可以继续验收。
接下来我拿某个金融行业的客户作为例子，看一下围绕 API 的团队协作以及自动化测试能够如何提升研发效能以及产品质量。
我们在 2020 年收到某银行的科技部邀请，希望我们能够帮助建设开放银行业务，其中很重要的一部分就是 API 的研发测试一体化平台，因为 API 是开放银行的核心，所以他们希望能够借此机会构建银行的接口管理规范体系，加速 API 开发与测试工作，为后续的开放银行业务打好基础。
银行方面在我们之前已经试过许多产品，包括自研平台、阿里云效、YAPI、RAP 等，但是都存在一些问题，比如对协议的支持比较少，一般只有 HTTP，缺乏版本管理，Mock 比较简单，没有将研发和测试团队的工作流程打通，导致效果并不理想。
而且熟悉银行的朋友应该都知道，银行内部往往有数量众多的供应商提供系统服务，而且许多系统的存在时间非常长，可能已经运行了十几年。因此不同的供应商、系统的 API 怎么做统一管理就是一个非常大的问题。
文档驱动
在了解情况之后，我们提出了文档和测试驱动的理念，建议通过一个统一的平台来规范地管理银行内部所有的 API 信息，并且围绕 API 信息进行协作，联动前端、后端和测试人员，构建更加敏捷的团队。并且这个 API 平台还可以通过 OpenAPI 与其他系统对接，强化 DevOps 能力。
测试驱动
在管理好了 API 之后，接下来就是要做自动化测试，通过界面而非代码的方式来做 API 自动化测试，可以让不同供应商的人员以及银行内部人员都可以快速上手，并且极大地提高效率。在这个过程中还可以不断完善测试数据，通过定时任务和持续测试来改进系统质量。
这个方案提出之后得到了银行方面的认可，并且也得到了非常不错的实施效果，我们一起来看一下。
- 亮点 1 : 通过平台实现 API 变更与订阅管理
首先是我们通过平台来实现 API 的变更和订阅的管理。值得特别关注的是，这里我们还对接了银行内部的版本发布平台，每次版本的迭代，或者是每个接口的变更，都可以设置版本号，当发布的时候就可以直接通知到接口的使用方，或者叫订阅方。
在产品内部，我们还维护了一套 API 的订阅关系，项目之间如果需要互相使用接口，则需要通过平台提前订阅，审核通过之后才能看到或者测试、对接相应的 API，这样也提高了接口调用的规范性和安全性。
- 亮点 2 : 通过平台将 API 文档转换为标准 ESB 配置
其次是我们取代了低效的 Excel 表格来管理 API 信息，之前银行内部有接近 200 套系统，上万个接口，这些接口存储在大大小小的不同的 Excel 表格里面，发布的时候需要通过 FTP 将表格上传到 Esb 系统的特定目录才能完成发布，整个过程非常的麻烦，而且之前的接口变更是通过邮件和线下口头沟通的方式，导致效率低下。
现在通过统一的 API 平台来存储 API 信息，并且将 API 快速发布到 Esb 就可以完成接口的版本更新，让整个过程更加简单，更加自动化。
| 开源计划与 Todo List
- Eoapi
借着这个机会，我们也很高兴和大家聊聊产品的开源计划，我们把两个核心产品逐步开源，让更多开发者和企业都能使用到我们的产品，并且促进 API 生态的发展。
首先是我们会把目前的 API 管理和测试的核心模块开源，我们把这个项目命名为 Eoapi，也就是 Easy & Open API，它能提供高效的 API 管理和测试功能，并且可以通过自定义插件来扩展功能。和现在市面上的 API 管理或者测试工具相比，Eoapi 的插件系统可以让社区在产品上实现各种各样的附加功能，如果你想将管理好的 API 信息快速导出为一种你们自定义的格式，或者接入一些 API 安全测试工具，都可以通过插件来快速实现。
- Apinto
其次是 Apinto，这个名字是由 API 和 Into 两个单词组合而成，意味着 API 的入口。Apinto 是我们将 Eolink 的企业级 API 网关彻底重构之后，重新设计的开源网关产品。
这是一个完全由 Golang 编写的高性能微服务网关，在相同环境下最高可比 Nginx、Kong 等开源产品提高约 50% 的访问性能，并且拥有极低的使用和部署门槛。和 Eoapi 一样，Apinto 也是一个插件系统，可以自由编写插件来扩展功能。相比于已有的开源网关，Apinto 结合了我们在 API 全生命周期中的一些最佳实践，而且基于 Go 语言开发，相信可以给喜欢 Go 语言的团队一个新的选择。
| 未 来
除了大力投入开源产品，目前我们也正在逐渐将AI能力融入产品中，让我们可以通过更智能的方式解决 API 相关的问题。并且通过插件市场和 API 开放平台，让更多开发者和企业可以一起参与 API 生态的建设。
