2020 至今，因为各种起因，越来越多企业抉择近程办公。Eolinker 联合本身长期的近程研发合作教训，为企业推出 API 治理近程合作指南，以下计划不仅在 Eolinker 外部，也在泛滥客户中失去验证，心愿可能帮忙您疾速理解如何将 API 治理与自动化测试使用在理论的近程办公中。
API 治理的倒退过程、痛点及解决方案
在过来，许多研发团队并不重视研发过程中的 API 治理，认为 API 治理无非是治理一下 API 文档，只须要用 word 文档或者 wiki 把 API 形容写一下，等到须要进行团队合作的时候再把 API 文档通过文件或者 wiki 的形式发给前端和测试人员即可。这时候的 API 治理形式粗放，咱们把它称之为 1.0 时代。
但随着麻利观点的一直遍及，大家开始发现传统的 API 治理只偏重治理 API 文档是不行的，存在以下显著的问题：
- 1、API 文档编写不标准：不足对立文档格局，简写、漏写或不写具体阐明（开发人员总感觉本人看得懂即可）。
- 2、贮存平台不对立：公司外部每个我的项目团队都有本人的应用习惯，甚至一个我的项目外部能够同时存在多个 API 管理工具，平台不对立导致无奈高效保护和合作。
- 3、文档更新不及时：开发团队习惯于先开发后补文档，认为文档对于开发工作而已是一个附加的内容，导致更新不及时。
- 4、变更历史不记录：因为没有及时保护文档，当须要回头查看我的项目或进行工作交接时就会发现看文档不如看代码，反而拖慢工作进度。
- 5、测试人员无奈疾速编写测试用例：因为传统 API 文档仅仅是个文档，测试人员还须要应用其余工具编写测试用例。
- 6、并没有升高沟通老本：因为上述起因，前端、后端、测试、运维等成员常常因为不清晰的文档而引发争执，有时候反而减少了沟通老本。
为了解决上述问题而呈现 2.0 时代的工具，开始思考如何将开发与测试联合，比方通过代码注解生成 API 文档来缩小后端开发编写文档的累赘、能够基于 API 文档间接进行测试等。这个时代最突出的产品是 Swagger、Postman、Jmeter、SoupUI 等产品。随着研发测试一体化的观点推广，这些产品逐步成为目前支流 API 治理与测试工具，有着宏大的用户群体。
然而上述产品呈现时并未风行近程合作，因而其产品设计根本是基于本地开发和集体应用，因而当遇到越来越高的迭代速度和品质要求时便显得力不从心，从而呈现以下问题：
- 1、前端开发进度受制于后端：单纯 API 文档不足 Mock API，前端须要期待后端开发实现能力拿到测试数据，本人结构测试数据费时费力。
- 2、文档变更不告诉：后端开发改了代码和接口习惯于口头沟通，而不是通过文档明确地指出批改的内容，导致前期沟通老本昂扬。
- 3、接口测试不不便：须要看着接口文档再另外应用工具进行测试，如果接口产生了变动，写好的测试也作废了，减少了反复工作量。
- 4、测试工作反复：须要看着接口文档再另外应用工具进行测试，如果接口产生了变动，写好的测试也作废了，减少了反复工作。
- 5、工作成绩无奈分享：每个测试人员都用单机测试工具编写测试脚本，但却没法共享和合作。
- 6、测试工作不自动化：始终心愿促成自动化测试，然而没有真正运作起来，每天“点点点”仍然耗费大量测试团队的精力。
- 7、测试成果无奈量化：无奈精确理解测试成果，没人能够说清明天、昨天、上周、这个月的测试状况如何，和之前比有何改良。
- 8、测试工作被动：测试总是排在最初进行，无奈参加我的项目探讨，无奈进行疾速大范畴回归测试，甚至无奈按时实现测试工作，导致我的项目延期或带着忐忑上线。
并且这些产品并未解决 API 研发合作过程中的外围问题：如何将开发、测试、运维、团队合作四者联合，成为一个实用于团队的、灵便的、对立的 API 治理平台。并且可能为后续 API 监控、运维提供间接的反对。
咱们将实现了开发、测试、运维、合作等四大因素的成为 3.0 时代的产品。而 Eolinker 自 2017 年成立以来，始终致力于构建 API 全生命周期治理解决方案，目前是国内最大的在线 API 研发治理平台，旗下的线上 SaaS 产品以及离线私有化产品包含：
API 生成平台（API Factory）
API 研发治理与自动化测试平台（API Studio）
API 监控平台（API Monitoring）
API 微服务网关平台（API Gateway）
API 开放平台（API Open Platform），行将公布
Eolinker API Studio 的实践根底：文档与测试驱动开发（DTDD）
置信大家早已据说过以下开发模式：文档驱动开发（DDD）以及测试驱动开发（TDD）。
文档驱动开发指的是在开发之前先把文档写好，明确性能需要、入参出参定义、异常情况解决等之后再进行开发。这就好比咱们在做题之前须要先理解分明题目要求，否则不审题就下笔很容易导致最初返工。
而测试驱动开发指的是在开发之前先把测试计划 / 用例写好，只开发可能顺利通过测试的性能，如果测试不通过则继续进行改良。这就好比咱们考试前会先理解考试通过的规范，没有规范乱答一通必定没有好后果。
以上两种开发方式进行联合后就是 Eolinker API Studio 的设计理念：文档与测试驱动开发（DTDD）。简略地说就是：
用规范文档代替口头约定和笔记文档，让开发、测试、运维、合作有迹可循；
疾速用测试后果推动开发进度，让团队沟通更充沛、治理有事实根据，实现麻利开发。
因而，在 Eolinker API Studio 中，简直所有的合作工作都是围绕着 API 文档进行的，当你创立了 API 文档之后，你能够随时查看 API 的改变状况、依据 API 文档发动 API 测试、编写 API 测试用例、创立 Mock API、进行 API 自动化测试等。
咱们在接触了大量的客户后发现，采纳“DTDD”模式比单纯用 TDD 或 DDD 形式的成果更好，相比之前提到 2.0 时代的研发效率晋升以及我的项目品质晋升更是要进步数倍。
因而咱们十分建议您尝试这种形式进行工作。
初识 API Studio
创立第一个 API 治理我的项目
在 Eolinker API Studio 中，所有的 API 都是以我的项目的形式进行妥善治理，因而咱们首先须要创立一个 API 治理我的项目。同时咱们也提供了一键导入性能，能够疾速将 Swagger、Postman、RAP、YAPI 等产品内的数据疾速迁徙到 Eolinker 中。
创立 API 文档
在 API Studio 中，您能够通过三种形式来创立 API 文档：
1、手动创立 API 文档，API Studio 提供了十分全面的 API 文档格局，可能具体记录您的 API 信息。这种形式适宜所有用户，并且也是咱们举荐的形式。
2、关联我的项目与 Swagger URL，API Studio 主动从该地址获取最新 API 文档。这种形式适宜之前曾经在应用 Swagger，并且偏向于将文档写在代码注解中的用户。但这种形式会带来代码入侵的问题，让代码中退出了许多无关的信息从而减少保护老本。
3、关联我的项目与代码仓库，API Studio 主动从代码仓库中扫描代码注解生成 API 文档。目前这种形式反对 Java 以及 PHP 两种语言。这种形式也会带来代码入侵的问题。
当咱们创立好 API 文档之后，能够在 API Studio 中看到清晰的 API 文档信息，并且能够在此基础上进行测试 API、编写 API 测试用例、编写 Mock API、治理 API 版本等等的操作。
一键发动 API 测试
当咱们创立好 API 文档之后，能够立即对该 API 进行测试，API Studio 提供了以下次要个性来帮忙测试人员疾速发动 API 测试：
- 反对本地测试、局域网测试、在线测试等；
- 反对一键切换测试环境，应用全局变量、减少额定申请参数、扭转申请地址等；
- 反对间接在界面编辑 JSON、XML 申请数据，不再须要手写 JSON、XML 等数据结构；
- 反对将测试数据保留为测试用例，当前能够间接应用测试用例进行测试；
- 反对批量测试 API，比方测试登录接口的多种状况并且返回实时测试数据；
- 反对在测试过程中编写代码进行签名、加解密、生成随机数据等操作；
- …
下图：在测试界面能够间接编写 JSON 数据。
下图：一秒切换测试环境并且发动测试。
批量测试多个 API 用例，解放测试劳动力
在以往的合作形式中，测试人员工作总是排在最初进行，无奈参加我的项目探讨，无奈进行疾速大范畴回归测试，甚至无奈按时实现测试工作，导致我的项目延期或带着忐忑上线。
在 API Studio 中，因为合作是基于 API 文档进行的，当后端开发人员将 API 文档写好之后，测试人员就能够马上染指，在 API 文档的根底上编写测试用例，让测试工作前移。
当 API 开发实现之后，测试人员能够一键将 API 的测试用例全副测完，并且失去具体的测试报告。后端开发只须要看到测试后果就可能晓得本人的 API 是否满足测试需要，如果有异样则可针对性改良。
当 API 产生扭转后，测试人员只须要一键即可进行 API 回归测试，真正解放劳动力。
通过上述形式，后端和测试人员能够进行更严密地沟通，让测试驱动开发实现。
下图：批量测试 API 的多种数据状况，并且取得具体测试报告，能够在报告中查看 API 异样起因。
构建 Mock API，让前端解脱后端解放
在瀑布流开发模式中，如果前端开发人员须要进行页面对接，须要后端先实现 API 的开发工作，因而前后端开发的进度会相互影响。
通过 Mock API，您能够当时编写好 API 的数据生成规定，由 API Studio 动静生成 API 的返回数据。开发人员通过拜访 Mock API 来取得页面所须要的数据，实现对接工作。
Mock API 反对依据不同的申请参数返回不同的 HTTP Status Code、Header、Body 等数据。你能够在一个 API 文档里创立多个 Mock API，模仿前端发动的各种申请，不便对前端逻辑进行校验。
当我的项目正式公布时，只需将 Mock API 的地址前缀替换为理论的拜访地址即可。
比方：同一个我的项目中的 Mock API 的地址前缀是雷同的（如 mock.eolinker.com/uasyd1/…），因而能够在代码中将 Mock API 的地址前缀作为全局变量，我的项目上线时仅需替换变量的值即可扭转整个我的项目的 API 申请地址前缀。
下图：该 API 创立了多个 Mock API，前端能够传递不同的申请参数获取相应的返回后果，比方用户名为 jack liu 时返回登录胜利，用户名为 percy 时返回登录失败或随机字符串。
当 API 文档产生变更时主动告诉相干成员
许多用户在保护 API 时，常常遇到 API 文档变更了，然而前端和测试人员却不晓得的问题。为了解决这个痛点，API Studio 提供了变更告诉性能，当 API 发生变化时通过邮件和站内信主动告诉相干成员，并且显示变更的内容。
并且在 API Studio 中，咱们将 API 的状态划分为以下阶段，不便成员在查看 API 文档时理解 API 以后所处的状态。
联合 API 变更告诉的性能，咱们就可能实现：
1. 当 API 状态变为“开发”时，告诉后端开发；
2. 当 API 变为“对接”时，告诉前端进行对接；
3. 当 API 变为“测试”时，告诉测试人员进行测试；
4. 等等…
下图：设置当 API 删除或异样时，告诉某位成员。
近程合作时，间接对 API 文档进行评论标注
当您进行近程合作时，能够间接在 API 文档上公布评论，所有的沟通内容都会追随 API 文档保留下来并且依照版本分类好，而不是零散地存在各种聊天工具中。这样防止前期沟通时找不到根据而浪费时间。
下图：在 API 文档中间接发表评论，并且 @了我的项目中的另一位成员查看。
查看、回滚、比照 API 编辑历史
API Studio 中还提供了十分弱小的 API 版本治理性能，您能够随时回滚到任意一次 API 文档版本，并且还能够比照两个版本之间的差别。
当无奈用语言沟通更新了什么时，无妨试试版本比照~
如下：以后版本相比历史版本，删减了某些参数，会在界面中以红色标出。
除此之外，还有…
API Studio 的性能还远不止如此，您能够在我的项目中进行严格的人员权限治理、API 状态码治理、我的项目文档治理、测试环境治理等等，一切都是为了让团队合作可能更加轻松高效。
进阶！通过 API Studio 打造 API 自动化测试平台！
疾速理解市面上当先的 API 自动化测试
在 API Studio 中还提供了目前市面上当先的 API 自动化测试性能：
1. 零代码自动化测试：不须要写任何代码即可进行 API 自动化测试；
2. 代码模式自动化测试：编写大量 Javascript 代码即可进行简单流程的自动化测试；
3. 反对操作数据库：测试过程中反对操作数据库，执行数据插入、删除、编辑等操作；
4. 数据驱动测试：一个测试用例反对测试多组数据，别离生成测试报告；
5. 主动生成测试报告：每次测试都能够生成具体测试报告，反对在线查看和离线下载；
6. 反对定时测试工作：设置定时器主动执行测试工作，将报告发送给指定人员邮箱；
7. 反对 Open API 触发测试：能够通过 API 对接 Jenkins，随时进行 API 自动化测试；
8. 极低学习门槛：15 分钟培训即可疾速上手进行 API 自动化测试；
能够帮忙您疾速解决以下常见问题：
1. 需要公布前须要对我的项目进行回归测试，传统测试形式的覆盖面窄、效率低下。能够用自动化测试进步测试范畴以及效率；
2. 产品需要变动 / 代码改变后，测试人员无奈确定测试范畴。能够用自动化测试进行大范畴回归测试保障根本业务失常；
3. 传统测试形式的周期长，无奈每天、每小时、24 小时随时执行测试，并且依赖于人的专业性，测试成果不牢靠。能够用 API 自动化测试的定时测试工作或者将 API Studio 集成到 Jenkins 上，实现代码提交即触发测试并实时失去测试报告。
4. 传统测试团队成员之间不足合作，相互不分明各自编写的测试用例、测试脚本、测试后果等，导致重复劳动。能够用 API Studio 实现测试团队的在线合作。
5. 测试团队应用 API Studio 日常保护 API 自动化测试用例后，可无效解决上述问题，帮忙测试团队进步测试能力和效率。
在 API Studio 中，咱们提供了 UI 和代码模式两种测试用例编写模式：
1.UI 模式：反对通过界面模式编辑 API 自动化测试用例，无需编写代码即可实现较简单的 API 自动化测试工作。
2. 脚本模式：通过编写 Javascript 代码，能够实现简单的 API 自动化测试工作。
因为篇幅起因，咱们在此仅演示 API Studio 的自动化测试成果，如需理解具体内容能够拜访 Eolinker 官方网站查看。
如下图所示，您可通过界面形式编辑 API 测试流程、API 之间的数据管理、返回的校验规定，甚至是插入数据库操作等，而后一键即可取得测试报告。
脚本模式中，您只须要编写几行代码即可发动测试，并且反对从 API 文档主动生成测试脚本！
咱们能够抉择多个测试用例，一键批量测试并失去测试报告。
通过更多形式触发 API 自动化测试
API Studio 中提供了多种自动化测试的触发形式：
手动触发；
定时触发；
Open API 触发，可对接到 Jenkins 等继续开发平台中。
灵活运用即可打造一个属于您的测试效率神器！
理解更多对于 Eolinker 的产品信息
疫情的肆虐让有数的企业经营碰壁，以上是 Eolinker 联合本身长期的近程研发合作教训，为企业推出 API 治理近程合作指南，以下计划不仅在 Eolinker 外部，也在泛滥客户中失去验证，心愿可能帮忙您疾速理解如何将 API 治理与自动化测试使用在理论的近程办公中。咱们心愿可能为此尽绵薄之力，帮忙更多企业从传统、低效的开发方式中解脱进去。
官方网站：https://www.eolinker.com/